Stop standby on scePowerUnlock if switch flipped while lock.

Torch · Post by **Torch** » Sat Jun 28, 2008 11:51 am

I want to prevent the PSP from going into standby when the power switch is pressed. But if I use scePowerLock and the power switch is flipped while locked, it will power off after scePowerUnlock, just like the SDK says.

How do I prevent this from happening? I don't want to keep the switch permanently locked either. I just need to lock it at a particular moment, but I don't want it to switch off on unlock if the button was pressed while locked.

Pirata Nervo · Post by **Pirata Nervo** » Sat Jun 28, 2008 5:22 pm

remapping the power button should work.
Like remapping it to the R button(I think it's possible to remap buttons) so then if the power button is pressed nothing happens as it has the same effect as the R button.

Torch · Post by **Torch** » Sat Jun 28, 2008 8:26 pm

Pirata Nervo wrote:remapping the power button should work.
Like remapping it to the R button(I think it's possible to remap buttons) so then if the power button is pressed nothing happens as it has the same effect as the R button.

Any sample code? I can't seem to find any. Also the control pad related stuff in the SDK doesn't mention the power switch anywhere, only the other buttons.

Pirata Nervo · Post by **Pirata Nervo** » Sat Jun 28, 2008 9:09 pm

Code: Select all

/* Power Callback */
int power_callback&#40;int unknown, int pwrflags, void *common&#41;
&#123;
    /* check for power switch and suspending as one is manual and the other automatic */
    if &#40;pwrflags & PSP_POWER_CB_POWER_SWITCH || pwrflags & PSP_POWER_CB_SUSPENDING&#41; &#123;
	sprintf&#40;powerCBMessage,
		"first arg&#58; 0x%08X, flags&#58; 0x%08X&#58; suspending\n", unknown, pwrflags&#41;;
    &#125; else if &#40;pwrflags & PSP_POWER_CB_RESUMING&#41; &#123;
	sprintf&#40;powerCBMessage,
		"first arg&#58; 0x%08X, flags&#58; 0x%08X&#58; resuming from suspend mode\n",
		unknown, pwrflags&#41;;
    &#125; else if &#40;pwrflags & PSP_POWER_CB_RESUME_COMPLETE&#41; &#123;
	sprintf&#40;powerCBMessage,
		"first arg&#58; 0x%08X, flags&#58; 0x%08X&#58; resume complete\n", unknown, pwrflags&#41;;
    &#125; else if &#40;pwrflags & PSP_POWER_CB_STANDBY&#41; &#123;
	sprintf&#40;powerCBMessage,
		"first arg&#58; 0x%08X, flags&#58; 0x%08X&#58; entering standby mode\n", unknown, pwrflags&#41;;
    &#125; else &#123;
	sprintf&#40;powerCBMessage, "first arg&#58; 0x%08X, flags&#58; 0x%08X&#58; Unhandled power event\n", unknown, pwrflags&#41;;
    &#125;
    sceDisplayWaitVblankStart&#40;&#41;;

	return 0;
&#125;

that's the power call back, it checks for the switch button, maybe you can hook that or something.

About button remapping:
http://localhost.geek.nz/remapsp/remapspsrc.zip

RemaPSP source code by Danzel

Torch · Post by **Torch** » Sun Jun 29, 2008 2:21 am

Pirata Nervo wrote: that's the power call back, it checks for the switch button, maybe you can hook that or something.

About button remapping:
http://localhost.geek.nz/remapsp/remapspsrc.zip

RemaPSP source code by Danzel

Its only a callback. The system will still receive the shutdown signal. Something else needs to be hooked.

RemaPSP just hooks the control pad functions and modifies them accordingly.

The SDK doesn't have a button defined for the power switch (or its simply left out and I don't know the value.)

Pirata Nervo · Post by **Pirata Nervo** » Sun Jun 29, 2008 4:42 am

Well, I am not sure but what checks the power switch is the Syscon chip right?

adrahil · Post by **adrahil** » Mon Jun 30, 2008 6:32 pm

It is usually not a good idea to lock the power switch for most purposes... What are you trying to accomplish?

There is a way to cancel the suspend, which is returning -1 whenever you receive a suspend notification sysevent. I'd have to find the event specification though, I can't remember from memory what the ID is.

Torch · Post by **Torch** » Mon Jun 30, 2008 6:49 pm

adrahil wrote:It is usually not a good idea to lock the power switch for most purposes... What are you trying to accomplish?

There is a way to cancel the suspend, which is returning -1 whenever you receive a suspend notification sysevent. I'd have to find the event specification though, I can't remember from memory what the ID is.

I want to prevent the PSP from going to suspend for 1 second after the Hold switch is released, because its easy to push the switch to far and suspend the PSP.

adrahil · Post by **adrahil** » Mon Jun 30, 2008 7:04 pm

Oh okay, not a bad idea... I'll try to find the correct way to do so, i'll post it sometime today.

Pirata Nervo · Post by **Pirata Nervo** » Mon Jun 30, 2008 7:15 pm

Cool, that would be nice :)

adrahil · Post by **adrahil** » Mon Jun 30, 2008 7:47 pm

Okay, in order to stop the PSP from going into standby, you have to register a sysevent handler for mask 0x0000FF00, and add something like this into your code:

Code: Select all

#define PSP_SYSEVENT_SUSPEND_QUERY 0x100

int my_handler&#40;int ev_id, char* ev_name, void* param, int* result&#41;&#123;
  if &#40;ev_id == PSP_SYSEVENT_SUSPEND_QUERY&#41; return &#40;suspend_allowed?0&#58;-1&#41;;
  return 0;
&#125;

And then just set suspend_allowed to value 0 to disallow suspend...

The advantage of using the sysevent handler, is that once you register it, it is there, and you don't need to change anything except the suspend_allowed variable - which has to be in global scope by the way.

The disadvantage is that the registering of the handler has to be done in kernel mode, have a look at the sample in samples/kernel/sysevent.

Pirata Nervo · Post by **Pirata Nervo** » Mon Jun 30, 2008 7:56 pm

k thanks :)

Art · Post by **Art** » Mon Jun 30, 2008 10:00 pm

Good thinking... surprised it took two or three years for someone to think of it.
You could also turn off brightness on hold, and turn it back on off hold.

Torch · Post by **Torch** » Tue Jul 01, 2008 2:57 am

Art wrote:Good thinking... surprised it took two or three years for someone to think of it.
You could also turn off brightness on hold, and turn it back on off hold.

I've already done that. Check out Hold+ v1.0 on QJ. (I didn't make the previous hold.prx, that was someone else. It had some bugs and didn't underclock properly so I made a new one myself.)

@adrahil
Its a kernel plugin anyway so no probs. Thank you very much, you'll be in the credits :D

Torch · Post by **Torch** » Tue Jul 01, 2008 5:06 am

All finished, with anti suspend protection: http://forums.qj.net/showthread.php?t=141671

J.F. · Post by **J.F.** » Tue Jul 01, 2008 5:23 am

I would appreciate it if you wouldn't try to redirect people to QJ, especially as you posted the thing on a download service anyway. I don't care if you post it there also, but don't make people here have to go there to get it. I'm trying to boycott QJ, and encouraging others to do so as well.

So that others don't need to go to QJ, here's the link:

http://ifile.it/694jmgv/hold_.v2.0.zip

Torch · Post by **Torch** » Tue Jul 01, 2008 5:26 am

J.F. wrote:I would appreciate it if you wouldn't try to redirect people to QJ, especially as you posted the thing on a download service anyway. I don't care if you post it there also, but don't make people here have to go there to get it. I'm trying to boycott QJ, and encouraging others to do so as well.

So that others don't need to go to QJ, here's the link:

http://ifile.it/694jmgv/hold_.v2.0.zip

LOL OK. I just had a thread with the readme info on it, in case people wanted to read up first, so thats why I posted.

Pirata Nervo · Post by **Pirata Nervo** » Tue Jul 01, 2008 5:51 am

thanks Torch

J.F. · Post by **J.F.** » Tue Jul 01, 2008 9:12 am

Torch wrote:
J.F. wrote:I would appreciate it if you wouldn't try to redirect people to QJ, especially as you posted the thing on a download service anyway. I don't care if you post it there also, but don't make people here have to go there to get it. I'm trying to boycott QJ, and encouraging others to do so as well.

So that others don't need to go to QJ, here's the link:

http://ifile.it/694jmgv/hold_.v2.0.zip
LOL OK. I just had a thread with the readme info on it, in case people wanted to read up first, so thats why I posted.

:)

No problem, but you could have posted the exact same thing here. :)

Torch · Post by **Torch** » Tue Jul 01, 2008 10:20 pm

J.F. wrote: :)

No problem, but you could have posted the exact same thing here. :)

But this isn't exactly some homebrew release channel.

J.F. · Post by **J.F.** » Wed Jul 02, 2008 2:32 am

Torch wrote:
J.F. wrote: :)

No problem, but you could have posted the exact same thing here. :)
But this isn't exactly some homebrew release channel.

It is if you developed it here. :) Dosbox is officially released here. So are a bunch of other things. We just don't keep a database and encourage noobs to frequent the place. It seems a little silly that one would do every last bit of writing a program here, then NOT release the final product here.

In fact, sometimes the finished product goes into the repo so that any time someone gets the SDK, they automatically get it.

Torch · Post by **Torch** » Wed Jul 02, 2008 2:40 am

Oh, OK. Nice to know that. Will release here next time.

@adrahil
Where do you get information about the various sysevents and mask numbers etc. I can't seem to find anything about it anywhere.

adrahil · Post by **adrahil** » Wed Jul 02, 2008 4:16 am

I had done quite a lot of work on them a long while ago, and back then comitted the pspsysevent.h file and sample into the SDK. The information I found on the specific sysevents is located in power.prx.

Yesterday I looked into the 4.01 power.prx, and there are only three main groups of sysevents issued by the PSP:

Code: Select all

- suspend events &#40;mask 0x0000FF00&#41;
- resume events &#40;mask 0x00FF0000&#41;
- CPU speed change events &#40;mask 0x01000000&#41;

I recommend you use the mask 0x00FFFF00 to catch suspend and resume ones. (Mask and event id can be totally unrelated, by the way, but masks can be ORed with each other...)

Here is a little dump of what events are called at PSP suspend/resume:

Code: Select all

0x100 query
0x102 query
0x210 phase2
0x20f phase2
0x20e phase2
0x20d phase2
0x20c phase2
0x20b phase2
0x20a phase2
0x209 phase2
0x208 phase2
0x207 phase2
0x206 phase2
0x205 phase2
0x204 phase2
0x203 phase2
0x202 phase2
0x201 phase2
0x200 phase2
0x400 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x401 phase1
0x402 phase1
0x1000 freeze
0x400f phase0
0x400e phase0
0x400d phase0
0x400c phase0
0x400b phase0
0x400a phase0
0x4009 phase0
0x4008 phase0
0x4007 phase0
0x4006 phase0
0x4005 phase0
0x4004 phase0
0x4003 phase0
0x4002 phase0
0x4001 phase0
0x4000 phase0
0x10000 phase0
0x10001 phase0
0x10002 phase0
0x10003 phase0
0x10004 phase0
0x10005 phase0
0x10006 phase0
0x10007 phase0
0x10008 phase0
0x10009 phase0
0x1000a phase0
0x1000b phase0
0x1000c phase0
0x1000d phase0
0x1000e phase0
0x1000f phase0
0x40000 melt
0x100000 phase1
0x100001 phase1
0x100002 phase1
0x400000 completed

0x4000 is, for instance the last suspend notification, whereas 0x10000 is the first resume.

Torch · Post by **Torch** » Wed Jul 02, 2008 4:28 am

Cool. Are there any other useful sysevents?

Anyway to detect when the system enables the display and lcd backlight when you press a key while they're both turned off either due to idle, or by holding screen button?

I'd like to prevent it from turning on the display and backlight but the key press should still be processed by the system.

adrahil · Post by **adrahil** » Wed Jul 02, 2008 5:19 am

The easiest way to prevent the user from turning on the screen is to hook the button handler in ctrl.prx directly... There also is sceDisplayGetBrightness to get the current brightness, and you can use the GPIO bits to check for display enable :)

No, there are no other sysevents... They don't use it as much.

Torch · Post by **Torch** » Wed Jul 02, 2008 10:22 pm

adrahil wrote:The easiest way to prevent the user from turning on the screen is to hook the button handler in ctrl.prx directly... There also is sceDisplayGetBrightness to get the current brightness, and you can use the GPIO bits to check for display enable :)

I don't understand. How will hooking the button functions prevent the screen from turning on automatically when a button is pressed? I'm not trying to prevent the USER from turning on the screen by pressing the display button. I want to prevent the system from automatically turning it on when any OTHER button is pressed, while the screen is off.

adrahil · Post by **adrahil** » Thu Jul 03, 2008 9:00 am

Well, then hook ctrl.prx and check if the display is disabled, and if so, mask the buttons :)

Torch · Post by **Torch** » Sat Jul 05, 2008 7:23 pm

adrahil wrote:Well, then hook ctrl.prx and check if the display is disabled, and if so, mask the buttons :)

I still don't understand.

I after my hooking function calls the original function I will have the "real" value of "SceCtrlLatch latch;".

My function is supposed to modify this value. I only see it possible to change the buttons pressed. How is this to be modified such that the screen doesn't turn on when a button is pressed?? The original buttons pressed should also remain.

adrahil · Post by **adrahil** » Sat Jul 05, 2008 7:26 pm

Ah, I see what you mean. I don't think it is possible, as the PSP will enable the screen anyways. You might want to look in display.prx for a way to turn the screen off for a long while :)

Torch · Post by **Torch** » Sat Jul 05, 2008 8:34 pm

In that case I'll simply disable the display with sceDisplayDisable and make brightness zero when required. The user will be able to operate the PSP but the display and backlight will remain off.

Theres a slight problem though, if the user presses the display button to turn on the screen, then the PSP goes to the "next" brightness level, instead of remaining at the same brightness level like when the display is manually turned off and turned on by holding the display button.

For this I think I'll have to hook the ctrl.prx functions, and check if the display button is pressed. If pressed while my program has programmatically turned off the display, it should mask it, and programmatically restore the previously stored brightness level. If the display is not currently programmatically turned off it should just ignore it.