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:

quoted

Hello!

quoted

quoted

quoted

From f9bb82e400effd3aea37b2be710add9e2bb832da Mon Sep 17 00:00:00 2001

From: Stefan Berzl <redacted>
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.

quoted

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

quoted

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

quoted

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