HOME button doesn't work on custom firmware... Why ?
-
- Posts: 160
- Joined: Wed Jul 12, 2006 7:09 am
HOME button doesn't work on custom firmware... Why ?
When you use sceCtrlPeekBufferPositive on custom firmware, the
HOME button isn't revealed: the routine returns 0.
Do you know what is the origin of the trouble ?
HOME button isn't revealed: the routine returns 0.
Do you know what is the origin of the trouble ?
Re: HOME button doesn't work on custom firmware... Why ?
Hi! :)
Ciaooo
Sakya
To read buttons such as HOME, VOL_UP, NOTE, ecc.. you need to call sceCtrlPeekBufferPositive in kernel mode (in a kernel mode prx). ;)pegasus2000 wrote:When you use sceCtrlPeekBufferPositive on custom firmware, the
HOME button isn't revealed: the routine returns 0.
Do you know what is the origin of the trouble ?
Ciaooo
Sakya
-
- Posts: 160
- Joined: Wed Jul 12, 2006 7:09 am
Re: HOME button doesn't work on custom firmware... Why ?
The trouble isn't here. I'm already in a kernel mode thread (notsakya wrote:Hi! :)To read buttons such as HOME, VOL_UP, NOTE, ecc.. you need to call sceCtrlPeekBufferPositive in kernel mode (in a kernel mode prx). ;)pegasus2000 wrote:When you use sceCtrlPeekBufferPositive on custom firmware, the
HOME button isn't revealed: the routine returns 0.
Do you know what is the origin of the trouble ?
Ciaooo
Sakya
launched by PRX, but from main code), and the other special
keys (VOL_UP, NOTE etc) works. Only HOME button is not
detected.....
Re: HOME button doesn't work on custom firmware... Why ?
Ciao! :)
Is it possible that sceCtrlPeekBufferPositive for some reason doesen't read the HOME button?
using this nid:
Ciaooo
Sakya
Strange...I use sceCtrlReadBufferPositive in a kernel mode prx and have no problem in reading PSP_CTRL_HOME.pegasus2000 wrote:The trouble isn't here. I'm already in a kernel mode thread (not
launched by PRX, but from main code), and the other special
keys (VOL_UP, NOTE etc) works. Only HOME button is not
detected.....
Is it possible that sceCtrlPeekBufferPositive for some reason doesen't read the HOME button?
Code: Select all
void readButtons(SceCtrlData *pad_data, int count){
k1 = pspSdkSetK1(0);
if (sceKernelDevkitVersion() < 0x03070110)
sceCtrlReadBufferPositive(pad_data, count);
else
sceCtrlReadBufferPositive371(pad_data, count);
pspSdkSetK1(k1);
}
Code: Select all
.set noreorder
#include "pspimport.s"
IMPORT_START "sceCtrl_driver",0x00010000
IMPORT_FUNC "sceCtrl_driver",0x6D74BF08,sceCtrlSetSamplingCycle371
IMPORT_FUNC "sceCtrl_driver",0x6A2774F3,sceCtrlSetSamplingCycle
IMPORT_FUNC "sceCtrl_driver",0x28E71A16,sceCtrlSetSamplingMode371
IMPORT_FUNC "sceCtrl_driver",0x1F4011E6,sceCtrlSetSamplingMode
IMPORT_FUNC "sceCtrl_driver",0x454455AC,sceCtrlReadBufferPositive371
IMPORT_FUNC "sceCtrl_driver",0x1F803938,sceCtrlReadBufferPositive
Sakya
Have a look at my ctrlhook.prx source and you will see how its done. It was based off homehook.prx but I went to the extreme.....lol
http://openbor.svn.sourceforge.net/view ... rlhookprx/
Have fun!
http://openbor.svn.sourceforge.net/view ... rlhookprx/
Have fun!
-
- Posts: 160
- Joined: Wed Jul 12, 2006 7:09 am
Re: HOME button doesn't work on custom firmware... Why ?
SOLVED. I have created a dedicated function in kernel extender...sakya wrote:Ciao! :)Strange...I use sceCtrlReadBufferPositive in a kernel mode prx and have no problem in reading PSP_CTRL_HOME.pegasus2000 wrote:The trouble isn't here. I'm already in a kernel mode thread (not
launched by PRX, but from main code), and the other special
keys (VOL_UP, NOTE etc) works. Only HOME button is not
detected.....
Is it possible that sceCtrlPeekBufferPositive for some reason doesen't read the HOME button?
using this nid:Code: Select all
void readButtons(SceCtrlData *pad_data, int count){ k1 = pspSdkSetK1(0); if (sceKernelDevkitVersion() < 0x03070110) sceCtrlReadBufferPositive(pad_data, count); else sceCtrlReadBufferPositive371(pad_data, count); pspSdkSetK1(k1); }
CiaoooCode: Select all
.set noreorder #include "pspimport.s" IMPORT_START "sceCtrl_driver",0x00010000 IMPORT_FUNC "sceCtrl_driver",0x6D74BF08,sceCtrlSetSamplingCycle371 IMPORT_FUNC "sceCtrl_driver",0x6A2774F3,sceCtrlSetSamplingCycle IMPORT_FUNC "sceCtrl_driver",0x28E71A16,sceCtrlSetSamplingMode371 IMPORT_FUNC "sceCtrl_driver",0x1F4011E6,sceCtrlSetSamplingMode IMPORT_FUNC "sceCtrl_driver",0x454455AC,sceCtrlReadBufferPositive371 IMPORT_FUNC "sceCtrl_driver",0x1F803938,sceCtrlReadBufferPositive
Sakya
Grazie Paolo....
Just curious... why do you do every single button separately instead of all at once? You have more than a dozen operations when only one is needed.SamuraiX wrote:Have a look at my ctrlhook.prx source and you will see how its done. It was based off homehook.prx but I went to the extreme.....lol
http://openbor.svn.sourceforge.net/view ... rlhookprx/
Have fun!
If you have three constants or'ed together it's combined to just one constant at compile time. So why would it be better to do a "and plus or" operation three times instead of just one "and" operation? And what difference would it make if you're doing it with assigned registers?adrahil wrote:I don't think that "a=b & (x | y | z)" is much better than "a= b&x; a|=b&y; a|=b&z;"... I think it's even the opposite... Especially since a and b are assigned registers ;)
Ok, if it was sarcasm, then you need to put more ";)" there ;)
ok, let's be sarcastic !
is
not similar to
?
it seems everything is here.
is
Code: Select all
ctrl_button |= paddata.Buttons & PSP_CTRL_SELECT;
ctrl_button |= paddata.Buttons & PSP_CTRL_START;
ctrl_button |= paddata.Buttons & PSP_CTRL_UP;
ctrl_button |= paddata.Buttons & PSP_CTRL_RIGHT;
ctrl_button |= paddata.Buttons & PSP_CTRL_DOWN;
ctrl_button |= paddata.Buttons & PSP_CTRL_LEFT;
ctrl_button |= paddata.Buttons & PSP_CTRL_LTRIGGER;
ctrl_button |= paddata.Buttons & PSP_CTRL_RTRIGGER;
ctrl_button |= paddata.Buttons & PSP_CTRL_TRIANGLE;
ctrl_button |= paddata.Buttons & PSP_CTRL_CIRCLE;
ctrl_button |= paddata.Buttons & PSP_CTRL_CROSS;
ctrl_button |= paddata.Buttons & PSP_CTRL_SQUARE;
ctrl_button |= paddata.Buttons & PSP_CTRL_HOME;
ctrl_button |= paddata.Buttons & PSP_CTRL_HOLD;
ctrl_button |= paddata.Buttons & PSP_CTRL_NOTE;
ctrl_button |= paddata.Buttons & PSP_CTRL_SCREEN;
ctrl_button |= paddata.Buttons & PSP_CTRL_VOLUP;
ctrl_button |= paddata.Buttons & PSP_CTRL_VOLDOWN;
Code: Select all
ctrl_button = paddata.Buttons
it seems everything is here.
I know, I know.... shame on me!!!!! Must lay off the pepper! But I believe initially I didn't want the memory stick active, disc inserted switch to be reported by the prx and just left it as is. Should have just &= the values that i didn't want to be reported.
Soo humiliating but, sharing is caring....lol In any case its been fixed and updated and thank you for the constructive comments....lol
Ok... but i do have a question. I noticed when I do the following for analog mode:
The analog stick is not registered within the prx. But within the pbp it is, any ideas? I know its not a kernel mode issue versus user mode, but the behavior is quite different. Works in one and not the other.
Soo humiliating but, sharing is caring....lol In any case its been fixed and updated and thank you for the constructive comments....lol
Ok... but i do have a question. I noticed when I do the following for analog mode:
Code: Select all
static int ctrl_button_thread(SceSize args, void *argp)
{
sceCtrlSetSamplingCycle(0);
sceCtrlSetSamplingMode(PSP_CTRL_MODE_ANALOG);
sceCtrlData paddata;
while(ctrl_active)
{
ctrl_data = 0;
if(pSceCtrlPeekBufferPositive)
{
(*pSceCtrlPeekBufferPositive)(&paddata, 1);
ctrl_data = paddata.Buttons;
if(paddata.Ly >= 0xC0) ctrl_data |= PSP_CTRL_DOWN;
if(paddata.Ly <= 0x30) ctrl_data |= PSP_CTRL_UP;
if(paddata.Lx <= 0x30) ctrl_data |= PSP_CTRL_LEFT;
if(paddata.Lx >= 0xC0) ctrl_data |= PSP_CTRL_RIGHT;
}
sceKernelDelayThread(10 * 1000);
}
sceKernelExitDeleteThread(0);
return 0;
}
The analog stick is not registered within the prx. But within the pbp it is, any ideas? I know its not a kernel mode issue versus user mode, but the behavior is quite different. Works in one and not the other.
Just some precisions :SamuraiX wrote:I know, I know.... shame on me!!!!! Must lay off the pepper! But I believe initially I didn't want the memory stick active, disc inserted switch to be reported by the prx and just left it as is.
Soo humiliating but, sharing is caring....lol In any case its been fixed and updated and thank you for the constructive comments....lol
Ok... but i do have a question. I noticed when I do the following for analog mode:
Code: Select all
static int ctrl_button_thread(SceSize args, void *argp) { sceCtrlSetSamplingCycle(0); sceCtrlSetSamplingMode(PSP_CTRL_MODE_ANALOG); sceCtrlData paddata; while(ctrl_active) { ctrl_data = 0; if(pSceCtrlPeekBufferPositive) { (*pSceCtrlPeekBufferPositive)(&paddata, 1); ctrl_data = paddata.Buttons; if(paddata.Ly >= 0xC0) ctrl_data |= PSP_CTRL_DOWN; if(paddata.Ly <= 0x30) ctrl_data |= PSP_CTRL_UP; if(paddata.Lx <= 0x30) ctrl_data |= PSP_CTRL_LEFT; if(paddata.Lx >= 0xC0) ctrl_data |= PSP_CTRL_RIGHT; } sceKernelDelayThread(10 * 1000); } sceKernelExitDeleteThread(0); return 0; }
The analog stick is not registered within the prx. But within the pbp it is, any ideas? I know its not a kernel mode issue versus user mode, but the behavior is quite different. Works in one and not the other.
sceCtrlSetSamplingCycle(0) --> set sampling at VSYNCH period
sceCtrlSetSamplingCycle(n) --> set sampling at n microsecond
sceKernelDelayThread(n) --> delay thread for n microsecond
it would probably be more efficient to do this way :
Code: Select all
static int ctrl_button_thread(SceSize args, void *argp)
{
// we want a sampling of 10 ms
sceCtrlSetSamplingCycle(10 * 1000);
sceCtrlSetSamplingMode(PSP_CTRL_MODE_ANALOG);
sceCtrlData paddata;
while (ctrl_active)
{
ctrl_data = 0;
if (pSceCtrlReadBufferPositive)
{
// take the most recent state
if ((*pSceCtrlReadBufferPositive)(&paddata, 0) > 0)
{
ctrl_data = paddata[0].Buttons;
...
}
}
}
sceKernelExitDeleteThread(0);
return 0;
}
Also note, sceCtrlReadBufferPositive is no longer synched with VSYNCH event but has its own timer.
Hmm... without the sleep all I get is a blank screen when timer for ReadBuffer is set to 10 * 1000 (10 milliseconds). Also if I use ReadBuffer there is no control what so ever when sleep thread is used. So I think PeekBuffer is the only one that works in a kernel PRX.hlide wrote:this way, you will get a new state at each 10 ms. No need to sleep the thread, sceCtrlReadBufferPositive does it for you.
Also note, sceCtrlReadBufferPositive is no longer synched with VSYNCH event but has its own timer.
But that still doesn't explain why Peek Buffer is not capable of reading the analog stick when running in a thread from a Kernel Prx.
that's very weird... would Sony have messed with the kernel version in such a way we could not use them anymore except when in user mode ?SamuraiX wrote:Hmm... without the sleep all I get is a blank screen when timer for ReadBuffer is set to 10 * 1000 (10 milliseconds). Also if I use ReadBuffer there is no control what so ever when sleep thread is used. So I think PeekBuffer is the only one that works in a kernel PRX.hlide wrote:this way, you will get a new state at each 10 ms. No need to sleep the thread, sceCtrlReadBufferPositive does it for you.
Also note, sceCtrlReadBufferPositive is no longer synched with VSYNCH event but has its own timer.
But that still doesn't explain why Peek Buffer is not capable of reading the analog stick when running in a thread from a Kernel Prx.
even with "u32 k1 = pspSdkSetK1(0); ...; pspSdkSetK1(k1);" around ? both for Read and Peek versions ?