Pandora+Pyra applications: /usr/share/pandyra


Staff member
Apr 5, 2012
Brussels, Belgium
It would be useful to have a "compatibility" directory in both the Pandora and Pyra firmware that can be used to make software that works well on both devices. Let's say the directory is called /usr/share/pandyra (the name of the directory is not important, make it /opt/dragonbox if that sounds better).

It could be used as an abstraction layer to abstract away the differences between the devices.

E.g. say the Pyra has action buttons labeled Δ Π Ω X and the Pandora has action buttons labeled Y A B X. From the point of view of a developer, they're just PgUp Home End PgDn, so the labeling does not really matter. But he may want to show the button mapping in a help screen or something. In /usr/share/pandyra there could be guihint images, e.g. /usr/share/pandyra/guihints/action_north.png could be an image of the Y button on a Pandora, and an image of the Δ button on the Pyra. That way, if you load the guihint images from that standard location, they "magically" become the right image. (Independently of what button labeling the Pyra will have, I think it's a good idea to have shared guihint image files in a standard location, even if they're the same for Pandora and Pyra).

We could use a similar idea to allow applications to use 4 shoulder buttons and 6 action buttons on the Pyra, while mapping the missing buttons to O P 1 backspace or something like that on the Pandora (and you could change the mapping easily and globally by tweaking some files).

Setting the CPU speed could be done by calling /usr/share/pandyra/ with as a parameter the number of classic Pandora MHz of performance the application needs. The script would check if the current cpu clockspeed is fast enough, automatically sets it higher if it's in range of what you allow to automatically change, or gives a warning and allows you to try anyway if the application wants to go higher. E.g. if you do set_cpu_speed 800 it may overclock a CC Pandora unit and do nothing on other devices, if you do set_cpu_speed 1000 it gives a warning on a CC/ReBirth unit but lets you try anyway at the max you can do (e.g. 900MHz), if you do set_cpu_speed 1400 it will overclock a 1GHz unit to the max you let it go to but may still do nothing on the Pyra. The formulation of the warning could depend on how much difference there is between the max you allow and the requested speed; e.g. if you try running a very demanding Pyra application that asks for 3000 "MHz" of performance (remember, these are Pandora-equivalent bogoMHz of performance, so 3000 "MHz" may correspond to only 1000MHz actual clock speed on the Pyra's A15) on a CC Pandora, the warning may say "This will not work. Do you really want to see this slideshow?". Anyway, you get the point, and by using a shared script, we can make it relatively intelligent.

And so on. There may be more things to put in /usr/share/pandyra. The point is: we should avoid having individual applications that try to do smart stuff so they work well on both Pandora and Pyra, the differences should be abstracted away somehow. Most of this abstraction will of course already happen with the standard libraries (like SDL etc), but there will be things that have to be made explicit and standardized, like the examples I gave above, and that require minor additions to the Pandora firmware. We can already start with that now and update our applications to become "Pyra-ready".
Thank you Silent-Hunter! I missed _wb_'s  idea first time round.

The width and breadth of Pandora software is unmatched by any device I know of. I can only assume that most people just now are working on Pandora specific titles.

Porting this valuable resource to the Pyra as easily as possible has to be a positive step.
Last edited by a moderator:
As a porter, I think it would be simpler to just make a different version of the program for the Pyra.
You're ignoring armhf vs softfp issues, due to this the programs will likely have different roots.

And why invent crazy names like pandyra, we could keep both /pandora and /pyra and have them both do sensible things..
Last edited by a moderator:
And why invent crazy names like pandyra, we could keep both /pandora and /pyra and have them both do sensible things..
Or, /pra, rhymes with She-Ra.

Sorry for more of my inane posts...

More seriously though, I keep reading stuff that is over my head, but if I understand correctly many/most/all Pandora software will not work on the Pyra.  Is this correct?  I can wait for things like games.  Some stuff is a bit more vital to me, though.  As an example, I use A and B for mouse buttons, so it would be nice to be able to do that with Pyra.  There are many other Pandora specific examples.  Will these be unusable as they are with the Pyra?  I am guessing things like LibreOffice and dependencies will be available through Debian repos.
I agree with both sides. There should be some standard resources in a standard location, but I think it would be absolutely critical to have a standard path to a board identification file. This way we have a standardized way to differ between Pandoras and Pyras.
I'd have thought that would be a given. The OS version file at the very least will enable you to tell the difference between Pandora OSes and Pyra ones.

Perhaps we want a way that doesn't depend on the OS though. Other linux flavours like Debian are able to run much of the same PNDs, but a file denoting the installed version of Angstrom doesn't make sense there. Perhaps we ought to include an API that can distinguish between CC, rebirth and 1Ghz units, and when the time comes, Pyras too, perhaps using much the same algorithm as the system info tool or model check does.

As for the icons, having pyra and pandora folders won't help if you want a standard location to find common icons, unless there's some envvar that points at them. I'd propose /usr/share/icons for the icons, as that's the FHS location from a quick internet search (so something like /usr/share/icons/dragonbox, or .../pandyra if you like). Other cross platform metadata and tools can go in their respective folders, and differ between distributions.

I don't consider that an important consideration, as may ports these days contain tutorials that tell me to press WASD or enter to fire and so on, and it's only a moment's work to guess what the real controls are. I'd personally like something that indicates which button is the main fire button, as when swapping between Hase (which uses A to fire) to DraStic (which uses B to fire) I often find myself accidentally going up a level from the folder where my DS games are, and having to navigate back is a bit of a faff (but then again, perhaps even that idea needs more consideration, as if I set my main fire button to A, it would still make sense for the DraStic menu to use DS layout in its menus).

I do think this sort of polishing work is a good thing we could improve though, as long as we have the right people working on it. It shouldn't detract from the more technical work needed just to make as many Pandora apps as possible run on the Pyra, but if it can be done by the right people with the right skills while making sure it's all coordinated so we don't end up with a profligacy of icons and tools, while keeping any coordination lightweight and open, that would be ideal.
Last edited by a moderator:
I was thinking more along the lines of having the file /etc/board containing the name of the device. Valid contents would be "pandora", "pandora 1ghz", " pandora rebirth" and "pyra". All lowercase and in the format "board [variant]". The file is terminated with a newline.

This way it's easy to distinguish them at the relevant level. For instance, an overclocking tool will want to know exactly what CPU is in there while a game just wants to know the button layout. Some applications might just want to know if they're running on a handheld at all.