Created attachment 17704 [details] /etc/X11/xorg.conf Before the addition of scaling to the driver after the April 29th git snapshot, a dual-head configuration of a 1920x1200 external LCD on DVI-D_1 and a laptop 1400x1050 PANEL to the RightOf the LCD worked fine. There was virtual screen real estate off the bottom of the PANEL that was inaccessible, but no big deal. After the addition of scaling on commit 26ccf1177465beb2db5a2c972dd7adc17c3f457b, the laptop is forced into the scaled "letterbox" style mode, making it tiny, undreadable, and with unusable black space on the top and bottom of the screen. Which is of course exactly what the new 1920x1200Scaled mode should look like. However, it's not what I want. I don't think it's a simple matter of a bad default selection, as the native 1400x1050 mode is set as the preferred mode. Trying to make it use this via xrandr manually fails: xrandr --output PANEL --mode 1400x1050 xrandr: Configure crtc 1 failed so I think the ability to use the native mode in this case is just broken, and the scaled mode is the fallback that works. xorg.conf attached, along with -logverbose 7 X logs for two cases: the working 20080429 version (git commit 45fdec79e523f3f9637c35a3d84c1fd9e61b9b21) and the latest of the broken versions, 20080716 (git 820187b208ab1ec94a015f07e48abbb381524c89). xrandr outputs also attached. Other info which I don't thinks is relevant but can't hurt: a fully patched Fedora 9 system, using Hans Ulrich's nicely packaged radeonhd rpms, system is a T60p Thinkpad with an M56 chip.
Created attachment 17705 [details] Working Xorg.0.log from pre-scaling era
Created attachment 17706 [details] Xorg.0.log with the forced scaling bug present
Created attachment 17707 [details] xrandr output in the working, pre-scaling case
Created attachment 17708 [details] xrandr output in the broken, forced-scaling case
A clarification - without the external LCD attached, the laptop's panel runs just fine in its native 1400x1050 mode. Only when trying to do dualhead does it insist on going into the scaled mode.
> Before the addition of scaling to the driver after the April 29th git snapshot, > a dual-head configuration of a 1920x1200 external LCD on DVI-D_1 and a laptop > 1400x1050 PANEL to the RightOf the LCD worked fine. There was virtual screen > real estate off the bottom of the PANEL that was inaccessible, but no big deal. Do you really want that? Isn't it better to be able to see the same screen content on both heads? You only see some part of the full screen of the external display on the laptop panel. So the hidden stuff would be even more unreadable as the one on the scaled screen. > After the addition of scaling on commit > 26ccf1177465beb2db5a2c972dd7adc17c3f457b, the laptop is forced into the scaled > "letterbox" style mode, making it tiny, undreadable, and with unusable black > space on the top and bottom of the screen. Which is of course exactly what the > new 1920x1200Scaled mode should look like. However, it's not what I want. Of course it would be possible to modify the code to not scale down when the option Option "ScaleType" "None" is set. This would restore your old behavior if the external screen has a higher resolution than the internal one. > I don't think it's a simple matter of a bad default selection, as the native > 1400x1050 mode is set as the preferred mode. Trying to make it use this via > xrandr manually fails: The mode picking is unfortunately done by randr. xrandr --output PANEL --mode 1400x1050 xrandr: Configure crtc 1 failed I don't know why this is happening. I need to investigate. The Xserver log shows: (II) RADEONHD(0): rhdRROutputModeFixup: Output PANEL : 1400x1050 (II) RADEONHD(0): FUNCTION: RHDRRModeFixup (II) RADEONHD(0): rhdRROutputModeFixup: 1400x1050 FAILED: internal error This doesn't explain what's happening unfortunately. > so I think the ability to use the native mode in this case is just broken, and > the scaled mode is the fallback that works. Possibly.
(In reply to comment #6) > I don't know why this is happening. I need to investigate. > The Xserver log shows: > (II) RADEONHD(0): rhdRROutputModeFixup: Output PANEL : 1400x1050 > (II) RADEONHD(0): FUNCTION: RHDRRModeFixup > (II) RADEONHD(0): rhdRROutputModeFixup: 1400x1050 FAILED: internal error I've looked at the problem again: I'm reluctant to change any behavior as the user preferences differ. I would like to concentrate on fixing the above error so that it is possible to change the resolution to the native mode using randr.
> Do you really want that? > Isn't it better to be able to see the same screen content on both heads? > You only see some part of the full screen of the external display on the laptop > panel. So the hidden stuff would be even more unreadable as the one on the > scaled screen. When working on multiple monitors, IMHO comparable dpi is the most important factor, to enhance the illusion that you really have one big workspace. In this case, 1920x1200 scaled onto 1400x1050 simply makes the fonts unreadable. The missing space off the bottom, on the other hand, is out of sight and out of mind - one doesn't miss what never existed :) > Of course it would be possible to modify the code to not scale down when the > option Option "ScaleType" "None" is set. This would restore your old behavior > if the external screen has a higher resolution than the internal one. This would be a capital workaround. I can see that my "IMHO" above is a personal preference, and would be quite happy to simply be able to configure it away. Will be able to test this come Monday (the external LCD is in the office). > I've looked at the problem again: I'm reluctant to change any behavior as the > user preferences differ. I would like to concentrate on fixing the above error > so that it is possible to change the resolution to the native mode using randr. Fixing errors is always +1 Let me know how I can help. Just so long as one can set their preference in the xorg.conf and not have to script xrandr commands.
(In reply to comment #8) > > When working on multiple monitors, IMHO comparable dpi is the most important > factor, to enhance the illusion that you really have one big workspace. In > this case, 1920x1200 scaled onto 1400x1050 simply makes the fonts unreadable. > The missing space off the bottom, on the other hand, is out of sight and out of > mind - one doesn't miss what never existed :) OK, I see this point. It is hard to have a default that makes everyone happy. The other scenario is where one uses a laptop for a presentation. This however requires that the dpi of both displays match. This would not be the case for my laptop (1680x1050) vs. my much bigger lcd with 1920x1200. Here of course one could use scaling to make this match. There this person might want to see exactly the same on the laptop display as is shown on the screen. > This would be a capital workaround. I can see that my "IMHO" above is a > personal preference, and would be quite happy to simply be able to configure it > away. Will be able to test this come Monday (the external LCD is in the > office). > > > I've looked at the problem again: I'm reluctant to change any behavior as the > > user preferences differ. I would like to concentrate on fixing the above error > > so that it is possible to change the resolution to the native mode using randr. > > Fixing errors is always +1 > > Let me know how I can help. OK, thanks. The 'FAILED' log file message I've included in one earlier comment troubles me. The reason is not specified so it's even harder for me to guess where it originates from. Today I committed code to make the message even more verbose. Can you get the latest git sources, start the xserver with verbose level 7 again and use xrandr to try to switch the panel to native mode? This worked well here and i don't understand why it doesn't work for you. I need to find out what validation test fails in your case. I was using a similar setup as yours only that my laptop is 1680x1050 instead of 1400x1050. > > Just so long as one can set their preference in the xorg.conf and not have to > script xrandr commands. > That's exactly the problem: it's a policy decision done by randr. The general believe there is that people will have some desktop thingy which will store the last configuration on log out and restore it the next time the user logs in. So the goal is to do away with a config file as much as possible. In your case I unfortunately have no clue how to set this up. You'd have to instruct randr to set each display to its native mode.
Created attachment 17839 [details] Using ScaleType None (git commit 31e46386) Using git snapshot 31e46386 with option ScaleType None, I get the old behavior I wanted: native resolution on the smaller PANEL. Hooray for open source and active development! Xorg.0.log attached.
Created attachment 17840 [details] Letting it try to scale (git commit 31e46386) However, without disabling the whole scaling thing, it still gives me the scaled output on PANEL. Xorg.0.log attached, which does output a lot more info when it tries to go to the preferred native mode and fails over to the scaled mode. Same behavior as previously when trying to xrandr manually, it fails and shuts down the PANEL. Something else I've noticed between the April pre-{DRI,Scaling} driver and any of the newer versions is that the external monitor glitches momentarily once every few minutes - blinks blank for a fraction of a second and recovers instantly. Distracting if not fatal, and all the logging is present in this bug already if anyone out there has an idea as to what might be making this. I'm not sure where on earth to start looking for that, it's pretty subtle.
Nuts - not so lucky with the ScaleType None after all. The PANEL is still scaling to 1920x1200Scaled, that mode's behavior is different. It's just fitting it to the whole panel rather than letterboxing it. Which is a slight improvement, but not what I was hoping for. I had simply joyously moved my mouse back and forth in the letterbox-free PANEL when reporting the previous success, opening a window with actual fonts brought me back to earth.
@Alec: Using Option "OutputOrder" "PANEL" here sort of does what you are asking for. Still it would be better to find out why your panel shuts off when you try to set the native mode of the panel. This is of course because xrandr is failing which again is related to the error message in the log file described in comment #7. Unfortunately this message isn't very telling so I've made it slightly more verbose in a very recent commit. So I need you to run a late version of the driver with '-logverbose 7' run xrandr again to set native mode, wait until the PANEL shuts off then terminate X and get me the log. I've tried to reproduce it here with my laptop and my external screen but I don't see the problem. So I need to rely on you to help me here.
Created attachment 17857 [details] Xorg.0.log with the logs for the xrandr-induced PANEL shutdown Logfile attached, which talks near the end about the shutdown of the PANEL induced by trying to set it to native mode. As for the OutputOrder, without that option the 1920x1200 external monitor always comes up in the 1400x1050 resolution of the PANEL, even though PreferredMode is set to the native resolution and a Virtual screen is set to be big enough to hold everything. Is the PreferredMode given any weight in the decisions which set the resolution? Could this be a hangover from the bad old CRT days? With modern LCDs, there is very little reason to ever run one at other than its native resolution. Mirroring a projector for a presentation or running a game fullscreen are the only two that come to mind. Certainly doing work for any length of time on a LCD running some other resolution is a recipe for a headache. xorg and xrandr have come a long way in making xorg.conf tweaks unnecessary, but the ability to define things statically in xorg.conf (overriding the automation) should certainly be retained. Perhaps "Preferred" is too softly-worded an option, what I'm looking for is a "use any other mode only if the selected mode causes smoke to escape" setting :)
Alec, thanks for the log file, I think I know what's going on. I've got a patch prepared which I will push soon.
Alec: Thanks for the logs btw. I've just pushed a bunch of fixes. Please retest. If it still doesn't work please supply a verbose log again as before. (You don't need to phase in the xrandr output, the plain verbose 7 Xserver log is sufficient). Thanks!
Thanks Egbert, will try. Have got it built but not packaged yet, stumbled across references in {src/Makefile.in,src/Makefile.am} to the now-removed radeon_dripriv.h which I can manually work around but need to go learn more git magic for the rpmbuilding scripts to work around. Stay tuned...
Alec, thanks! I've just pushed a build system fix.
Created attachment 18040 [details] log file with initial default to scaled mode but successful xrandr to native mode Great! With commit 708e31a4, although X came up in the scaled mode on PANEL, I was able to xrandr to the native mode successfully (logfile attached). Unfortunately, both Option "ScaleType" "None" and Option "PreferredMode" "1400x1050" seem to have no influence on the initial choice of modes for PANEL. The logfile does claim: (II) RADEONHD(0): Using user preference for initial modes (II) RADEONHD(0): Output DVI-D_1 using initial mode 1920x1200 (II) RADEONHD(0): Output PANEL using initial mode 1920x1200Scaled Which is something of a lie, since earlier it has read in the correct PreferredMode's from the xorg.conf: (II) RADEONHD(0): Output DVI-D_1 using monitor section DoubleSightDVI (**) RADEONHD(0): Option "PreferredMode" "1920x1200" (II) RADEONHD(0): Output VGA_1 has no monitor section (II) RADEONHD(0): Output PANEL using monitor section ThinkpadLCD (**) RADEONHD(0): Option "PreferredMode" "1400x1050" (**) RADEONHD(0): Option "RightOf" "DoubleSightDVI" I can see it Validating a lot of modes in between the above statements, but it doesn't provide any more comments on why it thinks it's "Using user preference for initial modes" when it's patently not. Any ideas? Looks like the plain old bug is fixed, now it's a subtler issue of how things decide which mode to start off in.
PS - if I take out the RROutputOrder option, then PANEL comes up in it's preferred mode but DVI-D_1 comes up in 1400x1050 instead of its PreferredMode. So one way or the other, a PreferredMode gets ignored.
Alec, you are right in both your last comments. RandR tries to match modes as closely as possible so that you see the same on all screens (or that screens match up either horizontally or vertically). This is because on modern day desktops you almost always have elements on the bottom or on one side which you won't be able to reach on the smaller display. If you want something else you'd have to use xrandr --output PANEL --mode 1400x1050. My goal was to make this no longer fail so that you can really set up your panel the way you personally prefer. The option 'none' doesn't have any effect if you have to scale down. It only affects the case where you scale up, as it will give you the screen in the top left corner while the parts of the panel the smaller root window doesn't cover are black. You cannot do this in the downscale mode. The startup default is something controlled by RandR not the driver. Scaling just extends the list of available modes for the panel from one (the native one) to a list of standard resolutions. This way the user can choose a resolution at run time using xrandr or some other tool.
Ok. Sounds like for the purposes of the radeonhd driver, this bug is fixed (so I'm resolving it), as xrandr will now put the screens in the modes I want if I do it manually. My complaints about lack of a persistent means of setting your preferences if they happen to disagree with what xrandr thinks is best should be opened as a bug against xrandr instead of the driver :) See bug #16927. Thanks for the fix!
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.