Re: [PATCH 10/53] Input: atmel_mxt_ts - Add memory access interfacevia sysfs

[Nick Dyer]

Mark Brown wrote:
> On Wed, Jun 05, 2013 at 10:36:45PM +0100, Nick Dyer wrote:
>> Run-time examples would be adjusting noise suppression or touch suppression
>> parameters based on something going on in the app layer (eg having
>> different parameters during unlock screen), or tuning report rates based on
>> application requirements, ot to inspect debug data if the touch sensor is
>> faulty. You might say, well we should implement an kernel driver interface
>> for these requirements, but they will vary hugely between different
>> products. We are trying to keep the driver as generic as possible and push
> 
> If this interface varies dramatically between products then that sounds
> like a badly designed interface.  Obviously the way the interface is
> being used would be likely to vary between products but what you're
> talking about sounds like parameter get/set stuff which sounds pretty
> generic to me.  What userspace chooses to do with the parameters is of
> course another story.

The underlying design is called Object Protocol by Atmel, and defines a
method where the the i2c address space starts with a table defining the
types and locations of various objects. Each object contains many
parameters, most of them are simple get/set as you describe, but many
objects have considerably more dynamic behaviours and interactions.

The Object Protocol itself is generic, but the objects themselves are
different on different maXTouch chips and firmware versions. The objects
may change in size, or be added/removed. The protocol is designed to be
flexible and allow rapid firmware development without having to
continuously update tools.

Having to define every parameter in each object (there are thousands) in
the kernel driver would be impractically technically, since it would result
in a huge, and constantly updating API, which would be always out-of-date,
and impossible to support.

Also, I'm afraid it would also be impractical legally, since it would
breach the NDA terms that Atmel require on these parameter definitions.

>> product-specific complexity to user space. Hence exposing the register map
>> and implementing user-space libraries to deal with this kind of customisation.
> 
> This sounds like a bad design decision for Linux, it's just asking for
> fragility if userspace can go randomly poking round the entire register
> map of the device with nothing coordinating with the driver code.

It works very well in practice. This same abstraction is used across
maXTouch products on many platforms to provide tool support. I agree that
its use should be restricted to system programs.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/