speechd-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Maintaining speechd-up


From: Halim Sahin
Subject: Maintaining speechd-up
Date: Mon, 19 Jul 2010 17:18:06 +0200

Hi, Hynek and Bill,

@Bill:
Sbl is used here since 1999 and it has speech support since 2002.
I am using it for my complete work in the linuxconsole.
When you say it works best  only for brailleusers only this will be simply 
wrong.
I know many users they are using it in speech-only setups, and on their
netbooks.

Sure it can be improoved in some points but it has much better
attribute handling than speakup and is the only sr for using ncurses
apps.

@Hynek:
Integrating console screenreaders in such session tools is not possible!
People who push these technologies are not using screenreaders and don't
care about their needs!
There are  many problems to solve when the sr is running as root.
It doesn't improove userexperience but makes things more complex.

The facts lsof |grep -i sbl |grep "/dev"

sbl       23687       root    2r      CHR                4,0       0t0       
1508 /dev/tty0
sbl       23687       root    4r      CHR              7,128    0t4004       
1795 /dev/vcsa
sbl       23687       root    5r      CHR                4,0       0t0       
1508 /dev/tty0
one more device which is needed is /dev/console
To insert keyboard commands the /dev/input/uinput is needed as well as
other stuff from /dev/input.
/dev/tty0 and /dev/input/uinput are owned by root

Currently a console screenreader works as a root service and provides
a11y for all tty's.
If someone tries to change this it would break console login a11y,
cursor routing and other stuff.
We tried to adapt sbl to this new stuff but it was not easy and brought
up many unresolvable issues.

security is one of the big arguments of the sessionintegration group.
Well, the x-server and gdm are running with superuser rights.
If someone hacks the x-session, the console screenreader wouldn't be
the problem there :-).
I need to know useful improovments for chaning things radicaly.
It's not enough to say: "plain console logins should really go away".
Plain consolelogins are great, stable, well tested and very comfortable.

So please don't push technologies which prevents well working a11y.
BR.
Halim




reply via email to

[Prev in Thread] Current Thread [Next in Thread]