Carview!

CARVIEW

MOTORHOMES

Select Language

HTTP/2 200 cross-origin-resource-policy: cross-origin etag: W/"14abe1b32bde1cc5fabd1c9138d660827317f822f22f3a5e77ce3de475b8c6c2" date: Fri, 26 Dec 2025 14:59:43 GMT content-type: application/atom+xml; charset=UTF-8 server: blogger-renderd expires: Fri, 26 Dec 2025 14:59:44 GMT cache-control: public, must-revalidate, proxy-revalidate, max-age=1 x-content-type-options: nosniff x-xss-protection: 0 last-modified: Tue, 16 Sep 2025 08:08:12 GMT content-encoding: gzip content-length: 20119 x-frame-options: SAMEORIGIN alt-svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000 tag:blogger.com,1999:blog-168808362025-09-16T01:08:12.051-07:00highlycomposite2discussing the linux kernel+apps and embedded hardware design stuff. also discussing political and economic issues in developing countries.jayakumarhttps://www.blogger.com/profile/01394315069061047760noreply@blogger.comBlogger30125tag:blogger.com,1999:blog-16880836.post-80392232828611980892011-02-03T03:26:00.000-08:002011-02-03T03:53:29.890-08:00AM350 Android E Ink SimulatorI've uploaded a video of my manual <a href="https://www.youtube.com/watch?v=MMZjFELQAwU">AM350 Android E Ink Simulator</a>. I have not yet implemented simulation of the actual display controller or the physical effects and timing of the waveform and update mode selection, but I think with time, there is nothing that prevents that from being done. I was just about to try downloading Gingerbread AOSP today, but I found out that apparently you have to have a 64-bit system to even build their code. I had thought I was doing well with my Core Duo T2300 1.66GHz/1GB/320GB, but after looking at Gingerbread build requirements and their mailing list where they ruthlessly bandy about numbers like 4GB of RAM like its commonplace, I realize I really need an upgrade. Hopefully prices will fall after Chinese New Year.jayakumarhttps://www.blogger.com/profile/01394315069061047760noreply@blogger.com1tag:blogger.com,1999:blog-16880836.post-39112242819402198002011-01-28T00:40:00.000-08:002011-01-28T02:44:20.551-08:00Video of Browser on E Ink Android kit with Google SearchI've uploaded a <a href="https://www.youtube.com/watch?v=R962xzZXMLg">video of Browser</a> running on the <a href="https://www.eink.com/developer_center.html">E Ink Android kit</a> with Google Search and hitting various stuff like Ars Technica, Google Image Search, Google News and others. youtube被大陆屏蔽了。所以<a href="https://www.tudou.com/programs/view/Oj9h9vTsoPE/">我用</a><a href="https://www.tudou.com/programs/view/Oj9h9vTsoPE/">土豆</a>。我欢迎您的意见。I'm interested in projects around this.jayakumarhttps://www.blogger.com/profile/01394315069061047760noreply@blogger.com1tag:blogger.com,1999:blog-16880836.post-34815178512365505672011-01-12T17:27:00.000-08:002011-01-12T17:41:51.944-08:00E Ink AM350 Android KitE Ink's latest <a href="https://www.eink.com/sell_sheets/AM350_Kit_Sell_Sheet.pdf">AM350 development kit</a> is up and about. Looks great, an E Ink Pearl film using an Epson controller with Armada PXA166E running full Android with touchscreen (inductive underlay so it retains full display quality) and WiFi. It looks like 2011 is starting out as an exciting year for e-paper devices.<span class=" on down" style="display: block;" id="formatbar_CreateLink" title="Link" onmouseover="ButtonHoverOn(this);" onmouseout="ButtonHoverOff(this);" onmouseup="" onmousedown="CheckFormatting(event);FormatbarButton('richeditorframe', this, 8);ButtonMouseDown(this);">jayakumarhttps://www.blogger.com/profile/01394315069061047760noreply@blogger.com0tag:blogger.com,1999:blog-16880836.post-83681317247556301182010-11-05T18:06:00.001-07:002010-11-05T18:08:39.426-07:00Video of CFA910Just watched <a href="https://www.youtube.com/watch?v=y2rfphDBV1o">the video</a> of the CFA910 showing evince, eye-of-gnome, gnumeric and others running on E Ink. Pretty cool. <object height="385" width="640"><param name="movie" value="https://www.youtube.com/v/y2rfphDBV1o?fs=1&hl=en_US"><param name="allowFullScreen" value="true"><param name="allowscriptaccess" value="always"><embed src="https://www.youtube.com/v/y2rfphDBV1o?fs=1&hl=en_US" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" height="385" width="640"></embed></object>jayakumarhttps://www.blogger.com/profile/01394315069061047760noreply@blogger.com0tag:blogger.com,1999:blog-16880836.post-67219001317230995642010-11-03T21:45:00.000-07:002010-11-03T21:52:48.592-07:00CrystalFontz CFA910 is outI'm excited to see <a href="https://www.crystalfontz.com/product/CFA910.html">this</a>. E Ink display with Atmel ARM running OpenEmbedded Ångström. Checkout the photos, I really like the one with evince running with matchbox-window-manager.<span class=" on down" style="display: block;" id="formatbar_CreateLink" title="Link" onmouseover="ButtonHoverOn(this);" onmouseout="ButtonHoverOff(this);" onmouseup="" onmousedown="CheckFormatting(event);FormatbarButton('richeditorframe', this, 8);ButtonMouseDown(this);"><img src="img/blank.gif" alt="Link" class="gl_link" border="0" />jayakumarhttps://www.blogger.com/profile/01394315069061047760noreply@blogger.com0tag:blogger.com,1999:blog-16880836.post-67114617594401926542010-10-18T22:30:00.001-07:002010-10-18T22:34:04.043-07:00Keeping things working"This is a classic problem in development: everybody wants to play the white knight coming to the rescue with the quick fix — the water pump, the $100 laptop, the motorcycle. But the tougher challenge is developing a cost-effective system to keep things working." I like above quote. Matches observable reality.jayakumarhttps://www.blogger.com/profile/01394315069061047760noreply@blogger.com1tag:blogger.com,1999:blog-16880836.post-48568753316569545392010-10-09T02:49:00.000-07:002010-10-09T03:03:44.506-07:00FOSS.IN/2010The <a href="https://foss.in/news/foss-in2010-call-for-participation.html">FOSS.IN/2010 CFP</a> is out. I highly recommend participating. I also suggest visiting Ooty, உதகமண்டலம் , but not via road, instead, take the steam train, <a href="https://en.wikipedia.org/wiki/Nilgiri_Mountain_Railway">Nilgiri Mountain Railway</a> which is now a UNESCO World Heritage site.jayakumarhttps://www.blogger.com/profile/01394315069061047760noreply@blogger.com0tag:blogger.com,1999:blog-16880836.post-84305429812485936632010-08-22T02:27:00.001-07:002010-08-22T02:44:07.355-07:00Electoral FraudShame on the government for the <a href="https://www.indianevm.com/blogs/?p=402">arrest</a> of security researcher, Hari Prasad, see <a href="https://www.usenix.org/events/evtwote10/final-letter-eci.pdf">USENIX letter</a>. It looks very likely that the Election Commissioner, SY Quraishi's claims that the electronic voting devices are tamper-proof are totally bogus. I've always wondered whether a true majority of people were really voting in such obviously corrupt politicians like the <a href="https://en.wikipedia.org/wiki/Sonia_Gandhi">Maino mafioso</a> family, well, now we have to suspect, was it all likely to have been due to electoral fraud on a massive scale?jayakumarhttps://www.blogger.com/profile/01394315069061047760noreply@blogger.com1tag:blogger.com,1999:blog-16880836.post-64139188199629057582010-04-19T17:56:00.000-07:002010-04-19T20:10:48.058-07:00Android Input Software NightmareLets now look at the wonders of Android Input. I was trying to get a touchscreen to work. The first challenge is that the Android input code was not designed to handle any device that requires calibration. It assumes that the ABS_X/Y coords that come from Linux input is already screen accurate. Sure, that works fine on your factory calibrated capacitive HTC Booyah but it doesn't quite meet the needs of many common technologies like resistive, let alone flexible touchscreens. Okay, nevermind, I implemented a workaround transform and I'm able to get past that. Next challenge. Lots of odd behavior. CPU utilization at 70-90% just for drawing on the screen. What's going on? Meanwhile, other issues as well. Semi functional touch. Sometimes picks up gestures fine, sometimes not. When drawing slowly, stuff works mostly okay. Draw fast, and a curve becomes a straight line. What's going on, dropping samples? data flooding? It wasn't the hardware. It wasn't the driver. It wasn't Linux input. So, I started looking at the wonderful Android input layer code. a) <a href="https://android.git.kernel.org/?p=platform/frameworks/base.git;a=blob;f=services/java/com/android/server/KeyInputQueue.java;h=1bb897b7042e536e99f55db09c1f7d3d5296db0b;hb=HEAD">KIQ</a> 588 synchronized (mFirst) { 589 // NOTE: The event timebase absolutely must be the same 590 // timebase as SystemClock.uptimeMillis(). 591 //curTime = gotOne ? ev.when : SystemClock.uptimeMillis(); 592 final long curTime = SystemClock.uptimeMillis(); 593 final long curTimeNano = System.nanoTime(); Hmm. Suspicious. 775 me = ms.generateAbsMotion(di, curTime, 776 curTimeNano, mDisplay, 777 mOrientation, mGlobalMetaState); Hmm. Generating motion needs to store nanosecond accurate time of every single sample? Ok. Maybe there are good reasons for that. 783 if (me != null) { 784 if (WindowManagerPolicy.WATCH_POINTER) { 785 Log.i(TAG, "Enqueueing: " + me); 786 } 787 addLocked(di, curTimeNano, ev.flags, 663 if (currentMove != null) { 664 if (false) Log.i("InputDevice", "Adding batch x=" 665 + reportData[MotionEvent.SAMPLE_X] 666 + " y=" + reportData[MotionEvent.SAMPLE_Y] 667 + " to " + currentMove); 668 currentMove.addBatch(curTime, reportData, metaState); 669 if (WindowManagerPolicy.WATCH_POINTER) { 670 Log.i("KeyInputQueue", "Updating: " + currentMove); 671 } 672 return null; 673 } um-huh-what? generate motion and then the result is intentionally typically null? Look through the <a href="https://android.git.kernel.org/?p=platform/frameworks/base.git;a=commit;h=2397640740e053af7ef4aa742467f723186d5ad7">code history</a>. Maybe there's a patch I can pick up that'll fix my problems. Oh, wonderful, nice, confident developments like: "Maybe fix issue #2145012: Array bounds exception in touch event processing" This software looks like rasam. Great swearware Googlers. Okay, give up trying to understand their code. Lets see what other people have discovered. Oh, great: <a href="https://code.google.com/p/android/issues/detail?id=7836">Known Issue 7836.</a> Check these excellent cpu utilization numbers just for doing input: <pre>36% CPU usage on my G1/1.6 </pre>Nice. The CPU vendors must love Android. But I'm frustrated and exhausted. I'm going to sleep and hope to wake up from this nightware.jayakumarhttps://www.blogger.com/profile/01394315069061047760noreply@blogger.com0tag:blogger.com,1999:blog-16880836.post-85682951938062595692010-04-16T21:07:00.000-07:002010-04-16T21:50:58.636-07:00Android shellLets look at the android shell, /system/bin/sh . By default, the build comes out with a shell that has no history, no tab completion, doesn't handle backspace or delete and various other excellent features. There's no easy way to switch to a recent shell because there's no automake and bionic has various other issues so those who enjoy more pain solve it by copying a staticly built busybox from some other build system. But... they're missing out. The great benefit of this Android shell is it provides regression therapy for embedded folks. Its like going back into 2002, or better known as 3-AB (3 years after busybox). You then poke at the shell code in the <a href="https://android.git.kernel.org/?p=platform/system/core.git;a=blob_plain;f=sh/Android.mk;hb=HEAD">Android tree</a>, praying to the spaghetti monster PBUH(er) that there's an ifdef IN_2010_NOW and instead, in their build scripts, you see stuff like: make_ash_files: p4 edit arith.c arith_lex.c arith.h builtins.h builtins.c p4 edit init.c nodes.c nodes.h token.h 1999, here we come. :-) Is Vajpayee still prime minister?jayakumarhttps://www.blogger.com/profile/01394315069061047760noreply@blogger.com2tag:blogger.com,1999:blog-16880836.post-72910013598604298862010-04-11T00:31:00.000-07:002010-04-11T01:23:36.947-07:00Thoughts on the iPadI saw remarks like John Gruber's "<a href="https://twitter.com/gruber/statuses/11619258296">E-Ink RIP</a>" and was surprised. Do people actually believe that the iPad somehow resurrected LCD technology? Has it changed LCD displays in some way and somehow enhanced their technical capabilities? No, the iPad just uses ye olde 9.7" 1024x768 18-bit IPS LCD. It's a good display, maybe even a great display for the iPad's purpose, but still... just another LCD, just the same currently dominant, good enough but boring electronic display technology that this planet will probably continue to have for another -2 to 8 years depending on application category. E-Ink technology on the other hand, especially the new "just making its way through the production floor flexible and <a href="https://www.xconomy.com/boston/2010/03/15/new-e-ink-leader-sees-colorful-future-for-company-under-taiwans-prime-view-international/4/">color enabled</a>" technology excites me. I wouldn't be surprised if iPad v2...jayakumarhttps://www.blogger.com/profile/01394315069061047760noreply@blogger.com0tag:blogger.com,1999:blog-16880836.post-74861133715828409272010-04-03T19:32:00.000-07:002010-04-03T20:12:00.770-07:00Reading Android codeI'm trying to like Android code but failing. I want to share today's challenge. Here is top of tree <a href="https://android.git.kernel.org/?p=platform/frameworks/base.git;a=blob_plain;f=libs/ui/EventHub.cpp;hb=HEAD">Android EventHub code</a>. When a device is removed, it does close_device which does things like: <pre> for(i = 1; i < index =" (device-">id&ID_MASK); mDevicesById[index].device = NULL; close(mFDs[i].fd); int count = mFDCount - i - 1; memmove(mDevices + i, mDevices + i + 1, sizeof(mDevices[0]) * count); memmove(mFDs + i, mFDs + i + 1, sizeof(mFDs[0]) * count); mFDCount--; </pre> You see the memmove-s and think, hmm, odd, wonder what they're trying to do. You look in open_device: <pre> int devid = 0; while (devid < mNumDevicesById) { if (mDevicesById[devid].device == NULL) { break; } devid++; } </pre><pre> mFDs[mFDCount].fd = fd; mFDs[mFDCount].events = POLLIN; </pre> and you see what looks like an attempt to map a device ID to a collection of data associated with it, most importantly its fd. It looks like a very odd way of doing it, but hey, if it works , then great, we can just ignore above oddness and go on with our lives. Problem is, that this stuff doesn't work. Even for simple things! When a device is removed, and then plugged back in, Android userspace fails in exciting ways. Lets work an example. The first device that had been added has devid 0, and when it is removed, the other devices are pulled back with the memmove of mFDs and mDevicesById[0].device entry is set to null. But then those devices that were pulled back haven't had their IDs changed, so the: <pre> #define id_to_index(id) ((id& ID_MASK)+1) if (ioctl(mFDs[id_to_index(device->id)].fd, </pre> results in the wrong fd being used for everything else since id n was memmoved to n-1 and the id_to_index doesn't account for that. The new device then picks up devid 0 (since that was the first mDeviceById[].device that was null) and then everything fails since mFDs[mFDcount] and count is 8 so it fails. fails. fails. :-( Sad. Okay, going to lunch now.jayakumarhttps://www.blogger.com/profile/01394315069061047760noreply@blogger.com3tag:blogger.com,1999:blog-16880836.post-36737506282137733692010-01-10T15:12:00.000-08:002010-01-10T15:49:25.483-08:00Gizmodo's articleMatt Buchanan writes on Gizmodo claiming that <a href="https://gizmodo.com/5443895/e+ink-is-dead-pixel-qis-amazing-transflective-lcd-just-killed-it?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+gizmodo%2Ffull+%28Gizmodo%29">E-Ink is dead, killed by Pixel-Qi</a>. I find such reports to be greatly exaggerated. The article is, unfortunately, sloppy. It makes statements like "it [the pixel qi display] immediately switched to the electrophoretic reflective mode". As most engineers are aware, electrophoresis is the physical phenomena of particle-in-solvent motion under an electrical field and is what E-Ink's Vizplex display films rely on. Pixel Qi's displays and the OLPC XO's displays do not use electrophoresis, instead, they rely on traditional twisted nematic liquid crystal technology. The term e-paper is being increasingly diluted by marketeer-ing. Originally, e-paper, as the term suggests, described an electronic display with paper like behaviour and capabilities. The key aspect being the ability of the display to retain an image for a significant period of time without the consumption of any power. That is, you should be able to rip the display out and the image that was last drawn to it will stay. E-paper display technologies (such as cholesteric liquid crystal, QR-LPD, ZBD, electrophoretic (E-Ink Vizplex), etc) have that characteristic bistability. Twisted nematic LCD displays (whether reflective or transflective), like the Pixel Qi display, do NOT have that characteristic. Marketing such displays as having "an e-paper mode" are, at best, bordering on hucksterism. E-Ink's display films currently dominate the market. LG and PrimeView are the major panel suppliers that use E-Ink's films to make the display panels used in the majority of the current e-book readers. Competitors to E-Ink should be coming to the party sometime this year. Some such as AUO-Sipix have already publicly announced this and even have possible design wins (Jinke). Anyway, I have no qualms about the long term value of e-paper technologies, whether they're E-Ink's or others. Gizmodo on the other hand, I'm not so sure about.jayakumarhttps://www.blogger.com/profile/01394315069061047760noreply@blogger.com0tag:blogger.com,1999:blog-16880836.post-58375199781775265672009-10-16T17:44:00.000-07:002009-10-16T17:47:31.541-07:00Deepavaliநண்பர்களுக்கு இனிய தீபாவளி வாழ்த்துக்கள். Happy Deepavali to everyone, enjoy in moderation. <a href="https://foss.in/news/fossincfp-2009.html">FOSS.IN CFP</a> is also out, I highly recommend participating.jayakumarhttps://www.blogger.com/profile/01394315069061047760noreply@blogger.com0tag:blogger.com,1999:blog-16880836.post-89788465589601794522009-10-12T16:59:00.000-07:002009-10-12T17:24:55.896-07:00Gizmodo articleGizmodo has an <a href="https://gizmodo.com/5378310/eink-gallery">article</a> by Brian Lam that has some assertions about E-Ink displays. He writes: "E-ink is superior for replicating paper, but it can't even support realtime cursor, movements or button presses, let alone video" Realtime cursor generally just means functionality as shown here: a) <a href="https://www.youtube.com/watch?v=aoG7XHO7P0s">rgbpaint running on top of full X11 stack (kdrive/Xfbdev, gtk, etc) on a PXA255 GPIO driven display</a> or b) <a href="https://www.youtube.com/watch?v=53X_XlqBdfM">sketch</a> on same hardware but custom app written by E-Ink engineers to talk directly to hardware from Linux userspace bitbanging gpio. So E-Ink displays can support realtime cursor movements and button presses. His point about video is somewhat true if you want true 60Hz full image quality video, but you can get watchable video with some tradeoffs by using waveforms that reduce update time by trading off image quality. In Portland, I showed a demo of y<a href="https://www.youtube.com/watch?v=i4Loe5rIu4I">outube running on an E-Ink display</a>. I only got about 4-8 Hz (depending on video content) because of software and bitbanged GPIO limitations.jayakumarhttps://www.blogger.com/profile/01394315069061047760noreply@blogger.com1tag:blogger.com,1999:blog-16880836.post-78374566976098365312009-10-08T07:48:00.000-07:002009-10-08T08:26:53.134-07:00Kindle2 InternationalI'm sitting in Changi waiting for the last leg of my flight to the Mud Delta. 5 hours left to go. I just read about the <a href="https://edition.cnn.com/2009/BUSINESS/10/07/amazon.kindle.international.ft/index.html">Kindle2 international version</a>. This promise of free worldwide data access for life... is pretty amazing. Amazon is stratifying the countries into totally free (you get both whispernet book purchase and free internet-over-whispernet), and limited (you get whispernet book purchase but no free internet blogs or browsing). India falls into the no free internet category which is highly unexpected. A crying shame or maybe a challenge for someone else to do better? People tell us that what is innovative about the Kindle is the E-Ink display, but I think another key highlight is the fact that the Kindle was the first consumer device that treated wireless data connectivity as something too cheap to meter. About damn time. I hope more vendors take that route.jayakumarhttps://www.blogger.com/profile/01394315069061047760noreply@blogger.com0tag:blogger.com,1999:blog-16880836.post-82974836844349347932009-03-04T02:20:00.000-08:002009-03-04T02:28:03.340-08:00And I thought...<a href="https://money.cnn.com/2009/03/03/technology/copeland_epaper.fortune/index.htm">Russ Wilcox on Fortune/CNN</a> provides proof that engineers are humble in their approach but not their ambitions for effect of technology on the planet. :-) "What we need more is calm, prudent thought - more expertise." That is what Wilcox hopes to deliver with E Ink. "We're not only going to save publishing," he says, "we're also going to save civilization."jayakumarhttps://www.blogger.com/profile/01394315069061047760noreply@blogger.com0tag:blogger.com,1999:blog-16880836.post-47578569489803574312009-02-11T15:38:00.000-08:002009-02-11T16:49:18.852-08:00LCD is the answer? To what question?I'm reading this <a href="https://radar.oreilly.com/2009/02/why-lcd-is-the-cool-new-techno.html">ETech Preview</a> 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 <a href="https://www.eetimes.com/news/design/showArticle.jhtml?articleID=208400384">OLPC teardown article</a> in EETimes by <a href="https://www.teardown.com/">Porteligent</a> 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 (<a href="https://www.youtube.com/watch?v=k4WBdagDgSg">fennec on e-ink</a>, <a href="https://www.youtube.com/watch?v=q_mLKQXcsgY">live drawing with rgbpaint</a>) 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!jayakumarhttps://www.blogger.com/profile/01394315069061047760noreply@blogger.com7tag:blogger.com,1999:blog-16880836.post-48791091176421906262009-02-09T04:24:00.000-08:002009-02-09T05:30:44.218-08:00Android on E-InkI'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: <a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgrCl_IXONnbs3CZYMTRCSPUNSWzntIknmwgkpnuar7Rv-peTX9fs3pKL_B-1k43CAn5vLvx-It4UX1JxeFARxq6z_u3k3i2xcMGtBT6r7mB4zijmxZeQnzsQRz4m3RfM2WTCVLQQ/s1600-h/android_eink.jpg"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer; width: 400px; height: 300px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgrCl_IXONnbs3CZYMTRCSPUNSWzntIknmwgkpnuar7Rv-peTX9fs3pKL_B-1k43CAn5vLvx-It4UX1JxeFARxq6z_u3k3i2xcMGtBT6r7mB4zijmxZeQnzsQRz4m3RfM2WTCVLQQ/s400/android_eink.jpg" alt="" id="BLOGGER_PHOTO_ID_5300776413439279282" border="0" /></a> And a video <a href="https://www.youtube.com/watch?v=YsmY4OGWLJA">here</a>, <a style="left: 0px ! important; top: 15px ! important;" title="Click here to block this object with Adblock Plus" class="abp-objtab-022545323632414405 visible ontop" href="https://www.youtube.com/v/YsmY4OGWLJA&hl=en&fs=1"></a><object width="425" height="344"><param name="movie" value="https://www.youtube.com/v/YsmY4OGWLJA&hl=en&fs=1"><param name="allowFullScreen" value="true"><param name="allowscriptaccess" value="always"><embed src="https://www.youtube.com/v/YsmY4OGWLJA&hl=en&fs=1" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="425" height="344"></embed></object> 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 <a href="https://labs.embinux.org/git/cgit.cgi/linux-omap-2.6/">Rupesh Gujare</a>, <a href="https://benno.id.au/blog/2007/11/18/android-framework-startup">Benno Leslie</a>, <a href="https://tree.celinuxforum.org/CelfPubWiki/Jamboree18AndroidDemo">Jyunji Kondo</a>, <a href="https://www.linuxdevices.com/articles/AT9900056470.html">John Lombardo</a> from <a href="https://www.linuxdevices.com/">LinuxDevices</a>, all quite useful. Some are now a bit outdated since it looks like they were written prior to the cupcake source release from Android. <span class="down" style="display: block;" id="formatbar_CreateLink" title="Link" onmouseover="ButtonHoverOn(this);" onmouseout="ButtonHoverOff(this);" onmouseup="" onmousedown="CheckFormatting(event);FormatbarButton('richeditorframe', this, 8);ButtonMouseDown(this);"><img src="https://www.blogger.com/img/blank.gif" alt="Link" class="gl_link" border="0" /> 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.jayakumarhttps://www.blogger.com/profile/01394315069061047760noreply@blogger.com6tag:blogger.com,1999:blog-16880836.post-80835901117308923122009-01-18T09:08:00.000-08:002009-01-18T10:28:50.253-08:00More fennec on e-ink and Midori-webkit tooSo it turns out that learning a bit about when and where to click in an application helps make it behave better. :-) So <a href="https://www.youtube.com/watch?v=k4WBdagDgSg">another Fennec on E-Ink video</a>, this time it feels more like a usable mobile browser. I haven't gotten hildon built yet so no on-screen keyboard input yet. I'm feeling more excited about this stuff. The cooperation between X and the kernel makes everything else work without modification. <object width="425" height="344"><param name="movie" value="https://www.youtube.com/v/k4WBdagDgSg&hl=en&fs=1"><param name="allowFullScreen" value="true"><param name="allowscriptaccess" value="always"><embed src="https://www.youtube.com/v/k4WBdagDgSg&hl=en&fs=1" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="425" height="344"></embed></object> You're probably going to ask, so you've tried Fennec, what about a webkit based mobile browser? Well, I couldn't find any that I could build for my Gumstix. If you have a suggestion, please let meknow. However, I did try Midori-webkit-gtk which works quite well if I ignore the lack of a touchscreen friendly user interface. It did better than Fennec in terms of memory consumption and was able to render more sites as far as I could tell. I've posted this <a href="https://www.youtube.com/watch?v=tgNgQ6CMBfU">Midori-webkit-gtk on E-Ink video</a>. <object width="425" height="344"><param name="movie" value="https://www.youtube.com/v/tgNgQ6CMBfU&hl=en&fs=1"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="https://www.youtube.com/v/tgNgQ6CMBfU&hl=en&fs=1" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="425" height="344"></embed></object>jayakumarhttps://www.blogger.com/profile/01394315069061047760noreply@blogger.com4tag:blogger.com,1999:blog-16880836.post-75928600145774446862009-01-17T07:24:00.000-08:002009-01-17T08:01:25.010-08:00Fennec on e-inkI've been trying to get fennec to work on broadsheetfb. Here's my current status as a brief <a href="https://www.youtube.com/watch?v=vCIfshy_4rM">video clip</a>. <object width="425" height="344"><param name="movie" value="https://www.youtube.com/v/vCIfshy_4rM&hl=en&fs=1"><param name="allowFullScreen" value="true"><param name="allowscriptaccess" value="always"><embed src="https://www.youtube.com/v/vCIfshy_4rM&hl=en&fs=1" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="425" height="344"></embed></object> As you can tell, that's far from perfect. Memory profile:<pre> Name: fennec State: R (running) Tgid: 1330 Pid: 1330 PPid: 652 TracerPid: 0 Uid: 0 0 0 0 Gid: 0 0 0 0 FDSize: 32 Groups: 0 VmPeak: 95848 kB VmSize: 95848 kB VmLck: 0 kB VmHWM: 38372 kB VmRSS: 37348 kB VmData: 57524 kB VmStk: 84 kB VmExe: 84 kB VmLib: 34612 kB VmPTE: 72 kB </pre> My device now has: MemTotal: 61560 kB MemFree: 2484 kB I see illegal instruction failures when trying to render various web sites which I presume are due to memory allocation failures encountered by Fennec. Further, I see this stuff: Alignment trap: fennec (1574) PC=0x40816a30 Instr=0xe1c860d8 Address=0x406503a4 FSR 0x013 Alignment trap: fennec (1574) PC=0x40816a58 Instr=0xe1c860f8 Address=0x406503a4 FSR 0x813 Alignment trap: fennec (1574) PC=0x408169ec Instr=0xe1c060d8 Address=0x406503a4 FSR 0x013 Alignment trap: fennec (1574) PC=0x40816a30 Instr=0xe1c860d8 Address=0x406503a4 FSR 0x013 I think I need a tofuier device than Gumstix in order to get fennec comfortable. So far I still haven't found one that I can afford. Still hoping someone will drop me a message on that. Alternatively, I guess I could investigate thinner browsers.jayakumarhttps://www.blogger.com/profile/01394315069061047760noreply@blogger.com2tag:blogger.com,1999:blog-16880836.post-25669376659512052682009-01-14T20:04:00.000-08:002009-01-14T20:23:09.756-08:00Happy Pongalதைப்பொங்கல் வாழ்த்துக்கள். I really wanted to finish this before Pongal but instead I'm one day late. Anyway, I've posted my improved demo of broadsheetfb. I've reduced latency quite a lot (I haven't measured but it should be quite significant) and the more important change is host cpu utilization is now a lot lower. I've posted a video of this <a href="https://www.youtube.com/watch?v=q_mLKQXcsgY">here</a> and you can contrast that with the <a href="https://www.youtube.com/watch?v=0Bny6qyRDWw">demo</a> that I made during CELF. I've posted code for both the things that I did to improve this. The <a href="https://marc.info/?l=linux-arm-kernel&m=123071690503887&w=2">gpiolib changes</a> need to be split to make review easier and hopefully I'll then be able to convince everyone that its a decent idea and not shortsighted. I've also just posted the <a href="https://marc.info/?l=linux-fbdev-devel&m=123197799423141&w=2">damage interface</a> code. I'm very excited about these displays and watching them improve is great fun. <object width="425" height="344"><param name="movie" value="https://www.youtube.com/v/q_mLKQXcsgY&hl=en&fs=1"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="https://www.youtube.com/v/q_mLKQXcsgY&hl=en&fs=1" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="425" height="344"></embed></object>jayakumarhttps://www.blogger.com/profile/01394315069061047760noreply@blogger.com3tag:blogger.com,1999:blog-16880836.post-77723291814573118082009-01-09T13:04:00.000-08:002009-01-09T13:26:41.703-08:0022 pins of GPIO or moreHi there, Are you a vendor of embedded boards with a recent CPU? If you happen to have a development board that has exposed 22 pins of GPIO or more, then I'd really like to chat with you. What do you get out of this? :-) The opportunity to have your board interfaced to a very new display technology which could provide potentially attractive pictures that I have permission to give to you and which you can use as you see fit for your marketing purposes. Plus, I'll, of course, put effort into getting your board playing well with Linux. Drop me a note. Thanks! ps: if your board only has 16 exposed cleanly, but you happen to have about 5 spare LEDs on the board or alternate outputs then that's viable too. I don't mind reworking anything myself as long as its surface traces with a pitch that can accommodate a trembler. <table style="width: auto;"><tbody><tr><td><a href="https://picasaweb.google.com/lh/photo/Z_0vhXXtJRaubdh4IMXl6g?feat=embedwebsite"><img src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhHQl0Pu1DyNY_EC1FnB4ALy0yb5FwATobo7XSsH1uJYNaGXvxR6XXWn3Tj9-F1jHMCVVLRSrGFp5b0SK355mDoEG_Ub2dc2lFkG8afiHvFo6zbU2e9-xMHKac6HI7FBOrq3gsKQg/s144/u_dscn4141.jpg" /></a></td></tr><tr><td style="font-family: arial,sans-serif; font-size: 11px; text-align: right;">From <a href="https://picasaweb.google.com/jayakumar.lkml/Metronomefb?feat=embedwebsite">metronomefb</a></td></tr></tbody></table>jayakumarhttps://www.blogger.com/profile/01394315069061047760noreply@blogger.com4tag:blogger.com,1999:blog-16880836.post-85257241619615275222008-11-05T19:50:00.000-08:002008-11-05T19:59:12.933-08:00broadsheetfb, xclock, rgbpaintI had posted a first pass of <a href="https://marc.info/?l=linux-arm-kernel&m=122576090809242&w=2">broadsheetfb</a> and also a driver for the <a href="https://marc.info/?l=linux-arm-kernel&m=122576058508878&w=2">wacom w8001</a> touchscreen. I've also made a small <a href="https://www.youtube.com/watch?v=0Bny6qyRDWw">video clip</a> of what functionality that set of patches currently entails. As the clip shows, the big problem is latency. The current implementation shows the clock ticking at about 1Hz while both xeyes and rgbpaint are actively doing stuff. <object width="425" height="344"><param name="movie" value="https://www.youtube.com/v/0Bny6qyRDWw&hl=en&fs=1"><param name="allowFullScreen" value="true"><param name="allowscriptaccess" value="always"><embed src="https://www.youtube.com/v/0Bny6qyRDWw&hl=en&fs=1" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="425" height="344"></embed></object>jayakumarhttps://www.blogger.com/profile/01394315069061047760noreply@blogger.com0tag:blogger.com,1999:blog-16880836.post-86238870157560809032008-08-25T05:38:00.000-07:002008-08-25T06:01:27.351-07:00E-InkCIOL's Pradeep Chakraborty has an interesting <a href="https://www.ciol.com/Semicon/SemiSpeak/Interviews/E-Inks-electronic-paper-displays-delight%21/20808109272/0/">article</a> on E-Ink detailing his/her conversation with E-Ink's VP of Marketing, <a href="https://www.eink.com/company/team.html">Sriram Peruvemba</a>. I would agree with a lot that is said there. I really hope that local companies start picking up on this and develop product using the technology. All of Gangaram's on an SD card would be pretty cool.jayakumarhttps://www.blogger.com/profile/01394315069061047760noreply@blogger.com1

Original Source | Taken Source