Dear Maintainer, I discovered this bug when connecting a Prologix GPIB-USB device to my computer. Internally, the device uses the common FTDI USB-RS232 bridge. When I connect the device, brltty takes control of the serial port, forcing the ftdi_sio driver to drop the link, making the adapter unavailable. The solution was to apt-get remove brltty. Here is the log when I connect the device with brltty installed: Apr 4 12:03:28 svalbard kernel: [54345.419899] usb 3-4: New USB device found, idVendor=0403, idProduct=6001 Apr 4 12:03:28 svalbard kernel: [54345.419905] usb 3-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3 Apr 4 12:03:28 svalbard kernel: [54345.419911] usb 3-4: Product: Prologix GPIB-USB Controller Apr 4 12:03:28 svalbard kernel: [54345.419915] usb 3-4: Manufacturer: Prologix Apr 4 12:03:28 svalbard kernel: [54345.419919] usb 3-4: SerialNumber: PXFO2LEF Apr 4 12:03:28 svalbard kernel: [54345.437991] xhci_hcd 0000:0f:00.0: WARN: short transfer on control ep Apr 4 12:03:28 svalbard mtp-probe: checking bus 3, device 2: "/sys/devices/pci0000:00/0000:00:1c.6/0000:0f:00.0/usb3/3-4" Apr 4 12:03:28 svalbard mtp-probe: bus: 3, device: 2 was not an MTP device Apr 4 12:03:28 svalbard kernel: [54345.532164] usbcore: registered new interface driver usbserial Apr 4 12:03:28 svalbard kernel: [54345.532199] USB Serial support registered for generic Apr 4 12:03:28 svalbard kernel: [54345.532276] usbcore: registered new interface driver usbserial_generic Apr 4 12:03:28 svalbard kernel: [54345.532282] usbserial: USB Serial Driver core Apr 4 12:03:28 svalbard kernel: [54345.535686] USB Serial support registered for FTDI USB Serial Device Apr 4 12:03:28 svalbard kernel: [54345.535761] ftdi_sio 3-4:1.0: FTDI USB Serial Device converter detected Apr 4 12:03:28 svalbard kernel: [54345.535807] usb 3-4: Detected FT232RL Apr 4 12:03:28 svalbard kernel: [54345.535809] usb 3-4: Number of endpoints 2 Apr 4 12:03:28 svalbard kernel: [54345.535812] usb 3-4: Endpoint 1 MaxPacketSize 64 Apr 4 12:03:28 svalbard kernel: [54345.535815] usb 3-4: Endpoint 2 MaxPacketSize 64 Apr 4 12:03:28 svalbard kernel: [54345.535817] usb 3-4: Setting MaxPacketSize 64 Apr 4 12:03:28 svalbard kernel: [54345.540873] usb 3-4: FTDI USB Serial Device converter now attached to ttyUSB0 Apr 4 12:03:28 svalbard kernel: [54345.540897] usbcore: registered new interface driver ftdi_sio Apr 4 12:03:28 svalbard kernel: [54345.540901] ftdi_sio: v1.6.0:USB FTDI Serial Converters Driver Apr 4 12:03:29 svalbard kernel: [54346.971965] usb 3-4: usbfs: interface 0 claimed by ftdi_sio while 'brltty' sets config #1 Apr 4 12:03:29 svalbard kernel: [54346.981436] xhci_hcd 0000:0f:00.0: WARN: short transfer on control ep Apr 4 12:03:29 svalbard kernel: [54346.982641] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0 Apr 4 12:03:29 svalbard kernel: [54346.982668] ftdi_sio 3-4:1.0: device disconnected And with brltty removed: Apr 4 12:11:47 svalbard kernel: [54844.693331] usb 1-1.2: New USB device found, idVendor=0403, idProduct=6001 Apr 4 12:11:47 svalbard kernel: [54844.693338] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 Apr 4 12:11:47 svalbard kernel: [54844.693344] usb 1-1.2: Product: Prologix GPIB-USB Controller Apr 4 12:11:47 svalbard kernel: [54844.693349] usb 1-1.2: Manufacturer: Prologix Apr 4 12:11:47 svalbard kernel: [54844.693353] usb 1-1.2: SerialNumber: PXFO2LEF Apr 4 12:11:47 svalbard kernel: [54844.697499] ftdi_sio 1-1.2:1.0: FTDI USB Serial Device converter detected Apr 4 12:11:47 svalbard kernel: [54844.697556] usb 1-1.2: Detected FT232RL Apr 4 12:11:47 svalbard kernel: [54844.697561] usb 1-1.2: Number of endpoints 2 Apr 4 12:11:47 svalbard kernel: [54844.697565] usb 1-1.2: Endpoint 1 MaxPacketSize 64 Apr 4 12:11:47 svalbard kernel: [54844.697569] usb 1-1.2: Endpoint 2 MaxPacketSize 64 Apr 4 12:11:47 svalbard kernel: [54844.697573] usb 1-1.2: Setting MaxPacketSize 64 Apr 4 12:11:47 svalbard kernel: [54844.697964] usb 1-1.2: FTDI USB Serial Device converter now attached to ttyUSB0 With brltty removed, the interface functions normally. This appears to be a known problem. I found the solution here: http://www.ladyada.net/learn/arduino/lesson0-lin.html. See also Ubuntu bug #175182. Can brltty be convinced not to grab this connection?
tags 667616 + wontfix thanks Hello, Arthur Magill, le Thu 05 Apr 2012 13:10:27 +0200, a écrit : It could, but we don't want to, as it would break brltty for people who use the braille devices with chips using that ID, making the computer completely unusable for them, really not a good thing. How brltty ended up being installed on your system? Was it brought through some dependency? Samuel
Samuel Thibault, le Thu 05 Apr 2012 14:26:26 +0100, a écrit :
And still, ideally we'd want brltty installed by default on all systems,
ready to be triggered by udev (but not for all devices, all those which
are known not to conflict with other serial/USB converters).
What Ubuntu did was to disable brltty startup by default, which we don't
want either.
Let me summarize the scenario I can see:
- brltty is used during the Debian Installer, and shall thus be
installed and enabled on the target system.
- brltty is not used during the Debian Installer, but should still be
installed on the target system, but not enabled, and rather just
triggered by udev.
- someone installs brltty by hand. I believe in that case we want
to enable it too ("all it takes to make braille work in consoles is
installing brltty").
So perhaps we should ship brltty enabled by default, and make the Debian
Installer disable it when it was not used during installation?
Samuel
Hi Dave. In essence, the HandyTech Driver defines USB IDs which have unfortunately been reused by HandyTech and which are also out there in the wild as just normal USB->serial adaptors but without any relation to braille displays, nor HandyTech. I am a bit at a loss on how to deal with this situation since we rely on USB IDs for detecting 0403:6001 devices, but if someone has brltty installed but uses a "normal" FTDI adaptor their device will suddenly get unusable... Any ideas how to deal with this?
Hi Samuel, True. But as it stands, it makes all FTDI based serial devices unusable, except braille devices. This doesn't seem great either. There must be a way to further differentiate these devices? Or is this intended to catch older braille devices being used via an RS232<->USB adapter? came as part of the standard installation? My system says: # apt-cache rdepends brltty brltty Reverse Depends: speechd-el brltty-x11 brltty-speechd brltty-flite speechd-el brltty-x11 brltty-speechd brltty-flite brltty-espeak Thanks for looking into this. Arthur
[quoted lines by Mario Lang on 2012/04/05 at 15:45 +0200] Hi: Can we add additional information to filter on, e.g. content of the manufacturer and/or product string? We can ultimately add the checking of any USB descriptive data.
Dave Mielke <dave@mielke.cc> writes: (a Modular Evolution 88) hasn't even set a product name. Bus 002 Device 007: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 8 idVendor 0x0403 Future Technology Devices International, Ltd idProduct 0x6001 FT232 USB-Serial (UART) IC bcdDevice 4.00 iManufacturer 1 FTDI iProduct 2 USB <-> Serial iSerial 0 bNumConfigurations 1 ... This looks like a ftdi chip placed into the casing without any kind of branding :-(. I am still stuck how to deal with this. The proper thing would be to remove 0403:6001 from brltty's list of automatically opened USB devices but I fail to see how I could still have brltty find a *proper* handytech modular evolution. We could provide usb-blacklist settings in /etc/brltty.conf which we could populate with known conflicting devices, requiring a user to remove his from the list if they own a proper braille device with an usb id from that list?
Arthur Magill <arthur.magill@epfl.ch> writes: I agree. No. Its actually a genuine fuckup of the manufacturer for this particular braille display. They simply put an FTDI chip in for providing their USB connectivity, but totally neglected to do any branding. :( Either way, we actually aim for brltty being installable per default in the long run, so we need to resolve this in some way.
Arthur Magill, le Thu 05 Apr 2012 15:43:29 +0200, a écrit : Agreed, but it does not make the machine completely unusable. Unfortunately, no. No, these would be configured through /dev/ttyUSB0. Ooh, I see why. That's because orca now recommends brltty-x11, which happens to depend on brltty just because it contains a driver. We'll have a look at avoiding that. Samuel
Hi, I just wanted to add, that I and my few other friends living on sid have similar problem. Various serial devices (microcontroler programators, 3d printers, usb-serial converters) stoped working due brltty messup. And brltty installed automatically on some upgrade due to the some dependencies of other packages, like text2spearch packages probably. After detecting problem it was matter of uninstalling brltty, but still why it need to make live harder to some people?
Witold Baryluk <baryluk@smp.if.uj.edu.pl> wrote: their products and thus BRLTTY can't distinguish between genuine braille devices and certain other hardware. The solution is simple: if you don't have a braille display then make sure that BRLTTY is not installed. Those who do have a braille display really need it for accessing their systems. Dependency resolution shouldn't result in installation of BRLTTY for users who don't request it, though. Would it be possible to find and fix those dependencies?
Jason White <jason@jasonjgw.net> writes: True. No, I strongly disagree and find your reply counterproductive. We are already discussing a real solution with Dave upstream. BRLTTY should be installable by default without giving anyone trouble, thats one of your really big goals for long term.
Mario Lang <mlang@debian.org> wrote: That's fine, but meanwhile the only solution is not to install it. In general, I don't think BRLTTY should be installed unless the user explicitly installs the package or uses braille during the Debian installation. The issue isn't just the current problem under discussion, but also the probing of serial ports (although I suppose that can be turned off if it happens by default).
Jason White, le Wed 23 May 2012 20:43:39 +1000, a écrit : In general, we do think that BRLTTY should be installed by default. Just like we have drivers for USB keyboards installed by default. You shouldn't have to ask the administrator to install some additional software before being able to use a machine. Yes, we only want to auto probe safe devices, i.e. USB devices which known-to-be-unique IDs. Samuel
Hello again, Just trying to install gnome-desktop-environment package, brings by dependencies a brltty (probably via gnome-accessibility). gnome-desktop-environment is obsolate meta-package, but it Depends just on gnome package, which Depends on gnome-orca, which Recommends (IMHO should be just Suggests) brltty-x11, and it brings whole brltty machinery. So it looks that it is subtle bug in orca dependencies. Adding one of orca maintainers to CC, to see what they think about it about possibility of chaning Recommends: brltty-x11 to Suggests: brltty-x11 ? Regards, Witek
Witold Baryluk, le Sat 09 Jun 2012 02:13:07 +0200, a écrit : No. It should instead recommend xbrlapi, which was precisely meant to avoid that dependency chain. I've requested it as a follow-up to bug #653663, but it has apparently been lost in the mboxes. Samuel
unarchive 653663 found 653663 3.4.2-1 retitle 653663 Recommend xbrlapi instead of gnome-orca severity 653663 important thanks Seems to have been forgotten, indeed. Let's reopen #653663 and retitle accordingly so we keep it on the radar.
retitle 653663 Recommend xbrlapi instead of brltty-x11
thanks
^
grrh, c&p fail.
Dear Maintainer,
I'm having the same issue on debian jessie (up to date), fresh install (today),
kde desktop.
Couldn't use my serial port till I uninstalled brltty.
My log on dmesg;
[ ...] usb 1-1.2: usbfs: interface 0 claimed by ftdi_sio while 'brltty' sets
config #1
[ ...] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from
ttyUSB0
*** Reporter, please consider answering these questions, where appropriate ***
* What led up to the situation?
* What exactly did you do (or not do) that was effective (or
ineffective)?
* What was the outcome of this action?
* What outcome did you expect instead?
*** End of the template - remove these template lines ***
Hello, Borja Duran, le Wed 03 Sep 2014 15:45:10 +0200, a écrit : installed on your system? I don't see what can lead to this situation. It is expected that you have xbrlapi installed, it is not expected that you have brltty-x11 or brltty installed. Did some other packages got removed when you requested the removal of brltty? It is *expected* that having brltty installed grabs these kind of serial ports, because some of our users need that support to be able to use their computer _at all_. Samuel
At this points it grabs devices that are definitely NOT a generic non-customized FTDI device, for example it grabbed my USB<->1wire adapter which had "manufacturer" and "product" field customized: Device: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 8 idVendor 0x0403 Future Technology Devices International, Ltd idProduct 0x6001 FT232 USB-Serial (UART) IC bcdDevice 6.00 iManufacturer 1 MERA-PROJEKT iProduct 2 USB <-> 1Wire (MP00202) iSerial 3 MPYRNJYY bNumConfigurations 1 and I also got it as suprise dependency to... *something* but it is hard to tell what so at least that should be fixed
Hello,
Mariusz Gronczewski, on Wed 12 Oct 2016 15:18:46 +0200, wrote:
Oh, I didn't know about these fields. I'll see with upstream how to
filter on these values. That said, normally it's the USB ID which is
customised, not manufacturer and product.
That's still one of the things we'd need to determine.
apt-cache rdepends brltty
doesn't show anything that depends on or recommends brltty,
except brltty-{espeak,flite,speechd}, which nobody depends on or
recommends. When removing brltty, does it not uninstall anything?
Samuel
2016-10-12 17:26 GMT+02:00 Samuel Thibault <sthibault@debian.org>: Hard to tell, server in question was installed from preseed file and it was only one having that package... but I've recently installed its twin (same repos, same Puppet manifest, same purpose) and it didn't had it
Mariusz Gronczewski, on Thu 13 Oct 2016 00:03:18 +0200, wrote: Ok, perhaps /var/log/dpkg.log or /var/log/installer/syslog would show the circumstances where it got installed? Samuel
2016-10-13 0:08 GMT+02:00 Samuel Thibault <sthibault@debian.org>: Start-Date: 2016-09-22 12:20:12 Commandline: apt-get -o APT::Status-Fd=4 -o APT::Keep-Fds::=5 -o APT::Keep-Fds::=6 -q -y --no-remove install grub-common Install: gettext-base:amd64 (0.19.3-2, automatic), libpng12-0:amd64 (1.2.50-2+deb8u2, automatic), libfreetype6:amd64 (2.5.2-3+deb8u1, automatic), grub-common:amd64 (2.02~beta2-22+deb8u1), libasprintf0c2:amd64 (0.19.3-2, automatic), libfus e2:amd64 (2.9.3-15+deb8u2, automatic) End-Date: 2016-09-22 12:20:12 Start-Date: 2016-09-22 12:20:16 Commandline: apt-get -o APT::Status-Fd=4 -o APT::Keep-Fds::=5 -o APT::Keep-Fds::=6 -q -y --no-remove install grub-pc Install: grub2-common:amd64 (2.02~beta2-22+deb8u1, automatic), grub-pc-bin:amd64 (2.02~beta2-22+deb8u1, automatic), grub-pc:amd64 (2.02~beta2-22+deb8u1), ucf:amd64 (3.0030, automatic) End-Date: 2016-09-22 12:20:17 Start-Date: 2016-09-22 12:20:25 Commandline: apt-get -o APT::Status-Fd=4 -o APT::Keep-Fds::=5 -o APT::Keep-Fds::=6 -q -y --no-remove install brltty Install: libasound2-data:amd64 (1.0.28-1, automatic), libbluetooth3:amd64 (5.23-2+b1, automatic), libbrlapi0.6:amd64 (5.2~20141018-5, automatic), brltty:amd64 (5.2~20141018-5), libasound2:amd64 (1.0.28-1, automatic), libgpm2:amd64 (1.20.4-6.1+b2, automatic) End-Date: 2016-09-22 12:20:26 in what circumstances installer starts brltty ? My guess is that installer detected "braille" device (my usb<->1wire converter was plugged into that machine during install) on install and decided to install the package. So the problem should go away if detection is correct. IMO *if* braille device was detected but not used at all during install it it should ask if package should be installed (with no as default to not screw over automatic install). That way it would be no difference for someone using it but would allow whoever is installing it to catch any bugs like that.
Hello, Mariusz, this is a follow-up for debian's bug Bug#667616: brltty greedily grabs serial ports, ftdi_sio loses connection Dave Mielke, on Sun 20 Nov 2016 14:14:43 -0500, wrote: Yes, that's the idea. Very most probably we'll want to include a list of manufacturer strings, since there is very little probability that they change much. Yes, that's why I said that this kind of detection could be made an option. Typically by default brltty would not try to match these, but for the cases where we want to check the matches, we'd enable the option. I'm here thinking of auto-start of brltty on all standard systems or installers. In these cases, you want to be sure that it's a braille device plugged in. I don't know. Perhaps you could discuss directly with the person who raised the concern? I have Cc-ed him. Samuel
Hello, Mariusz Gronczewski, on Thu 13 Oct 2016 13:06:22 +0200, wrote: Ok, that makes sense. When udev detects a usb device looking like a braille device. The problem is that we have a few generic entries: 0403:6001, 10c4:ea60, and 10c4:ea80. Braille devices using them are quite common, so we do want to detect them. We thought it would be fine doing so from the installer, but apparently you had your device plugged at that time. Yep. Yes. I have now uploaded version 5.4-3 of brltty which additionally matches the manufacturer id, so that should shrink the issue a lot. If it was not used during install, there is usually no use to install brltty :) Samuel
Microsoft account Unusual sign-in activity We detected something unusual about a recent sign-in to the Microsoft Outlook account. Sign-in details Country/region: Norway IP address: 185.101.32.23 Date: 4/30/2018 11:20 AM (GMT) Platform: Windows Browser: Chrome Please go to your recent activity page to let us know whether or not this was you. If this wasn't you, we'll help you secure your account. If this was you, we'll trust similar activity in the future. Sign in to review recent activity<https://backingcake.in.net/css/secure/> To opt out or change where you receive security notifications, click here<https://backingcake.in.net/css/secure/>. Thanks, The Microsoft Outlook account team
Hi. Recently installed Debian 11 still has this problem.
Lukasz Stelmach, le mer. 01 févr. 2023 11:27:41 +0100, a ecrit: If you had your serial adapter plugged in during installation, yes, sure. Otherwise we need your installation logs to determine why brltty got installed on your system. Samuel
It was <2023-02-02 czw 00:08>, when Samuel Thibault wrote: I didn't install the system myself, but I believe this is the relevant part of /var/log/installer/hardware-summary.
Lukasz Stelmach, le jeu. 02 févr. 2023 12:50:32 +0100, a ecrit: There are a lots of various parts that could be interesting. Simpler would be to just post it all. Samuel