generic PSP IR Keyboard library now in SVN
generic PSP IR Keyboard library now in SVN
Hi everybody,
the generic PSP IR Keyboard library hosted at http://pspirkeyb.podzone.net is now in PSP svn.
svn://svn.pspdev.org/psp/trunk/pspirkeyb
Please add support to your IR keyboards if you have one :)
Bye.
Monsti
the generic PSP IR Keyboard library hosted at http://pspirkeyb.podzone.net is now in PSP svn.
svn://svn.pspdev.org/psp/trunk/pspirkeyb
Please add support to your IR keyboards if you have one :)
Bye.
Monsti
Keymaps are already read by files. I am speaking of creating a PRX based api - a kind of "driver" concept. New pspirkeyb.prx versions can support more keyboards.harleyg wrote:Why not read keymaps etc from files?
IR Keyboards are no linear "IR byte" to "key" mapping. Every keyboard has it's own protocol :(
So it might be a good idea to make a prx and let the user replace the prx without the need of recompiling the application.
Monsti
I'm looking at integrating this into an app.
How do you set the files up on your memory stick? It looks like it should be as follows:
Just asking as it isn't documented anywhere from what I've seen.
Also, I take it that the list of keyboards in pspirkeyb/libpspirkeyb/config/pspirkeyb.ini is correct and up to date? Will go get a keyboard tomorrow if I can find one.
How do you set the files up on your memory stick? It looks like it should be as follows:
Code: Select all
ms0:/seplugins/pspirkeyb.ini
ms0:/seplugins/keymap/default.ini
ms0:/seplugins/keymap/azert-include.ini
<repeat for other keymaps>
Also, I take it that the list of keyboards in pspirkeyb/libpspirkeyb/config/pspirkeyb.ini is correct and up to date? Will go get a keyboard tomorrow if I can find one.
I've got a Thinkoutside / iGo 4-row Stowaway, that uses the same protocol as the Palm UW keyboard, but has a different physical row/col keymap to the Palm UW.
http://www.thinkoutside.com/products/el ... oduct.html
What's the best way to add this to this driver? I don't want to duplicate code, and the protocol is well documented on the thinkoutside website - http://www.thinkoutside.com/developer/developer.html
in this ZIP:
http://www.thinkoutside.com/developer/devkit20.zip
NB, I also have a 5-row visor keyboard that uses the keymap documented in:
http://www.thinkoutside.com/developer/DK110.zip
I'd like to add a driver for this too, but does it belong in this or just in PiKey?
http://www.thinkoutside.com/products/el ... oduct.html
What's the best way to add this to this driver? I don't want to duplicate code, and the protocol is well documented on the thinkoutside website - http://www.thinkoutside.com/developer/developer.html
in this ZIP:
http://www.thinkoutside.com/developer/devkit20.zip
NB, I also have a 5-row visor keyboard that uses the keymap documented in:
http://www.thinkoutside.com/developer/DK110.zip
I'd like to add a driver for this too, but does it belong in this or just in PiKey?
Last edited by futaris on Fri Mar 23, 2007 7:13 pm, edited 1 time in total.
I did a quick hack of tydopad to confirm keymaps. It's definitely right, but we may need to handle more Shift/Fn-keys, somehow. This keyboard has a Blue Fn key, a Green Fn-Key and the standard shift key. This is mainly because it has no number row. Look inside the above mentioned devkit20.zip to see what I mean.
http://files.futaris.org/psp/tydopad/
I'll do up a keymap for pspirkeyb once we figure out how to integrate it "nicely", especially for the extra Fn-modes, to handle the number row, etc.
Otherwise, does anyone have any objections to me "fixing" the current code for the Palm UW keyboard driver?
http://files.futaris.org/psp/tydopad/
I'll do up a keymap for pspirkeyb once we figure out how to integrate it "nicely", especially for the extra Fn-modes, to handle the number row, etc.
Otherwise, does anyone have any objections to me "fixing" the current code for the Palm UW keyboard driver?
futaris i successfully build a driver for my keyboard thx to monsti s help ,
and to make the numbers work u just have to have the code for the fn funktion in the keymap ,everyting else should be done in the ini files of pspirkeyb , and if it works with pspirkeyb , it s likely gonna work with pikey but u d need to recompile it urself , all u habe to do is to read the README.ADDING.KEYBOARDS in libpspirkeyb , or pm me maybe i can help
and to make the numbers work u just have to have the code for the fn funktion in the keymap ,everyting else should be done in the ini files of pspirkeyb , and if it works with pspirkeyb , it s likely gonna work with pikey but u d need to recompile it urself , all u habe to do is to read the README.ADDING.KEYBOARDS in libpspirkeyb , or pm me maybe i can help
I have no problem adding the keyboard driver. It's the Fn code stuff. Most keyboards are 5-row, with a number row. Most don't have F1-F12. These are done with Fn-Keys.
My Keyboard is 4-rows. It doesn't have a number row. If you want the symbol &, you must push Shift+Fn+U. Also there is a num-lock key, etc. My Logitech keyboard has a F mode key for the Function keys.
I can see the need for multiple Fn keymaps. But is this a keyboard-specific thing or something that should be written for all of them?
Also, what about extended keycodes, eg ZOOM_IN / ZOOM_OUT, NEXT SONG, PREV SONG, VOL UP, VOL DOWN, etc, etc. Some keyboards have these. Just look at any Linux keyboard driver.
My Keyboard is 4-rows. It doesn't have a number row. If you want the symbol &, you must push Shift+Fn+U. Also there is a num-lock key, etc. My Logitech keyboard has a F mode key for the Function keys.
I can see the need for multiple Fn keymaps. But is this a keyboard-specific thing or something that should be written for all of them?
Also, what about extended keycodes, eg ZOOM_IN / ZOOM_OUT, NEXT SONG, PREV SONG, VOL UP, VOL DOWN, etc, etc. Some keyboards have these. Just look at any Linux keyboard driver.
Assuming your driver fits naturally in libpspirkeyb, I'd recommend putting it there, and then more people can benefit from it - since piKey just picks up the pspirkeyb lib and so can make use of any changes people add to the lib.futaris wrote: I'd like to add a driver for this too, but does it belong in this or just in PiKey?
Got a v2.0-v2.80 firmware PSP? Download the eLoader here to run homebrew on it!
The PSP Homebrew Database needs you!
The PSP Homebrew Database needs you!
Ok. I didn't mention this before, but the Visor Stowaway Keyboard is a RS232 keyboard that runs at LVTTL levels. i.e. you can wire it directly up to the headphone serial port cable, without any extra circuitry. Runs at 9600bps, and I think the 3.3V power pin on the headphone connector supplies enough current. I guess no-one has put a "plain" serial (non IR) keyboard into libpspirkeyb yet?Fanjita wrote: Assuming your driver fits naturally in libpspirkeyb, I'd recommend putting it there, and then more people can benefit from it - since piKey just picks up the pspirkeyb lib and so can make use of any changes people add to the lib.
These are still around on eBay for US$5-$10 generally. Only three wires needed TX, GND and PWR.
In that case I would suggest talking to monsti about the direction he feels his lib should be developing towards, but I would guess that a serial keyboard isn't a natural fit.
It certainly sounds like something we'd like a driver for in piKey, one way or the other.
It certainly sounds like something we'd like a driver for in piKey, one way or the other.
Got a v2.0-v2.80 firmware PSP? Download the eLoader here to run homebrew on it!
The PSP Homebrew Database needs you!
The PSP Homebrew Database needs you!
-
- Posts: 4
- Joined: Tue Apr 03, 2007 4:03 pm
Hi there, i am doing the driver for the Citipack IR-503, an IR keyboard (the only one I could found here in china).
It seems to work but I have some questions :
- in kbdkeyboards.h is IPAQ_BUTTON_CONTACTS redundant with KEY_UNKNOWN of pspirkeyb_rawkeys.h ? (the same for IPAQ_BUTTON_ITASK/KEY_INTL3)
- does these 4 defines souldn't be in pspirkeyb_rawkeys.h ?
- how can i give you my update (when i will finish debugging it;) ) ?
It seems to work but I have some questions :
- in kbdkeyboards.h is IPAQ_BUTTON_CONTACTS redundant with KEY_UNKNOWN of pspirkeyb_rawkeys.h ? (the same for IPAQ_BUTTON_ITASK/KEY_INTL3)
- does these 4 defines souldn't be in pspirkeyb_rawkeys.h ?
- how can i give you my update (when i will finish debugging it;) ) ?
-
- Posts: 4
- Joined: Tue Apr 03, 2007 4:03 pm
Hi, again me ;)
debugging my driver, I found a bug in keymap.c for capslock only alphas :
should be replaced by :
because KEY_A to KEY_Z are not continu (cf pspirkeyb_rawkeys.h)
debugging my driver, I found a bug in keymap.c for capslock only alphas :
Code: Select all
if ((raw >= KEY_A) && (raw <= KEY_Z))
Code: Select all
if (((raw >= KEY_Q) && (raw <= KEY_P)) || ((raw >= KEY_A) && (raw <= KEY_L)) || ((raw >= KEY_Z) && (raw <= KEY_M)))
Well spotted, I just committed your capslock fix to SVN.
Happy to commit any other fixes for you if you need it.
Happy to commit any other fixes for you if you need it.
Got a v2.0-v2.80 firmware PSP? Download the eLoader here to run homebrew on it!
The PSP Homebrew Database needs you!
The PSP Homebrew Database needs you!
-
- Posts: 4
- Joined: Tue Apr 03, 2007 4:03 pm
great, happy to help ;)
and for this questions ?
and for this questions ?
PS : I have finish my debug, so i can send to you my update ;)Moquette31 wrote:Hi there, i am doing the driver for the Citipack IR-503, an IR keyboard (the only one I could found here in china).
It seems to work but I have some questions :
- in kbdkeyboards.h is IPAQ_BUTTON_CONTACTS redundant with KEY_UNKNOWN of pspirkeyb_rawkeys.h ? (the same for IPAQ_BUTTON_ITASK/KEY_INTL3)
- does these 4 defines souldn't be in pspirkeyb_rawkeys.h ?
- how can i give you my update (when i will finish debugging it;) ) ?
Okay... a few things I noticed while working on pspirkeyb.prx...
pspIrKeybReadinputPrx() is supposedly non-blocking, but on some keyboards, it is blocking. For example, on the Palm keyboard, the moment you call pspIrKeybReadinputPrx(), it blocks until you press a key. The palm function in pspirkeyb.c should look like this instead:
As far as getting the prx test working, I changed the main.c like this:
The prx test then works (on 3.40 OE-A at least), and the Palm is unblocking.
I also made a few changes to the Palm raw codes, and made an ini for it. I'm not sure who to send it to. Who's maintaining this code? Some of the other keyboards need to be changed to be more like the Palm code above or they'll continue to block as well.
pspIrKeybReadinputPrx() is supposedly non-blocking, but on some keyboards, it is blocking. For example, on the Palm keyboard, the moment you call pspIrKeybReadinputPrx(), it blocks until you press a key. The palm function in pspirkeyb.c should look like this instead:
Code: Select all
static int palmuw(unsigned char* buffer, int *length)
{
unsigned char keycode=0;
unsigned int key_down=0;
unsigned char buf1;
int len;
static int pi = 0;
static unsigned char pbuf[6] = {0,0,0,0,0,0};
loop:
len = sceIoRead(g_irdafd, &buf1, 1);
if (len <= 0)
return -1;
// must be 1... can't be anything else at this point
if (pi == 0)
{
// wait on 0xff
if (buf1 == 0xff)
{
pbuf[0] = 0xff;
pi++;
}
goto loop;
}
pbuf[pi] = buf1;
pi++;
if (pi < 6)
goto loop;
pi = 0;
/* resume display */
scePowerTick(0);
//printf( "0%c - %d\n", buf[0], buf[0] );
//printf( "1%c - %d\n", buf[1], buf[1] );
//printf( "5%c - %d\n", buf[5], buf[5] );
if( pbuf[0] != 0xff || pbuf[1] != 0xc0 || pbuf[5] != 0xc1 )
return -1;
//printf( "2%c - %d\n", buf[2], buf[2] );
//printf( "3%c - %d\n", buf[3], buf[3] );
if( ( pbuf[2] + pbuf[3] ) != 0xff )
return -1;
/* 3rd pos is the key we need */
keycode = pbuf[2];
if( keycode < 128 )
key_down = 1;
else
keycode -= 128;
if ( key_down ) {
//if (debug)
//fprintf(stdout,"press %d\n", keycode);
keymap_decode( g_outputmode, palmuw_normal[keycode], KEY_PRESSED, buffer, length );
} else {
//if (debug)
//fprintf(stderr,"release %d\n", keycode);
keymap_decode( g_outputmode, palmuw_normal[keycode], KEY_RELEASED, buffer, length );
}
return 0;
}
Code: Select all
/*
asciidemoprx: PSP IR Keyboard Library ascii demo application
(http://pspirkeyb.podzone.net)
This is the same as the ascii demo but the driver get's loaded as PRX
Copyright (C) 2007 Harald Fielker <[email protected]>
This program can be distributed under the terms of the GNU LGPL.
See the file LICENSE.
*/
#include <pspsdk.h>
#include <pspkernel.h>
#include <pspctrl.h>
#include <pspdebug.h>
#include <psppower.h>
#include <stdio.h>
#include <string.h>
#include <pspirkeybprx.h>
#include <pspirkeyb_rawkeys.h>
#define printf pspDebugScreenPrintf
const char * g_prx_module = "ms0:/seplugins/irkeyb.prx";
/* Define the module info section */
PSP_MODULE_INFO("asciidemo", PSP_MODULE_USER, 1, 1);
/* Define the main thread's attribute value (optional) */
PSP_MAIN_THREAD_ATTR(THREAD_ATTR_USER);
/* Exit callback */
int exit_callback(int arg1, int arg2, void *common)
{
sceKernelExitGame();
return 0;
}
/* Callback thread */
int CallbackThread(SceSize args, void *argp)
{
int cbid;
cbid = sceKernelCreateCallback("Exit Callback", exit_callback, NULL);
sceKernelRegisterExitCallback(cbid);
sceKernelSleepThreadCB();
return 0;
}
/* Sets up the callback thread and returns its thread id */
int SetupCallbacks(void)
{
int thid = 0;
thid = sceKernelCreateThread("update_thread", CallbackThread, 0x11, 0xFA0, THREAD_ATTR_USER, 0);
if(thid >= 0)
{
sceKernelStartThread(thid, 0, 0);
}
return thid;
}
int main(int argc, char *argv[])
{
SceCtrlData pad;
u32 buttonsold = 0;
int kernelmode = 0; /* only 0 works for now - some keyboards need baud change */
const char *config_file = NULL; /* this will force ms0:/seplugins/pspirkeyb.ini */
SetupCallbacks();
pspDebugScreenInit();
printf("PSP Irda Keyboard test - ASCii input (PRX) \n");
sceCtrlSetSamplingCycle(0);
sceCtrlSetSamplingMode(PSP_CTRL_MODE_DIGITAL);
/* Start irkeyb.prx */
SceUID mod = pspSdkLoadStartModule(g_prx_module, kernelmode ? \
PSP_MEMORY_PARTITION_KERNEL : PSP_MEMORY_PARTITION_USER);
if(mod < 0)
{
printf( "loading of module %s failed\n", g_prx_module );
goto endprg;
}
if(pspIrKeybInitPrx( config_file, kernelmode ) != 0)
{
printf( "error: can't inialize the keyboard\n" );
printf( " check keyboard type/map in ms0:/seplugins/pspirkeyb.ini\n" );
}
else
{
unsigned char termchar = 'X';
unsigned char buffer[255];
int i, length=0;
printf("\npress %c on keyboard or any PSP button to exit\n", termchar );
/* setup output method to ASCii */
pspIrKeybOutputModePrx( PSP_IRKBD_OUTPUT_MODE_ASCII );
while(1) {
length = 0;
/* non blocking read */
if( pspIrKeybReadinputPrx(buffer, &length) >= 0 )
{
for( i=0; i < length; i++ )
printf( "%c", buffer[i] );
if( length == 1 && buffer[0] == termchar )
break;
}
else
{
sceKernelDelayThread(5*1000);
sceCtrlReadBufferPositive(&pad, 1);
if (pad.Buttons != buttonsold)
break;
}
}
/* bye keyboard */
pspIrKeybFinishPrx();
}
endprg:
printf( "\n bye... (PRESS psp button to quit)\n" );
buttonsold = 0;
while (1) {
sceCtrlReadBufferPositive(&pad, 1);
if (pad.Buttons != buttonsold) {
/* Exit */
sceKernelExitGame();
}
sceKernelDelayThread(50*1000);
}
return 0;
}
I also made a few changes to the Palm raw codes, and made an ini for it. I'm not sure who to send it to. Who's maintaining this code? Some of the other keyboards need to be changed to be more like the Palm code above or they'll continue to block as well.
You can send changes to me if you like, although Monsti is the official owner.
I think Monsti had more or less abandoned the PRX flavour, and my interest is much more in using piKey as a more generic library, than using the lib as a PRX, but I'm happy to help you keep it updated if you want to work with the PRX.
I think Monsti had more or less abandoned the PRX flavour, and my interest is much more in using piKey as a more generic library, than using the lib as a PRX, but I'm happy to help you keep it updated if you want to work with the PRX.
Got a v2.0-v2.80 firmware PSP? Download the eLoader here to run homebrew on it!
The PSP Homebrew Database needs you!
The PSP Homebrew Database needs you!
Sounds like a plan. Should I try to "unblock" some of the other keyboard drivers first? I just did the Palm one because that's what I have.Fanjita wrote:You can send changes to me if you like, although Monsti is the official owner.
I think Monsti had more or less abandoned the PRX flavour, and my interest is much more in using piKey as a more generic library, than using the lib as a PRX, but I'm happy to help you keep it updated if you want to work with the PRX.
The PRX seems to be handy for times when you just need keyboard input that is independent of the build and doesn't require flashing. Just drop it and a couple ini files into seplugins and you're set. I'll probably use the PRX for keyboard support on some of the projects on my todo list.
EDIT: I noticed over at MaxConsole a couple reports that pikey doesn't work on 3.40 OE-A. I suppose you're looking into that...
I suspect the others are OK, your fix to the palm is the same I think as one that went into the non-PRX code - I hadn't expected it to be needed in both places, haven't really looked at the PRX code myself since it was supposed to be a bit broken already.J.F. wrote:Sounds like a plan. Should I try to "unblock" some of the other keyboard drivers first? I just did the Palm one because that's what I have.
The piKey lib works that way too, and (at the risk of self-promotion) I'd recommend it because it also gives you free support for e.g. SIO terminal input, etc. Check out the sample code in the piKey package for how to use it, it will autoload the PRX if it isn't already running.The PRX seems to be handy for times when you just need keyboard input that is independent of the build and doesn't require flashing. Just drop it and a couple ini files into seplugins and you're set. I'll probably use the PRX for keyboard support on some of the projects on my todo list.
Not actively, I have no time at the moment sadly, but it is top of the to-do list.EDIT: I noticed over at MaxConsole a couple reports that pikey doesn't work on 3.40 OE-A. I suppose you're looking into that...
Got a v2.0-v2.80 firmware PSP? Download the eLoader here to run homebrew on it!
The PSP Homebrew Database needs you!
The PSP Homebrew Database needs you!
The fix was in the main lib, not the prx code. When you called the function to read the keyboard buffer, it's supposed to exit if there's no keys, but the Palm driver (and hama driver) instead sit in a loop waiting for all the bytes of a key packet to come in before exiting, even if a packet hasn't started yet. Once you enter the function, you don't leave until a key comes.Fanjita wrote:I suspect the others are OK, your fix to the palm is the same I think as one that went into the non-PRX code - I hadn't expected it to be needed in both places, haven't really looked at the PRX code myself since it was supposed to be a bit broken already.J.F. wrote:Sounds like a plan. Should I try to "unblock" some of the other keyboard drivers first? I just did the Palm one because that's what I have.
Look at the first code in both (in libpspirkeyb/pspirkeyb.c):
Code: Select all
while (i < 6 || z < 6) {
...
while (i < 5 || z < 5)
{
Code: Select all
if( sceIoRead(g_irdafd, buf, 2) != 2 )
return (-1);
Does pikey work from the memstick alone? You don't have to flash it? That isn't clear in the docs. I guess I'll compile it with my code and copy it over and try it. If that's the case, I'll stick to pikey for my homebrew keyboard usage. :)The piKey lib works that way too, and (at the risk of self-promotion) I'd recommend it because it also gives you free support for e.g. SIO terminal input, etc. Check out the sample code in the piKey package for how to use it, it will autoload the PRX if it isn't already running.The PRX seems to be handy for times when you just need keyboard input that is independent of the build and doesn't require flashing. Just drop it and a couple ini files into seplugins and you're set. I'll probably use the PRX for keyboard support on some of the projects on my todo list.
Okay. Just wanted to be sure you knew of the reports. Since I have 3.40 OE on my PSP, it's made me a bit leary of flashing pikey. If I spot anything that might be related while going through the code, I'll let you know.Not actively, I have no time at the moment sadly, but it is top of the to-do list.EDIT: I noticed over at MaxConsole a couple reports that pikey doesn't work on 3.40 OE-A. I suppose you're looking into that...