Keyboard Info


bpmurray

Still Fresh
Joined
Mar 5, 2006
Messages
38
Age
68
Location
Ireland
Website
louthanglers.8k.com
How can I identify the keys pressed in C/C++? I don't want to add SDL to the mix, particularly since I have most of it working. However, I can't seem to work out the input from the /dev/GPIO device - what are the mask values returned?
 
bpmurray posted on May 3 2006 at 10:34 PM said:
How can I identify the keys pressed in C/C++? I don't want to add SDL to the mix, particularly since I have most of it working. However, I can't seem to work out the input from the /dev/GPIO device - what are the mask values returned?
Have you seen this?

The notation used on that page is [GPIO register][bit], i.e. for the left shoulder button, C10 is GPIO register C, bit 10. The controls are designated active low, so the bits for each control are normally set to 1, and when the appropriate button is pressed, the bit is reset to 0.

I have some working code which I can clean up if you're looking for an example...
 
Last edited by a moderator:
Thanks - this looks interesting, but it uses memory-mapped registers. I'm reading directly from the /dev/GPIO device, so I suppose I'll have to see how these map to the return values from the read().
 
bpmurray posted on May 3 2006 at 11:22 PM said:
Thanks - this looks interesting, but it uses memory-mapped registers. I'm reading directly from the /dev/GPIO device, so I suppose I'll have to see how these map to the return values from the read().
I didn't even cop onto that (/dev/GPIO) in your message, I'd never noticed that you could access the GPIO like that, but I'm sure there is a speed penalty. I'll have to look into this now, as it could be useful for quick and dirty programs.

The format looks a little bit like it could well be firmware specific, so it might not be a good idea to rely on it. I did a google search and found this in the cache, on the official developer forum, of all places, and the weirdest thing is that it no longer seems to be available!!! Perhaps you have to log in, but I can't remember my login right now...
 
Last edited by a moderator:
I was trying to find that post on dev.gp2x.com last night - in a way I'm glad it's been confirmed as removed because it means I'm not going insane :blink:. I think a load of other interesting posts have disappeared off there too for some strange reason. I'd say that way of checking input is safe to use because it's the code used in GPH's version of SDL.
 
OK, found out the painful way - press the button & log the result for each button :blink:

The returned value from the read are all 4 bytes long, and are masked as follows:

Code:
#define GP2X_BUTTON_UP			  0x00000001
#define GP2X_BUTTON_UPLEFT		  0x00000002
#define GP2X_BUTTON_LEFT			0x00000004
#define GP2X_BUTTON_DOWNLEFT		0x00000008
#define GP2X_BUTTON_DOWN			0x00000010
#define GP2X_BUTTON_RIGHT		   0x00000020
#define GP2X_BUTTON_DOWNRIGHT	   0x00000040
#define GP2X_BUTTON_UPRIGHT		 0x00000080
#define GP2X_BUTTON_START		   0x00000100
#define GP2X_BUTTON_SELECT		  0x00000200
#define GP2X_BUTTON_L			   0x00000400
#define GP2X_BUTTON_R			   0x00000800
#define GP2X_BUTTON_A			   0x00001000
#define GP2X_BUTTON_B			   0x00002000
#define GP2X_BUTTON_X			   0x00004000
#define GP2X_BUTTON_Y			   0x00008000
#define GP2X_BUTTON_VOLDOWN		 0x00010000
#define GP2X_BUTTON_VOLUP		   0x00020000
#define GP2X_BUTTON_CLICK		   0x00040000

All values appear to have the bits 0xFFF80000 ON, so the return value should be masked against 0x0007FFFF.

Just FYI - I'm trying to port nano-x to provide an underpinning for Java. The mouse functionality seems fine - just working on the keyboard now. Where can I post the completed stuff? Is there somewhere that hosts the source & binaries of ported code?
 
woogal posted on May 4 2006 at 09:07 AM said:
I was trying to find that post on dev.gp2x.com last night - in a way I'm glad it's been confirmed as removed because it means I'm not going insane :blink:. I think a load of other interesting posts have disappeared off there too for some strange reason. I'd say that way of checking input is safe to use because it's the code used in GPH's version of SDL.
I would love to know why it was removed, as it doesn't seem like they're going to foster much of a developer community if they remove valuable information like that! Also, although you say it should be safe because GPH use it in their build of SDL, don't forget that their SDL libraries will presumably be updated with each new firmware, so if they change the behaviour of /dev/GPIO, they can modify their SDL distribution accordingly.

Snooping through the firmware sources, I think I've found the related code, in drivers/char/mmsp2-key.c, more specifically the MMSP2key_read function, where it shifts bits in from GPIOM[0-7], GPIOC[8-15], GPIOD7, GPIOD6 and GPIOD11. In that case, I think you might have your volume up and down values transposed.

It could be worth your time looking at the IOCTL code there too. Some interesting stuff: Battery LED on/off, LCD backlight...
 
Last edited by a moderator:
Thanks for the tips - I'll have a closer look at that code.

Actually, if this is as undependable as it seems, perhaps it's better to use SDL instead.
 
I'd say the most dependable method would be to ignore /dev/gpio and read the hardware registers directly. Far less chance of the hardware changing that GPH fecking around with the the kernel source and making /dev/gpio return different results (and it'll be slightly faster too).
 
Squidge posted on May 8 2006 at 08:06 PM said:
I'd say the most dependable method would be to ignore /dev/gpio and read the hardware registers directly. Far less chance of the hardware changing that GPH fecking around with the the kernel source and making /dev/gpio return different results (and it'll be slightly faster too).
Unless they reprogram the GPIO so that the keys read active high instead of low...
 
Last edited by a moderator:
Back
Top