Re: [PATCH v2] Input: Add driver for Microchip's CAP1106

[Daniel Mack <daniel@zonque.org>]

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