| Message ID | 20210829091925.190-7-alistair@alistair23.me |
|---|---|
| State | New |
| Headers | show |
| Series | Add Wacom I2C support to rM2 | expand |
On Sun, Aug 29, 2021 at 07:19:18PM +1000, Alistair Francis wrote: > When we query the device let's also read the descriptor from the device. > This tells us useful information, including the version, which we use to > determine a generation. > > This is based on the driver from Wacom. > > Signed-off-by: Alistair Francis <alistair@alistair23.me> > --- > drivers/input/touchscreen/wacom_i2c.c | 64 +++++++++++++++++++++++++++ > 1 file changed, 64 insertions(+) > > diff --git a/drivers/input/touchscreen/wacom_i2c.c b/drivers/input/touchscreen/wacom_i2c.c > index 28255c77d426..72ba4a36459b 100644 > --- a/drivers/input/touchscreen/wacom_i2c.c > +++ b/drivers/input/touchscreen/wacom_i2c.c > @@ -16,6 +16,7 @@ > #include <linux/of.h> > #include <asm/unaligned.h> > > +#define WACOM_DESC_REG 0x01 > #define WACOM_CMD_QUERY0 0x04 > #define WACOM_CMD_QUERY1 0x00 > #define WACOM_CMD_QUERY2 0x33 > @@ -24,11 +25,46 @@ > #define WACOM_CMD_THROW1 0x00 > #define WACOM_QUERY_SIZE 19 > > +#define WACOM_MAX_DATA_SIZE_BG9 10 > +#define WACOM_MAX_DATA_SIZE_G12 15 > +#define WACOM_MAX_DATA_SIZE_AG14 17 > +#define WACOM_MAX_DATA_SIZE 22 > + > +/* Generation selction */ > +/* Before and at G9 generation */ > +#define WACOM_BG9 0 > +/* G12 generation the IC supports "height"*/ > +#define WACOM_G12 1 > +/* After and at G14 generation the IC supports "height" and > + * it is defined as "Z" axis > + */ > +#define WACOM_AG14 2 > + > +struct wacom_desc { > + u16 descLen; > + u16 version; > + u16 reportLen; > + u16 reportReg; > + u16 inputReg; > + u16 maxInputLen; > + u16 outputReg; > + u16 maxOutputLen; > + u16 commReg; > + u16 dataReg; > + u16 vendorID; > + u16 productID; > + u16 fwVersion; > + u16 misc_high; > + u16 misc_low; > +}; This looks like I2C HID descriptor. Is the device actually I2C HID compatible? If so we should use that and abandon this driver. Ping, Tatsunosuke, please advise. Thanks. -- Dmitry
Hi Tatsunosuke, On Thu, Sep 02, 2021 at 07:33:49AM +0000, Tobita, Tatsunosuke wrote: > Hi Dmitry, > > Yes, our firmware supports HID over I2C. However, some of our > customers often do not want to use HID to handle our hardware; even > they don't install the generic HID driver neither. In such case, we > need to distinguish what generation of our device customer's has. And > to do so, we check I2C HID descriptor even though the driver is not > working with HID driver components, but this one. That is why I2C HID > descriptor is used there. It is called, but the situation with this > driver is not supposed to work as a HID device. I would like to understand better why the customers do not want to use HID. There needs to be a _very_ strong reason to essentially duplicate HID layer in a vendor driver and I inclined to say that such customers would need to patch their kernels themselves. Thanks. -- Dmitry
Hi Ping, On Tue, Sep 07, 2021 at 10:25:43PM -0700, Ping Cheng wrote: > Hi Dmitry, > > On Mon, Sep 6, 2021, 11:05 PM Dmitry Torokhov <dmitry.torokhov@gmail.com> > wrote: > > > Hi Tatsunosuke, > > > > On Thu, Sep 02, 2021 at 07:33:49AM +0000, Tobita, Tatsunosuke wrote: > > > Hi Dmitry, > > > > > > Yes, our firmware supports HID over I2C. However, some of our > > > customers often do not want to use HID to handle our hardware; even > > > they don't install the generic HID driver neither. In such case, we > > > need to distinguish what generation of our device customer's has. And > > > to do so, we check I2C HID descriptor even though the driver is not > > > working with HID driver components, but this one. That is why I2C HID > > > descriptor is used there. It is called, but the situation with this > > > driver is not supposed to work as a HID device. > > > > I would like to understand better why the customers do not want to use > > HID. > > > Those customers normally run embedded Linux. Their hardwares have very > specific use cases. They don't need to support any other HID devices except > the Wacom i2c device. > > > > There needs to be a _very_ strong reason to essentially duplicate > > HID layer in a vendor driver and I inclined to say that such customers > > would need to patch their kernels themselves. > > > They most likely don't want to duplicate HID layer. They just don't need > most of the HID layer code. They just need touchscreen support. Plus stylus support. And maybe battery support. And maybe something else down the road... And they need to introduce DT and ACPI descriptors to be able to mould the behavior to platform needs. Which is pretty much the purpose of HID layer. > wacom_i2c simplifies their deployment and > testing process. Most of those customers are very small companies... And now please continue this train of thoughts and consider every touch vendor. Wacom is not unique. We have Elan, Cypress, Weida, Goodix, etc. etc. Vendor drivers were acceptable before we had I2C standard, but now it is much better for everyone to share the efforts and use HID instead of replicating it for every vendor. Thanks.
Hi Ping, On Fri, Sep 17, 2021 at 01:43:18PM -0700, Ping Cheng wrote: > Hi Dmitry, > > On Tue, Sep 7, 2021 at 10:55 PM Dmitry Torokhov > <dmitry.torokhov@gmail.com> wrote: > > > > > > > > > > > > Yes, our firmware supports HID over I2C. However, some of our > > > > > customers often do not want to use HID to handle our hardware; even > > > > > they don't install the generic HID driver neither. In such case, we > > > > > need to distinguish what generation of our device customer's has. And > > > > > to do so, we check I2C HID descriptor even though the driver is not > > > > > working with HID driver components, but this one. That is why I2C HID > > > > > descriptor is used there. It is called, but the situation with this > > > > > driver is not supposed to work as a HID device. > > > > > > > > I would like to understand better why the customers do not want to use > > > > HID. > > > > > > > > > Those customers normally run embedded Linux. Their hardwares have very > > > specific use cases. They don't need to support any other HID devices except > > > the Wacom i2c device. > > > > > > > > > > There needs to be a _very_ strong reason to essentially duplicate > > > > HID layer in a vendor driver and I inclined to say that such customers > > > > > > would need to patch their kernels themselves. > > > > > > They most likely don't want to duplicate HID layer. They just don't need > > > most of the HID layer code. > > > > They just need touchscreen support. Plus stylus support. And maybe > > battery support. And maybe something else down the road... And they need > > to introduce DT and ACPI descriptors to be able to mould the behavior to > > platform needs. Which is pretty much the purpose of HID layer. > > I see your point. > > > > wacom_i2c simplifies their deployment and > > > testing process. Most of those customers are very small companies... > > > > And now please continue this train of thoughts and consider every touch > > vendor. Wacom is not unique. We have Elan, Cypress, Weida, Goodix, etc. > > etc. Vendor drivers were acceptable before we had I2C standard, but now > > it is much better for everyone to share the efforts and use HID instead > > of replicating it for every vendor. > > And I agree with you that we should share our efforts on the main tasks. > > However, with the same token of sharing efforts, I see the benefit of > merging this set of patches upstream. From the version number we can > tell the patchset has gone through at least 10 rounds of review and > update. Alistair has put a lot of effort to get this far (Thank you > Alistair for your time and effort!). I am sorry, but the fact that a developer spent a lot of time writing code can not be used as a justification for merging said code. > A few community developers have > also reviewed the patches. This set of patches thoroughly touched all > parts of the components that related to an input i2c driver, which is > much better than the original version. This patchset would be a great > starting point for vendors to create their out of tree drivers, when > necessary. It would also offer vendors a clear picture of what > components they need to change/update to make their i2c input device > work under kernel input subsystem. And they can do that by looking at the mailing list archive and they can also follow this discussion and see why what they are doing is quite wrong. I mean, why would they stop at dropping HID only? Why not bypass I2C system as well and poke at the I2C controller directly. Skip PCI as well? > > So, merging the patchset will benefit more people and preserve the > effort that went into the patchset so far. If you like, you can add a > comment in the patch mentioning that future effort should be directed > to the i2c-hid subsystem, etc... No, we should not merge the patch set that we agreed is wrong in its approach. Maybe if I (and other community reviewers) realized that the device was HID compliant we could stop this effort earlier, but unfortunately it did not happen, so effort was wasted, but this happens sometimes. Thanks. -- Dmitry
On Tue, Sep 21, 2021 at 2:35 PM Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote: > > Hi Ping, > > On Fri, Sep 17, 2021 at 01:43:18PM -0700, Ping Cheng wrote: > > Hi Dmitry, > > > > On Tue, Sep 7, 2021 at 10:55 PM Dmitry Torokhov > > <dmitry.torokhov@gmail.com> wrote: > > > > > > > > > > > > > > > Yes, our firmware supports HID over I2C. However, some of our > > > > > > customers often do not want to use HID to handle our hardware; even > > > > > > they don't install the generic HID driver neither. In such case, we > > > > > > need to distinguish what generation of our device customer's has. And > > > > > > to do so, we check I2C HID descriptor even though the driver is not > > > > > > working with HID driver components, but this one. That is why I2C HID > > > > > > descriptor is used there. It is called, but the situation with this > > > > > > driver is not supposed to work as a HID device. > > > > > > > > > > I would like to understand better why the customers do not want to use > > > > > HID. > > > > > > > > > > > > Those customers normally run embedded Linux. Their hardwares have very > > > > specific use cases. They don't need to support any other HID devices except > > > > the Wacom i2c device. > > > > > > > > > > > > > There needs to be a _very_ strong reason to essentially duplicate > > > > > HID layer in a vendor driver and I inclined to say that such customers > > > > > > > > would need to patch their kernels themselves. > > > > > > > > They most likely don't want to duplicate HID layer. They just don't need > > > > most of the HID layer code. > > > > > > They just need touchscreen support. Plus stylus support. And maybe > > > battery support. And maybe something else down the road... And they need > > > to introduce DT and ACPI descriptors to be able to mould the behavior to > > > platform needs. Which is pretty much the purpose of HID layer. > > > > I see your point. > > > > > > wacom_i2c simplifies their deployment and > > > > testing process. Most of those customers are very small companies... > > > > > > And now please continue this train of thoughts and consider every touch > > > vendor. Wacom is not unique. We have Elan, Cypress, Weida, Goodix, etc. > > > etc. Vendor drivers were acceptable before we had I2C standard, but now > > > it is much better for everyone to share the efforts and use HID instead > > > of replicating it for every vendor. > > > > And I agree with you that we should share our efforts on the main tasks. > > > > However, with the same token of sharing efforts, I see the benefit of > > merging this set of patches upstream. From the version number we can > > tell the patchset has gone through at least 10 rounds of review and > > update. Alistair has put a lot of effort to get this far (Thank you > > Alistair for your time and effort!). > > I am sorry, but the fact that a developer spent a lot of time writing > code can not be used as a justification for merging said code. > > > A few community developers have > > also reviewed the patches. This set of patches thoroughly touched all > > parts of the components that related to an input i2c driver, which is > > much better than the original version. This patchset would be a great > > starting point for vendors to create their out of tree drivers, when > > necessary. It would also offer vendors a clear picture of what > > components they need to change/update to make their i2c input device > > work under kernel input subsystem. > > And they can do that by looking at the mailing list archive and they can > also follow this discussion and see why what they are doing is quite > wrong. I mean, why would they stop at dropping HID only? Why not bypass > I2C system as well and poke at the I2C controller directly. Skip PCI as > well? > > > > > So, merging the patchset will benefit more people and preserve the > > effort that went into the patchset so far. If you like, you can add a > > comment in the patch mentioning that future effort should be directed > > to the i2c-hid subsystem, etc... > > No, we should not merge the patch set that we agreed is wrong in its > approach. Maybe if I (and other community reviewers) realized that the > device was HID compliant we could stop this effort earlier, but > unfortunately it did not happen, so effort was wasted, but this happens > sometimes. Should I prepare a patch to remove the wacom I2C driver entirely then? Alistair > > Thanks. > > -- > Dmitry
Hi Dmitry, I now understand what you mean. The understandable example is USB. The most of the recent drivers for USB devices has bee released as HiD driver. That said. It's glad if you can have comments too about my questions. Especially, when someone doesn't want the whole HID driver, but a single I2C I/F'd input device driver. And also, I want to make correction that ***not*** all of our devices support HID. Some old devices do not support HID; that's why I added the driver in 2011. Thanks, Tats -----Original Message----- From: Tobita, Tatsunosuke <tatsunosuke.tobita@wacom.com> Sent: Friday, September 10, 2021 1:10 PM To: Dmitry Torokhov <dmitry.torokhov@gmail.com>; Ping Cheng <pinglinux@gmail.com> Cc: Alistair Francis <alistair@alistair23.me>; Cheng, Ping <Ping.Cheng@wacom.com>; linux-input <linux-input@vger.kernel.org>; linux-imx@nxp.com; kernel@pengutronix.de; Tatsunosuke Tobita <junkpainting@gmail.com>; linux-kernel@vger.kernel.org; alistair23@gmail.com; robh+dt@kernel.org; devicetree@vger.kernel.org Subject: RE: [PATCH v10 05/12] Input: wacom_i2c - Read the descriptor values [EXTERNAL] Hi Dmitry and Ping, I understand that we should stick with HID as much as possible. However, there're certainly situations in which some do not want even whole HID, but only an individual functionality for a certain device. In that case, they may not even include the bit of the HID, but exclude HID. What about then; what they should do without HID? This would be also the questions if such situations happened to other vendors than Wacom. Also, what I need to add is that the early generations of our I2C devices do not support HID which is why "wacom_i2c" was added in 2011. Tats -----Original Message----- From: Dmitry Torokhov <dmitry.torokhov@gmail.com> Sent: Wednesday, September 8, 2021 2:56 PM To: Ping Cheng <pinglinux@gmail.com> Cc: Tobita, Tatsunosuke <tatsunosuke.tobita@wacom.com>; Alistair Francis <alistair@alistair23.me>; Cheng, Ping <Ping.Cheng@wacom.com>; linux-input <linux-input@vger.kernel.org>; linux-imx@nxp.com; kernel@pengutronix.de; Tatsunosuke Tobita <junkpainting@gmail.com>; linux-kernel@vger.kernel.org; alistair23@gmail.com; robh+dt@kernel.org; devicetree@vger.kernel.org Subject: Re: [PATCH v10 05/12] Input: wacom_i2c - Read the descriptor values [EXTERNAL] Hi Ping, On Tue, Sep 07, 2021 at 10:25:43PM -0700, Ping Cheng wrote: > Hi Dmitry, > > On Mon, Sep 6, 2021, 11:05 PM Dmitry Torokhov > <dmitry.torokhov@gmail.com> > wrote: > > > Hi Tatsunosuke, > > > > On Thu, Sep 02, 2021 at 07:33:49AM +0000, Tobita, Tatsunosuke wrote: > > > Hi Dmitry, > > > > > > Yes, our firmware supports HID over I2C. However, some of our > > > customers often do not want to use HID to handle our hardware; > > > even they don't install the generic HID driver neither. In such > > > case, we need to distinguish what generation of our device > > > customer's has. And to do so, we check I2C HID descriptor even > > > though the driver is not working with HID driver components, but > > > this one. That is why I2C HID descriptor is used there. It is > > > called, but the situation with this driver is not supposed to work as a HID device. > > > > I would like to understand better why the customers do not want to > > use HID. > > > Those customers normally run embedded Linux. Their hardwares have very > specific use cases. They don't need to support any other HID devices > except the Wacom i2c device. > > > > There needs to be a _very_ strong reason to essentially duplicate > > HID layer in a vendor driver and I inclined to say that such > > customers > > would need to patch their kernels themselves. > > > They most likely don't want to duplicate HID layer. They just don't > need most of the HID layer code. They just need touchscreen support. Plus stylus support. And maybe battery support. And maybe something else down the road... And they need to introduce DT and ACPI descriptors to be able to mould the behavior to platform needs. Which is pretty much the purpose of HID layer. > wacom_i2c simplifies their deployment and testing process. Most of > those customers are very small companies... And now please continue this train of thoughts and consider every touch vendor. Wacom is not unique. We have Elan, Cypress, Weida, Goodix, etc. etc. Vendor drivers were acceptable before we had I2C standard, but now it is much better for everyone to share the efforts and use HID instead of replicating it for every vendor. Thanks. -- Dmitry
Hi Tatsunosuke, On Wed, Oct 06, 2021 at 07:08:38AM +0000, Tobita, Tatsunosuke wrote: > Hi Dmitry, > > I now understand what you mean. The understandable example is USB. The > most of the recent drivers for USB devices has bee released as HiD > driver. That said. It's glad if you can have comments too about my > questions. Especially, when someone doesn't want the whole HID > driver, but a single I2C I/F'd input device driver. So far I have not heard a good reason for "not wanting" to use a standard, well tested solution that everyone else is using, and instead having a custom driver that essentially reimplements everything that HID layer already does. Is the additional memory requirements of HID layer too onerous? Can we address that instead? If we continue this train of thought, why are they concerned with HID, but happy with using I2C layer? Why don't they require a driver that bangs directly onto I2C master ports bypassing all the layersi and communicating with the peripheral directly? > And also, I want to make correction that ***not*** all of our devices > support HID. Some old devices do not support HID; that's why I added > the driver in 2011. And that is a good reason to keep existing version of wacom_i2c in the kernel, but we should not try to extend it to handle HID-compatible devices. Thanks, Dmitry > > Thanks, > > Tats > > -----Original Message----- > From: Tobita, Tatsunosuke <tatsunosuke.tobita@wacom.com> > Sent: Friday, September 10, 2021 1:10 PM > To: Dmitry Torokhov <dmitry.torokhov@gmail.com>; Ping Cheng <pinglinux@gmail.com> > Cc: Alistair Francis <alistair@alistair23.me>; Cheng, Ping <Ping.Cheng@wacom.com>; linux-input <linux-input@vger.kernel.org>; linux-imx@nxp.com; kernel@pengutronix.de; Tatsunosuke Tobita <junkpainting@gmail.com>; linux-kernel@vger.kernel.org; alistair23@gmail.com; robh+dt@kernel.org; devicetree@vger.kernel.org > Subject: RE: [PATCH v10 05/12] Input: wacom_i2c - Read the descriptor values > > [EXTERNAL] > > Hi Dmitry and Ping, > > I understand that we should stick with HID as much as possible. > However, there're certainly situations in which some do not want even whole HID, but only an individual functionality for a certain device. > In that case, they may not even include the bit of the HID, but exclude HID. What about then; what they should do without HID? > This would be also the questions if such situations happened to other vendors than Wacom. > > Also, what I need to add is that the early generations of our I2C devices do not support HID which is why "wacom_i2c" was added in 2011. > > > Tats > > -----Original Message----- > From: Dmitry Torokhov <dmitry.torokhov@gmail.com> > Sent: Wednesday, September 8, 2021 2:56 PM > To: Ping Cheng <pinglinux@gmail.com> > Cc: Tobita, Tatsunosuke <tatsunosuke.tobita@wacom.com>; Alistair Francis <alistair@alistair23.me>; Cheng, Ping <Ping.Cheng@wacom.com>; linux-input <linux-input@vger.kernel.org>; linux-imx@nxp.com; kernel@pengutronix.de; Tatsunosuke Tobita <junkpainting@gmail.com>; linux-kernel@vger.kernel.org; alistair23@gmail.com; robh+dt@kernel.org; devicetree@vger.kernel.org > Subject: Re: [PATCH v10 05/12] Input: wacom_i2c - Read the descriptor values > > [EXTERNAL] > > Hi Ping, > > On Tue, Sep 07, 2021 at 10:25:43PM -0700, Ping Cheng wrote: > > Hi Dmitry, > > > > On Mon, Sep 6, 2021, 11:05 PM Dmitry Torokhov > > <dmitry.torokhov@gmail.com> > > wrote: > > > > > Hi Tatsunosuke, > > > > > > On Thu, Sep 02, 2021 at 07:33:49AM +0000, Tobita, Tatsunosuke wrote: > > > > Hi Dmitry, > > > > > > > > Yes, our firmware supports HID over I2C. However, some of our > > > > customers often do not want to use HID to handle our hardware; > > > > even they don't install the generic HID driver neither. In such > > > > case, we need to distinguish what generation of our device > > > > customer's has. And to do so, we check I2C HID descriptor even > > > > though the driver is not working with HID driver components, but > > > > this one. That is why I2C HID descriptor is used there. It is > > > > called, but the situation with this driver is not supposed to work as a HID device. > > > > > > I would like to understand better why the customers do not want to > > > use HID. > > > > > > Those customers normally run embedded Linux. Their hardwares have very > > specific use cases. They don't need to support any other HID devices > > except the Wacom i2c device. > > > > > > > There needs to be a _very_ strong reason to essentially duplicate > > > HID layer in a vendor driver and I inclined to say that such > > > customers > > > > would need to patch their kernels themselves. > > > > > > They most likely don't want to duplicate HID layer. They just don't > > need most of the HID layer code. > > They just need touchscreen support. Plus stylus support. And maybe battery support. And maybe something else down the road... And they need to introduce DT and ACPI descriptors to be able to mould the behavior to platform needs. Which is pretty much the purpose of HID layer. > > > wacom_i2c simplifies their deployment and testing process. Most of > > those customers are very small companies... > > And now please continue this train of thoughts and consider every touch vendor. Wacom is not unique. We have Elan, Cypress, Weida, Goodix, etc. > etc. Vendor drivers were acceptable before we had I2C standard, but now it is much better for everyone to share the efforts and use HID instead of replicating it for every vendor. > > Thanks. > > -- > Dmitry
diff --git a/drivers/input/touchscreen/wacom_i2c.c b/drivers/input/touchscreen/wacom_i2c.c index 28255c77d426..72ba4a36459b 100644 --- a/drivers/input/touchscreen/wacom_i2c.c +++ b/drivers/input/touchscreen/wacom_i2c.c @@ -16,6 +16,7 @@ #include <linux/of.h> #include <asm/unaligned.h> +#define WACOM_DESC_REG 0x01 #define WACOM_CMD_QUERY0 0x04 #define WACOM_CMD_QUERY1 0x00 #define WACOM_CMD_QUERY2 0x33 @@ -24,11 +25,46 @@ #define WACOM_CMD_THROW1 0x00 #define WACOM_QUERY_SIZE 19 +#define WACOM_MAX_DATA_SIZE_BG9 10 +#define WACOM_MAX_DATA_SIZE_G12 15 +#define WACOM_MAX_DATA_SIZE_AG14 17 +#define WACOM_MAX_DATA_SIZE 22 + +/* Generation selction */ +/* Before and at G9 generation */ +#define WACOM_BG9 0 +/* G12 generation the IC supports "height"*/ +#define WACOM_G12 1 +/* After and at G14 generation the IC supports "height" and + * it is defined as "Z" axis + */ +#define WACOM_AG14 2 + +struct wacom_desc { + u16 descLen; + u16 version; + u16 reportLen; + u16 reportReg; + u16 inputReg; + u16 maxInputLen; + u16 outputReg; + u16 maxOutputLen; + u16 commReg; + u16 dataReg; + u16 vendorID; + u16 productID; + u16 fwVersion; + u16 misc_high; + u16 misc_low; +}; + struct wacom_features { + struct wacom_desc desc; int x_max; int y_max; int pressure_max; char fw_version; + unsigned char generation; }; struct wacom_i2c { @@ -45,6 +81,7 @@ static int wacom_query_device(struct i2c_client *client, struct wacom_features *features) { int ret; + u8 cmd_wac_desc[] = {WACOM_DESC_REG, 0x00}; u8 cmd1[] = { WACOM_CMD_QUERY0, WACOM_CMD_QUERY1, WACOM_CMD_QUERY2, WACOM_CMD_QUERY3 }; u8 cmd2[] = { WACOM_CMD_THROW0, WACOM_CMD_THROW1 }; @@ -70,6 +107,33 @@ static int wacom_query_device(struct i2c_client *client, }, }; + /* Read the description register */ + ret = i2c_master_send(client, cmd_wac_desc, sizeof(cmd_wac_desc)); + if (ret < 0) + return ret; + ret = i2c_master_recv(client, (char *)&features->desc, sizeof(features->desc)); + if (ret < 0) + return ret; + + switch (features->desc.maxInputLen) { + case WACOM_MAX_DATA_SIZE_BG9: + features->generation = WACOM_BG9; + break; + + case WACOM_MAX_DATA_SIZE_G12: + features->generation = WACOM_G12; + break; + + case WACOM_MAX_DATA_SIZE_AG14: + features->generation = WACOM_AG14; + break; + + default: + /* Cover all generations possible */ + features->generation = WACOM_AG14; + break; + } + ret = i2c_transfer(client->adapter, msgs, ARRAY_SIZE(msgs)); if (ret < 0) return ret;
When we query the device let's also read the descriptor from the device. This tells us useful information, including the version, which we use to determine a generation. This is based on the driver from Wacom. Signed-off-by: Alistair Francis <alistair@alistair23.me> --- drivers/input/touchscreen/wacom_i2c.c | 64 +++++++++++++++++++++++++++ 1 file changed, 64 insertions(+)