Re: freeware != free software??? Re: Navigation
> a) the group "free software" is nothing but a combination of an adjective > and a substantive, the adjective qualifying the substantive That might be the case, but in the context of distributing a piece of software in the context of GNU/Linux, "free software" refers to the FSF's notion. Any other use is a misuse, Stefan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: debian/fso on freerunner
> Debian is definitely great, but it has a big disadvantage on the FR: > Size matters. More generally, it has trouble adapting to particular hardware needs, whether disk space, FPU-less CPU, small RAM, etc... Its precompiled nature makes it largely unavoidable, sadly. Stefan PS: it is possible to install Debian on the internal flash, but it requires more care, indeed. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Debian] new kernel package
> '> Apart from factoring out those modules, is the new kernel improved in >> some way? And is it built without the debug settings? > It's the latest upstream andy-tracking, mostly meaning that if > compared to July snapshot Bluetooth, GPS etc. should handle suspend > better among else. Debug is disabled. WLAN should work, but because of > the debug being disabled one usually hits this bug quite soon: I just tried it and the boot fails with "unable to mount rootfs on unknown block". My Debian / partition is on the NAND, if it matters. Any idea what might be the problem? Stefan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Rutgers University writes malware for Freerunner
> It's not hard to run your browser on the neo as user. Though it should > be made default. It is the default if you install Debian on your Freerunner, Stefan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
How to get the QtMoko kyboard
I just installed QtMoko (v18) on a uSD to try it out, and while it looks OK, it never shows me any keyboard, which makes a lot of its functionality unusable. Is it supposed to popup automatically? If it doesn't, is there some way to force it? I do see a little "Aa" icon at the top of the screen when I'm in a text field, but it doesn't seem to be do anything. Stefan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Debian] new kernel package
>>> '> Apart from factoring out those modules, is the new kernel improved in some way? And is it built without the debug settings? >>> It's the latest upstream andy-tracking, mostly meaning that if >>> compared to July snapshot Bluetooth, GPS etc. should handle suspend >>> better among else. Debug is disabled. WLAN should work, but because of >>> the debug being disabled one usually hits this bug quite soon: >> I just tried it and the boot fails with "unable to mount rootfs on >> unknown block". My Debian / partition is on the NAND, if it matters. >> Any idea what might be the problem? > Had the same issue. Solved it re-running 'configure-uboot.sh' with > rootfstype=ext2 instead of ext3, What is this "configure-uboot.sh"? I'm not even using U-Boot but Qi instead. Furthermore, I'm using neither ext2 nor ext3 since / is on the NAND (where I use jffs2). Stefan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Debian] new kernel package
>> > well, but that's a specific scenario for a rather limited audience, isn't >> > it? >> Sure nowadays but if a user could easily choose encryption they might >> just use it. > I suspect that without a hardware encryption engine the performance and > battery life hit will be too much for most people. I doubt it: there are very significant performance differences between jffs2-on-NAND and ext3-on-uSD, but people hardly ever bother to mention it. The impact of encryption would probably be fairly low as well. Stefan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Debian] new kernel package
> I switched from ext3 builtin to ext3 as module, because this is more > Debian like. I guess I will have to change this back to built in, > because we have no initramfs? So, IIUC you also switched to jffs2 as module, which would explain why I can't boot into my NAND-installed Debian. I think both ext3 and jffs2 should be built-in since they are the two kinds of filesystems most widely used on the FR. Stefan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: How to get the QtMoko onscreen keyboard
> The “Aa” icon means the input method is set to Phone Keys, but of course > the FreeRunner lacks a physical keypad. You need to press the white > triangle, which points down, to the right of the “Aa” icon to choose one > of the keyboard-based input methods. I prefer the Docked Keyboard. In > QtMoko v14, the input method reverts to Phone Keys every time Qt > Extended Improved (QtEI) is restarted, so you always need to change it > back to a keyboard-based input method. AFAIK, this bug has still not > been fixed, so QtMoko v18 probably still behaves the same as v14. Ah, thanks, it works now. I even managed to get my wifi configured (including all the weird chars in the WPA password). Now I keep wondering: why is this Debian-based distribution not using *.deb packages for its /opt/qtmoko stuff? Stefan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: How to get the QtMoko onscreen keyboard
>> Now I keep wondering: why is this Debian-based distribution not using >> *.deb packages for its /opt/qtmoko stuff? I finally saw that this is a TODO item, so clearly it's just because nobody did it. Stefan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: tangoGPS is a very successful user orienteted map and gps viewer
Reminds me of the following feature request: when downloading levels N...N+4 (or 5, 6, younameit), please also download all the levels above (it's a negligible fraction of the corresponding disk space and network bandwidth anyway). I.e. instead of "downloads N to N+4", it should be "download levels 1 to N+4". Stefan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Is xserver-xorg-video-glamo freezy for anyone else than just me?
> Yes you need to configure the userland watchdog to do something > useful. Like check that you have no processes in disk sleep (D) state > and that SSH server is running etc. Which watchdog daemon would that be, and hos do you configure it. The only ones I've seen were trivial (like busybox's) and didn't seem to come with any way to do such useful checks. Stefan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Is xserver-xorg-video-glamo freezy for anyone else than just me?
>> Which watchdog daemon would that be > It's the normal one that everyone's been using since 1996 :-) Duh! Thanks for making me finally see the obvious, Stefan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Detecting 1024 on qtmoko
>> Also... do QtMoko really log to files on flash or have I missed >> something. I would prefer logging to a ramfs like on SHR. > Now it logs to flash. I have been experimenting with this > a little. It's very wanted for next releases... I use the following script: % cat /etc/init.d/syslog-busybox #!/bin/sh ### BEGIN INIT INFO # Provides: sysklogd # Required-Start: $remote_fs $time # Required-Stop:$remote_fs $time # Should-Start: $network # Should-Stop: $network # Default-Start:2 3 4 5 # Default-Stop: 0 1 6 # Short-Description:System logger ### END INIT INFO case "$1" in start ) echo -n "Starting Busybox syslog:" if busybox syslogd -C16; then echo -n " syslogd"; else echo -n " !syslogd!"; fi if busybox klogd; then echo -n " klogd"; else echo -n " !kogd!"; fi echo "." ;; esac % It should be made into a small Debian package, but I haven't spent the time yet to learn how to make such a thing. Stefan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: qi-bootmenu-0.1 for GTA02
> flash partitions are not scanned? Why? Because reading even just a single file of a jffs2 partition requires a lot of time (typically proportional to the size of the jffs2 partition). Stefan PS: Think of a jffs2 partition as a "cyclic tape": to find a file, we first need to find the beginning of the tape which could be anywhere, so it requires scanning the whole tape. There are many ways to optimize this search, but all flash based file systems have to struggle with this problem. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko v24
>> I've gone for a less radical approach, as most of the loglines came from >> qtopia: >> >> in /etc/init.d/qpe.sh >> >> change the line that starts qpe in >> qpe 2>&1 | logger -p local5.debug -t 'Qtopia' >> >> than use /etc/syslog.conf to only log important info (see man >> syslog.conf) > Sure, but i have seen kernel going crazy and spamming megabytes into > /var/log/messages. So i think complete removal of loggers is more safe. Why not use the circular in-memory buffer provided by busybox's syslogd? It's what OpenWRT uses (and many other embedded firmwares): it doesn't eat up your Flash/disk, but still gives you access to the last few messages. I already posted the init file I use for it: # cat /etc/init.d/syslog-busybox #!/bin/sh ### BEGIN INIT INFO # Provides: sysklogd # Required-Start: $remote_fs $time # Required-Stop:$remote_fs $time # Should-Start: $network # Should-Stop: $network # Default-Start:2 3 4 5 # Default-Stop: 0 1 6 # Short-Description:System logger ### END INIT INFO case "$1" in start ) echo -n "Starting Busybox syslog:" if busybox syslogd -C16; then echo -n " syslogd"; else echo -n " !syslogd!"; fi if busybox klogd; then echo -n " klogd"; else echo -n " !kogd!"; fi echo "." ;; esac # You can then read your syslog with "busybox logread" (for which you can make a symlink). Stefan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko v24
>> Why not use the circular in-memory buffer provided by busybox's syslogd? >> It's what OpenWRT uses (and many other embedded firmwares): it doesn't >> eat up your Flash/disk, but still gives you access to the last >> few messages. > but we dont have busybox in debian. ??? Ever tried "aptitude search busybox" ??? Not only it's part of Debian, but it's used in Debian's initrd, i.e. in most desktop installations. Actually, having just tried "aptitude search busybox", I see that not only there is a busybox package, but there's even a busybox-syslogd package in unstable, which provides the same feature as my script (in a more verbose way, with more bells and whistles). Stefan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko Beagle Hybrid
> 1. PCB and very special components only (you can go shopping yourself). > 2. PCB and complete component set (unsoldered) > 3. PCB and components already soldered on a professional SMT line (we > have one) > 4. same as 3 including a Wi2Wi GPS receiver module (we are not sure if > the internal Freerunner antenna module works, but an external antenna > connected through the MMCX plug did work). This will increase the > price of course. I'm a software guy, so options 1 and 2 are out for me. No preference w.r.t 3 vs 4. Stefan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko on Wikipedia
> This is done to protect users from malware, Please don't spread such misinformation. It is done to keep control of the device away from the user. I.e. it's only correct if you define "malware" as "program that the company doesn't like", whereas I think it's usually understood as "program which does things that the end-user doesn't like". Many pre-installed software on today's popular devices are actually malware (tho only discerning users realize it). Stefan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Good evening to everyone
> 1/ USB Host is not working in v30, v31 (in v26 is). Dmesg says "unable > to enumerate device". I was trying to connect USB flash drive, BT dongle > and USBtoRS232 converter (With PL2??something chip) - all these were > working on v26. The FreeRunner's USB port can be switched from device to host separately on the data and power pins, so my guess is that you set its data pins to host mode but left the power in device mode, which means that the FR will not provide power via USB but will expect to pull power from it instead (this is typically used together with a tweaked USB hub powered from a power brick). Stefan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: qtmoko v33
> * qtmoko and it's applications are packaged as debian packages Yay! Thanks for the rest as well, but this is the big one for me. Stefan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: qtmoko v33
* removed package vim-tiny from v33 .tgz, please re-add it as default;) >>> > > Hmm i am trying to keep the image as small as possible. I'd rather >>> prefer if >>> > people could install they favourite apps with apt-get. >> I agree, but I think vi/vim is quite a basic tool in any distribution. >> I'd remove nano instead, not so common as vi is. >> btw, nano is 1786kB, vim-tiny is 1114kB;) > +1 :-) Nah, I much prefer zile. Stefan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Sharing TSM30 source
> I badly need to set up a new FTP server with bigger disks and a newer > ftpd that supports REST, so that I can put *everything* I have online. > But I can't stomach PC hardware, at least not in my machine room: I'm > OK with x86 laptops and *maybe* desktop workstations, but an x86 > server is a no-no for me. I'm not sure what's your objection to x86 servers, but I use an Asus WL700ge for a somewhat similar circumstance. It's very low-power, but is perfectly adequate for serving files over a DSL line. It's got a MIPS cpu, 64MB RAM, runs OpenWRT, and I put a 1TB drive in it (via a small PATA->SATA bridge since the machine only has PATA but large disks only come in SATA). Stefan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: How to bring forward the community?
>> what you think would bring forward the Openmoko community > Hardware: One-man-show Nikolaus > Software: One-man-show Radek > I am praying each night, that both of you fasten your seatbelt daily. > Instead a participating community we converted to simple consumers > waiting for news and order buttons. We dont need new features, but a new > spirit first hand. Poor pre-order numbers of GTA04 proove this. Openmoko was a combination of several things: - Open hardware. - A phone running Free Software. - A phone running standard GNU/Linux software (e.g. X-Windows). IIUC there are many more people interested in the second than in the first. Stefan PS: There's a general expectation that open hardware will run Free software, but w.r.t open hardware's GPU that doesn't seem to be very often the case. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
GTA02 screen broken
My GTA02's screen is cracked. The display is still very good, but the touchscreen is unusable, making the whole device unusable. Does anyone have pointers as to where I could find a replacement (what hardware should I be looking for)? Stefan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GTA02 screen broken
>> My GTA02's screen is cracked. The display is still very good, but the >> touchscreen is unusable, making the whole device unusable. >> Does anyone have pointers as to where I could find a replacement (what >> hardware should I be looking for)? Thanks to all your help, I now have a replacement screen, but I'm wondering how do I go about doing the actual replacement. Does someone have some kind of instructions to guide me through the process? Are there particular things to look out for? Or do I just "unscrew whatever seems to get in the way" until I can take out the screen? Stefan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [QtMoko] Wireless connention to eduroam
>> > on="expr:@/Network/Interfaces/Wifi/State == 2" >> active="expr:@/Network/Interfaces/Wifi/State == 2" >> onclick="message=QPE/Application/qterminal,setDocument(QString),/opt/qtmoko >> /bin/ping.sh" /> > There is command line utility calles vsexplorer (or something like that) in > /opt/qtmoko/bin. You can use it to read and probably set these valuespace > objects. Why isn't the icon shown based on the actual interface's status rather than based on some external info that needs to be constantly kept up-to-date? Stefan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
QtMoko and WPA
So, now that I replaced the touchscreen in my GTA02, I can try and actually use that gizmo. So I installed QtMoko v54, and it seems to work fairly well. But I can't figure out how to connect to my home wifi. Part of the problem might be that I don't understand the UI. Here's what I expect: - click on some "wifi connect" button. - auto-select a known network, and/or show me a list of available networks. - I choose my home network. - seeing it's encrypted, it asks me for the password, connects and then remembers the password for next time. Instead, here's what I did and what happened: - clock on the house shaped icon. - click on the "settings" icon. - select "Internet". - create a "Wireless LAN" entry with "New" (in the menu). - fail to understand what to do, so moved back. - click on the newly created "Wireless LAN". - it shows me a list of networks, from which I can select mine. - says it tries to connect but doesn't ask for a password. - after a while the status reverts to "not connected", indicating presumably that the connection failed. - move back and keep the "Wireless LAN" entry selected. - select "Properties..." from the menu. - go to "Wireless Encryption". - this time I can select my home network from the menu (along with all the many others that are in range even no I never showed any interest in them). - even tho the earlier list (the one from which I can try to connect) showed that QtMoko knows the network is encrypted, the encryption setting defaults to "Open". - I set it to WPA-PSK. - I painfully type in the long password, and hit return. - move back. - move "forward" to wireless encryption again, to check the password was properly recorded. The display doesn't actually show the password any more, but at least the WPA-PSK setting is recorded as well as the length of the password: looking OK. - select "Wireless LAN". - from the network list shown I select my home network. - the system says it's trying to connect to my network. - after a while it reverts to saying the status is "not connected" without any information about why. - I go back to the wireless encryption panel and lo and behold the encryption setting for my network is again set to "Open". I tried it a couple times, in case the error was in the password, but now I'm pretty sure the problem is elsewhere. Am I doing something wrong? Is there some way to get some info about what went wrong? Can I provide my network's password via the command line instead? Stefan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GTA02 screen broken
> there is a very good description in the GTA04 Manual: > http://projects.goldelico.com/p/gta04-main/page/Manual/ > It's the same procedure on the GTA02! Thank, worked a treat (even easier when the screen you're removing is already broken ;-) Stefan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko and WPA
> Am I doing something wrong? Is there some way to get some info about > what went wrong? Can I provide my network's password via the command > line instead? Any help to connect to a home WPA network? Stefan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Crowdfunding an Ubuntu smartphone (right now)
The main problem I see with such Free and/or Open phone is the "small production" syndrome. Small productions mean high prices and low reliability, whereas we need reasonable prices and reliability. So we need to focus on making larger production. For that, we need to widen the target "market". I'm not sure how best to do that, but I think the key is in making products that can be used in more situations. E.g. the EOMA project comes to mind: a single "SoC card" can potentially be used in various devices (tablet, router, NAS, ...). If the core part of the hardware could be shared between communities such as Openmoko (free phone), Raspberry, etc.. then it'd be easier to get that core part produced at reasonable cost, and to have a reasonably reliable kernel running on it. Stefan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Crowdfunding an Ubuntu smartphone (right now)
> I don't see reliability as a problem because it depends on what type > of reliability you are thinking of: component, software, hardware, > production, or availability. Small production runs means very few people have a chance of discovering, let alone, fixing the various problems that can show up. > In essence it goes to a modular approach - but "modular" typically drives > cost up (at least for the version having the highest production numbers) > and is in strong contradiction with miniaturization of handheld devices. In my part of the world, phones have been getting bigger rather than smaller. And while modularity has a cost, it can be offset by economies of scale (both in terms of production as in terms of developping/debugging the kernel support) if that module can be reused in more places. Free Software strives on standards and modularity. Also, if you can upgrade the screen and the CPU separately, you might attract a few other users, who aren't so interested in Freedom but do like the idea of customizing their phones. I'd be very happy to have a Free Phablet (and I actually wouldn't necessarily need it to have cell-phone connectivity, as long as VoIP works well), even if that's not my favorite form factor: at this stage, I'm willing to settle for anything smallish. > It would be sufficient to bundle buying power (by summing up # of > units for different projects), so that we get existing modules > cheaper. I.e. if all projects would use let's say an DM3730+Memory, > they still can be soldered into different devices. Or WLAN/BT and > UMTS are already coming as SoC/MCP "modules". Right. That is a lower-leve of modularity than EOMA but it provides similar benefits (not only direct cost, but also development&debugging). > So the trick is to use a bigger shopping bag and make a different meal > out if it every day. Exactly. The various "Free Hardware" communities need to pool their resources. Stefan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Crowdfunding an Ubuntu smartphone (right now)
> Production problems show almost immediately, even if there is only one > person. And they show after making let's say 20 units. As you know, that has not been the experience with the GTA02, where audio quality output (works fine for line-out but not for headphones), GPS issues, and the "1024 issue" have appeared over time and some of them took a long time to track down and fix. I can bet that your tests for GTA04 did not catch problems along the lines of power consumption issues that will only show up in particular usage scenarios that will only be used by the customer number 1462. >> Also, if you can upgrade the screen and the CPU separately, you might >> attract a few other users, who aren't so interested in Freedom but do >> like the idea of customizing their phones. > That is a dream that is not realistic. Every display has a different > connector (there is no standardization!). And every CPU has different > signals and power supply needs. I.e. you can swap an OMAP3505 for an > OMAP3530 or an DM3730 but nor for an OMAP4 or OMAP5 or Snapdragon or > i.MX6. Because they are not designed for this way of use. I know. But I'm not talking about swapping the actual CPU or the actual display. I'm talking about swapping the "CPU module" or the "display module". I.e. create a standardized module interface around off-the-shelf (i.e. non-standardized) components. It would have its own cost (in money and in size), but in the long run, I hope the benefits of relying on standardized interfaces would make up for it. >From what I can tell, Free Hardware projects don't benefit nearly enough from each other's efforts. Not sure we have enough Sisyphus around to keep them all alive. Stefan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: The "open hardware" phone project that's had the most interest
> There are numerous threads on Reddit that explain very well why this is not > feasible [1,2,many] This is bogus. It is feasible. Just not quite in the way those people ask for it. E.g. you wouldn't have just a CPU module, and instead you'd have a module that combines the CPU with many other things. So the whole phone would be made up of very few modules: a case, a screen, a battery, and one or two "electronics" modules. And it would be bulkier and more expensive than a non-modular phone, of course. I for one would be willing to pay twice as much for such a phone, even if it's twice as thick. Stefan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Crowdfunding an Ubuntu smartphone (right now)
> But none of them is building modular devices. I wonder why. For the same reason they don't make their hardware open, for the same reason they don't make their software Free, for the same reason they don't want you to have root access on your phone. Stefan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GTA04A5 / Letux 2804
> Upgrade? Surely you must have meant downgrade - why would anyone in There are tradeoffs everywhere. I think that having a 100% free firmware for the cell-phone part is really great. Having an up to date "smartphone" that runs Free Software is also great. I see no reason why one project should feel like the other is a threat. BTW, one issue with Calypso is that as the proportion of non-3G phones in use decreases, coverage for non-3G phones is going down. Maybe it's not yet a problem, but it's only a question of time. Stefan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Free phone: smart or not?
> are you using your FR because it's free or because it's a smartphone? I don't really use my FR for the following reasons: - I don't use its phone part because it's not Free (I guess by now I could try to use your firmware to fix that part) and because I don't like the idea of being actively tracked by my cell phone provider (and I hate the providers here, who all force you to sign contracts because they suck so much that all users would otherwise run away), so I'd want to turn the cell-phone part OFF most of the time. - I do want to use the smartphone side, such as GPS, book reader, email reader, Jabber client, web browser. I want this more than a cell-phone, really. But the FR's hardware is too limited for that in my experience (e.g. the screen is too small for a resistive touchscreen), and the software is not reliable enough. Stefan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: State of FreeCalypso
> Lets not forget - just one man working doggedly on the only project that > offers any possibility of a cell phone running firmware that offers the > four freedoms. FWIW, last I checked, his work does sadly not enjoy any of those freedoms. Yes, you *can* look at the code, change it, and redistribute it, but you're not legally allowed to because the source code he has is proprietary. Much better than running some binary blob you can't even look at, yes, but still very different from the the goals of Free Software. Stefan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: State of FreeCalypso
>> but still very different from the the goals of Free Software. > Are they very different? As long as this FreeCalypso code stays very obscure and marginal, in practice the difference might not matter that much. I think what you're saying is that from an Open Source point of view, his effort is just fine. But from a Free Software point of view, his effort is deeply flawed unless/until he/we start lobbying the copyright holder to Free the original code. Stefan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: moko13 firmware
> And how many people have responded to this shutdown plan by taking a > vow to live without any cellphone at all instead of accepting 3G/4G > when such shutdown happens? Why would someone do that? I mean this as a real technical question: what is the difference between 2G and 3G which would cause someone to take a stand against 3G? Stefan "who doesn't want to use cell-phone technology and limits itself to wifi instead, where it's harder to track you from a central location" ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Announcing new Project - Intone mplayer frontend
> Well, I'm actually looking at taking it further - apart from being a > frontend to mplayer. I'm also looking at playing ogg through tremor and > trying out mpg123 to see if that is any better. Though, I intend stopping > after these two codecs - since most audio IMHO is likely to be in these > formats. MPD (and many other players) already plays Ogg/tremor just fine. Why don't you try and improve those players rather than reinvent the wheel? Stefan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Problem installing apache webserver on my FreeRunner
> I just got my new FR fone as a part of my university research program > and tried installing apache2 but it does not install.It returns error > status 2. > Can you guys suggest how i can go ahead. I am using OM 2008.12. I tried > opkg install apache2 FWIW, maybe you'd be better served by installing Debian since you then have a larger collection of standard packages. Stefan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR-Unstable] Dead gstreamer?
> Hey, I'm trying to use Pythm, but the gstreamer backend seems broken. > It doesn't play any sound, and judging by CPU usage, it's not even > trying. I have no idea where to look to diagnose this... Try the MPD backend. For me, it works without hassle. Stefan "apt-get install mpd" ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR-Unstable] Dead gstreamer?
> See subject, I use SHR-Unstable. :\ Is mpd available for that? It's packaged for OpenWRT, and it shouldn't be difficult to package it for OpenEmbedded, so if it's not, that's easy to fix. Stefan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [All] To build a better music player
>> FYI, there is a new version of pythm available on opkg.org > I only miss one little thing > When you add an entire directory to playlist, tracks are alphabetically > ordered, but, if exists, they should be ordered by track # (from ID3 or ogg > tags). This turns out to be a tricky problem. > I have a lot of disks without track number on track name, only identified by > track# on id3/ogg And other people have directories with files that aren't part of a single album, so the track numbers are not related. Also, there are multi-CD albums, where you may have a single directory with all the songs for all the CDs in the album, so you'd then need to sort by disknumber+tracknumber. The current solution is the easiest and also the most flexible: no matter how you organize your directories, it should be pretty easy for you to fix your file names such that they get sorted in the order you like. Stefan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [All] To build a better music player
> I think it's a problem of horsepower. I don't. > If you can, as modern players do, read all id3 info of all tracks, > and process it on a relational database, you can perfectly sort all > your songs by author/album/year/genre/what you want ;) Actually, if you only use ID3 info, it's very difficult to do a good job of sorting files: it's basically impossible to reliably figure out which songs are part of the same album and which aren't. You can use heuristics which will work OK in many cases, but sooner or later you'll bump into some songs whose "album" tag says (say) "Anthology" and which are really divided into 4 different albums, some of which are "well behaved" (same artist and year for all their songs), and the others are compilations where every song has a different year/genre/artist. And then you add classical music into the mix and it gets even more fun. > But, if doing so is a slow process on my 2.4 GHz desktop, I cannot > imagine how slow would be on the freerunner. My measly WL-700gE (266MHz MIPS CPU + 64MB RAM) does it just fine for my music collection (7000 songs). Whoever has read my earlier messages knows that this is using MPD ;-). So at least in the case where the backend is MPD, pythm does have all the necessary tag info at hand, but sorting is still a nightmare, so sorting "by file name" really turns out to be a very good solution. Stefan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [All] To build a better music player
>> Actually, if you only use ID3 info, it's very difficult to do a good job >> of sorting files: it's basically impossible to reliably figure out which >> songs are part of the same album and which aren't. You can use > I've solved all those problems the first times I opened amarok, and > now it's a pleasure searching for some song, artist, disk, track... >> heuristics which will work OK in many cases, but sooner or later you'll >> bump into some songs whose "album" tag says (say) "Anthology" and which >> are really divided into 4 different albums, some of which are "well > When you find one, you can allways change track's id3 :) Except that those ID3 tags have a clear meaning, and "fixing them" to get the sorting to work may imply "breaking them" in the sense that the info they carry is not quite correct any more. Tho, I guess it depends on the details: in which way did you change the ID3 info to solve such problems? >> behaved" (same artist and year for all their songs), and the others are >> compilations where every song has a different year/genre/artist. > Sorting by name has also problems. No doubt. > If you have songs from several disks or a double album in the same > folder, you can finish with this playlist: > - track 1, disk 1 > - track 1, disk 2 > ... > - track 1, disk n > - track 2, disk 1 > - track 2, disk 2 > ... I name them "- " and it works great ;-) >> sorting "by file name" really turns out to be a very good solution. > Not for me ;) Because you find "changing ID3 tags" to be simpler than "changing file names". > I still think that offering several sortings is the way to go Well, ... it's more work. An algorithm that uses both ID3 tags and filenames (mostly just directory names, actually) should be able to accomodate all situations. Stefan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [All] To build a better music player
>> Except that those ID3 tags have a clear meaning, and "fixing them" to >> get the sorting to work may imply "breaking them" in the sense that the >> info they carry is not quite correct any more. >> Tho, I guess it depends on the details: in which way did you change the >> ID3 info to solve such problems? > No, I don't break them for sorting to work, Simply I correct them so I avoid > ambiguities. > For antologies (or double/triple albums) > * Put the same "disk name","year" and "artist name" labels in every track, > * Set "track number" and "track name" labels for every track > * Set "disk number" label for diferenciating tracks from a disk from tracks > from another > For compilations, > * Put the same "disk name" and "year" in every track > * Set "artist name", "track number" and "track name" for every track > * Set "disk number" if needed > That way, my labels are *completely correct*, and every well behaved player > can order my tracks by album... Yes, those settings are correct, but they still won't work right if you have several compilation albums of the same year with the same title. Stefan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Pulster fixe(s) and rework
> Your mentioned 50mA for the AUX LED is ridiculous. It is. Sadly it's also true. > And when you are on battery the AUX led is off by default and even if it > blinks (like i modified my led behaviour) it isn't really much it uses. Indeed, it's not lit very often... I'll let you guess why that is. Stefan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Pulster fixe(s) and rework
> I have suggested a refinement on the second approach: short the small > capacitors. Add big caps outside the shielded unit - there are places > with room. But don't put wires from the caps into the shielded > unit. Connect them to the headset plug instead, and break the plug's > normal connection to the circuit board. This approach won't pick up any > more buzz than the headset based solution, or the current bassless > setup. And you can use any headset you want. > The big question is - is it safe to short those small capacitors? Or > will that have other side effects, such as draining the battery or > disturbing sound on the built-in speaker? > Another question - is a single big capacitor enough, if it is put into > the ground line instead of having one cap for each of the stereo > channels? Or will that wreck stereo sound? One could then use a even > bigger cap. > There is lots of easily accessible room next to the battery, above the > SIM card. I'd love to see a good answer to those questions. Currently, it's unusable as an MP3 player and that's an important use for me (if I could use it as an MP3 player, I'd carry it with me that much more often, which would in turn increase my use of it). Stefan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Pulster fixe(s) and rework
> | I'd love to see a good answer to those questions. Currently, it's > | unusable as an MP3 player and that's an important use for me (if > | I could use it as an MP3 player, I'd carry it with me that much more > | often, which would in turn increase my use of it). > Lifting the can and meddling with the caps is nontrivial. Somebody did > give this plan a go on the list about 6 months ago and reported some > success though. But I don't recommend considering it unless you are in > an experimental frame of mind and can deal with the fiddling and risk > involved. I have no intention to do it myself. But if a good "how to" gets written, I could probably find someone who does have the necessary expertise. Stefan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Open IPKG packages from command line
> I have been able to extract some packages by using "tar -zxvf" after > renaming the extension to tar.gz - though I cant with all packages (and > I dont know why). Try it with `file': it will usually tell you what kind of file you're looking at. `ipkg' packages have used various formats over time, the ones I remember are .tar.gz and ar. In bith cases, the content is a few meta files plus a .tar.gz (so you stupidly get double compression if the outer wrapper is .tar.gz). Stefan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Open IPKG packages from command line
> AFAIK file should return you a 'debian binary' file format for ipk > packages now. Duh, it does now indeed. I can see why it can be useful, but for it would also sometimes be useful to know that it's a "subtype" of `ar'. Stefan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [debian] Installing *.ipk/*.opk part 1: Dependencies
> "Rask" == Rask Ingemann Lambertsen writes: >When installing opk/ipk packages from e.g. http://www.opkg.org/, there > will be problems with unmet dependencies because Debian uses other > package names for some of the packages providing the dependencies. I've > created a few small packages which create a mapping of the package names so > tricks like --force-depends/--ignore-depends should not be necessary. See: > http://nospamnospam.homepage.dk/software/download/oedepmappings/ >It works as a repository too if you run this as root: > # echo 'deb http://nospamnospam.homepage.dk/software/download/oedepmappings/ > /' >/etc/apt/sources.list.d/ril-oedepmappings.list You might want to add a note about it to http://wiki.debian.org/DebianOnFreeRunner (or maybe http://wiki.openmoko.org/wiki/Debian). Stefan PS: I wish those two pages were merged into one. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [debian] Installing *.ipk/*.opk part 1: Dependencies
>> When installing opk/ipk packages from e.g. http://www.opkg.org/, there >> will be problems with unmet dependencies because Debian uses other >> package names for some of the packages providing the dependencies. I've >> created a few small packages which create a mapping of the package names so >> tricks like --force-depends/--ignore-depends should not be necessary. See: >> http://nospamnospam.homepage.dk/software/download/oedepmappings/ >> It works as a repository too if you run this as root: >> # echo 'deb http://nospamnospam.homepage.dk/software/download/oedepmappings/ >> /' >/etc/apt/sources.list.d/ril-oedepmappings.list > You might want to add a note about it to > http://wiki.debian.org/DebianOnFreeRunner (or maybe > http://wiki.openmoko.org/wiki/Debian). Also, it would probably be preferable for those packages to have a name that makes it clear that they're not "real". E.g. you might call them something like "adapter-opkg-", and then have them provide the required feature. Stefan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [debian] Installing *.ipk/*.opk part 1: Dependencies
>>> Nice it would be grat in future if we (debian users) could just add opkg >>> repos as deb ones... maybe with different priority... it may be difficult >>> and risky, but indeed useful! > Wouldn't it be much easier to just create real debian packages? Well, since [io]pkgs can be found in all kinds of places, it would definitely be preferable to just be able to install [io]pkgs directly without depending on the willingness to make a .deb variant of it. Of course, another option is to create a tool like Alien that takes a .[io]pk and turns it into a .deb. Most likely such a tool would mostly tweak the architecture tag and adjust a few dependencies. Stefan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Thinking deeply about cofundos.org
> As a matter of fact, I'm convinced donations to Free Software, through > Foundations, could be one of the best approaches to support FS > development, if governments had laws allowing donations to be somehow > deductible to taxes. But I have yet to see the FSF, FSFE, ONU, etc, to > lobby for this concept. AFAIK, the FSF is registered "non-profit organization" so that donations to the FSF are tax-deductible (but that only applies to the US, of course). Stefan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: "Multitouch" on FR ... imho should be possible to mimic
FWIW, there's another source of info that might be used: jitter. When you have two fingers pressed, not only the reported position is more-or-less the middle point, but it's also jittery. So you could detect such jitter as a tell-tale of "multitouch" and then use the jitter itself (orientation and magnitude) as an indicator of the actual position of the fingers. Whether it would be sufficiently reliable to be used, I don't know. Stefan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Cellhunter] no offline log any more
>> Cellhunter tries to read out your $HOME variable. when NOT set it goes >> to /home/root (line 536) > that seems to be a very strange fallback > - where is root's home below /home/? so far i've seen it in oe only > - why is the user "root" assumed? > a sane fallback would be /tmp, which usually exists everwhere and is r/w > for everyone. No, a sane fallback would be to signal an error and exit. Stefan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: "Multitouch" on FR ... imho should be possible to mimic
> Unfortunately, the jitter has many interpretations. > * The user is moving the fingers apart > * The user is moving the fingers together > * The user holds the finger still, but pressure varies I think the jitter you should see with multitouch should be quite different from finger moves: much higher frequency. Stefan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Cellhunter] no offline log any more
>> No, a sane fallback would be to signal an error and exit. > that's no fallback -- that's an exit strategy. For a problem detected at startup, it's much better than a bogus fallback. After all, a missing HOME envvar, or a $HOME that points to a missing directory is the result of a misconfiguration that needs to be fixed in any case. Stefan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Configuring neo as a Bluetooth Headset to SIP client
> I want to configure neo as a bluetooth headset for my linux PC SIP client so > that i can receive my VOIP calls on my neo speakers and i can talk with my > neo microphone! Interesting. I wonder, tho: why do you prefer such a setup over one where the FR itself runs the VOIP program? Stefan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Qt Extended] debian image
> i have uploaded the debian based rootfs here [1]. All the patches > to QTE Improved GIT were sent on this list yesterday. Nice. The next step is to package QtE so it can be installed via apt-get. Stefan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Qt Extended] debian image
> Yes, i was thinking exactly the same. There are some things that > have to be solved cleanly before this can be done. E.g. the udev > rule for GSM modem. I have described it in my howto. The udev rule seems easy to fix: rather than put it in /media/card/etc/udev/rules.d/50-udev.rules, put it in a new file /media/card/etc/udev/rules.d/50-qtextended.rules Stefan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Sean's speech at ESC about making a 3G device
>> He also explains what it would take to put 3G in the phones, saying >> that they'd do it (but the 3G part would be closed) if a customer put >> in a large enough order (ie 50,000 units). > You've just convinced me that, unless this changes, no OpenMoko with 3G > will get my money as far as I'm concerned :) IIUC there's no hope on the horizon to get a non-closed phone device (whether 2G as in the FR, or any other cell-phone technology), so that the 3G part would be closed is not any different from the closedness of the GSM/GPRS in the FR. I.e. it would suck, but not more than what we already have. Stefan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Sean's speech at ESC about making a 3G device
> Regardless of what you produce as Plan B, even if it's a hair didn't you mean: especially > straightener, I'll buy one. ;-) -- Stefan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR-Unstable] opkg upgrade fail
> Yeah, I get that much, but what do I put into it? :P "google swap /etc/fstab" should give you the necessary info. Stefan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Intone-video problems!! Help !
> From what I understand, mplayer can take over a full window given it's > id. I don't know how to make mplayer take over part of a window. IIUC the "window id" passed to mplayer does not have to be a top-level window. Stefan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Command-line Yaouh! clone
> It'd also be nice to have an option for automatically "zooming out". > That is, if I have a bunch of tiles at zoom 15 (downloaded using > tangogps perhaps) then I want the zoom 14 tiles covering the same area, > as well as the zoom 13 tiles, and so on all the way up to the top. > Of course, the number of tiles quickly gets lower as one goes up, and > usually hits a tile that is there already after a few levels. Yes, that would be welcome. Actually, more to the point TangoGPS's "download the view + 4 levels down" should also download the all levels above (after all, downloading levels "N and above" only take 33% more time&space than downloading level N). > If people start doing this a lot, then transparent proxies at the > various ISPs will take much of the load. :-) I haven't heard of any ISP using transparent proxies around here. > Another thing that'd be nice to have, is duplicate tile detection. > There are a lot of "sea" tiles, "empty land" tiles, and probably some > tiles containing only forest or similiar. This could save lots of space, Yes, on an ext3 filesystem, it would save 4kB per duplicate file. Personally, I'd also want to see Yaouh (or the corresponding functionality) integrated into TangoGPS (probably by first making clear that the "download" operation only fills holes in the cache and doesn't refetch things that are already cached, and then by providing a new command "refresh all the tiles in the current area (above and below)"). Stefan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [All?] Dictator - the most undemocratic recording and dictation software ever
> Would it be possible to have an option which, if set, would > * answer automatically each incomming phonecall, > * play a previously save wav file as a "I not here at the moment blabla " > welcomming message and route it so that the correspondant can hear it > * record the remote guy until he/she stops the call (we need other names for > the files recorded, as -MM-DD_HH-MM_voicebox.wav) > I do not know it this must be implemented in Dictator, as it is a bit far > from a "dictator" function, but yeahhh, this would be great ! Seems like what you want is to route the GSM to Asterisk. Stefan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Theora 320x240 - is it possible?
> i would like to distribute in my rootfs video player that can play > theora videos in fullscreen mode 320x240. I'd also like a way to play Theora&Ogg videos fullscreen. > I was experimenting with mplayer on with fbdev as video output, but > i was able to play just very small resolution video (160x120). I used > ffmpeg2theora for encoding and mplayer from debian. You'll first need to make sure that your mplayer doesn't use floating-point audio playback, otherwise this will overwhelm everything else. Also you may need to reencode your videos at lower frame rates. Stefan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
[OT] Re: OpenMoko and LCD TV
>> They run Linux on TVs now?? What kind of processing is a TV doing that >> needs an OS overseeing it? > I think it started with MHEG engines for DVB, and EPG. Next they > started adding things like SD and USB with media viewers. This one's > got an ethernet port that's currently unused, but some use them for > streaming media playback. > The problem is the usual one - things that don't quite behave as you > want them to, or functions the hardware's capable of but they > haven't implemented. Is the firmware's source available somewhere? Stefan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR] emacs package
> It's been asked before but I can't find any references to a package > for Emacs. Does such exist? If not, how can I get Emacs running - If you run Debian on your FR, then you can just "aptitude install emacs". > doesn't need to be xemacs as I'm quite happy to run it either in > terminal or via a remote session. Not sure what you mean by that, since Emacs is not just a terminal application. Maybe you're one of the few remaining victims of the confusion "XEmacs is Emacs for X"? Stefan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR] emacs package
>> It's been asked before but I can't find any references to a package >> for emacs. Does such exist? If not, how can I get emacs running - >> doesn't need to be xemacs as I'm quite happy to run it either in >> terminal or via a remote session. > I install joe which includes jmacs an emacs-like editor. I also recommend Zile if you're looking for a "poor man's Emacs". Among the "small emacs-like editors", it's the one that's closest to the real thing (both visually and in its behavior). Stefan PS: And on my Debian-i686 desktop, Zile is about 1/3 the size of Joe. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR] emacs package
>>> It's been asked before but I can't find any references to a package >>> for Emacs. Does such exist? If not, how can I get Emacs running - > Use vim in stead! It's been a long time since I last looked at it, but AFAIK Vim's emulation of Emacs is at best very poor. Stefan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Mokomaze as non-root
What are we supposed to do to get Mokomaze to run as a non-root user? Stefan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [debian] Installing *.ipk/*.opk part 2: apt-get-file
> debian-gta02:~# apt-get-file install > http://projects.openmoko.org/frs/download.php/575/ledclock_0.6_all.ipk > trap: 26: ERR: bad trap > Any clue ? The script uses /bin/sh but actually relies on bashisms, so if your /bin/sh is actually something else (like dash, according to my crystal ball), you need to tweak the script with a patch such as the one below. Stefan === modified file 'apt-get-file' (properties changed: -x to +x) --- apt-get-file2009-05-10 19:41:44 + +++ apt-get-file2009-05-10 19:47:27 + @@ -23,9 +23,12 @@ exit 1 } -trap exit_clean ERR -set -o errexit -set -o errtrace +# Bashisms. +#trap exit_clean ERR +#set -o errexit +#set -o errtrace +# For Dash. +trap exit_clean ILL QUIT SEGV HUP 0 if [ "--verbose" = "$1" ]; then shift ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New Life in Openmoko Phones
> For me, I think you've hit the nail on the head. We're trying something > new with gta02-core, and by working on the small changes we've proposed > we can focus on the tools that we use, the organisation of individual > contributors and the stages we need to go through to get functional > hardware. Doing gta02-core means that we should be able to move forward > fairly rapidly and shake out any problems as we go. For that aim, the > specific changes we make are almost arbitrary - and as stated on the > wiki we don't expect this to turn into production hardware. That still doesn't explain why removing one of the two accelerometers is a good idea. What is the benefit? Why not remove them both? Is it that all the programs that use the accelerometers (as of now) only use one of the two? Is it that having two accelerometers introduces layout difficulties? Is it that there aren't enough interrupt lines on the SoC to properly support the two accelerometers? ... Since it was decided to remove it, there must have been some kind of expected benefit. I actually have the same question for the audio-amp: why remove it? But that one is a bit more complicated, because I'm not sure what is this "audio-amp" anyway (is it the thing that drives the headphone plug?) Stefan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: root almighty
> As far as I know most (all?) distributions for FR use root account to > run phone application and to access device via ssh. To my mind this > introduce great security risk. The Debian distribution works with a non-root user. Stefan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [GPS] new GPS GUI application for OM freerunner
> After nearly 5 months development, I'm happy to announce the first alpha > release of omgps. Looks like a great alternative to TangoGPS. I like the ability to write on the map and save it as a screenshot. But I would even prefer a way to take notes via the microphone and/or the keyboard, automatically associated with the current GPS position. Stefan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Buzzing
>> Also, I know everyone loves X, but is it really the best choice for a low >> powered device that needs a responsive UI? X used to be a resource hog. But that was when processor speed was measured in MHz and with a single digit (and RAM was measured in MB and also with a single digit). For the FR, it seems to be a very good choice. Stefan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Flashing Neo
> Is there a problem if i flash my neo too many times? because i have done > around 20 times in a week time.. Be careful: at this rhythm, your flash will only last ... another 1000 weeks (or maybe 1 if you're lucky). Stefan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Font size problem #2
>> The correct solution is to decide that "dpi" means "pixels per >> apparent inch." Because we look at the FR from much closer than we >> do a desktop screen, the dpi that we set in /etc/X11/xorg.conf >> should be somewhat less than the physical pixels per inch. >> >> I estimate that I see a desktop screen from about 25 inches, and the >> FR from about 10 inches. So the FR should be set to about 110 >> dpi. This would have about the same effect as using a font size of >> 5 points. I'm not 100% sure that it's "The Correct Solution", but I do think it's the best solution and I indeed start my Xglamo with "-dpi 100" for that very reason. > I believe introducing the "apparent" factor would create a huge mess > instead of solving it. There would be no reliable way to tell how much > is an inch - for example displaying a ruler with correct scale would > be impossible. The strength of DPI is its ability of being measured. > I have another solution of the problem - the toolkits of the clients > asking the server about the preferred font size similar way they ask > it about the resolution. I think it would not be possible or feasible > to ask exactly the same way (does the X server expose preferred font > size the same way as DPI?). The client-side apps might contact the > corresponding server-side toolkit, which they already do (I noticed > irregularities while connecting to a host with an old version of > GTK). This would, however, require patches to the toolkits... The problem is that many programs use "inches" not as a way to talk about the size as measured on the screen (i.e. physical size), but as a way to talk about the size as seen by the user (i.e. visual size). Currently, those two issues are completely conflated (at least for all apps I'm familiar with, under X11). So there's no way to fix one without breaking the other. As it happens, I look at objects on my screen a lot more than I measure them, so I don't care about the physical size of pixels nearly as much as I care about their visual size. So I ask my FR's X server to lie about its pixel density. I originally tried to just adjust the font size, but it's a lot more painful: font size is set at too many places, including at places over which I have no control (e.g. web pages). In theory setting DPI to 100 is the wrong solution, but in practice it seems to be the best one. Stefan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: axfs
> i don't know if this topic was already a discussion, but i think, if > openmoko could change to axfs, i belive, it's a great performance-step. Problems with it: - axfs is read-only, so you'd need to use a setup similar to OpenWRT with a axfs filesystem containing "the base system" plus a jffs2 filesystem layered on top (using some variant of unionfs). - its main attraction is the XIP feature, but this only works with NOR flash. We do have some NOR flash, but it's only 2MB (IIUC) and it can only be flashed with the debug-board, so the potential benefit is slim and restricted to those users who bought the debug board. Using axfs+jffs2 might be an option, where the main benefit would be to save some space on the flash drive, but currently the 256MB of flash is rarely a significant limitation (especially if you're careful to keep only application in the NAND and put all your data/images/sounds in the microSD card). Actually, the one place I know where the 256MB of flash is a bit short is when installing Debian there, but using axfs+jffs2 with Debian would be a fair bit of extra work and would often defeat the purpose of using Debian in the first place. Stefan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Survey about the Touchscreen
> And I'm not sure that multi touch is really so important and the low res I do not know if it's important, but being restricted to events of the form mouse-1-down, mouse-1-up, and mouse-move is problematic in my experience. So if we can't have multi-touch sensitivity, we need some other source of input. It could be buttons on the sides (e.g. I could imagine a phone where you use one hand for the touchscreen while the other hand holds the phone and can squeeze it to generate a "modifier" kind of event). For usability, I think it's important that this other source of input be usable at the same time as the touchscreen is used to move the cursor (so you can get similar effects as the 2-finger scroll, for exemples, or the mouse-3 context menus) so it probably would have to be activated by the other hand. Stefan PS: I'm not even considering single-handed use. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Survey about the Touchscreen
> Me too, high-res is all good.. But high-res does NOT preclude the use of Actually, the high-res is one of the highlights of the FR for me. So, while I don't need 280dpi, I wouldn't settle for less than 200dpi for a gadget I hold so close to my eyes. Stefan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [debian] sources
> You can of course install Debian stable on your FreeRunner, but it won’t > contain any OpenMoko-specific software. I'm running fso-pkg (unstable) alongside plain Debian testing. Stefan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [debian] sources
> deb http://ftp2.de.debian.org/debian testing main > deb http://ftp2.de.debian.org/debian unstable main > deb http://pkg-fso.alioth.debian.org/debian sid main More like deb http://ftp2.de.debian.org/debian testing main deb http://pkg-fso.alioth.debian.org/debian unstable main Stefan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko keyboard mockup
> [1] - which is ironic given that they were invented to encourage people to > publish their ideas rather than keep them secret. Actually, not so ironic: it basically means that rather than keeping them as internal secrets, they get to lock them in a government-provided vault. IIRC, the history of patents is a bit more interesing than people think, and the end result's paradoxes are not as unintended as you'd think. But it really should be expected: just as is still the case now (if not even more), the (potential) holders of big patent portfolio had a lot of leverage. Stefan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: stupid networking question
>> It looks now like that: >> >> auto lo >> iface lo inet loopback >> >> # freerunner >> auto usb0 >> allow-hotplug usb0 >> iface usb0 inet static >> address 192.168.0.200 >> netmask 255.255.255.192 >> post-up /etc/network/freerunner start >> pre-down /etc/network/freerunner stop > You should only use "auto usb0" or "allow-hotplug usb0" but not both at > the same time. Why not? "auto" is the same as "allow-auto" and nothing says you can't have "allow-toto eth0" and "allow-tata eth0" and "allow-titi eth0". So if you have both "allow-hotplug" and "auto" for the same interface, it just means you want to bring it up at boot and you also want to bring it up when it gets plugged in. Stefan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [hackable1] Working mouse "out of the box"
> I need to check how much mA does it takes, any ideas how can I do that? cat /proc/bus/usb/devices should give you that info. Stefan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [All] To build a better music player
> 1) Improved responsiveness, especially with regard to starting the > next song in a play list. > 2) Lowered processing overhead during main update loop. > 3) Tweaked the GUI. Most notably, the buttons are larger. > 4) Read ID3 tag info at play list load time using python ID3 library. > 5) Optionally (default true) disable suspend through enlightenment > while song is playing. Change the no_suspend option in the [mplayer] > section of /etc/pythm.conf. > 6) Automatically pause playback when phone call received, resume on > hang-up. Only if running on FSO-based framework (not qtopia > phone-kit). > 7) Hook directly into alsa for setting/getting the volume. > 8) Tweaked nice levels for more consistent playback. I think issues 1 and 4 are fixed for free by using the MPD backend. I highly recommend it. It probably affects 2 as well. Stefan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: which file system for sd card?
> Anyway, I'm also inclined for FAT, mostly for the simplicity (thus "less > susceptibility to corruption") and universality of the fs. I'm just left I'd stay away from FAT: its simplicity makes it less susceptible to software bugs, maybe, but still susceptible to corruption. The general recommendation is to go with ext3 (ext2 is more likely to get corrupted on crash or power loss, and fsck is a pain in the rear). The potential performance (and wearout) issue with the journal is only theoretical. Stefan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [All] To build a better music player
> I am still in the process of making changes, but I have some packages > if anyone wants to try it. This version has the option of using a > gstreamer back-end (the default with the packaged config file) instead > of mplayer. By using gstreamer, CPU and memory load have been reduced, > and I was able to rig it such that track transitions occur without the > delays that were present using mplayer. Furthermore, I added tag > reading support for Ogg and Flac through mutagen. I still wonder: what's wrong with the MPD backend? It already did all that, and is very memory efficient as well. Stefan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [All] To build a better music player
> 2) I would have liked to use mpd, but I have never been able to find a > package for it for arm. It is not feasible to stream from a server, > since I listen to music in my car. Hmm I'm under Debian where I just "apt-get install mpd". But `mpd' is packaged for OpenWRT and AFAIK there's also one for OpenEmbedded, so it should be easy for someone setup with OpenEmbedded to build the corresponding opkg. Stefan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Setting up MPD (was: [All] To build a better music player)
> In my experience, MPD is a pain to set up. Hmm... that's probably something we can improve. I had no trouble with it but then it wasn't the first time I set it up: could you give us some hint what was difficult? Stefan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Setting up MPD
> Ahh, just when I want a media player, the last thing I usually want to do is > edit conf files. The only thing that should need specifying in this file should be the directory where the songs are kept. What else did you have to edit? > Then, I had to find a client, and perhaps I got a bad one (I don't > remember which I used) but it was pretty tough to pair the two. Yes, MPD clients aren't great in my experience (there's a lot more quantity than quality). But Pythm isn't bad. > After that, I had no control of the playlist, it just played my whole > collection alphabetically. Hmm... sounds odd. It reminds me of the brain-dead /etc/init.d/mpd used in the `mpd' package of OpenWRT (I have sent a patch for it, but it hasn't been accepted/applied yet, don't hold your breath). Normally, the playlist is pretty straightforward to manage, so you must have hit some weird default setup. How did you install/start this `mpd'? Stefan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Wiki page - which file system in sd card?
> done on the FR. Therefore, I'll edit the page with "opinions are > divided" regarding reliability and "no objective comparisons yet for > other criteria". It'd be much easier to just punt on the whole issue and say "same rules apply as for any other Linux system". Stefan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [All] To build a better music player
> Before, mplayer took 40%-50% of cpu according to top. > Now, pythm-bin uses 48%-49% instead. This when playing stereo .ogg Still sounds much too high. Even my home router (266MHz MIPS) decodes .ogg with less than 30% of CPU. Usind `mpd', my FR shows significantly less than 20% CPU decoding .ogg files (tho admittedly, these are 96Kb/s, so maybe that helps). I haven't tried again recently (among other things because the headphone output is so lousy), but there's no reason for it to be higher than 20%, unless maybe there's some resampling going on, or some floating-point software-mixer somewhere. Stefan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Annuncing new Project - Intone mplayer frontend
> files. All that was required was a frontend for it! I know pythm is just > that, but my Neo uses more than 30% CPU with it. It could be a minor bug - I'll just remind people here that pythm also works with MPD. If you use the MPD backend, it works very efficiently (probably the same as what you see with your mplayer+intone). The other advantage of MPD is that you can control it from anywhere since the communication between the frontend and the backend is over a TCP/IP connection. E.g. you can use your FR's pythm as a remote control for your other machines's MPDs (I have an MPD running on a small server at home, turning it into a jukebox). Stefan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
