Some updates to the kernel (will try to find some time tomorrow to compile and release new binaries):
I just got battery reading working (thanks [email protected]). You can get the voltage in millivolts by reading from /proc/jz/battery. At the moment, and until we have some charge/discharge voltage curves, we cannot relate voltage level to battery charge status.
I know that most (if not all) of you are using the serial console over the USB cable to access your A320, and since the kernel panics when unpluging the cable, it is not possible to trace the discharge curve unless one builds an special USB cable without the +5V line. So in the next days I'll work on fixing the cable unplug bug, and then ask for help on tracing the battery charge/discharge curves.
I also got the LCD backlight working. The FBIOSETBACKLIGH ioctl command now works, but I also implemented a procfs interface and since it doesn't require kernel headers (from the userspace developer's point of view), I would strongly advice to use it instead of ioctls.
Just read/write a value between 0 and 100 to /proc/jz/lcd_backlight. As a refinement I might add a linearization table (the apparent brightness increase is much larger from 0 to 10 than from 90 to 100).
Finally, a couple of notes about the keyboard mapping:
I replaced KEY_KEYBOARD by KEY_MENU (power+select). This keycode is intended to bring up an overlay screen which might include a virtual keyboard, but which will certainly include more functions (volume, brightness, process control, etc). So makes a little more sense to use MENU than KEYBOARD:
I added the KEY_EXIT keycode (power+left shoulder). It is intended to kill the "foreground" application, that is, the one using the framebuffer.
Note: when I say "intended" I mean that an userspace daemon will be needed that will capture those keycodes, bring up the overlay screen, etc.
I just got battery reading working (thanks [email protected]). You can get the voltage in millivolts by reading from /proc/jz/battery. At the moment, and until we have some charge/discharge voltage curves, we cannot relate voltage level to battery charge status.
I know that most (if not all) of you are using the serial console over the USB cable to access your A320, and since the kernel panics when unpluging the cable, it is not possible to trace the discharge curve unless one builds an special USB cable without the +5V line. So in the next days I'll work on fixing the cable unplug bug, and then ask for help on tracing the battery charge/discharge curves.
I also got the LCD backlight working. The FBIOSETBACKLIGH ioctl command now works, but I also implemented a procfs interface and since it doesn't require kernel headers (from the userspace developer's point of view), I would strongly advice to use it instead of ioctls.
Just read/write a value between 0 and 100 to /proc/jz/lcd_backlight. As a refinement I might add a linearization table (the apparent brightness increase is much larger from 0 to 10 than from 90 to 100).
Finally, a couple of notes about the keyboard mapping:
I replaced KEY_KEYBOARD by KEY_MENU (power+select). This keycode is intended to bring up an overlay screen which might include a virtual keyboard, but which will certainly include more functions (volume, brightness, process control, etc). So makes a little more sense to use MENU than KEYBOARD:
I added the KEY_EXIT keycode (power+left shoulder). It is intended to kill the "foreground" application, that is, the one using the framebuffer.
Note: when I say "intended" I mean that an userspace daemon will be needed that will capture those keycodes, bring up the overlay screen, etc.
http://www.dingux.com/2009/07/batter...backlight.html