linux-kernel - Re: [GIT] HID for 3.12 merge window

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Sat, 07 Sep 2013 10:12:36 -0700
From:	Dmitry Torokhov <dmitry.torokhov@...il.com>
To:	David Herrmann <dh.herrmann@...il.com>,
	Benjamin Tissoires <benjamin.tissoires@...il.com>
CC:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Markus Trippelsdorf <markus@...ppelsdorf.de>,
	Jiri Kosina <jkosina@...e.cz>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	"open list:HID CORE LAYER" <linux-input@...r.kernel.org>
Subject: Re: [GIT] HID for 3.12 merge window

David Herrmann <dh.herrmann@...il.com> wrote:
>Hi
>
>On Sat, Sep 7, 2013 at 11:20 AM, Benjamin Tissoires
><benjamin.tissoires@...il.com> 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.
>

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/