I wonder... will the Pyra be more "my thing"?

[scippie]

I have bought 2 pandora's in the past, one in early development with lots of flaws and another last year because I saw lots of issues were solved.

Sadly, I don't use the pandora as much as I wanted to be using it. For me it has certainly not been worth the price, although it's a fun thing to have of course.

Here are the most important reasons why I don't use it as much:
- The joystick nubs sometimes do not work as they should. If feels like bad calibration, but it can occur at any time, even after having worked fine, where I can no longer move my mouse cursor up with it (or only veeeeeeeery slowly). I have had this issue with both pandora's. It's just no fun using the pandora this way.
- Why not use the stylus or the touch? Because here's the next thing: the stylus/touch almost never works in the corners of the screen. I have had this issue with both pandora's. It's just no fun using the pandora this way.
- Most of the software in the app repository are no longer maintained up to where they even no longer function. I have tried to make use of the pandora for all kinds of situations where the device itself would perfectly work but the software is bad or not even working. It's just not fun trying to use the pandora for something productive but not be able to because of the software is not working
- I no longer seem to be happy with spending my time on "hacking", something I used to do all the time when I was younger. Otherwise I would have been fixing the software myself, but I just no longer want to do it.
- Lots of games did not work or stuttered or ...

So now I read up about the Pyra and the most important thing I notice is: it supports a complete Debian! This is great! I use Debian myself in virtual machines and servers, even for developing. If I understand correctly, this means that whatever software is released in the Debian repository WILL work on the Pyra. Am I correct? Everything that is open source will compile on it, right?
If this is the case, a BIG problem I had with the pandora is solved! I will probably not need to be hacking my way through because if it's on a debian repo, it works.

But how about the nubs? Will they be better now? How about the touch on the screen, will it perform better? Will I be able to tick the corners of the screen now?

The reason I ask this is that this has obviously been a problem with the pandora (as both of mine had it) and I don't understand that they have never been solved. The early pandy's had the issues, and the latest pandy's had the same issues! They have never been addressed while I can't imagine I have been the only one suffering from them.

Because of this, I am a little concerned about the Pyra. Is ED only focusing on the new things or will the old problems like the ones I mentioned also be handled now?

As you can read... after being disappointed two times by the pandora, I never thought of buying the Pyra until I recently read what it's all about. This is the second time ED gets me excited again. Maybe I'll be pre-ordering soon! But only if my mind is eased with some answers to my questions

 

[PowerGod]

If you find Pandora PNDs that are not working you should ask about them in the forum, maybe the author will correct them, or maybe you just found something wrong on the OS, and even in this case a solution could come.

The OS on the Pyra will be Debian for ARM, so everything in it's repo should work (if it doesn't need specific hardware), but beware that the repo differs from the one of Debian for PC (x86 and compatibles)

 

[TrashyMG]

But how about the nubs? Will they be better now?

They're completely new, off the shelf components, not some untried custom design that the Pandora used. They use Hall of effect sensors vs weird resistive pad and brush method.

If I understand correctly, this means that whatever software is released in the Debian repository WILL work on the Pyra. Am I correct?

Yeah pretty much, only few exceptions I see. Most games that are 3D accelerated are geared for openGL, not OpenGLES. The PowerVR is GLES only, so we need something like glshim or have the code converted. I found on the OMAP5 development board, emulators are pretty poorly optimized on the Debian Repository. Dosbox ran slower than it does on the Pandora, however after using a properly compiled version targeting the specific platform it was lightning fast.

 

[HelenF]

I'm looking forward to the Pyra mainly for the better nubs/keyboard/screen and having full Debian as the main supported OS.

Have you tried Slackware on the Pandora? It's probably the best-supported alternative OS. Things need compiling from source sometimes, but this usually just works (unlike compiling for SuperZaxxon which is a dodgy business).

 

[levi]

They're completely new, off the shelf components, not some untried custom design that the Pandora used. They use Hall of effect sensors vs weird resistive pad and brush method.

FWIW, it's the Hall effect, named after Mr Edwin Hall you're referring to there. No 'of'.

I found on the OMAP5 development board, emulators are pretty poorly optimized on the Debian Repository. Dosbox ran slower than it does on the Pandora, however after using a properly compiled version targeting the specific platform it was lightning fast.

That's slightly unexpected. Debian's armhf platform is armv7+floating point, which is what the Cortex-A15 is built around, so a rebuild of stuff using the same source should perform pretty similarly I'd have thought. Were there any significiant source changes? I guess you built the latest stuff versus whatever debian built mind you, which might have more to do with it.

Also, in reply to the OP I'll mention the LCD surround on the pyra clips in on one side, but screws in at the other three fixing points. It should have less play, and therefore be less unlikely to pop out one of its clips, which is a common reason behind touchscreen problems. If it's not that in your case, I don't know what it is - mine worked fine, even in the corners.

 

[TrashyMG]

FWIW, it's the Hall effect, named after Mr Edwin Hall you're referring to there. No 'of'.

Noted think I got Hall of mirrors or something on my brain.

That's slightly unexpected. Debian's armhf platform is armv7+floating point, which is what the Cortex-A15 is built around, so a rebuild of stuff using the same source should perform pretty similarly I'd have thought. Were there any significiant source changes? I guess you built the latest stuff versus whatever debian built mind you, which might have more to do with it.

Also, in reply to the OP I'll mention the LCD surround on the pyra clips in on one side, but screws in at the other three fixing points. It should have less play, and therefore be less unlikely to pop out one of its clips, which is a common reason behind touchscreen problems. If it's not that in your case, I don't know what it is - mine worked fine, even in the corners.

I have a feeling it may have to do with the options that the repo version was compiled with, like OpenGL and other nonsense. @Wally built the port I tried on the devboard, maybe he could tell you more on what he did for optimization.

 

[sulu]

As for the software, you pretty much got that right. Pretty much everything that's available in the Debian repo will work, but there are some constraints:
1. As TrashyMG mentioned: Everything that needs OpenGL will probably not work until glshim is ported. And even once that's done, at least in its current state it would only support OpenGL 1.?. So games that require higher OpenGL versions like Supertuxkart won't work even then.
2. Performance may vary greatly. Most software is optimized for x86, and while it mostly runs on arm, it doesn't necessarily do that very fast (even with respect to the limitations of the SoC). You should also check if the software you want is available for arm at all. You shouldn't assume that your experience with x86 will be portable (though it will be helpful in most cases). For example, Chromium and Virtualbox will not be available in Debian/arm.
3. If you're thinking long-term, you'll likely be dependent on the PyraOS devs or the community. While the kernel patches necessary for the Pyra are already being mainlined, you'll still need someone to provide you with kernel updates if you don't want to fiddle with those on your own. It's unlikely that Debian will do that for you. So the worst case is, that you might be stuck with a device that's hard to maintain in five years, should ED and this community vanish for some reason.

As for the hardware:
Well, so far nobody actually had a final production model in his hands, not even ED. The Prototypes look promising so far, but they are still just prototypes and it can't be predicted what problems might occur during or after mass production.
If I interprete your situation correctly, and if you wouldn't mind missing the first batch, then I'd just wait for actual feedback of final customers before buying a Pyra if I were you.

 

[Wally]

Pretty sure the debian port lacks the dynarec and various other ARMv7 optimisations, I Applied @M-HT's optimisations as mentioned somewhere here, that's pretty much it.

As Ptitseb has a better port, i'll probably let him take control!

 

[TrashyMG]

Just to note many games that do require OpenGL on the repository can launch thanks to Mesa, but the performance is horrible as it's just software rendering.

 

[ptitSeb]

@scippie : what game stuter? or software is not maintained anymore?

 

[levi]

3. If you're thinking long-term, you'll likely be dependent on the PyraOS devs or the community. While the kernel patches necessary for the Pyra are already being mainlined, you'll still need someone to provide you with kernel updates if you don't want to fiddle with those on your own. It's unlikely that Debian will do that for you. So the worst case is, that you might be stuck with a device that's hard to maintain in five years, should ED and this community vanish for some reason.

You don't have to fiddle with kernels on Debian or any other linux system that uses package management; the apt system will cope with updating your kernel as you use it to update the rest of the system. I guess the Pyra dev team might use a separate repo configured first to provide improved kernels and so on, targetting specific features of the Pyra, and if we do manage to upset Notaz enough to stop him providing them, it should just be a matter of editing sources.list and using the stock debian kernel instead, even if that won't perform quite as well.

That said, I'm not aware of Notaz actually modifying the Pandora kernel beyond the one from kernel.org; his patches have mainly concerned daemons and scripts and things as far as I know.

 

[sulu]

Just to note many games that do require OpenGL on the repository can launch thanks to Mesa, but the performance is horrible as it's just software rendering.

My knowledge is only theoretical and quite old, so I might have a wrong impression. But weren't GL and GLES very similar - so much that one can almost rewrite the code automatically in most cases? Has that ever been tried for the Pandora?

You don't have to fiddle with kernels on Debian or any other linux system that uses package management; the apt system will cope with updating your kernel as you use it to update the rest of the system.

But you'll have to rebuild initrds and update bootloaders. At least the latter part won't be done by Debian for you on arm.

I guess the Pyra dev team might use a separate repo configured first to provide improved kernels and so on, targetting specific features of the Pyra,

That will be the case during the Stretch release cycle for sure, maybe even longer.

and if we do manage to upset Notaz enough to stop him providing them, it should just be a matter of editing sources.list and using the stock debian kernel instead, even if that won't perform quite as well.

What if he gets run over by a bus?
I'm certainly not hoping for that, but this is the typical question someone at my workplace will be asked if he claims he doesn't have to know how one of our processes he depends on works, because another colleague will take care for that.

 

[levi]

But you'll have to rebuild initrds and update bootloaders. At least the latter part won't be done by Debian for you on arm.

Really? I often watch my arch x86 systems rebuilding initfs and upgrading my bootloader as part of its post-install scripts for the kernel or the bootloader. It's been a while since I used Debian on any system, but why wouldn't it do the same on armhf? Perhaps not the bootloader, as on ARM that doesn't tend to be considered part of Linux for historical reasons, but the pandora also didn't use an initfs to boot as far as I know. Just the bootloader then.

What if he gets run over by a bus?
I'm certainly not hoping for that, but this is the typical question someone at my workplace will be asked if he claims he doesn't have to know how one of our processes he depends on works, because another colleague will take care for that.

Well, as far as I know, how Notaz updates the kernel is to take upstream versions from kernel.org and build those. There's plenty of documents on the web that will tell you how to do that. As for the other stuff he does that actually makes the system more usable, then he would be a big loss to the project, but I hope someone else would be able to step up and at least maintain his work.

 

[ptitSeb]

My knowledge is only theoretical and quite old, so I might have a wrong impression. But weren't GL and GLES very similar - so much that one can almost rewrite the code automatically in most cases? Has that ever been tried for the Pandora?

glshim & gl4es (look in the code, it's not that "automatic").

 

[sulu]

Really? I often watch my arch x86 systems rebuilding initfs and upgrading my bootloader as part of its post-install scripts for the kernel or the bootloader. It's been a while since I used Debian on any system, but why wouldn't it do the same on armhf? Perhaps not the bootloader, as on ARM that doesn't tend to be considered part of Linux for historical reasons, but the pandora also didn't use an initfs to boot as far as I know. Just the bootloader then.

If the bootloader isn't considered a part of the OS, then someone will have to take care for that. The point is, that scippie doesn't want to be that guy. So he needs someone else to do it for him. That might be notaz at the moment (and hopefully for a long time), but if it's only him I wouldn't call that a reliable basis. I'm even not sure if this community would qualify as a reliable basis for people to depend on if they don't want to dig deep into the system.

Now obviously, this community has been around for quite a while and I'm pretty new to it, so I might not see the whole picture. But I've been part of the Maemo community for quite some time and in its better days it felt pretty similar to this one. The truth is, that large parts of the Maemo community pretty much collapsed when Nokia ceased to support Maemo. There were a lot of great one-man shows going on, but once these people moved on to other systems much of the dynamics were lost. I'm just wary that something similar might happen here in case Openpandora GmbH ceases to exist for some reason.
So you might call me biased, but I believe that everyone who buys a product from a company this small that is maintained by a relatively small community should at least be prepared in the long run to not rely on any current infrastructure. I'm talking about a time frame of 10-15 years here, because that's roughly the time I use a specific piece of computer hardware.

glshim & gl4es (look in the code, it's not that "automatic").

I know. What I mean starts at the other end, at the application's code. My point was not to emulate GL functions to support GL software, but to rewrite the GL software to use GLES instead.
I believe my faint memories might be based on this article in the Maemo wiki [1], but it seems there's also a good introduction to it in the Pandora wiki [2]. I think it's 3-5 years ago when I read somewhere that someone wrote some type of software (I believe a script of some sort) that reliably and automatically converted 80-90% of GL code to GLES.
I was hoping that someone has a better memory of it or is actually working on something like that.


[1] https://wiki.maemo.org/OpenGL-ES
[2] https://pandorawiki.org/Porting_to_GLES_from_GL

 

[WizardStan]

My point was not to emulate GL functions to support GL software, but to rewrite the GL software to use GLES instead.

glshim isn't emulating anything, it is "rewriting" GL to be GLES instead. Instead of a script going through, finding OpenGL calls and literally replacing them in the code, the compiler does it through a library. The end result is virtually identical and there's no need to futz with the code as much.

 

[levi]

If the bootloader isn't considered a part of the OS, then someone will have to take care for that. The point is, that scippie doesn't want to be that guy. So he needs someone else to do it for him. That might be notaz at the moment (and hopefully for a long time), but if it's only him I wouldn't call that a reliable basis. I'm even not sure if this community would qualify as a reliable basis for people to depend on if they don't want to dig deep into the system.

For reference, the pandora's bootloader has only ever been updated once in the time I've owned mine, and that was for improved SD card support, so it's had no security fixes that I know of.

You're completely right that the benefits of owning a Pandora or a Pyra are intrinsically linked to the community here, and if too many people jump over to the GPD Win or something newer then that could be a problem. Some of the more prolific posters here came from the PSP modding scene, others came via the GP32 and GP2X, so they're not tied to any particular system. But at least while the Pandora was new, people were still updating GP2X stuff for a little while while the same projects could run on both. I guess it limited new projects on the GP2X, but there were a few devs would couldn't afford a Pandora and kept with their GP2Xs or Wizes.

 

[FBnil]

disappointed two times by the pandora

Three times is a charm. To be honest, I am not sure you would get more out of it. Things improved of course, the brittle case is now strong enough a greek can stand on it. The nubs are totally new and do not have the problem of the Pandora's. The keypad is still being tweaked. Keyboard keys are not where they used to be. The Pyra is better because it is an improved iteration. Not all has been fixed: The screen remains small, and the CPU power is still not impressive. On the flipside it means it is portable and the battery life will not dissapoint. But the important thing: We need you. We need to make a second batch possible. Who knows, maybe there will be no more produced after the first batch (*).

My advice: Wait and see. But its gonna be a great product...

(*) Rumor has it a government department, dissatisfied with the security of the Neo900 (and being unable to spy on it) made it so their paypal got closed. Who knows, this could happen to the Pyra too...

 

[levi]

Paypal? Where we're going we don't need... paypal!

/accelerates to 88mph

 

[scippie]

Wow, I hadn't seen any notification email so I thought nobody answered... Thanks a lot for all the answers. I will let them sip in slowly.

For what I already noticed: only opengl es is a little disappointing although I understand of course, almost every portable device only supports es, but those portable devices are not trying to run software that already exists for years.

Not the same debian repo but a pyra repo seems to me like it will get us back to the same problem I noticed with the pandora repo, people starting projects that aren't finished or no longer work since several updates.

@ptitSeb : It has been a while since I have been browsing. But I remember having to remove 3 out of 4 packages because they didn't respond well or didn't even start up. I remember an instrument tuning application that wouldn't work with the internal microphone. All pandora's use the same h/w (I think) so why would this not work when someone releases this on the repo? Stuff like that. Oh, I also remember trying to get HammerWatch to work. I have this game on Steam and I followed the instructions. Didn't work. Crashes and stuff like that. And really, lots more of that. Oh, and I don't think I have a faulty device as the h/w seems to work fine in other applications.