Re: About OpenMoko Rotate
1. The touchscreen calibration is fine when the screen is in normal rotation, to left or to right but if it's upside down then the calibration goes way off for me. When I click somewhere the action actually takes place above and to the right of the actual click. Which version are you using? In om2008.8 (with updates) it has been fixed. Simply keep the xglamo package update! 2. I'm using the Raster's keyboard and I can only see half of the bottom row of buttons, especially when the screen is not in normal rotation. Don't know if it's the keyboard or Rotate. Like before, it should have been fixed. I got that problem too but now I can't reproduce and I'm using ASU with all the updates but with Raster's keyboard. Hmm, you're right. I last updated yesterday and both problem were there. I did a quick update a minute ago and it only updated angstrom but now both problems are gone. 3. This is probably a kernel problem or something but after a while, the accelerometes seem to stop working which can leave the rotation to an unconfortable position. Suspending and resuming helps. Yes if I'm not wrong there's something about this in the trac. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: About OpenMoko Rotate
Hmm, you're right. I last updated yesterday and both problem were there. I did a quick update a minute ago and it only updated angstrom but now both problems are gone. I take that back. Both problems still persist but not constantly. I can't connect their appearance with anything. Yogiz ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: About OpenMoko Rotate
I haven't looked at the code yet, but my instinctive approach would be to calculate the direction of the down vector (constant 9.8m/s2 acceleration) and then compare that to the phone's down direction. It is the difference between these two vectors that I am referring to. Even if the error is great, surely it is not superior to 45 degrees (a quarter turn)? Is this not the way it is done? Fox Mulder wrote: This is not so easy to do. The rotation comes out of a calculation of the values from acceleration sensors. There are no angle sensors for this operation. So there is no way of exactly say which angle the neo currently has instead these are just aproximations. Ciao, Rainer Vasco Névoa wrote: That's very cool. I appreciate the mod. :) I'm seeing something that looks like a bug (in both versions)... but I'm not sure if the accelerometers require calibration or something. With the FR in vertical position, if I tilt it counter-clockwise, it takes just over 90 degrees to get 'accel-rotate' to change the orientation; but if I tilt it even less than 10 degrees clockwise after that, it reverts back to the original orientation. Shouldn't the threshold be set at the midpoint angles (45, 135, 225, 315 degrees)? Anyway, good work to both coders, it's just what I wanted. :D Maybe someone cares to extend this simple app to use some kind of sexy morph instead of the disruptive xrandr rotation? 8-) Rui Miguel Silva Seabra wrote: Done. I've added a reference to it at http://wiki.openmoko.org/wiki/Rotate but my page about it is at http://blog.1407.org/2008/09/20/openmoko-rotate-now-using-libxrandr/ Users of Rotate, I've patched it so it doesn't use system+xrandr but simply call directly the xrandr function using libxrandr. This means: * quicker * less battery consumption Best, Rui On Fri, Sep 19, 2008 at 10:13:29AM +0100, Rui Miguel Silva Seabra wrote: Hi, I'm preparing a patch for using xrandr api directly in Rotate instead of system(). It's almost done but I can only code it at home time (which, for me, starts again in about 9 hours) :) This will be much better in terms of speed and battery life! Best, Rui ___ 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 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: About OpenMoko Rotate
On Saturday 20 September 2008, Vasco Névoa wrote: I haven't looked at the code yet, but my instinctive approach would be to calculate the direction of the down vector (constant 9.8m/s2 acceleration) and then compare that to the phone's down direction. It is the difference between these two vectors that I am referring to. Even if the error is great, surely it is not superior to 45 degrees (a quarter turn)? Is this not the way it is done? It doesn't do that at the moment - it's _very_ quick'n'dirty. I would calculate the acceleration vector too, but ignore the direction if the magnitude was to far from 1g as that would suggest something dynamic was going on. Fox Mulder wrote: This is not so easy to do. The rotation comes out of a calculation of the values from acceleration sensors. There are no angle sensors for this operation. So there is no way of exactly say which angle the neo currently has instead these are just aproximations. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: About OpenMoko Rotate
On Sat, 20 Sep 2008 01:47:04 +0100 Rui Miguel Silva Seabra [EMAIL PROTECTED] wrote: Done. I've added a reference to it at http://wiki.openmoko.org/wiki/Rotate but my page about it is at http://blog.1407.org/2008/09/20/openmoko-rotate-now-using-libxrandr/ Users of Rotate, I've patched it so it doesn't use system+xrandr but simply call directly the xrandr function using libxrandr. This means: * quicker * less battery consumption Best, Rui I love it. You probably know the bugs and most might not even have to do with the program but I'll point them out just in case: 1. The touchscreen calibration is fine when the screen is in normal rotation, to left or to right but if it's upside down then the calibration goes way off for me. When I click somewhere the action actually takes place above and to the right of the actual click. 2. I'm using the Raster's keyboard and I can only see half of the bottom row of buttons, especially when the screen is not in normal rotation. Don't know if it's the keyboard or Rotate. 3. This is probably a kernel problem or something but after a while, the accelerometes seem to stop working which can leave the rotation to an unconfortable position. Suspending and resuming helps. Other then that, I love it. Good job. Yogiz ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: About OpenMoko Rotate
On Sat, Sep 20, 2008 at 08:05:11PM +0300, Yogiz wrote: On Sat, 20 Sep 2008 01:47:04 +0100 Rui Miguel Silva Seabra [EMAIL PROTECTED] wrote: Done. I've added a reference to it at http://wiki.openmoko.org/wiki/Rotate but my page about it is at http://blog.1407.org/2008/09/20/openmoko-rotate-now-using-libxrandr/ Users of Rotate, I've patched it so it doesn't use system+xrandr but simply call directly the xrandr function using libxrandr. This means: * quicker * less battery consumption Best, Rui I love it. You probably know the bugs and most might not even have to do with the program but I'll point them out just in case: 1. The touchscreen calibration is fine when the screen is in normal rotation, to left or to right but if it's upside down then the calibration goes way off for me. When I click somewhere the action actually takes place above and to the right of the actual click. 2. I'm using the Raster's keyboard and I can only see half of the bottom row of buttons, especially when the screen is not in normal rotation. Don't know if it's the keyboard or Rotate. 3. This is probably a kernel problem or something but after a while, the accelerometes seem to stop working which can leave the rotation to an unconfortable position. Suspending and resuming helps. Other then that, I love it. Good job. I didn't write the hardest part, I just patched it to be a little better. I will try to check if I can fix the instability problems, but I can't promise anything. Rui -- Or not. Today is Pungenday, the 44th day of Bureaucracy in the YOLD 3174 + 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: About OpenMoko Rotate
Yogiz wrote: On Sat, 20 Sep 2008 01:47:04 +0100 Rui Miguel Silva Seabra [EMAIL PROTECTED] wrote: Done. I've added a reference to it at http://wiki.openmoko.org/wiki/Rotate but my page about it is at http://blog.1407.org/2008/09/20/openmoko-rotate-now-using-libxrandr/ Users of Rotate, I've patched it so it doesn't use system+xrandr but simply call directly the xrandr function using libxrandr. This means: * quicker * less battery consumption Nice... However in my point of view the it is too aggressive: imho allowing the phone to rotate its resolution after each gesture is too much (both for battery usage and for usability). So, for example, I'd make it checking the accelerometers and allowing to rotate only if the AUX button is pressed (or if it has been pressed in the past few seconds). I know that some apps are using the AUX key (E, for example for locking the phone also if that should be just a stub) but I'd prefer a such version. 1. The touchscreen calibration is fine when the screen is in normal rotation, to left or to right but if it's upside down then the calibration goes way off for me. When I click somewhere the action actually takes place above and to the right of the actual click. Which version are you using? In om2008.8 (with updates) it has been fixed. Simply keep the xglamo package update! 2. I'm using the Raster's keyboard and I can only see half of the bottom row of buttons, especially when the screen is not in normal rotation. Don't know if it's the keyboard or Rotate. Like before, it should have been fixed. I got that problem too but now I can't reproduce and I'm using ASU with all the updates but with Raster's keyboard. 3. This is probably a kernel problem or something but after a while, the accelerometes seem to stop working which can leave the rotation to an unconfortable position. Suspending and resuming helps. Yes if I'm not wrong there's something about this in the trac. -- Treviño's World - Life and Linux http://www.3v1n0.net/ ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: About OpenMoko Rotate
Done. I've added a reference to it at http://wiki.openmoko.org/wiki/Rotate but my page about it is at http://blog.1407.org/2008/09/20/openmoko-rotate-now-using-libxrandr/ Users of Rotate, I've patched it so it doesn't use system+xrandr but simply call directly the xrandr function using libxrandr. This means: * quicker * less battery consumption Best, Rui On Fri, Sep 19, 2008 at 10:13:29AM +0100, Rui Miguel Silva Seabra wrote: Hi, I'm preparing a patch for using xrandr api directly in Rotate instead of system(). It's almost done but I can only code it at home time (which, for me, starts again in about 9 hours) :) This will be much better in terms of speed and battery life! Best, Rui -- P'tang! Today is Pungenday, the 44th day of Bureaucracy in the YOLD 3174 + 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: About OpenMoko Rotate
That's very cool. I appreciate the mod. :) I'm seeing something that looks like a bug (in both versions)... but I'm not sure if the accelerometers require calibration or something. With the FR in vertical position, if I tilt it counter-clockwise, it takes just over 90 degrees to get 'accel-rotate' to change the orientation; but if I tilt it even less than 10 degrees clockwise after that, it reverts back to the original orientation. Shouldn't the threshold be set at the midpoint angles (45, 135, 225, 315 degrees)? Anyway, good work to both coders, it's just what I wanted. :D Maybe someone cares to extend this simple app to use some kind of sexy morph instead of the disruptive xrandr rotation? 8-) Rui Miguel Silva Seabra wrote: Done. I've added a reference to it at http://wiki.openmoko.org/wiki/Rotate but my page about it is at http://blog.1407.org/2008/09/20/openmoko-rotate-now-using-libxrandr/ Users of Rotate, I've patched it so it doesn't use system+xrandr but simply call directly the xrandr function using libxrandr. This means: * quicker * less battery consumption Best, Rui On Fri, Sep 19, 2008 at 10:13:29AM +0100, Rui Miguel Silva Seabra wrote: Hi, I'm preparing a patch for using xrandr api directly in Rotate instead of system(). It's almost done but I can only code it at home time (which, for me, starts again in about 9 hours) :) This will be much better in terms of speed and battery life! Best, Rui ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
