speakup-r functionality

speakup-r functionality

[Okash Khawaja]

Hi,

I'm trying to replicate the speakup-r problem where cursor stops many
lines down from where speech stops.

Can someone guide how to do that? I can't find documentation around speakup-r.

Thanks,
Okash

Re: speakup-r functionality

[John Covici]

Well, find a document such as a text file -- I use emacs for this, but
I suppose any editor will work -- of course it has to be in a text
console.  Now, make sure the synthesizer supports indexing -- I think
indexing support was not implemented for all drivers.  Now do
speakup-r and the file should be spoken and when you hit the control
key the cursor should be where the last word spoken.  Currently its a
number of lines down.  Try this with the old speakup with the serial
workaround patch to hear what it is supposed to b like.

Hope this helps.

On Sun, 28 May 2017 13:58:59 -0400,
Okash Khawaja wrote:
> 
> Hi,
> 
> I'm trying to replicate the speakup-r problem where cursor stops many
> lines down from where speech stops.
> 
> Can someone guide how to do that? I can't find documentation around speakup-r.
> 
> Thanks,
> Okash
> _______________________________________________
> Speakup mailing list
> Speakup@linux-speakup.org
> 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
         covici@ccs.covici.com

Re: speakup-r functionality

[Okash Khawaja]

On Sun, May 28, 2017 at 02:39:17PM -0400, John Covici wrote:
> Well, find a document such as a text file -- I use emacs for this, but
> I suppose any editor will work -- of course it has to be in a text
> console.  Now, make sure the synthesizer supports indexing -- I think
> indexing support was not implemented for all drivers.  Now do
> speakup-r and the file should be spoken and when you hit the control
> key the cursor should be where the last word spoken.  Currently its a
> number of lines down.  Try this with the old speakup with the serial
> workaround patch to hear what it is supposed to b like.
> 
> Hope this helps.
Thanks. I don't have a synth that supports indexing. But it looks like
this fix by Dan Carpenter likely addresses the issue:
http://linux-speakup.org/pipermail/speakup/2017-May/060802.html

handle_cursor_read_all() in main.c ultimately calls into
spk_ttyio_in_nowait. If value returned by spk_ttyio_in_nowait() is 0xff
when 0x00 is expectd then sentence count and index count will be
different (higher in this case) than expected.

I have update speakup.tgz to include this fix. If the above explanation
makes sense then please test it when possible.

Okash

Re: speakup-r functionality

[John Covici]

I just have one question -- how did it work with the old serial i/o
system?

On Sun, 28 May 2017 16:48:56 -0400,
Okash Khawaja wrote:
> 
> On Sun, May 28, 2017 at 02:39:17PM -0400, John Covici wrote:
> > Well, find a document such as a text file -- I use emacs for this, but
> > I suppose any editor will work -- of course it has to be in a text
> > console.  Now, make sure the synthesizer supports indexing -- I think
> > indexing support was not implemented for all drivers.  Now do
> > speakup-r and the file should be spoken and when you hit the control
> > key the cursor should be where the last word spoken.  Currently its a
> > number of lines down.  Try this with the old speakup with the serial
> > workaround patch to hear what it is supposed to b like.
> > 
> > Hope this helps.
> Thanks. I don't have a synth that supports indexing. But it looks like
> this fix by Dan Carpenter likely addresses the issue:
> http://linux-speakup.org/pipermail/speakup/2017-May/060802.html
> 
> handle_cursor_read_all() in main.c ultimately calls into
> spk_ttyio_in_nowait. If value returned by spk_ttyio_in_nowait() is 0xff
> when 0x00 is expectd then sentence count and index count will be
> different (higher in this case) than expected.
> 
> I have update speakup.tgz to include this fix. If the above explanation
> makes sense then please test it when possible.
> 
> Okash

-- 
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

         John Covici
         covici@ccs.covici.com

Re: speakup-r functionality

[Okash Khawaja]

On Sun, May 28, 2017 at 06:38:39PM -0400, John Covici wrote:
> I just have one question -- how did it work with the old serial i/o
> system?
In main.c, handle_cursor_read_all calls spk_get_index_count which calls
spk_ttyio_in_nowait or spk_serial_in_nowait depending on whether TTY or
old serial i/o is in use. So the difference is in spk_serial_in_nowait
as the layers above that are identical. spk_serial_in_nowait returns 0
when there is no data on rx. spk_ttyio_in_nowait immitates that but due
to the signedness bug, it was returning 0xff instead of 0 when there
is no data.

With the fix, now both serial i/o and TTY stacks  should have same
behaviour.

Re: speakup-r functionality

[John Covici]

OK, I will test as soon as I can.

On Mon, 29 May 2017 05:50:33 -0400,
Okash Khawaja wrote:
> 
> On Sun, May 28, 2017 at 06:38:39PM -0400, John Covici wrote:
> > I just have one question -- how did it work with the old serial i/o
> > system?
> In main.c, handle_cursor_read_all calls spk_get_index_count which calls
> spk_ttyio_in_nowait or spk_serial_in_nowait depending on whether TTY or
> old serial i/o is in use. So the difference is in spk_serial_in_nowait
> as the layers above that are identical. spk_serial_in_nowait returns 0
> when there is no data on rx. spk_ttyio_in_nowait immitates that but due
> to the signedness bug, it was returning 0xff instead of 0 when there
> is no data.
> 
> With the fix, now both serial i/o and TTY stacks  should have same
> behaviour.

-- 
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

         John Covici
         covici@ccs.covici.com

Re: speakup-r functionality

[Okash Khawaja]

Hi,

Which synth do you use?

Thanks,
Okash

> On 29 May 2017, at 13:08, John Covici <covici@ccs.covici.com> wrote:
> 
> OK, I will test as soon as I can.
> 
> On Mon, 29 May 2017 05:50:33 -0400,
> Okash Khawaja wrote:
>> 
>>> On Sun, May 28, 2017 at 06:38:39PM -0400, John Covici wrote:
>>> I just have one question -- how did it work with the old serial i/o
>>> system?
>> In main.c, handle_cursor_read_all calls spk_get_index_count which calls
>> spk_ttyio_in_nowait or spk_serial_in_nowait depending on whether TTY or
>> old serial i/o is in use. So the difference is in spk_serial_in_nowait
>> as the layers above that are identical. spk_serial_in_nowait returns 0
>> when there is no data on rx. spk_ttyio_in_nowait immitates that but due
>> to the signedness bug, it was returning 0xff instead of 0 when there
>> is no data.
>> 
>> With the fix, now both serial i/o and TTY stacks  should have same
>> behaviour.
> 
> -- 
> Your life is like a penny.  You're going to lose it.  The question is:
> How do
> you spend it?
> 
>         John Covici
>         covici@ccs.covici.com

Re: speakup-r functionality

[John Covici]

In my latest test, it still did not work.  I will send you a file to
test with.  I started  at the beginning of the file, went to line 25
and hit control and the cursor was at line 198.  Now it might work
differently with speech dispatcher, you probably should use a serial
synth to test.  Without the speakup-r empty line fix, it does work.

On Mon, 29 May 2017 05:50:33 -0400,
Okash Khawaja wrote:
> 
> On Sun, May 28, 2017 at 06:38:39PM -0400, John Covici wrote:
> > I just have one question -- how did it work with the old serial i/o
> > system?
> In main.c, handle_cursor_read_all calls spk_get_index_count which calls
> spk_ttyio_in_nowait or spk_serial_in_nowait depending on whether TTY or
> old serial i/o is in use. So the difference is in spk_serial_in_nowait
> as the layers above that are identical. spk_serial_in_nowait returns 0
> when there is no data on rx. spk_ttyio_in_nowait immitates that but due
> to the signedness bug, it was returning 0xff instead of 0 when there
> is no data.
> 
> With the fix, now both serial i/o and TTY stacks  should have same
> behaviour.

-- 
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

         John Covici
         covici@ccs.covici.com

Re: speakup-r functionality

[Okash Khawaja]

Okay I tested with the file you sent and as you described, but
couldn't replicate. If it does behave differently with serial synth
then it _could_ be that another issue has been exposed by this change.
I don't have a functional serial synth which supports indexing. I will
look into fixing my doubletalk lt.

Just to be sure, following is the patch which breaks speakup-r?

---
 drivers/staging/speakup/main.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- a/drivers/staging/speakup/main.c
+++ b/drivers/staging/speakup/main.c
@@ -1408,7 +1408,8 @@ static void read_all_doc(struct vc_data
  cursor_track = read_all_mode;
  spk_reset_index_count(0);
  if (get_sentence_buf(vc, 0) == -1) {
- kbd_fakekey2(vc, RA_DOWN_ARROW);
+ del_timer(&cursor_timer);
+ start_read_all_timer(vc, RA_DOWN_ARROW);
  } else {
  say_sentence_num(0, 0);
  synth_insert_next_index(0);

Thanks,
Okash

On Sun, Aug 20, 2017 at 5:12 PM, John Covici <covici@ccs.covici.com> wrote:
> In my latest test, it still did not work.  I will send you a file to
> test with.  I started  at the beginning of the file, went to line 25
> and hit control and the cursor was at line 198.  Now it might work
> differently with speech dispatcher, you probably should use a serial
> synth to test.  Without the speakup-r empty line fix, it does work.
>
> On Mon, 29 May 2017 05:50:33 -0400,
> Okash Khawaja wrote:
>>
>> On Sun, May 28, 2017 at 06:38:39PM -0400, John Covici wrote:
>> > I just have one question -- how did it work with the old serial i/o
>> > system?
>> In main.c, handle_cursor_read_all calls spk_get_index_count which calls
>> spk_ttyio_in_nowait or spk_serial_in_nowait depending on whether TTY or
>> old serial i/o is in use. So the difference is in spk_serial_in_nowait
>> as the layers above that are identical. spk_serial_in_nowait returns 0
>> when there is no data on rx. spk_ttyio_in_nowait immitates that but due
>> to the signedness bug, it was returning 0xff instead of 0 when there
>> is no data.
>>
>> With the fix, now both serial i/o and TTY stacks  should have same
>> behaviour.
>
> --
> Your life is like a penny.  You're going to lose it.  The question is:
> How do
> you spend it?
>
>          John Covici
>          covici@ccs.covici.com

Re: speakup-r functionality

[John Covici]

I think speech dispatch/speechd-up do something different with regard
to indexing -- they don't actually use index marks like a serial
synth, so my guess is that it works differently.

On Sun, 20 Aug 2017 13:26:50 -0400,
Okash Khawaja wrote:
> 
> Okay I tested with the file you sent and as you described, but
> couldn't replicate. If it does behave differently with serial synth
> then it _could_ be that another issue has been exposed by this change.
> I don't have a functional serial synth which supports indexing. I will
> look into fixing my doubletalk lt.
> 
> Just to be sure, following is the patch which breaks speakup-r?
> 
> ---
>  drivers/staging/speakup/main.c |    3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> --- a/drivers/staging/speakup/main.c
> +++ b/drivers/staging/speakup/main.c
> @@ -1408,7 +1408,8 @@ static void read_all_doc(struct vc_data
>   cursor_track = read_all_mode;
>   spk_reset_index_count(0);
>   if (get_sentence_buf(vc, 0) == -1) {
> - kbd_fakekey2(vc, RA_DOWN_ARROW);
> + del_timer(&cursor_timer);
> + start_read_all_timer(vc, RA_DOWN_ARROW);
>   } else {
>   say_sentence_num(0, 0);
>   synth_insert_next_index(0);
> 
> Thanks,
> Okash
> 
> On Sun, Aug 20, 2017 at 5:12 PM, John Covici <covici@ccs.covici.com> wrote:
> > In my latest test, it still did not work.  I will send you a file to
> > test with.  I started  at the beginning of the file, went to line 25
> > and hit control and the cursor was at line 198.  Now it might work
> > differently with speech dispatcher, you probably should use a serial
> > synth to test.  Without the speakup-r empty line fix, it does work.
> >
> > On Mon, 29 May 2017 05:50:33 -0400,
> > Okash Khawaja wrote:
> >>
> >> On Sun, May 28, 2017 at 06:38:39PM -0400, John Covici wrote:
> >> > I just have one question -- how did it work with the old serial i/o
> >> > system?
> >> In main.c, handle_cursor_read_all calls spk_get_index_count which calls
> >> spk_ttyio_in_nowait or spk_serial_in_nowait depending on whether TTY or
> >> old serial i/o is in use. So the difference is in spk_serial_in_nowait
> >> as the layers above that are identical. spk_serial_in_nowait returns 0
> >> when there is no data on rx. spk_ttyio_in_nowait immitates that but due
> >> to the signedness bug, it was returning 0xff instead of 0 when there
> >> is no data.
> >>
> >> With the fix, now both serial i/o and TTY stacks  should have same
> >> behaviour.
> >
> > --
> > Your life is like a penny.  You're going to lose it.  The question is:
> > How do
> > you spend it?
> >
> >          John Covici
> >          covici@ccs.covici.com

-- 
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

         John Covici
         covici@ccs.covici.com

Re: speakup-r functionality

[Okash Khawaja]

Hi,

Here's one thing I think worth trying. I have updated the patch so that
the net difference between before and after the patch is that
speakup_fake_down_arrow() is not called when inside interrupt context.

Calling speakup_fake_down_arrow() inside interrupt causes the kernel
lock up because this itself generates same interrupt, leading to
infinite recursion.

I didn't think this code was triggered outside of interrupt context, but
it possibly is when using a serial console - which is the only
explanation I can think of for the behaviour you've described.

Thanks


---
 drivers/staging/speakup/main.c |    5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

--- a/drivers/staging/speakup/main.c
+++ b/drivers/staging/speakup/main.c
@@ -1408,7 +1408,10 @@ static void read_all_doc(struct vc_data
 	cursor_track = read_all_mode;
 	spk_reset_index_count(0);
 	if (get_sentence_buf(vc, 0) == -1) {
-		kbd_fakekey2(vc, RA_DOWN_ARROW);
+		del_timer(&cursor_timer);
+		if (!in_interrupt())
+			speakup_fake_down_arrow();
+		start_read_all_timer(vc, RA_DOWN_ARROW);
 	} else {
 		say_sentence_num(0, 0);
 		synth_insert_next_index(0);

Re: speakup-r functionality

[John Covici]

I tried the new patch, but no joy.  I hope you can fix your serial
synth to test.

Thanks for trying.


On Sun, 20 Aug 2017 17:45:27 -0400,
Okash Khawaja wrote:
> 
> Hi,
> 
> Here's one thing I think worth trying. I have updated the patch so that
> the net difference between before and after the patch is that
> speakup_fake_down_arrow() is not called when inside interrupt context.
> 
> Calling speakup_fake_down_arrow() inside interrupt causes the kernel
> lock up because this itself generates same interrupt, leading to
> infinite recursion.
> 
> I didn't think this code was triggered outside of interrupt context, but
> it possibly is when using a serial console - which is the only
> explanation I can think of for the behaviour you've described.
> 
> Thanks
> 
> 
> ---
>  drivers/staging/speakup/main.c |    5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> --- a/drivers/staging/speakup/main.c
> +++ b/drivers/staging/speakup/main.c
> @@ -1408,7 +1408,10 @@ static void read_all_doc(struct vc_data
>  	cursor_track = read_all_mode;
>  	spk_reset_index_count(0);
>  	if (get_sentence_buf(vc, 0) == -1) {
> -		kbd_fakekey2(vc, RA_DOWN_ARROW);
> +		del_timer(&cursor_timer);
> +		if (!in_interrupt())
> +			speakup_fake_down_arrow();
> +		start_read_all_timer(vc, RA_DOWN_ARROW);
>  	} else {
>  		say_sentence_num(0, 0);
>  		synth_insert_next_index(0);

-- 
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

         John Covici
         covici@ccs.covici.com

Re: speakup-r functionality

[Okash Khawaja]

Okay then it must be that speakup_fake_down_arrow() is called from inside a
different interrupt when on serial synth. Otherwise it would have caused
kernel lock up.

Thanks very much for testing. I'll try to fix my serial synth.

Cheers,
Okash

On 21 Aug 2017 4:33 am, "John Covici" <covici@ccs.covici.com> wrote:

I tried the new patch, but no joy.  I hope you can fix your serial
synth to test.

Thanks for trying.


On Sun, 20 Aug 2017 17:45:27 -0400,
Okash Khawaja wrote:
>
> Hi,
>
> Here's one thing I think worth trying. I have updated the patch so that
> the net difference between before and after the patch is that
> speakup_fake_down_arrow() is not called when inside interrupt context.
>
> Calling speakup_fake_down_arrow() inside interrupt causes the kernel
> lock up because this itself generates same interrupt, leading to
> infinite recursion.
>
> I didn't think this code was triggered outside of interrupt context, but
> it possibly is when using a serial console - which is the only
> explanation I can think of for the behaviour you've described.
>
> Thanks
>
>
> ---
>  drivers/staging/speakup/main.c |    5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> --- a/drivers/staging/speakup/main.c
> +++ b/drivers/staging/speakup/main.c
> @@ -1408,7 +1408,10 @@ static void read_all_doc(struct vc_data
>       cursor_track = read_all_mode;
>       spk_reset_index_count(0);
>       if (get_sentence_buf(vc, 0) == -1) {
> -             kbd_fakekey2(vc, RA_DOWN_ARROW);
> +             del_timer(&cursor_timer);
> +             if (!in_interrupt())
> +                     speakup_fake_down_arrow();
> +             start_read_all_timer(vc, RA_DOWN_ARROW);
>       } else {
>               say_sentence_num(0, 0);
>               synth_insert_next_index(0);

--
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

         John Covici
         covici@ccs.covici.com