hide_cursor when-typing disables mouse on keyboard input while gaming

[NomisIV]

• Sway Version: 1.6

• Debug Log: gist of sway.log

• Description:

  • Play a video game while hide_cursor set to when-typing
  • Press at least one mouse button and move the mouse (e.g. aim / shoot and look around)
  • Still pressing and moving the mouse, press a key on the keyboard (e.g. WASD for evading enemies)
  • The mouse now stops moving, and you can't look around until you release the key.

I suspect this has to do with XWayland, since I can't reproduce the bug in sway itself.

I am not alone with this issue: reddit post

[lelgenio]

This is not exclusive to XWaylnd, a much simpler way to test is with xev/wev:

1. Hold a mouse button
2. Move mouse around and see it logged
3. Click any keyboard key
4. Move mouse around and don't see it logged

[Firgen]

This doesn't affect only gaming, but also gimp, blender, and presumably other image editors, 3d modelling programs etc. For example in gimp when selecting an area and trying to zoom in/out using ctrl + mouse wheel at the same time.

[Xyene]

Could you run swaymsg -t get_inputs and paste the bits that relate to the mouse? There should be more than one if the mouse is identifying as both a mouse and keyboard.

[Firgen]

Input device: Logitech G102 Prodigy Gaming Mouse Keyboard
  Type: Mouse
  Identifier: 1133:49284:Logitech_G102_Prodigy_Gaming_Mouse_Keyboard
  Product ID: 49284
  Vendor ID: 1133
  Libinput Send Events: enabled

Input device: Logitech G102 Prodigy Gaming Mouse Keyboard
  Type: Keyboard
  Identifier: 1133:49284:Logitech_G102_Prodigy_Gaming_Mouse_Keyboard
  Product ID: 49284
  Vendor ID: 1133
  Active Keyboard Layout: English (US)
  Libinput Send Events: enabled

Input device: Logitech G102 Prodigy Gaming Mouse
  Type: Mouse
  Identifier: 1133:49284:Logitech_G102_Prodigy_Gaming_Mouse
  Product ID: 49284
  Vendor ID: 1133
  Libinput Send Events: enabled

[Firgen]

I just tested it with a mouse that only registers as a mouse device and it also happens.

[Xyene]

Oh, I understand now, but I'm not sure what we can do about this?

Deferring disabling the mouse to when all mouse keys are released seems reasonable, to avoid the OP's issue, but won't help if you're pressing Ctrl before scrolling. We could special-case modifiers from not triggering dwt, but at that point the casing seems arbitrary...

What do other compositors/OSes do here?

[Firgen]

but won't help if you're pressing Ctrl before scrolling

I think it would; to clarify the problem: when selecting an area (mouse button being pressed down), then pressing ctrl (or any other key) makes the selection stop responding.

So I believe not disabling the cursor while a mouse button is pressed would solve the issue.

What do other compositors/OSes do here?

I only tried Xorg window managers with xbanish. I haven't noticed any issues with it.

[progandy]

As i understand it, xbanish simply hides the cursor image, but the cursor itself is still functional. Any mouse event will restore the image. Maybe that could be improved to prevent hiding while a mouse button is pressed as well.

[igorlfs]

I noticed a similar bug when hovering with hide_cursor enabled: if something is being previewed, it'll disappear with the cursor. I also think xbanish's approach might be more practical.

[Zeioth]

I can reproduce. See #7383 and #7399.

[elcste]

FWIW, MacOS, which has this feature built-in (and not able to be disabled that I know of), the mouse also stays active when the cursor hides.

[Zeioth]

Someone just reported on reddit that removing the line

wlr_seat_pointer_notify_clear_focus(cursor->seat->wlr_seat);

Fron the method cursor_hide() seems to fix it.
Needs to be tested.

Patch: lelgenio@b21dc48
Reddit post: https://www.reddit.com/r/swaywm/comments/10kevqd/comment/j5tqv7o/?context=3

[bl4ckb0ne]

Could you open a pull request with the patch?

[emersion]

We've discussed this before and decided against it.

[bl4ckb0ne]

Why, could you link the discussion pls?

[emersion]

Mostly #4145, #3967. IIRC there was another issue with more discussion but I can't find it…

[sochotnicky]

I was hitting this and it took me a while to realize what was going on and find this issue.

Perhaps we could put a warning into the manpage at least? Basically just mention that there can be side-effects with some software (games, inkscape etc). I can try and prep some MR

[lbatalha]

I have a slightly different problem

With hide_cursor when-typing enable, while holding a mouse button, if I press any keyboard key once, and then release the mouse button, the mouse will be locked in the state of being pressed, instead of cancelling the drag operation as reported in other issues above

This happens on any window I've tried, from terminals, browsers, looking-glass, etc...

A quick way to reproduce is to hold left mouse click to select some text, tap CTRL, let go of the left mouse button and move the mouse around, it will keep selecting text.
To reset the state, clicking any mouse button or changing focus will do (but not keyboard typing).

I have not tested #7574 yet, has anyone seen this specific behavior?