Re: [PATCH] hid: Add support for the xp-pen deco mini7 tablet

[Stefan Berzl <stefanberzl@gmail.com>]

Hello there!

On 23/06/2022 19:51, José Expósito wrote:
> Hi Stefan,
> 
> On Wed, Jun 22, 2022 at 11:31:05PM +0200, Stefan Berzl wrote:
>> Hello!
>>
>>>> >From f9bb82e400effd3aea37b2be710add9e2bb832da Mon Sep 17 00:00:00 2001
>>>> From: Stefan Berzl <stefanberzl@gmail.com>
>>>> Date: Fri, 11 Mar 2022 04:04:30 +0100
>>>> Subject: [PATCH] hid: Add support for the xp-pen deco mini7 tablet
>>>>
>>>> ...
>>>
>>> Stefan,
>>>
>>> sorry for not responding earlier, but this patch somehow fell in between 
>>> cracks. Please for your further submissions do not forget to at least CC 
>>> some of the relevant malinglists as well.
>>
>> Will do... I am still new to the process and tend to forget things, but 
>> I'll do my best.
>>
>>> Quite a lot has changed in uclogic driver since then, as José has been 
>>> pushing quite a lot of code there from DIGImend project ... could you 
>>> please update your patch on top of current codebase and resend it?
>>>
>>> Thanks,
>>>
>>
>> I think you'll be pleased to find that José's work is basically a 
>> superset of mine, therefore eliminating the need for my patch 
>> altogether. When running his newest deco l code, the deco mini 7 is 
>> fully supported as well. I should have given a tested-by or something, 
>> but since I am still new to this, I was kinda hesitant with the big 
>> changes introduced by the newest digimend work. As you know, there is no 
>> sort of registry to differentiate devices by ability, so one or two
>> useless evdev devices are generated for hardware the tablet may or may 
>> not have, like "Touch Ring" or "Touch Strip". I thought that this might 
>> cause confusion and would have to be amended.
> 
> Useless event nodes should not be created. At the moment, the driver
> disables all interfaces that are not used and, after switching to "raw"
> mode, it should only create a node for each valid device.
> 
> At the moment, there are only HID descriptors for the frame and the pen
> so, if your tablet is creating a touch ring device, something is not
> working as expected.
> 
> Running "sudo libinput record" should display only the frame and the
> pen. Does it show something different in your case?
> 
> 	$ sudo libinput record
> 	[...]
> 	/dev/input/event21:	Hanvon Ugee Technology Co.,Ltd Deco L
> 	/dev/input/event22:	Hanvon Ugee Technology Co.,Ltd Deco L Pad

This is certainly true for the newer xppen devices we are working on. 
However, while waiting for the xppen stuff to gain support, I bought a
tablet  that's already supported, the Gaomon S620. Executing libinput 
record or any other command that lists the devices, like evemu-describe, 
gives:

/dev/input/event15: GAOMON Gaomon Tablet
/dev/input/event16: GAOMON Gaomon Tablet Pad
/dev/input/event17: GAOMON Gaomon Tablet Touch Strip
/dev/input/event18: GAOMON Gaomon Tablet Dial

>> There is however one caveat that seems to be unique to the mini7, which 
>> is the ack packet that is sent when switching to the vendor defined 
>> usage. It doesn't do much though, as currently it gets interpreted as a 
>> pen report and since it doesn't have useful values, causes the cursor to 
>> go to the top left screen position. Since the ack packet is only sent 
>> once, it ought to be of little consequence.
>>
>> 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.

Can the contents maybe differ?

This is the ack the mini 7 gives me:
02 b1 04 00 00 00 00 00 00 00 00 00

While this is a button:
02 f0 00 00 00 00 00 00 00 00 00 00

And here we have pen movement:
02 a1 59 23 ef 32 b8 0e 00 00 00 00

>> 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.
> 
> Best wishes,
> Jose
> 

Yours truly
Stefan Berzl