xrandr won't enable LVDS1 unless VGA1 is off

Bug #1071288 reported by Berend De Schouwer on 2012-10-25
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
xf86-video-intel
Invalid
Medium
xserver-xorg-video-intel (Ubuntu)
Low
Unassigned

Bug Description

Gnome-shell usually doesn't run on multiple monitors, even though it's configured in SystemSettings -> Displays

"usually" because once in a blue moon it does. So the hardware supports it.

xrandr lists:
LVDS1 connected (normal left inverted right x axis y axis)
   1366x768 59.9 +
VGA1 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 477mm x 268mm
   1920x1080 60.0*+

(other resolutions cut from the output)

gdm starts on both monitors. As soon as I log in, LVDS1 goes off.

I can enable the second monitor in SystemSettings->Displays, and even click on "keep configuration" but it doesn't activate.

It's disabled in software somewhere. I say that because the message tray at the bottom is in a different location when both monitors are active. So there is a software detect-monitor-size that moves the message tray, and it's almost always where it would be for single monitors.

Worked fine in Gnome-Shell 3.0.0.

ProblemType: Bug
DistroRelease: Ubuntu 12.10
Package: gnome-shell 3.6.1-0ubuntu1
ProcVersionSignature: Ubuntu 3.5.0-17.28-generic 3.5.5
Uname: Linux 3.5.0-17-generic i686
ApportVersion: 2.6.1-0ubuntu6
Architecture: i386
CheckboxSubmission: 4c35a9d722052b5a55114f98690e7808
CheckboxSystem: b633b4f40868d491c2ae5b50030ce6f3
Date: Thu Oct 25 13:47:41 2012
DisplayManager: gdm
InstallationDate: Installed on 2010-02-06 (992 days ago)
InstallationMedia: Ubuntu-Netbook-Remix 9.10 "Karmic Koala" - Release i386 (20091028.4)
MarkForUpload: True
SourcePackage: gnome-shell
UpgradeStatus: Upgraded to quantal on 2012-10-10 (15 days ago)

Tim Lunn (darkxst) wrote :

This doesnt really sound like it would be a gnome-shell bug.

Does it work in Unity or Gnome Classic?
Does it work if you manually activate with xrandr, i.e. something like
xrandr --output LVDS1 --auto --right-of VGA1

Can you attach /var/log/Xorg.0.log and the full output of `xrandr -q` to this bug.

gdm: mirrors display.
kde: works (but KDE limits the resolution options to two or three for each screen)
xrandr: works
gnome classic: doesn't work
gnome shell: doesn't work

"doesn't work" means systemsettings->display notices both monitors, and will let you set resolutions, etc. except LVDS1 never switches on. systemsettings->display appears to think it is on.

The following xrandr commands work as expected:

xrandr --output LVDS1 --mode 1366x768
xrandr --output LVDS1 --below VGA1
xrandr --output LVDS1 --pos 554x1080

xrandr --right-of results in a corrupt display. That's expected. This video card has a max width of 2048, so the main display (1920x1080) + any display to the right causes corruption.

I'm also attaching /var/log/Xorg.0.log and xrandr -q (after enabling the second display)

xrandr -q output

I just noticed LVDS1 is listed as 0mm by 0mm. Dunno if that's correct, but it certainly looks odd.

gnome classic appears to be based on gnome3 now. systemsettings looks identical to gnome-shell's.

Tim Lunn (darkxst) on 2012-10-26
affects: gnome-shell (Ubuntu) → gnome-control-center (Ubuntu)
Tim Lunn (darkxst) wrote :

given that it works correctly when configured using xrandr commands, I am re-assigning this bug against gnome-control-center.

I've found a probable cause.

xrandr won't enable LVDS1 unless VGA1 is off. So I have to plug in VGA1, and then run:

xrandr --output VGA1 --off
xrandr --output LVDS1 --mode 1366x768
xrandr --output VGA1 --auto
xrandr --output VGA1 --primary

I have to turn VGA1 off, then I can turn LVDS1 on, and then VGA1 on.

The xrandr error message is "cannot find crtc for output LVDS1"

A bit of googling shows that this happens to more people, with different video cards, on all sorts of versions, with all sorts of Linux distributions.

Possibly related, possibly off-topic: I make VGA1 the primary display, because if I don't I can't resize beyond a certain size even though VGA1 is 1920x1080. This may be because VGA1's resolution is higher, and windows are stuck on LVDS1's size.

Sebastien Bacher (seb128) wrote :

the recent comment suggest the issue is an xorg/driver one, xrandr command line is having the same issue if the VGA is not turned off

affects: gnome-control-center (Ubuntu) → xorg-server (Ubuntu)
summary: - No multiple monitors
+ xrandr won't enable LVDS1 unless VGA1 is off
Timo Aaltonen (tjaalton) on 2013-03-08
affects: xorg-server (Ubuntu) → xserver-xorg-video-intel (Ubuntu)
Chris Wilson (ickle) wrote :

The earlier bugs are gnome specific. The last bug is bad client behaviour and arguably lack of atomic modesetting support. xrandr is reporting a true limitation of the device in that the LVDS can only be bound to one pipe, so if you bind VGA first to that pipe, then LVDS cannot be lit. This is reported to the client via the available CRTCs so again doesn't appear to be a driver bug.

Created attachment 77488
Xorg.0.log

I have a PanelPC with a graphic card "Intel 945GM" inside.

Centos Release : CentOS release 6.3 (Final)
Intel driver Package : xorg-x11-drv-intel-2.20.2-2.el6.i686

When I connect an external VGA monitor, LVDS appear disconnected.

# xrandr -q
Screen 0: minimum 320 x 200, current 1024 x 768, maximum 4096 x 4096
VGA1 connected 1024x768+0+0 (normal left inverted right x axis y axis) 304mm x 228mm
   800x600 72.2 + 75.0 60.3 56.2
   1024x768 75.1* 70.7 70.1 60.0
   832x624 74.6
   640x480 72.8 75.0 66.7 60.0
LVDS1 disconnected (normal left inverted right x axis y axis)

And it reconnects when I disconnect the VGA monitor.

# xrandr -q
Screen 0: minimum 320 x 200, current 1280 x 800, maximum 4096 x 4096
VGA1 disconnected (normal left inverted right x axis y axis)
LVDS1 connected 1280x800+0+0 (normal left inverted right x axis y axis) 0mm x 0mm
   1280x800 59.8*+ 59.9
   1280x1024 59.7 +
   1280x960 60.0
   1280x768 59.9 60.0
   1024x768 60.0
   800x600 60.3 56.2
   848x480 60.0
   640x480 59.9

2.6.32-279.el6.i686 - the behaviour you have here is not an artifact of our driver as the LVDS is always reported as connected unless you manually override that behaviour by telling it to use the lid status. Please try reproducing with an upstream kernel.

I don't think it is a kernel thing.

In any case, I've updated my kernel over CentOs to the last version : vmlinuz-2.6.32-358.2.1.el6.i686 ant the same results. ( log is attached )

I've also tested other enviroments with newer kernels and happen the same:

Fedora Core 17 i686 : xorg-x11-drv-intel 2.19.0-1 / kernel 3.3.4-5
Fedora Core 18 i686 : xorg-x11-drv-intel 2.20.19-2 / kernel 3.6.10-4

It happesns the same : LVDS1 repostes as disconnect on plug an VGA monitos

Also the vesa driver shows on LVDS1 and VGA1 a perfectly cloned desktop. Without disconnect LVDS1 display. Unlikely for oue propouses vesa driver is a very basic one, no extended desktop included.

I wanna focus on the hardware : is a Panel PC, not a laptop!! and acpi even don't create /proc/acpi/button/lid directory! this is why I think there is some problem into the understanding between ACAPI and Inter Driver. Intel drives could not report the right lid status and LVDS1 is disconnected by the drives when other option like VGA is available.

If you're not willing to test upstream kernels (this means 3.8 or even newer), then please file this bug against your distro.

2.6.32 is _NOT_ supported by us since a long time.

Created attachment 77673
Xorg.0.log-3.8.0-17

Same experience with upstream kernel 3.8.0-17 and intel-driver, see Xorg.0.log-3.8.0-17 attached.

Executing xrandr without motinitor attached at VGA

> Screen 0: minimum 320 x 200, current 1280 x 1024, maximum 32767 x 32767
> LVDS1 connected 1280x1024+0+0 (normal left inverted right x axis y axis)
> 0mm x 0mm
> 1280x1024 59.7*+
> 1280x960 60.0
> 1152x864 60.0
> 1024x768 60.0
> 800x600 60.3 56.2
> 640x480 59.9
> VGA1 disconnected (normal left inverted right x axis y axis)

Executing xrandr with VGA monitor attached

> Screen 0: minimum 320 x 200, current 1024 x 768, maximum 32767 x 32767
> LVDS1 disconnected (normal left inverted right x axis y axis)
> VGA1 connected 1024x768+0+0 (normal left inverted right x axis y axis)
> 304mm x 228mm
> 1024x768 75.1* 70.7 70.1 60.0 832x624 74.6
> 800x600 72.2 75.0 60.3 56.2
> 640x480 72.8 75.0 66.7 60.0
> 720x400 70.1

Expected results: LVDS1 connected.

Can you pls boot that 3.8 kernel with drm.debug=0xe added to your kernel cmdline and the attach the complete dmesg after having connected VGA and done an xrandr call?

Created attachment 77815
dmesg w/debug - kernel 3.9.0-0.rc4.git0.1.fc19.i686 - xf86-video-intel-2.21.3

Created attachment 77816
Xorg.0.log - kernel 3.9.0-0.rc4.git0.1.fc19.i686 - xf86-video-intel-2.21.3

Sorry about the delay.

The version I've testes Ubuntu life 13.04 allways hungs on installation... finally I've get an FC19 alpha really-slowly release with kernel 3.9.0-0, I've compiled the xf86-video-intel-2.21.3 driver and copy to /usr/lib/xorg/modules/drivers/.

The same results when connect VGA monitor, open terminal & xrandr

> # xrandr
> Screen 0: minimum 320 x 200, current 1280 x 1024, maximum 4096 x 4096
> LVDS1 disconnected primary 1280x1024+0+0 (normal left inverted right x axis y > axis) 0mm x 0mm
> VGA1 connected (normal left inverted right x axis y axis)
> 1366x768 59.8 +
> 1280x1024 75.0 60.0
> 1280x960 60.0
> 1280x800 59.8
> 1152x864 75.0
> 1280x720 60.0
> 1024x768 75.1 70.1 60.0
> 832x624 74.6
> 800x600 72.2 75.0 60.3 56.2
> 640x480 72.8 75.0 66.7 60.0
> 720x400 70.1
> 1280x1024 (0x44) 108.0MHz
> h: width 1280 start 1328 end 1440 total 1688 skew 0 clock 64.0KHz
> v: height 1024 start 1025 end 1028 total 1072 clock 59.7Hz

dmesg with debug is attached.

Hope it could help

Oh, an sdvo lvds output. That explains a lot (dmesg with debug output was key, Xorg.log is pretty irrelevant here). I'm looking into a fix.

Changed in xserver-xorg-video-intel:
importance: Unknown → Medium
status: Unknown → Confirmed

(In reply to comment #10)
> Oh, an sdvo lvds output. That explains a lot (dmesg with debug output was
> key, Xorg.log is pretty irrelevant here). I'm looking into a fix.

Daniel, ping for the fix. ;D

Oh, I've looked a bit harder and noticed that thing are pretty neatly screwed up in sdvo land. So not something I can fix in 1-2 easy patches. And since sdvo isn't a high prio thing for us I've postponed this for now.

If you can code and want to fix this yourself I could point you into the right direction. Just ping me on irc on #intel-gfx (I'm danvet there).

Meh, haven't gotten around to tackle this yet, so let's keep this bug around for a bit more ...

Berend De Schouwer, this bug was reported a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue? If so, could you please test for this with the latest development release of Ubuntu? ISO images are available from http://cdimage.ubuntu.com/daily-live/current/ .

If it remains an issue, could you please run the following command in the development release from a Terminal (Applications->Accessories->Terminal), as it will automatically gather and attach updated debug information to this report:

apport-collect -p xserver-xorg-video-intel REPLACE-WITH-BUG-NUMBER

Please note, given that the information from the prior release is already available, doing this on a release prior to the development one would not be helpful.

Thank you for your understanding.

Helpful bug reporting tips:
https://wiki.ubuntu.com/ReportingBugs

Changed in xserver-xorg-video-intel (Ubuntu):
importance: Undecided → Low
status: New → Incomplete

Created attachment 95147
drm/i915/sdvo: Fix LVDS connector status detection

(In reply to comment #14)
> Created attachment 95147 [details] [review]
> drm/i915/sdvo: Fix LVDS connector status detection

Aitor, please try Chris' patch on top of a recent kernel and report back.

Changed in xserver-xorg-video-intel:
status: Confirmed → Incomplete

Timing out. Aitor, if you get around to testing Chris's patch, please re-open.

Changed in xserver-xorg-video-intel:
status: Incomplete → Invalid
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.