get-key-map method for Mac OS (was Re: [PATCH v7 6/7] mac_newworld: Deprecate mac99 "via" option)
On Fri, 27 Jan 2023, Howard Spoelstra wrote:
On Fri, Jan 27, 2023 at 3:29 AM BALATON Zoltan balaton@eik.bme.hu wrote:
On Fri, 27 Jan 2023, BALATON Zoltan wrote:
On Thu, 26 Jan 2023, Howard Spoelstra wrote:
On Thu, Jan 26, 2023 at 9:57 PM BALATON Zoltan balaton@eik.bme.hu
wrote:
On Thu, 26 Jan 2023, Howard Spoelstra wrote:
Mac OS X #10.0 bus1 mouse: usb_ohci_stop pci-ohci: USB Suspended. Reverts to
adb
mouse. No recognition as HID device. #10.0 bus2 kbd: usb_ohci_stop pci-ohci: USB Suspended. Up to that
point
kbd
pcap shows normal interrupt operation and recognition as HID device #10.0 bus1 kbd: usb_ohci_stop pci-ohci: USB Suspended. Up to that
point
kbd
pcap shows normal interrupt operation and recognition as HID device #10.0 bus2 mouse: usb_ohci_stop pci-ohci: USB Suspended. Reverts to
adb
mouse. pcap shows no recognition as HID device. #10.0 in both cases apple system profiler shows 2 usb buses but no
devices.
These are all the logs I get booting a 10.0 install iso with mac99,via=pmu
> ============================================================= > OpenBIOS 1.1 [May 25 2022 20:04] > Configuration device id QEMU version 1 machine id 1 > CPUs: 1 > Memory: 256M > UUID: 00000000-0000-0000-0000-000000000000 > CPU type PowerPC,G4
milliseconds isn't unique.
> switching to new context: > call-method slw_update_keymap failed with error ffffffdf > call-method slw_update_keymap failed with error ffffffdf
usb_ohci_reset pci-ohci usb_ohci_stop pci-ohci: USB Suspended usb_ohci_set_ctl pci-ohci: new state 0x0 usb_ohci_stop pci-ohci: USB Suspended usb_ohci_port_detach port #0 usb_ohci_port_attach port #0 usb_ohci_port_detach port #1 usb_ohci_port_attach port #1 dbdma_unassigned_flush: use of unassigned channel 0 dbdma_unassigned_flush: use of unassigned channel 0 usb_ohci_mem_write_bad_offset 0x30 usb_ohci_set_ctl pci-ohci: new state 0x80 usb_ohci_start pci-ohci: USB Operational usb_ohci_hub_power_up powered up all ports usb_ohci_hub_power_up powered up all ports usb_ohci_set_ctl pci-ohci: new state 0xc0 usb_ohci_stop pci-ohci: USB Suspended usb_ohci_hub_power_up powered up all ports usb_ohci_hub_power_up powered up all ports usb_ohci_port_reset port #0
It's probably OK until it restarts but the seems to be stopped. Anybody wants to have a look? Maybe start with finding what the states mean.
I get the same with two usb-ohci controllers (so 6 ports) running Mac OS 9.0.4:
usb_ohci_set_ctl pci-ohci: new state 0x80 usb_ohci_start pci-ohci: USB Operational usb_ohci_hub_power_up powered up all ports usb_ohci_hub_power_up powered up all ports usb_ohci_hub_power_up powered up all ports usb_ohci_hub_power_up powered up all ports usb_ohci_hub_power_up powered up all ports usb_ohci_hub_power_up powered up all ports usb_ohci_port_reset port #0 usb_ohci_port_reset port #0
So both usb mouse and kbd do not work.
the pcap file for the mouse stalls here: 12 0.007048 0.1.0 host USB 64 SET CONFIGURATION Response
Maybe the driver gets something from the emulated HID device that it
cannot
handle and stops during init? Can you reproduce the same with OS X 10.0
and
try to correlate the events you see in pcap and trace with the driver
source
or find out how to enable and read the messages in the driver (unless
these
are stripped from the binary in Mac OS X but maybe there's something in
the
guest logs; ave you checked those?) In QEMU the usb-kbd and mouse are implemented in hw/usb/dev-hid.c but this file does not have any debuging
or
traces. You might try to add some printfs for testing.
However, when I use the usb probe tool from the USB DDK, to probe the
buses
I see the host emit a get descriptor
13 115.761725 host 0.0.0 USB 64 GET DESCRIPTOR Request DEVICE 14 115.761803 0.0.0 host USB 72 GET DESCRIPTOR Response DEVICE 15 115.773719 host 0.0.0 USB 64 SET ADDRESS Request etc. and this time the mouse is recognised as HID device, the host
starts
polling it and mouse and kbd start to work.
It could be possible that the driver did not get to this point but once something else get's past that it recognises the device but I have no
idea
how this works and not even sure which OS you had this result with. Is
this
still 9.0.4? That's hard to debug because we don't know what its driver
is
doing.
Is there a Darwin, OpenDarwin or whatever was that called during the
years
iso that boots on this machine (also on the real one)? That should be
fully
open source and probably have the same drivers as Mac OS X so
reproducing
with that could give some more info or maybe its driver is more verbose
about
errors and has debugging. So you could try to find an early Darwin
version
that's about the same time as early OS X versions or look at the
IOHIDFamily
and try to find what part of it is running when you see the logs (as
this
driver is quite complex it may not be easy).
The oldest Darwin CD I could find is 6.2 which boots and works so it's not old enough for us.
The simplest driver is in the oldest 10.0 version so maybe we should try to look at that:
https://github.com/apple-oss-distributions/IOHIDFamily/tree/IOHIDFamily-6
and the low level part is in the xnu kernel:
https://github.com/apple-oss-distributions/xnu/tree/xnu-123.5/iokit/Families...
I don't quite know how it works and where it starts running but a large part of it looks like it handles key mapping. While booting I see an error from OpenBIOS saying:
call-method slw_update_keymap failed with error ffffffdf
Could this be related to the problem? What is this error about? This PearPC bug has some info on where it may come from:
This seem to come from here: https://web.archive.org/web/20150922180615/http://www.opensource.apple.com/s...
Great. That's now here (also this is the earilest 10.0 version which should be the simplest):
https://github.com/apple-oss-distributions/BootX/blob/BootX-34/bootx.tproj/c...
This seems to want to call get-key-map method on keyboard. Searching for that in OpenBIOS shows we have that implemented in openbios/drivers/adb_kbd.c and arch/ppc/mol/methods.c but not for usb keyboard.
I'm moving this thread to the openbios mailing list as it is now more about this issue than my qemu patch. Any idea/suggestion how should we add this method to the usb keyboard in OpenBIOS? I've ported the USB driver back then but I forgot all about it. There are some methods defined in openbios/drivers/usbhid.c so I guess I could copy it from one of the above two implementations but maybe it's a good time to try to share it between these places but I'm not sure what's the best way for that.
Regards, BALATON Zoltan
On Fri, 27 Jan 2023, BALATON Zoltan wrote:
On Fri, 27 Jan 2023, Howard Spoelstra wrote:
On Fri, Jan 27, 2023 at 3:29 AM BALATON Zoltan balaton@eik.bme.hu wrote:
On Fri, 27 Jan 2023, BALATON Zoltan wrote:
On Thu, 26 Jan 2023, Howard Spoelstra wrote:
On Thu, Jan 26, 2023 at 9:57 PM BALATON Zoltan balaton@eik.bme.hu
wrote:
On Thu, 26 Jan 2023, Howard Spoelstra wrote: > Mac OS X > #10.0 bus1 mouse: usb_ohci_stop pci-ohci: USB Suspended. Reverts to
adb
> mouse. No recognition as HID device. > #10.0 bus2 kbd: usb_ohci_stop pci-ohci: USB Suspended. Up to that
point
kbd > pcap shows normal interrupt operation and recognition as HID device > #10.0 bus1 kbd: usb_ohci_stop pci-ohci: USB Suspended. Up to that
point
kbd > pcap shows normal interrupt operation and recognition as HID device > #10.0 bus2 mouse: usb_ohci_stop pci-ohci: USB Suspended. Reverts to
adb
> mouse. pcap shows no recognition as HID device. > #10.0 in both cases apple system profiler shows 2 usb buses but no devices.
These are all the logs I get booting a 10.0 install iso with mac99,via=pmu
>> ============================================================= >> OpenBIOS 1.1 [May 25 2022 20:04] >> Configuration device id QEMU version 1 machine id 1 >> CPUs: 1 >> Memory: 256M >> UUID: 00000000-0000-0000-0000-000000000000 >> CPU type PowerPC,G4 milliseconds isn't unique. >> switching to new context: >> call-method slw_update_keymap failed with error ffffffdf >> call-method slw_update_keymap failed with error ffffffdf usb_ohci_reset pci-ohci usb_ohci_stop pci-ohci: USB Suspended usb_ohci_set_ctl pci-ohci: new state 0x0 usb_ohci_stop pci-ohci: USB Suspended usb_ohci_port_detach port #0 usb_ohci_port_attach port #0 usb_ohci_port_detach port #1 usb_ohci_port_attach port #1 dbdma_unassigned_flush: use of unassigned channel 0 dbdma_unassigned_flush: use of unassigned channel 0 usb_ohci_mem_write_bad_offset 0x30 usb_ohci_set_ctl pci-ohci: new state 0x80 usb_ohci_start pci-ohci: USB Operational usb_ohci_hub_power_up powered up all ports usb_ohci_hub_power_up powered up all ports usb_ohci_set_ctl pci-ohci: new state 0xc0 usb_ohci_stop pci-ohci: USB Suspended usb_ohci_hub_power_up powered up all ports usb_ohci_hub_power_up powered up all ports usb_ohci_port_reset port #0
It's probably OK until it restarts but the seems to be stopped. Anybody wants to have a look? Maybe start with finding what the states mean.
I get the same with two usb-ohci controllers (so 6 ports) running Mac OS 9.0.4:
usb_ohci_set_ctl pci-ohci: new state 0x80 usb_ohci_start pci-ohci: USB Operational usb_ohci_hub_power_up powered up all ports usb_ohci_hub_power_up powered up all ports usb_ohci_hub_power_up powered up all ports usb_ohci_hub_power_up powered up all ports usb_ohci_hub_power_up powered up all ports usb_ohci_hub_power_up powered up all ports usb_ohci_port_reset port #0 usb_ohci_port_reset port #0
So both usb mouse and kbd do not work.
the pcap file for the mouse stalls here: 12 0.007048 0.1.0 host USB 64 SET CONFIGURATION Response
Maybe the driver gets something from the emulated HID device that it
cannot
handle and stops during init? Can you reproduce the same with OS X 10.0
and
try to correlate the events you see in pcap and trace with the driver
source
or find out how to enable and read the messages in the driver (unless
these
are stripped from the binary in Mac OS X but maybe there's something in
the
guest logs; ave you checked those?) In QEMU the usb-kbd and mouse are implemented in hw/usb/dev-hid.c but this file does not have any debuging
or
traces. You might try to add some printfs for testing.
However, when I use the usb probe tool from the USB DDK, to probe the
buses
I see the host emit a get descriptor
13 115.761725 host 0.0.0 USB 64 GET DESCRIPTOR Request DEVICE 14 115.761803 0.0.0 host USB 72 GET DESCRIPTOR Response DEVICE 15 115.773719 host 0.0.0 USB 64 SET ADDRESS Request etc. and this time the mouse is recognised as HID device, the host
starts
polling it and mouse and kbd start to work.
It could be possible that the driver did not get to this point but once something else get's past that it recognises the device but I have no
idea
how this works and not even sure which OS you had this result with. Is
this
still 9.0.4? That's hard to debug because we don't know what its driver
is
doing.
Is there a Darwin, OpenDarwin or whatever was that called during the
years
iso that boots on this machine (also on the real one)? That should be
fully
open source and probably have the same drivers as Mac OS X so
reproducing
with that could give some more info or maybe its driver is more verbose
about
errors and has debugging. So you could try to find an early Darwin
version
that's about the same time as early OS X versions or look at the
IOHIDFamily
and try to find what part of it is running when you see the logs (as
this
driver is quite complex it may not be easy).
The oldest Darwin CD I could find is 6.2 which boots and works so it's not old enough for us.
The simplest driver is in the oldest 10.0 version so maybe we should try to look at that:
https://github.com/apple-oss-distributions/IOHIDFamily/tree/IOHIDFamily-6
and the low level part is in the xnu kernel:
https://github.com/apple-oss-distributions/xnu/tree/xnu-123.5/iokit/Families...
I don't quite know how it works and where it starts running but a large part of it looks like it handles key mapping. While booting I see an error from OpenBIOS saying:
call-method slw_update_keymap failed with error ffffffdf
Could this be related to the problem? What is this error about? This PearPC bug has some info on where it may come from:
This seem to come from here: https://web.archive.org/web/20150922180615/http://www.opensource.apple.com/s...
Great. That's now here (also this is the earilest 10.0 version which should be the simplest):
https://github.com/apple-oss-distributions/BootX/blob/BootX-34/bootx.tproj/c...
This seems to want to call get-key-map method on keyboard. Searching for that in OpenBIOS shows we have that implemented in openbios/drivers/adb_kbd.c and arch/ppc/mol/methods.c but not for usb keyboard.
I'm moving this thread to the openbios mailing list as it is now more about this issue than my qemu patch. Any idea/suggestion how should we add this method to the usb keyboard in OpenBIOS? I've ported the USB driver back then but I forgot all about it. There are some methods defined in openbios/drivers/usbhid.c so I guess I could copy it from one of the above two implementations but maybe it's a good time to try to share it between these places but I'm not sure what's the best way for that.
Looks like there's not much to share as this is just returning a pointer to 32 bytes which should hold the state of keys held down. Patch sent to add that to usbhid which makes the error go away unfortunately it does not fix the problem with OS X 10.0 so it's somethung else causing that.
Regards, BALATON Zoltan
-
BALATON Zoltan