[PATCH libinput 5/7] pad: Add a new API for modes and mode groups

[Peter Hutterer]

On Tue, Jun 07, 2016 at 06:33:19PM -0700, Jason Gerecke wrote:
> On Sun, Jun 5, 2016 at 11:50 PM, Peter Hutterer
> <peter.hutterer at who-t.net> wrote:
> > Move mode control to libinput. This reduces some flexibility on what we can do
> > with modes but makes it a lot easier for anyone to implement modes correctly
> > and have the LEDs apply appropriately, etc. Let's go with the option to make
> > the 95% use-case easy. Note: whether the mode is actually used is up to the
> > caller, e.g.  under Windows and OS X the mode only applies to the
> > rings/strips, not the buttons.
> >
> > A tablet pad has 1 or more mode groups, all buttons/ring/strips are assigned
> > to a mode group. That group has a numeric mode index and is hooked to the
> > LEDs. libinput will switch the LEDs accordingly.
> >
> > The mode group is a separate object. This allows for better APIs when it comes
> > to:
> > * checking whether a button/ring/strip is part of a mode group
> > * checking whether a button will trigger a mode transition
> > * checking which mode transition will happen
> >
> > and in the future potentially:
> > * setting which button should change the mode transition
> > * changing what type of mode transition should happen.
> > * moving a button from one mode group to the other
> >
> > This patch adds the basic scaffolding, without any real implementation.
> >
> > Signed-off-by: Peter Hutterer <peter.hutterer at who-t.net>

...

> > +        * pressing a mode toggle button.
> > +        *
> > +        * @note Support for this event is not yet implemented.
> > +        */
> 
> Is this a nod to the EKR's read-only mode switches, or a hint about a
> future API extension to allow compositors to set modes? If the former,
> is there a reason callers would care that the device switched modes
> instead of libinput? If the latter, wouldn't it make sense to leave
> this event out for the time being?

yes, I'll leave this out of the final version.

I'm not planning to implement this for the EKR since it has a clearly
defined toggle button. There are two use-cases for this event: one at
startup to notify the caller of the current mode and external access to the
modes. I've sinced ditched the former in favour of letting the caller just
call get_mode on DEVICE_ADDED despite the potential race with an event
already in the pipe, it's too unlikely and it just doesn't matter.

The second case is more realistic: someone can write to the syfs file and
change the LEDs without libinput noticing. This should in theory cause a
MODE event but tbh I'm having a really hard time convincing myself that the
effort required is worth it (it would require monitoring the file).
I think I'll file this in the "don't do that" bin.

fwiw, the next step that Carlos and I have discussed already: getting a
O_RDWR fd on the sysfs tree isn't as trivial as it should be. so one
potential solution would be to have a privileged dbus daemon running that
handles the sysfs access and libinput talks to it to toggle the LEDs. That
would make the MODE event more prevalent since anyone could talk to it but
IMO even then its still firmly in the "don't do that" category :)

So yes, I'll remove this in the final version.

All typos/rewordings fixed as requested.

Cheers,
   Peter