-----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'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 3.10-2-686-pae (SMP w/2 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iEYEARECAAYFAlImRtkACgkQ9xQaBfeouaoxVQCfUbhK6KrbZgkNBvu6ZJMUGuw+ sHsAn2ZQNrF7e6nYIag1ra0KJ4T27GCa =im+i -----END PGP SIGNATURE----- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org