scuffed cursor with transformed secondary display #7412
Comments
|
post hyprctl monitors likely that logic coordinates overlap I should make a warning pop up in those cases |
|
odd indeed, have you tried not using negative offsets? |
|
with this i still have the issue: |
|
even with this i still have an issue. it's like DP-2's cursor logic is tied to DP-1 as soon as I apply a transform monitor=DP-1,preferred,auto,1 |
|
really odd... for the sake of testing, what if you put one at 0x0 another at 5000x5000 and the third at 10000x10000 |
|
doesn't work. well, it kinda fixes one problem. the two monitors no longer share cursor movement, but monitor i know nothing about the inner workings of hyprland but i'm guessing the transform logic applies the transform to the display canvas and then applies the transform to the cursor matrix (or whatever it's called) and there's a bug in the code that makes it select the cursor matrix of the primary monitor instead of the monitor that's being transformed. |
|
at this point I wish I could just mount the monitor the right way up, but unfortunately Samsung was really silly and put the vesa mount on the top edge of that monitor rather than in the middle, so it's not physically possible |
|
OK so this bug is new in version 42. I installed version 41 to test and I have no such bug with my cursor. I hope this can be fixed in a future update |
|
can you bisect then |
|
@vaxerski Thank you for the suggestion to bisect. However, I've discovered some additional information that changes the situation:
Given these points, it seems the bug is specifically related to the new renderer implementation. Since the new renderer was added all at once, a bisect between 0.41 and 0.42 won't be effective in pinpointing the exact cause of the bug. Perhaps I could test any experimental fixes or tweaks to the new renderer code if you have suspicions about what might be causing the issue? I'm happy to assist further in any way that would be most useful for debugging this issue. |
|
can you just bisect with git to find the exact commit https://wiki.hyprland.org/Crashes-and-Bugs/#bisecting-an-issue |
|
OK interesting development, turns out legacy renderer has the issue as well. I will bisect and find the problem |
@vaxerski ok I found the first bad commit: |
|
here's my bisect log if that helps at all |
|
that doesn't really make sense though because I believe that the line changed in that commit was reverted in a later commit... so I'm running bisect again |
|
I just ran bisect again and it pointed to the exact same commit |
|
dafoq |
|
yeah dafoq! any ideas how we could resolve this? i'm using 0.41.0 for now and it's working great but I am loving hyprland and don't want to be left behind. |
|
it's possible that the real bad commit is 016da23? |
|
could be, no clue tho |
Problematic Commit@vaxerski I can confirm that the issue is present in I think that this suggests that it's a bug related to either Aquamarine or how Aquamarine interfaces with Hyprland. Do you have any idea how we could fix this? I thought if I used legacy renderer in compilation I could use wlroots instead of Aquamarine. Am I mistaken? Edit: ExperimentsI decided to conduct some experiments on 0.42.0, which might help pinpoint the issue. Experiment 1: ScalingI thought that the cursor boundaries were matching the primary monitor so I thought a workaround could either be to set the scaling of the buggy monitor to 1.5x to match 2560x1440. Unfortunately, even scaled at 1.5x, the cursor boundary is much smaller than the visible screen canvas. Experiment 2: ResolutionI tried configuring the monitor to be 2560x1440 so that both monitors were the same resolution. Unfortunately the cursor boundaries are still smaller than the visible screen area. Experiment 3: Single-Monitor OnlyI tried disabling the other two monitors, (using Experiment 4: Different TransformI tried a different transform: this time I tried rotating the monitor 90 degrees in my Hyprland.conf. Unfortunately this did not fix the issue. Interestingly, the full vertical resolution of the monitor was available, only the width had a smaller cursor canvas. Experiment 5: Disabled TransformI tried removing the transform. With transform disabled, the cursor behaves as expected. HypothesisI think the issue lies where Aquamarine handles its transforms. |
|
I really doubt it's a problem in aq, I'd bet on some transform oopsie in hl that happened in the transition |
|
Ahh, I tried having a look through the commit to find the relevant code for the transform but I'm a bit lost |
Hi @vaxerski i know you've probably got a million issues to be thinking about right now but I was wondering if you had any more thoughts about this issue? I am eager to help in any way I can |
|
no clue, this is just weird |
|
I'm seeing the same issue with a 2-display setup. I can confirm that the problem started when I moved from 0.41 to 0.42, when aquamarine was first pulled in as a dependency. I have one vertical display, and one horizontal display to the right of it. An interesting bit of behavior is that when I move the mouse left, to the vertical display, the "bugged" mouse on the right display snaps to the top left corner. And then when an event occurs that changes the cursor (e.g from pointer to hand), the mouse then snaps down on the right display to match the Y coordinate on the left display. The position does not change until the cursor changes. |
|
I have this issue on Hyprland 0.43 using amdgpu driver. I did not have this issue on 0.42 with nvidia prop driver. Exact same config used for both. Will investigate the code when I have time. |
|
Confirmed 016da23 is first bad commit. Chonky one so this will be fun... |
|
Found something related to the issue... The reason why nvidia was fine was because it was using software cursor. So I tried using "env WLR_NO_HARDWARE_CURSORS=1 Hyprland" which only partially disables hardware cursors. The function CPointerManager::updateCursorBackend() still consider the cursor to be hardware. Hyprland/src/managers/PointerManager.cpp Line 318 in d35e70a Returns false and so the cursor->hardwareFailed is set to false. So now the cursor is a software cursor but is handled as a hardware one. So forcing cursor->hardwareFailed = true fixes the original warping issue, obviously because it is using a full software cursor. However there are still other issues where the checks are obviously wrong. Moving the mouse back and forward between the 2 monitors results in the cursor randomly being drawn as a hardware cursor. |
|
well yeah, something in the hw cursor xforms is wrong imo |
|
Not sure if the variable is only for NVIDIA or something. But the wiki says WLR_NO_HARDWARE_CURSORS is deprecated, when it appears to be removed (for amdgpu at least). Setting Works as expected and resolves the warping issue. I will look more into the actual HW cursor side later. It does seem strange though, that the cursor when set to -1337, -420 warps to 0, 0 instead. And it is also very strange that the actual warp is caused by mousing over window decorations/entering exiting new windows. I did test and it never actually considers that the cursor has re-entered the glitching monitor. So there has to be a case where a check is updating all mice positions regardless of bounds.
Is there not someway to just hide the mouse on the second monitor other than warping it off screen? No idea if that would just be a band aid for this kind of issue though. |
|
band-aid cuz the coords would be wrong still no? |
Yes, I am not really sure if it would matter or not as I haven't looked into how clicks/focus and such would be affected on the glitched/non focused monitor. If clicks/focus are ignored on the non focused monitor then it wouldn't matter since when the mouse re-entered the monitor its position would be updated anyway. And if refocused via keyboard the mouse would just be warped. The mouse can only slide along the closest edge to the currently focused monitor (so only x or y are updated on the glitched cursor not both), so I would guess it might only have some affect if a floating window was at the edge, or no margins were set? Or maybe with some random 3/4 monitor layouts where you could arrange them in a crazy wind mill formation or something. |
|
OK, figured out what is going on. Hyprland/src/managers/PointerManager.cpp Lines 313 to 330 in e74efd8 This function is called whenever the mouse transisitions/moves over a decoration etc. That sets the mouse position for all pointers, but there is only a single pointer position so all pointers end up getting moved. Hyprland/src/managers/PointerManager.hpp Line 155 in e74efd8 Then it checks the cursor image and sets it, again for all cursors resulting in the bonus mouse cursor getting a new look. Since the actual position of the mouse pointer on the second monitor is never tracked you could just add a hide/show when a cursor leaves/enters and this issue would be solved. The attemptHardwareCursor function should also probably only update positions/images of new pointers, or when some actual setting has changed like the hyprland.conf disable hardware cursors. |
that's doable. |
|
see #7806 |
|
@drammelt do your findings also concern the issue where the cursor boundaries are smaller on the transformed display, or only the issue which creates multiple cursors |
Regression?
No
System Info and Version
System/Version info
Description
How to reproduce
have two monitors with different resolutions
transform one of them to be upside down
move cursor
???
profit
Crash reports, logs, images, videos
I have a video on youtube that demonstrates the issue:
https://www.youtube.com/watch?v=t_Gvd_6j1uc
The text was updated successfully, but these errors were encountered: