getting timestamp of last interrupt?
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 10 lines · Richard B. Johnson
Quoted 5 lines · Hans-Georg Thien
I am looking for a possibility to read out the last timestamp when an interrupt has occured.
e.g.: the user presses a key on the keyboard. Where can I read out the timestamp of this event?
Quoted 6 lines
You can get A SIGIO signal for every keyboard, (or other input) event. What you do with it is entirely up to you. Linux/Unix doesn't have "callbacks", instead it has signals. It also has
select()andpoll(), all useful for handling such events. If you want a time-stamp, you callgettimeofday()in your signal handler.
Thanks a lot Richard,
... but ... can I use signals in kernel mode?
Quoted 17 lines · Hans-Georg Thien
Quoted 10 lines · Richard B. Johnson
Quoted 5 lines · Hans-Georg Thien
I am looking for a possibility to read out the last timestamp when an interrupt has occured.
e.g.: the user presses a key on the keyboard. Where can I read out the timestamp of this event?
Quoted 6 lines
You can get A SIGIO signal for every keyboard, (or other input) event. What you do with it is entirely up to you. Linux/Unix doesn't have "callbacks", instead it has signals. It also has
select()andpoll(), all useful for handling such events. If you want a time-stamp, you callgettimeofday()in your signal handler.
Quoted 3 lines
Thanks a lot Richard,
... but ... can I use signals in kernel mode?
Well you talked about the user pressing a key and getting a time-stamp as a result. If you need time-stamps inside the kernel, i.e, a module, then you can call the kernel's do_gettimeofday() function.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.22 on an i686 machine (797.90 BogoMips).
Note 96.31% of all statistics are fiction.
Quoted 20 lines · Richard B. Johnson
Quoted 17 lines · Hans-Georg Thien
Quoted 8 lines
[...]
Quoted 5 lines
I am looking for a possibility to read out the last timestamp when an interrupt has occured.
e.g.: the user presses a key on the keyboard. Where can I read out the timestamp of this event?
Quoted 6 lines
You can get A SIGIO signal for every keyboard, (or other input) event. What you do with it is entirely up to you. Linux/Unix doesn't have "callbacks", instead it has signals. It also has
select()andpoll(), all useful for handling such events. If you want a time-stamp, you callgettimeofday()in your signal handler.Thanks a lot Richard,
Quoted 8 lines
Quoted 1 line
... but ... can I use signals in kernel mode?
Well you talked about the user pressing a key and getting a time-stamp as a result. If you need time-stamps inside the kernel, i.e, a module, then you can call the kernel's
do_gettimeofday()function.
Hello Richard, - It seems, that I should be more precise about what I exactly mean...
I'm writing a kernel mode device driver (mouse).
In that device driver I need the timestamp of the last event for another kernel mode device (keyboard).
I do not care if that timestamp is in jiffies or in gettimeofday() format or whatever format does exist in the world. I am absolutely sure I can convert it somehow to fit my needs.
But since it is a kernel mode driver it can not -AFAIK- use the signal() syscall.
-Hans
Quoted 38 lines · Hans-Georg Thien
Quoted 20 lines · Richard B. Johnson
Quoted 17 lines · Hans-Georg Thien
Quoted 8 lines
[...]
Quoted 5 lines
I am looking for a possibility to read out the last timestamp when an interrupt has occured.
e.g.: the user presses a key on the keyboard. Where can I read out the timestamp of this event?
Quoted 6 lines
You can get A SIGIO signal for every keyboard, (or other input) event. What you do with it is entirely up to you. Linux/Unix doesn't have "callbacks", instead it has signals. It also has
select()andpoll(), all useful for handling such events. If you want a time-stamp, you callgettimeofday()in your signal handler.Thanks a lot Richard,
Quoted 8 lines
Quoted 1 line
... but ... can I use signals in kernel mode?
Well you talked about the user pressing a key and getting a time-stamp as a result. If you need time-stamps inside the kernel, i.e, a module, then you can call the kernel's
do_gettimeofday()function.Hello Richard, - It seems, that I should be more precise about what I exactly mean...
I'm writing a kernel mode device driver (mouse).
In that device driver I need the timestamp of the last event for another kernel mode device (keyboard).
Quoted 8 lines
I do not care if that timestamp is in jiffies or in
gettimeofday()format or whatever format does exist in the world. I am absolutely sure I can convert it somehow to fit my needs.But since it is a kernel mode driver it can not -AFAIK- use the
signal()syscall.-Hans
Then it gets real simple. Just use jiffies, if you can stand the wrap that will occur every (2^32 -1)/HZ seconds ~= 497 days with HZ = 100. If not, call sys_gettimeofday(). Also, if your events are closer in time than a HZ, then you must get time from sys_gettimeofday().
Cheers,
Dick Johnson
Penguin : Linux version 2.4.22 on an i686 machine (797.90 BogoMips).
Note 96.31% of all statistics are fiction.
Quoted 13 lines · Richard B. Johnson
Quoted 11 lines · Hans-Georg Thien
[...]
I'm writing a kernel mode device driver (mouse).In that device driver I need the timestamp of the last event for another kernel mode device (keyboard).
I do not care if that timestamp is in jiffies or in
gettimeofday()format or whatever format does exist in the world. I am absolutely sure I can convert it somehow to fit my needs.
Quoted 7 lines
Quoted 4 lines
But since it is a kernel mode driver it can not -AFAIK- use the
signal()syscall.-Hans
Then it gets real simple. Just use jiffies, if you can stand the [...]
I fear that there is still some miss-understanding. Jiffies are totally OK for me. I can use them without any conversion.
I'll try to formulate the problem with some other words:
I hope that there is is something like a "jiffie-counter" for the keyboard driver, that stores the actual jiffies value whenever a keyboard interrupt occurs.
I hope too, that there is a way to query that "jiffie-counter" from another kernel driver, so that I can write something like
mymouse_module.c
...
void mouse_event(){
// get the current time in jiffies
int now=jiffies;
// get the jiffie value of the last kbd event int last_kbd_event= ????; // ... but how to do that ...
if ((now - last_kbd_event) > delay) {
do_some_very_smart_things(); }
}
...
-Hans
Quoted 22 lines · Hans-Georg Thien
Quoted 13 lines · Richard B. Johnson
Quoted 11 lines · Hans-Georg Thien
[...]
I'm writing a kernel mode device driver (mouse).In that device driver I need the timestamp of the last event for another kernel mode device (keyboard).
I do not care if that timestamp is in jiffies or in
gettimeofday()format or whatever format does exist in the world. I am absolutely sure I can convert it somehow to fit my needs.Quoted 7 lines
Quoted 4 lines
But since it is a kernel mode driver it can not -AFAIK- use the
signal()syscall.-Hans
Then it gets real simple. Just use jiffies, if you can stand the [...]
Quoted 9 lines
I fear that there is still some miss-understanding. Jiffies are totally OK for me. I can use them without any conversion.
I'll try to formulate the problem with some other words:
I hope that there is is something like a "jiffie-counter" for the keyboard driver, that stores the actual jiffies value whenever a keyboard interrupt occurs.
Well the keyboard driver and the mouse driver are entirely different devices.
The keyboard has a built-int CPU that generates scan-codes for every key-press/key-release. It also performs auto-repeat. The mouse generates mouse data at each interrupting event. This data represents direction and three key events. Wheel mouse have may have additional data, I haven't looked at them. They are not related in any way.
Quoted 18 lines
I hope too, that there is a way to query that "jiffie-counter" from another kernel driver, so that I can write something like
mymouse_module.c...
void mouse_event(){// get the current time in jiffies int now=jiffies; // get the jiffie value of the last kbd event int last_kbd_event= ????; // ... but how to do that ... if ((now - last_kbd_event) > delay) { do_some_very_smart_things(); }
Quoted 3 lines
}
...
Now this pseudo-code shows a "last_kbd_event", not a mouse- event as shown in:
Quoted 1 line
Quoted 1 line
Quoted 1 line
I'm writing a kernel mode device driver (mouse).
... your words, not mine.
I presume that you are replacing the existing mouse-driver. If so, your mouse-buffer, i.e., the place you put the mouse-event movement-codes can be something like:
struct mouse_event {
unsigned long time;
int mouse_code;
}You allocate a buffer of this type and, during each interrupt, you put both the jiffie-time and the mouse code into your buffer.
If you are not replacing the existing mouse driver, then you need to share its interrupt with your new module. The new module records the time-stamp of each of the interrupts, only.
Every bit of mouse-data was obtained as a result of an interrupt. Using that knowledge, you should be able to correlate a time-stamp to mouse-data (clear your time-stamp buffer when no mouse data are available).
If you are using the keyboard, not the mouse, then the same things apply.
If you just want to patch the existing keyboard or mouse ISR to save a time-stamp in your module code, you need to make the built-in keyboard or mouse ISR code call a function by pointer. This pointer must be initialized to point to a stub that simply returns. You need to export this symbol so it can be found by your module.
When your module is installed, it saves the value in that pointer. It then changes the pointer value to the address of your routine. It needs to do this under a spin-lock.
When your module is un-installed, it needs to restore the previous (saved) value of that pointer.
Whatever code you make that pointer point-to, must be interrupt-safe. It can get the jiffie-count and put it into a buffer, then return.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.22 on an i686 machine (797.90 BogoMips).
Note 96.31% of all statistics are fiction.
Quoted 32 lines · Richard B. Johnson
Quoted 29 lines · Hans-Georg Thien
Quoted 13 lines · Richard B. Johnson
Quoted 10 lines · Hans-Georg Thien
[...]
I'm writing a kernel mode device driver (mouse).In that device driver I need the timestamp of the last event for another kernel mode device (keyboard).
I do not care if that timestamp is in jiffies or in
gettimeofday()format or whatever format does exist in the world. I am absolutely sure I can convert it somehow to fit my needs.Quoted 7 lines
Quoted 4 lines
But since it is a kernel mode driver it can not -AFAIK- use the
signal()syscall.-Hans
Then it gets real simple. Just use jiffies, if you can stand the [...]
I fear that there is still some miss-understanding. Jiffies are totally OK for me. I can use them without any conversion.
I'll try to formulate the problem with some other words:
Quoted 9 lines
Quoted 4 lines
I hope that there is is something like a "jiffie-counter" for the keyboard driver, that stores the actual jiffies value whenever a keyboard interrupt occurs.
Well the keyboard driver and the mouse driver are entirely different devices.
yes, - I know
Quoted 7 lines
The keyboard has a built-int CPU that generates scan-codes for every key-press/key-release. It also performs auto-repeat. The mouse generates mouse data at each interrupting event. This data represents direction and three key events. Wheel mouse have may have additional data, I haven't looked at them. They are not related in any way.
yes, - I know
Quoted 25 lines
Quoted 20 lines
I hope too, that there is a way to query that "jiffie-counter" from another kernel driver, so that I can write something like
mymouse_module.c...
void mouse_event(){// get the current time in jiffies int now=jiffies; // get the jiffie value of the last kbd event int last_kbd_event= ????; // ... but how to do that ... if ((now - last_kbd_event) > delay) { do_some_very_smart_things(); }Quoted 3 lines
}
...
Quoted 3 lines
Now this pseudo-code shows a "
last_kbd_event", not a mouse- event as shown in:
yes, - I know =8))
It is because I want do some things with the mouse in relation to keyboard events.
Quoted 2 lines
[... a quite detailed explanation on mouse interrupts, mouse data ...]
yes, I know. But my question was: how can I get the timestamp of the last keyboard interrupt.
Quoted 3 lines
When your module is un-installed, it needs to restore the previous (saved) value of that pointer.
yes, - I know
Quoted 4 lines
Whatever code you make that pointer point-to, must be interrupt-safe. It can get the jiffie-count and put it into a buffer, then return.
yes, - I know
Hey Richard, - what is so difficult to understand ?
Anyway, - have you read the email reply from Gabriel Paubert regarding this topic? Sounds very good for a 2.6.x kernel. It seems that I can use the /dev/input/event? device files. I have just modprobed the "evdev" module. It seems that I can get my timestamps by reading one of this files. Have to investigate still which one of them I have to use.
-Hans
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 16 lines · Karim Yaghmour
Quoted 13 lines · Hans-Georg Thien
I am looking for a possibility to read out the last timestamp when an interrupt has occured.
e.g.: the user presses a key on the keyboard. Where can I read out the timestamp of this event?
To be more precise, I 'm looking for
( )a function call
( ) a callback where I can register to be notified when an event occurs ( ) a global accessible variable
( ) a /proc entryor something like that.
Quoted 8 lines
Quoted 1 line
Any ideas ?
Have a look at the Linux Trace Toolkit:
http://www.opersys.com/LTT/
It records micro-second time-stamps for quite a few events, including interrupts.
thanke a lot for reply Karim,
but I think that LTT does not fit to my needs. It needs to modify the kernel - and that is what I want to avoid.
I'm looking for a already existing built-in capability.
Maybe signal SIGIO is a solution, if it does not
(x) give me *every* IO event
(x) has to much overhead - I have to respond to keyboard/mouse events, *not* disk events
grafic card events
eth event
etc. ...
- Hans
Quoted 33 lines · Hans-Georg Thien
Quoted 18 lines · Karim Yaghmour
Quoted 15 lines · Hans-Georg Thien
I am looking for a possibility to read out the last timestamp when an interrupt has occured.
e.g.: the user presses a key on the keyboard. Where can I read out the timestamp of this event?
To be more precise, I 'm looking for
( )a function call
( ) a callback where I can register to be notified when an event occurs ( ) a global accessible variable
( ) a /proc entryor something like that.
Quoted 8 lines
Quoted 1 line
Any ideas ?
Have a look at the Linux Trace Toolkit:
http://www.opersys.com/LTT/
It records micro-second time-stamps for quite a few events, including interrupts.thanke a lot for reply Karim,
but I think that LTT does not fit to my needs. It needs to modify the kernel - and that is what I want to avoid.
Quoted 6 lines
I'm looking for a already existing built-in capability.
Maybe signal SIGIO is a solution, if it does not
(x) give me *every* IO event
(x) has to much overhead - I have to respond to keyboard/mouse events, *not*
Doesn't the input layer add a timestamp to every event?
At least that's the impression I have from xxd /dev/input/eventN: the first eight bytes of each 16 bytes packet look so furiously close to a struct timeval that they can't be anything else :-)
Just that I don't know how the devices and N are associated, it seems to be order of discovery/registering at boot.
Regards,
Gabriel
Quoted 5 lines · Gabriel Paubert
Quoted 3 lines
Quoted 3 lines
[...]
Quoted 2 lines
I am looking for a possibility to read out the last timestamp when an interrupt has occured. [...]
Quoted 8 lines
Doesn't the input layer add a timestamp to every event?
At least that's the impression I have from xxd
/dev/input/eventN: the first eight bytes of each 16 bytes packet look so furiously close to a struct timeval that they can't be anything else :-)Just that I don't know how the devices and N are associated, it seems to be order of discovery/registering at boot.
Hello Gabriel,
Oh yes, - that looks quite good to me. I'm investigating on that now. I found out, that you need at least to compile the "evdev" module.
-Hans