[quoted lines by Nicolas Pitre on 2015/09/19 at 16:53 -0400]
Please retest with the latest development code.
--
Dave Mielke | 2213 Fox Crescent | The Bible is the very Word of God.
Phone: 1-613-726-0014 | Ottawa, Ontario | http://Mielke.cc/bible/
EMail: d...@mielke.cc | Canada K2A 1
On Sat, 19 Sep 2015, Dave Mielke wrote:
> [quoted lines by Nicolas Pitre on 2015/09/19 at 16:18 -0400]
>
> >Not exactly. That is prior the screen update delay discussed in this
> >thread. I thought it could have had some unwanted side effects, but the
> >issue was there before the delay was in
[quoted lines by Nicolas Pitre on 2015/09/19 at 16:18 -0400]
>Not exactly. That is prior the screen update delay discussed in this
>thread. I thought it could have had some unwanted side effects, but the
>issue was there before the delay was introduced.
Okay, thanks. I guess I looked up the wr
On Sat, 19 Sep 2015, Dave Mielke wrote:
> [quoted lines by Nicolas Pitre on 2015/09/19 at 15:58 -0400]
>
> >Update: the above commit does exhibit the lost key event issue as well.
>
> That'd be the latest development code.
Not exactly. That is prior the screen update delay discussed in this
t
[quoted lines by Nicolas Pitre on 2015/09/19 at 15:58 -0400]
>Update: the above commit does exhibit the lost key event issue as well.
That'd be the latest development code.
>The one that doesn't is stock Fedora 22 brltty package
>brltty-5.2-3.fc22.
There are a lot of commits in between.
--
D
On Fri, 18 Sep 2015, Nicolas Pitre wrote:
> On Fri, 18 Sep 2015, Dave Mielke wrote:
>
> > Have you verified that it's exactly this one change that makes the
> > difference?
>
> No. Not yet.
>
> And as I said, it takes hours on average for this issue to occur.
>
> I'm using commit 79cd158b no
On Fri, 18 Sep 2015, Dave Mielke wrote:
> [quoted lines by Nicolas Pitre on 2015/09/18 at 17:02 -0400]
>
> >Well... It's been a few days since I've been running that brltty version
> >on my BC640. I don't know how the 5ms delay might affect things other
> >than the screen refresh rate, but it
[quoted lines by Nicolas Pitre on 2015/09/18 at 17:02 -0400]
>Well... It's been a few days since I've been running that brltty version
>on my BC640. I don't know how the 5ms delay might affect things other
>than the screen refresh rate, but it seems that some braille display key
>events are dr
On Mon, 14 Sep 2015, Nicolas Pitre wrote:
> On Mon, 14 Sep 2015, Dave Mielke wrote:
>
> > [quoted lines by Nicolas Pitre on 2015/09/14 at 18:11 -0400]
> >
> > >I really do enjoy the current display refresh snappiness and
> > >I'd like for my refresh delay to remain at 0.
> >
> > Could you give
Are you able to check if your problem is also resolved by using the latest
development code of brltty?
--
Dave Mielke | 2213 Fox Crescent | The Bible is the very Word of God.
Phone: 1-613-726-0014 | Ottawa, Ontario | http://Mielke.cc/bible/
EMail: d...@mielke.cc | Canada K2A 1H7 |
Hello,
FYI: the following settings in .alpinerc (by editor or via the
configure menu of alpine) finaly solve the reported cursor tracking
problem for brltty:
no-enable-mail-check-cue
quell-imap-envelope-update
busy-cue-rate=0
With these settings
mail-check-interval=x
x can be
On Mon, 14 Sep 2015, Dave Mielke wrote:
> [quoted lines by Nicolas Pitre on 2015/09/14 at 18:11 -0400]
>
> >I really do enjoy the current display refresh snappiness and
> >I'd like for my refresh delay to remain at 0.
>
> Could you give the latest code (with a 5ms delay) a (fair) test? I don't
[quoted lines by Nicolas Pitre on 2015/09/14 at 18:11 -0400]
>I really do enjoy the current display refresh snappiness and
>I'd like for my refresh delay to remain at 0.
Could you give the latest code (with a 5ms delay) a (fair) test? I don't think
that this rather short delay is noticeable.
F
On Mon, 14 Sep 2015, Aura Kelloniemi wrote:
> I wish these options could be configurable at run-time - either through the
> preferences menu or /etc/brltty.conf, because users' opinions are likely to
> vary.
Agreed. I really do enjoy the current display refresh snappiness and
I'd like for my r
On Mon, 14 Sep 2015, Dave Mielke wrote:
> Right now, the handler that processes a screen update alert is scheduled to
> execute immediately. My theory is that it might be better to schedule it to
> occur a few milliseconds later.
I'd suggest this delay should apply only to cursor tracking. No
Dave Mielke writes:
> [quoted lines by Aura Kelloniemi on 2015/09/14 at 21:56 +0300]
>>So, here are the new results. Now I tested with emacs with up to four windows
>>all updating the mode line continuously. I also tested with elinks which also
>>has a "clock on status line" feature.
>>
>>Value
[quoted lines by Aura Kelloniemi on 2015/09/14 at 21:56 +0300]
>So, here are the new results. Now I tested with emacs with up to four windows
>all updating the mode line continuously. I also tested with elinks which also
>has a "clock on status line" feature.
>
>Values 0 and 1 are too small - ther
Dave Mielke writes:
> [quoted lines by Aura Kelloniemi on 2015/09/14 at 19:57 +0300]
>>I think that the problem with Dave's attempt to fix this problem was that
>>screen updates just take a longer time than what was suspected. However, for
>>top for example, the screen update takes a noticeably
[quoted lines by Aura Kelloniemi on 2015/09/14 at 19:57 +0300]
>I think that the problem with Dave's attempt to fix this problem was that
>screen updates just take a longer time than what was suspected. However, for
>top for example, the screen update takes a noticeably long time (perhaps
>around
Hello
Dave Mielke writes:
> Right now, the handler that processes a screen update alert is scheduled to
> execute immediately. My theory is that it might be better to schedule it to
> occur a few milliseconds later.
I tried the git head. My expert test bench looked like this:
Test #1: emac
[quoted lines by Klaus-Peter Wegge on 2015/09/14 at 16:42 +0200]
>The problem does not appear with alpine2.11 on the debian8 when
>downgrading to a brltty4.x version. May be it has to do with the change
>of the refresh strategy from 4 to 5.
The difference is that brltty 4 (and earlier) would simp
Thanks for both answers and explanations.
The problem does not appear with alpine2.11 on the debian8 when
downgrading to a brltty4.x version. May be it has to do with the change
of the refresh strategy from 4 to 5.
BTW: older alpine versions have the same problem with brltty5.
I figured out that
[quoted lines by Aura Kelloniemi on 2015/09/14 at 15:02 +0300]
>Therefore it is at the moment almost impossible to use cursor tracking in
>programs which update the screen frequently. I, for example, would like to
>have emacs display a clock on its mode line, but I cannot activate the
>feature, be
Klaus-Peter Wegge writes:
> Hello,
> with my update to debian 8 I also updated from brltty3.8 to 5.2.
> Now I'm approaching the following problem when using alpine2.11:
> When reading a mail by moving the braille window around
> the braille window jumps back to the current cursor position a
Hello,
Klaus-Peter Wegge, le Mon 14 Sep 2015 09:12:02 +0200, a écrit :
> with my update to debian 8 I also updated from brltty3.8 to 5.2.
> Now I'm approaching the following problem when using alpine2.11:
> This effect does not appear when login in by ssh from an old PC with
> brtlly 4.x.
> The d
25 matches
Mail list logo
