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

[Mark Brown]

On Fri, Jun 07, 2013 at 04:12:25PM +0100, Nick Dyer wrote:
> Mark Brown wrote:

> > 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.

> OK. But if user-space is talking to the device based on register numbers, a
> binary attribute seems like the correct way to present that - isn't that
> what they're designed for?

I thought there was this protocol you're concerned aboout, not raw
registers?  Presenting the actual data in binary form seems sane, how
one gets to the data is the issue.

> >> 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

> Not really.

> The chip itself will enforce which registers are read-only (by ignoring
> writes) or write-only (by returning zeros if read). Encoding all this
> information in the driver would just make it more brittle in the face of
> touch controller firmware updates.

So not only do you interact with the firmware via this protocol but the
actual hardware register map is unstable and there's nothing in the
device that the driver itself actually interacts with, all it does is
ferry these messages from the application layer to the device?  Given
the number of other patches here that doesn't seem to be the case...

> It would be possible for the driver to intermediate for some of the
> registers that it cares about. For example, if we change the screen width
> then the driver could reinitialise the input device. But I can't see that
> it makes sense if you are changing several settings in a row for the input
> device to be reinitialised several times. It is far less buggy to provide a
> single way of tearing down everything and reinitialising (which could be
> simply triggered from user space) than to encode all of the dependencies
> (which is bound to introduce bugs).

I am having an extremely hard time connecting anything you're talking
about here with the discussion at hand I'm afraid...

> > 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.

> Sure, that's what I'm trying to accomplish. It's just that as far as I can
> see it makes more sense to use the established protocol that these chips
> have implemented rather than trying to bodge something else over the top or
> crowbar it into a different model that will cause abstraction problems. We
> have thought about this problem at great length, and discussed it on these
> lists, and with other kernel engineers at customers, etc.

Nobody is talking about changing the protocol for interacting with the
device.  The discussion here is about the ABI the driver offers to the
application layer.

Attachment: signature.asc
Description: Digital signature