Bug 1092839

For now "zypper addlock brltty" made the next "zypper dup" keep it working.

This is essentially bsc#1007652 for another device ID.
Adding Michael Gorse.

brltty is recommended by orca which is recommended by gdm

Maintainer of brttty is Ruediger Oertel. Reassigning.

The problem is indeed the USB id. USB id 10c4:ea60 is registered in brltty-5.5/Autostart/Udev/rules. 10C4:EA80 has the same problem:

# Device: 10C4:EA60
# Generic Identifier
# Vendor: Cygnal Integrated Products, Inc.
# Product: CP210x UART Bridge / myAVR mySmartUSB light
# BrailleMemo [Pocket]
# Seika [Braille Display]
ENV{PRODUCT}=="10c4/ea60/*", ENV{BRLTTY_BRAILLE_DRIVER}="mm,sk", GOTO="brltty_usb_run"

# Device: 10C4:EA80
# Generic Identifier
# Vendor: Cygnal Integrated Products, Inc.
# Product: CP210x UART Bridge
# Seika [Note Taker]
ENV{PRODUCT}=="10c4/ea80/*", ENV{BRLTTY_BRAILLE_DRIVER}="sk", GOTO="brltty_usb_run"


According to kroesche from Silicon Labs, the correct assignment for these two USB ids are: 

10C4:EA60 CP210x UART Bridge
https://usb-ids.gowdy.us/read/UD/10c4/ea60

10C4:EA80 CP2110 HID UART Bridge
https://usb-ids.gowdy.us/read/UD/10c4/ea80

So this is cleanly a fault of Braille device manufacturer. Vendor ignored rules and released their devices with the unchanged default UART Bridge USB id. They even did not request custom product id from Silicon Labs.
https://www.silabs.com/products/interface/request-product-id

brltty udev rule either has to add a helper to identify the Braille device (without breaking of other serial devices), or we have to live with a Braille device that does not work out of the box and needs configuration.

As CP210x are very common, it is even possible that brltty udev configuration would require to configure exact USB connector. Otherwise the user of Braille device would not be able to use a wide set of devices (GPSes, AVR programmers, serial converters etc.).

Testing package disabling these two:
https://build.opensuse.org/project/show/home:sbrabec:branches:openSUSE:Leap:15.0

(In reply to Stanislav Brabec from comment #5)
> Testing package disabling these two:
> https://build.opensuse.org/project/show/home:sbrabec:branches:openSUSE:Leap:
> 15.0

That will likely fix this bug. But will you do this again and again for every new abused device ID?

Comment 6 (Oliver Neukum):

I read the whole rules file and found one another broken device, which abuses FTDI USB ud:

# 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"

I will comment this out as well.

Some vendors of generic USB chips even offer USB ids for free for devices based on their hardware, so it is a fault of the Braille device manufacturer.

This is not the first application and not the first USB id where it happened.

If the manufacturer sets at least textual USB name, it is still possible to add auto-detection. But I don't have any of these devices to check and add such rule.

Reference to FT232:
https://usb-ids.gowdy.us/read/UD/0403/6001

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

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

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

Moving the discussion to the upstream, as it has a heavy impact to blind people.
https://brltty.app/pipermail/brltty/2018-May/015936.html


Revoking the request. I just found that the proposed patch is not sufficient.

it also hooks to the kernel. My GPS Qstarz BT-1000P is also broken, so I can test it. Even with the patch, it still fails:

[48419.996278] usb 1-1.3: new full-speed USB device number 5 using ehci-pci
[48420.106379] usb 1-1.3: New USB device found, idVendor=10c4, idProduct=ea60
[48420.106386] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[48420.106390] usb 1-1.3: Product: CP2102 USB to UART Bridge Controller
[48420.106394] usb 1-1.3: Manufacturer: Silicon Labs
[48420.106397] usb 1-1.3: SerialNumber: 0001
[48420.133630] usbcore: registered new interface driver usbserial_generic
[48420.133644] usbserial: USB Serial support registered for generic
[48420.135750] usbcore: registered new interface driver cp210x
[48420.135763] usbserial: USB Serial support registered for cp210x
[48420.135788] cp210x 1-1.3:1.0: cp210x converter detected
[48420.137735] usb 1-1.3: cp210x converter now attached to ttyUSB0
[48420.188395] usb 1-1.3: usbfs: interface 0 claimed by cp210x while 'brltty' sets config #1
[48420.189018] cp210x ttyUSB0: cp210x converter now disconnected from ttyUSB0
[48420.189041] cp210x 1-1.3:1.0: device disconnected
[48424.103414] input: BRLTTY 5.6 Linux Screen Driver Keyboard as /devices/virtual/input/input10

lookup.yml for Leap 15.0 shows brltty as coming from SUSE:SLE-15:GA
So I think that whatever we submit to fix this should be sent there.

I really appreciate your work on this.

please remember to also change the %service_add/del macros in
the specfile, see also bug#1074096. In short: it should be
brltty.target for all these macro calls.

This is really a duplicate of https://bugzilla.suse.com/show_bug.cgi?id=1093378 i'm not sure if just fixing it for ftdi chips is enough there maybe other devices that also have the issue, I have one or two here that have had issues with tumbleed in the past but I don't remember if they were ftdi based, i'll try and dig them out tomorrow and test.

(In reply to Simon Lees from comment #15)
> This is really a duplicate of
> https://bugzilla.suse.com/show_bug.cgi?id=1093378

That's not a fair statement, 2839 clearly comes before 3378.

(In reply to Simon Lees from comment #15)
> This is really a duplicate of
> https://bugzilla.suse.com/show_bug.cgi?id=1093378 i'm not sure if just
> fixing it for ftdi chips is enough there maybe other devices that also have
> the issue, I have one or two here that have had issues with tumbleed in the
> past but I don't remember if they were ftdi based, i'll try and dig them out
> tomorrow and test.

/usr/lib/udev/rules.d/77-mm-usb-serial-adapters-greylist.rules may serve as a starting point. For FTDI, VID 0403 is somewhat broad as apparently only PID 6000-6014 are used by FTDI themselves, everything else are specific devices.

Instead of deleting the problematic devices from the udev rules file, it may be better to move the IDs to a rule file in a separate subpackage Suggested by the brltty main package. This would allow to reactivate the rules for users by just installing an additional package.

Stefan Brüns: All conflicting devices use FTDI chip as well. And vendor of these devices were too lazy to change USB identification. So the FTDI serial bridge is indistinguishable from a Braille terminal or Braille display on the USB level. Only serial communication can determine the device.

(In reply to Stanislav Brabec from comment #18)
> Stefan Brüns: All conflicting devices use FTDI chip as well. And vendor of
> these devices were too lazy to change USB identification. So the FTDI serial
> bridge is indistinguishable from a Braille terminal or Braille display on
> the USB level. Only serial communication can determine the device.

The conflicting devices use chips from FTDI or Silabs (Cygnal), and some of these use the generic product IDs. I am completely aware of the USB standards (having implemented several USB host and device drivers), and how udev works.

Actually, I don't know what you are trying to tell me, or to which part of my comment you are referring to.

Stefan Brüns, comment 19: Sorry, I misunderstood. Move to a an optional sub-package will work.

Maybe a combination of ZYPP USB hardware supplements would end with a ZYPP dialog similar to bug 1093378 comment 23 point 2, just on installation level.

Supplements:  modalias(usb:v10c4pea60d*dc*dsc*dp*ic*isc*ip*) 
Provides:     udev_usb_rule_10c4_ea60
Conflicts:    otherproviders(udev_usb_rule_10c4_ea60)

It will complain that you are trying to install conflicting packages:
brltty-udev-rules-serialbridge
gpsd-udev-rules-serialbridge
udev-udev-rules-generic-serialbridge
and ask you to pick one.

A problem will occur when a person will have more devices with the same id. None of these packages will fulfill the requirement.

But as you pointed to, use of ATTRS{busnum} and ATTRS{devpath} would make possible to write rules that will be capable of doing that.

I can confirm this bug, I run today into it with my CP210x device :/.

Any news here?

commented out in brltty:

10C4:EA60 CP210x UART Bridge
https://usb-ids.gowdy.us/read/UD/10c4/ea60

10C4:EA80 CP2110 HID UART Bridge
https://usb-ids.gowdy.us/read/UD/10c4/ea80

closing