Pandora Libpnd Api - Read Nubs/dpads, Etc

[skeezix]

libpnd is really a few parts, some parts of which most people will never concern themselves with. Other parts I think every dev for Pandora should be aware of

Aside: Let me know if theres anything you'd like in there, and if its something I can squeeze in I'll see what I can do. Otherwise, you can add it yourself I'm really hoping people will keep going with the 'this is really great bit, lets add it to libpnd so no one else has to reinvent the wheel' .. I'm hoping we won't have too many similar-but-different approaches to the same things, as that just increases the surface area for issues. Anyway..

Anyway, I've added a really basic simple way to read the nubs and d-pads, and thought I'd post it here so you know where to look for your upcoming projects; theres a couple input methods in there, but I'm referring to one I just called 'pnd evdev'.

I expect most people will use SDL for IO, and that will mostly 'just work'...

- SDL audio, works fine
- SDL keyboard will pick up d-pads (SDLK_LEFT for left on the d-pad, for instance.)
- SDL surfaces work for rendering, and it'll center if fulscreen and a funny sized window (funny compared to our 800x480 I mean

Maybe I didn't enable something in SDL in my ports, but the nubs don't show up in SDL by default, but it is absolutely trival to pick up with the libpnd stuff.

You can pick up pretty much everything with SDL. If you're not using SDL, you can pick it all up through other means, and sample code and APIs are in libpnd to do it all for you, or show you the way.

I'll have some SDL answers below, and fill in the gaps; for pure non-SDL, its just easy.

Q: When someone hits a key on the pandora..

A: You get a SDL key event, generally. dpads, bpadbuttons, shoulders, start/select/pandora buttons too.

Q: If I want to have d-pad events sent as joystick events, can I?

A: The kernel will default to sending keyb events for those buttons; there is a device-gloval setting to switch it to send joystick events for dpad buttons. (Likewise, you can switch the nubs to be a mouse, too.)
NOTE: This _shoudl not_ really be used. Its a multitasking device, and if the user fires up 5 apps in a row that all screw with global settings, its just going tyo break everything. We've wrestled over it, but it is best to just not touch the settings and leave the default.

Q: If you want to use pnd_io_evdev.[ch] libs from libpnd, it is absoltuely trivial:

pnd_evdev_open ( pnd_evdev_dpads ) -> returns 0 on fail, 1 on success
pnd_evdev_catchup ( 0 /* no block */ ) -> lib catches up on events; call this before testing values. You can have it block (Wait for inputs) if you want.
pnd_evdev_get_dpad_state, and pnd_evdev_Get_nub_state() -> return the buttons that are down, or the x/y for the nubs.

Thats it, easy as pie. 'evdevtest' sample program included in libpnd.

Its really as easy as "int state = get state; if state & pnd_evdev_left -> move guy left". I added nub control as ST mouse to hatari in 5 lines of code. Seriously.

Q: If my SDL app gets keyboard events, but I don't want to it to handle d-pads soI can have them movie Mario around..

A: Then you can 1) ignore SDLK_LEFT/etc, perhaps using a if ( dpad_is_joystick ) mode of your own, or 2) switch device global mode (bad idea), or 3) comment out or don't use SDLK processing for those events, just use libpnd as above since its so easy.

Note; we used to have the kernel return joystick+keyb events for a single dpad hit, but that caused problems for apps that read both joystick and keyboard; since d-pad as keyboard is so utterly damned useful for keyboard (ie: d-pad to move cursor arounjd in abiword, to move selection around on the xfce desktop, and the various butotns as control and shift and such), thats the default. If you want to get dpad as something else, libpnd makes it very easy to do. And if you really want SDL_joystick type code ot just work, you can switch the mode of the device for your app.. but I would seriously think you shoudl ask the user first before breaking some of his keyboard

Consider..

pnd_nubstate_t ns;
pnd_evdev_get_nub_state ( pnd_evdev_nub1, &ns )
--> now you have ns.x and ns.y (-256 <-> +256 values for those)

We've made your life easy

jeff

Once we get right to release day, maybe I'll spend a few hours filling out wiki docs for some of the general purpose APIs (ie: the pnd magic stuff most will never look at, but I imagine cpu clock setting people will all want to see; or folks will roll their own, but thats sillyness

 

[dflemstr]

(Rhetorical question that exists to highlight an issue
Can I make my game depend on libpnd and then compile it for the x86 platform, and expect it to still "work"? Aka, if I use my application on x86, will it segfault if it still links libpnd, or will libpnd perform the necessary checks at runtime to see if the evdev files are present (and just spit out zeros)? Or do I have to do the usual #ifndef stuff all over my code?

 

[skeezix]

libpnd will build out of the box on other linux platforms; the pandora specific stuff will just not work sometimes, but will not crash. libpnd doesn't exploit any pandora-specific hardware, it uses standard linuxy wayfs of doing things.

ie: /dev/input/eventX is used for this stuff, as botaz has the kernel talking to that system.

Same for opejning the PC keyboard on a desktop linux box (I did my testing that way), its just that as libpnd assumes Left Trigger is Right Control (or whatever), it'll build fine on deskotp linux, just you'd have to hit Right Control to affect a left-trigger to libpnd.

the pnd-magic works fine on a few Unixes I tried (when properly configured in searchpaths, mountpoints, etc) .. so no worries.

But as I say, most people will just use SDL (I'm guessing), meaning you needn't worry; handle SDLK_LEFT and you're good on PC or Pandora; you want to use nubs though, use the libpnd stuff above, and it'll work fine, and be ignored on other machines.

(why? Because when libpnd goes reading /dev/input/event[0-...] to find the right event handler, it goes by returned device name. It looks for vsense66 and vsense67 for nub1/nub2, and its pretty certain your desktop does not have that event handler; so when you open nub1, it'll fail from libpnd. If it succeeds, it'll try to deal with the returns from that handler, and shoudl be fine (if weird results.)

pnd_device.h has constants for a bunch of pandora-specific device names and whatnot, and includes APIs for setting the clock etc; they'll all just fail on non-pandora, but will not crash. (ie: setting the cpu clock, you can just read/write to a /proc device, or ust the libpnd API to isolate you from being that device speciifc should it ever change name in the filesystem. But its nothign new, same old read(2)/write(2) as every linux.)

jeff

 

[Pickle]

skeezix: the nubs are accessible through SDL, they are detected as individual joysticks. So the dpad,abxy,rl are joystick 0 and the nubs are 1 and 2.

 

[skeezix]

Ah, I didn't enable joy 1 and 2, doh!

Still, non-SDL folks need the code so I whipped it up Wanted to see if anyone would post 'we need this' back really.

ie: I don't really want to put in /dev/fb handler in libpnd, since its such a comprehsnsive topic .. simple code should use SDK, but if people want to go right to /dev/fb they can use the ioctl's in /usr/include/linux/fb.h .. or do I need to make some handy routines like 'go fullscreen' and 'what is colour depth and format' and all that? *hmmrf*

jeff