On Wed, 20 May 2009, Stéphane Chatty wrote: > I just saw a message in the linux-input ml about a USB tablet that is > not registered in the input layer. Someone proposed that there might be > no useful application in the HID report descriptors. > > There is an other possibility: the IS_INPUT_APPLICATION in hid.h might > fail to capture a legitimate application. I am currently working on a > HID driver for a multitouch surface by Stantum that has application > usage 0x000d0004 (Digitizer / Touchscreen), and I had to change > IS_INPUT_APPLICATION to have it registered in the input layer. The > N-Trig surface is registered only because it declares two application > collections: a Pen and a Touchscreen. > > The comment that accompanies the definition of the macro looks very old. > Is there another reason why the definition of input applications is so > restrictive? I had in mind to add the range 0x000d0002-0x000d0006 at > least. Is there any contraindication to this? Hi Stephane, we definitely want to extend the IS_INPUT_APPLICATION() macro to reflect the current hardware -- the contants used in the macro are quite old indeed. On the other hand we must be careful not to break any userspace drivers -- because currently hiddev node (which userspace drivers use) is created when the device has at least one application which is not recognized as input application by IS_INPUT_APPLICATION macro. If we change semantics of this macro, it might happen that hiddev node would stop appearing for certain devices, thus breaking backwards compatibility for userspace drivers. -- Jiri Kosina SUSE Labs
