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

[pmprog]

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.

Heh, I remember the first time I started the Tournament Hub, I was told adding all those features was monolithic and "Microsoft-y", not very linux like. Still @skeezix maybe we could bang heads again, and make a combined product?

My developer-API is currently C based, and can be found here. I've got another two repos, one for the website, and one for a Qt UI, so cross platform

 

[Eight Bit]

 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.

Only a few willing or able to put in the time and effort that is needed and finish what they start, I hope is what you want to say. I think you have a very reliable community here

 

[foxblock]

No, it happens because there is not enough manpower.

[...]

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.

[...]

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.

Yup, I totally get it. However most people here either lack the skill, the time or both to help.

Money could "fix" the time problem. I mean most people working on the Pandora's OS did so voluntarily and as you said, you cannot rely on that! Why not hire a few men to work on it full-time. Yup, that is a lot of money, maybe it's worth it, maybe not, depends what you are aiming for.

I would love to see people getting paid for some great software after the release of the Pyra, so thanks for planning on doing so. However doing an investment before the release could avoid some of the problems the Pandora had imo.

It like when you move into a new house, if you don't do all work, like painting walls in the colour you like, while you are moving in, you will never do so, because people are inherently lazy and good at accepting stuff as status-quo and just living with that.

I also said the exact same thing some time ago when the Pyra was just announced, so it's not like I am crying just now when the project enters the final stretch. I just feel like the attitude has not changed since then.

Concerning the dev hub: I totally agree the standards need to be laid out first, but coding has to happen eventually or it will just be a lot of arguing about nothing of value in the end.

Concerning SDKs: Not just talking about compiling on the Pyra/Pandora. There also should be an easy way and "officially" supported way to compile from a desktop PC (of any OS). There is a nice VM image for Linux now, if this had existed from the start, the entry to development for the Pandora would have been much easier for many people.

I know this is a lot of complaining coming from somebody who did not put much time into working on the Pandora core, but when I see a valid concern from an experienced developed (who did put in a lot of time) simply get waved away, I become concerned.

Maybe it is coming across as more negative than it is intended, sorry for that. I appreciate the time and money you and all contributors like aTc put into this humongous project. I just fear mistakes could be repeated and I would hate for the Pyra to be plagued by the same problems the Pandora had.

Thanks for your reply.

 

[ptitSeb]

I don't completly agree with you @foxblock, at least on certain point.

The "no unified control scheme" is not a problem of Money or early start... It's just, well, it's an Open world and community. 

I prefer the main action button to be X, so most of my ports are like that. Other prefer B as main, so you find port like that... This is no Nintendo, Sony, or other, where the whole GUI & so as to be validated and must follow some guidelines...

So, I think some things are not messy, they are Open and Free, not the same things.

 

[ekianjo]

I prefer the main action button to be X, so most of my ports are like that. Other prefer B as main, so you find port like that... This is no Nintendo, Sony, or other, where the whole GUI & so as to be validated and must follow some guidelines...

Yeah, but it kind of makes sense to be consistent across applications, though. For the end-user, that's the best.

That's why there should be some kind of guideline to avoid everyone using different standards for each application they port, at least to ensure they don't do it unintentionally.

For example, it's particularly annoying that every application has a different way to exit. That kind of basic behavior (action, quitting, selecting) should be consistent as much as possible across applications, just like we don't reinvent scrollbars on the desktop the whole time.

 

[ptitSeb]

I prefer the main action button to be X, so most of my ports are like that. Other prefer B as main, so you find port like that... This is no Nintendo, Sony, or other, where the whole GUI & so as to be validated and must follow some guidelines...

Yeah, but it kind of makes sense to be consistent across applications, though. For the end-user, that's the best.

That's why there should be some kind of guideline to avoid everyone using different standards for each application they port, at least to ensure they don't do it unintentionally.

That would be interesting to have one, but even if there was one, it would not be mandatory to comply to it to be allowed to publish an app.

My point is not to point out that the lack of guideline is good (and in fact it's not), but to point that even with guideline, it would be messy anyway.

 

[PokeParadox]

I prefer the main action button to be X, so most of my ports are like that. Other prefer B as main, so you find port like that... This is no Nintendo, Sony, or other, where the whole GUI & so as to be validated and must follow some guidelines...

Yeah, but it kind of makes sense to be consistent across applications, though. For the end-user, that's the best.

That's why there should be some kind of guideline to avoid everyone using different standards for each application they port, at least to ensure they don't do it unintentionally.

That would be interesting to have one, but even if there was one, it would not be mandatory to comply to it to be allowed to publish an app.

My point is not to point out that the lack of guideline is good (and in fact it's not), but to point that even with guideline, it would be messy anyway.

This has been a problem since the GP2X (and possibly GP32 days although that's before my time). I think the "easiest" way to solve this inconsistency issue is to abstract away from physical buttons and map "Actions" to the function you are doing in the application or game. Then the OS provides a GUI to map these actions to the physical buttons. The developer does not care what the physical buttons are (unless it's text input or needs to be specific keys) but does want to assign an accept/back/pause/menu button action.

A Style guide/standards has been attempted with each open console release and each time has had limited success.
Another option would be a validation process to be listed in the official repo.

 

[Grench]

OK - so, IMHO, what gets assigned to B or X is irrelevant.  What is important is that there is a defined method of communicating with the nubs (in mouse and joystick modes) and every button on the machine.  I.e. it is important that the hardware behaves in a known consistent manner from the physical button press to the OS.  

How the individual programmer/porter/etc interprets that input and interprets it for the screen is entirely 'up to them'.  If someone doesn't like it enough, they can program/port/etc their own version of it.

So much attention to what B and X 'do' INSIDE applications (emulator is an app) is a waste of energy.  Those will always be decisions of the application creator and should not be dictated.

 

[Christoph.Krn]

foxblock, ptitSeb, ekianjo, PokeParadox, and Grench, you may want to read flipBX - Gaming buttons (non-)standardization on Pyra if you haven't done so yet. If you added your opinion or personal view there, that would be splendid, because now is the best time to discuss this (as opposed to /after/ the Pyra's release). I'd really like to hear more people say what they think of on the idea.

 

[EvilDragon]

I also like the idea of configurable default buttons.

But it needs to be done in a way that even not very experienced porters (like myself) can implement that in their ports.

I know how to change SDL button configs when porting a game... would that "Action"-Button have it's own SDL keycode, or how would that work?

 

[hns]

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.

The hardware supports two modes (depending on which components are installed):
1.) Pandora mode - here the potentiometer is analog and attenuates the PCM DAC signals before they go to the headset or speaker amplifiers
2.) TWL6040 mode - here the potentiometer goes to one of the ADC inputs of the Palmas chip so that the gpadc iio driver presents a value between 0 and 100%. This can be repeatedly fed by a daemon into amixer
In both cases the position is remembered (mechanically) whatever happens.
Indeed 2.) is more flexible to configure what you really want to control by the volume wheel (headset, speaker, bluetooth, HDMI) - or even use it as a game input device...

 

[TrashyMG]

What I'm worried about with option 2 is lack of control when the CPU is bogged down or perhaps if it's in a state where the software isn't in control of the hardware, such as low-level use, using an alternant OS and etc. 

 

[Christoph.Krn]

I also like the idea of configurable default buttons.

But it needs to be done in a way that even not very experienced porters (like myself) can implement that in their ports.

I know how to change SDL button configs when porting a game... would that "Action"-Button have it's own SDL keycode, or how would that work?

It would be good if we could continue this discussion over at the flipBX thread, which already contains more information on this. The short version is that luckily, if you just read a bool from a file, and switched two buttons' functions in menus depending on whether the value was true or false, many of the biggest user experience problems concerning buttons would already be eliminated, as far as I can see (but like I said, I'm looking for more input from others). This would be rather easy to build into applications. More information is in the flipBX thread.

 

[Linux-SWAT]

I prefer the main action button to be X, so most of my ports are like that. Other prefer B as main, so you find port like that... This is no Nintendo, Sony, or other, where the whole GUI & so as to be validated and must follow some guidelines...

Yeah, but it kind of makes sense to be consistent across applications, though. For the end-user, that's the best.

That's why there should be some kind of guideline to avoid everyone using different standards for each application they port, at least to ensure they don't do it unintentionally.

That would be interesting to have one, but even if there was one, it would not be mandatory to comply to it to be allowed to publish an app.

My point is not to point out that the lack of guideline is good (and in fact it's not), but to point that even with guideline, it would be messy anyway.

I totally agree and it's something I complained about at the very beginning of the CC days.

But even if it's messy, at least there's a guideline, and that's something important.

 

[hns]

What I'm worried about with option 2 is lack of control when the CPU is bogged down or perhaps if it's in a state where the software isn't in control of the hardware, such as low-level use, using an alternant OS and etc. 

What could happen?
The twl6040 isn't emitting noise by itself and it can't read eMMC or SD cards. So if you play music by aplay, this also needs the CPU to run and provide the sound data. So output will simply stop as well.
The worst case could be that the daemon crashes and the volume wheel becomes inactive. In that case you can still use the GUI (I think there is a sound level widget in the XFCE bar) or simply press two buttons to hard reset.
Anyways there are only these two solutions. And we can't insert the volume wheel into the twl6040 analog audio output signal path because it has built-in amplifiers (btw: avoiding the only two big tantalum capacitors needed for the Pandora design. Tantalum caps are not very well for the environment).
But since nobody knows exactly how well these alternatives operate, we do the prototype run to find out. At least one device will be reworked for the Pandora audio. And then we will compare audio qulity and useability aspects so that ED can decide which one goes into mass production.

 

[Exophase]

I also like the idea of configurable default buttons.

But it needs to be done in a way that even not very experienced porters (like myself) can implement that in their ports.

I know how to change SDL button configs when porting a game... would that "Action"-Button have it's own SDL keycode, or how would that work?

The proposal is to implement it through environment variables, so the code would look something like this (in C):

const char *confirm_key_str = getenv("PYRA_ACTION_CONFIRM");
int confirm_key = PYRA_ACTION_CONFIRM_DEFAULT;
 
if(confirm_key_str)
  confirm_key = strtol(confirm_key_str, NULL, 10);
 
// ... code here, get key code
 
if(SDL_key_code == confirm_key_str)
  // Do confirm stuff

 

[Exophase]

What I'm worried about with option 2 is lack of control when the CPU is bogged down or perhaps if it's in a state where the software isn't in control of the hardware, such as low-level use, using an alternant OS and etc. 

I don't know why people are so worried about this. If the device hard freezes you'll want to reboot it anyway.

IMO this should be implemented at the kernel level, with a timer IRQ monitoring the ADC or perhaps an ADC level change trigger if the chip supports it. Functions like this and some other things might actually fit well on one of the Cortex-M4s, but I don't think people will be very happy about the OS reserving one for internal use even if they'll probably never actually use them (let alone both)

This design has some decent advantages. Principally, being able to display the wheel's level on the screen. But it also means you could hypothetically change the volume curve (eg raising or lowering the logarithmic coefficients), rebalance left/right error, or ignore it entirely if it breaks instead of risking it ending up always open and therefore killing audio.

Is there any reason that the pot output isn't routed to the PMIC ADC input in the Pandora-style circuit? That'd at least allow volume display.

 

[Christoph.Krn]

The proposal is to implement it through environment variables, so the code would look something like this (in C):

const char *confirm_key_str = getenv("PYRA_ACTION_CONFIRM");
int confirm_key = PYRA_ACTION_CONFIRM_DEFAULT;
 
if(confirm_key_str)
  confirm_key = strtol(confirm_key_str, NULL, 10);
 
// ... code here, get key code
 
if(SDL_key_code == confirm_key_str)
  // Do confirm stuff

Where was this proposed? IRC?

So if you have one application that by default assumes PYRA_ACTION_CONFIRM on (B) and, say, PYRA_ACTION_BACK on (A), but the user has PYRA_ACTION_CONFIRM set to (B), and PYRA_ACTION_BACK to (X), then what is the software to do if (X) was supposed to be some other function? What if the user has set even more variables, and there's even more conflicts? What's the proposed solution to this? Is there something I'm not seeing here?

 

[TrashyMG]

What I'm worried about with option 2 is lack of control when the CPU is bogged down or perhaps if it's in a state where the software isn't in control of the hardware, such as low-level use, using an alternant OS and etc. 

I don't know why people are so worried about this. If the device hard freezes you'll want to reboot it anyway.

IMO this should be implemented at the kernel level, with a timer IRQ monitoring the ADC or perhaps an ADC level change trigger if the chip supports it. Functions like this and some other things might actually fit well on one of the Cortex-M4s, but I don't think people will be very happy about the OS reserving one for internal use even if they'll probably never actually use them (let alone both)

This design has some decent advantages. Principally, being able to display the wheel's level on the screen. But it also means you could hypothetically change the volume curve (eg raising or lowering the logarithmic coefficients), rebalance left/right error, or ignore it entirely if it breaks instead of risking it ending up always open and therefore killing audio.

Is there any reason that the pot output isn't routed to the PMIC ADC input in the Pandora-style circuit? That'd at least allow volume display.

I'm not talking about freezing, I'm talking about delayed response time by just general CPU usage... or lack of control of sound when in odd software states. It's a usability annoyance to depend on software that could fail to turn down the volume when in a crowded room and such. I also like to know 100% of the time when I plug in my headset it turns off the speakers.  

Not everyone plans on using the same OS or even Kernel, to me the Pandora method is simpler and less of a usability nightmare. If this was all done with a microcontroller independent of the kernel/OS sure maybe I could see it as a good option.

 

[WizardStan]

I have the following situation on my computer with volume only control: my volume is only at 3% with these headphones.  I don't have a great deal of accuracy when I do need to adjust the volume for any reason.  If my headphones had a hardware wheel on them I could crank that way down and then software adjust from 0 to 100% as needed, and that would be fine.

You can control this for the speakers, drive them in such a way that the volume is good at 100%, but you can't control headphones, different headphones will have different impedance which means different volumes at the same output level.  And not just the impedance, but different headphone styles will behave differently.

This is the #1 reason I want actual hardware volume control, so that I can use any headphones I can get and still get decent volume adjustment.

The #2 reason stems back to when I used to run Windows, I once started it up in the middle of a library and it played 5 seconds of startup noise really loudly and I couldn't mute it because the software for controlling that hadn't started yet.  A flick of the wheel would have solved it.  But this can be solved in other ways, like making sure the volume daemon is started before it's allowed to play any audio at all.