Thanks for the info. In both cases, the final character is an
system_profiler, but a
1 in the device filename. I have no idea why that’s happening, but if that’s consistent, it’ll be simple enough to update the script to compensate.
Thanks for the info. In both cases, the final character is an
I just did a double-check and the device filename does change:
$ ls -l /dev/cu*
crw-rw-rw- 1 root wheel 21, 3 10 Feb 05:43 /dev/cu.Bluetooth-Incoming-Port
crw-rw-rw- 1 root wheel 21, 1 10 Feb 05:42 /dev/cu.SSDC
crw-rw-rw- 1 root wheel 21, 9 10 Feb 18:43 /dev/cu.usbmodemCDkbio01
The Serial Number: Ckbio01E entry from the system_profiler output looks more like a model number than a serial number. My assumption is that the trailing E designates a production run number. In either case it does not seem to play much of a role in selecting the device name.
In one instance of listing the device name I got “cu.usbmodemCkbio011” in the other I got “cu.usbmodemCDkbio01”. I am not sure of what criteria OSX is using to add the “D” or the trailing “1”. However the kbio01 appears to be consistent.
Presuming that the user does not have two keyboardio keyboards hooked into the same Mac, you could probably get away with using “DEVICE_PORT=/dev/cu.usbmodemkbio01” as a search term. It is certainly safer than catching every device attached to the usbmodem driver.
BTW I tried to find the the find-device-port-macos function, but could not find where it is defined. Is the function definition missing from the distribution?
My asterisks got dropped.
Should have been a star both before and after kbio01.
As in, DEVICE_PORT=/dev/cu.usbmodemkbio01
Using backticks for “code” works well:
We’re trying to determine the correct device name, rather than just guessing. And if you look at @blake’s report above, you’ll see that his (at least that one time) didn’t include the expected
kbio01 string, which I believe comes from here:
@blake’s string was
HIDHL, which likely came from this code instead:
I got the same issue trying to update the firmware, with the Model01-Firmware.
Product ID: 0x2301 Vendor ID: 0x1209 Version: 1.00 Serial Number: Ckbio01E Speed: Up to 12 Mb/sec Manufacturer: Keyboardio Location ID: 0x00200000 / 11 Current Available (mA): 500 Current Required (mA): 500 Extra Operating Current (mA): 0 Nicolass-Mac-Pro:Model01-Firmware nicolas$ ls -l /dev/cu.usb* crw-rw-rw- 1 root wheel 21, 5 18 Feb 16:11 /dev/cu.usbmodemCkbio011
In one i have a ‘E’ and he other i have a ‘1’.
i’m following this procedure to flash the firmware
Any idea what i need to modify to make it work ?
(i couldn’t find the kaleidoscope-builder conf file)
Heu … my bad … the update worked for me to. Here the result i got
Press ENTER when ready... In Find device port dir var /Users/nicolas/Documents/Arduino//hardware/keyboardio/avr/libraries/Kaleidoscope/bin dev port prob /Users/nicolas/Documents/Arduino//hardware/keyboardio/avr/libraries/Kaleidoscope/bin/find-device-port-macos Connecting to programmer: . Found programmer: Id = "CATERIN"; type = S Software Version = 1.0; No Hardware Version given. Programmer supports auto addr increment. Programmer supports buffered memory access with buffersize=128 bytes. Programmer supports the following devices: Device code: 0x44
I would say it works but not sure …
next step is trying to update the keymap … still looking …
Sorry; for some reason I overlooked this question earlier.
find-device-port-macos is a Perl script here: Kaleidoscope/bin/find-device-port-macos. It’s called from
I ran into the same problem. I managed it by just making the prober return the correct location.
Model 01: Product ID: 0x2301 Vendor ID: 0x1209 Version: 1.00 Serial Number: Ckbio01E Speed: Up to 12 Mb/sec Manufacturer: Keyboardio Location ID: 0x14100000 / 14 Current Available (mA): 500 Current Required (mA): 500 Extra Operating Current (mA): 0
The correct node is /dev/cu.usbmodemCkbio011, which the current prober can’t autodetect from the above info. Perhaps something changed with High Sierra that broke the prober?
It’s definitely not happening on every machine running High Sierra, but there are enough occurrences of this same exact phenomenon that I’ll submit a PR to fix it soon; probably this evening.
If you don’t mind, I’m interested to see what the output of this command is on a machine with this problem:
ioreg -p IOUSB -l -b | grep -E "@|PortNum|USB Serial Number"
In particular, the USB Serial Number string for the Model01, and if it’s different from what
Here’s what it looks like on mine; thanks for looking into fixing this:
+-o AppleUSBXHCI Root Hub Simulation@14000000 <class AppleUSBRootHubDevice, id 0x1000003f3, registered, matched, active, busy 0 (0 ms), retain 13> +-o Model 01@14100000 <class AppleUSBDevice, id 0x1000014ea, registered, matched, active, busy 0 (7 ms), retain 20> | "PortNum" = 1 | "USB Serial Number" = "Ckbio01" +-o iBridge@14200000 <class AppleUSBDevice, id 0x100001625, registered, matched, active, busy 0 (8 ms), retain 32> "PortNum" = 2
system_profiler SPUSBDataType shows it as
It has Ckbio01, no E:
Model 01: Product ID: 0x2301 Vendor ID: 0x1209 Version: 1.00 Serial Number: Ckbio01 Speed: Up to 12 Mb/sec Manufacturer: Keyboardio Location ID: 0x14100000 / 16 Current Available (mA): 500 Current Required (mA): 500 Extra Operating Current (mA): 0
A strange thing is that that changed sometime in the last few hours. In addition, the /dev node has changed name to something the script would pick up:
crw-rw-rw- 1 root wheel 33, 9 Feb 21 12:19 /dev/cu.usbmodemCkbio011
crw-rw-rw- 1 root wheel 33, 13 Feb 21 12:30 /dev/cu.usbmodemCkbio01
It might have occurred when I flashed my firmware to my fork at https://github.com/treed/Model01-Firmware ; which is a few months out of date with the main repo, although there’s nothing operative. Perhaps there was a bug in the firmware as shipped from the factory? This model just arrived today, unsure if that’s true of the others having this problem.
It’s also worth noting that the port name when the device is in the bootloader may be different than the device name when you’re booted into keyboard mode.
The data the keyboard-mode firmware supplies to macOS (including the serial number) could change between flashings, but the bootloader version won’t be altered by a simple flash-over-USB.
The prior serial and port name held at least through the point where I held down prog and hit enter on the keyboard, which I think would be past the point of the bootloader?
The trouble is that
system_profiler is now reporting a name that doesn’t match the device filename. I can update the prober script easily enough to compensate, but it feels like we’ll be going back to guessing.
Does ioreg tell more of the truth?
That’s what I’m trying to find out. Unfortunately, the only Mac I’ve got doesn’t seem to have this problem. Maybe I should try to trigger it by making it forget about the Model01 repeatedly?