On Mon, Jun 1, 2020 at 7:45 PM Gary Aitken <[email protected]> wrote:
> 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? Not really no. :( uhub is the 'bus' of USB, but beyond that it gets murky. > 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 :-). > You might find that devinfo -v gives you enough information to hold dementia at bay for another day or three... Or not if I've lost it Warner _______________________________________________ [email protected] mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[email protected]"
