Bug 473033

Thanks for the bug report.  We have reviewed the information you have provided above, and there is some additional information we require that will be helpful in our diagnosis of this issue.

Please attach your X server config file (/etc/X11/xorg.conf) and X server log file (/var/log/Xorg.*.log) to the bug report as individual uncompressed file attachments using the bugzilla file attachment link below.

Could you please also try to run without any /etc/X11/xorg.conf whatsoever and let X11 autodetect your display and video card? Attach to this bug /var/log/Xorg.0.log from this attempt as well, please.

We will review this issue again once you've had a chance to attach this information.

Thanks in advance.

Created attachment 324775 [details]
/var/log/Xorg.0.log

I would attach the xorg.conf file, but per my comments above,
it doesn't exist.

thanks

Intel hardware doesn't give us any way of detecting whether LVDS is connected, only whether the internal connector is present.  The best we can do is look in the BIOS for the LVDS mode table and hope it's right.  For laptops, it usually is.  For machines like the eeebox where you're using a GM part in a fixed case, it's usually a lie.

If the PCI subsystem ID is unique, we can quirk around this pretty easily.  If (like many Intel boards) the subsystem vendor ID is 8086, then we'll need to scrape it out of DMI instead.  Can you attach the output of lspci -n and dmidecode please?

In the future, if the Intel reference video bioses would default to some implausible panel size like 0x0, IHVs would be forced to set it correctly for machines that actually have LVDS, and the rest would at least be giving us obvious lies (that we could ignore) instead of plausible lies like 1024x768 (that we can't distinguish from a real panel).

So the confusion is that this is a mobile chipset
in a desktop box, and so you expect an integrated
LVDS but instead get an external DVI connector?

[lenb@eeebox ~]$ lspci -n
00:00.0 0600: 8086:27ac (rev 03)
00:02.0 0300: 8086:27ae (rev 03)
00:02.1 0380: 8086:27a6 (rev 03)
00:1b.0 0403: 8086:27d8 (rev 02)
00:1c.0 0604: 8086:27d0 (rev 02)
00:1c.1 0604: 8086:27d2 (rev 02)
00:1c.2 0604: 8086:27d4 (rev 02)
00:1d.0 0c03: 8086:27c8 (rev 02)
00:1d.1 0c03: 8086:27c9 (rev 02)
00:1d.2 0c03: 8086:27ca (rev 02)
00:1d.3 0c03: 8086:27cb (rev 02)
00:1d.7 0c03: 8086:27cc (rev 02)
00:1e.0 0604: 8086:2448 (rev e2)
00:1f.0 0601: 8086:27b9 (rev 02)
00:1f.2 0101: 8086:27c4 (rev 02)
00:1f.3 0c05: 8086:27da (rev 02)
03:00.0 0280: 1814:0781
04:00.0 0200: 10ec:8168 (rev 02)

[lenb@eeebox ~]$ lspci
00:00.0 Host bridge: Intel Corporation Mobile 945GME Express Memory Controller Hub (rev 03)
00:02.0 VGA compatible controller: Intel Corporation Mobile 945GME Express Integrated Graphics Controller (rev 03)
00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller (rev 03)
00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 02)
00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 02)
00:1c.1 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 2 (rev 02)
00:1c.2 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 3 (rev 02)
00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #1 (rev 02)
00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #2 (rev 02)
00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #3 (rev 02)
00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #4 (rev 02)
00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller (rev 02)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e2)
00:1f.0 ISA bridge: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge (rev 02)
00:1f.2 IDE interface: Intel Corporation 82801GBM/GHM (ICH7 Family) SATA IDE Controller (rev 02)
00:1f.3 SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller (rev 02)
03:00.0 Network controller: RaLink RT2860
04:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 02)

Created attachment 331611 [details]
dmidecode

The confusion is that we try to light up all connected outputs by default.  After all, you plugged the display in, clearly you want it lit up.  But LVDS gives us no connection sense.  So all we have to go on is "is there an LVDS connector", "does the BIOS table have something that looks like a plausible panel descriptor", and "is the ACPI lid switch closed".  That BIOS table part isn't reliable because the stock video BIOS includes a plausible panel descriptor, and BIOS engineers are lazy and don't remove it.  The lid-closed bit also only really works on laptops, because for other machines, either there's no lid switch in ACPI, or it's wired to open.

So then when we go to figure out what mode to program by default, we try to clone all the heads together (because our memory management is still trash for other reasons).  And we try to force them all to the same resolution, because otherwise gnome gets very confused, putting panels in the wrong place or whatnot.  If we had working memory management we'd probably default to right-of screen placement, but that would just change the bug to "I seem to have this large invisible region of my desktop off to one side, make it go away please".

Sorry, I should have asked for lspci -vn, I need the subsystem IDs not just primary IDs.

Created attachment 331630 [details]
lspci -vn

D'oh.  It's already quirked out in git master.

Try this:

http://kojipkgs.fedoraproject.org/packages/xorg-x11-drv-i810/2.5.0/5.fc10/i386/xorg-x11-drv-i810-2.5.0-5.fc10.i386.rpm

I was hoping that the ACPI FADT.Preferred_PM_Profile
might be a clue, but on this machine, it is set to "mobile":-(

On a system which has ACPI enabled, and has no LID switch,
isn't it a safe bet that there is no LID and thus nothing
on the LVDS?

Note that the lid is represented by PNP0C0D, which
is visible in sysfs on a machine that has one:

ls -l /sys/class/input/input1
lrwxrwxrwx 1 root root 0 2009-02-11 17:57 /sys/class/input/input1 -> ../../devices/LNXSYSTM:00/device:00/PNP0C0D:00/input/input1

the quirk works.

after installing the rpm in comment #9 and rebooting,
the Eee Box came up and talked in native 1920x1200 mode
without requiring any manual xrandr intervention.

(In reply to comment #11)

> On a system which has ACPI enabled, and has no LID switch,
> isn't it a safe bet that there is no LID and thus nothing
> on the LVDS?

Enh.  There are some people who do all-in-one systems with LVDS panels, IBM POS terminals come to mind.  Those happen to be SDVO LVDS, but I don't think that gives us connection sense either.

Closing per comment #12.