lkml.org 
[lkml]   [2016]   [Oct]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] Input: wdt87xx_i2c - support new body WDT8752
Hi Hn,

On Tue, Sep 06, 2016 at 11:47:39AM +0000, Hn Chen wrote:
> Hi Benjamin,
>
> Sorry for my poor English and leading you misunderstanding.
>
> The FW of WDT8752 can support HIDI2C for Windows products. And then we develop this driver.
> So we "borrowed" something from HIDI2C.
> What I try to mention here is that this driver utilize a part of existed protocol from HIDI2C.
> We thought that the size of FW can be shrunk in that way.
>
> So, basically, this is still a linux i2c driver with some protocols similar to HIDI2C.

If you already have hardware and firmware that supports HIDI2C, why not
continue using it? Linux's hid-multitouch driver should be able to
handle Win-compatible touchscreens out of the box (or maybe with a small
quirk).

What are the features that require the brand new driver?

Thanks.

>
> BR,
> Hn.chen
>
> -----Original Message-----
> From: Benjamin Tissoires [mailto:benjamin.tissoires@redhat.com]
> Sent: Monday, September 05, 2016 9:56 PM
> To: Hn Chen
> Cc: Dmitry Torokhov; linux-input@vger.kernel.org; lkml
> Subject: Re: [PATCH] Input: wdt87xx_i2c - support new body WDT8752
>
> Hi HN,
>
> On Sep 05 2016 or thereabouts, Hn Chen wrote:
> > Hi Dmitry,
> >
> > >> Considering to be compatible with i2c-hid, WDT8752 has the same way
> > >> in enumerating device.
> > >If it is a HID device then I think you should write a HID driver for it (unless existing driver, such as hid-multitouch can already handle it, possibly >with some changes). I'm addng Benjamin to he can comment as well.
> > The device can be handled by i2c-hid driver (HID over I2C) already but this proprietary driver still is a must-have for more features.
>
> Then what are those must-have features? From what I can read, only the reflashing firmware is part of it. Unless there is something else, I really don't understand why you can't have a hid-weidatech driver that could handle the specific bits while leaving the rest to i2c-hid.
>
> Also, I am not sure if your driver doesn't interfere with i2c-hid as you are claiming the device through the ACPI ID "WDHT0001" but there should be some PNP IDs "PNP0C50" if it were declared as i2c-hid. If both are set, then the fact your driver is picked up seems to be pure luck: there will be a race between the probe of your driver and i2c-hid, which is not something you want.
>
> If there are some issues with i2c-hid, I'd like also to know them because if we fix them for you there is a high chance other vendors will benefit from those fixes too.
>
> Cheers,
> Benjamin
>
> >
> > >> And also modify the part of FW update to be more efficiency. The
> > >> main modification is that reducing the amount of data transmitted
> > >> and using polling for time comsuming operation.
> > >>
> > >> Flash erase will wait 50ms for the operation complete in last driver.
> > >> Extend it to 200ms since the spec says the typical is 30ms but the
> > >> max is 200ms.
> > >This should be split into a separate patch please.
> > Ok, I will resubmit the part of possible-issue fixing and then the driver patch for supporting WDT8752 again.
> > Please ignore this submission.
> >
> > Hn.chen

--
Dmitry

\
 
 \ /
  Last update: 2016-10-08 01:47    [W:0.281 / U:0.016 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site