Difference between revisions of "Kernel interface"
m (Forgot hold key) |
(updates) |
||
Line 4: | Line 4: | ||
==Input== | ==Input== | ||
+ | '''Warning''': if your goal is just to read inputs use higher level libraries/interfaces like SDL, X input or similar for your own good (portability). It may be impossible to retain this layout on some major hardware revision, let's say Pandora 3000, and your program will break. | ||
+ | |||
Buttons, keypad, touchscreen and nubs are all exposed through Linux event interface (EVDEV). All devices are represented by /dev/input/eventX files, which can be opened, read and queried (using ioctl calls). The reads can be synchronous (the read will only return when user does something, like presses the button), or asynchronous (the system will report what changed since the last time you asked). | Buttons, keypad, touchscreen and nubs are all exposed through Linux event interface (EVDEV). All devices are represented by /dev/input/eventX files, which can be opened, read and queried (using ioctl calls). The reads can be synchronous (the read will only return when user does something, like presses the button), or asynchronous (the system will report what changed since the last time you asked). | ||
Line 29: | Line 31: | ||
!event.value | !event.value | ||
|- | |- | ||
− | | | + | |keypad |
|keypad | |keypad | ||
|EV_KEY | |EV_KEY | ||
Line 47: | Line 49: | ||
|0 - closing, 1 - opening | |0 - closing, 1 - opening | ||
|- | |- | ||
− | | | + | |touchscreen |
|touchscreen | |touchscreen | ||
|EV_ABS | |EV_ABS | ||
Line 53: | Line 55: | ||
|varies, use calibration data | |varies, use calibration data | ||
|- | |- | ||
− | | | + | |nub0 |
|left nub | |left nub | ||
|EV_ABS | |EV_ABS | ||
Line 59: | Line 61: | ||
| -256 (Left/Up) ...0... +256 (Right/Down) | | -256 (Left/Up) ...0... +256 (Right/Down) | ||
|- | |- | ||
− | | | + | |nub1 |
|right nub | |right nub | ||
|EV_ABS | |EV_ABS | ||
Line 66: | Line 68: | ||
|} | |} | ||
− | Sample code | + | Sample code:<br> |
[http://beagleboard.googlecode.com/files/evtest.c evtest.c] | [http://beagleboard.googlecode.com/files/evtest.c evtest.c] | ||
− | [http:// | + | [http://git.openpandora.org/cgi-bin/gitweb.cgi?p=pandora-misc.git;a=blob;f=op_test_inputs.c;hb=HEAD op_test_inputs.c] |
===Touchscreen=== | ===Touchscreen=== | ||
Line 93: | Line 95: | ||
Some things can be controlled through files in /proc/pandora/: | Some things can be controlled through files in /proc/pandora/: | ||
* /proc/pandora/cpu_mhz_max - if [http://www.kernel.org/pub/linux/utils/kernel/cpufreq/cpufreq.html cpufreq] is enabled, sets maximum allowed cpu clock, if not, just sets CPU clock to value supplied (echo 600 > /proc/pandora/cpu_mhz_max). Might also just use cpufreq parameters themselves. | * /proc/pandora/cpu_mhz_max - if [http://www.kernel.org/pub/linux/utils/kernel/cpufreq/cpufreq.html cpufreq] is enabled, sets maximum allowed cpu clock, if not, just sets CPU clock to value supplied (echo 600 > /proc/pandora/cpu_mhz_max). Might also just use cpufreq parameters themselves. | ||
− | |||
more to come.. | more to come.. | ||
[[Category:Development]] | [[Category:Development]] |
Revision as of 21:11, 26 April 2010
Warning: this is preliminary and is subject to change until release.
In case you need to write low level code (you can't/don't want to use high level libs like SDL), you can use kernel interface. This is the recommended way to access hardware (as opposed to GP2X style of accessing chip registers by mmap'ing /dev/mem), because in case hardware changes are needed in future, they could be handled by kernel and all programs would still work. It also should allow several programs to work at the same time and should be more stable.
Input
Warning: if your goal is just to read inputs use higher level libraries/interfaces like SDL, X input or similar for your own good (portability). It may be impossible to retain this layout on some major hardware revision, let's say Pandora 3000, and your program will break.
Buttons, keypad, touchscreen and nubs are all exposed through Linux event interface (EVDEV). All devices are represented by /dev/input/eventX files, which can be opened, read and queried (using ioctl calls). The reads can be synchronous (the read will only return when user does something, like presses the button), or asynchronous (the system will report what changed since the last time you asked).
Warning: don't hardcode device filenames in your program! For example, currently /dev/input/event2 represents game buttons, but in future it may become touchscreen. Scan input device names instead, example:
for (i = 0; 1; i++)
{
sprintf(name, "/dev/input/event%i", i);
fd = open(name, O_RDONLY);
if (fd < 0) break; /* no more devices */
ioctl(fd, EVIOCGNAME(sizeof(name)), name);
if (strcmp(name, "gpio-keys") == 0)
return fd; /* found the buttons! */
close(fd); /* we don't need this device */
}
List of device names and events they send:
name | description | event.type | event.code | event.value |
---|---|---|---|---|
keypad | keypad | EV_KEY | KEY_0...KEY_Z, KEY_BACKSPACE, KEY_LEFTSHIFT, KEY_SPACE, KEY_ENTER, KEY_COMMA, KEY_DOT, KEY_FN | 0 - released, 1 - pressed, 2 - autorepeat event |
gpio-keys | game buttons | EV_KEY | KEY_UP, KEY_DOWN, KEY_LEFT, KEY_RIGHT, KEY_MENU (Pandora button), KEY_LEFTALT (Start), KEY_LEFTCTRL (Select), KEY_KP1 (Y/North), KEY_KP2 (A/East), KEY_KP3 (X/South), KEY_KP4 (B/West), KEY_KP5 (Shoulder L), KEY_KP6 (Shoulder R), KEY_KP7 (Shoulder L2), KEY_KP8 (Shoulder R2), KEY_COFFEE (Hold) | 0 - released, 1 - pressed |
gpio-keys | lid state | EV_SW | SW_LID | 0 - closing, 1 - opening |
touchscreen | touchscreen | EV_ABS | ABS_X, ABS_Y, ABS_PRESSURE | varies, use calibration data |
nub0 | left nub | EV_ABS | ABS_X, ABS_Y | -256 (Left/Up) ...0... +256 (Right/Down) |
nub1 | right nub | EV_ABS | ABS_X, ABS_Y | -256 (Left/Up) ...0... +256 (Right/Down) |
Sample code:
evtest.c
op_test_inputs.c
Touchscreen
Event interface returns uncalibrated values directly from driver, so you need to use tslib or manage calibration yourself (using data from /etc/pointercal).
Sound
Pandora uses ALSA, but it has OSS emulation enabled too, so GP2X code should work.
Video
Framebuffer device (/dev/fb0) is supported. More to come..
LEDs and backlight
The LEDs can be controlled via /sys/class/leds/, and then a file [1]:
- pandora::sd1
- pandora::sd2
- pandora::charger
- pandora::power
- pandora::bluetooth
- pandora::wifi
- pandora::keypad_bl
Backlight can be controlled via /sys/class/backlight/.
Misc
Some things can be controlled through files in /proc/pandora/:
- /proc/pandora/cpu_mhz_max - if cpufreq is enabled, sets maximum allowed cpu clock, if not, just sets CPU clock to value supplied (echo 600 > /proc/pandora/cpu_mhz_max). Might also just use cpufreq parameters themselves.
more to come..