From: Greg KH <greg@kroah.com>
To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
linux-kernel@vger.kernel.org
Subject: Re: [RFC] accessibility, speakup, speech synthesis & /sys
Date: Tue, 30 Jun 2009 08:34:18 -0700 [thread overview]
Message-ID: <20090630153418.GB16038@kroah.com> (raw)
In-Reply-To: <20090630130822.GR6405@const.bordeaux.inria.fr>
On Tue, Jun 30, 2009 at 03:08:22PM +0200, Samuel Thibault wrote:
> Hello,
>
> Greg KH, le Mon 29 Jun 2009 21:18:33 -0700, a écrit :
> > > I believe there are two things:
> > >
> > > - per- harware speech synthesizer parameters (e.g. speed, pitch, etc.)
> > > - screen reading parameters (e.g. characters pronunciation, key_echo,
> > > current synthesizer being used etc.)
> > >
> > > Speech synthesizers should probably have their own device class, how
> > > should it be called? "synth"? "speech"?
> >
> > Which do you think it should?
>
> Speakup used to call them "synth", but anything else than speech could
> be synthesized, so speech may be better.
Ok.
> > > Then there are the screen reading parameters. I'd tend to think that
> > > like there are /sys/{block,firmware,fs,power}, there could be a
> > > /sys/accessibility, or even shorter, /sys/a11y? Speakup parameters
> > > could then be in /sys/a11y/speakup?
> >
> > Wouldn't these be on a "per-screen" basis?
>
> Mmm, what do you call a screen? I guess you mean
> /sys/class/vtconsole/vtcon0? It would make sense indeed.
Yes, that is what I was referring to.
> > So they would live under the screen reader device itself, not way up
> > high in the device tree.
>
> One problem is usability. That's something that users
> will often want to tune, and /sys/a11y/speakup/key_echo is
> definitely easier for the very common case of one head, than
> /sys/class/vtconsole/vtcon0/reader/speakup/key_echo :)
But as you can have multiple "screens" or readers, you really need to
set this on a per-device basis.
And just wrap all of that up in a simple userspace program if you think
users are going to want to tweak things on the devices. Don't worry
where in /sys/ things live just for user "ease-of-use" as that's not the
point for sysfs. Otherwise we would just cram everything into the root
directory so people wouldn't have to type 'cd' :)
> > Actually, you are proposing them outside of the device tree, which I
> > do not think you want at all.
>
> It depends on what you call a "device". It's probably not obvious that
> a screen reader is a device, but why not.
But it is within the kernel, so please treat it as one.
> > What specific files are you thinking you would need?
>
> There are a lot of them actually, like 20, tuning various aspects of
> reading what happens on the console.
Ok, I suggest writing them all out, as you will need to add them to
Documentation/ABI/ when the patch goes in.
thanks,
greg k-h
next prev parent reply other threads:[~2009-06-30 15:44 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-25 22:04 [RFC] accessibility, speakup, speech synthesis & /sys Samuel Thibault
2009-06-30 4:18 ` Greg KH
2009-06-30 13:08 ` Samuel Thibault
2009-06-30 15:34 ` Greg KH [this message]
2009-06-30 20:01 ` Samuel Thibault
2009-06-30 6:34 ` Pavel Machek
2009-07-01 22:19 ` Samuel Thibault
2009-07-08 9:35 ` Pavel Machek
2009-07-08 9:42 ` Samuel Thibault
2009-07-12 10:31 ` Pavel Machek
2009-07-12 14:57 ` Samuel Thibault
2009-07-14 9:52 ` Pavel Machek
2009-07-14 12:44 ` Samuel Thibault
2009-07-19 21:27 ` Pavel Machek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090630153418.GB16038@kroah.com \
--to=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
--cc=samuel.thibault@ens-lyon.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.