Re: New Life in Openmoko Phones
Werner Almesberger wrote: Wolfgang Spraul wrote: Today Openmoko released additional pieces of documentation about Freerunner hardware: board outline, footprints and netlist. This is great. Thanks a lot to you and everyone in Openmoko who has helped to make this happen ! Ack - Thanks all! Dave ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New Life in Openmoko Phones
David Reyes Samblas Martinez wrote: 2009/5/18 Rui Miguel Silva Seabra r...@1407.org: On Mon, May 18, 2009 at 07:20:13PM +0200, arne anka wrote: http://wiki.openmoko.org/wiki/Gta02-core sounds interesting. could someone add background information why parts change? removing the glamo seems pretty plausible, but why removing one of the accelerometers? audio amp? nor? ... I don't see why to remove one of the accelerometers and have added so to the Discussion tab. For this you have the actual GTA02, I'm not an expert at all, but keep things simply is always a good Idea , and as they sayd is not pretended to have a production ready phone, but all the learning done in the way of do this simply phone can help to start a more complicated design, even with gyroscopes, compass, a full kitchen and swimming pool if it fit the case, but now I agree in do this a simple but powerful as they can, and even if they finish with something looks like this[1] but with functional GPS/WIFI/BT/GPRS/CIR/SIR/USB will worth the effort For me, I think you've hit the nail on the head. We're trying something new with gta02-core, and by working on the small changes we've proposed we can focus on the tools that we use, the organisation of individual contributors and the stages we need to go through to get functional hardware. Doing gta02-core means that we should be able to move forward fairly rapidly and shake out any problems as we go. For that aim, the specific changes we make are almost arbitrary - and as stated on the wiki we don't expect this to turn into production hardware. My hope is certainly that we'll be in a position to design a more interesting device once we've finished with gta02-core, having established a hardware community and process for making those design decisions. We'll also be in a better position to discuss part availability with suppliers (or project sponsors), if we've demonstrated our ability to 'create' as a community. There's definitely plenty to do, so it would be great to see anyone interested in helping with hardware construction or review on the gta03 list. Dave ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New Life in Openmoko Phones
Toni Mueller wrote: They chose a 100% GPL layout tool, KiCAD (http://en.wikipedia.org/wiki/Kicad), which uses only text-based files This sounds good, but you seem to require a certain minimum version of Kicad, right? Checking out from OM and running Lenny's Kicad produced less-than-satisfactory results... Either the repo is broken, or the software is. Some clarification would be nice to have! I'm currently using 20080825 (latest ubuntu package), and Werner is on the svn bleeding edge - both seem to work with the current repo. It's early days, and we are still experimenting with KiCad to work out how best to use it collaboratively - so there may be things we need to change. Come over to the gta03 mailing list and we'll try to help with the specific problems you're having. Dave ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New Life in Openmoko Phones
GNUtoo wrote: *will the sound quality be ok(is there a plan to correct the problematic capacitor that is between the sound card and the audio connector)? and will it fit into the same case than the GTA02...because if I understood well the sound problem can't or is too difficult to fix well(otherwise it's dangerous...) on the GTA02 We expect to be able to get the 100uF capacitors in the space we gain from removing the audio amp and the u4401 (gsm upload) circuitry. Retro-fitting to gta02 boards is more complex, as there is neither board space or vertical height above existing components and below the can. *Does everything fit into the buses(GPIO,SPI etc...) because the removing the glamo removes some GPIO if I remember well Removing Glamo loses the SDIO interface currently used for the SD card. So we will be moving the WLAN to SPI, and the SD card to the SDIO interface on the SoC freed up by the WLAN It all fits so far. *I bet I will need to buy the debug board if I buy such phone...because I'm afraid of bricking it(no NOR means only one bootloader...and I could have rendered mine unbootable if the nor was not present: I typed bad uboot command and that prevented the nand uboot from beeing used(no more usb-serial access and no more booting)) The expectation is that QI and any build data will be written to NAND once, and then not over-written. QI's simplicity means that once it's working for the new board, it shouldn't need upgrading later. Combined with the kernel and OS images on the SD card, this should eliminate (or at least vastly reduce) any writing to NAND. This puts the gta02-core bootloader in a similar situation to the current GSM firmware, and many PC BIOSes - not normally field serviced, but can be if needed. Debug boards or other JTAG equipment will be needed for anyone hacking on the initial boot/bringup, which probably covers all of the handful of prototype boards we're currently expecting to produce... Dave ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New Life in Openmoko Phones
Max wrote: Are there plans to change uSD placeholder? No - changing uSD holder isn't part of the GTA02-core plans. In GTA02-core the intention is that the uSD card contains the full OS image including kernel. The NAND will only contain QI, and the expectation is that QI won't need to be re-flashed regularly. GTA02-core can't start if the card is missing, and there's no possibility of swapping out the card while the phone is switched on. Thus the uSD is rather like a standard PC's OS hard drive, and rather unlike 'removable' media types. This is how some folk are using the uSD at the moment, with one or multiple distro images on an uSD card. Upgrading a distribution, or fixing a broken install is then possible by removing the uSD and mounting it in a regular PC, without necessarily re-flashing through dfu. With GTA02-core, each distro can have a kernel ( modules etc) it's matched to, because the kernel is part of the distro's filesystem image. This also means that our internal storage is upgradable, as new uSD devices become economical etc. One thought is that future phones should include two uSD cards - one 'internal' for OS/kernel etc. and one that is 'removable' for data storage/exchange - although this is out of scope for GTA02-core. All the best, Dave ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New Life in Openmoko Phones
Martin Bernreuther wrote: One thought is that future phones should include two uSD cards - one 'internal' for OS/kernel etc. and one that is 'removable' for data storage/exchange - although this is out of scope for GTA02-core. s/should/could. Obviously there isn't any commitment to future phones at the moment, so while I may think two uSD cards is a swell idea, it may or may not happen. Dave ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Freerunner's Future
Rui Miguel Silva Seabra wrote: On Wed, Jun 03, 2009 at 12:30:21AM +0400, Alexander Chemeris wrote: On Tue, Jun 2, 2009 at 8:44 PM, Rui Miguel Silva Seabra r...@1407.org wrote: For now, I'm hoping my Freerunner improves enough to last long, as I don't expect another Free Software phone to come up anytime soon. Don't forget about GizmoForYou project with its Flow, as just an example: http://www.gizmoforyou.com/comment.php?comment.news.41 Flow looks sleek, but what about it's commitment to Free Software? I really don't know, can you help me know more? The flow project itself seems pretty open, but it depends on gumsticks, which have closed hardware but seem to be widely supported by open software corresponding communities. It sounds an interesting project, and will be available much sooner than the gta02-core or 'future' work which we have started, although these OM / gta derivatives might have more potential in the longer term. I echo everyone elses thanks to Sean and the rest of the team that have had involvement with OM - you guys both achieved a lot, and did so openly in a way that gives us a platform to build from. Through the last couple of years and now, thanks for communicating as openly as you have. It's down to us now, and I look forward to both contributing myself, and benefiting from the contributions from the whole community. Dave ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Freerunner's Future
Risto H. Kurppa wrote: Thanks Sean for this announcement! It's appreciated to get a status update from OM of things we've heard rumors of. I'm very happy that OM got this far with the phones: we have some tens of thousands (better guess anyone?) of Linux phones around the world, various open/free distros to run on the HW and means to communicate to make it better. I think OM was decent on the hardware side, it's a great achievement to have manufactured a open/free Linux-phone. Thank you for that, thank you everyone who worked on OM for this! ditto! :-) And also thanks for the commitments to opening up further details, designs and marks in support of the community, and providing the om.org infrastructure we're using. Now as the community will go 'wild', I'd now, more than ever, like to see good leadership practices to organize and guide the community. If you ask me where OM failed, it's this: managing and leading the community. So I think we'd need some direction where to make people go, who don't know where to go. We have around 20 distros and phone apps - I wouldn't like to see this all break in small sub-projects that all do the same work and don't communicate, but one single big project that'd actually take us somewhere. Diversity has it's advantage, though focus on a smaller number of projects has it's own benefits too. I think it's great that FSO has resulted in a stable platform that most of the current distros rely on and benefit from. While there remains interest in the current (or future) distros, my personal feeling is that we shouldn't try to kill one, in favour of another. They currently all have strengths and weaknesses, and the community as a whole gets strength from their diversity. We should collaborate on any common ground (kernel, fso?, illume?), and allow distributions to differentiate where they see appropriate. I think you are spot on though that we need to be better organised, and as individuals, communities and 'leaders' (if that's appropriate) have clear asperations and achievable objectives. Overall, I think clarity and sensible organisation will allow the community(ies) to flourish, while supporting as much diversity as the different sectors of our community want. Dave ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: The University of São Paulo's intent to j oin Openmoko development
Hi Maddog, [added cc to gta02-core list] Thanks for looking into this - it certainly sounds like an amazing opportunity, almost too good to be true - what's the catch! :-) Do you know how Dr Zuffo sees the universities involvement with, and relationship to the rest of the community - i.e. do they seem themselves driving the projects, becoming 'sponsors', or as contributing members of the wider community? From my point of view, it sounds like they've got a lot to offer the projects (both in expertise and facilities), and I think our community would be stronger with them as members. I'm assuming from your messages below that (initially at least) they are happy participating in the kicad / CC-SA licensed community process gta02-core has adopted so far? While we're a long way away from producing quantities of 10,000 devices, in the coming weeks and months the gta02-core project is hoping to be in position to produce a handful of prototypes. It sounds like LSI-USP might be able to help us with this current design process, and production of the prototypes? This could be a sensible starting point for Dr Zuffo and LSI-USP to get involved with the community, building a relationship that can grow as we get to know them, and they get to know us! All the best, Dave Jon 'maddog' Hall wrote: Dear Openmoko Community, In light of the refocusing of Sean's company on consumer items, there has been a perceived vacuum created in the Openmoko community's efforts to create next-generation open cellular smart phones. I happened to be working with Dr. Marcelo Zuffo, a full professor and the head of the Laboratory for Integrated Systems at the University of São Paulo, Brazil, on an unrelated project. I asked Dr. Zuffo if the university would be willing to join the Openmoko community and to provide critical resources to the task at hand. I subsequently have met with Dr. Zuffo several times on this matter, have seen his facilities (which include a very modern and state-of-the-art SMT line) and have discussed the goals of the community to design and prototype a completely open design for a cellular phone. Dr. Zuffo and the university understand your issues, understand free and open source software and hardware and are willing to assist the community with this project. I might add that the university can bring several new capabilities to the community: First of all, Dr. Zuffo has discussed the Openmoko project with the Minister of Telecommunications of Brazil, and the Minister is very enthusiastic about the concept. Having the support of the government of the twelfth largest economy behind the project might really help us with various negotiations with vendors. Secondly the University has been working on several aspects of telecommunications for a long time, and therefore has expertise in telephonic security and codecs (among other things) that could be of use to the Openmoko community. Third, the university has the ability and expertise to design new integrated circuits. Recently they designed a a range of analog-digital chips. Therefore the possibility of developing, manufacturing and freely licensing new chips to help reduce the cost of the phone is possible. Forth, while the facilities I mentioned are capable of producing up to 10,000 units at the rate of one circuit board every 30 seconds, the purpose of the facilities is research, developing and support projects that can lead innovation, the lab's charter does not allow them to manufacture more units then the 10,000 because that would be commercial production. Therefore the university has a goal of freely licensing the design to companies for manufacture. Fifth, the university would be happy to host the mailing lists and forums of the Openmoko project. If some of the software projects need hosting and can not find hosting services other places, the university will consider acting as a primary hosting facility for these projects. Sixth, personally I would like to see this concept extended, of inviting more universities and their facilities to help with this project world-wide. I hope that the leadership of the University of Sao Paulo will help create the structure and inspiration for this to happen. Finally, the university has a non-profit legal entity, LSITEC, which can easily do the type of paperwork that Sean's company did (NDAs, certification) so the community can leverage off that. I know that there will be a lot of questions and considerations to take before the community is comfortable with this relationship. Dr. Zuffo has asked that I help coordinate the joining together of the university with the community, and in the interest of seeing Openmoko continue to do the fine work started by Sean and all of you, I will be glad to help in this capacity. I am monitoring the community mailing list, and people are also welcome to email me directly (mad...@li.org) with
Re: Freerunner Chat Application: Suggestions wanted!
Rui Miguel Silva Seabra wrote: On Thu, Jul 16, 2009 at 01:16:09PM +0100, Michael Sheldon wrote: Alex Teiche wrote: Hello everyone, I recently recieved my A6 FreeRunner, and have been looking for some coding to do:) I plan on writing a chat application(similar to Pidgin) optomized for the small screen. I was wondering what suggestions the community had before I get too far into it. Hi Alex, I'm actually currently working on a project similar to this using elementary and telepathy; I haven't made it particularly public yet as it's only in a very roughly usable state and I think I still need to spend some time updating some of the telepathy packages in OE before it's easy to install directly on the device (there are easy to install debian/ubuntu packages though). Release early, release often, have a public repository for sources, issues, etc... works best even if your first releases only have basic functionality. Go, go, go, go! Mike :) +lots I love the concept here - bringing together a contact and all your contact with them (through whatever medium), and using the best method for reaching them. What's the odds of integrating this with google voice or similar roaming-number service? I don't know where FSO is at with a comprehensive contacts database (i.e. beyond sim stored data), but it might be worth talking to them about integrating your contacts store needs as an FSO api? Cheers, Dave ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: The University of São Paulo's intent to join Openmoko development
Jon 'maddog' Hall wrote: So organize your needs. Reach out to your own universities and software usability development groups. Get them to join the project. Don't give up. If you look closely, you can see the light at the end of the tunnel. It may be faint, but I have seen similar tunnels before, and I can see the light now. This (and the aim of something better) is all the encouragement we should need. This is up to us, and we need to work together - each finding the area we can contribute - to first make the current projects successful, then expand, and later change the way people look at their phones (in the same way that Linux has changed data centres and startups). Dave ps - illume and SHR rocks my FR ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: The University of São Paulo's intent to join Openmoko development
Hi Maddog, it certainly sounds like an amazing opportunity, almost too good to be true - what's the catch! :-) I hope that you will find there is no catch. If you do think there is a catch, please tell me. Thanks again for bringing this to us, and the detailed responses. I think this is a very positive opportunity, and I hope we are on track to the university being in a position to help out with our little projects. I think Werner is trying to catch up with Dr Zuffo - which in my mind would be a very good thing to happen as Werner is definitely the point man for the gta02-core effort. I certainly see the university as sponsors of the project, in the fact that it does cost money to run such an SMT line, to do some of the legal work, etc. I would like to find a way to help compensate them for this work, to make the project truly self-sustaining. Dr. Zuffo and I have discussed government grants and other funding ideas. Please see below. snip In order to fund the Openmoko project, I would like to suggest that *all* the things that Openmoko made open *up to this time*: o circuit design o case design o circuit board layout o testing issues. o plans for future, etc. be completely open and published as before. But (for example) the gerbers be licensed with a small royalty (1-2 dollars per phone, with a cap of 500,000 to 1,000,000 USD) only if the party will make *over* 5,000-10,000 phones There are obviously some significant costs associated with developing hardware that while HW development took place inside openmoko, were met by Sean etal. You rightly point out that if we're to be successful we'll need to find ways to meet those costs. I'd very much like to hear others thoughts on the matter, but from my point of view (and this may be wishful thinking), if there are opportunities to fund this work through grants or corporate donations, I think this would be preferable to licensing the end results (i.e. the gerbers) for production. In my mind, licensing the gerbers for production introduces restrictions on the uses that a recipient may put those designs too - including their ability to modify redistribute those files. My preference would be to encourage that redistribution, through Share-Alike / GPL style licensing of all assets. If a manufacturer wants to adopt the design to a new case, add extra buttons, changes components or invests additional resources in increasing production yields, the rational for sharing that investment with other licenses is less concrete. Some potential sources for funding might be: - phone fabs that would otherwise need to spend significantly more money either developing their own designs or buying someone else's design - government grants to seed phone production industries, or promote telephony freedom - universities or other research organisations that can use our devices as a platform for learning or their own development. If gerber licensing is believed to be the only realistic way to generate the investment needed for prototype runs etc., I think there would be benefit in any such ownership and licensing being conducted through a legal vehicle independent of any one individual or organisation (I don't know if LSITEC fits this description or not). Doing so would encourage the involvement of multiple organisations, universities or individuals, and would allow the team to select the most economic or timely method for purchasing or prototype production - through one of our partners or external commercial parties if they're able to deliver more effectively. I don't want my comments to be taken negatively, I think LSI-USP has fantastic potential for helping these projects, ensuring the longterm viability of our dream and filling in some of the gaps that are apparent in our efforts to-date. I think you're spot on that universities could be excellent partners with many shared objectives in what we're trying to achieve. Can we do this without resorting to paid licensing of any of our assets? I see a scenario where we, with USP, are in a position to generate designs that they could take into small scale production (similar to OM), selling those handsets to the community at small scale profits, using the process for the benefit of their students and generating a platform for them to grow in the future - while maintaining the SA style licensing. If it's achievable, this seems the ideal outcome to me. /$0.02 All the best, Dave ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [CU] voting required
Jon 'maddog' Hall wrote: I assume you would like to modify V1, but could you explain how more precisely? I like the over-all look of V1, but I also like the working hardware box. By putting the working hardware box in a column by itself, making a three-column layout, you reduce the amount of space for column two, which makes the page longer showing the same amount of information. I suggest that the working hardware box of V3 be moved to the first column under the left-hand picture of the application/distribution. Then the home page, Image, Tested on Hardware, etc. which is now at the bottom of the page could also be listed in the left hand column beneath the working hardware box. This would allow the right hand column (of what is now a two-column page) to be just text on a white background. I was just trying to describe exactly the same thing. I like this approach, based on the clean V1, and think that it will be clear enough where one section stops and the other starts by the picture/title associated with each table. If that doesn't work, in my mind a simple 1px gray light border would work better than the block colours, which can be a little over-powering. Dave ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [CU] voting required
Patryk Benderz wrote: [cut] associated with each table. If that doesn't work, in my mind a simple 1px gray light border would work better than the block colours, which can be a little over-powering. 1 px added for you where relevant. Tell me how do you like it now. I Like it - particularly the one with two columns (not three) and the 1px orange border. Dave ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [CU] voting required
Andrew Stephen wrote: 2009/7/28 Warren Baird wjba...@alumni.uwaterloo.ca: looks great - I took the liberty of adding the version #'s into the output created by the template, so you can see the version #'s on the draft community page. My preference is '8a' I vote for 8a also. 8a was the one I liked. Dave ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Qi - why only 3 partitions on SD card?
Dr. H. Nikolaus Schaller wrote: What I wonder is why nobody did fix u-boot if it had problems with bigger kernels. I'm just a bystander here, but from what I understood this wasn't the reason Qi was started. u-boot is an entire environment that needs drivers for a lot of the hardware (usb, graphics, pmu, etc.) all of which end up duplicated in the Linux kernel. The u-boot philosophy (of an entire environment supporting DFU and a boot menu) implies that those drivers have to be maintained in two places (u-boot and kernel) which cases pain, and inevitably results in u-boot being slower to boot. Qi starts with a completely different philosophy - that the bootlooder should do as little as possible, and that it should need to know as little as possible about the hardware. In terms of intent, it's closer to the coreboot project than it is to u-boot. You really couldn't achieve this [separation of bootloader device drivers] with u-boot, which is why the separate Qi project was formed instead of continuing to evolve u-boot. So what you _can't_ do inside Qi is have a graphical boot menu, or support dfu - because Qi doesn't know how to talk to the hardware. What you _can_ do is construct a mini Linux environment that provides a boot menu / usb-dfu, and is booted by Qi in the normal way. This would place those tools in regular Linux userspace, i.e. much more accessible to regular non kernel / bootloader hackers. This could be the default or secondary boot option - provide a boot menu and then chainload the desired final Linux environment. There's a philosophical difference between the two projects, and I think Qi's approach is much better suited to this kind of hardware, than u-boot could ever be (with trunk, or with the existing gripes resolved). But you can only influence the future but never change the history... Wise words! :-) Imho our time would be better spent building this mini-environment (which would probably be best constructed in initrd as Paul mentioned) than returning to u-boot. Any takers? Dave ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ideal screen rotation
Carsten Haitzler (The Rasterman) wrote: On Sat, 7 Nov 2009 19:46:28 + Rui Miguel Silva Seabra r...@1407.org said: Being X properties or DBUS, it's the same for me. DBUS seems more natural as there's probably less pooling, but then I know only a bit more of DBUS than of X11 (which AFAIR was a bunch of huge books) :) no. dbus is far from natural or correct. that's what i keep saying. this is not something for dbus. it's something for properties on a window. Sounds like we should be using window properties for passing hints to the WM, and dbus for getting orientation information from the accelerometers. Maybe it's time for omnewrotate to retire, with the WM talking to FSO's orientation API [1] directly? app - window properties - wm - dbus - fso WM making the decision on what direction to orient the display, based on window properties and device actual orientation etc. Dave [1] http://git.freesmartphone.org/?p=specs.git;a=blob_plain;f=html/org.freesmartphone.Device.Orientation.html;hb=HEAD ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ideal screen rotation
Carsten Haitzler (The Rasterman) wrote: On Sun, 08 Nov 2009 02:03:47 + Dave Ball openm...@underhand.org said: Sounds like we should be using window properties for passing hints to the WM, and dbus for getting orientation information from the accelerometers. that is sane. :) Maybe it's time for omnewrotate to retire, with the WM talking to FSO's orientation API [1] directly? perhaps. whatever the mechanism 1. the wm is the right place to make the decision. 2. the wm is in the best position to easily gather information about an application's window and know what window is active 3. the wm is already talking to the xserver as part of its job - and it's always hanging around 4. all the wm needs to know is some external input has decded that the screne should be rotated. I think what you meant here is the WM decides whether the screen should be rotated or not - all the 'external input' provides to the WM is some hint that e.g. the _device_ has been rotated? WM could decide to NOT rotate the screen, if the current app only works in one orientation. be this an accelerometer, or like the g1, opening up the screen, so be it. as long as 4.1 the current status of this rotation state can be queried at any time (you can ask what position the device is in or the screen is opened up or not etc. etc.) 4.2 you can get an event when this state changes really quickly (not have to wait a while). Indeed. I've not played with the fso orientation API, but it looks like that is exactly what it's designed to provide. It seems sensible for this to be over dbus - given that it's an abstraction of hardware. if it were me... i'd even have the current desired rotation state be a property on the root window too... but at this point its moot - dbus or property. If the root window will only work in one orientation, specifying that orientation through a window property would be consistent - but ideally wouldn't we want the root window to be able to cope with being rotated to work in either orientation? Or have i missed something special about the root window? Dave ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ideal screen rotation
Carsten Haitzler (The Rasterman) wrote: wm needs to track both and determine which one takes precedence based on policy and th en implement that rotation, if needed. policy is what a wm implements - that's the nature of the beast. that policy may be hard-coded in the wm or configuration for it. Is there a quick-start guide for writing an e module, maybe some simple code / example? Dave ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ideal screen rotation
Carsten Haitzler (The Rasterman) wrote: On Sun, 08 Nov 2009 04:37:07 + Dave Ball openm...@underhand.org said: Is there a quick-start guide for writing an e module, maybe some simple code / example? http://www.rasterman.com/files/logo-0.0.1.tar.gz http://www.youtube.com/watch?v=abNsVyYTSkU Heh - Thanks! That's pretty comprehensive and cool - now if only youtube would let me step frame-by-frame! :-) Dave ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ideal screen rotation
Carsten Haitzler (The Rasterman) wrote: wm needs to track both and determine which one takes precedence based on policy and th en implement that rotation, if needed. policy is what a wm implements - that's the nature of the beast. that policy may be hard-coded in the wm or configuration for it. I've been looking at existing window properties [1] to try and understand the best way to do this. option1: New atoms in the _NET_WM_STATE property. - _NET_WM_STATE_LANDSCAPE - _NET_WM_STATE_PORTRAIT If neither is present for a given window, WM can choose (based on the accelerometers). Both present is an error - or could be defined as leave the window in it's current orientation. option2: New property. _NET_WM_ORIENTATION 0 = Either / WM decides 1 = Landscape 2 = Portrait Thoughts? http://www.youtube.com/watch?v=abNsVyYTSkU OT - but I'm struggling with e's xnest.sh script: xhost + su newuser Xnest -ac :1 env DISPLAY=:1 enlightenment_start works, but: xhost + su newuser /data/programming/e17/e17_src/e/xnest.sh doesn't. Initially it ran through e's firstrun wizard in an xnest, then crashed - now it dies on start. I've attached the xnest.sh output - any ideas? Dave [1] http://standards.freedesktop.org/wm-spec/1.4/ar01s05.html newu...@dougal:/data/programming/e17/logo-0.0.1$ /data/programming/e17/e17_src/e/xnest.sh [dix] Could not init font path element /usr/share/fonts/X11/cyrillic, removing from list! (EE) config/hal: NewInputDeviceRequest failed (2) (EE) config/hal: NewInputDeviceRequest failed (2) (EE) config/hal: NewInputDeviceRequest failed (2) (EE) config/hal: NewInputDeviceRequest failed (2) (EE) config/hal: NewInputDeviceRequest failed (2) (EE) config/hal: NewInputDeviceRequest failed (2) GNU gdb 6.8-debian Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as x86_64-linux-gnu... [Thread debugging using libthread_db enabled] ESTART: 0.0 [0.0] - begin ESTART: 0.00010 [0.00010] - signals done ESTART: 0.00014 [0.4] - determine prefix DYNAMIC DETERMINED PREFIX: /opt/e17 ESTART: 0.00034 [0.00020] - prefix done ESTART: 0.00037 [0.3] - eina init [New Thread 0x7f440ce2c710 (LWP 25665)] ESTART: 0.01835 [0.01798] - intl init ESTART: 0.01840 [0.5] - parse args ESTART: 0.01841 [0.1] - arg parse done ESTART: 0.01845 [0.3] - ecore init ESTART: 0.02113 [0.00268] - ecore_file init ESTART: 0.02128 [0.00015] - more ecore ESTART: 0.02129 [0.1] - x connect Xlib: extension DPMS missing on display :1.0. Xlib: extension RANDR missing on display :1.0. ESTART: 0.02402 [0.00273] - ecore_con ESTART: 0.02432 [0.00030] - xinerama E17 INIT: XINERAMA CHOSEN: [0], 1080x675+0+0 ESTART: 0.02665 [0.00233] - x hints ESTART: 0.02702 [0.00037] - x hints done ESTART: 0.02703 [0.1] - ecore_evas init ESTART: 0.02715 [0.00012] - test done ESTART: 0.02716 [0.1] - efreet ESTART: 0.02731 [0.00015] - efreet done ESTART: 0.02732 [0.1] - configure ESTART: 0.02738 [0.6] - dirs ESTART: 0.02746 [0.8] - filereg ESTART: 0.02747 [0.1] - config ESTART: 0.02906 [0.00159] - scale ESTART: 0.02915 [0.8] - pointer ESTART: 0.02916 [0.2] - path ESTART: 0.02922 [0.6] - ipc INFO: E_IPC_SOCKET=/tmp/enlightenment-system/disp-:1.0-25665 ESTART: 0.02954 [0.00031] - font ESTART: 0.02957 [0.4] - theme ESTART: 0.03629 [0.00672] - intl post ESTART: 0.04364 [0.00735] - move/resize info ESTART: 0.04374 [0.9] - splash RUN INIT: /opt/e17/lib/enlightenment/utils/enlightenment_init '/opt/e17/share/enlightenment/data/themes/default.edj' '1' '0' 'Enlightenment' '0.16.999.062' Xlib: extension DPMS missing on display :1.0. Xlib: extension RANDR missing on display :1.0. E17 INIT: XINERAMA CHOSEN: [0], 1080x675+0+0 Program received signal SIGUSR2, User defined signal 2. [Switching to Thread 0x7f440ce2c710 (LWP 25665)] 0x7f4407b0e8b0 in __pause_nocancel () from /lib/libpthread.so.0 #0 0x7f4407b0e8b0 in __pause_nocancel () from /lib/libpthread.so.0 #1 0x0042e626 in main () The program is running. Exit anyway? (y or n) [answered Y; input not from terminal] newu...@dougal:/data/programming/e17/logo-0.0.1$ [dix] Could not init font path element /usr/share/fonts/X11/cyrillic, removing from list! (EE) XKB: No components provided for device Virtual core keyboard ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ideal screen rotation
Rui Miguel Silva Seabra wrote: On Tue, Nov 10, 2009 at 12:00:31AM +, Dave Ball wrote: option1: New atoms in the _NET_WM_STATE property. - _NET_WM_STATE_LANDSCAPE - _NET_WM_STATE_PORTRAIT If neither is present for a given window, WM can choose (based on the accelerometers). Both present is an error - or could be defined as leave the window in it's current orientation. option2: New property. _NET_WM_ORIENTATION 0 = Either / WM decides 1 = Landscape 2 = Portrait There are two landscape positions and 2 portrait positions :) Doh - of course! Which would lead to: _NET_WM_STATE_ORIENTATION_LANDSCAPE _NET_WM_STATE_ORIENTATION_PORTRAIT _NET_WM_STATE_ORIENTATION_INVERTED or _NET_WM_ORIENTATION 0 = Either / WM decides 1 = Landscape 2 = Portrait 3 = Landscape inverted 4 = Portrait inverted However, what's the use-case for an application requesting either of the inverted states? I can't see when those would be useful - in terms of hints the app would supply. Obviously, if the WM was deciding orientation based on the device position, you would correctly rotate to the inverted states, but if an application is built for portrait or landscape is there any reason a developer would not want the normal portrait/landscape orientation for the device? Dave ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ideal screen rotation
Warren Baird wrote: perhaps the landscape / portrait flag should just contrain the rotation? So if you flip the phone 180 degrees, you get the 'expected' behaviour, but if you just flip it 90 degrees nothing changes? Given that these properties are for the orientation an application requests (to the WM) should ideally be used, I'm not sure how the actual rotation would help? Working from rotation would also complicate the behaviour on devices that are normally landscape - such as the Nokia N900. What I'm suggesting is that the application just says landscape or portrait, and then the WM would decide the most appropriate way to orient the screen for that device. If an application doesn't request either landscape or portrait, then the WM would rotate the screen according to the device orientation, through each of the positions the device could be held (including inverted). So the WM definitely needs to know the actual orientation of the device (such as from the FSO api), but I think the application itself only needs to request Landscape, Portrait or neither. Dave ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ideal screen rotation
Rui Miguel Silva Seabra wrote: On Tue, Nov 10, 2009 at 12:08:06PM +, Dave Ball wrote: However, what's the use-case for an application requesting either of the inverted states? I can't see when those would be useful - in terms of hints the app would supply. Obviously, if the WM was deciding orientation based on the device position, you would correctly rotate to the inverted states, but if an application is built for portrait or landscape is there any reason a developer would not want the normal portrait/landscape orientation for the device? Yes, certain devices may be better prepared (in terms of connectivity for power, usb, etc...) for one kind of landscape rather than the other. Yup - although that would be at the device level rather than the application level. If the WM knows what the device's policy is, I can't see a situation where one app wants to be in landscape, and a different app wants to be in landscape inverted on the same device? Dave ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ideal screen rotation
Warren Baird wrote: I meant that it should *constrain* the behaviour of rotation - more or less like omnewrotate behaves now, but skipping over the two 'incorrect' orientations. so if the app says 'landscape', it's still flip between xrandr -o 1 and xrandr -o 3 as you rotate the phone, but won't flip to xrandr -o 0 or xrandr -o 2. I don't think it will normally makes sense for an application to specficially request 'xrandr -o 3' - they will usually just want to be sure that they are displayed in portrait or landscape mode. ok, we can make that a policy decision in the WM, but the app only needs to specify portrait or landscape. Dave ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Whither open hardware ?
Laszlo KREKACS wrote: There is also the openpandora project: http://www.open-pandora.org/index.php?option=com_contentview=categorylayout=blogid=2Itemid=2lang=en Is it unsuitable for a phone because of power inefficiency? Can be the ARM Cortex-A8 600Mhz used in a future phone? The pandora (and beagleboard) use the OMAP3530 which (afaik) is just a retail package of the (oem only) OMAP3430 used in the palm pre and motorola droid. [1] The docs are open [2] (except the power VR 3D subsystem), and from first looks it should be fine in a future phone - though it would be a radical departure from our existing designs. Dave [1] http://en.wikipedia.org/wiki/Texas_Instruments_OMAP [2] http://focus.ti.com/docs/prod/folders/print/omap3530.html ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Whither open hardware ?
Hi Werner, Werner Almesberger wrote: There are many component choices for future phones. Things to consider when choosing chips include: snip - are they available (to us) ? What's the yard stick for measuring against here? I.e. are we talking about one-off from digikey/farnell, samples direct from the manufacturer, or limited-run (couple of hundreds) quantities? - what are the integration costs ? is this things like placement of awkward (small pitch etc.) parts, FPC's etc., or ancillary parts such as partner chips? - do they work as intended ? Hehehe. :-) Is the normal route of sourcing via a factory (even for prototypes etc.)? From a few searches it seems that getting hold of some parts (i.e. screens / touch layers) is incredibly difficult for one-offs. Dave ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: qi-bootmenu-0.1 for GTA02
Hi Torfinn with the SD card inserted, I see no bootmenu - it just boots /dev/mmcblk0p2 every time. What's wrong? You forgot to tell Qi not to boot from the SD partitions. See: http://wiki.openmoko.org/wiki/Qi#Files According to the readme[1] on the qi-bootmenu site, it is not necessary to mark the SD paryitions as not bootable: This is the case if you have installed Marc's patched Qi. The qi-bootmenu results in a two step boot process: - firstly qi-bootloader boots and executes the linux kernel in NAND. This includes an initramfs with the qi-bootmenu userspace - That userspace then scans SD card partitions, presents the menu and proceeds to boot whichever you select. So to get the bootmenu working properly you need to make sure Qi boots the kernel/initramfs in NAND, and not your SD card partitions. You can make sure qi boots from NAND by either: - installing marcs patched qi which ignores the SD card completely or - marking your partitions as noboot as Al suggested. If your freerunner is booting from SD card by default, and only displaying the bootmenu when pressing AUX while booting, then you're still using standard qi rather than the patched version. hth. Dave ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
