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 [off-list ref]
wrote:
quoted
Hi Tatsunosuke,
On Thu, Sep 02, 2021 at 07:33:49AM +0000, Tobita, Tatsunosuke wrote:
quoted
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.
quoted
There needs to be a _very_ strong reason to essentially duplicate
quoted
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 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 <redacted>
Cc: Tobita, Tatsunosuke <redacted>; Alistair Francis <redacted>; Cheng, Ping <Ping.Cheng@wacom.com>; linux-input <redacted>; linux-imx@nxp.com; kernel@pengutronix.de; Tatsunosuke Tobita <redacted>; 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
[off-list ref]
wrote:
quoted
Hi Tatsunosuke,
On Thu, Sep 02, 2021 at 07:33:49AM +0000, Tobita, Tatsunosuke wrote:
quoted
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.
quoted
There needs to be a _very_ strong reason to essentially duplicate
quoted
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 Dmitry,
On Tue, Sep 7, 2021 at 10:55 PM Dmitry Torokhov
[off-list ref] wrote:
quoted
quoted
quoted
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.
quoted
There needs to be a _very_ strong reason to essentially duplicate
quoted
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.
quoted
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!). 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.
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...
I think the ultimate goal is to encourage more people to contribute to
open source projects and to make Linux a great platform that everyone
can work on easily.
Thank you for your consideration and support,
Ping
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
[off-list ref] wrote:
quoted
quoted
quoted
quoted
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.
quoted
There needs to be a _very_ strong reason to essentially duplicate
quoted
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.
quoted
quoted
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
From: Alistair Francis <hidden> Date: 2021-09-29 07:51:21
On Tue, Sep 21, 2021 at 2:35 PM Dmitry Torokhov
[off-list ref] wrote:
Hi Ping,
On Fri, Sep 17, 2021 at 01:43:18PM -0700, Ping Cheng wrote:
quoted
Hi Dmitry,
On Tue, Sep 7, 2021 at 10:55 PM Dmitry Torokhov
[off-list ref] wrote:
quoted
quoted
quoted
quoted
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.
quoted
There needs to be a _very_ strong reason to essentially duplicate
quoted
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.
quoted
quoted
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.
quoted
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?
quoted
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
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 <redacted>
Sent: Friday, September 10, 2021 1:10 PM
To: Dmitry Torokhov <dmitry.torokhov@gmail.com>; Ping Cheng <redacted>
Cc: Alistair Francis <redacted>; Cheng, Ping <Ping.Cheng@wacom.com>; linux-input <redacted>; linux-imx@nxp.com; kernel@pengutronix.de; Tatsunosuke Tobita <redacted>; 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 <redacted>
Cc: Tobita, Tatsunosuke <redacted>; Alistair Francis <redacted>; Cheng, Ping <Ping.Cheng@wacom.com>; linux-input <redacted>; linux-imx@nxp.com; kernel@pengutronix.de; Tatsunosuke Tobita <redacted>; 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
[off-list ref]
wrote:
quoted
Hi Tatsunosuke,
On Thu, Sep 02, 2021 at 07:33:49AM +0000, Tobita, Tatsunosuke wrote:
quoted
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.
quoted
There needs to be a _very_ strong reason to essentially duplicate
quoted
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 <redacted>
Sent: Friday, September 10, 2021 1:10 PM
To: Dmitry Torokhov <dmitry.torokhov@gmail.com>; Ping Cheng <redacted>
Cc: Alistair Francis <redacted>; Cheng, Ping <Ping.Cheng@wacom.com>; linux-input <redacted>; linux-imx@nxp.com; kernel@pengutronix.de; Tatsunosuke Tobita <redacted>; 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 <redacted>
Cc: Tobita, Tatsunosuke <redacted>; Alistair Francis <redacted>; Cheng, Ping <Ping.Cheng@wacom.com>; linux-input <redacted>; linux-imx@nxp.com; kernel@pengutronix.de; Tatsunosuke Tobita <redacted>; 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:
quoted
Hi Dmitry,
On Mon, Sep 6, 2021, 11:05 PM Dmitry Torokhov
[off-list ref]
wrote:
quoted
Hi Tatsunosuke,
On Thu, Sep 02, 2021 at 07:33:49AM +0000, Tobita, Tatsunosuke wrote:
quoted
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.
quoted
There needs to be a _very_ strong reason to essentially duplicate
quoted
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.
quoted
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
Dmitry,
Thanks you. I appreciate that your answered my questions.
I think now I agree we just stay with the current wacom_i2c.
This is just to tell you what kind of situation we deal with wacom_i2c with our customers.
We work with OEMs,/ODMs and they often want to add/customize their own features onto Wacom pen functionality with their Linux based OS, such as Chrome OS, Android, Linux desktop distribution, etc.
In those cases, some of them want to use wacom_i2c.
The reason is if they used wacom_i2c, they would be able to concentrate on their own desired programs.
Since wacom_i2c has simple structure for initialization - their desired special preparation- and for handling input events to add their specific purpose,
it is easier for OEMs/ODMs to handle such. On the other hand, they may have to look into whole hid codes throughout parsing hid collections when they
want to the same as I just described prior to this sentence; and it takes time more than they do with wacom_i2c. Also, finding problems becomes more difficult for them if they have.
We usually recommend the customers use i2c-hid, but not all of them follow it and use wacom_i2c with that reasons above.
We, this time, tried to update it because some of the customers try to use the current wacom_i2c as it is - compatible older generations of the products- and ask us the correct one.
Yes we do then, but we thought maybe updating wacom_i2c may help them use it easier.
That's it. I just want to tell you why we started suddenly update the driver.
Thanks,
Tats
-----Original Message-----
From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Sent: Thursday, October 7, 2021 3:03 AM
To: Tobita, Tatsunosuke <redacted>
Cc: Ping Cheng <redacted>; Alistair Francis <redacted>; Cheng, Ping <Ping.Cheng@wacom.com>; linux-input <redacted>; linux-imx@nxp.com; kernel@pengutronix.de; Tatsunosuke Tobita <redacted>; 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 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 <redacted>
Sent: Friday, September 10, 2021 1:10 PM
To: Dmitry Torokhov <dmitry.torokhov@gmail.com>; Ping Cheng
[off-list ref]
Cc: Alistair Francis <redacted>; Cheng, Ping
[off-list ref]; linux-input [off-list ref];
linux-imx@nxp.com; kernel@pengutronix.de; Tatsunosuke Tobita
[off-list ref]; 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 <redacted>
Cc: Tobita, Tatsunosuke <redacted>; Alistair
Francis [off-list ref]; Cheng, Ping [off-list ref];
linux-input [off-list ref]; linux-imx@nxp.com;
kernel@pengutronix.de; Tatsunosuke Tobita [off-list ref];
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:
quoted
Hi Dmitry,
On Mon, Sep 6, 2021, 11:05 PM Dmitry Torokhov
[off-list ref]
wrote:
quoted
Hi Tatsunosuke,
On Thu, Sep 02, 2021 at 07:33:49AM +0000, Tobita, Tatsunosuke wrote:
quoted
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.
quoted
There needs to be a _very_ strong reason to essentially duplicate
quoted
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.
quoted
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