Libinput: Halfkey/Mirrorboard implementation

Kieran Bingham kieranbingham at
Tue Aug 18 09:47:43 PDT 2015

Hi Peter,

Sorry for the late reply here, I've moved back from South America to England
and had to look in to some of my assumptions!

On 27 July 2015 at 06:07, Peter Hutterer <peter.hutterer at> wrote:
> 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.

The xkb solution is the only real alternate contender here for me.
 (Hardware = cost, windows/mac != linux, other solutions = old+broken)

My difficulties with xkb are in creating a mapping where by the space bar
acts as both a modifier *and* a space bar.

> > 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.

Exactly - I had assumed (which now I think may be wrong) that libinput was
effectively passing up the equivalent to scancodes which are then modified
by X to perform the keyboard mappings. I was hoping to be able to generate
a solution which will act 'under' the keyboard layouts so that it doesn't matter
what the key is ... it is being mirrored as if it was a hardware mirror.

I'd (foolisly) hoped for a single solution that would map on to french azerty
keyboards, just the same as it would map to a us/en qwerty by simply mirroring
under the layout definitions. Now that I've dug deeper into xkb - I see that it
would of course be more complicated than that anyway.

> 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
> keyboards.


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

This is an important point.
It certainly would need a switch.
The design goal is that the keyboard functions 'normally' except when a modifier
is held at the same time as a key. However, in my testing, I have
noted that a fast
typist (like me) occasionally holds the space down longer, which would give them
a surprise mirrored key.

> 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
> libinput.

This is sort of what my earlier solution did with XLib/XTest.
Disconnected the input source, and re-injected after modification.

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

In summary, I haven't been able to map the space bar to act as a modifier to
flip the keyboard, and a space bar when pressed on its own.

However, I agree with your responses, and have spent a lot of today sinking my
head back into xkb mappings. Now that my head hurts, I've signed up to the
xkb mailinglist over at!forum/xkb
and will beg for assistance there :)

It may be that I need to extend the compat actions to support a modifier/action
key somehow - but I haven't got my head round it yet.



More information about the wayland-devel mailing list