[g-a-devel] [gdm-list] What's the Status of Audio in GDM?

Wed May 7 22:23:25 UTC 2008

Hi, Brian:

Brian Cameron writes:
> 
> Chuck:
> 
> > I've done some testing of accessibility support on GDM, specifically 
> > the screen reader and audio output, on Fedora 9.
> > 
> > On Wed, May 07, 2008 at 10:13:06AM -0400, Janina Sajka wrote:
> >> What is the plan for SoundOnLogin=true ? Is it coming back? Should I
> >> just be patient?
> > 
> > I don't know about that option, however I do have sound working on my 
> > GDM login screen.  Orca starts up automatically.

You have Orca starting during GDM? I would like to set that up. If
you're achieving it via Ctrl-S, it isn't working that way for me yet. If
some other mechanism, I'd really appreciate a pointer.

> 
> The feature was to provide 3 sounds at various points in the login
> process:
> 
> 1. When the login screen is ready for input
> 2. On failed login
> 3. On successful login
> 
Yes, yes. Just as of this morning this is also working for me on two
machines. Seems to have come on line with the push of
gnome-audio-2.22.2.

And a very elegant logo audio /usr/share/sounds/startup3.wav is! I would
venture it's the classiest yet from Gnome!

I should note, though, that it's only sounding on my laptop because I
have a spare audio device--which happens to be the third audio device.
While I can aplay -D hw:0 (or hw:1), the playing of this sound comes
over hw:2 for some reason. I'm not sure why, and that gives me the
concern that many users might miss it if something else has taken 
the only audio device available.

In my case hw:0 is taken by Speakup (the console screen reader) driving
TTSynth (http://ttsynth.com). I have to pull off a little trick to make
sure that other sounds can still play over hw:0, but I have that
covered.

A console twinkle voip phone is running over hw:1. I don't know why
startup3.wav won't play there, and would like to know, actually.

> The previous GDM allowed you to configure whether the above 3 sounds
> would be played, and allowed you to configure what soundfile would be
> played for each.
> 
> This allows users who are blind to navigate the login process without
> needing to use orca or to know how to launch orca.  Since, in the
> normal use-case, a user just enters their username and password, it
> isn't really necessary to provide full orca feedback to navigate this
> most common use-case.  Orca is really only needed if the user wants to
> navigate the GUI to do other use-cases like change the language, change
> the session, use the XDMCP chooser, etc.
> 
It's still a good idea to have Orca available. For one thing that
competing OS from the U.S. West Coast does that. For another, even
something as simple as Login, <enter> passwd, <enter> can go awry
without feedback. It has for me, and I'm pretty on top of things. Yet,
my password shows up in my logs sometimes, because, for some reason,
I've gotten out of sync. Maybe the phone rang and I inadvertently
pressed <enter> without realizing it? Now I'm entering my password in
the login field without knowing it. If Orca where there speaking, I'd be
hearing the chars echo'd, and would immediately stop typing them and
clear my entry with backspace. But, without Orca, I'm assuming, and
sometimes getting it wrong.

> However, now that GDM has the Face Browser on by default, it might
> not be possible for blind users to easily navigate the login process
> without Orca anymore.  Though perhaps a hotkey could be added to
> allow the username entry field to become available so that a blind
> user could avoid having to use the face browser.  For most blind
> users, the Face Browser is a distraction and makes the login process
> more cumbersome.
> 
> It might be reasonable to avoid supporting these sound prompts if it is
> possible for blind users to launch orca from the login screen via a
> keybinding, and if GDM works well enough with orca that a blind user can
> navigate the login screen without needing these sound prompts.
> 
> However, without the sound alerting the user when GDM is ready for
> input, a blind user would have to guess when to hit the hotkey to
> start orca, which is a bit ugly.  I can imagine if the bootup
> process had a problem, a blind user might wait a long time before
> realizing that GDM is not showing up.
> 
Exactly. we need to know to start typing--or navigating.

May I make an additional rfe in this regard? The Ctrl-S gesture requires
that one hold the combination for some period of time. My experience
when this was working for me--back with Fedora 7--was that the exact
amount of time could vary by several seconds actually. I guess it
depended on what other pids were keeping the hd busy?

So, my RFE -- Could we have a very brief sound when Ctrl-S actually
engages? So we know when it's OK to let go? Else one can hold them too
long and miss the functionality only to become frustrated.

I am thinking of something very simple an inocuous like
/usr/share/sounds/pop.wav ? From an audio interface point of view I
think this would be quite elegant and certainly functional.

Janina

> Brian
> _______________________________________________
> Gnome-accessibility-devel mailing list
> Gnome-accessibility-devel at gnome.org
> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel

-- 

Janina Sajka,	Phone:	+1.202.595.7777;	sip:janina at a11y.org
Partner, Capital Accessibility LLC	http://CapitalAccessibility.Com

Marketing the Owasys 22C talking screenless cell phone in the U.S. and Canada
Learn more at http://ScreenlessPhone.Com

Chair, Open Accessibility	janina at a11y.org	
Linux Foundation		http://a11y.org