So, what's the actual state of the software?

[benoitb]

Thanks for the precise status. Tearing and 3D are the most troublesome items I'd say. But given that the prototypes are not even finished this is a great state of software already !

 

[notaz]

* Nubs: Work. They use the same userspace and settings as in the Pandora, but there's not yet an UI implemented to set it up.

I think all userspace controls should be dropped and moved to the input daemon. That will make it compatible with mainline, and must be done early so nothing depends on the old stuff. So quite some work here.

* Wifi / Bluetooth: Should work out of the box as soon as the drivers are in the kernel.

The same was true for pandora, but turned out to be a multi year major headache...

* 3G/4G/LTE/GPS: Works from the command line (and with AT commands), but again, a proper UI is missing.

And probably difficult to use it for anything (like to get Internet).

* Audio: Analog output works fine.

On uevm which is completely different board... Have you even decided if it it will be pandora's audio with real analog wheel or default codec with messy software wheel handling?

* LCD: Right now, it's being started using a script. That works, but a proper driver should be written. Rotation also works, but no sync yet, so you have tearing with fast movements.

The tearing is regardless of rotation, we could not get pass-through mode to work. We don't even know if the tearing can actually be solved, right now there are just some unimplemented ideas/theories. If a portrait display could appear sometime soon I think delaying the device would be well worth it, this rotator will be major headache and maintenance nightmare.

 

[Silent-Hunter]

I've never NOT had tearing when using Linux.

 

[TrashyMG]

Thanks @notaz for all the points. Anyway my main question is still unsolved, Is someone "hired" to work on software like the hardware "team"?

Paid with a prototype perhaps... Nikolaus is paid and does a ton of the kernel work. aTc is chained to a desk down in a basement enslaved to work on the OS.

 

[EvilDragon]

* Nubs: Work. They use the same userspace and settings as in the Pandora, but there's not yet an UI implemented to set it up.

I think all userspace controls should be dropped and moved to the input daemon. That will make it compatible with mainline, and must be done early so nothing depends on the old stuff. So quite some work here.

Such things can be improved in the future. We also improved a lot of the Pandora over time, so the Pyra doesn't need to be perfect from the beginning.

* Wifi / Bluetooth: Should work out of the box as soon as the drivers are in the kernel.

The same was true for pandora, but turned out to be a multi year major headache...

True, but we also had a custom-made antenna, etc.
The current module has a standard chip-antenna sitting right besides the module, so it should work better from the beginning (in theory, we'll see when we test it )

* 3G/4G/LTE/GPS: Works from the command line (and with AT commands), but again, a proper UI is missing.

And probably difficult to use it for anything (like to get Internet).

NetworkManager supports UMTS modems (even on the Pandora with a UMTS USB Stick), so in theory (again), it should work with that right away.

We'll find that out, but using UMTS modems in Linux is not as complex as it was years ago, it should be supported by Debian.

* Audio: Analog output works fine.

On uevm which is completely different board... Have you even decided if it it will be pandora's audio with real analog wheel or default codec with messy software wheel handling?

The uevm uses the same TWL we use on our system, AFAIK.
Pandoras audio circuit has been somewhat implemented, but as you mentioned to Nikolaus that it probably won't work like that, we'll populate both on the prototypes but default to the TWL (to test the Pandora circuit, some solderings need to be done on the PCB, but it's fully populated).
I don't know how Nikolaus planned the wheel in the case of using the TWL. I would need to check that.

* LCD: Right now, it's being started using a script. That works, but a proper driver should be written. Rotation also works, but no sync yet, so you have tearing with fast movements.

The tearing is regardless of rotation, we could not get pass-through mode to work. We don't even know if the tearing can actually be solved, right now there are just some unimplemented ideas/theories. If a portrait display could appear sometime soon I think delaying the device would be well worth it, this rotator will be major headache and maintenance nightmare.

There are multiple theories to get it to work, and what we know is that it will work for sure if we switch MIPI to command mode instead of video mode, which seems to be the default system which MIPI uses these days.

That needs some coding work, yes, but I'm also ready to hire someone to get it to work.

What we know is that it can be made to work, that's the most important thing for me.

 

[EvilDragon]

Thanks @notaz for all the points. Anyway my main question is still unsolved, Is someone "hired" to work on software like the hardware "team"?

Nikolaus knows some kernel developers from the GTA04 we could hire and when he finished the hardware, he also wanted to work on the drivers part a bit.

 

[pmprog]

On uevm which is completely different board... Have you even decided if it it will be pandora's audio with real analog wheel or default codec with messy software wheel handling?

Oh wow, I thought the whole point of having a volume wheel was that it was a 100% hardware control - so you could mute the device even if it'd locked up.

 

[ekianjo]

I've never NOT had tearing when using Linux.

Thats because you dont know how to remove the compositor

 

[TrashyMG]

On uevm which is completely different board... Have you even decided if it it will be pandora's audio with real analog wheel or default codec with messy software wheel handling?

Oh wow, I thought the whole point of having a volume wheel was that it was a 100% hardware control - so you could mute the device even if it'd locked up.

Screenshots of the board shows a potentiometer not some dial encoder... I think the Analog volume wheel is still in the plans.

 

[EvilDragon]

On uevm which is completely different board... Have you even decided if it it will be pandora's audio with real analog wheel or default codec with messy software wheel handling?

Oh wow, I thought the whole point of having a volume wheel was that it was a 100% hardware control - so you could mute the device even if it'd locked up.

Well, I cannot remember that the Pandora ever locked up and made some weird noise... doesn't really happen often these days (if it even does).

I've asked Nikolaus, what the final solution for that is.

But: With a modern chip, every connector has it's own volume controls. So headphone port and speakers are two different output devices and use two different volume controls.

That also means that you can have different audio coming out of the speaker than via Bluetooth, Headphones or HDMI.

It's hard to find the best solution here.

 

[Silent-Hunter]

I've never NOT had tearing when using Linux.

Thats because you dont know how to remove the compositor

I'm not using a compositor. I'm using CDE it doesn't support that.

 

[TrashyMG]

@EvilDragon: I personally think the overall control of the output to speakers and headset should use just a regular potentiometer.  We shouldn't have to be dependent on the software to lower or raise volume... It's one of the absolute annoyances with modern devices. bluetooth, phone and other sources individually can be controlled by software, a tray utility or hotkeys IMO.

 

[EvilDragon]

@EvilDragon: I personally think the overall control of the output to speakers and headset should use just a regular potentiometer.  We shouldn't have to be dependent on the software to lower or raise volume... It's one of the absolute annoyances with modern devices. bluetooth, phone and other sources individually can be controlled by software, a tray utility or hotkeys IMO.

Yes, I know. But I don't know if this is easily possible - unless you only want to use one output for both speakers and headset.

 

[Silent-Hunter]

What's wrong with that?

 

[pmprog]

Well, I cannot remember that the Pandora ever locked up and made some weird noise... doesn't really happen often these days (if it even does).

When I say "lock up", I don't just mean where a reboot is required - even running Firefox locks up my Pandora for a reasonable length of time, and again, it doesn't have to be a weird noise - could just be MP3s that are stuttering, but can't because Firefox is battering the CPU.

 

[TrashyMG]

@EvilDragon: I personally think the overall control of the output to speakers and headset should use just a regular potentiometer.  We shouldn't have to be dependent on the software to lower or raise volume... It's one of the absolute annoyances with modern devices. bluetooth, phone and other sources individually can be controlled by software, a tray utility or hotkeys IMO.

Yes, I know. But I don't know if this is easily possible - unless you only want to use one output for both speakers and headset.

I can't think of anything outside of bizarre uses for needing to have different outputs simultaneously for the headset or speakers... generally most people plug in the headset want to mute the audio coming of the speakers. I can't think of any other device that would do it that way, no smart phone I ever owned could.

 

[EvilDragon]

I can't think of anything outside of bizarre uses for needing to have different outputs simultaneously for the headset or speakers... generally most people plug in the headset want to mute the audio coming of the speakers. I can't think of any other device that would do it that way, no smart phone I ever owned could.

Well, connect the headphones to your stereo to listen to music but get notification sounds out of the Pyra speakers (I hate it when they also go throught the stereo...)

True, not often used

I'll check with Nikolaus, as said.

 

[foxblock]

* Nubs: Work. They use the same userspace and settings as in the Pandora, but there's not yet an UI implemented to set it up.

I think all userspace controls should be dropped and moved to the input daemon. That will make it compatible with mainline, and must be done early so nothing depends on the old stuff. So quite some work here.

Such things can be improved in the future. We also improved a lot of the Pandora over time, so the Pyra doesn't need to be perfect from the beginning.

NO NO NO NO

This attitude is part of the reason the Software on the Pandora is such a mess.

Sure we got tons of PNDs, but as a developer as well as a user there are so many inconsistencies and pitfalls.

We don't have a unified control scheme - leading to confused users and an overall messy experience until you get used to it.

A lot of PNDs depend on old or new libs (which need to be packed along) - it took forever to get away from the completely hacked OS and kernel and get some sort of compatibility with standard packages.

There is no central game hub. We have C4A now (after how many years), but no common lobby/chat/etc. (granted this is not essential, however we are such a small community, you need to make it as easy as possible for people to meet and interact with each other)

There is no official SDK or devkit, everybody just hacked their own. It is pretty straightforward now, but it was a mess in the beginning.

It took quite a while for a central repo to appear and now that we got one it is basically dead development wise and not open-source.

Stuff like this happens and work hours get wasted because everything just gets rushed to a barely working state, then improved later.

I mean don't get me wrong, I am not trying to say everything is shit with the Pandora, but the Pyra could be so much more.

Doing things right from the beginning is essential to give users and developers a better experience. Sitting a few skilled people down with coordinated tasks could save so many man-hours in the end.

I do get that you have to make money and don't have the time to spend on "extra" tasks (since many people here probably don't even care for these things). I am not saying doing all this is easy and straight-forward. I don't really know what to do about it, just please keep this in mind and consider giving the OS and Software side of the Pyra before launch more attention than the Pandora's OS got back then.

 

[pmprog]

There is no central game hub. We have C4A now (after how many years), but no common lobby/chat/etc. (granted this is not essential, however we are such a small community, you need to make it as easy as possible for people to meet and interact with each other)

My Tournament Hub (Mk II) will hopefully deal with that... Once I finish it   Want to try and get my other Pyra-related project "finished" first though (it's coming along quite nicely), then get my hub API out there for implementing by devs...

I still dream

 

[EvilDragon]

* Nubs: Work. They use the same userspace and settings as in the Pandora, but there's not yet an UI implemented to set it up.

I think all userspace controls should be dropped and moved to the input daemon. That will make it compatible with mainline, and must be done early so nothing depends on the old stuff. So quite some work here.

Such things can be improved in the future. We also improved a lot of the Pandora over time, so the Pyra doesn't need to be perfect from the beginning.

NO NO NO NO

This attitude is part of the reason the Software on the Pandora is such a mess.

Sure we got tons of PNDs, but as a developer as well as a user there are so many inconsistencies and pitfalls.

Most of those happened because we don't have much space on the NAND, so we have to include various libraries...

Of course, the more we can finalize at the beginning, the better. But focussing on the most important bits first and improving the rest later is the only way to go.

Otherwise, you might have not-that-important stuff optimized, but something like 3D doesn't work at all.

We don't have a unified control scheme - leading to confused users and an overall messy experience until you get used to it.

A lot of PNDs depend on old or new libs (which need to be packed along) - it took forever to get away from the completely hacked OS and kernel and get some sort of compatibility with standard packages.

That should have been improved with the new .dbp format, which is in open development for quite some time.

There is no central game hub. We have C4A now (after how many years), but no common lobby/chat/etc. (granted this is not essential, however we are such a small community, you need to make it as easy as possible for people to meet and interact with each other)

Skeezix still plans to enhance that into a central game hub for the Pyra. I don't know how much time he has though, but in my opinion, it's important to have everything (with all features) clearly defined upfront. Code can happen later, but the standards need to be lined out and defined.

There is no official SDK or devkit, everybody just hacked their own. It is pretty straightforward now, but it was a mess in the beginning.

Yes, part of the small NAND. With the Pyra, you can easily install all the dev-packages.

It took quite a while for a central repo to appear and now that we got one it is basically dead development wise and not open-source.

I've got access to the sourcecode, milkshake agreed to make the repo for the Pyra as well and he also said multiple times that I'm free to do whatever I want with the sourcecode (even opening it) in case he stops working on it.

You can also work on a such a repo if you like, with guys from the community.

In fact, that's what I wanted to do when I wanted to create the new website (with Wiki, Repo, Boards, etc. integrated)  with community members over a year ago.

We found a few guys who wanted to do that voluntarily - and not a single line of code has been written since then.

I'm happy if community members do that, but sadly, it's not something that can be relied on.

Stuff like this happens and work hours get wasted because everything just gets rushed to a barely working state, then improved later.

No, it happens because there is not enough manpower.

We can't wait 2 more years with the release simply because the software takes so long to be polished enough.

aTc is basically working alone on the OS (with a bit of help), for over a year now, slaeshjeeg on the dbp system.

There actually was a long timeframe where anyone could've helped.

Crying out now when the hardware is nearly finished won't help at all. There wouldn't have be any need for rushing if more users would've helped long ago.

I mean don't get me wrong, I am not trying to say everything is shit with the Pandora, but the Pyra could be so much more.

Doing things right from the beginning is essential to give users and developers a better experience. Sitting a few skilled people down with coordinated tasks could save so many man-hours in the end.

True, but were are these people?

I'm happy to work together with anyone to improve everything from the beginning, but it seems there are only a few really reliable community members.

I do get that you have to make money and don't have the time to spend on "extra" tasks (since many people here probably don't even care for these things). I am not saying doing all this is easy and straight-forward. I don't really know what to do about it, just please keep this in mind and consider giving the OS and Software side of the Pyra before launch more attention than the Pandora's OS got back then.

Once the units are being sold, money shouldn't be the problem and I'm fine paying for good software work.

Until then, manpower is low, so we need to concentrate on the essential things, try to at write down everything we want to implement (and HOW it will be implemented) from the beginning and implement that later, so that not much will need to be changed.