[U-Boot] [PATCH 2/2] usb: kbd: implement special keys

[Simon Glass]

+Tom for comment

Hi Heinrich,

On 8 March 2018 at 15:04, Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
> On 03/08/2018 09:30 PM, Simon Glass wrote:
>> Hi Heinrich,
>>
>> input.c uses PS/2 scan codes at present. However these are somewhat
>> internal. You should see docs in input.h
>>
>> I am not sure of the best approach, but one would be to convert USB
>> scan codes to PS/2 codes.
>>
>> Regards,
>> Simon
>>
>
> Hello Simon, hello Marek,
>
> thanks for the clarification.
>
> Between input.c and usb_kbd.c we have the following differences:
>
> - Most keycodes are different.

Yes, although if you call input_add_table() you can supply your own.

> - The way ALT, CTRL, SHIFT, META are transferred differ.

Indeed

> - Input.c has implemented support for different keyboard layouts
>   (EN, DE) which is not easily expandable to other layouts.

That's just the tables though, right?

>
> So if we wanted to have a common layer this would require a complete rewrite
> of both input.c and usb_kbd.c.

I hope that in fact only the latter would need a rewrite. But I admit
I have not done it.

>
> I do not have access to any device using input.c. So I am unable to test any
> of it.
>
> So I would prefer if we could just patch usb_kbd.c to provide the missing
> special keys and keep the code separate.

Actually sandbox has tests for this. Try running with -l and you
should get a keyboard on the simulated LCD screen, which uses the
input layer.
>
> Having usb_kbd.c in directory common/ looks like a misplacement.
> It could be put under drivers/input/ or under drivers/usb/hid/.
> I think in future we should have also mouse and touchscreen as hid drivers.
> Otherwise using an EFI menu on a tablet will not be possible.
> So I would prefer moving usb_kbd to drivers/usb/hid/.

Well yes it would be better out of common.

I think it would be possible to use the input_send_keycodes()
interface from the USB keyboard driver, given a suitable keymap. There
is quite a lot of code that looks much the same, and unifying them was
always my intent. But I understand that it is not a trivial
undertaking, so I suppose it might be a bridge too far.

Regards,
Simon