Prev: Weird deadlock when shutting down
Next: [git pull] Input updates for 2.6.33-rc7
From: Dmitry Torokhov on 18 Feb 2010 05:00
Hi Christopher,

On Wed, Feb 17, 2010 at 02:37:36PM -0800, Christopher Heiny wrote:
> [This is a resend of a patch sent earlier this month - apologies
> for the duplication, but I botched some of the addressing in the
> previous submission (neglecting to include Dmitry), as well as the
> cover note.]
>
> This patch adds an initial driver supporting Synaptics ClearPad
> touchscreens that use the RMI4 protocol, as defined here:
>
> http://www.synaptics.com/sites/default/files/511-000136-01_revA.pdf
>
>
> Differences to the previous RFC PATCH sent include:
> - proper line wrapping (sending with get-sendemail)
> - extensive changes to make checkpatch.pl happy. Not all errors were
> eliminated, because in a couple of cases we couldn't figure out what the
> problem was.
> - i2c interface updated to reflect recent i2c changes in the kernel.
>


Thank you for making the changes and yes, please CC me and linux-input
mailing list on the subsequent submissions - this way you should
normally get quicker response.

PLease give me a couple days to look over the driver and ping me if you
don't hear from me.

--
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Dmitry Torokhov on 8 Mar 2010 03:50
On Thu, Mar 04, 2010 at 05:16:09PM -0800, Christopher Heiny wrote:
> On 03/02/2010 01:12 AM, Dmitry Torokhov wrote:
> >Hi Christofer,
> >
> >I assume that since you sent it with git-send-email it was your
> >corporate mail server that murdered all identation and whitespace.
> >Please try sending next version using alternative server, like gmail or
> >maybe your personal account. On the off chance that the formatting used
> >in the driver was preserved intact - please remember that kernel uses
> >hard tabs for identation (8 chars, no expanding). Camel-casing is also
> >frowned upon.
>
> Actually, the strange indenting/whitespace is due to a day-long struggle
> with checkpatch.pl to get it to accept something - anything - without
> complaining. Personally I thought the formatting that checkpatch
> finally accepted was kind of strange, but went with it.
>
> We'll update to 8-space hard tabs only, and ignore any future
> checkpatch complaints in that department.

Umm, generally speaking checkpatch is "telling the truth" and if you run
it aginst most of the krenle code you shold get very few complaints. The
only thing I tend to ignore is the 80 column limit (which I think is
being liften in recent version).

Also, while you are at it - consider using dev_xxx() for printing
messages when you have 'struct device *' available and pr_xxx() when you
do not have it instead of using "naked" printks.

Thanks.

--
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Arve Hjønnevåg on 22 Mar 2010 23:10
On Mon, Mar 22, 2010 at 7:07 PM, Christopher Heiny <cheiny(a)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
> � � �<mike(a)compulab.co.il> and Igor Grinberg <grinberg(a)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
> � � �<arve(a)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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Christopher Heiny on 23 Mar 2010 15:20
On 03/22/2010 08:04 PM, Arve Hj�nnev�g wrote:
> On Mon, Mar 22, 2010 at 7:07 PM, Christopher Heiny<cheiny(a)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
>> <mike(a)compulab.co.il> and Igor Grinberg<grinberg(a)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
>> <arve(a)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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Arve Hjønnevåg on 23 Mar 2010 18:40
2010/3/23 Christopher Heiny <cheiny(a)synaptics.com>:
> On 03/22/2010 08:04 PM, Arve Hj�nnev�g wrote:
>>
>> On Mon, Mar 22, 2010 at 7:07 PM, Christopher Heiny<cheiny(a)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
>>> � � �<mike(a)compulab.co.il> �and Igor Grinberg<grinberg(a)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
>>> � � �<arve(a)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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
 |  Next  |  Last
Pages: 1 2
Prev: Weird deadlock when shutting down
Next: [git pull] Input updates for 2.6.33-rc7