Summary: | [r300 KMS] KMS uses wrong display resulution, xrandr causes X to crash | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | DRI | Reporter: | Daniel Klaffenbach <danielklaffenbach> | ||||||||
Component: | DRM/Radeon | Assignee: | Default DRI bug account <dri-devel> | ||||||||
Status: | RESOLVED MOVED | QA Contact: | |||||||||
Severity: | normal | ||||||||||
Priority: | medium | CC: | marius.groeger | ||||||||
Version: | XOrg git | ||||||||||
Hardware: | x86 (IA32) | ||||||||||
OS: | Linux (All) | ||||||||||
Whiteboard: | |||||||||||
i915 platform: | i915 features: | ||||||||||
Attachments: |
|
Description
Daniel Klaffenbach
2009-11-07 05:21:25 UTC
Created attachment 31035 [details]
Xorg log file after crash
Created attachment 31036 [details]
xorg config file
My xorg config file. Note that I have AIGLX and Compositing disabled.
I see the same issue on my T43 (r300) with these components: - kernel 2.6.33 - xserver-xorg-video-ati 6.12.191+git20100302.e6dc8866-0ubuntu0sarvatt~karmic - no xorg.conf - KMS: modeset=1 dynclks=1 Please let me know if I can provide any kind of log or dump to help finding a solution. The core issue seems to be, as Daniel reported, too, the false detection of an S-Video connection while there is none present. (In reply to comment #0) > Created an attachment (id=31034) [details] > dmesg from 2.6.32-rc6 after X crash > > I just tested KMS with 2.6.32-rc6 for my Radeon Xpress 200M in a HP nx6125. > > When the system boots KMS selects the wrong resolution for the framebuffer > (800x600 instead of 1024x768). In dmesg it says: > > [drm] LVDS-11: set mode 1024x768 16 > [drm] crtc 1 is connected to a TV > [drm] TV-9: set mode 800x600 17 > > However, I do not have any other monitors/TVs connected (just the laptop > panel). But the worst thing of all is that X behaves abnormally: > - X also uses 800x600 > - X (or let's say my XSession) does not load correctly > - to make my XSession start up completely I need to switch to VT1 and back to > VT7 > - when issuing "xrandr --output LVDS --auto" Xorg crashes immediately Is this still an issue with 2.6.33 or drm-next? (In reply to comment #3) > I see the same issue on my T43 (r300) with these components: > - kernel 2.6.33 > - xserver-xorg-video-ati 6.12.191+git20100302.e6dc8866-0ubuntu0sarvatt~karmic > - no xorg.conf > - KMS: modeset=1 dynclks=1 > > Please let me know if I can provide any kind of log or dump to help finding a > solution. The core issue seems to be, as Daniel reported, too, the false > detection of an S-Video connection while there is none present. > Are you getting a crash as well or just the tv-out getting detected as connected? Do either of your laptops have a tv-out port? Is the issue that your laptops do not have tv-out ports at all in which case they shouldn't be listed, or that they have ports, but they are being detected as connected when they are not? Thanks for picking this up, Alex. > Are you getting a crash as well or just the tv-out getting detected as > connected? No crash, just the tv-out getting detected as connected. > Do either of your laptops have a tv-out port? Is the issue that your laptops > do not have tv-out ports at all in which case they shouldn't be listed, or that > they have ports, but they are being detected as connected when they are not? The latter, in my case. I do have an S-video output (yellow cinch connector) but nothing's connected to it. > Is this still an issue with 2.6.33 or drm-next? I am using 2.6.33 final using the mainline-ppa builds for ubuntu. (In reply to comment #4) > Is this still an issue with 2.6.33 or drm-next? Nope. For me the TV-out/xrandr issue seems to be fixed. By now I am using 2.6-master, mesa-master, radeon-master and libdrm-master. My laptop has a TV-out port and it is now being reported as "disconnected", which is true. Now I do also get the full resolution in X and the framebuffer console. > > Is this still an issue with 2.6.33 or drm-next?
> Nope. For me the TV-out/xrandr issue seems to be fixed. By now I am using
> 2.6-master, mesa-master, radeon-master and libdrm-master.
Daniel, your reply is confusing, since it seems to still /be/ an issue with 2.6.33. Have you tried that kernel before switching to 2.6-master?
(In reply to comment #8) > Daniel, your reply is confusing, since it seems to still /be/ an issue with > 2.6.33. Have you tried that kernel before switching to 2.6-master? I did not try 2.6.33 (only git master). If I remember correctly the issue disappeared (for me) in the _final_ release of 2.6.32: http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.32 * drm/radeon/kms: Disable TV load detect on RS400,RC410,RS480 Thanks for clearing this up, Daniel. Seems I have to take it from here on my own, as the issue is definitely present with 2.6.33 on my r300 (Thinkpad T43). I verified this issue is still present with 2.6.35rc6 and the current X packages on xorg-edgers. Something new I noticed with Ubuntu 10.04: if I set GRUB_GFXMODE=1400x1050 (the native resolution of the LVDS) in /etc/defaults/grub, then the console actually uses the correct resolution. Howerver, once X starts, the new FB switches to 800x600. The Xorg.0.log indicates that S-Video is falsely detected as being connected, while in fact nothing is attached. What can I do to further isolate the cause of this issue? (In reply to comment #11) > I verified this issue is still present with 2.6.35rc6 and the current X > packages on xorg-edgers. Something new I noticed with Ubuntu 10.04: if I set > GRUB_GFXMODE=1400x1050 (the native resolution of the LVDS) in > /etc/defaults/grub, then the console actually uses the correct resolution. > Howerver, once X starts, the new FB switches to 800x600. The Xorg.0.log > indicates that S-Video is falsely detected as being connected, while in fact > nothing is attached. > > What can I do to further isolate the cause of this issue? Unfortunately, load detection for tv-out is inherently unreliable on a lot of boards (You can end up with false positives and false negatives). The best option is to force the tv-out connection on or off in your console or xorg config. (In reply to comment #12) > Unfortunately, load detection for tv-out is inherently unreliable on a lot of > boards (You can end up with false positives and false negatives). The best > option is to force the tv-out connection on or off in your console or xorg > config. Fair enough, however that's what I tried but it doesn't seem to work either. I have this definition in xorg.conf: Section "Monitor" Identifier "S-Video Monitor" Option "Enabled" "false" EndSection According to the Xorg.0.log it is picked up: (II) RADEON(0): Output S-video using monitor section S-Video Monitor but then this: (II) RADEON(0): Output LVDS connected (II) RADEON(0): Output VGA-0 disconnected (II) RADEON(0): Output DVI-0 disconnected (II) RADEON(0): Output S-video connected (II) RADEON(0): Using exact sizes for initial modes (II) RADEON(0): Output LVDS using initial mode 800x600 (II) RADEON(0): Output S-video using initial mode 800x600 Is there any other way to disable a connector? How to do it on the console? (In reply to comment #13) > (In reply to comment #12) > > Unfortunately, load detection for tv-out is inherently unreliable on a lot of > > boards (You can end up with false positives and false negatives). The best > > option is to force the tv-out connection on or off in your console or xorg > > config. > > Fair enough, however that's what I tried but it doesn't seem to work either. I > have this definition in xorg.conf: > > Section "Monitor" > Identifier "S-Video Monitor" > Option "Enabled" "false" > EndSection It's: Option "Enable" "False" However, some older xservers (maybe recent ones too), do not deal with enable false, you need to use: Option "Disable" "True" (In reply to comment #14) > Option "Enable" "False" > However, some older xservers (maybe recent ones too), do not deal with enable > false, you need to use: > Option "Disable" "True" Oops :-) However, unfortunately still no luck. "Enable" and "Disable" are accepted and confirmed in Xorg.0.log, but the resolution is still switch to 800x600. For some reason the probing seems to override the xorg.conf setting. Any further ideas? (In reply to comment #15) > Oops :-) However, unfortunately still no luck. "Enable" and "Disable" are > accepted and confirmed in Xorg.0.log, but the resolution is still switch to > 800x600. For some reason the probing seems to override the xorg.conf setting. > Any further ideas? Two things: 1) Option "Ignore" "true" in xorg.conf for your S-Video port 2) or try adding "radeon.tv=0" to your kernel commandline. Option 2 does not work for me as the machine seems to freeze with it. However you might have more luck ;) (In reply to comment #16) > (In reply to comment #15) > > Oops :-) However, unfortunately still no luck. "Enable" and "Disable" are > > accepted and confirmed in Xorg.0.log, but the resolution is still switch to > > 800x600. For some reason the probing seems to override the xorg.conf setting. > > Any further ideas? > Two things: > 1) Option "Ignore" "true" in xorg.conf for your S-Video port > 2) or try adding "radeon.tv=0" to your kernel commandline. Great, the Ignore option did the trick! Thanks a bunch! While it still feels like a bug, I'd understand if nothing can be done to it so we might just as well close it as WONTFIX. You guys decide... (In reply to comment #17) > Great, the Ignore option did the trick! Thanks a bunch! > > While it still feels like a bug, I'd understand if nothing can be done to it so > we might just as well close it as WONTFIX. You guys decide... "Ignore" means you won't be able to use the connector at all during the life of the xserver. If the Disable/Enable options are broken, that's most likely a xserver issue. (In reply to comment #18) > "Ignore" means you won't be able to use the connector at all during the life of > the xserver. If the Disable/Enable options are broken, that's most likely a > xserver issue. Yes thats probably right and I guess I should open a new bug for this. I was however referring to the original problem of the connector not being probed properly as unconnected. So here again my call to you to decide whether this is fixable at all or to just close this bug as a WONTFIX. -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/amd/issues/964. |
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.