KDE on handhelds: What does it take? What is missing? Let's make it Konsistent.

I’m reposting this here from reddit. Either it’s on me and my posts aren’t good, or reddit isn’t the right environment for these thoughts. I think it fits the brainstorm section. If this kind of content is disliked, I’d appreciate some guidance on why.

Anyways, I’m interested in discussing these ideas, and seeing if other people have done similar setups. With the rise of the Steam Deck and similar computers, it makes sense to me to treat them as their own hardware class. Plasma Bigscreen for TV, Plasma mobile for phones, and maybe a Plasma “Portable” in the future. I’m aware that it’s a niche use case for now.


Linux handhelds like the Steam Deck (besides from the clunkiness) are perfect gadgets for tech-nerds on the go. After more than 10 years I gave KDE another chance and it has been amazing to see how far it has come. The amount of features and customisability on a modern pocket hardware induces a feeling of freedom and control that I had been missing since the iPhone jailbreak era.

Desktop OSs are efficient to use and powerful, but built around keyboard and mouse and big screens; mobile OSs are great for small screens with touch input but aren’t really multi-taskable and efficient. The steam deck fits both categories, but neither well.

The goal is to have an self-sufficient device without reliance on periphery. Here is what I think is needed for a good experience:

Window Management

  • Tiling WM: like on a tablet, moving multiple tiny windows around a screen is no fun. Having one or two windows fill all available space is the way to go. :white_check_mark: solved by Krohnkite KWin script

  • Vertical Dynamic Desktops: A newly opened app should also create a new desktop and be placed there. Unneeded desktops should be automatically removed. For wide screens, cycling desktops vertically around the short edge is faster and more intuitive. :white_check_mark: solved by KWin script

  • KDE Configurations: Small scale factor (Steam Deck 1.1) makes it less touch friendly but more multitaskable. Focus follows mouse means less clicks. Retractable dock, Desktop switcher, Taskbar incl. window menus and activity bar, make use of all four edges and maximize usable screen space. :white_check_mark: configurable via settings

  • Activities: are super powerful. I can have one activity to create music, one for developing, one for gaming etc. When using ~1 window per desktop it makes even more sense, to cluster desktops into activities

Input

  • Shortcuts: To be efficient, shortcuts and modifier keys via physical buttons are essential. Ctrl-Click in the browser, switching desktops, opening, moving, closing applications, copy, paste, undo, redo. :warning: partly done by Steam

  • Application shortcuts: Firefox, Dolphin, Konsole, Kdenlive profit from different sets of frequent shortcut actions. Easily covered by a full keyboard, harder to do with a handful of buttons. :warning: solution needed

  • Touch: Touch and multi-touch gestures work great :white_check_mark:

  • Mouse: Handhelds usually have joysticks or trackpads. :white_check_mark: standard sticks can be easily mapped to mouse input. :warning: the Deck’s trackpads need translation software (currently steam).

  • Text Input: :white_check_mark: Multiple on-screen keyboards exist and are being improved

  • Voice Input: :white_check_mark: works great even outside using builtin microphones, a noise filter, and software like OpenWhisper and ydotool.

Authentication

  • Sudo passwords: are a bottleneck, since they should be set for security reasons but then require cumbersome input via OSK. A custom PAM module could allow controller button combinations to act as a PIN, in addition to the normal password.

  • Polkit dialogs: GUI applications requesting elevated privileges face the same issue. A custom polkit agent could reuse the same controller PIN flow, replacing the default polkit agent.

  • Lock screen: Similar story. Once on the lock screen, there is no way of entering without an OSK :warning:. A custom kscreenlocker QML theme could map controller inputs to a PIN.

Experimental

  • Spatial A11y Navigation: To reduce the need for mouse input and trackpads all along, I thought it could be interesting to move between elements via joystick. By leveraging the accessibility APIs, retrieving all element trees and compressing them to a 2d map of focusable non-occluded elements the joystick could be used to aim and jump to different elements on screen. This should create a very intuitive handling, but is tricky to implement.

  • (Not sure if there is any real use: the gyros could be used to control a parallax effect and make the desktop appear 2.5d)

Is anyone else using KDE on their handheld and is trying to tweak it? What are your thoughts? Are there problems or solutions I have missed?

If you want to see some of these ideas in action, check out GitHub - Plasma-Deckery/deckery: Steam-independent context-aware input stack for handheld Linux (Steam Deck) · GitHub , where I created a more powerful open-source implementation of steam’s input mapping.