Re: [GIT] HID for 3.12 merge window
From: David Herrmann
Date: Sat Sep 07 2013 - 05:29:33 EST
Hi
On Sat, Sep 7, 2013 at 11:20 AM, Benjamin Tissoires
<benjamin.tissoires@xxxxxxxxx> wrote:
>
>
> On 07/09/13 10:57, David Herrmann wrote:
>> Hi
>>
>> On Sat, Sep 7, 2013 at 10:24 AM, Benjamin Tissoires
>>> I'm not particularly in favor of adding semantic between ABS_MISC and
>>> ABS_MT_SLOT. We already did that once with the ABS_MT_* stuff, and the
>>> problem comes from devices showing several axes, not really mapped
>>> (like joysticks). These axes are all mapped to ABS_MISC, but the input
>>> core function map them to ABS_MISC+N. This way some joysticks show
>>> multitouch axes and are treated as such, whereas the axis are just
>>> regular absolute axes. (not sure I am clear enough... :( )
>>>
>>> Currently, nothing is done in X or in Wayland to detect these false
>>> multitouch devices with a large number of absolute axes. But if we
>>> keep a hole between ABS_MISC and ABS_MT_SLOT, we could add an
>>> heuristic like:
>>> "if all the axes between ABS_MISC and ABS_MT_SLOT are available, then
>>> ABS_MT_SLOT does not mean multitouch, but ABS_MISC+6."
>>
>> So Xorg just took control over the unused ABS_* slots? Hmm, then I
>> have no other idea than reverting the 3 patches.
>> Sadly, that also means there's no way for us to easily extend the
>> ABS_* bits. If someone has an idea, let me know. But for now I'll just
>> put the drums/guitar patches on hold.
>>
>
> Well, I would say the "problem" lies in hid-input.c, line 919:
>>>>>>>>>>>>>>>>>>>
> while (usage->code <= max && test_and_set_bit(usage->code, bit))
> usage->code = find_next_zero_bit(bit, max + 1, usage->code);
>>>>>>>>>>>>>>>>>>>
>
> So if you try to map several times ABS_MISC or any other axis, then you are mapping ABS_MISC+N.
>
> Anyway, the only problematic axis is ABS_MISC, as it is a default fallback. IMO, we can extend the ABS_* definitions after ABS_MT_TOOL_Y, like the original patch you proposed without having to deal with the above problem (though this will report the patch series to v3.13).
> To prevent future mistakes, we should just define ABS_MISC0 (0x29) to ABS_MISC5 (0x2e) to fill the hole.
As mentioned earlier in this thread, ABS_* is limited to 0x3f, so we
have only 2 more free slots after ABS_MT_TOOL_Y.
We will figure something out for 3.13.
I will also prepare a patch for ABS_MISC0-MISC5.
Regards
David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/