5 ms·

Does it have hardware cursor support yet? My last experience was unusable for mouse-centric use, like treacle compared to Windows or X11. Windows has proven you

Does it have hardware cursor support yet? My last experience was unusable for mouse-centric use, like treacle compared to Windows or X11. Windows has proven you can have all these nice things in a low latency environment

lulitao1997 3y ago
KDE, wlroots's hardware cursor are broken right now https://bugs.kde.org/show_bug.cgi?id=452117 https://bugs.kde.org/show_bug.cgi?id=452117 https://github.com/swaywm/sway/issues/4763 https://github.com/swaywm/sway/issues/4763 sad to see another linux api design failure
colordrops 3y ago
You must have something wrong with your setup. I'm not seeing any issues with the cursor on my two older laptops.
- kiririn 3y ago
  You probably won’t notice it on a laptop display, especially not if using the touchpad
  - colordrops 3y ago
    I've got 2 4k screens attached to my laptop.
  - kaba0 3y ago
    There is nothing to notice as it is FUD.
worthless-trash 3y ago
You've just started me down a rabbit hole of reading, I'm so confused now that there is even the idea of a 'hardware cursor' of an idea so clearly implemented in software.
- kiririn 3y ago
  The cursor has to be rendered outside the normal graphics pipeline to feel responsive. To match it you would need to render the desktop at 2x or so the mouse polling rate (like 2000 fps or so for a good mouse)
  - whizzter 3y ago
    1: Mouse polling rate needs to be higher than rendering rate and and NOT the other way around. The higher the better because it guarantees that there is less of a delay between the latest sample from the mouse and the time the mouse cursor is rendered. (There are plenty of articles about how to minimize latency for fighting games by going from triple to double buffering and sampling just at the start of the "double" rendering phase) 2: Hardware cursors of old were akin to sprite hardware on consoles, here the hardware did compositing (or pre-compositing) operations on a per-line basis just before sending the frame contents to the display. On platforms like the C64 you only had 8 sprites in hardware but if you tuned your code to race the display processor you could have more by updating the sprite positions to lines below (so still limited to 8 per line but non-overlapped it was possible to have more). 3: Looking at WDDM there seems to be 2 ways cursors could be handled, either Windows uses overlays under the hood for the cursor (if overlays support operations like alpha-blending automatically) or the compositor pre-empts the GPU when it's time for an display update, modern GPU's are fast enough that compositing operations should be able to finish quickly enough to meet frame-times but if done off-screen for safety it could be producing an extra frame of latency. Regardless the GPUs should be fast enough today to make it happen whenever needed even if not using the classic ways.
    - kiririn 3y ago
      Right but say the mouse is a constant 1000hz. To get the most recent sample on the screen as quickly as possible you either need the entire rendering pipeline to run ridiculously fast (the 2000 fps example), render just in time before vsync with impossible accuracy, or bypass as many clocks and buffers as possible and blit the cursor with hardware magic. There’s a reason it’s still done this way after so many years of advancement
hackernudes 3y ago
Each implementation of Wayland is its own beast (called a "compositor"). Sure there is a libwayland they all share, but all the implementation details are up to the compositor. The idea of a cursor being hardware or software is not a fundamental part of Wayland as far as I can tell. Hardware cursors are supported in wlroots.
Jasper_ 3y ago
All Wayland compositors I am aware of use KMS planes to push a hardware cursor plane. It should work fine.
kaba0 3y ago
Literally every major compositor had it since forever.

lulitao1997 3y ago

KDE, wlroots's hardware cursor are broken right now https://bugs.kde.org/show_bug.cgi?id=452117 https://bugs.kde.org/show_bug.cgi?id=452117 https://github.com/swaywm/sway/issues/4763 https://github.com/swaywm/sway/issues/4763 sad to see another linux api design failure

colordrops 3y ago

You must have something wrong with your setup. I'm not seeing any issues with the cursor on my two older laptops.

kiririn 3y ago
You probably won’t notice it on a laptop display, especially not if using the touchpad
- colordrops 3y ago
  I've got 2 4k screens attached to my laptop.
- kaba0 3y ago
  There is nothing to notice as it is FUD.

worthless-trash 3y ago

You've just started me down a rabbit hole of reading, I'm so confused now that there is even the idea of a 'hardware cursor' of an idea so clearly implemented in software.

kiririn 3y ago
The cursor has to be rendered outside the normal graphics pipeline to feel responsive. To match it you would need to render the desktop at 2x or so the mouse polling rate (like 2000 fps or so for a good mouse)
- whizzter 3y ago
  1: Mouse polling rate needs to be higher than rendering rate and and NOT the other way around. The higher the better because it guarantees that there is less of a delay between the latest sample from the mouse and the time the mouse cursor is rendered. (There are plenty of articles about how to minimize latency for fighting games by going from triple to double buffering and sampling just at the start of the "double" rendering phase) 2: Hardware cursors of old were akin to sprite hardware on consoles, here the hardware did compositing (or pre-compositing) operations on a per-line basis just before sending the frame contents to the display. On platforms like the C64 you only had 8 sprites in hardware but if you tuned your code to race the display processor you could have more by updating the sprite positions to lines below (so still limited to 8 per line but non-overlapped it was possible to have more). 3: Looking at WDDM there seems to be 2 ways cursors could be handled, either Windows uses overlays under the hood for the cursor (if overlays support operations like alpha-blending automatically) or the compositor pre-empts the GPU when it's time for an display update, modern GPU's are fast enough that compositing operations should be able to finish quickly enough to meet frame-times but if done off-screen for safety it could be producing an extra frame of latency. Regardless the GPUs should be fast enough today to make it happen whenever needed even if not using the classic ways.
  - kiririn 3y ago
    Right but say the mouse is a constant 1000hz. To get the most recent sample on the screen as quickly as possible you either need the entire rendering pipeline to run ridiculously fast (the 2000 fps example), render just in time before vsync with impossible accuracy, or bypass as many clocks and buffers as possible and blit the cursor with hardware magic. There’s a reason it’s still done this way after so many years of advancement

hackernudes 3y ago

Each implementation of Wayland is its own beast (called a "compositor"). Sure there is a libwayland they all share, but all the implementation details are up to the compositor. The idea of a cursor being hardware or software is not a fundamental part of Wayland as far as I can tell. Hardware cursors are supported in wlroots.

Jasper_ 3y ago

All Wayland compositors I am aware of use KMS planes to push a hardware cursor plane. It should work fine.

kaba0 3y ago

Literally every major compositor had it since forever.