Re: Status on hid xppen patch

[José Expósito]

Hi Stefan,

On Sun, Apr 24, 2022 at 01:19:30AM +0200, Stefan Berzl wrote:
> >> Hello everynyan!
> >>
> >> A while ago I sent in a patch to add support for newer Xp-pen tablets 
> >> that even made it into patchwork:
> >>
> >> https://patchwork.kernel.org/project/linux-input/patch/b401e453-9c66-15e3-1a1d-21f33b7a64e8@xxxxxxxxx/
> >>
> >> I have never actually gotten any feedback on it though and am wondering 
> >> if everything is to your liking. Anyway it doesn't build against the 
> >> current tree anymore. Assuming there is any value it, should I rewrite 
> >> it against hid master or hid uclogic?
> >>
> >> Many thanks
> >>
> >> Stefan Berzl
> > 
> > Hi Stefan,
> > 
> > I just saw your email in the mailing list.
> > 
> > Your patch doesn't apply against the current tree because of the changes
> > from Nikolai/the DIGImend project I'm sending upstream. For reference,
> > here is the latest batch of patches, with links to the previous ones:
> > 
> > https://lore.kernel.org/linux-input/20220421175052.911446-1-jose.exposito89@xxxxxxxxx/T/
> > 
> > Please note that I'm not the maintainer of the driver, I'm just a web
> > developer who does free software as a hobby, i.e., this is not my area
> > of expertise, so take my words as suggestions, not as the path to
> > follow ;)
> > 
> > The development of the uclogic driver takes place on the DIGImend
> > project (inactive right now):
> > https://github.com/DIGImend/digimend-kernel-drivers
> > 
> > Like you, I wanted to add support for my tablet/improve my kernel
> > dev skills, but I noticed that I needed some patches from DIGImend, so,
> > instead of taking what I needed, I decided to upstream all the patches.
> > 
> > At the moment of writing this email, 24 patches from DIGImend have been
> > merged, 5 are under review and 7 more need to be sent. We are close to
> > the end.
> > 
> > My tablet (Parblo A610 PLUS V2) also needs some magic data to be enabled.
> > Actually, the data is pretty similar to the one in your patch.
> > You can see my implementation here:
> > https://github.com/JoseExposito/linux/commit/f1f24e57fab45a2bcf4e0af5ba9d8f5a2245670b
> > 
> > I just refactored my patch and extracted the code to send the magic data
> > to its own function (uclogic_probe_interface), so we can share it.
> > 
> > I'd suggest rebasing your code on top of DIGImend's code + my patch
> > so we can share some code and once all patches are upstream, you can
> > send it with minor or without conflicts.
> > 
> > What do you think?
> > 
> > José Expósito
> > 
> 
> Hello José,
> 
> nice hearing from you. I was actually thinking of just asking if you
> want to take my patch under your wing, since you seem to be doing a lot
> of uclogic related work. But your idea is even better, just submitting  
> my patch once everything has settled down seems to be the way to go.

Cool, let's do that. I'll cc you on the last batch of patches so you
get notified when they get merged.
 
> You are actually the first person to ever contact me about this. I was  
> pretty worried that the patch is no good, but then I saw that there is  
> quite a backlog in the maintainers patchwork and some of your patches
> haven't been reviewed either. Originally I tried showing it to Nikolai,
> but he said he was rather busy too and then some guys in the Digimend
> project tried to get me interested in some userspace driver that works  
> around all the issues of like init-packets and stuff. I always imagined
> the kernel as this highly organzied, well-structured endeavor where
> things would be quickly scrutinized and suggestions offered to assure 
> the highest quality. Yet here we have two web developers working on the
> graphics tablet driver. Let me say that it's really great you take the
> time and effort to mainline these patches and help everyone enjoy their
> tablets on linux!

Well, the kernel is well-structured, but as you mentioned, there is a
*lot* of work on the maintainers side and I think there is not a big
community supporting this driver. It's normal that it takes some time
to get everything reviewed.

> On the technical side, the magic bytes really are very similar, the only
> difference being the two additional trailing 0x00 for mine. Also my
> tablet sends a response after activating this new interface which can 
> get interpreted as a button press if it's not discarded. Is there a nice
> way to work around this, with subreports or anything?

Same here, my tablet responds with: 02 b1 04 00 00 00 00 00 00 00.

In my case, button presses look like: 02 F0 XX XX 00 00 00 00 00 00.
Because of the 0xF0 subreport, I think this data gets ignored, but I'll
do some extra testing just in case.

How did you test it?

> Lastly, do you have an idea in which kernel version the bulk of your
> patches will have been merged, just so I know when to start looking at
> this again? I don't mean to belittle the kernel maintainers of course,  
> for I am sure they have more pressing and difficult issues on their
> plate, like eBPF and such.   

I couldn't tell, I can imagine that 5.19 or 5.20. Anyway, I'll cc you
so you can have a good idea about what's going on.

Best wishes,
José Expósito

> Lets fixie wixie this fucksy uppsy!
> 
> Bye
> 
> 
> Stefan Berzl