Re: About OpenMoko Rotate

2008-09-21 Thread Yogiz
> 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

2008-09-21 Thread Rui Miguel Silva Seabra
On Sat, Sep 20, 2008 at 07:08:46PM +0100, Rui Miguel Silva Seabra wrote:
> > 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.

I'm about to make a rewrite...
http://blog.1407.org/2008/09/21/getting-ready-for-rotate-rewrite/

It's easier to read the accelerometers than I thought, and I think I'm
reading them in a safer way (at least the data I'm getting is quite
consistent).

BTW, the sensibility is awesome, I'd say it may actually be able to
sense an earthquake sooner than I'd be able to...

Rui

-- 
Kallisti!
Today is Prickle-Prickle, the 45th 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

2008-09-20 Thread Yogiz

> > 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

2008-09-20 Thread Marco Trevisan (Treviño)
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

2008-09-20 Thread Rui Miguel Silva Seabra
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

2008-09-20 Thread Yogiz
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

2008-09-20 Thread Al Johnson
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

2008-09-20 Thread Vasco Névoa
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

2008-09-20 Thread Rui Miguel Silva Seabra
I didn't touch that part yet, it's buggy but not an easy win :)

As for sexy morphs... wouldn't that probably have to be done at xrandr
level?

If the original author (or someone else) doesn't get to it first, I'll
try to improve the tilt sensibility.

Rui

On Sat, Sep 20, 2008 at 02:50:44AM +0100, 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

-- 
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

2008-09-20 Thread Fox Mulder
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


Re: About OpenMoko Rotate

2008-09-19 Thread Vasco Névoa
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


Re: About OpenMoko Rotate

2008-09-19 Thread Rui Miguel Silva Seabra
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