Bug 26878

Summary: vesa driver interacts badly with KMS
Product: xorg Reporter: Christopher James Halse Rogers <chalserogers>
Component: Driver/VesaAssignee: 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:
Description Flags
Xorg log
none
Fail to bind to pci devices being managed by a drmfb
none
New patch, with shouty configure warning
none
KMS detection - part 2 none

Description Christopher James Halse Rogers 2010-03-03 21:57:36 UTC
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.
Comment 1 Michal Suchanek 2010-03-12 06:20:01 UTC
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.
Comment 2 Christopher James Halse Rogers 2010-03-24 01:24:02 UTC
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.
Comment 3 Michel Dänzer 2010-03-24 05:07:12 UTC
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. :)
Comment 4 Christopher James Halse Rogers 2010-03-24 16:26:38 UTC
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?
Comment 5 Michal Suchanek 2010-03-25 12:15:07 UTC
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.

Comment 6 Christopher James Halse Rogers 2010-03-26 16:01:35 UTC
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?
Comment 7 Michal Suchanek 2010-03-27 06:04:41 UTC
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.
Comment 8 Marcin Slusarz 2010-05-23 12:47:48 UTC
Created attachment 35807 [details] [review]
KMS detection - part 2

Patch which drops dri dependency when detecting KMS
Comment 9 Julien Cristau 2010-07-03 04:38:02 UTC
*** Bug 28896 has been marked as a duplicate of this bug. ***
Comment 10 Michal Suchanek 2012-08-31 13:17:11 UTC
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.