Ubuntu
xserver-xorg-video-vesa package

VESA driver should fail to load when KMS is active

Bug #531736 reported by Chris Halse Rogers
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
X.Org X server
Fix Released
Medium
xserver-xorg-video-vesa (Ubuntu)
Fix Released
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.

See original description
Revision history for this message
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.

Bug Watch Updater (bug-watch-updater)
Changed in xorg-server:
status: Unknown → Confirmed
Revision history for this message
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
Revision history for this message
In , Michal Suchanek (hramrach) wrote :

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.

Revision history for this message
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
Revision history for this message
In , Chris Halse Rogers (raof) wrote :

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.

Revision history for this message
In , Michel Dänzer (michel-daenzer) wrote :

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

Chris Halse Rogers (raof)
Changed in xserver-xorg-video-vesa (Ubuntu):
status: Triaged → Fix Committed
Revision history for this message
In , Chris Halse Rogers (raof) wrote :

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?

Revision history for this message
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
Revision history for this message
In , Michal Suchanek (hramrach) wrote :

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.

Revision history for this message
In , Chris Halse Rogers (raof) wrote :

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?

Revision history for this message
In , Michal Suchanek (hramrach) wrote :

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.

Revision history for this message
In , Marcin Slusarz (marcin-slusarz) wrote :

Created an attachment (id=35807)
KMS detection - part 2

Patch which drops dri dependency when detecting KMS

Revision history for this message
In , Julien Cristau (jcristau) wrote :

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

Bug Watch Updater (bug-watch-updater)
Changed in xorg-server:
importance: Unknown → Medium
Bug Watch Updater (bug-watch-updater)
Changed in xorg-server:
importance: Medium → Unknown
Bug Watch Updater (bug-watch-updater)
Changed in xorg-server:
importance: Unknown → Medium
Revision history for this message
In , Michal Suchanek (hramrach) wrote :

Was this fixed already?

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

Revision history for this message
In , Marcin Slusarz (marcin-slusarz) wrote :

Yes, it was fixed.

http://cgit.freedesktop.org/xorg/driver/xf86-video-vesa/commit/?id=b1f7f190f9d4f2ab63d3e9ade3e7e04bb4b1f89f

Bug Watch Updater (bug-watch-updater)
Changed in xorg-server:
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

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