* speakup-r empty line lockup
@ Okash Khawaja
` Samuel Thibault
` (3 more replies)
0 siblings, 4 replies; 27+ messages in thread
From: Okash Khawaja @ UTC (permalink / raw)
To: speakup; +Cc: John Covici, Samuel Thibault
Hi,
The lockup when running speakup-r at start of an empty line occurs
because simulated key press is generated (using speakup_fake_down_arrow)
from context of keyboard_notifier_call callback which is called in
interrupt context. The simulated keypress leads to
keybaord_notifier_call to be trigerred again from the same context
leading to the lockup. The exact cause could be priority inversion where
simulated keypress cannot be processed because there is a real keyboard
interrupt already being processed (the one from which simulated keypress
was triggered), hence causing a deadlock. Please share your thoughts on
this. Here is the call chain.
(speakup-r) --> keyboard_notifier_call --> speakup_key --> do_spkup -->
read_all_doc --> get_sentence_buf [which returns -1 because of empty
line] --> kbd_fakekey2(RA_DOWN_ARROW) --> speakup_fake_down_arrow
The following patch resolves this by not simulating the keypress inside
keyboard notifier callback but instead delegating it to cursor_timer. In
the above chain, when get_sentence_buf returns -1, this patch starts
timer and passes RA_DOWN_ARROW as argument. When timer handler runs and
sees RA_DOWN_ARROW, it will then call kbd_fakekey2(RA_DOWN_ARROW) which
will correctly simulate the keypress inside timer context. I've tested
this succesfully.
It's the first time I've worked on this side of the code so please
review carefully :)
Finally, I have updated the test repo on github so you can test from
there.
Thanks,
Okash
---
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);
^ permalink raw reply [flat|nested] 27+ messages in thread* Re: speakup-r empty line lockup speakup-r empty line lockup Okash Khawaja @ ` Samuel Thibault ` Chris Brannon ` (2 subsequent siblings) 3 siblings, 0 replies; 27+ messages in thread From: Samuel Thibault @ UTC (permalink / raw) To: Okash Khawaja; +Cc: speakup, John Covici Hello, Okash Khawaja, on sam. 24 juin 2017 10:06:45 +0100, wrote: > It's the first time I've worked on this side of the code so please > review carefully :) Well, I'd say you're on your own on this one, unless elder developers remember something :) >From what I can see and understand, I'd say Reviewed-by: Samuel Thibault <samuel.thibault@ens-lyon.org> Samuel ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: speakup-r empty line lockup speakup-r empty line lockup Okash Khawaja ` Samuel Thibault @ ` Chris Brannon ` John Covici ` John Covici 3 siblings, 0 replies; 27+ messages in thread From: Chris Brannon @ UTC (permalink / raw) To: Okash Khawaja; +Cc: speakup, John Covici Okash Khawaja <okash.khawaja@gmail.com> writes: > The following patch resolves this by not simulating the keypress inside > keyboard notifier callback but instead delegating it to cursor_timer. In > the above chain, when get_sentence_buf returns -1, this patch starts > timer and passes RA_DOWN_ARROW as argument. When timer handler runs and > sees RA_DOWN_ARROW, it will then call kbd_fakekey2(RA_DOWN_ARROW) which > will correctly simulate the keypress inside timer context. I've tested > this succesfully. I wrote the fakekey code back in 2010, but I don't remember details. Your reasoning looks very, very sound, so you get my tentative Reviewed-by: Chris Brannon <chris@the-brannons.com> ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: speakup-r empty line lockup speakup-r empty line lockup Okash Khawaja ` Samuel Thibault ` Chris Brannon @ ` John Covici ` Okash Khawaja ` John Covici 3 siblings, 1 reply; 27+ messages in thread From: John Covici @ UTC (permalink / raw) To: Okash Khawaja; +Cc: speakup, Samuel Thibault Thanks a lot, I will definitely test this -- do I need a new export.patch as well? On Sat, 24 Jun 2017 05:06:45 -0400, Okash Khawaja wrote: > > Hi, > > The lockup when running speakup-r at start of an empty line occurs > because simulated key press is generated (using speakup_fake_down_arrow) > from context of keyboard_notifier_call callback which is called in > interrupt context. The simulated keypress leads to > keybaord_notifier_call to be trigerred again from the same context > leading to the lockup. The exact cause could be priority inversion where > simulated keypress cannot be processed because there is a real keyboard > interrupt already being processed (the one from which simulated keypress > was triggered), hence causing a deadlock. Please share your thoughts on > this. Here is the call chain. > > (speakup-r) --> keyboard_notifier_call --> speakup_key --> do_spkup --> > read_all_doc --> get_sentence_buf [which returns -1 because of empty > line] --> kbd_fakekey2(RA_DOWN_ARROW) --> speakup_fake_down_arrow > > The following patch resolves this by not simulating the keypress inside > keyboard notifier callback but instead delegating it to cursor_timer. In > the above chain, when get_sentence_buf returns -1, this patch starts > timer and passes RA_DOWN_ARROW as argument. When timer handler runs and > sees RA_DOWN_ARROW, it will then call kbd_fakekey2(RA_DOWN_ARROW) which > will correctly simulate the keypress inside timer context. I've tested > this succesfully. > > It's the first time I've worked on this side of the code so please > review carefully :) > > Finally, I have updated the test repo on github so you can test from > there. > > Thanks, > Okash > > --- > 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); -- 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: speakup-r empty line lockup ` John Covici @ ` Okash Khawaja 0 siblings, 0 replies; 27+ messages in thread From: Okash Khawaja @ UTC (permalink / raw) To: covici; +Cc: speakup, Samuel Thibault Yes export-tty.patch on the repo has been updated. Let me know if you get any problems. Cheers, Okash > On 24 Jun 2017, at 11:12, John Covici <covici@ccs.covici.com> wrote: > > Thanks a lot, I will definitely test this -- do I need a new > export.patch as well? > > On Sat, 24 Jun 2017 05:06:45 -0400, > Okash Khawaja wrote: >> >> Hi, >> >> The lockup when running speakup-r at start of an empty line occurs >> because simulated key press is generated (using speakup_fake_down_arrow) >> from context of keyboard_notifier_call callback which is called in >> interrupt context. The simulated keypress leads to >> keybaord_notifier_call to be trigerred again from the same context >> leading to the lockup. The exact cause could be priority inversion where >> simulated keypress cannot be processed because there is a real keyboard >> interrupt already being processed (the one from which simulated keypress >> was triggered), hence causing a deadlock. Please share your thoughts on >> this. Here is the call chain. >> >> (speakup-r) --> keyboard_notifier_call --> speakup_key --> do_spkup --> >> read_all_doc --> get_sentence_buf [which returns -1 because of empty >> line] --> kbd_fakekey2(RA_DOWN_ARROW) --> speakup_fake_down_arrow >> >> The following patch resolves this by not simulating the keypress inside >> keyboard notifier callback but instead delegating it to cursor_timer. In >> the above chain, when get_sentence_buf returns -1, this patch starts >> timer and passes RA_DOWN_ARROW as argument. When timer handler runs and >> sees RA_DOWN_ARROW, it will then call kbd_fakekey2(RA_DOWN_ARROW) which >> will correctly simulate the keypress inside timer context. I've tested >> this succesfully. >> >> It's the first time I've worked on this side of the code so please >> review carefully :) >> >> Finally, I have updated the test repo on github so you can test from >> there. >> >> Thanks, >> Okash >> >> --- >> 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); > > -- > 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: speakup-r empty line lockup speakup-r empty line lockup Okash Khawaja ` (2 preceding siblings ...) ` John Covici @ ` John Covici ` Okash Khawaja 3 siblings, 1 reply; 27+ messages in thread From: John Covici @ UTC (permalink / raw) To: Okash Khawaja; +Cc: speakup, Samuel Thibault I just tested the empty line lockup is gone, but now speakup-r does not work, actually in the file I had, after reading a number of lines when I hit control, the cursor was actually at the end of the file. Thanks for working on this one. On Sat, 24 Jun 2017 05:06:45 -0400, Okash Khawaja wrote: > > Hi, > > The lockup when running speakup-r at start of an empty line occurs > because simulated key press is generated (using speakup_fake_down_arrow) > from context of keyboard_notifier_call callback which is called in > interrupt context. The simulated keypress leads to > keybaord_notifier_call to be trigerred again from the same context > leading to the lockup. The exact cause could be priority inversion where > simulated keypress cannot be processed because there is a real keyboard > interrupt already being processed (the one from which simulated keypress > was triggered), hence causing a deadlock. Please share your thoughts on > this. Here is the call chain. > > (speakup-r) --> keyboard_notifier_call --> speakup_key --> do_spkup --> > read_all_doc --> get_sentence_buf [which returns -1 because of empty > line] --> kbd_fakekey2(RA_DOWN_ARROW) --> speakup_fake_down_arrow > > The following patch resolves this by not simulating the keypress inside > keyboard notifier callback but instead delegating it to cursor_timer. In > the above chain, when get_sentence_buf returns -1, this patch starts > timer and passes RA_DOWN_ARROW as argument. When timer handler runs and > sees RA_DOWN_ARROW, it will then call kbd_fakekey2(RA_DOWN_ARROW) which > will correctly simulate the keypress inside timer context. I've tested > this succesfully. > > It's the first time I've worked on this side of the code so please > review carefully :) > > Finally, I have updated the test repo on github so you can test from > there. > > Thanks, > Okash > > --- > 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); -- 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: speakup-r empty line lockup ` John Covici @ ` Okash Khawaja ` Okash Khawaja ` John Covici 0 siblings, 2 replies; 27+ messages in thread From: Okash Khawaja @ UTC (permalink / raw) To: John Covici; +Cc: speakup, Samuel Thibault Hi, This looks like the problem you raised previously, the one which was resolved by calling flush_buffers. Is this happening on ttyUSB? usb-serial driver doesn't implement flush_buffers method which means that speakup-r will have this issue until there is flush_buffers in usb-serial. Thanks, Okash On Mon, Jul 03, 2017 at 05:52:19AM -0400, John Covici wrote: > I just tested the empty line lockup is gone, but now speakup-r does > not work, actually in the file I had, after reading a number of lines > when I hit control, the cursor was actually at the end of the file. > > Thanks for working on this one. > > On Sat, 24 Jun 2017 05:06:45 -0400, > Okash Khawaja wrote: > > > > Hi, > > > > The lockup when running speakup-r at start of an empty line occurs > > because simulated key press is generated (using speakup_fake_down_arrow) > > from context of keyboard_notifier_call callback which is called in > > interrupt context. The simulated keypress leads to > > keybaord_notifier_call to be trigerred again from the same context > > leading to the lockup. The exact cause could be priority inversion where > > simulated keypress cannot be processed because there is a real keyboard > > interrupt already being processed (the one from which simulated keypress > > was triggered), hence causing a deadlock. Please share your thoughts on > > this. Here is the call chain. > > > > (speakup-r) --> keyboard_notifier_call --> speakup_key --> do_spkup --> > > read_all_doc --> get_sentence_buf [which returns -1 because of empty > > line] --> kbd_fakekey2(RA_DOWN_ARROW) --> speakup_fake_down_arrow > > > > The following patch resolves this by not simulating the keypress inside > > keyboard notifier callback but instead delegating it to cursor_timer. In > > the above chain, when get_sentence_buf returns -1, this patch starts > > timer and passes RA_DOWN_ARROW as argument. When timer handler runs and > > sees RA_DOWN_ARROW, it will then call kbd_fakekey2(RA_DOWN_ARROW) which > > will correctly simulate the keypress inside timer context. I've tested > > this succesfully. > > > > It's the first time I've worked on this side of the code so please > > review carefully :) > > > > Finally, I have updated the test repo on github so you can test from > > there. > > > > Thanks, > > Okash > > > > --- > > 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); > > -- > 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: speakup-r empty line lockup ` Okash Khawaja @ ` Okash Khawaja ` John Covici 1 sibling, 0 replies; 27+ messages in thread From: Okash Khawaja @ UTC (permalink / raw) To: John Covici; +Cc: speakup, Samuel Thibault When I test speakup-r with speakup_soft + espeakup, it doesn't behave the way it should. That is true with or without this patch. May be I've missed something but here is what I did. Open spkguide.txt in vim. Move cursor to beginning of the line "Permission is granted to copy...". Hit keyboard ins + r. Cursor immediately moves to beginning of next line "under the terms of..." and the speaking starts. Speaking stops after finishing the next line, i.e. the "under the terms of..." line. It stops automatically. So at this stage cursor is at beginning of that line while speaking stopped at end of that line. This is behaviour is same both with and without the patch, so I am unable to test it. Again, if this problem happens on ttyUSB* but doesn't happen on ttyS* then that is because usb-serial doesn't implement flush data. Thanks, Okash On Mon, Jul 03, 2017 at 12:14:53PM +0100, Okash Khawaja wrote: > Hi, > > This looks like the problem you raised previously, the one which was > resolved by calling flush_buffers. Is this happening on ttyUSB? > usb-serial driver doesn't implement flush_buffers method which means > that speakup-r will have this issue until there is flush_buffers in > usb-serial. > > Thanks, > Okash > > On Mon, Jul 03, 2017 at 05:52:19AM -0400, John Covici wrote: > > I just tested the empty line lockup is gone, but now speakup-r does > > not work, actually in the file I had, after reading a number of lines > > when I hit control, the cursor was actually at the end of the file. > > > > Thanks for working on this one. > > > > On Sat, 24 Jun 2017 05:06:45 -0400, > > Okash Khawaja wrote: > > > > > > Hi, > > > > > > The lockup when running speakup-r at start of an empty line occurs > > > because simulated key press is generated (using speakup_fake_down_arrow) > > > from context of keyboard_notifier_call callback which is called in > > > interrupt context. The simulated keypress leads to > > > keybaord_notifier_call to be trigerred again from the same context > > > leading to the lockup. The exact cause could be priority inversion where > > > simulated keypress cannot be processed because there is a real keyboard > > > interrupt already being processed (the one from which simulated keypress > > > was triggered), hence causing a deadlock. Please share your thoughts on > > > this. Here is the call chain. > > > > > > (speakup-r) --> keyboard_notifier_call --> speakup_key --> do_spkup --> > > > read_all_doc --> get_sentence_buf [which returns -1 because of empty > > > line] --> kbd_fakekey2(RA_DOWN_ARROW) --> speakup_fake_down_arrow > > > > > > The following patch resolves this by not simulating the keypress inside > > > keyboard notifier callback but instead delegating it to cursor_timer. In > > > the above chain, when get_sentence_buf returns -1, this patch starts > > > timer and passes RA_DOWN_ARROW as argument. When timer handler runs and > > > sees RA_DOWN_ARROW, it will then call kbd_fakekey2(RA_DOWN_ARROW) which > > > will correctly simulate the keypress inside timer context. I've tested > > > this succesfully. > > > > > > It's the first time I've worked on this side of the code so please > > > review carefully :) > > > > > > Finally, I have updated the test repo on github so you can test from > > > there. > > > > > > Thanks, > > > Okash > > > > > > --- > > > 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); > > > > -- > > 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: speakup-r empty line lockup ` Okash Khawaja ` Okash Khawaja @ ` John Covici ` Okash Khawaja ` Okash Khawaja 1 sibling, 2 replies; 27+ messages in thread From: John Covici @ UTC (permalink / raw) To: Okash Khawaja; +Cc: speakup, Samuel Thibault Mope, its on regular serial, somehow your fix broke it. On Mon, 03 Jul 2017 07:14:53 -0400, Okash Khawaja wrote: > > Hi, > > This looks like the problem you raised previously, the one which was > resolved by calling flush_buffers. Is this happening on ttyUSB? > usb-serial driver doesn't implement flush_buffers method which means > that speakup-r will have this issue until there is flush_buffers in > usb-serial. > > Thanks, > Okash > > On Mon, Jul 03, 2017 at 05:52:19AM -0400, John Covici wrote: > > I just tested the empty line lockup is gone, but now speakup-r does > > not work, actually in the file I had, after reading a number of lines > > when I hit control, the cursor was actually at the end of the file. > > > > Thanks for working on this one. > > > > On Sat, 24 Jun 2017 05:06:45 -0400, > > Okash Khawaja wrote: > > > > > > Hi, > > > > > > The lockup when running speakup-r at start of an empty line occurs > > > because simulated key press is generated (using speakup_fake_down_arrow) > > > from context of keyboard_notifier_call callback which is called in > > > interrupt context. The simulated keypress leads to > > > keybaord_notifier_call to be trigerred again from the same context > > > leading to the lockup. The exact cause could be priority inversion where > > > simulated keypress cannot be processed because there is a real keyboard > > > interrupt already being processed (the one from which simulated keypress > > > was triggered), hence causing a deadlock. Please share your thoughts on > > > this. Here is the call chain. > > > > > > (speakup-r) --> keyboard_notifier_call --> speakup_key --> do_spkup --> > > > read_all_doc --> get_sentence_buf [which returns -1 because of empty > > > line] --> kbd_fakekey2(RA_DOWN_ARROW) --> speakup_fake_down_arrow > > > > > > The following patch resolves this by not simulating the keypress inside > > > keyboard notifier callback but instead delegating it to cursor_timer. In > > > the above chain, when get_sentence_buf returns -1, this patch starts > > > timer and passes RA_DOWN_ARROW as argument. When timer handler runs and > > > sees RA_DOWN_ARROW, it will then call kbd_fakekey2(RA_DOWN_ARROW) which > > > will correctly simulate the keypress inside timer context. I've tested > > > this succesfully. > > > > > > It's the first time I've worked on this side of the code so please > > > review carefully :) > > > > > > Finally, I have updated the test repo on github so you can test from > > > there. > > > > > > Thanks, > > > Okash > > > > > > --- > > > 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); > > > > -- > > 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: speakup-r empty line lockup ` John Covici @ ` Okash Khawaja ` Okash Khawaja 1 sibling, 0 replies; 27+ messages in thread From: Okash Khawaja @ UTC (permalink / raw) To: John Covici; +Cc: speakup, Samuel Thibault Thanks, I'm looking into it. On Wed, Jul 05, 2017 at 06:54:13AM -0400, John Covici wrote: > Mope, its on regular serial, somehow your fix broke it. > > On Mon, 03 Jul 2017 07:14:53 -0400, > Okash Khawaja wrote: > > > > Hi, > > > > This looks like the problem you raised previously, the one which was > > resolved by calling flush_buffers. Is this happening on ttyUSB? > > usb-serial driver doesn't implement flush_buffers method which means > > that speakup-r will have this issue until there is flush_buffers in > > usb-serial. > > > > Thanks, > > Okash > > > > On Mon, Jul 03, 2017 at 05:52:19AM -0400, John Covici wrote: > > > I just tested the empty line lockup is gone, but now speakup-r does > > > not work, actually in the file I had, after reading a number of lines > > > when I hit control, the cursor was actually at the end of the file. > > > > > > Thanks for working on this one. > > > > > > On Sat, 24 Jun 2017 05:06:45 -0400, > > > Okash Khawaja wrote: > > > > > > > > Hi, > > > > > > > > The lockup when running speakup-r at start of an empty line occurs > > > > because simulated key press is generated (using speakup_fake_down_arrow) > > > > from context of keyboard_notifier_call callback which is called in > > > > interrupt context. The simulated keypress leads to > > > > keybaord_notifier_call to be trigerred again from the same context > > > > leading to the lockup. The exact cause could be priority inversion where > > > > simulated keypress cannot be processed because there is a real keyboard > > > > interrupt already being processed (the one from which simulated keypress > > > > was triggered), hence causing a deadlock. Please share your thoughts on > > > > this. Here is the call chain. > > > > > > > > (speakup-r) --> keyboard_notifier_call --> speakup_key --> do_spkup --> > > > > read_all_doc --> get_sentence_buf [which returns -1 because of empty > > > > line] --> kbd_fakekey2(RA_DOWN_ARROW) --> speakup_fake_down_arrow > > > > > > > > The following patch resolves this by not simulating the keypress inside > > > > keyboard notifier callback but instead delegating it to cursor_timer. In > > > > the above chain, when get_sentence_buf returns -1, this patch starts > > > > timer and passes RA_DOWN_ARROW as argument. When timer handler runs and > > > > sees RA_DOWN_ARROW, it will then call kbd_fakekey2(RA_DOWN_ARROW) which > > > > will correctly simulate the keypress inside timer context. I've tested > > > > this succesfully. > > > > > > > > It's the first time I've worked on this side of the code so please > > > > review carefully :) > > > > > > > > Finally, I have updated the test repo on github so you can test from > > > > there. > > > > > > > > Thanks, > > > > Okash > > > > > > > > --- > > > > 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); > > > > > > -- > > > 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: speakup-r empty line lockup ` John Covici ` Okash Khawaja @ ` Okash Khawaja ` Chris Brannon 1 sibling, 1 reply; 27+ messages in thread From: Okash Khawaja @ UTC (permalink / raw) To: John Covici; +Cc: speakup, Samuel Thibault Hi, I used printk to output result of in_interrupt() when the affected code is called. It looks like the affected code is only called when inside interrupt context, i.e. when keyboard_notifier_callback is called and that's when we can't call speakup_fake_down_arrow as that leads to lockup, as explained earlier in this thread. Given limited scope of the change - it is only called when running speakup-r from empty line - I can't work out how this results in cursor going to the end of file when control is hit. However, I say this based on speakup_soft + espeakup test in which speakup-r stops automatically after reading two lines (both before and after this patch). So until I am able to replicate the problem, it will be hard for me to test. The triple talk I bricked, I haven't got round to fixing it yet - if it can be fixed. If there is any additional information that might be relevant, that will be helpful. Until then, I will try to work out what might be happening. Since the github repo contains this and other changes, it will be interesting to check if the problem is down to this change or is a result of other changes that also went in. Thanks, Okash On Wed, Jul 05, 2017 at 06:54:13AM -0400, John Covici wrote: > Mope, its on regular serial, somehow your fix broke it. > > On Mon, 03 Jul 2017 07:14:53 -0400, > Okash Khawaja wrote: > > > > Hi, > > > > This looks like the problem you raised previously, the one which was > > resolved by calling flush_buffers. Is this happening on ttyUSB? > > usb-serial driver doesn't implement flush_buffers method which means > > that speakup-r will have this issue until there is flush_buffers in > > usb-serial. > > > > Thanks, > > Okash > > > > On Mon, Jul 03, 2017 at 05:52:19AM -0400, John Covici wrote: > > > I just tested the empty line lockup is gone, but now speakup-r does > > > not work, actually in the file I had, after reading a number of lines > > > when I hit control, the cursor was actually at the end of the file. > > > > > > Thanks for working on this one. > > > > > > On Sat, 24 Jun 2017 05:06:45 -0400, > > > Okash Khawaja wrote: > > > > > > > > Hi, > > > > > > > > The lockup when running speakup-r at start of an empty line occurs > > > > because simulated key press is generated (using speakup_fake_down_arrow) > > > > from context of keyboard_notifier_call callback which is called in > > > > interrupt context. The simulated keypress leads to > > > > keybaord_notifier_call to be trigerred again from the same context > > > > leading to the lockup. The exact cause could be priority inversion where > > > > simulated keypress cannot be processed because there is a real keyboard > > > > interrupt already being processed (the one from which simulated keypress > > > > was triggered), hence causing a deadlock. Please share your thoughts on > > > > this. Here is the call chain. > > > > > > > > (speakup-r) --> keyboard_notifier_call --> speakup_key --> do_spkup --> > > > > read_all_doc --> get_sentence_buf [which returns -1 because of empty > > > > line] --> kbd_fakekey2(RA_DOWN_ARROW) --> speakup_fake_down_arrow > > > > > > > > The following patch resolves this by not simulating the keypress inside > > > > keyboard notifier callback but instead delegating it to cursor_timer. In > > > > the above chain, when get_sentence_buf returns -1, this patch starts > > > > timer and passes RA_DOWN_ARROW as argument. When timer handler runs and > > > > sees RA_DOWN_ARROW, it will then call kbd_fakekey2(RA_DOWN_ARROW) which > > > > will correctly simulate the keypress inside timer context. I've tested > > > > this succesfully. > > > > > > > > It's the first time I've worked on this side of the code so please > > > > review carefully :) > > > > > > > > Finally, I have updated the test repo on github so you can test from > > > > there. > > > > > > > > Thanks, > > > > Okash > > > > > > > > --- > > > > 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); > > > > > > -- > > > 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: speakup-r empty line lockup ` Okash Khawaja @ ` Chris Brannon ` John Covici 0 siblings, 1 reply; 27+ messages in thread From: Chris Brannon @ UTC (permalink / raw) To: Okash Khawaja; +Cc: John Covici, Speakup is a screen review system for Linux. Okash Khawaja <okash.khawaja@gmail.com> writes: > Given limited scope of the change - it is only called when running > speakup-r from empty line - I can't work out how this results in cursor > going to the end of file when control is hit. However, I say this based > on speakup_soft + espeakup test in which speakup-r stops automatically > after reading two lines (both before and after this patch). espeakup was never modified to support speakup-r. I think speechd-up may have done it. Code is at https://github.com/WilliamH/speechd-up but I don't know what is involved in getting it running these days. -- Chris ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: speakup-r empty line lockup ` Chris Brannon @ ` John Covici ` Okash Khawaja 0 siblings, 1 reply; 27+ messages in thread From: John Covici @ UTC (permalink / raw) To: Chris Brannon; +Cc: Okash Khawaja, Speakup is a screen review system for Linux. speakup-r did work with speechd-up, last time I tried it. On Wed, 05 Jul 2017 16:00:05 -0400, Chris Brannon wrote: > > Okash Khawaja <okash.khawaja@gmail.com> writes: > > > Given limited scope of the change - it is only called when running > > speakup-r from empty line - I can't work out how this results in cursor > > going to the end of file when control is hit. However, I say this based > > on speakup_soft + espeakup test in which speakup-r stops automatically > > after reading two lines (both before and after this patch). > > espeakup was never modified to support speakup-r. I think speechd-up > may have done it. Code is at https://github.com/WilliamH/speechd-up but > I don't know what is involved in getting it running these days. > > -- Chris -- 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: speakup-r empty line lockup ` John Covici @ ` Okash Khawaja ` Okash Khawaja 0 siblings, 1 reply; 27+ messages in thread From: Okash Khawaja @ UTC (permalink / raw) To: covici; +Cc: Chris Brannon, Speakup is a screen review system for Linux. Awesome. That's great > On 5 Jul 2017, at 21:02, John Covici <covici@ccs.covici.com> wrote: > > speakup-r did work with speechd-up, last time I tried it. > > On Wed, 05 Jul 2017 16:00:05 -0400, > Chris Brannon wrote: >> >> Okash Khawaja <okash.khawaja@gmail.com> writes: >> >>> Given limited scope of the change - it is only called when running >>> speakup-r from empty line - I can't work out how this results in cursor >>> going to the end of file when control is hit. However, I say this based >>> on speakup_soft + espeakup test in which speakup-r stops automatically >>> after reading two lines (both before and after this patch). >> >> espeakup was never modified to support speakup-r. I think speechd-up >> may have done it. Code is at https://github.com/WilliamH/speechd-up but >> I don't know what is involved in getting it running these days. >> >> -- Chris > > -- > 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: speakup-r empty line lockup ` Okash Khawaja @ ` Okash Khawaja ` John Covici ` Samuel Thibault 0 siblings, 2 replies; 27+ messages in thread From: Okash Khawaja @ UTC (permalink / raw) To: John Covici; +Cc: Speakup is a screen review system for Linux. Hi John, I'm now trying to replicate the problem where cursor goes to end of file when hitting control after reading several lines with speakup-r. I'm testing it on spkguide.txt. Starting from beginning I went up to line 45. Hitting control stopped reading and cursor was at beginning of next line to the one being read. Would you suggest reading more lines? BTW, when running speakup-r, cursor always jumps to beginning of next line while reading current line. That's same, with or without the change I made. Thanks, Okash On 5 Jul 2017 9:07 pm, "Okash Khawaja" <okash.khawaja@gmail.com> wrote: > Awesome. That's great > > > On 5 Jul 2017, at 21:02, John Covici <covici@ccs.covici.com> wrote: > > > > speakup-r did work with speechd-up, last time I tried it. > > > > On Wed, 05 Jul 2017 16:00:05 -0400, > > Chris Brannon wrote: > >> > >> Okash Khawaja <okash.khawaja@gmail.com> writes: > >> > >>> Given limited scope of the change - it is only called when running > >>> speakup-r from empty line - I can't work out how this results in cursor > >>> going to the end of file when control is hit. However, I say this based > >>> on speakup_soft + espeakup test in which speakup-r stops automatically > >>> after reading two lines (both before and after this patch). > >> > >> espeakup was never modified to support speakup-r. I think speechd-up > >> may have done it. Code is at https://github.com/WilliamH/speechd-up > but > >> I don't know what is involved in getting it running these days. > >> > >> -- Chris > > > > -- > > 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 > ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: speakup-r empty line lockup ` Okash Khawaja @ ` John Covici ` Samuel Thibault 1 sibling, 0 replies; 27+ messages in thread From: John Covici @ UTC (permalink / raw) To: Okash Khawaja; +Cc: Speakup is a screen review system for Linux. hmmm, I will have to try this again. I know I didn't read that many lines. I think it went to the end because it ran out of lines. If you say its not doing that for you, I will have to retest and see what happens. On Fri, 18 Aug 2017 03:17:33 -0400, Okash Khawaja wrote: > > [1 <text/plain; UTF-8 (7bit)>] > [2 <text/html; UTF-8 (quoted-printable)>] > Hi John, > > I'm now trying to replicate the problem where cursor goes to end of file when hitting control after reading several lines with speakup-r. I'm testing it on spkguide.txt. Starting from beginning I went up to line 45. Hitting control > stopped reading and cursor was at beginning of next line to the one being read. > > Would you suggest reading more lines? BTW, when running speakup-r, cursor always jumps to beginning of next line while reading current line. That's same, with or without the change I made. > > Thanks, > Okash > > On 5 Jul 2017 9:07 pm, "Okash Khawaja" <okash.khawaja@gmail.com> wrote: > > Awesome. That's great > > > On 5 Jul 2017, at 21:02, John Covici <covici@ccs.covici.com> wrote: > > > > speakup-r did work with speechd-up, last time I tried it. > > > > On Wed, 05 Jul 2017 16:00:05 -0400, > > Chris Brannon wrote: > >> > >> Okash Khawaja <okash.khawaja@gmail.com> writes: > >> > >>> Given limited scope of the change - it is only called when running > >>> speakup-r from empty line - I can't work out how this results in cursor > >>> going to the end of file when control is hit. However, I say this based > >>> on speakup_soft + espeakup test in which speakup-r stops automatically > >>> after reading two lines (both before and after this patch). > >> > >> espeakup was never modified to support speakup-r. I think speechd-up > >> may have done it. Code is at https://github.com/WilliamH/speechd-up but > >> I don't know what is involved in getting it running these days. > >> > >> -- Chris > > > > -- > > 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: speakup-r empty line lockup ` Okash Khawaja ` John Covici @ ` Samuel Thibault ` Okash Khawaja 1 sibling, 1 reply; 27+ messages in thread From: Samuel Thibault @ UTC (permalink / raw) To: Speakup is a screen review system for Linux.; +Cc: John Covici Okash Khawaja, on ven. 18 août 2017 08:17:33 +0100, wrote: > Would you suggest reading more lines? The point of the feature is that by typing control, you stop the speech at the place where you want to bring the cursor to :) Samuel ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: speakup-r empty line lockup ` Samuel Thibault @ ` Okash Khawaja ` Kirk Reiser 0 siblings, 1 reply; 27+ messages in thread From: Okash Khawaja @ UTC (permalink / raw) To: Speakup is a screen review system for Linux. On Sat, Aug 19, 2017 at 01:11:39AM +0200, Samuel Thibault wrote: > Okash Khawaja, on ven. 18 ao??t 2017 08:17:33 +0100, wrote: > > Would you suggest reading more lines? > > The point of the feature is that by typing control, you stop the speech > at the place where you want to bring the cursor to :) I see... So the use case is that you can move the cursor to a line where you want the speech to stop and hit control, so that hitting speakup-r again will then start speaking from that line. Is that right? Thanks, Okash ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: speakup-r empty line lockup ` Okash Khawaja @ ` Kirk Reiser ` Chime Hart ` Janina Sajka 0 siblings, 2 replies; 27+ messages in thread From: Kirk Reiser @ UTC (permalink / raw) To: Speakup is a screen review system for Linux. Hahahah, close. The object is you can hit speakup-r and speakup will start reading the document from where the cursor is until you tap the control, shift or whatever silence key and it will place the cursor at the position you heard whent you tapped the key. That way one can continuously read a document in an edittor and have the cursor able to start again where you hit the silence key for further reading or editting. Kirk On Sun, 20 Aug 2017, Okash Khawaja wrote: > On Sat, Aug 19, 2017 at 01:11:39AM +0200, Samuel Thibault wrote: >> Okash Khawaja, on ven. 18 ao??t 2017 08:17:33 +0100, wrote: >> > Would you suggest reading more lines? >> >> The point of the feature is that by typing control, you stop the speech >> at the place where you want to bring the cursor to :) > > I see... So the use case is that you can move the cursor to a line > where you want the speech to stop and hit control, so that hitting > speakup-r again will then start speaking from that line. Is that right? > > Thanks, > Okash > _______________________________________________ > Speakup mailing list > Speakup@linux-speakup.org > http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup -- Well that's it then, colour me secure! -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1 mQENBFYV5DMBCAC060mbsnLhGPjnFkf0R0p+7MxcfxlOuy5wc8y59y9ZNF0RZD1s OTEsDih4vD9YJ3zA78VsBUDK47aiDWduh3nHzYN2ZSuxAQ9u7qPqphCG0jPagTU8 p7+Ceeya4I5odWtq+Nkf1UrHB7KKEtexphStSwUG5Bhi4bb84YinmX/a3I+OGV1D by4QBSdPvSuDw0qFkt/ucLyEwv4L6lDjoH2GF+tnCew4SJtliJFvA1k7NpWO6HW9 aWtBxfYU85ccZKBSE25y+9KprUCncVTpaVs3FztCWG0dQRXHvEbV+Damp/IBd9Jv HZX7azqbERUa/FjPTIlZhhI9VtaZaFfJSH+5ABEBAAG0HUtpcmsgUmVpc2VyIDxr aXJrQHJlaXNlcnMuY2E+iQE+BBMBAgAoBQJWFeQzAhsDBQkADS8ABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAAKCRAHTEsk7UQUUoeuB/wIqsdLCfDrSvr3qg7rKBDg ru44OMuRit6hbdWFZjmxccCdjeNhBJRVd5wrEqjj5YoqQAhmacXaEB0DO/TZlDgo kUfJM7lrtQD4mYU9GVtrzJxCJoBUyeMVnMJt39F91tBu0mYM6oI/dv81dwxIv++4 hj55TZ4GG7DGYAy4LwNb+noNbivgOFHlnfNq8nxhZkHbJdYKP+sptZOL5sagmBQZ iS9STB54g/U7Jtt1Fe+JwDmbxQhbSHa9JuWn0xZ8CtYhrz06xSqZl5vpMlak3eW2 x6m6IcqZfyuI2K7W/9BCgcsQyYzufO4Gk9KyPNISskX6pFBLuNxIH6hdfxSYYm9y uQENBFYV5DMBCACtMyhHog5MR6eQUPTx7fWH5ntkgCtmWvQp4lcKj0HHbteDWglS NVbWKWEk9PAKA4UeQVUH4vOhTRhAPpuDUavLdp2tDtT7ZBVh91B3AWIM6+7fIvyU 2uYt1q/CNjga8RllXBT7mW2zHGEYQFIkBJvqlU0PN1HlxRZIbSSEb+zQuVAd+ph3 kt/oZon3ZbNmKg+arsYMmKkYJ0REwKQib7h5Xl31aK74XmWBp2Ky+lopsJSP8wpH AfC71h4s3LDm8ADHF1Ns4KuGZdLTugr8uiPm5kEJFGes1uYKy8R7OTFko0NEuJkv STfpPYnTU2qDCJBH08zZErI/6YBIlSsCSde3ABEBAAGJASUEGAECAA8FAlYV5DMC GwwFCQANLwAACgkQB0xLJO1EFFKAmgf/d3dk1/HgmF8rmvYVru/hJvmIpmiLqPl5 bYSwdZeU+k82qp3xACM2yMJhOh89SgHsaaqQAE1qo5rAJcSG7/+7M/kzf4u/WM/E unXDtLkbzi5Zl+gjoikrfOhgF0NmuGdlrOme8a6ue7+iE4XLAo0/jhVlh45O6Iq0 0DGyeFr22cR3jZj4wRmPw5zj4r/sWc06UfquVAEMmfIvJMaGYvwBI+TU6gI8MjLe VDY0vay/nQ79fXSLQmYEvjwKXIavQu9c8TFt0z9EDdoIMx69ZunqZuYQInxaT+cL i9zhihMGz4XA1q3blLNX3I0jWzAa23ZchI7htc3kfxp1jWqrGyGEIg== =nrPH -----END PGP PUBLIC KEY BLOCK----- ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: speakup-r empty line lockup ` Kirk Reiser @ ` Chime Hart ` Janina Sajka 1 sibling, 0 replies; 27+ messages in thread From: Chime Hart @ UTC (permalink / raw) To: Speakup is a screen review system for Linux. Well Kirk-and-All, I sure wish that feature would work while reading a live mail in pine Chime ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: speakup-r empty line lockup ` Kirk Reiser ` Chime Hart @ ` Janina Sajka ` John Covici 1 sibling, 1 reply; 27+ messages in thread From: Janina Sajka @ UTC (permalink / raw) To: speakup This will be absolutely awesome, especially if can persist it's even as you might use Speakup in another terminal/console for some other task before resuming. So, is it particular to a tty? Or, should we not expect to run away to another tty for some quick task before resuming reading? Just trying to get my mind around a cool feature I expect to use a lot! Janina Kirk Reiser writes: > Hahahah, close. The object is you can hit speakup-r and speakup will > start reading the document from where the cursor is until you tap the > control, shift or whatever silence key and it will place the cursor at > the position you heard whent you tapped the key. That way one can > continuously read a document in an edittor and have the cursor able to > start again where you hit the silence key for further reading or > editting. > > Kirk > > On Sun, 20 Aug 2017, Okash Khawaja wrote: > > > On Sat, Aug 19, 2017 at 01:11:39AM +0200, Samuel Thibault wrote: > > > Okash Khawaja, on ven. 18 ao??t 2017 08:17:33 +0100, wrote: > > > > Would you suggest reading more lines? > > > > > > The point of the feature is that by typing control, you stop the speech > > > at the place where you want to bring the cursor to :) > > > > I see... So the use case is that you can move the cursor to a line > > where you want the speech to stop and hit control, so that hitting > > speakup-r again will then start speaking from that line. Is that right? > > > > Thanks, > > Okash > > _______________________________________________ > > Speakup mailing list > > Speakup@linux-speakup.org > > http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup > > -- > Well that's it then, colour me secure! > > -----BEGIN PGP PUBLIC KEY BLOCK----- > Version: GnuPG v1 > > mQENBFYV5DMBCAC060mbsnLhGPjnFkf0R0p+7MxcfxlOuy5wc8y59y9ZNF0RZD1s > OTEsDih4vD9YJ3zA78VsBUDK47aiDWduh3nHzYN2ZSuxAQ9u7qPqphCG0jPagTU8 > p7+Ceeya4I5odWtq+Nkf1UrHB7KKEtexphStSwUG5Bhi4bb84YinmX/a3I+OGV1D > by4QBSdPvSuDw0qFkt/ucLyEwv4L6lDjoH2GF+tnCew4SJtliJFvA1k7NpWO6HW9 > aWtBxfYU85ccZKBSE25y+9KprUCncVTpaVs3FztCWG0dQRXHvEbV+Damp/IBd9Jv > HZX7azqbERUa/FjPTIlZhhI9VtaZaFfJSH+5ABEBAAG0HUtpcmsgUmVpc2VyIDxr > aXJrQHJlaXNlcnMuY2E+iQE+BBMBAgAoBQJWFeQzAhsDBQkADS8ABgsJCAcDAgYV > CAIJCgsEFgIDAQIeAQIXgAAKCRAHTEsk7UQUUoeuB/wIqsdLCfDrSvr3qg7rKBDg > ru44OMuRit6hbdWFZjmxccCdjeNhBJRVd5wrEqjj5YoqQAhmacXaEB0DO/TZlDgo > kUfJM7lrtQD4mYU9GVtrzJxCJoBUyeMVnMJt39F91tBu0mYM6oI/dv81dwxIv++4 > hj55TZ4GG7DGYAy4LwNb+noNbivgOFHlnfNq8nxhZkHbJdYKP+sptZOL5sagmBQZ > iS9STB54g/U7Jtt1Fe+JwDmbxQhbSHa9JuWn0xZ8CtYhrz06xSqZl5vpMlak3eW2 > x6m6IcqZfyuI2K7W/9BCgcsQyYzufO4Gk9KyPNISskX6pFBLuNxIH6hdfxSYYm9y > uQENBFYV5DMBCACtMyhHog5MR6eQUPTx7fWH5ntkgCtmWvQp4lcKj0HHbteDWglS > NVbWKWEk9PAKA4UeQVUH4vOhTRhAPpuDUavLdp2tDtT7ZBVh91B3AWIM6+7fIvyU > 2uYt1q/CNjga8RllXBT7mW2zHGEYQFIkBJvqlU0PN1HlxRZIbSSEb+zQuVAd+ph3 > kt/oZon3ZbNmKg+arsYMmKkYJ0REwKQib7h5Xl31aK74XmWBp2Ky+lopsJSP8wpH > AfC71h4s3LDm8ADHF1Ns4KuGZdLTugr8uiPm5kEJFGes1uYKy8R7OTFko0NEuJkv > STfpPYnTU2qDCJBH08zZErI/6YBIlSsCSde3ABEBAAGJASUEGAECAA8FAlYV5DMC > GwwFCQANLwAACgkQB0xLJO1EFFKAmgf/d3dk1/HgmF8rmvYVru/hJvmIpmiLqPl5 > bYSwdZeU+k82qp3xACM2yMJhOh89SgHsaaqQAE1qo5rAJcSG7/+7M/kzf4u/WM/E > unXDtLkbzi5Zl+gjoikrfOhgF0NmuGdlrOme8a6ue7+iE4XLAo0/jhVlh45O6Iq0 > 0DGyeFr22cR3jZj4wRmPw5zj4r/sWc06UfquVAEMmfIvJMaGYvwBI+TU6gI8MjLe > VDY0vay/nQ79fXSLQmYEvjwKXIavQu9c8TFt0z9EDdoIMx69ZunqZuYQInxaT+cL > i9zhihMGz4XA1q3blLNX3I0jWzAa23ZchI7htc3kfxp1jWqrGyGEIg== > =nrPH > -----END PGP PUBLIC KEY BLOCK----- > _______________________________________________ > Speakup mailing list > Speakup@linux-speakup.org > http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup -- Janina Sajka, Phone: +1.443.300.2200 sip:janina@asterisk.rednote.net Email: janina@rednote.net Linux Foundation Fellow Executive Chair, Accessibility Workgroup: http://a11y.org The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI) Chair, Accessible Platform Architectures http://www.w3.org/wai/apa ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: speakup-r empty line lockup ` Janina Sajka @ ` John Covici ` Samuel Thibault 0 siblings, 1 reply; 27+ messages in thread From: John Covici @ UTC (permalink / raw) To: Speakup is a screen review system for Linux. While speakup-r is going, you need to stay in that console. this is the one thing I wish eemacspeak had. It works great except for that empty line lockup. David Borowski's mods fixed that problem, so if you don't mind using the old serial code, that will work as well -- and if you use speakup with speech dispatcher and speechd-up speakup-r will work as well -- not with espeakup. I use this every day, would not have a speech system without it. On Mon, 21 Aug 2017 10:49:20 -0400, Janina Sajka wrote: > > This will be absolutely awesome, especially if can persist it's even as > you might use Speakup in another terminal/console for some other task > before resuming. > > So, is it particular to a tty? Or, should we not expect to run away to > another tty for some quick task before resuming reading? > > Just trying to get my mind around a cool feature I expect to use a lot! > > Janina > > Kirk Reiser writes: > > Hahahah, close. The object is you can hit speakup-r and speakup will > > start reading the document from where the cursor is until you tap the > > control, shift or whatever silence key and it will place the cursor at > > the position you heard whent you tapped the key. That way one can > > continuously read a document in an edittor and have the cursor able to > > start again where you hit the silence key for further reading or > > editting. > > > > Kirk > > > > On Sun, 20 Aug 2017, Okash Khawaja wrote: > > > > > On Sat, Aug 19, 2017 at 01:11:39AM +0200, Samuel Thibault wrote: > > > > Okash Khawaja, on ven. 18 ao??t 2017 08:17:33 +0100, wrote: > > > > > Would you suggest reading more lines? > > > > > > > > The point of the feature is that by typing control, you stop the speech > > > > at the place where you want to bring the cursor to :) > > > > > > I see... So the use case is that you can move the cursor to a line > > > where you want the speech to stop and hit control, so that hitting > > > speakup-r again will then start speaking from that line. Is that right? > > > > > > Thanks, > > > Okash > > > _______________________________________________ > > > Speakup mailing list > > > Speakup@linux-speakup.org > > > http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup > > > > -- > > Well that's it then, colour me secure! > > > > -----BEGIN PGP PUBLIC KEY BLOCK----- > > Version: GnuPG v1 > > > > mQENBFYV5DMBCAC060mbsnLhGPjnFkf0R0p+7MxcfxlOuy5wc8y59y9ZNF0RZD1s > > OTEsDih4vD9YJ3zA78VsBUDK47aiDWduh3nHzYN2ZSuxAQ9u7qPqphCG0jPagTU8 > > p7+Ceeya4I5odWtq+Nkf1UrHB7KKEtexphStSwUG5Bhi4bb84YinmX/a3I+OGV1D > > by4QBSdPvSuDw0qFkt/ucLyEwv4L6lDjoH2GF+tnCew4SJtliJFvA1k7NpWO6HW9 > > aWtBxfYU85ccZKBSE25y+9KprUCncVTpaVs3FztCWG0dQRXHvEbV+Damp/IBd9Jv > > HZX7azqbERUa/FjPTIlZhhI9VtaZaFfJSH+5ABEBAAG0HUtpcmsgUmVpc2VyIDxr > > aXJrQHJlaXNlcnMuY2E+iQE+BBMBAgAoBQJWFeQzAhsDBQkADS8ABgsJCAcDAgYV > > CAIJCgsEFgIDAQIeAQIXgAAKCRAHTEsk7UQUUoeuB/wIqsdLCfDrSvr3qg7rKBDg > > ru44OMuRit6hbdWFZjmxccCdjeNhBJRVd5wrEqjj5YoqQAhmacXaEB0DO/TZlDgo > > kUfJM7lrtQD4mYU9GVtrzJxCJoBUyeMVnMJt39F91tBu0mYM6oI/dv81dwxIv++4 > > hj55TZ4GG7DGYAy4LwNb+noNbivgOFHlnfNq8nxhZkHbJdYKP+sptZOL5sagmBQZ > > iS9STB54g/U7Jtt1Fe+JwDmbxQhbSHa9JuWn0xZ8CtYhrz06xSqZl5vpMlak3eW2 > > x6m6IcqZfyuI2K7W/9BCgcsQyYzufO4Gk9KyPNISskX6pFBLuNxIH6hdfxSYYm9y > > uQENBFYV5DMBCACtMyhHog5MR6eQUPTx7fWH5ntkgCtmWvQp4lcKj0HHbteDWglS > > NVbWKWEk9PAKA4UeQVUH4vOhTRhAPpuDUavLdp2tDtT7ZBVh91B3AWIM6+7fIvyU > > 2uYt1q/CNjga8RllXBT7mW2zHGEYQFIkBJvqlU0PN1HlxRZIbSSEb+zQuVAd+ph3 > > kt/oZon3ZbNmKg+arsYMmKkYJ0REwKQib7h5Xl31aK74XmWBp2Ky+lopsJSP8wpH > > AfC71h4s3LDm8ADHF1Ns4KuGZdLTugr8uiPm5kEJFGes1uYKy8R7OTFko0NEuJkv > > STfpPYnTU2qDCJBH08zZErI/6YBIlSsCSde3ABEBAAGJASUEGAECAA8FAlYV5DMC > > GwwFCQANLwAACgkQB0xLJO1EFFKAmgf/d3dk1/HgmF8rmvYVru/hJvmIpmiLqPl5 > > bYSwdZeU+k82qp3xACM2yMJhOh89SgHsaaqQAE1qo5rAJcSG7/+7M/kzf4u/WM/E > > unXDtLkbzi5Zl+gjoikrfOhgF0NmuGdlrOme8a6ue7+iE4XLAo0/jhVlh45O6Iq0 > > 0DGyeFr22cR3jZj4wRmPw5zj4r/sWc06UfquVAEMmfIvJMaGYvwBI+TU6gI8MjLe > > VDY0vay/nQ79fXSLQmYEvjwKXIavQu9c8TFt0z9EDdoIMx69ZunqZuYQInxaT+cL > > i9zhihMGz4XA1q3blLNX3I0jWzAa23ZchI7htc3kfxp1jWqrGyGEIg== > > =nrPH > > -----END PGP PUBLIC KEY BLOCK----- > > _______________________________________________ > > Speakup mailing list > > Speakup@linux-speakup.org > > http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup > > -- > > Janina Sajka, Phone: +1.443.300.2200 > sip:janina@asterisk.rednote.net > Email: janina@rednote.net > > Linux Foundation Fellow > Executive Chair, Accessibility Workgroup: http://a11y.org > > The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI) > Chair, Accessible Platform Architectures http://www.w3.org/wai/apa > > _______________________________________________ > 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: speakup-r empty line lockup ` John Covici @ ` Samuel Thibault ` John Covici 0 siblings, 1 reply; 27+ messages in thread From: Samuel Thibault @ UTC (permalink / raw) To: covici, Speakup is a screen review system for Linux. John Covici, on lun. 21 août 2017 12:03:19 -0400, wrote: > It works great except for that empty line lockup. David Borowski's > mods fixed that problem, Is it known what exactly he did to fix it? That would probably very informative. Samuel ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: speakup-r empty line lockup ` Samuel Thibault @ ` John Covici ` Okash Khawaja 0 siblings, 1 reply; 27+ messages in thread From: John Covici @ UTC (permalink / raw) To: Samuel Thibault; +Cc: Speakup is a screen review system for Linux. He rewrote the whole part of the code, adding some new features as well, so the bug mysteriously went away. On Mon, 21 Aug 2017 12:05:25 -0400, Samuel Thibault wrote: > > John Covici, on lun. 21 août 2017 12:03:19 -0400, wrote: > > It works great except for that empty line lockup. David Borowski's > > mods fixed that problem, > > Is it known what exactly he did to fix it? That would probably very > informative. > > Samuel -- 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: speakup-r empty line lockup ` John Covici @ ` Okash Khawaja ` John Covici 0 siblings, 1 reply; 27+ messages in thread From: Okash Khawaja @ UTC (permalink / raw) To: covici, Speakup is a screen review system for Linux. [-- Attachment #1: Type: text/plain, Size: 749 bytes --] Hi, On Mon, Aug 21, 2017 at 12:23:46PM -0400, John Covici wrote: > He rewrote the whole part of the code, adding some new features as > well, so the bug mysteriously went away. I still think the root cause is correct, i.e. interrupt being triggered from its own interrupt handler context. The fix however was too broad. First one changed the behaviour in all cases. Second one from last night narrowed the change to just the interrupt context. If I had right serial synth, I would try the attached patch. This narrows the fix down even further, so that we avoid calling speakup_fake_down_arrow() only when we are in context of keyboard_notifier_call() which is always invoked in interrupt context, in response to a keyboard event. Thanks, Okash [-- Attachment #2: speakup-r-fix --] [-- Type: text/plain, Size: 1423 bytes --] --- drivers/staging/speakup/main.c | 15 ++++++++++++--- 1 file changed, 12 insertions(+), 3 deletions(-) --- a/drivers/staging/speakup/main.c +++ b/drivers/staging/speakup/main.c @@ -1376,6 +1376,8 @@ static void reset_highlight_buffers(stru static int read_all_key; +static volatile int in_keyboard_notifier = 0; + static void start_read_all_timer(struct vc_data *vc, int command); enum { @@ -1408,7 +1410,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_keyboard_notifier) + speakup_fake_down_arrow(); + start_read_all_timer(vc, RA_DOWN_ARROW); } else { say_sentence_num(0, 0); synth_insert_next_index(0); @@ -2212,8 +2217,10 @@ static int keyboard_notifier_call(struct int ret = NOTIFY_OK; static int keycode; /* to hold the current keycode */ + in_keyboard_notifier = 1; + if (vc->vc_mode == KD_GRAPHICS) - return ret; + goto out; /* * First, determine whether we are handling a fake keypress on @@ -2225,7 +2232,7 @@ static int keyboard_notifier_call(struct */ if (speakup_fake_key_pressed()) - return ret; + goto out; switch (code) { case KBD_KEYCODE: @@ -2266,6 +2273,8 @@ static int keyboard_notifier_call(struct break; } } +out: + in_keyboard_notifier = 0; return ret; } ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: speakup-r empty line lockup ` Okash Khawaja @ ` John Covici ` Okash Khawaja 0 siblings, 1 reply; 27+ messages in thread From: John Covici @ UTC (permalink / raw) To: Okash Khawaja Cc: Speakup is a screen review system for Linux., Samuel Thibault OK, tested the patch, no joy with this one either. Note that a couple of thehunks sucedded with a bit of line difference, but that should not be of significance. The procedure I used was to unpatch the previous one and then put the new one in, same like I did with the previous patch, unpatch old one and put in new one. On Mon, 21 Aug 2017 15:24:32 -0400, Okash Khawaja wrote: > > [1 <text/plain; us-ascii (7bit)>] > Hi, > > On Mon, Aug 21, 2017 at 12:23:46PM -0400, John Covici wrote: > > He rewrote the whole part of the code, adding some new features as > > well, so the bug mysteriously went away. > > I still think the root cause is correct, i.e. interrupt being triggered > from its own interrupt handler context. The fix however was too broad. > First one changed the behaviour in all cases. Second one from last night > narrowed the change to just the interrupt context. > > If I had right serial synth, I would try the attached patch. This > narrows the fix down even further, so that we avoid calling > speakup_fake_down_arrow() only when we are in context of > keyboard_notifier_call() which is always invoked in interrupt context, > in response to a keyboard event. > > Thanks, > Okash > [2 speakup-r-fix <text/plain; us-ascii (7bit)>] > --- > drivers/staging/speakup/main.c | 15 ++++++++++++--- > 1 file changed, 12 insertions(+), 3 deletions(-) > > --- a/drivers/staging/speakup/main.c > +++ b/drivers/staging/speakup/main.c > @@ -1376,6 +1376,8 @@ static void reset_highlight_buffers(stru > > static int read_all_key; > > +static volatile int in_keyboard_notifier = 0; > + > static void start_read_all_timer(struct vc_data *vc, int command); > > enum { > @@ -1408,7 +1410,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_keyboard_notifier) > + speakup_fake_down_arrow(); > + start_read_all_timer(vc, RA_DOWN_ARROW); > } else { > say_sentence_num(0, 0); > synth_insert_next_index(0); > @@ -2212,8 +2217,10 @@ static int keyboard_notifier_call(struct > int ret = NOTIFY_OK; > static int keycode; /* to hold the current keycode */ > > + in_keyboard_notifier = 1; > + > if (vc->vc_mode == KD_GRAPHICS) > - return ret; > + goto out; > > /* > * First, determine whether we are handling a fake keypress on > @@ -2225,7 +2232,7 @@ static int keyboard_notifier_call(struct > */ > > if (speakup_fake_key_pressed()) > - return ret; > + goto out; > > switch (code) { > case KBD_KEYCODE: > @@ -2266,6 +2273,8 @@ static int keyboard_notifier_call(struct > break; > } > } > +out: > + in_keyboard_notifier = 0; > return ret; > } > -- 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: speakup-r empty line lockup ` John Covici @ ` Okash Khawaja 0 siblings, 0 replies; 27+ messages in thread From: Okash Khawaja @ UTC (permalink / raw) To: John Covici; +Cc: Samuel Thibault, Speakup is a screen review system for Linux. Thanks John. Appreciate it. I'll update here if I make progress. Cheers, Okash On 22 Aug 2017 12:36 am, "John Covici" <covici@ccs.covici.com> wrote: > OK, tested the patch, no joy with this one either. Note that a couple > of thehunks sucedded with a bit of line difference, but that should > not be of significance. The procedure I used was to unpatch the > previous one and then put the new one in, same like I did with the > previous patch, unpatch old one and put in new one. > > On Mon, 21 Aug 2017 15:24:32 -0400, > Okash Khawaja wrote: > > > > [1 <text/plain; us-ascii (7bit)>] > > Hi, > > > > On Mon, Aug 21, 2017 at 12:23:46PM -0400, John Covici wrote: > > > He rewrote the whole part of the code, adding some new features as > > > well, so the bug mysteriously went away. > > > > I still think the root cause is correct, i.e. interrupt being triggered > > from its own interrupt handler context. The fix however was too broad. > > First one changed the behaviour in all cases. Second one from last night > > narrowed the change to just the interrupt context. > > > > If I had right serial synth, I would try the attached patch. This > > narrows the fix down even further, so that we avoid calling > > speakup_fake_down_arrow() only when we are in context of > > keyboard_notifier_call() which is always invoked in interrupt context, > > in response to a keyboard event. > > > > Thanks, > > Okash > > [2 speakup-r-fix <text/plain; us-ascii (7bit)>] > > --- > > drivers/staging/speakup/main.c | 15 ++++++++++++--- > > 1 file changed, 12 insertions(+), 3 deletions(-) > > > > --- a/drivers/staging/speakup/main.c > > +++ b/drivers/staging/speakup/main.c > > @@ -1376,6 +1376,8 @@ static void reset_highlight_buffers(stru > > > > static int read_all_key; > > > > +static volatile int in_keyboard_notifier = 0; > > + > > static void start_read_all_timer(struct vc_data *vc, int command); > > > > enum { > > @@ -1408,7 +1410,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_keyboard_notifier) > > + speakup_fake_down_arrow(); > > + start_read_all_timer(vc, RA_DOWN_ARROW); > > } else { > > say_sentence_num(0, 0); > > synth_insert_next_index(0); > > @@ -2212,8 +2217,10 @@ static int keyboard_notifier_call(struct > > int ret = NOTIFY_OK; > > static int keycode; /* to hold the current keycode */ > > > > + in_keyboard_notifier = 1; > > + > > if (vc->vc_mode == KD_GRAPHICS) > > - return ret; > > + goto out; > > > > /* > > * First, determine whether we are handling a fake keypress on > > @@ -2225,7 +2232,7 @@ static int keyboard_notifier_call(struct > > */ > > > > if (speakup_fake_key_pressed()) > > - return ret; > > + goto out; > > > > switch (code) { > > case KBD_KEYCODE: > > @@ -2266,6 +2273,8 @@ static int keyboard_notifier_call(struct > > break; > > } > > } > > +out: > > + in_keyboard_notifier = 0; > > return ret; > > } > > > > -- > 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 > ^ permalink raw reply [flat|nested] 27+ messages in thread
end of thread, other threads:[~ UTC | newest]
Thread overview: 27+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
speakup-r empty line lockup Okash Khawaja
` Samuel Thibault
` Chris Brannon
` John Covici
` Okash Khawaja
` John Covici
` Okash Khawaja
` Okash Khawaja
` John Covici
` Okash Khawaja
` Okash Khawaja
` Chris Brannon
` John Covici
` Okash Khawaja
` Okash Khawaja
` John Covici
` Samuel Thibault
` Okash Khawaja
` Kirk Reiser
` Chime Hart
` Janina Sajka
` John Covici
` Samuel Thibault
` John Covici
` Okash Khawaja
` John Covici
` Okash Khawaja
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).