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 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
Reply to: