- 23 Mar, 2022 16 commits
-
-
Eric Pouech authored
Signed-off-by:
Eric Pouech <eric.pouech@gmail.com> Signed-off-by:
Alexandre Julliard <julliard@winehq.org>
-
Eric Pouech authored
Signed-off-by:
-
Eric Pouech authored
Signed-off-by:
-
Paul Gofman authored
Signed-off-by:
Paul Gofman <pgofman@codeweavers.com> Signed-off-by:
Huw Davies <huw@codeweavers.com> Signed-off-by:
-
Paul Gofman authored
Signed-off-by:
-
Zebediah Figura authored
Signed-off-by:
Zebediah Figura <zfigura@codeweavers.com> Signed-off-by:
-
Zebediah Figura authored
Signed-off-by:
-
Zebediah Figura authored
Signed-off-by:
-
Zebediah Figura authored
Only return it from UrlGetPartA(). Signed-off-by:
-
Floris Renaud authored
Signed-off-by:
Floris Renaud <jkfloris@dds.nl> Signed-off-by:
-
Aurimas Fišeras authored
Signed-off-by:
Aurimas Fišeras <aurimas@members.fsf.org> Signed-off-by:
-
Byeongsik Jeon authored
Signed-off-by:
Byeongsik Jeon <bsjeon@hanmail.net> Signed-off-by:
-
Tim Clem authored
Mac driver version of a8b4cf7f. Combined with the previous patch that reordered synthesized modes, the Mac driver implementation of EnumDisplayModesEx now returns modes in the same order as the X11 driver. Signed-off-by:
Tim Clem <tclem@codeweavers.com> Signed-off-by:
-
Tim Clem authored
Also return higher synthesized bitdepths first. Signed-off-by:
-
Tim Clem authored
Prefer supported display modes over similar unsupported ones. Centralizes the logic from the ChangeDisplaySettingsEx and EnumDisplaySettingsEx implementations. Signed-off-by:
-
Tim Clem authored
Introduce a helper function to determine if a mode is preferred over another. Signed-off-by:
-
- 22 Mar, 2022 24 commits
-
-
Zebediah Figura authored
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=51713Signed-off-by:
Matteo Bruni <mbruni@codeweavers.com> Signed-off-by:
-
Alistair Leslie-Hughes authored
Signed-off-by:
Alistair Leslie-Hughes <leslie_alistair@hotmail.com> Signed-off-by:
-
Rémi Bernon authored
Signed-off-by:
Rémi Bernon <rbernon@codeweavers.com> Signed-off-by:
-
Rémi Bernon authored
Signed-off-by:
-
Rémi Bernon authored
Signed-off-by:
-
Rémi Bernon authored
Signed-off-by:
-
Rémi Bernon authored
Signed-off-by:
-
Zhiyi Zhang authored
Signed-off-by:
Zhiyi Zhang <zzhang@codeweavers.com> Signed-off-by:
-
Gabriel Ivăncescu authored
Signed-off-by:
Gabriel Ivăncescu <gabrielopcode@gmail.com> Signed-off-by:
Jacek Caban <jacek@codeweavers.com> Signed-off-by:
-
Huw Davies authored
This is equivalent to commit 01ad5030 in the coreaudio driver. Signed-off-by:
Andrew Eikum <aeikum@codeweavers.com> Signed-off-by:
-
Huw Davies authored
Signed-off-by:
-
Huw Davies authored
The syscall itself is temporary. Signed-off-by:
-
Huw Davies authored
Signed-off-by:
-
Huw Davies authored
Signed-off-by:
-
Huw Davies authored
Signed-off-by:
-
Jinoh Kang authored
The client can set mark_pending to indicate that the full-blown I/O completion mechanism shall be triggered (asynchronous completion) even if the status indicates failure. Signed-off-by:
Jinoh Kang <jinoh.kang.kr@gmail.com> Signed-off-by:
-
Jinoh Kang authored
Today, we assert that a short write clears the FD_WRITE event bit; however, short writes can never happen on Windows in the first place. We're testing for a property of a socket behaviour that does not exist on Windows, but currently happens to be exhibited by Wine. Ignore short writes, and continue sending until it fails with EWOULDBLOCK. This way, the test won't care whether or not a short write clears FD_WRITE. This allows us some flexibility in implementation of send(). Signed-off-by:
-
Jinoh Kang authored
Shift the resposibility of setting initial status from set_async_direct_result request handler to async_set_result(). Signed-off-by:
-
Jinoh Kang authored
Commit 15483b1a (server: Allow calling async_handoff() with status code STATUS_ALERTED., 2022-02-10) introduced the set_async_direct_result handler which calls async_set_initial_status(). However, the async_set_initial_status() call does nothing since async->terminated is set, leaving the async in a confusing state (unknown_status = 1 but pending/completed). So far, this issue is unlikely to have been a problem in practice for the following reasons: 1. async_set_initial_status() would have unset unknown_status, but it remains set instead. This is usually not a problem, since unknown_status is usually ever read by code paths effectively unreachable for non-device (e.g. socket) asyncs. It would still potentially allow set_async_direct_result to be called multiple times, but it wouldn't actually happen in practice unless something goes wrong. 2. async_set_initial_status() would have set initial_status; however, it is left with the default value STATUS_PENDING. If the actual status is something other than that, the handler closes the wait handle and async_satisfied (the only real consumer of initial_status) would never be called anyway. For reasons above, this issue is not effectively observable or testable. Nonetheless, the current code does leave the async object in an inconsistent state. Fix this by removing the !async->terminated check in async_set_initial_status(). Also, remove assert( async->unknown_status ). The client can now trigger the assert() by calling set_async_direct_result on a device async, thereby causing async_set_initial_status() to be called twice. Signed-off-by:
-
Alexandre Julliard authored
Signed-off-by: -
Alexandre Julliard authored
Signed-off-by: -
Alexandre Julliard authored
Signed-off-by: -
Alexandre Julliard authored
Signed-off-by: -
Alexandre Julliard authored
Signed-off-by:
-
