crank
crank copied to clipboard
--device is hardcoded for a specific playdate on Unix
This line is hardcoded for a specific playdate number so it won't work unless you're lucky enough to have that exact playdate.: https://github.com/pd-rs/crank/blob/6ac43230b11c3e5c431fd163faf708674637647c/src/main.rs#L370
I think https://github.com/pd-rs/crank/pull/23 provides a work-around. I'll make the default work better in the future.
Since the modem appears and disappears as the device is mounted as a disk, I don't think there is a way to make a good default. I think an environmental variable is the best we can do.
Since the modem appears and disappears as the device is mounted as a disk, I don't think there is a way to make a good default. I think an environmental variable is the best we can do.
I think a way to make it work would be to check for a modem with the correct prefix, if it exists use that. If it doesn't exist check for the PLAYDATE volume and eject it then search for the modem again.
So long as there's some code to handle the no playdate plugged in at all case that seems good to me.
Something like ioreg -p IOUSB | grep Playdate
would work on Mac. lsusb
for Linux, and maybe Get-PnpDevice -PresentOnly | Where-Object { $_.InstanceId -match '^USB' } | Select-String Playdate
on Windows?
I think a way to make it work would be to check for a modem with the correct prefix, if it exists use that
lsusb
for Linux
At least with lsusb 015, it only shows CDC ACM capability info, not the device path, at least not directly. Since other devices (like my keyboard) have the capability as well, that alone isn't enough to find the device. Here's how that section of the Playdate's information shows up:
iManufacturer 1 Panic Inc
iProduct 2 Playdate
iSerial 3 PDU1-Y999999
...
CDC Header:
bcdCDC 1.10
CDC Call Management:
bmCapabilities 0x00
bDataInterface 1
CDC ACM:
bmCapabilities 0x02
line coding and serial state
CDC Union:
bMasterInterface 0
bSlaveInterface 1
...
Interface Descriptor:
bInterfaceClass 10 CDC Data
...
However, I found that the kernel (or udev) creates a very useful symlink to the ttyACM device:
/dev/serial/by-id/usb-Panic_Inc_Playdate_PDU1-Y999999-if00 -> ../../ttyACM1
The pieces of the symlink name come from the manufacturer, product, and serial from lsusb, so we could probably reconstruct the exact name and therefore find the link, but I think it'd be fine to wildcard /dev/serial/by-id/usb-Panic_Inc_Playdate_PDU1-*
and use the result. We'd use the link target if found, and fall back to the current logic if not. If someone has two Playdates connected, they would set $PLAYDATE_SERIAL_DEVICE
, as they would today.
What do you think? I could write that for the Linux case.
Worth a shot. I'm not sure when I'll have the time to do the Mac side of the work, but that's no reason not to make it better for Linux.