On Wed, Jun 24, 2020 at 01:45:27PM -0400, Michael Spang wrote: > On Wed, Jun 24, 2020 at 7:27 AM Nikolai Kondrashov <spbnick@xxxxxxxxx> wrote: > > > > Hi Peter, everyone, > > > > On 6/24/20 10:06 AM, Peter Hutterer wrote: > > > On Wed, Jun 17, 2020 at 02:39:47PM -0700, Harry Cutts wrote: > > >> Hi Kernel input people, > > >> > > >> On Chrome OS, we've observed a couple of graphics tablets getting > > >> INPUT_PROP_DIRECT set despite them being traditional digitizers > > >> without screens. The two tablets we've seen this for are the Huion > > >> H610PRO (VID:PID 256c:006d) and the UGTABLET 10 inch PenTablet > > >> (28bd:0905). Reverting "HID: input: Set INPUT_PROP_-property for > > >> HID_UP_DIGITIZERS" (8473a93d1ba5385f63a128a285702ccc1d3ae2cc) fixes > > >> the Huinon, at least. (We didn't get a chance to test it with the > > >> UGTABLET.) Do we know if this is a shortcoming of that patch, are > > >> those tablets just describing themselves incorrectly in their HID > > >> descriptors? (in which case I guess we'd just have to add quirks for > > >> them) > > > > > > fwiw, both huion and ugtablet are ones i know are regularly giving me > > > troubles in libinput because what they say they do and what they do isn't in > > > sync. HUION also re-uses usbids. 006d is a relatively new one I think, we > > > have at least 7 different devices with 0256c:006e in libwacom and need to > > > match on the name there, but with the Huion HS610 even that breaks - it uses > > > the same vid/pid *and* name of other devices despite having different > > > properties [1]. HS610, HS64 and your H610PRO all seem to use 000d, so... > > > yay? > > > > > > I've CC'd Nikolai, he has much more kernel-level experience with these > > > devices than I do. > > > > These days, you can't rely on pretty much anything to identify an exact > > non-Wacom graphics tablet model. With Huion's I sometimes rely on the special > > string descriptor containing tablet parameters in binary, retrieving which has > > side effects (switching proprietary mode on). > > > > The only reliable way to deal with them is to only consider their reported > > parameters, and not try to derive anything else from any > > supposedly-identifying properties. > > > > Regarding the original topic of this thread, it's not clear from the source > > code what INPUT_PROP_DIRECT exactly means, but I see that it is synonymous > > with the "Pen" (0x02) application collection usage, about which HUT 1.12 [1] > > 16.1 Digitizer Devices says: > > > > A digitizer with an integrated display that allows use of a stylus. The > > system must ensure that the sensed stylus position and the display > > representations of that position are the same. > > It means there is a display integrated with the input devices and > applies to both touchscreens and LCD drawing tablets. also, the google term here is "direct vs indirect input devices" which will provide you with more academic papers than you want to read :) Cheers, Peter > > I also see that all replacement graphics tablet report descriptors I > > contributed to the kernel use it, and that is incorrect. Shame on me. > > > > The proper fix thus would be to replace the 0x02 usage with 0x01 in > > replacement report descriptors, before application collection item, for all > > (non-display) graphics tablets. 0x01, according to HUT 1.12 would mean: > > > > A device that measures absolute spatial position, typically in two or more > > dimensions. This is a generic usage; several specialized types of > > digitizers are distinguished by their attributes. > > > > That would get INPUT_PROP_POINTER assigned to them instead. > > > > However, this might get a bit tricky as it's not always easy to find out which > > exact models are display models, and then there's Huion display models, e.g.: > > > > https://www.huion.com/pen_display/KamvasPro/kamvas-pro-24.html > > > > which likely have the aforementioned identification issues too. > > > > Finally, of course, we have models which don't have replacement report > > descriptors we control, but which have 0x02 usage instead of 0x01 in their > > firmware (I must have copied that from somewhere after all). OTOH, those > > usually don't work (well) out-of-box, so probably not a big deal. > > > > What's the practical implication of having INPUT_PROP_POINTER instead of > > INPUT_PROP_DIRECT for a display-equipped graphics tablet? > > This case is basically usable. It has the following problems: > > (1) The mouse cursor will be drawn under the stylus which is > unnecessary and obscures content. > (2) Rotating the display will throw off the coordinate system and make > the device unusable. > (3) Multiple pen inputs will interfere with each other (e.g for an > interactive whiteboard). This isn't a fundamental problem but stems > from pointer devices just reusing existing mouse APIs which have a > single, global pointer. > > Note that POINTER is the default behavior for stylus devices that > report neither DIRECT nor POINTER, so the above problems are status > quo for devices with integrated displays unless they add the DIRECT > property specifically. > > > > > > Nick > > > > [1]: Universal Serial Bus HID Usage Tables (HUT) 1.12 > > https://www.usb.org/sites/default/files/hut1_12.pdf
