[BRLTTY] 5.4 has been released.

[Dave Mielke]

[quoted lines by Samuel Thibault on 2016/07/04 at 21:54 +0200]

>in Debian we do use a udev rule for 0403/6001 because there are popular 
>devices which use this generic ID. 

Do you, then, allow all generic adapter rules in? If you only allow this one, 
how do you filter the others out? Does the updusbdevs script need more 
functionality?

>We however have to limit the set of drivers that we enable to hm and ht, and 
>notably we removed at, ce and mm, because when a handytech Device is plugged, 
>they were bogusly discovering it (conflicting protocols).

That's probably the answer to a question that we (Mario and I) couldn't 
remember the answer to. We were wondering why the udev rules were setting the 
braille driver to auto rather than to the known, explicit list. When auto is 
specified, an internal driver list is used which indeed doesn't include those 
problematic drivers. The trade-off to using auto, of course, is that a lot more 
drivers are checked.

>So my question means: will the md driver pose the same kind of issue,
>or is it safe to enable it along hm and ht?

Its protocol looks different enough that I wouldn't expect a problem.

>Actually, perhaps upstream brltty itself should not enable all these
>drivers in the generic udev file it ships, since it is well-known that
>there is no way for brltty to discover by itself which one should be
>used, and thus I'd say only the most popular non-conflicting ones should
>be enabled by default (the user can still override that).

As described above, specifying auto (for the driver) already does. What we 
probably really want, though, is a way for the udev rules to specify an 
explicit list that doesn't include them.

-- 
Dave Mielke           | 2213 Fox Crescent | The Bible is the very Word of God.
Phone: 1-613-726-0014 | Ottawa, Ontario   | http://Mielke.cc/bible/
EMail: Dave at Mielke.cc | Canada  K2A 1H7   | http://FamilyRadio.org/