Libinput: Halfkey/Mirrorboard implementation

[Peter Hutterer]

On Tue, Aug 18, 2015 at 05:47:43PM +0100, Kieran Bingham wrote:
> 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 who-t.net> 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
> > > http://www.onehandkeyboard.org, 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
> > > http://www.onehandkeyboard.org/linux-one-handed-keyboards/
> >
> > 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.

right. I don't think xkb will let you do this, at least not as a either/or
case depending on e.g. how long you press. you'll need to designate a
separate key for it.
 
> > > 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. 

That's correct, libinput passes evdev codes (see the KEY_* defines in
linux/input.h) to the xf86-input-libinput driver which simply adds 8
(historical reasons) and passes that on. in that it's no different to e.g. evdev.

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

that is possible, but only while you're assuming that the HW is mostly
identical, and this is where the difficulty lies. take your normal PC
keyboard and it won't matter if the layout up-top is us or fr. take a laptop
keyboard and it starts to matter, since the keys are suddenly all over the
place.

Cheers,
   Peter

> 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.
> >
> 
> Understood.
> 
> 
> >
> > 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
> https://groups.google.com/a/listserv.bat.ru/forum/#!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.
> 
> Regards
> 
> Kieran