I’ve recently been working on a real-time system which uses SDL to do the
graphics work. I’m are running a very slim Fedora Core 2, with an RTLinux Free
kernel underneath. I use a real-time kernel module to handle our keyboard
interrupts.
Basically I am displaying visual stimuli using SDL, and when a keystroke is
detectedm, the time is detected from a real-time timer module, and the screen is
immediatly cleared. I have run this setup on several Pentium Pro 2 boxes for a
while. Recently the setup was installed on a few Pentium II 400MHz boxes, and
on these machines the following problem occurs:
When I do an SDL_Init(), keystrokes are not registering until after SDL_Quit().
I wrote a quick diagnostic real-time module to notify me every time it sees ANY
IRQ. We stop recieving any IRQ 1’s (keyboard) after a write to /dev/psaux in
the detect_imps2 function which is called during SDL_Init() (we use the
framebuffer/fbcon).
The line of code (in SDL_fbevents.c) which seems to make the difference is
…
if (write(fd, &query_ps2, sizeof (query_ps2)) == sizeof (query_ps2)) {
…
After this system call… no IRQ 1.
My question is, how is it that this is telling IRQ 1 to be quiet? Its not
simply collecting the keystrokes itself, but telling the device to hold all IRQs
until further notice (it seems to me).
Thanks
Cooper Thompson
Lowly Undergrad
Dept of Psychology
The Ohio State University
Eesh. You wouldn’t think a plain ordinary read would be able to do that…
Is the device being read in any funny mode like non-blocking? You may have
discovered a bug in RTlinux. Can you try a newer kernel? SDL’s not
executing as root, is it?On December 7, 2005 02:41 pm, Cooper Thompson wrote:
The line of code (in SDL_fbevents.c) which seems to make the difference is
…
if (write(fd, &query_ps2, sizeof (query_ps2)) == sizeof (query_ps2)) {
…
After this system call… no IRQ 1.
My question is, how is it that this is telling IRQ 1 to be quiet? Its not
simply collecting the keystrokes itself, but telling the device to hold all
IRQs until further notice (it seems to me).
Tyler Montbriand <tsm accesscomm.ca> writes:
The line of code (in SDL_fbevents.c) which seems to make the difference is
…
if (write(fd, &query_ps2, sizeof (query_ps2)) == sizeof (query_ps2)) {
…
After this system call… no IRQ 1.
My question is, how is it that this is telling IRQ 1 to be quiet? Its not
simply collecting the keystrokes itself, but telling the device to hold all
IRQs until further notice (it seems to me).
Eesh. You wouldn’t think a plain ordinary read would be able to do that…
Is the device being read in any funny mode like non-blocking? You may have
discovered a bug in RTlinux. Can you try a newer kernel? SDL’s not
executing as root, is it?
The reads we do from inside our kernel module use inb(). Its called in a
interrupt request handler, which only gets called when the kernel sees IRQ1.
As far as the SDL write goes, /dev/psaux is opened O_RDWR only (this is in
SDL_fbevents.c), but blocking there doesn’t seem like an issue.
As far as a newer kernel, we use RTLinux Free v3.1. We used the 3.2-pre2
version for a while, but RTLinux 3.1 had support for the linux 2.4.29 kernel,
(whereas we used 2.4.20 before).> On December 7, 2005 02:41 pm, Cooper Thompson wrote:
Cooper Thompson wrote:
The reads we do from inside our kernel module use inb(). Its called in a
interrupt request handler, which only gets called when the kernel sees IRQ1.
As far as the SDL write goes, /dev/psaux is opened O_RDWR only (this is in
SDL_fbevents.c), but blocking there doesn’t seem like an issue.
As far as a newer kernel, we use RTLinux Free v3.1. We used the 3.2-pre2
version for a while, but RTLinux 3.1 had support for the linux 2.4.29 kernel,
(whereas we used 2.4.20 before).
What does cat /proc/interrupts say ? Btw, you can see the number of
interrupts from here, instead of writing another module.
I’m not sure what your kernel module looks like, but if you touched the
i8042 code, you might very well have some interaction with a PS/2 mouse.
Stephane
Stephane Marchesin <stephane.marchesin wanadoo.fr> writes:
Cooper Thompson wrote:
The reads we do from inside our kernel module use inb(). Its called in a
interrupt request handler, which only gets called when the kernel sees IRQ1.
As far as the SDL write goes, /dev/psaux is opened O_RDWR only (this is in
SDL_fbevents.c), but blocking there doesn’t seem like an issue.
As far as a newer kernel, we use RTLinux Free v3.1. We used the 3.2-pre2
version for a while, but RTLinux 3.1 had support for the linux 2.4.29 kernel,
(whereas we used 2.4.20 before).
What does cat /proc/interrupts say ? Btw, you can see the number of
interrupts from here, instead of writing another module.
I’m not sure what your kernel module looks like, but if you touched the
i8042 code, you might very well have some interaction with a PS/2 mouse.
Stephane
$cat /proc/interrupts
CPU0
0: 5432 RTLinux virtual irq timer
1: 79 RTLinux virtual irq keyboard
2: 0 RTLinux virtual irq cascade
9: 14 RTLinux virtual irq usb-uhci, eth0
14: 1910 RTLinux virtual irq ide0
15: 343 RTLinux virtual irq ide1
222: 0 RTLinux virtual irq RTLinux Scheduler
223: 0 RTLinux virtual irq RTLinux FIFO
NMI: 0
ERR: 0
And the module I wrote prints a message (rtl_printf, basically a printk)
everytime it sees an IRQ (in real-time). So I can see when interrupts are
occuring. Its for debugging only of course, as typing ‘ps’ yields:
$IRQ 1 detected!
p
IRQ 1 detected!
s
My very sophisticated debugging method has been to run our test driver, smashing
keys continuously, looking for when I no longer see IRQs, (relative to debug
statements from the code).
I’m starting to think this thread might belong in a kernel forum somewhere
rather than on an SDL newsgroup.
Cooper Thompson wrote:
Stephane Marchesin <stephane.marchesin wanadoo.fr> writes:
Cooper Thompson wrote:
The reads we do from inside our kernel module use inb(). Its called in a
interrupt request handler, which only gets called when the kernel sees IRQ1.
As far as the SDL write goes, /dev/psaux is opened O_RDWR only (this is in
SDL_fbevents.c), but blocking there doesn’t seem like an issue.
As far as a newer kernel, we use RTLinux Free v3.1. We used the 3.2-pre2
version for a while, but RTLinux 3.1 had support for the linux 2.4.29 kernel,
(whereas we used 2.4.20 before).
What does cat /proc/interrupts say ? Btw, you can see the number of
interrupts from here, instead of writing another module.
I’m not sure what your kernel module looks like, but if you touched the
i8042 code, you might very well have some interaction with a PS/2 mouse.
Stephane
$cat /proc/interrupts
CPU0
0: 5432 RTLinux virtual irq timer
1: 79 RTLinux virtual irq keyboard
2: 0 RTLinux virtual irq cascade
9: 14 RTLinux virtual irq usb-uhci, eth0
14: 1910 RTLinux virtual irq ide0
15: 343 RTLinux virtual irq ide1
222: 0 RTLinux virtual irq RTLinux Scheduler
223: 0 RTLinux virtual irq RTLinux FIFO
NMI: 0
ERR: 0
And the module I wrote prints a message (rtl_printf, basically a printk)
everytime it sees an IRQ (in real-time). So I can see when interrupts are
occuring. Its for debugging only of course, as typing ‘ps’ yields:
$IRQ 1 detected!
p
IRQ 1 detected!
s
My very sophisticated debugging method has been to run our test driver, smashing
keys continuously, looking for when I no longer see IRQs, (relative to debug
statements from the code).
I’m starting to think this thread might belong in a kernel forum somewhere
rather than on an SDL newsgroup.
That’s quite what I think too 
I don’t think there’s a way to know without seeing the code for your
kernel module (and even then I’m not sure I could tell what the problem
is). In any case, my point is that the i8042 code handles both ps/2
keyboard and mouse, so you might very well have a side effect in your
module.
Stephane