Hi,
We have made progress on the items in TODO file of speakup driver in
staging directory and wanted to get some clarity on the remaining
items. Below is a summary of status of each item along with the quotes
from TODO file.
1. "The first issue has to do with the way speakup communicates
with serial ports. Currently, we communicate directly with the hardware
ports. This however conflicts with the standard serial port drivers,
which poses various problems. This is also not working for modern
hardware such as PCI-based serial ports. Also, there is not a way we
can communicate with USB devices. The current serial port handling
code is in serialio.c in this directory."
Drivers for all external synths now use TTY to communcate with the
devices. Only ones still using direct communication with hardware ports
are internal synths: acntpc, decpc, dtlk and keypc. These are typically
ISA cards and generally hardware which is difficult to make work. We
can leave these in staging.
2. "Some places are currently using in_atomic() because speakup
functions are called in various contexts, and a couple of things can't
happen in these cases. Pushing work to some worker thread would
probably help, as was already done for the serial port driving part."
There aren't any uses of in_atomic anymore. Commit d7500135802c
"Staging: speakup: Move pasting into a work item" was the last one that
removed such uses.
3. "There is a duplication of the selection functions in selections.c.
These functions should get exported from drivers/char/selection.c
(clear_selection notably) and used from there instead."
This is yet to be done. I guess drivers/char/selection.c is now under
drivers/tty/vt/selection.c.
4. "The kobjects may have to move to a more proper place in /sys.The
discussion on lkml resulted to putting speech synthesizers in the
"speech" class, and the speakup screen reader itself
into /sys/class/vtconsole/vtcon0/speakup, the nasty path being handled
by userland tools."
Although this makes logical sense, the change will mean changing
interface with userspace and hence the user space tools. I tried to
search the lkml discussion but couldn't find it. It will be good to
know your thoughts on this.
Finally there is an issue where text in output buffer sometimes gets
garbled on SMP systems, but we can continue working on it after the
driver is moved out of staging, if that's okay. Basically we need a
reproducer of this issue.
In addition to above, there are likely code style issues which will
need to be fixed.
We are very keen to get speakup out of staging both, for settling the
driver but also for getting included in distros which build only the
mainline drivers.
Thank you,
Okash
Okash Khawaja <[email protected]> writes:
> Finally there is an issue where text in output buffer sometimes gets
> garbled on SMP systems, but we can continue working on it after the
> driver is moved out of staging, if that's okay. Basically we need a
> reproducer of this issue.
What kind of reproducer do you need here? It's straightforward to
reproduce in casual use, at least with a software synthesizer. I don't
know whether it affects hardware synths.
-- Chris
On Fri, Mar 15, 2019 at 01:01:27PM +0000, Okash Khawaja wrote:
> Hi,
>
> We have made progress on the items in TODO file of speakup driver in
> staging directory and wanted to get some clarity on the remaining
> items. Below is a summary of status of each item along with the quotes
> from TODO file.
>
> 1. "The first issue has to do with the way speakup communicates
> with serial ports. Currently, we communicate directly with the hardware
> ports. This however conflicts with the standard serial port drivers,
> which poses various problems. This is also not working for modern
> hardware such as PCI-based serial ports. Also, there is not a way we
> can communicate with USB devices. The current serial port handling
> code is in serialio.c in this directory."
>
> Drivers for all external synths now use TTY to communcate with the
> devices. Only ones still using direct communication with hardware ports
> are internal synths: acntpc, decpc, dtlk and keypc. These are typically
> ISA cards and generally hardware which is difficult to make work. We
> can leave these in staging.
Ok, that's fine.
> 2. "Some places are currently using in_atomic() because speakup
> functions are called in various contexts, and a couple of things can't
> happen in these cases. Pushing work to some worker thread would
> probably help, as was already done for the serial port driving part."
>
> There aren't any uses of in_atomic anymore. Commit d7500135802c
> "Staging: speakup: Move pasting into a work item" was the last one that
> removed such uses.
Great, let's remove that todo item then.
> 3. "There is a duplication of the selection functions in selections.c.
> These functions should get exported from drivers/char/selection.c
> (clear_selection notably) and used from there instead."
>
> This is yet to be done. I guess drivers/char/selection.c is now under
> drivers/tty/vt/selection.c.
Yes, someone should update the todo item :)
> 4. "The kobjects may have to move to a more proper place in /sys.The
> discussion on lkml resulted to putting speech synthesizers in the
> "speech" class, and the speakup screen reader itself
> into /sys/class/vtconsole/vtcon0/speakup, the nasty path being handled
> by userland tools."
>
> Although this makes logical sense, the change will mean changing
> interface with userspace and hence the user space tools. I tried to
> search the lkml discussion but couldn't find it. It will be good to
> know your thoughts on this.
I don't remember, sorry. I can review the kobject/sysfs usage if you
think it is "good enough" now and see if I find anything objectionable.
> Finally there is an issue where text in output buffer sometimes gets
> garbled on SMP systems, but we can continue working on it after the
> driver is moved out of staging, if that's okay. Basically we need a
> reproducer of this issue.
>
> In addition to above, there are likely code style issues which will
> need to be fixed.
>
> We are very keen to get speakup out of staging both, for settling the
> driver but also for getting included in distros which build only the
> mainline drivers.
That's great, I am glad to see this happen. How about work on the
selection thing and then I can review the kobject stuff in a few weeks,
and then we can start moving things for 5.2?
thanks,
greg k-h
Chris Brannon, le ven. 15 mars 2019 18:19:39 -0700, a ecrit:
> Okash Khawaja <[email protected]> writes:
> > Finally there is an issue where text in output buffer sometimes gets
> > garbled on SMP systems, but we can continue working on it after the
> > driver is moved out of staging, if that's okay. Basically we need a
> > reproducer of this issue.
>
> What kind of reproducer do you need here? It's straightforward to
> reproduce in casual use, at least with a software synthesizer.
The problem is that neither Okash nor I are even casual users of
speakup, so we need a walk-through of the kind of operation that
produces the issue. It does not have to be reproducible each time it is
done. Perhaps (I really don't know what that bug is about actually) it
is a matter of putting text in the selection buffer, and try to paste it
100 times, and once every 10 times it will be garbled, for instance.
Samuel
Hi,
On Fri, 15 Mar 2019 18:19:39 -0700
Chris Brannon <[email protected]> wrote:
> Okash Khawaja <[email protected]> writes:
>
> > Finally there is an issue where text in output buffer sometimes gets
> > garbled on SMP systems, but we can continue working on it after the
> > driver is moved out of staging, if that's okay. Basically we need a
> > reproducer of this issue.
>
> What kind of reproducer do you need here? It's straightforward to
> reproduce in casual use, at least with a software synthesizer. I
> don't know whether it affects hardware synths.
I meant if we can reproduce it at will. Then we will be very close to
the root cause of the race which is what it seems like.
Btw I haven't started investigating it yet.
Thanks,
Okash
On Fri, 15 Mar 2019 20:18:31 -0700
Greg Kroah-Hartman <[email protected]> wrote:
> On Fri, Mar 15, 2019 at 01:01:27PM +0000, Okash Khawaja wrote:
> > Hi,
> >
> > We have made progress on the items in TODO file of speakup driver in
> > staging directory and wanted to get some clarity on the remaining
> > items. Below is a summary of status of each item along with the
> > quotes from TODO file.
> >
> > 1. "The first issue has to do with the way speakup communicates
> > with serial ports. Currently, we communicate directly with the
> > hardware ports. This however conflicts with the standard serial
> > port drivers, which poses various problems. This is also not
> > working for modern hardware such as PCI-based serial ports. Also,
> > there is not a way we can communicate with USB devices. The
> > current serial port handling code is in serialio.c in this
> > directory."
> >
> > Drivers for all external synths now use TTY to communcate with the
> > devices. Only ones still using direct communication with hardware
> > ports are internal synths: acntpc, decpc, dtlk and keypc. These are
> > typically ISA cards and generally hardware which is difficult to
> > make work. We can leave these in staging.
>
> Ok, that's fine.
>
> > 2. "Some places are currently using in_atomic() because speakup
> > functions are called in various contexts, and a couple of things
> > can't happen in these cases. Pushing work to some worker thread
> > would probably help, as was already done for the serial port
> > driving part."
> >
> > There aren't any uses of in_atomic anymore. Commit d7500135802c
> > "Staging: speakup: Move pasting into a work item" was the last one
> > that removed such uses.
>
> Great, let's remove that todo item then.
>
> > 3. "There is a duplication of the selection functions in
> > selections.c. These functions should get exported from
> > drivers/char/selection.c (clear_selection notably) and used from
> > there instead."
> >
> > This is yet to be done. I guess drivers/char/selection.c is now
> > under drivers/tty/vt/selection.c.
>
> Yes, someone should update the todo item :)
>
> > 4. "The kobjects may have to move to a more proper place in /sys.The
> > discussion on lkml resulted to putting speech synthesizers in the
> > "speech" class, and the speakup screen reader itself
> > into /sys/class/vtconsole/vtcon0/speakup, the nasty path being
> > handled by userland tools."
> >
> > Although this makes logical sense, the change will mean changing
> > interface with userspace and hence the user space tools. I tried to
> > search the lkml discussion but couldn't find it. It will be good to
> > know your thoughts on this.
>
> I don't remember, sorry. I can review the kobject/sysfs usage if you
> think it is "good enough" now and see if I find anything
> objectionable.
>
> > Finally there is an issue where text in output buffer sometimes gets
> > garbled on SMP systems, but we can continue working on it after the
> > driver is moved out of staging, if that's okay. Basically we need a
> > reproducer of this issue.
> >
> > In addition to above, there are likely code style issues which will
> > need to be fixed.
> >
> > We are very keen to get speakup out of staging both, for settling
> > the driver but also for getting included in distros which build
> > only the mainline drivers.
>
> That's great, I am glad to see this happen. How about work on the
> selection thing and then I can review the kobject stuff in a few
> weeks, and then we can start moving things for 5.2?
Perfect. I'll start looking into selection refactor now.
Thanks very much!
Okash
Hello,
Please keep the lists in Cc, so that not only I have the information
(in particular since I will probably *not* have the time to investigate
myself).
Samuel Thibault, le sam. 16 mars 2019 10:35:43 +0100, a ecrit:
> The problem is that neither Okash nor I are even casual users of
> speakup, so we need a walk-through of the kind of operation that
> produces the issue.
deedra Waters <[email protected]> wrote:
> it's dead simple
For a user, perhaps, but again, neither Okash or I are actual users of
speakup, so we have just no idea what casual use is.
> just lead the screenreader read large blocks of text i guarantee it's
> reproduceable.
Which shortcut do you use to make the screen reader read it? What is
"large"? Is that only one 80x25 complete output screen? Is that cat-ing
a long text? How is it garbled: is that right from the beginning of the
text? or at some point during it? or is that just a piece of it and then
it's Ok again?
Samuel
On Sat, 16 Mar 2019 10:35:43 +0100
Samuel Thibault <[email protected]> wrote:
> Chris Brannon, le ven. 15 mars 2019 18:19:39 -0700, a ecrit:
> > Okash Khawaja <[email protected]> writes:
> > > Finally there is an issue where text in output buffer sometimes gets
> > > garbled on SMP systems, but we can continue working on it after the
> > > driver is moved out of staging, if that's okay. Basically we need a
> > > reproducer of this issue.
> >
> > What kind of reproducer do you need here? It's straightforward to
> > reproduce in casual use, at least with a software synthesizer.
>
> The problem is that neither Okash nor I are even casual users of
> speakup, so we need a walk-through of the kind of operation that
> produces the issue. It does not have to be reproducible each time it is
> done. Perhaps (I really don't know what that bug is about actually) it
> is a matter of putting text in the selection buffer, and try to paste it
> 100 times, and once every 10 times it will be garbled, for instance.
paste_selection still says
/* Insert the contents of the selection buffer into the
* queue of the tty associated with the current console.
* Invoked by ioctl().
*
* Locking: called without locks. Calls the ldisc wrongly with
* unsafe methods,
*/
from which I deduce that with everyone using X nobody ever bothered to
fix it. So before you look too hard at the speakup code you might want to
review the interaction with selection.c too.
Alan
Alan Cox, le mar. 19 mars 2019 16:31:21 +0000, a ecrit:
> On Sat, 16 Mar 2019 10:35:43 +0100
> Samuel Thibault <[email protected]> wrote:
> > Chris Brannon, le ven. 15 mars 2019 18:19:39 -0700, a ecrit:
> > > Okash Khawaja <[email protected]> writes:
> > > > Finally there is an issue where text in output buffer sometimes gets
> > > > garbled on SMP systems, but we can continue working on it after the
> > > > driver is moved out of staging, if that's okay. Basically we need a
> > > > reproducer of this issue.
> > >
> > > What kind of reproducer do you need here? It's straightforward to
> > > reproduce in casual use, at least with a software synthesizer.
> >
> > The problem is that neither Okash nor I are even casual users of
> > speakup, so we need a walk-through of the kind of operation that
> > produces the issue. It does not have to be reproducible each time it is
> > done. Perhaps (I really don't know what that bug is about actually) it
> > is a matter of putting text in the selection buffer, and try to paste it
> > 100 times, and once every 10 times it will be garbled, for instance.
>
> paste_selection still says
The issue is not actually with pasting a selection, just plain text
output from applications.
Samuel
On Tue, Mar 19, 2019 at 04:31:21PM +0000, Alan Cox wrote:
> On Sat, 16 Mar 2019 10:35:43 +0100
> Samuel Thibault <[email protected]> wrote:
> > Chris Brannon, le ven. 15 mars 2019 18:19:39 -0700, a ecrit:
> > > What kind of reproducer do you need here? It's straightforward to
> > > reproduce in casual use, at least with a software synthesizer.
> >
> > we need a walk-through of the kind of operation that
> > produces the issue. It does not have to be reproducible each time it is
> > done. Perhaps (I really don't know what that bug is about actually) it
> > is a matter of putting text in the selection buffer, and try to paste it
> > 100 times, and once every 10 times it will be garbled, for instance.
>
> paste_selection still says
>
> /* Insert the contents of the selection buffer into the
> * queue of the tty associated with the current console.
> * Invoked by ioctl().
> *
> * Locking: called without locks. Calls the ldisc wrongly with
> * unsafe methods,
> */
>
> from which I deduce that with everyone using X nobody ever bothered to
> fix it. So before you look too hard at the speakup code you might want to
> review the interaction with selection.c too.
This looks like https://bugs.debian.org/849474 which causes a lockup, and
for which Bill Allombert wrote a nice reproducer.
Meow!
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Did ya know that typing "test -j8" instead of "ctest -j8"
⢿⡄⠘⠷⠚⠋⠀ will make your testsuite pass much faster, and fix bugs?
⠈⠳⣄⠀⠀⠀⠀
On Tue, 19 Mar 2019 16:31:21 +0000
Alan Cox <[email protected]> wrote:
> On Sat, 16 Mar 2019 10:35:43 +0100
> Samuel Thibault <[email protected]> wrote:
>
> > Chris Brannon, le ven. 15 mars 2019 18:19:39 -0700, a ecrit:
> > > Okash Khawaja <[email protected]> writes:
> > > > Finally there is an issue where text in output buffer sometimes
> > > > gets garbled on SMP systems, but we can continue working on it
> > > > after the driver is moved out of staging, if that's okay.
> > > > Basically we need a reproducer of this issue.
> > >
> > > What kind of reproducer do you need here? It's straightforward to
> > > reproduce in casual use, at least with a software synthesizer.
> >
> > The problem is that neither Okash nor I are even casual users of
> > speakup, so we need a walk-through of the kind of operation that
> > produces the issue. It does not have to be reproducible each time
> > it is done. Perhaps (I really don't know what that bug is about
> > actually) it is a matter of putting text in the selection buffer,
> > and try to paste it 100 times, and once every 10 times it will be
> > garbled, for instance.
>
> paste_selection still says
>
> /* Insert the contents of the selection buffer into the
> * queue of the tty associated with the current console.
> * Invoked by ioctl().
> *
> * Locking: called without locks. Calls the ldisc wrongly with
> * unsafe methods,
> */
>
> from which I deduce that with everyone using X nobody ever bothered to
> fix it. So before you look too hard at the speakup code you might
> want to review the interaction with selection.c too.
Hi,
This is a good point. At the moment speakup uses its own set of
selection and paste functions but I am in process of changing speakup
to use these functions from drivers/tty/vt/selection.c instead. This
lack of locking will be worth watching out for.
Thanks!
Okash
On Fri, 15 Mar 2019 20:18:31 -0700
Greg Kroah-Hartman <[email protected]> wrote:
> On Fri, Mar 15, 2019 at 01:01:27PM +0000, Okash Khawaja wrote:
> > Hi,
> >
> > We have made progress on the items in TODO file of speakup driver in
> > staging directory and wanted to get some clarity on the remaining
> > items. Below is a summary of status of each item along with the
> > quotes from TODO file.
> >
> > 1. "The first issue has to do with the way speakup communicates
> > with serial ports. Currently, we communicate directly with the
> > hardware ports. This however conflicts with the standard serial
> > port drivers, which poses various problems. This is also not
> > working for modern hardware such as PCI-based serial ports. Also,
> > there is not a way we can communicate with USB devices. The
> > current serial port handling code is in serialio.c in this
> > directory."
> >
> > Drivers for all external synths now use TTY to communcate with the
> > devices. Only ones still using direct communication with hardware
> > ports are internal synths: acntpc, decpc, dtlk and keypc. These are
> > typically ISA cards and generally hardware which is difficult to
> > make work. We can leave these in staging.
>
> Ok, that's fine.
>
> > 2. "Some places are currently using in_atomic() because speakup
> > functions are called in various contexts, and a couple of things
> > can't happen in these cases. Pushing work to some worker thread
> > would probably help, as was already done for the serial port
> > driving part."
> >
> > There aren't any uses of in_atomic anymore. Commit d7500135802c
> > "Staging: speakup: Move pasting into a work item" was the last one
> > that removed such uses.
>
> Great, let's remove that todo item then.
>
> > 3. "There is a duplication of the selection functions in
> > selections.c. These functions should get exported from
> > drivers/char/selection.c (clear_selection notably) and used from
> > there instead."
> >
> > This is yet to be done. I guess drivers/char/selection.c is now
> > under drivers/tty/vt/selection.c.
>
> Yes, someone should update the todo item :)
>
> > 4. "The kobjects may have to move to a more proper place in /sys.The
> > discussion on lkml resulted to putting speech synthesizers in the
> > "speech" class, and the speakup screen reader itself
> > into /sys/class/vtconsole/vtcon0/speakup, the nasty path being
> > handled by userland tools."
> >
> > Although this makes logical sense, the change will mean changing
> > interface with userspace and hence the user space tools. I tried to
> > search the lkml discussion but couldn't find it. It will be good to
> > know your thoughts on this.
>
> I don't remember, sorry. I can review the kobject/sysfs usage if you
> think it is "good enough" now and see if I find anything
> objectionable.
>
> > Finally there is an issue where text in output buffer sometimes gets
> > garbled on SMP systems, but we can continue working on it after the
> > driver is moved out of staging, if that's okay. Basically we need a
> > reproducer of this issue.
> >
> > In addition to above, there are likely code style issues which will
> > need to be fixed.
> >
> > We are very keen to get speakup out of staging both, for settling
> > the driver but also for getting included in distros which build
> > only the mainline drivers.
>
> That's great, I am glad to see this happen. How about work on the
> selection thing and then I can review the kobject stuff in a few
> weeks, and then we can start moving things for 5.2?
Hi Greg,
Apologies for the delay. I de-duplicated selection code in speakup to
use code that's already in kernel (commit ids 496124e5e16e and
41f13084506a). Following items are what remain now:
1. moving kobjects location
2. fixing garbled text
I couldn't replicate garbled text but Simon (also in CC list) is
looking into it.
Can you please advise on the way forward?
Thanks,
Okash
On Sat, Jul 06, 2019 at 08:08:57PM +0100, Okash Khawaja wrote:
> On Fri, 15 Mar 2019 20:18:31 -0700
> Greg Kroah-Hartman <[email protected]> wrote:
>
> > On Fri, Mar 15, 2019 at 01:01:27PM +0000, Okash Khawaja wrote:
> > > Hi,
> > >
> > > We have made progress on the items in TODO file of speakup driver in
> > > staging directory and wanted to get some clarity on the remaining
> > > items. Below is a summary of status of each item along with the
> > > quotes from TODO file.
> > >
> > > 1. "The first issue has to do with the way speakup communicates
> > > with serial ports. Currently, we communicate directly with the
> > > hardware ports. This however conflicts with the standard serial
> > > port drivers, which poses various problems. This is also not
> > > working for modern hardware such as PCI-based serial ports. Also,
> > > there is not a way we can communicate with USB devices. The
> > > current serial port handling code is in serialio.c in this
> > > directory."
> > >
> > > Drivers for all external synths now use TTY to communcate with the
> > > devices. Only ones still using direct communication with hardware
> > > ports are internal synths: acntpc, decpc, dtlk and keypc. These are
> > > typically ISA cards and generally hardware which is difficult to
> > > make work. We can leave these in staging.
> >
> > Ok, that's fine.
> >
> > > 2. "Some places are currently using in_atomic() because speakup
> > > functions are called in various contexts, and a couple of things
> > > can't happen in these cases. Pushing work to some worker thread
> > > would probably help, as was already done for the serial port
> > > driving part."
> > >
> > > There aren't any uses of in_atomic anymore. Commit d7500135802c
> > > "Staging: speakup: Move pasting into a work item" was the last one
> > > that removed such uses.
> >
> > Great, let's remove that todo item then.
> >
> > > 3. "There is a duplication of the selection functions in
> > > selections.c. These functions should get exported from
> > > drivers/char/selection.c (clear_selection notably) and used from
> > > there instead."
> > >
> > > This is yet to be done. I guess drivers/char/selection.c is now
> > > under drivers/tty/vt/selection.c.
> >
> > Yes, someone should update the todo item :)
> >
> > > 4. "The kobjects may have to move to a more proper place in /sys.The
> > > discussion on lkml resulted to putting speech synthesizers in the
> > > "speech" class, and the speakup screen reader itself
> > > into /sys/class/vtconsole/vtcon0/speakup, the nasty path being
> > > handled by userland tools."
> > >
> > > Although this makes logical sense, the change will mean changing
> > > interface with userspace and hence the user space tools. I tried to
> > > search the lkml discussion but couldn't find it. It will be good to
> > > know your thoughts on this.
> >
> > I don't remember, sorry. I can review the kobject/sysfs usage if you
> > think it is "good enough" now and see if I find anything
> > objectionable.
> >
> > > Finally there is an issue where text in output buffer sometimes gets
> > > garbled on SMP systems, but we can continue working on it after the
> > > driver is moved out of staging, if that's okay. Basically we need a
> > > reproducer of this issue.
> > >
> > > In addition to above, there are likely code style issues which will
> > > need to be fixed.
> > >
> > > We are very keen to get speakup out of staging both, for settling
> > > the driver but also for getting included in distros which build
> > > only the mainline drivers.
> >
> > That's great, I am glad to see this happen. How about work on the
> > selection thing and then I can review the kobject stuff in a few
> > weeks, and then we can start moving things for 5.2?
>
> Hi Greg,
>
> Apologies for the delay. I de-duplicated selection code in speakup to
> use code that's already in kernel (commit ids 496124e5e16e and
> 41f13084506a). Following items are what remain now:
>
> 1. moving kobjects location
> 2. fixing garbled text
>
> I couldn't replicate garbled text but Simon (also in CC list) is
> looking into it.
>
> Can you please advise on the way forward?
I don't think the "garbled text" is an issue to get this out of staging
if others do not see this. It can be fixed like any other bug at a
later point if it is figured out.
The kobject stuff does need to be looked at. Let me carve out some time
next week to do that and I will let you know what I see/recommend.
thanks,
greg k-h
On Sun, Jul 07, 2019 at 08:57:10AM +0200, Greg Kroah-Hartman wrote:
> On Sat, Jul 06, 2019 at 08:08:57PM +0100, Okash Khawaja wrote:
> > On Fri, 15 Mar 2019 20:18:31 -0700
> > Greg Kroah-Hartman <[email protected]> wrote:
> >
> > > On Fri, Mar 15, 2019 at 01:01:27PM +0000, Okash Khawaja wrote:
> > > > Hi,
> > > >
> > > > We have made progress on the items in TODO file of speakup driver in
> > > > staging directory and wanted to get some clarity on the remaining
> > > > items. Below is a summary of status of each item along with the
> > > > quotes from TODO file.
> > > >
> > > > 1. "The first issue has to do with the way speakup communicates
> > > > with serial ports. Currently, we communicate directly with the
> > > > hardware ports. This however conflicts with the standard serial
> > > > port drivers, which poses various problems. This is also not
> > > > working for modern hardware such as PCI-based serial ports. Also,
> > > > there is not a way we can communicate with USB devices. The
> > > > current serial port handling code is in serialio.c in this
> > > > directory."
> > > >
> > > > Drivers for all external synths now use TTY to communcate with the
> > > > devices. Only ones still using direct communication with hardware
> > > > ports are internal synths: acntpc, decpc, dtlk and keypc. These are
> > > > typically ISA cards and generally hardware which is difficult to
> > > > make work. We can leave these in staging.
> > >
> > > Ok, that's fine.
> > >
> > > > 2. "Some places are currently using in_atomic() because speakup
> > > > functions are called in various contexts, and a couple of things
> > > > can't happen in these cases. Pushing work to some worker thread
> > > > would probably help, as was already done for the serial port
> > > > driving part."
> > > >
> > > > There aren't any uses of in_atomic anymore. Commit d7500135802c
> > > > "Staging: speakup: Move pasting into a work item" was the last one
> > > > that removed such uses.
> > >
> > > Great, let's remove that todo item then.
> > >
> > > > 3. "There is a duplication of the selection functions in
> > > > selections.c. These functions should get exported from
> > > > drivers/char/selection.c (clear_selection notably) and used from
> > > > there instead."
> > > >
> > > > This is yet to be done. I guess drivers/char/selection.c is now
> > > > under drivers/tty/vt/selection.c.
> > >
> > > Yes, someone should update the todo item :)
> > >
> > > > 4. "The kobjects may have to move to a more proper place in /sys.The
> > > > discussion on lkml resulted to putting speech synthesizers in the
> > > > "speech" class, and the speakup screen reader itself
> > > > into /sys/class/vtconsole/vtcon0/speakup, the nasty path being
> > > > handled by userland tools."
> > > >
> > > > Although this makes logical sense, the change will mean changing
> > > > interface with userspace and hence the user space tools. I tried to
> > > > search the lkml discussion but couldn't find it. It will be good to
> > > > know your thoughts on this.
> > >
> > > I don't remember, sorry. I can review the kobject/sysfs usage if you
> > > think it is "good enough" now and see if I find anything
> > > objectionable.
> > >
> > > > Finally there is an issue where text in output buffer sometimes gets
> > > > garbled on SMP systems, but we can continue working on it after the
> > > > driver is moved out of staging, if that's okay. Basically we need a
> > > > reproducer of this issue.
> > > >
> > > > In addition to above, there are likely code style issues which will
> > > > need to be fixed.
> > > >
> > > > We are very keen to get speakup out of staging both, for settling
> > > > the driver but also for getting included in distros which build
> > > > only the mainline drivers.
> > >
> > > That's great, I am glad to see this happen. How about work on the
> > > selection thing and then I can review the kobject stuff in a few
> > > weeks, and then we can start moving things for 5.2?
> >
> > Hi Greg,
> >
> > Apologies for the delay. I de-duplicated selection code in speakup to
> > use code that's already in kernel (commit ids 496124e5e16e and
> > 41f13084506a). Following items are what remain now:
> >
> > 1. moving kobjects location
> > 2. fixing garbled text
> >
> > I couldn't replicate garbled text but Simon (also in CC list) is
> > looking into it.
> >
> > Can you please advise on the way forward?
>
> I don't think the "garbled text" is an issue to get this out of staging
> if others do not see this. It can be fixed like any other bug at a
> later point if it is figured out.
>
> The kobject stuff does need to be looked at. Let me carve out some time
> next week to do that and I will let you know what I see/recommend.
At first glance, this might all be just fine.
But, I can't quite figure out what some files are doing. No matter
what, you will need Documentation/ABI/ entries for the speakup code for
these sysfs files.
Can you make up a patch to create a
drivers/staging/speakup/sysfs-speakup file with the needed information?
That way it will be much easier to determine exactly what these sysfs
files do and my review can be easier, and perhaps not needed at all :)
thanks,
greg k-h
Hello,
To readers of the linux-speakup: could you help on this so we can get
Speakup in mainline? Neither Okash or I completely know what user
consequences the files in /sys/accessibility/speakup/ have, so could
people give brief explanations for each file (something like 3-6 lines
of explanation)?
The i18n/ files have been already documented in section 14.1 of the
spkguide.txt, so we do not need help for them.
Thanks!
Samuel
Greg KH, le ven. 12 juil. 2019 10:38:19 +0200, a ecrit:
> Can you make up a patch to create a
> drivers/staging/speakup/sysfs-speakup file with the needed information?
> That way it will be much easier to determine exactly what these sysfs
> files do and my review can be easier, and perhaps not needed at all :)
On Fri, Jul 12, 2019 at 9:38 AM Greg Kroah-Hartman
<[email protected]> wrote:
>
> On Sun, Jul 07, 2019 at 08:57:10AM +0200, Greg Kroah-Hartman wrote:
> > On Sat, Jul 06, 2019 at 08:08:57PM +0100, Okash Khawaja wrote:
> > > On Fri, 15 Mar 2019 20:18:31 -0700
> > > Greg Kroah-Hartman <[email protected]> wrote:
> > >
> > > > On Fri, Mar 15, 2019 at 01:01:27PM +0000, Okash Khawaja wrote:
> > > > > Hi,
> > > > >
> > > > > We have made progress on the items in TODO file of speakup driver in
> > > > > staging directory and wanted to get some clarity on the remaining
> > > > > items. Below is a summary of status of each item along with the
> > > > > quotes from TODO file.
> > > > >
> > > > > 1. "The first issue has to do with the way speakup communicates
> > > > > with serial ports. Currently, we communicate directly with the
> > > > > hardware ports. This however conflicts with the standard serial
> > > > > port drivers, which poses various problems. This is also not
> > > > > working for modern hardware such as PCI-based serial ports. Also,
> > > > > there is not a way we can communicate with USB devices. The
> > > > > current serial port handling code is in serialio.c in this
> > > > > directory."
> > > > >
> > > > > Drivers for all external synths now use TTY to communcate with the
> > > > > devices. Only ones still using direct communication with hardware
> > > > > ports are internal synths: acntpc, decpc, dtlk and keypc. These are
> > > > > typically ISA cards and generally hardware which is difficult to
> > > > > make work. We can leave these in staging.
> > > >
> > > > Ok, that's fine.
> > > >
> > > > > 2. "Some places are currently using in_atomic() because speakup
> > > > > functions are called in various contexts, and a couple of things
> > > > > can't happen in these cases. Pushing work to some worker thread
> > > > > would probably help, as was already done for the serial port
> > > > > driving part."
> > > > >
> > > > > There aren't any uses of in_atomic anymore. Commit d7500135802c
> > > > > "Staging: speakup: Move pasting into a work item" was the last one
> > > > > that removed such uses.
> > > >
> > > > Great, let's remove that todo item then.
> > > >
> > > > > 3. "There is a duplication of the selection functions in
> > > > > selections.c. These functions should get exported from
> > > > > drivers/char/selection.c (clear_selection notably) and used from
> > > > > there instead."
> > > > >
> > > > > This is yet to be done. I guess drivers/char/selection.c is now
> > > > > under drivers/tty/vt/selection.c.
> > > >
> > > > Yes, someone should update the todo item :)
> > > >
> > > > > 4. "The kobjects may have to move to a more proper place in /sys.The
> > > > > discussion on lkml resulted to putting speech synthesizers in the
> > > > > "speech" class, and the speakup screen reader itself
> > > > > into /sys/class/vtconsole/vtcon0/speakup, the nasty path being
> > > > > handled by userland tools."
> > > > >
> > > > > Although this makes logical sense, the change will mean changing
> > > > > interface with userspace and hence the user space tools. I tried to
> > > > > search the lkml discussion but couldn't find it. It will be good to
> > > > > know your thoughts on this.
> > > >
> > > > I don't remember, sorry. I can review the kobject/sysfs usage if you
> > > > think it is "good enough" now and see if I find anything
> > > > objectionable.
> > > >
> > > > > Finally there is an issue where text in output buffer sometimes gets
> > > > > garbled on SMP systems, but we can continue working on it after the
> > > > > driver is moved out of staging, if that's okay. Basically we need a
> > > > > reproducer of this issue.
> > > > >
> > > > > In addition to above, there are likely code style issues which will
> > > > > need to be fixed.
> > > > >
> > > > > We are very keen to get speakup out of staging both, for settling
> > > > > the driver but also for getting included in distros which build
> > > > > only the mainline drivers.
> > > >
> > > > That's great, I am glad to see this happen. How about work on the
> > > > selection thing and then I can review the kobject stuff in a few
> > > > weeks, and then we can start moving things for 5.2?
> > >
> > > Hi Greg,
> > >
> > > Apologies for the delay. I de-duplicated selection code in speakup to
> > > use code that's already in kernel (commit ids 496124e5e16e and
> > > 41f13084506a). Following items are what remain now:
> > >
> > > 1. moving kobjects location
> > > 2. fixing garbled text
> > >
> > > I couldn't replicate garbled text but Simon (also in CC list) is
> > > looking into it.
> > >
> > > Can you please advise on the way forward?
> >
> > I don't think the "garbled text" is an issue to get this out of staging
> > if others do not see this. It can be fixed like any other bug at a
> > later point if it is figured out.
> >
> > The kobject stuff does need to be looked at. Let me carve out some time
> > next week to do that and I will let you know what I see/recommend.
>
> At first glance, this might all be just fine.
>
> But, I can't quite figure out what some files are doing. No matter
> what, you will need Documentation/ABI/ entries for the speakup code for
> these sysfs files.
>
> Can you make up a patch to create a
> drivers/staging/speakup/sysfs-speakup file with the needed information?
> That way it will be much easier to determine exactly what these sysfs
> files do and my review can be easier, and perhaps not needed at all :)
Thanks for looking into this. I agree these descriptions will
generally be helpful for future also.
Will get back to you once it's done.
Okash
On Fri, Jul 12, 2019 at 11:23:19AM +0200, Samuel Thibault wrote:
> Hello,
>
> To readers of the linux-speakup: could you help on this so we can get
> Speakup in mainline? Neither Okash or I completely know what user
> consequences the files in /sys/accessibility/speakup/ have, so could
> people give brief explanations for each file (something like 3-6 lines
> of explanation)?
I have a recollection of documenting most of this on the speakup list
in response to a similar query a number of years ago. Unfortunately,
the speakup mailing list archives aren't easily searchable, and I
don't have a local copy of that mail.
Kirk, doing grep with a few of the file names in
/sys/accessibility/speakup against the list's mbox file archive should
find that message if it's in fact there. If you can please find it,
and post the date when it was sent, we can provide a URL to that
thread as a starting point. If my recollection is wrong, and such a
message isn't in the archives, I'll write up what I know about.
Greg
--
web site: http://www.gregn.net
gpg public key: http://www.gregn.net/pubkey.asc
skype: gregn1
(authorization required, add me to your contacts list first)
If we haven't been in touch before, e-mail me before adding me to your contacts.
--
Free domains: http://www.eu.org/ or mail [email protected]
Gregory Nowak <[email protected]> writes:
> keymap
> I believe this is the currently active kernel keymap. I'm not sure of
> the format, probably what dumpkeys(1) and showkey(1) use. Echoing
> different values here should allow for remapping speakup's review
> commands besides remapping the keyboard as a whole.
AFAIK the Speakup keymap is just for remapping keys to Speakup
functions. It's a binary format, not related to dumpkeys etc. You need
a special program to compile a textual keymap into something that can be
loaded into /sys/accessibility/speakup/keymap. I may have source for
that lying around here somewhere. This is "here there be dragons"
territory. I think the only specification of the format is in the
source code.
-- Chris
Hi,
I have added a few things inline in Greg's message, mainly regarding the
bleeps and cursor_time.
FWIW, Willem
On Wed, 24 Jul 2019, Gregory Nowak wrote:
> [The e-mail server of the sender could not be verified (SPF Record)]
>
> On Fri, Jul 12, 2019 at 05:46:23PM -0700, Gregory Nowak wrote:
>> On Fri, Jul 12, 2019 at 11:23:19AM +0200, Samuel Thibault wrote:
>>> Hello,
>>>
>>> To readers of the linux-speakup: could you help on this so we can get
>>> Speakup in mainline? Neither Okash or I completely know what user
>>> consequences the files in /sys/accessibility/speakup/ have, so could
>>> people give brief explanations for each file (something like 3-6 lines
>>> of explanation)?
>>
>> I have a recollection of documenting most of this on the speakup list
>> in response to a similar query a number of years ago. Unfortunately,
>> the speakup mailing list archives aren't easily searchable, and I
>> don't have a local copy of that mail.
>>
>> Kirk, doing grep with a few of the file names in
>> /sys/accessibility/speakup against the list's mbox file archive should
>> find that message if it's in fact there. If you can please find it,
>> and post the date when it was sent, we can provide a URL to that
>> thread as a starting point. If my recollection is wrong, and such a
>> message isn't in the archives, I'll write up what I know about.
>
> I've located the message I was thinking of in the archives, but that
> describes some speakup key commands, not
> /sys/accessibility/speakup. So, here's what I know, and hopefully
> someone else can fill in the rest.
>
> attrib_bleep
> Beeps the PC speaker when there is an attribute change such as
> foreground or background color when using speakup review commands. One
> = on, zero = off. I'm not currently at a machine with a working PC
> speaker, so can't test this right now.
>
> bell_pos
> As far as I know, this works much like a typewriter bell. If for
> example 72 is echoed to bell_pos, it will beep the PC speaker when
> typing on a line past character 72. Again, no PC speaker at the moment
> here, so can't actually test this.
Yes, it works as you say, a verry short beep happens at the echoed
position.
>
> bleeps
> Not 100% sure, but I believe this controls whether one hears beeps
> through the PC speaker when using speakup's review commands. If no one
> jumps in on this, I'll experiment when at a machine with a working PC
> speaker, and will reply back with details.
>
Yes, when 0 is echoed to /sys/accessibility/speakup/bleeps, review beeps
stop. the default seem to be 3, so I suppose it controls more than just on
or off. When set to zero, the bell still sounds when, e.g. in a terminal
at a bash prompt, one press backspace.
> bleep_time
> Again, not 100% sure, but I believe this controls the duration of the
> PC speaker beeps speakup produces. I'm not sure of the units this is
> in either, possibly jiffys. I'll come back with more details on this
> one if no one else does.
Yes, it seems to control the time as you say, verry small units though.
It was 30 and I could set it to 180, but not 360. At 180, the bleeps are
clearly a little longer, but not much.
>
> cursor_time
> Don't know.
As far as I know, one can set cursor_time to a higher value when working
e.g. over a slow connection.
When a connection is very slow, with the default setting, when moving with
the arrows, or backspacing etc. speakup says the incorrect characters.
I am not 100% sure though, but seem to recall having used such a setting
in the past when working over dialup.
>
> delimiters
> Don't know. I've tried echoing various characters to this and looking
> for differences when reviewing the screen, but no luck.
>
> ex_num
> Don't know.
>
> key_echo
> Controls if speakup speaks keys when they are typed. One = on, zero =
> off or don't echo keys.
>
> keymap
> I believe this is the currently active kernel keymap. I'm not sure of
> the format, probably what dumpkeys(1) and showkey(1) use. Echoing
> different values here should allow for remapping speakup's review
> commands besides remapping the keyboard as a whole.
>
> no_interrupt
> Controls if typing interrupts output from speakup. With no_interrupt
> set to zero, typing on the keyboard will interrupt speakup if for
> example the say screen command is used before the entire screen is
> read. With no_interrupt set to one, if the say screen command is used,
> and one then types on the keyboard, speakup will continue to say the
> whole screen regardless until it finishes.
>
> punc_all
> This is a list of all the punctuation speakup should speak when
> punc_level is set to four.
>
> punc_level
> Controls the level of punctuation spoken as the screen is displayed,
> not reviewed. Levels range from zero no punctuation, to four, all
> punctuation. As far as I can tell, one corresponds to punc_some, two
> corresponds to punc_most, and three as well as four seem to both
> correspond to punc_all, though I do stand to be corrected. I am using
> the soft synthesizer driver, so it is possible that some hardware
> synthesizers have different levels each corresponding to three and four
> for punc_level. Also note that if punc_level is set to zero, and
> key_echo is set to one, typed punctuation is still spoken as it is
> typed.
>
> punc_most
> This is a list of all the punctuation speakup should speak when
> punc_level is set to two.
>
> punc_some
> This is a list of all the punctuation speakup should speak when
> punc_level is set to one.
>
> reading_punc
> Almost the same as punc_level, the differences being that reading_punc controls
> the level of punctuation when reviewing the screen with speakup's
> screen review commands. The other difference is that reading_punc set
> to three speaks punc_all, and reading_punc set to four speaks all
> punctuation, including spaces.
>
> repeats
> a list of characters speakup repeats. Normally, when there are
> more than three characters in a row, speakup just reads three of those
> characters. For example, "......" would be read as dot, dot, dot. If a
> . is added to the list of characters in repeats, "......" would be
> read as dot, dot, dot, times six.
>
> say_control
> If set to one, speakup speaks shift, alt and control when those keys are
> pressed. Perhaps more keys are spoken, but those three are the ones I
> found. If say_control is set to zero, shift, ctrl, and alt are not
> spoken when they are pressed.
>
> say_word_ctl
> Don't know.
>
> silent
> Don't know.
>
> spell_delay
> As far as I can tell, this controls how fast a word is spelled when
> speakup's say word review command is pressed twice quickly to speak
> the current word being reviewed. Zero just speaks the letters one
> after another, while values one through four seem to introduce more of
> a pause between the spelling of each letter by speakup.
>
> synth
> Gets or sets the synthesizer driver currently in use. Reading synth
> returns the synthesizer driver currently in use. Writing synth
> switches to the given synthesizer driver, provided it is either built
> into the kernel, or already loaded as a module.
>
> synth_direct
> Sends whatever is written to synth_direct
> directly to the speech synthesizer in use, bypassing speakup. This
> could be used to make the synthesizer speak a string, or to send
> control sequences to the synthesizer to change how the synthesizer
> behaves.
>
> version
> Reading version returns the version of speakup, and the version of the
> synthesizer driver currently in use.
>
> Synthesizer Driver Parameters
> In /sys/accessibility/speakup is a directory corresponding to the
> synthesizer driver currently in use (E.G) soft for the soft
> driver. This directory contains files which control the speech
> synthesizer itself, as opposed to controlling the speakup screen
> reader. As far as I know, the parameters in this directory have the
> same names and functions across all supported synthesizers. Also as
> far as I know, the range of values for freq, pitch, rate, and vol is
> the same for all supported synthesizers,
> with the given range being internally mapped by the driver to more or
> less fit the range of values supported for a given parameter by the
> individual synthesizer. I will below describe the values and
> parameters for the soft synthesizer, which I believe is the
> synthesizer currently most commonly in use.
>
> caps_start
> I believe this is the string that is sent to the synthesizer to cause
> it to start speaking uppercase letters. For the soft synthesizer and
> most others, this causes the pitch of the voice to rise above the
> currently set pitch.
>
> caps_stop
> I believe this is the string sent to the synthesizer to cause it to
> stop speaking uppercase letters. In the case of the soft synthesizer
> and most others, this returns the pitch of the voice down to the
> currently set pitch.
>
> delay_time
> Don't know.
>
> direct
> Controls if punctuation is spoken by speakup, or by the
> synthesizer. For example, speakup speaks ">" as "greater", while the
> espeak synthesizer used by the soft driver speaks "greater than". Zero
> lets speakup speak the punctuation. One lets the synthesizer itself
> speak punctuation.
>
> freq
> Gets or sets the frequency of the speech synthesizer. Range is 0-9.
>
> full_time
> Don't know.
>
> jiffy_delta
> As far as I know, this controls how many jiffys the kernel gives to
> the synthesizer. I seem to recall Kirk saying that setting this too
> high can make a system unstable, or even crash it.
>
> pitch
> Gets or sets the pitch of the synthesizer. The range is 0-9.
>
> punct
> Gets or sets the amount of punctuation spoken by the synthesizer. The
> range for the soft driver seems to be 0-2. I'm not exactly sure how
> this relates to speakup's punc_level, or reading_punc
>
> rate
> Gets or sets the rate of the synthesizer. Range is from zero slowest,
> to nine fastest.
>
> tone
> Gets or sets the tone of the speech synthesizer. The range for the
> soft driver seems to be 0-2. This seems to make no difference if using
> espeak and the espeakup connector. I'm not sure even if espeakup
> supports different tonalities.
>
> trigger_time
> Don't know.
>
> voice
> Gets or sets the voice used by the synthesizer if the synthesizer can
> speak in more than one voice. The range for the soft driver is
> 0-7. Note that while espeak supports multiple voices, this parameter
> will not set the voice when the espeakup connector is used between
> speakup and espeak.
>
> vol
> Gets or sets the volume of the speech synthesizer. Range is 0-9, with
> zero being the softest, and nine being the loudest.
>
> Additions, clarifications, and corrections are welcome and
> appreciated.
>
> Greg
>
>
> --
> web site: http://www.gregn.net
> gpg public key: http://www.gregn.net/pubkey.asc
> skype: gregn1
> (authorization required, add me to your contacts list first)
> If we haven't been in touch before, e-mail me before adding me to your contacts.
>
> --
> Free domains: http://www.eu.org/ or mail [email protected]
> _______________________________________________
> Speakup mailing list
> [email protected]
> http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup
>
On Thu, Jul 25, 2019 at 08:11:04AM +0200, Willem van der Walt wrote:
> Hi,
> I have added a few things inline in Greg's message, mainly regarding the
> bleeps and cursor_time.
This is a great start, can someone turn this into the correct format
that we need for Documentation/ABI/ ?
thanks,
greg k-h
On Fri, Jul 12, 2019 at 05:46:23PM -0700, Gregory Nowak wrote:
> On Fri, Jul 12, 2019 at 11:23:19AM +0200, Samuel Thibault wrote:
> > Hello,
> >
> > To readers of the linux-speakup: could you help on this so we can get
> > Speakup in mainline? Neither Okash or I completely know what user
> > consequences the files in /sys/accessibility/speakup/ have, so could
> > people give brief explanations for each file (something like 3-6 lines
> > of explanation)?
>
> I have a recollection of documenting most of this on the speakup list
> in response to a similar query a number of years ago. Unfortunately,
> the speakup mailing list archives aren't easily searchable, and I
> don't have a local copy of that mail.
>
> Kirk, doing grep with a few of the file names in
> /sys/accessibility/speakup against the list's mbox file archive should
> find that message if it's in fact there. If you can please find it,
> and post the date when it was sent, we can provide a URL to that
> thread as a starting point. If my recollection is wrong, and such a
> message isn't in the archives, I'll write up what I know about.
I've located the message I was thinking of in the archives, but that
describes some speakup key commands, not
/sys/accessibility/speakup. So, here's what I know, and hopefully
someone else can fill in the rest.
attrib_bleep
Beeps the PC speaker when there is an attribute change such as
foreground or background color when using speakup review commands. One
= on, zero = off. I'm not currently at a machine with a working PC
speaker, so can't test this right now.
bell_pos
As far as I know, this works much like a typewriter bell. If for
example 72 is echoed to bell_pos, it will beep the PC speaker when
typing on a line past character 72. Again, no PC speaker at the moment
here, so can't actually test this.
bleeps
Not 100% sure, but I believe this controls whether one hears beeps
through the PC speaker when using speakup's review commands. If no one
jumps in on this, I'll experiment when at a machine with a working PC
speaker, and will reply back with details.
bleep_time
Again, not 100% sure, but I believe this controls the duration of the
PC speaker beeps speakup produces. I'm not sure of the units this is
in either, possibly jiffys. I'll come back with more details on this
one if no one else does.
cursor_time
Don't know.
delimiters
Don't know. I've tried echoing various characters to this and looking
for differences when reviewing the screen, but no luck.
ex_num
Don't know.
key_echo
Controls if speakup speaks keys when they are typed. One = on, zero =
off or don't echo keys.
keymap
I believe this is the currently active kernel keymap. I'm not sure of
the format, probably what dumpkeys(1) and showkey(1) use. Echoing
different values here should allow for remapping speakup's review
commands besides remapping the keyboard as a whole.
no_interrupt
Controls if typing interrupts output from speakup. With no_interrupt
set to zero, typing on the keyboard will interrupt speakup if for
example the say screen command is used before the entire screen is
read. With no_interrupt set to one, if the say screen command is used,
and one then types on the keyboard, speakup will continue to say the
whole screen regardless until it finishes.
punc_all
This is a list of all the punctuation speakup should speak when
punc_level is set to four.
punc_level
Controls the level of punctuation spoken as the screen is displayed,
not reviewed. Levels range from zero no punctuation, to four, all
punctuation. As far as I can tell, one corresponds to punc_some, two
corresponds to punc_most, and three as well as four seem to both
correspond to punc_all, though I do stand to be corrected. I am using
the soft synthesizer driver, so it is possible that some hardware
synthesizers have different levels each corresponding to three and four
for punc_level. Also note that if punc_level is set to zero, and
key_echo is set to one, typed punctuation is still spoken as it is
typed.
punc_most
This is a list of all the punctuation speakup should speak when
punc_level is set to two.
punc_some
This is a list of all the punctuation speakup should speak when
punc_level is set to one.
reading_punc
Almost the same as punc_level, the differences being that reading_punc controls
the level of punctuation when reviewing the screen with speakup's
screen review commands. The other difference is that reading_punc set
to three speaks punc_all, and reading_punc set to four speaks all
punctuation, including spaces.
repeats
a list of characters speakup repeats. Normally, when there are
more than three characters in a row, speakup just reads three of those
characters. For example, "......" would be read as dot, dot, dot. If a
. is added to the list of characters in repeats, "......" would be
read as dot, dot, dot, times six.
say_control
If set to one, speakup speaks shift, alt and control when those keys are
pressed. Perhaps more keys are spoken, but those three are the ones I
found. If say_control is set to zero, shift, ctrl, and alt are not
spoken when they are pressed.
say_word_ctl
Don't know.
silent
Don't know.
spell_delay
As far as I can tell, this controls how fast a word is spelled when
speakup's say word review command is pressed twice quickly to speak
the current word being reviewed. Zero just speaks the letters one
after another, while values one through four seem to introduce more of
a pause between the spelling of each letter by speakup.
synth
Gets or sets the synthesizer driver currently in use. Reading synth
returns the synthesizer driver currently in use. Writing synth
switches to the given synthesizer driver, provided it is either built
into the kernel, or already loaded as a module.
synth_direct
Sends whatever is written to synth_direct
directly to the speech synthesizer in use, bypassing speakup. This
could be used to make the synthesizer speak a string, or to send
control sequences to the synthesizer to change how the synthesizer
behaves.
version
Reading version returns the version of speakup, and the version of the
synthesizer driver currently in use.
Synthesizer Driver Parameters
In /sys/accessibility/speakup is a directory corresponding to the
synthesizer driver currently in use (E.G) soft for the soft
driver. This directory contains files which control the speech
synthesizer itself, as opposed to controlling the speakup screen
reader. As far as I know, the parameters in this directory have the
same names and functions across all supported synthesizers. Also as
far as I know, the range of values for freq, pitch, rate, and vol is
the same for all supported synthesizers,
with the given range being internally mapped by the driver to more or
less fit the range of values supported for a given parameter by the
individual synthesizer. I will below describe the values and
parameters for the soft synthesizer, which I believe is the
synthesizer currently most commonly in use.
caps_start
I believe this is the string that is sent to the synthesizer to cause
it to start speaking uppercase letters. For the soft synthesizer and
most others, this causes the pitch of the voice to rise above the
currently set pitch.
caps_stop
I believe this is the string sent to the synthesizer to cause it to
stop speaking uppercase letters. In the case of the soft synthesizer
and most others, this returns the pitch of the voice down to the
currently set pitch.
delay_time
Don't know.
direct
Controls if punctuation is spoken by speakup, or by the
synthesizer. For example, speakup speaks ">" as "greater", while the
espeak synthesizer used by the soft driver speaks "greater than". Zero
lets speakup speak the punctuation. One lets the synthesizer itself
speak punctuation.
freq
Gets or sets the frequency of the speech synthesizer. Range is 0-9.
full_time
Don't know.
jiffy_delta
As far as I know, this controls how many jiffys the kernel gives to
the synthesizer. I seem to recall Kirk saying that setting this too
high can make a system unstable, or even crash it.
pitch
Gets or sets the pitch of the synthesizer. The range is 0-9.
punct
Gets or sets the amount of punctuation spoken by the synthesizer. The
range for the soft driver seems to be 0-2. I'm not exactly sure how
this relates to speakup's punc_level, or reading_punc
rate
Gets or sets the rate of the synthesizer. Range is from zero slowest,
to nine fastest.
tone
Gets or sets the tone of the speech synthesizer. The range for the
soft driver seems to be 0-2. This seems to make no difference if using
espeak and the espeakup connector. I'm not sure even if espeakup
supports different tonalities.
trigger_time
Don't know.
voice
Gets or sets the voice used by the synthesizer if the synthesizer can
speak in more than one voice. The range for the soft driver is
0-7. Note that while espeak supports multiple voices, this parameter
will not set the voice when the espeakup connector is used between
speakup and espeak.
vol
Gets or sets the volume of the speech synthesizer. Range is 0-9, with
zero being the softest, and nine being the loudest.
Additions, clarifications, and corrections are welcome and
appreciated.
Greg
--
web site: http://www.gregn.net
gpg public key: http://www.gregn.net/pubkey.asc
skype: gregn1
(authorization required, add me to your contacts list first)
If we haven't been in touch before, e-mail me before adding me to your contacts.
--
Free domains: http://www.eu.org/ or mail [email protected]
I think the program is genmap, I have it in my init sequence, but I
am not sure it does anything at this point.
On Thu, 25 Jul 2019 00:04:07 -0400,
Chris Brannon wrote:
>
> Gregory Nowak <[email protected]> writes:
>
> > keymap
> > I believe this is the currently active kernel keymap. I'm not sure of
> > the format, probably what dumpkeys(1) and showkey(1) use. Echoing
> > different values here should allow for remapping speakup's review
> > commands besides remapping the keyboard as a whole.
>
> AFAIK the Speakup keymap is just for remapping keys to Speakup
> functions. It's a binary format, not related to dumpkeys etc. You need
> a special program to compile a textual keymap into something that can be
> loaded into /sys/accessibility/speakup/keymap. I may have source for
> that lying around here somewhere. This is "here there be dragons"
> territory. I think the only specification of the format is in the
> source code.
>
> -- Chris
> _______________________________________________
> Speakup mailing list
> [email protected]
> http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup
--
Your life is like a penny. You're going to lose it. The question is:
How do
you spend it?
John Covici wb2una
[email protected]
the cursor_time option (I think) controls a cursor delay when you do
the arrow keys. I think the delimiters are what delimit a word fr
speakup, I changed it to space only, so it would work better for me.
On Wed, 24 Jul 2019 23:53:52 -0400,
Gregory Nowak wrote:
>
> On Fri, Jul 12, 2019 at 05:46:23PM -0700, Gregory Nowak wrote:
> > On Fri, Jul 12, 2019 at 11:23:19AM +0200, Samuel Thibault wrote:
> > > Hello,
> > >
> > > To readers of the linux-speakup: could you help on this so we can get
> > > Speakup in mainline? Neither Okash or I completely know what user
> > > consequences the files in /sys/accessibility/speakup/ have, so could
> > > people give brief explanations for each file (something like 3-6 lines
> > > of explanation)?
> >
> > I have a recollection of documenting most of this on the speakup list
> > in response to a similar query a number of years ago. Unfortunately,
> > the speakup mailing list archives aren't easily searchable, and I
> > don't have a local copy of that mail.
> >
> > Kirk, doing grep with a few of the file names in
> > /sys/accessibility/speakup against the list's mbox file archive should
> > find that message if it's in fact there. If you can please find it,
> > and post the date when it was sent, we can provide a URL to that
> > thread as a starting point. If my recollection is wrong, and such a
> > message isn't in the archives, I'll write up what I know about.
>
> I've located the message I was thinking of in the archives, but that
> describes some speakup key commands, not
> /sys/accessibility/speakup. So, here's what I know, and hopefully
> someone else can fill in the rest.
>
> attrib_bleep
> Beeps the PC speaker when there is an attribute change such as
> foreground or background color when using speakup review commands. One
> = on, zero = off. I'm not currently at a machine with a working PC
> speaker, so can't test this right now.
>
> bell_pos
> As far as I know, this works much like a typewriter bell. If for
> example 72 is echoed to bell_pos, it will beep the PC speaker when
> typing on a line past character 72. Again, no PC speaker at the moment
> here, so can't actually test this.
>
> bleeps
> Not 100% sure, but I believe this controls whether one hears beeps
> through the PC speaker when using speakup's review commands. If no one
> jumps in on this, I'll experiment when at a machine with a working PC
> speaker, and will reply back with details.
>
> bleep_time
> Again, not 100% sure, but I believe this controls the duration of the
> PC speaker beeps speakup produces. I'm not sure of the units this is
> in either, possibly jiffys. I'll come back with more details on this
> one if no one else does.
>
> cursor_time
> Don't know.
>
> delimiters
> Don't know. I've tried echoing various characters to this and looking
> for differences when reviewing the screen, but no luck.
>
> ex_num
> Don't know.
>
> key_echo
> Controls if speakup speaks keys when they are typed. One = on, zero =
> off or don't echo keys.
>
> keymap
> I believe this is the currently active kernel keymap. I'm not sure of
> the format, probably what dumpkeys(1) and showkey(1) use. Echoing
> different values here should allow for remapping speakup's review
> commands besides remapping the keyboard as a whole.
>
> no_interrupt
> Controls if typing interrupts output from speakup. With no_interrupt
> set to zero, typing on the keyboard will interrupt speakup if for
> example the say screen command is used before the entire screen is
> read. With no_interrupt set to one, if the say screen command is used,
> and one then types on the keyboard, speakup will continue to say the
> whole screen regardless until it finishes.
>
> punc_all
> This is a list of all the punctuation speakup should speak when
> punc_level is set to four.
>
> punc_level
> Controls the level of punctuation spoken as the screen is displayed,
> not reviewed. Levels range from zero no punctuation, to four, all
> punctuation. As far as I can tell, one corresponds to punc_some, two
> corresponds to punc_most, and three as well as four seem to both
> correspond to punc_all, though I do stand to be corrected. I am using
> the soft synthesizer driver, so it is possible that some hardware
> synthesizers have different levels each corresponding to three and four
> for punc_level. Also note that if punc_level is set to zero, and
> key_echo is set to one, typed punctuation is still spoken as it is
> typed.
>
> punc_most
> This is a list of all the punctuation speakup should speak when
> punc_level is set to two.
>
> punc_some
> This is a list of all the punctuation speakup should speak when
> punc_level is set to one.
>
> reading_punc
> Almost the same as punc_level, the differences being that reading_punc controls
> the level of punctuation when reviewing the screen with speakup's
> screen review commands. The other difference is that reading_punc set
> to three speaks punc_all, and reading_punc set to four speaks all
> punctuation, including spaces.
>
> repeats
> a list of characters speakup repeats. Normally, when there are
> more than three characters in a row, speakup just reads three of those
> characters. For example, "......" would be read as dot, dot, dot. If a
> . is added to the list of characters in repeats, "......" would be
> read as dot, dot, dot, times six.
>
> say_control
> If set to one, speakup speaks shift, alt and control when those keys are
> pressed. Perhaps more keys are spoken, but those three are the ones I
> found. If say_control is set to zero, shift, ctrl, and alt are not
> spoken when they are pressed.
>
> say_word_ctl
> Don't know.
>
> silent
> Don't know.
>
> spell_delay
> As far as I can tell, this controls how fast a word is spelled when
> speakup's say word review command is pressed twice quickly to speak
> the current word being reviewed. Zero just speaks the letters one
> after another, while values one through four seem to introduce more of
> a pause between the spelling of each letter by speakup.
>
> synth
> Gets or sets the synthesizer driver currently in use. Reading synth
> returns the synthesizer driver currently in use. Writing synth
> switches to the given synthesizer driver, provided it is either built
> into the kernel, or already loaded as a module.
>
> synth_direct
> Sends whatever is written to synth_direct
> directly to the speech synthesizer in use, bypassing speakup. This
> could be used to make the synthesizer speak a string, or to send
> control sequences to the synthesizer to change how the synthesizer
> behaves.
>
> version
> Reading version returns the version of speakup, and the version of the
> synthesizer driver currently in use.
>
> Synthesizer Driver Parameters
> In /sys/accessibility/speakup is a directory corresponding to the
> synthesizer driver currently in use (E.G) soft for the soft
> driver. This directory contains files which control the speech
> synthesizer itself, as opposed to controlling the speakup screen
> reader. As far as I know, the parameters in this directory have the
> same names and functions across all supported synthesizers. Also as
> far as I know, the range of values for freq, pitch, rate, and vol is
> the same for all supported synthesizers,
> with the given range being internally mapped by the driver to more or
> less fit the range of values supported for a given parameter by the
> individual synthesizer. I will below describe the values and
> parameters for the soft synthesizer, which I believe is the
> synthesizer currently most commonly in use.
>
> caps_start
> I believe this is the string that is sent to the synthesizer to cause
> it to start speaking uppercase letters. For the soft synthesizer and
> most others, this causes the pitch of the voice to rise above the
> currently set pitch.
>
> caps_stop
> I believe this is the string sent to the synthesizer to cause it to
> stop speaking uppercase letters. In the case of the soft synthesizer
> and most others, this returns the pitch of the voice down to the
> currently set pitch.
>
> delay_time
> Don't know.
>
> direct
> Controls if punctuation is spoken by speakup, or by the
> synthesizer. For example, speakup speaks ">" as "greater", while the
> espeak synthesizer used by the soft driver speaks "greater than". Zero
> lets speakup speak the punctuation. One lets the synthesizer itself
> speak punctuation.
>
> freq
> Gets or sets the frequency of the speech synthesizer. Range is 0-9.
>
> full_time
> Don't know.
>
> jiffy_delta
> As far as I know, this controls how many jiffys the kernel gives to
> the synthesizer. I seem to recall Kirk saying that setting this too
> high can make a system unstable, or even crash it.
>
> pitch
> Gets or sets the pitch of the synthesizer. The range is 0-9.
>
> punct
> Gets or sets the amount of punctuation spoken by the synthesizer. The
> range for the soft driver seems to be 0-2. I'm not exactly sure how
> this relates to speakup's punc_level, or reading_punc
>
> rate
> Gets or sets the rate of the synthesizer. Range is from zero slowest,
> to nine fastest.
>
> tone
> Gets or sets the tone of the speech synthesizer. The range for the
> soft driver seems to be 0-2. This seems to make no difference if using
> espeak and the espeakup connector. I'm not sure even if espeakup
> supports different tonalities.
>
> trigger_time
> Don't know.
>
> voice
> Gets or sets the voice used by the synthesizer if the synthesizer can
> speak in more than one voice. The range for the soft driver is
> 0-7. Note that while espeak supports multiple voices, this parameter
> will not set the voice when the espeakup connector is used between
> speakup and espeak.
>
> vol
> Gets or sets the volume of the speech synthesizer. Range is 0-9, with
> zero being the softest, and nine being the loudest.
>
> Additions, clarifications, and corrections are welcome and
> appreciated.
>
> Greg
>
>
> --
> web site: http://www.gregn.net
> gpg public key: http://www.gregn.net/pubkey.asc
> skype: gregn1
> (authorization required, add me to your contacts list first)
> If we haven't been in touch before, e-mail me before adding me to your contacts.
>
> --
> Free domains: http://www.eu.org/ or mail [email protected]
> _______________________________________________
> Speakup mailing list
> [email protected]
> http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup
--
Your life is like a penny. You're going to lose it. The question is:
How do
you spend it?
John Covici wb2una
[email protected]
On Thu, Jul 25, 2019 at 3:49 AM John Covici <[email protected]> wrote:
>
> I think the program is genmap, I have it in my init sequence, but I
> am not sure it does anything at this point.
>
> On Thu, 25 Jul 2019 00:04:07 -0400,
> Chris Brannon wrote:
> >
> > Gregory Nowak <[email protected]> writes:
> >
> > > keymap
> > > I believe this is the currently active kernel keymap. I'm not sure of
> > > the format, probably what dumpkeys(1) and showkey(1) use. Echoing
> > > different values here should allow for remapping speakup's review
> > > commands besides remapping the keyboard as a whole.
> >
> > AFAIK the Speakup keymap is just for remapping keys to Speakup
> > functions. It's a binary format, not related to dumpkeys etc. You need
> > a special program to compile a textual keymap into something that can be
> > loaded into /sys/accessibility/speakup/keymap. I may have source for
> > that lying around here somewhere. This is "here there be dragons"
> > territory. I think the only specification of the format is in the
> > source code.
> >
> > -- Chris
> > _______________________________________________
> > Speakup mailing list
> > [email protected]
> > http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup
>
> --
> Your life is like a penny. You're going to lose it. The question is:
> How do
> you spend it?
>
> John Covici wb2una
> [email protected]
> _______________________________________________
> Speakup mailing list
> [email protected]
> http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup
Hi Greg N,
Would like to send this as a patch as Greg K-H suggested? If not, I
can do that with your email in Authored-by: tag?
Thanks,
Okash
On Wed, Aug 21, 2019 at 09:39:25AM -0700, Okash Khawaja wrote:
> Hi Greg N,
>
> Would like to send this as a patch as Greg K-H suggested? If not, I
> can do that with your email in Authored-by: tag?
>
> Thanks,
> Okash
Hi Okash and all,
feel free to submit the patch with my email in the Authored-by:
tag if that's OK. Thanks, and good luck on your presentation.
Greg
--
web site: http://www.gregn.net
gpg public key: http://www.gregn.net/pubkey.asc
skype: gregn1
(authorization required, add me to your contacts list first)
If we haven't been in touch before, e-mail me before adding me to your contacts.
--
Free domains: http://www.eu.org/ or mail [email protected]
Sorry, I have only now got round to working on this. It's not complete
yet but I have assimilated the feedback and converted subjective
phrases, like "I think..." into objective statements or put them in
TODO: so that someone else may verify. I have attached it to this
email.
Next step will be to convert the format to match Documentation/ABI/
requirements.
Thanks,
Okash
On Wed, Aug 21, 2019 at 11:23 PM Gregory Nowak <[email protected]> wrote:
>
> On Wed, Aug 21, 2019 at 09:39:25AM -0700, Okash Khawaja wrote:
> > Hi Greg N,
> >
> > Would like to send this as a patch as Greg K-H suggested? If not, I
> > can do that with your email in Authored-by: tag?
> >
> > Thanks,
> > Okash
>
> Hi Okash and all,
> feel free to submit the patch with my email in the Authored-by:
> tag if that's OK. Thanks, and good luck on your presentation.
>
> Greg
>
>
> --
> web site: http://www.gregn.net
> gpg public key: http://www.gregn.net/pubkey.asc
> skype: gregn1
> (authorization required, add me to your contacts list first)
> If we haven't been in touch before, e-mail me before adding me to your contacts.
>
> --
> Free domains: http://www.eu.org/ or mail [email protected]
> _______________________________________________
> Speakup mailing list
> [email protected]
> http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup
On Sun, Sep 08, 2019 at 10:43:02AM +0100, Okash Khawaja wrote:
> Sorry, I have only now got round to working on this. It's not complete
> yet but I have assimilated the feedback and converted subjective
> phrases, like "I think..." into objective statements or put them in
> TODO: so that someone else may verify. I have attached it to this
> email.
I think bleeps needs a TODO, since we don't know what values it accepts, or
what difference those values make. Also, to keep things uniform, we
should replace my "don't know" for trigger_time with a TODO. Looks
good to me otherwise. Thanks.
Greg
--
web site: http://www.gregn.net
gpg public key: http://www.gregn.net/pubkey.asc
skype: gregn1
(authorization required, add me to your contacts list first)
If we haven't been in touch before, e-mail me before adding me to your contacts.
--
Free domains: http://www.eu.org/ or mail [email protected]
On Mon, Sep 9, 2019 at 3:55 AM Gregory Nowak <[email protected]> wrote:
>
> On Sun, Sep 08, 2019 at 10:43:02AM +0100, Okash Khawaja wrote:
> > Sorry, I have only now got round to working on this. It's not complete
> > yet but I have assimilated the feedback and converted subjective
> > phrases, like "I think..." into objective statements or put them in
> > TODO: so that someone else may verify. I have attached it to this
> > email.
>
> I think bleeps needs a TODO, since we don't know what values it accepts, or
> what difference those values make. Also, to keep things uniform, we
> should replace my "don't know" for trigger_time with a TODO. Looks
> good to me otherwise. Thanks.
Great thanks. I have updated.
I have two questions:
1. Is it okay for these descriptions to go inside
Documentation/ABI/stable? They have been around since 2.6 (2010). Or
would we prefer Documentation/ABI/testing/?
2. We are still missing descriptions for i18n/ directory. I have added
filenames below. can someone can add description please:
What: /sys/accessibility/speakup/i18n/announcements
KernelVersion: 2.6
Contact: [email protected]
Description:
TODO
What: /sys/accessibility/speakup/i18n/chartab
KernelVersion: 2.6
Contact: [email protected]
Description:
TODO
What: /sys/accessibility/speakup/i18n/ctl_keys
KernelVersion: 2.6
Contact: [email protected]
Description:
TODO
What: /sys/accessibility/speakup/i18n/function_names
KernelVersion: 2.6
Contact: [email protected]
Description:
TODO
What: /sys/accessibility/speakup/i18n/states
KernelVersion: 2.6
Contact: [email protected]
Description:
TODO
What: /sys/accessibility/speakup/i18n/characters
KernelVersion: 2.6
Contact: [email protected]
Description:
TODO
What: /sys/accessibility/speakup/i18n/colors
KernelVersion: 2.6
Contact: [email protected]
Description:
TODO
What: /sys/accessibility/speakup/i18n/formatted
KernelVersion: 2.6
Contact: [email protected]
Description:
TODO
What: /sys/accessibility/speakup/i18n/key_names
KernelVersion: 2.6
Contact: [email protected]
Description:
TODO
Thanks,
Okash
Hello,
Okash Khawaja, le sam. 14 sept. 2019 22:08:35 +0100, a ecrit:
> 2. We are still missing descriptions for i18n/ directory. I have added
> filenames below. can someone can add description please:
There are some descriptions in the "14.1. Files Under the i18n
Subdirectory" section of spkguide.txt
Samuel
On Sat, Sep 14, 2019 at 10:08:35PM +0100, Okash Khawaja wrote:
> On Mon, Sep 9, 2019 at 3:55 AM Gregory Nowak <[email protected]> wrote:
> >
> > On Sun, Sep 08, 2019 at 10:43:02AM +0100, Okash Khawaja wrote:
> > > Sorry, I have only now got round to working on this. It's not complete
> > > yet but I have assimilated the feedback and converted subjective
> > > phrases, like "I think..." into objective statements or put them in
> > > TODO: so that someone else may verify. I have attached it to this
> > > email.
> >
> > I think bleeps needs a TODO, since we don't know what values it accepts, or
> > what difference those values make. Also, to keep things uniform, we
> > should replace my "don't know" for trigger_time with a TODO. Looks
> > good to me otherwise. Thanks.
>
> Great thanks. I have updated.
>
> I have two questions:
>
> 1. Is it okay for these descriptions to go inside
> Documentation/ABI/stable? They have been around since 2.6 (2010). Or
> would we prefer Documentation/ABI/testing/?
stable is fine.
thanks,
greg k-h
On Sun, Sep 15, 2019 at 2:43 PM Greg Kroah-Hartman
<[email protected]> wrote:
>
> On Sat, Sep 14, 2019 at 10:08:35PM +0100, Okash Khawaja wrote:
> > On Mon, Sep 9, 2019 at 3:55 AM Gregory Nowak <[email protected]> wrote:
> > >
> > > On Sun, Sep 08, 2019 at 10:43:02AM +0100, Okash Khawaja wrote:
> > > > Sorry, I have only now got round to working on this. It's not complete
> > > > yet but I have assimilated the feedback and converted subjective
> > > > phrases, like "I think..." into objective statements or put them in
> > > > TODO: so that someone else may verify. I have attached it to this
> > > > email.
> > >
> > > I think bleeps needs a TODO, since we don't know what values it accepts, or
> > > what difference those values make. Also, to keep things uniform, we
> > > should replace my "don't know" for trigger_time with a TODO. Looks
> > > good to me otherwise. Thanks.
> >
> > Great thanks. I have updated.
> >
> > I have two questions:
> >
> > 1. Is it okay for these descriptions to go inside
> > Documentation/ABI/stable? They have been around since 2.6 (2010). Or
> > would we prefer Documentation/ABI/testing/?
>
> stable is fine.
>
> thanks,
>
> greg k-h
Thanks Samuel and Greg.
I have attached the descriptions. There are still some files marked
with TODO, whose descriptions are incomplete or missing.
Thanks,
Okash
Okash Khawaja, le dim. 15 sept. 2019 19:41:30 +0100, a ecrit:
> I have attached the descriptions.
Attachment is missing :)
Samuel
On Mon, Sep 16, 2019 at 03:47:28PM +0200, Samuel Thibault wrote:
> Okash Khawaja, le dim. 15 sept. 2019 19:41:30 +0100, a ecrit:
> > I have attached the descriptions.
>
> Attachment is missing :)
I saw it :)
Anyway, please put the Description: lines without a blank after that,
with the description text starting on that same line.
thanks!
greg k-h
On Mon, Sep 16, 2019 at 04:11:00PM +0200, Greg Kroah-Hartman wrote:
> On Mon, Sep 16, 2019 at 03:47:28PM +0200, Samuel Thibault wrote:
> > Okash Khawaja, le dim. 15 sept. 2019 19:41:30 +0100, a ecrit:
> > > I have attached the descriptions.
> >
> > Attachment is missing :)
>
> I saw it :)
>
> Anyway, please put the Description: lines without a blank after that,
> with the description text starting on that same line.
>
> thanks!
>
> greg k-h
It's attached. Hope the indentation is OK.
Greg
--
web site: http://www.gregn.net
gpg public key: http://www.gregn.net/pubkey.asc
skype: gregn1
(authorization required, add me to your contacts list first)
If we haven't been in touch before, e-mail me before adding me to your contacts.
--
Free domains: http://www.eu.org/ or mail [email protected]
On Mon, Sep 16, 2019 at 03:47:28PM +0200, Samuel Thibault wrote:
> Okash Khawaja, le dim. 15 sept. 2019 19:41:30 +0100, a ecrit:
> > I have attached the descriptions.
>
> Attachment is missing :)
>
> Samuel
Samuel, check the message that came to you directly, and it should be
there. The speakup list rejects attachments.
Greg
--
web site: http://www.gregn.net
gpg public key: http://www.gregn.net/pubkey.asc
skype: gregn1
(authorization required, add me to your contacts list first)
If we haven't been in touch before, e-mail me before adding me to your contacts.
--
Free domains: http://www.eu.org/ or mail [email protected]
On Mon, Sep 16, 2019 at 03:38:48PM -0700, Gregory Nowak wrote:
> On Mon, Sep 16, 2019 at 04:11:00PM +0200, Greg Kroah-Hartman wrote:
> > On Mon, Sep 16, 2019 at 03:47:28PM +0200, Samuel Thibault wrote:
> > > Okash Khawaja, le dim. 15 sept. 2019 19:41:30 +0100, a ecrit:
> > > > I have attached the descriptions.
> > >
> > > Attachment is missing :)
> >
> > I saw it :)
> >
> > Anyway, please put the Description: lines without a blank after that,
> > with the description text starting on that same line.
> >
> > thanks!
> >
> > greg k-h
>
> It's attached. Hope the indentation is OK.
Alignment is a bit off, you forgot a tab after "Description:"
And you have some trailing whitespace in the document :(
thanks,
greg k-h
Ah it looks like the spaces after Description: need to be converted into tabs.
Thanks,
Okash
On Tue, Sep 17, 2019 at 10:35 PM Okash Khawaja <[email protected]> wrote:
>
> Hi Greg,
>
> You're right, I got none of those emails. Thanks. Is it all taken care of?
>
> Best regards,
> Okash
>
> On Tue, Sep 17, 2019 at 4:56 AM Gregory Nowak <[email protected]> wrote:
> >
> > Hi Okash,
> > I just realized the below didn't go to you directly along with the
> > other addresses.
> >
> > Greg
> >
> >
> > ----- Forwarded message from Gregory Nowak <[email protected]> -----
> >
> > Date: Mon, 16 Sep 2019 15:38:48 -0700
> > From: Gregory Nowak <[email protected]>
> > To: Greg Kroah-Hartman <[email protected]>
> > Cc: [email protected], Simon Dickson <[email protected]>,
> > "Speakup is a screen review system for Linux."
> > <[email protected]>, [email protected], John Covici
> > <[email protected]>
> > Subject: Re: [HELP REQUESTED from the community] Was: Staging status of speakup
> >
> > On Mon, Sep 16, 2019 at 04:11:00PM +0200, Greg Kroah-Hartman wrote:
> > > On Mon, Sep 16, 2019 at 03:47:28PM +0200, Samuel Thibault wrote:
> > > > Okash Khawaja, le dim. 15 sept. 2019 19:41:30 +0100, a ecrit:
> > > > > I have attached the descriptions.
> > > >
> > > > Attachment is missing :)
> > >
> > > I saw it :)
> > >
> > > Anyway, please put the Description: lines without a blank after that,
> > > with the description text starting on that same line.
> > >
> > > thanks!
> > >
> > > greg k-h
> >
> > It's attached. Hope the indentation is OK.
> >
> > Greg
> >
> >
> > --
> > web site: http://www.gregn.net
> > gpg public key: http://www.gregn.net/pubkey.asc
> > skype: gregn1
> > (authorization required, add me to your contacts list first)
> > If we haven't been in touch before, e-mail me before adding me to your contacts.
> >
> > --
> > Free domains: http://www.eu.org/ or mail [email protected]
> >
> > What: /sys/accessibility/speakup/attrib_bleep
> > KernelVersion: 2.6
> > Contact: [email protected]
> > Description: Beeps the PC speaker when there is an attribute change such as
> > foreground or background color when using speakup review
> > commands. One = on, zero = off.
> > What: /sys/accessibility/speakup/bell_pos
> > KernelVersion: 2.6
> > Contact: [email protected]
> > Description: This works much like a typewriter bell. If for example 72 is
> > echoed to bell_pos, it will beep the PC speaker when typing on
> > a line past character 72.
> > What: /sys/accessibility/speakup/bleeps
> > KernelVersion: 2.6
> > Contact: [email protected]
> > Description: This controls whether one hears beeps through the PC speaker
> > when using speakup's review commands.
> > TODO: what values does it accept?
> > What: /sys/accessibility/speakup/bleep_time
> > KernelVersion: 2.6
> > Contact: [email protected]
> > Description: This controls the duration of the PC speaker beeps speakup
> > produces.
> > TODO: What are the units? Jiffies?
> > What: /sys/accessibility/speakup/cursor_time
> > KernelVersion: 2.6
> > Contact: [email protected]
> > Description: This controls cursor delay when using arrow keys. When a
> > connection is very slow, with the default setting, when moving
> > with the arrows, or backspacing etc. speakup says the incorrect
> > characters. Set this to a higher value to adjust for the delay
> > and better synchronisation between cursor position and speech.
> > What: /sys/accessibility/speakup/delimiters
> > KernelVersion: 2.6
> > Contact: [email protected]
> > Description: Delimit a word from speakup.
> > TODO: add more info
> > What: /sys/accessibility/speakup/ex_num
> > KernelVersion: 2.6
> > Contact: [email protected]
> > Description: TODO:
> > What: /sys/accessibility/speakup/key_echo
> > KernelVersion: 2.6
> > Contact: [email protected]
> > Description: Controls if speakup speaks keys when they are typed. One = on,
> > zero = off or don't echo keys.
> > What: /sys/accessibility/speakup/keymap
> > KernelVersion: 2.6
> > Contact: [email protected]
> > Description: Speakup keymap remaps keys to Speakup functins. It uses a binary
> > format. A special program called genmap is needed to compile a
> > textual keymap into the binary format which is then loaded into
> > /sys/accessibility/speakup/keymap.
> > What: /sys/accessibility/speakup/no_interrupt
> > KernelVersion: 2.6
> > Contact: [email protected]
> > Description: Controls if typing interrupts output from speakup. With
> > no_interrupt set to zero, typing on the keyboard will interrupt
> > speakup if for example the say screen command is used before the
> > entire screen is read. With no_interrupt set to one, if the say
> > screen command is used, and one then types on the keyboard,
> > speakup will continue to say the whole screen regardless until
> > it finishes.
> > What: /sys/accessibility/speakup/punc_all
> > KernelVersion: 2.6
> > Contact: [email protected]
> > Description: This is a list of all the punctuation speakup should speak when
> > punc_level is set to four.
> > What: /sys/accessibility/speakup/punc_level
> > KernelVersion: 2.6
> > Contact: [email protected]
> > Description: Controls the level of punctuation spoken as the screen is
> > displayed, not reviewed. Levels range from zero no punctuation,
> > to four, all punctuation. One corresponds to punc_some, two
> > corresponds to punc_most, and three as well as four both
> > correspond to punc_all. Some hardware synthesizers may have
> > different levels each corresponding to three and four for
> > punc_level. Also note that if punc_level is set to zero, and
> > key_echo is set to one, typed punctuation is still spoken as it
> > is typed.
> > What: /sys/accessibility/speakup/punc_most
> > KernelVersion: 2.6
> > Contact: [email protected]
> > Description: This is a list of all the punctuation speakup should speak when
> > punc_level is set to two.
> > What: /sys/accessibility/speakup/punc_some
> > KernelVersion: 2.6
> > Contact: [email protected]
> > Description: This is a list of all the punctuation speakup should speak when
> > punc_level is set to one.
> > What: /sys/accessibility/speakup/reading_punc
> > KernelVersion: 2.6
> > Contact: [email protected]
> > Description: Almost the same as punc_level, the differences being that
> > reading_punc controls the level of punctuation when reviewing
> > the screen with speakup's screen review commands. The other
> > difference is that reading_punc set to three speaks punc_all,
> > and reading_punc set to four speaks all punctuation, including
> > spaces.
> > What: /sys/accessibility/speakup/repeats
> > KernelVersion: 2.6
> > Contact: [email protected]
> > Description: A list of characters speakup repeats. Normally, when there are
> > more than three characters in a row, speakup just reads three of
> > those characters. For example, "......" would be read as dot,
> > dot, dot. If a . is added to the list of characters in repeats,
> > "......" would be read as dot, dot, dot, times six.
> > What: /sys/accessibility/speakup/say_control
> > KernelVersion: 2.6
> > Contact: [email protected]
> > Description: If set to one, speakup speaks shift, alt and control when those
> > keys are pressed. If say_control is set to zero, shift, ctrl,
> > and alt are not spoken when they are pressed.
> > What: /sys/accessibility/speakup/say_word_ctl
> > KernelVersion: 2.6
> > Contact: [email protected]
> > Description: TODO:
> > What: /sys/accessibility/speakup/silent
> > KernelVersion: 2.6
> > Contact: [email protected]
> > Description: TODO:
> > What: /sys/accessibility/speakup/spell_delay
> > KernelVersion: 2.6
> > Contact: [email protected]
> > Description: This controls how fast a word is spelled when speakup's say word
> > review command is pressed twice quickly to speak the current
> > word being reviewed. Zero just speaks the letters one after
> > another, while values one through four seem to introduce more of
> > a pause between the spelling of each letter by speakup.
> > What: /sys/accessibility/speakup/synth
> > KernelVersion: 2.6
> > Contact: [email protected]
> > Description: Gets or sets the synthesizer driver currently in use. Reading
> > synth returns the synthesizer driver currently in use. Writing
> > synth switches to the given synthesizer driver, provided it is
> > either built into the kernel, or already loaded as a module.
> > What: /sys/accessibility/speakup/synth_direct
> > KernelVersion: 2.6
> > Contact: [email protected]
> > Description: Sends whatever is written to synth_direct
> > directly to the speech synthesizer in use, bypassing speakup.
> > This could be used to make the synthesizer speak a string, or to
> > send control sequences to the synthesizer to change how the
> > synthesizer behaves.
> > What: /sys/accessibility/speakup/version
> > KernelVersion: 2.6
> > Contact: [email protected]
> > Description: Reading version returns the version of speakup, and the version
> > of the synthesizer driver currently in use.
> > What: /sys/accessibility/speakup/i18n/announcements
> > KernelVersion: 2.6
> > Contact: [email protected]
> > Description: This file contains various general announcements, most of which
> > cannot be categorized. You will find messages such as "You
> > killed Speakup", "I'm alive", "leaving help", "parked",
> > "unparked", and others. You will also find the names of the
> > screen edges and cursor tracking modes here.
> > What: /sys/accessibility/speakup/i18n/chartab
> > KernelVersion: 2.6
> > Contact: [email protected]
> > Description: TODO
> > What: /sys/accessibility/speakup/i18n/ctl_keys
> > KernelVersion: 2.6
> > Contact: [email protected]
> > Description: Here, you will find names of control keys. These are used with
> > Speakup's say_control feature.
> > What: /sys/accessibility/speakup/i18n/function_names
> > KernelVersion: 2.6
> > Contact: [email protected]
> > Description: Here, you will find a list of names for Speakup functions.
> > These are used by the help system. For example, suppose that
> > you have activated help mode, and you pressed keypad 3. Speakup
> > says: "keypad 3 is character, say next."
> > The message "character, say next" names a Speakup function, and
> > it comes from this function_names file.
> > What: /sys/accessibility/speakup/i18n/states
> > KernelVersion: 2.6
> > Contact: [email protected]
> > Description: This file contains names for key states.
> > Again, these are part of the help system. For instance, if you
> > had pressed speakup + keypad 3, you would hear:
> > "speakup keypad 3 is go to bottom edge."
> > The speakup key is depressed, so the name of the key state is
> > speakup.
> > This part of the message comes from the states collection.
> > What: /sys/accessibility/speakup/i18n/characters
> > KernelVersion: 2.6
> > Contact: [email protected]
> > Description: Through this sys entry, Speakup gives you the ability to change
> > how Speakup pronounces a given character. You could, for
> > example, change how some punctuation characters are spoken. You
> > can even change how Speakup will pronounce certain letters. For
> > further details see '12. Changing the Pronunciation of
> > Characters' in Speakup User's Guide (file spkguide.txt in
> > source).
> > What: /sys/accessibility/speakup/i18n/colors
> > KernelVersion: 2.6
> > Contact: [email protected]
> > Description: When you use the "say attributes" function, Speakup says the
> > name of the foreground and background colors. These names come
> > from the i18n/colors file.
> > What: /sys/accessibility/speakup/i18n/formatted
> > KernelVersion: 2.6
> > Contact: [email protected]
> > Description: This group of messages contains embedded formatting codes, to
> > specify the type and width of displayed data. If you change
> > these, you must preserve all of the formatting codes, and they
> > must appear in the order used by the default messages.
> > What: /sys/accessibility/speakup/i18n/key_names
> > KernelVersion: 2.6
> > Contact: [email protected]
> > Description: Again, key_names is used by Speakup's help system. In the
> > previous example, Speakup said that you pressed "keypad 3."
> > This name came from the key_names file.
> > What: /sys/accessibility/speakup/<synth-name>/
> > KernelVersion: 2.6
> > Contact: [email protected]
> > Description: In `/sys/accessibility/speakup` is a directory corresponding to
> > the synthesizer driver currently in use (E.G) `soft` for the
> > soft driver. This directory contains files which control the
> > speech synthesizer itself, as opposed to controlling the speakup
> > screen reader. The parameters in this directory have the same
> > names and functions across all supported synthesizers. The range
> > of values for freq, pitch, rate, and vol is the same for all
> > supported synthesizers, with the given range being internally
> > mapped by the driver to more or less fit the range of values
> > supported for a given parameter by the individual synthesizer.
> > Below is a description of values and parameters for soft
> > synthesizer, which is currently the most commonly used.
> > What: /sys/accessibility/speakup/soft/caps_start
> > KernelVersion: 2.6
> > Contact: [email protected]
> > Description: This is the string that is sent to the synthesizer to cause it
> > to start speaking uppercase letters. For the soft synthesizer
> > and most others, this causes the pitch of the voice to rise
> > above the currently set pitch.
> > What: /sys/accessibility/speakup/soft/caps_stop
> > KernelVersion: 2.6
> > Contact: [email protected]
> > Description: This is the string sent to the synthesizer to cause it to stop
> > speaking uppercase letters. In the case of the soft synthesizer
> > and most others, this returns the pitch of the voice down to the
> > currently set pitch.
> > What: /sys/accessibility/speakup/soft/delay_time
> > KernelVersion: 2.6
> > Contact: [email protected]
> > Description: TODO:
> > What: /sys/accessibility/speakup/soft/direct
> > KernelVersion: 2.6
> > Contact: [email protected]
> > Description: Controls if punctuation is spoken by speakup, or by the
> > synthesizer. For example, speakup speaks ">" as "greater", while
> > the espeak synthesizer used by the soft driver speaks "greater
> > than". Zero lets speakup speak the punctuation. One lets the
> > synthesizer itself speak punctuation.
> > What: /sys/accessibility/speakup/soft/freq
> > KernelVersion: 2.6
> > Contact: [email protected]
> > Description: Gets or sets the frequency of the speech synthesizer. Range is
> > 0-9.
> > What: /sys/accessibility/speakup/soft/full_time
> > KernelVersion: 2.6
> > Contact: [email protected]
> > Description: TODO:
> > What: /sys/accessibility/speakup/soft/jiffy_delta
> > KernelVersion: 2.6
> > Contact: [email protected]
> > Description: This controls how many jiffys the kernel gives to the
> > synthesizer. Setting this too high can make a system unstable,
> > or even crash it.
> > What: /sys/accessibility/speakup/soft/pitch
> > KernelVersion: 2.6
> > Contact: [email protected]
> > Description: Gets or sets the pitch of the synthesizer. The range is 0-9.
> > What: /sys/accessibility/speakup/soft/punct
> > KernelVersion: 2.6
> > Contact: [email protected]
> > Description: Gets or sets the amount of punctuation spoken by the
> > synthesizer. The range for the soft driver seems to be 0-2.
> > TODO: How is this related to speakup's punc_level, or
> > reading_punc.
> > What: /sys/accessibility/speakup/soft/rate
> > KernelVersion: 2.6
> > Contact: [email protected]
> > Description: Gets or sets the rate of the synthesizer. Range is from zero
> > slowest, to nine fastest.
> > What: /sys/accessibility/speakup/soft/tone
> > KernelVersion: 2.6
> > Contact: [email protected]
> > Description: Gets or sets the tone of the speech synthesizer. The range for
> > the soft driver seems to be 0-2. This seems to make no
> > difference if using espeak and the espeakup connector.
> > TODO: does espeakup support different tonalities?
> > What: /sys/accessibility/speakup/soft/trigger_time
> > KernelVersion: 2.6
> > Contact: [email protected]
> > Description: TODO:
> > What: /sys/accessibility/speakup/soft/voice
> > KernelVersion: 2.6
> > Contact: [email protected]
> > Description: Gets or sets the voice used by the synthesizer if the
> > synthesizer can speak in more than one voice. The range for the
> > soft driver is 0-7. Note that while espeak supports multiple
> > voices, this parameter will not set the voice when the espeakup
> > connector is used between speakup and espeak.
> > What: /sys/accessibility/speakup/soft/vol
> > KernelVersion: 2.6
> > Contact: [email protected]
> > Description: Gets or sets the volume of the speech synthesizer. Range is 0-9,
> > with zero being the softest, and nine being the loudest.
> >
> > _______________________________________________
> > Speakup mailing list
> > [email protected]
> > http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup
> >
> >
> > ----- End forwarded message -----
> >
> > --
> > web site: http://www.gregn.net
> > gpg public key: http://www.gregn.net/pubkey.asc
> > skype: gregn1
> > (authorization required, add me to your contacts list first)
> > If we haven't been in touch before, e-mail me before adding me to your contacts.
> >
> > --
> > Free domains: http://www.eu.org/ or mail [email protected]
On Tue, Sep 17, 2019 at 06:03:53PM -0700, Gregory Nowak wrote:
> On Tue, Sep 17, 2019 at 10:01:18AM +0200, Greg Kroah-Hartman wrote:
> > On Mon, Sep 16, 2019 at 03:38:48PM -0700, Gregory Nowak wrote:
> > > On Mon, Sep 16, 2019 at 04:11:00PM +0200, Greg Kroah-Hartman wrote:
> > > > On Mon, Sep 16, 2019 at 03:47:28PM +0200, Samuel Thibault wrote:
> > > > > Okash Khawaja, le dim. 15 sept. 2019 19:41:30 +0100, a ecrit:
> > > > > > I have attached the descriptions.
> > > > >
> > > > > Attachment is missing :)
> > > >
> > > > I saw it :)
> > > >
> > > > Anyway, please put the Description: lines without a blank after that,
> > > > with the description text starting on that same line.
> > > >
> > > > thanks!
> > > >
> > > > greg k-h
> > >
> > > It's attached. Hope the indentation is OK.
> >
> > Alignment is a bit off, you forgot a tab after "Description:"
> >
> > And you have some trailing whitespace in the document :(
> >
> > thanks,
> >
> > greg k-h
> >
>
> I put in the tabs after "Description:" and did the best I could to fix
> the alignment, and to find and get rid of the white space. If the
> alignment is still off, or if there is still white space I missed,
> could someone else please correct that? Thanks.
Extra line between each attribute (before the "What:" line) would be
nice.
Also fixing the TODO items :)
thanks,
greg k-h
On Tue, Sep 17, 2019 at 10:01:18AM +0200, Greg Kroah-Hartman wrote:
> On Mon, Sep 16, 2019 at 03:38:48PM -0700, Gregory Nowak wrote:
> > On Mon, Sep 16, 2019 at 04:11:00PM +0200, Greg Kroah-Hartman wrote:
> > > On Mon, Sep 16, 2019 at 03:47:28PM +0200, Samuel Thibault wrote:
> > > > Okash Khawaja, le dim. 15 sept. 2019 19:41:30 +0100, a ecrit:
> > > > > I have attached the descriptions.
> > > >
> > > > Attachment is missing :)
> > >
> > > I saw it :)
> > >
> > > Anyway, please put the Description: lines without a blank after that,
> > > with the description text starting on that same line.
> > >
> > > thanks!
> > >
> > > greg k-h
> >
> > It's attached. Hope the indentation is OK.
>
> Alignment is a bit off, you forgot a tab after "Description:"
>
> And you have some trailing whitespace in the document :(
>
> thanks,
>
> greg k-h
>
I put in the tabs after "Description:" and did the best I could to fix
the alignment, and to find and get rid of the white space. If the
alignment is still off, or if there is still white space I missed,
could someone else please correct that? Thanks.
Greg
--
web site: http://www.gregn.net
gpg public key: http://www.gregn.net/pubkey.asc
skype: gregn1
(authorization required, add me to your contacts list first)
If we haven't been in touch before, e-mail me before adding me to your contacts.
--
Free domains: http://www.eu.org/ or mail [email protected]
On Wed, Sep 18, 2019 at 08:16:42AM +0200, Greg Kroah-Hartman wrote:
> On Tue, Sep 17, 2019 at 06:03:53PM -0700, Gregory Nowak wrote:
> > On Tue, Sep 17, 2019 at 10:01:18AM +0200, Greg Kroah-Hartman wrote:
> > > On Mon, Sep 16, 2019 at 03:38:48PM -0700, Gregory Nowak wrote:
> > > > On Mon, Sep 16, 2019 at 04:11:00PM +0200, Greg Kroah-Hartman wrote:
> > > > > On Mon, Sep 16, 2019 at 03:47:28PM +0200, Samuel Thibault wrote:
> > > > > > Okash Khawaja, le dim. 15 sept. 2019 19:41:30 +0100, a ecrit:
> > > > > > > I have attached the descriptions.
> > > > > >
> > > > > > Attachment is missing :)
> > > > >
> > > > > I saw it :)
> > > > >
> > > > > Anyway, please put the Description: lines without a blank after that,
> > > > > with the description text starting on that same line.
> > > > >
> > > > > thanks!
> > > > >
> > > > > greg k-h
> > > >
> > > > It's attached. Hope the indentation is OK.
> > >
> > > Alignment is a bit off, you forgot a tab after "Description:"
> > >
> > > And you have some trailing whitespace in the document :(
> > >
> > > thanks,
> > >
> > > greg k-h
> > >
> >
> > I put in the tabs after "Description:" and did the best I could to fix
> > the alignment, and to find and get rid of the white space. If the
> > alignment is still off, or if there is still white space I missed,
> > could someone else please correct that? Thanks.
>
> Extra line between each attribute (before the "What:" line) would be
> nice.
In a previous post above, you wrote:
On Mon, Sep 16, 2019 at 04:11:00PM +0200, Greg Kroah-Hartman wrote:
> Anyway, please put the Description: lines without a blank after that,
> with the description text starting on that same line.
I understood that to mean that the description text should start on
the same line, and the blank lines after the description text should
be removed. I've put them back in. Someone more familiar with the
speakup code will have to dig into it to resolve the TODO items I
suppose.
On Wed, Sep 18, 2019 at 03:28:05PM +0200, Didier Spaier wrote:
> Trailing white spaces removed in attachment.
> Alignment LGTM.
Thank you. This is the copy I put the blank lines into, and am
attaching with the original file name.
Greg N
--
web site: http://www.gregn.net
gpg public key: http://www.gregn.net/pubkey.asc
skype: gregn1
(authorization required, add me to your contacts list first)
If we haven't been in touch before, e-mail me before adding me to your contacts.
--
Free domains: http://www.eu.org/ or mail [email protected]
On Wed, Sep 18, 2019 at 01:30:33PM -0700, Gregory Nowak wrote:
> > Extra line between each attribute (before the "What:" line) would be
> > nice.
>
> In a previous post above, you wrote:
> On Mon, Sep 16, 2019 at 04:11:00PM +0200, Greg Kroah-Hartman wrote:
> > Anyway, please put the Description: lines without a blank after that,
> > with the description text starting on that same line.
>
> I understood that to mean that the description text should start on
> the same line, and the blank lines after the description text should
> be removed. I've put them back in. Someone more familiar with the
> speakup code will have to dig into it to resolve the TODO items I
> suppose.
No problem, this looks good to me. If someone wants to turn this into a
patch adding it to the drivers/staging/speakup/ directory, I'll be glad
to take it and it will allow others to fill in the TODO entries easier.
thanks,
greg k-h
On Fri, Sep 20, 2019 at 8:46 AM Greg Kroah-Hartman
<[email protected]> wrote:
>
> On Wed, Sep 18, 2019 at 01:30:33PM -0700, Gregory Nowak wrote:
> > > Extra line between each attribute (before the "What:" line) would be
> > > nice.
> >
> > In a previous post above, you wrote:
> > On Mon, Sep 16, 2019 at 04:11:00PM +0200, Greg Kroah-Hartman wrote:
> > > Anyway, please put the Description: lines without a blank after that,
> > > with the description text starting on that same line.
> >
> > I understood that to mean that the description text should start on
> > the same line, and the blank lines after the description text should
> > be removed. I've put them back in. Someone more familiar with the
> > speakup code will have to dig into it to resolve the TODO items I
> > suppose.
>
> No problem, this looks good to me. If someone wants to turn this into a
> patch adding it to the drivers/staging/speakup/ directory, I'll be glad
> to take it and it will allow others to fill in the TODO entries easier.
Thank you. I'll create a patch soon.