-----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
p3cAnixaq8s71iWzEJ4CbCURb0Dc1tA6
=HnXY
-----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
