A target mobile DPI of 135 is rather low and results in excessively
large scale factors, so everything is too big.. Let's raise it a
little bit to improve the default level of information density on
these devices that are designed to be held close to the face.
This has the effect of changing the calculated default scale factor for
the following devices:
| Device | Device DPI | Old scale factor | New scale factor |
| ---------- | ---------- | ---------------- | ---------------- |
| Steam Deck | 204 | 1.5 | 1.25 |
| PinePhone | 268 | 2.0 | 1.75 |
| OnePlus | 388 | 3.0 | 2.5 |
Devices are taken from the autotest data found at
https://invent.kde.org/plasma/kscreen/-/blob/master/tests/kded/configs/AutogeneratedMobileScreenScales.json
The autohidden panels "blink" because this effect animates their opacity.
The dock windows are animated because, as the comment says, the old effect
animated almost every window.
Conceptually, animating docks doesn't align with the purpose of this effect.
Wayland has a design philosophy of prohibiting keyloggers, which is
sane. However X11 did not, and a lot of X11 apps were developed with the
expectation of being able to sniff keyboard events to handle global
shortcuts. When such apps are run in a Wayland session under XWayland,
these features break.
Historically we have prohibited this in the name of security. In Plasma
5.27, we gave users a KCM they can use to choose their preferred balance
of security and unbreaking XWayland apps with global shortcuts. But we
still defaulted to total 100% security, at the expense of breaking these
apps by default.
However today we have a compromise that unbreaks them 99% of the time
while not meaningfully reducing security: we can have KWin only prohibit
XWayland apps from reading alphanumeric key events that don't have a
modifier key pressed at the same time. This still prevents those apps
from acting as keyloggers and reading your password or all the text you
type, but does allow those apps that have a legitimate need to read key
events for global shortcuts do so, because global shortcuts will involve
modifier keys being held down.
Due to the way the security modes work, making this change will also
allow XWayland apps to read non-alphanumeric keystrokes without any
modifiers being held down, but that's also fine for security since you
can't use any of those keys to type text or passwords.
NET::OnAllDesktops is a special desktop number (-1), desktopForX11Id will not return a desktop for it
When all desktops are requested pass an empty desktop list, the following code will handle it appropriately
BUG: 482670
We need to re-arrange layer shell surfaces, compute new struts and adjust
the windows in a single step.
Workspace::updateClientArea() is the best candidate for that, so this change
repurposes that function from computing work areas to a generic relayouting
function.
CCBUG: 482361
When the output layout changes, the Workspace is going to update the
struts and then go through every window and see whether it should be
moved or resized.
On the other hand, the layer shell windows react to output changes on
a timer. Furthermore, it's not synchronized with the workspace rearranging
the managed windows. It means that when Workspace::desktopResized() runs,
the panel struts can be slightly outdated, i.e.
- An output layout change occurs
- Workspace::desktopResized() is called but the struts can be wrong
- some time later, LayerShellV1Integration::rearrange is called, it
fixes layer shell window geometries and struts
- after the layer shell integration has finished rearranging the
layer shell windows, it calls Workspace::desktopResized(), but the
damage had already been caused
With the proposed change, the Workspace and the LayerShellV1Integration
will rearrange the windows in sync.
CCBUG: 482361
The behavior between direct scanout and normal presentation being different is an
implementation detail of DrmPipeline, the output layers shouldn't need to care
Multi monitor setups with 4K screens are not uncommon and one of the
annoyances associated with such setups is that you lose the track
of the cursor sometimes. It's natural to shake the cursor in such
occasions.
This change enables the shake cursor effect to improve the desktop
experience. One potential risk associated with doing so is that the cursor
can be magnified in some undesired situations. It is true. But we took a
great precaution of that and added some heuristics to avoid triggering the
effect in such cases given all the data we have available.
Only store one history item for movement in the same direction.
With this optimization I measure m_history.size() <= 15 for all kinds of
movements, including back and forth, and circular.
The current behavior is that the cursor size follows how hard or fast
the cursor is shaken. While this looks fancy, given the purpose of this
plugin, it should be possible to magnify the cursor as easy as possible
without interfering or false triggering.
This change implements a sort of a compromise. When the cursor is shaken
for the first time, the cursor is magnified by some certain scale factor.
Then every next shake magnifies the cursor further by a smaller amount.
When using fractional scaling, an xwayland window's client geometry can
have some fractional part. When that's the case, .toRect() can shrink the
client geometry or extruding the decoration borders inside the surface.
On the other hand, the pointer is going to be confined as long as the
wl_surface is focused. If the focus jumps to the decoration, the pointer
constraint is going to be broken. Unfortunately, the focus can shift to
the decoration even though the wl_surface is still focused because of the
pesky .toRect().
BUG: 482448
CCBUG: 477124
