Hi, This series is an RFC for USI (Universal Stylus Interface) style pen support. This is based on documentation from USB org describing the HID usage tables for digitizers (page 0x0D) and experimentation with actual USI capable controllers. This series introduces the USI support with a new HID driver, which applies the controller specific quirks. The most problematic part of the USI support is handling of the pen parameters (color, line width, line style), which are not immediately available from the controller from pen down event, but must be cached and queried separately from the controller. In addition to that, when a get-feature report is sent to the controller, there is a delay before the proper value is reported out; it is not part of the feature report coming back immediately. Most of the code in the driver is to handle this (otherwise we could just use hid-generic.) This also boils down to the reason why this series is an RFC, I would like to receive some feedback which option to pick for programming of the new values for the programmable pen parameters; whether to parse the input events so userspace can directly write the new values to the input event file handle, or whether to use IOCTL. Patches #7 / #8 are sort of optional choices towards this, but are there to show that both approaches can be done. Direct write to evdev causes some confusion on the driver level though, thus patch #7 is there to avoid some of that introducing new input events for writing the parameters. IOCTL might be the cleanest approach and I am slightly leaning towards that myself (see patch #8, this would need to be squashed and cleaned up a bit though but would effectively get rid of some code from patch #6 and completely rid patch #7.) The driver has been tested with chromebooks that contain either Goodix or Elan manufactured USI capable touchscreen controllers in them. Any feedback appreciated! -Tero
