On Fri, 25 Feb 2000, Pauline Middelink wrote:
>> I'm working on some stuff in keyboard.c that is timing sensitive
>> right now. What I want to do is keep track of the elapsed time
>> between to successive calls to handle_scancode().
>>
>> How exactly would I do this? I've snooped around here and there,
>> and it appears that something like:
>
>If you don't need an absolute time, but just the difference,
>you could just look at the time difference between jiffies?
Correct. All I need to know is how many "X" units of time have
expired between keycode Y's down event, and it's up event. The
time units are irrelevant - microseconds, nanoseconds, jiffies,
whatever ... and todays date is certainly not important. ;o)
The only important things are that the units are fine grained
enough to handle the keyboard's fastest possible sequence of two
keycodes being sent one after the other. I don't know how fast
that is though. The other thing is that this is a SIMPLE time
measurement, and I do not want to have the keyboard driver
dependant on some new timing code, or 40k driver just for the
purpose of trapping a single key and timing the time in between
it's make and break codes being received. Any code that
generates more than a handful of instructions (say 40 bytes or
so..) is unacceptable, as is forcing another CONFIG_XXXX thing to
have to be included.. Someone suggested I use the RTC... That
is no-go. This is just a keyboard driver!
What I'm trying to do is detect keys that send make and break
codes simultaneously WITHOUT you actually letting go of the
key. This would occur very quickly, and if I set up a threshold
time on these broken keys, then if the make/break are captured
within the threshold time I know the keyboard is broken, and
special case code can be activated, however if a human presses
the key and only make is sent, then even the fastest typist would
not be able to let go of the key within the threshold time, and
so the special case "broken keyboard" code would not be
activated.
Why you ask? Because my keyboard doesn't work with SYSRQ. I
have a fix for the SYSRQ code now that makes it work on my
keyboard, *AND* on regular keyboards, however it slightly changes
the way that SYSRQ works, and I figured that would be
unacceptible to the kernel folk as a general patch. I figured if
I had the keyboard driver detect the broken keyboard and only use
my special SYSRQ code when a broken keyboard is there, otherwise
make SYSRQ work the same as it always did, that my patch would
have a better chance of getting in.
So, as you can see, this is a SIMPLE problem, and I do not need
RTC, or dedicated PCI hardware timer cards for it. ;o)
I'm very new to kernel code, and unfamiliar with most of it. I'm
certainly trying to learn though, - by trial and error. The code
is my book. ;o)
Thanks for your idea! I'll try it out tonight!
Take care,
TTYL
-- Mike A. Harris Linux advocate Computer Consultant GNU advocate Capslock Consulting Open Source advocateSuspicious Anagram #4: Word: PRESIDENT CLINTON OF THE USA Anagram: TO COPULATE HE FINDS INTERNS
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Feb 29 2000 - 21:00:12 EST