[RFC PATCH 0/1] input/touchscreen: Synaptics Touchscreen Driver
Christopher Heiny
touchscreens that use the RMI4 protocol, as defined here:
http://www.synaptics.com/sites/default/files/511-000136-01_revA.pdf
This patch addresses most of the feedback relating to our previous submission.
Any elements not acted on (such as creation of an 'rmi' bus on the kernel
bus architecture) are captured as TODOs in the code, and will be implemented
in a future submission. In addition:
- We think we've resolved all the whitespace issues. For Kconfig,
we used the indent pattern used by other modules. For all other
sources, we've converted to 8-space hard TAB characters.
- Some concerns were expressed regarding our I2C implementation.
Dmitry recommended we contact Jean Delvare for further review,
so we are cc'ing him on this patch.
This version of the driver does not support all features of the RMI4
protocol yet. We felt it more important to start with a solid
implementation of the basic functionality, and then build on that base
to support additional features (such as gestures, proximity detection,
capacitive buttons, and so on).
Additionally, as this is our team's first venture into the wonderful
world of kernel submissions, we figured it was important to start out
initially with a fairly simple codebase, just in case we're doing
something horribly wrong.
The significant files in this version of the driver are:
rmi_core.c
Implements the basic core of the RMI4 protocol
including self-discovery of RMI4 functions. This
also implements RMI4 function 0x01, which provides
generic device control.
rmi_function_11.c
Implements basic RMI4 function 0x11 (2D sensor)
features, including multitouch up to 10 fingers.
rmi_app_touchpad.c
The major driver functions (mod_init, mod_exit,
and so on).
An additional file is included, but will eventually be changed/dropped
rmi_i2c_gta01.c
Provides platform setup for development. This will
be replaced in the future by a generic approach to
specifying platform parameters.
More detailed descriptions can be found in each file's comments.
We chose to use multiple source files because it makes it easy to add
support for additional RMI4 functions with minimal impact to existing
functions. Additionally, this supports future changes to the
configuration to allow you to compile in only those RMI4 functions that
you need for your particular device.
There are two existing drivers for similar Synaptics devices in the
current kernel tree (excluding the PS/2 touchpad driver). These are:
./linux-2.6/drivers/input/mouse/synaptics_i2c.c
A driver for the Exeda 15mm touchpad, written by Mike Rapoport
<mi...@compulab.co.il> and Igor Grinberg <grin...@compulab.co.il>
./linux-2.6/drivers/staging/dream/synaptics_i2c_rmi.c
A driver for the HTC Dream ClearPad, written by Arve Hjønnevåg
<ar...@android.com>
We have not extended these drivers for a couple of reasons. First, the
two drivers are specific to particular Synaptics products, and it is our
desire to produce a general solution that takes advantage of the 'self
describing' features of products that use the RMI protocol.
Second, and more importantly, is that the existing drivers are written
for an older version of the RMI protocol (aka RMI3) that is being
retired in favor of a more recent and substantially changed version (aka
RMI4). Most currently shipping Synaptics ClearPads speak the RMI4
protocol, and it will be Synaptics protocol of choice going forward. In
almost all respects, RMI4 is not backward compatible with RMI3, making
it impractical to support both versions in the same driver.
Comments and other feedback on this driver are welcomed.
Bill Manson
Allie Xiong
Christopher Heiny
---
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Arve Hjønnevåg
...
> There are two existing drivers for similar Synaptics devices in the
> current kernel tree (excluding the PS/2 touchpad driver). These are:
>
> ./linux-2.6/drivers/input/mouse/synaptics_i2c.c
> A driver for the Exeda 15mm touchpad, written by Mike Rapoport
> <mi...@compulab.co.il> and Igor Grinberg <grin...@compulab.co.il>
>
> ./linux-2.6/drivers/staging/dream/synaptics_i2c_rmi.c
> A driver for the HTC Dream ClearPad, written by Arve Hjønnevåg
> <ar...@android.com>
>
> We have not extended these drivers for a couple of reasons. First, the
> two drivers are specific to particular Synaptics products, and it is our
> desire to produce a general solution that takes advantage of the 'self
> describing' features of products that use the RMI protocol.
>
Do you plan to add platform data to align the reported touchscreen
data with the screen behind it, or do the new hardware allow the the
firmware handle this? In the past we even needed separate parameters
for different firmware versions (seen in
drivers/staging/dream/synaptics_i2c_rmi.h).
--
Arve Hjønnevåg
Christopher Heiny
> On Mon, Mar 22, 2010 at 7:07 PM, Christopher Heiny<che...@synaptics.com> wrote:
> ...
>> There are two existing drivers for similar Synaptics devices in the
>> current kernel tree (excluding the PS/2 touchpad driver). These are:
>>
>> ./linux-2.6/drivers/input/mouse/synaptics_i2c.c
>> A driver for the Exeda 15mm touchpad, written by Mike Rapoport
>> <mi...@compulab.co.il> and Igor Grinberg<grin...@compulab.co.il>
>>
>> ./linux-2.6/drivers/staging/dream/synaptics_i2c_rmi.c
>> A driver for the HTC Dream ClearPad, written by Arve Hjønnevåg
>> <ar...@android.com>
>>
>> We have not extended these drivers for a couple of reasons. First, the
>> two drivers are specific to particular Synaptics products, and it is our
>> desire to produce a general solution that takes advantage of the 'self
>> describing' features of products that use the RMI protocol.
>>
>
> Do you plan to add platform data to align the reported touchscreen
> data with the screen behind it, or do the new hardware allow the the
> firmware handle this? In the past we even needed separate parameters
> for different firmware versions (seen in
> drivers/staging/dream/synaptics_i2c_rmi.h).
Hi Arve,
RMI4 touchscreens allow adjustment of the reported coordinate range (see
the F11_2D_Ctrl6..9 registers, page 48 of the current version of the
spec at http://www.synaptics.com/developers/manuals). Using this
feature, the device can be configured to report the same number of
positions on each axis as there are pixels on the display.
We plan to make these settings accessible via sysfs, so that it can be
dynamically tweaked if the user changes the display resolution (not
likely on a phone, probable on a tablet/slate/ereader type device).
Assuming there are no significant issues with our current patch, we plan
to include that in the next one. We're holding off that implementation
because we're still finding our feet on the submission process, and
wanted to keep the initial submits small so changes would be more
manageable.
Coordinate rotation/reflection settings will be handled at the driver
level, again via sysfs.
These features should be independent of the touchscreen firmware level.
Initial settings for these features should probably be done at the
platform level.
Chris
Arve Hjønnevåg
> On 03/22/2010 08:04 PM, Arve Hj�nnev�g wrote:
>>
>> On Mon, Mar 22, 2010 at 7:07 PM, Christopher Heiny<che...@synaptics.com>
>> �wrote:
>> ...
>>>
>>> There are two existing drivers for similar Synaptics devices in the
>>> current kernel tree (excluding the PS/2 touchpad driver). �These are:
>>>
>>> ./linux-2.6/drivers/input/mouse/synaptics_i2c.c
>>> � � �A driver for the Exeda 15mm touchpad, written by Mike Rapoport
>>> � � �<mi...@compulab.co.il> �and Igor Grinberg<grin...@compulab.co.il>
>>>
>>> ./linux-2.6/drivers/staging/dream/synaptics_i2c_rmi.c
>>> � � �<ar...@android.com>
>>>
>>> We have not extended these drivers for a couple of reasons. �First, the
>>> two drivers are specific to particular Synaptics products, and it is our
>>> desire to produce a general solution that takes advantage of the 'self
>>> describing' features of products that use the RMI protocol.
>>>
>>
>> Do you plan to add platform data to align the reported touchscreen
>> data with the screen behind it, or do the new hardware allow the the
>> firmware handle this? In the past we even needed separate parameters
>> for different firmware versions (seen in
>> drivers/staging/dream/synaptics_i2c_rmi.h).
>
> Hi Arve,
>
> RMI4 touchscreens allow adjustment of the reported coordinate range (see the
> F11_2D_Ctrl6..9 registers, page 48 of the current version of the spec at
> http://www.synaptics.com/developers/manuals). �Using this feature, the
> device can be configured to report the same number of positions on each axis
> as there are pixels on the display.
>
This does not help aligning the touchscreen values with the screen
behind it. It just moves the linear scaling from userspace (which can
use fixed or floating point values to preserve subpixel precision) to
the firmware.
> We plan to make these settings accessible via sysfs, so that it can be
> dynamically tweaked if the user changes the display resolution (not likely
> on a phone, probable on a tablet/slate/ereader type device). Assuming there
> are no significant issues with our current patch, we plan to include that in
> the next one. �We're holding off that implementation because we're still
> finding our feet on the submission process, and wanted to keep the initial
> submits small so changes would be more manageable.
You could also post a patch series instead of one patch.
>
> Coordinate rotation/reflection settings will be handled at the driver level,
> again via sysfs.
>
Do you also have a plan to let the userspace know that touchscreen
coordinate x1,y1 correspond to screen coordinate 0,0 and x2,y2
correspond to screen coordinate xmax,ymax? The android driver sets
absmin/max to the values reported when touching the display edges (not
the actual min and max that the touchscreen can report), but other
solutions are also possible.
> These features should be independent of the touchscreen firmware level.
In the past they have depended on the firmware version for two
reasons. On one product, firmware changes to improve the edges of the
screen completely changed the relationship between values reported and
the physical touch location. On another product, the physical size of
the sensor changed, and the firmware version was used to detect this.
If all RMI4 based product allow field updates of the firmware the
first case it less important, but we still need to cover the second
case.
> �Initial settings for these features should probably be done at the platform
> level.
>
> � � � � � � � � � � � � � � � � � � � �Chris
>
--
Arve Hj�nnev�g
Christopher Heiny
>>>
>>> On Mon, Mar 22, 2010 at 7:07 PM, Christopher Heiny<che...@synaptics.com>
>>> wrote:
>>> ...
>>>>
>>>> There are two existing drivers for similar Synaptics devices in the
>>>> current kernel tree (excluding the PS/2 touchpad driver). These are:
>>>>
>>>> ./linux-2.6/drivers/input/mouse/synaptics_i2c.c
>>>> A driver for the Exeda 15mm touchpad, written by Mike Rapoport
>>>> <mi...@compulab.co.il> and Igor Grinberg<grin...@compulab.co.il>
>>>>
>>>> ./linux-2.6/drivers/staging/dream/synaptics_i2c_rmi.c
>>>> <ar...@android.com>
>>>>
>>>> We have not extended these drivers for a couple of reasons. First, the
>>>> two drivers are specific to particular Synaptics products, and it is our
>>>> desire to produce a general solution that takes advantage of the 'self
>>>> describing' features of products that use the RMI protocol.
>>>>
>>>
>>> Do you plan to add platform data to align the reported touchscreen
>>> data with the screen behind it, or do the new hardware allow the the
>>> firmware handle this? In the past we even needed separate parameters
>>> for different firmware versions (seen in
>>> drivers/staging/dream/synaptics_i2c_rmi.h).
>>
>> Hi Arve,
>>
>> RMI4 touchscreens allow adjustment of the reported coordinate range (see the
>> F11_2D_Ctrl6..9 registers, page 48 of the current version of the spec at
>> http://www.synaptics.com/developers/manuals). Using this feature, the
>> device can be configured to report the same number of positions on each axis
>> as there are pixels on the display.
>>
>
> This does not help aligning the touchscreen values with the screen
> behind it. It just moves the linear scaling from userspace (which can
> use fixed or floating point values to preserve subpixel precision) to
> the firmware.
Hi Arve,
It sounds like your concern is for cases when the origin of the
touchscreen coordinates does not correspond to a corner of the pixel
area. Is that correct?
In any case, it's a perfectly valid issue - not all manufacturers take
care to map the touchscreen to the display screen that way (though most
do). Adding a translation control to the driver would be easy - we'll
put it on the todo list.
>
>> We plan to make these settings accessible via sysfs, so that it can be
>> dynamically tweaked if the user changes the display resolution (not likely
>> on a phone, probable on a tablet/slate/ereader type device). Assuming there
>> are no significant issues with our current patch, we plan to include that in
>> the next one. We're holding off that implementation because we're still
>> finding our feet on the submission process, and wanted to keep the initial
>> submits small so changes would be more manageable.
>
> You could also post a patch series instead of one patch.
It's more the other direction - we were concerned (validly, it turned
out) that some extensive changes might be required as a result of
feedback on the initial submissions, and wanted to keep the codebase
we'd have to refactor small.
As the codebase grows, we'll switch to using patch series. Probably
with the next submission or (more likely) the one after that.
>> Coordinate rotation/reflection settings will be handled at the driver level,
>> again via sysfs.
>>
> Do you also have a plan to let the userspace know that touchscreen
> coordinate x1,y1 correspond to screen coordinate 0,0 and x2,y2
> correspond to screen coordinate xmax,ymax? The android driver sets
> absmin/max to the values reported when touching the display edges (not
> the actual min and max that the touchscreen can report), but other
> solutions are also possible.
We are not planning on that, since it would require the driver to know
the orientation (standard? rot 90? rot -90? rot 180?) and resolution of
the display and track whenever that changes. It is better to handle
that information at a higher level, which can then tell the touchscreen
driver the desired resolution/rotation/etc settings.
>> These features should be independent of the touchscreen firmware level.
>
> In the past they have depended on the firmware version for two
> reasons. On one product, firmware changes to improve the edges of the
> screen completely changed the relationship between values reported and
> the physical touch location.
Good point.
> On another product, the physical size of
> the sensor changed, and the firmware version was used to detect this.
> If all RMI4 based product allow field updates of the firmware the
> first case it less important, but we still need to cover the second
> case.
Hmmmm. I can see a lot of other cases where it might be desirable to
know the size of the touchscreen in a platform independent manner.
Certainly the firmware version is not a reliable way to do this going
forward. I will contact the spec maintainer and see if we can have the
device report the relative information in a query.
Thanks,
Chris
Christopher Heiny
> Sorry for the delay. Here finally come my comments on your code. I'm
> only commenting on the i2c side of things.
Hi Jean,
Thanks for the input! It's quite helpful and clears up some things we
were a bit puzzled about. We'll fold most of your suggestions into the
next patch. Answers to some questions you raised will be coming shortly.
Thanks again,
Chris