[PATCH libinput] udev: add quirk for Chalkboard Electronics HID Touchscreen

[Peter Hutterer]

On Wed, Sep 20, 2017 at 12:19:13PM -0400, Matt Porter wrote:
> On Wed, Sep 20, 2017 at 10:14:41AM +1000, Peter Hutterer wrote:
> > Hi Matt,
> 
> Hi Peter!
> 
> > On Tue, Sep 19, 2017 at 12:41:52PM -0400, Matt Porter wrote:
> > > The Chalkboard Electronics HID Touchscreen is classified as
> > > a tablet device by systemd udev because it has BTN_TOOL_PEN
> > > support. It also reports a resolution of 0 for both X and Y
> > > axes in absinfo. This causes libinput to reject it as an
> > > invalid tablet device.
> > > 
> > > This quirk reclassifies the device as a touchscreen which
> > > allows it to be added as a valid input device.
> > > 
> > > Signed-off-by: Matt Porter <mporter at konsulko.com>
> > > ---
> > >  udev/90-libinput-model-quirks.hwdb | 7 +++++++
> > >  1 file changed, 7 insertions(+)
> > > 
> > > diff --git a/udev/90-libinput-model-quirks.hwdb b/udev/90-libinput-model-quirks.hwdb
> > > index 72fcdca..6348f0c 100644
> > > --- a/udev/90-libinput-model-quirks.hwdb
> > > +++ b/udev/90-libinput-model-quirks.hwdb
> > > @@ -72,6 +72,13 @@ libinput:name:*ETPS/2 Elantech Touchpad*:dmi:*svnASUSTeKCOMPUTERINC.:pnX555LAB:*
> > >   LIBINPUT_MODEL_TOUCHPAD_VISIBLE_MARKER=1
> > >  
> > >  ##########################################
> > > +# Chalkboard Electronics
> > > +##########################################
> > > +libinput:name:Chalkboard Electronics HID Touchscreen:dmi:*
> > > + ID_INPUT_TABLET=0
> > > + ID_INPUT_TOUCHSCREEN=1
> 
> First off, thanks for the very good explanation of where this quirk
> handling should live...I wasn't entirely clear on the separation from my
> read of systemd and libinput.
> 
> > There are three things we have to fix here:
> > 1) ID_INPUT_* is not something set by libinput so if it is wrong, we should fix
> > it at the source (i.e. systemd) so it will be correct for everyone. By the
> > time libinput sees this device, the ID_INPUT_* must be correct already, that
> > is one of the requirements we have from the base system.
> 
> Ok. Since systemd's logic of normally classifying anything with a pen
> tool as a tablet makes sense, tt appears I'll want to add something
> similar to 65-libwacom.rules. We definitely are a traditional
> touchscreen device and not something with semantics like a Wacom
> tablet. Something like:
> 
> 65-chalkboard-electronics.rules
> -------------------------------
> # udev rules for Chalkboard Electronics devices
> 
> ACTION!="add|change", GOTO="chalkboard_end"
> KERNEL!="event[0-9]*", GOTO="chalkboard_end"
> 
> ENV{ID_BUS}=="usb", ENV{ID_VENDOR_ID}=="04d8", ENV{ID_MODEL_ID}=="f723", ENV{ID_INPUT}="1", ENV{ID_INPUT_TABLET}="", ENV{ID_INPUT_TOUCHSCREEN}="1"
> 
> LABEL="chalkboard_end"


yes. I'd rather have this as a hwdb entry but right now you can only set a
property to '0', not unset it via hwdb. that's fine for libinput but other
systems (including the xserver) don't recognise this correctly.

> > 2) The absinfo bits can be set with the EV_ABS_.. in 60-evdev.hwdb. Have a
> > look at that file, it includes the explanation on how to set it.
> 
> Ok, perfect. I totally missed this and I have a patch I'll send upstream
> to systemd.

for the archives, there's a PR here:
https://github.com/systemd/systemd/pull/6880

 
> > 3) The libinput part of this will be to add a
> > LIBINPUT_MODEL_CHALKBOARD_ELECTRONICS_TOUCHSCREEN tag for this particular
> > model. That needs to be parsed in evdev_pre_configure_model_quirks because
> > we need to libevdev_disable_event_code(BTN_TOOL_PEN) for that to make sure
> > the rest of libinput has the data it expects.
> 
> I see, ok. Is this necessary even if the device is detected as a
> touchscreen? It appears that BTN_TOOL_PEN events are only used in the
> evdev-tablet.c paths so I would have thought it unncessary to disable
> pen events. That is, assuming I have the first two cases above
> implemented. Is this simply for correctness and to not have bogus pen
> events arriving at get_key_type()? In any case, I can rework as
> described above.

It's not necessary at the moment, but it may be in the future. libinput can
work around devices that are known to be broken but we're trying to be
relatively strict in what we accept.

fwiw, there are no 'bogus pen events' in the touchscreen case because we
don't handle tools there anyway. This could potentiall break if we get a
touchpad that has FINGER and PEN at the same time, but I'm not sure yet how
to handle those and we currently rely on the kernel do split up the event
nodes for us.

I think the worst that could happen is that libinput either complains in the
log or rejects the device outright.

Cheers,
   Peter