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

From: Mark Brown
Date: Thu Jun 06 2013 - 12:46:53 EST


On Thu, Jun 06, 2013 at 05:13:32PM +0100, Nick Dyer wrote:

> I am not a legal expert, but I have described what you suggest to people
> who are more expert in the NDA terms and they say I cannot implement a
> solution which exposes the names of all the parameters. In any case,

Who said anything about names? I'd assume the userspace stuff is
eventually talking to the device based on numbers of some kind and I'd
expect that this would be what ends up in the API.

> Without the register names all you really have is the object protocol that
> we started with, you would end up accessing

> /sys/bus/i2c/drivers/atmel_mxt_ts/1-0020/objectX/registerX

> rather than parsing the object table once when your program started, then
> performing a read/write to offset X.

Well, assuming sysfs makes sense for this. It's not immediately clear
to me that it does.

> And we wouldn't have won anything, because the user could still write to
> the register that turns off reporting (for example) by mistake with both
> methods.

You'd not have access to the entire device register map which seems like
a win and people would be able to integrate sensibly with things like
the overall device power management (which might help with whatever is
causing you to have to cope with failing I/O) more smoothly.

> > So this goes back to what I was saying before about the interface being
> > badly designed - if the API you have to present is really this complex
> > then you've got a big problem in kernel or out of kernel.

> Touch controllers are inherently complex system with a lot of configurable
> parameters. The fact that it's complex and changes quickly doesn't make it
> badly designed per se.

Having lots of configuration and having the parameters change regularly
doesn't immediately mean that it has to be complex - the requirement is
very common, touchscreens aren't too remarkable here. The usual thing
is for the kernel to understand how to transfer data back and forth but
not the content of the data.

Attachment: signature.asc
Description: Digital signature