Bug 478560

This appears to work for me with today's git master: Shift+arrow keys move the box by single pixels, not by two pixels.

(In reply to Nate Graham from comment #1)
> This appears to work for me with today's git master: Shift+arrow keys move
> the box by single pixels, not by two pixels.

Use the mouse, not arrow keys.

I don't understand what you mean, sorry. Mice are physical devices that don't move by pixels. Do you mean the on-screen pointer? If so, as far as I can tell, I can move the pointer by individual pixels on Wayland with 200% scale.

Yes, I mean the mouse cursor. If you want to test the behavior with a different app, try KRuler.

I should also mention that I have a two monitor setup with 1x scale and 2x scale screens.

"Spectacle" is probably the wrong product for this bug report. This seems like a more general wayland issue, but I initially filed it here because it was a problem for Spectacle.

Unless I'm completely blind or misunderstanding the issue, I can't reproduce the inability to move the pointer by physical pixels (rather than logical pixels) on my 200% scale screen, either along or when plugged into an external 1080p screen set to 100% scale.

Created attachment 164797 [details]
KRuler on 2x scale screen (2 monitors, 1x and 2x) with issue

Maybe this will help you see?

From what I can tell, that's a KRuler bug. When I move my pointer along the ruler as indicated in your screenshot, I do indeed see that the *label* and the red line change by 2px increments, but the pointer appears to be able to move to individual pixel positions finer than what the label and red line show. Because the label and the red line are limited to logical pixels rather than physical pixels, I'm capable of moving the pointer to positions that do not cause the label and the red line to update. I have to move the pointer really really slowly and precisely to see it and shove my face right up against the screen, but I do see it?

Can you confirm that?

Created attachment 164799 [details]
same, but with even slower movement

It's not a KRuler bug. My mouse cursor and the positions Qt is able to detect really are skipping 2 physical pixels a time, so you can't fix the issue in KRuler or Spectacle. Qt's mouse positions are scaled to the device pixel ratio (e.g., the bottom right corner of a 4K@2x screen is considered 1920,1080), but Qt supports fractional mouse positions on X11 when the UI scale is set to 2x.

That is strange, I'm seeing something different.

Anyway, clearly this isn't a Spectacle issue so I'm going to move it to KWin.

Mouse moves in the logical pixels. So it's intentional.

If mouse moves in the device pixels, its speed would be affected by the scale factor. For example, if you use x2 scale factor, the UI is going to be enlarged twice, but the pointer speed will be reduced twice, in other words you would need to move the mouse a lot more on such a scaled output. One way to compensate for that would be to increase the pointer speed in system settings, but then it's going to make the pointer too fast on x1 outputs.

Also, FTR kwin sends motion events with fractional parts (in logical pixels), so if you have a monitor with x2 scale factor, and receive a motion event with 1.5 delta, then it means that the pointer moved 3 px in device pixels. Make sure that spectacle doesn't round anything on its side. If you've confirmed that spectacle receives motion events without fractional part, then it's probably a qtwayland bug.

Also also, I checked that kwin sends motion events with fractional parts on my machine both with a regular mouse and a touchpad

(In reply to Vlad Zahorodnii from comment #12)
> One way to compensate for that would be to increase the pointer speed in system settings, but then it's going to make the pointer too fast on x1 outputs.

Could the mouse speed be scaled by the scale factor only on the scaled screens?

(In reply to Vlad Zahorodnii from comment #13)
> If you've confirmed that spectacle receives motion events without fractional part, then it's probably a qtwayland bug.

Yes, I have confirmed that. I'm even using the new Qt 6 QEvent based APIs that give QPointFs, but still don't get a fractional part. I suppose I'll have to file a bug with Qt Wayland.

Created attachment 164838 [details]
fractional positions in gammaray

> Could the mouse speed be scaled by the scale factor only on the scaled screens?

It could, but it would make input dispatching code more complex.

QtWayland forwards fractional mouse events, see my screenshot and I also confirmed via qDebug() in spectacle

Created attachment 164839 [details]
Noah's lack of fractional positions in GammaRay

(In reply to David Redondo from comment #18)
> QtWayland forwards fractional mouse events, see my screenshot and I also
> confirmed via qDebug() in spectacle

I don't get fractional positions in GammaRay or qDebug (already checked qDebug before posting this report).

I tried unplugging my 2nd screen and setting my main screen to 2x and setting both monitors to 2x. Neither change made a difference.

 Clearly I still have a bug, but we don't know where it comes from. Can we reopen this and move it somewhere out of KWin (if necessary) so that it can be tracked until we find the real source of the problem? I don't think we can consider this intentional behavior if the other people here don't have this problem. I could do it myself, but I'm not sure where the bug should go.

Actually, could it be the mouse driver that's sending non-fractional positions? I'm using libinput for all connected pointing devices, but I just noticed that I can move pixel-by-pixel when I use my touchpad. I've been using my Logitech MX Master 3 this whole time and I can't move that pixel-by-pixel.