[Bug 57584] New: 8-bit color mode is broken in Wine 9.11 and later
https://bugs.winehq.org/show_bug.cgi?id=57584 Bug ID: 57584 Summary: 8-bit color mode is broken in Wine 9.11 and later Product: Wine Version: 9.11 Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: winex11.drv Assignee: wine-bugs(a)winehq.org Reporter: alexhenrie24(a)gmail.com Distribution: --- Created attachment 77694 --> https://bugs.winehq.org/attachment.cgi?id=77694 Regedit on Wine 9.22 in Xephyr Similar to Bug 48088, palette colors are being mapped incorrectly again. Steps to reproduce: 1. In one terminal, run `Xephyr :2 -ac -screen 800x600x8` 2. In a second terminal, run `DISPLAY=:2 openbox` 3. In a third terminal, run `DISPLAY=:2 wine regedit` `git bisect` says: commit 6ace92e0cafcc381f324fc831f3006fb15db4b4e (HEAD) Author: Rémi Bernon <rbernon(a)codeweavers.com> AuthorDate: Mon Jun 3 17:48:30 2024 +0200 Commit: Alexandre Julliard <julliard(a)winehq.org> CommitDate: Mon Jun 3 23:24:59 2024 +0200 winex11: Create a HBITMAP for the allocated surface pixels. dlls/winex11.drv/bitblt.c | 77 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++------------------- 1 file changed, 58 insertions(+), 19 deletions(-) -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=57584 Alex Henrie <alexhenrie24(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.winehq.org/sho | |w_bug.cgi?id=48088 Regression SHA1| |6ace92e0cafcc381f324fc831f3 | |006fb15db4b4e Keywords| |regression, source -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=57584 Alex Henrie <alexhenrie24(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rbernon(a)codeweavers.com -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=57584 --- Comment #1 from Rémi Bernon <rbernon(a)codeweavers.com> --- I'm curious, what is the use case for non-32bit (more specifically 8/16bit) host display modes? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=57584 mrdeathjr28(a)yahoo.es changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mrdeathjr28(a)yahoo.es -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=57584 --- Comment #2 from Alex Henrie <alexhenrie24(a)gmail.com> --- There are quite a few 90's games that demand 8-bit color mode: Bug 46666 is one example. That's why Windows has a "Reduced color mode" checkbox among its compatibility options. See https://gitlab.winehq.org/wine/wine/-/wikis/256-Color-Mode for more information. It wouldn't be as big of a problem if Wine could emulate 8-bit color mode in the X11 driver, transparently translating 8-bit colors to 32-bit colors like in Windows's compatibility mode. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=57584 Fabian Maurer <dark.shadow4(a)web.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dark.shadow4(a)web.de -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=57584 --- Comment #3 from Rémi Bernon <rbernon(a)codeweavers.com> --- I thought we were emulating 8bit display mode already, but maybe only for GDI rendering and we're then missing it on the GL/VK side. As we're likely going to move towards more virtualization of the GL/VK rendering (for DPI scaling, compositing, etc) this use case would be addressed that way, and I'm not sure it's worth supporting such exotic host display server configuration. Anyway, it was working before, I'll have a look. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=57584 Rémi Bernon <rbernon(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Fixed by SHA1| |9dc80fb036a59ea9140a8413af3 | |27672d51eb840 Resolution|--- |FIXED --- Comment #4 from Rémi Bernon <rbernon(a)codeweavers.com> --- This should be working better with 9dc80fb036a59ea9140a8413af327672d51eb840. The color mapping is still slightly different from before for some reason, but I think the window surfaces were previously using 8bpp DIB without a color table, which doesn't seem to be possible with the HBITMAP that is now used as an interface. It's still possible to force something closer to the old behavior with X server side GDI drawing (ClientSideGraphics = N in X11 Driver registry options), but looking at regedit and winecfg it didn't seem really necessary and things are readable enough. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=57584 Alexandre Julliard <julliard(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #5 from Alexandre Julliard <julliard(a)winehq.org> --- Closing bugs fixed in 10.0-rc5. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=57584 --- Comment #6 from Alex Henrie <alexhenrie24(a)gmail.com> --- Created attachment 78186 --> https://bugs.winehq.org/attachment.cgi?id=78186 About Wine on Wine 10.3 in Xephyr The situation is arguably better now, but it's not like it was before the regression. Some colors are correct, but others still seem to be chosen at random. Take for example the green splotch on the wineglass on the About tab in winecfg, and the green text on the Apply button. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=57584 --- Comment #7 from Alex Henrie <alexhenrie24(a)gmail.com> --- Created attachment 78187 --> https://bugs.winehq.org/attachment.cgi?id=78187 Audio config on Wine 10.3 in Xephyr with client-side graphics ClientSideGraphics=N isn't any better overall: Although it makes the text more legible in some places (like the tab titles), it causes some text to render as black on a black background which is completely unreadable. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=57584 Alex Henrie <alexhenrie24(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|FIXED |--- Status|CLOSED |REOPENED --- Comment #8 from Alex Henrie <alexhenrie24(a)gmail.com> --- Reopening because the issue was not fully resolved. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=57584 Alex Henrie <alexhenrie24(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #78187|Audio config on Wine 10.3 |Audio config on Wine 10.3 description|in Xephyr with client-side |in Xephyr without |graphics |client-side graphics Attachment #78187|Audio config on Wine 10.3 |Audio config on Wine 10.3 filename|in Xephyr with client-side |in Xephyr without |graphics.png |client-side graphics.png -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=57584 --- Comment #9 from Rémi Bernon <rbernon(a)codeweavers.com> --- Created attachment 79810 --> http://bugs.winehq.org/attachment.cgi?id=79810 Winecfg about tab It now looks like this for me with Xephyr. It might be some change on the X server side, but note how it also seems to look much better with no Windows theme selected. Can we close this or decide it's not a regression? I don't think we should spend much time on 8bpp X11 server display depth support, it's unlikely going to be a common use case and I don't see what else we could do about it. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=57584 --- Comment #10 from Rémi Bernon <rbernon(a)codeweavers.com> --- This is with ClientSideGraphics=N, but disabling theming also improves the display with ClientSideGraphics=Y, though the colors aren't as good. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=57584 --- Comment #11 from Alex Henrie <alexhenrie24(a)gmail.com> --- It turns out that reverting the fix for Bug 48088 restores the correct colors in Xephyr. The original fix didn't make much sense to me in the first place (why would the window palette be hard-coded?) and it seems that with your HBITMAP change in commit 6ace92e0caf, it is now unnecessary. Patch sent: https://gitlab.winehq.org/wine/wine/-/merge_requests/9619 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (1)
-
WineHQ Bugzilla