| Summary: | vesa driver interacts badly with KMS | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | xorg | Reporter: | Christopher James Halse Rogers <chalserogers> | ||||||||||
| Component: | Driver/Vesa | Assignee: | Xorg Project Team <xorg-team> | ||||||||||
| Status: | RESOLVED FIXED | QA Contact: | Xorg Project Team <xorg-team> | ||||||||||
| Severity: | normal | ||||||||||||
| Priority: | medium | CC: | ajax, aros, hramrach, marcin.slusarz | ||||||||||
| Version: | unspecified | ||||||||||||
| Hardware: | Other | ||||||||||||
| OS: | All | ||||||||||||
| Whiteboard: | |||||||||||||
| i915 platform: | i915 features: | ||||||||||||
| Attachments: |
|
||||||||||||
This also happens on a PC with ION chipset and external screen. What's worse, vesa driver restores the card to text mode on exit which does not work with the KMS drmfb. Created attachment 34393 [details] [review] Fail to bind to pci devices being managed by a drmfb Here's a patch to fix this. When LIBPCIACCESS is defined, configure additionally checks for a new-enough libdrm (and xf86driproto - needed for DRICreatePCIBusId), and if so will add a check for kernel modesetting in the PCI probe function. Ideally, such checks shouldn't have any build time dependencies - building a driver without the prerequisites for KMS support doesn't make it work any better with KMS. :) I could certainly duplicate the libdrm code for drmCheckModesettingSupported to make the kms check unconditionally built. Are there a lot of cases where someone will build vesa on a system without support for kms and deploy it on a system with support for kms, though? And I don't think vesa wants to have a hard build-time dependency on a new-enough libdrm does it? I would say that the typical case would be old vesa driver which does not have this patch in any form. Otherwise people rebuilding X should have new enough setup. Perhaps a fat warning in configure output is in order but that's it. Created attachment 34500 [details] [review] New patch, with shouty configure warning Here's a revision of the previous patch, but with a shouty configure warning when the dependencies for kms detection are not available. It still won't do kms detection if the X server isn't built with libpciaccess, and it won't complain either; is this a configuration I should be caring about? Is such configuration even used? You do need libpciaccess for most drivers to work, right? Still if people build kdrive or what was the name of the simplistic single-driver X servers then perhaps it makes sense. Are these around still? I would say adding a warning for a possible issue that can be easily detected in code is better than receiving loads of bug reports but I am not a X developer or anything so take my suggestions with a grain of salt. Created attachment 35807 [details] [review] KMS detection - part 2 Patch which drops dri dependency when detecting KMS *** Bug 28896 has been marked as a duplicate of this bug. *** Was this fixed already? There is a multitude of patches but bug is still marked as new. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
Created attachment 33749 [details] Xorg log When using nouveau's kernel module providing KMS, the vesa driver fails to properly set the mode on my laptop's LVDS display, resulting in the display "blooming". Since it should be quite easy to detect the presence of KMS, perhaps the vesa driver could fail to load when it detects a KMS framebuffer? Xorg.0.log of the session with blooming LVDS attached.