Red Hat Bugzilla – Bug 178451
i810 driver does not correctly display 1920x1200 mode on DVI
Last modified: 2007-11-30 17:11:21 EST
Description of problem:
Using X on the Intel 945G integrated chipset seems to fall back on the vesa
driver, which does not correctly handle the DVI output. Manually setting the
driver to i810 results in X incorrectly displaying 1920x1200 mode on the DVI --
the display is cut off at 1600x1200.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Use X on 945G system with 1920x1200 DVI display
1600x1200 pixels of cut off sadness.
1920x1200 pixels of desktop goodness.
I like monkeys.
Created attachment 123498 [details]
X server startup log
Created attachment 123499 [details]
I believe you just need to add a 1920x1200 modeline to the config file manually
and configure the screen section to use the new mode. The X server currently
does not contain very many built in widescreen modes it seems. Longterm it
seems the general concensus is to scrap the statically coded lists that are
manually updated and built into the server, and replace them with dynamically
generated modeline lists using GTF/CVT at runtime, accentuated with a handful
of additional hard coded modes. I'm not sure when that is planned though,
but it'll be a godsend when it eventually happens. ;o)
I think I saw another bug in either our bugzilla or Xorg bugzilla for this
or a similar issue, as ISTR seeing someone post a modeline that worked for
this hardware. The details are a bit sketchy now tho. You can also try
the 'gtf' utility that comes with X to whipup a workaround for now that
should probably work. Let me know how you make out either way, and
we'll see what we can do to get it fixed for FC5.
Created attachment 123501 [details]
current x config file
Hey Mike! Well, the mode line does include 1920x1200... There was some
speculation by Jesse that the i810 driver is using the VBE modes which might be
missing a 1920x1200 entry, as they're usually provided by the BIOS. Cheers!
Poking around in the source, I found the following likely candidate for the
clipping. I have no idea how to get an X build environment properly setup,
though. 1920 is probably on the low side for the size, as Dell is shipping a
2560x1600 these days....
diff -ur xf86-video-i810-184.108.40.206/src/i810_driver.c
--- xf86-video-i810-220.127.116.11/src/i810_driver.c 2005-08-05 19:04:33.000000000 -0400
+++ xf86-video-i810-18.104.22.168.new/src/i810_driver.c 2006-01-20
@@ -1024,7 +1024,7 @@
i = xf86ValidateModes(pScrn, pScrn->monitor->Modes,
- 0, 320, 1600, 64 * pScrn->bitsPerPixel,
+ 0, 320, 1920, 64 * pScrn->bitsPerPixel,
i810_pitches, 0, 0, 64 * pScrn->bitsPerPixel,
I'd assume that 1920 is ok there, but I wouldn't assume that Intel hardware
can output 2560x1600 per se. ;o)
I'll confer with Alan Hourihane, and report back to see if there are other
potential issues that need to be resolved also.
The file you've modified is only for the very old i810 chip.
As for the actual problem - it's as Jesse says - your video bios doesn't support
1920x1200 so it's limiting you to 1920x1200.
whoops, that should say "limiting you to 1600x1200"
Poking around internally, it seems that there is a tool to help with this
problem: see http://www.geocities.com/stomljen/ for 915resolution which enabled
modifying the BIOS mode table. Hopefully the i810 code gets reworked at some
point so this kind of hack becomes unnecessary. =-)
I've chatted a bit more with Alan in IRC, and he also suggested the
i810/i915resolution utilities as interim workarounds for this problem.
Keep in mind though, that the real problem is that all modesetting is
done via the BIOS, as the hardware is not documented to permit direct
programming of the hardware as is done in most other drivers. So long
as the hardware remains undocumented, the Intel drivers will be forced
to use VBE for modesetting, and unfortunately end up held hostage to
the video modes built into the BIOS. What makes this even worse, is that
many BIOSes do not have proper mode tables, in particular on various
laptops where the native mode of the built in LCD panel is not present in
This is a serious problem for useability, however it seems all we can really
do, is hope that Intel (or whoever) releases the necessary specifications to
do direct mode programming at some point in the future, and that it gets
Let me know if the i915 utility works for you.
One more thing I forgot to mention, is that even using the external utilities
to enable modes, the result is unpredictable, and may or may not work. That
was another thing Alan mentioned. HTH
Since this issue is really a BIOS bug/limitation, and the only real solutions
to the problem are:
1) Using the 3rd party utility to sledgehammer the BIOS mode tables (unsupported)
2) Using a driver patched to do the same (unsupported and not avail)
3) Getting Intel to release the specs needed to alanh or others to implement
direct mode programming.
We're kindof in a bind I'm afraid. I'm going to close this CANTFIX for now,
until #2 or 3 above avails. Sorry... ;o/
That's okay, I suspect by the next major release something will happen as the
developers here at Intel have it as a high priority item. The only thing that
I'd like to see in FC5 is that the installer needs to know about the PCI ids so
that the i810 driver gets loaded instead of the framebuffer (which doesn't
output anything on the DVI output).
> That's okay, I suspect by the next major release something will happen as the
> developers here at Intel have it as a high priority item.
That would be totally awesome. It's the single biggest nasty annoyance on
the Intel video side of things. It totally upsets huge numbers of users
in a big bad way. Personally I'd be furious to buy hardware and have that
problem, so I totally feel for everyone who has gotten bitten. ;/
If Intel plans on resolving it, even if just for new hardware coming out,
that would really be a wonderful thing.
> The only thing that I'd like to see in FC5 is that the installer needs to
> know about the PCI ids so that the i810 driver gets loaded instead of the
> framebuffer (which doesn't output anything on the DVI output).
Yeah, there was a bit of miscommunication in December that led to FC5 test1
and test2 not having proper video detection, however it /should/ be resolved
in rawhide now. I updated the Intel metadata last night with a new PCI ID,
and just checked to see if yours was present:
(II) PCI: 00:02:0: chip 8086,2772 card 1043,817a rev 02 class 03,00,00 hdr 80(In
reply to comment #13)
... and it wasn't. ;o) I'm updating the i810 package again right now to
add your PCI ID to it. If you have a list of all Intel video PCI IDs that
should be present though, I can add more. Unfortunately the source code
doesn't list them all in one place. They're scattered over various places
in a way that requires spending lots of time to update all of our metadata
files. Very sad state of things in the Xorg code. However, it's an upstream
goal to clean that up and get it in consistent sane shape for 7.1 or 7.2,
so by that time, we should be able to automate everything and have it
kept updated during build time instead of a tedious human process. ;o)
I just added:
alias pcivideo:v00008086d00002772sv*sd*bc*sc*i* i810
to the i810.xinf videoaliases file, so your card should be detected with
the xorg-x11-drv-i810-22.214.171.124-3 package now.
Thanks for bringing that to my attention. Lemme know if it works.
There is a good workaround for forcing missing modes from the BIOS using the
i810 driver available to download from FreeDesktop bug 643.
It would be nice if RedHat could patch their i810 driver for FC5 to allow users
to do this.