IS_INPUT_APPLICATION and tablets

IS_INPUT_APPLICATION and tablets

[Stéphane Chatty]

Dear Jiris, dear Greg,

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?

St.

Re: IS_INPUT_APPLICATION and tablets

[Jiri Kosina]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1632 bytes --]

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

Re: IS_INPUT_APPLICATION and tablets

[Rafi Rubin]

Is there any downside to letting hiddev to cover all devices, even those that are supported by the hid system?

I should point out that with the current settings, the n-trig digitizers do in fact bind to both drivers.  Its been a useful
debugging tool.

Jiri Kosina wrote:
> 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.
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: IS_INPUT_APPLICATION and tablets

[Jiri Kosina]

On Thu, 21 May 2009, Rafi Rubin wrote:

> Is there any downside to letting hiddev to cover all devices, even those 
> that are supported by the hid system?

That's one of the possible solutions, yes. (we could either make that 
behavior configurable, with default settings to always create hiddev 
node, to preserve backwards compatibility with userspace).

-- 
Jiri Kosina
SUSE Labs

Re: IS_INPUT_APPLICATION and tablets

[Rafi Rubin]

Jiri Kosina wrote:
> On Thu, 21 May 2009, Rafi Rubin wrote:
> 
>> Is there any downside to letting hiddev to cover all devices, even those 
>> that are supported by the hid system?
> 
> That's one of the possible solutions, yes. (we could either make that 
> behavior configurable, with default settings to always create hiddev 
> node, to preserve backwards compatibility with userspace).
> 

Those codes are descriptions, not unique identifiers.  It seems to me that sooner or later a conflict will arise over multiple
devices with the same code where the driver writers for devices have differing philosophies.

You could also leave a legacy version of IS_INPUT_APPLICATION with some old ranges for hiddev while letting hid-input use a version
which is free to expand.  But I think forking like that would be uglier than having hiddev nodes for all devices by default.

As for a configurable solution, there's always the style used by serio_raw.  Though, I think enabling hiddev shouldn't unbind the
normal hid-input driver.

Rafi