Interrupt To Check Keys And Joystick

[marmakoide]

Hi all !
I'am just beginning to get into the GP2X development, learning by making tiny demos. I want to bypass the SDL, to get a full freedom and speed (and also pain ). My actual main problem is to get the events from the keys and the joystick.

what I do now
Direct read of the keys state, as I seen it in a Squidge tutorial on GP2X demo programming

int  isStartButtonPushed() {
  if (mmsp2_regs_16[0x1184 >> 1] & 0x100)
	return 0;

  return 1;
}

The bad thing with this, is I get the state of key at a given moment in my program execution, so I could miss many events, or information such how many time since the last key event.

what I wish to do
Using an interrupt to get the keys (and joystick if possible) events : pressed key released. This way, I miss no event and I could compute the time between keys event. But well, how to do it, and do it well ?
1) The direct way : using a key interrupt, if any ?
2) The indirect way : using a timer interrupt, if any ? Then, at each interrupt I will check all the keys state.

 

[marmakoide]

Ok, after some further readings, it seems that catching the interrupts like in the good old DOS time (int 9 to be precise) is not possible under good OSs like Linux. So my question is now :
* In the "without SDL" case, how do you handle the keyboard and joysticks event ?

 

[gfoot]

The traditional way to implement this kind of thing under Linux is using a device to communicate with the kernel. The app can wait on the device using select or poll (which has a nicer interface IMHO), and the thread will wake up when data arrives. You can run all this on a separate thread, and get the effect of interrupts firing, though obviously you're a lot further from the hardware. It's enough for implementing input responses though. You may have applications that need more delicate control of the interrupts, but for general input it's not necessary.

For the keyboard on PCs this is coupled to data arriving in the buffer, including things like auto-repeating, but you can also knock it into raw mode and just see keypresses and releases. Coupling the buffer's emptiness with the waiting mechanism is an interesting approach, as far as abstractions go - a lot of things in Unix work this way, doing almost everything through files is very Unix, and as a consequence it's a mature mechanism. The same kind of system could be used to wait for vsync without continuously polling it - Shawn Hargreaves (the Allegro author) implemented it for the framebuffer device, but I think it didn't actually get merged into the mainstream kernel in the end.

The GPH kernel does provide /dev/gpio, but I don't know anything about it - maybe they have hooked it up as a buffered event sequence of some kind, or maybe not.

 

[Squidge]

Most of the buttons are not connected to IRQs or FIQ's, so it would be difficult. Best thing to do is just sample the buttons at the end or beginning of each vblank. You shouldn't need to sample at a higher frequency than that anyway.

 

[gfoot]

Yes, it's no good if there's no hardware interrupt there in the first place I got the impression from the MMSP2 databook that you can enable interrupts on any GPIO changes, but maybe that's dependent on the actual hardware configuration, not just under software control. I don't know much about that stuff.

 

[marmakoide]

Actually, I do like Squidge said : after each vblank, I grab the 0x1184 register. But I was quite afraid to miss buttons events, leading to poor game controls. Anyway, you true, 50 hz is not so bad sampling frequency, Keep It Simple Stupid... So I will keep this way.