From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.9) Gecko/20070209 Fedora/1.5.0.9-3.fc6 Firefox/1.5.0.9 pango-text Description of problem: I have a Intel 945GM graphics adaptor in my Dell D820 laptop and a screen capable of 1920x1200. I use the i810 driver (when trying the "intel" one I only get a black screen) and use the 915resolution utility to patch mode 5c to 1920x1200. And everything works fine _until_ I boot the Xen kernel (2.6.19-1.2911.fc6xen). With the XEN kernel I only get the 1600x1200 resolution.... Does anyone have any clues? Attached is the Xorg.log. Version-Release number of selected component (if applicable): xorg-x11-drv-i810-1.6.5-10.fc6 How reproducible: Always Steps to Reproduce: 1. boot XEN kernel Actual Results: Expected Results: Additional info:
Created attachment 148570 [details] Xorg.log
In BIOS on my laptop, there is an option to set "LCD panel expansion" to "off". When set to this, the display will show a small but sharp image centered on the screen when driven with a low resolution. I've noticed that when running the Xen kernel, if I switch back to a VT _after_ X has started the image of the VT is then stretched to cover the entire screen giving a blurry image. Not a major problem per se, but maybe a hint of what's wrong...
Created attachment 148868 [details] X log from vanilla kernel for comparison
Discussing this with the X-people we (surprisingly) came to the conclusion this probably a (XEN) kernel problem.... So to re-iterate the issue. If I boot my Latitude D820 laptop with the vanilla 2.6.19-1.2911.fc6 kernel everything works fine but if I boot it with the XEN kernel I need to step down to 16 bit colour in order to get the full 1920x1200 resolution. I use the i810 driver and the "915resolution" utility to re-map one of the graphics modes to 1920x1200. I'm attaching the output of dmesg in case it could contain any leads...
I have found this same bug, independent of David, and can also reproduce it. The relevant packages are: kernel-xen-2.6.18-1.2869.fc6 915resolution-0.5.2-6.fc6 xorg-x11-drv-i810-1.6.5-10.fc6 --Martin
Just to make the point a bit clearer: X should not be able to tell the difference between a normal kernel and a Xen-enabled dom0 Linux kernel; X is a userspace process, and therefore all the Xen magic _should_ be hidden. Therefore any visible difference in X's behaviour between normal and dom0 kernels is highly likely to be a bug in Xen. For this particular bug, 915resolution maps part of the video BIOS and scribbles in new timings; later, X comes along and asks the video BIOS to set that mode. That the new timings don't make it to X, indicates that Xen's mmap code is busted for this case.
I'm not sure about the mmap interpretation. The 1920x1200x16 resolution wouldn't be available unless 915resolution did something. Without 915resolution the screen resolution is limited to 1600x1200 for all color depths. Using 915resolution I get 1920x1200 at all color depths. Booting the Xen kernel and using 915resolution, I get 1600x1200 at 24 bit, but lowering the depth to 16 bits gives 1920x1200.
Right; it looks more like the different memory layout under Xen is confusing something into thinking that there's less framebuffer memory available. That's the only reason I can think of why 1920x1200x24 wouldn't be available if it's available at ...x16 (the video timings are the same for both). Checks... and indeed, the Xorg.log shows >>>>>>>> (II) I810(0): Modeline "1920x1200" 161.84 1920 2020 2052 2184 1200 1202 1208 1235 -hsync -vsync (--) I810(0): A non-CRT device is attached to pipe B. No refresh rate overrides will be attempted. (--) I810(0): Maximum space available for video modes: 7872 kByte >>>>>>>> so it IS detecting 1920x1200, but is only offering 7.8MB for video memory; the non-Xen case shows >>>>>>>> (--) I810(0): Maximum space available for video modes: 12288 kByte >>>>>>>> for the memory detection. To proceed, we'd need to know how X determines the maximum available memory in this case. Once we've got that, we can certainly look into why it's different under Xen.
The i810 driver queries memory size from VBE. If it's too small, it makes another VBE call to allocate more, and then reinits VBE. Apparently under Xen this change isn't taking effect. This could be due to using the x86 emulator instead of vm86 when in Xen, but we had to do that at one point because Xen's vm86 support was so deeply broken. It would be interesting to know if the same failure shows under non-xen kernel when using the x86 emulator. You'd do this by adding the line Option "Int10Backend" "x86emu" to the ServerLayout section in xorg.conf.
Adding the x86emu line to xorg.conf results again in 1600x1200. This is with 915resolution and without Xen. >>>>>>>>>> (II) I810(0): Printing DDC gathered Modelines: (II) I810(0): Modeline "1920x1200" 161.84 1920 2020 2052 2184 1200 1202 1208 1235 -hsync -vsync (--) I810(0): A non-CRT device is attached to pipe B. No refresh rate overrides will be attempted. (--) I810(0): Maximum space available for video modes: 7872 kByte >>>>>>>>>>>
In Fedora 7, with kernel-xen-2.6.20-2925.11.fc7, and the intel (not i810 driver) from xorg-x11-drv-i810-2.0.0-4.fc7 everything works fine so I'm closing this bug(-: