[PATCH v2 libinput 00/10] pad: add a mode toggle API

[Peter Hutterer]

On Fri, Jul 01, 2016 at 09:03:47PM +0200, Carlos Garnacho wrote:
> Hey!,
> 
> On Tue, Jun 21, 2016 at 8:25 PM, Jason Gerecke <killertofu at gmail.com> wrote:
> > On 06/14/2016 11:37 PM, Peter Hutterer wrote:
> >>
> >> Updated patchset adds EKR support and fixes a bunch of issues pointed out in
> >> v1. Patch 04 is intentionally missing, that's the SVG being added which
> >> wouldn't make it past the mailman filters.
> >>
> >> The branch is available on
> >> https://github.com/whot/libinput/tree/wip/tablet-pad-modes-v2
> >>
> >> One important thing of note: Benjamin and I discussed the kernel side of
> >> things and we'll be aiming for handling the LED toggling in the kernel
> >> through the LED class interface. This means that libinput won't need write
> >> support to sysfs and that libinput doesn't actually have to update the mode,
> >> merely read the changed mode.
> >>
> >> this also means that patch 06 and 07 will change significantly though the
> >> public API will remain the same. once the kernel patches are on track to be
> >> in an upstream kernel I'll update the implementation, for now we go with
> >> this one.
> >>
> >> Cheers,
> >>   Peter
> >
> > Aside from the small comments on two of the patches, this looks good to
> > me. Testing also seems to look good aside from the not-yet-implemented
> > direct mode switching on my 24HD.
> 
> This got me thinking... it would also be great to know the mode those
> direct-mode buttons switch to. Although this is just useful for
> labeling purposes (eg. setting "Switch to mode 1/2/3" labels instead
> of a generic "Switch mode" on all three), so having this in libinput
> is dubious in the first place. To be resolved through a different call
> than libinput_tablet_pad_mode_group_button_is_toggle at the very
> least.

I'm not 100% sure on where to put this this tbh. with the upcoming kernel
patches libinput doesn't have the authority over mode switching anymore and
itself needs to figure out what switches where (either based on libwacom or
by reading the LED trigger files). so we can know all this in libinput, but
we don't necessarily need to know this.

I'm wondering if a better workaround here would be to adjust the UI so this
isn't even needed (yes, this sounds lazy :)

Cheers,
   Peter