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

Mark Brown wrote:

quoted

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.

quoted

quoted

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.

quoted

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

quoted

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.