Note: No `udev` configuration necessary on my Arch Linux box

[friedrichromstedt]

This is just to state that I am able to use pyftdi as an ordinary user on my Arch Linux box without any udev tinkering.

This means (to illustrate what I mean by "I am able to use"):

1. That I can run:

   $ python3
   >>> from pyftdi.ftdi import Ftdi
   >>> Ftdi().open_from_url('ftdi:///?')
   

   and that it will enumerate the FTDI devices present;

2. and that I can communicate with my FTDI device:

   $ python3
   >>> import ftdi
   >>> port = ftdi.serialext.serial_for_url('ftdi://ftdi:230x:<S/N>/1', baudrate=9600, bytesize=8, parity='N', stopbits=1)
   
   (sending data to the device:)
   >>> port.write(b'0ho1\a')
   5
   
   (now attempting to read without timeout, using ^C, then writing again and doing:)
   >>> port.timeout = 0
   >>> reply = port.read(1024)
   >>> reply
   bytearray(b'0POFFFFFFF9\r\n')
   

All this behaviour is to the specification.

Might this be useful for Arch Linux users interested in using pyftdi.

[eblot]

What is the user id when you run Python ?

[friedrichromstedt]

The user is friedrich; the groups reported by $ groups friedrich are friedrich and systemd-journal. On Arch Linux it is customary that for ordinary users (like friedrich, i.e. me), there is an accompanying group of the same name with this user as the only member (per /etc/passwd). Membership in systemd-journal via /etc/group is for the purpose of full access to the system journal (via journalctl, part of systemd).

[eblot]

Ok. I never worked with Arch Linux. Does it mean that anybody gets access to any USB device w/o any control on this distribution or is it something specific to a peculiar device class?

[friedrichromstedt]

Does it mean that anybody gets access to any USB device w/o any control on this distribution or is it something specific to a peculiar device class?

I just don't know. So far I've only tried the FTDI device this report is based on (in the way described above).

I did some quick googling (arch linux access usb devices and arch linux access usb devices FTDI) but did not find any conclusive information. Probably upstream needs to be consulted to find out more about this behaviour.

Maybe your're more educated than me about how to find out the important bits of information telling why I can access my FTDI device without introducing additional udev rules? This might help in narrowing down the question before possibly turning to upstream, if it does not already lead to a complete understanding.

[eblot]

I need to find some spare time to install Arch Linux then. I'm curious to know how it works. Never tried it: I do not know how to use their package manager.

[friedrichromstedt]

I'm pretty satisfied with Arch Linux. The package manager, pacman, does a very good job, the documentation is comprehensive, and things come without front-ends shadowing the internal mechanisms. Just have a look at https://wiki.archlinux.org/.

If I can help you out by investigation on my own Arch Linux box just let me know.

[eblot]

OMG... Back to 1992 when I spent so many nights trying to figure out why Linux did not boot... So Arch Linux does not have an installer (why not), BUT use that worse piece of software ever named systemd? What bootloader should I use to boot Arch in a (Parallels) VM ?

[eblot]

Syslinux does work (refind does not, grub is a PITA) but it seems I missed something as DHCP does not seem to be installed. I really do not plan to spend my whole week end figuring it out how to sort this endless list of install issues...

Is there an Arch Linux VM image ready to use somewhere ?

[friedrichromstedt]

I really do not plan to spend my whole week end figuring it out how to sort this endless list of install issues...

Arch Linux is a cutting-edge, hard-core distribution. Certainly it takes some time to get acquainted with its working.

Personally I've been using SUSE Linux in the time of secondary school, then used Windows (in the XP era) for several years, after that used the Macintosh for some more years (starting at the time of Snow Leopard). Some years ago, when it came to choose a new laptop, I decided for Linux (dual-boot with Windows 10) on a Lenovo machine, and chose Arch Linux as my distro after careful consideration. I agree that Arch Linux is quite opposite to the Macintosh in its approach to administration. For sure Arch Linux doesn't provide that kind of ease of use macOS offers.

All this is quite OT, but I'd like to indicate that I'm quite happy with systemd and grub.

If you're using macOS because it combines the power of a Unix system with the power of its interface, you probably never will feel comfortable with Arch.

as DHCP does not seem to be installed

You need to install the package of some DHCP client and you probably also will want to start it (via systemctl start <unit>) and enable it to be started automatically (by systemctl enable <unit>). You might use a device-specific unit like dhcpcd@<device>.

If you're not feeling like reading up-stream manuals you probably will end up with an endless chain of unanswered questions. To successfully use Arch, it is (in my opinion) inevitable to, in a certain degree, dive into the programs used with it. Low-level programs are included sometimes with this ...

Hope this is useful in some sense ... I would like to help with understanding the behaviour of Arch Linux w.r.t. accessing USB hardware, even though it will be difficult to find the time to.

[friedrichromstedt]

To verify that the behaviour didn't change in the meantime since I opened this issue, I am providing some more tests today.

There were also some mistakes in the code listing I provided on 20 December. Here is the content of a Python3 script I am using in this investigation:

#!/usr/bin/python3

import pyftdi.ftdi
import pyftdi.serialext


pyftdi.ftdi.Ftdi.show_devices()

print("Creating *port*.")
# It is necessary that the ``Serial`` object is closed when finished
# using it.  This can be achieved by using it as a context manager:
with pyftdi.serialext.serial_for_url('ftdi://ftdi:ft-x:DO011EDV/1',
        baudrate=9600, bytesize=8, parity='N', stopbits=1) as port:

    print("Homing the device.")
    port.write(b'0ho1\a')

    print("Reading reply with 5 seconds timeout.")
    port.timeout = 5
    reply = port.read(1024)
    print("Got reply: {}.".format(reply))

When running this script, the following output is produced:

Available interfaces:
  ftdi://ftdi:ft-x:DO011EDV/1   (FT230X Basic UART)

Creating *port*.
Homing the device.
Reading reply with 5 seconds timeout.
Got reply: b'0POFFFFFFFE\r\n'.

I logged the system journal during running the script, here is the log:

May 01 12:51:21 T470p kernel: usb 1-2: usbfs: interface 0 claimed by ftdi_sio while 'python3' sets config #1
May 01 12:51:21 T470p kernel: ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0
May 01 12:51:21 T470p kernel: ftdi_sio 1-2:1.0: device disconnected
May 01 12:51:23 T470p kernel: ftdi_sio 1-2:1.0: FTDI USB Serial Device converter detected
May 01 12:51:23 T470p kernel: usb 1-2: Detected FT-X
May 01 12:51:23 T470p kernel: usb 1-2: FTDI USB Serial Device converter now attached to ttyUSB0

Result: It is still not necessary for me to create custom udev rules on my Arch Linux system to access my device. Notice that I am not using the latest kernel for now; I am using Linux-5.4.15 at the moment. This is with pyftdi-0.50.2.

[eblot]

I do not think it depends on the kernel, but how udev is managed on Arch Linux. I really do lack time to investigate this specific distrib for now, I'll try to find some time (and nerves :-)) to install Arch Linux and check what's going on.

Thanks for the feedback.

[FFY00]

Do you have libftdi installed? It installs udev rules.

$ cat /usr/lib/udev/rules.d/69-libftdi.rules
# FTDI Devices: FT232BM/L/Q, FT245BM/L/Q, FT232RL/Q, FT245RL/Q, VNC1L with VDPS Firmware
SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", TAG+="uaccess"

# FTDI Devices: FT2232C/D/L, FT2232HL/Q
SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6010", TAG+="uaccess"

# FTDI Devices: FT4232HL/Q
SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6011", TAG+="uaccess"

# FTDI Devices: FT232H
SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6014", TAG+="uaccess"

# FTDI Devices: FT230X
SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6015", TAG+="uaccess"

[friedrichromstedt]

Do you have libftdi installed? It installs udev rules.

Yes indeed I have. My device has idVendor=0403 and idProduct=6015. This explains the behaviour.

I looked around for TAG+="uaccess"; the most relevant page I found is https://github.com/systemd/systemd/issues/4288. From what I see, /usr/lib/udev/rules.d/73-seat-late.rules seems to run some "builtin" called as well "uaccess" for items being tagged "uaccess". Is this the way the tag "uaccess" works?

[friedrichromstedt]

In the udev rules file /usr/lib/udev/rules.d/69-libftdi.rules embedded in @FFY00's post a method to make the device user-accessible using TAG+="uaccess" is used. This is a different approach than described in http://eblot.github.io/pyftdi/installation.html. Maybe the TAG method might be worth mentioning there?

[eblot]

There are likely dozens, if not hundreds of way to configure udev. I'll add a note to the doc to refer to udev documentation