Re: [GIT] HID for 3.12 merge window

David Herrmann [off-list ref] wrote:

Hi

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

quoted

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

quoted

quoted

quoted

ABS_MT_SLOT. We already did that once with the ABS_MT_* stuff, and

the

quoted

quoted

quoted

problem comes from devices showing several axes, not really mapped
(like joysticks). These axes are all mapped to ABS_MISC, but the

input

quoted

quoted

quoted

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

quoted

quoted

quoted

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

quoted

quoted

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))

quoted

                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

quoted

So if you try to map several times ABS_MISC or any other axis, then

you are mapping ABS_MISC+N.

quoted

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).

quoted

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.

Regardless of whether we settle on using lower bits or bite the bullet and extend number of axis I think it's time for EVIOCGABS2 that would take axis in its argument instead of encoding it in ioctl number - that idea wasn't that good.


Thanks.

-- 
Dmitry