Messages in this thread | | | Date | Fri, 25 Feb 2000 09:36:06 -0500 (EST) | From | "Mike A. Harris" <> | Subject | Re: How to read a timestamp in kernel driver code? |
| |
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 advocate
Suspicious 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/
| |