VESA driver should fail to load when KMS is active

Bug #531736 reported by Chris Halse Rogers on 2010-03-04
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
X.Org X server
Fix Released
Medium
xserver-xorg-video-vesa (Ubuntu)
High
Chris Halse Rogers

Bug Description

Binary package hint: xserver-xorg-video-vesa

The vesa driver doesn't interact well with KMS; on my laptop, when nouveau-kms is active, vesa causes "blooming" on the internal LVDS display when it tries to reprogram it.

It should be fairly simple for vesa to detect kms and fail to load in that case, in which case the fbdev driver should take over.

Chris Halse Rogers (raof) wrote :

Binary package hint: xserver-xorg-video-vesa

The vesa driver doesn't interact well with KMS; on my laptop, when nouveau-kms is active, vesa causes "blooming" on the internal LVDS display when it tries to reprogram it.

It should be fairly simple for vesa to detect kms and fail to load in that case, in which case the fbdev driver should take over.

Changed in xorg-server:
status: Unknown → Confirmed
Bryce Harrington (bryce) wrote :

Hi raof,

Please attach the output of `lspci -vvnn` and `dmesg`, and attach your /var/log/Xorg.0.log (and maybe Xorg.0.log.old) file from after reproducing this issue. If you're using a custom /etc/X11/xorg.conf please attach that as well.

[This is an automated message. Apologies if it has reached you inappropriately; please just reply to this message indicating so.]

tags: added: needs-xorglog
tags: added: needs-lspci-vvnn
Changed in xserver-xorg-video-vesa (Ubuntu):
status: New → Incomplete

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.

Chris Halse Rogers (raof) wrote :

This should be quite easy to do, and is quite alarming for users who hit it.

Changed in xserver-xorg-video-vesa (Ubuntu):
status: Incomplete → Triaged
assignee: nobody → Chris Halse Rogers (raof)
importance: Undecided → High

Created an attachment (id=34393)
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. :)

Changed in xserver-xorg-video-vesa (Ubuntu):
status: Triaged → Fix Committed

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?

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package xserver-xorg-video-vesa - 1:2.3.0-1ubuntu1

---------------
xserver-xorg-video-vesa (1:2.3.0-1ubuntu1) lucid; urgency=low

  [ Julien Cristau ]
  * Remove myself from Uploaders

  [ Christopher James Halse Rogers ]
  * debian/patches/100_bail_when_kms_active.patch:
    + Fail to load when kernel modesetting is active (LP: #531736)
 -- Christopher James Halse Rogers <email address hidden> Wed, 24 Mar 2010 20:09:47 +1100

Changed in xserver-xorg-video-vesa (Ubuntu):
status: Fix Committed → Fix Released

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 an attachment (id=34500)
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 an attachment (id=35807)
KMS detection - part 2

Patch which drops dri dependency when detecting KMS

*** Bug 28896 has been marked as a duplicate of this bug. ***

Changed in xorg-server:
importance: Unknown → Medium
Changed in xorg-server:
importance: Medium → Unknown
Changed in xorg-server:
importance: Unknown → Medium

Was this fixed already?

There is a multitude of patches but bug is still marked as new.

Changed in xorg-server:
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.