Bug 1054645

by the way, this is (of course) related to the hidpi troubles of many users....

How is this related to kscreen? Except for

> KDE utility cannot handle scaling of separate monitors, it scales them stupidly all. easy, but useless.

which is currently a WONTFIX this is only about xrandr.

@fabian,

this is about Linux desktop not able to individually scale two or more monitors.

wether that is a xrandr / kscreen issue or both, is imo not very relevant.

It just needs to get fixed.

xrandr is broken, and so is Kscreen. 

because neither can do their job properly.


best,

Rens

This is automated batch bugzilla cleanup.

The openSUSE 42.2 changed to end-of-life (EOL [1]) status. As such
it is no longer maintained, which means that it will not receive any
further security or bug fix updates.
As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
openSUSE, or you can still observe it under openSUSE Leap 15.0, please
feel free to reopen this bug against that version (see the "Version"
component in the bug fields), or alternatively open
a new ticket.

Thank you for reporting this bug and we are sorry it could not be fixed
during the lifetime of the release.

[1] https://en.opensuse.org/Lifetime

Created attachment 767473 [details]
autoscales an eDPI and optionally 2 HD screens so the eDPI remains usable.

42.3 still has the same issues.

improved the autoscale script so it handles max 3 monitors.

needs to be adapted to one's personal situation (names of the screens, mostly)

scaling still does not work properly. not by xrandr, not by kde kscreen.


updated the autoscale script.

KScreen does not implement per-screen scale on X11, that is intentional.
It works fine on Wayland. If you really need it on X11, please talk with upstream.

I'll reassign to the X.Org component for the xrandr bug.

I can confirm the xrandr behavior on Leap 42.3. I also tested upstream xrandr and it behaves the same way.

The --right-of, --left-of, etc. are interpreted by the xrandr commandline tool. X server receives the final calculated absolute numbers. So the interaction with the --scale feature has to be improved in the xrandr tool. That also means that other randr tools may have already fixed this issue, or will have to do it on their own.

By the way, the --scale is only a shortcut for --transform, so the relative monitor placements would need to work with general 2D transformation. But that should not be a problem, we just need to get the bounding box of the monitor post transformation. There is already function for that in xrandr.

Rens, can you please test if xrandr from this buildservice project behaves as you would expect with regards to the scale?

Project:
https://build.opensuse.org/project/show/home:michalsrb:branches:bnc1054645:X11:XOrg

Leap 42.3 repository:
https://download.opensuse.org/repositories/home:/michalsrb:/branches:/bnc1054645:/X11:/XOrg/openSUSE_Leap_42.3/

Note that since this is on edge between a bug and feature, I will not submit it to OpenSUSE unless it is accepted upstream first.

Michael,
thx,
will do that this weekend.

best
Rens

hi Michael,
did some testing.
starting point: 3 monitors.
+---------+------------+
| hdmi-1  |   hdmi-2   | 1920x1080 (both)
|         |            |
+---------+------------+
|         | 2560x1440
|  edp-1  | 
+_________+

xrandr at start:

xrandr |grep -e Screen -e connected  # omit all the frequencies possible....
Screen 0: minimum 320 x 200, current 3840 x 2520, maximum 8192 x 8192
eDP-1 connected 2560x1440+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 1920x1080+0+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

___________________________________________

Now scale eDP-1 to 0.6 and see if all displays get positioned properly

xrandr --output eDP-1 --scale 0.6x0.6

= xrandr |grep -e Screen -e connected
Screen 0: minimum 320 x 200, current 3840 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 1920x1080+0+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 FB is good, eDP-1 is good. HDMI's still good.

_______________________________________________

Now scale eDP-1 back to native resolution:

xrandr --output eDP-1 --scale 1.0x1.0
4.4.120-45-default:itsme:[/data/itsme/bin]
= xrandr |grep -e Screen -e connected
Screen 0: minimum 320 x 200, current 3840 x 2520, maximum 8192 x 8192
eDP-1 connected 2560x1440+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 1920x1080+0+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

All good.

_________________________________________________

scaling a the rightmost HDMI to 1.1

xrandr |grep -e Screen -e connected
Screen 0: minimum 320 x 200, current 4032 x 2520, maximum 8192 x 8192
eDP-1 connected 2560x1440+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 1920x1080+0+0 (normal left inverted right x axis y axis) 527mm x 296mm
HDMI-2 connected 2112x1188+1920+0 (normal left inverted right x axis y axis) 527mm x 296mm
4

All good

_____________________________________________________

scale eDP-1 to 0.6, HDMI-2 back to 1.0, and HDMI-1 to 0.8

xrandr --output HDMI-2 --scale 1.0x1.0 --output HDMI-1 --scale 0.8x0.8 --output eDP-1 --scale 0.6x0.6
4.4.120-45-default:itsme:[/data/itsme/bin]
= xrandr |grep -e Screen -e connected
Screen 0: minimum 320 x 200, current 3840 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+0+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

Not good.
scaling is done properly, but HDMI-2 should have been at 1536x0, not at 1920x0

________________________________________

change of order ?? (cuz HDMI-2 was first on the line, not HDMI-1 )
( i first reset eDP-1 and HDMI-1/2 to 1.0 scaling. that worked out OK.)

xrandr --output HDMI-1 --scale 0.8x0.8 --output HDMI-2 --scale 1.0x1.0 --output eDP-1 --scale 0.6x0.6 

No that did not work out correctly, although the *order* of specs was allowing  a correct outcome. the HDMI-2 is still at 1920x0, where it should have been at 1536x0 :

= xrandr |grep -e Screen -e connected
Screen 0: minimum 320 x 200, current 3840 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+0+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

____________________________________

scaling HDMI-1 to 0.5 also does not work properly:
the 1080 height becomes 540 height, but the eDP-1 screen right under it, should of course be moved up to 0x540.  

xrandr --output HDMI-1 --scale 0.5x0.5
4.4.120-45-default:itsme:[/data/itsme/bin]
= xrandr |grep -e Screen -e connected
Screen 0: minimum 320 x 200, current 3840 x 1800, maximum 8192 x 8192
eDP-1 connected 1280x720+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 960x540+0+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



IN other words: I can rescale a monitor at the outside: 
that is, in my example setup:
the HDMI-2 right most,
and the eDP-1 bottom,
but as soon as I change the scale of the HDMI-1, things go wrong.

What needs to be done is to ensure that xrandr recalculates the boxes row by row from left to right and then start configuring the outputs.

handling correctly configurations like:
1 2 3 4

1 2 3
4

1 2
3 4

would be a start :-)

but there is folks who have this:

1 2 3
    4

oh, and there is folks who put (one of) their monitors vertical, if they are in to word processing....

cheers,
Rens

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.

(In reply to Stefan Dirsch from comment #12)
> 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.

Well, the user may want to have gaps, for whatever reasons. Could be even for testing purposes.

(In reply to Stefan Dirsch from comment #14)
> Well, the user may want to have gaps, for whatever reasons. Could be even
> for testing purposes.

LOL

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....

Created attachment 767907 [details]
camera screenshot showing there is no gap where there should have been one

(In reply to Stefan Dirsch from comment #14)
> 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"

(In reply to rens groenewegen from comment #17)
> 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.

handling correctly configurations like:
1 2 3 4

1 2 3
4

1 2
3 4

would be a start :-)

but there is folks who have this:

1 2 3
    4
(In reply to rens groenewegen from comment #16)
> 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...

(In reply to Stefan Dirsch from comment #12)
> 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.

I agree with Stefan here. Xrandr is not going to change position unless you tell him with the absolute --pos parameter or one of the relative parameters like --left-of. The information whether a monitor was placed relatively to another or on absolute position is not stored anywhere. From X server's point of view there are only absolute positions and xrandr does not persist any settings itself. It is a simple tool that does only what is it told at the moment. Other randr tools, like kscreen, may store such information aside.

I will check how it behaves with more monitors, but keep in mind that you should always specify the full setup including all relative positions when calling xrandr. Otherwise it will do only the changes you write, leaving the rest as it is.

> (In reply to rens groenewegen from comment #16)
> > 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

This is certainly a bug. I will try to reproduce it. The X error killed xrandr in the middle of configuring X server, so it left it in some state between the old and the new configuration. The state after that does not matter, it would not happen if xrandr would not crash.

> 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.

The strategy xrandr uses is to first disable any outputs that would be outside the new framebuffer size, then change the framebuffer size, then re-enable and configure all outputs. But it seems that in this case it did not work as it should.

Related to scaling: xrandr --output HDMI1 --scale 2x2 --fb 7980x2160 --pos 3840x0

works for me in Leap 15.0, but there is a bug where your mouse pointer is limited to a quarter of the screen.

Apparently there is a fix for this, could there be an update?

https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1580123

(In reply to David F from comment #23)
> Related to scaling: xrandr --output HDMI1 --scale 2x2 --fb 7980x2160 --pos
> 3840x0
> 
> works for me in Leap 15.0, but there is a bug where your mouse pointer is
> limited to a quarter of the screen.
> 
> Apparently there is a fix for this, could there be an update?
> 
> https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1580123

Well, looks like for this you still need an additional patch from 2014 (?!?) and then you need to specify --panning in addition and then xorg-server may crash in the end. I suggest to handle this in a separate bug once you figured out, what exactly is needed.

Rens, is that still an issue with current TW or a supported openSUSE Leap version?

42.3 still supported, or ??

(In reply to Stefan Dirsch from comment #27)
> Rens, is that still an issue with current TW or a supported openSUSE Leap
> version?

42.3 still supported ??

(In reply to rens groenewegen from comment #29)
> (In reply to Stefan Dirsch from comment #27)
> > Rens, is that still an issue with current TW or a supported openSUSE Leap
> > version?
> 
> 42.3 still supported ??

Sorry. You're right. 42.3 is still supported.

JFYI,

https://en.opensuse.org/Lifetime

[...]
Leap 42.3 - is expected to be maintained until June 30 2019
[...]

Meanwhile 42.3 is no longer supported. Any improvements with Leap 15.0/15.1?

This is automated batch bugzilla cleanup.

The openSUSE 42.3 changed to end-of-life (EOL [1]) status. As such
it is no longer maintained, which means that it will not receive any
further security or bug fix updates.
As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
openSUSE (At this moment openSUSE Leap 15.1, 15.0 and Tumbleweed) please
feel free to reopen this bug against that version (!you must update the
"Version" component in the bug fields, do not just reopen please), or
alternatively create a new ticket.

Thank you for reporting this bug and we are sorry it could not be fixed
during the lifetime of the release.

[1] https://en.opensuse.org/Lifetime

thats a great way of working on bugs


reported 2 years ago

no response for more than a year

finally someone picks it up

problem is too hard. so just wait for release to become unsupported


then ask to resubmit in case it is still a problem...

thanks. but no thanks. I will not.

bye