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 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. Samuel -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
