Re: Conflict when several apps use the accelerometers?
Hendrik Siedelmann wrote: [...] Yes, I too think it would be useful for a longer period. In a time of 3-5 seconds one could propably get away with simply projecting the route at signal loss with constant speed. And I think navit snaps to streets anyway, so it wouldn't matter if its off by a bit. Unfortunately, navit snaps to the roads above the tunnel too. :-/ If I take the trouble of connecting to the car in order to get speedometer data, I can also get a digital compass. Those two together should be able to help the gps anywhere. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Conflict when several apps use the accelerometers?
maybe this can be of help: http://openbossa.indt.org/carman/index.html it interfaces with the car On Tue, Jan 27, 2009 at 10:53 PM, Hendrik Siedelmann hendrik.siedelm...@googlemail.com wrote: 2009/1/27, Helge Hafting helge.haft...@hist.no: Gunnar Aastrand Grimnes wrote: This page does: http://wiki.openmoko.org/wiki/Accelerometer_Fundamentals Noise is around 3cm/s^2, i.e: It can fill in _short_ - 3-5s gaps in GPS coverage, if the orientation of the phone is known. Not enough for a 4km tunnel then, which is 3 min when going 80km/h. 5s is enough for a 111m tunnel, but 5s signal loss is usually not a problem anyway. Of course, the car speedometer readout can take care of speed and braking/acceleration, the accelerometer would only be needed to notice turning. Could be interesting to see where it thinks I am after 3 min, if 5s is all I can expect. I guess those 3-5s is the interval where precision matces the gps. But it will be useful for longer than that, as long as estimate is more accurate than stopped at the tunnel entrance. The error increase with time, but so do the real distance from the entrance. Helge Hafting Yes, I too think it would be useful for a longer period. In a time of 3-5 seconds one could propably get away with simply projecting the route at signal loss with constant speed. And I think navit snaps to streets anyway, so it wouldn't matter if its off by a bit. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Conflict when several apps use the accelerometers?
Gunnar Aastrand Grimnes wrote: This page does: http://wiki.openmoko.org/wiki/Accelerometer_Fundamentals Noise is around 3cm/s^2, i.e: It can fill in _short_ - 3-5s gaps in GPS coverage, if the orientation of the phone is known. Not enough for a 4km tunnel then, which is 3 min when going 80km/h. 5s is enough for a 111m tunnel, but 5s signal loss is usually not a problem anyway. Of course, the car speedometer readout can take care of speed and braking/acceleration, the accelerometer would only be needed to notice turning. Could be interesting to see where it thinks I am after 3 min, if 5s is all I can expect. I guess those 3-5s is the interval where precision matces the gps. But it will be useful for longer than that, as long as estimate is more accurate than stopped at the tunnel entrance. The error increase with time, but so do the real distance from the entrance. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Conflict when several apps use the accelerometers?
2009/1/27, Helge Hafting helge.haft...@hist.no: Gunnar Aastrand Grimnes wrote: This page does: http://wiki.openmoko.org/wiki/Accelerometer_Fundamentals Noise is around 3cm/s^2, i.e: It can fill in _short_ - 3-5s gaps in GPS coverage, if the orientation of the phone is known. Not enough for a 4km tunnel then, which is 3 min when going 80km/h. 5s is enough for a 111m tunnel, but 5s signal loss is usually not a problem anyway. Of course, the car speedometer readout can take care of speed and braking/acceleration, the accelerometer would only be needed to notice turning. Could be interesting to see where it thinks I am after 3 min, if 5s is all I can expect. I guess those 3-5s is the interval where precision matces the gps. But it will be useful for longer than that, as long as estimate is more accurate than stopped at the tunnel entrance. The error increase with time, but so do the real distance from the entrance. Helge Hafting Yes, I too think it would be useful for a longer period. In a time of 3-5 seconds one could propably get away with simply projecting the route at signal loss with constant speed. And I think navit snaps to streets anyway, so it wouldn't matter if its off by a bit. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Conflict when several apps use the accelerometers?
Hendrik Siedelmann wrote: Get higher gps accuracy using accelerometer data (or use it when driving through a tunnel) would be a nice example. That'd be interesting. Do anyone know the precision of the accelerometers? Assuming, of course, that one has a car mount so the phone has a known orientation relative to the car. How long tunnels would be feasible? Where I live, there are some 4km tunnels that curve slightly, and a shorter one with a roundabout inside. :-/ Usually, one also uses the car speedometer for this. I have a box that converts this to serial - perhaps a serial to usb converter could be used to connect the phone. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Conflict when several apps use the accelerometers?
This page does: http://wiki.openmoko.org/wiki/Accelerometer_Fundamentals Noise is around 3cm/s^2, i.e: It can fill in _short_ - 3-5s gaps in GPS coverage, if the orientation of the phone is known. Helge Hafting wrote: Hendrik Siedelmann wrote: Get higher gps accuracy using accelerometer data (or use it when driving through a tunnel) would be a nice example. That'd be interesting. Do anyone know the precision of the accelerometers? Assuming, of course, that one has a car mount so the phone has a known orientation relative to the car. How long tunnels would be feasible? Where I live, there are some 4km tunnels that curve slightly, and a shorter one with a roundabout inside. :-/ Usually, one also uses the car speedometer for this. I have a box that converts this to serial - perhaps a serial to usb converter could be used to connect the phone. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- Gunnar Aastrand Grimnes gunnar.grimnes [AT] dfki.de DFKI GmbH Knowledge Management Trippstadter Strasse 122 D-67663 Kaiserslautern Germany Office: +49 631 205 75-117 Mobile: +49 177 277 4397 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Conflict when several apps use the accelerometers?
On Monday 26 January 2009, Helge Hafting wrote: Hendrik Siedelmann wrote: Get higher gps accuracy using accelerometer data (or use it when driving through a tunnel) would be a nice example. That'd be interesting. Do anyone know the precision of the accelerometers? Assuming, of course, that one has a car mount so the phone has a known orientation relative to the car. How long tunnels would be feasible? Where I live, there are some 4km tunnels that curve slightly, and a shorter one with a roundabout inside. :-/ Usually, one also uses the car speedometer for this. I have a box that converts this to serial - perhaps a serial to usb converter could be used to connect the phone. Could do. The other thing that would work in many cars would be a USB CAN bus adaptor. This may give access to other useful signals too. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Conflict when several apps use the accelerometers?
Thomas Otterbein wrote: Perhaps a Accelero-Deamon? Applications could register for receiving, probably even already pre-processed, events. And an application could also request exclusive access in which case the others would just not receive further events. So, problem's solved! Could we please get a working demo by tomorrow? ;-) Fully exclusive access is not a solution. It just defeats the purpose of multitasking. Actually I think the window manager should dispatch accelerator events, like it dispatches the mouse events. Only focused application should receive them and decide what to do with them - rotate screen, or move some goblin. Screen rotation should be also function of window manager. Apps should only set hints to the window manager regarding preferred orientation if they have one, and change the hint according to their own algorithms. The window manager should decide screen orientation based on focused app. In short, there's no need for daemon, cause the only software which talks directly to proposed daemon is actually window manager. -- View this message in context: http://n2.nabble.com/Conflict-when-several-apps-use-the-accelerometers--tp2145087p2157142.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Conflict when several apps use the accelerometers?
VirtuAlex wrote: the window manager should dispatch accelerator events I meant accelerometer events. -- View this message in context: http://n2.nabble.com/Conflict-when-several-apps-use-the-accelerometers--tp2145087p2157147.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Conflict when several apps use the accelerometers?
On Wed, Jan 14, 2009 at 3:40 PM, VirtuAlex virtua...@linuxoid.net wrote: Fully exclusive access is not a solution. It just defeats the purpose of multitasking. Actually I think the window manager should dispatch accelerator events, like it dispatches the mouse events. Only focused application should receive them Well, unless we decide of a new kind of focus (accel-focus or something), this should be more flexible. For example, some background apps might want to get accel' data : auto-rotation tools (yeah I know, the whole point of managing accelerometers through the WM would be to bury this practice), HDD-parkers (yeah I know, there's not HDD in Neo's), ... Seriously, I can't get anything serious as an example, but I think you got my point. This apart, I'm all for the WM-based path. This should be a freedesktop standard or something, actually. Or has it more to do with Linux' input layer? Or Xorg's? I don't know... -- LC ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Conflict when several apps use the accelerometers?
Fully exclusive access is not a solution. It just defeats the purpose of multitasking. Actually I think the window manager should dispatch accelerator events, like it dispatches the mouse events. Only focused Okay, that's basically what I meant with deamon. A piece of software that's responsible for reading the input of a device and forward pre-computed information as events to whoever might be concerned. Side-effect: If the accelerometer get's replaced by another model only this part has to be rewritten and not all software using the feature. While writing these lines: I think Gestures (http://wiki.openmoko.org/wiki/Gestures) may do exactly this already. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Conflict when several apps use the accelerometers?
Rui Miguel Silva Seabra wrote: Hi, omnewrotate is quite blind to what is running. If you have an application which uses accelerometers you are much better off not running omnewrotate at the same time, regardless of solving the monopolization problem. Imagine it is solved: If the application uses the accelerometers then you may have some problems when you hit a position where it thinks it should rotate the screen. I can imagine how this would be a problem with Pingus, for instance. I plan to have a toggling script for use in the desktop icon, instead of a starter script. This is the sort of thing that might be useful to have on the illume top shelf. autototate on/off, and rotate now when auto is off. Rotation is useful with maps. It depends on what the region look like. Also, it is easier to but the phone down on the long edge in a car. I can see how autorotation would be a problem in a game. Pingus works in either orientation, but several guys walk of the cliffs while the screen repaints. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Conflict when several apps use the accelerometers?
Hi all, I plan to have a toggling script for use in the desktop icon, instead of a starter script. This is the sort of thing that might be useful to have on the illume top shelf. autototate on/off, and rotate now when auto is off. Rotation is useful with maps. It depends on what the region look like. Also, it is easier to but the phone down on the long edge in a car. I can see how autorotation would be a problem in a game. Pingus works in either orientation, but several guys walk of the cliffs while the screen repaints. to my opinion the default auto-rotation software should have some signaling mechanism that keeps it from doing it's job while a certain software is active. You can experience this with the later versions of MPlayer. It tells the Screensaver not to activate during movie playback. I figure the screensaver modules of Desktop-Manager must have appropriate interfaces to accomplish that behaviour. For example if a program would like to gain exclusive control over the accelerometers it could create a certain file (e.g. /var/run/donotrotate_illdoitmyself). The default rotation software checks for this file and while the file exists it loosen it's grip of the meters. This would solve the issue of concurrent access too. As far as I know the file could be created in a way so that even when the software crashes completely it is removed and therefore allow the original rotation-software to reactivate reliably. Regards thomas ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Conflict when several apps use the accelerometers?
On Tue, Jan 13, 2009 at 11:00:02AM +0100, Helge Hafting wrote: Rui Miguel Silva Seabra wrote: Hi, omnewrotate is quite blind to what is running. If you have an application which uses accelerometers you are much better off not running omnewrotate at the same time, regardless of solving the monopolization problem. Imagine it is solved: If the application uses the accelerometers then you may have some problems when you hit a position where it thinks it should rotate the screen. I can imagine how this would be a problem with Pingus, for instance. I plan to have a toggling script for use in the desktop icon, instead of a starter script. This is the sort of thing that might be useful to have on the illume top shelf. autototate on/off, and rotate now when auto is off. Rotation is useful with maps. It depends on what the region look like. Also, it is easier to but the phone down on the long edge in a car. I can see how autorotation would be a problem in a game. Pingus works in either orientation, but several guys walk of the cliffs while the screen repaints. oy! more ./configure compilation options comin' right up (well, not right up as I don't know how to program with efl yet... but nothing like writing a small module to learn it, hey?) Rui -- Keep the Lasagna flying! Today is Pungenday, the 13th day of Chaos in the YOLD 3175 + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Conflict when several apps use the accelerometers?
i'm just responding to confirm that some apps also don't work correctly with omnewrotate installed mokoeightball is one of them; after installing omnewrotate and rebooting, shaking the phone does not work with mokoeightball apps like the ledclock (http://www.opkg.org/package_104.html) displays by default in landscape mode, but turning the phone to landscape makes the teks adapt itself and displays in normal mode On Tue, Jan 13, 2009 at 11:51 AM, Rui Miguel Silva Seabra r...@1407.org wrote: On Tue, Jan 13, 2009 at 11:36:29AM +0100, Thomas Otterbein wrote: Hi all, I plan to have a toggling script for use in the desktop icon, instead of a starter script. This is the sort of thing that might be useful to have on the illume top shelf. autototate on/off, and rotate now when auto is off. Rotation is useful with maps. It depends on what the region look like. Also, it is easier to but the phone down on the long edge in a car. I can see how autorotation would be a problem in a game. Pingus works in either orientation, but several guys walk of the cliffs while the screen repaints. to my opinion the default auto-rotation software should have some signaling mechanism that keeps it from doing it's job while a certain software is active. You can experience this with the later versions of MPlayer. It tells the Screensaver not to activate during movie playback. I figure the screensaver modules of Desktop-Manager must have appropriate interfaces to accomplish that behaviour. Yes, I'm thinking of catching SIGUSR1 for that. Anything that wants to toggle it just pkill -USR1 omnewrotate in the near future. Rui -- Grudnuk demand sustenance! Today is Pungenday, the 13th day of Chaos in the YOLD 3175 + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Conflict when several apps use the accelerometers?
small correction; in ledclock one can override the rotation On Tue, Jan 13, 2009 at 1:05 PM, Yorick Moko yorickm...@gmail.com wrote: i'm just responding to confirm that some apps also don't work correctly with omnewrotate installed mokoeightball is one of them; after installing omnewrotate and rebooting, shaking the phone does not work with mokoeightball apps like the ledclock (http://www.opkg.org/package_104.html) displays by default in landscape mode, but turning the phone to landscape makes the teks adapt itself and displays in normal mode On Tue, Jan 13, 2009 at 11:51 AM, Rui Miguel Silva Seabra r...@1407.org wrote: On Tue, Jan 13, 2009 at 11:36:29AM +0100, Thomas Otterbein wrote: Hi all, I plan to have a toggling script for use in the desktop icon, instead of a starter script. This is the sort of thing that might be useful to have on the illume top shelf. autototate on/off, and rotate now when auto is off. Rotation is useful with maps. It depends on what the region look like. Also, it is easier to but the phone down on the long edge in a car. I can see how autorotation would be a problem in a game. Pingus works in either orientation, but several guys walk of the cliffs while the screen repaints. to my opinion the default auto-rotation software should have some signaling mechanism that keeps it from doing it's job while a certain software is active. You can experience this with the later versions of MPlayer. It tells the Screensaver not to activate during movie playback. I figure the screensaver modules of Desktop-Manager must have appropriate interfaces to accomplish that behaviour. Yes, I'm thinking of catching SIGUSR1 for that. Anything that wants to toggle it just pkill -USR1 omnewrotate in the near future. Rui -- Grudnuk demand sustenance! Today is Pungenday, the 13th day of Chaos in the YOLD 3175 + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Conflict when several apps use the accelerometers?
Yes, ledclock works fine if you disable rotation. On Tue, Jan 13, 2009 at 01:08:24PM +0100, Yorick Moko wrote: small correction; in ledclock one can override the rotation On Tue, Jan 13, 2009 at 1:05 PM, Yorick Moko yorickm...@gmail.com wrote: i'm just responding to confirm that some apps also don't work correctly with omnewrotate installed mokoeightball is one of them; after installing omnewrotate and rebooting, shaking the phone does not work with mokoeightball apps like the ledclock (http://www.opkg.org/package_104.html) displays by default in landscape mode, but turning the phone to landscape makes the teks adapt itself and displays in normal mode On Tue, Jan 13, 2009 at 11:51 AM, Rui Miguel Silva Seabra r...@1407.org wrote: On Tue, Jan 13, 2009 at 11:36:29AM +0100, Thomas Otterbein wrote: Hi all, I plan to have a toggling script for use in the desktop icon, instead of a starter script. This is the sort of thing that might be useful to have on the illume top shelf. autototate on/off, and rotate now when auto is off. Rotation is useful with maps. It depends on what the region look like. Also, it is easier to but the phone down on the long edge in a car. I can see how autorotation would be a problem in a game. Pingus works in either orientation, but several guys walk of the cliffs while the screen repaints. to my opinion the default auto-rotation software should have some signaling mechanism that keeps it from doing it's job while a certain software is active. You can experience this with the later versions of MPlayer. It tells the Screensaver not to activate during movie playback. I figure the screensaver modules of Desktop-Manager must have appropriate interfaces to accomplish that behaviour. Yes, I'm thinking of catching SIGUSR1 for that. Anything that wants to toggle it just pkill -USR1 omnewrotate in the near future. Rui -- Grudnuk demand sustenance! Today is Pungenday, the 13th day of Chaos in the YOLD 3175 + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- Grudnuk demand sustenance! Today is Pungenday, the 13th day of Chaos in the YOLD 3175 + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Conflict when several apps use the accelerometers?
Thomas Otterbein wrote: to my opinion the default auto-rotation software should have some signaling mechanism that keeps it from doing it's job while a certain software is active. You can experience this with the later versions of MPlayer. It tells the Screensaver not to activate during movie playback. I figure the screensaver modules of Desktop-Manager must have appropriate interfaces to accomplish that behaviour. For example if a program would like to gain exclusive control over the accelerometers it could create a certain file (e.g. /var/run/donotrotate_illdoitmyself). The default rotation software checks for this file and while the file exists it loosen it's grip of the meters. This would solve the issue of concurrent access too. As far as I know the file could be created in a way so that even when the software crashes completely it is removed and therefore allow the original rotation-software to reactivate reliably. How about running two apps then, if they're both using accelerometers and each requires its own orientation? -- View this message in context: http://n2.nabble.com/Conflict-when-several-apps-use-the-accelerometers--tp2145087p2152673.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Conflict when several apps use the accelerometers?
How about running two apps then, if they're both using accelerometers and each requires its own orientation? Perhaps a Accelero-Deamon? Applications could register for receiving, probably even already pre-processed, events. And an application could also request exclusive access in which case the others would just not receive further events. So, problem's solved! Could we please get a working demo by tomorrow? ;-) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Conflict when several apps use the accelerometers?
Is it possible to let several apps use the accelerometers, similiar to how several apps may share the gps unit? I noticed that omnewrotate seems to monopolize the accelerometers, so openmoocow and duke can't use them. Omnewrotate is useful to have, and there will probably be more games using the accelerometers. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Conflict when several apps use the accelerometers?
On Monday 12 January 2009, Helge Hafting wrote: Is it possible to let several apps use the accelerometers, similiar to how several apps may share the gps unit? I noticed that omnewrotate seems to monopolize the accelerometers, so openmoocow and duke can't use them. Omnewrotate is useful to have, and there will probably be more games using the accelerometers. The gps unit itself is single access too - we use gpsd, gypsy or ogpsd to allow access by multiple apps. The same goes for (most) sound interfaces, with esd, pulseaudio and so on providing mediation for multiple apps. So far we don't have anything to do this with the accelerometers AFAIK. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Conflict when several apps use the accelerometers?
On Mon, Jan 12, 2009 at 11:42:37AM +0100, Helge Hafting wrote: Is it possible to let several apps use the accelerometers, similiar to how several apps may share the gps unit? I noticed that omnewrotate seems to monopolize the accelerometers, so openmoocow and duke can't use them. Omnewrotate is useful to have, and there will probably be more games using the accelerometers. Hi, omnewrotate is quite blind to what is running. If you have an application which uses accelerometers you are much better off not running omnewrotate at the same time, regardless of solving the monopolization problem. Imagine it is solved: If the application uses the accelerometers then you may have some problems when you hit a position where it thinks it should rotate the screen. I can imagine how this would be a problem with Pingus, for instance. I plan to have a toggling script for use in the desktop icon, instead of a starter script. Rui -- Or not. Today is Boomtime, the 12th day of Chaos in the YOLD 3175 + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
