Created attachment 45192 [details] Xorg.0.log I have a primary CRT monitor connected to the DVI-0 port of a Radeon HD 3870 graphics card. To this card's DVI-1 port I have connected a flat screen TV using a HDMI adapter. According to its manual, this TV is capable of running 1080i and 720p but xrandr doesn't show these resolutions: Screen 0: minimum 320 x 200, current 2624 x 1200, maximum 8192 x 8192 DVI-0 connected 1600x1200+0+0 (normal left inverted right x axis y axis) 400mm x 300mm 1600x1200 85.0*+ 1920x1440 75.0 1856x1392 75.0 1792x1344 75.0 1280x1024 85.0 75.0 1152x864 75.0 1024x768 85.0 75.1 70.1 60.0 832x624 74.6 800x600 72.2 75.0 60.3 56.2 640x480 72.8 75.0 66.7 60.0 720x400 87.8 70.1 DIN disconnected (normal left inverted right x axis y axis) DVI-1 connected 1024x768+1600+432 (normal left inverted right x axis y axis) 640mm x 360mm 1024x768 60.0* 800x600 60.3 640x480 60.0 When I run the xrandr command, a list of modes (from EDID) is printed to Xorg.0.log. When, for example, the 1080i mode that is printed to the xorg log is added manually with xrandr, it works fine. But these modes aren't listed by default by xrandr. I'm using xserver-xorg-video-radeon compiled from git version 20110307. I am attaching Xorg.0.log and the output of dmesg with the kernel option "drm.debug=0xe" added.
Created attachment 45193 [details] Outpuf of 'dmesg' with kernel option "drm.debug=0xe" added It should be noted that the flat screen TV is made by Philips (as shown in Xorg.0.log: "Monitor name: Philips FTV") and that the EDID vendor ID is "PHL". The strange thing is that drm doesn't seem to detect the EDID modes, all it prints to dmesg are the modes that xrandr also claims to only have: "1024x768", "800x600" and "640x480". But X gets the correct modes fine - they are added to the Xorg log file each time I run xrandr.
> When I run the xrandr command, a list of modes (from EDID) is printed to > Xorg.0.log. When, for example, the 1080i mode that is printed to the xorg log > is added manually with xrandr, it works fine. But these modes aren't listed by > default by xrandr. I also have this problem with my TV - it's only KMS that doesn't add all the modes, with UMS they are shown OK.
Make sure your kernel has this commit otherwise interlaced modes won't get added: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=c49948f4bd39e27dd06a1cdb0c3743ca2a734f5e Also check sysfs to see if the kernel is sees the modes or if X is rejecting them: cat /sys/class/drm/<connector>/modes
I just installed a 2.6.38-kernel and now the 1080i mode at 25 Hz is auto detected: rune@runescomp:~$ xrandr [...cut ...] DVI-1 connected (normal left inverted right x axis y axis) 1920x1080i 25.0 + 1024x768 60.0 800x600 60.3 640x480 60.0 rune@runescomp:~$ cat /sys/class/drm/card0-DVI-I-2/modes 1920x1080i 1024x768 800x600 640x480 So we're seeing progress!
(In reply to comment #0) >When, for example, the 1080i mode that is printed to the xorg log > is added manually with xrandr, it works fine. But these modes aren't listed by > default by xrandr. Your modes look similar to my TV - I thought that 1080i was OK at first glance, but then I noticed that parts of bottom line are displayed at the top X3. I am going to file a bug (lower res i modes also have colour problems). Assuming you have overscan off on the tv, could you test please, by moving a window around over the bottom of the screen to see if you also see this.
Created attachment 45243 [details] tv section of xorg log + xrandr (In reply to comment #3) > Also check sysfs to see if the kernel is sees the modes or if X is rejecting > them: > cat /sys/class/drm/<connector>/modes For me the kernel sees the same few modes as xrandr. These are referred to as probed modes in xorg log, the others as DDC gathered.
Created attachment 45429 [details] Output of 'xrandr --verbose' (In reply to comment #5) > Assuming you have overscan off on the tv, could you test please, by moving a > window around over the bottom of the screen to see if you also see this. Overscan seems to be on for the TV, and I'm not sure how to turn it off. The manual doesn't mention anything about overscan. I have tried adjusting the "underscan"/"underscan vborder"/"underscan hborder" properties using xrandr but they seem to have no effect. I'm including the verbose output of xrandr in case this is helpful.
Created attachment 45447 [details] Xorg.0.log without xorg.conf I'm attaching an Xorg.0.log of the system starting up with both the CRT and the TV connected but without any xorg.conf file.
(In reply to comment #7) > Created an attachment (id=45429) [details] > Output of 'xrandr --verbose' > > (In reply to comment #5) > > Assuming you have overscan off on the tv, could you test please, by moving a > > window around over the bottom of the screen to see if you also see this. > Overscan seems to be on for the TV, and I'm not sure how to turn it off. The > manual doesn't mention anything about overscan. I have tried adjusting the > "underscan"/"underscan vborder"/"underscan hborder" properties using xrandr but > they seem to have no effect. Sorry for the delayed response. It's possible I suppose there may be a setting hidden away somewhere - but then I don't know what TV you have. If you can't see the edge of your screen then you won't be able to see what I mean - I filed a bug for it. https://bugs.freedesktop.org/show_bug.cgi?id=35970 I can confirm, that turning on underscan with xrandr does not work for interlaced modes, it does work for progressive modes.
It looks like the kernel edid parser doesn't parse edid extension blocks while X does.
(In reply to comment #10) > It looks like the kernel edid parser doesn't parse edid extension blocks while > X does. Ah, I see. Well good that you seem to know what the issue is. So this bug is more of a feature request than a bug? I'm guessing this parsing isn't exactly trivial to implement...
Is this still an issue with a newer driver/kernel? Recent kernels should now pull additional hdmi modes from the edid. Please re-open if you are still having an issue.
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.