>Anyway, I am now considering the following experiment.
>
>- We make the psm driver count the number of the "out-of-sync" errors.
>- When the error is detected for the first time, the psm driver will
> throw few data bytes (up to entire packet size) and see if it can
> get back to sync.
>- If
Kazutaka YOKOTA wrote:
> >o You may want to implement a rate throttling mechanism;
> > init will stop respawning a getty on a port, if it is
> > exiting too rapidly, while inetd will rate limit the
> > number of connection attempts a second, as well. I
> > guess you p
>> If disable/enable sequence, which is lot simpler and takes considrably
>> less time, can correct the sync problem, I think it will be better.
>
>It looks to me as if the mouse is automatically enabled by
>default after a reset?
No, the mouse is disabled after reset. We need to explicitly
enab
>o If you are going to reset, disable and drain the input
> queue before you do it; this will make the mouse lose
> buffered data, making a partial send with a disable
> in the middle not resume (e.g. it is no longer an
> issue for you).
Don't worry. I was going to d
Kazutaka YOKOTA wrote:
> While we are carrying out the reset/initialization sequence, the mouse
> pointer will be frozen on the screen. The keyboard input may not
> respond in a timely fasion because the PS/2 mouse and the AT keyboard
> share the same I/O port. Then, I suspect our user may feel un
Kazutaka YOKOTA wrote:
> Anyway, I am now considering the following experiment.
>
> - We make the psm driver count the number of the "out-of-sync" errors.
> - When the error is detected for the first time, the psm driver will
> throw few data bytes (up to entire packet size) and see if it can
>
> > Too complicated?
>
>It sounds fine to me. I was thinking that if you are truly concerned
>about the amount of time that the disable/enable calls take, the way to
>solve that is a combination of counter and timer. Increment a counter
>when you take the disable/enable path to prevent recursive
>Does it make sense to have a timeout (or perhaps just timestamps) in the
>driver, so that after some period of inactivity, you "know" that the
>next byte from the moust is the first of a multi-byte message?
>
>louie
I haven't thought about this. Yes, it may be possible. But, when the
mouse is m
>: Too complicated?
>
>I like this idea. It will allow mechanical KVM switches to "work"
>better than they do now (which is to say, not much at all). I also
>have one KVM switch that hits the out-of-sync problem when its power
>fails. Unfortunately, it has a horrible user interface: The power
>
Kazutaka YOKOTA writes:
> Anyway, I am now considering the following experiment.
>
> - We make the psm driver count the number of the "out-of-sync" errors.
> - When the error is detected for the first time, the psm driver will
> throw few data bytes (up to entire packet size) and see if it
Does it make sense to have a timeout (or perhaps just timestamps) in the
driver, so that after some period of inactivity, you "know" that the
next byte from the moust is the first of a multi-byte message?
louie
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" i
In message <[EMAIL PROTECTED]> Kazutaka YOKOTA
writes:
: Anyway, I am now considering the following experiment.
:
: - We make the psm driver count the number of the "out-of-sync" errors.
: - When the error is detected for the first time, the psm driver will
: throw few data bytes (up to entire
Ok, I am back.
There are so many issues to be explained and discussed. I will tackle
them one by one
- Flags 0x8000 for psm and "out-of-sync" error
As many people want to make it default, and my initial intent to make
it an option didn't work out well as a hindsight, we had better make
it
13 matches
Mail list logo
