Re: [orca-list] "Quit screen reader" is now an unbound command

[Luke Yelavich <themuso ubuntu com>]

Hi Jason,
this is rather lengthy, as usual, reply is inline.

On Thu, Aug 22, 2013 at 08:06:18PM EST, Jason White wrote:
> As it stands, BRLTTY is now started during the boot process. If it can be
> assumed to start prior to the display manager, couldn't one establish a
> simpler mechanism: detect whether there is a Brlapi server present (i.e., a
> running BRLTTY instance), and if there is, whether it has a display attached?
> This way, BRLTTY would run system-wide as usual and the only issue would be to
> query it via the Brlapi client library - I haven't looked at whether that's
> possible as it's currently implemented.

Whilst what you propose could be done, it crosses user/system boundaries, and would violate the security 
approach that GNOME/Fedora, Ubuntu etc are taking. See my answer to the second part of your reply for a more 
indepth explanation.

> Of course, that won't help if someone connects a braille display during a
> session, thus I suppose it isn't really an adequate solution. It's also
> important to remember that BRLTTY should still provide access to console
> sessions, which requires root privileges, so I would think you would wish to
> avoid running it within a user's session.

We are moving more and more towards an environment where applications and services are run with as little 
privilege as possible, even to the point where apps are confined, and can only use pre-determined and trusted 
mechanisms and interfaces for communicating with system services. At some point, BrlTTY needs to be extended 
to work in this newer world order, and that means running one BrlTTY instance per logged in user. This is 
done now with many a service for a user session, pulseaudio being one of them. BrlTTY has no need to run as 
root, and combined with logind/consolekit, can be granted access to the hardware interfaces it wants to use.

Yes, I know there is the issue of continued access to Braille on the console, but there is a solution for 
that. Part of this solution has already been explored for Vinux 4, in that I extended speechd-up and 
consolekit to allow a non-privileged instance of speechd-up to access speakup when a user is not logged in. 
Once a user logs in, an instance of speechd-up is launched for that user session, and that instance of 
speechd-up has access to the data stream from speakup. The same thing would be done with BrlTTY. Running 
BrlTTY early could still be done, but once the boot process gets to a particular point, BrlTTY can then be 
signaled to drop privileges, and run under a specially marked consolekit/logind session, providing Braille 
access to the console at login. It should be noted that consolekit development is afaik dead upstream, so 
this will need to be re-implemented in systemd/logind going forward.

The major advantage of this approach is that it allows users to have different Braille settings. Whereas 
BrlTTY now stores one set of settings system-wide, a multi-user system could have several Braille users all 
with their own BrlTTY configurations stored in their home directory. It would also allow other useful 
additions, like being able to configure and use a bluetooth display with BrlTTY via the GNOME bluetooth 
configuration GUI. I may have it wrong, and BrlTTY may be able to store configs per user, so feel free to 
correct me if that is the case.

> As you know, there are already udev rules to invoke it at least in some
> distributions.

Indeed, and are only useful if running as root, which longer term, BrlTTY has no need for. If anything, using 
libudev would allow us to possibly further query those devices we know are also used in USB to serial 
adapters. If we received a satisfactory responce, we would then know that it is a Braille display. This is 
only a guess, since I don't know or have access to such hardware, so there may not be any init/query strings 
that could be sent to determine this.

Luke