The software side

[vinipsmaker]

This could be solved by having the input API have target actions that can be mapped to the physical buttons and remapping program.

Thus developers would say if(contols->isAccept(PRESSED)) do action

This would use which ever button the user has mapped the accept button to... (with sensible defaults)

http://wiki.libsdl.org/CategoryGameController ?

 

[notaz]

Problem is, I don't really see a coordinated effort to avoid those issues on a successor.

And I don't think there is going to be any, unless someone steps up and does it.


As bad as it is, we could barely pull off stuff for current pandora at all at release, and that was with the release being late over a year. At the time first units shipped, DjWillis was the only one who could build the system images, had he disappeared back then, we would have nothing to ship. IIRC PND/PXML stuff was proposed by someone on the forums, skeezix implemented it and vimacs wrote the scripts. So it all was a hackjob done by people with no time, but it works, sort of. It doesn't look like things are going to change for Pyra.

The problem is that there are very few OS/firmware developers already for the existing Pandora. So you can't expect new ones to magically appear out of nowhere.

 
Yes, hence the "Attracting as many people as possible" bit.


Not to mention trying to keep them involved.. a lot of the people who did stuff for the pandora firmware in the beginning have never done anything for it after that.

And how we can make it different this time around? 

Dumping some old firmware in a chroot is the worst option possible.

Do you have any alternatives? This is the only way I see to get it actually working.

This could be solved by having the input API have target actions that can be mapped to the physical buttons and remapping program.


Thus developers would say if(contols->isAccept(PRESSED)) do action


This would use which ever button the user has mapped the accept button to... (with sensible defaults)

This was discussed a lot before. The problem is we can't force anyone to use the API (did you know libpnd always had it's input API that nobody ever used?), this is an open device dominated by ports, people will just use whatever the ported program used.

 

[vinipsmaker]

Hey, let's create a wiki page to collect all ideas being proposed and notes about what the format should have (ubson, for example).

The next step should be github projects/libraries/scripts to implement small parts and then big projects to use the small parts.

We can have scheduled meetings on IRC also (but I prefer here).

 

[pmprog]

The problem is that there are very few OS/firmware developers already for the existing Pandora. So you can't expect new ones to magically appear out of nowhere.

 Yes, hence the "Attracting as many people as possible" bit.

Not to mention trying to keep them involved.. a lot of the people who did stuff for the pandora firmware in the beginning have never done anything for it after that.

And how we can make it different this time around?

Personally, I would like to get involved. It would hopefully help me better understand the Linux system, and hey, I might actually release a PND that works Although I am struggling with time at the minute
As for attracting people, as annoying as it might sound, having a nice VM set up with all the build tools to compile the firmware and software for the platform would be great.

 

[TrashyMG]

I could help out in testing and bug reporting. while I do have coding experience, I don't think I have the time to contribute in any meaningful way to the actual development of the OS.. I'm way too busy between working full time and classes I'm taking. However I'm actually considering buying the omap5432 EVM development board myself.

 

[aTc]

And I don't think there is going to be any, unless someone steps up and does it.

As bad as it is, we could barely pull off stuff for current pandora at all at release, and that was with the release being late over a year.

At the time first units shipped, DjWillis was the only one who could build the system images, had he disappeared back then, we would have nothing to ship.

IIRC PND/PXML stuff was proposed by someone on the forums, skeezix implemented it and vimacs wrote the scripts. So it all was a hackjob done by people with no time, but it works, sort of. It doesn't look like things are going to change for Pyra.

Well this thread is a start, and there are already people offering their help and ideas. Of course there's a big difference between doing a bit of complaining on a forum, and actually doing stuff, but we should be able to come up with a few more people.

Just because things didn't that smoothly on pandora doesn't mean you might as well not bother with it this time.

You really want some sort of project manager to coordinate things. Waiting for people to randomly pop up with various bits of firmware isn't the way to do it.

And how we can make it different this time around?

By making everything open, documented, and easy to use.

Having a firmware that can only really be built by one person (or required a huge amount of effort to get going anywhere else) isn't something you want.

That's why it's important to base things on existing, stable automated build systems, following standards.

Learn from the things that went "wrong" on the pandora.

Make it easy to see what's going on, and easy to join in, with an easy to set up dev environment.

And you most certainly don't want "helpfull" people rushing off writing things before the basic elements are decided on.

And not sending devboards to people who ported an emulator, and expecting them to write OS software for you

Dumping some old firmware in a chroot is the worst option possible.

Do you have any alternatives? This is the only way I see to get it actually working.

Well if old libs and/or a chroot is required, at least everything should be able to be built from source automatically, not just appear from some magical tar.bz2

I myself don't see .pnd backward compatibility as a hugely important feature.

Having a large existing repo of software may look like a nice feature, but most of the pnds in there are either things that are part of any sensible distro already, or things that can be easily recompiled/packaged.

Also, don't underestimate the amount of hacks that go on inside the pnd and its startup scripts for some of these things. Hardware gets poked directly (nubs mode, overclocking, scaling), env vars are redirected all over the place, libs inside the pnd are forced ( i think a few include libc, which even caused cp calls inside the startup script to segfault on .next, and libgles that were in the firmware already ), files are copied to all sorts of places, etc.

And there's the soft/hardfp fun Cloudef mentioned.

In fact, I see any effort on .pnd backwards compatibility as a huge waste of time.

If anything it should be a side project for some sort of ginge like app, nothing more.

This was discussed a lot before. The problem is we can't force anyone to use the API (did you know libpnd always had it's input API that nobody ever used?), this is an open device dominated by ports, people will just use whatever the ported program used.

It can at least be done slightly more sensible this time, and have the gamepad bits show up as a single gamepad.

A lot of programs have support for gamepads, but you couldn't use that on pandora because they don't expect gamepads to show up as something spread over two devices and half the keyboard.

Since a lot more stuff will come straight from .deb , forcing an pyra specific api isn't going to work for those, and neither is having it as a software option inside a pnd like thing.

So what I think is needed here is a way to switch the game controls into either gamepad or keyboard mode, probably by using some dedicated keyboard button, or hardware switch, maybe backed up by a led.

 

[second exodous]

I really liked .pnds on the Pandora since it worked really well with the removable sd cards. I'd like to see this stay if there isn't a large amount of fixed storage. If trying to keep the OS stock as possible how will it handle things installed through it's repository onto a SD card and then have it removed? I really really like the idea of Debian and repositories filled with .deb packages at my finger tips but what happens when I remove the SD I'm installing all my progams through .deb?

 

[God Ginrai]

PNDs are great for us users. However, like aTc and Cloudef have pointed out, we need to improve the system so that it's good both for users and for the OS and developers.

-God Ginrai

 

[notaz]

And how we can make it different this time around?

By making everything open, documented, and easy to use.

This looks good "on paper" but that increases the overall effort needed multiple times, and having way less than 1 person (in terms of manhours/week vs someone working fulltime) this is going to be extremely difficult to pull off without risking to have nothing at all ready on release.

I myself don't see .pnd backward compatibility as a hugely important feature.

You might not but ED does, it was one of main reasons for not going Intel's way from what I can tell.

It can at least be done slightly more sensible this time, and have the gamepad bits show up as a single gamepad.

But this is not how the hardware is connected (bunch of unrelated devices on different buses) and such driver has no chance to be ever mainlined. Nobody likes to sit on old kernels just because there's nobody to do the porting work. Unless we can do it in userspace this is not going to happen.

So what I think is needed here is a way to switch the game controls into either gamepad or keyboard mode, probably by using some dedicated keyboard button, or hardware switch, maybe backed up by a led.

And this is counter-intuitive, you'd have to teach every user to do this. Not to mention the same incompatibility with mainline problem again, unless it somehow can be done in userspace. What could be done is hacking popular libraries like SDL, but that's going to be a burden to maintain.

 

[vinipsmaker]

This looks good "on paper" but that increases the overall effort needed multiple times, and having way less than 1 person (in terms of manhours/week vs someone working fulltime) this is going to be extremely difficult to pull off without risking to have nothing at all ready on release.

An IRC log on a wiki page with a list of links to forum posts is already some documentation.

And say that I want to help and work and the tools. How can I make anything if the specification of the PND file format is closed? The effort to figure it out the file format looking on the source code of several spread tools would be a real blocker to new developers. And then the development would be very slow because there is only one person working on it.

And this is counter-intuitive, you'd have to teach every user to do this. Not to mention the same incompatibility with mainline problem again, unless it somehow can be done in userspace. What could be done is hacking popular libraries like SDL, but that's going to be a burden to maintain.

I'm not favoring this decision, but your complaint is bad. This can be an easy process (hidden under a GUI).

 

[Wrath Of Khan]

I wholly agree that it would make sense, to have a more concerted effort this time, for the pyra os and other software.

If possible a team could be set up, if any forum members would be willing to seriously contribute.

I was thinking the exact same myself.

Well internet browsing was always so slow and unreliable on the pandora. It was ok but not fast enough.

I know there was various reasons for that of course.

Id like to see a specific browser worked on for the pyra.

Better to have one good browser than ten so, so browsers.

 

[ekianjo]

Well internet browsing was always so slow and unreliable on the pandora. It was ok but not fast enough.

 

Have you tried Qupzilla ? It's way faster than most other browsers on Pandora. 

ANother reason why browsers have been slow on Pandora is because on desktop they are usually not optimized for speed as much as the mobile ones, and resources like RAM are supposed to be abundant. 

This being said, the Pyra will run browsers very very fast. We don't need any "optimized" version of anything for Firefox or anything else to run well on Pyra. 

 

[ekianjo]

This looks good "on paper" but that increases the overall effort needed multiple times, and having way less than 1 person (in terms of manhours/week vs someone working fulltime) this is going to be extremely difficult to pull off without risking to have nothing at all ready on release.

I agree with notaz here. Ideally this would be a good idea to make things work, but let's be realistic two seconds. There's tons of things to do on the current Pandora and there's been repeated calls from SKeezix and others about the fact that there's almost nobody working on the firmware (apart from... notaz!) and we have yet to see many developers jump on board to do anything.

So, why would there be more involvement for the Pyra while the current involvement with the Pandora is close to zero, while it has an existing user base and all ?  

Guys, if you are serious about helping notaz, why not starting to show what you can do with the current Pandora that can be reapplied to the Pyra later on ? Otherwise you are just talking the talk but not walking the walk. 

 

[Wrath Of Khan]

Well internet browsing was always so slow and unreliable on the pandora. It was ok but not fast enough.

 

Have you tried Qupzilla ? It's way faster than most other browsers on Pandora. 

ANother reason why browsers have been slow on Pandora is because on desktop they are usually not optimized for speed as much as the mobile ones, and resources like RAM are supposed to be abundant. 

This being said, the Pyra will run browsers very very fast. We don't need any "optimized" version of anything for Firefox or anything else to run well on Pyra. 

Not yet. I will try qupzilla. My pandora has been neglected as of late.

Good news indeed that the pyra will have no issues with browsers.

 

[Neelix]

I myself don't see .pnd backward compatibility as a hugely important feature.

You might not but ED does, it was one of main reasons for not going Intel's way from what I can tell.

I agree that PND backward compatibility is important, but I honestly believe that a ginge-like compatibility layer or a chroot environment is the best way to implement it. I don't see it working any other way unless we run the same OS on the Pyra as on the Pandora.

I also think it's a good idea make a revised version of the PND system for the Pyra as we do still need a way to store portable applications on SD cards.

It can at least be done slightly more sensible this time, and have the gamepad bits show up as a single gamepad.

But this is not how the hardware is connected (bunch of unrelated devices on different buses) and such driver has no chance to be ever mainlined. Nobody likes to sit on old kernels just because there's nobody to do the porting work. Unless we can do it in userspace this is not going to happen.

I don't know a lot about kernel development so please correct me if I'm wrong but if this is done as a loadable module then shouldn't just be a matter of rebuilding it for the new kernel when a new kernel is built? What am I missing?

In any case this has already been done in userspace for the pandora, so it shouldn't be too hard to adapt that for the Pyra if need be, and incorporate it into the firmware.

- Neelix

 

[ekianjo]

I agree that PND backward compatibility is important, but I honestly believe that a ginge-like compatibility layer or a chroot environment is the best way to implement it. I don't see it working any other way unless we run the same OS on the Pyra as on the Pandora.

Seriously ? Why would you even need a chroot ? Angrstrom is a debian derivative, you should be able to make the libpnd work on the actual debian just fine without having to chroot anything.  

 

[aTc]

This looks good "on paper" but that increases the overall effort needed multiple times, and having way less than 1 person (in terms of manhours/week vs someone working fulltime) this is going to be extremely difficult to pull off without risking to have nothing at all ready on release.

Of course it's difficult to pull off, that's why you have to start early with these things.

And these things don't have to be taken to extreme levels, just that there must be some way for a complete outsider to join in.

Take the .next stuff for example. Despite beeing something hardly anyone cares about, it has its own reasonably easy to find section on the forum, it has a few posts that sort of tell what's going on, a github repo that makes contributing easy, and a build system that's not completely impossible to set up. And it actually attracted a few people that jumped in and helped a bit.

And that's for something that's hardly an official pandora team project, based on a near unusable OE base system. An official pyra project based on debian should have it far easier.

If the infrastructure is there, people will show up, that's how all open/free projects work.

There are already too many devices out there that have great hardware specs, but are near unusable thanks to bad software.

Getting a software dev team and infrastructure set up should be just as important as getting the hardware itself developed.

Just because you now have a kernel and a somewhat working debian image doesn't mean that you can just sit back and wait.

You might not but ED does, it was one of main reasons for not going Intel's way from what I can tell.

ED is wrong.

I've told him a few times, but he still sees .pnd as the magical perfectly working system it appears to be to the end user, instead of the hacked together disaster that it is on the inside.

Of course you could spend a lot of time on adding even more hacks on top of that to get it running on a completely different system, or you could spend that time on getting something more sensible done.

For marketing purposes it's nice to be able to mention 1000+ apps, but as I said before, 95% of them are just things that exist as .deb packages already, and the rest is easily recompiled/repacked.

And just to make things clear,  a cleanly implemented .pnd like system in itself isn't a bad idea.

But this is not how the hardware is connected (bunch of unrelated devices on different buses) and such driver has no chance to be ever mainlined. Nobody likes to sit on old kernels just because there's nobody to do the porting work. Unless we can do it in userspace this is not going to happen.

One failed project for pandora was a daemon that took all those devices and made them show up as a single gamepad. So doing it in userspace is certainly a possibility.

I think it went nowhere because apps just switched around nub modes when they felt like it, making devices pop in and out of existance all over the place.

As long as the hardware actually shows up as what it really is ,and stays that way, instead of switching between beeing a keyboard, a mouse or a gamepad, a userspace daemon that ties it all together would be the way to go.

And this is counter-intuitive, you'd have to teach every user to do this. Not to mention the same incompatibility with mainline problem again, unless it somehow can be done in userspace. What could be done is hacking popular libraries like SDL, but that's going to be a burden to maintain.

If any hacks need to be done, it'd better be one small userspace daemon, than having to patch half the OS. (Not everyone will want to run debian anyway)

But you do need some easy way of switching the daemon between generating mouse/keyboard events, and gamepad events.

You can't have it always do both , generating mouse events and nub movements at the same time , or fire buttons that also press keys at the same time for example will do weird stuff in a lot of games.

A clearly labeled keyboard button that makes the daemon switch between modes shouldn't be THAT hard to explain to users.

Make it light up a led to indicate the mode, and everyone should be able to figure out what's going on and what to do when they move the nub and the mouse doesn't move.

(you could do it in software with an applet, but you'd probably want to switch modes inside a fullscreen game sometimes, and having to go back to the desktop just to switch it around is even less user friendly)

 

[slaeshjag]

I agree that PND backward compatibility is important, but I honestly believe that a ginge-like compatibility layer or a chroot environment is the best way to implement it. I don't see it working any other way unless we run the same OS on the Pyra as on the Pandora.

Seriously ? Why would you even need a chroot ? Angrstrom is a debian derivative, you should be able to make the libpnd work on the actual debian just fine without having to chroot anything.  

At least the majority of the libraries will need to be overridden due to the almost certian softfp->hardfp transition. The PND system isn't the problem per se.

It should be possible to auto-detect a PND made for the old pandora system, and automatically launch it in the chroot.

 

[ekianjo]

due to the almost certian softfp->hardfp transition

I didn't think about that. Then a number of PNDs would not work out of the box, but still some would.  

 

[vinipsmaker]

What will we develop for Pyra? We should document this and make some experimental github projects.

• A compatibility layer
• A revised PND format
  Spec
• Implementation

Am I forgetting something?

I'd like to follow both projects, but I'm more interested in help the development of the specification of the PND format.