Message-ID: <20161007234601.GA22149@dtor-ws>
Date:   Fri, 7 Oct 2016 16:46:01 -0700
From:   Dmitry Torokhov <dmitry.torokhov@...il.com>
To:     Hn Chen <hn.chen@...dahitech.com>
Cc:     Benjamin Tissoires <benjamin.tissoires@...hat.com>,
        "linux-input@...r.kernel.org" <linux-input@...r.kernel.org>,
        lkml <linux-kernel@...r.kernel.org>
Subject: Re: [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@...hat.com] 
> Sent: Monday, September 05, 2016 9:56 PM
> To: Hn Chen
> Cc: Dmitry Torokhov; linux-input@...r.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

Powered by blists - more mailing lists