--
v2: winex11: Remove now unnecessary window surface BITMAPINFO.
winewayland: Remove now unnecessary window surface BITMAPINFO.
wineandroid: Remove now unnecessary window surface BITMAPINFO.
winemac: Remove now unnecessary driver surface BITMAPINFO.
win32u: Get rid of the unnecessary offscreen window surface struct.
win32u: Introduce a new helper to get surface color info and bits.
win32u: Pass BITMAPINFO and color bits to window surface flush.
win32u: Introduce a new helper to update layered window surface attributes.
win32u: Move layered surface attributes to the window_surface struct.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5947
This part XII of cmd engine rewrite.
This serie implements proper support for && and || command chaining operators:
- implement proper precedence parsing
- implement semantics for the operators
- for this to work, we need to have expected success/failure from commands;
this is supported here for external commands (and calling into a label or
another BAT/CMD file), but support has to be added for all builtin
commands
- that's a big mess as behaviors is far from homogeneous among the builtins:
+ some builtin set coherent success/failure vs errorlevel information
+ some report success/failure, but only set errorlevel upon failure
(keeping errorlevel from previous commands untouched),
+ some even report success (even in case of failure) yet set errorlevel
in case of failure,
- so the next series will now concentrate on testing success/failure and
errorlevel for every builtin command (sigh)
- for now, to help the transition phase, we can distinguish if a builtin
properly reports success/failure; if a builtin with success/failure
ability is used in a chaining operator, we implement the intented
behavior of the chaining operator; otherwise,
we keep old behavior (ie always execute LHS and RHS whatever the
success/failure status).
This shall be removed when all builtin commands report success/failure.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5949
This should reflect what we actually support, while still being a superset
of what native drivers actually support.
Native driver support varies, but, as the comments document, native drivers
(at least as of windows 10) support only RGB -> RGB, YUV -> RGB, and BC -> RGB
conversions. The actual formats supported are a more limited subset than exposed
(despite that the video cards should be perfectly capable of supporting more
conversions) but erring on the side of overreporting seems safer.
--
v3: wined3d: Implement wined3d_check_device_format_conversion().
https://gitlab.winehq.org/wine/wine/-/merge_requests/5816