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] [day] [month] [year] [list]
Message-ID: <20220625153030.GB4820@elementary>
Date:   Sat, 25 Jun 2022 17:30:30 +0200
From:   José Expósito <jose.exposito89@...il.com>
To:     Stefan Berzl <stefanberzl@...il.com>
Cc:     Jiri Kosina <jikos@...nel.org>, benjamin.tissoires@...hat.com,
        spbnick@...il.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 Fri, Jun 24, 2022 at 12:24:09AM +0200, Stefan Berzl wrote:
> On 23/06/2022 19:51, José Expósito wrote:
> > 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

Ah OK, I though you were talking about the XP-PEN device. I don't know why
those extra event nodes are created, sorry.
 
> >> 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

Yes, the contents are different. My ACK does not contain the last 2 bytes.
As mentioned in my previous email, I think that because the ACK of your
tablet matches the size of a pen report and starts with 02 it is handled as
a pen report.

Jose

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ