linux-kernel - Re: [RFC] UCLogic: Filtering unsupported HUION tablets

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <47970684-1158-cee8-9ff5-d7dca70a54ae@gmail.com>
Date:   Wed, 20 Jul 2022 20:45:55 +0300
From:   Nikolai Kondrashov <spbnick@...il.com>
To:     José Expósito <jose.exposito89@...il.com>
Cc:     jikos@...nel.org, benjamin.tissoires@...hat.com,
        linux-input@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC] UCLogic: Filtering unsupported HUION tablets

On 7/20/22 20:36, José Expósito wrote:
> Hi Nikolai,
> 
> Thanks a lot for the quick response.
> 
> On Tue, Jul 19, 2022 at 12:57:09PM +0300, Nikolai Kondrashov wrote:
>> Hi José,
>>
>> First of all, thanks a lot for all the work you're doing with the tablets!
>>
>> Yes, this situation is unfortunate, but there's really not much we could do.
>> The tablet database at http://digimend.github.io/tablets/ hasn't been
>> updated in ages, and it has never been exhaustive to start with.
>>
>> There are tons of tablet modifications, including of the same (marketed)
>> model, and those can differ not only in the reported name, but probably even
>> the VID:PID, as could've happened when Huion switched from v1 to v2
>> protocol.
>>
>> So, I think a "whitelist" would be a maintenance nightmare.
>>
>> Moreover, I think it's better to disable the tablet completely in case we
>> failed initialization (e.g. got an invalid response to configuration, or
>> failed to find some interfaces and such), after producing a comprehensive
>> error message. Configuring a tablet partially, and then handing it over to
>> the generic driver could mess things up more.
>>
>> It's less confusing for the user, and stops them from trying to fix the
>> problem up the stack with various settings, often getting into a worse
>> situation. It's also much easier for the maintainer, since they don't need
>> to investigate all the higher layers.
>>
>> A "blacklist" would work better here, if you can find the tablets to include.
>>
>> Nick
> 
> That makes sense, thanks for the pointers.
> 
> It is unfortunate that we don't have the required information about the
> supported tablets. Excluding the unsupported tablets (when fixing them
> is not possible for reasons) seems like a reasonable approach.
> 
> I don't know about any broken device handled by the driver, so there is
> no need to add new code yet :)
> I'll try to keep an eye on DIGImend's issue tracker now that the code
> present in the upstream kernel is being released by many distros.

If you have the time, backporting your changes to digimend-kernel-drivers 
would get you feedback much faster :)

I can do a release once we get the code in.

Nick