Manage USB devices via Chromium Serial API

I have a CharaChorder One keyboard, and some of it's functionality is managed via a web page, that uses the Serial API from web browsers (like Chrome/Chromium). I've followed some Linux guides, like add the user to the dialout or dialer group to get access to
/dev/tty* but still it seems Chromium can't find my keyboard.

Does anyone know if this is at all possible with FreeBSD 13.2 or 14 - or do I need to keep using my wife's iMac for certain features (eg: upgrading my keyboard firmware, manage the chording library etc). :)

 
A USB serial device usually shows up as /dev/ttyU* and/or /dev/cuaU* (ucom(4)). Are any of those actually getting detected?

I'd run tail -F /var/log/messages in a terminal, then plugin the keyboard. Have a look at the devices that are being detected. It's also possible some specific command needs to be send to the device in order for the serial interface to show up.

We'll worry about permissions if we can find the serial device.
 
The CharaChorder One (CC1) keyboard itself works just fine (after I disabled the old keyboard/USB modules - recommended to me in another thread ). I was just curious about Chrome/Chromium browser accessing Serial devices under FreeBSD.

SirDice, I followed your instructions and this is the log output when I connect my CharaChorder One keyboard.

Code:
Feb  9 17:21:37 graeme-desktop kernel: hidbus6: detached
Feb  9 17:21:37 graeme-desktop kernel: usbhid6: detached
Feb  9 17:21:44 graeme-desktop kernel: ugen1.2: <CharaChorder CharaChorder One USB Serial> at usbus1
Feb  9 17:21:44 graeme-desktop kernel: umodem0 on uhub1
Feb  9 17:21:44 graeme-desktop kernel: umodem0: <CharaChorder CharaChorder One USB Serial, class 239/2, rev 2.00/1.00, addr 1> on usbus1
Feb  9 17:21:44 graeme-desktop kernel: umodem0: data interface 1, has no CM over data, has break
Feb  9 17:21:45 graeme-desktop kernel: usbhid6 on uhub1
Feb  9 17:21:45 graeme-desktop kernel: usbhid6: <CharaChorder CharaChorder One USB Serial, class 239/2, rev 2.00/1.00, addr 1> on usbus1
Feb  9 17:21:45 graeme-desktop kernel: hidbus6: <HID bus> on usbhid6
Feb  9 17:21:45 graeme-desktop kernel: hkbd2: <CharaChorder CharaChorder One USB Serial Keyboard> on hidbus6
Feb  9 17:21:45 graeme-desktop kernel: kbd4 at hkbd2
Feb  9 17:21:45 graeme-desktop kernel: hms2: <CharaChorder CharaChorder One USB Serial Mouse>
Feb  9 17:21:45 graeme-desktop kernel:  on hidbus6
Feb  9 17:21:45 graeme-desktop kernel: hms2: 5 buttons and [XYWH] coordinates ID=1

cracauer@: Here is the output of
usbconfig
....
Code:
ugen0.1: <AMD XHCI root HUB> at usbus0, cfg=0 md=HOST spd=SUPER (5.0Gbps) pwr=SAVE (0mA)
ugen2.1: <AMD XHCI root HUB> at usbus2, cfg=0 md=HOST spd=SUPER (5.0Gbps) pwr=SAVE (0mA)
ugen1.1: <AMD XHCI root HUB> at usbus1, cfg=0 md=HOST spd=SUPER (5.0Gbps) pwr=SAVE (0mA)
ugen2.2: <American Power Conversion Back-UPS XS 1400U  FW:926.T2 .I USB FW:T2> at usbus2, cfg=0 md=HOST spd=LOW (1.5Mbps) pwr=ON (24mA)
ugen1.4: <AsusTek Computer Inc. AURA LED Controller> at usbus1, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (16mA)
ugen2.3: <vendor 0x1a40 USB 2.0 Hub> at usbus2, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (100mA)
ugen2.4: <vendor 0x0424 product 0x2514> at usbus2, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (2mA)
ugen2.5: <vendor 0x0424 product 0x2640> at usbus2, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (2mA)
ugen2.6: <Generic Ultra Fast Media Reader> at usbus2, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (96mA)
ugen2.7: <Graeme Geldenhuys Ergodox (Hacked by Graeme)> at usbus2, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (500mA)
ugen2.8: <CMEDIA Q9-1> at usbus2, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (100mA)
ugen2.9: <Logitech USB-PS/2 Optical Mouse> at usbus2, cfg=0 md=HOST spd=LOW (1.5Mbps) pwr=ON (98mA)
ugen1.2: <CharaChorder CharaChorder One USB Serial> at usbus1, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (100mA)
 
Interesting that it shows up as umodem(4):
Code:
Feb  9 17:21:44 graeme-desktop kernel: umodem0: <CharaChorder CharaChorder One USB Serial, class 239/2, rev 2.00/1.00, addr 1> on usbus1
I suspect this is the serial interface you need. Does ls -l /dev/ttyU* /dev/cuaU* show anything when it's plugged in?
 
This is what I see:
Code:
graemeg@graeme-desktop:~ % ls -l /dev/ttyU* /dev/cuaU*
crw-rw----  1 uucp  dialer  0x111  9 Feb 17:21 /dev/cuaU0
crw-rw----  1 uucp  dialer  0x112  9 Feb 17:21 /dev/cuaU0.init
crw-rw----  1 uucp  dialer  0x113  9 Feb 17:21 /dev/cuaU0.lock
crw-------  1 root  wheel   0x10e  9 Feb 17:21 /dev/ttyU0
crw-------  1 root  wheel   0x10f  9 Feb 17:21 /dev/ttyU0.init
crw-------  1 root  wheel   0x110  9 Feb 17:21 /dev/ttyU0.lock

And these are the groups my user account belongs too:
Code:
graemeg@graeme-desktop:~ % groups
graemeg wheel operator video dialer vboxusers
 
So I ran chromium from a terminal window, and noticed that when I tried to connect to a serial device (my keyboard), it had log output saying that serial support in FreeBSD is disabled.

Code:
[20210:-36888576:0419/190320.166177:ERROR:device_service.cc(337)] Check failed: false. Serial devices not supported on this platform.

I then Googled for that output in the chromium source code, and found it here:


Then searching in the ports tree of chromium patches, I found that flag was disabled in the /usr/ports/www/chromium/files/patch-services_device_BUILD.gn file.

I also noted that the 'use_udev' flag was disabled under FreeBSD too. So that would explain why Serial API support doesn't work. A pity. I've reached the limit of my investigation and Chromium source code is well above my skill level. :)

At least I know it's not simply a permission problem now.
 
Back
Top