Bug#721763: brltty grabs tty from CP2102/CP2109 device disconnecting default
Hello, Mika Hanhijärvi, le dim. 31 mars 2019 19:59:19 +0300, a ecrit: > This bug seems to still exist in Debian 9.8 "Stretch". As explained earlier in the thread, the behavior mentioned in the topic "grabs tty from CP2102/CP2109" is expected, because that's the only way for blind people to get their their device working without having to configure things blindly. What is not expected is the package to be installed on a system which does not have a Braille device. As mentioned earlier again, AFAIK that *only* happens if these devices are plugged during installation of Debian. Samuel
Bug#721763: brltty grabs tty from CP2102/CP2109 device disconnecting default
Hello This bug seems to still exist in Debian 9.8 "Stretch". I actually do not own any hardware using the cp210X kernel module, I am just forwarding this information here. Output from lsusb command: Bus 006 Device 002: ID 10c4:ea60 Cygnal Integrated Products, Inc. CP210x UART Bridge / myAVR mySmartUSB light Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Output from logs: Mar 31 07:23:57 debian kernel: [ 6221.612063] usb 6-2: new full-speed USB device number 2 using uhci_hcd Mar 31 07:23:57 debian kernel: [ 6221.791082] usb 6-2: New USB device found, idVendor=10c4, idProduct=ea60 Mar 31 07:23:57 debian kernel: [ 6221.791086] usb 6-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 Mar 31 07:23:57 debian kernel: [ 6221.791088] usb 6-2: Product: CP2102 USB to UART Bridge Controller Mar 31 07:23:57 debian kernel: [ 6221.791090] usb 6-2: Manufacturer: Silicon Labs Mar 31 07:23:57 debian kernel: [ 6221.791092] usb 6-2: SerialNumber: 0001 Mar 31 07:23:57 debian mtp-probe: checking bus 6, device 2: "/sys/devices/pci:00/:00:1d.0/usb6/6-2" Mar 31 07:23:57 debian mtp-probe: bus: 6, device: 2 was not an MTP device Mar 31 07:23:57 debian kernel: [ 6221.869563] usbcore: registered new interface driver usbserial Mar 31 07:23:57 debian kernel: [ 6221.869586] usbcore: registered new interface driver usbserial_generic Mar 31 07:23:57 debian kernel: [ 6221.869607] usbserial: USB Serial support registered for generic Mar 31 07:23:57 debian kernel: [ 6221.892149] usbcore: registered new interface driver cp210x Mar 31 07:23:57 debian kernel: [ 6221.892173] usbserial: USB Serial support registered for cp210x Mar 31 07:23:57 debian kernel: [ 6221.892225] cp210x 6-2:1.0: cp210x converter detected Mar 31 07:23:57 debian kernel: [ 6221.898200] usb 6-2: cp210x converter now attached to ttyUSB0 Mar 31 07:24:01 debian brltty[430]: USB configuration set error 16: Laite tai resurssi varattu. Mar 31 07:24:01 debian brltty[430]: brltty: USB configuration set error 16: Laite tai resurssi varattu. Mar 31 07:24:01 debian kernel: [ 6225.530058] usb 6-2: usbfs: interface 0 claimed by cp210x while 'brltty' sets config #1 Mar 31 07:24:01 debian brltty[430]: brltty: USB interface in use: 0 (cp210x) Mar 31 07:24:01 debian brltty[430]: USB interface in use: 0 (cp210x) Mar 31 07:24:01 debian kernel: [ 6225.532412] cp210x ttyUSB0: cp210x converter now disconnected from ttyUSB0 Mar 31 07:24:01 debian kernel: [ 6225.532431] cp210x 6-2:1.0: device disconnected Mar 31 07:24:01 debian brltty[430]: Ignored Byte: 00 Mar 31 07:24:01 debian brltty[430]: brltty: Ignored Byte: 00 AFAIK the version of brltty in use is 5.4-7 which is the current brltty in Debian Stretch. Any idea if brltty 5.6 or later fixes this problem? Thanks in advance. Regards Mika
Bug#721763: brltty grabs tty from CP2102/CP2109 device disconnecting default kernel driver
Hello, Tjeerd Pinkert, on Tue 03 Sep 2013 22:30:18 +0200, wrote: > On connecting a CERN SPEC board (see www.ohwr.org White Rabbit > project) through it's USB to serial convertor (CP2102/CP2109, > vid=10C4h, pid=EA60h) to the system, expecting a ttyUSB device to be > installed using the default kernel driver, brltty unexpectedly > replaced the default kernel driver with it's own USB Braille terminal > driver. Since the Seika Braille reader uses the CP2102/CP2109 default > vid/pid, brltty addressed the SPEC board as such. Do you still have this board for testing? What values does it show in the idVendor field of lsusb -v? As explained in the bug report, we are wary of breaking users' support for their only way to access their computer. But recently version 5.4-3 of brltty was fixed into only taking control of devices with the right idVendor field. Unfortunately again the identifiers used by the actual devices are the main product ones, in the case of the current bugreport "Silicon Labs". Is that what your device has? Usually even if they didn't modify vid/pid the vendor field is modified, and thus brltty now avoids grabbing these. Samuel
Bug#721763: brltty grabs tty from CP2102/CP2109 device disconnecting default kernel driver
Tjeerd Pinkert, le Wed 18 Sep 2013 00:15:07 +0200, a écrit : > I have machines running Ubuntu and as a quick way of installing the > bulk of the software I use, I have simply installed the packages on my > Debian system that dpkg --get-selections gave on the Ubuntu system. Ah, that explains everything: the Ubuntu way is different: they assume brltty is to be installed on all systems, but it is not enabled by default; while on Debian brltty is not to be installed by default, but when installed, it is enabled by default. Samuel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#721763: brltty grabs tty from CP2102/CP2109 device disconnecting default kernel driver
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 15-09-13 21:22, Samuel Thibault wrote: > Tjeerd Pinkert, le Tue 03 Sep 2013 22:30:18 +0200, a ￩crit : >> brltty unexpectedly replaced the default kernel driver with it's >> own USB Braille terminal driver. Since the Seika Braille reader >> uses the CP2102/CP2109 default vid/pid, brltty addressed the SPEC >> board as such. > > Yes, this is unfortunately *expected*, actually. I conclude, only if the user installed brltty (which is assumed to be on purpose). >> To resolve the issue I uninstalled the brltty package. > > Yes, that's the proper way currently. What we would need to > understand is how brltty got installed on your system. We don't > expect systems without a braille device to have brltty installed. > That way, we can make some of these nasty devices actually work > easily without workarounds. The bug really is why brltty ended up > being installed on your computer. Uhm, yes, good question (blush). There are two possible answers. I have machines running Ubuntu and as a quick way of installing the bulk of the software I use, I have simply installed the packages on my Debian system that dpkg --get-selections gave on the Ubuntu system. While uninstalling brltty on the Ubuntu system I got the message: - --- The following actions will resolve these dependencies: Remove the following packages: 1) brltty-x11 Leave the following dependencies unresolved: 2) ubuntu-desktop recommends brltty - --- so it might have been installed by default on Ubuntu 12.04 LTS? A second Ubuntu system had the brltty package installed too, no *brl* processes running, no ubuntu-desktop dependency complaint on removal. A second possibility is that I might have pulled the package in (having to install new systems lately, going through the huge package list and installing all what seems usefull) myself on the Ubuntu side and then having applied the above copy action. To be sure about this I would need to either reinstall, or find a way of seeing what Ubuntu installs as a minimum. Most probably I'm the fault here. So this means the bug could be closed for Debian, since it is not a fault in the distro, and most probably caused by myself installing something I should not have done, although there is a real problem with some devices which would have solved this on forehand in an ideal world. >> I have had contact with: The devellopers, among others Eric van >> der Bij and Tomasz Wlostowski, of the SPEC board, whose strong >> conviction is that the default kernel driver should be used to >> yield a ttyUSB device, and that changing to a custom vid/pid for >> this harware will cause confusion. > > Why would this cause confusion? This vid/pid designates a serial > port converter. Using another vid/pid to more precisely describe > the device would be useful. The chip (on the SPEC) is used as serial port, so the defaults are correct. > Anyway, the SPEC board is not an isolated case. Whatever serial > device, which a user would connect through a USB-to-serial > converter, would have just the same issue. Which is crazily crazy. > USB has *given* us a way for a device to identify itself in a > perfectly safe way, and thus permits to have real safe plug&play > support, which was an extremely great addition for the > accessibility of the debian installer, for instance. Indeed, one could say it is a manufacturer induced problem, if a device is not meant to be a serial port. > Yes, we can't do anything for the already-produced devices, we'll > have to live with them. It'd however be really good to manage to > convince Seika & such that having a separate vid/pid is a really > important detail for accessibility everywhere on the long term. That would be best indeed... I have notified them of the bug report here. I hope it is picked up. Maybe active contact from the actual user community would help here? >> My expectation of the outcome is: the default kernel driver >> being respected for the default vid/pid of USB to serial >> convertors, but a possibility to enable the use of brltty if >> needed will be provided. If possible, clear communication to the >> blind users of brltty is given on forehand, that specific devices >> will become disabled because of this issue. > > This is actually already what we have: brltty is not supposed to > be installed on usual systems, and blind users know that they have > to install brltty (or get it automatically installed by the > installer run in braille mode) in order to get their braille device > working. I would argue differently, it can get installed somehow... However, the (Debian?) view on the issue is more clear and I think the bug can thus be closed. Tjeerd -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iEYEARECAAYFAlI41GoACgkQ9xQaBfeouapDaQCfc2IMZ7WQ9EiOE/7bbU7yVHSy p3cAnixaq8s71iWzEJ
Bug#721763: brltty grabs tty from CP2102/CP2109 device disconnecting default kernel driver
Tjeerd Pinkert, le Tue 03 Sep 2013 22:30:18 +0200, a écrit : > brltty unexpectedly replaced the default kernel driver with it's own > USB Braille terminal driver. Since the Seika Braille reader uses the > CP2102/CP2109 default vid/pid, brltty addressed the SPEC board as > such. Yes, this is unfortunately *expected*, actually. > To resolve the issue I uninstalled the brltty package. Yes, that's the proper way currently. What we would need to understand is how brltty got installed on your system. We don't expect systems without a braille device to have brltty installed. That way, we can make some of these nasty devices actually work easily without workarounds. The bug really is why brltty ended up being installed on your computer. > As far as the sources concern, the vid/pid combination is found in > Drivers/Braille/Seika/braille.c connectResource() function, but also > in the Hotplug/udev.rules file. I cannot find the latter installed, > and thus assume that the c-code is used. Yes. > If I look at the udev.rules file in the source the news means that > this bug presumably also holds for the following devices: > # Device: 10C4:EA80 > # Device: 0403:6001 Agreed. > I had hoped to be able to disable the conflicting device by disabling > the brltty udev rules for these devices, which is alas not possible at > the moment, since it seems not to be used. You can also simply disable the daemon. > I have had contact with: > The devellopers, among others Eric van der Bij and Tomasz Wlostowski, > of the SPEC board, whose strong conviction is that the default kernel > driver should be used to yield a ttyUSB device, and that changing to a > custom vid/pid for this harware will cause confusion. Why would this cause confusion? This vid/pid designates a serial port converter. Using another vid/pid to more precisely describe the device would be useful. > Not to mention the problems this would possibly cause in Windows land, > since this means programming (and certification) of a custom serial > port driver. That, however, I can't argue on. That's what we get with systems which tend to steal rights from its users. Note however that IIRC on newer Windows systems, WinUSB permits to easily access USB devices from userland. Anyway, the SPEC board is not an isolated case. Whatever serial device, which a user would connect through a USB-to-serial converter, would have just the same issue. > A develloper, Dave Mielke, of brltty, whose conviction is that the > SPEC usage of the default vid/pid is correct, but that brltty should > enable as many devices as possible for ease of use by blind people, > the Braille devices are their screen. A standpoint that can be > understood from his perspective. And from the perspective of all blind users, actually. It has to be thought like "Would you be happy with having to configure something on the system of your laptop before being able to see anything on the screen?" This is fine for e.g. an embedded device, which you can usually access another way, but not for a laptop. > Dave is investigating if the device can be distinghuished from the > default chip via other/additional USB descriptors. I'm afraid that'll not be possible. And there'll always be manufacturers which don't pay attention to making that possible. > The manufacturer, Seika, of the Braille reader, who says the reader > can identify itself over the serial bus. Which is crazily crazy. USB has *given* us a way for a device to identify itself in a perfectly safe way, and thus permits to have real safe plug&play support, which was an extremely great addition for the accessibility of the debian installer, for instance. Still relying on probing is just about still living in the XXth century... Seika has to understand that the consequence of his not using a dedicated vid/pid basically means *not* seeing accessibility everywhere someday, since it is well-known that blindly (sic) probing a serial port can sometimes mean bricking the non-braille-device device at the other end, so we can not dare systematically probing for whatever braille device could get connected. > Although the CP210x chips in principle allow reprogramming, it seems > not so easy to solve this problem on the hardware side of the Braille > readers, since existing Braille displays are not easily replaced > because of their high cost and users might not understand why they > should update vid/pid if it could be done in a proper way. Yes, we can't do anything for the already-produced devices, we'll have to live with them. It'd however be really good to manage to convince Seika & such that having a separate vid/pid is a really important detail for accessibility everywhere on the long term. > My expectation of the outcome is: the default kernel driver being > respected for the default vid/pid of USB to serial convertors, but a > possibility to enable the use of brltty if needed will be provided. If > possible, clear communication to the blin
Bug#721763: brltty grabs tty from CP2102/CP2109 device disconnecting default kernel driver
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Package: brltty Severity: critical Tags: upstream Justification: breaks unrelated software Dear Maintainer, On connecting a CERN SPEC board (see www.ohwr.org White Rabbit project) through it's USB to serial convertor (CP2102/CP2109, vid=10C4h, pid=EA60h) to the system, expecting a ttyUSB device to be installed using the default kernel driver, brltty unexpectedly replaced the default kernel driver with it's own USB Braille terminal driver. Since the Seika Braille reader uses the CP2102/CP2109 default vid/pid, brltty addressed the SPEC board as such. The output of dmesg is given here: [ 3548.128782] usb 3-1.5: new full-speed USB device number 7 using ehci_hcd [ 3548.222649] usb 3-1.5: New USB device found, idVendor=10c4, idProduct=ea60 [ 3548.222654] usb 3-1.5: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 3548.222657] usb 3-1.5: Product: CP2102 USB to UART Bridge Controller [ 3548.222660] usb 3-1.5: Manufacturer: Silicon Labs [ 3548.222662] usb 3-1.5: SerialNumber: 0001 [ 3548.223562] cp210x 3-1.5:1.0: cp210x converter detected [ 3548.296321] usb 3-1.5: reset full-speed USB device number 7 using ehci_hcd [ 3548.389167] usb 3-1.5: cp210x converter now attached to ttyUSB0 [ 3548.389243] usb 3-1.5: usbfs: interface 0 claimed by cp210x while 'brltty' sets config #1 [ 3548.389670] cp210x ttyUSB0: cp210x converter now disconnected from ttyUSB0 [ 3548.389691] cp210x 3-1.5:1.0: device disconnected To resolve the issue I uninstalled the brltty package. Withholding brltty from connecting by default to the conflicting USB to serial convertors involved, solves this problem, but seems not easily possible at the moment. As far as the sources concern, the vid/pid combination is found in Drivers/Braille/Seika/braille.c connectResource() function, but also in the Hotplug/udev.rules file. I cannot find the latter installed, and thus assume that the c-code is used. Furtheron I read that alls supported USB devices are enabled by default in the /usr/share/doc/brltty/NEWS.Debian.gz file. If I look at the udev.rules file in the source the news means that this bug presumably also holds for the following devices: # Device: 10C4:EA80 # Generic Identifier # Vendor: Cygnal Integrated Products, Inc. # Product: CP210x UART Bridge # Seika [Note Taker] # 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] it holds for my device: # Device: 10C4:EA60 # Generic Identifier # Vendor: Cygnal Integrated Products, Inc. # Product: CP210x UART Bridge / myAVR mySmartUSB light # Seika [Braille Display] I had hoped to be able to disable the conflicting device by disabling the brltty udev rules for these devices, which is alas not possible at the moment, since it seems not to be used. I have had contact with: The devellopers, among others Eric van der Bij and Tomasz Wlostowski, of the SPEC board, whose strong conviction is that the default kernel driver should be used to yield a ttyUSB device, and that changing to a custom vid/pid for this harware will cause confusion. Not to mention the problems this would possibly cause in Windows land, since this means programming (and certification) of a custom serial port driver. A develloper, Dave Mielke, of brltty, whose conviction is that the SPEC usage of the default vid/pid is correct, but that brltty should enable as many devices as possible for ease of use by blind people, the Braille devices are their screen. A standpoint that can be understood from his perspective. Dave is investigating if the device can be distinghuished from the default chip via other/additional USB descriptors. The manufacturer, Seika, of the Braille reader, who says the reader can identify itself over the serial bus. No outcome on what is possible with the vid/pid is given up to this moment. Programming a custom serial port driver (and having it certified) on the Windows platform might be a problem in this case too (this is speculative from my side). Although the CP210x chips in principle allow reprogramming, it seems not so easy to solve this problem on the hardware side of the Braille readers, since existing Braille displays are not easily replaced because of their high cost and users might not understand why they should update vid/pid if it could be done in a proper way. My expectation of the outcome is: the default kernel driver being respected for the default vid/pid of USB to serial convertors, but a possibility to enable the use of brltty if needed will be provided. If possible, clear communication to the blind users of brltty is given on forehand, that specific devices will become disabled because of this issue. Yours, Tjeerd Pinkert - -- System Information: Debian Release: jessie/sid APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'testing'), (50
