[Bug 1054645] New: kde cannot handle scaling only 1 of 2 monitors, xrandr multi screen placement is broken when using scaling.
http://bugzilla.novell.com/show_bug.cgi?id=1054645 Bug ID: 1054645 Summary: kde cannot handle scaling only 1 of 2 monitors, xrandr multi screen placement is broken when using scaling. Classification: openSUSE Product: openSUSE Distribution Version: Leap 42.2 Hardware: Other OS: openSUSE 42.2 Status: NEW Severity: Major Priority: P5 - None Component: KDE Workspace (Plasma) Assignee: opensuse-kde-bugs@opensuse.org Reporter: rens.groenewegen@xs4all.nl QA Contact: qa-bugs@suse.de Found By: --- Blocker: --- Created attachment 737389 --> http://bugzilla.novell.com/attachment.cgi?id=737389&action=edit script that shows correct xrandr command for scaling and placing of multi monitor setup KDE utility cannot handle scaling of separate monitors, it scales them stupidly all. easy, but useless. xrandr is supposed to be able to handle multi monitor setups. this will sort-of work, as long as the scaling factor of the monitors is not different, and not other than 1.0 ( i.e, no scaling ) I have a eDP 2560x1440 (enhanced DPI ) laptop screen, and a "normal" HDMI HD (1920x1080) screen. Scaling of one of the monitors, if using both monitors at the same time, is not possible. xrandr screws up the layout, and/or screws up the framebuffer (too small) because it does not calculate properly what is required when scaling 1 or even both monitors. (cannot try more than 2 monitors, pffff ) for example, what should work: 2 screens next to each other: left one is eDP (2560x1440) other is HDMI (1920x1080) You will want to scale the eDP screen to 0.6 ( that is, enlarge it) so you can read it. +---------+------------+ | | | | | | | | | | +------------+ +_________+ to set this up, xrandr man page claims you should do this: xrandr -d :0 --output eDP-1 --scale -0.6x0.6 --pos 0x0 --output HDMI-1 --scale 1x1 --right-of eDP-1 this does NOT work. (would be lovely, though.. ) what goes wrong: the width of eDP-1 is 2560 native, but because of scaling it becomes 1536x864. xrandr will put the HDMI screen at 2560, (while this should have been 1536) which means you have a thousand pixel gap between eDP-1 and HDMI-1 like so: +---------+ +------------+ | | | | | eDP-1 | | HDMI-1 | | | | | | | +------------+ +_________+ xrandr in this case will also allocate keep the framebuffer as it was, which is bigger than what is needed, because of insisting on the 2560 width. that means that your mouse cursor can go off screen where it shouldnt be possible, apart from the gap between the two screens. if you would want to configure a vertical setup like this: +--------------+ | | | HDMI-1 | | | +---------+----+ | eDP1 | | | | | +---------+ and then scale the top screen, you have a problem: the top screen overlaps the bottom screen, because again, the placement is derived from the native screen dimensions, not from the scaled dimension. If you want to scale the top screen to smaller, screen, you get the gap again. please find attached a script, which builds the required xrandr command and shows it. it works by exactly calculating the required parameters (and avoid using --below, right-of and similar placing parameters, because they do NOT work ) This will "kind of" work, but not always. it is sometimes necessary to reset both monitors by scaling them to use scale 1.0x1.0. or even use init 3 / init 5 to reset the state of X. My question is: can we PLEASE fix this BS ? it's not that difficult, and very annoying to have to deal with this ( think presenting to an audience, for example......) best, Rens -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=1054645
http://bugzilla.novell.com/show_bug.cgi?id=1054645#c1
--- Comment #1 from rens groenewegen
http://bugzilla.novell.com/show_bug.cgi?id=1054645
http://bugzilla.novell.com/show_bug.cgi?id=1054645#c11
--- Comment #11 from rens groenewegen
http://bugzilla.novell.com/show_bug.cgi?id=1054645
http://bugzilla.novell.com/show_bug.cgi?id=1054645#c12
--- Comment #12 from Stefan Dirsch
http://bugzilla.novell.com/show_bug.cgi?id=1054645
http://bugzilla.novell.com/show_bug.cgi?id=1054645#c13
--- Comment #13 from rens groenewegen
I haven't tried Michal's xrandr yet, but I'm wondering why you expect a realignment of the monitors, when changing the resolution via scale option of the "inner" monitor when omitting the position option like e.g. --letf-of?
Have you tried that? IMHO it would be even wrong to do an auto-alignment here, i.e. silently changing the position.
just tried a few. does not look like that works properly either, except for the simple case of 2 monitors. with three it fails, it looks like. But, I will get back with structured test being 100% sure about starting point etc. However, I do not think that it is "wrong" for software to accommodate proper functioning if the required information is available. i.e, if it can calculate positioning of the boxes and size of the framebuffer from the information, it should just do that. it is no rocket science. After all, it is not reasonable to assume a user wants gaps between the outputs, because that would serve no purpose at all. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=1054645
http://bugzilla.novell.com/show_bug.cgi?id=1054645#c14
--- Comment #14 from Stefan Dirsch
http://bugzilla.novell.com/show_bug.cgi?id=1054645
http://bugzilla.novell.com/show_bug.cgi?id=1054645#c15
--- Comment #15 from rens groenewegen
Well, the user may want to have gaps, for whatever reasons. Could be even for testing purposes.
LOL -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=1054645
http://bugzilla.novell.com/show_bug.cgi?id=1054645#c16
--- Comment #16 from rens groenewegen
http://bugzilla.novell.com/show_bug.cgi?id=1054645
http://bugzilla.novell.com/show_bug.cgi?id=1054645#c17
--- Comment #17 from rens groenewegen
http://bugzilla.novell.com/show_bug.cgi?id=1054645
http://bugzilla.novell.com/show_bug.cgi?id=1054645#c18
--- Comment #18 from rens groenewegen
Well, the user may want to have gaps, for whatever reasons. Could be even for testing purposes.
sorry for laughing out loud. I suggest we have a --userdebug option to achieve that. or a --act_normal option to disable this "feature" -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=1054645
http://bugzilla.novell.com/show_bug.cgi?id=1054645#c19
--- Comment #19 from rens groenewegen
Created attachment 767907 [details] camera screenshot showing there is no gap where there should have been one
hmm correction : X did not loose track, it is xrandr showing data that does not match reality. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=1054645
http://bugzilla.novell.com/show_bug.cgi?id=1054645#c20
--- Comment #20 from rens groenewegen
tested with option --left-of, as stefan suggested.
starting point: 3 monitors. +---------+------------+ | hdmi-1 | hdmi-2 | 1920x1080 (both) | | | +---------+------------+ | | 2560x1440 | edp-1 | +_________+
xrandr --output HDMI-1 --scale 0.8x0.8 --left-of HDMI-2 X Error of failed request: BadMatch (invalid parameter attributes) Major opcode of failed request: 140 (RANDR) Minor opcode of failed request: 7 (RRSetScreenSize) Serial number of failed request: 37 Current serial number in output stream: 39 4.4.120-45-default:itsme:[/data/itsme] = xrandr |grep -e Screen -e connected Screen 0: minimum 320 x 200, current 3856 x 1944, maximum 8192 x 8192 eDP-1 connected 1536x864+0+1080 (normal left inverted right x axis y axis) 294mm x 165mm DP-1 disconnected (normal left inverted right x axis y axis) HDMI-1 connected primary 1536x864+384+0 (normal left inverted right x axis y axis) 527mm x 296mm HDMI-2 connected 1920x1080+1920+0 (normal left inverted right x axis y axis) 527mm x 296mm
screen buffer is wrong: should be 3456x1944 ( 1536 + 1920 )x 1944
output HDMI-2 should be at 1536x0, which it is not. it's at it's old position.
so much for what xrandr says. the FB operation fails, but the placement succeeds, although X has lost track of the reality "on the ground". check out the attachment with the screenshot (taken with a camera, not with X :-) ) of this text, on the gap between HDMI-1 and 2: there is no gap. while there should have been a 384 pixel gap.
as we can see, the word "have" in the previous sentence is not missing a single digit, not quite possible when 384 pixel should have been missing....
just contemplating these results: Order is important: screenbuffer size shrinking (width AND/OR height) can only be done *after* resizing outputs (the current outputs would generate an error, I think that is what happened here) screenbuffer size increasing (width AND/OR height) must of course happen *before* any output resizing. perhaps that has something to do with xrandr loosing track of actual placement... -- You are receiving this mail because: You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply＠novell.com