Libinput: Halfkey/Mirrorboard implementation

Peter Hutterer peter.hutterer at
Sun Jul 26 22:07:24 PDT 2015

Hi Kieran,

On Fri, Jul 24, 2015 at 04:28:04PM -0500, Kieran Bingham wrote:
> Hi Guys,
> I've been working on a personal project to implement one-handed touch
> typing as an accessibility feature.
> There are software solutions for this available for Win/MacOS
>, and an (expensive)
> hardware solution available. There is also a solution which uses xkb
> mappings to utilise the caps-lock as a modifier,
> but this didn't meet my needs; along with a couple of outdated other linux
> alternatives mentioned at

so first of all, I appreciate your work. the first question I have here is
why the current solutions are insufficient, especially the xkb one.

> I had originally started this using XLib hooks to capture all keyboard
> input and re-introduce keys through XTest.
> This wasn't the best solution however, and while reading up on wayland, I
> discovered libinput provides a good
> location for this work. And using the xf86-input-libinput wrapper for X I'm
> now using it on my laptop.
> Anyway, I thought I had got to a stage where I could share some code
> (although this is still a work in progress)
> I'd love to hear your feedback as to whether this is something that you
> would like to integrate, or for me to continue working on.
> (I'll continue to use it for personal use, but if its desired, I can work
> on improvements to upstream it)

I'm wondering if libinput is the right position in the stack to handle this.
libinput is a hw abstraction that makes the hw easier to deal with, more
complex things should go into the higher layers.
Flipping keyboard layouts is semantically more complicated than what
libinput knows about the keyboard (e.g. we don't handle keyboard layouts) so
you'll likely run into a number of issues here when the keyboard layouts
differ from the us default. That's a nonissue for a local installation, but
a bigger issue when we'd try to merge this as a generic solution for all

having this in xkb is also more discoverable for clients than in libinput
where it's more or less hidden and done magically.

funnily enough, I can also imagine this as a daemon emulating a uinput
device that does the mapping on demand to emulate a virtual hardware device.
In that case everthing would be truly hidden and we'd pretend this is a
custom hardware device with this functionality by default, so it'd sit below

long term though I think the xkb solution would be the best, so again: why
wasn't xkb sufficient?

> My current work is on github, and includes updates to the
> xf86-input-libinput wrapper to enable the feature from xorg.conf.d
> Rebased today in the forks at :
> : branch halfkey
> : branch halfkey
> Currently implemented:
>  * Functioning halfkey support using the space bar as a modifier
>  * Test cases in test/keyboard-halfkey.c
>  * Property to enable support with : Option "Halfkey" "on"
> Todo List:
>  * Customisable Modifier (use caps-lock/tab etc instead)
>  * Customisable or device specific mirror mappings
>  * Testing on non-qwerty / UK keyboards and layouts (I have used only my
> keyboard so far)
>  * Add a "RELEASE" state to track pressed keys after modifier released
> (Current work in progress)
>  * Introduce halfkey pressed keys on a different seat as if it was a
> separate keyboard
>    (due to failing test case .. halfkey_test_corner_cases )
>  * Probably some updates to the debug tooling in tools/
>  * Some more documentation and state diagrams?
>  * Add timeout on space down to insert (repeating) spaces.
>  * Tidy up the patches :)
> Warning: If you run this live, and press a key down followed by its mirror
> equivalent down at the same time, libinput will fire an assertion and your
> X-session will restart !
> ( This is the bug failing in halfkey_test_corner_cases )
> Look forward to hearing from you.
> Regards
> Kieran Bingham

More information about the wayland-devel mailing list