crank icon indicating copy to clipboard operation
crank copied to clipboard

--device is hardcoded for a specific playdate on Unix

Open kettle11 opened this issue 2 years ago • 7 comments

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

kettle11 avatar Apr 23 '22 01:04 kettle11

I think https://github.com/pd-rs/crank/pull/23 provides a work-around. I'll make the default work better in the future.

rtsuk avatar Apr 23 '22 12:04 rtsuk

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.

rtsuk avatar Apr 23 '22 13:04 rtsuk

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.

kettle11 avatar Apr 24 '22 02:04 kettle11

So long as there's some code to handle the no playdate plugged in at all case that seems good to me.

rtsuk avatar Apr 24 '22 12:04 rtsuk

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?

rtsuk avatar Apr 24 '22 12:04 rtsuk

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.

tjkirch avatar Feb 26 '23 17:02 tjkirch

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.

rtsuk avatar Feb 26 '23 17:02 rtsuk