With this change, KXcursorTheme will be able to load svg cursors provided
by breeze.
If a cursor theme provides both xcursor cursors and svg cursors, the svg
cursors will be preferred.
At the moment, KXcursorTheme doesn't cache svg render results but it could
do that if it becomes a noticeable issue.
Currently, the embedded cursors have effectively a scale factor of 10.
So they look smooth even though the current maxScale is small. With the
svg cursors, the shake cursor needs to provide more reasonable maxScale
values.
Clients can have valid reasons to change the selection when the
same user action that also caused the selection request
to lose keyboard focus. This is notbaly the case for menus
created from a Plasma panel which itself will not take focus
but when clicking on action it only triggers after the menu
is closed.
This also matches what weston and sway do.
BUG:490803
It just shows "Compositing" in the corner and doesn't block direct scanout.
When direct scanout is active, the "Compositing" text isn't visible anymore.
This is useful for debugging performance or power draw issues.
Makes the outputs we are emitting relative to the output position. This
way if there's an esoteric setup or just more than one output, it won't
just always be relative to the first output.
Signed-off-by: Victoria Fischer <victoria.fischer@mbition.io>
If the application uses a surface with a single-pixel black buffer as a background,
for example behind a video or video game, that surface can be ignored, as the KMS
background is black as well.
With this commit, mpv with --vo=dmabuf-wayland can get direct scanout even if the
aspect ratio of the video and screen don't match, which can result in very significant
power savings
We optionally send some keys to xwayland through the filter when no x11
client has focus. This allows shortcut handling in X11 apps to work.
When kwin is grabbing keys we don't necessarily want X11 to sniff these
keys as things can get out of sync. A key place is the tabbox. The X11
client sill has focus, but xwayland is not active. This means we pass
tab keys to X which then go to application incorrectly.
Part of this patch changes the tabbox filter to not intercept the alt
key release event. This ensures xwayland's concept of pressed modifiers
stays in sync.
BUG: 484992
In some IM backends pre-edit text should be submitted on user interaction, in some it should be discarded.
In TextInputV1 and V2 this was a flag sent to the client along with
the commit string ahead of time.
TextInputV3 does not have a flag for this, so we handle it compositor side.
We flush the text to be committed :
- when we change keyboard focus, before the current client gets wl_keyboard.leave
- when a mouse is pressed in the relevant surface
- when a key is pressed and the InputMethod doesn't have a grab
- when the InputMethod forwards a key to the client
(which includes the InputMethod passing on grabbed keys)
When the tabbox grabs input, the key events won't be sent to the client.
It's not good for a couple of reasons: first, it can fool the client into
repeating a previously pressed key; and the server side and the client
side can be out of sync after the task switcher is dismissed.
In order to handle that properly, this change makes the tabbox reset the
keyboard focus when it's shown or hidden. When the task switcher is
dismissed, an enter event will be sent with the current state of the pressed
keys.
Ideally, the same needs to be done with the pointer focus but it's
challenging to achieve with the current input pipeline design. An input
grab abstraction is needed to handle pointer focus when the task switcher
is active.
This is problematic as it means anything requiring a fixed position
in the chain cannot be added or removed at runtime. This is bad for both
performance and code cleanliness as all code ends up input.cpp rather than
where it semantically belongs.
Remaining users that prepend event filters have the problem of the order
being effectively undefined.
This patch adds a weight attribute to the filter allowing filters to be
installed and removed at runtime whilst maintaining a specific deterministic
order.
Currently the order is defined by an enum based on the filter names.
This gives an easy to read explicit order for anyone reading kwin code, but
it is left cast to an int so we have future flexibility.
This fixes not sending frame callbacks for tablet cursors. And in general
this simplifies the code by removing a level of indirection responsible for
communicating the frame timestamps, the Compositor can tell the CursorSource
the frame time directly.
On X11 we get focus in and out events for normal input and when grabs
change. Kwin's concept of the active window should only follow the
normal focus changing.
Testing done:
Run Xfreerdp and move the pointer outside the window, the cursor
decoration should not change. It should still be the active window.
If the graphics buffer view is null, GraphicsBufferView::image() will
point to a valid memory location but the QImage at that address is going
to be null.
This effect is used to implement the visual bell accessibility feature.
It allows to implement it on Wayland and significantly improve it on X11,
where it's currently rather broken.
It offers two modes:
- Inverting the colors (code is based off the invert effect)
- Flashing a solid color
Make the window caption without suffix available in
the scripting API by adding a `captionNormal` property.
Update the doc for the `caption` property to mention that
`captionNormal` can be used to get the caption without
added suffix, instead of suggesting to call a getter with
a bool param that was dropped in
commit f0652970f4
Date: Sun Aug 20 09:35:15 2017 +0200
Drop boolean parameter from AbstractClient::caption
We return early for screens with physical height reported as ≤ 0mm.
However some extremely dumb screens report a value for their height
greater than zero but absurdly small, causing the scale calculator to
go ballistic. Theoretically this could happen for widths, too.
Let's loosen the detection to flag a physical screen size as invalid if
either its width or height is less than 3mm. There is no screen that
can possibly make sense to exist at this physical size given the angular
resolution of the human eyeball. And if for some reason it does, 100%
scale is fine for it.
BUG: 490777
FIXED-IN: 6.2.0
