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

[Jason White <jason jasonjgw net>]

Luke Yelavich <themuso ubuntu com> wrote:
 
> I like this idea, however a couple of changes would need to be made to allow
> this to work properly: * BrlTTY would have to be extended to run in the user
> session, this means looking for configs in the user's home directory, not
> loading drivers that aren't needed, i.e Linux screen driver, setting up the
> BrlAPI socket in a user-specific directory, etc.  * BrlTTY would have to be
> loaded as part of the user session, regardless of whether a display is
> present or not, and use libudev to register itself to be notified about new
> hardware, check the new hardware, and then act accordingly if a display is
> connected. An alternative is to write a GNOME settings daemon plugin to do
> the udev monitoring side of things, then load BrlTTY when a display is
> present, and allow it to take over. The upshot of this is that the GNOME
> settings daemon plugin could then twiddle the knobs needed to bring up Orca,
> complete with Braille functionality.
>
> Udev rules could launch a process that is meant to be run as a particular
> user, but there are extra bits involved with doing that properly, such as
> making sure the process has access to the relevant pieces of session
> specific metadata set up by logind/consolekit, hense the presence of code
> that runs in the user session, and uses libudev to be notified of new
> hardware, and then acting accordingly. 

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.

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.

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