Kernel interface - Revision history

Notaz: line counter, minor updates

2016-02-28T16:18:28Z

line counter, minor updates

Notaz: adaptive vsync

2016-02-28T15:46:48Z

adaptive vsync

Lolla at 10:14, 27 November 2013

2013-11-27T10:14:15Z

Lolla at 10:08, 27 November 2013

2013-11-27T10:08:40Z

Lolla at 10:00, 27 November 2013

2013-11-27T10:00:24Z

Lolla at 09:58, 27 November 2013

2013-11-27T09:58:37Z

Lolla at 09:57, 27 November 2013

2013-11-27T09:57:36Z

Notaz: use "sane" permissions in an example

2013-02-17T00:38:25Z

use "sane" permissions in an example

Notaz: battery stuff

2013-02-16T01:23:32Z

battery stuff

Foft: /* Input */

2012-12-29T21:36:42Z

‎Input

@@ Line 110: / Line 110: @@
 OMAP3 display subsystem is controlled by a driver known as DSS2, which has various controls available on /sys/devices/platform/omapdss/ (but they are not meant to be changed by programs, so they are root writable only). The driver exposes 3 layers (called overlays) and 2 displays. Overlays 1 and 2 can perform hardware scaling on the fly using 5-tap poly-phase filter, overlay0 can not. Displays 0 and 1 represent LCD and TV respectively. By default the 3 framebuffers (/dev/fbX) are redirected to 3 overlays, which all output to the LCD. This configuration is not meant to be changed by programs, only firmware should manage these.
 ===Basic usage===
@@ Line 138: / Line 140: @@
 ioctl(fbdev, FBIOPAN_DISPLAY, &fbvar);
 </source>
-going back to buffer1 would be repeating above with fbvar.yoffset = 0. Tripple or quad buffering can be implemented using the same technique.
+going back to buffer1 would be repeating above with fbvar.yoffset = 0. Triple or quad buffering can be implemented using the same technique.
 ====vertical sync====
@@ Line 156: / Line 158: @@
 </source>
 =====adaptive vsync=====
-Standard vsync has a problem: if the program takes slightly longer that one frame to update, calling FBIO_WAITFORVSYNC will wait for the whole next frame, wasting time. In the worst case this can halve the framerate, and the CPU ends up being not fully utilized. The program can try to combat this by measuring time since the last wait, but that is not reliable because ioctl may return long after the actual vsync as Linux may need to process other drivers or system threads.
+Standard vsync has a problem: if the program takes slightly longer that one frame to update, calling FBIO_WAITFORVSYNC will wait for the whole next frame, wasting time. In the worst case this can halve the framerate, and the CPU ends up being not fully utilized. The program can try to combat this by measuring time since the last wait, but that is not reliable because ioctl may return long after the actual vsync as Linux may need to process other drivers or system threads before giving back control.
-To solve the above issue, kernel 3.2.78 has introduced a new ioctl:
+To solve the above issue, SZ 1.74 (kernel 3.2.78) has introduced a new ioctl:
 <source lang="c">
 #ifndef OMAPFB_WAITFORVSYNC_FRAME
@@ Line 167: / Line 169: @@
 ioctl(fbdev, FBIO_WAITFORVSYNC, &arg);
 </source>
-OMAPFB_WAITFORVSYNC_FRAME has an unsigned int arg which is the current frame number (both an input and output). The ioctl only waits if the passed arg matches the current frame number, otherwise it instantly returns. It always updates the arg to the current frame number on return.
+OMAPFB_WAITFORVSYNC_FRAME has an unsigned int arg which is the current frame number (both an input and output). The ioctl only waits if the passed arg matches the current frame number that's maintained inside the kernel, otherwise it instantly returns. It always updates the arg to the current frame number on return.
 Making 'arg' static is the easiest way to make it work, but you can keep the variable anywhere else as long as it's preserved between ioctl calls.
 ====hardware scaling====
-Overlay1 (/dev/fb1) can be used to achieve hardware scaling. Technically overlay2 (fb2) can be used for this too, but it is planned to be used by the system for TV-out functionality, so don't use it. The overlay is configured using series of standard and OMAP specific ioctl calls, but the system ships with some tools to achieve this from scripts too. This way the framebuffer can be set up for some arbitrary size (say 320x240) and can output to LCD as 800x480 with hardware scaling.
+Overlay1 (/dev/fb1) can be used to achieve hardware scaling. Technically overlay2 (fb2) can be used for this too, but it is reserved for TV-out functionality and only usable by root, so don't use it. The overlay is configured using series of standard and OMAP specific ioctl calls, but the system ships with some tools to achieve this from scripts too. This way the framebuffer can be set up for some arbitrary size (say 320x240) and can output to LCD as 800x480 with hardware scaling.
 Here is an example script:
 <source lang="bash">
@@ Line 190: / Line 204: @@
 Now the program can act as if it works with 320x240 16bpp screen.
 ====LCD refresh rate====

@@ Line 155: / Line 155: @@
 #endif
 </source>
 ====hardware scaling====

@@ Line 107: / Line 107: @@
 ==Video==
 ===Architecture===
-Framebuffer device (/dev/fbX) is supported. There are 3 framebuffers available ('''/dev/fb0''', /dev/fb1 and /dev/fb2), which represent 3 graphics/video layers on [[OMAP3]] by default (but can be reconfigured). Only /dev/fb0 is enabled by default.
+Framebuffer device (/dev/fbX) is supported. There are 3 framebuffers available ('''/dev/fb0''', /dev/fb1 and /dev/fb2), which represent 3 graphics/video layers on OMAP3 by default (but can be reconfigured). Only /dev/fb0 is enabled by default.
-[[OMAP3]] display subsystem is controlled by a driver known as [[DSS2]], which has various controls available on /sys/devices/platform/omapdss/ (but they are not meant to be changed by programs, so they are root writable only). The driver exposes 3 layers (called overlays) and 2 displays. Overlays 1 and 2 can perform hardware scaling on the fly using 5-tap poly-phase filter, overlay0 can not. Displays 0 and 1 represent LCD and TV respectively. By default the 3 framebuffers (/dev/fbX) are redirected to 3 overlays, which all output to the LCD. This configuration is not meant to be changed by programs, only firmware should manage these.
+OMAP3 display subsystem is controlled by a driver known as DSS2, which has various controls available on /sys/devices/platform/omapdss/ (but they are not meant to be changed by programs, so they are root writable only). The driver exposes 3 layers (called overlays) and 2 displays. Overlays 1 and 2 can perform hardware scaling on the fly using 5-tap poly-phase filter, overlay0 can not. Displays 0 and 1 represent LCD and TV respectively. By default the 3 framebuffers (/dev/fbX) are redirected to 3 overlays, which all output to the LCD. This configuration is not meant to be changed by programs, only firmware should manage these.
 ===Basic usage===
@@ Line 225: / Line 225: @@
 ==Battery==
-There is bq27500 battery monitoring chip onboard, that exports various files at /sys/class/power_supply/bq27500-0/ , for example 'capacity' tells charge percenage left. See [[Data_provided_by_Battery_and_Power_driver]] for more details.<br>
+There is bq27500 battery monitoring chip onboard, that exports various files at /sys/class/power_supply/bq27500-0/ , for example 'capacity' tells charge percenage left. See Data_provided_by_Battery_and_Power_driver for more details.<br>
 There are also similar directories at /sys/class/power_supply/twl4030_* that provide info while charging.

@@ Line 103: / Line 103: @@
 ==Sound==
-Pandora uses [[ALSA]], but it has [[OSS]] emulation enabled too, so [[GP2X]] code should work.
+Pandora uses ALSA, but it has OSS emulation enabled too, so GP2X code should work.
 ==Video==

@@ Line 4: / Line 4: @@
 ==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).
+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

@@ Line 1: / Line 1: @@
 {{hint|For apps use higher level libraries/interfaces like SDL, Qt, X 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. Also this requires some level of Linux programming knowledge.}}
-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.
+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==

@@ Line 115: / Line 115: @@
 Framebuffers can be accessed Linux fbdev interface:
 <source lang="c">
-fbdev = open("/dev/fb0", O_RDONLY);
+fbdev = open("/dev/fb0", O_RDWR);
-buffer = mmap(0, 800*480*2, PROT_WRITE, MAP_SHARED, fbdev, 0);
+buffer = mmap(0, 800*480*2, PROT_READ | PROT_WRITE, MAP_SHARED, fbdev, 0);
 </source>
 (this is basic example, no error checks)

@@ Line 223: / Line 223: @@
 * pandora::keypad_bl
 Backlight can be controlled via '''/sys/class/backlight/'''.
 ==Misc==

@@ Line 42: / Line 42: @@
 |game buttons
 |EV_KEY
-|KEY_UP, KEY_DOWN, KEY_LEFT, KEY_RIGHT, KEY_MENU (Pandora button), KEY_LEFTALT (Start), KEY_LEFTCTRL (Select), KEY_END (Y/North), KEY_HOME (A/East), KEY_PAGEDOWN (X/South), KEY_END (B/West), KEY_RIGHTSHIFT (Shoulder L), KEY_RIGHTCTRL (Shoulder R), KEY_KPPLUS (Shoulder L2), KEY_KPMINUS (Shoulder R2), KEY_COFFEE (Hold)
+|KEY_UP, KEY_DOWN, KEY_LEFT, KEY_RIGHT, KEY_MENU (Pandora button), KEY_LEFTALT (Start), KEY_LEFTCTRL (Select), KEY_PAGEUP (Y/North), KEY_HOME (A/East), KEY_PAGEDOWN (X/South), KEY_END (B/West), KEY_RIGHTSHIFT (Shoulder L), KEY_RIGHTCTRL (Shoulder R), KEY_KPPLUS (Shoulder L2), KEY_KPMINUS (Shoulder R2), KEY_COFFEE (Hold)
 |0 - released<br> 1 - pressed
 |-