Mac OS X calls it during boot. This gets rid of an error saying "call-method slw_update_keymap failed with error ffffffdf" but otherwise does not seem to matter. It's probably used for getting the pressed keys that can change some boot actions like enable verbose mode with Cmd-V.
Signed-off-by: BALATON Zoltan balaton@eik.bme.hu --- drivers/usbhid.c | 8 ++++++++ 1 file changed, 8 insertions(+)
diff --git a/drivers/usbhid.c b/drivers/usbhid.c index b8e1548..d3ad4ef 100644 --- a/drivers/usbhid.c +++ b/drivers/usbhid.c @@ -52,12 +52,20 @@ keyboard_close(int *idx) { }
+static void +keyboard_get_key_map(void) +{ + static char keytable[32] = { 0 }; + PUSH(pointer2cell(keytable)); +} + static void keyboard_read(void);
NODE_METHODS( usb_kbd ) = { { "open", keyboard_open }, { "close", keyboard_close }, { "read", keyboard_read }, + { "get-key-map", keyboard_get_key_map }, };
#ifdef CONFIG_DEBUG_USB
On 27/01/2023 13:33, BALATON Zoltan wrote:
Mac OS X calls it during boot. This gets rid of an error saying "call-method slw_update_keymap failed with error ffffffdf" but otherwise does not seem to matter. It's probably used for getting the pressed keys that can change some boot actions like enable verbose mode with Cmd-V.
Signed-off-by: BALATON Zoltan balaton@eik.bme.hu
drivers/usbhid.c | 8 ++++++++ 1 file changed, 8 insertions(+)
diff --git a/drivers/usbhid.c b/drivers/usbhid.c index b8e1548..d3ad4ef 100644 --- a/drivers/usbhid.c +++ b/drivers/usbhid.c @@ -52,12 +52,20 @@ keyboard_close(int *idx) { }
+static void +keyboard_get_key_map(void) +{
- static char keytable[32] = { 0 };
- PUSH(pointer2cell(keytable));
+}
static void keyboard_read(void);
NODE_METHODS( usb_kbd ) = { { "open", keyboard_open }, { "close", keyboard_close }, { "read", keyboard_read },
{ "get-key-map", keyboard_get_key_map }, };
#ifdef CONFIG_DEBUG_USB
It looks like the ADB version is similar, apart from it also has this comment:
/* Debugging BootX: the lines below force get-key-map to report that * cmd-V is being held down, which forces BootX to run in verbose mode * for debugging. * * TODO: if we can find a mapping between the get-key-map bitmap and * ADB scancodes, the keyboard driver should be altered to update this * accordingly. */
/* kbd->keytable[3] = 0x40; kbd->keytable[28] = 0x10;
Might be worth adding a similar comment (and maybe even testing it) for the USB version, but regardless:
Reviewed-by: Mark Cave-Ayland mark.cave-ayland@ilande.co.uk
ATB,
Mark.
On Sat, 28 Jan 2023, Mark Cave-Ayland wrote:
On 27/01/2023 13:33, BALATON Zoltan wrote:
Mac OS X calls it during boot. This gets rid of an error saying "call-method slw_update_keymap failed with error ffffffdf" but otherwise does not seem to matter. It's probably used for getting the pressed keys that can change some boot actions like enable verbose mode with Cmd-V.
Signed-off-by: BALATON Zoltan balaton@eik.bme.hu
drivers/usbhid.c | 8 ++++++++ 1 file changed, 8 insertions(+)
diff --git a/drivers/usbhid.c b/drivers/usbhid.c index b8e1548..d3ad4ef 100644 --- a/drivers/usbhid.c +++ b/drivers/usbhid.c @@ -52,12 +52,20 @@ keyboard_close(int *idx) { } +static void +keyboard_get_key_map(void) +{
- static char keytable[32] = { 0 };
- PUSH(pointer2cell(keytable));
+}
- static void keyboard_read(void); NODE_METHODS( usb_kbd ) = { { "open", keyboard_open }, { "close", keyboard_close }, { "read", keyboard_read },
- { "get-key-map", keyboard_get_key_map }, }; #ifdef CONFIG_DEBUG_USB
It looks like the ADB version is similar, apart from it also has this comment:
/* Debugging BootX: the lines below force get-key-map to report that * cmd-V is being held down, which forces BootX to run in verbosemode * for debugging. * * TODO: if we can find a mapping between the get-key-map bitmap and * ADB scancodes, the keyboard driver should be altered to update this * accordingly. */
/* kbd->keytable[3] = 0x40; kbd->keytable[28] = 0x10;Might be worth adding a similar comment (and maybe even testing it) for the USB version, but regardless:
I don't think repeating that comment here is useful. This seems to be used by MacOS to check if keys are held down during boot such as changing to boot from cd, clear PRAM, enable safe mode, etc. So there are more than what the comment mentions but that may rather belong in arch/ppc somewhere with some way to override these during boot to simulate key press for debugging. This patch just gets rid of the warnings printed during booting MacOS but I haven't seen any other change. The non-working devices are probably due to some bug in QEMU's ohci emulation. If we actually want to implement this correctly then key presses may need to set and clear bits in this array but none of the current implementations do that and the meaning of the bits are also not known. Also it may be hard to actually hold down keys during boot as it's faster in emulation than on real hardware so to be useful it should have some other way to define this before start.
Regards, BALATON Zoltan
Reviewed-by: Mark Cave-Ayland mark.cave-ayland@ilande.co.uk
ATB,
Mark. _______________________________________________ OpenBIOS mailing list -- openbios@openbios.org To unsubscribe send an email to openbios-leave@openbios.org
On 28/01/2023 22:59, BALATON Zoltan wrote:
On Sat, 28 Jan 2023, Mark Cave-Ayland wrote:
On 27/01/2023 13:33, BALATON Zoltan wrote:
Mac OS X calls it during boot. This gets rid of an error saying "call-method slw_update_keymap failed with error ffffffdf" but otherwise does not seem to matter. It's probably used for getting the pressed keys that can change some boot actions like enable verbose mode with Cmd-V.
Signed-off-by: BALATON Zoltan balaton@eik.bme.hu
drivers/usbhid.c | 8 ++++++++ 1 file changed, 8 insertions(+)
diff --git a/drivers/usbhid.c b/drivers/usbhid.c index b8e1548..d3ad4ef 100644 --- a/drivers/usbhid.c +++ b/drivers/usbhid.c @@ -52,12 +52,20 @@ keyboard_close(int *idx) { } +static void +keyboard_get_key_map(void) +{ + static char keytable[32] = { 0 }; + PUSH(pointer2cell(keytable)); +}
static void keyboard_read(void); NODE_METHODS( usb_kbd ) = { { "open", keyboard_open }, { "close", keyboard_close }, { "read", keyboard_read }, + { "get-key-map", keyboard_get_key_map }, }; #ifdef CONFIG_DEBUG_USB
It looks like the ADB version is similar, apart from it also has this comment:
/* Debugging BootX: the lines below force get-key-map to report that * cmd-V is being held down, which forces BootX to run in verbose mode * for debugging. * * TODO: if we can find a mapping between the get-key-map bitmap and * ADB scancodes, the keyboard driver should be altered to update this * accordingly. */
/* kbd->keytable[3] = 0x40; kbd->keytable[28] = 0x10;
Might be worth adding a similar comment (and maybe even testing it) for the USB version, but regardless:
I don't think repeating that comment here is useful. This seems to be used by MacOS to check if keys are held down during boot such as changing to boot from cd, clear PRAM, enable safe mode, etc. So there are more than what the comment mentions but that may rather belong in arch/ppc somewhere with some way to override these during boot to simulate key press for debugging. This patch just gets rid of the warnings printed during booting MacOS but I haven't seen any other change. The non-working devices are probably due to some bug in QEMU's ohci emulation. If we actually want to implement this correctly then key presses may need to set and clear bits in this array but none of the current implementations do that and the meaning of the bits are also not known. Also it may be hard to actually hold down keys during boot as it's faster in emulation than on real hardware so to be useful it should have some other way to define this before start.
I should clarify that I'm not suggesting to implement the full bitmap, but copying the comment and suggested entries for debugging BootX is helpful. There are developers less familiar with the Mac history who wouldn't think to look up the corresponding code for ADB devices when attempting to debug the BootX startup process.
ATB,
Mark.
On Mon, 6 Mar 2023, Mark Cave-Ayland wrote:
On 28/01/2023 22:59, BALATON Zoltan wrote:
On Sat, 28 Jan 2023, Mark Cave-Ayland wrote:
On 27/01/2023 13:33, BALATON Zoltan wrote:
Mac OS X calls it during boot. This gets rid of an error saying "call-method slw_update_keymap failed with error ffffffdf" but otherwise does not seem to matter. It's probably used for getting the pressed keys that can change some boot actions like enable verbose mode with Cmd-V.
Signed-off-by: BALATON Zoltan balaton@eik.bme.hu
drivers/usbhid.c | 8 ++++++++ 1 file changed, 8 insertions(+)
diff --git a/drivers/usbhid.c b/drivers/usbhid.c index b8e1548..d3ad4ef 100644 --- a/drivers/usbhid.c +++ b/drivers/usbhid.c @@ -52,12 +52,20 @@ keyboard_close(int *idx) { } +static void +keyboard_get_key_map(void) +{ + static char keytable[32] = { 0 }; + PUSH(pointer2cell(keytable)); +}
static void keyboard_read(void); NODE_METHODS( usb_kbd ) = { { "open", keyboard_open }, { "close", keyboard_close }, { "read", keyboard_read }, + { "get-key-map", keyboard_get_key_map }, }; #ifdef CONFIG_DEBUG_USB
It looks like the ADB version is similar, apart from it also has this comment:
/* Debugging BootX: the lines below force get-key-map to report that * cmd-V is being held down, which forces BootX to run in verbose mode * for debugging. * * TODO: if we can find a mapping between the get-key-map bitmap and * ADB scancodes, the keyboard driver should be altered to update this * accordingly. */
/* kbd->keytable[3] = 0x40; kbd->keytable[28] = 0x10;
Might be worth adding a similar comment (and maybe even testing it) for the USB version, but regardless:
I don't think repeating that comment here is useful. This seems to be used by MacOS to check if keys are held down during boot such as changing to boot from cd, clear PRAM, enable safe mode, etc. So there are more than what the comment mentions but that may rather belong in arch/ppc somewhere with some way to override these during boot to simulate key press for debugging. This patch just gets rid of the warnings printed during booting MacOS but I haven't seen any other change. The non-working devices are probably due to some bug in QEMU's ohci emulation. If we actually want to implement this correctly then key presses may need to set and clear bits in this array but none of the current implementations do that and the meaning of the bits are also not known. Also it may be hard to actually hold down keys during boot as it's faster in emulation than on real hardware so to be useful it should have some other way to define this before start.
I should clarify that I'm not suggesting to implement the full bitmap, but copying the comment and suggested entries for debugging BootX is helpful. There are developers less familiar with the Mac history who wouldn't think to look up the corresponding code for ADB devices when attempting to debug the BootX startup process.
I'm not sure the suggested values would be correct for USB as well so blindly copying that comment might be unhelpful for future readers. Searching for get-key-map should turn up the comment on ADB and depeding which BootX this applies to people are better off refrring to the source of that instead of relying on unverified info here. So unless this can be tested I'd rather don't add that comment but I don't have time and interest to test it.
But it you want you can add the comment when merging and note it in a [comment] in the commit message near the Signed-off-by tags, I don't mind you doing that.
Regards, BALATON Zoltan
On 06/03/2023 21:31, BALATON Zoltan wrote:
On Mon, 6 Mar 2023, Mark Cave-Ayland wrote:
On 28/01/2023 22:59, BALATON Zoltan wrote:
On Sat, 28 Jan 2023, Mark Cave-Ayland wrote:
On 27/01/2023 13:33, BALATON Zoltan wrote:
Mac OS X calls it during boot. This gets rid of an error saying "call-method slw_update_keymap failed with error ffffffdf" but otherwise does not seem to matter. It's probably used for getting the pressed keys that can change some boot actions like enable verbose mode with Cmd-V.
Signed-off-by: BALATON Zoltan balaton@eik.bme.hu
drivers/usbhid.c | 8 ++++++++ 1 file changed, 8 insertions(+)
diff --git a/drivers/usbhid.c b/drivers/usbhid.c index b8e1548..d3ad4ef 100644 --- a/drivers/usbhid.c +++ b/drivers/usbhid.c @@ -52,12 +52,20 @@ keyboard_close(int *idx) { } +static void +keyboard_get_key_map(void) +{ + static char keytable[32] = { 0 }; + PUSH(pointer2cell(keytable)); +}
static void keyboard_read(void); NODE_METHODS( usb_kbd ) = { { "open", keyboard_open }, { "close", keyboard_close }, { "read", keyboard_read }, + { "get-key-map", keyboard_get_key_map }, }; #ifdef CONFIG_DEBUG_USB
It looks like the ADB version is similar, apart from it also has this comment:
/* Debugging BootX: the lines below force get-key-map to report that * cmd-V is being held down, which forces BootX to run in verbose mode * for debugging. * * TODO: if we can find a mapping between the get-key-map bitmap and * ADB scancodes, the keyboard driver should be altered to update this * accordingly. */
/* kbd->keytable[3] = 0x40; kbd->keytable[28] = 0x10;
Might be worth adding a similar comment (and maybe even testing it) for the USB version, but regardless:
I don't think repeating that comment here is useful. This seems to be used by MacOS to check if keys are held down during boot such as changing to boot from cd, clear PRAM, enable safe mode, etc. So there are more than what the comment mentions but that may rather belong in arch/ppc somewhere with some way to override these during boot to simulate key press for debugging. This patch just gets rid of the warnings printed during booting MacOS but I haven't seen any other change. The non-working devices are probably due to some bug in QEMU's ohci emulation. If we actually want to implement this correctly then key presses may need to set and clear bits in this array but none of the current implementations do that and the meaning of the bits are also not known. Also it may be hard to actually hold down keys during boot as it's faster in emulation than on real hardware so to be useful it should have some other way to define this before start.
I should clarify that I'm not suggesting to implement the full bitmap, but copying the comment and suggested entries for debugging BootX is helpful. There are developers less familiar with the Mac history who wouldn't think to look up the corresponding code for ADB devices when attempting to debug the BootX startup process.
I'm not sure the suggested values would be correct for USB as well so blindly copying that comment might be unhelpful for future readers. Searching for get-key-map should turn up the comment on ADB and depeding which BootX this applies to people are better off refrring to the source of that instead of relying on unverified info here. So unless this can be tested I'd rather don't add that comment but I don't have time and interest to test it.
That would make no sense though - otherwise BootX would require separate knowledge of USB and ADB devices and their individual layouts, rather than simply opening the keyboard device and executing "get-key-map" and then checking for keys of interest.
But it you want you can add the comment when merging and note it in a [comment] in the commit message near the Signed-off-by tags, I don't mind you doing that.
I'm still deep in OpenBIOS internals trying to figure out why your config word patch doesn't seem to be doing the right thing (emphasising here again that I don't think the patch itself is at fault, but it's exposing an existing bug). If you can send an updated patch with the comment, I'll aim to apply it later before sending a 8.0 OpenBIOS PR for QEMU.
ATB,
Mark.
-
BALATON Zoltan -
Mark Cave-Ayland