lkml.org 
[lkml]   [2000]   [Feb]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: How to read a timestamp in kernel driver code?
Hi Mike.

>>> 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)

Reading through your description of what it's for, what you actually
need is a simple go/no-go test that says "did these two codes arrive
too fast?" with the definition of "too fast" being the problem.

If so, what you're actually looking at is something along the lines of
the following pseudocode:

int key_timer() {
static time_t expiry = 0;
time_t now = get_current_time_value();
int Code;

if (now < expiry) {
printk(KERN_INFO "Scancodes arrived too fast\n");
Code = 1;
} else {
printk(KERN_INFO "Timeout has expired\n");
Code = 0;
}
expiry = now + TIMEOUT;
return Code;
}

In the above, get_current_time_value() is a macro or function that
reads the jiffies counter (or whatever) and returns its value, and
TIMEOUT is whatever interval is defined as being the relevant timeout.

As it stands, the above function won't handle jiffies wrapping at all
well, but I understand there's a standard way to deal with that,so
will leave that to you...

> 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.

That's the description I referred to above.

> 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.

Have you ever heard of "sticky keys" ? If not, it's a standard
accessibility tweak for computers under several operating systems
(originally under Windows 2.0 and available under all later versions
thereof) that enables disabled people with limited finger control to
use a keyboard, and it's also used by people with no hand control at
all, including those who have had both hands amputated.

Basically, it means that the various shift keys (such as SHIFT, CTRL
and ALT) are converted from their normal synchronous action to a
sequential action instead, so that instead of pressing CTRL and D
together to get what BASIC calls CHR$(4) you press CTRL then release
it, then press D and release it.

I suspect this is the tweak you refer to, and if so, and you can
extend it to provide a full "sticky keys" implementation as standard
in the kernel, then I for one would have no problem endorsing it in
that disguise. I know several people with suchlike disabilities who
would be willing to use Linux were it not for their disability.

> 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)

Very true.

> 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)

That's the best way in my experience.

Best wishes from Riley.

* Copyright (C) 1999, Memory Alpha Systems.
* All rights and wrongs reserved.

+----------------------------------------------------------------------+
| There is something frustrating about the quality and speed of Linux |
| development, ie., the quality is too high and the speed is too high, |
| in other words, I can implement this XXXX feature, but I bet someone |
| else has already done so and is just about to release their patch. |
+----------------------------------------------------------------------+
* http://www.memalpha.cx/Linux/Kernel/


-
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/

\
 
 \ /
  Last update: 2005-03-22 13:56    [W:1.091 / U:0.504 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site