Ok, I've rebooted even though I didn't need to ;-)
If I start an X session as root, when I start arduino the Serial Port
menu item is live; I have the needed access and see 4 devices:
/dev/ttyu0
/dev/cuau0
/dev/ttyU0
/dev/cuaU0
In my case, /dev/cuaU0 is what responds when I have the arduino
plugged in.
The other three devices are "permanently" present;
cuaU0 only appears when the arduino is plugged in.
If I assign cuaU0 as the arduino serial device, arduino uploads to
it fine.
So all is cool if you're the supreme being.
Switching back to a normal user, the entire serial port menu item
is still greyed out, so you see no choices even though the other
three devices are still present.
As a normal user:
$ grep skinnyguy /etc/group
operator:*:5:root,skinnyguy
video:*:44:skinnyguy
dialer:*:68:skinnyguy
$ grep devfs /etc/rc.conf
# allow local rules as specified in /etc/devfs.rules (5)
devfs_system_ruleset="localrules"
$ cat /etc/devfs.rules
# Allow operator group to mount USB devices
[localrules=5]
add path 'da*' mode 0660 group operator
# for arduino hotplug USB
add path 'ugen*' mode 0660 group operator
add path 'usb/*' mode 0660 group operator
add path 'usb' mode 0770 group operator
add path 'cuaU*' mode 0770 group operator
$ ls -l /dev/cuaU0
crwxrwx--- 1 uucp operator 0xac Jun 1 17:32 /dev/cuaU0
Giving +rw access to everyone for cua* makes no difference
Did I miss something along the way, or is there yet something else
that root has that I'm missing?
On 6/1/20 9:36 AM, Tomasz CEDRO wrote:
On Mon, Jun 1, 2020 at 5:28 PM Ian Lepore wrote:
There should be no need to unload ucom to access the low-level usb
device via libusb. I typically have anywhere from 5-8 usb-serial
adapters connected at once, it would be crazy to unload ucom and lose
access to all of them just to use one of them with libusb.
It is important, however, to avoid accessing /dev/cuaU# or /dev/ttyU#
at the same time that some application is using libusb (or libftdi) to
access that same device. That would cause ucom and the work being done
via libusb to conflict with each other.
Exactly the problem here. Either application tries to unload kernel
driver just to make sure terminal can connect to a dongle (linux
quickfix), or the modem port is already opened with u3g module (more
probable scenario). Anyway CMSIS-DAP has its own endpoint that is
separate from VCP so it should work without unloading the module.
Will verify and send patches to the upstream no worries, thanks for
the hints, but that could be another source of problem described by
Gary that I found in a similar application :-)
I'm running xfce via "/usr/local/bin/startxfce4 --with-ck-launch"
Other than a bunch of xterms, a clock, and thunderbird, nothing
special.
However, I see that dbus- has four instances, and at-spi-bus-launcher
has one:
$ ps ax | grep bus
604 - Is 0:00.03 /usr/local/bin/dbus-daemon --system
6260 - Is 0:00.03 /usr/local/bin/dbus-daemon --syslog --fork --print-pid
5 --print-address 7 --session
6262 - I 0:00.01 /usr/local/libexec/at-spi-bus-launcher
6263 - S 0:00.09 /usr/local/bin/dbus-daemon
--config-file=/usr/local/share/defaults/at-spi2/accessibility.conf --nofork --p
6259 v0 I 0:00.00 /usr/local/bin/dbus-launch --sh-syntax
--exit-with-session xfce4-session
Could these be interfering with user access as you hypothesize?
I don't *know* of any other apps accessing any usb port other than
the mouse.
Jun 1 17:32:30 breakaway kernel: ugen6.2: <Arduino www.arduino.cc product
0x0043> at usbus6
Jun 1 17:32:30 breakaway kernel: umodem0 on uhub3
Jun 1 17:32:30 breakaway kernel: umodem0: <Arduino www.arduino.cc product 0x0043,
class 2/0, rev 1.10/0.01, addr 2> on usbus6
Jun 1 17:32:30 breakaway kernel: umodem0: data interface 1, has CM over data,
has break
Is there a document describing the relationship between usb0 and
ugen6.2, umodem0, usbus6, and uhub3? I'm guessing something like
usbusn is a physical port on uhubm which is a physical multiplexor,
and ugena.b, umodemx and usbusy are somehow mapped to usbusn, but
that's a wild guess and probably not useful (to *me*) in making
progress here. But inquiring minds always want to know, if for
no other reason than to fight dementia :-).
Gary
_______________________________________________
freebsd-usb@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
