Bug 473033 - display limited to 1024x768 -- Asus Eee Box
display limited to 1024x768 -- Asus Eee Box
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-i810 (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Adam Jackson
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2008-11-26 01:27 EST by Len Brown
Modified: 2018-04-11 07:31 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 528750 (view as bug list)
Last Closed: 2009-09-06 04:37:19 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
/var/log/Xorg.0.log (401.00 KB, text/plain)
2008-11-26 13:34 EST, Len Brown
no flags Details
dmidecode (10.28 KB, text/plain)
2009-02-11 14:20 EST, Len Brown
no flags Details
lspci -vn (7.23 KB, text/plain)
2009-02-11 17:51 EST, Len Brown
no flags Details

  None (edit)
Description Len Brown 2008-11-26 01:27:42 EST
Description of problem:

Linux eeebox #1 SMP Tue Nov 18 12:19:59 EST 2008 i686 i686 i386 GNU/Linux

Fedora 10 runs its GUI in 1024x768 mode on
my Asus Eee Box, even though I have a Samsung
SyncMaster 245BW screen connected via DVI
offering native 1920x1200 resolution.

This box originally came with Xandros Linux installed,
and that distribution correctly detected the
same monitor and ran it at native resolution.

Running Fedora's "Monitor Resolution Settings" application,
the highest resolution offered is 1024x768.
If Mirror Screens is de-selected, the GUI shows
that it understand that this is a Samsung 24" screen.
However, it doesn't offer any higher resolution.

manual invocation of...

xrandr --size 1920x1200

works around the problem.

Curiously, I found no xorg.conf file in /etc/X11 to edit...

This box has a...
00:02.0 VGA compatible controller: Intel Corporation Mobile 945GME Express Integrated Graphics Controller (rev 03)

and is running i915:

[lenb@eeebox ~]$ lsmod |grep i915
i915                   53380  2 
drm                   158260  3 i915
Comment 1 Matěj Cepl 2008-11-26 05:33:33 EST
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.
Comment 2 Len Brown 2008-11-26 13:34:20 EST
Created attachment 324775 [details]

I would attach the xorg.conf file, but per my comments above,
it doesn't exist.
Comment 3 Matěj Cepl 2008-11-26 19:05:44 EST
Comment 4 Adam Jackson 2009-02-10 10:10:40 EST
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?
Comment 5 Adam Jackson 2009-02-10 10:19:43 EST
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).
Comment 6 Len Brown 2009-02-11 14:18:35 EST
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)
Comment 7 Len Brown 2009-02-11 14:20:28 EST
Created attachment 331611 [details]
Comment 8 Adam Jackson 2009-02-11 16:48:07 EST
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.
Comment 9 Len Brown 2009-02-11 17:51:27 EST
Created attachment 331630 [details]
lspci -vn
Comment 10 Adam Jackson 2009-02-11 18:33:00 EST
D'oh.  It's already quirked out in git master.

Try this:

Comment 11 Len Brown 2009-02-11 21:00:51 EST
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
Comment 12 Len Brown 2009-02-11 21:10:51 EST
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.
Comment 13 Adam Jackson 2009-02-12 14:25:00 EST
(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.
Comment 14 Vedran Miletić 2009-09-06 04:37:19 EDT
Closing per comment #12.

Note You need to log in before you can comment on or make changes to this bug.