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.