Active Topics
pali |
2012-07-25
, 10:33
|
|
Posts: 2,153 |
Thanked: 8,462 times |
Joined on May 2010
|
#41
|
if you set both PB_CLASS_VOIP and PB_STATE_PLAY in libplayback then jackbias is ON. But in this state is volume from non VOIP applications muted. So MAFW in this state not working...
|
|
2012-07-25
, 11:15
|
|
Posts: 203 |
Thanked: 445 times |
Joined on Mar 2010
|
#42
|
Ah, that reminds me of something I liked on my old Palm Pre, and missed when I switched to the N900:
When listening to music, on incoming SMS, Chats, etc, the Pre would lower the volume of the music (instead of muting, like the N900 does) and overlay the event sound. The result was quite pleasant for the listener, I think.
Your findings, pali, sound like they could have something to do with that (i.e. MAFW being muted). Maybe it'd be possible in the future to make the N900 behave similarly to the Pre?
Last edited by foobar; 2012-07-25 at 11:40.
When listening to music, on incoming SMS, Chats, etc, the Pre would lower the volume of the music (instead of muting, like the N900 does) and overlay the event sound. The result was quite pleasant for the listener, I think.
Your findings, pali, sound like they could have something to do with that (i.e. MAFW being muted). Maybe it'd be possible in the future to make the N900 behave similarly to the Pre?
Last edited by foobar; 2012-07-25 at 11:40.
| The Following User Says Thank You to foobar For This Useful Post: | ||
|
|
2012-07-25
, 11:18
|
|
Posts: 2,153 |
Thanked: 8,462 times |
Joined on May 2010
|
#43
|
This sounds easy for SMS, Chat, Email, .. (not for calls). Ask on OMP thread. OMP now has support to "force" all sounds to mute and also handle maemo events (incoming call). So I think SW interfaces for this are prepaired in OMP.
|
|
2012-07-25
, 15:06
|
|
Posts: 1 |
Thanked: 10 times |
Joined on Jul 2012
@ Espoo, Finland
|
#44
|
Hello guys !
Sorry for the idiotic way to reply to jonwils message but I'm in the middle of my (apparently way too successful) vacation and seem to be unable to recall my gitorious password right now. Hence I cannot reply to him personally so I need to answer here. I hope you don't mind, jonwil. I did not see anything personal in your message so I took the liberty to cut'n paste it here with my original answers...
Anyway, first of all good detective work guys. Basically your decompiled prolog predicates have all the policy logic for controlling jack-bias (ie. enabling/disabling headset button detection). Basically button press detection is enabled if there is an incoming (IP or CS) call in alerting or active (= accepted) state and there is a headset connected to the device.
Now as some of you have realised, probably the easiest way to achieve what you want would be to modify the logical alsaped
control definitions so that jack-bias is always on whenever there is a headset connected. This might also involve changing jackbias-off to be a no-op so that ohm cannot disable jack-bias when a call is rejected/disconnected (see my original reply below).
However, now that you have the decompiled predicates another, very very intriguing way to accomplish what you want would be to decompile the prolog ruleset part, drop it under another name in the basic ruleset tree, compile the ruleset (using the stock Makefiles of the basic ruleset), take the resulting policy.plc and replace the stock policy.plc with it.
Because of the way how the ruleset is precompiled, this might require modifying the dres part of the ruleset just to get the whole shebang precompiling, even if you don't use the resulting dresc file. You need to test it in practice to see if this is needed.
This would basically properly modify the ruleset to get what you want. This would still be half-assed in the sense that you would not have the full ruleset, but for this particular case it shold work because all the logic for flipping jackbias on/off is done by the prolog predicates IIRC. A bigger limitation is that you still would not be able to add new things to the ruleset because those you typically hook into one of the top-level dres targets corresponding to an appropriate system or client event.
That said, it would be very much possible to decompile the dres part as well. You might want to give it a try that as well. Actually if you look at the binary loading code, you can see that everything else is self-explanatorily trivial except to get back the original target updating scriptlets which should not be that hard either. dres uses a stack-based byte-code-compiled VM for the scriptlets and from the binary ruleset you get back the VM binary byte-code. The same one you can see in symbolic form if you drop the ohm console plugin in place (to get it automatically loaded when ohm starts up), telnet to the debug console, then do a 'grab all' (or was it just 'grab') and then a 'dump targets'. To get back the original scriptlets, you need to take a look at the dres script parser (dres/src/{parser.y, ast.c}), the VM byte compiler (dres/src/compiler.c) to see how the scripts are turned first to an AST and then how the AST is compiled to the VM assembler. Then you need to take the binary scriptlet VM byte code for each target and decompile it using this information.
If you did this, you would end up having the full ruleset in source form and you could pretty much hack on it freely... That would be pretty cool, if you ask me.
A couple of other notes:
1)
The fact_exists predicate has its first argument the name of a 'factstore' variable of ohm. Factstore is the in-memory DB used in the N900 policy in ohm and the first argument basically denotes something similar to a table in a DB. Typically those are used to represent decisions such as audio routing, video routing, or some resource arbitration (or eg. the state of the jackbias ALSA switch).
2)
I would not try to use the socket based app-detector interface to fool policy/ohm. Basically app-detector is used to track which application is in the foreground (ie. which app the user is interacting with it). It reports this to policy/ohm where this typically triggers a decision which reconfigures how CPU and memory is allocated to the different logical process (c)groups. If you try to fake things with this you might have some very undesirable side-effects (such as most application groups getting frozen for several seconds, or a lot of memory getting reclaimed from some applications causing a huge swap storm and a lot of I/O wait).
Cheers,
kli
Here is my original answer before I saw your decompilation work:
>
> Hi Krisztian,
> I am a developer working (along with other developers) on the Nokia N900 Open Hardware Manager. We are trying to find a way to enable the jackbias setting for headphones for use in things other than phone calls such as media players.
>
> We have located source code for the various Open Hardware Manager bits that matches the binaries shipped with the N900 (including libprolog, libdres, and ohm-plugins-misc) but we can't find a way to enable jackbias without pretending to be a VOIP call (which has unwanted side-effects)
> Some analysis with swi-prolog shows that the jackbias seems to be handled by logic inside the compiled prolog and dresrc files (policy.plc and policy.dresrc) but we cant find any mention of jackbias in the "policy-settings-basic" source code on gitorius.
>
Yes, unfortunately Nokia did not open source the full policy ruleset for the N900. Policy-setting-basic is a very much stripped down version of the ruleset that only includes basic resource arbitration for audio/video/camera playback/recording (ie. the decision making backend for libplayback) and audio input/output routing. For instance all the call handling logic and cgroup-based memory and CPU cycle allocation is excluded from it. It was meant to be merely as a demo and a starting point for other projects/devices for a policy ruleset.
> Is there any information you can share regarding where the jackbias logic is, how it works and how we might be able to turn it on without needing to pretend to be a VOIP call?
It was a long time ago and meanwhile having worked on the policy for the N9 have faded my N900 memories even further but IIRC the actual jackbias control is in the alsaped configuration. Policy (ohm based on the policy decisions) merely tells alsaped and pulseaudio high-level routing etc. commands and these enforcement points do any necessary configuration changes in their own enforcement domain. Hence, although you cannot do the 'Right Thing' as you (or me) do not have the N900 ruleset sources, one acceptable workaround might be to modify the alsaped configuration (/usr/share/policy/etc/rx51/alsaped.conf, I don't have such good memory, but luckily I have my kids N900 here so I could take the terminal and check the path ;-) to have the jack-bias on in all configurations where you have a headset connected.
The brute force way would be to keep jack-bias always on. However that would have a negative effect on the already not very good battery life of the N900. It also might have other unwanted side effects that I'm not aware of/cannot remember, so I would not start from that. You might need to add other kludges, particularly you might need to change the configuration of jackbias-off so that's its either a no-op or even to turn jack-bias on. This depends on the order in which policy decision are emitted on the bus by policy/ohmd when a phonecall comes in/is accepted/is ended. You need to dbus-monitor the decisions to see whether it's needed.
> We really want to make jackbias work as it is needed to make the headset button on the wired headphones function properly.
Yes, you need it to detect button presses on the headset...
Sorry for the idiotic way to reply to jonwils message but I'm in the middle of my (apparently way too successful) vacation and seem to be unable to recall my gitorious password right now. Hence I cannot reply to him personally so I need to answer here. I hope you don't mind, jonwil. I did not see anything personal in your message so I took the liberty to cut'n paste it here with my original answers...
Anyway, first of all good detective work guys. Basically your decompiled prolog predicates have all the policy logic for controlling jack-bias (ie. enabling/disabling headset button detection). Basically button press detection is enabled if there is an incoming (IP or CS) call in alerting or active (= accepted) state and there is a headset connected to the device.
Now as some of you have realised, probably the easiest way to achieve what you want would be to modify the logical alsaped
control definitions so that jack-bias is always on whenever there is a headset connected. This might also involve changing jackbias-off to be a no-op so that ohm cannot disable jack-bias when a call is rejected/disconnected (see my original reply below).
However, now that you have the decompiled predicates another, very very intriguing way to accomplish what you want would be to decompile the prolog ruleset part, drop it under another name in the basic ruleset tree, compile the ruleset (using the stock Makefiles of the basic ruleset), take the resulting policy.plc and replace the stock policy.plc with it.
Because of the way how the ruleset is precompiled, this might require modifying the dres part of the ruleset just to get the whole shebang precompiling, even if you don't use the resulting dresc file. You need to test it in practice to see if this is needed.
This would basically properly modify the ruleset to get what you want. This would still be half-assed in the sense that you would not have the full ruleset, but for this particular case it shold work because all the logic for flipping jackbias on/off is done by the prolog predicates IIRC. A bigger limitation is that you still would not be able to add new things to the ruleset because those you typically hook into one of the top-level dres targets corresponding to an appropriate system or client event.
That said, it would be very much possible to decompile the dres part as well. You might want to give it a try that as well. Actually if you look at the binary loading code, you can see that everything else is self-explanatorily trivial except to get back the original target updating scriptlets which should not be that hard either. dres uses a stack-based byte-code-compiled VM for the scriptlets and from the binary ruleset you get back the VM binary byte-code. The same one you can see in symbolic form if you drop the ohm console plugin in place (to get it automatically loaded when ohm starts up), telnet to the debug console, then do a 'grab all' (or was it just 'grab') and then a 'dump targets'. To get back the original scriptlets, you need to take a look at the dres script parser (dres/src/{parser.y, ast.c}), the VM byte compiler (dres/src/compiler.c) to see how the scripts are turned first to an AST and then how the AST is compiled to the VM assembler. Then you need to take the binary scriptlet VM byte code for each target and decompile it using this information.
If you did this, you would end up having the full ruleset in source form and you could pretty much hack on it freely... That would be pretty cool, if you ask me.
A couple of other notes:
1)
The fact_exists predicate has its first argument the name of a 'factstore' variable of ohm. Factstore is the in-memory DB used in the N900 policy in ohm and the first argument basically denotes something similar to a table in a DB. Typically those are used to represent decisions such as audio routing, video routing, or some resource arbitration (or eg. the state of the jackbias ALSA switch).
2)
I would not try to use the socket based app-detector interface to fool policy/ohm. Basically app-detector is used to track which application is in the foreground (ie. which app the user is interacting with it). It reports this to policy/ohm where this typically triggers a decision which reconfigures how CPU and memory is allocated to the different logical process (c)groups. If you try to fake things with this you might have some very undesirable side-effects (such as most application groups getting frozen for several seconds, or a lot of memory getting reclaimed from some applications causing a huge swap storm and a lot of I/O wait).
Cheers,
kli
Here is my original answer before I saw your decompilation work:
>
> Hi Krisztian,
> I am a developer working (along with other developers) on the Nokia N900 Open Hardware Manager. We are trying to find a way to enable the jackbias setting for headphones for use in things other than phone calls such as media players.
>
> We have located source code for the various Open Hardware Manager bits that matches the binaries shipped with the N900 (including libprolog, libdres, and ohm-plugins-misc) but we can't find a way to enable jackbias without pretending to be a VOIP call (which has unwanted side-effects)
> Some analysis with swi-prolog shows that the jackbias seems to be handled by logic inside the compiled prolog and dresrc files (policy.plc and policy.dresrc) but we cant find any mention of jackbias in the "policy-settings-basic" source code on gitorius.
>
Yes, unfortunately Nokia did not open source the full policy ruleset for the N900. Policy-setting-basic is a very much stripped down version of the ruleset that only includes basic resource arbitration for audio/video/camera playback/recording (ie. the decision making backend for libplayback) and audio input/output routing. For instance all the call handling logic and cgroup-based memory and CPU cycle allocation is excluded from it. It was meant to be merely as a demo and a starting point for other projects/devices for a policy ruleset.
> Is there any information you can share regarding where the jackbias logic is, how it works and how we might be able to turn it on without needing to pretend to be a VOIP call?
It was a long time ago and meanwhile having worked on the policy for the N9 have faded my N900 memories even further but IIRC the actual jackbias control is in the alsaped configuration. Policy (ohm based on the policy decisions) merely tells alsaped and pulseaudio high-level routing etc. commands and these enforcement points do any necessary configuration changes in their own enforcement domain. Hence, although you cannot do the 'Right Thing' as you (or me) do not have the N900 ruleset sources, one acceptable workaround might be to modify the alsaped configuration (/usr/share/policy/etc/rx51/alsaped.conf, I don't have such good memory, but luckily I have my kids N900 here so I could take the terminal and check the path ;-) to have the jack-bias on in all configurations where you have a headset connected.
The brute force way would be to keep jack-bias always on. However that would have a negative effect on the already not very good battery life of the N900. It also might have other unwanted side effects that I'm not aware of/cannot remember, so I would not start from that. You might need to add other kludges, particularly you might need to change the configuration of jackbias-off so that's its either a no-op or even to turn jack-bias on. This depends on the order in which policy decision are emitted on the bus by policy/ohmd when a phonecall comes in/is accepted/is ended. You need to dbus-monitor the decisions to see whether it's needed.
> We really want to make jackbias work as it is needed to make the headset button on the wired headphones function properly.
Yes, you need it to detect button presses on the headset...
|
|
2012-07-25
, 15:24
|
|
Posts: 2,153 |
Thanked: 8,462 times |
Joined on May 2010
|
#45
|
@kli, hello, my idea is to load plc file into swipl, write new predicate for jackbias (see code under). then using assert & retract replace existing and then compile code to plc file via qsave_program. Will it work?
This code should enable/disable jackbias when headset is connected/disconnected. I removed call predicates.
Code:
context_variable(jackbias, B) :- ( headset_accessible *-> A=on ; A=off ), context_entry(jackbias, A, B).
|
|
2012-07-25
, 15:37
|
|
Posts: 567 |
Thanked: 2,965 times |
Joined on Oct 2009
|
#46
|
Just to keep things in one place, here are some logs I made by using various parts of swi-prolog to decompile stuff
http://www.cncmods.net/files/prolog.log
http://www.cncmods.net/files/prolog2.log
http://www.cncmods.net/files/prolog.log
http://www.cncmods.net/files/prolog2.log
|
|
2012-07-25
, 15:42
|
|
Posts: 1,680 |
Thanked: 3,685 times |
Joined on Jan 2011
|
#47
|
Originally Posted by kli
Kli delivers!
Hello guys !
Sorry for the idiotic way to reply to jonwils message but I'm in the middle of my (apparently way too successful) vacation and seem to be unable to recall my gitorious password right now. Hence I cannot reply to him personally so I need to answer here. I hope you don't mind, jonwil. I did not see anything personal in your message so I took the liberty to cut'n paste it here with my original answers...
Anyway, first of all good detective work guys. Basically your decompiled prolog predicates have all the policy logic for controlling jack-bias (ie. enabling/disabling headset button detection). Basically button press detection is enabled if there is an incoming (IP or CS) call in alerting or active (= accepted) state and there is a headset connected to the device.
Now as some of you have realised, probably the easiest way to achieve what you want would be to modify the logical alsaped
control definitions so that jack-bias is always on whenever there is a headset connected. This might also involve changing jackbias-off to be a no-op so that ohm cannot disable jack-bias when a call is rejected/disconnected (see my original reply below).
However, now that you have the decompiled predicates another, very very intriguing way to accomplish what you want would be to decompile the prolog ruleset part, drop it under another name in the basic ruleset tree, compile the ruleset (using the stock Makefiles of the basic ruleset), take the resulting policy.plc and replace the stock policy.plc with it.
Because of the way how the ruleset is precompiled, this might require modifying the dres part of the ruleset just to get the whole shebang precompiling, even if you don't use the resulting dresc file. You need to test it in practice to see if this is needed.
This would basically properly modify the ruleset to get what you want. This would still be half-assed in the sense that you would not have the full ruleset, but for this particular case it shold work because all the logic for flipping jackbias on/off is done by the prolog predicates IIRC. A bigger limitation is that you still would not be able to add new things to the ruleset because those you typically hook into one of the top-level dres targets corresponding to an appropriate system or client event.
That said, it would be very much possible to decompile the dres part as well. You might want to give it a try that as well. Actually if you look at the binary loading code, you can see that everything else is self-explanatorily trivial except to get back the original target updating scriptlets which should not be that hard either. dres uses a stack-based byte-code-compiled VM for the scriptlets and from the binary ruleset you get back the VM binary byte-code. The same one you can see in symbolic form if you drop the ohm console plugin in place (to get it automatically loaded when ohm starts up), telnet to the debug console, then do a 'grab all' (or was it just 'grab') and then a 'dump targets'. To get back the original scriptlets, you need to take a look at the dres script parser (dres/src/{parser.y, ast.c}), the VM byte compiler (dres/src/compiler.c) to see how the scripts are turned first to an AST and then how the AST is compiled to the VM assembler. Then you need to take the binary scriptlet VM byte code for each target and decompile it using this information.
If you did this, you would end up having the full ruleset in source form and you could pretty much hack on it freely... That would be pretty cool, if you ask me.
A couple of other notes:
1)
The fact_exists predicate has its first argument the name of a 'factstore' variable of ohm. Factstore is the in-memory DB used in the N900 policy in ohm and the first argument basically denotes something similar to a table in a DB. Typically those are used to represent decisions such as audio routing, video routing, or some resource arbitration (or eg. the state of the jackbias ALSA switch).
2)
I would not try to use the socket based app-detector interface to fool policy/ohm. Basically app-detector is used to track which application is in the foreground (ie. which app the user is interacting with it). It reports this to policy/ohm where this typically triggers a decision which reconfigures how CPU and memory is allocated to the different logical process (c)groups. If you try to fake things with this you might have some very undesirable side-effects (such as most application groups getting frozen for several seconds, or a lot of memory getting reclaimed from some applications causing a huge swap storm and a lot of I/O wait).
Cheers,
kli
Here is my original answer before I saw your decompilation work:
>
> Hi Krisztian,
> I am a developer working (along with other developers) on the Nokia N900 Open Hardware Manager. We are trying to find a way to enable the jackbias setting for headphones for use in things other than phone calls such as media players.
>
> We have located source code for the various Open Hardware Manager bits that matches the binaries shipped with the N900 (including libprolog, libdres, and ohm-plugins-misc) but we can't find a way to enable jackbias without pretending to be a VOIP call (which has unwanted side-effects)
> Some analysis with swi-prolog shows that the jackbias seems to be handled by logic inside the compiled prolog and dresrc files (policy.plc and policy.dresrc) but we cant find any mention of jackbias in the "policy-settings-basic" source code on gitorius.
>
Yes, unfortunately Nokia did not open source the full policy ruleset for the N900. Policy-setting-basic is a very much stripped down version of the ruleset that only includes basic resource arbitration for audio/video/camera playback/recording (ie. the decision making backend for libplayback) and audio input/output routing. For instance all the call handling logic and cgroup-based memory and CPU cycle allocation is excluded from it. It was meant to be merely as a demo and a starting point for other projects/devices for a policy ruleset.
> Is there any information you can share regarding where the jackbias logic is, how it works and how we might be able to turn it on without needing to pretend to be a VOIP call?
It was a long time ago and meanwhile having worked on the policy for the N9 have faded my N900 memories even further but IIRC the actual jackbias control is in the alsaped configuration. Policy (ohm based on the policy decisions) merely tells alsaped and pulseaudio high-level routing etc. commands and these enforcement points do any necessary configuration changes in their own enforcement domain. Hence, although you cannot do the 'Right Thing' as you (or me) do not have the N900 ruleset sources, one acceptable workaround might be to modify the alsaped configuration (/usr/share/policy/etc/rx51/alsaped.conf, I don't have such good memory, but luckily I have my kids N900 here so I could take the terminal and check the path ;-) to have the jack-bias on in all configurations where you have a headset connected.
The brute force way would be to keep jack-bias always on. However that would have a negative effect on the already not very good battery life of the N900. It also might have other unwanted side effects that I'm not aware of/cannot remember, so I would not start from that. You might need to add other kludges, particularly you might need to change the configuration of jackbias-off so that's its either a no-op or even to turn jack-bias on. This depends on the order in which policy decision are emitted on the bus by policy/ohmd when a phonecall comes in/is accepted/is ended. You need to dbus-monitor the decisions to see whether it's needed.
> We really want to make jackbias work as it is needed to make the headset button on the wired headphones function properly.
Yes, you need it to detect button presses on the headset...
FWIW, with slightly higher capacity batteries (+150maH) and a bunch of kernel modifications (AHEM, smart reflex) the N900 actually has pretty decent battery life these days.
__________________
N900: One of God's own prototypes. A high-powered mutant of some kind never even considered for mass production. Too weird to live, and too rare to die.
| The Following 2 Users Say Thank You to vi_ For This Useful Post: | ||
 |
|
2012-07-29
, 01:41
|
|
Posts: 5,028 |
Thanked: 8,613 times |
Joined on Mar 2011
|
#48
|
But, of course, we don't want any negative impact on battery life, where avoidable 
Even using 3Ah batteries, or, soon to come, 6Ah ones.
Even using 3Ah batteries, or, soon to come, 6Ah ones.
__________________
N900's aluminum backcover / body replacement
-
N900's HDMI-Out
-
Camera cover MOD
-
Measure battery's real capacity on-device
-
TrueCrypt 7.1 | ereswap | bnf
-
Hardware's mods research is costly. To support my work, please consider donating. Thank You!
N900's aluminum backcover / body replacement
-
N900's HDMI-Out
-
Camera cover MOD
-
Measure battery's real capacity on-device
-
TrueCrypt 7.1 | ereswap | bnf
-
Hardware's mods research is costly. To support my work, please consider donating. Thank You!
|
|
2012-08-16
, 09:30
|
|
Posts: 2,153 |
Thanked: 8,462 times |
Joined on May 2010
|
#49
|
SWI prolog binary state file policy.plc was successfully decompiled into prolog source files. I also fixed jackbias problem and created new deb package for cssu-devel:
http://gitorious.org/community-ssu/policy-settings-rx51
http://maemo.merlin1991.at/cssu/comm...settings-rx51/
Scripts for decompiling binary SWI prolog state files are here:
https://gitorious.org/community-ssu/...plc-predicates
https://gitorious.org/community-ssu/.../plc-decompile
Note that for decompiling you need same SWI prolog version which was used for compiling file. You can find prolog version in first 10 lines in binary file. In binary plc file is line:
So this means that our policy.plc was compiled by SWI prolog version 5.6.50
http://gitorious.org/community-ssu/policy-settings-rx51
http://maemo.merlin1991.at/cssu/comm...settings-rx51/
Scripts for decompiling binary SWI prolog state files are here:
https://gitorious.org/community-ssu/...plc-predicates
https://gitorious.org/community-ssu/.../plc-decompile
Note that for decompiling you need same SWI prolog version which was used for compiling file. You can find prolog version in first 10 lines in binary file. In binary plc file is line:
Code:
exec ${SWIPL-/usr/lib/swipl-5.6.50/bin/armel/swipl} -x "$0" -- "$@"
| The Following 5 Users Say Thank You to pali For This Useful Post: | ||