Bug 1007652

(In reply to Matthias Brugger from comment #0)
> When plugging in the FTDI adpater, it get's registered as ttyUSB but shortly
> afterwards it gets deregistered and reregistered as input device:
> 

I forgot some dmesg lines

> 
> dmesg
> [ 4330.254760] usb 1-1.2: new full-speed USB device number 19 using ehci-pci
> [ 4330.371475] usb 1-1.2: New USB device found, idVendor=0403, idProduct=6001
> [ 4330.371480] usb 1-1.2: New USB device strings: Mfr=1, Product=2,
> SerialNumber=3
> [ 4330.371484] usb 1-1.2: Product: FT232R USB UART
> [ 4330.371486] usb 1-1.2: Manufacturer: FTDI
> [ 4330.371488] usb 1-1.2: SerialNumber: A50285BI
> [ 4330.374746] ftdi_sio 1-1.2:1.0: FTDI USB Serial Device converter detected
> [ 4330.374826] usb 1-1.2: Detected FT232RL
> [ 4330.375406] usb 1-1.2: FTDI USB Serial Device converter now attached to
> ttyUSB0
> [ 4331.045927] usb 1-1.2: usbfs: interface 0 claimed by ftdi_sio while
> 'brltty' sets config #1
> [ 4331.046819] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now
> disconnected from ttyUSB0
> [ 4331.046845] ftdi_sio 1-1.2:1.0: device disconnected

[ 4337.270583] usb 1-1.2: usbfs: USBDEVFS_CONTROL failed cmd brltty rqt 128 rq 6 len 255 ret -110
[ 4340.012348] input: BRLTTY 5.4 Linux Screen Driver Keyboard as /devices/virtual/input/input39
[ 4378.329466] usb 1-1.2: usbfs: USBDEVFS_CONTROL failed cmd brltty rqt 128 rq 6 len 255 ret -110

Also reported in the forum:
https://forums.opensuse.org/showthread.php/520714-Bug-handling-USB-RS232-Serial-cable

According to the logs syszemd thinks this is an input device for the blind and does something to it. What exactly are you plugging in? Please provide the output of "lsusb -v".

output from lsub -v for my device:

Bus 004 Device 006: ID 0403:6001 Future Technology Devices International, Ltd FT232 Serial (UART) IC
Couldn't open device, some information will be missing
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0 
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0         8
  idVendor           0x0403 Future Technology Devices International, Ltd
  idProduct          0x6001 FT232 Serial (UART) IC
  bcdDevice            6.00
  iManufacturer           1 
  iProduct                2 
  iSerial                 3 
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           32
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0x80
      (Bus Powered)
    MaxPower               90mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass    255 Vendor Specific Subclass
      bInterfaceProtocol    255 Vendor Specific Protocol
      iInterface              2 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0

You are seeing a conflict between the kernel and brltty, which comes in the package brltty-5.4-1.1.x86_64. Due to the following rule it claims an lot of devices:

# BEGIN_USB_DEVICES

# Device: 0403:6001
# Generic Identifier
# Vendor: Future Technology Devices International, Ltd
# Product: FT232 USB-Serial (UART) IC
# Albatross [all models]
# Cebra [all models]
# HIMS [Sync Braille]
# HandyTech [FTDI chip]
# MDV [all models]
ENV{PRODUCT}=="403/6001/*", ENV{BRLTTY_BRAILLE_DRIVER}="at,ce,hm,ht,md", GOTO="brltty_usb_run"

If you deinstall the package, it will work again, but that is no permanent solution for the issue.

Michael,

it looks like the udev rules introduced with the update of brltty to version 5.3.1 broke some USB to RS232 converters by being to unspecific. Do you have a braille device of this kind so we can get better distinction?

(In reply to Oliver Neukum from comment #6)
> Michael,
> 
> it looks like the udev rules introduced with the update of brltty to version
> 5.3.1 broke some USB to RS232 converters by being to unspecific. Do you have
> a braille device of this kind so we can get better distinction?

From what I can see, it uses the FTDI converter as it's generic driver. It's not clear to me why. There shouldn't be a braille device which uses this ID to identify itself.

(In reply to Oliver Neukum from comment #6)
> Michael,
> 
> it looks like the udev rules introduced with the update of brltty to version
> 5.3.1 broke some USB to RS232 converters by being to unspecific. Do you have
> a braille device of this kind so we can get better distinction?

My display is a Baum (0403:fe72).
There was a recent thread on the brltty list about this issue:
http://mielke.cc/pipermail/brltty/2016-October/014365.html

I don't see a good solution; apparently some of the Braille displays just have their manufacturer set to "FTDI".

Maybe we should just comment out that line in the udev rules and add a README.SUSE to document this. Let me know if you'd like me to do that.

(In reply to Michael Gorse from comment #8)
> (In reply to Oliver Neukum from comment #6)
> > Michael,
> > 
> > it looks like the udev rules introduced with the update of brltty to version
> > 5.3.1 broke some USB to RS232 converters by being to unspecific. Do you have
> > a braille device of this kind so we can get better distinction?
> 
> My display is a Baum (0403:fe72).
> There was a recent thread on the brltty list about this issue:
> http://mielke.cc/pipermail/brltty/2016-October/014365.html
> 
> I don't see a good solution; apparently some of the Braille displays just
> have their manufacturer set to "FTDI".
> 
> Maybe we should just comment out that line in the udev rules and add a
> README.SUSE to document this. Let me know if you'd like me to do that.

Packages argyllcms does have lines with excactly the same Vendor:Product ids commented, so I think this is a reasonable approach.

Thanks for looking/fixing this.

(In reply to Matthias Brugger from comment #9)
> (In reply to Michael Gorse from comment #8)
http://mielke.cc/pipermail/brltty/2016-October/014365.html
> > 
> > I don't see a good solution; apparently some of the Braille displays just
> > have their manufacturer set to "FTDI".
> > 
> > Maybe we should just comment out that line in the udev rules and add a
> > README.SUSE to document this. Let me know if you'd like me to do that.
> 
> Packages argyllcms does have lines with excactly the same Vendor:Product ids
> commented, so I think this is a reasonable approach.

I am afraid it is not so clear. We'd push out an update that would break the console for some users. Is brltty installed by default in any product?

It gets installed if the GNOME desktop is installed at least. It is needed there for orca to be able to interact with a Braille display.

Do we have a way to generate a message to be displayed if brltty is being updated? If so, then that might help to warn users who might have one of the affected Braille displays.

(In reply to Michael Gorse from comment #14)
> It gets installed if the GNOME desktop is installed at least. It is needed
> there for orca to be able to interact with a Braille display.
> 
> Do we have a way to generate a message to be displayed if brltty is being
> updated? If so, then that might help to warn users who might have one of the
> affected Braille displays.

That is no good. If the package is installed by default we'd mess up the next update for the vast majority of users who don't even know what brltty is. We'd have to know whether the device is actually connected.
If we could do that, the point would become moot and we could probe in the udev rule.

The new udev rule caused the regression, so I'm for commenting it out. What we can do is to replace the rule with one that logs a message when the device (FTDI or Braille display) is connected. That way we hind the person setting up a system with such Braille display at the right solution (at the cost of spamming others each time the plug in their serial adapter, but hey).

*** Bug 1029758 has been marked as a duplicate of this bug. ***

For people seeing this bug, is it fixed with the latest brltty I made a change a while ago that was intended to fix / work around this, but I don't have hardware to test with.

I tried today with brltty-5.5-1.1 and can confirm that the issue is fixed.

Thanks a lot!

I observe this again with brltty-5.6-99.12

> udevadm monitor
monitor will print the received events for:
UDEV - the event which udev sends out after rule processing
KERNEL - the kernel uevent

KERNEL[4621.088941] add      /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2 (usb)
KERNEL[4621.097121] add      /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.0 (usb)
KERNEL[4621.097774] add      /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.0/ttyUSB0 (usb-serial)
KERNEL[4621.099971] add      /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.0/ttyUSB0/tty/ttyUSB0 (tty)
KERNEL[4621.100050] bind     /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.0/ttyUSB0 (usb-serial)
KERNEL[4621.100126] bind     /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.0 (usb)
KERNEL[4621.100187] bind     /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2 (usb)
UDEV  [4621.654409] add      /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2 (usb)
UDEV  [4621.659146] add      /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.0 (usb)
UDEV  [4621.662476] add      /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.0/ttyUSB0 (usb-serial)
UDEV  [4621.670044] add      /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.0/ttyUSB0/tty/ttyUSB0 (tty)
UDEV  [4621.671403] bind     /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.0/ttyUSB0 (usb-serial)
UDEV  [4621.672138] bind     /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.0 (usb)
UDEV  [4621.673399] bind     /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2 (usb)
KERNEL[4622.826940] remove   /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.0/ttyUSB0/tty/ttyUSB0 (tty)
KERNEL[4622.827016] unbind   /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.0/ttyUSB0 (usb-serial)
KERNEL[4622.827053] remove   /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.0/ttyUSB0 (usb-serial)
KERNEL[4622.827107] unbind   /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.0 (usb)
KERNEL[4622.827175] bind     /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.0 (usb)
UDEV  [4622.830975] remove   /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.0/ttyUSB0/tty/ttyUSB0 (tty)
UDEV  [4622.833293] unbind   /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.0/ttyUSB0 (usb-serial)
UDEV  [4622.835044] remove   /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.0/ttyUSB0 (usb-serial)
UDEV  [4622.836645] unbind   /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.0 (usb)
UDEV  [4622.839450] bind     /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.0 (usb)
KERNEL[4625.870706] unbind   /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.0 (usb)
UDEV  [4625.874526] unbind   /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.0 (usb)
KERNEL[4626.006916] bind     /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.0 (usb)
UDEV  [4626.011022] bind     /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.0 (usb)
KERNEL[4627.876296] unbind   /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.0 (usb)
UDEV  [4627.880304] unbind   /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.0 (usb)
KERNEL[4628.010895] bind     /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.0 (usb)
UDEV  [4628.014727] bind     /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.0 (usb)

And so on until I unplug the device.

Hi all.

Trying to connect a "NodeMCO ESP32" IoT board via usb to my OpenSuse box (Leap 15, but same scenario as discussed here), per default installed brltty "catches" my cp210x serial port:

[ 2286.880760] usb 1-2.4: new full-speed USB device number 10 using xhci_hcd
[ 2287.024255] usb 1-2.4: New USB device found, idVendor=10c4, idProduct=ea60
[ 2287.024260] usb 1-2.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 2287.024263] usb 1-2.4: Product: CP2102 USB to UART Bridge Controller
[ 2287.024265] usb 1-2.4: Manufacturer: Silicon Labs
[ 2287.024268] usb 1-2.4: SerialNumber: 0001
[ 2287.033732] cp210x 1-2.4:1.0: cp210x converter detected
[ 2287.035981] usb 1-2.4: cp210x converter now attached to ttyUSB0
[ 2287.199670] usb 1-2.4: usbfs: interface 0 claimed by cp210x while 'brltty' sets config #1
[ 2287.200517] cp210x ttyUSB0: cp210x converter now disconnected from ttyUSB0
[ 2287.200562] cp210x 1-2.4:1.0: device disconnected
[ 2289.167848] input: BRLTTY 5.5 Linux Screen Driver Keyboard as /devices/virtual/input/input12


As I'm not blind, I of course could just uninstall brltty. But as I've found and read this bug, I see that you're searching for a more reasonable solution.

What's currently the most reasonable way to tell brltty NOT to use my cp210x device?


Regards,
Michael

okay, looking at the specfile we already disabled
0403:6001 "10C4:EA60 CP210x UART Bridge"

additionally I'm now commenting out
10c4:ea60 "10C4:EA60 CP210x UART Bridge"
10c4:ea80 "10C4:EA80 CP2110 HID UART Bridge"

so we should now have the most common re-used IDs commented out.
which means we are disabling 3 USB Ids out of 103 in the udev rules.

see also
bug#1093378
bug#1093455
bug#1007652

closing

This is an autogenerated message for OBS integration:
This bug (1007652) was mentioned in
https://build.opensuse.org/request/show/736726 Factory / brltty

SUSE-RU-2019:3013-1: An update that has three recommended fixes can now be installed.

Category: recommended (moderate)
Bug References: 1007652,1093378,1093455
CVE References: 
Sources used:
SUSE Linux Enterprise Module for Open Buildservice Development Tools 15-SP1 (src):    brltty-5.5-5.3.1
SUSE Linux Enterprise Module for Open Buildservice Development Tools 15 (src):    brltty-5.5-5.3.1
SUSE Linux Enterprise Module for Desktop Applications 15-SP1 (src):    brltty-5.5-5.3.1
SUSE Linux Enterprise Module for Desktop Applications 15 (src):    brltty-5.5-5.3.1
SUSE Linux Enterprise Module for Basesystem 15-SP1 (src):    brltty-5.5-5.3.1
SUSE Linux Enterprise Module for Basesystem 15 (src):    brltty-5.5-5.3.1

NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.

openSUSE-RU-2019:2563-1: An update that has three recommended fixes can now be installed.

Category: recommended (moderate)
Bug References: 1007652,1093378,1093455
CVE References: 
Sources used:
openSUSE Leap 15.1 (src):    brltty-5.5-lp151.5.3.1

openSUSE-RU-2019:2561-1: An update that has three recommended fixes can now be installed.

Category: recommended (moderate)
Bug References: 1007652,1093378,1093455
CVE References: 
Sources used:
openSUSE Leap 15.0 (src):    brltty-5.5-lp150.4.3.1