Discussion:
[RFC][PATCH] "Disable Trackpad while typing" on Notebooks withh a PS/2 Trackpad
Hans-Georg Thien
2003-05-01 21:48:21 UTC
Permalink
Sorry for this long text and my bad english. And please be kind to me -
it is my very first posting to this mailing list ...

I have written a *very small* patch against the linux 2.4.20 kernel and
I want to submit it now.

The short story
---------------
The trackpad on the MacIntosh iBook Notebooks have a feature that
prevents unintended trackpad input while typing on the keyboard. There
are no mouse-moves or mouse-taps for a short period of time after each
keystroke.

I believe that many people with i386 notebooks would like this feature
and I want to give it to the linux community.

First I had the idea of writing a loadable kernel module "trackpad" that
implements that feature and is loadable via

insmod keybd_irq=? mouse_irq=? delay=?

The long story
--------------
My first approach was - because I came from the bad old M$-DOS times -
write something like a "terminate and stay resident program"

Procedure LoadModule
Save the currentlly installed handlers for keyboard and mouse.
Install your own interrupt handlers for keyboard and mouse.
End

Procedure UnloadModule
Stop and remove "reset-timer" if necessary
Restore the saved interrupt handlers for keyboard and mouse
End

Procedure KbdHandler
Stop or modify "reset-timer" if necessary
Set global variable block_mouse_events=1
Start a timer that resets block_mouse_events=0 after ??? mSec
Call the old keyboard interrupt handler
End

Proceure MouseHandler
if block_mouse_events>0 then
call ACK(mouse irq) if necessary
do nothing
else
call old mouse interrupt handler
End


So I bought the book "Linux Device Drivers" written by Alessandro Rubini
& Jonathan Corbert. It is an excellent book about LKM, but I couldn't
find a way to "save and restore" irq-handlers as in the design
described above.

That's why I requested a little help in the newsgroup at
comp.os.linux.development.system. This ended up with some people who
said "don't mess around with irq-handlers in that way".

While trying to gain a deeper understanding of irq-handling - espically
for mouse and keyboard handlers - I found out that the keyboard and
mouse interrupts are handled *both* in
/usr/src/linux/drivers/char/pc_keyb.c.

Ok, that is only true for PS/2 mice, but the majority of notebooks on
the market have a PS/2 trackpad. On modifiying the pc_keyb.c file there
is no longer a need to save/restore Interrupt handlers or to call them
indirecty via a function pointer. Unfortunatly it has to be compiled in
the kernel and cannot be written as a LKM module.

But anyway - I sad down and got a working solution very quickly! I'm
very glad with it! I needed not more than 45 minutes to get this
working! Works in textmode (gpm) and under X11 as expected!


Testing
-------
I have tested my patch only on my own notebook (Compaq M300). It would
help a lot if there are some volunteers...


Future Plans
------------
[x] make the "disable trackpad time" configurable via the /proc
filesystem. Do you think that /proc/sys/kernel/trackpad is a good place
for it? There are other files under the /proc/sys/kernel directory that
fall in the category "keyboard handling", e.g. ctrl-alt-del or sysrq.

[x] make a /proc entry to allow "disable trackpad" and "enable
trackpad". That would allow to turn the builtin trackpad off when an
external mouse is pluged in, and to re-enable it when an external mouse
is unplugged again.


Here is the patch
-----------------
Måns Rullgård
2003-05-01 22:13:53 UTC
Permalink
static inline void handle_keyboard_event(unsigned char scancode)
{
+
+#ifdef CONFIG_DISABLE_TRACKPAD_WHILE_TYPING
+
+ /* setup a timer to re-enable the trackpad */
+ static struct timer_list enable_trackpad_timer;
+ static int enable_trackpad_timer_initialized=3D0;
+
+ disable_trackpad_while_typing=3D1; /* disable trackpad */
+
+ if(enable_trackpad_timer_initialized)
+ {
+ /* trackpad timer already exists, - just restart it=
*/
+ mod_timer(&enable_trackpad_timer, jiffies+trackpad_=
delay);
+ }
+ else
+ {
+ /* no trackpad timer yet. Initialize and start it *=
/
+ init_timer(&enable_trackpad_timer);
+ enable_trackpad_timer.expires=3Djiffies+trackpad_de=
lay;
+ enable_trackpad_timer.function=3Denable_trackpad;
+ add_timer(&enable_trackpad_timer);
+ enable_trackpad_timer_initialized=3D1;
The else block would probably be better off in some initialization
function. Maybe the same place that sets up the interrupt handler is
appropriate.

--=20
M=E5ns Rullg=E5rd
***@users.sf.net
Hans-Georg Thien
2003-05-02 09:41:56 UTC
Permalink
Ups, it seems that the majordomo has eaten the initial part of the mail...
(Multipart EMail problem?)

Here is the initial posting without the patch

[InitialPart]

Sorry for this long text and my bad english. And please be kind to me -
it is my very first posting to this mailing list ...

I have written a *very small* patch against the linux 2.4.20 kernel and
I want to submit it now.

The short story
---------------
The trackpad on the MacIntosh iBook Notebooks have a feature that
prevents unintended trackpad input while typing on the keyboard. There
are no mouse-moves or mouse-taps for a short period of time after each
keystroke.

I believe that many people with i386 notebooks would like this feature
and I want to give it to the linux community.

First I had the idea of writing a loadable kernel module "trackpad" that
implements that feature and is loadable via

insmod keybd_irq=? mouse_irq=? delay=?

The long story
--------------
My first approach was - because I came from the bad old M$-DOS times -
write something like a "terminate and stay resident program"

Procedure LoadModule
Save the currentlly installed handlers for keyboard and mouse.
Install your own interrupt handlers for keyboard and mouse.
End

Procedure UnloadModule
Stop and remove "reset-timer" if necessary
Restore the saved interrupt handlers for keyboard and mouse
End

Procedure KbdHandler
Stop or modify "reset-timer" if necessary
Set global variable block_mouse_events=1
Start a timer that resets block_mouse_events=0 after ??? mSec
Call the old keyboard interrupt handler
End

Proceure MouseHandler
if block_mouse_events>0 then
call ACK(mouse irq) if necessary
do nothing
else
call old mouse interrupt handler
End


So I bought the book "Linux Device Drivers" written by Alessandro Rubini
& Jonathan Corbert. It is an excellent book about LKM, but I couldn't
find a way to "save and restore" irq-handlers as in the design
described above.

That's why I requested a little help in the newsgroup at
comp.os.linux.development.system. This ended up with some people who
said "don't mess around with irq-handlers in that way".

While trying to gain a deeper understanding of irq-handling - espically
for mouse and keyboard handlers - I found out that the keyboard and
mouse interrupts are handled *both* in
/usr/src/linux/drivers/char/pc_keyb.c.

Ok, that is only true for PS/2 mice, but the majority of notebooks on
the market have a PS/2 trackpad. On modifiying the pc_keyb.c file there
is no longer a need to save/restore Interrupt handlers or to call them
indirecty via a function pointer. Unfortunatly it has to be compiled in
the kernel and cannot be written as a LKM module.

But anyway - I sad down and got a working solution very quickly! I'm
very glad with it! I needed not more than 45 minutes to get this
working! Works in textmode (gpm) and under X11 as expected!


Testing
-------
I have tested my patch only on my own notebook (Compaq M300). It would
help a lot if there are some volunteers...


Future Plans
------------
[x] make the "disable trackpad time" configurable via the /proc
filesystem. Do you think that /proc/sys/kernel/trackpad is a good place
for it? There are other files under the /proc/sys/kernel directory that
fall in the category "keyboard handling", e.g. ctrl-alt-del or sysrq.

[x] make a /proc entry to allow "disable trackpad" and "enable
trackpad". That would allow to turn the builtin trackpad off when an
external mouse is pluged in, and to re-enable it when an external mouse
is unplugged again.

[/InitialPart]
wwp
2003-05-06 09:29:28 UTC
Permalink
Hi Hans-Georg Thien,
Post by Hans-Georg Thien
Sorry for this long text and my bad english. And please be kind to me -
it is my very first posting to this mailing list ...
I have written a *very small* patch against the linux 2.4.20 kernel and
I want to submit it now.
Would it be possible to enable/disable this feature from userspace using an
echo 1 > /proc/blabla, or only using insmod/modprobe -r?
Anyway, very good idea!


Regards,
--
wwp
Hans-Georg Thien
2003-05-06 11:27:10 UTC
Permalink
Post by wwp
Hi Hans-Georg Thien,
Would it be possible to enable/disable this feature from userspace using an
echo 1 > /proc/blabla, or only using insmod/modprobe -r?
Anyway, very good idea!
I'm working on an "echo ??? >/proc/something?" solution, where ??? is

delay=1200 # adjust trackpad to delay 1200 mSec after last keystroke
delay=0 # no delay, => disable that feature


-Hans
Khalid Aziz
2003-05-08 19:12:18 UTC
Permalink
This patch makes it impossible to perform any operation that requires
pressing a key on the keyboard while clicking a mouse button - for
example bringing up X-terminal menu with CTRL-<middle button>. I am sure
there are other similar combination used by other software. You would
think 1 second after the CTRL key is pressed (which is when a keyboard
event is generated), mouse will be re-enabled and you should be able to
click mouse buttons as long as you do not let go of the key. Does not
seem to work that way. Mouse stays disabled as long as the key is
pressed.

--
Khalid
Post by Hans-Georg Thien
Sorry for this long text and my bad english. And please be kind to me -
it is my very first posting to this mailing list ...
I have written a *very small* patch against the linux 2.4.20 kernel and
I want to submit it now.
The short story
---------------
The trackpad on the MacIntosh iBook Notebooks have a feature that
prevents unintended trackpad input while typing on the keyboard. There
are no mouse-moves or mouse-taps for a short period of time after each
keystroke.
I believe that many people with i386 notebooks would like this feature
and I want to give it to the linux community.
First I had the idea of writing a loadable kernel module "trackpad" that
implements that feature and is loadable via
insmod keybd_irq=? mouse_irq=? delay=?
The long story
--------------
My first approach was - because I came from the bad old M$-DOS times -
write something like a "terminate and stay resident program"
Procedure LoadModule
Save the currentlly installed handlers for keyboard and mouse.
Install your own interrupt handlers for keyboard and mouse.
End
Procedure UnloadModule
Stop and remove "reset-timer" if necessary
Restore the saved interrupt handlers for keyboard and mouse
End
Procedure KbdHandler
Stop or modify "reset-timer" if necessary
Set global variable block_mouse_events=1
Start a timer that resets block_mouse_events=0 after ??? mSec
Call the old keyboard interrupt handler
End
Proceure MouseHandler
if block_mouse_events>0 then
call ACK(mouse irq) if necessary
do nothing
else
call old mouse interrupt handler
End
So I bought the book "Linux Device Drivers" written by Alessandro Rubini
& Jonathan Corbert. It is an excellent book about LKM, but I couldn't
find a way to "save and restore" irq-handlers as in the design
described above.
That's why I requested a little help in the newsgroup at
comp.os.linux.development.system. This ended up with some people who
said "don't mess around with irq-handlers in that way".
While trying to gain a deeper understanding of irq-handling - espically
for mouse and keyboard handlers - I found out that the keyboard and
mouse interrupts are handled *both* in
/usr/src/linux/drivers/char/pc_keyb.c.
Ok, that is only true for PS/2 mice, but the majority of notebooks on
the market have a PS/2 trackpad. On modifiying the pc_keyb.c file there
is no longer a need to save/restore Interrupt handlers or to call them
indirecty via a function pointer. Unfortunatly it has to be compiled in
the kernel and cannot be written as a LKM module.
But anyway - I sad down and got a working solution very quickly! I'm
very glad with it! I needed not more than 45 minutes to get this
working! Works in textmode (gpm) and under X11 as expected!
Testing
-------
I have tested my patch only on my own notebook (Compaq M300). It would
help a lot if there are some volunteers...
Future Plans
------------
[x] make the "disable trackpad time" configurable via the /proc
filesystem. Do you think that /proc/sys/kernel/trackpad is a good place
for it? There are other files under the /proc/sys/kernel directory that
fall in the category "keyboard handling", e.g. ctrl-alt-del or sysrq.
[x] make a /proc entry to allow "disable trackpad" and "enable
trackpad". That would allow to turn the builtin trackpad off when an
external mouse is pluged in, and to re-enable it when an external mouse
is unplugged again.
--
====================================================================
Khalid Aziz Linux and Open Source Lab
(970)898-9214 Hewlett-Packard
***@hp.com Fort Collins, CO

"The Linux kernel is subject to relentless development"
- Alessandro Rubini
Hans-Georg Thien
2003-05-09 11:47:47 UTC
Permalink
[...] impossible to perform any operation that requires
pressing a key on the keyboard while clicking a mouse button - for
example bringing up X-terminal menu with CTRL-<middle button>. I am sure
there are other similar combination used by other software. You would
think 1 second after the CTRL key is pressed (which is when a keyboard
event is generated), mouse will be re-enabled and you should be able to
click mouse buttons as long as you do not let go of the key. Does not
seem to work that way. Mouse stays disabled as long as the key is
pressed.
Thanks a lot Khalid! I have fixed that now.

Now, when you first press a key the trackpad is disabled. But the
"timer" is not restarted now when you hold the key pressed down
(prev_scancode == actual_scancode).
Hans-Georg Thien
2003-05-27 20:47:06 UTC
Permalink
Post by Hans-Georg Thien
The short story
---------------
Apple MacIntosh iBook Notebooks computers have a nice feature that
prevents unintended trackpad input while typing on the keyboard. There
are no mouse-moves or mouse-taps for a short period of time after each
keystroke. I wanted to have this feature on my i386 notebook ...
It it is now possible to adjust some settings via

echo ???? > /proc/tty/ps2-trackpad

(1) Set the delay time to 2 Secs (default is 10 ==> 1 Sec)

echo "delay 20" > /proc/tty/ps2-trackpad


(2) Completely disable the trackpad (default 0). Useful if you plug in
an external mouse.

echo "disable 1" > /proc/tty/ps2-trackpad

(3) Escape the keyboard scancode for a key. These scancodes are
passed without a delay. (defaults are the scancodes for CTRL and SHIFT
keys).

This is useful for some applications ( like xterm ) which are using
keydown events in combination with mouseclick events.

You can use showkey -s to find out the scancodes of your own keys.
To unescape a scancode you must apply that scancode twice! For keys with
multiple scancodes you must use the *last* generated scancode.

Example: define an escape for HOME-KeyDown

echo "escape 0x047" > /proc/tty/ps2-trackpad
wwp
2003-05-27 21:10:26 UTC
Permalink
Hi Hans-Georg Thien,
[snip]
Post by Hans-Georg Thien
It it is now possible to adjust some settings via
echo ???? > /proc/tty/ps2-trackpad
(1) Set the delay time to 2 Secs (default is 10 ==> 1 Sec)
echo "delay 20" > /proc/tty/ps2-trackpad
(2) Completely disable the trackpad (default 0). Useful if you plug in
an external mouse.
echo "disable 1" > /proc/tty/ps2-trackpad
(3) Escape the keyboard scancode for a key. These scancodes are
[snip]

Sounds good, thanx for your work, guy :-).
Do you think/know if this patch will be merged to the official tree?


Regards,
--
wwp
Hans-Georg Thien
2003-05-29 12:07:09 UTC
Permalink
Post by wwp
Hi Hans-Georg Thien,
[snip]
Post by Hans-Georg Thien
It it is now possible to adjust some settings via
echo ???? > /proc/tty/ps2-trackpad
(1) Set the delay time to 2 Secs (default is 10 ==> 1 Sec)
echo "delay 20" > /proc/tty/ps2-trackpad
(2) Completely disable the trackpad (default 0). Useful if you plug in
an external mouse.
echo "disable 1" > /proc/tty/ps2-trackpad
(3) Escape the keyboard scancode for a key. These scancodes are
[snip]
Sounds good, thanx for your work, guy :-).
Do you think/know if this patch will be merged to the official tree?
I hope, of course ... If you know a way to enforce it - let me know!
Hans-Georg Thien
2003-09-30 20:51:54 UTC
Permalink
I have written a patch against the linux 2.4.x kernel and I want to port
it to the 2.6.x Kernel now.

What it is
- ----------
The trackpad on the MacIntosh iBook notebooks have a feature that
prevents unintended trackpad input while typing on the keyboard. There
are no mouse-moves or mouse-taps for a short period of time after each
keystroke.

I thougt that was a nice-to-have for my i386 notebook and have
implemented it ( with some very important help of other people, namely
Torsten Foertsch ).

This feature is fully configurable via a proc entry.

How it currently works
- ----------------------

In the 2.4.x kernel the handling of keyboard and PS/2 mouse where both
done in linux/drivers/char/pc_keyb.c. So it was easy to apply a patch
without touching other files.

It simply stores a timestamp whenever a key event occurs. If a mouse
event occurs it compares the timestamp of the mouse event with stored
timestamp of the key event. If the delta of these timestamps is less
than a treshold value, than this mouse event is simply discarded. There
where some things more to consider about, but I think you have the idea.

Where I need help now
- ---------------------
Since I do not want to touch the keyboard driver, I wonder if there is
better way to get the timestamp when the last keyboard event occured?

Maybe a function call, a callback function where I can register to the
be notified when a event occurs, a global accessible variable, a proc
entry or something like that.

Any ideas ?

- - Hans
Hans-Georg Thien
2003-10-02 17:40:41 UTC
Permalink
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 entry

or something like that.

Any ideas ?

- Hans
Karim Yaghmour
2003-10-02 18:54:13 UTC
Permalink
Post by 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 entry
or something like that.
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.

HTH,

Karim
--
Author, Speaker, Developer, Consultant
Pushing Embedded and Real-Time Linux Systems Beyond the Limits
http://www.opersys.com || ***@opersys.com || 514-812-4145
Richard B. Johnson
2003-10-02 18:59:28 UTC
Permalink
Post by 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?
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() and poll(),
all useful for handling such events. If you want a time-stamp, you
call gettimeofday() in your signal handler.


Cheers,
Dick Johnson
Penguin : Linux version 2.4.22 on an i686 machine (797.90 BogoMips).
Note 96.31% of all statistics are fiction.
Peter Chubb
2003-10-02 22:46:34 UTC
Permalink
Hans-Georg> I am looking for a possibility to read out the last
Hans-Georg> timestamp when an interrupt has occured.

Hans-Georg> e.g.: the user presses a key on the keyboard. Where can I
Hans-Georg> read out the timestamp of this event?

Hans-Georg> To be more precise, I 'm looking for

Hans-Georg> ( )a function call ( ) a callback where I can register to
Hans-Georg> be notified when an event occurs ( ) a global accessible
Hans-Georg> variable ( ) a /proc entry

Hans-Georg> or something like that.

Hans-Georg> Any ideas ?

If you have the microstate accoounting patch applied, then the
timestamp of each last IRQ is in the array msa_irq_entered[cpu][irq],
measured as an architecture-specific number. Convert it to
nanoseconds since boot with MSA_TO_NSEC


Peter C
Hans-Georg Thien
2003-10-04 04:03:55 UTC
Permalink
Post by Richard B. Johnson
Post by 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?
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() and poll(),
all useful for handling such events. If you want a time-stamp, you
call gettimeofday() in your signal handler.
Thanks a lot Richard,

... but ... can I use signals in kernel mode?
Richard B. Johnson
2003-10-06 12:52:31 UTC
Permalink
Post by Hans-Georg Thien
Post by Richard B. Johnson
Post by 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?
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() and poll(),
all useful for handling such events. If you want a time-stamp, you
call gettimeofday() in your signal handler.
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.
Hans-Georg Thien
2003-10-06 18:21:23 UTC
Permalink
Post by Richard B. Johnson
Post by Hans-Georg Thien
Post by Richard B. Johnson
[...]
Post by 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?
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() and poll(),
all useful for handling such events. If you want a time-stamp, you
call gettimeofday() in your signal handler.
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.
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
Richard B. Johnson
2003-10-06 18:34:57 UTC
Permalink
Post by Hans-Georg Thien
Post by Richard B. Johnson
Post by Hans-Georg Thien
Post by Richard B. Johnson
[...]
Post by 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?
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() and poll(),
all useful for handling such events. If you want a time-stamp, you
call gettimeofday() in your signal handler.
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.
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
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.
Hans-Georg Thien
2003-10-06 19:05:13 UTC
Permalink
Post by 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.
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
Richard B. Johnson
2003-10-06 19:33:22 UTC
Permalink
Post by Hans-Georg Thien
Post by 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.
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 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.
Post by Hans-Georg Thien
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();
}
}
...
Now this pseudo-code shows a "last_kbd_event", not a mouse-
Post by Hans-Georg Thien
Post by Hans-Georg Thien
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.
Hans-Georg Thien
2003-10-06 21:59:35 UTC
Permalink
Post by Richard B. Johnson
Post by Hans-Georg Thien
Post by 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.
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 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
Post by Richard B. Johnson
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
Post by Richard B. Johnson
Post by Hans-Georg Thien
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();
}
}
...
Now this pseudo-code shows a "last_kbd_event", not a mouse-
yes, - I know =8))

It is because I want do some things with the mouse in relation to
keyboard events.
Post by Richard B. Johnson
[... 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.
Post by Richard B. Johnson
When your module is un-installed, it needs to restore the
previous (saved) value of that pointer.
yes, - I know
Post by Richard B. Johnson
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

Hans-Georg Thien
2003-10-04 04:05:02 UTC
Permalink
Post by Karim Yaghmour
Post by 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 entry
or something like that.
Any ideas ?
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
Gabriel Paubert
2003-10-06 15:26:32 UTC
Permalink
Post by Hans-Georg Thien
Post by Karim Yaghmour
Post by 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 entry
or something like that.
Any ideas ?
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*
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
Hans-Georg Thien
2003-10-06 18:37:35 UTC
Permalink
Post by Gabriel Paubert
[...]
Post by Hans-Georg Thien
I am looking for a possibility to read out the last timestamp when an
interrupt has occured.
[...]
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
Loading...