linux-kernel - Re: [PATCH] Add BTN_TOOL

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <AANLkTinJZyDcORj5DBGNr6Ss8penFyLxw4YDBFaTNLSK@mail.gmail.com>
Date:	Tue, 23 Nov 2010 16:51:10 -0800
From:	Ping Cheng <pinglinux@...il.com>
To:	Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc:	linux-kernel@...r.kernel.org, jkosina@...e.cz
Subject: Re: [PATCH] Add BTN_TOOL_BUTTONS to input.h

On Tue, Nov 23, 2010 at 4:38 PM, Dmitry Torokhov
<dmitry.torokhov@...il.com> wrote:
> On Tue, Nov 23, 2010 at 04:12:13PM -0800, Ping Cheng wrote:
>> On Tue, Nov 23, 2010 at 2:24 PM, Dmitry Torokhov
>> <dmitry.torokhov@...il.com> wrote:
>> >
>> >> > The BTN_TOOL_* were introduced to indicate to the userspace tool that is
>> >> > currently touching the surface of the device. Buttons are expected to be
>> >> > always present and can change their state regardless of what tool is
>> >> > being used at the moment. I.e. The full hardware state (between
>> >> > EV_SYN/SYN_REPORT) could be, for example,
>> >> >
>> >> > Pen at 10,20, BTN_0, and BTN_2 (ABS_X 10, ABS_Y 20, BTN_TOOL_PEN, BTN_0,
>> >> > BTN_2) or
>> >> >
>> >> > Lens at 20,15 and BTN_1 (ABS_X 20, ABS_Y 15, BTN_TOOL_LENS, BTN_1).
>> >> >
>> >> > As you can see BTN_* events can accompany either BTN_TOOL_LENS or
>> >> > BTN_TOOL_PEN or any other BTN_TOOL_*.
>> >>
>> >> You are right. The tablet buttons can go with one of those other
>> >> BTN_TOOL_s _if_ they do not define the same event types (BTN_s) as the
>> >> tablet buttons.
>> >>
>> >> The new Bamboo MT code sends both BTN_LEFT and BTN_RIGHT events for
>> >> Tablet Buttons (refer to line 905 and 908 of wacom_wac.c). However,
>> >> BTN_LEFT and BTN_RIGHT are also sent by BTN_TOOL_MOUSE/LENS tool
>> >> (refer to wacom_wac.c line 622 to 665).
>> >>
>> >> If we remove BTN_TOOL_FINGER without a BTN_TOOL-something to replace
>> >> it, the two LEFT and RIGHT buttons will have a hard time to tell the
>> >> user land if they are from the MOUSE/LENS or the Tablet Buttons. The
>> >> worst case could be the LEFT/RIGHT sent later overwrites the earlier
>> >> ones.
>> >>
>> >> We could do some guesswork in the user land to figure out which
>> >> LEFT/RIGHT belongs to which BTN_TOOL_ if the above scenario does not
>> >> happen. But, it would be much cheaper and more reliable if we can tell
>> >> the user land where those LEFT and RIGHT come from. This is the whole
>> >> purpose of the kernel driver, isn't it?
>> >
>> > What would userspace want to figure what physical button was pressed?
>> > Input events convey _actions_, i.e. BTN_LEFT means that user pressed
>> > primary button on the device. It does not matter if it was pressed on
>> > tablet or the mouse/lens; the response should be the same.
>>
>> You're right, if the user wants a LEFT click. In a lot of cases, they
>> want to translate it into something else. LEFT is only a default value
>> that we give them if they do nothing.
>>
>> > If you expect different response, depending on which physical button is
>> > pressed, then they should emit different BTN_* events. If you are
>> > concerned that some users might want to have the same actions while
>> > others want different actions - then please implement key remapping in
>> > the driver.
>>
>> That is exactly what I am trying to convince you. Without being able
>> to tell one button event from the other, even just logically, how can
>> I and other clients remap them?
>
> EVIOCSKEYCODE. You just need to wire wacom driver to support this ioctl.
>
>>
>> > If you want to treat touch and pen as completely independent devices -
>> > we can do that too but as you remember there are some issues with
>> > "pairing" of the devices.
>>
>> No, this issue has nothing to do with separating pen and touch
>> devices. This is for BUTTONS only. Those button events can come from
>> the physical tools (pen, mouse, lens, etc.) or the tablet itself.
>> Without knowing that the button events are from the ones that
>> physically sit on the tablet, it may mess up with the buttons that are
>> from the physical tools.
>>
>> You might have mixed my BTN_TOOL_TOUCH request with this patch.
>
> No, I have not. Again, if actions are different then physical buttons
> should emit different events. If actions are the same then events are
> the same and it does not matter whether user pushed button on the
> touchpad or the mouse.

All right. I'll submit a patch to close this request. The
BTN_TOOL_TOUCH request is still open though.

Thank you,

Ping
--
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/