| Summary: | xrandr size change kills second output | ||
|---|---|---|---|
| Product: | xorg | Reporter: | Pierre Ossman <pierre-bugzilla> |
| Component: | Driver/Radeon | Assignee: | xf86-video-ati maintainers <xorg-driver-ati> |
| Status: | RESOLVED FIXED | QA Contact: | Xorg Project Team <xorg-team> |
| Severity: | major | ||
| Priority: | medium | ||
| Version: | 7.3 (2007.09) | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
|
Description
Pierre Ossman
2007-11-10 08:31:01 UTC
with xrandr 1.2 you have to specify what output you want to change the resolution of: xrandr --output VGA-0 --mode 1280x1024 or xrandr --output DVI-0 --mode 1280x800 or xrandr --auto the supported modes are the ones listed under each output. xrandr -s only changes the mode on the backwards compatibility output which is VGA-0 in this case. Well, if the expected result is just that VGA-0 is modified, then this is a most definitely a bug as it also _permanently_ kills DVI-0. If your position is that all RandR 1.0 calls are unsupported then you really should add an option to make the X server ignore those. (In reply to comment #2) > Well, if the expected result is just that VGA-0 is modified, then this is a > most definitely a bug as it also _permanently_ kills DVI-0. > > If your position is that all RandR 1.0 calls are unsupported then you really > should add an option to make the X server ignore those. > randr 1.0 are supported, but they only work with one output. randr 1.0 did not have the concept of multiple outputs. if you run xrandr -s 1280x1024 what should be the expected behavior with multiple outputs some of which may not support 1280x1024. for randr 1.0 compatibility one crtc and one output are chosen by the driver as the compatibility output for randr 1.0 calls. if you want to be able to control multiple outputs use randr 1.2 calls. DVI-0 is not permanently dead, you just need to issue xrandr 1.2 calls to re-enable it. That's what I'm trying to explain, there is a bug somewhere that causes DVI-0 to go belly up. No xrandr call gets it back up and running again. The only way to get it back is to restart the X server. Just look at the way it suddenly decides that 1600x1200 is no longer support on DVI-0. I do not expect RandR 1.0 calls to magically do the right thing for every odd monitor setup. I don't expect the X server to be psycic. But I do expect backward compatibility. It's not like dual-head didn't exist before RandR 1.2, so there is a precedence for the behaviour of RandR 1.0 calls with two monitors. You might want to try the patches I just sent to xorg-devel about xrandr.c and randr/rrcrtc.c - I will also push them this week. It could well be that you're hitting the last case: Upon recreation of the RandR internal data structures in RRCrtcNotify() the crtc of an output could be NULLed if the crtc was shared (cloned) between two outputs and one of them got another crtc assigned. In this case you could only try to --off the according output and re-enable it. The output of your xrandr command a bit strange indeed, no idea whether DVI-0 is off or just in an invalid state. You also might want to add --crtc <x> to explicitly specify the crtc the secondary output should be connect to, i.e. xrandr --output DVI-0 --off; xrandr --output DVI-0 --mode 1600x1200 --crtc 1 I'll try to test your suggestions as soon as possible (the machine is unfortunately not at my place :/). The setup was however not a cloned one, but a big desktop. I also did not get a cloned setup when the second output died. Ok, I've tested the following: 1. Changing mode explicitly on either output: WORKS 2. Trying to disable broken output and re-enable with --auto: FAILS 3. Trying to disable broken output and re-enable with explicit mode and CRTC: FAILS 4. Disable second output before doing RandR 1.0 call: FAILS Building my own Xorg wasn't as trivial as I'd hoped, so I haven't tried your patch. This looks like a bug in the randr 1.0 compatibility support. Those paths are not too well tested I suspect. Can anyone reproduce this problem on another randr 1.2 driver (intel or mga for example)? Matthias' patch may indeed fix it. Has anyone been able to reproduce my problem and test if the patch fixes it? (The patch also seems to stay clear of the fact that the Randr 1.0 emulation does not behave like "real" Randr 1.0, so that issue would remain even if the patch fixes the dead DVI.) The problem is with randr 1.0, there was no concept of crtcs or outputs, so the "head" was whatever ended up being detected as connected (DVI, VGA, etc.). With randr 1.2 you have multiple crtc and outputs and one output and one crtc get chosen as the "compat" output and crtc (which very well may be different than what you got under randr 1.0 and the old driver). Now, if you use the xrandr 1.0 compatibility layer, it will change the mode on the compatibility crtc and output even though you may have them routed differently using xrandr 1.2 commands; that particular crtc and output may not even be currently associated. I'm not sure why the randr compat stuff permanently breaks changes via randr 1.2 though. Does forcing the crtcs help when attempting to reset the modes using randr 1.2? xrandr --output DVI-0 --crtc 1 --mode 1280x1024 Closing bug for inactivity, also this should be fixed wit recent xf86-video-ati and Xserver with randr 1.2 support, reopen if you still experience this issue with recent Xserver & xf86-video-ati. |
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.