[Bug 42413] New: NVIDIA Closed Drivers 256/ 8bpp Colour mode near Impossible with Current Workarounds.

wine-bugs at winehq.org wine-bugs at winehq.org
Thu Feb 9 17:56:24 CST 2017


https://bugs.winehq.org/show_bug.cgi?id=42413

            Bug ID: 42413
           Summary: NVIDIA Closed Drivers 256/8bpp Colour mode near
                    Impossible with Current Workarounds.
           Product: Wine
           Version: 2.1
          Hardware: x86
                OS: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: winex11.drv
          Assignee: wine-bugs at winehq.org
          Reporter: oiaohm at gmail.com
      Distribution: ---

The workarounds to use 256/8bpp documented here
https://wiki.winehq.org/256_Color_Mode  of Xephyr, Xnest and Xinit do not work
when using Nvidia binary drivers even basic glxinfo test will fail out with
XLib unable to access GLX of course for wine wanting to use opengl this is now
in trouble.   The VNC suggestion leads users into the path of what VNC server
some of those no longer work with 8bpp.

https://www.x.org/wiki/Releases/7.8/ As noted here all of Xepher and Xnest are
marked for future replacement by xf86-video-nested that may or may not fix the
issue.

Don't say use open source drivers because Nvidia has habit of not releasing
firmware to do basic things like correctly run the cooling fans so the open
source drivers are very limited use.   Same applies to other closed source
drivers.

Nvidia is the most common desktop driver with this issue.   Of course
attempting to run wine on Android and the like the project will not be promised
that the closed source drivers will support 8bpp mode directly.

Solution could be inbuilt support for handling 8bpp mode.   The hardware these
days is 24/32 bit so it is possible for a future closed source driver to be
missing the 16bpp randr modes as well.   So while developers are looking at
making 8bpp mode work without having to change screen to 8bpp adding support
to-do the same with 16bpp would be good future proofing.

Running application inside virtual desktop mode would be acceptable as this is
like what using Xephr or Xnest are like this where they work.

Basically wine project has got away with colour depth not be a problem the
project has had to worry about.  Problem is the systems that allowed this fact
have failed for a decent percentage of users.

I do suspect implementing from what has been said will cause stability problems
so this could be a feature that has to start life in the staging branch.

This is me reporting a bug from a support point of view.   I am basically
stuffed giving people advice how to make 256/8bpp applications in wine when
they have NVIDIA closed source without some change.   Also connecting every
application with a 8bpp colour mode would be insane.

-- 
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.



More information about the wine-bugs mailing list