[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a817b3d3-f749-e4e9-dd7c-7e97cfc8d57e@gmail.com>
Date: Fri, 24 Jun 2022 09:08:11 +0300
From: Nikolai Kondrashov <spbnick@...il.com>
To: Stefan Berzl <stefanberzl@...il.com>,
José Expósito <jose.exposito89@...il.com>
Cc: Jiri Kosina <jikos@...nel.org>, benjamin.tissoires@...hat.com,
linux-input@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] hid: Add support for the xp-pen deco mini7 tablet
On 6/24/22 01:46, Stefan Berzl wrote:
> Hi!
>
> On 23/06/2022 20:01, Nikolai Kondrashov wrote:
>> On 6/23/22 20:51, José Expósito wrote:
>>>> I would of course fix this, but I don't really know what's the preferred
>>>> way. One can obviously simply set up an urb to catch this, but it would
>>>> have to be a special corner case for the mini 7, as José assures me that
>>>> none of his tablets display similar behavior. Is this acceptable?
>>>
>>> My tablets also send an ACK packet, but in my case it does not have any
>>> visible effects. Maybe it is related to the DE environment used. I
>>> tested it on elementary OS (Ubuntu) and Fedora 36, in both cases the
>>> ACK is ignored... But catching it is fine, we can include the code you
>>> suggest.
>>>
>>>> José already had a look at some firmware device descriptor string that
>>>> reports the number of buttons and what not, but as far as I know, it
>>>> doesn't say anything about ack packets (right José? Does it say
>>>> anything about touch strips or similar?).
>>>
>>> In the devices I tested, the ACK packet is always present, so it should
>>> be fine to catch it. I'll test your patch in all the devices I own to
>>> be safe.
>>
>> I think it's OK to just ignore the first packet for these devices, even if the ACK packet is not sent for some of them. Even with the report rate of 20 years ago nobody would've noticed if you dropped one packet.
>>
>> Nick
>
> Sounds good indeed. Does it also work if the user presses a button first?
> The way I get it, we would only receive the button up event then, not the
> button down?
It's basically humanly impossible to register a pen's button press without
first producing some movement reports. You have to hold the pen within range
for it to register, and it's hard to hold it still enough within range to not
produce movement reports, while also trying to press a button. I think we're
safe here.
If there are any buttons on the frame, then it's likely possible to
distinguish their reports from the pen ones by looking at the report contents
before discarding.
Nick
Powered by blists - more mailing lists