On 19 August 2015 at 07:20, Peter Hutterer <peter.hutte...@who-t.net> wrote: > 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.hutte...@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.
As I feared, - the really big power in this feature is that the keyboard acts normally until the space bar is held down. And it needs to be a central modifier so that both the left and right hand can both access it with ease. (Using the thumb to flip is very easy) >> > > 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. > For the most part, I'd expect only the main row keys to be mirrored, So I would expect limitations. Do you know of any keyboards that don't have the usual main rows? - i.e. A-Z and numbers albeit in a localised layout? Ideally there would be a way for users to customise, perhaps with a configuration file, or GUI ... but I'm getting ahead of myself here if its not feasible :) -- Regards Kieran > 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 _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel