Re: [GIT] HID for 3.12 merge window

Hi

On Sat, Sep 7, 2013 at 11:20 AM, Benjamin Tissoires
[off-list ref] wrote:

On 07/09/13 10:57, David Herrmann wrote:

quoted

Hi

On Sat, Sep 7, 2013 at 10:24 AM, Benjamin Tissoires

quoted

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:

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

        while (usage->code <= max && test_and_set_bit(usage->code, bit))
                usage->code = find_next_zero_bit(bit, max + 1, usage->code);

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

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