PC keyboard rate/delay
In file include/linux/kd.h was declared KDKBDREP ioctl number to tune up keyboard rate/delay with struct kbd_repeat. But in 2.4.x kernel there is only m68k version for that. I wrote some code for implement this feature on x86 machines. Gzipped and uuencoded patch for kernel 2.4.5 is attached. To setup keyboard rate/delay on x86 you should use code like that:
struct kbd_repeat kbd_rep={
1000, /* delay in ms */
30 /* repeat rate in cps */
};ioctl(0,KDKBDREP,&kbd_rep);
After that ioctl kbd_rep is filled with previous values.
I hope it will be useful for someone.
Quoted 7 lines
In file
include/linux/kd.hwas declared KDKBDREP ioctl number to tune up keyboard rate/delay with structkbd_repeat. But in 2.4.x kernel there is only m68k version for that. I wrote some code for implement this feature on x86 machines. Gzipped and uuencoded patch for kernel 2.4.5 is attached. To setup keyboard rate/delay on x86 you should use code like that:
Quoted 8 lines
struct
kbd_repeatkbd_rep={
1000, /* delay in ms */
30 /* repeat rate in cps */
};ioctl(0,KDKBDREP,&kbd_rep);After that ioctl
kbd_repis filled with previous values. I hope it will be useful for someone.
You must have been reading my mind. Yesterday I traced at least one X11 hang down to the kernel and X server both frobbing with the port at the same time and crashing the microcontroller on my PC110.
Alan
Quoted 14 lines
Quoted 14 lines
In file
include/linux/kd.hwas declared KDKBDREP ioctl number to tune up keyboard rate/delay with structkbd_repeat. But in 2.4.x kernel there is only m68k version for that. I wrote some code for implement this feature on x86 machines. Gzipped and uuencoded patch for kernel 2.4.5 is attached. To setup keyboard rate/delay on x86 you should use code like that:struct
kbd_repeatkbd_rep={
1000, /* delay in ms */
30 /* repeat rate in cps */
};ioctl(0,KDKBDREP,&kbd_rep);
Quoted 6 lines
Quoted 2 lines
After that ioctl
kbd_repis filled with previous values. I hope it will be useful for someone.You must have been reading my mind. Yesterday I traced at least one X11 hang down to the kernel and X server both frobbing with the port at the same time and crashing the microcontroller on my PC110.
Also the beeper is a problem. Have X and a console app set off a beep at the same time. I'm glad the input api will make these problems go away :-)
AC> You must have been reading my mind. Yesterday I traced at least one X11 AC> hang down to the kernel and X server both frobbing with the port at the same AC> time and crashing the microcontroller on my PC110.
I think it would be better to place all of kbd controller code into the kernel instead of using various userspace programs such as kbdrate. Otherwise why KDKBDREP was defined ?-)
Sergey Tursanov mailto:[email protected]
Quoted 7 lines · Sergey Tursanov
AC> You must have been reading my mind. Yesterday I traced at least one X11 AC> hang down to the kernel and X server both frobbing with the port at the same AC> time and crashing the microcontroller on my PC110.
I think it would be better to place all of kbd controller code into the kernel instead of using various userspace programs such as kbdrate. Otherwise why KDKBDREP was defined ?-)
Because (almost?) all m68k machines don't have PC style keyboard controllers, so we _had_ to invent some other way to implement it in a portable (across all m68k machines) way.
<wishful thinking>
Of course it would be nice if all architectures would want to use it. </wishful thinking>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Quoted 4 lines
Because (almost?) all m68k machines don't have PC style keyboard controllers, so we _had_ to invent some other way to implement it in a portable (across all m68k machines) way.
This stuff is such a mess :-( Sparc has its own routines as well.
Quoted 3 lines
<wishful thinking>
Of course it would be nice if all architectures would want to use it. </wishful thinking>
It will for 2.5.X :-)
Quoted 5 lines · James Simmons
Quoted 3 lines
Because (almost?) all m68k machines don't have PC style keyboard controllers, so we _had_ to invent some other way to implement it in a portable (across all m68k machines) way.
This stuff is such a mess :-( Sparc has its own routines as well.
Ours is older :-)
Quoted 5 lines
Quoted 3 lines
<wishful thinking>
Of course it would be nice if all architectures would want to use it. </wishful thinking>It will for 2.5.X :-)
Good!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Quoted 2 lines
Quoted 1 line
It will for 2.5.X :-)
Good!
Since it lets anyone hang many boxes by careful combined use of X and gpm I suspect it wants fixing in 2.4
Quoted 7 lines · Sergey Tursanov
AC> You must have been reading my mind. Yesterday I traced at least one X11 AC> hang down to the kernel and X server both frobbing with the port at the same AC> time and crashing the microcontroller on my PC110.
I think it would be better to place all of kbd controller code into the kernel instead of using various userspace programs such as kbdrate. Otherwise why KDKBDREP was defined ?-)
KDKBDREP on m68k
KIOCSRATE on sparc/dev/port on i386 etc.
Yes, we want to get rid of /dev/port.
Quoted 3 lines · Sergey Tursanov
In file
include/linux/kd.hwas declared KDKBDREP ioctl number But in 2.4.x kernel there is only m68k version for that. I wrote some code for implement this feature on x86 machines.
Yes, it is unfortunate that many ioctls are needlessly different between various architectures. But the utility kbdrate works on all architectures I have tried it on.
Andries