forums.ps2dev.org Forum Index forums.ps2dev.org
Homebrew PS2, PSP & PS3 Development Discussions
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Stop standby on scePowerUnlock if switch flipped while lock.
Goto page 1, 2  Next
 
Post new topic   Reply to topic    forums.ps2dev.org Forum Index -> PSP Development
View previous topic :: View next topic  
Author Message
Torch



Joined: 28 May 2008
Posts: 842

PostPosted: Sat Jun 28, 2008 11:51 am    Post subject: Stop standby on scePowerUnlock if switch flipped while lock. Reply with quote

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.
Back to top
View user's profile Send private message
Pirata Nervo



Joined: 09 Oct 2007
Posts: 409

PostPosted: Sat Jun 28, 2008 5:22 pm    Post subject: Reply with quote

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

Upgrade your PSP
Back to top
View user's profile Send private message
Torch



Joined: 28 May 2008
Posts: 842

PostPosted: Sat Jun 28, 2008 8:26 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
Pirata Nervo



Joined: 09 Oct 2007
Posts: 409

PostPosted: Sat Jun 28, 2008 9:09 pm    Post subject: Reply with quote

Code:

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

   return 0;
}

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
_________________

Upgrade your PSP
Back to top
View user's profile Send private message
Torch



Joined: 28 May 2008
Posts: 842

PostPosted: Sun Jun 29, 2008 2:21 am    Post subject: Reply with quote

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.)
Back to top
View user's profile Send private message
Pirata Nervo



Joined: 09 Oct 2007
Posts: 409

PostPosted: Sun Jun 29, 2008 4:42 am    Post subject: Reply with quote

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

Upgrade your PSP
Back to top
View user's profile Send private message
adrahil



Joined: 16 Mar 2006
Posts: 277

PostPosted: Mon Jun 30, 2008 6:32 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
Torch



Joined: 28 May 2008
Posts: 842

PostPosted: Mon Jun 30, 2008 6:49 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
adrahil



Joined: 16 Mar 2006
Posts: 277

PostPosted: Mon Jun 30, 2008 7:04 pm    Post subject: Reply with quote

Oh okay, not a bad idea... I'll try to find the correct way to do so, i'll post it sometime today.
Back to top
View user's profile Send private message
Pirata Nervo



Joined: 09 Oct 2007
Posts: 409

PostPosted: Mon Jun 30, 2008 7:15 pm    Post subject: Reply with quote

Cool, that would be nice :)
_________________

Upgrade your PSP
Back to top
View user's profile Send private message
adrahil



Joined: 16 Mar 2006
Posts: 277

PostPosted: Mon Jun 30, 2008 7:47 pm    Post subject: Reply with quote

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:

#define PSP_SYSEVENT_SUSPEND_QUERY 0x100

int my_handler(int ev_id, char* ev_name, void* param, int* result){
  if (ev_id == PSP_SYSEVENT_SUSPEND_QUERY) return (suspend_allowed?0:-1);
  return 0;
}


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.
Back to top
View user's profile Send private message
Pirata Nervo



Joined: 09 Oct 2007
Posts: 409

PostPosted: Mon Jun 30, 2008 7:56 pm    Post subject: Reply with quote

k thanks :)
_________________

Upgrade your PSP
Back to top
View user's profile Send private message
Art



Joined: 09 Nov 2005
Posts: 647

PostPosted: Mon Jun 30, 2008 10:00 pm    Post subject: Reply with quote

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.
_________________
If not actually, then potentially.
Back to top
View user's profile Send private message
Torch



Joined: 28 May 2008
Posts: 842

PostPosted: Tue Jul 01, 2008 2:57 am    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
Torch



Joined: 28 May 2008
Posts: 842

PostPosted: Tue Jul 01, 2008 5:06 am    Post subject: Reply with quote

All finished, with anti suspend protection: http://forums.qj.net/showthread.php?t=141671
Back to top
View user's profile Send private message
J.F.



Joined: 22 Feb 2004
Posts: 2906

PostPosted: Tue Jul 01, 2008 5:23 am    Post subject: Reply with quote

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
Back to top
View user's profile Send private message AIM Address
Torch



Joined: 28 May 2008
Posts: 842

PostPosted: Tue Jul 01, 2008 5:26 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
Pirata Nervo



Joined: 09 Oct 2007
Posts: 409

PostPosted: Tue Jul 01, 2008 5:51 am    Post subject: Reply with quote

thanks Torch
_________________

Upgrade your PSP
Back to top
View user's profile Send private message
J.F.



Joined: 22 Feb 2004
Posts: 2906

PostPosted: Tue Jul 01, 2008 9:12 am    Post subject: Reply with quote

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. :)
Back to top
View user's profile Send private message AIM Address
Torch



Joined: 28 May 2008
Posts: 842

PostPosted: Tue Jul 01, 2008 10:20 pm    Post subject: Reply with quote

J.F. wrote:

:)

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


But this isn't exactly some homebrew release channel.
Back to top
View user's profile Send private message
J.F.



Joined: 22 Feb 2004
Posts: 2906

PostPosted: Wed Jul 02, 2008 2:32 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message AIM Address
Torch



Joined: 28 May 2008
Posts: 842

PostPosted: Wed Jul 02, 2008 2:40 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
adrahil



Joined: 16 Mar 2006
Posts: 277

PostPosted: Wed Jul 02, 2008 4:16 am    Post subject: Reply with quote

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:

- suspend events (mask 0x0000FF00)
- resume events (mask 0x00FF0000)
- CPU speed change events (mask 0x01000000)


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:
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.
Back to top
View user's profile Send private message
Torch



Joined: 28 May 2008
Posts: 842

PostPosted: Wed Jul 02, 2008 4:28 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
adrahil



Joined: 16 Mar 2006
Posts: 277

PostPosted: Wed Jul 02, 2008 5:19 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
Torch



Joined: 28 May 2008
Posts: 842

PostPosted: Wed Jul 02, 2008 10:22 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
adrahil



Joined: 16 Mar 2006
Posts: 277

PostPosted: Thu Jul 03, 2008 9:00 am    Post subject: Reply with quote

Well, then hook ctrl.prx and check if the display is disabled, and if so, mask the buttons :)
Back to top
View user's profile Send private message
Torch



Joined: 28 May 2008
Posts: 842

PostPosted: Sat Jul 05, 2008 7:23 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
adrahil



Joined: 16 Mar 2006
Posts: 277

PostPosted: Sat Jul 05, 2008 7:26 pm    Post subject: Reply with quote

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 :)
Back to top
View user's profile Send private message
Torch



Joined: 28 May 2008
Posts: 842

PostPosted: Sat Jul 05, 2008 8:34 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    forums.ps2dev.org Forum Index -> PSP Development All times are GMT + 10 Hours
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group