Message-ID: <51B1F859.1010504@itdev.co.uk>
Date:	Fri, 07 Jun 2013 16:12:25 +0100
From:	Nick Dyer <nick.dyer@...ev.co.uk>
To:	Mark Brown <broonie@...nel.org>
CC:	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Daniel Kurtz <djkurtz@...omium.org>,
	Henrik Rydberg <rydberg@...omail.se>,
	Joonyoung Shim <jy0922.shim@...sung.com>,
	Alan.Bowens@...el.com, linux-input@...r.kernel.org,
	linux-kernel@...r.kernel.org, pmeerw@...erw.net,
	bleung@...omium.org, olofj@...omium.org
Subject: Re: [PATCH 10/53] Input: atmel_mxt_ts - Add memory access interface
 via sysfs

Mark Brown wrote:
> 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.

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?

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

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

It's not laziness, it's trying to push policy into user space.

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

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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists