Mulitple displays position issue with Hyprland

[gac3k]

Hey,

After updating Hyprland to the latest version, I do have a weird issue, that when connecting from mac os host to linux client, mouse is not moved to the monitor that is actually to the left from the host, and is going straight to the far left one, and then if I manually switch to the workspace on primary monitor it's other way around, I am then able to go from my primary monitor on the client to the host, but not to the far left one, as whenever I am going to the screen edge on primary monitor, mouse is getting locked, and I can only switch using keyboard shortcut. It is not happening if I am using mouse directly without utilizing waynergy.

My hyprland display configuration is, so one important factor here might be that I have my far left screen rotated.

monitor=DP-1,highres,1080x0,1
monitor=HDMI-A-1,highres,0x0,1,transform,1

Weird thing is that in the logs geometry seems to be properly recognized, and it was working just fine till this very update:

0.107775955: [INFO] Output updated: 1920x1080 at 0, 0 (scale: 1)
0.107798905: [INFO] Output name: HDMI-A-1
0.107804175: [INFO] Output description: Dell Inc. DELL U2414H 292K46B80EPL (HDMI-A-1)
0.107809055: [INFO] Output updated: 1080x1920 at 0, 0 (scale: 1)
0.107815615: [INFO] Output updated: 3440x1440 at 0, 0 (scale: 1)
0.107820775: [INFO] Geometry updated: 3440x1920
0.107826865: [INFO] Output name: DP-1
0.107831625: [INFO] Output description: LG Electronics LG ULTRAWIDE 304NTAB9S128 (DP-1)
0.107836215: [INFO] Output updated: 3440x1440 at 1080, 0 (scale: 1)
0.107841115: [INFO] Geometry updated: 4520x1920
0.107959076: [INFO] Compositor seems to be Hyprland
0.107994006: [INFO] Using wlroots virtual input protocols
0.107999216: [INFO] Using wlroots protocols for virtual input
0.110213489: [INFO] Using ext-idle-notify-v1 idle inhibition protocol
0.110227479: [INFO] Going to connect to 192.168.50.105 at port 24800

Another a bit weird thing is that the mouse on the secondary monitor now feels off, and even if I am doing quite big mouse movements, it only moves cursor just a tiny bit, which looks like another issue with the geometry. I know that it's very specific problem with very specific environment but maybe somebody will be able to help.

[egrims]

I'm actually having the exact same issue with a very similar layout to yours. I thought I was just losing my mind but thankful to not be the only one I suppose. My monitor configuration is below.

monitor = DP-1, disable
monitor = DP-2, disable
monitor = HDMI-A-1, 1920x1080@60, 4880x0, 1.00, transform, 1
monitor = HDMI-A-2, 2560x1440@144, 5960x0, 1.00

The reason for the further push of the start point instead of 0x0 is due to my configuration changing when I'm working versus not. I've also tried moving the 4880x0 monitor start to 0x0 and the second to 1080x0 and have the same issue. I've also experienced the same mouse movement issues you've commented on. It happens on the rotated monitor and feels like when you have the monitor flipped but the mouse isn't or vice versa but in a much more subtle manner. Hard to explain but there is a definitive difference in the mouse movement.

[r-c-f]

It sounds like it could be an issue with relative versus absolute cursor movement handling on the hyprland side. If you lock synergy/barrier/whatever to the given host (not sure of the default binding but it should be configurable, and is often necessary for games to work) it will switch to relative. Does that improve the situation?

[gac3k]

@r-c-f no, unfortunately doesn't help. The slow cursor issue though isn't the main issue anyway, as I think the root of that issue is also somehow related to the geometry recognition. It seems that by default waynergy is recognizing secondary monitor as primary, and no matter how weird it sounds it seems to use overall geometry for the cursor movements, but cursor itself might only be moved on that particular screen, if I go to the right edge then, it's not going to the actua. And then if I change the workspace in hyprland the cursor is moving as well, but then I can only move it on the other screen and to the host, but no to the secondary display on the client.

I think that actual PR in Hyprland that introduced that issue, is that one, but I might be wrong.
https://github.com/hyprwm/Hyprland/pull/6268/files

BTW. thank you, and great work overall saved me a lot of time :D

[gac3k]

@r-c-f not sure whether it really changes anything, but I decided to debug it a bit, and what I know now is that when mouse_motion is being executed, the move is always calculated relatively to the whole geometry width and height, but only within that specific screen, meaning that if my total geometry is 4520x1920 as it is right now, whenever I am reaching left edge of my primary display it does have an x argument equal to 0 and on the other hand when it's reaching the other end it's 4520, this is also the reason for these odd mouse movements on the secondary display which is rotated vertically, there it also uses these relative calculations but because the difference in geometry is way bigger as the resolution on that screen is 1920x1080 and width is effectively 1080 because it's rotated, it's having these weird mouse movement glitches. Not sure if this is something related to wayland, libeip or something else, but it's definitealy wrong. Do you have any idea what might be the reason?

[r-c-f]

@gac3k The full size should be used in all cases, as the underlying protocol does not allow one to specify a particular screen, only a particular absolute position. This requires the full range, to avoid rounding errors in scaling toward the edges of any given screen. The detection itself also seems to be accurate: the rotated display is detected as 1080x1920, while your other display is located at an X offset of 1080. If this is incorrect, this would be an issue with the compositor that is supplying these incorrect values (hyprland itself, in this case).

This weekend I'll have a go with Hyprland myself, to see if I can get a handle on what is going on.

As a last-ditch troubleshooting effort, you might consider trying the uinput backend. Hyprland will see that as a standard mouse and keyboard; any special protocol handling will be out of the picture.

[gac3k]

@r-c-f yeah, I was trying with uinput backend, as I originally thought an issue might be in some changes to libeip and virtual pointer logic in Hyprland itself, doesn't look like it though. I spent few hours yesterday debugging, which is a bit tricky since I am not a C developer :D

Unfortunately it didn't direct me towards anything that would make a sense really, only thing that I really know now is that the calculation of x and y positions are not properly interpreted no matter of the specified backend (uinput or wlr) and that the interpretation of the x and y positions are always relative to the display that is actively focused, so of course 1080x1920 resolution on the second screen is all right but when I am on that screen, and I am making a significant move with my mouse, it's being recognized as a way bigger number i.e. 2300, and it's not moving the mouse to the edge of that screen or to the primary display, but instead it's moving the cursor to the middle of that display, as in the debug logs it's recognizing the mouse movement properly and the geometry is recognized properly as well (4520 of width, 3440 + 1080) just the actual interpretation is wrong for some really odd reason, as it always only treats the currently focused screen as the only one that exists, and all the geometry is applied only relatively to that particular one.

[gac3k]

@r-c-f I don't know whether you're actually going to take a deeper look into that, but after the longer investigation it has to be something with the latest changes in Hyprland, and introduction of all the new wayland protocol implementations that they did for 0.40 release in the last few weeks, the problem is that there are so many of them that I literally have no idea where to look, and if the problem persists I'll probably have to ditch Hyprland for now till it's fixed.

If you'll have any clue though, please let me know. Thanks :)

[r-c-f]

Due to an unfortunate hardware failure I can't really get around to that immediately, but if you can reproduce the issue with the virtual-pointer client example from https://gitlab.freedesktop.org/wlroots/wlr-clients that would make opening an issue with Hyprland itself much more feasible, to at least see what they'd have to say without requiring too much setup on their part.

Using multiple virtual pointers to allow for per-output control might actually be possible, but will require much more state tracking and geometry compensation for non-rectangular layouts because the synergy protocol itself doesn't support them (and thus testing before I'd be comfortable with it).