Disable plasma-keyboard / kwin virtual keyboard when a physical keyboard is attached?

Development
1

Hey there @espidev and @apol and maybe others from the KWin team (Nico? David?).

Is there a way to inhibit the OSK on kwin on setups where a touch screen is available, but the user connected a physical keyboard? I saw that there’s functionality to detect whether a touch screen is available, and inhibit the OSK on setups where no touch screen is used.

But what about a setup where an external keyboard is connected - can this be detected somehow and then the OSK not show up, like on a non-touch screen?

Lacking that, I wonder how we could potentially implement/workaround this on our application level. I stumbled over src/virtualkeyboard_dbus.h in KWin which sounds promising, but looking at qdbus | grep -i keyboard I only find org.kde.keyboard but not the org.kde.kwin.VirtualKeyboard interface. The former (org.kde.keyboard) gives access to keyboard layouts, but not the enabled property which sounds like what I would like to set to false in the above setup?

Thanks!

2

There is Configurable Virtual Keyboard behavior (!8592) · Merge requests · Plasma / KWin · GitLab ongoing.

1 Like
3

This is great, thanks! I’ll keep an eye on that one.

I’d still be interested to learn how to access the org.kde.kwin.VirtualKeyboard interface via dbus as a potential way to workaround this.

4

It’s a bit of a mess though. It’s been proven nearly impossible to detect keyboards.

There’s many devices that will register themselves as full keyboards even though they’re not (headsets, mice, power buttons come to mind). That’s why we decided to go by if it’s interacted with touch vs it’s interacted with a mouse.

5

Right, agreed. Which is why I was looking for a programmatic way to toggle OSK on/off and putting this choice into the hand of the user via some application settings button. Is that possible? Without the DBUS interface, I wouldn’t know how?

Or are you saying: this should not be needed, as focus-via-touch is handled differently to focus-via-mouse/keyboard already, and thus the user should not need to do anything at all anyhow and it Just Works™?

6

qdbus without arguments will list D-Bus (service) names, not interfaces.

Given its name I would guess that it is the interface of an object of KWin.

Like org.kde.KWin.VirtualDesktopManager on the /VirtualDesktopManager object on the org.kde.KWin name/connection

7

Right. I also tried to look around in qdbusviewer but cannot find that interface anywhere. It’s certainly not in the VirtualDesktopManager. I would expect there to be a VirtualKeyboard entry on the top, but there isn’t:

```

qdbus org.kde.KWin
/
/ColorPicker
/Compositor
/Effects
/FTrace
/KWin
/Plugins
/Scripting
/Session
/VirtualDesktopManager
/WindowsRunner
/org
/org/kde
/org/kde/KWin
/org/kde/KWin/BlendChanges
/org/kde/KWin/Effect
/org/kde/KWin/Effect/OutputLocator1
/org/kde/KWin/Effect/SystemBell1
/org/kde/KWin/Effect/WindowView1
/org/kde/KWin/HighlightWindow
/org/kde/KWin/NightLight
/org/kde/KWin/ScreenShot2
```

8

Right.

I was just using it as an example of an interface that does not directly correspond to a D-Bus connection name and would thus not show up in a simple grep on qdbus’ output :slight_smile: