Avoids accidentally triggering an edge when dragging a scroll bar or
text selection all the way to the screen edge.
Special case for moving windows, as you want to be able to drag
a window to an edge to switch virtual desktops.
Compositor::scheduleRepaint() needs some knowledge of the composited
layers, which would be great to get rid of to split wayland and x11
compositing bits.
Display the window caption and class name (safe for the icon) like is done
with the windows themselves.
Eases debugging properties, such as "transientFor".
Otherwise, when using Alt as modifier for moving windows, the tabbox window
cannot be clicked because Alt is held down during Alt+Tab, which would try
to initiate a window move but the window isn't actually movable, so ends up
doing nothing.
It also allows to interact with Plasma popups, which are also immovable,
while the modified key is pressed.
Currently when we move the mouse the one render loop triggers a repaint.
When the cursor layer needs a new update we end up in the compositor
repainting the main content.
Even though painting should mostly no-op it still goes through all
existing items and effects to collect damage, still potentially making
the GL context current which could stall. A waste when we know we
haven't got anything to do. It's enough to cause noticable mouse lag on
some hardware.
Co-authored-by: Vlad Zahorodnii <vlad.zahorodnii@kde.org>
It never belonged in the OutputBackend, but we also didn't have a better
place when the relevant code had been added.
With the introduction of graphics buffer allocators, it's no longer the
case.
Some wheels might send fewer or more than 120 fractions per step.
In order to always register a discrete step, we count these as a step
already at half(120/2) of one mouse wheel step in stepping mode.
The timer resets the initial value of the step because the mouse
can switch between free spin and stepping mode.
When transitioning from free spin to stepping mode,
the mouse calibrates its wheel position to the starting point
and generates some fractions.
As a result, our starting position can appear far from the zero point,
potentially causing us to count two(or zero) steps instead of one.
Additionally, the compositor might start when the mouse is in
free spin mode(or the mouse could be connected in free spin mode),
leading to the same issue.
https://gitlab.freedesktop.org/libinput/libinput/-/issues/814
Xaver Hugl