So here's a picture of my current output:
And a video here,
note, there's nothing visually impressive to show yet. It just shows boot and about 1.5mins in, it shows the Android UI, then after that it shows Android disliking something about my input driver although it seems to respond to some extent by drawing the date at the top.
I need to debug what exactly "InputManagerService Starting input on non-focused client android.view.inputmethod.InputMethodManager$1@437b5e90 (uid=1000 pid=1060) WindowManager Pointer down received while already down in: Window{437b6bd0 StatusBar}" and whether "path=/dev/input/event0 name=Wacom W8001 Penabled Serial TouchScreen id=0x10001 (of 0x2) index=2 fd=35 classes=0x4 KeyInputQueue X: unknown values KeyInputQueue Y: unknown values KeyInputQueue Pressure: unknown values KeyInputQueue Size: unknown values KeyInputQueue Device added: id=0x10000, name=null, classes=4 KeyInputQueue X: unknown values KeyInputQueue Y: unknown values" is a catastrophic issue.
As you can tell from the picture and the video, there's also some image corruption. That is basically a grayscale conversion issue on my part. The reason for this is that Android's EGLDisplaySurface component (a C++ library that sits directly on top of fbdev) forces the use of RGB565 and doesn't seem to like being switched into GL L8 which I had hoped it would not mind since I thought the compositor uses OGL-ES. So I decided to just do a byte truncation rather than the full shifts and fixed point 0.3*r + 0.59*g + 0.11*b since I need to do it for every pixel. Anyway, another problem for me is that this stuff uses fb flipping, yes, that's right, it does a big swapbuffers every time. Yeah, that naturally kills defio performance since it's a touch every page every swapbuffers. Even if I implemented panning support, I'm not sure that would help because I think there's a full frame iterator doing stuff in order to composite things as well. I don't understand the big picture yet because this implementation wouldn't protect against tearing since there's no sync to vblank here. There's no real swap barrier or retrace counter that's exposed by fbdev drivers. We just have the wait vblank ioctl supported by 1 or 2 drivers. Anyway, I need time to look at all this and understand why they're doing things this way.
At the userspace system level, android isn't really linux-like at all. Stuff like udev/hotplug/etc which I depend on for loading the waveform for metronomefb isn't there. I'm using the cupcake build of android which has a custom init program that parses its own init.rc config file and does a bunch of device creation, and all kinds of other stuff. I found the following code and articles from Rupesh Gujare, Benno Leslie, Jyunji Kondo, John Lombardo from LinuxDevices, all quite useful. Some are now a bit outdated since it looks like they were written prior to the cupcake source release from Android.
Here's what the process list looks like:
787 root 268 S /android_root/init
1045 1000 812 S /system/bin/servicemanager
1047 root 1852 S /system/bin/mountd
1048 root 71308 S zygote /bin/app_process -Xzygote /system/bin --zygote
1049 1013 17084 S /system/bin/mediaserver
1051 1002 1168 S /system/bin/dbus-daemon --system --nofork
1053 root 1268 S /sbin/adbd
1060 1000 159m S system_server
1095 1001 99.0m S com.android.phone
1103 10002 109m S android.process.acore
1127 10006 93192 S com.example.android.softkeyboard
1135 10005 95960 S com.android.calendar
I find myself increasingly limited, shall we say, gum-ed up by my gumstix as I have a serious shortage of memory to run this kind of stuff. Overall opinion at the moment is that Android is very different from other embedded linux systems. Trying to decide whether that's a good thing or a bad thing depends on many subjective issues so I'll postphone my thoughts on that until I've understood the overall system and its intentions better.
SOCIAL SHARE CARD GENERATOR