Kernel interface

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

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
omap_twl4030keypad	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, BTN_START, BTN_SELECT, BTN_X, BTN_Y, BTN_A, BTN_B, BTN_TL, BTN_TR	0 - released, 1 - pressed
ADS784x Touchscreen	touchscreen	EV_ABS	ABS_X, ABS_Y, ABS_PRESSURE	varies, use calibration data
vsense66	left nub	EV_ABS	ABS_X, ABS_Y	-256...0...256
vsense67	right nub	EV_ABS	ABS_X, ABS_Y	-256...0...256

Sample code: evtest.c pnd_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..

LED's

The LED's can be controlled via /sys/class/leds/, and then a file [1]:

• pandora::bluetooth
• pandora::lcd_bl This is going to move to /sys/class/backlight/ by the time Pandora is shipped
• pandora::sd2
• pandora::charger
• pandora::power
• pandora::wifi
• pandora::keypad_bl
• pandora::sd1

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).
• /proc/pandora/wait_vsync - if you read this file, your process will block until next vsync interrupt (note: this might change to fbdev ioctl).

more to come..