| View previous topic :: View next topic |
| Author |
Message |
pegasus2000
Joined: 12 Jul 2006
Posts: 160
|
 Posted: Sat Dec 29, 2007 3:09 am Post subject: 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 ? |
|
| Back to top |
|
 |
sakya
Joined: 28 Apr 2006
Posts: 190
|
| Posted: Sat Dec 29, 2007 3:19 am Post subject: Re: HOME button doesn't work on custom firmware... Why ? |
|
|
Hi! :)
| 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 ? |
To read buttons such as HOME, VOL_UP, NOTE, ecc.. you need to call sceCtrlPeekBufferPositive in kernel mode (in a kernel mode prx). ;)
Ciaooo
Sakya |
|
| Back to top |
|
|
pegasus2000
Joined: 12 Jul 2006
Posts: 160
|
| Posted: Sat Dec 29, 2007 3:36 am Post subject: Re: HOME button doesn't work on custom firmware... Why ? |
|
|
| sakya wrote: | Hi! :)
| 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 ? |
To read buttons such as HOME, VOL_UP, NOTE, ecc.. you need to call sceCtrlPeekBufferPositive in kernel mode (in a kernel mode prx). ;)
Ciaooo
Sakya |
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..... |
|
| Back to top |
|
|
sakya
Joined: 28 Apr 2006
Posts: 190
|
| Posted: Sat Dec 29, 2007 4:01 am Post subject: Re: HOME button doesn't work on custom firmware... Why ? |
|
|
Ciao! :)
| 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..... |
Strange...I use sceCtrlReadBufferPositive in a kernel mode prx and have no problem in reading PSP_CTRL_HOME.
Is it possible that sceCtrlPeekBufferPositive for some reason doesen't read the HOME button?
| Code: | void readButtons(SceCtrlData *pad_data, int count){
k1 = pspSdkSetK1(0);
if (sceKernelDevkitVersion() < 0x03070110)
sceCtrlReadBufferPositive(pad_data, count);
else
sceCtrlReadBufferPositive371(pad_data, count);
pspSdkSetK1(k1);
} |
using this nid:
| Code: | .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 |
Ciaooo
Sakya |
|
| Back to top |
|
|
SamuraiX
Joined: 31 Jan 2006
Posts: 76
Location: USA
|
|
| Back to top |
|
|
pegasus2000
Joined: 12 Jul 2006
Posts: 160
|
| Posted: Sat Dec 29, 2007 9:37 am Post subject: Re: HOME button doesn't work on custom firmware... Why ? |
|
|
| sakya wrote: | Ciao! :)
| 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..... |
Strange...I use sceCtrlReadBufferPositive in a kernel mode prx and have no problem in reading PSP_CTRL_HOME.
Is it possible that sceCtrlPeekBufferPositive for some reason doesen't read the HOME button?
| Code: | void readButtons(SceCtrlData *pad_data, int count){
k1 = pspSdkSetK1(0);
if (sceKernelDevkitVersion() < 0x03070110)
sceCtrlReadBufferPositive(pad_data, count);
else
sceCtrlReadBufferPositive371(pad_data, count);
pspSdkSetK1(k1);
} |
using this nid:
| Code: | .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 |
Ciaooo
Sakya |
SOLVED. I have created a dedicated function in kernel extender...
Grazie Paolo.... |
|
| Back to top |
|
|
J.F.
Joined: 22 Feb 2004
Posts: 2906
|
| Posted: Sat Dec 29, 2007 5:12 pm Post subject: |
|
|
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. |
|
| Back to top |
|
|
adrahil
Joined: 16 Mar 2006
Posts: 277
|
| Posted: Sat Dec 29, 2007 10:28 pm Post subject: |
|
|
| 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 ;) |
|
| Back to top |
|
|
Mihawk
Joined: 03 Apr 2007
Posts: 29
|
| Posted: Sat Dec 29, 2007 11:06 pm Post subject: |
|
|
| 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 ;) |
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?
Ok, if it was sarcasm, then you need to put more ";)" there ;) |
|
| Back to top |
|
|
hlide
Joined: 10 Sep 2006
Posts: 750
|
| Posted: Sun Dec 30, 2007 4:02 am Post subject: |
|
|
ok, let's be sarcastic !
is
| Code: |
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;
|
not similar to
| Code: |
ctrl_button = paddata.Buttons
|
?
it seems everything is here. |
|
| Back to top |
|
|
SamuraiX
Joined: 31 Jan 2006
Posts: 76
Location: USA
|
| Posted: Sun Dec 30, 2007 7:16 am Post subject: |
|
|
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:
| Code: |
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. |
|
| Back to top |
|
|
hlide
Joined: 10 Sep 2006
Posts: 750
|
| Posted: Sun Dec 30, 2007 8:10 am Post subject: |
|
|
| 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: |
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 :
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: |
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;
} |
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. |
|
| Back to top |
|
|
SamuraiX
Joined: 31 Jan 2006
Posts: 76
Location: USA
|
| Posted: Sun Dec 30, 2007 10:55 am Post subject: |
|
|
| 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. |
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.
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. |
|
| Back to top |
|
|
hlide
Joined: 10 Sep 2006
Posts: 750
|
| Posted: Sun Dec 30, 2007 2:17 pm Post subject: |
|
|
| SamuraiX wrote: | | 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. |
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.
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 ?
even with "u32 k1 = pspSdkSetK1(0); ...; pspSdkSetK1(k1);" around ? both for Read and Peek versions ? |
|
| Back to top |
|
|
SamuraiX
Joined: 31 Jan 2006
Posts: 76
Location: USA
|
| Posted: Sun Dec 30, 2007 3:53 pm Post subject: |
|
|
| Just tried that too and no luck. It just doesn't make sense to only partially remove the functionality though. |
|
| Back to top |
|
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
