brltty silently blocks CH340 USB driver under Linux Mint 20/21

[s0170071]

Describe the problem

There is a misleading flaw with the CH340 driver under Linux. It causes the USB based boards such as Wemos D1 mini to not show up in the ports list.

There is a lot of tips around, such as :

1. Since Linux Mint version 20.3 the CH340 driver is not included in the kernel (version >5.3). Using a n older kernel version fixes this.
2. Normally, the driver just needs to be downloaded, compiled and added to the system:
3. If the system is in UEFI mode, the driver needs to be signed.

I faintly remember that I could do 1. and 2. for non UEFI versions of Linux Mint, but I did not try 3. as it is too much of a hassle for me. However, I just discovered a fourth solution.

According to this source the driver is included in the kernel after all, but apparently gets blocked by a braille display driver.

Workaround (confirmed): uninstall brltty with sudo apt-get remove brltty and you're good to go.

To reproduce

Use a out-of-the-box Linux mint and try to get a CH340 based board programmed.

Expected behavior

I would expect the IDE to to check for this brltty flaw as this has been around for quite some time noẃ and is tricky to find.

Arduino IDE version

2.0.3

Operating system

Linux

Operating system version

Linux Mint 21

Additional context

No response

Issue checklist

• I searched for previous reports in the issue tracker
• I verified the problem still occurs when using the latest nightly build
• My report contains all necessary details

[per1234]

Hi @s0170071. Thanks for your suggestion. There is nothing that can be done in the Arduino IDE codebase to fix or mitigate this problem.

The place for the fix is at the source of the problem: the BRLTTY project. Please report this irresponsible treatment of serial ports by BRLTTY to the maintainers of that project:

https://brltty.app/contact.html

---

The place where I do think Arduino can mitigate this common (the scope is actually larger than the specific combination of Linux Mint + CH340 you mention here) source of problems for users is via documentation. I think it would be a good idea to document this cause of the problem and the fix in an Arduino Help Center article. I see there is a somewhat related article:

• https://support.arduino.cc/hc/en-us/articles/360016495679-Fix-port-access-on-Linux

but nothing about BRLTTY specifically. For this reason, I have transferred the issue to the repository where the Help Center content is maintained:

arduino/help-center-content#155

[DaveMielke]

For purposes of introduction, I'm the dude who has the final word concerning the brltty project. I've received several emails drawing my attention to the fact that brltty is stealing generic USB to serial adapters, like the CH340, from those who'd like to use them for other purposes. Yes, that buck does stop at me. I've just been asked to comment on this issue here, supposedly because that'd be a way to contact most of you at once.

Some braille device manufacturers, especially recently, have opted to use generic internal USB to serial adapters without customizing them (vendor/product identifiers, manufacturer/product strings, etc). Nevertheless, brltty still needs to be able to recognize even these devices because, without an operational braille device, a braille user (who is most probably blind) effectively has no screen. It'd be just like any of you sighted users booting your computer and then finding yourself without a screen while you try to figure out why it isn't working and how to get it working.

I'm guessing that those of you who are finding this issue to still be a problem have a release of brltty earlier than 6.5 installed on your computer. In 6.5, we implemented what we hoped would be a reasonable resolution to it. We split out the rules for claiming generic USB to serial adapters out into a separate udev rules file which needs to be installed separately from the main package.

You can tell which version of brltty you have by using its -V (or --version) command line option. If it's earlier than 6.5 then I suggest upgrading it. If it's 6.5 or later then I'm guessing that that optional udev rules package is installed and should be removed.

[s0170071]

@DaveMielke thanks for stopping by here.
My syslog reads BRLTTY 6.4 rev BRLTTY-6.4 . It does not provide the third digit of its version number. But I assume it is 6.4.4 because this is what I get when I re-install it.
During installation, the console says:
http://archive.ubuntu.com/ubuntu jammy-updates/main amd64 brltty amd64 6.4-4ubuntu3 [1365 kB]
I could test 6.5 to see if the issue is gone, but I have no idea how I would get that latest version. Apparently the ubuntu repositories (and linux mint for that matter) still provide v6.4.4 as latest version.

[DaveMielke]

[quoted lines by s0170071 on 2022/12/27 at 18:11 +0000]

My syslog reads `BRLTTY 6.4 rev BRLTTY-6.4 `. It does not provide the third digit of its version number.

We don't often have releases with a third digit, so you can assume 0.

But I assume it is 6.4.4 because this is what I get when I re-install it. During installation, the console says: `http://archive.ubuntu.com/ubuntu jammy-updates/main amd64 brltty amd64 6.4-4ubuntu3 [1365 kB] `

that .4 would've been added by the Ubuntu (or maybe the Debian) people. They do that kind of thing when they pick up commits from after 6.4 because they think they're important enough.

I could test 6.5 to see if the issue is gone, but I have no idea how I would get that latest version.

Nor do I as I use Fedora.

Apparently the ubuntu repositories (and linux mint for that matter) still provide v6.4.4 as latest version.

6.5 was released this past June. Maybe you need to point your sources.list (I think that's what Debian calls it) to some new, testing, or experimental repository, or something like that. Another thing you should be able to do is to disable the brltty service. Again, since I'm not a Debian user, I don't know, off the top of my head, how to do that on a Debian-based system.