Re: [Om2009] testing Release 3: first impressions
On Thu, May 21, 2009 at 6:21 PM, Toni Mueller wrote: > > Other things that I'd change if I were able to, off the top of my head: > Hi Tony! A great list of issues and things to write down for further development. Please add the items here so they're all on one list and can easily be read through: http://wiki.openmoko.org/wiki/Paroli-issues Thanks! r -- | risto h. kurppa | risto at kurppa dot fi | http://risto.kurppa.fi ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Repository management (was: Re: [debian] navit navit_0.1.0+svn-2279_armel.deb)
On Fri, May 22, 2009 at 8:30 AM, Robin Paulson wrote: > 2009/5/22 Marcel : >> - Is is somehow possible (of course it is, but what's the price? ;) ) to >> have opkg.org be accessible directly via opkg as a repository? > > it is already. there are instructions in the kustomizer script as to > how to do this see http://wiki.openmoko.org/wiki/Kustomizer The opkg.org repository has some issues so don't rely on it too much. r -- | risto h. kurppa | risto at kurppa dot fi | http://risto.kurppa.fi ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [GPS] new GPS GUI application for OM freerunner
First of all, Google map and Google sat are good, but there are distorts and offsets, at least in my region. I don't know whether that's due to technical reason or something else. That's why I the "FixMap" button in "Map Tile" menu. As of Google map, only offset found, but Google stat has distort + offset, that's non-linear thus can't be "fixed" at all. Without good maps, any GPS GUI application becomes nearly useless. As an author, I have to think about map licenses. The ideal way is to remove any commercial licensed map configurations from omgps. But to provide you and me a ease of use application, I finally decided to keep Google map and Yahoo sat in config file :D Here is the config for Google sat: def GoogleSat(): return "min-zoom=1; max-zoom=17; image-ext=jpg" def GoogleSat_url(zoom, x, y): return "http://khm.google.com/kh/v=37&hl=en&x="; + `x` + "&y=" + `y` + "&z=" + `zoom` + "&s=Gali" (1) You append these two functions to $HOME/.omgps/config_01./map.py, make sure replace leading blanks with a tab latter. (2) Then add "GoogleSat" to map_list() Please note: (1) about the parameters "v=" and "hl=", version may changes, you can set hl as your locale? (2) the downloads always fail, it may returns a HTML page which contains clear text redirected URL. I think that's a polite anti-spam way. - About tracking (or tracing), I accept your suggestion. I choose limited in-memory points due to performance reason, but that may be unnecessary at all or performance can be improved by better algorithm. About the slow response of zoom/pan: yes, it is slow especially when maps are layered. I've taken considerable time to improve the response time, in-memory tile cache is one of the solution, but I know there are chances to improve it. I'd like to provide you and me a new version with faster UI response. Thanks a lot! ivvmm wrote: > > mqy wrote: >> Hi all: >> >> I got my gta02 freerunner on DEC 2008. >> After nearly 5 months development, I'm happy to announce the first alpha >> release of omgps. >> >> It is not as feature rich as other GPS applications, such as tangoGPS, >> anyway I think it should satisfy most of >> the daily needs. Please goto http://code.google.com/p/omgps/, download >> and >> give a try. >> >> After ten years of programming as a web developer for most of the time, >> now >> I join the community with my little gift :) Thanks you to open source >> community -- for your great works and spirits. >> > > Your application is definitely good one and worth using it all the time. > But what prevents from using it for now is why is it *so* slow while > dragging the screen or zooming? Well. May be it is not. But in TangoGPS > it just moves the screen, when u drag with a finger and then loads PNG > so it looks like response(somehow). And in omgps I feel like it hangs > for certain amount of time. > > Another question. Why did you limit the number of GPX traces? Why just > not to go unlimited? > > There is also a repo in TangoGPS called googlesat, which is better than > YahooSat in quality. Can it be added? Or could instructions for adding > it to omgps be posted? > > Thank you for improved GPS handling in FreeRunner! Now we have something > to compete with TangoGPS. > > > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > > -- View this message in context: http://n2.nabble.com/-GPS--new-GPS-GUI-application-for-OM-freerunneromgps-tp2948257p2955790.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Repository management (was: Re: [debian] navit navit_0.1.0+svn-2279_armel.deb)
2009/5/22 Marcel : > - Is is somehow possible (of course it is, but what's the price? ;) ) to > have opkg.org be accessible directly via opkg as a repository? it is already. there are instructions in the kustomizer script as to how to do this ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Community-driven redesign / new theme for Paroli
That's really interesting initiative. However it's unclear how do we handle rotation with this approach. I think it's one of the crucial things about themes - to be able to work (e. g. look & feel nice) after rotation. thank you, Max. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [shr-testing] Forcing fast charge mode
> With the current setup I get this error from the script: File not found: > /sys/devices/platform/s3c2440-i2c/i2c-adapter/i2c-0/0-0073/chgmode! > my guess would be this may be where it should be pointed to the voltage_now > file because everything else I was able to match up, but again I'm not quite > sure about this. http://wiki.openmoko.org/wiki/GTA02_sysfs#.2Fsys.2Fdevices.2Fplatform.2Fs3c2440-i2c.2Fi2c-adapter.2Fi2c-0.2F0-0073.2Fchgmode says that chgmode used to tell if the phone is charging or not. I think status also tells you exactly the same thing. You can cat /sys/class/power_supply/battery/status to verify that. --Vikas ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New Life in Openmoko Phones
Wolfgang Spraul wrote: > > Hi everybody, > > > Right now, if you want to join the revolution in open hardware > development, read the gta02-core wiki page carefully > (http://wiki.openmoko.org/wiki/Gta02-core), and join the mailing list > (slightly confusingly named gta03 :-)) at > http://lists.openmoko.org/mailman/listinfo/gta03 > Then see where you can contribute - it's a wide open field with many > possible tasks, no matter which background you are coming from. > > I'll see what I can do. > > I already put this on Wiki main page . > I think that will be more easy to find this page. > > Brenda Wang > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > > -- View this message in context: http://n2.nabble.com/New-Life-in-Openmoko-Phones-tp2934354p2955538.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New Life in Openmoko Phones
Nils Faerber wrote: > Wouldn't it be more fruitful to create a project that is only concerned > about providing the best possible tools, hardware and software, for > braking into and reverse engineering existing devices? There are already a number of projects that do exactly this, such as OpenEZX and gnufiish. There are a number of limitations to this approach, though: - there's always the risk that you can't "forcibly open" some important chips E.g. see the still large number of "0%" items on http://gnufiish.org/trac/wiki/Project_Status - it's difficuly to get power management right without knowing exactly what goes on in the device - even if you succeed, there's no guarantee that the vendor won't make some changes for the worse (from the Open Source point of view) in new revisions of the product. E.g., OpenWRT got bitten by a radical change of the core system architecture of the WRT54G. Luckily, LinkSys/Cisco could be convinced to make a variant specifically targetted for Linux. - worse yet, considering the amount of time such reverse engineering takes and the short life cycles of these products, the product may already have been replaced by the time you catch up. This means that it will be very difficult to spread such opened devices outside a groups of very determined enthusiasts. E.g., consider the age of the hardware OpenEZX, being in fairly good shape as far as the software is concerned, uses. Of course, none of this means that this approach is guaranteed to fail, there is the success story of the WRT54G, but that's also a much simpler and extremely long-lived device. So the bottom line is that I don't think this approach can only scale if you can convince the company whose phone you "opened" to cooperate with you. And it's unlikely that they would be able to open their design, even if you could convince them they should. On the other hand, the approach where you own the design can be brought to mass-production with anyone's support. Even a small carrier or a consortium of interested parties could do it. Furthermore, an open design lowers the barrier of entry for people who want to make variants. Not only do they not have to license the design, but they also don't depend on a single company to support them. > Hardware is needed in the form of good debug adapters. Those would be > much easier to have made than a complete phone device. Good software is > needed for the hardware debuggers and also for disassembly analysis, > protocol analysis etc. I think in terms of tools, both approaches can share a lot. A protocol analyzer will help you debug your own implementation just as well as it will help you to discover a vendor's mystery protocol. - Werner ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: linphonec
On Thursday 21 May 2009, Angus Ainslie wrote: > On May 21, 2009 03:01:48 pm GNUtoo wrote: > > Hi, > > I've just bitbaken linphonec and I didn't succeed at making it work > > I've followed this howto: > > http://wiki.openmoko.org/wiki/Linphone > > and I've no sound... > > Denis. > > > > PS: if there are better recipes I'd like to know where to find them > > Linphone 3 has been in the Om2009 feeds since testing 1 That looks like the release version where the GUI crashes if you try to access the preferences. This was a bug in the release version if built without video support, and has been fixed in svn. The attached recipe worked using autorev just after the upstream fix (rev 396) but I wasn't sure what the versioning convention was for svn recipes, then got distracted. Posting it now before I forget again! DESCRIPTION = "SIP-based IP phone (console edition)" HOMEPAGE = "http://www.linphone.org/?lang=us"; SECTION = "x11/utils" LICENSE = "GPLv2" DEPENDS = "intltool libosip2 speex libogg alsa-lib readline" DEPENDS_${PN} = "liblinphone" DEPENDS_${PN}c = "liblinphone readline" DEPENDS_liblinphone = "libmediastreamer libortp libosip2 libexosip2" DEPENDS_libmediastreamer = "speex libogg alsa-lib libortp" RDEPENDS_${PN} = "liblinphone" RDEPENDS_${PN}c = "liblinphone readline" RDEPENDS_liblinphone = "libmediastreamer libortp libosip2 libexosip2" RDEPENDS_libmediastreamer = "speex libogg libasound libortp" PROVIDES += "linphone linphonec liblinphone" PV = "3.1+svnr${SRCREV}" PR = "r1" SRC_URI = "svn://svn.savannah.gnu.org/linphone/;module=trunk" S = "${WORKDIR}/trunk/linphone" inherit autotools pkgconfig export PKG_CONFIG=${STAGING_BINDIR_NATIVE}/pkg-config EXTRA_OECONF = "--disable-gtk-doc \ --without-ffmpeg --disable-video --without-sdl \ --enable-alsa \ --with-osip=${STAGING_DIR_HOST}${layout_exec_prefix} \ --with-readline=${STAGING_DIR_HOST}${layout_exec_prefix} \ --with-speex=${STAGING_DIR_HOST}${layout_exec_prefix} \ --disable-truespeech --disable-manual \ --enable-strict=no \ " PARALLEL_MAKE = "" do_stage () { install -d ${STAGING_DATADIR}/aclocal oe_libinstall -a -so liblinphone ${STAGING_LIBDIR} install -d ${STAGING_INCDIR}/linphone install -m 0644 ${S}/coreapi/linphonecore.h ${STAGING_INCDIR}/linphone install -m 0644 ${S}/coreapi/lpconfig.h ${STAGING_INCDIR}/linphone oe_libinstall -a -so libmediastreamer ${STAGING_LIBDIR} install -d ${STAGING_INCDIR}/mediastreamer2 install -m 0644 ${S}/mediastreamer2/include/mediastreamer2/*.h ${STAGING_INCDIR}/mediastreamer2 install -d ${STAGING_INCDIR}/ortp oe_libinstall -a -so libortp ${STAGING_LIBDIR}/ install -m 0644 ${S}/oRTP/include/ortp/*.h ${STAGING_INCDIR}/ortp/ autotools_stage_all } PACKAGES += "linphonec linphone-rings liblinphone libmediastreamer libortp" FILES_${PN} = "${bindir}/linphone ${bindir}/linphone-3 ${datadir}/pixmaps ${datadir}/applications ${datadir}/gnome/apps ${datadir}/linphone" FILES_${PN}c = "${bindir}/linphonec ${bindir}/linphonecsh ${bindir}/sipomatic ${datadir}/sounds/linphone/ringback.wav" FILES_${PN}-rings = "${datadir}/sounds/linphone/rings" FILES_liblinphone = "${libdir}/liblinphone.so.*" FILES_libmediastreamer = "${libdir}/libmediastreamer.so.*" FILES_libortp = "${libdir}/libortp.so.*" FILES_${PN}-dev += "${libdir}/*.a ${libdir}/*.la ${libdir}/pkgconfig ${includedir}" ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [shr-testing] Forcing fast charge mode
On Thursday 21 May 2009 06:26:46 pm Vikas Saurabh wrote: > Check out > http://wiki.openmoko.org/wiki/GTA02_sysfs#GTA02_Kernel_sysfs_highlights_for >_kernel_2.6.28. specifically: >charger_type = > "/sys/class/i2c-adapter/i2c-0/0-0073/pcf50633-mbc/chg_curlim" #limit > that freerunner would accept >capacity = "/sys/class/power_supply/battery/capacity" >voltage = "/sys/class/power_supply/battery/voltage_now" >status = "/sys/class/power_supply/battery/status" >image_dir = "/usr/share/battery/" >usb_limit = > "/sys/class/i2c-adapter/i2c-0/0-0073/pcf50633-mbc/usb_curlim" #current that > is actually coming The only thing I wasn't able to quite figure out where it when is the voltage, here is the current configuration for the bash script, hopefully someone here will be able to tell where it goes and double checks this script before any phones get killed by bad settings: # SYS-Files and other settings # pmu_chgmode: tells what the charger status is (eg. "fast") # pmu_chgtype: tells in which charge mode we are currently running # pmu_chgstate: tells the charget state (what charger is detected) # pmu_curlim:tells us the current charge limit # pmu_chgfile: enables us to supply an override charge mode # bat_status:tells us the current status of the battery (if its charging etc) # bat_capacity: current capacity of the battery # bat_tech: technology of the battery, "Li-ion" for fics standard battery # bat_present: 1 if a battery is in place, 0 if not # bat_ttf & bat_tte: Time to full and time to empty pmu_chgmode="/sys/devices/platform/s3c2440-i2c/i2c- adapter/i2c-0/0-0073/chgmode" pmu_chgtype="/sys/class/i2c-adapter/i2c-0/0-0073/pcf50633-mbc/chg_curlim" pmu_chgstate="/sys/devices/platform/s3c2440-i2c/i2c- adapter/i2c-0/0-0073/chgstate" pmu_curlim="/sys/class/i2c-adapter/i2c-0/0-0073/pcf50633-mbc/usb_curlim" pmu_chgfile="/sys/devices/platform/s3c2440-i2c/i2c- adapter/i2c-0/0-0073/force_usb_limit_dangerou bat_status="/sys/class/power_supply/battery/status" bat_capacity="/sys/class/power_supply/battery/capacity" bat_tech="/sys/devices/platform/bq27000-battery.0/power_supply/bat/technology" bat_present="/usr/share/battery/" bat_ttf="/sys/devices/platform/bq27000- battery.0/power_supply/bat/time_to_full_now" bat_tte="/sys/devices/platform/bq27000- battery.0/power_supply/bat/time_to_empty_now" With the current setup I get this error from the script: File not found: /sys/devices/platform/s3c2440-i2c/i2c-adapter/i2c-0/0-0073/chgmode! my guess would be this may be where it should be pointed to the voltage_now file because everything else I was able to match up, but again I'm not quite sure about this. -- "We must plan for freedom, and not only for security, if for no other reason than only freedom can make security more secure." Karl Popper signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
ffalarms 0.2.2 mainly fixes "ffalarms does not start on SHR unstable"
If ffalarms does not start for you displaying exception: ValueError: Ecore_Evas_Engine_Type changed and bindings are now invalid, position 180 is now NULL! Then ffalarms 0.2.2 is a fix for that get it from: http://projects.openmoko.org/frs/?group_id=260 (only Python 2.6 version). Changes: - fix ffalarms not starting due to ecore.evas.engines_get raising ValueError instead of returning True (incompatibility between python-ecore and ecore; thanks to skamster for reporting) - add -E, --engine=x11|x11-16 option - check also for software_16_x11 (new name) apart from software_x11_16 (old name) - fix typo in "Scheduled alarms:" on main screen (thanks to Marcel) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Om2009 testing release 4
Rui Miguel Silva Seabra wrote: > On Thu, May 21, 2009 at 11:33:31PM +0100, Rui Miguel Silva Seabra wrote: >> Problem at Display->Profile: can't get back to illume, illume, paroli >> or paroli-illume all look exactly the same > > Mirko told me all you need is to reboot (first boot problems ... I really > can't understand that) for it to work. I added this to the wiki under known problems. Please check and correct if I've misunderstood. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [shr] feature request - power
On Thu, 21 May 2009 16:19:41 +0200 Johny Tenfinger wrote: > On Thu, May 21, 2009 at 16:09, jeremy jozwik > wrote: > > well nuts to that... > > > > "I can switch them easly... Closing as upstream - looking of > > elementary Toggles depends on elementary theme. If you think > > default elementary theme is bad, please report it on e tracker (or > > develop SHR theme ;) )" > > (that was me who closed that ticket, and i'm main developer of > shr-settings) > > Size of Toggles (that sliders) is equal to size of buttons. So what's > the problem? It only looks thin. I agree on one - we really should > have our own elementary (and e17 at all) theme. But we don't have at > the moment. That's why i closed ticket, as it's not possible to do > easily without breaking everything. I hope you understand :) Question: I've played around with a new Elementary theme, but still don't know the 'right' way to enable it - All I've been able to do is replace /usr/share/elementary/themes/default.edj. If I add (for instance) /usr/share/elementary/themes/serenity.edj, how do I cause it to be used? The theme selection in E config only seems to affect the main E/Illume theme used. j ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [shr] feature request - power
I think the point is that sliders suck: 1. they are very hard to use - unless you have fingers as thin as a stylus. Especially the ones that go close to the screen edge. 2. They are impossible to use whilst walking. 4. They take too long to operate - seem to use a lot of processing as they "hang" for a few seconds part way until the display settles. Basicly, sliders are inappropriate for digital (on/off) values - thats what radio buttons are for. And yes I would love to have the time to figure out how the opaque mess that is e works so I can fix these HCI disasters, at least for myself ... BillK On Thu, 2009-05-21 at 16:19 +0200, Johny Tenfinger wrote: > On Thu, May 21, 2009 at 16:09, jeremy jozwik wrote: > > well nuts to that... > > > > "I can switch them easly... Closing as upstream - looking of elementary > > Toggles depends on elementary theme. If you think default elementary theme > > is bad, please report it on e tracker (or develop SHR theme ;) )" > > (that was me who closed that ticket, and i'm main developer of shr-settings) > > Size of Toggles (that sliders) is equal to size of buttons. So what's > the problem? It only looks thin. I agree on one - we really should > have our own elementary (and e17 at all) theme. But we don't have at > the moment. That's why i closed ticket, as it's not possible to do > easily without breaking everything. I hope you understand :) > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community -- William Kenworthy Home in Perth! ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Om2009 testing release 4
On Thu, May 21, 2009 at 01:34:48PM -0600, Angus Ainslie wrote: > - wanted volunteer to change analog clock to digital I just removed the analog clock, on the paroli-illume profile you still have the nice paroli clock and the analog isn't really very readable for me (due to size). Having a digital clock would be better though, speaking from my SHR tests runs, it's very readable and always present. Paroli's clock, of course, won't waste real estate on other paroli screens, but I still like to always be able to check the time at a glance on the phone, so I'd keep the paroli clock but also would like to have a digital clock on the menu bar. If you want a tester, I'm all for it :) > Ability to cut 30 seconds off boot time > - DO NOT use this if you use bind-home > - install udev-static-devices to get this speed boost > - any solutions on using bind-home and static-devices appreciated This I will do tomorrow. You could, although, just ln -s /media/card/home /home and this shouldn't then be a problem, right? > - suspend fails after a call http://trac.freesmartphone.org/ticket/435 This happened to me with SHR-unstable, and then calls would also be somewhat lost. I could understand a call was being made by the interference with the computer speakers at home, but the phone didn't do anything. I hope it's not the same since this, in effect, makes you loose calls. Rui ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Om2009 testing release 4
On Thu, May 21, 2009 at 11:33:31PM +0100, Rui Miguel Silva Seabra wrote: > Problem at Display->Profile: can't get back to illume, illume, paroli > or paroli-illume all look exactly the same Mirko told me all you need is to reboot (first boot problems ... I really can't understand that) for it to work. Thanks Mirko! :) Rui ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Om2009 testing release 4
Problem at Display->Profile: can't get back to illume, illume, paroli or paroli-illume all look exactly the same On Thu, May 21, 2009 at 01:34:48PM -0600, Angus Ainslie wrote: > Hi All, > > As I think we've fixed more things than we broke it's time for another > testing > release. As usual there are additional instructions here. > > http://wiki.openmoko.org/wiki/Om2009 > > There is also a new page for community involvement. Many of these wishlist > items need someone to implement them. If you are interested in in owning one > of the wishlist items come and join #paroli or send me an email > > http://wiki.openmoko.org/wiki/Om_2009_get_active > > Don't bother trying to do an opkg update opkg upgrade to do the upgrade. > Chances are you won't get the dependencies right ( I know I didn't ). If you > want to preserve your settings use the bind-home method and flash the full > image. > > New in feeds > > callrec > claws-mail > dictator > dillo > midori > mokomaze > omnewrotate > pyring > sms-sentry > webkit-efl > > New features > > Improved call handling - should limit races in oeventsd > Better list handling > More consistent interface > New paroli-illume theme > - only change so far is to remove desktop switcher > - wanted volunteer to change analog clock to digital > - wanted different colour scheme ( maybe white on black to > match the rest of paroli ? ) > Static MAC addresses for usb devices > - usb networking will now show up as ethx on the host side please check > dmesg > on the host side > Ability to cut 30 seconds off boot time > - DO NOT use this if you use bind-home > - install udev-static-devices to get this speed boost > - any solutions on using bind-home and static-devices appreciated > Keyboard goes away after use > Updated /etc/network/interfaces to give USB0 a metric > Added readahead to busybox to test speed increase > > Known issues > > Some oeventsd rules are ignored ( framework oeventsd problems ) > - don't suspend while plugged in > http://trac.freesmartphone.org/ticket/381 > - suspend fails after a call http://trac.freesmartphone.org/ticket/435 > > Bugs fixed > > 1 pixel wide illume exit menu > UTF chars in SMS's > - you must still install a keyboard to be able to write different > character > sets. > Keyboard collapses after use > > Angus > > > > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community -- ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [shr-testing] Forcing fast charge mode
Check out http://wiki.openmoko.org/wiki/GTA02_sysfs#GTA02_Kernel_sysfs_highlights_for_kernel_2.6.28. specifically: charger_type = "/sys/class/i2c-adapter/i2c-0/0-0073/pcf50633-mbc/chg_curlim" #limit that freerunner would accept capacity = "/sys/class/power_supply/battery/capacity" voltage = "/sys/class/power_supply/battery/voltage_now" status = "/sys/class/power_supply/battery/status" image_dir = "/usr/share/battery/" usb_limit = "/sys/class/i2c-adapter/i2c-0/0-0073/pcf50633-mbc/usb_curlim" #current that is actually coming I have attached a modified battery.py for the http://wiki.openmoko.org/wiki/Forcing_fast_charge_mode#The_battery_package. I don't know how to make the package so I guess someone might help here :). BTW, I don't know python...I have updated it by copying the code...so it would be great if someone reviews it before packaging. Moreover, once the information is confirmed we can update http://wiki.openmoko.org/wiki/Forcing_fast_charge_mode with exact paths as well --Vikas > http://wiki.openmoko.org/wiki/Forcing_fast_charge_mode#Beni.27s_fast_charge_gta02.sh > it says that "The /sys paths need to be updated for recent distributions" what > does that mean? If simply editing the shell script will get it working again > I will be happy to do it if I knew what that means. battery.py Description: Binary data ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Solar backpack (Solar charger)
On Thu, 2009-05-21 at 17:48 +0200, David Reyes Samblas Martinez wrote: > search on the list, there was some info on this, and has and here > http://wiki.openmoko.org/wiki/Solar_chargers you will find results on > some models I have tested, very dissapointing all in all. > If you find some model useful let me know Yeah, I have been watching this thread just from beginning. Actually, I have contact the ShenZhen China, and provide some types. And they are NOT as good as you proposed (From spec.) I was thinking about a backpack for a while. As it's useful, when traveling. And It seems that they have solar bag charger for laptop fro advertisement. Well, laptop, I think it's much more powerful. If so, they might be power enough for FR at least. OK, I'm just search this yesterday night and contact them. I have inquiring some spec on their product. And keep thread updated, when I have info. Well, I think it's much more useful than solar charger than you tested. It's really not that convenient when I'm out (biking, mountain climbing). If I carry SC018,SC019,SC20, just waste a lot of time for charging the internal battery. Apparently, I like keep my hands on bike or keep my hands off when climbing :) > > 2009/5/21 Daniel.Li : > > Dear All, > > > > Solar backpack absorbs solar energy and turns it into electric energy > > storing in storage battery. It can charge different specification mobile > > phones through corresponding connectors. > > > > I'm really interested in this. And I think solar backpack is much more > > suitable for emergency situation when there is no electricity > > outdoors.This product is easy to operate ,safe to use ,convenient to > > take and fashionable. > > > > Solar backpack is an ideal product for living and traveling. It's much > > more convenient than solar charger, as I don't wanna hold solar charge > > when I'm biking or mountain climbing :) > > > > What do u think? Any idea or comment on this? > > > > > > http://jdhysm.cn.alibaba.com/athena/offerdetail/sale/jdhysm-1037354-160959215.html > > -- > > Daniel.Li > > PALFocus (http://palfocus.oicp.net) > > > > > > > > ___ > > Openmoko community mailing list > > community@lists.openmoko.org > > http://lists.openmoko.org/mailman/listinfo/community > > > > > -- Daniel.Li PALFocus (http://palfocus.oicp.net) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: linphonec
On Thu, 2009-05-21 at 23:13 +0200, GNUtoo wrote: > On Thu, 2009-05-21 at 23:08 +0200, GNUtoo wrote: > > On Thu, 2009-05-21 at 23:01 +0200, GNUtoo wrote: > > > Hi, > > > I've just bitbaken linphonec and I didn't succeed at making it work > > > I've followed this howto: > > > http://wiki.openmoko.org/wiki/Linphone > > > and I've no sound... > > > Denis. > > > > > > PS: if there are better recipes I'd like to know where to find them > > I think it's my state file > > with the headset I've hashed and incomprehensible audio but I've some > > audio > > Denis. > The strange thing is the CPU usage that is low: less than 40% > Denis. Using GSM codec made it work so I bet it's speex at first I used normal oe recipe but I had: ortp-error-Could not set vbr mode to speex encoder. then I recrosscompiled only speex: EXTRA_OECONF_append_arm = " --enable-fixed-point " instead of: EXTRA_OECONF_append_arm = "--enable-fixed-point --disable-float-api --disable-vbr " quick and dirty hack... now I wonder why speex act like this...should I recompile evrything that depend on speex? Denis. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Om2009 testing release 4
It is a midnight here, but I can't wait till tomorrow... flashing... :) 2009/5/21 Angus Ainslie > Hi All, > > As I think we've fixed more things than we broke it's time for another > testing > release. As usual there are additional instructions here. > > http://wiki.openmoko.org/wiki/Om2009 > > There is also a new page for community involvement. Many of these wishlist > items need someone to implement them. If you are interested in in owning > one > of the wishlist items come and join #paroli or send me an email > > http://wiki.openmoko.org/wiki/Om_2009_get_active > > Don't bother trying to do an opkg update opkg upgrade to do the upgrade. > Chances are you won't get the dependencies right ( I know I didn't ). If > you > want to preserve your settings use the bind-home method and flash the full > image. > > New in feeds > > callrec > claws-mail > dictator > dillo > midori > mokomaze > omnewrotate > pyring > sms-sentry > webkit-efl > > New features > > Improved call handling - should limit races in oeventsd > Better list handling > More consistent interface > New paroli-illume theme >- only change so far is to remove desktop switcher >- wanted volunteer to change analog clock to digital >- wanted different colour scheme ( maybe white on black to >match the rest of paroli ? ) > Static MAC addresses for usb devices >- usb networking will now show up as ethx on the host side please > check dmesg >on the host side > Ability to cut 30 seconds off boot time >- DO NOT use this if you use bind-home >- install udev-static-devices to get this speed boost >- any solutions on using bind-home and static-devices appreciated > Keyboard goes away after use > Updated /etc/network/interfaces to give USB0 a metric > Added readahead to busybox to test speed increase > > Known issues > > Some oeventsd rules are ignored ( framework oeventsd problems ) >- don't suspend while plugged in > http://trac.freesmartphone.org/ticket/381 >- suspend fails after a call > http://trac.freesmartphone.org/ticket/435 > > Bugs fixed > > 1 pixel wide illume exit menu > UTF chars in SMS's >- you must still install a keyboard to be able to write different > character >sets. > Keyboard collapses after use > > Angus > > > > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: linphonec
On May 21, 2009 03:01:48 pm GNUtoo wrote: > Hi, > I've just bitbaken linphonec and I didn't succeed at making it work > I've followed this howto: > http://wiki.openmoko.org/wiki/Linphone > and I've no sound... > Denis. > > PS: if there are better recipes I'd like to know where to find them > Linphone 3 has been in the Om2009 feeds since testing 1 Angus ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Om2009 testing release 4
On May 21, 2009 01:48:44 pm Michael Shiloh wrote: > Angus Ainslie wrote: > > Hi All, > > > > As I think we've fixed more things than we broke it's time for another > > testing release. > > You've only updated the rootfs, right? So no changes in the wifi driver? > > M Right you could try the experimental kernel and modules. Angus ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: linphonec
On Thu, 2009-05-21 at 23:08 +0200, GNUtoo wrote: > On Thu, 2009-05-21 at 23:01 +0200, GNUtoo wrote: > > Hi, > > I've just bitbaken linphonec and I didn't succeed at making it work > > I've followed this howto: > > http://wiki.openmoko.org/wiki/Linphone > > and I've no sound... > > Denis. > > > > PS: if there are better recipes I'd like to know where to find them > I think it's my state file > with the headset I've hashed and incomprehensible audio but I've some > audio > Denis. The strange thing is the CPU usage that is low: less than 40% Denis. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: linphonec
On Thu, 2009-05-21 at 23:01 +0200, GNUtoo wrote: > Hi, > I've just bitbaken linphonec and I didn't succeed at making it work > I've followed this howto: > http://wiki.openmoko.org/wiki/Linphone > and I've no sound... > Denis. > > PS: if there are better recipes I'd like to know where to find them I think it's my state file with the headset I've hashed and incomprehensible audio but I've some audio Denis. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Om2009 testing release 4
fso-paroli-image-om- 8% |*** I'm waiting :) On Thu, May 21, 2009 at 10:58 PM, Risto H. Kurppa wrote: > Awesome Angus & Mirko - can't wait to get testing this :) > > r > > > -- > | risto h. kurppa > | risto at kurppa dot fi > | http://risto.kurppa.fi > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
linphonec
Hi, I've just bitbaken linphonec and I didn't succeed at making it work I've followed this howto: http://wiki.openmoko.org/wiki/Linphone and I've no sound... Denis. PS: if there are better recipes I'd like to know where to find them ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Om2009 testing release 4
Awesome Angus & Mirko - can't wait to get testing this :) r -- | risto h. kurppa | risto at kurppa dot fi | http://risto.kurppa.fi ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [QtExtended] Latest and greatest, progress mail 11
I've been running this build for about a week now, and am pretty happy with it. I installed it on my SD card on top of an OM2009 TR3 install. I don't know if that's an officially supported configuration, but it has seemed to mostly work. The only recurrent problem I've had is that it seems like my battery meter recently started always showing full - I've had the thing run out of battery a couple of times due to this. Now I have to go to the terminal and run apm if I want to know what my actual battery is. However, just in the last couple of hours I've seen a new failure mode - when someone calls my FR I see the standard call indication - but if I click answer, it doesn't actually answer the call - the caller continues to hear ringing and eventually goes to voice mail. The entries I see in logread starting when I get the call look like this: May 23 16:53:04 om-gta02 user.emerg kernel: [65512.07] mapped channel 10 to 2 May 23 16:53:04 om-gta02 user.notice Qtopia: QAudioOutput: snd_pcm_sw_params: err -22 May 23 16:53:05 om-gta02 user.info kernel: [65513.845000] fbcon_event_notify action=12, data=c7a75dac May 23 16:53:05 om-gta02 user.info kernel: [65513.845000] jbt6k74 spi2.0: jbt6k74 unblank May 23 16:53:05 om-gta02 user.info kernel: [65513.87] fbcon_event_notify action=9, data=c7a75de8 May 23 16:53:05 om-gta02 user.info kernel: [65513.87] jbt6k74 spi2.0: jbt6k74 unblank May 23 16:53:26 om-gta02 user.info kernel: [65534.05] fbcon_event_notify action=12, data=c7a75dac May 23 16:53:26 om-gta02 user.info kernel: [65534.05] jbt6k74 spi2.0: jbt6k74 unblank May 23 16:53:26 om-gta02 user.info kernel: [65534.07] fbcon_event_notify action=9, data=c7a75de8 May 23 16:53:26 om-gta02 user.info kernel: [65534.07] jbt6k74 spi2.0: jbt6k74 unblank It's kinda annoying to not be able to answer calls... :-) I'm going to reboot and hope that fixes it. Is it possible this is because I started with the OM2009 TR image, and not the one recommended in the install script? Warren On Sat, May 2, 2009 at 5:49 AM, Franky Van Liedekerke wrote: > New location for the files, watch out! > New install script, watch out! > > (install instructions and script updated on 2090502: see below) > > Problems solved: > > See http://www.e-dynamics.be/openmoko/qt-issues-fixed.txt > > Latest: > - 20090430: deep sleep is now configurable and by default adaptive, see > etc/default/Trolltech/Modem.conf (values: always, adaptive, never) > - 20090502: mplayer frontend from Radek built > - 20090502: VOIP code built > > See http://github.com/liedekef/qtmoko/commits/master for the changes > > Problems found (more like small nuisances now): > === > See http://www.e-dynamics.be/openmoko/qt-issues.txt > > Install instructions: > = > download the script > http://www.e-dynamics.be/openmoko/qtmoko_install.sh , read the > comments at the top and then execute the script on your openmoko (after > having flashed the device and made sure internet works). > The script has 2 options: "install" or "update". An update will just > download the tgz file and replace your current qte with it. > > For those who just want to replace their existing QtE manually, here's > the link: http://www.e-dynamics.be/openmoko/qte_20090502.tgz . > > Enjoy! > > Franky > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > -- Warren Baird - Photographer and Digital Artist http://www.synergisticimages.ca ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Repository management (was: Re: [debian] navit navit_0.1.0+svn-2279_armel.deb)
Am Donnerstag, 21. Mai 2009 21:24:31 schrieb arne anka: > http://www.ginguppin.de/node/26 Thanks! Seeing this - announcing a new package on the ml - I have a few ideas: - Could we have some mailinglist-daemon which sends a list of newly uploaded or updated opkg.org packages maybe once every 24h? - Is is somehow possible (of course it is, but what's the price? ;) ) to have opkg.org be accessible directly via opkg as a repository? - What about a web interface to the fso repo on alioth.debian.org similarly to a synthesis of opkg.org and idea #2? (still requiring a deb package to be lintian clean etc) -- Marcel ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Om2009] testing Release 3: first impressions
Hi, [ still exploring the thing w/o much of a clue... ] On Thu, 21.05.2009 at 17:21:07 +0200, Toni Mueller wrote: > * Illume (Paroli?) should have a "reset to factory setting" option, > so I don't have to re-flash in case I made a mistake. after messing up too much and, as I wrote, having severely misconfigured Illume, after remembering that it's Linux, I opted to delete the .e, .gconf and similar directories, then reboot. This gave me back Paroli, but now I can chose "Illume" in the "display" profile option all day long, and don't ever get back Illume. Another reboot fixed this. > * After several suspend-resume cycles, Enlightenment crashes with a > SEGV. In normal PCs, this suggests a hardware problem (bad ram!) > unless the software is really broken... It also happens w/o several suspend-resume cycles. Will investigate further and hopefully submit a bug report next time. I've now done some tests with a SIM card (T-Mobile), too: * I have trouble answering the calls. Placing calls is easy, though. * On SMS reception, the screen looks rather garbled (imho). Going to Paroli's home screen and to the messages from there is my current workaround. * The "Enter PIN" dialogue should be optional. I'd like to bypass this and be able to activate the SIM card sometime later. * The phonebook ("People") is quite unwieldy, but that has already been noted by someone else. * Now with the card activated, the phone feels quite a bit more sluggish than before. * I need to get the buzz fix. ;} Wishlist: Being able to update to Om2009 final w/o re-flashing. I'm not overly comfortable writing to the mailing list this way, but don't have a better idea, yet. Kind regards, --Toni++ ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Solar backpack (Solar charger)
The panel is too small to generate a reasonable amount of power, even if you were by some chance to spend all your walking/cycling time in direct sunlight, with your back to the sun, leaning forward to keep the panel at right angles to the sun. You can get flexible fold-up panels that could be strapped to the outside of a backpack or paniers, but they work much better when you're stationary and they can be pointed at the sun. For a worthwhile power output they aren't cheap. If you want something effective for emergencies or extended periods away from power a mechanical device is probably more effective. For cycling a good dynamo will provide more, and more reliable, power than any bike-mounted solar panel. Other than that there are some good quality hand cranked generators available, along with a lot of bad ones. There are even a few devices that will take energy from irregular movement, a bit like a self-winding watch. On Thursday 21 May 2009, Daniel.Li wrote: > Dear All, > > Solar backpack absorbs solar energy and turns it into electric energy > storing in storage battery. It can charge different specification mobile > phones through corresponding connectors. > > I'm really interested in this. And I think solar backpack is much more > suitable for emergency situation when there is no electricity > outdoors.This product is easy to operate ,safe to use ,convenient to > take and fashionable. > > Solar backpack is an ideal product for living and traveling. It's much > more convenient than solar charger, as I don't wanna hold solar charge > when I'm biking or mountain climbing :) > > What do u think? Any idea or comment on this? > > > http://jdhysm.cn.alibaba.com/athena/offerdetail/sale/jdhysm-1037354-1609592 >15.html ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Om2009 testing release 4
On Thursday 21 May 2009 20:34:48 Angus Ainslie wrote: > New features > > Improved call handling - should limit races in oeventsd > Better list handling > More consistent interface > New paroli-illume theme > - only change so far is to remove desktop switcher > - wanted volunteer to change analog clock to digital > - wanted different colour scheme ( maybe white on black to > match the rest of paroli ? ) Just a thought but would the serenity theme do perhaps? It has a white on black Illume bar at least. solar.george signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Om2009 testing release 4
Angus Ainslie wrote: > Hi All, > > As I think we've fixed more things than we broke it's time for another > testing > release. You've only updated the rootfs, right? So no changes in the wifi driver? M ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Om2009 testing release 4
Congratulations! I'm downloading right now and will report back. I'm very impressed with the rate of revisions. Michael Shiloh Angus Ainslie wrote: > Hi All, > > As I think we've fixed more things than we broke it's time for another > testing > release. As usual there are additional instructions here. > > http://wiki.openmoko.org/wiki/Om2009 > > There is also a new page for community involvement. Many of these wishlist > items need someone to implement them. If you are interested in in owning one > of the wishlist items come and join #paroli or send me an email > > http://wiki.openmoko.org/wiki/Om_2009_get_active > > Don't bother trying to do an opkg update opkg upgrade to do the upgrade. > Chances are you won't get the dependencies right ( I know I didn't ). If you > want to preserve your settings use the bind-home method and flash the full > image. > > New in feeds > > callrec > claws-mail > dictator > dillo > midori > mokomaze > omnewrotate > pyring > sms-sentry > webkit-efl > > New features > > Improved call handling - should limit races in oeventsd > Better list handling > More consistent interface > New paroli-illume theme > - only change so far is to remove desktop switcher > - wanted volunteer to change analog clock to digital > - wanted different colour scheme ( maybe white on black to > match the rest of paroli ? ) > Static MAC addresses for usb devices > - usb networking will now show up as ethx on the host side please check > dmesg > on the host side > Ability to cut 30 seconds off boot time > - DO NOT use this if you use bind-home > - install udev-static-devices to get this speed boost > - any solutions on using bind-home and static-devices appreciated > Keyboard goes away after use > Updated /etc/network/interfaces to give USB0 a metric > Added readahead to busybox to test speed increase > > Known issues > > Some oeventsd rules are ignored ( framework oeventsd problems ) > - don't suspend while plugged in > http://trac.freesmartphone.org/ticket/381 > - suspend fails after a call http://trac.freesmartphone.org/ticket/435 > > Bugs fixed > > 1 pixel wide illume exit menu > UTF chars in SMS's > - you must still install a keyboard to be able to write different > character > sets. > Keyboard collapses after use > > Angus > > > > > ___ > devel mailing list > de...@lists.openmoko.org > https://lists.openmoko.org/mailman/listinfo/devel > ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Om2009 testing release 4
Hi All, As I think we've fixed more things than we broke it's time for another testing release. As usual there are additional instructions here. http://wiki.openmoko.org/wiki/Om2009 There is also a new page for community involvement. Many of these wishlist items need someone to implement them. If you are interested in in owning one of the wishlist items come and join #paroli or send me an email http://wiki.openmoko.org/wiki/Om_2009_get_active Don't bother trying to do an opkg update opkg upgrade to do the upgrade. Chances are you won't get the dependencies right ( I know I didn't ). If you want to preserve your settings use the bind-home method and flash the full image. New in feeds callrec claws-mail dictator dillo midori mokomaze omnewrotate pyring sms-sentry webkit-efl New features Improved call handling - should limit races in oeventsd Better list handling More consistent interface New paroli-illume theme - only change so far is to remove desktop switcher - wanted volunteer to change analog clock to digital - wanted different colour scheme ( maybe white on black to match the rest of paroli ? ) Static MAC addresses for usb devices - usb networking will now show up as ethx on the host side please check dmesg on the host side Ability to cut 30 seconds off boot time - DO NOT use this if you use bind-home - install udev-static-devices to get this speed boost - any solutions on using bind-home and static-devices appreciated Keyboard goes away after use Updated /etc/network/interfaces to give USB0 a metric Added readahead to busybox to test speed increase Known issues Some oeventsd rules are ignored ( framework oeventsd problems ) - don't suspend while plugged in http://trac.freesmartphone.org/ticket/381 - suspend fails after a call http://trac.freesmartphone.org/ticket/435 Bugs fixed 1 pixel wide illume exit menu UTF chars in SMS's - you must still install a keyboard to be able to write different character sets. Keyboard collapses after use Angus ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [GPS] new GPS GUI application for OM freerunner
mqy wrote: > Hi all: > > I got my gta02 freerunner on DEC 2008. > After nearly 5 months development, I'm happy to announce the first alpha > release of omgps. > > It is not as feature rich as other GPS applications, such as tangoGPS, > anyway I think it should satisfy most of > the daily needs. Please goto http://code.google.com/p/omgps/, download and > give a try. > > After ten years of programming as a web developer for most of the time, now > I join the community with my little gift :) Thanks you to open source > community -- for your great works and spirits. > Your application is definitely good one and worth using it all the time. But what prevents from using it for now is why is it *so* slow while dragging the screen or zooming? Well. May be it is not. But in TangoGPS it just moves the screen, when u drag with a finger and then loads PNG so it looks like response(somehow). And in omgps I feel like it hangs for certain amount of time. Another question. Why did you limit the number of GPX traces? Why just not to go unlimited? There is also a repo in TangoGPS called googlesat, which is better than YahooSat in quality. Can it be added? Or could instructions for adding it to omgps be posted? Thank you for improved GPS handling in FreeRunner! Now we have something to compete with TangoGPS. signature.asc Description: OpenPGP digital signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
[debian] navit navit_0.1.0+svn-2279_armel.deb
http://www.ginguppin.de/node/26 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: LCD Displays?
On Thu, May 21, 2009 at 12:37 PM, Al Johnson wrote: > On Thursday 21 May 2009, zogg wrote: >> Thats intresting. What could have stopped them from making it >> non-monochrome in daylight? > > Probably cost and efficiency as these were major factors in OLPC. If PixelQi > don't start producing screens that are colour in daylight then I guess there's > a technical reason as well. Based on the explanation below I would have > thought adding the coloured filters between the LCD and the reflective layer > would drop backlight efficiency only a little since the prism has already > split the light, but I'm no expert. The extra component requiring precision > placement would add cost though. That's a good idea actually, and might just work. (!) --tim ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: LCD Displays?
On Thu, May 21, 2009 at 10:01 AM, zogg wrote: > Thats intresting. What could have stopped them from making it > non-monochrome in daylight? It's not possible, as light coming from the front of the LCD will have to pass through the prism in the wrong direction in order to be reflected back through the prism. The split light would then not line up with the pixel boundaries. --tim ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Om2009] testing Release 3: first impressions
On May 21, 2009 10:46:54 am Toni Mueller wrote: > There was a dialogue in Paroli where I could adjust the time. There, I > entered the time according to my local time zone, being unaware of the > network time stuff. But I'd prefer to configure an /etc/localtime, like > in any other *nix, too. Doing it in frameworkd.conf should work, too. > You need to *copy* in the correct zone file from user share zones and set set zonesources to NONE. If you don't set zonesources then as soon as you add a SIM card the zone will get set from the GSM network Angus ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [shr-testing] Forcing fast charge mode
On Thursday 21 May 2009 06:15:33 am Risto H. Kurppa wrote: > On Thu, May 21, 2009 at 1:06 PM, Leonardo de Virgilio > > wrote: > > Great link r.h.k.!! > > I've waited for fast-charging mode on new kernel for months!! > > I'll try today ;) > > It'd be great if someone had the energy to update > http://wiki.openmoko.org/wiki/Forcing_fast_charge_mode#The_battery_package > - it's a great tool to manage the recharge status & monitor the > charging. it's only a simple .py with the paths nicely listed -> not > too hard to do but a package would be nice (or just a new .py with > updated paths) > There is already a thread about this yay! Anyways I stumbled upon that page and I thought that it would come in handy, I am about to go on a trip and being able to for my FR to pull more power through USB would be handy. Am I correct in understanding that the solutions on this page are currently broken, take this one for example http://wiki.openmoko.org/wiki/Forcing_fast_charge_mode#Beni.27s_fast_charge_gta02.sh it says that "The /sys paths need to be updated for recent distributions" what does that mean? If simply editing the shell script will get it working again I will be happy to do it if I knew what that means. -- "We must plan for freedom, and not only for security, if for no other reason than only freedom can make security more secure." Karl Popper signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [OT] Is Android really free? (was Re: root almighty)
GNUtoo wrote: > > > There is something stopping people from contributing: > make: *** No rule to make target `run-java-tool', needed by > `out/host/common/obj/JAVA_LIBRARIES/droiddoc_intermediates/javalib.jar'. > Stop. > what should I do? > > PS: I've some java warnings etc...I hope it's not the fault of > icedtea/openjdk > > I'm not familiar with that particular situation, though someone on the just posted some generic build instructions, which might be useful so I'll repost it - Marcelo wrote: > > > Go to: http://git.koolu.org/ > > Follow the instructions there to checkout the code. > > Go to http://trac.koolu.org/ and follow the rest of the instructions. > > Basically: > > $ mkdir -p ~/bin > $ curl http://android.git.kernel.org/repo > ~/bin/repo > $ chmod a+x ~/bin/repo > $ mkdir ~/mydroid > $ cd ~/mydroid > $ repo init -u git://git.koolu.org/freerunner/platform/manifest.git -b > koolu-1.0 > $ repo sync > $ make TARGET_PRODUCT=freerunner > > replace "koolu-1.0" by whatever branch you wish to work on (look at > the git repo to find out which ones are available) > > Since you need that TARGET_PRODUCT variable always, I find it better to do > this: > > $ cat > buildspec.mk > TARGET_PRODUCT := freerunner > ^D > $ make > > If you wish to switch a branch, do > > $ repo init -b new_branch > $ repo sync > > (and likely rm -rf out) > > Marcelo > -- View this message in context: http://n2.nabble.com/-OT--Is-Android-really-free--%28was-Re%3A-root-almighty%29-tp2943035p2953292.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Om2009] testing Release 3: first impressions
Hi Angus, On Thu, 21.05.2009 at 10:03:50 -0600, Angus Ainslie wrote: > The time gets updated from the network NTP, I assume? That'd be very much ok. > Thats paroli talking to the frame work before the framework is ready to > respond. Ok. > I'd prefer digital too and maybe even white on black to match the rest of > paroli. Send a patch for the paroli-illume profile and I'll integrate it. In Paroli, it's white on black, but in Illume, the top bar is light grey. There, it should probably be black on white for that reason. > > * I have yet to find out how to rotate the screen on demand. > xrandr Thank you. I guess that someone should appropriately augment the "Getting Started" page in the wiki to explain the different GUIs, along with screenshots/photos. Taking note do do that at some point... > Instead of configuring it for locatime you should set the correct localtime > file > and set ZONESOURCES=NONE in /etc/frameworkd.conf There was a dialogue in Paroli where I could adjust the time. There, I entered the time according to my local time zone, being unaware of the network time stuff. But I'd prefer to configure an /etc/localtime, like in any other *nix, too. Doing it in frameworkd.conf should work, too. Thank you for your hand-holding. Kind regards, --Toni++ ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [OT] Is Android really free? (was Re: root almighty)
> You instinctively decide to hate it due to some features you don't like > (which are aimed at supporting proprietary apps, and you're free to disable > in your version, or just not use those apps). There's nothing stopping > people from releasing android apps as FOSS. personally I really like the > idea of paying for apps from an app store if I choose to, or using/writing > free ones if I don't. There is something stopping people from contributing: make: *** No rule to make target `run-java-tool', needed by `out/host/common/obj/JAVA_LIBRARIES/droiddoc_intermediates/javalib.jar'. Stop. what should I do? PS: I've some java warnings etc...I hope it's not the fault of icedtea/openjdk Denis. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Om2009] testing Release 3: first impressions
Hi, some more breakage, may be unrelated to Om2009, though... I've managed to mangle my menues, so now I can't get at the settings anymore, and the Terminal is also gone. I don't remember being able to completely disable suspend, and my micro SD card seems to be not properly recognized. At least, I get this: r...@om-gta02:~#fdisk -l /dev/mmcblk0 Disk /dev/mmcblk0: 7969 MB, 7969177600 bytes 255 heads, 63 sectors/track, 968 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/mmcblk0p1 1 33 265041 83 Linux /dev/mmcblk0p2 34 66 265072+ 82 Linux swap /dev/mmcblk0p3 67 968 7245315 5 Extended /dev/mmcblk0p5 67 193 1020096 83 Linux /dev/mmcblk0p6 194 320 1020096 83 Linux /dev/mmcblk0p7 321 447 1020096 83 Linux /dev/mmcblk0p8 448 968 4184901 83 Linux r...@om-gta02:~# mount rootfs on / type rootfs (rw) /dev/root on / type jffs2 (rw,noatime) proc on /proc type proc (rw) sysfs on /sys type sysfs (rw) /dev/root on /dev/.static/dev type jffs2 (rw) udev on /dev type tmpfs (rw,size=2048k,mode=755) /dev/mmcblk0p7 on /media/mmcblk0p7 type ext3 (rw,sync,errors=continue,data=ordered) /dev/mmcblk0p1 on /media/card type ext3 (rw,errors=continue,data=ordered) /dev/mmcblk0p5 on /media/mmcblk0p5 type ext3 (rw,sync,errors=continue,data=ordered) /dev/mmcblk0p6 on /media/mmcblk0p6 type ext3 (rw,sync,errors=continue,data=ordered) tmpfs on /var/volatile type tmpfs (rw,mode=755) tmpfs on /dev/shm type tmpfs (rw,mode=777) devpts on /dev/pts type devpts (rw,gid=5,mode=620) I didn't do anything - don't know how the partitions got mounted, BUT r...@om-gta02:~# mkdir data r...@om-gta02:~# mount /dev/mmcblk0p8 data mount: special device /dev/mmcblk0p8 does not exist r...@om-gta02:~# mkfs.ext3 /dev/mmcblk0p8 mke2fs 1.38 (30-Jun-2005) Could not stat /dev/mmcblk0p8 --- No such file or directory The device apparently does not exist; did you specify it correctly? I did have some unclean shutdowns, though... IOW, the second half of my 8 gig card which I wanted to use for maps and other data that is not OS specific and uses large amounts of storage, is always available. One more problem: Once the X server crashes, there's apparently NO way to restart it w/o having at least an SSH connection to the device, or the device rebooted. There should be an easier way, imho. Kind regards, --Toni++ ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Om2009] testing Release 3: first impressions
On May 21, 2009 09:21:07 am Toni Mueller wrote: > Hi, > > On Wed, 20.05.2009 at 04:24:33 -0400, Mirko Lindner wrote: > > Toni Mueller wrote: > >> I thought I'd just throw my 0.02 cents into the arena. ;} > > > > Yeah, we want it all :) > > while flashing moko11 I've just discovered that Paroli doesn't let me > set the date, but only the time. For some obscure reason, after a > reboot (all w/o a GSM SIM card), the date was magically adjusted from > May 9th to today. > The time gets updated from the network > > Other things that I'd change if I were able to, off the top of my head: > > > * I still happen to not understand Paroli's UI. The battery looks like > being empty in Paroli, but full in Illume. > Thats paroli talking to the frame work before the framework is ready to respond. > * There's a strange icon to the left of the battery that doesn't say > what it is, nor what it wants to "tell me". > GSM signal level > * The minuscule analog clock doesn't really serve a purpose, imho. It'd > be better to either (configurably) replace it by a digital clock, > and/or maximize it when activated, like any other application, too. > I'd prefer digital too and maybe even white on black to match the rest of paroli. Send a patch for the paroli-illume profile and I'll integrate it. > > * I have yet to find out how to rotate the screen on demand. > xrandr > * Suspend should be configurable to not being activated while on USB > power. It's annoying to me that the device always goes to sleep, > and consequently, my SSH connection goes down, while I'm looking > something up in the wiki or elsewhere. It should not suspend while plugged in. But there is a race condition in framework that those rules don't get properly applied sometimes. What sometimes works is to unplug the usb cable until the LED goes out and then plug it back in. I should not suspend after that point > > * After several reboots, the time has now been turned backwards for > well over an hour. The difference is small enough to suggest to me > that maybe the device displays what it thinks is UTC instead of local > time (which I configured). > Instead of configuring it for locatime you should set the correct localtime file and set ZONESOURCES=NONE in /etc/frameworkd.conf Angus ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Solar backpack (Solar charger)
search on the list, there was some info on this, and has and here http://wiki.openmoko.org/wiki/Solar_chargers you will find results on some models I have tested, very dissapointing all in all. If you find some model useful let me know 2009/5/21 Daniel.Li : > Dear All, > > Solar backpack absorbs solar energy and turns it into electric energy > storing in storage battery. It can charge different specification mobile > phones through corresponding connectors. > > I'm really interested in this. And I think solar backpack is much more > suitable for emergency situation when there is no electricity > outdoors.This product is easy to operate ,safe to use ,convenient to > take and fashionable. > > Solar backpack is an ideal product for living and traveling. It's much > more convenient than solar charger, as I don't wanna hold solar charge > when I'm biking or mountain climbing :) > > What do u think? Any idea or comment on this? > > > http://jdhysm.cn.alibaba.com/athena/offerdetail/sale/jdhysm-1037354-160959215.html > -- > Daniel.Li > PALFocus (http://palfocus.oicp.net) > > > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > -- David Reyes Samblas Martinez http://www.tuxbrain.com Open ultraportable & embedded solutions Openmoko, Openpandora, Arduino Hey, watch out!!! There's a linux in your pocket!!! ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [shr-testing] Forcing fast charge mode
On Thu, May 21, 2009 at 6:15 AM, Risto H. Kurppa wrote: > On Thu, May 21, 2009 at 1:06 PM, Leonardo de Virgilio > wrote: >> Great link r.h.k.!! >> I've waited for fast-charging mode on new kernel for months!! >> I'll try today ;) >> > > It'd be great if someone had the energy to update > http://wiki.openmoko.org/wiki/Forcing_fast_charge_mode#The_battery_package > - it's a great tool to manage the recharge status & monitor the > charging. it's only a simple .py with the paths nicely listed -> not > too hard to do but a package would be nice (or just a new .py with > updated paths) > > r I agree, the battery package is quite nice. Though if you are just looking for fast-charge control for when using dumb chargers, the basics have already been added to the Battery module for shr-settings. It's in the git repo [1], and potentially buggy, but I was running it fine with my car charger all weekend on a road trip. Just replace the existing file in /usr/lib/python2.6/site-packages/shr_settings_modules/ and restart shr-settings. Beware: it may upset your cat, not work, or attract polar bears so use with understanding, and backup your original before overwriting [1] http://git.shr-project.org/git/?p=shr-settings.git;a=blob_plain;f=shr_settings_modules/shr_battery.py;hb=HEAD ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [shr-testing] Forcing fast charge mode
I don't want to say that before trying I was sceptic, but now I can confirm: I've tried, IT WORKS!! :D My personal way to make it handly, is creating a .desktop file in /usr/share/applications with the "exec" like the before mentioned command. I think this should be inserted (without difficulty) as a "button" in SHR power-menu. Thanks again :D 2009/5/21 Risto H. Kurppa > On Thu, May 21, 2009 at 11:35 AM, Vikas Saurabh > wrote: > > > > > > On Wed, May 20, 2009 at 5:09 PM, Vikas Saurabh > wrote: > >> > >> I have recently flashed shr-testing and was wondering if the fast charge > information available here [ > http://wiki.openmoko.org/wiki/Forcing_fast_charge_mode] is still usable? > Or is there some FSO API that I have missed? > > I just updated it yesterday, the apps there use old paths -> don't > work. The paths to use now are listed in > > http://wiki.openmoko.org/wiki/Forcing_fast_charge_mode#OM2009_.26_Freerunner > - I'd think SHR uses the same.. > > Feel free to update the apps to work.. > > r > > > > > -- > | risto h. kurppa > | risto at kurppa dot fi > | http://risto.kurppa.fi > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Om2009] testing Release 3: first impressions
Hi, On Wed, 20.05.2009 at 04:24:33 -0400, Mirko Lindner wrote: > Toni Mueller wrote: >> I thought I'd just throw my 0.02 cents into the arena. ;} > Yeah, we want it all :) while flashing moko11 I've just discovered that Paroli doesn't let me set the date, but only the time. For some obscure reason, after a reboot (all w/o a GSM SIM card), the date was magically adjusted from May 9th to today. Other things that I'd change if I were able to, off the top of my head: * I still happen to not understand Paroli's UI. The battery looks like being empty in Paroli, but full in Illume. * There's a strange icon to the left of the battery that doesn't say what it is, nor what it wants to "tell me". * I generally like Illume better, but would like the Illume task bar (?) to vanish unless used. * The minuscule analog clock doesn't really serve a purpose, imho. It'd be better to either (configurably) replace it by a digital clock, and/or maximize it when activated, like any other application, too. * I'd like to freely configure the selection and order of apps in that task bar, and probably have bigger arrows to press, owing to my fat fingers. Btw, I've just gotten an "Enlightenment Error", SEGV. * Illume (Paroli?) should have a "reset to factory setting" option, so I don't have to re-flash in case I made a mistake. * I have yet to find out how to rotate the screen on demand. * Suspend should be configurable to not being activated while on USB power. It's annoying to me that the device always goes to sleep, and consequently, my SSH connection goes down, while I'm looking something up in the wiki or elsewhere. * After several reboots, the time has now been turned backwards for well over an hour. The difference is small enough to suggest to me that maybe the device displays what it thinks is UTC instead of local time (which I configured). * After several suspend-resume cycles, Enlightenment crashes with a SEGV. In normal PCs, this suggests a hardware problem (bad ram!) unless the software is really broken... I know that asking for wishes and not doing anything is rather cheap... > Hit the topbar (the small clock the the top of the screen) that should > always get you back to the homescreen. I've been able to pinpoint this a bit more. Running w/o a GSM SIM card, I've entered the dialer in Paroli, typed a number, and then pressed "Call". Naturally, no call was placed, but after that, I couldn't go back to the main Paroli screen anymore. And one OT remark: Often, bug numbers are slung around. It would be good to have either full bug URLs for the various trackers used, and/or shortcuts in the Wiki that would redirect properly edited bug numbers to the right tracker. Eg. the user types "shr:#123", and the wiki redirects one to the corresponding tracker entry in the SHR tracker (hypothetical example, but you get the idea). So far, I'm often a bit at a loss as to which bug trackers (and where) are actually implied if I see a bug number. Kind regards, --Toni++ ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [android] new cupcake image
Russell Hay writes: > > 2009/5/20 Russell Dwiggins > >> >> I'm wondering if it has something to do with the partitioning of the SD >> card? The wiki confused me because it instructs one to fdisk the card with >> 2 linux partitions (83), then format one with FAT and one with ext3. I >> fdisked the fat partition with vfat (0b) and formatted with vfat, could >> that >> be the problem? >> > In case you've not seen it, here's the video and the flashing instructions.. > http://www.newlc.com/en/freerunner-mobile-which-support-android-cupcake The resulting partitioning should look like unless you wouldn't be sure : # sudo parted -s /dev/sdc print Model: Generic STORAGE DEVICE (scsi) Disk /dev/sdc: 2033MB Sector size (logical/physical): 512B/512B Partition Table: msdos Number Start End SizeType File system Flags 1 3584B 128MB 128MB primary fat16lba 2 128MB 256MB 128MB primary ext3 3 256MB 2033MB 1777MB primary fat16lba Hope this helps, -- Olivier BERGER (OpenPGP: 1024D/B4C5F37F) http://www.olivierberger.com/weblog/ ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [GPS] new GPS GUI application for OM freerunner
It's the two sides of a coin. It's not a good idea to suppose something that we are not sure, right? Let me explain. 1. Think about app A save it's maps to dir_a, app B save it's maps to dir_b, and c, d... What about when the "default" one changes it's directory? 2. soft link is the best choice. If you suddenly flashed a new image, and forgot to backup, the MicroSD partition saves you time and energy. If the Os can't boot, you can still read/backup data from MicroSD. I did not suppose user is root at all, even though we are all roots, that's why I soft link *.py to $HOME/.omgps/, because compiled python binary file is saved to the directory which contains the source *.py module. Risto H. Kurppa wrote: > > On Thu, May 21, 2009 at 11:54 AM, arne anka wrote: >>> Looks great but PLEASE use /home/root/Maps to store map tiles -> share >>> with Tangogps... right..? >> >> NO! >> please, use $HOME/... >> this "we're all root!" madness has to stop -- and hardcoding paths like >> that is really bad anyway. > > Oops, sorry, you're right :) But anyway I think it'd be great to use > the same folder that Tangogps uses ($HOME/Maps) -> I have some 300 000 > png tiles there, it's just waste of space, bandwith and time to > download separate files for both - and if/since everyone will symlink, > why not do it by default.. > > > r > > -- > | risto h. kurppa > | risto at kurppa dot fi > | http://risto.kurppa.fi > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > > -- View this message in context: http://n2.nabble.com/-GPS--new-GPS-GUI-application-for-OM-freerunner-tp2948257p2952293.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [shr] feature request - power
thats better. more explanation to a reason is vastly better than just saying... make your own theme. its not entirely the thinness of the buttons but the overall process of actually switching it. ive tried all the settings in elementary in regards to finger scrolling and nothing seems to improve the feedback or responsiveness of dragging that little switch. even on different versions of shr, i personally believe it would just be simplier as a on/off toggle. maybe thats just me? i would think that would not require a rebuild of a theme, just what icon is displayed for the setting. if its an issue no one else cares about then could you point me in the direction of how to just switch that UI element to a button rather then a slider. right now i have no idea how most of the ui coding is acheived. On Thu, May 21, 2009 at 7:19 AM, Johny Tenfinger wrote: > On Thu, May 21, 2009 at 16:09, jeremy jozwik > wrote: > > well nuts to that... > > > > "I can switch them easly... Closing as upstream - looking of elementary > > Toggles depends on elementary theme. If you think default elementary > theme > > is bad, please report it on e tracker (or develop SHR theme ;) )" > > (that was me who closed that ticket, and i'm main developer of > shr-settings) > > Size of Toggles (that sliders) is equal to size of buttons. So what's > the problem? It only looks thin. I agree on one - we really should > have our own elementary (and e17 at all) theme. But we don't have at > the moment. That's why i closed ticket, as it's not possible to do > easily without breaking everything. I hope you understand :) > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: [OT] Is Android really free? (was Re: root almighty)
jldominguez wrote: > > Hello, is it true that Google can uninstall an app not approved by > themselves (that is, an app not included in the 'Android Market')? I > understand the app would be uninstalled when the user visits a Google shop > or accesses a Google service? > It's not true that any non-approved app would be uninstalled as soon as the user visits the market, that's a little bit too Apple-ish. The App store is not the only place that you can get software. However there does seem to be a "kill switch" that would enable google to disable specific applications. IMHO this is another good reason to run it on FR instead of G1 or other closed handset though, as this capability can be discovered and disabled in the source tree. -- View this message in context: http://n2.nabble.com/-OT--Is-Android-really-free--%28was-Re%3A-root-almighty%29-tp2943035p295.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Solar backpack (Solar charger)
Dear All, Solar backpack absorbs solar energy and turns it into electric energy storing in storage battery. It can charge different specification mobile phones through corresponding connectors. I'm really interested in this. And I think solar backpack is much more suitable for emergency situation when there is no electricity outdoors.This product is easy to operate ,safe to use ,convenient to take and fashionable. Solar backpack is an ideal product for living and traveling. It's much more convenient than solar charger, as I don't wanna hold solar charge when I'm biking or mountain climbing :) What do u think? Any idea or comment on this? http://jdhysm.cn.alibaba.com/athena/offerdetail/sale/jdhysm-1037354-160959215.html -- Daniel.Li PALFocus (http://palfocus.oicp.net) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [shr] feature request - power
On Thu, May 21, 2009 at 16:09, jeremy jozwik wrote: > well nuts to that... > > "I can switch them easly... Closing as upstream - looking of elementary > Toggles depends on elementary theme. If you think default elementary theme > is bad, please report it on e tracker (or develop SHR theme ;) )" (that was me who closed that ticket, and i'm main developer of shr-settings) Size of Toggles (that sliders) is equal to size of buttons. So what's the problem? It only looks thin. I agree on one - we really should have our own elementary (and e17 at all) theme. But we don't have at the moment. That's why i closed ticket, as it's not possible to do easily without breaking everything. I hope you understand :) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [GPS] new GPS GUI application for OM freerunner
1. "Center" button is not "auto center" which waste power -- that's on each update, if the screen distance between new position and previous one greater than (say 5 pixels), the position is redrawn. As of "auto center", the whole map must be updated, that's really a waste. 2. Each time you press the "Center" button, it switch to "keep location in view" mode. In this mode, if you don't pan (drag) map, it keeps the location(position) in view, else the view back layers are not updated. About the foot: it means tracking. By default on each start the tracking is not enabled, so the image is a foot with "x" on means tracking is disabled now. If you start tracking, the image is updated to another foot without "x" sign on it. William Kenworthy wrote: > > On Thu, 2009-05-21 at 08:52 +0200, David Reyes Samblas Martinez wrote: >> Nice app :) >> I know it should be no easy, but a feature that I miss both in Tango >> and this is the ability to rotate the maps accordingly the direction > > I am still waiting for gps lock (actually just got it ... in the > office :), but it looks nice so far. symlinking the map directory to > the tangogps store works fine. > > One thing that all gps apps I see on the FR so far do is centre the > cursor/position. Thats fine when standing still, but I am not really > interested in where I have been, but where I am going so it would be > nice if the cursor/centre of the display was offset appropriately. > > Can someone tell me: > what the "foot" with a red cross through it means - doesnt seem to do > anything. > and similarly, the two diagonal opposing arrows next to it. > > BillK > > > > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > > -- View this message in context: http://n2.nabble.com/-GPS--new-GPS-GUI-application-for-OM-freerunner-tp2948257p2952181.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: [Om2009] testing Release 3: first impressions
Hi, I decided I'd try to start using om2009 as my daily phone to help test it out. Here are a few of my comments (some I'm sure have been mentioned before) 1.) I really like the paroli look/interface! It is simple, responsive, and the contrast makes it easy to see. 2.) If you rotate the screen orientation, the main menu for paroli does not resize well. Other parts, (the dialer for instance) work fine rotated though. 3.) This is a big one for me: When someone sends me a text message, the number does not get looked up in the addressbook. The lookup works fine when someone calls me, but not when an sms comes in. I just see the number instead of the name. 4.) The "people" page needs to jump to the first contact that starts with a letter typed. I have hundreds of contacts, and scrolling through them to find someone is a royal pain. If I could jump to a letter, that would be great. I'll continue testing it and comment about anything else I see, but so far I really like it! Good job guys! -Dan Staley ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [GPS] new GPS GUI application for OM freerunner
you might want to add it on opkg.org maybe On Thu, May 21, 2009 at 11:37 AM, David Reyes Samblas Martinez wrote: > 2009/5/21 Risto H. Kurppa : >> On Thu, May 21, 2009 at 11:54 AM, arne anka wrote: Looks great but PLEASE use /home/root/Maps to store map tiles -> share with Tangogps... right..? >>> >>> NO! >>> please, use $HOME/... >>> this "we're all root!" madness has to stop -- and hardcoding paths like >>> that is really bad anyway. >> >> Oops, sorry, you're right :) But anyway I think it'd be great to use >> the same folder that Tangogps uses ($HOME/Maps) -> I have some 300 000 >> png tiles there, it's just waste of space, bandwith and time to >> download separate files for both - and if/since everyone will symlink, >> why not do it by default.. > Good point, just check in if the direrectory exist if true symlink if > not create it. >> >> >> r >> >> -- >> | risto h. kurppa >> | risto at kurppa dot fi >> | http://risto.kurppa.fi >> >> ___ >> Openmoko community mailing list >> community@lists.openmoko.org >> http://lists.openmoko.org/mailman/listinfo/community >> > > > > -- > David Reyes Samblas Martinez > http://www.tuxbrain.com > Open ultraportable & embedded solutions > Openmoko, Openpandora, Arduino > Hey, watch out!!! There's a linux in your pocket!!! > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: [OT] Is Android really free? (was Re: root almighty)
> No, they really aren't. You can download > and install stuff from outside the > approved store on commercial android handsets Hello, is it true that Google can uninstall an app not approved by themselves (that is, an app not included in the 'Android Market')? I understand the app would be uninstalled when the user visits a Google shop or accesses a Google service? Regards, Juan Lucas De: community-boun...@lists.openmoko.org en nombre de Gothnet Enviado el: jue 21/05/2009 15:53 Para: community@lists.openmoko.org Asunto: Re: [OT] Is Android really free? (was Re: root almighty) Ignacio Torres Masdeu wrote: > > >> in fact there is a lot of closed linux devices out there , for example >> routers,motorola phones, ebook reader... and those doesn't mean Linux >> is closed, > > It only means that if they don't publish the code, and that's usual, > they are violating the GPL. http://gpl-violations.org/ > > Not necessarily. They don't have to provide any mechanism to re-flash the device, then the linux based device is just as closed, even when they publish the source. GPL does not protect against this (v3 might, not sure). Ignacio Torres Masdeu wrote: > > > The problem with Android is not the license of the OS, but the > "ecosystem" around it. Closed hardware, DRMd content (applications, > music), the restrictions imposed on the OS by cell companies... it's a > nightmare, and the freedom of the user doesn't even appear in the > horizon. > It's BSD style FOSS. Anyone can do what they like with it. The fact that others can close their versions doesn't detract from that. If you want to argue that it loses flexibility as a platfor, when you're using a self- or community-compiled version, then sure. Ignacio Torres Masdeu wrote: > > I have strong feelings against Android, for the restrictions around it > are very similar to those of the iPhone, though Apple doesn't try to > disguise themselves as "open source paladins". > No, they really aren't. You can download and install stuff from outside the approved store on commercial android handsets and on free/open ones ones (Android on FR) you have full control, including the full source under APL2. You just try getting the source from Apple and running it somewhere else. Ignacio Torres Masdeu wrote: > > Android, as a platform (not an OS, not a device) is worst than closed, > for it lures developers with the false concept of an open environment. > Yes, just like the entire BSD operating system! It's a trap! *facepalm* Ignacio Torres Masdeu wrote: > > Yes, people could fork and create gAndroid but where would they run > it? It's a wolf with a lamb skin, > Why fork when you can port? There are several places doing just that and re-submitting upstream when they have good results. It's being ported to some nokia devices, netbooks, FR etc. And why is it a wolf in lambs skin? I mean, what the hell are you talking about at this point? Where would they run what? Ignacio Torres Masdeu wrote: > > And my last rant. Why did they create yet another isolated platform? > For f*cks sake! It's not even standard java! At least Objective-C > builds on top of C! Couldn't they create a set of libraries? Or use if > they wanted portability use Python? Argh! > > My 2 cents > Java is the most popular language on the planet right now, more people know it than know pretty much anything else going. Attracting developers is essential to the success of the platform. W
Re: [shr] feature request - power
well nuts to that... "I can switch them easly... Closing as upstream - looking of elementary Toggles depends on elementary theme. If you think default elementary theme is bad, please report it on e tracker (or develop SHR theme ;) )" On Wed, May 20, 2009 at 6:20 PM, jeremy jozwik wrote: > thanks for that link. sent it on its merry way > > On Wed, May 20, 2009 at 5:50 PM, Adam Jimerson wrote: > >> On Wednesday 20 May 2009 06:56:14 pm jeremy jozwik wrote: >> > not sure if this is the right area for feature requests but in getting >> > frustrated. under settings > power the suspend sliders are silly small >> and >> > the sliding action rarely responds to your finger movements. i request >> that >> > the sliders either become larger and more centralized in the menu or >> > convert it to on off switchs. i switch this feature multiple times a day >> > and its getting annoying having to try to set it over and over waiting >> for >> > it to work properly. >> > >> > thanks! keep up the good work though. everything else is a.o.k! >> >> Agreed, but I think you might do better opening a ticket here >> http://trac.shr- >> project.org/trac for bug reports and feature requests >> -- >> "We must plan for freedom, and not only for security, if for no other >> reason >> than only freedom can make security more secure." Karl Popper >> >> ___ >> Openmoko community mailing list >> community@lists.openmoko.org >> http://lists.openmoko.org/mailman/listinfo/community >> >> > ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [OT] Is Android really free? (was Re: root almighty)
I should also add that at least in the short term I would expect that being able to run android applications on FR is going to give me a far wider choice of mobile-friendly software than any of the "true" linux distros available for FR. -- View this message in context: http://n2.nabble.com/-OT--Is-Android-really-free--%28was-Re%3A-root-almighty%29-tp2943035p2952101.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [OT] Is Android really free? (was Re: root almighty)
Ignacio Torres Masdeu wrote: > > >> in fact there is a lot of closed linux devices out there , for example >> routers,motorola phones, ebook reader... and those doesn't mean Linux >> is closed, > > It only means that if they don't publish the code, and that's usual, > they are violating the GPL. http://gpl-violations.org/ > > Not necessarily. They don't have to provide any mechanism to re-flash the device, then the linux based device is just as closed, even when they publish the source. GPL does not protect against this (v3 might, not sure). Ignacio Torres Masdeu wrote: > > > The problem with Android is not the license of the OS, but the > "ecosystem" around it. Closed hardware, DRMd content (applications, > music), the restrictions imposed on the OS by cell companies... it's a > nightmare, and the freedom of the user doesn't even appear in the > horizon. > It's BSD style FOSS. Anyone can do what they like with it. The fact that others can close their versions doesn't detract from that. If you want to argue that it loses flexibility as a platfor, when you're using a self- or community-compiled version, then sure. Ignacio Torres Masdeu wrote: > > I have strong feelings against Android, for the restrictions around it > are very similar to those of the iPhone, though Apple doesn't try to > disguise themselves as "open source paladins". > No, they really aren't. You can download and install stuff from outside the approved store on commercial android handsets and on free/open ones ones (Android on FR) you have full control, including the full source under APL2. You just try getting the source from Apple and running it somewhere else. Ignacio Torres Masdeu wrote: > > Android, as a platform (not an OS, not a device) is worst than closed, > for it lures developers with the false concept of an open environment. > Yes, just like the entire BSD operating system! It's a trap! *facepalm* Ignacio Torres Masdeu wrote: > > Yes, people could fork and create gAndroid but where would they run > it? It's a wolf with a lamb skin, > Why fork when you can port? There are several places doing just that and re-submitting upstream when they have good results. It's being ported to some nokia devices, netbooks, FR etc. And why is it a wolf in lambs skin? I mean, what the hell are you talking about at this point? Where would they run what? Ignacio Torres Masdeu wrote: > > And my last rant. Why did they create yet another isolated platform? > For f*cks sake! It's not even standard java! At least Objective-C > builds on top of C! Couldn't they create a set of libraries? Or use if > they wanted portability use Python? Argh! > > My 2 cents > Java is the most popular language on the planet right now, more people know it than know pretty much anything else going. Attracting developers is essential to the success of the platform. Why *not* use java? I use python myself, and I like it, but I don't see why choosing java was wrong. Frankly, I think you're nuts. A big corp puts a lot of work in and releases a whole new userspace environment targeted at MIDs, phones etc, under one of the least restrictive licenses out there, and you're calling it worse than closed source! You're weird! You instinctively decide to hate it due to some features you don't like (which are aimed at supporting proprietary apps, and you're free to disable in your version, or just not use those apps). There's nothing stopping people from releasing android apps as FOSS. personally I really like the idea of paying for apps from an app store if I choose to, or using/writing free ones if I don't. -- View this message in context: http://n2.nabble.com/-OT--Is-Android-really-free--%28was-Re%3A-root-almighty%29-tp2943035p2952092.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Om2009] testing Release 3: first impressions
On May 21, 2009 07:22:15 am Robin Paulson wrote: > that's confusing. i'm trying to install udev-static-devices, because > apparently it will speed up boot time. > > it's not listed in the feeds which are on my neo (including > 'http://downloads.openmoko.org/repository/testing/armv4t/' as you > listed above) - as shown by 'opkg list|grep udev-static-device' > returning nothing. > It hasn't made it to the testing feed yet. You will need to get it from the unstable feed http://downloads.openmoko.org/repository/unstable/ Angus ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Om2009] testing Release 3: first impressions
2009/5/22 Laszlo KREKACS : > On Thu, May 21, 2009 at 2:50 PM, Robin Paulson > wrote: >> how do we install this package? i can't find it in the om archives; is >> it from a separate feed, or does it need to be installed manually? > > http://downloads.openmoko.org/repository/testing/armv4t/numptyphysics_0.2+svnr109-r1_armv4t.ipk > http://downloads.openmoko.org/repository/testing/armv4t/tangogps_0.9.6-r0_armv4t.ipk > etc > that's confusing. i'm trying to install udev-static-devices, because apparently it will speed up boot time. it's not listed in the feeds which are on my neo (including 'http://downloads.openmoko.org/repository/testing/armv4t/' as you listed above) - as shown by 'opkg list|grep udev-static-device' returning nothing. so, if it's not in those feeds, where is the package? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Om2009] testing Release 3: first impressions
On Thu, May 21, 2009 at 2:50 PM, Robin Paulson wrote: > how do we install this package? i can't find it in the om archives; is > it from a separate feed, or does it need to be installed manually? http://downloads.openmoko.org/repository/testing/armv4t/numptyphysics_0.2+svnr109-r1_armv4t.ipk http://downloads.openmoko.org/repository/testing/armv4t/tangogps_0.9.6-r0_armv4t.ipk etc Laszlo ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Community-driven redesign / new theme for Paroli
On Mon, May 18, 2009 at 10:55 PM, Risto H. Kurppa wrote: > I don't know exactly how doable it is. As far as I know, it's possible > to create themes for Paroli. I don't know what parts can be changed or > how to do it but I believe that if people are interested, it'll all > come out nicely: I'm sure someone here knows the good old pen&paper > thing (or GIMP or Inkscape :) to design a GUI for Paroli. We add some > user experience skills to give it the usability touch. I'm also sure > there are people here who know enough about themes and python to > implement the template. I have spent some time in paroli theming, and how this whole e stuff works together. So I would like to propose the following thing. As the paroli gui itself is a bit in flux, needs some consistency here and there, the best way to involve the community, is to draw invidual screens how each pages should look like. There is not so much screens in paroli: - homescreen - people app screen, people->contact_detail, new_contact_dialer, new_contact_name - io - msgs, new_msgs_dialer, new_msgs_text, msgs_error_popup - tele - settings, settings->* Its only 12 screens and the settings submenus. So I think taking screenshot on every screen, put them into an inkscape.svg file, import most of the images from edje directories, and we can evolve from there. We define the svg page to be 480x640 px. We draw a main black rectangle at this size. We draw 480x65 rectangle for the illume top bar, and we are settle. (the paroli window is 480x575px, and its stretched when needed, ie in fullscreen or when the keyboard is shown) I have already created some concept drawings in inkscape, if there are interest I can share it: http://laszlo.krekacs.googlepages.com/default_view.png And we can even write some explanation to the others: http://laszlo.krekacs.googlepages.com/selected_item.png We can draw the whole interface in inkscape, and export directly as .png images to the theme. Its not that hard. I have created a call/hang up icon, here is a screenshot: http://www.paroli-project.org/pics/Screenshot-3.png Tasks: 1. create a central communication point (wiki is enough?) 2. take all those screenshots 3. create an inkscape .svg file (already done) 4. import those screenshots in there 5. import the images from edje directories (call button, delete button, etc) 6. start drawing proposing consistent layout, etc. Who is in? Laszlo ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Solar charger samples arrived[was Re: Solar charger (was Re: News Openmoko Shop Pulster)]
After test all them, just one conclusion not worth the money. nor the effort to do a strong analisis, wiki updated with the comments http://wiki.openmoko.org/wiki/Solar_chargers No one has minimum requirements to be really useful, and of course I no way want to include them on my catalogs If some one has any positive feedback from any other models from others brand please update the wiki or notify me or on the list. Best regards 2009/5/12 David Reyes Samblas Martinez : > >> More seriously, what about making an "announce" email in a new thread >> (this thread of discussion is getting quite long), so that people can >> manifest their interest and propose some tests to be carried on the >> solar charger you have selected. > > Hi all, > No much time to comment right now more comments later but at you > disposal there is a wiki page > http://wiki.openmoko.org/wiki/Solar_chargers I will fill more on later > too but there are loaded the quick and dirty pictures of the three > samples of en-chance.com for your enjoy. > > Sumarizing: > SC018 so simple than seems a toy. > SC020 seems my gandma moneybag > SC019 cool really cool > More on later and I will start with use test tomorrow > Regards > > > > > > -- > David Reyes Samblas Martinez > http://www.tuxbrain.com > Open ultraportable & embedded solutions > Openmoko, Openpandora, Arduino > Hey, watch out!!! There's a linux in your pocket!!! > -- David Reyes Samblas Martinez http://www.tuxbrain.com Open ultraportable & embedded solutions Openmoko, Openpandora, Arduino Hey, watch out!!! There's a linux in your pocket!!! ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Shr-User] opkg upgrade fail and can't boot FR to desktop
2009/5/22 Daniel.Li : > What version do u suggest, I'm using 0427-unstable. Recent version of > SHR, do u mean shr-testing? err, i'd suggest om2009, actually. shr (stable hybrid release, apparently...) got to be far too annoying. the newest version of -unstable might have fixed these bugs, but it might have introduced more as well have you tried running opkg upgrade again? > And I have found there are some problems in latest shr-testing version. > As I know, 05XX (sorry I don't remember it) has a 1 pixel shutdown menu > issue. Is it solved? nope, not in -testing. more issues with e and i couldn't get a connection to my phone network are you subscribed to the shr list, they might have better ideas what's happening? >> if not, there are more e libraries (possibly also misnamed), in >> sub-dirs of /usr/lib/evas/ >> >> i'm not confident this is related to your problem though; i don't >> recognise the error messages you're geting > > I hope NOT to re-flash the device. Anyway, if there is really no way to > go. OK, just re-flash it :( ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Om2009] testing Release 3: first impressions
2009/5/20 Risto H. Kurppa : > I've been told that you can install the package udev-static-devices to > reduce the boot time by ~30s (but if you have your home on > /media/disk/bind-home, it'll not work, see > http://wiki.openmoko.org/wiki/Om2009#Installing ) - stuff still under > development. how do we install this package? i can't find it in the om archives; is it from a separate feed, or does it need to be installed manually? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Shr-User] opkg upgrade fail and can't boot FR to desktop
On Fri, 2009-05-22 at 00:26 +1200, Robin Paulson wrote: > have you tried a more recent version of shr? they may have fixed this > by now What version do u suggest, I'm using 0427-unstable. Recent version of SHR, do u mean shr-testing? And I have found there are some problems in latest shr-testing version. As I know, 05XX (sorry I don't remember it) has a 1 pixel shutdown menu issue. Is it solved? > > if not, there are more e libraries (possibly also misnamed), in > sub-dirs of /usr/lib/evas/ > > i'm not confident this is related to your problem though; i don't > recognise the error messages you're geting I hope NOT to re-flash the device. Anyway, if there is really no way to go. OK, just re-flash it :( -- Daniel.Li PALFocus (http://palfocus.oicp.net) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Shr-User] opkg upgrade fail and can't boot FR to desktop
2009/5/22 Daniel.Li : > ln -s /usr/lib/libecore_evas-ver-pre-svn-01.so.0 libecore_evas.so.0 > ln -s /usr/lib/libecore_fb-ver-pre-svn-01.so.0 libecore_fb.so.0 > ln -s /usr/lib/libecore_x-ver-pre-svn-01.so.0 libecore_x.so.0 > ln -s /usr/lib/libecore_txt-ver-pre-svn-01.so.0 libecore_txt.so.0 > ln -s /usr/lib/libecore_input-ver-pre-svn-01.so.0 libecore_input.so.0 > ln -s /usr/lib/libecore_ipc-ver-pre-svn-01.so.0 libecore_ipc.so.0 > ln -s /usr/lib/libedje-ver-pre-svn-01.so.0 libedje.so.0 > ln -s /usr/lib/libembryo-ver-pre-svn-01.so.0 libembryo.so.0 > ln -s /usr/lib/libecore_job-ver-pre-svn-01.so.0 libecore_job.so.0 > ln -s /usr/lib/libecore_job-ver-pre-svn-01.so.0 libecore_job.so.0 > ln -s /usr/lib/libecore_file-ver-pre-svn-01.so.0 libecore_file.so.0 > ln -s /usr/lib/libecore_con-ver-pre-svn-01.so.0 libecore_con.so.0 > ln -s /usr/lib/libehal-ver-pre-svn-01.so.0 libehal.so.0 > ln -s /usr/lib/libedbus-ver-pre-svn-01.so.0 libedbus.so.0 > ln -s /usr/lib/libecore_imf_evas-ver-pre-svn-01.so.0 > libecore_imf_evas.so.0 > ln -s /usr/lib/libecore_imf-ver-pre-svn-01.so.0 libecore_imf.so.0 > ln -s /usr/lib/libevas-ver-pre-svn-01.so.0 libevas.so.0 > ln -s /usr/lib/libecore-ver-pre-svn-01.so.0 libecore.so.0 > ln -s /usr/lib/libeina-ver-pre-svn-01.so.0 libeina.so.0 > > > $ enlightenment_start.oe > E - PID=1786, do_precache=0 > ESTART: 0.00026 [0.00026] - begin > ESTART: 0.01106 [0.01080] - signals done > ESTART: 0.02173 [0.01067] - determine prefix > e_prefix_determine() > DYNAMIC DETERMINED PREFIX: /usr > ESTART: 0.04540 [0.02367] - prefix done > ESTART: 0.04708 [0.00168] - eina init > ESTART: 0.08354 [0.03646] - intl init > ESTART: 0.09212 [0.00858] - parse args > ESTART: 0.09747 [0.00535] - arg parse done > ESTART: 0.09825 [0.00078] - ecore init > ESTART: 0.12793 [0.02968] - ecore_file init > ESTART: 0.13390 [0.00597] - more ecore > ESTART: 0.13488 [0.00098] - x connect have you tried a more recent version of shr? they may have fixed this by now if not, there are more e libraries (possibly also misnamed), in sub-dirs of /usr/lib/evas/ i'm not confident this is related to your problem though; i don't recognise the error messages you're geting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Shr-User] opkg upgrade fail and can't boot FR to desktop
On Thu, 2009-05-21 at 13:02 +1200, Robin Paulson wrote: > 2009/5/21 Daniel.Li : > >> I've just done > >> > >> sed -i 's/testing/unstable/g' /etc/opkg/* > >> opkg update;opkg upgrade > >> > >> and now I'm getting this too... > >> > >> I can still get in via ssh. It look as though e is missing a library: > >> > >> $ enlightenment_start.oe > >> Enlightenment : using user default > >> E - PID=1530, do_precache=0 > >> /usr/bin/enlightenment: error while loading shared libraries: > >> libecore_evas-ver-pre-01.so.0: cannot open shared object file: No such > >> file or directory > > Add SHR mail list > > > > I remove .e folder, and have another lib missing. > > > > $ enlightenment_start.oe > > E - PID=1662, do_precache=0 > > /usr/bin/enlightenment: error while loading shared libraries: > > libecore_evas.so.0: cannot open shared object file: No such file or > > directory > > this was a major bug with the new naming scheme in e - there's > argument as to whether shr caused the problem, or enlightenment did; i > won't comment either way. apparently it's been fixed now, although at > the time a few of us hacked it by creating symlinks from > libecore_evas.so to libecore_evas-ver-pre-01.so (or vice versa, i > can't remember). > > this was criticised as being very hacky, but there you go I upgrade just a few minutes before send this mail and tried below without luck. How can I solve the problem? Anyone helps? ln -s /usr/lib/libecore_evas-ver-pre-svn-01.so.0 libecore_evas.so.0 ln -s /usr/lib/libecore_fb-ver-pre-svn-01.so.0 libecore_fb.so.0 ln -s /usr/lib/libecore_x-ver-pre-svn-01.so.0 libecore_x.so.0 ln -s /usr/lib/libecore_txt-ver-pre-svn-01.so.0 libecore_txt.so.0 ln -s /usr/lib/libecore_input-ver-pre-svn-01.so.0 libecore_input.so.0 ln -s /usr/lib/libecore_ipc-ver-pre-svn-01.so.0 libecore_ipc.so.0 ln -s /usr/lib/libedje-ver-pre-svn-01.so.0 libedje.so.0 ln -s /usr/lib/libembryo-ver-pre-svn-01.so.0 libembryo.so.0 ln -s /usr/lib/libecore_job-ver-pre-svn-01.so.0 libecore_job.so.0 ln -s /usr/lib/libecore_job-ver-pre-svn-01.so.0 libecore_job.so.0 ln -s /usr/lib/libecore_file-ver-pre-svn-01.so.0 libecore_file.so.0 ln -s /usr/lib/libecore_con-ver-pre-svn-01.so.0 libecore_con.so.0 ln -s /usr/lib/libehal-ver-pre-svn-01.so.0 libehal.so.0 ln -s /usr/lib/libedbus-ver-pre-svn-01.so.0 libedbus.so.0 ln -s /usr/lib/libecore_imf_evas-ver-pre-svn-01.so.0 libecore_imf_evas.so.0 ln -s /usr/lib/libecore_imf-ver-pre-svn-01.so.0 libecore_imf.so.0 ln -s /usr/lib/libevas-ver-pre-svn-01.so.0 libevas.so.0 ln -s /usr/lib/libecore-ver-pre-svn-01.so.0 libecore.so.0 ln -s /usr/lib/libeina-ver-pre-svn-01.so.0 libeina.so.0 $ enlightenment_start.oe E - PID=1786, do_precache=0 ESTART: 0.00026 [0.00026] - begin ESTART: 0.01106 [0.01080] - signals done ESTART: 0.02173 [0.01067] - determine prefix e_prefix_determine() DYNAMIC DETERMINED PREFIX: /usr ESTART: 0.04540 [0.02367] - prefix done ESTART: 0.04708 [0.00168] - eina init ESTART: 0.08354 [0.03646] - intl init ESTART: 0.09212 [0.00858] - parse args ESTART: 0.09747 [0.00535] - arg parse done ESTART: 0.09825 [0.00078] - ecore init ESTART: 0.12793 [0.02968] - ecore_file init ESTART: 0.13390 [0.00597] - more ecore ESTART: 0.13488 [0.00098] - x connect Enlightenment Error Enlightenment cannot initialize its X connection. Have you set your DISPLAY variable? E17: Begin shutdown procedure! > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community -- Daniel.Li PALFocus (http://palfocus.oicp.net) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: LCD Displays?
Tim Schmidt wrote: > The OLPC has an LCD which is very easy to read in daylight. When > backlit, it appears as a color LCD, but when frontlit (as from the > sun), it appears greyscale. This display _very_ cool, I saw an OLPC in action a few weeks ago. It is not even limited to direct sunlight for the reflective display, it already works extremly well at normal room lighting. You just turn the backlight off and it then switches automatically to greyscale at increased resolution. This would be way cool to have as a phone/PDA display. :) -- Tobias PGP: http://9ac7e0bc.uguu.de ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [android] new cupcake image
In case you've not seen it, here's the video and the flashing instructions.. http://www.newlc.com/en/freerunner-mobile-which-support-android-cupcake Russ 2009/5/20 Russell Dwiggins > Just tested this, but having a problem. Kernel seems to boot OK, and the > "Android" splash comes up, but then seems to loop (animation starts, > pauses, > then starts again). > > I'm wondering if it has something to do with the partitioning of the SD > card? The wiki confused me because it instructs one to fdisk the card with > 2 linux partitions (83), then format one with FAT and one with ext3. I > fdisked the fat partition with vfat (0b) and formatted with vfat, could > that > be the problem? > > Russell Dwiggins > undrwa...@verizon.net > (562)761-1819 > -Original Message- > From: community-boun...@lists.openmoko.org > [mailto:community-boun...@lists.openmoko.org] On Behalf Of Pieter Colpaert > Sent: Wednesday, May 20, 2009 5:56 AM > To: community@lists.openmoko.org > Subject: [android] new cupcake image > > Michael Trimarchi, aka Panicking, released a new image for the cupcake > version of android (1.5). Anyone into testing? > > images: > http://panicking.kicks-ass.org/download/ > > quote from the koolu mailing list: > > I start again working on android porting on freerunner. > > I have a new image, and I will create a public repository. > > > > Michael > > Good to hear Michael! Looking forward to see more. > > Pieter > > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 8.0.238 / Virus Database: 270.12.33/2120 - Release Date: 05/18/09 > 06:28:00 > > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: LCD Displays?
On Thursday 21 May 2009, zogg wrote: > Thats intresting. What could have stopped them from making it > non-monochrome in daylight? Probably cost and efficiency as these were major factors in OLPC. If PixelQi don't start producing screens that are colour in daylight then I guess there's a technical reason as well. Based on the explanation below I would have thought adding the coloured filters between the LCD and the reflective layer would drop backlight efficiency only a little since the prism has already split the light, but I'm no expert. The extra component requiring precision placement would add cost though. > Tim Schmidt wrote: > > On Thu, May 21, 2009 at 9:12 AM, zogg wrote: > >> Looks like LCD for indoors are common, and for outdoors theres scarcity. > >> So, do you know any manufacturers, or at least in what direction should > >> i try and look at? > > > > The OLPC has an LCD which is very easy to read in daylight. When > > backlit, it appears as a color LCD, but when frontlit (as from the > > sun), it appears greyscale. This is a function of the OLPC's very > > efficient backlight system (instead of using colored filters to block > > out 66% of the light from the white backlight for each pixel, they use > > a fresnel prism to split the backlight into it's component wavelengths > > on pixel boundaries. Thereby allowing nearly 100% of the light > > produced by the backlight through to your eyes, as opposed to less > > than 33% for typical LCDs. Light from the front of the LCD passes > > through the pixels, and is reflected by a silvered layer, back through > > the pixels to your eyes, never passing through the prism, so what > > would normally be colored sub-pixels appear as greyscale pixels. > > > > --tim ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [shr-testing] Forcing fast charge mode
On Thu, May 21, 2009 at 1:06 PM, Leonardo de Virgilio wrote: > Great link r.h.k.!! > I've waited for fast-charging mode on new kernel for months!! > I'll try today ;) > It'd be great if someone had the energy to update http://wiki.openmoko.org/wiki/Forcing_fast_charge_mode#The_battery_package - it's a great tool to manage the recharge status & monitor the charging. it's only a simple .py with the paths nicely listed -> not too hard to do but a package would be nice (or just a new .py with updated paths) r -- | risto h. kurppa | risto at kurppa dot fi | http://risto.kurppa.fi ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [shr-testing] Forcing fast charge mode
Great link r.h.k.!! I've waited for fast-charging mode on new kernel for months!! I'll try today ;) 2009/5/21 Risto H. Kurppa > On Thu, May 21, 2009 at 11:35 AM, Vikas Saurabh > wrote: > > > > > > On Wed, May 20, 2009 at 5:09 PM, Vikas Saurabh > wrote: > >> > >> I have recently flashed shr-testing and was wondering if the fast charge > information available here [ > http://wiki.openmoko.org/wiki/Forcing_fast_charge_mode] is still usable? > Or is there some FSO API that I have missed? > > I just updated it yesterday, the apps there use old paths -> don't > work. The paths to use now are listed in > > http://wiki.openmoko.org/wiki/Forcing_fast_charge_mode#OM2009_.26_Freerunner > - I'd think SHR uses the same.. > > Feel free to update the apps to work.. > > r > > > > > -- > | risto h. kurppa > | risto at kurppa dot fi > | http://risto.kurppa.fi > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [GPS] new GPS GUI application for OM freerunner
2009/5/21 Risto H. Kurppa : > On Thu, May 21, 2009 at 11:54 AM, arne anka wrote: >>> Looks great but PLEASE use /home/root/Maps to store map tiles -> share >>> with Tangogps... right..? >> >> NO! >> please, use $HOME/... >> this "we're all root!" madness has to stop -- and hardcoding paths like >> that is really bad anyway. > > Oops, sorry, you're right :) But anyway I think it'd be great to use > the same folder that Tangogps uses ($HOME/Maps) -> I have some 300 000 > png tiles there, it's just waste of space, bandwith and time to > download separate files for both - and if/since everyone will symlink, > why not do it by default.. Good point, just check in if the direrectory exist if true symlink if not create it. > > > r > > -- > | risto h. kurppa > | risto at kurppa dot fi > | http://risto.kurppa.fi > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > -- David Reyes Samblas Martinez http://www.tuxbrain.com Open ultraportable & embedded solutions Openmoko, Openpandora, Arduino Hey, watch out!!! There's a linux in your pocket!!! ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [GPS] new GPS GUI application for OM freerunner
2009/5/21 mqy : > > Wild! No easy sure. But... can be done with: > > (1) a bigger background pximap > (2) iimage rotation > (3) curve fitting to determine direction > (4) semi transparency as you said > > Waste energy! However, to see clearly in sun light, you have to adjust > backlight nearly 100%, thus energy is not a problem. > > Since most road segments are straight, I recommend you upgrade your > "supporting frame" rotate-able :D Well , when the path is straight there is no major problem even gps not necessary :P, I was thinking more in offroad tracks that sometimes are all but straight ;) In fact my support frame is rotate able, but if looking at the screen on the go is not secure, biking with one hand, with the other trying to follow the direction while looking at the screen on a offroad track... well at least suicidal.the supporting frame is a prototype i will try to commercialize, but as you can understand is a little bit more complicated than a leather case :) I hope I can move forward on this and report good news soon. > > I'm also a biker, but I'm doubting if it is safe to keep watching on > the screen while moving. And thas the reason is useful to know , in case of doubt , where is the right path without following on the screen what direction your are moving before stop, just stop, a quick look on the screen and you know if have the follow the right or the left path in a crossover, without guessing if the left/right path on the screen is the same as yours :P > That's why I develop the sounding module. Yes is the right way when your are moving sure! > > So, your requirement can be classified as "optional", agree? Totally agree :) > > 2009/5/21 David Samblas Martinez (via Nabble) > : >> Nice app :) >> I know it should be no easy, but a feature that I miss both in Tango >> and this is the ability to rotate the maps accordingly the direction >> you are moving on to have always up i the screen what you have in >> front of you. Maybe a semi transparent Compass on the scree can help >> to not get confused. offcourse it has to be an option you can >> dissable/enable. >> But when you move in bike for example it can be an awesome feature. >> > > -- > View this message in context: > http://n2.nabble.com/-GPS--new-GPS-GUI-application-for-OM-freerunner-tp2948257p2950687.html > Sent from the Openmoko Community mailing list archive at Nabble.com. > > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > -- David Reyes Samblas Martinez http://www.tuxbrain.com Open ultraportable & embedded solutions Openmoko, Openpandora, Arduino Hey, watch out!!! There's a linux in your pocket!!! ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [GPS] new GPS GUI application for OM freerunner
On Thu, May 21, 2009 at 11:54 AM, arne anka wrote: >> Looks great but PLEASE use /home/root/Maps to store map tiles -> share >> with Tangogps... right..? > > NO! > please, use $HOME/... > this "we're all root!" madness has to stop -- and hardcoding paths like > that is really bad anyway. Oops, sorry, you're right :) But anyway I think it'd be great to use the same folder that Tangogps uses ($HOME/Maps) -> I have some 300 000 png tiles there, it's just waste of space, bandwith and time to download separate files for both - and if/since everyone will symlink, why not do it by default.. r -- | risto h. kurppa | risto at kurppa dot fi | http://risto.kurppa.fi ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [GPS] new GPS GUI application for OM freerunner
> Looks great but PLEASE use /home/root/Maps to store map tiles -> share > with Tangogps... right..? NO! please, use $HOME/... this "we're all root!" madness has to stop -- and hardcoding paths like that is really bad anyway. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: root almighty
> I've run as a regular user on Debian, but updates would break most of > it. huh? what are you doing to make that happen? breakages happend at most twice: - when dbus was upgraded -- and that was remedied by putting the fso related changes in an additional file - when nodm changed its configuration -- instead of managing these data in /etc/init.d/nodm it went to /etc/default/nodm both changes happend a long time ago. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [shr-testing] Forcing fast charge mode
On Thu, May 21, 2009 at 11:35 AM, Vikas Saurabh wrote: > > > On Wed, May 20, 2009 at 5:09 PM, Vikas Saurabh > wrote: >> >> I have recently flashed shr-testing and was wondering if the fast charge >> information available here >> [http://wiki.openmoko.org/wiki/Forcing_fast_charge_mode] is still usable? Or >> is there some FSO API that I have missed? I just updated it yesterday, the apps there use old paths -> don't work. The paths to use now are listed in http://wiki.openmoko.org/wiki/Forcing_fast_charge_mode#OM2009_.26_Freerunner - I'd think SHR uses the same.. Feel free to update the apps to work.. r -- | risto h. kurppa | risto at kurppa dot fi | http://risto.kurppa.fi ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: NEW e-tasks Alpha release Updated
to sync with evolution, there is an amazing simple to called syncevolution which uses the syncml protocol to sync with a server (as funambol eg). I use it on my desktop, and it rocks ! Your tasks app must use the evolution data server. The only pbm : one has to compile it for the freerunner. If someone around has good compilation skills :D 2009/5/21, c_c : > > Hi, > Here's the latest release. Changes :- > * added notes to tasks > * some minor gui fixes and cleanups > * purge button to remove all deleted tasks (from the deleted category) > > Still scratching my head about how to sync with evolution. > > http://n2.nabble.com/file/n2949930/e-tasks_0.20_arm.ipk e-tasks_0.20_arm.ipk > -- > View this message in context: > http://n2.nabble.com/NEW-e-tasks-Alpha-release-%28Updated---02-May%29-tp2740524p2949930.html > Sent from the Openmoko Community mailing list archive at Nabble.com. > > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [shr-testing] Forcing fast charge mode
On Wed, May 20, 2009 at 5:09 PM, Vikas Saurabh wrote: > > I have recently flashed shr-testing and was wondering if the fast charge > information available here > [http://wiki.openmoko.org/wiki/Forcing_fast_charge_mode] is still usable? Or > is there some FSO API that I have missed? > > --Vikas ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [GPS] new GPS GUI application for OM freerunner
On Thu, May 21, 2009 at 11:15 AM, W.Kenworthy wrote: > Can someone tell me: > what the "foot" with a red cross through it means - doesnt seem to do > anything. My guess is that it's something about 'path' or 'track'.. > and similarly, the two diagonal opposing arrows next to it. No ideas.. r -- | risto h. kurppa | risto at kurppa dot fi | http://risto.kurppa.fi ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: LCD Displays?
Hi Zoggie, > > i had this event yesterday. In office, a friend of mine spotted my > Freerunner laying on the desk and said "Hey, thats freakin cool > display!". He shared his problem with me: its hard to find cheap LCD > displays that may be used outdoors. And i replied that community that > produced Freerunner might know the direction where to look at. > > Looks like LCD for indoors are common, and for outdoors theres scarcity. > So, do you know any manufacturers, or at least in what direction should > i try and look at? Look for the word transflective displays when you look for lcd supplies. There are a number of manufacturers that produces transflective displays. KP ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [GPS] new GPS GUI application for OM freerunner
On Thu, 2009-05-21 at 08:52 +0200, David Reyes Samblas Martinez wrote: > Nice app :) > I know it should be no easy, but a feature that I miss both in Tango > and this is the ability to rotate the maps accordingly the direction I am still waiting for gps lock (actually just got it ... in the office :), but it looks nice so far. symlinking the map directory to the tangogps store works fine. One thing that all gps apps I see on the FR so far do is centre the cursor/position. Thats fine when standing still, but I am not really interested in where I have been, but where I am going so it would be nice if the cursor/centre of the display was offset appropriately. Can someone tell me: what the "foot" with a red cross through it means - doesnt seem to do anything. and similarly, the two diagonal opposing arrows next to it. BillK ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: LCD Displays?
Thats intresting. What could have stopped them from making it non-monochrome in daylight? Tim Schmidt wrote: > On Thu, May 21, 2009 at 9:12 AM, zogg wrote: > >> Looks like LCD for indoors are common, and for outdoors theres scarcity. >> So, do you know any manufacturers, or at least in what direction should >> i try and look at? >> > > The OLPC has an LCD which is very easy to read in daylight. When > backlit, it appears as a color LCD, but when frontlit (as from the > sun), it appears greyscale. This is a function of the OLPC's very > efficient backlight system (instead of using colored filters to block > out 66% of the light from the white backlight for each pixel, they use > a fresnel prism to split the backlight into it's component wavelengths > on pixel boundaries. Thereby allowing nearly 100% of the light > produced by the backlight through to your eyes, as opposed to less > than 33% for typical LCDs. Light from the front of the LCD passes > through the pixels, and is reflected by a silvered layer, back through > the pixels to your eyes, never passing through the prism, so what > would normally be colored sub-pixels appear as greyscale pixels. > > --tim > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > > ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: LCD Displays?
What about protection film? Tim Schmidt wrote: > > On Thu, May 21, 2009 at 9:12 AM, zogg wrote: >> Looks like LCD for indoors are common, and for outdoors theres scarcity. >> So, do you know any manufacturers, or at least in what direction should >> i try and look at? > > The OLPC has an LCD which is very easy to read in daylight. When > backlit, it appears as a color LCD, but when frontlit (as from the > sun), it appears greyscale. This is a function of the OLPC's very > efficient backlight system (instead of using colored filters to block > out 66% of the light from the white backlight for each pixel, they use > a fresnel prism to split the backlight into it's component wavelengths > on pixel boundaries. Thereby allowing nearly 100% of the light > produced by the backlight through to your eyes, as opposed to less > than 33% for typical LCDs. Light from the front of the LCD passes > through the pixels, and is reflected by a silvered layer, back through > the pixels to your eyes, never passing through the prism, so what > would normally be colored sub-pixels appear as greyscale pixels. > > --tim > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > > -- View this message in context: http://n2.nabble.com/LCD-Displays--tp2950632p2950710.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [GPS] new GPS GUI application for OM freerunner
Wild! No easy sure. But... can be done with: (1) a bigger background pximap (2) iimage rotation (3) curve fitting to determine direction (4) semi transparency as you said Waste energy! However, to see clearly in sun light, you have to adjust backlight nearly 100%, thus energy is not a problem. Since most road segments are straight, I recommend you upgrade your "supporting frame" rotate-able :D I'm also a biker, but I'm doubting if it is safe to keep watching on the screen while moving. That's why I develop the sounding module. So, your requirement can be classified as "optional", agree? 2009/5/21 David Samblas Martinez (via Nabble) : > Nice app :) > I know it should be no easy, but a feature that I miss both in Tango > and this is the ability to rotate the maps accordingly the direction > you are moving on to have always up i the screen what you have in > front of you. Maybe a semi transparent Compass on the scree can help > to not get confused. offcourse it has to be an option you can > dissable/enable. > But when you move in bike for example it can be an awesome feature. > -- View this message in context: http://n2.nabble.com/-GPS--new-GPS-GUI-application-for-OM-freerunner-tp2948257p2950687.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: LCD Displays?
On Thu, May 21, 2009 at 9:12 AM, zogg wrote: > Looks like LCD for indoors are common, and for outdoors theres scarcity. > So, do you know any manufacturers, or at least in what direction should > i try and look at? The OLPC has an LCD which is very easy to read in daylight. When backlit, it appears as a color LCD, but when frontlit (as from the sun), it appears greyscale. This is a function of the OLPC's very efficient backlight system (instead of using colored filters to block out 66% of the light from the white backlight for each pixel, they use a fresnel prism to split the backlight into it's component wavelengths on pixel boundaries. Thereby allowing nearly 100% of the light produced by the backlight through to your eyes, as opposed to less than 33% for typical LCDs. Light from the front of the LCD passes through the pixels, and is reflected by a silvered layer, back through the pixels to your eyes, never passing through the prism, so what would normally be colored sub-pixels appear as greyscale pixels. --tim ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
LCD Displays?
Hi list, i had this event yesterday. In office, a friend of mine spotted my Freerunner laying on the desk and said "Hey, thats freakin cool display!". He shared his problem with me: its hard to find cheap LCD displays that may be used outdoors. And i replied that community that produced Freerunner might know the direction where to look at. Looks like LCD for indoors are common, and for outdoors theres scarcity. So, do you know any manufacturers, or at least in what direction should i try and look at? P.S. Im aware that this is little bit offtopic, but this is the only place i know that has knowledge in this matter. :) ~ Zoggie ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [GPS] new GPS GUI application for OM freerunner
On Thu, May 21, 2009 at 8:52 AM, David Reyes Samblas Martinez wrote: > I know it should be no easy, but a feature that I miss both in Tango Hi! What I miss is street name search. In openstreetmap we can search, so it is possible somehow to extract street names and gps coordinates of them. I could download all street names within a rectangle, so lets say the area of my town. Thats way it wouldn't be confused, if two cities share the same street names. Is it difficult to implement? Laszlo ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community