Mark Brown wrote:

On Wed, Jun 05, 2013 at 10:36:45PM +0100, Nick Dyer wrote:

quoted

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.

quoted

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.