Wednesday, February 11, 2009

LCD is the answer? To what question?

I'm reading this ETech Preview article and having a hard time reconciling the observations and predictions there like "LCD is the cool new technology" with real life data and technology curves.

The article described the OLPC display as "OLPC's breakthrough low-power transflective display". I too had believed that once. These days, I just have questions and concerns. This OLPC teardown article in EETimes by Porteligent teardown expert David Carrey shares one. That article states:
"The dual-mode LCD--supplied by AUO--is a curious bit of technology. Despite much talk of fancy diffraction gratings and other trickery to implement a combination color-backlit and monochrome-reflective display, we couldn't detect anything other than a fairly standard pixel stackup and construction vs. a standard transflective-LCD construction. The RGB pixel filter arrangement is based on diagonal striping instead of the normal adjacent RGB triad, and thus requires some special addressing and dithering. Otherwise, we saw little evidence of a radical approach to the LCD."

So.. when I see "bring the revolutionary engineering used in the XO to the broader consumer market", I find myself struggling to understand what the facts are. Don't get me wrong, I'm not interested in putting down anyone's efforts, I would just like to understand the details. A bit of accurate technical information and perhaps a response to David's article would be nice to see.

The article also states:
"I have a Kindle and I have to hit the page turn button when I'm three-quarters of the way down the page, and wait for it to refresh while I read the rest of the page. And then if I get stuck on something, then I have to go back. And we really need something with video, or a way to do fast page change and color. And I believe it's actually a lot easier to do that with standard LCD."

A full grayscale page update time on a Vizplex display with a broadsheet controller (in Kindle-2 and Sony PRS700) is 800ms. A black-and-white update is 260ms. I've not encountered a scenario where there's a serious usability issue like "wait for it to refresh while I read the rest of the page" with any E-Ink display panel from the last year. I'm able to show that a low spec electrophoretic system with minimal software optimization is able to do fairly reasonable interactive content (fennec on e-ink, live drawing with rgbpaint) even with standard uncustomized apps. The latency issues (beyond the stated update numbers) in my demonstrations thus far are software limitations rather than hardware imposed constraints.

I agree with the article that current electrophoretic technology is not yet satisfactory for displaying video. I also agree that the technology path to get color with electrophoretic displays may lead to incomplete color gamuts and non-optimal reflectivity. I don't dispute the "a lot easier to do that with standard LCD" part but I think that's an odd comparison to make. The LCD will always consume static power. That is, you have to power the display to hold the image. That's an apple. The electrophoretic scenario consumes no static power. It is non-volatile. That's an orange.

"And one of the advantages of electrophoretic is supposed to be the power consumption, in that you don't need to refresh the screen every 30th or 60th of a second, with all of the pixels, and doing that takes power, because it holds its charge. But as a result, you have to unwrite the charge before you can write something in. And the voltage which you have rewrite it at is hard. And so if you actually look in at the details, the advantage, kind of when looked at from a systems perspective, according to everything that we know, it kind of disappears."

Ok, I think this is unfair. What voltage problem? Yes, there's power needed to update the display and of course there's voltage on the gate drivers but its not a problem. How is that significantly different from the source/gate drives on an LCD panel? If there is a problem, I'd like to know exactly what that is . Taken from a systems perspective, there is an order of magnitude difference in power consumption between an LCD display and an electrophoretic display. That's why the e-book readers of the past 2 years have been using electrophoretic displays rather than LCDs. Statements like "it kind of disappears" without explaining the details of how such a conclusion can be drawn seem problematic to me.

"I run Linux, pretty nice. I run Ubuntu. And still the question, is what's the motherboard doing on? What's the CPU doing on? What is all of that doing on right now when nothing is changing..."

Yay, now that is a reasonable issue!

Labels:

Monday, February 09, 2009

Android on E-Ink

I've been thinking about porting Android on to the AM300 a while. I was curious exactly how Android's framebuffer architecture worked. I finally made some progress thanks to Thaipusam. I'm considering this my kavadi.

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.
Link
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.

Labels: ,