Re: Bug#6203, rotation and OHMD

2009-11-19 Thread Kimmo Hämäläinen
On Wed, 2009-11-18 at 17:23 +0100, ext Martin Grimme wrote:
 How about another XAtom (since we already have so many on Maemo ;) )
 on the application window, saying I rotate well and quickly. ?
 
 The ohmd could take care of this atom and refrain from freezing the
 app during rotation, iff it is the currently visible one.

It's much simpler to just not freeze the application that is being
rotated.  This allows it to redraw for the new screen dimensions _while_
we are showing the rotating animation.  Currently the ohmd freezing is
breaking this for others than the Phone application (it seems those guys
didn't understand what is happening), but it will be fixed.

-Kimmo

 
 Of course applications could lie about their rotation capabilities,
 but that's what we have the extras-testing QA for.
 
 
 Martin
 
 
 2009/11/18, Eero Tamminen eero.tammi...@nokia.com:
  Hi,
 
  ext Eugene Antimirov wrote:
  It handles also audio policies and tries to make sure that you get
  your phone calls when the device is heavily loaded and some other
  minor things.
 
  Just to know.
   
  I see now this `ohmd` process in my 41-10. I did not get it, was this
  daemon improved or made worse in new firmware released lately?
 
  Better for known (pre-installed) applications, worse for unknown
  applications.  The reason for this is that unknown applications have
  unknown resource usage so system policy treats them with more care.
 
 
  It's a bit of a chicken and egg problem.  Changing the policy is slow
  iterative work requiring lots of testing that the policy change doesn't
  significantly worsen other use-cases in some situations (e.g. for things
  for which there are certain certification  legal requirements).
 
  Developers can now experiment and report/discuss things which they would
  like policy to handle better (for certain classes of 3rd applications
  and their use-cases). I.e. in regards to 3rd party applications, the
  policies could be considered work-in-progress.
 
 
  Things that could potentially be done for 3rd party applications
  policy handling:
 
  - Default policy is improved in regards to unknown processes.
 It's yet unknown whether this can be done well enough without
 sacrificing the known functionality, that's why feedback is needed
 on the behavior of 3rd party application use-cases.
 
  - Applications themselves specify the required policy on install.
 This is extra work for apps, and requires extensive testing to
 guarantee that the policy they choose is good match for
 the application in all cases. (application doesn't leak or
 otherwise hog resources)
 
  - Some way for user to specify per-application policy.
 I'm sure power-users would like that... :-)
 
 
  - Eero
  ___
  maemo-developers mailing list
  maemo-developers@maemo.org
  https://lists.maemo.org/mailman/listinfo/maemo-developers
 
 ___
 maemo-developers mailing list
 maemo-developers@maemo.org
 https://lists.maemo.org/mailman/listinfo/maemo-developers

___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers


Re: Bug#6203, rotation and OHMD

2009-11-19 Thread Kimmo Hämäläinen
On Wed, 2009-11-18 at 17:44 +0100, ext Cornelius Hald wrote:
 I see many use cases for those policies like an incoming phone call
 should work properly even while some app is doing heavy number
 crunching.
 
 However rotation is a different thing. I mean what's the objective? The
 rotation animation should be smooth even if something uses a lot of
 processing time? Fair enough. But pausing the _foreground_ application
 is hardly the solution. How about pausing all _background_ applications?

You are right. This is the bug :)

-Kimmo

 
 The foreground application is the only application interested in the
 rotation. Therefore it already specifies explicitly that it can rotate.
 If I now write an application it's my duty to give the CPU some time
 while rotating. If I don't do this, _my_ application looks shitty and
 everyone will tell me. It's not the platform that gets a bad reputation,
 it's my app.
 
 So, if anything should get paused, it's all applications which are not
 white listed and which are not in the foreground.
 
 If I somehow missed the point, please tell me :)
 
 Cheers!
 Conny
 
 
 On Wed, 2009-11-18 at 18:07 +0200, Eero Tamminen wrote:
  Hi,
  
  ext Eugene Antimirov wrote:
   It handles also audio policies and tries to make sure that you get
   your phone calls when the device is heavily loaded and some other
   minor things.
   
   Just to know.
   
   I see now this `ohmd` process in my 41-10. I did not get it, was this
   daemon improved or made worse in new firmware released lately?
  
  Better for known (pre-installed) applications, worse for unknown
  applications.  The reason for this is that unknown applications have
  unknown resource usage so system policy treats them with more care.
  
  
  It's a bit of a chicken and egg problem.  Changing the policy is slow
  iterative work requiring lots of testing that the policy change doesn't
  significantly worsen other use-cases in some situations (e.g. for things
  for which there are certain certification  legal requirements).
  
  Developers can now experiment and report/discuss things which they would
  like policy to handle better (for certain classes of 3rd applications
  and their use-cases). I.e. in regards to 3rd party applications, the
  policies could be considered work-in-progress.
  
  
  Things that could potentially be done for 3rd party applications
  policy handling:
  
  - Default policy is improved in regards to unknown processes.
 It's yet unknown whether this can be done well enough without
 sacrificing the known functionality, that's why feedback is needed
 on the behavior of 3rd party application use-cases.
  
  - Applications themselves specify the required policy on install.
 This is extra work for apps, and requires extensive testing to
 guarantee that the policy they choose is good match for
 the application in all cases. (application doesn't leak or
 otherwise hog resources)
  
  - Some way for user to specify per-application policy.
 I'm sure power-users would like that... :-)
  
  
  - Eero
  ___
  maemo-developers mailing list
  maemo-developers@maemo.org
  https://lists.maemo.org/mailman/listinfo/maemo-developers
 
 ___
 maemo-developers mailing list
 maemo-developers@maemo.org
 https://lists.maemo.org/mailman/listinfo/maemo-developers

___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers


Re: Bug#6203, rotation and OHMD

2009-11-18 Thread Eero Tamminen
Hi,

ext Aniello Del Sorbo wrote:
 Is the purpose of OHMD ONLY to pause not whitelisted applications when
 rotating?
 
 As if it is so, I'd put a stop ohmd every time I run Xournal to make
 sure it rotates smoothly.
 
 It handles also audio policies and tries to make sure that you get
 your phone calls when the device is heavily loaded and some other
 minor things.
 
 Not something you may want to stop then.
 
 I'll wait for a fix.

The policy configuration is in:
/usr/share/policy/etc/current/syspart.conf

As a temporary hack for your own device, you might try to modify
that file as root and then do killall ohmd to restart it with
the new policy.

This way you get to decide what has the priority instead of it
being dictated by Nokia. :-)

In future there may be some way to install extra policies.


NOTE: if this conf file has errors, ohmd isn't started and your
device will most likely behave strangely as result (cannot play
music etc).

DISCLAIMER: if it breaks, you get to keep all the pieces.
I.e. have an up to date backup of your data and be ready to
reflash in the case that things really break.  Modified policy
is an untested configuration.


- Eero
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers


Re: Bug#6203, rotation and OHMD

2009-11-18 Thread Eugene Antimirov
 Message: 13
 Date: Tue, 17 Nov 2009 19:28:49 +0200
 From: Eero Tamminen eero.tammi...@nokia.com
 Subject: Re: Bug#6203, rotation and OHMD
 To: ext Aniello Del Sorbo ani...@gmail.com
 Cc: maemo-developers@maemo.org maemo-developers@maemo.org
 Message-ID: 4b02dd51.3070...@nokia.com
 Content-Type: text/plain; charset=ISO-8859-1; format=flowed

 It handles also audio policies and tries to make sure that you get
 your phone calls when the device is heavily loaded and some other
 minor things.

        - Eero

Just to know.
I see now this `ohmd` process in my 41-10. I did not get it, was this
daemon improved or made worse in new firmware released lately?

-- 
Sincerely,
Eugene
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers


Re: Bug#6203, rotation and OHMD

2009-11-18 Thread Aniello Del Sorbo
2009/11/18 Eero Tamminen eero.tammi...@nokia.com:
 Hi,

 ext Aniello Del Sorbo wrote:

 Is the purpose of OHMD ONLY to pause not whitelisted applications when
 rotating?



 As if it is so, I'd put a stop ohmd every time I run Xournal to make
 sure it rotates smoothly.



 It handles also audio policies and tries to make sure that you get
 your phone calls when the device is heavily loaded and some other
 minor things.

 Not something you may want to stop then.

 I'll wait for a fix.

 The policy configuration is in:
        /usr/share/policy/etc/current/syspart.conf

 As a temporary hack for your own device, you might try to modify
 that file as root and then do killall ohmd to restart it with
 the new policy.

 This way you get to decide what has the priority instead of it
 being dictated by Nokia. :-)

 In future there may be some way to install extra policies.


 NOTE: if this conf file has errors, ohmd isn't started and your
 device will most likely behave strangely as result (cannot play
 music etc).

 DISCLAIMER: if it breaks, you get to keep all the pieces.
 I.e. have an up to date backup of your data and be ready to
 reflash in the case that things really break.  Modified policy
 is an untested configuration.


As commented on the Bug I won't touch anything, I may play with it, but
I will have to just wait for a fix coming from you guys.

You do realize that the ones that will get thumbs down for this will be us,
third party developers as people will think it's Xournal and Conboy not properly
developed.
Indeed, Nokia Phone app rotates nicely.

:)

-- 
anidel
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers


Re: Bug#6203, rotation and OHMD

2009-11-18 Thread Eero Tamminen
Hi,

ext Eugene Antimirov wrote:
 It handles also audio policies and tries to make sure that you get
 your phone calls when the device is heavily loaded and some other
 minor things.
 
 Just to know.
 
 I see now this `ohmd` process in my 41-10. I did not get it, was this
 daemon improved or made worse in new firmware released lately?

Better for known (pre-installed) applications, worse for unknown
applications.  The reason for this is that unknown applications have
unknown resource usage so system policy treats them with more care.


It's a bit of a chicken and egg problem.  Changing the policy is slow
iterative work requiring lots of testing that the policy change doesn't
significantly worsen other use-cases in some situations (e.g. for things
for which there are certain certification  legal requirements).

Developers can now experiment and report/discuss things which they would
like policy to handle better (for certain classes of 3rd applications
and their use-cases). I.e. in regards to 3rd party applications, the
policies could be considered work-in-progress.


Things that could potentially be done for 3rd party applications
policy handling:

- Default policy is improved in regards to unknown processes.
   It's yet unknown whether this can be done well enough without
   sacrificing the known functionality, that's why feedback is needed
   on the behavior of 3rd party application use-cases.

- Applications themselves specify the required policy on install.
   This is extra work for apps, and requires extensive testing to
   guarantee that the policy they choose is good match for
   the application in all cases. (application doesn't leak or
   otherwise hog resources)

- Some way for user to specify per-application policy.
   I'm sure power-users would like that... :-)


- Eero
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers


Re: Bug#6203, rotation and OHMD

2009-11-18 Thread Martin Grimme
How about another XAtom (since we already have so many on Maemo ;) )
on the application window, saying I rotate well and quickly. ?

The ohmd could take care of this atom and refrain from freezing the
app during rotation, iff it is the currently visible one.

Of course applications could lie about their rotation capabilities,
but that's what we have the extras-testing QA for.


Martin


2009/11/18, Eero Tamminen eero.tammi...@nokia.com:
 Hi,

 ext Eugene Antimirov wrote:
 It handles also audio policies and tries to make sure that you get
 your phone calls when the device is heavily loaded and some other
 minor things.

 Just to know.
  
 I see now this `ohmd` process in my 41-10. I did not get it, was this
 daemon improved or made worse in new firmware released lately?

 Better for known (pre-installed) applications, worse for unknown
 applications.  The reason for this is that unknown applications have
 unknown resource usage so system policy treats them with more care.


 It's a bit of a chicken and egg problem.  Changing the policy is slow
 iterative work requiring lots of testing that the policy change doesn't
 significantly worsen other use-cases in some situations (e.g. for things
 for which there are certain certification  legal requirements).

 Developers can now experiment and report/discuss things which they would
 like policy to handle better (for certain classes of 3rd applications
 and their use-cases). I.e. in regards to 3rd party applications, the
 policies could be considered work-in-progress.


 Things that could potentially be done for 3rd party applications
 policy handling:

 - Default policy is improved in regards to unknown processes.
It's yet unknown whether this can be done well enough without
sacrificing the known functionality, that's why feedback is needed
on the behavior of 3rd party application use-cases.

 - Applications themselves specify the required policy on install.
This is extra work for apps, and requires extensive testing to
guarantee that the policy they choose is good match for
the application in all cases. (application doesn't leak or
otherwise hog resources)

 - Some way for user to specify per-application policy.
I'm sure power-users would like that... :-)


   - Eero
 ___
 maemo-developers mailing list
 maemo-developers@maemo.org
 https://lists.maemo.org/mailman/listinfo/maemo-developers

___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers


Re: Bug#6203, rotation and OHMD

2009-11-18 Thread Aniello Del Sorbo
Out of ignorance,

why don't you guys simply allow only the foremost (i.e. the currently
visible one)
application to rotate and send the rotation event to the other apps
AFTER the animation has completed.

After all to switch from one app to the other we've got to go via the
task switcher
and that rotates to landscape mode anyway (at least until you put in support
for rotation there as well, but still..)

Aniello

2009/11/18 Martin Grimme martin.gri...@gmail.com:
 How about another XAtom (since we already have so many on Maemo ;) )
 on the application window, saying I rotate well and quickly. ?

 The ohmd could take care of this atom and refrain from freezing the
 app during rotation, iff it is the currently visible one.

 Of course applications could lie about their rotation capabilities,
 but that's what we have the extras-testing QA for.


 Martin


 2009/11/18, Eero Tamminen eero.tammi...@nokia.com:
 Hi,

 ext Eugene Antimirov wrote:
 It handles also audio policies and tries to make sure that you get
 your phone calls when the device is heavily loaded and some other
 minor things.

 Just to know.
  
 I see now this `ohmd` process in my 41-10. I did not get it, was this
 daemon improved or made worse in new firmware released lately?

 Better for known (pre-installed) applications, worse for unknown
 applications.  The reason for this is that unknown applications have
 unknown resource usage so system policy treats them with more care.


 It's a bit of a chicken and egg problem.  Changing the policy is slow
 iterative work requiring lots of testing that the policy change doesn't
 significantly worsen other use-cases in some situations (e.g. for things
 for which there are certain certification  legal requirements).

 Developers can now experiment and report/discuss things which they would
 like policy to handle better (for certain classes of 3rd applications
 and their use-cases). I.e. in regards to 3rd party applications, the
 policies could be considered work-in-progress.


 Things that could potentially be done for 3rd party applications
 policy handling:

 - Default policy is improved in regards to unknown processes.
    It's yet unknown whether this can be done well enough without
    sacrificing the known functionality, that's why feedback is needed
    on the behavior of 3rd party application use-cases.

 - Applications themselves specify the required policy on install.
    This is extra work for apps, and requires extensive testing to
    guarantee that the policy they choose is good match for
    the application in all cases. (application doesn't leak or
    otherwise hog resources)

 - Some way for user to specify per-application policy.
    I'm sure power-users would like that... :-)


       - Eero
 ___
 maemo-developers mailing list
 maemo-developers@maemo.org
 https://lists.maemo.org/mailman/listinfo/maemo-developers

 ___
 maemo-developers mailing list
 maemo-developers@maemo.org
 https://lists.maemo.org/mailman/listinfo/maemo-developers




-- 
anidel
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers


Re: Bug#6203, rotation and OHMD

2009-11-18 Thread Cornelius Hald
I see many use cases for those policies like an incoming phone call
should work properly even while some app is doing heavy number
crunching.

However rotation is a different thing. I mean what's the objective? The
rotation animation should be smooth even if something uses a lot of
processing time? Fair enough. But pausing the _foreground_ application
is hardly the solution. How about pausing all _background_ applications?

The foreground application is the only application interested in the
rotation. Therefore it already specifies explicitly that it can rotate.
If I now write an application it's my duty to give the CPU some time
while rotating. If I don't do this, _my_ application looks shitty and
everyone will tell me. It's not the platform that gets a bad reputation,
it's my app.

So, if anything should get paused, it's all applications which are not
white listed and which are not in the foreground.

If I somehow missed the point, please tell me :)

Cheers!
Conny


On Wed, 2009-11-18 at 18:07 +0200, Eero Tamminen wrote:
 Hi,
 
 ext Eugene Antimirov wrote:
  It handles also audio policies and tries to make sure that you get
  your phone calls when the device is heavily loaded and some other
  minor things.
  
  Just to know.
  
  I see now this `ohmd` process in my 41-10. I did not get it, was this
  daemon improved or made worse in new firmware released lately?
 
 Better for known (pre-installed) applications, worse for unknown
 applications.  The reason for this is that unknown applications have
 unknown resource usage so system policy treats them with more care.
 
 
 It's a bit of a chicken and egg problem.  Changing the policy is slow
 iterative work requiring lots of testing that the policy change doesn't
 significantly worsen other use-cases in some situations (e.g. for things
 for which there are certain certification  legal requirements).
 
 Developers can now experiment and report/discuss things which they would
 like policy to handle better (for certain classes of 3rd applications
 and their use-cases). I.e. in regards to 3rd party applications, the
 policies could be considered work-in-progress.
 
 
 Things that could potentially be done for 3rd party applications
 policy handling:
 
 - Default policy is improved in regards to unknown processes.
It's yet unknown whether this can be done well enough without
sacrificing the known functionality, that's why feedback is needed
on the behavior of 3rd party application use-cases.
 
 - Applications themselves specify the required policy on install.
This is extra work for apps, and requires extensive testing to
guarantee that the policy they choose is good match for
the application in all cases. (application doesn't leak or
otherwise hog resources)
 
 - Some way for user to specify per-application policy.
I'm sure power-users would like that... :-)
 
 
   - Eero
 ___
 maemo-developers mailing list
 maemo-developers@maemo.org
 https://lists.maemo.org/mailman/listinfo/maemo-developers

___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers


Re: Bug#6203, rotation and OHMD

2009-11-18 Thread Eero Tamminen
Hi,

ext Aniello Del Sorbo wrote:
 why don't you guys simply allow only the foremost (i.e. the currently
 visible one)
 application to rotate and send the rotation event to the other apps
 AFTER the animation has completed.

Background applications don't get the rotation / redraw messages at all.
You can check this with xresponse and/or xev.

(Fixing that in X and composite/window manager required a lot of work,
but AFAIK applicable parts of this work are now in upstream.)


- Eero
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers


Re: Bug#6203, rotation and OHMD

2009-11-18 Thread Eero Tamminen
Hi,

ext Martin Grimme wrote:
 How about another XAtom (since we already have so many on Maemo ;) )
 on the application window, saying I rotate well and quickly. ?
 
 The ohmd could take care of this atom and refrain from freezing the
 app during rotation, iff it is the currently visible one.
 
 Of course applications could lie about their rotation capabilities,
 but that's what we have the extras-testing QA for.

The rotation case is a minor issue and I think it can be handled OK
for unknown applications without this kind of kludges.  Let's just
hope we can get a fix for that included to the next release.

The main issue with policy is handling of unknown processes in
general and for that more feedback is needed.


(A hint: MAFW is a known system service, so it's good to use
that for music playback...  Tracker use is a bit more problematic
because it's resource usage can fluctuate pretty much according
to content it processes and what kind of requests it gets.  And
policy daemon doesn't currently know whether foreground application
needs tracker or not.)


- Eero

___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers


Re: Bug#6203, rotation and OHMD

2009-11-18 Thread Aniello Del Sorbo
2009/11/18 Cornelius Hald h...@icandy.de:
 I see many use cases for those policies like an incoming phone call
 should work properly even while some app is doing heavy number
 crunching.

 However rotation is a different thing. I mean what's the objective? The
 rotation animation should be smooth even if something uses a lot of
 processing time? Fair enough. But pausing the _foreground_ application
 is hardly the solution. How about pausing all _background_ applications?

 The foreground application is the only application interested in the
 rotation. Therefore it already specifies explicitly that it can rotate.
 If I now write an application it's my duty to give the CPU some time
 while rotating. If I don't do this, _my_ application looks shitty and
 everyone will tell me. It's not the platform that gets a bad reputation,
 it's my app.

 So, if anything should get paused, it's all applications which are not
 white listed and which are not in the foreground.

 If I somehow missed the point, please tell me :)

 Cheers!
 Conny


How dare you steal my words out of my hands before I even write them!
No, I miss the point as well..

Aniello


 On Wed, 2009-11-18 at 18:07 +0200, Eero Tamminen wrote:
 Hi,

 ext Eugene Antimirov wrote:
  It handles also audio policies and tries to make sure that you get
  your phone calls when the device is heavily loaded and some other
  minor things.
 
  Just to know.
  
  I see now this `ohmd` process in my 41-10. I did not get it, was this
  daemon improved or made worse in new firmware released lately?

 Better for known (pre-installed) applications, worse for unknown
 applications.  The reason for this is that unknown applications have
 unknown resource usage so system policy treats them with more care.


 It's a bit of a chicken and egg problem.  Changing the policy is slow
 iterative work requiring lots of testing that the policy change doesn't
 significantly worsen other use-cases in some situations (e.g. for things
 for which there are certain certification  legal requirements).

 Developers can now experiment and report/discuss things which they would
 like policy to handle better (for certain classes of 3rd applications
 and their use-cases). I.e. in regards to 3rd party applications, the
 policies could be considered work-in-progress.


 Things that could potentially be done for 3rd party applications
 policy handling:

 - Default policy is improved in regards to unknown processes.
    It's yet unknown whether this can be done well enough without
    sacrificing the known functionality, that's why feedback is needed
    on the behavior of 3rd party application use-cases.

 - Applications themselves specify the required policy on install.
    This is extra work for apps, and requires extensive testing to
    guarantee that the policy they choose is good match for
    the application in all cases. (application doesn't leak or
    otherwise hog resources)

 - Some way for user to specify per-application policy.
    I'm sure power-users would like that... :-)


       - Eero
 ___
 maemo-developers mailing list
 maemo-developers@maemo.org
 https://lists.maemo.org/mailman/listinfo/maemo-developers

 ___
 maemo-developers mailing list
 maemo-developers@maemo.org
 https://lists.maemo.org/mailman/listinfo/maemo-developers




-- 
anidel
Sent from London, Eng, United Kingdom
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers


Re: Bug#6203, rotation and OHMD

2009-11-17 Thread Andrew Flegg
On Tue, Nov 17, 2009 at 16:17, Aniello Del Sorbo ani...@gmail.com wrote:

 Is the purpose of OHMD ONLY to pause not whitelisted applications when
 rotating? As if it is so, I'd put a stop ohmd every time I run Xournal
 to make sure it rotates smoothly.

Find a way of including applications which do support rotation in
ohmd's whitelist?

Cheers,

Andrew

-- 
Andrew Flegg -- mailto:and...@bleb.org  |  http://www.bleb.org/
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers


Re: Bug#6203, rotation and OHMD

2009-11-17 Thread Eero Tamminen
Hi,

ext Aniello Del Sorbo wrote:
 according to bug 6203 (https://bugs.maemo.org/show_bug.cgi?id=6203)
 Nokia introduced this ohmd daemon that
 pauses applications not whitelisted so that the rotation itself would
 proceed smoothly.
 
 In the meanwhile Collabora had fixed and improved a lot rotation
 itself, so that this pausing is not needed anymore.
 In fact, it make thinks worse.
 
 Is the purpose of OHMD ONLY to pause not whitelisted applications when 
 rotating?
 As if it is so, I'd put a stop ohmd every time I run Xournal to make
 sure it rotates smoothly.

It handles also audio policies and tries to make sure that you get
your phone calls when the device is heavily loaded and some other
minor things.


- Eero
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers


Re: Bug#6203, rotation and OHMD

2009-11-17 Thread Aniello Del Sorbo
2009/11/17 Eero Tamminen eero.tammi...@nokia.com:
 Hi,

 ext Aniello Del Sorbo wrote:

 according to bug 6203 (https://bugs.maemo.org/show_bug.cgi?id=6203)
 Nokia introduced this ohmd daemon that
 pauses applications not whitelisted so that the rotation itself would
 proceed smoothly.

 In the meanwhile Collabora had fixed and improved a lot rotation
 itself, so that this pausing is not needed anymore.
 In fact, it make thinks worse.

 Is the purpose of OHMD ONLY to pause not whitelisted applications when
 rotating?
 As if it is so, I'd put a stop ohmd every time I run Xournal to make
 sure it rotates smoothly.

 It handles also audio policies and tries to make sure that you get
 your phone calls when the device is heavily loaded and some other
 minor things.


        - Eero


Not something you may want to stop then.

I'll wait for a fix.

-- 
anidel
Sent from London, Eng, United Kingdom
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers