[Bug 42413] New: NVIDIA Closed Drivers 256/ 8bpp Colour mode near Impossible with Current Workarounds.
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(a)winehq.org Reporter: oiaohm(a)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.
https://bugs.winehq.org/show_bug.cgi?id=42413 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |austinenglish(a)gmail.com Severity|normal |enhancement --- Comment #1 from Austin English <austinenglish(a)gmail.com> --- For reference, what version of the Nvidia driver are you referring to? -- 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=42413 Zebediah Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12(a)gmail.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=42413 --- Comment #2 from oiaohm <oiaohm(a)gmail.com> --- NVIDIA 375.26 is the version I am sitting on. I have found one very bad and wrong work around using virtualgl that still end up with a broken opengl solution with Xepher and Xnest so not a place you want to recommend people testing program. It does not matter if you want to start up a 8 bit or 24/32bit Xepher or Xnest both going to fail the same way.
Xlib: extension "GLX" missing on display ":
Result no opengl. https://bugs.launchpad.net/qtcreator-plugin-autopilot/+bug/1474108 This is a autopilot Reported bug by other using different versions of Nvidia to mine. So Xepher and Xnest are broken. The xinit failure is different. vesa: Ignoring device with a bound kernel driver. Were it just does not start. The xinit path might be away to make it work but this is not going to be a simple do this instruction. So the xinit instructions if there is a workable path would have to be rewritten. So none of these paths are easy any more. Should have been more clear that the xinit failure is different but the problem is basically the same. -- 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)
-
wine-bugs＠winehq.org