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

[EvilDragon]

Well, most of the hardware does BASICALLY work (as Nikolaus needed to make it work to test it), but there's not yet an easy way to use it.

* 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.
* LEDs: Will work from userspace as well, but no UI implemented.
* Wifi / Bluetooth: Should work out of the box as soon as the drivers are in the kernel.
* 3G/4G/LTE/GPS: Works from the command line (and with AT commands), but again, a proper UI is missing.
* HDMI out: Basically works. But the graphics system isn't finished yet (DRM vs. omapfb), so you can't use HDMI out at the same time as the LCD right now. Also, no audio yet with HDMI out.
* Audio: Analog output works fine.
* 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.
* Graphics: 3D driver not yet hacked in, 2D is fast (with fbturbo) or slow (with drm). In the end, we probably want to use a mixture of both (as 3D should work easier with the drm driver and stuff like xrandr works as well).
* SD-Cards, USB-Ports, etc: Should already work without any issues.
* Sensors: They spit out data, but there's no proper UI for them yet
* Powersaving: Nothing there yet. The SoC should powersave itself, but there's no UI yet for switching on / off the hardware you don't need to save some more power.
* Touchscreen: Works, but not yet the virtual two-finger-scrolling.
* Battery charging: The charger can work independently from the OS (so it works), but no functions are yet in the OS to control the charging (increase charging speed, etc.).

So most of the hardware drivers are there and working but are missing an UI (which can even be simply python UIs, etc., as most of these things work using the userspace)
Some hardware stuff is not yet included in the OS, as tearing fix for the rotator chip, powersaving, HDMI audio, 3D driver.

The OS itself is Debian ARM, so there's a huge repository with stuff

 

[TrashyMG]

 Also, no audio yet with HDMI out.

aTc just got this working...
 

 

[EvilDragon]

Heh That's some timing

Awesome, great work

 

[PowerGod]

Another thing I see as positive with having an early unit, is the excitement provoked by each new feature added.

Yeah, having everything already there is so boring

 

[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.

 

[Xcl4m4t10n]

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

 

[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.