Dingux News - Linux for Dingoo A320 - Implementing system controls

I will comment how I have though that the system controls could be implemented, as always, in order to get some feedback both from final users and developers.

I think that the most important limitation of the A320 is its 32MB of RAM, and that is why I think we need a"only one foreground application running" approach for dingux. These would be the sequence of events after rootfs is mounted by the kernel:

/sbin/init is executed
/sbin/init executes the initialization scripts, launching any required daemons.
/sbin/init executes the main system menu application in "respawn" mode. At this point we have the daemons, the init process and the main menu system application running.

When the main system menu application wants to launch an external application, it does it by using the exec call. This means that the process is replaced in memory. At this point we have the daemons, the init process and the external application running.
When the external application finishes, the init process notices and respawns the main system menu application.

This way, we avoid having some MB of memory locked by the main system menu while it's not actually running. This is an approach completely different to the used in desktop systems, where the window manager and desktop applications are "always there" retaining control of the system.

This approach poses a problem: who takes care of the system controls (volume, LCD brightness and such) ?. It cannot be the main menu system application because then we would not be able to change settings while running an emulator or other application.

I've come up with an scheme that I think would do the job:

Modify the keyboard kernel driver to appear as two different input devices. All the special key combinations (power+whatever) would be generated by the second input device, and there would be a special mode entered by one of these combinations in which normal keycodes would also be sent to the second input device.
Modify the framebuffer kernel driver to appear as two different framebuffer devices. The second framebuffer would be shown (only while it is in open) as a traslucent overlay over the first framebuffer. The traslucency would be done in software and thus would use quite a chunk of CPU power, but this will be ok in the usage scenarios I will describe.
Make a system daemon process that will be listening to the event queue of the second input device, and will open and use the second framebuffer whenever it wants to show an overlay screen.
Usage cases:

The user presses the "volume up" key combination (power+up), the system daemon opens the second framebuffer device and shows a "volume up" splash screen for a short period.
The user presses the "menu" key combination (power+select), the system daemon opens the second framebuffer device and shows a menu where you can terminate the current running application (which would be identified by looking at who is using the first framebuffer), use a virtual keyboard to send keystrokes to the current running application (i.e. generated by the first input device) etc.
The rationale of the CPU intensive traslucency not being important is as follows: if you are using special key combinations to change the volume, you won't mind if the currently running application slows down a little for a short time. If you are using the virtual keyboard, the currently running application will be stopped in an input box dialog, so you won't notice the slowdown.

You may be thinking that the system daemon would be an application "stuck in memory" which defeats the initial purpose of saving memory. The system daemon will have to be implemented as very optimized code in terms of memory usage code, but most importantly, it will have only a reduced and limited set of feattures, while the system menu application can grow as necessary, including lots of eyecandy, an audio player (instead of an external application), etc.

Someone is already working in suck a daemon and my mission is to provide the required kernel space functionality. As usual, I kindly request your comments and suggestions. In particular, I'm learning about some kernel subsystems on the go, so if you have more experience in input and/or framebuffer devices, I'll be specially glad to hear you opinion on the feasibility of this whole approach.

UPDATE: I did a quick check and it seems that all input events from all input devices reach the controlling tty (makes sense because if you plug two keyboards to a linux box you can type from any of them), which means having two input devices is not the right way to divert certain input events to different processes. An easy way to achieve similar functionality would be to use a dedicated char device only known to the system control daemon, from which it would get special keystrokes and "kidnapped" normal keystrokes in menu mode. This would also solve an issue I didn't notice when writing this entry: if we implement a virtual keyboard in userspace, how do we "inject" the resulting virtual keystrokes back in the input subsystem?.

Well, I guess I could just use special keycodes for all operations to be handled by the system control daemon and assume that the current running application will just ignore them. However, I don't think "assuming" is good practice in general...