After testing latest F11-Beta with xorg-x11-drv-intel version 2.6.99.902 I'm seeing what appears to be a problem with using resolutions over 1024x768. When booting, kms is detecting the screen resolution as 1280x768 (HDTV via DVI). The display is activated but I see a solid blue or light grey color. Initially I thought this was a problem with the modelines detected by the EDID but after testing on another monitor ( Dell 20" monitor at 1680x1050). Disabling LVDS and VGA as per bug #19529m does not make any difference.
Created attachment 24463 [details] Output from dmesg Here's the output from dmesg. You can see some error reports at the end.
Created attachment 24464 [details] Xorg log
Some additional notes. With the xrandr command I've been attempting to change resolution and noticed that 1) 640x480 presents a blank black screen 2) 800x600 works as expected (from 640x480 up to doesn't display, 1024x768 down to does) 3) 1024x768 works as expected 4) 1280x768 presents a blank blue screen 5) 1360x768 presents a blank blue screen
Yakui, is this related to bug#20801?
Not sure it's related to that bug Gordon. xrandr lists all the modes correctly. Also the issue is present if I boot with nomodeset param
Which mode is used in your test? KMS mode /UMS mode? Will you please try to boot the system with UMS mode and see whether the issue still exists? (By adding the boot option of "i915.modeset=0") thanks.
(In reply to comment #5) > Also the issue is present if I boot with nomodeset param So this is not KMS issue. Does this ever worked before? If so, which version?
Created attachment 24494 [details] Xorg log with KMS disabled and modedebug set
Ok, tested again with both nomodeset and i915.modeset=0. Both resulted in the same. Text based plymouth was visible during boot up (hadn't been before, so possible I simply mistyped nomodeset at grub prompt). xrandr shows a limited set of resolutions available with modesetting disabled versus what's visible with it enabled. Modesetting Enabled [root@localhost ~]# DISPLAY=:0 xrandr Screen 0: minimum 320 x 200, current 1280 x 768, maximum 2048 x 2048 DVI1 connected 1280x768+0+0 (normal left inverted right x axis y axis) 708mm x 398mm 1280x768 60.0*+ 1360x768 60.0 1024x768 75.1 70.1 60.0 800x600 72.2 75.0 60.3 640x480 72.8 75.0 60.0 720x400 70.1 0x0 0.0 Modesetting Disabled [root@localhost ~]# DISPLAY=:0 xrandr Screen 0: minimum 320 x 200, current 720 x 400, maximum 1024 x 1024 TMDS connected 720x400+0+0 (normal left inverted right x axis y axis) 708mm x 398mm 1024x768 85.0 75.0 70.1 60.0 800x600 85.1 72.2 75.0 60.3 640x480 85.0 75.0 72.8 59.9 720x400 70.1*
Created attachment 24495 [details] Photo of display after booting with nomodeset & X @720x400
there's been no updates on this and I noticed that this isn't listed on the 2.7 release blockers. I'll check out the latest driver next week but was wondering if there's explicitly anything further I can do to help ?
Retested with latest updates for Fedora 11, 2.6.99.902-2.fc11 and 2.6.29.1-68.fc11.i586. No difference yet.
Created attachment 25330 [details] Boot with drm.debug=1 Updated my Fedora 11/Rawhide install to the latest from Rawhide, kernel 2.6.29-1.111. Booted with the drm.debug=1 and had rsyslog put kern.* in /var/log/kern. SSH'd on and used grep "drm\|i915\|i2c" > drm_debug.log to create the attachment.
ought to be a21d4794b6812ce05d08f06dc47b26c4fb1c1fef which confuse dvo-lvds panel timing with int-lvds panel timing
(In reply to comment #14) > ought to be a21d4794b6812ce05d08f06dc47b26c4fb1c1fef which confuse dvo-lvds > panel timing with int-lvds panel timing This patch was now identified as causing this regression, and please reverted it and try. thanks Ma Ling
What do I need to do ? I've been using Fedora 11 rpms up to this point.
Created attachment 26850 [details] please try the debug UMS patch on your machine, thanks. In order to reduce compile and debug time, I produce the debug patch in UMS code. please try it on your machine, then upload log file with modedebug optoin on. Thanks for your help Ma Ling
Created attachment 26851 [details] Xorg log file with patch applied and nomodeset kernel param
Created attachment 26852 [details] Xorg log file with patch applied and kernel mode setting enabled Attached 2 copies of the Xorg log file as requested. One from kernel with KMS disabled, the other with KMS enabled.
(In reply to comment #19) > Created an attachment (id=26852) [details] > Xorg log file with patch applied and kernel mode setting enabled > Attached 2 copies of the Xorg log file as requested. One from kernel with KMS > disabled, the other with KMS enabled. The issue still exist with nomodeset kernel param now?
Yes, this has always been the case.
(In reply to comment #21) > Yes, this has always been the case. > ling's patch in comment# 17 should resolve the problem in comment# 9, i.e. less modes when modesetting is disabled.. could you please confirm that? besides that, would you please give us a log in good case, for example when you use Fedora 10? with Modedebug turns on in xorg.conf, please. please also give us some description of your HW environment. Is it a laptop? what's the model of the machine? thanks.
Ling's patch does resolve the issue from Comment #9 The system in question is a thin client pc from Lex Systems, based on the MI853A-1R10 motherboard. Based on the PCI id's used for the VGA controller (8086:3582), I'm guessing this is a derivative of an iBase board based on other ID's I've seen. Light-MI853A-1R10 Lexcom light system, w/MI853A-1R10 M/B Fanless system, Intel Celeron M 1Ghz CPU We've several hundred of these units in use across some very prestigious hospitals in London as Set Top Boxes, connecting to 26"/32" Philips hospitality TV's via the DVI port on the rear panel. Our current platform is a minimal install of Fedora Core 5 with some custom software written as the UI and VLC as the media player (controlled via the UI). I'm currently working on a platform upgrade for all our units (several thousand bedside terminals as well as these STB's) to a minimal Fedora 11 install but this bug is holding me back. I need to run the UI on the TV at 1360x768 to accommodate some feature changes requested by the hospital group. Currently the UI is minimal and running at 640x480. I've never been able to successfully get the linux drivers on Fedora 10 or 11 to correctly drive the TV at 1360x768. I've also connected the unit to a Dell 20" display that runs at 1680x1050, with the same problems. Under windows xp, both those setups on the same unit work as expected, so I know that the hardware is capable of driving the displays. Here's the output from xrander with the Dell monitor attached [root@localhost ~]# DISPLAY=:0 xrandr Screen 0: minimum 320 x 200, current 1680 x 1050, maximum 1680 x 1680 TMDS connected 1680x1050+0+0 (normal left inverted right x axis y axis) 434mm x 270mm 1680x1050 59.9*+ 1280x1024 75.0 60.0 1152x864 75.0 1024x768 75.0 60.0 800x600 75.0 60.3 640x480 75.0 59.9 720x400 70.1 I'll create an attachment that shows the Xorg log. To recap, same problem again, the screen only shows a solid colour when running over 1024x768 *NOTE, just did a xrandr set of tests when connected to the Dell screen and noticed the following 1680x1050 == Solid colour 1280x1024 == Displays properly, X desktop off center (due to initial res most likely) 1152x864 == as above 1024x768 == as above 800x600 == solid black 640x480 == solid black 720x400 == Displays proplery, X desktop off center (due to initial res most likely)
Created attachment 26917 [details] Xorg log file with patch applied and nomodeset kernel param connected to a Dell 19" monitor over DVI
would Option "NoAccel" "True" help?
The issue is in the DRM driver as well as the X driver, so I doubt it.... Just verified with a nomodeset boot and NoAccel set to true in the configs.
Has the monitor vag output, and could you please try that so that we can narrow down issue to SDVO output ? Thanks for your help Ma Ling
(In reply to comment #27) > Has the monitor vag output, and could you please try that so that we can narrow > down issue to SDVO output ? > Thanks for your help > Ma Ling ping ~
On vacation, will be able to test tomorrow
(In reply to comment #29) > On vacation, will be able to test tomorrow ping ~
With KMS enabled, no Xorg config, VGA enabled in the BIOS, Dell 1680x1050 connected running on an upto date Fedora 11 install 1) The framebuffer during kernel bootup is a mess. The plymouth ascii progress bar is displayed but illegible. The timing seem to be off as it's off centre and diagonal and flickering [root@localhost ~]# dmesg | grep drm [drm] Initialized drm 1.1.0 20060810 fbcon: inteldrmfb (fb0) is primary device [drm] DAC-6: set mode 1680x1050 17 [drm] LVDS-8: set mode 1280x768 15 fb0: inteldrmfb frame buffer device [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0 [drm] DAC-6: set mode 800x600 19 [drm] LVDS-8: set mode 800x600 1a Again, LVDS is being detected when nothing is connected. 2) X/Gnome starts up with 2 devices detected, defaults to Mirroring and uses 800x600 3) With xorg.conf set to ignore DVI and LVDS, X/Gnome starts up but again the timings are off on the console so X seems to inherit this setting 4) With KMS Disabled and Xorg.conf set to ignore DVI and LVDS (as in point 3) then the Plymouth boot progress (ascii) is perfect. X then starts up perfectly
Created attachment 27406 [details] VGA connection, KMS enabled, no xorg config to limit display options This is the xorg log showing the autodetection of the LVDS device which isn't connected. The common resolutions between LVDS and VGA (640x480 & 800x600) are then used with the displays mirroring each other.
Created attachment 27407 [details] KMS Enabled but Xorg config to limit display options to just VGA Shows the Xorg config with X setup based on the KMS detections.
Created attachment 27408 [details] Successful 1680x1050 with KMS Disabled and Xorg config to limit display options Successfully display at 1680x1050 on VGA with KMS Disabled and Xorg config set to ignore LVDS and DVI
(In reply to comment #34) > Created an attachment (id=27408) [details] > Successful 1680x1050 with KMS Disabled and Xorg config to limit display options > Successfully display at 1680x1050 on VGA with KMS Disabled and Xorg config set > to ignore LVDS and DVI ok, the issue is from TMDS output. Could you please re-try dvi monitor Dell 1680x1050 in the same UMS mode, then upload your logfile with modedebug option.
(In reply to comment #35) > (In reply to comment #34) > > Created an attachment (id=27408) [details] [details] > > Successful 1680x1050 with KMS Disabled and Xorg config to limit display options > > Successfully display at 1680x1050 on VGA with KMS Disabled and Xorg config set > > to ignore LVDS and DVI > ok, the issue is from TMDS output. Could you please re-try dvi monitor Dell > 1680x1050 in the same UMS mode, then upload your logfile with modedebug option. BTW, meanwhile please ignore lvds too :)
Created attachment 27512 [details] UMS DVI Connection to dell 1680x1050 with mode debug enabled
Created attachment 27830 [details] pleaset try the patch on your machine in KMS mode, thanks. this patch only enable pixel doubling for dvi, please try it. Thanks Ma Ling
(In reply to comment #38) > Created an attachment (id=27830) [details] > pleaset try the patch on your machine in KMS mode, thanks. > this patch only enable pixel doubling for dvi, please try it. > Thanks > Ma Ling (In reply to comment #38) > Created an attachment (id=27830) [details] > pleaset try the patch on your machine in KMS mode, thanks. > this patch only enable pixel doubling for dvi, please try it. > Thanks > Ma Ling ping ~ It look like clock issue, so could you please try the patch?
Is that against the kernel drm code or the Xorg driver ?
(In reply to comment #40) > Is that against the kernel drm code or the Xorg driver ? The patch is against xorg-video-intel in UMS mode
Tried in UMS and KMS mode, no difference.
Created attachment 27901 [details] Log with Forced double width patch applied
Glen, would you be able to test more recent fedora to help us narrow down the problem? such as fedora 6/7/8/9/10 to see if any of them can get you the correct display on DVI? please continue to ignore LVDS in your xorg.conf... hopefully you can find LiveCD which could make the testing easier. thanks.
Michael, I assume you mean an older Fedora release. I'll try updating to Rawhide to get the latest 2.6.30 series kernel and the 2.8.0 drivers. As for testing older releases, I'm not really in a position to do that time wise. I can say the following.... In Fedora Core 5, I have used the 915resolution tool to display at 1360x768 and also got a black screen Fedora Core 10 didn't work at all. Windows XP works perfectly
(In reply to comment #45) > Michael, I assume you mean an older Fedora release. > > I'll try updating to Rawhide to get the latest 2.6.30 series kernel and the > 2.8.0 drivers. As for testing older releases, I'm not really in a position to > do that time wise. > > I can say the following.... > In Fedora Core 5, I have used the 915resolution tool to display at 1360x768 and > also got a black screen > Fedora Core 10 didn't work at all. > Windows XP works perfectly > ok. And, I thought FC5 worked for you, did it? Running FC5, would you please attach 1) a xorg.log with Option "Modedebug" "True" in xorg.conf 2) intel_reg_dump output
Would intel_reg_dump even run on a Fedora Core 5 system ?
(In reply to comment #47) > Would intel_reg_dump even run on a Fedora Core 5 system ? how about vesa driver, does not work either ?
(In reply to comment #47) > Would intel_reg_dump even run on a Fedora Core 5 system ? Yes. Please also attach the vbios dump. thanks.
(In reply to comment #49) > (In reply to comment #47) > > Would intel_reg_dump even run on a Fedora Core 5 system ? > Yes. > Please also attach the vbios dump. > thanks. > Will you please attach the vbios.dump? Please use the following command to get the vbios.dump echo 1 > /sys/devices/pci0000:00/0000:00:02.0/rom cat /sys/devices/pci0000:00/0000:00:02.0/rom >vbios.dump echo 0 > /sys/devices/pci0000:00/0000:00:02.0/rom Thanks.
Further testing today as part of the Fedora test day for intel drivers. Using their rawhide test iso I booted my hardware while connected only with DVI to the TV. Kernel 2.6.31-0.219.rc9.git2.fc12.i686 xorg-x11-drv-intel-2.8.0-13.20090909.fc12 Again, VGA was detected when nothing was plugged into that port and nothing displayed on the DVI connection during boot. Once X came up, Both the VGA and DVI where detected (no LVDS, which is an improvement) and where set to share at 800x600. If I use xrandr to turn off VGA and set DVI to the native resolution of the TV, 1360x768, I get a grey screen. Via ssh, "DISPLAY=:0 xwininfo -root" is showing that the resolution has set to 1360x768, but I've got a solid grey screen I'll create some attachements next with the output of the intel_gpu_dump and the vbios as previously requested.
Created attachment 29420 [details] VBIOS dump from /sys/devices/..../rom
Created attachment 29421 [details] GPU Dump GPU dump from the 852GM when set to 1360x768 with solid grey screen displayed
Created attachment 29422 [details] Xorg log after from Fedora Rawhide testday Here's the default Xorg.0.log after setting the display to 1360x768 and getting the solid grey color.
(clearing NEEDINFO)
Hope this doesn't still happen...
"Allocate new frame buffer 1360x768 stride 2048" Bizarre, given a 32bpp fb. Certainly won't say that today ;-) Anyway, hopefully this works...
Thanks Chris, I'm actually due to resurrect a Fedora 14 build on that hardware next week. Any particular set of releases I should look at ?
Please do! I'm confident that it all works... But nothing beats actually testing.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.