Re: [U-Boot] [PATCH 2/2] usb: kbd: implement special keys
On Mon, Mar 19, 2018 at 11:59:45AM -0600, Simon Glass wrote: > +Tom for comment > > Hi Heinrich, > > On 8 March 2018 at 15:04, Heinrich Schuchardt 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. Yes, we should probably try and get that code unified, or at least have an idea of how long it would take to do so. -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] usb: kbd: implement special keys
+Tom for comment Hi Heinrich, On 8 March 2018 at 15:04, Heinrich Schuchardt 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 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] usb: kbd: implement special keys
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. - The way ALT, CTRL, SHIFT, META are transferred differ. - Input.c has implemented support for different keyboard layouts (EN, DE) which is not easily expandable to other layouts. So if we wanted to have a common layer this would require a complete rewrite of both input.c and usb_kbd.c. 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. 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/. Best regards Heinrich ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] usb: kbd: implement special keys
On 02/23/2018 09:59 PM, Simon Glass wrote: Hi Heinrich, On 22 February 2018 at 05:04, Heinrich Schuchardt wrote: Correct support for arrow keys: use the standard xterm escape sequences. Provide support for F1-F12, Insert, Delete, Home, End, Page Up, Page Down. Signed-off-by: Heinrich Schuchardt --- common/usb_kbd.c | 121 +-- 1 file changed, 90 insertions(+), 31 deletions(-) Is there any way this code could be shared with input.c? It has translation tables. Hello Simon, input.c seems to be another incomplete implementation of a keyboard driver. Yes it would make sense to avoid duplicating code. But unfortunately input.c lacks any documentation. As maintainer I hope you can answer the following: When configuring a German keyboard and typing Right-Alt + M the output is 0xE6. This is mju (ยต) in code page 437. Wouldn't we always use UTF-8 in U-Boot? The scan codes for PS/2 serial keyboards and USB keyboards differ (cf. "USB HID to PS/2 Scan Code Translation Table" http://download.microsoft.com/download/1/6/1/161ba512-40e2-4cc9-843a-923143f3456c/translate.pdf). Is input.c meant to handle PS/2 scan codes or USB scan codes? Regards Heinrich ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] usb: kbd: implement special keys
Hi Heinrich, On 22 February 2018 at 05:04, Heinrich Schuchardt wrote: > Correct support for arrow keys: use the standard xterm escape sequences. > > Provide support for F1-F12, Insert, Delete, Home, End, Page Up, Page Down. > > Signed-off-by: Heinrich Schuchardt > --- > common/usb_kbd.c | 121 > +-- > 1 file changed, 90 insertions(+), 31 deletions(-) > Is there any way this code could be shared with input.c? It has translation tables. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
