Comments on DINGUX: Implementing system controls

@booboo: I'd like to move the daemon to a publ...

2009-07-07T22:22:22.478+02:00

@booboo: I'd like to move the daemon to a public repository soon. Can I
do this on your google code project? I think having a centralized
development infrastructure could be beneficial.

It still needs a little bit of cleanup and the removal of some
obsolete sdl checks from the autoconf stuff, I also need to hook
up a button to bring it up.

All the modules still need quiet a lot of work, but there's
infrastructure.

I also had to (at least partially re-)learn some stuff, since I'm
a toolkit-guy nowadays and haven't done much low-level linux-stuff
yet. So my progress wasn't as quick as it could have been.

I still want to work on it, but maybe I can attract others by
making it public. I just don't nearly have the time to hack
on it full-time.

@kmeaw:vt switching sounds good, will this work?

@mth: the uevent stuff is exactly what i want to do for the virtual
keyboard / mouse, but haven't found the time to try yet.

@batman52: The daemon could do that (running background apps) using
the (not very thoroughly tested) app launcher. also some UI for it would
have to be implemented, unless you can live with button mappings
(which already work, still need one thing to be done). hm, they are also
quicker, if you haven't got that many programs it should be enough.

Drawing animated background + translucent UI would require a lot of CPU
cycles, indeed. I always had drawing a static snapshot of the background
in mind, because nobody wants a sluggish background app AND menu system.
The background process would be stopped and restarted by the daemon.
You could just skip frames when updating the FB to reduce the CPU load,
but that wouldn't achieve much in the end. Battery lifetime also should
play a role.

For the rather static bars of the "basic display mode" of the daemon
you could also just read out the values every few ms and update the
corresponding FB regions. Doing that when only their values change
would even further reduce the CPU usage, but it's only visible for
short periods of time, so I don't know if it's worth the effort.

If you want to overlay it with, say, black you could have a pre-blended
version of the FB and blend with the active UI elements

I think the menu system will look just fine being opaque. special themes
could be implemented, however. This could be done by implementing some
mechanism to retrieve the FB content as it was before a vt switch
from the daemon. I think at that point we could also provide a c library
(input mapping, screenshots, whatever comes up) which communicates
with the daemon when neccessary for community-created programs.

Here's what I have:
- a deamon structurized in modules
- modules less than more working:
input,mouse(-emu),battery,(app)launcher,screen,sound
- config file parsing and button mapping
- sdl independence (draws directly to framebuffer)

I also have some code in some test apps which I'll merge when
I find the time.

Maybe a stupid idea, but could you not have a devi...

2009-07-06T17:29:19.166+02:00

Maybe a stupid idea, but could you not have a device like a framebuffer, but it keeps a buffer only of active pixels along with their x y location... if the buffer is empty nothing is drawn, but if it has contents (e.g. you drew a volume control image) they are copied into the correct places in the real framebuffer by the driver? That way you don't have to copy the rest of the normal framebuffer contents backwards and forwards.

Also, I have been wondering - anyone got any idea if the USB-host pins are available anywhere on the dingoo PCB?

@Bastian: I like your idea! Moreover i would like ...

2009-07-06T13:05:11.791+02:00

@Bastian: I like your idea! Moreover i would like to see a few of useful embedded apps able to run in "background mode", just like the music player or a simple text viewer, as it happens with the original firmaware. Many users reported as "very useful" the ability of reading files during emulation. Personally i'd like being able of reading ebooks while listenig to music or radio, as i can do with the original fw.

@kmeaw: I like your ideas very much. The overlay h...

2009-07-06T12:09:49.095+02:00

@kmeaw: I like your ideas very much. The overlay however is required for the "volume up/down" splash. As far as I understand booboo he wants the splash to display while the application continues to run.

I had another idea: If we gonna have a menu that can be opened at any time while an application is running, then we could as well include the possibility for the running application to add its own options (like button remapping/frameskip/etc). This would be a huge usability feature IMO

Using the "uevent" driver, it's poss...

2009-07-06T10:08:19.215+02:00

Using the "uevent" driver, it's possible to inject input events. However, I do not know exactly at which point they are injected; you'd have to be careful to not create a loop where the system control daemon would process the events it injected just before.

You can implement these special keypresses as ACPI...

2009-07-06T09:35:42.247+02:00

You can implement these special keypresses as ACPI events like it is done on laptops for Fn+something keys like brightness, volume, etc. The daemon will subscribe to acpid events of acpid or even could (if the memory is an issue and running acpid is a bad idea) read /proc/acpi/events directly.

I don't think we need a separate framebuffer device to draw an overlay. Upon a special event the control daemon can switch VT to a free one, copy old framebuffer contents into a temporary buffer, draw overlay over it. When everything is done and user wants his app back, daemon should restore framebuffer contents and switch the VT back.

This approach will also solve the problem of handling non-special keys while in overlay mode - if the VT is switched, they would not be delivered into the "foreground" application.

AFAIR userspace processes can open a /dev/input de...

2009-07-06T08:05:13.591+02:00

AFAIR userspace processes can open a /dev/input device and send the EVIOCGRAB ioctl to prevent that keyboard events are sent to the foreground process.