On Wed, Feb 16, 2011 at 11:51:18AM -0800, Rakesh Iyer wrote:
> >
> > On Wed, Feb 09, 2011 at 11:44:40AM -0800, riyer@xxxxxxxxxx wrote:
> > > +
> > > + /*
> > > + * If the platform uses Fn keymaps, translate keys on a Fn keypress.
> > > + * Function keycodes are KBC_MAX_COL apart from the plain keycodes.
> > > + */
> > > + for (i = 0; (i < num_down) && fn_keypress; i++) {
> > > + scancodes[i] += KBC_MAX_COL;
> >
> > This should be KBC_MAX_KEY, isn't it?
>
> In my implementation (and in your change) each row contains both Plain and Fn translated keys.
> So Cols 0-7 correspond to the plain keys and Cols 8-15 correspond to the Fn keys.
> That's why we add KBC_MAX_COL to get to the Fn translation.
>
> This is using the logic from matrix_keypad.h
>
> keymap[MATRIX_SCAN_CODE(row, col, row_shift)] = code;
>
> and #define MATRIX_SCAN_CODE(row, col, row_shift) (((row) << (row_shift)) + (col))
>
> I will address the latter part after this one is cleared up.
>
Ah, yes. However I think we should change this so that Fn adds more
rows, not columns. This way you can properly limit keymap size and would
not accept/report to userspace (via EVIOCG/SKEYCODE) scancodes that are
not valid for given configuration. Do you agree?
Thanks.
--
Dmitry
--
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
