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@xxxxxxxxx> >>>> 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
