Hello again, Thanks to everyone who has responded to my introductory post with helpful tips and suggestions!
Radek Polak <pson...@seznam.cz> wrote: > As for good power management - it's given by HW design and linux kernel. > You can't affect very much from userspace. But doesn't the userspace need to tell the kernel when some things should be powered up or down? Things like the LCD, the backlight, the audio codec... > You can get 4-5 days on one battery charge, > if the phone is in suspend (PMU+RAM+modem is on, rest if off). That's very good to hear! I was a little afraid of the FreeRunner being a charge 2-3 times a day type of deal: that's what some sources were suggesting. Glad to hear that the original Om developers did a good job building the HW such that it *can* provide "normal phone" battery life, assuming that of course the software does its part properly as well and does not needlessly waste power. > Btw why X11 for such project? Wouldnt be framebuffer enough? I've been thinking about going the X11 route for two reasons: * My personal programming comfort zone: I've written X11 apps using just libX11, and I'm comfortable with it. If I want to put a piece of text on the screen, I can just ask X11 to do it for me, exactly the same way as how I do it on the 1980s UNIX workstations which stay back in my office while I roam around with my FR. :-) If I went the directfb route, I would have to learn how to use some text/font rendering library outside of X11. Yes, my project is all about learning, but I'm interested in more focused learning: I want to learn how to make my phone place and answer voice calls, not how to use whatever is the "modern Linux" world's preferred text/font rendering library du jour. * X11's client/server architecture is generally viewed as a nuisance in the embedded world, but it might actually help me split my UI code into more manageable pieces. I tentatively plan on having a main UI daemon, but some pieces could be split off into separate programs. For example, upon getting an incoming call (MT = Mobile Terminated in GSM-speak), I could make my gsmd fork/exec off an mtcall process; the mtcall binary would then connect to the X11 server and display a window showing the number and/or contact name of whoever is calling. All of the above are just my tentative thoughts, I may well end up choosing a different approach when I actually get into it. I have a strong dislike for abstract-ware, so I need to hold the hardware in my hand before my brain can really kick into gear and decide how I should write the software for it. I am still waiting for my GTA02 to arrive, and until I get it I am limited to fairly idle speculation. :-( Denis 'GNUtoo' Carikli <gnu...@no-log.org> wrote: > feature phone is also non-derogatory and means exacty the same thing I don't think it means the same thing though: as I understand it, people generally use the term "feature" in "feature phone" to refer to non-basic-telephony features: camera, mobile web browser, integration with AIM/Yahoo/Facebook/whatever, all that stuff I hate with a passion. A phone that does voice calls, SMS, and absolutely positively nothing else would not be a "feature phone" to most people, it would be a featureless phone. That is what I am after, and that is what I call a Plain Phone. Actually, I need to clarify a little: I'm not against the non-telephony features per se, I just consider them much less important. I can see how *some* non-telephony features, such as GPS+openstreetmaps for navigation in a car when I get lost, would be a useful thing to have on the phone even for me. *After* I put together my "featureless" Free Plain Phone distro, I may well become interested in making an extended version of it with some non-telephony features added. But not before: I want a really good Plain Phone first. Part of it is just natural resistance: if someone were to constantly keep forcing some particular type of food down your throat, you'd naturally develop a hatred for it pretty quickly, even if it's something you would find tasty under different circumstances. That's how it is for me with "smart" and "features" phones. For many years now I have become disgusted with the kind of phones that are made, sold and bought by the mainstream society nowadays. And it isn't even the phones themselves, it's where the makers, promoters and ultimately buyers/users of these phones put their emphasis. Over the past many years now, every time I've been compelled into shopping for a new phone (be it a change of carrier, or old phone broke, or whatever), I've been bombarded by disgust: the phone salespeople keep focusing their sales pitches on non-telephony features. It seems to me that the phone industry and its user community have become so obsessed with their phones doing everything but basic telephony functions, that perhaps if someone came out with a new cool smartphone that browses the web, goes to Facebook, does GPS, displays TV and movies, plays MP3s but can't make a simple voice call, most users would likely never even notice the last minor omission. The non-telephony features occupy such a prominent role in the minds of the designers of today's phones, in their UI design, in their manuals, in their marketing and in the minds of the intended users, that the basic Plain Phone features are some little "ugly duckling" tucked away in the corner. *That* is what I am rebelling against, and that is why I want a Free Plain Phone distro that would make a phone do voice calls, SMS, and absolutely positively nothing else: it is my form of expressing protest against today's dominant smart/feature phone mentality. > learn about osmcombb, Googled for it, found the site, read the basics - wow, that is very, very cool! Awesome in fact! Definitely something to keep an eye on. > however it's not a drop-in replacement as it lacks: > *an AT command interpreter part(however they have an abandoned nuttx > port) Yes, it clearly is nowhere near ready for production use yet. But it's still something very much worth keeping an eye on. > *any kind of certification needed for connecting to carrier networks How would they enforce that? Just transmit a valid-looking IMEI and they would never know the difference, right? > still that's not so bad, the GSM modem doesn't control the CODEC(the > "sound card") nor the GPS. Yes, having no GPS in the Calypso is a very very good thing. I have a big problem with RRLP. Of course it is still possible for Calypso to implement E-OTD - does anyone know if Om's Calypso FW does or not? If it does, replacing it with a future usable version of OsmocomBB would be a good project. But that's for the future. > battery charging is done in the kernel. Including the intelligent logic to tell the PMIC how much current it should draw from USB VBUS? That's all from me for now, gotta wait for the GTA02 hardware unit to arrive... MS _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community