brltty claiming cp210x devices on 22.04

[bdav]

* Impact

The brltty udev rules are claiming generic devices IDs which makes some other devices like Arduino cards not able to interact with the serial port anymore

* Test Case

Try to use an Arduino over a cp210x or FTDI serial port, it should be able to talk to the computer

- upgrades from focal/impish to the SRU version should have no question and no /etc/udev/rules.d/86-brltty-usbgeneric.rules generated

- upgrades from brltty 6.4-4ubuntu2
1. if a device matching the IDs 0403:6001 / 10C4:EA60 / 10C4:EA80 is connectect at the time of the upgrade it should prompt with the debconf question
1.a if the answer is yes, /etc/udev/rules.d/86-brltty-usbgeneric.rules should be generated
1.b if the answer is no, /etc/udev/rules.d/86-brltty-usbgeneric.rules not installed

2. if no matching device is connected
there should be no debconf question nor /etc/udev/rules.d/86-brltty-usbgeneric.rules generated

- installing brltty when it was not installed
no question and no config generated

* Regression potential

If the debconf logic is wrong users could be prompted with the question when not needed or not prompted when they should. If the udev rules was incorrect or wrongly installed it could lead to have brltty not starting when it should

-------------------

Distributor ID: Ubuntu
Description: Ubuntu Jammy Jellyfish (development branch)
Release: 22.04
Codename: jammy
brltty: Installed: 6.4-2ubuntu1

 brltty appears once again to be claiming cp210x devices with the vendor/product ID of:

idVendor=10c4, idProduct=ea60

Example dmesg output:
  999.215968] usb 3-6.3: New USB device found, idVendor=10c4, idProduct=ea60, bcdDevice= 1.00
[ 999.215973] usb 3-6.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 999.215975] usb 3-6.3: Product: CP2103 USB to UART Bridge
[ 999.215977] usb 3-6.3: Manufacturer: Silicon Labs
[ 999.215978] usb 3-6.3: SerialNumber: 0005
[ 999.234070] usbcore: registered new interface driver usbserial_generic
[ 999.234081] usbserial: USB Serial support registered for generic
[ 999.235262] usbcore: registered new interface driver cp210x
[ 999.235272] usbserial: USB Serial support registered for cp210x
[ 999.235298] cp210x 3-6.3:1.0: cp210x converter detected
[ 999.237039] usb 3-6.3: cp210x converter now attached to ttyUSB0
[ 999.300049] input: PC Speaker as /devices/platform/pcspkr/input/input41
[ 999.807223] input: BRLTTY 6.4 Linux Screen Driver Keyboard as /devices/virtual/input/input42
[ 999.991926] usb 3-6.3: usbfs: interface 0 claimed by cp210x while 'brltty' sets config #1
[ 999.995045] cp210x ttyUSB0: cp210x converter now disconnected from ttyUSB0
[ 999.995066] cp210x 3-6.3:1.0: device disconnected

[Samuel thibault (samuel-thibault)]

Yes, but it is meant to be so: the Seika Braille device is announced as such, so we have to recognize such devices in brltty, otherwise the Seika Braille devices would not work at all.

The question is rather: why is brltty installed on your system? It is supposed to be installed only if you installed your system with a Braille device connected.

[Sebastien Bacher (seb128)]

@Samuel, the Ubuntu installer isn't having such smart logic, is Debian actual doing that and adapting the package set according to the hardware?

[Samuel thibault (samuel-thibault)]

Debian is installing the brltty package only when brltty was used during installation.

Brltty gets started during installation either through the udev rules, or started manually from the kernel command line. The finish-install script just checks out /var/run/brltty.pid to determine whether a brltty is running.

[bdav (bdavjones)]

In this case, brltty appeared (or at least the device claim) after a dist-upgrade. I would have had no cause to use it through the initial installation.

It still feels very bad form for a vendor device to use the default VID/PID of the underlying converter chip as opposed to the (very easy) step of changing it in the case of the cp210x.

[Samuel thibault (samuel-thibault)]

> In this case, brltty appeared (or at least the device claim) after a dist-upgrade

Ah, do you happen to have a log of that dist-upgrade, so we can determine what brought it in?

> It still feels very bad form for a vendor device to use the default VID/PID of the underlying converter chip

Yes. Unfortunately that's what they have done, those devices are out there, and people have already bought them (and they cost a lot of money) :(

[Sebastien Bacher (seb128)]

bug #1970408 is similar with arduino devices

[Batwam (batwam)]

As mentioned by Sebastien above, I have a smiliar issue which is blocking the use of the USB as serial port for use with Arduino. If this helps, my dist-upgrade log is available in another bug report if you want to have a look: https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/1969353

Based on the content, it looks to me like brltty was already there prior to upgrade and I also woudn't have used brltty during installation which was only done 2-3 weeks before upgrade.

I also just did a fresh install in a virtual machine and brltty is also there. It looks to me like this package is a dependancy of ubuntu-desktop or similar through orca:
$ apt-cache rdepends brltty
brltty
Reverse Depends:
  brltty-espeak
  xubuntu-desktop
  vanilla-gnome-desktop
  ubuntukylin-desktop
  ubuntu-unity-desktop
  ubuntu-budgie-desktop
  speechd-el
  brltty-x11
  brltty-speechd
  brltty-flite
  orca
  ubuntu-desktop-minimal
  ubuntu-desktop

for info, I did also check on a fresh Debian Testing install and the package isn't installed by default there.

[Samuel thibault (samuel-thibault)]

orca only suggests brltty, it's the *-desktop packages which seem to be recommending brltty.

If Ubuntu really wants to install brltty by default, it should disable the udev entries for the generic USB IDs

[Sebastien Bacher (seb128)]

Thanks Samuel for sharing your expertise here!

I would need to check why it has been historically installed by default but I would expect that's because we want the default installation as friendly as possible to users that need accessibility. Doing what Debian is doing is nice but gives an inconsistent result since it would depend of how the system was installed.

We need to discuss what's best going forward but the easiest option meanwhile for the LTS is probably to disable the udev rule as you suggested.

[bdav (bdavjones)]

I might suggest that, for ease of use by end users, if disabling such devices in the default install, it may be worth packaging a brltty-conflictingdevices or similar to un-disable them, as opposed to requiring manual un-disabling of the udev rules.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Batwam (batwam)]

I believe that the best course of action would be for the offending package (brtty) to get fixed. Until it is, perhaps mark is as a conflict and delete it when people install Arduino.

[bdav (bdavjones)]

Unfortunately its not just Arduino - its pretty much anything that uses a cp210x serial device, of which there are many many different things.

[Chris D (crispyoz)]

I have the same issue connecting to Onion Omega2 IoT devices, since they use cp210x

[David Spoelstra (davids-mediamachine)]

It also affects FTDI USB to Serial adapters!

$ lsusb
Bus 002 Device 013: ID 0403:6001 Future Technology Devices International, Ltd FT232 Serial (UART) IC

$ grep -i ftdi /lib/udev/rules.d/*
85-brltty.rules:# HandyTech [FTDI chip]
85-brltty.rules:ENV{PRODUCT}=="403/6001/*", ATTRS{manufacturer}=="FTDI", ENV{BRLTTY_BRAILLE_DRIVER}="hd,hm,ht", GOTO="brltty_usb_run"

[Sebastien Bacher (seb128)]

@Samuel so I was checking debian/brltty.udev.rules following your suggestion, but it's a bit unclear to me which entries there should be considered 'generic USB IDs'?

I also don't understand why those rules are debian specific. How does upstream handle the devices?

We should stop installing brltty by default going forward but we aren't going to respin ISOs on old serie for such changes and that wouldn't be a solution for already installed systems...

[Samuel thibault (samuel-thibault)]

> it's a bit unclear to me which entries there should be considered 'generic USB IDs'?

They are marked "Generic Identifier", that's

0403:6001
10C4:EA60
10C4:EA80

> I also don't understand why those rules are debian specific

See the diff between ./debian/brltty-udeb.udev.rules and ./Autostart/Udev/device.rules.in

Note that in debian we use the udev rules *only* inside the installer. The current strategy in Debian is that in the installer we use udev rules to autodetect braille devices. But in the installed system we don't: when the user installs brltty, the user means that they have a Braille device and want to probe it, whether it uses a generic USB ID or not, i.e. we always start brltty

> How does upstream handle the devices?

When brltty is started it just always probes all devices. Its udev rules file always starts brltty, be it generic IDs or not.

> We should stop installing brltty by default going forward

That would align with the way it happens in Debian yes.

Ideally the udev rules would be split so that the non-generic pieces get always installed to start brltty, and the generic pieces are installed only when necessary. That's a matter of actually spending time on implementing it.

> we aren't going to respin ISOs on old serie for such changes and that wouldn't be a solution for already installed systems...

Yes, rather disable the generic udev rules.

[Sebastien Bacher (seb128)]

Thanks Samuel, I've uploaded the changes now.

I also checked a bit the package history since I'm not really familiar with the package (we used to have Luke working on accessibility but since he left we mostly carried the status over and don't have anyone really familiar those changes) and it seems I was wrong in what I wrote on the installer

The intend seems to be that brltty is always installed but the installer writes a /etc/default/brltty configuration and the systemd units should be active depending on the configuration (which is a delta we carry for brltty)

https://launchpad.net/ubuntu/+source/brltty/3.7.2-7ubuntu1
https://launchpad.net/ubuntu/+source/brltty/5.3.1-2ubuntu2.1

[Sebastien Bacher (seb128)]

We should review how the package works but meanwhile the udev rules change is going to resolve the conflict

[Brian Murray (brian-murray)]

Given that some braille devices are going to stop working with this update I think this should be release noted and information provided on how to reenable the devices if necessary.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Steve Langasek (vorlon)]

I understand the importance of fixing this conflict, and I agree it's bad behavior on the part of the hardware manufacturer that retail devices were shipped using these generic USB IDs, but the consequence of the proposed SRU - disabling the use of brltty on the USB ids in question - is that a blind user who uses one of these devices, who has successfully installed Ubuntu and has a working system, will on the installation of this SRU have their only accessible tty device rendered inoperable.

That represents a CRITICAL regression for the users in question. It effectively bricks their machine and requires the user to rely on a sighted person (who is also Ubuntu-knowledgeable) to get it working again.

So I am rejecting this SRU. It's unfortunate that this wasn't caught before release, but now that support for this hardware is present in the release, we can't be bricking blind users' systems to enable other cp210x devices. We'll need to find some other path forward.

[Steve Langasek (vorlon)]

An upload of brltty to jammy-proposed has been rejected from the upload queue for the following reason: "Would introduce a critical regression for blind users of this hardware".

[Batwam (batwam)]

Hi Steve, would you be able to describe how the patch worked Vs current behaviour?

If we can’t touch the brltty package, could we remove it from standard install (like in Debian) to minimise the number of people impacted and/or make it incompatible with every other package which might be incompatible with it (such as Arduino) so people get prompted to remove brltty if it is installed - include special warning if you feel it’s needed)?

[Paul Menzel (paulmenzel)]

1. This is Debian bug report #667616.
2. *brltty* was installed when doing `do-release-upgrade` from 21.10 to 22.04 [2].

[1]: https://bugs.debian.org/667616
[2]: https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/1976293

[Oliver Grawert (ogra)]

we funnily have removed these udev rules before (but i guess the patch was dropped when syncing a new version)

https://bugs.launchpad.net/ubuntu/+source/brltty/+bug/874181

[Launchpad Janitor (janitor)]

This bug was fixed in the package brltty - 6.4-6ubuntu1

---------------
brltty (6.4-6ubuntu1) kinetic; urgency=medium

  * Resynchronize on Debian
    - Remaining changes:
      + add brltty-setup
        - debian/brltty-setup
        - debian/brltty.install
        - debian/rules
      + add initramfs integration to run brltty-setup if necessary before
        plymouth starts
        - debian/control
        - debian/initramfs/brltty.sh
        - debian/initramfs/hooks/brltty.in
        - debian/initramfs/scripts/init-premount/brltty
        - debian/initramfs/scripts/init-top/brltty
        - debian/brltty.dirs
        - debian/brltty.install
        - debian/brltty.postinst
      + add ubiquity integration to propagate any brltty configuration to the
        target system
        - debian/31brltty
        - debian/brltty.dirs
        - debian/brltty.install
      + add udev rules file that uses brltty-udev.service to activate via
        systemd
        - debian/brltty-udev.service
        - debian/brltty.dirs
        - debian/brltty.udev.rules
        - debian/rules
      + disable brltty.service by default, but enable it if the user configures
        Braille at install time for a non-USB display
        - debian/31brltty
        - debian/rules
      + don't install /etc/brltty.conf in the package
        - debian/31brltty
      + debian/brltty.udev.rules: don't claim generic USB device IDs it leads
        to brltty grabbing serial ports which other devices like Arduinos
        boards can't use anymore, thanks Samuel Thibault (lp: #1958224)

brltty (6.4-6) unstable; urgency=medium

  * patches/paste-newlines: Fix pasting newlines in X with the brltty
    shortcut.
  * patches/paste-firefox-lo: Fix pasting into FireFox and LibreOffice.
  * debian/brltty-udeb.prebaseconfig: Use ':' in chown.

brltty (6.4-5) unstable; urgency=medium

  * patches/py310-sysconfig: Fix build with python 3.10 (Closes: Bug#1007927)

 -- Sebastien Bacher <email address hidden> Thu, 12 May 2022 16:01:05 +0200

[Sebastien Bacher (seb128)]

Olivier is right, seems like we had the issue in the past and even SRUed a change back then
https://launchpad.net/ubuntu/+source/brltty/4.2-8ubuntu5.1

The change got unfortunately overwritten in the recent merge https://launchpad.net/ubuntu/+source/brltty/6.4-2ubuntu1 while bringing a new version from Debian with some refactoring that made the change less obvious to notice probably

[Sebastien Bacher (seb128)]

I've uploaded a new SRU, updating the description according.

The new revision handle the situation by asking a debconf question to users updating from a version which included the conflicting rules which ask them if they want to keep that config or not. The question is only asked if a device matching one of those IDs is found on the system, the answer default to 'yes' to avoid accidentally disabling a working screen reader for people who rely on those.

After the SRU will be in updates people upgrading from earlier serie to 22.04 will not see the question nor having the conflicting rules. New installations from 22.04.1 when it's out will also not have the issue

[Robie Basak (racb)]

This isn't a full review, but I glanced through and I noticed a minor typo:

+debian/brllty-usb-generic.rules
...
+ cp /usr/share/doc/brltty/examples/brllty-usb-generic.rules /etc/udev/rules.d/86-brltty-usbgeneric.rules

It's brllty vs. brltty. Since it's in two places the code will presumably work, but it might be worth fixing now to avoid confusion later.

[Robie Basak (racb)]

> +Description: Should brltty handle generic usb serial devices?
> + It might be needed for some braille screen reader to be detected but
> + is likely to create conflict with USB to serial adapters

I think this text could be improved. I'm not sure that a ordinary user would know what to do in response to this.

How about something like this:

Description: Are you using a Braille screen reader?
 If you are not using a Braille screen reader, then we will configure your system for better hardware support for other devices, such as USB serial adapters and Arduino and similar boards. This is recommended unless you are using a Braille screen reader that is affected by this update.
 .
 However, if you are using a Braille screen reader, you should answer Yes to this question. Otherwise it may stop working. For more details, please see: https://launchpad.net/bugs/1958224

Please correct the details in the text above, but I hope you see what I mean: this way, we'd be signposting people to our default behaviour without any doubt about what we advise, _unless_ they are using a screen reader.

[Sebastien Bacher (seb128)]

Thanks Robie, I reuploaded with the typo fixes and the wording you suggested since the text seems fine to me

[Chris Halse Rogers (raof)]

Hello bdav, or anyone else affected,

Accepted brltty into jammy-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/brltty/6.4-4ubuntu3 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-jammy to verification-done-jammy. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-jammy. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Sebastien Bacher (seb128)]

Testing 6.4-4ubuntu3

- upgrading from focal gives a rules without the generic ID as expected.
 -upgrading from jammy without a matching device connected, the rules doesn't include the generic IDs as expected and the extra rules isn't installed
- upgrading from jammy with a matching device connected, the user is correctly debconf prompted and the rules is installed depending of the answer to the question

settings as verified

[Launchpad Janitor (janitor)]

This bug was fixed in the package brltty - 6.4-4ubuntu3

---------------
brltty (6.4-4ubuntu3) jammy; urgency=medium

  * Try to resolve brltty conflicting with generic serials (lp: #1958224)
  * debian/brltty.udev.rules, debian/brltty-usb-generic.rules,
    debian/brltty.examples:
    - split the generic identifier udev rules to a separate rule which
      is going to be distributed as an example but not installed by default.
      Those rules are needed by some braille readers to work but conflict
      with cp210x and FTDI serial ports. Those special devices had required
      manual setup in Ubuntu since 2011 and were only added back to the
      default configuration due to a merge error.
  * debian/brltty.templates, debian/brltty.postinst, debian/rules:
    - when upgrading from a version that provided the generic rules prompt
      the user with debconf to ask if those should still be installed.
      The default answer is yes to avoid accidentally regressing users
      with a such braille reader configured during the upgrade.
      If you don't use a brailler reader you should answer 'no' to avoid
      having the service blocking access to other devices.
      The script is /etc/udev/rules.d/86-brltty-usbgeneric.rules

 -- Sebastien Bacher <email address hidden> Tue, 28 Jun 2022 17:25:25 +0200

[Łukasz Zemczak (sil2100)]

The verification of the Stable Release Update for brltty has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

[Bill Turner, wb4alm (wb4alm)]

Installation of UBUNTU 22.04.1 on August 15, 2022 STILL HAS THIS BUG.

The installation was an upgrade from UBUNTU 20.04 which failed due to other issues with PYTHON.

Subsequent clean installs of UBUNTU 22.04.1 constantly caused re-occurances of this bug.

It was necessary to UNINSTALL brltty to restore access to my USB->Serial converts.

Installation of LINUX MINT 21 in December 2022 did --NOT-- have this problem.

[Steve Langasek (vorlon)]

A stable release update of brltty was done to correct this issue. If you are still experiencing problems when version 6.4-4ubuntu3 of brltty is installed, we will need more information about your hardware, starting with the output of lsusb.

[Timothée Manaud (timothee)]

I still have this bug with Linux Mint 21.1 Cinnamon 5.15.0-69-generic.

Arduino Mega 2560 RobotDyn R3 over micro USB, syslog:

usb 3-6.4.6.1: ch341-uart converter now attached to ttyUSB0
usb 3-6.4.6.1: new full-speed USB device number 49 using xhci_hcd
usb 3-6.4.6.1: New USB device found, idVendor=1a86, idProduct=7523, bcdDevice= 2.62
usb 3-6.4.6.1: New USB device strings: Mfr=0, Product=2, SerialNumber=0

Meantime I had to remove sudo apt get remove brltty

[Walter (wdoekes)]

Not sure what is fixed with 6.4-4ubuntu3.

I removed/purged brltty, rebooted (just to make sure) and checked the /dev/ttyUSB0 availability:

[ 89.311770] usb 3-3: new full-speed USB device number 4 using xhci_hcd
[ 89.529433] usb 3-3: New USB device found, idVendor=1a86, idProduct=7523, bcdDevice= 2.64
[ 89.529439] usb 3-3: New USB device strings: Mfr=0, Product=2, SerialNumber=0
[ 89.529440] usb 3-3: Product: USB Serial
[ 90.069647] usbcore: registered new interface driver usbserial_generic
[ 90.069654] usbserial: USB Serial support registered for generic
[ 90.074280] usbcore: registered new interface driver ch341
[ 90.074290] usbserial: USB Serial support registered for ch341-uart
[ 90.074300] ch341 3-3:1.0: ch341-uart converter detected
[ 90.074810] usb 3-3: ch341-uart converter now attached to ttyUSB0
[ 93.183733] usb 3-3: USB disconnect, device number 4
[ 93.184054] ch341-uart ttyUSB0: ch341-uart converter now disconnected from ttyUSB0
[ 93.184072] ch341 3-3:1.0: device disconnected

That works. After installing brltty and retrying, we see that /dev/ttyUSB0 is immediately stolen.

[ 130.375473] usb 3-3: new full-speed USB device number 5 using xhci_hcd
[ 130.593243] usb 3-3: New USB device found, idVendor=1a86, idProduct=7523, bcdDevice= 2.64
[ 130.593249] usb 3-3: New USB device strings: Mfr=0, Product=2, SerialNumber=0
[ 130.593250] usb 3-3: Product: USB Serial
[ 130.595110] ch341 3-3:1.0: ch341-uart converter detected
[ 130.595546] usb 3-3: ch341-uart converter now attached to ttyUSB0
[ 131.168883] input: PC Speaker as /devices/platform/pcspkr/input/input17
[ 131.677420] input: BRLTTY 6.4 Linux Screen Driver Keyboard as /devices/virtual/input/input18
[ 131.797698] usb 3-3: usbfs: interface 0 claimed by ch341 while 'brltty' sets config #1
[ 131.798107] ch341-uart ttyUSB0: ch341-uart converter now disconnected from ttyUSB0
[ 131.798115] ch341 3-3:1.0: device disconnected

Here's the lsusb output:

# lsusb
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 002: ID 27c6:609c Shenzhen Goodix Technology Co.,Ltd. Goodix USB2.0 MISC
Bus 003 Device 005: ID 1a86:7523 QinHeng Electronics CH340 serial converter
Bus 003 Device 003: ID 8087:0032 Intel Corp. AX210 Bluetooth
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Apparently, I'm not using a CP210x but a CH340. It suffers from the same problem though.

Having said that, I agree with Steve [~vorlon]:

> That represents a CRITICAL regression for the users in question.
> It effectively bricks their machine and requires the user to rely
> on a sighted person (who is also Ubuntu-knowledgeable) to get it
> working again.

We can just purge brltty and be done with it. So it's clearly the lesser of two evils right now.

Walter

[Walter (wdoekes)]

Ah, I was looking in /etc/udev. But it was in /lib/udev:

This is the offending rule that selects my generic device:

----

# Device: 1A86:7523
# Baum [NLS eReader Zoomax (20 cells)]
ENV{PRODUCT}=="1a86/7523/*", ENV{BRLTTY_BRAILLE_DRIVER}="bm", GOTO="brltty_usb_run"

----

When looking at http://www.linux-usb.org/usb.ids I see:

1a86 QinHeng Electronics
 5512 CH341 in EPP/MEM/I2C mode, EPP/I2C adapter
 5523 CH341 in serial mode, usb to serial port converter
 5584 CH341 in parallel mode, usb to printer port converter
 7522 CH340 serial converter
 7523 CH340 serial converter
 752d CH345 MIDI adapter
 7584 CH340S
 e008 HID-based serial adapter

Generic indeed.

----

# wget http://www.linux-usb.org/usb.ids

# TAB=$'\t'; lastcode=; lastrest=; sed -e '/^[[:blank:]]*#/d;/^$/d' usb.ids | while IFS=' ' read -r code rest; do if test "${code#$TAB}" = "$code"; then lastcode=$code; lastrest=$rest; else echo "$lastcode:${code#$TAB} $rest ($lastrest)"; fi; done > usb.ids.full

# head -n3 usb.ids.full

0001:7778 Counterfeit flash drive [Kingston] (Fry's Electronics)
0002:0002 passport00 (Ingram)
0002:7007 HPRT XT300 (Ingram)

# cat /lib/udev/rules.d/85-brltty.rules | sed -e '/^ENV{PRODUCT}/!d;s/[^"]*"//;s#/\*.*##;s#/#:#;s/^\(...\):/0\1:/;s/:\(...\)$/:0\1/;s/:\(..\)$/:00\1/;s/:\(.\)$/:000\1/' | head -n3

0403:de58
0403:de59
0403:f208

# cat /lib/udev/rules.d/85-brltty.rules | sed -e '/^ENV{PRODUCT}/!d;s/[^"]*"//;s#/\*.*##;s#/#:#;s/^\(...\):/0\1:/;s/:\(...\)$/:0\1/;s/:\(..\)$/:00\1/;s/:\(.\)$/:000\1/' | while read id; do grep "^$id" usb.ids.full ; done

0403:f208 Papenmeier Braille-Display (Future Technology Devices International, Ltd)
0452:0100 Control Panel for Leica TCS SP5 (Mitsubishi Electronics America, Inc.)
045e:930a ISOUSB.SYS Intel 82930 Isochronous IO Test Board (Microsoft Corp.)
0798:0001 Braille Voyager (Optelec)
0798:0640 BC640 (Optelec)
0798:0680 BC680 (Optelec)
1209:abc0 Omzlo controller (Generic)
16c0:05e1 Free shared USB VID/PID pair for CDC devices (Van Ooijen Technische Informatica)
1a86:7523 CH340 serial converter (QinHeng Electronics)
1c71:c004 Braille Note Apex (braille terminal mode) (Humanware Inc)

----

Of those devices found in usb.ids, I only see the first and last as definite Braille devices. The others.. not so sure.

Do with this info what you want.

Cheers,
Walter

[Samuel thibault (samuel-thibault)]

Concerning 1a86:7523, the udev rules file in ubuntu indeed seems to be missing the manufacturer filter:

debian/brltty.udev.rules says:
ENV{PRODUCT}=="1a86/7523/*", ENV{BRLTTY_BRAILLE_DRIVER}="bm", GOTO="brltty_usb_run"

while it should be:
ENV{PRODUCT}=="1a86/7523/*", ATTRS{idVendor}=="1a40", ATTRS{idProduct}=="0101", ENV{BRLTTY_BRAILLE_DRIVER}="bm", GOTO="brltty_usb_run"

This needs to be fixed in the various ubuntu brltty versions, starting from 6.4.

BTW, for 403/6001 I see there
Ubuntu disable those to avoid conflicts, https://launchpad.net/bugs/1958224
But the line with the manufacturer filter should *not* be disabled, it properly filters-in the producer of the Braille devices.

[Julian Andres Klode (juliank)]

This needs a followup SRU for the 1a86:7523 following the change in mantic, but it may be best to track this in a new bug report?

[Julian Andres Klode (juliank)]

It does seem we already have bug 1990189 fgor the 1a86:7523

[ihor lys (ihor-lys)]

Confirming this exists still on a fully upgraded system of 22.04 LTS for vanilla online RS485 converters using the CH340 USB to 485 chip.

[Alessandro Astone (aleasto)]

@samuel-thibault, regarding comment #42

1. I don't understand how a device can match both
  ENV{PRODUCT}=="1a86/7523/*"
and
  ATTRS{idVendor}=="1a40", ATTRS{idProduct}=="0101"
aren't the identifiers in ENV{PRODUCT} already idVendor/idProduct?

2. Are you saying we re-enable lines:
  ENV{PRODUCT}=="10c4/ea60/*", ATTR{manufacturer}=="Silicon Labs", ENV{BRLTTY_BRAILLE_DRIVER}="sk", GOTO="brltty_usb_run"
  ENV{PRODUCT}=="10c4/ea80/*", ATTR{manufacturer}=="Silicon Laboratories", ENV{BRLTTY_BRAILLE_DRIVER}="sk", GOTO="brltty_usb_run"
because it filters ATTR{manufacturer}=="Silicon Lab*"?
Isn't that also a generic manufacturer that will match unwanted devices?

[Samuel thibault (samuel-thibault)]

> aren't the identifiers in ENV{PRODUCT} already idVendor/idProduct?

I don't know the details. From what I gather from the upstream source code, this device has a special rule to appear like this in the udev file:

Drivers/Braille/Baum/braille.c:

    { /* NLS eReader Zoomax (20 cells) */
      .vendor=0X1A86, .product=0X7523,
      .parentVendor=0X1A40, .parentProduct=0X0101,

Perhaps something like 1A86/7523 plugged on 1A40/0101. That being said it seems like both are generic ids, and the combination of them is not really specific to Baum devices, since one could very well plug a QinHeng Electronics HL-340 USB-Serial adapter on a Terminus Technology Inc. 4-Port HUB.

I have opened the question on https://brltty.app/pipermail/brltty/2024-November/020445.html

[Samuel thibault (samuel-thibault)]

> Are you saying we re-enable lines:
> ENV{PRODUCT}=="10c4/ea60

I didn't talk about these lines, but the 403/6001 ones, that do match a proper Braille manufacturer string:

ENV{PRODUCT}=="403/6001/*", ATTR{manufacturer}=="Hedo Reha Technik GmbH", ENV{BRLTTY_BRAILLE_DRIVER}="hd", GOTO="brltty_usb_run"
ENV{PRODUCT}=="403/6001/*", ATTR{manufacturer}=="Tivomatic Oy", ENV{BRLTTY_BRAILLE_DRIVER}="at", GOTO="brltty_usb_run"

[Samuel thibault (samuel-thibault)]

> Perhaps something like 1A86/7523 plugged on 1A40/0101. That being said it seems like both are generic ids

Ah, but this 1A86/7523 line is properly emitted by upstream in the `usb-generic.rules` file, so it shouldn't be enabled by default, to avoid matching such combination of generic devices.

The two 403/6001 lines I mentioned in #48 are however really proper, I have notified upstream about them.

[Alessandro Astone (aleasto)]

Thanks, understood.

Took that into consideration for the 6.7-1 merge: https://code.launchpad.net/~aleasto/ubuntu/+source/brltty/+git/brltty/+merge/477046