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: <47970684-1158-cee8-9ff5-d7dca70a54ae@gmail.com>
Date:   Wed, 20 Jul 2022 20:45:55 +0300
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.10.0
Subject: Re: [RFC] UCLogic: Filtering unsupported HUION tablets
Content-Language: en-US
To:     =?UTF-8?B?Sm9zw6kgRXhww7NzaXRv?= <jose.exposito89@gmail.com>
Cc:     jikos@kernel.org, benjamin.tissoires@redhat.com,
        linux-input@vger.kernel.org, linux-kernel@vger.kernel.org
References: <20220718172953.6817-1-jose.exposito89@gmail.com>
 <5d4ef0df-083f-a00e-fb41-1ce1df6e9473@gmail.com>
 <20220720173656.GA3725@elementary>
From:   Nikolai Kondrashov <spbnick@gmail.com>
In-Reply-To: <20220720173656.GA3725@elementary>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk

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