add a basic alphanumeric on-screen keyboard

[Boteium]

this implement an on screen keyboard for tablet or cellphone.
add a parameter --show-keypad for enabling this feature and --keypad-text-color for setting color

This feature has been requested repeatedly for several times in #394 #271 #426

[Boteium]

[emersion]

Thanks for sending a patch, but I'm not sure an integrated virtual keyboard is the right approach. I think we should make it so external virtual keyboards can work with swaylock instead.

[Boteium]

Thanks for the review! I completely agree that relying on an external OSK is the ideal architecture, and I am perfectly fine with building that integration.

My decision to build the keyboard directly into swaylock was simply based on the project's history. Looking at discussions like PR #443 and PR #445, there is an understandable reluctance to merge external auth integrations due to the strict focus on simplicity and stability.

Going the external OSK route means navigating inherent logic pitfalls such as ecurely layering a third-party window over the lock screen, managing race conditions, and handling ecosystem fragmentation. I am absolutely willing to tackle these. My only concern is investing the heavy effort into that integration, only to have the PR rejected later because those necessary architectural compromises ultimately make you uncomfortable.

To be completely honest, I am not in love with the idea of a baked-in keyboard either. it is definitely a concession. However, since I personally use Squeekboard while other users rely on entirely different setups (issue 394), a basic native option felt like a practical middle ground. It bypasses the fragmentation completely and provides an immediate, out-of-the-box fix for the Linux touchscreen community, who are currently stuck in a frustrating limbo without a usable locker.

If you would rather aim for the cleaner external OSK architecture and are open to accepting a PR for it, I am more than happy to switch gears and build that instead. Just let me know which direction

[kennylevinsen]

If we need to present an OSK, I imagine the "solution" would be mostly outside swaylock:

1. A general wayland OSK app
2. A way for such OSK app to be considered special and presented despite session lock being active, as needed
3. Whatever change it would take to swaylock to trigger the OSK

Maybe one could reuse text-input/input-method to show a full OSK instead of the usual CJK IME interfaces.

[Boteium]

I also like the idea of using an external OSK, but the real bottleneck is finding an implementation the maintainers will actually accept.

The first issue is the trigger mechanism. For example, waking up an OSK like squeekboard requires D-Bus, but maintainers explicitly rejected adding a D-Bus dependency in PR #283. Even workarounds using external commands like busctl are currently stalled in PR #443, so the main hurdle is finding a technical approach everyone can agree on.

The second issue is ecosystem fragmentation. Even if the trigger mechanism gets solved, there is no single universal Wayland OSK. How do we get the people to agree on exactly which OSK swaylock should officially target and support?

[kennylevinsen]

Anything requiring swaylock to integreate directly with specific OSKs wouldn't really make sense, for similar reason as to why direct dbus integration doesn't make sense for Wayland OSKs as they are accessibility tools that should be available for any text input.

text-input and input-method are protocols that allow an external applications to effectively control and type into text input fields and present UIs in their vincinity. The primary intent is to show UIs for more advanced scripts like CJK, but maybe it would make sense to use for such on-demand OSKs.

The swaylock side would then just involve using text-input, with a possibly arbitrary placement.

For an OSK using standard toplevels or layer shell, the primary work would relate to allowing such surfaces to be shown during session lock in e..g, sway, but in that case the OSK could just be started before swaylock.

[Boteium]

This is a clean architecture, I'll leave this here for someone else to pick up since it doesn't fit my workflow, anyway.

Relying on the text-input protocol shifts the heavy lifting to compositors (like Sway or labwc), I think. Compositors would need updates to allow OSK rendering over the lock screen. Coordinating changes across multiple upstream projects is beyond my scope. Additionally, I don't use OSK auto-hide, so a text-input auto-trigger wouldn't solve my specific use case even if those compositor changes were merged. However, this can be offload to user's side such as in issue 426.

For now, it seems touch users will have to rely on modified lockers until the Wayland ecosystem pick touch screen support. Thanks for taking the time to explain the community design philosophy for this!