Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <95576534-1f5e-c2e3-4f73-c1b0a8300b56@gmail.com>
Date:   Sun, 24 Apr 2022 01:19:30 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.8.1
Subject: Re: Status on hid xppen patch
Content-Language: en-US
To:     =?UTF-8?B?Sm9zw6kgRXhww7NzaXRv?= <jose.exposito89@gmail.com>
Cc:     jikos@kernel.org, benjamin.tissoires@redhat.com, spbnick@gmail.com,
        linux-input@vger.kernel.org, linux-kernel@vger.kernel.org
References: <941a793a-d2f7-9c2c-59be-b3930e1acfec@gmail.com>
 <20220423172330.32585-1-jose.exposito89@gmail.com>
From:   Stefan Berzl <stefanberzl@gmail.com>
In-Reply-To: <20220423172330.32585-1-jose.exposito89@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Precedence: bulk

>> 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@gmail.com/
>>
>> 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@gmail.com/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.

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!

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?

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.   

Lets fixie wixie this fucksy uppsy!

Bye


Stefan Berzl