https://bugs.kde.org/show_bug.cgi?id=524468
Bug ID: 524468
Summary: Virtual keyboard is always placed on the active
window's screen; add a configurable placement policy
for the input panel
Classification: Plasma
Product: kwin
Version First 6.6.5
Reported In:
Platform: Other
OS: Linux
Status: REPORTED
Severity: wishlist
Priority: NOR
Component: input
Assignee: [email protected]
Reporter: [email protected]
CC: [email protected]
Target Milestone: ---
**Summary**
On a multi-monitor Wayland session the virtual keyboard is always shown on the
screen holding the
active window, and there is no configuration to influence that. On any layout
where the keyboard
overlaps the window being typed into, the user has no recourse: it cannot be
moved, and it cannot
be told to prefer a different screen.
**Steps to reproduce**
1. Wayland session, two or more screens. Enable the virtual keyboard
(System Settings → Virtual Keyboard → Plasma Keyboard).
2. Focus a text field in a window on screen A. The keyboard appears on screen
A.
3. Move that window to screen B while it keeps focus.
**Observed**: the keyboard follows the window to screen B. It is anchored to
the bottom edge of
whichever screen holds the active window, and cannot be dragged, repositioned,
or assigned to a
screen.
**Requested**
A configurable **placement policy** for the input panel, rather than the single
hardcoded
"screen of the active window" behaviour. The specific policy matters less than
the existence of the
setting — the request is for the mechanism and a way to express a preference,
not for any one
behaviour to become the new default.
Policies that would be worth being able to express include:
- current behaviour (screen of the active window) — should remain the default;
- a specific, named output;
- the primary output;
- **the leftmost (or rightmost) output that does *not* contain the active
window** — this is the
case that motivated the report: with two side-by-side screens, put the
keyboard on the other
screen so it never covers what is being typed into.
That last one is offered as a worked example showing the setting needs to
support a *relative,
dynamic* choice and not merely a fixed output — not as a preference that should
be hardlined into
the implementation.
**Why it matters**
- On a touchscreen the keyboard is large, and on a single-screen-height layout
it covers a
substantial part of the window being typed into. A second screen is sitting
idle right next to it.
- **There is no workaround, and this is the part that makes it a hard blocker
rather than an
annoyance.** KWin does not advertise `zwp_virtual_keyboard_manager_v1` or
`zwp_input_method_manager_v2` to clients (67 interfaces advertised; neither
is among them), so a
third-party on-screen keyboard such as `wvkbd` can draw via
`zwlr_layer_shell_v1` but cannot
inject keystrokes. The built-in keyboard is therefore the only functioning
option on this
session, and it is the one that cannot be placed.
- The panel is not an ordinary window, so there is no KWin window rule or
Meta+drag fallback either.
**Environment**
- Plasma / `plasma-keyboard` 6.6.5, Kubuntu, Wayland session, KWin.
- Two 1920x1080 outputs: `DP-1` at `0,0`, `HDMI-A-2` at `1920,0`.
- `plasma-keyboard --help` exposes no geometry or output options; its System
Settings module
exposes only enabled locales, sound, vibration and keyboard navigation;
KWin's configuration
exposes only `VirtualKeyboard` / `VirtualKeyboardEnabled` (on/off).
--
You are receiving this mail because:
You are watching all bug changes.
