Re: Fast questions about GTA03
On Saturday June 28, [EMAIL PROTECTED] wrote: I was thinking of asking the very same thing. When dialing or using a calculator or sending a text message, the glamo would only slow us down. Or am I mistaken? Maybe it's a very stupid question (I presume if it were possible such a trivial feat would already be implemented). The glamo is the video controller. If you disable the glamo, you don't get any picture. NeilBrown y On Sat, Jun 28, 2008 at 11:21 AM, Atilla Filiz [EMAIL PROTECTED] wrote: Can we just disable glamo with software and use it only when profitable? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: rationale for ASU (and change from GTK to Qt)
On Saturday June 28, [EMAIL PROTECTED] wrote: I have to say that I find it a bit odd running X11 on a mobile phone - a WM wouldn't be required without it - when an alternative is possible. In fact, as far as I can ascertain an alternative already exists. X11 seems logical to me for desktop computers, but not for a device which will only ever have one main window on the screen at a time. I had mistakenly understood earlier Openmoko builds to be non- X11 (i.e. qtopia-ish?) Saying we don't need X11 because we only have one window is a bit like we don't need a multitasking operating system, because we only have one user. It just isn't that simple. If all that X11 does for us is to allow switching between concurrently running programs, written against different toolkits, then that is a very useful thing. I would hate for someone to be turned of writing an app for Openmoko because the toolkit they liked wasn't supported, so I think it is very important to support qt and gtk (and tk and ...). The only way to support multiple toolkits today is with an X11 server. X11 allows freedom of toolkit choice, and freedom is what we are all about. NeilBrown ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPS rework: Please test and report on software fix prior to attempting any hardware fix
On Tuesday August 5, [EMAIL PROTECTED] wrote: For a bit more consistency of timing, less manual intervention, and enough readings to get an idea of the run to run variation in that location, can I suggest a script? It could do with a timeout when waiting for a fix since with deivestrength 3 and idleclk 1 this can take a _very_ long time, possibly forever in some locations! Thanks for the script. After wondering for a while why it didn't work at all for me, I added stty min 1 /dev/ttySAC1 because either frameworkd in FSO or openmoko-agpsui did an stty min 0 /dev/ttySAC1 and that caused grep to exit immediately. Anyway, I haven't let it run completely yet, but the first result is d i time 0 0 real 9m 52.15s Yes, nearly 10 minutes. This is indoors, but I have had problems getting a GPS fix everywhere, inside, outside, in a car, in the park. Once it fixes it tracks OK (though it doesn't recover from going into a shopping complex and coming out again). It seems a lot like the originally reported problem, but this is with a kernel that has the fix and the magic sysfs files: Linux om-gta02 2.6.24 #1 PREEMPT Tue Jul 29 01:19:38 UTC 2008 armv4tl unknown I have the wireless going, but GSM is possibly turned off as I killed frameworkd to make sure it wasn't touching the GPS. I know someone who I trust to solder the capacitor - should I try that (if I can get hold of him)? Another result just came in: d i time 0 0 real 9m 52.15s 0 1 real 8m 29.79s These numbers are actually pretty good. openmoko-agpsui was giving me 1000 or 2100 seconds! I decided to take out the SD card (and the SIM card) and try again. (just chat quietly among yourselves while we wait for the first result). d i time 0 0 real 5m 14.32s 0 1 real 2m 56.78s 1 0 real 5m 37.79s Well, that wasn't so bad. But still not what I hoped for. I'm wondering if I got a lemon :-( NeilBrown ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPS logger / field data collection
On Monday August 18, [EMAIL PROTECTED] wrote: I was kind of surprised that gpsd didn't give me a simple way to just get the current location, I had to capture 5 sentences to do that simple thing, but what I really wanted was to simply get the last known lat and long I was at. With the data logger I can presumably do that by getting the last entry of the log. from the man page for gpsd p Returns the current position in the form P=%f %f; numbers are in degrees, latitude first. $ telnet tangogps.org gpsd Trying 82.240.156.91... Connected to tangogps.org. Escape character is '^]'. p GPSD,P=43.739028 7.364333 ^] telnet q Connection closed. 43 degrees north, 7 east. NeilBrown ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QTopia full screen handwriting on OM2008?
On Monday September 1, [EMAIL PROTECTED] wrote: Hello, According to Trolltech's documentation ( http://doc.trolltech.com/qtopia4.3/inputmethods-description.html), QTopia supports handwriting recognition. Is there some way to get handwriting recognition to work on the OM 2008 distribution? I don't want to start a discussion about the pros and cons of virtual keyboards, but I've been happy with the 'handwriting' recognition on my Sony Ericsson P910i, and just not having a keyboard covering half the screen would be nice. I'm working on it whether I'll ever finish is uncertain though :-) What I currently have is a little scribble pad application with handwriting recognition built in, so if you tap somewhere you can start drawing letters and digits and they are added to the scribble pad page as text. git://neil.brown.name/scribble/ This is largely just to test and experiment with handwriting recognition. I'm in the process of re-writing the recognition code so that it (hopefully) makes fewer mistakes. It currently gets confused between l (drawn like L) and e, has trouble recognising 8 and v, and various other little issues. But I find it usable. Then I'll put the recogniser into a program that grabs all touchscreen events and feeds them back as either key strokes or stylus events. My initial plan is that: - a tap goes straight through as a mouse click - a stroke is interpreted as a written symbol - a tap-and-drag (like you can do in a notebook's touchpad) becomes mouse movement - a vertical stroke in the right 1/3 of the screen becomes a scroll-wheel event. I don't know how the tap-and-drag will feel - it might be too frustrating. Eventually (if I get that far) I'd like to have a little widget in the illume status bar to allow selection of abc/123/stroke. But that will be much later. NeilBrown ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
python upgrade in fso-testing broken ssl TCP connections....
Hi, I use the http://downloads.freesmartphone.org/fso-testing/ and so recently python got upgraded from 2.5 to 2.6. This broke pygtk as that is still expecting python-2.5 to be present. but it isn't. I fixed that with a few symlinks, but problems continued. In particular, 'ssl.py' doesn't exist, so when urllib tries to import ssl, it fails, so I cannot make https: requests. Can this (And the pygtk version) be fixed? Anything I can do to help? Thanks, NeilBrown ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Dialup On Demand (was: [SHR] Miscellanious minor issues)
On Saturday January 31, freerun...@newkirk.us wrote: What about (which I expect will not be a candidate for an 'official' solution;) get frameworkd talking to ip_queue or netlink. For example, we could: Create a lowest-priority default route that hits lo, like: route add default gw 127.127.127.127 dev lo metric 100 use ip_queue.ko. Write a userspace handler for the iptables QUEUE target. (It's been a few years but I've written a couple, in c, use libipq - pretty simple) The handler will receive every packet that is sent to it with a firewall rule like: iptables -A INPUT -d ! 127.0.0.0/8 -i lo -m limit --limit 1/sec -j QUEUE iptables -A INPUT -d ! 127.0.0.0/8 -i lo -j DROP Now whenever another route doesn't exist, the kernel presents outbound packets to the queue handler. (up to one per second, and unspecified --limit-burst is 5 - the second rule drops what doesn't get queued) The handler gets to tell the kernel whether to accept or drop the packets, in this case it'd be simplest probably to drop them. In the meantime, however, it can tell the network manager (or whatever mechanism) to try to bring up an interface. If that's successful then its newly-created route takes precedence. (providing it has a lower metric than 100...) I've never played with ip_queue so I cannot say. You may well be right that a solution lies that way as well. However if I understand it correctly, it relies on the kernel retransmitting packets after the new routes are set up. I think that is likely to introduce more delay that might be acceptable. As soon as the link come up we really want to re-introduce all packets that were captured so that the network seems as responsive as possible. Though I may be misunderstanding you suggestion. There is an interesting complication that I was reminded of when I tried to knock up a quick-and-dirty proof of concept. An important aspect of any solution is that you need to set up masquerading (or Source NAT) so that packets from the internal address get the source address re-written on the way out. However SNAT mapping are set up when the first packet in a connection is seen. So if we capture the first packet of a connection, then set up an external interface, it is now too late to do source NAT for that connection. It can work for new connections without trouble, but that first connection is stuck. I think(hope?) it might be possible to use the NOTRACK target in iptables to exempt all packets from connection tracking until the external like is up and the default route and been redirected. I only learned about NOTRACK today and have not experimented with it so I cannot be sure, but it does seem to be a perfect fit for this problem. It can also take a moment to examine the packets it's handed and decide - based on whatever criteria desired - if it really needs to bring up an interface or not. Like if it's DNS fire it up, but if it's broadcasts just ignore it. (those criteria could be handled in iptables actually, but others would be harder, the things that frameworkd can offer like is a voice call in progress? [if so, forget gprs] or am I preparing to suspend?, etc) Yes, being selective about which packets can trigger a network connection would be a valuable feature. NeilBrown ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Accelerometer Data
On Sunday March 22, charles-henri.gros+openm...@m4x.org wrote: Iain B. Findleton wrote: I have been playing a bit with the accelerometers on the FR appear to observe the following: 1) The time stamp on events appears to be unreliable, in the sense that the time difference between sequential events is frequently negative, and appears also to be have erratically by jumping an order of magnitude or 2 between sequentially available events. 2) It also appears to be relatively common that a SYN arrives before all 3 axis values are available, making it hard to figure out the meaning of the data I've seen that too; it seems that '0' readings are discarded. That is because the device reports REL events. In the latest andy-tracking it reports the more correct 'ABS' events. So now it does report zeros. However it doesn't report an axis if there has been no change. If you want to simply get the current values there is an ioctl : EVIOCGABS I think. NeilBrown ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Accelerometer Data
On Monday March 23, michael-tanse...@gmx.de wrote:
In the latest andy-tracking it reports the more correct 'ABS' events.
So now it does report zeros. However it doesn't report an axis if there
has been no change.
Is it correct that there are now two changes for developers. The first one is
that the EVENT type has changed from EV_REL (0x02) to EV_ABS (0x03). This
would mean in the python sample code of the wiki the change would be:
from:
if type == 2:
if code == 0:
x = value
if code == 1:
y = value
if code == 2:
z = value
to:
if type == 3:
if code == 0:
x = value
if code == 1:
y = value
if code == 2:
z = value
Or
if type == 2 or type == 3:
...
then it would work on both old and new kernels.
The second change is that if no new (y,x, or z) value is reported the old one
should be taken.
Correct. The code you have given does this already, providing that x,
y, and z persist between calls to that code.
If you want to simply get the current values
there is an ioctl : EVIOCGABS I think.
I think that is what most developers want. It would be great if someone could
show a small sample code how this works.
In C it is simply:
#include linux/input.h
.
.
.
struct input_absinfo abs;
ioctl(fd, EVIOCGABS(ABS_X), abs); x = abs.value;
ioctl(fd, EVIOCGABS(ABS_Y), abs); y = abs.value;
ioctl(fd, EVIOCGABS(ABS_Z), abs); z = abs.value;
In python it is a little harder because you need to make your
own EVIOCABS()
Something like...
import fcntl, struct
_IOC_WRITE = 1
_IOC_READ = 2
_IOC_NRBITS = 8
_IOC_TYPEBITS = 8
_IOC_SIZEBITS = 14
_IOC_DIRBITS = 2
_IOC_NRSHIFT = 0
_IOC_TYPESHIFT = _IOC_NRSHIFT + _IOC_NRBITS
_IOC_SIZESHIFT = _IOC_TYPESHIFT + _IOC_TYPEBITS
_IOC_DIRSHIFT = _IOC_SIZESHIFT + _IOC_SIZEBITS
def _IOC(dir, type, nr, size):
return ( (dir _IOC_DIRSHIFT) |
(ord(type) _IOC_TYPESHIFT) |
(nr _IOC_NRSHIFT) |
(size _IOC_SIZESHIFT))
def EVIOCGABS(abs):
return _IOC(_IOC_READ, 'E', 0x40 + abs, 5*4)
ABS_X = 0
ABS_Y = 1
ABS_Z = 2
def get_abs(fd, code):
buf = struct.pack('i', 0, 0, 0, 0, 0)
abs = fcntl.ioctl(fd, EVIOCGABS(code), buf)
(val,min,max,fuzz,flat) = struct.unpack('i', abs)
return val
fd = open(/dev/input/event2)
x,y,z = get_abs(fd, ABS_X), get_abs(fd, ABS_Y), get_abs(fd, ABS_Z)
print x,y,z
which could, of course, be cleaned up and put in a class or two.
NeilBrown
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: Accelerometer Data
On Monday March 23, ifindle...@videotron.ca wrote:
Okay, it looks like the 2.6.28 kernel and modules are an improvement for
the accelerometer data, but the report times, while not negative any
more, appear somewhat erratic. The type codes appear to be unchanged in
this build, with the driver reporting EV_REL and EV_SYN.
The time codes should be very reliable, and should be spaced at 10ms
intervals as the device interrupts at 100Hz (by default).
Each open file on the /dev/input/eventXX device has an internal buffer
of 64 entries. If your application is not able to read fast enough to
keep that buffer from over flowing, then you will occasionally loose
chunks of 64 entries (and so see gaps for 640 ms).
However this is not what I see. If I measure the time between EV_SYN
reports for 1000 such reports, I get a histogram like
freq ms
805 10
136 20
34 30
11 40
1 41
4 51
5 61
1 71
Which isn't what I expected. No over-runs are being reported, and
there are no 640ms gaps, so the internal buffer isn't wrapping.
(goes and reads code again...)
Ah. If none of X, Y, or Z change, then EV_SYN won't be reported
either. So this presumably shows that there are times when the
accelerometers think the device is completely stable - nothing
changing.
If the device were reporting EV_REL events, then you could only lose
EV_SYN events if all three axes reported 0, which means perfect
free-fall. That seem unlikely...
I have a patch which I'm in the middle of writing which makes the
'sample_rate' sysfs setting more useful. Instead of just '100' or
'400' you can have any other (smaller) value, and it samples the
accelerometers at that rates. So e.g. '10' with give 10 samples per
second, and '0.1' will give one every 10 seconds. When I get up to
testing that I'll make sure that it delivers properly times events.
You do similar histogram-generation tests yourself by:
wget http://beagleboard.googlecode.com/files/evtest.c
cc -o evtest evtest.c
./evtest /dev/input/event2 | grep Sync | awk '{print int(($3 - prev)*1000) ;
prev = $3}' | sed 1000q | sort | uniq -c
I would be interested to see what you get using a kernel that
reports EV_REL events.
'evtest' is a very useful program for experimenting with the various
input devices.
NeilBrown
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: Accelerometer Data
On Monday March 23, ifindle...@videotron.ca wrote: Charles-Henri Gros wrote: A known issue in 2008.12. http://docs.openmoko.org/trac/ticket//2145 Workaround: echo 10 /sys/devices/platform/lis302dl.1/threshold ls /sys/devices/platform: They seem to move around a bit.. debian-gta02:/tmp# find /sys | grep thresh /sys/class/i2c-adapter/i2c-0/0-0073/spi_s3c24xx_gpio.0/spi3.0/threshold /sys/class/i2c-adapter/i2c-0/0-0073/spi_s3c24xx_gpio.0/spi3.0/wakeup_threshold /sys/class/i2c-adapter/i2c-0/0-0073/spi_s3c24xx_gpio.0/spi3.1/threshold /sys/class/i2c-adapter/i2c-0/0-0073/spi_s3c24xx_gpio.0/spi3.1/wakeup_threshold or debian-gta02:/tmp# p=*; while [ `eval echo /sys/$p/threshold` = /sys/$p/threshold ]; do p=$p/* ; done ; echo /sys/$p/threshold /sys/bus/spi/devices/spi3.0/threshold /sys/bus/spi/devices/spi3.1/threshold So look under /sys/bus/spi/devices/spi3.x I wonder what 'spi' means... NeilBrown ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: SHR-U Accelerometer data
On Thu, 17 Dec 2009 12:32:46 -0500 Iain B. Findleton ifindle...@videotron.ca wrote: Let me remind you that the driver has changed wrt. RELATIVE and ABSOLUTE. These days, upon opening the device, only the first report is a full report. Subsequent reports only contain changed axes. I got that about the ABSOLUTE. The changes only thing does not look to come from the driver code. Is that something associated with the linux input system interface? Yes - for absolute events, the linux input layer only forwards them when they change. You can get the current values at any time using an 'ioctl'. EBIOCGABS returns a 'struct input_absinfo' - see /usr/include/linux/input.h NeilBrown ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Alternatives to FR
On Mon, 04 Jan 2010 01:12:54 + William Kenworthy bi...@iinet.net.au wrote: What alternatives to the FR (with the same functionality) are there? I want 3G phone/sms access and the FR doesnt cut it any more ... The android phones (htc dream?) - none of which are fully functional on FSO/SHR (I think), and access through android to the underlying system is minimal. Flow - good but pricy, and unless I am looking at the design wrong, there is only one adapter/interface socket so you can have a phone, or a GSM device, but not both at the same time. Nokia n900 - probably the best choice at this time. What others are available NOW? http://www.exedamobile.com/ Looks like an interesting device. Not terribly cheap, and they seem to want you to buy in lots of 1000, but once you find the price page: http://www.compulab.co.il/exeda/html/exeda-price.htm it does appear that for 40% extra you can buy them in ones. Maybe $US672 with wifi, bluetooth, gsm, gprs, gps, $US32 extra for a camera. Claims (http://www.compulab.co.il/exeda/html/exeda-os-support.htm) to all work with Linux. If you buy one, let us know how it goes :-) NeilBrown ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Quick e-mail poll: Still using your Freerunner?
On Tue, 9 Feb 2010 13:17:17 -0800 (PST) Mike Crash m...@mikecrash.com wrote: No Yes Debian Yes No Debian The recent innovation of compiling the kernel with the go-slow straps removed has had a significant improvement on my experience. Now if only I could figure out why the gprs is not reliable I'd be on my way to being happy. I guess we cannot hope for the GSM firmware being made open-source... (any New Zealand residents out there? I visited NZ in Jan, bought a 2degrees SIM can and found that I couldn't send SMS messages though receiving and calls were fine. SIM worked fine in another phone. Does anyone else experience that?) NeilBrown ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: tangoGPS 0.99.3 is out
On Sat, 20 Feb 2010 22:54:02 +0100 Helge Hafting helge.haft...@hist.no wrote: Marcus Bauer wrote: Hi, tangoGPS is out with lots of speed improvements and a lot less of CPU usage. Moreover the speed display is now set in pixels and no longer in points - especially on SHR that should result in lot smaller digits. Very nice! The smaller speed digits is much better on this display.:-) I have one wishlist item still: Tangogps remembers the last position and zoom level. And it remembers if it was logging to a file the last time it was running. It'd be very nice if tangogps also remembered the status of the center on gps position setting, instead of always defaulting to not follow the gps around. I have another wish-list item for the 'auto-centre' setting. It would be great if the button was a toggle that was visually down when the setting was active, and up when it was inactive. A small thing, but it seems to bother me. Also I noticed a peculiarity which I haven't tried to reproduce yet, but: I went for a 1 hour bicycle ride with tangogps recording my path. It was set on zoom 13. When I zoomed in (to 14) to have a closer look at the path, it only showed the last half hour or so. When I zoomed it again (to 15) it was the last 15 or 20 minutes. (these are fairly rough figures). I zoom back out to 13 and I see the whole path. I this expected. An hour later (stationary the whole time, but on) the results were the same. I didn't lose any more of the path as time progressed, but I didn't get it back either. NeilBrown ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko v18 - based on 2.6.32
On Mon, 8 Mar 2010 17:16:58 +0100
Radek Polak pson...@seznam.cz wrote:
BTW. /dev/input/mice is a placeholder to make X read all kinds of mice at
once. It is supposed to simplify the configuration as you could replace
your PS/2 mouse with a USB one, a touchpad or even a good old serial
mouse. But if you know the concrete input of the Touchscreen (cat
/proc/bus/input/devices) you can enter this one into the xorg.conf.
Maybe i dont understand it correctly, but i thought that touchscreen is
different from mouse and should not appear in /dev/input/mice because it
generates absolute screen coordinates while mouse generates relative
coordinates. But that is just my impression, i havent read any docs about it
yet :)
/dev/input/mice combines multiple point-like device and generates relative
motion events. For a touch screen, it reports differences between consecutive
locations so you can use it like a touchpad.
A key data structure is in drives/input/mousedev.c and is mousedev_ids.
This data structure identifies what sort of devices will be handled
by /dev/input/mice.
It has a section:
{
.flags = INPUT_DEVICE_ID_MATCH_EVBIT |
INPUT_DEVICE_ID_MATCH_KEYBIT |
INPUT_DEVICE_ID_MATCH_ABSBIT,
.evbit = { BIT_MASK(EV_KEY) | BIT_MASK(EV_ABS) },
.keybit = { [BIT_WORD(BTN_TOUCH)] = BIT_MASK(BTN_TOUCH) },
.absbit = { BIT_MASK(ABS_X) | BIT_MASK(ABS_Y) },
}, /* A tablet like device, at least touch detection,
two absolute axes */
which means that any device which generates absolute X and Y events as well
as a key calls 'touch' is included.
In andy-tracking, this stanza has #if 0 / #endif around it.
In om-gta02-2.6.32 it does not.
That might explain the difference.
The #if hack was in there to support X servers that did not support hot-plug
of input devices, so that people could still use e.g a bluetooth mouse
(through /dev/input/mice) it they like, while also getting absolute events
from the touchscreen.
To get things working with 2.6.32 you need to do one of:
- Put the #if 0 hack back
- Tell X not to open /dev/input/mice, so you will not be able to use
e.g. a bluetooth mouse, but there will be no confusion with the
touchscreen.
- Use an X server that supports got-plug of input devices, and make sure
it doesn't open /dev/input/mice as well. This is the ideal configuration,
but last time I looked (a couple of years ago) no such X server existed.
It probably does now - you may even be using it already...
NeilBrown
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: transparency in gtk
On Thu, 25 Mar 2010 11:02:43 +0600
Chuck Norris norris.ch...@mail.ru wrote:
I need transparency in gtk under freerunner. So I compiled this code
#include gtk/gtk.h
gint main(gint argc, gchar **argv)
{
GtkWidget *window;
gtk_init(argc, argv);
window = gtk_window_new(GTK_WINDOW_TOPLEVEL);
gtk_window_set_opacity(GTK_WINDOW(window), 0.1);
gtk_widget_show_all(window);
gtk_main();
}
under my desktop and it shows transparent window. Then I compiled it for
shr-u with crosscompiler from tmp/cross folder of shr-u sources. And on
freerunner it shows not transparent window. So Is it possible to create
transparent gtk apps in shr or other distribs for freerunner? And how if
it possible?
Make sure your X server has the compositing extension loaded and run
xcompmgr.
I don't know how this works on shr exactly. On Debian using nodm I
have
NODM_X_OPTIONS='-nolisten tcp -pn +extension Composite -dpi 150'
in /etc/defauilt/nodm
NeilBrown
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: When is the next and more powerful openmoko releasing
On Fri, 13 Aug 2010 11:22:02 +0200 Dr. H. Nikolaus Schaller h...@computer.org wrote: Am 12.08.2010 um 14:12 schrieb RANJAN: Hi, When is the next and more powerful openmoko (capable of seamless 3D video and faster processor) is going to be released??? Assume, you could get a motherboard upgrade board that fits into the Freerunner (or Neo1973) case. Based on the TI OMAP3 SoC (OMAP3530 or DM3730) and UMTS. Let me ask two questions to everybody: * How long could you be willing to wait for it to really become available? * How much would you think you could afford to pay for such a board? Is there a serious possibility of this? I'm willing to wait a couple of years at least. And the 500 Euro number that people are throwing around seems OK. Would this be re-using the case, display and touch screen and replacing everything else? NeilBrown ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: When is the next and more powerful openmoko releasing
On Fri, 13 Aug 2010 19:27:38 +0100 Ben Thompson b...@thompson.org.uk wrote: To finance the next phase, we are thinking about asking for donations or to hold an auction for the first 5 or 10 prototype units. What would you think of such an approach? I'm not keen on either (although would consider a donation). What about a pre-order? I'm not keen on an auction as it tends to focus on getting large amounts money from few people - those many who have modest amounts of money get excluded. I'm not very keen of straight donations either as you really need a strong accountability structure before donations are at all safe, and I don't think you want to go that way. I like pre-order, but I wonder about combining them all... Choose a maximum subscription and a minimum price. Invite people to pre-order and pay the minimum price or greater as they choose. Only take orders up to the maximum subscription. As units become available, fill orders in order of the price paid starting with those who paid the most. Publish basic statistics about orders received so far and allow people to know their position. Also allow people to top-up their orders to climb the list. That way people can donate and are rewarded by getting a phone sooner - but everyone still gets a phone. The maximum subscription ensures that no-one will continually be over-taken by someone new paying a little bit more. An unfortunate quirk of this method is that those who pay the most - and get the first phone - may end up with a phone that is defective as some bug may not have been found yet. (obviously people pay postage plus minimum price plus extra). Just an thought.. NeilBrown ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
