[BRLTTY] [PATCH] don't steal abused USB ids

[Dave Mielke]

[quoted lines by Stanislav Brabec on 2018/05/14 at 21:26 +0200]

>> Mightn't it be possible, if not fairly probable, that a system with a lot of 
>> those devices already connected to it is being reinstalled? I suppose, though, 
>> that what you mean is that it'd be okay to assume a braille device since those 
>> other devices, even if connected, wouldn't be useful when installing.
>
>System is installed: We can assume Braille device. We can live with
>non-Braille UART devices being not responding, at least for initial
>stage of installation. (The risk still exists, but it is pretty low, for
>example those serial UPSes with one character commands that can shut
>down the system immediately.)

I hope that's true. I'm very uncomfortable with serial probing when we really 
have no idea regarding what the device actually is.

>System is upgraded: Braille device is already configured, and no
>additional detection is needed 

Assuming that it being a braille device during the install was somehow properly 
verified by the installer itself.

>(with exception of the introduction of new rules).

And this can't be written off quite so easily. Let's say that I let my sighted 
friend borrow my computer to do the install at his place. Then he brings it 
back to me on his way somewhere else and doesn't have any extra time to hang 
around. Now I need to get my braille device up and running with no sighted 
assistance. This is a very probable scenario, and there are others.

Note, also, that even if a sighted person is around, it may well be that that 
person has no technical computer skills. So, even if sighted assistance is 
available, that doesn't mean that it's all that helpful.

>> I assume you mean that the installer would use the rules that include all of 
>> the devices (not just the non-generic ones).
>
>Yes. But in case of well made Braille devices, you know that for sure.
>No need for guesses, no need for detection nor questions.

I can't afford to have that perspective. We provide software without having any 
knowledge of the zillions of ways how and environments within which it's used. 
In other words, we need to code for the worst case, which, in this case, means 
a poorly designed USB braille device, a poorly designed other kind of device 
which looks like it might be a braille device, etc.

>> Would it be sufficient if the number is high enough to be after the rules for 
>> the other devices? We currently recommend 90. I don't know if distributions are 
>> using it or picking their own number. I also don't know if 90 is high enough.
>
>As long as there is no conflicting rule, numbers don't really matter.

But I'm assuming that this discussion is taking place because there must be 
conflicting rules.

>Most hardware devices use 65 to 90.

Should we increase our number to, say, 95?

>> This would be a problem because a braille user wouldn't be able to read the 
>> prompt until his braille device is working.
>
>Well, it would be no problem:

Really? I completely disagree.

>If a generic serial USB device that can be Braille device appears, send
>the prompt to the visual console and all generic USB serial devices, and
>read a response from visual console and all generic USB serial devices.

And how, exactly, would we write the prompt to, and read the response from, a 
braille device? They use complex protocols, and it's different for each model. 
Just because it's using a generic serial adapter doesn't mean that 
communicating with it as anywhere near as simple as merely writing/reading 
characters.

>> Yes. As mentioned above, I don't like serial probing.
>
>Me too. But serial probing is still better than random sending of serial
>data.

Which is exactly what a textual prompt would look like to a braille device - 
entirely random data.

>> How would a user specify the port, and how would we find out which port the 
>> device is on?
>
>Kernel has some support, see "lsusb -t". But it seems that udev
>currently cannot create rules "USB device with id A:B connected to
>leftmost rear port.

I don't think it'd be possible since ports are laid out in many different 
physical ways, and those ports can be connected to the motherboard in different 
ways, too. There are no standards for mapping physical placement to software 
references.

Let's consider my own computer as an example. It has two ports, side-by-side, 
near the top. About half way down it has four ports in a "square". At the 
bottom it has four ports in a row. And that's only the back. On the front it 
has a plate with two USB ports, along with a microphone and a speaker port. Up 
near the top is another plate with four more, along with card slots of various 
types.

>> This is a device that brltty creates with uinput. How can we create it 
>> differently so that it won't cause a problem?
>
>Confirming. After commenting out udev rules AND killing of brltty
>daemon, GPS can be used again.

That doesn't help me. In fact, I don't even understand why that device causes 
any problems. It's a uinput-created device that emulates a keyboard. Maybe, in 
that case, Linux is creating something like a USB HID interface to it, but 
that's well beyond our control. We write input events to it, and have no need 
for USB access.

>Some daemons use udev helpers to notify new matching devices, so the
>detection is implemented only once, by udev.

But I wouldn't even know what it's matching since, when we create it, we aren't 
able to supply any USB data.

-- 
I believe the Bible to be the very Word of God: http://Mielke.cc/bible/
Dave Mielke            | 2213 Fox Crescent | WebHome: http://Mielke.cc/
EMail: Dave at Mielke.cc  | Ottawa, Ontario   | Twitter: @Dave_Mielke
Phone: +1 613 726 0014 | Canada  K2A 1H7   |