Tutorial: How to have your nubs change modes upon launching of a PND


Blue Protoman

Well-Known Member
Joined
Mar 6, 2010
Messages
4,117
Here, have a tutorial. Someone mind adding this to the Tweaks thread up top?


First off, why would you want to do this? Simple; at least one person has reported that, when playing a natively-ported FPS (like Duke Nukem or Quake, but not GoldenEye) on the Pandora, using the right nub as the mouse has proven to be more comfortable and less awkward. But switching nub modes manually is annoying; so let's have Linux do it for you!


Step 1


You must download sebt3's new pnd_run.sh installer and run it. Get it here.


This step is no longer required as of Hotfix 6 Alpha 1.


Step 2


Open Mousepad (the text editor), and copy/paste this;



Code:
cat /proc/pandora/nub0/mode > /tmp/nub0mode_before

cat /proc/pandora/nub1/mode > /tmp/nub1mode_before


echo "mbuttons" > /proc/pandora/nub0/mode

echo "mouse" > /proc/pandora/nub1/mode



This will back up your current nub modes, then switch them; the left will act as the mouse buttons, the right will act as the mouse. If you'd like, you can substitute "scroll" or "absolute" (joystick) in, depending on how you like your nubs. But you must save this as "PND_pre_script.sh" (sans quotes). Save it wherever you'd like, you will be moving it elsewhere later.



Step 3

Copy/paste this into Mousepad again. Different file this time.



Code:
cat /tmp/nub0mode_before > /proc/pandora/nub0/mode

cat /tmp/nub1mode_before > /proc/pandora/nub1/mode


rm /tmp/nub0mode_before /tmp/nub1mode_before


This will restore your nub modes to what they were before, and delete the temporary files used to store them. You must save it as "PND_post_script.sh", without the quotes.


Step 4


Simply copy these files into the appdata folder of your program of choice! Now you're done. If you want to test it, drag these files into the appdata of a program that runs windowed (like Comix or Deadbeef), so you can test with the mouse. Simply delete the files if you no longer desire their effects.


And you're done! I can't take full credit for this; someone else wrote the original script, and I modified it. Don't remember who (sorry!).
 
Last edited by a moderator:
Bump. I don't want this valuable advice to get lost because Gruso hasn't added it to the pinned thread!
 
i don't think this should be pinned, just update Tweaks Thread
th_wordsye1.gif
 
Hi Blue Protoman!


But what if the application crashes?


Does the user then return to the OS GUI (MiniMenu or XFCE) with this modified nub setup and must manually change it or reboot (to get back the defaults)?


Post your anwer here, and respectively please update http://pandorawiki.org/PND_nub_modes accordingly.


Thanks, porg
 
Just to get it right, in order to then write reliable info into the wiki:


You put custom pre/post scripts (with standardized filenames, so that your modified pnd_run.sh recognizes them) into the appdata folder of those apps, whose nub behavior you want to change, and then if you launch a PND app, pnd_run.sh runs its associated pre-script, then evaluates the PXML/PND and executes its contained executable accordingly, somewhen later this program is quitted correctly or crashes, and then the encapsulating pnd_run.sh runs the post-script regardless of whether the PND was shutdown correctly or crashed.


Or in other words: pnd_run.sh is the outer loop, the PND app itself the inner loop, so pnd_run always remains "watching/active" throughout PND's execution time.


Right?
 
Alternative option:

  • start the nub configurator
  • create a profile for the setup you wish your application to use.
    Below, I'll assume a profile is created which is called joysticks which places both nubs in joystick mode.
  • Pre application launch:


    Code:
    /usr/pandora/scripts/op_nubmode.py -s temp_profile -p joysticks

    This will store the current configuration in a profile called temp_profile and next will load the joysticks profile.
  • Post application launch:


    Code:
    /usr/pandora/scripts/op_nubmode.py -p temp_profile -d temp_profile

    This will load the previously created profile temp_profile and will remove it afterwards.
Advantage:

Uses the GUI to easily create custom profiles without having to know where values are written to.



Disadvantages:

It is slower, uses some memory and writes profiles to NAND.



If you want to avoid NAND-writes per launch and you always revert back to the same profile after launch then you can use static profiles without having to save and remove the current. E.g. something like:



Before (PND_pre_script.sh):



Code:
/usr/pandora/scripts/op_nubmode.py -p joysticks

After (PND_post_script.sh):



Code:
/usr/pandora/scripts/op_nubmode.py -p Default
 
Last edited by a moderator:
With all the info here in this thread, I totally revised: http://pandorawiki.org/PND_nub_modes

  • Added note, that sebt3's modified pnd_run.sh is included as of Hotfix 6 Alpha 1
  • Added new method from @Caine
  • Added note concerning crash-safety (no affect on general nub behavior but only per app, and postscript runs for sure)
  • Restructured everything to reflect the changes.


Peer review of my wiki update is appreciated. Thanks!
 
Last edited by a moderator:
@sebt3: Thanks for your confirmation.


@Others involved: Would love to get a review on the wiki article, to be certain it is correct!


Just a short OK notice here, or if necessary apply a correction right within the wiki and I get automatically noticed, as the wiki article is on my wiki watchlist.


Thanks!
 
Thanks for that review! This increases my confidence, as articles in the wiki (especially tutorials) are expected to have a certain reliability.
 
Thanks for that review! This increases my confidence, as articles in the wiki (especially tutorials) are expected to have a certain reliability.
Perhaps one small addition. This will break if you launch multiple applications applying this trick. The case where the target controls are different is obvious, but there are more subtle ways to break it.


If you utilize the same temp files in all scripts then the second application will dump the modified controls into the temporary files destroying the original configuration.


Having each application read/write their own temporary file will only partially fix the above problem because the second application to start will capture the modified controls as the controls to restore upon termination. Now, if the first application terminates after the second then all will be fine, but otherwise you end up with changed controls.


Using static profiles like e.g. /usr/pandora/scripts/op_nubmode.py -p Default will avoid that issue, though naturally conflicts in target configurations cannot be resolved. The only way to really work around that is to have OS support such that each process has its own configuration which is made active when you perform a task switch.


I don't think this will be a common problem (you don't run multiple games simultaneously all that often), but it does exist.
 
Why do you need temp files anyway? You can (and should) use /etc/pandora/conf/nubs.state to restore the last nubs configuration activated via the nub configurator. BTW, that's how PNDconfig works.
 
Last edited by a moderator:
Back
Top