Sunday, July 5, 2009

Battery reading and LCD backlight working

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 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:
  1. 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:
  2. 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.


  1. Instead of "killing" a working usb cable, shouldn't be too difficult writing a shell script that acts as a battery voltage data logger, and launch it with the "trick" of the history file.

  2. Hello!
    Could it be done that when the battery is low a noisy sound be produced and after 5mins the device automatically rebooted or halted and all this while we're playing games etc. Thanks!

  3. @batman52:

    The problem is not the automation of battery voltage reading and logging, but how to enable and disable battery charging. This can only be done AFIK by switching the +5V USB power, and if you do it by unplugging the cable, the kernel panics and the data logging stops.

  4. @booboo:

    You can do the logging trick while running the kernel, which does not support USB serial, which causes it to panic when you attach the cable.

  5. @booboo: I supose you can switch USB power using the wall charger! With an automated script you don't need to connect to pc-USB -> no kernel panics, am i wrong?

  6. @batman52

    Well... yes, you're right. It could be done that way, but you'd be entirely "blind".

    Let's give a try to fixing the g_serial bug. It'll make things easier and has to be done anyway.

  7. But don't you have a serial line on your dingoo booboo? So you wouldn't need the usb-serial...