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-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
