On 07/15/2014 10:51 AM, Mark Rutland wrote: > On Mon, Jul 14, 2014 at 11:20:17AM +0100, Daniel Mack wrote: >> Hmm, I thought about that, but there are - in theory - more details that >> could be specified per channel. I left those functions out for the first >> version, as I have no good way to test them. > > Ok. Could you elaborate on what those details might be? It might make > sense to have these as nodes if there are arbitrary properties to > describe for each button, but I'm not familiar enough with the hardware > to make a call either way. No, there are just settings that can be made for each indvidual channel/button, such as sensitivity settings for instance. But they can of course be specified in a similar manner as the keycodes, in a fixed-size array. That's completely ok I think. >> linux,keycode feels a bit overkill here though, so I'd rather go for a >> fixed-size linux,keycodes property. The number of entries is fixed, >> anyway. Would you be fine with that? > > Assuming no-one's likely to want a sparse keymap (i.e. one where some > keys do nothing) then that's probably ok. If such a setup occurs, support for disabling channels could easily be added, and in such cases, the keycode is simple ignored. I don't think a sparse matrix keymap makes much sense here, especially as the buttons are not organized in rows and columns. >>> /me mutters usual grumblings about the autorepeat property. >> >> I took that from the gpio-keys driver. Is there a better way to denote >> such a feature? > > Unfortunately not, given current practice. My gripe is that it's a Linux > detail that were describing rather than a property of the device. We can > forget about that for now. I see, so I'll leave it as it is. I'll drop the input device unregister call as Dmitry said, and repost v5. Thanks again! Daniel -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
