No Android on the Neo1973 - Only MyPhone left
There has been some serious effort trying to get Android to run on the Neo: http://benno.id.au/blog/2007/11/21/android-neo1973 It was at the point where he started writing code to emulate ARMv5 instructions on an ARMv4 that I was thinking If anyone can get it running, it's going to be this guy. So, to get Android running, you need a processor with ARM v5 ISA. I.e. A gumstix with its XScale processor (Both PXA255 PXA270 should work). Anyone fancy having a go at putting Android on their MyPhone? Cheers, Tom ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: Gphone isn't open, linux dev not possible
For someone to claim to write a C android app, what would be required would be for the app to communicate with the Surface Manager and display a GUI, and/or communicate with the android databases (phone book, call log, whatever), and/or communicate with the device drivers (eg, make a call, receive an SMS). Some of these could even be done out of the emulator -- if you have a PC app that talks to the Surface Manager, then that's acceptable as a proof of android development. This is being worked on - specifically linking to and using the Android C++ libraries. A good resource for following the progress is the blog of the main guy doing the work (Ben Leslie): http://benno.id.au/blog/ Cheers, Tom PS: Is anyone working on getting android up on the neo? ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: linuxmobiles.org - a new forum
Why does the world need yet another mobile Linux knitting circle? Just because you can buy a domain name doesn't mean you should mint new .orgs. RANT It doesn't. There are SO MANY wikis, blogs, news groups, websites, forums etc. set up around android. Why? MONEY! Most of the sites I've seen have banner adds and are raking in advertising money for the person who set them up. Those which don't have ads yet are only waiting till the user base grows enough to make advertising worth while. The people who set them up seem to know next to nothing. There are 5 different official android groups, which is plenty. If you want general mobile linux info, www.linuxdevices.com has been around since the dawn of time and www.elinux.org in its various forms has been around for almost as long. Sorry John, your about 5 years too late. /RANT PS: Sorry for the pointless (hopefully) out-of-character emotional response. It's been an annoying day. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: Gphone isn't open, linux dev not possible
Currently, Android sucks big time, IMO. Google has no announced plans for allowing developers to write any C/C++ applications. Well I've managed to get a native C hello world running under the android emulator, so it is possible to run native C/C++ applications. All we need to do is work out how to talk to the surface manager and we'll be able to get native applications showing stuff on the screen. It is feasible to build a root-less X server for the Android platform which talks to the surface manager to render windows. I was intending to do this for Qtopia Core. Run an x server which displays X windows using QWS. Probably going to be dog-slow, but who knows? Cheers, Tom ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Is Google developing a phone after all?
Sorry to bring up the whole google phone thing again, but... I read the arm-linux Mailing list. Yesterday, Brian Swetland (Linux Kernel Lead, Android Project, Google) posted, announcing the public git tree for the Qualcomm MSM7K. This could just be the platform the android guys have been using for development. However, why would they go to all the trouble of porting Linux to a new SoC when there are many other already supported SoCs they could have used to develop on? I think this could be evidence that Google IS developing their own phone after all, one which will run Android. As I've already mentioned, another interesting thing I noticed was one of the Open Handset Alliance's members - The Astonishing Tribe (http://www.tat.se). They have some pretty slick GUI demos and their Kastor graphics engine supports OpenGL ES acceleration. Now look at the Qualcomm MSM7K's specs (http://www.cdmatech.com/products/msm7200_chipset_solution.jsp). Notice the high-end 3D accelerator. 1) I think Google IS developing their own phone after all 2) I think that phone will be based on the Qualcomm MSM7K 3) I think Android will be using Kastor as a rendering engine 4) If so, Android will look a lot like the Kastor demos on tat's website. (e.g. http://www.tat.se/images/demo/kastor_platform_01.mp4) Cheers, Tom ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: Is Google developing a phone after all?
1) I think Google IS developing their own phone after all 2) I think that phone will be based on the Qualcomm MSM7K 3) I think Android will be using Kastor as a rendering engine 4) If so, Android will look a lot like the Kastor demos on tat's website. (e.g. http://www.tat.se/images/demo/kastor_platform_01.mp4) It's probably a reference platform and one for developers. A bare minimum specification. It can't be the bare minimum as they've already said the minimum is an ARM9 and that Qualcomm is an ARM11. Plus, why port to a new platform when there are plenty of development kits for ARM9 (and event ARM11 these days) which support Linux out of the box. They could have used a Gumstix. They didn't, they ported Linux to a completely new family of SoC - no simple task. Just ask the OpenMoko Kernel developers! :-) ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: Is Google developing a phone after all?
But why joined TAT on the 5 november, the day of the press release? isn't this a little bit late or just another reason to believe they use TAT, cause they don't wanted to spoil the whole thing with TAT oh their list even earlier? Good question... I had assumed 5th November is just when the announcement came out and that they had been working together behind closed doors for some time. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: Community update: The 850 MHz issue
Its really hard to imagine a company building a phone that didnt think through what frequencies were needed. More interestingly, that it took a trip from Michael to Taiwan to get anyone to focus on it. If this substantially sets back the development effort, it really is a major blow to the project. In all fairness to OpenMoko, I think 850 Mhz is only used by the USA and Canada, which only account for ~10% of mobile phones in the world. That's according to statistics at http://www.itfacts.biz/index.php?id=P7222 United States: 201.6m + Canada: 16.6m = 218.2m World: 2.14bn So the OpenMoko can still be used in 90% of the GSM world. Although, having said that, I feel people's pain. :-( Plus I guess you have to factor in that the number of potential OpenMoko users/developers/hackers in the USA is probably _way_ higher than 10%. :-) ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: Community update: The 850 MHz issue
When you look at real smart phone sales - i.e. the 20m number, a very significant number of those are sold in the US. This is just I think Nkoli's point was that if you are going to say something like A very significant number, it might be better to back it up with a reference to some statistics on the net somewhere. I happen to think your probably right, but personally I tend to dismiss comments which don't cite a reference. winmail.dat___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: google open phone platform
http://www.engadget.com/2007/11/05/live-coverage-of-googles-android-gphone-mobile-os-announcement looks like google are announcing an open-source linux based phone OS, supported by a lot of big names in the hardware industry Look at the smaller names tho. One court my eye, I remember stumbling across them about 6-months ago when I was researching GUI stacks - TAT (The Astonishing Tribe): www.tat.se You can be sure the stack they'll be releasing will be based on TAT's Kastor. Look at the quality of the interface, it's truly amazing. All the apps are written in XML - sounds very google-friendly to me. I guess it must use JavaScript or similar to tie all the elements together. The graphics engine supports OpenGL ES 2 hardware acceleration too, so those screen casts are going to be what you'll get on the device. I'm just surprised the likes of Imagination Technologies Arm aren't members. It also seems odd that Arm announced their own Linux stack only last month - I wonder if they just weren't invited. I do hope they really mean that the whole stack will be open source - I can't imagine E.g. Nvidia releasing open source drivers for the GoForce. Cheers, Tom PS: What are the chances that the first demo phones we see turn out to be Neos? winmail.dat___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: [EMAIL PROTECTED]
Oh yeah, welcome Rasterman!! So e17 also on openmoko phone? :D Wow!! I'm sooo excited! E17 is already running on the neo (in a fashion): http://www.linuxdevices.com/news/NS8294545513.html FancyPants is based on E17 - more info at http://linuxdevices.com/files/article078/fst-fancypants-celf2007.pdf Cheers, Tom ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: Current status, and previous Community Updates: wiki page
I've created a wiki page to consolidate the current status, and provide a place for you to add questions and topics you'd like to see addressed. I've added a section on the SMedia 3362. Most of my questions have been answered off-list by OpenMoko people (thanks!): There will be no 3D on the GTA02 despite the hardware being there. :-( This is because there are no drivers. However, a while back Harald did mention the sMedia 3362 documentation would be made available to the community. Any chance of chasing: a) When b) What the documentation will consist of - will it be sufficient for a community member to have a go at writing a 3D driver? Cheers, Tom ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
SMedia 3362 (Again... sorry)
In a previous e-mail it was confirmed that the driver for the SMedia accelerator found in the GTA02 will take the form of a KDrive driver. (Correct?) Given that the chip is OpenGL ES 1.2 compliant and the SMedia datasheet (At least for the 3370, no datasheet for the 3362) claim Embedded Linux software support, are we likely to see an OpenGL ES library for the GTA02? I realise OpenMoko is about open source, but if a closed source library is available, surely that's better than nothing, at least until open source drivers/libraries can be written? I think OpenGL ES support for the neo would be fantastic - The hardware's there, why not use it? Writing some clutter (http://www.clutter-project.org) based applications would be great fun! Cheers, Tom ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: Right-click (as opposed to left-click)
I've just tried Mines (testing purposes only, of course!), but it's kind of hard to win with-out being able to right-click. Does anyone know how to perform such an exotic action? In Windows Mobile Windows XP Tablet, you can emulate right click by holding down the stylus for 0.5 secs. Sounds like a bodge but I found it quite usable. winmail.dat___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
No Camera???
I've been following OpenMoko for nearly a year now and the thought has only just struck me - There's no camera! Even the GTA02 seems to be missing a camera. Surely if this is intended to be aimed at consumers a camera is a must? If you look on Nokia's website they have 35 phones listed. Filter that by with camera and you get 30. Consumers want cameras and no consumer is going to buy a phone without one?? When the Neo is finally launched as a consumer product (say early 2009) it's not going to matter how open it is or how many 3rd party apps there are - People will not buy a phone without a camera. I think the whole project is in real danger of being a very big, expensive flop. Please, someone put my mind at rest! :-) ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: No Camera???
A survey on The Register (UK site) had camera at the lowest required feature with about 25% of people saying they need one and 25% saying the couldn't care less. Do you have a link? I can't seem to find it. Also, The Register's readers are hardly representative of the mobile phone market! http://www.theregister.com/2007/06/25/mobile_devices_who_decides/ LOL! The survey is about business users, what's more it's aimed at purchase managers buying phones for their employees. Not very surprising they don't want to give their employees camera phones! I'm amazed so many listed it as desirable. The question asked was: Thinking across your mobile user base, how desirable are the following features in a handheld device for data or mixed use. I really don't think you can use the results of this survey to back up the argument that *consumers* don't want cameras on their phones. Although that said, it is an important result - Your boss doesn't want you to have a camera on your corporate phone. winmail.dat___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: No Camera???
You appear to only be focusing on one group that share a common interest. Keep in my that the OpenMoko/Neo 1973 is not necessarily designed for teenagers or kids who's sole focus is the text messaging and the camera. I thought it was aimed at non-techy people, I guess I was wrong. My point is that it would have been cool to see some of the big operators like T-Mobile, ATT or Orange offer the Neo, or even to be able to walk into a high-street shop and buy one. I wanted to see the industry change and move away from closed phones. In a way, this is beginning to happen (thanks in part to OpenMoko I guess). Just have a look at http://www.linuxdevices.com/news/NS2981287645.html as an example (Motorola's announcement that a native SDK is under development for the Razr2). I just wanted to change the world, that's all! (sob sob). winmail.dat___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: No Camera???
So there's no way a tiny sensor in a phone is ever going to be useful for much more than drunken shots in a pub/bar. I agree, and I'm sure that's what most phone cameras are used for. But people want to be able to take awful quality photos of their mates family doing stupid things, spur of the moment. winmail.dat___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: No Camera???
So there's no way a tiny sensor in a phone is ever going to be useful for much more than drunken shots in a pub/ bar. I agree, and I'm sure that's what most phone cameras are used for. But people want to be able to take awful quality photos of their mates family doing stupid things, spur of the moment. winmail.dat. Everyone I see taking such shots are using a compact camera. Wow, you mean you've never seen anyone using the camera on their phone before? The little blighters are everywhere I seem to go. winmail.dat___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Getting the USB Host to work
Hi All, I'm also trying to get the USB Host working on the neo. I've got a kernel running (2.6.22.5-r3) with the USB host patch. I'm logging in over bluetooth (as suggested in the wiki page) and have done an ifdown on usb0 (also recommended on the wiki page). When I echo host to usb_mode, I get the following in var/log/messages: Oct 5 22:31:24 fic-gta01 user.warn kernel: s3c2410: changing usb to host Oct 5 22:32:01 fic-gta01 user.err kernel: hub 1-0:1.0: Cannot enable port 2. Maybe the USB cable is bad? Oct 5 22:32:04 fic-gta01 user.err kernel: hub 1-0:1.0: Cannot enable port 2. Maybe the USB cable is bad? Oct 5 22:32:08 fic-gta01 user.err kernel: hub 1-0:1.0: Cannot enable port 2. Maybe the USB cable is bad? This is with nothing plugged into the usb port. When I do plug something in using the cable I made, I get the following: Oct 5 22:32:15 fic-gta01 user.info kernel: usb 1-2: new full speed USB device using s3c2410-ohci and address 41 Oct 5 22:32:15 fic-gta01 user.err kernel: usb 1-2: device descriptor read/64, error -62 Oct 5 22:32:16 fic-gta01 user.err kernel: usb 1-2: device descriptor read/64, error -62 Oct 5 22:32:16 fic-gta01 user.info kernel: usb 1-2: new full speed USB device using s3c2410-ohci and address 42 Oct 5 22:32:16 fic-gta01 user.err kernel: usb 1-2: device descriptor read/64, error -62 Oct 5 22:32:16 fic-gta01 user.err kernel: usb 1-2: device descriptor read/64, error -62 Oct 5 22:32:16 fic-gta01 user.info kernel: usb 1-2: new full speed USB device using s3c2410-ohci and address 43 Oct 5 22:32:17 fic-gta01 user.err kernel: usb 1-2: device not accepting address 43, error -62 Oct 5 22:32:17 fic-gta01 user.info kernel: usb 1-2: new full speed USB device using s3c2410-ohci and address 44 Oct 5 22:32:17 fic-gta01 user.err kernel: usb 1-2: device not accepting address 44, error -62 I'm plugging in an Archos MP3 player which is powered from a separate DC power supply (I'm not applying power to my cable). Any thoughts? Also, I assume you connect the USB cable strait through? red-to-red, black-to-black, green-to-green white-to-white. You don't have to swap green white? Cheers, Tom ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
bug #747, qmake possible missing bbclass
Pretty sure this list isn't the right place for this but... There's a bug on bugzilla (#747) which I've also encountered and fixed. First, I think this may be a bug in upstream qmake 4.3.1 as I've been developing a lot with Qtopia outside OpenMoko. Every time I run qmake -project I have to manually add network to the QT variable in the project file, even for hello world. Second, I also needed to modify the Makefile qmake produced and edit the LINK= $(OE_QMAKE_LINK) to LINK=$(CXX). This is because OE_QMAKE_LINK isn't defined. Looking through the OpenEmbedded tree there is a class called qmake.bbclass ( qmake2.bbclass) which defines OE_QMAKE_LINK. I don't know OpenEmbedded too well but I do know portage/gentoo and I assume a bbclass is like an eclass in portage?? If that's the case, surely the uicmoc4-native_4.3.1 recipe needs to inherit from the qmake or qmake2 class? I guess this may have been fixed in upstream OpenEmbedded? Like I say, my OpenEmbedded knowledge is a bit limited, so what I just wrote may make no sense whatsoever. :-) Cheers, Tom PS: In future, where's the best place for this kind of stuff? Should I have created a new bug? ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: Qtopia coming for Neo1973
Can we please end this back and forth C vs. C++, Qt vs. Gtk, X11 vs no-X11, Openmoko vs Qtopia. I think most of us have seen plenty of these debates over the years and nothing constructive ever comes of them. As far as I'm concerned, this should have ended last week. The original question asked was why continue with OpenMoko development when Qtopia is available, faster, more complete and stable?. It was debated and some pretty conclusive reasons came out (as posted last Thursday) 1) Redundency is good, if Qtopia fails for some reason, there's an alternative. 2) A greater number existing applications can be ported easily to an X based framework. There is also precedent in the Maemo project of where this has been very useful. I'd like to add a 3rd: Competition breeds innovation. :-) I guess a 4th reason that's come out now is some people just prefer the GTK+ api and maybe a 5th reason some people prefer the LGPL over the GPL. So there you go, there's the 5 reasons why OpenMoko development will continue.Agree or disagree those are the reasons. Perhaps these could be added to the wiki to avoid future debates running over the same ground? Cheers, Tom PS: The faster, more complete and stable bit refers to the _current_ state of OpenMoko and not to what OpenMoko will obviously become. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Unified PIM
I guess my only comment is that while I don't really care which interface people use on their phones, it seems like the data interfaces should be the same... If I open up qtopia phone edition and look at my contacts or maybe even edit them and then close it down and open up my OM interface and look at them, they should be the same. All edit are visible.. No double entry. Agreed, but I'd take it one step further. Given the neo has an internet connection, why can't PIM data be stored on a web server and just cached locally. Couldn't you then integrate that into desktop PIM applications too? Ok, so this isn't a new idea. :-) Evolution Data Server supports integration to groupware backends, but from what I've seen, these are enterprise-class groupware servers designed for corporations. I can't seem to find anything designed for the consumer, an internet-accessible groupware server I can sign up to and store my contacts in a single place. The problem is not local - I'd be surprised if Embedded EDS couldn't be adapted to store it's data on a server and just use a cached dataset locally. The problem is that this requires some server infrastructure and so far I've yet to find something which will do it. Has anyone else seen this done? Cheers, Tom ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: Qtopia coming for Neo1973
My thoughts that competition has it's advantages and both of the technologies will find their fans. But Trolltech and Openmoko should cooperate with each other first of all in terms of integration of PIM data. Do you really need dual-booting (or other possibility to start either Qtopia or Openmoko) without possibility to synchronize address book etc between them? Of course, the best case from my point of view is to have the same low-level infrastructure (I mean API's to GSM-part, to PIM-part, etc.) for both Qtopia and Openmoko, but differ in the GUI part. But it is too late to talk about this as I can see :). This is something someone else touched on. If you're writing an application, abstract all the complicated stuff away from the UI code, then you can make whatever kind of UI you want. NetworkManager I think is a perfect example of this. It would be good to have a defined interface to access PIM info, make calls etc. I believe LiPS has been set up to do just that. So perhaps it would be better to make moth OpenMoko Qtopia PE LiPS complient. I heard that the LiPS forum hired a load of GPE PE developers to develop a reference implementation. It might be worth looking at GPE PE and lifting some of the standardised bits. I don't know, perhaps this is happening already? One more thing on duplication of effort... It's nice to see OpenHand developers working on OpenMoko, are there any plans to merge Sato into OpenMoko? There's currently 4 GTK+ mobile phone frameworks I know of (GPE PE, Sato, OpenMoko Hiker). Surely no one can claim that much duplicated effort is a good thing? I can see the argument for KDE/Gnome, GTK+/QT, but not 4 projects all relying on the same technology all doing exactly the same thing. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: Qtopia coming for Neo1973
As long as X11 renders to FB, that's true. However, with the GPU in GTA02 that may not be true at all as in fact, Mickey mentioned on IRC yesterday that fb operations may well be *slower* on GTA02 than on GTA01. I don't know enough about the differences between Qt and Qtopia (aside of the fact that Qtopia draws to the fb directly), but if Qtopia app scan run on Qt, we might well end up seeing that on GTA02 as Qt/X11 will get the GPU acceleration for free? At that point, GTK and Qt(opia) could happily coexist like they do on the desktop. What acceleration? You don't get hardware acceleration for free. Just because there's hardware there to accelerate drawing operations doesn't mean it gets used. I have raised this question several times: What kind of driver are you planning on? (I don't think I saw that answered yet, sorry if I missed it) KDrive, DRI, etc... We don't disclose this information yet, sorry. As soon as there is something working, it will be in our subversion, though. That reply came from Harold of all people. Surely it goes against the ideals of OpenMoko? I guess the main reason I'm for a Qtopia based framework over a GTK+/X framework is the technology and the ease of accelerating drawing operations. I've spent a lot of time trying to understand how Linux graphics stacks work. Now, Qtopia seems highly integrated (and much simpler as a result). It is also exceptionally well documented thanks to doc.trolltech.com. X on the other hand seems mind-blowingly complicated and I have really struggled to understand how it works. Documentation is apauling and I can't even find any decent books on how it works. But, I will now try and explain how I understand it works and please, PLEASE correct me where I'm wrong! :-) X is client server architecture which uses sockets. The server draws things on behalf of the clients. Rather than clients having to understand the X protocol, Xlib was developed to provide a drawing API. XLib is a very limited API for drawing lines, rectangles and arcs. XLib also allows clients to send a pixmap to the server to render. As time went on, line rectangles and arcs became a bit limiting so toolkits like GTK started rendering vector graphics into pixmaps and just used XLib to send those pixmaps to the server. Copying pixmaps over sockets was slow so shared memory was used instead for local clients. Pretty soon a more advanced vector graphics API was needed and so Cairo was born. Cairo rasterizes vector graphics into a client-side pixmap which is then drawn onto the screen using XRender, allowing compositing. Soon, people wanted anti-aliased, scaleable text, which XLib couldn't provide and so Pango was born. Pango uses Cairo to render text allowing both vector graphics and text to appear together. Pango, Cairo XLib are wrapped up in the GDK (The API of which is pretty well documented at http://library.gnome.org/devel/gdk/index.html). GTK+ widgets are rendered using a theme engine, which uses the GDK to render widgets. I.e. An application defines a widget, a theme engine draws that widget via GDK. That could be rendered using GDK's wrappers for XLib or cairo (typically cairo for desktops). So that's how I understand GTK/Cairo/Pango/X hangs together, but as I said before others know far more than I do. ;-) Now, given that is how the graphics stack hangs together, where do you off-load operations to hardware? What operations _can_ you off load to hardware? From what I've read, the most computationally expensive operations are ones which involve accessing large blocks of memory, e.g. block fills block copies. These typically can be performed by hardware. So, when you drag a window round the screen, hardware can be used to copy the window to it's new location. Block fills block copies are the only operations (other than cursors) most hardware accelerated x servers implement, which is fine, because that's where most of the work is. I mentioned earlier that cairo uses Xrender to copy compose rasterized graphics onto the screen. Some graphics hardware can accelerate some of the XRender operations, however, in X.org it seems the current driver model makes that very difficult, resulting in limited acceleration and thus slowness (different drivers accelerate different XRender operations). To fix that, Glitz was created to allow cairo to render to a GL context and use the 3D hardware to accelerate the composition, sidestepping XRender completely. Lets look at OpenMoko's rendering path. Thomas Wood mentioned yesterday, OpenMoko currently uses a pixmap based theme engine. The pixmaps are (IMO) beautiful. They are all shiny and curved and have a nice orange-black gradient. While they look great, they are slow as the pixmaps need to be copied from off-screen buffers to the frame buffer. My guess is that's why the OpenMoko interface is a bit slugish (only a guess, I suspect others on this list know a lot more about this
RE: Qtopia coming for Neo1973
Firstly, Sato is not a mobile phone framework in any sense at all. It does not include any applications or services that would make a mobile phone useful. Sato is simply a visual style. Strange, the description on http://www.pokylinux.org/ says: Sato is our experimental reference/example GTK+/Matchbox based PDA/smartphone like user interface environment aimed primarily at handheld devices with very high DPI VGA displays. It features a full suite of PIM applications, multimedia playback, web browsing, games and more. Huh?? User interface environment basically means the look and feel. It doesn't mean that it includes any sort of framework. It also says it is simply a PDA/smartphone *like* interface, not that it actually includes any usable phone software. I'll get this updated if it's causing confusion. Yes, sorry, I mis-understood this. I'd get rid of the bit that says It features a full suite of PIM applications, multimedia playback, web browsing, games and more. too if it doesn't actually contain any applications. ;-) I should have downloaded it and tried it out rather than assume things. winmail.dat___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: Qtopia coming for Neo1973
X provides an OpenGL API. So if you want to do fancy stuff like Compiz, you do it with OpenGL. X does not however provide an OpenGL ES API, neither does GDK. Qtopia on the other hand does allow OpenGL ES integration. In fact Beryl/Compiz-type effects and composition is already avaliable on Qtopia (acording to their documentation - no screen shots). To do that on KDrive you'd have to implement the XComposite extension and write a complete compositing manager which knows how to speak OpenGL ES. A massive task. I suspect this is a moot point anyway as I doubt we'll ever see an OpenGL ES library/driver for the SMedia. I really hope I'm wrong about this as the visual effects which could be achieved would be amazing, way better than the iPhone. winmail.dat___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: Qtopia coming for Neo1973
And there are already plans for someone to do the necessary XRender coding to support GTA02. That's fantastic news! Why on earth did Harold say that the fact that an accelerated kdrive was being written couldn't be disclosed? What's the problem in telling the community? Not that it matters really. If OpenMoko's going for an XLib based theme engine, why bother with XRender? What else uses it other than Cairo? Surely xvideo would be a more useful extension to focus on? Because coding simple gradients is trivial and I've already done it :-) Great, but soon people will want to do ever more complex vector graphics. Perhaps if/when XRender is accelerated, the switch could be made to cairo? All in all, the great thing about OpenMoko and the Neo1973 is that you're free to choose whatever path you wish to take. If you want to use Qtopia on your Neo1973 then you are more than welcome to do so! There are many many different Linux distributions and probably almost as many graphical user interface projects. One of the great things about the Free Software philosophy is choice and the Neo1973 is one of the first phones that gives you that ability to choose every single bit of software that you use on it. Sure, and I'm not disputing the fact that you can run whatever you want is a good thing. I just wanted to clarify why development of OpenMoko was continuing given that there is now a more complete and mature alternetive and I think this has been answered: 1) Redundency is good, if Qtopia fails for some reason, there's an alternative. 2) A greater number existing applications can be ported easily to an X based framework. There is also presedent in the Maemo project of where this has been very useful. I'd like to add a 3rd: Competition breeds innovation. :-) Cheers, Tom ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: Screen shots of Qtopia on Neo and some thoughts
Two complete distributions you can install and run on the same hardware? Both free? (not counting Sun since I can't get my paws on that one...) That's the real revolution here, and I would say this proves Sean's point of doing this in the first place... Can't agree more, the whole idea of a hackable phone is fantastic. Why I joined the SVHMPC and why I've spent over $1000 on development kits to build my own mobile phone. Shame I only heard about OpenMoko _after_ I shelled out a grand. :-( My hope is that this marks the end of closed phones. A Nokia, iPhone or Razer I can put my own OS onto?!? That's cool. winmail.dat___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: Qtopia coming for Neo1973
In short: Qtopia is going to be fully GPL'd (telephony applications included, which weren't) and is being ported to Neo1973. Fantastic news! What works? Looking at the youtube videos, it appears that the phone, SMS, bluetooth power management are all working? Can you actually place and recieve calls? I'm sure OpenMoko development will continue, but a good question is why? I don't really want to start a flame war, but I do think the question should raised. Why spend so much effort creating yet another GTK+ based framework? What would happen if all the people working on OpenMoko focused their efforts on improving Qtopia on the neo instead? Surely we'd get a fast, stable and functional phone stack a lot quicker? Cheers, Tom winmail.dat___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: Qtopia coming for Neo1973
Has anyone seen these benchmarks: http://zrusin.blogspot.com/2006/10/benchmarks.html It compares Cairo (what GTK+ uses) against QT. When it comes to rendering, I believe Qtopia QT use the same code. So ignoring X, Qt was respectively 7, 5 and 6 times faster. Than Cairo in those plain tests. Now factor in the fact that QWS has a lot less overhead than X and a smaller memory footprint. Can someone _please_ give me a technical reason why they believe GTK+ is better? The only arguments I've seen on this list are philosophical ones. The only technical argument has been that you can run applications on the phone and have them appear on your desktop thanks to X. Surely there is a better reason? I hate to say it, but I'm beginning to feel that the OpenMoko developer's ego is a big driving force behind developing the OpenMoko stack. winmail.dat___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: Qtopia coming for Neo1973
Very simple, i would think it is about compatibility of code. With openmoko, it is a small difficulty to port a normal linux application to openmoko. With Qtopia, it would probably involve a rewrite of major sections of the code. So you're saying Qtopia makes it harder to port desktop applications designed to be used with a 17+ monitor, keyboard and mouse to a device with no buttons and a 2.8 touch screen. I'd argue that the problems with porting desktop applications are far greater than the underlying framework. Are there any instances of a desktop application being ported to the OpenMoko which is usable? The only one I've seen is gpaint on OpenHand's Poky Linux, and that looked fiddly at best. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: Qtopia coming for Neo1973
Very simple, i would think it is about compatibility of code. With openmoko, it is a small difficulty to port a normal linux application to openmoko. With Qtopia, it would probably involve a rewrite of major sections of the code. Also, one possible solution to this would be to run an x server which outputed to a QWS window. I seem to remember something like this being developed for OpenZaurus years ago. I would have thought something like Xvfb or Xephyr could be modified to display output into a QWS window? If you don't like it? Ignore it. Make it better. Whatever. No one made a decision for _you_. True. Who am I to challenge the decisions of others? I understand that, but I just can't bare to see duplication of effort in community projects, it's such a waste of such talented people. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: Qtopia coming for Neo1973
Would you really say either gnome or is wasted effort and should be discontinued? Or vim/gnome,linux/bsd,gecko/webkit/mysql/postgres... Yes, it's my personal belief that these projects all represent wasted effort and that if they cooperated they'd achieve more. I always get a nice warm fuzzy feeling whenever I see a forked project merge (Compiz Fusion, Webkit/KHTML) PS: Thanks for the examples. It's by far the most convincing argument I've seen yet. :-) ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: speeding up the flow of information
I'd like to introduce Michael Shiloh and Joachim Roh Steiger -- two new members of the OpenMoko team. Their primary responsibility will be to support you, the OpenMoko community developers. I'm sure you'll all agree this is an extremely important (and too often neglected in this project) role ;-) Fantastic news... In that case, any chance of letting us know: What exactly will the [sMedia3362] driver actually be? As far as I can tell there are several options: 1) A DRI/DRM kernel module associated mesa module 2) A hacked up KDrive with accelerated driver 3) An xorg EXA/XAA driver 4) A DirectFB kernel module 5) A bog-standard Linux frame buffer device One of the biggest complaints I've read about on this list is the responsiveness of the user interface. One possible/probable reason for this is the rendering speed of OpenMoko's GTK+ implementation. The sMedia chip has been touted as one of the ways the GTA02 will speed up rendering, and the term Hardware acceleration has been mentioned quite a bit. However, I've not seen anyone mention _how_ GTK+ is actually going to be accelerated by the sMedia chip. I think this is a pretty important issue. Personally I'd like to see a full OpenGL ES EGL library so we(I) can start porting the OpenGL ES port of Quake 3 to the neo. :-) Quake 3 on the neo... mm... yummy... Cheers! Tom ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: SMedia 3362
What exactly will the driver actually be? As far as I can tell there are several options: 1) A DRI/DRM kernel module associated mesa module 2) A hacked up KDrive with accelerated driver 3) An xorg EXA/XAA driver 4) A DirectFB kernel module 5) A bog-standard Linux frame buffer device Does anyone know the answer to this at all? I've had a quick look around the source and can't seem to find anything which might give us a clue... ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: SMedia 3362
So are you claiming the open source drivers that we are writing are not open source, merely by the fact that we are writing them? Using this argument, the entire openmoko software stack would not be open source, because we are writing it. So are you going to release the source code to the driver you write? I think the impression was that an NDA would include not disclosing any source code you wrote using the NDA'd docs (ala Gumstix Marvell wireless drivers). What exactly will the driver actually be? As far as I can tell there are several options: 1) A DRI/DRM kernel module associated mesa module 2) A hacked up KDrive with accelerated driver 3) An xorg EXA/XAA driver 4) A DirectFB kernel module 5) A bog-standard Linux frame buffer device If it's simply going to be a kernel framebuffer device, what's the point in including the smedia chip at all?!?!? If it's going to be an x-org EXA driver, how much memory is xorg going to use compared with kdrive? I am guessing it's going to be a modified KDrive, in which case I guess we can kiss accelerated OpenGL ES 3D graphics goodbye? Cheers, Tom ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: At the risk of being flamed : State of software
Hi all, Personally, I intend to use Qtopia for my homebrew phone (because of lots of reasons, but mostly because of the OpenGL ES acceleration). I'm certain OpenMoko will never switch to Qtopia as so much effort has been put in already. I suspect, however that Qtopia may one day find itself running on the GTA02 as a separate project, as already mentioned. Considering how easy it was for the Gumstix guys to get Qtopia working (It took about 5 minutes, just a recompile) I think a Qtopia based OS on the GTA02 will quickly overtake a GTK+ based OS in speed, reliability and functionality. That is my own, personal opinion, but this is a subject I have researched very heavily over the last 12-months. A fair bit of my research is published on the elinux website, if anyone's interested in reading more: http://www.elinux.org/User_Interfaces. Technical Stuff === Qtopia is in a far more stable state and runs _quickly_, it has to, Trolltech sell it as commercial product! What's more importent is that it can take advantage of the OpenGL ES hardware acceleration, which will be avaliable on the GTA02 (see http://doc.trolltech.com/4.3-snapshot/qtopiacore-ahigl.html on how to do this). Getting OpenGL ES acceleration working under GTK+ _will_ be a huge task, requiring massive chunks of Cairo to be rewritten. Remember, the only OpenGL acceleration Cairo has is Glitz, which I believe is unmaintained and only accelerates image composition tasks anyway. Plus, it's OpenGL, not OpenGL ES and will require work to port it. From what I've read, the OpenGL ES stuff currently in Qtopia provides window transition effects similar to Beryl on desktop systems. I guess this can probably be extended easily to get a cube desktop on the GTA02. Plus, it all done in hardware so will be _fast_. Licensing = As mentioned, Qtopia is avaliable under the GPL. Strictly speaking it is more open than GTK+ which is distributed under the LGPL (Lesser GPL). I.e. Open source developers put in time and effort to develop GTK+ code. A big company can come along and say, yes, I like that, I think I'll use it. So they do and write closed-source software using the freely avaliable GTK+ code. They sell it and make lots of money out of other people's work, without contributing a thing back to the community, not even source code. This is all perfectly legal under the LGPL and has been done in the past by companies like VMWare, real networks (real player), adobe and many others. On the other hand, Qtopia is avaliable under the GPL (The full on GPL, not a GPL-like license, the GPL itself). As far as I understand it, there is nothing stopping anyone forking Qtopia (if deemed necessary) so long as they always publish their changes for everyone to see (As specified under the GPL). Anyone using Qtopia is obliged to publish the source code of their application, not just the changes they have made to Qtopia itself. So, IMO, all this talk of using GTK+ as it's developed by the community is a little redundant. Why not just take Qtopia, as long as you publish any changes, the community can develop it as much as they want. Finally, I feel I should remind people what's happening with Hildon. Nokia spend a lot of money hiring developers to develop Hildon, the GTK+ based framework on the N770 and N800. Now, Intel has come along and decided to take all the work Nokia has done and make it run on their own devices. How would FIC look if say HTC came along and took OpenMoko and put it onto their own phones? Cheers, Tom PS: Just read a few other posts... As mentioned on elinux, unlike desktop systems, it is _not_ possible to run both Qtopia and GTK+ applications simultaniously. It's one or the other (although it might be possible to get a hack working using DirectFB). ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: At the risk of being flamed : State of software
One big question out there regarding the viability of other platforms on neo remains: how much effort is FIC putting into pushing changes upstream? There's a lot of reinvention required if they don't. (Even reinvention within FIC having to forward port patches endlessly) In terms or wheel re-inventing, this is happening a staggering amount at the moment. Currently, the following projects have a user interface based on a modified (to varying degrees) GTK+: OpenMoko, GPE Palmtop Environment, GPE Phone Edition, Hiker (Access Linux Platform), Sato (Opened Hand), Hildon (Maemo), Sugar (OLPC). And these are just the ones I've come across. This is why the Gnome Mobile Embedded project was started, to try and bring some of these projects together and stop duplicating so much effort. It was great to see that OpenMoko was involved in the Gnome Mobile project, I really hope projects resource start to be pulled together. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: Greenphone is not GPL (was RE: At the risk of being flamed :State of software)
Be careful that you look at exactly what is covered under that GPL licensing. In order to gain access to the phone stack for the Greenphone (a must for my purposes) you have to pay them almost $5K for a commercial license. I think Qtopia Core is what's covered under the GPL. Qtopia core is the complete framework for application including all the windowing rendering stuff plus all the nice QT widgets for stuff like networking etc. It doesn't contain any actual applications. Qtopia Platform is a set of applications built on Qtopia Core, which are not all licenced under the GPL. Looking at the Trolltech website, there is Qtopia Open Source Edition however, which is a near-complete package of the Qtopia Phone Edition and Qtopia Platform source code. It includes an extensive source code for Qtopia applications and libraries.. I really need to get the LCD up and running on my phone and start trying these things out! :-) I may just wait for a GTA02 and try it out on that, assuming it will come with OpenGL ES libraries. (Anyone?) Cheers, Tom ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Benchmarks
Hello all, Over at the SVHMPC, we have been benchmarking application processors. The main drive for this is that I have been working on a Freescale i.MX31 processor (based on an ARM11 core) and wanted to see how it performs compared to the competition. So far we have benchmarks for a 400Mhz PXA255, 600Mhz PXA270 and 530Mhz i.MX31. I would very much like to see how the S3C2410 and SC32442 used in the GTA01 and GTA02 stack up against the others. We may also be getting results from someone with a PXA320. If you're interested, could someone with a GTA01 (and GTA02 if possible) please compile run the benchmark? We're using the nbench software as it's easy to cross-compile. nbench is available at http://www.tux.org/~mayer/linux/bmark.html. I've posted the results we have so far on our wiki, http://hbmobile.org/wiki/index.php?title=Application_Processor_Benchmark s These are preliminary results and currently do not match what others have found, so some tweaking might be needed (especially on the i.MX31!!!). I look forward to adding more results as they come in. Cheers, Tom ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
New wishlist item: Side-mounted touch strip sensor
Hi All, I've added a new item on the hardware wishlist: http://wiki.openmoko.org/wiki/Wish_List_-_Hardware#Side-Mounted_Touch_St rip Add a touch strip sensor onto the side of the phone which can be used to scroll. By having it on the side you can use your thumb to scroll comfortably while holding the phone one-handed. An 8-element capacitive sensor would work wonderfully and be easy to fab using either a Quantum QT411 (http://www.qprox.com/products/qslide_qt411.php) or Analog Devices AD7143 (http://www.analog.com/en/prod/0,2877,AD7143,00.html) controller. The Analog Devices chip seems better suited due to it's smaller allowable element size. With the AD7143 you can have an 8-element (128-position) 25mm long strip - Perfect!. This is an idea which was floated on the SVHMPC list a few months ago. The only possible issue is those people who are left-handed. Perhaps a strip on each side would be the best way to go. :-) Cheers, Tom ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: New wishlist item: Side-mounted touch strip sensor
Ok, there seems to be 2 other possibilities, a rocker switch and a scroll wheel. Rocker switch: Have you ever used a cheap mouse with a rocker switch instead of a scroll wheel? If you have then you know how limited they are. They simply do not offer the same amount of control a scroll wheel or touch strip does. Scroll wheel: A scroll wheel is much better, which is why mice use them. They can provide mechanical feedback and give the user far more control over their scrolling adventures. However, the image on the screen scrolling will be enough feedback. I used to work for HP in their research center (HP Labs). While there I worked on a prototype ebook reader. To maximise the readability of the display, the device doesn't have a touchscreen. Instead it has touch strips around the outside of the screen. To turn a page you drag your finger along the strip and see the page turning as you move your finger. Stop moving your finger and the page stops turning. The feel of the interface was awesome. Some pics here: http://www.pocket-lint.co.uk/news/news.phtml/7676/8700/hp-ebook-reader-concept-design.phtml although without a video it's hard to gauge just how well it works. (I actually wrote the touch strip calibration software and the bookshelf application on the device the bloke is holding in the first picture. :-) ) So given that the visual feedback is adequate, a touch strip does give you more than a scroll wheel. First, the strip can be quite long, although I guess you'd only want it between 25-40mm. It also gives you a resolution of 128 different positions, allowing very precise (pixel-by-pixel) control of the image you are scrolling. I've just tried my own mouse's scroll wheel, which, in a single finger swipe, gives me 8/9 different positions. That's a whole lot more control. I guess one problem with pixel-by-pixel scrolling is CPU power. Without a hardware blitter, I doubt the GTA01 has enough processing power to give smooth scrolling. Roll on GTA02. :-) As for power jogging the touch strip accidentally, well, the controller provides a stand-by mode. When the phone is locked, the strip controller is placed in standby. Why would you ever want to have a scrolling input device wake it up? Also, while I'm on the subject, please tell me that the GTA01 is not woken up by touchscreen interupts??? To have a complete resistive touchscreen and it's associated controller powered up all the time must make quite an impact on power consumption?!?!? Or does it poll the touch screen every 500ms or so while locked? Judging from some odd replies I should probably clarify that this is a 1D, one dimensional sensor. It's not a touch pad and IMO, a side mounted touch pad makes no sense. I also agree with people who say there should be some buttons. I think a touch strip combined with 2 buttons (select back) is all you need or want for menu navigation. I also think the 2 buttons should complement the touch strip in such a way that the device can be used single handedly. The sensor controllers I first posted use either I2C or SPI so technically could be retrofitted. The only problem is that the Analog part (my preferred part) is only available as pain-in-the-bottom to solder 4x4mm surface mount packages, which is beyond my skill to solder. :-( Also, these are very specialist multi-element capacitive sensors. A general purpose uc is not able to detect the tiny changes in capacitance between sensor elements. The chips contain very complicated and sensitive self-calibration and environmental compensation circuitry which cannot be replicated. Cheers, Tom ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Google maps caching
Hi All, I've read through several threads on this list, and others, which discuss the use of Google Maps for mobiles. It has been mentioned several times that Google doesn't allow map tiles to be cached. I've read through the Google Maps API Terms of Use and I can't seem to find any mention of caching being prohibited. Could someone please point me to the relevant section please? I find it a little odd that Google doesn't allow caching of map tiles as they are quite large and I can imagine Google's server bandwidth costs are huge if every tile is fetched directly without going through a caching http proxy. My train of thought is going along the lines of running squid or similar on the actual phone... Cheers, Tom ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
LCD
The specs for the NEO say it boasts a 2.8 640x480 display. From my calculations this is 285 dpi, which is just awesome... In fact it's so good that I almost don't believe it. What LCD is actually in the phone (MakeModel?). I've searched all the LCD manufactures I can think of and none of them have screens anywhere near that dpi. The smallest VGA LCD I can find is 4. Can you please confirm that this screen really is full VGA not 320x200? Cheers, Tom ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
