The 1000-traces-puzzle

[WizardStan]

Also, I assume that the phone functionality (in software) will not work immediately

The phone functionality is actually pretty trivial, you can open the serial device and send AT commands to connect, dial, and answer the phone.So I fully expect basic functionality to exist from day 1, maybe day 2, even if it's just a command line "dialNumber <1111111>", a few days after that someone'll figure out a very simple answering service I bet.

A fancier dialer is going to be a ways away though.

 

[Jumpman]

Same here. If I ever order a Pyra, I will wait until all the stuff works that should work. I mean, who would buy a gaming PC if there is no 3D driver for it?

Full speed Dreamcast, full speed PPSSPP, and perhaps full speed Yaubause not good for ya? Who gives a damn what's driver is in it? I don't as long as it runs better than the Pandora now, then it is a big step forward. I still kiss my Pandoras goodnight every night as I can stop shaking my head in disblief this little 1GHz, 512MB ram can do so many thing so well. Ed was being nice and tried to be transparent by disclose all things to us so don't discourage him and his team please.

And please preorder in two months please

I'm "ALL IN", no problem. I guess some of these guys forget this is a homebrew style community. If we where all waiting for perfect outcomes, we wouldn't have gotten past the GP2X, or GP32 for that matter. LOL I understand some of the concerns from new community members, but if you've been around here for awhile, this is how things work, nothing new.

Honestly, I would rather us go the preorder route, VS Kickstarter, as I think it would be better that way. But if we can't get 1000, KS is a viable option. KS brings in more interest, but it also brings in more variables(good & bad). Ultimately, KS may be better, as I want ED and his team to be compensated for their troubles, and we may not get where we need to be by just the community ONLY.

I guess all we can do is see how many preorders come once they open and then go from there. The Pyra seems to be on a much better foundation than the Pandora ever was, and I'm hopefully as long as it doesn't run in to any Pandora style issues(Broken Nubs, case defects, Etc), it should sale rather well. As unique as the Pandora was so many years ago, the Pyra is still just as unique, if not more so,as there still isn't really any direct competition.

So, if all goes to plan(which it never does), and preorders are successful in September, can we be looking at holidays of this year for shipping? I'm assuming early 2016 at best, but I would love to be proven wrong.

Chris

 

[Haraldur]

Also, I assume that the phone functionality (in software) will not work immediately

The phone functionality is actually pretty trivial, you can open the serial device and send AT commands to connect, dial, and answer the phone.So I fully expect basic functionality to exist from day 1, maybe day 2, even if it's just a command line "dialNumber <1111111>", a few days after that someone'll figure out a very simple answering service I bet.

A fancier dialer is going to be a ways away though.

Perfect! I can now show off to my other somewhat-techy friends by initiating a call with "echo XXXXXXXXX > my_call_script.sh", assuming that it is just a TTY-type device in /dev.

I suppose a notification system, with vibration and noise-making would take a bit more effort -- a daemon to listen to one TTY, which sends commands to a vibrator TTY and runs something like "mplayer alarm.ogg"?

 

[slaeshjag]

Or.. You could just port over the openmoko stuff which uses the same cell module?

 

[fusion_power]

Same here. If I ever order a Pyra, I will wait until all the stuff works that should work. I mean, who would buy a gaming PC if there is no 3D driver for it?

Full speed Dreamcast, full speed PPSSPP, and perhaps full speed Yaubause not good for ya? Who gives a damn what's driver is in it? I don't as long as it runs better than the Pandora now, then it is a big step forward. I still kiss my Pandoras goodnight every night as I can stop shaking my head in disblief this little 1GHz, 512MB ram can do so many thing so well. Ed was being nice and tried to be transparent by disclose all things to us so don't discourage him and his team please.
And please preorder in two months please

I have no money at the moment, I can't buy the Pyra in the near future, no matter if it has 3D or not. ^^"And my worries were actualy about general hardware acceleration, not only 3D. On my Pandora I can't watch anything that is .mkv (mostly h.264 encoded), not even with HW acceleration. Afaik even 2D is often HW accelerated and without a real working driver, these things can slow down even fast hardware. Flash (Youtube streaming(!) is important to me) is bad on the Pandora, html5 afaik not even really existant, at least not faster than flash (videos).

It's true, I don't do 3D stuff at my Pandora at the moment but even 2D stuff is so slow, games are actualy the fastest apps on my Pandora, browsing, "desktop stuff" not really, evan an simple desktop menu takes many seconds to load -WTF?!? This plus my slow WiFi let me wait until it's proven that the (final) Pyra rally can stand all the stuff that was slow onto the Pandora.

 

[WizardStan]

On my Pandora I can't watch anything that is .mkv (mostly h.264 encoded), not even with HW acceleration.

This is a decoding problem, nothing to do with the display driver. It can put the images to the screen fast enough, uncompressing the video is the hard part. There is no hardware acceleration, it is all CPU. 480p is the max resolution I've found it can handle. You may be able to hit 720p with older codecs, like DivX/XviD.The Pyra won't have that problem because the CPU is much more powerful.

Again, this has nothing to do with hardware acceleration and the GPU driver won't have any impact on this.

 

[Exophase]

^ sounds like the 2D part is open source?

AFAIK the display controller part is, like on Pandora. And it's properly documented so it can be developed more by other people, to some extent.

I don't think the 2D accelerator part (Vivante GC320) is publicly documented or officially supported with an open source driver by TI, but the etnaviv project has reverse engineered it and written drivers for it for other SoCs. Another option is this library:

http://graphics.github.io/bltsville/

Which is supposed to supports GC320, not sure on the details.

EDIT: Looks like bltsville interfaces kernel support which is present:

http://processors.wiki.ti.com/index.php/GLSDK_Datasheet_OMAP5_6.03.00.01#GC320

bltsville is open source, and the kernel part has to be too so we should be set there.

3D performance looks satisfying in last years videos. Where's the big deal? Compared to the Pandora Pyra removes a lot of weaknesses and further improves the assets/strong points, and the Pandora is already awesome. I just don't see the need to complain and ruin the mood by posting you wont buy "her" until the OS is in good shape...  You don't have to. No need to tell everybody

The problem is that 3D driver only works on an (AFAIK very) old kernel and it's not going to work on the OS that the Pyra will ship with. From what I gather, the driver could be made to work with a new kernel if a userbase shim is written to bridge some changes in interface. But I don't know how realistic it is to find someone other than notaz who is capable of doing that (also he he will probably correct me if I got this totally wrong)

 

[EvilDragon]

The problem is that 3D driver only works on an (AFAIK very) old kernel and it's not going to work on the OS that the Pyra will ship with. From what I gather, the driver could be made to work with a new kernel if a userbase shim is written to bridge some changes in interface. But I don't know how realistic it is to find someone other than notaz who is capable of doing that (also he he will probably correct me if I got this totally wrong)

The kernel driver part is open and based on Kernel 3.8, so it could be ported to a more recent kernel.

What needs to be reverse engineered it a tiny binary blob that is needed to load the binary blob for use with the X-Server.

AFAIR, without X it works (which is how we ran it last year on GamesCom - by killing X and running it using the driver directly).

It might need an older omapdrm version as well, but that driver is OpenSource and could be fixed.

The more updated blobs we hopefully will get end 2015 / early 2016 should hopefully work with a more recent X, so that the driver should work without hacking.

We don't know yet whether TI will also offer a more recent kernel driver, but as that one is open, it can be ported to a more recent kernel from basically anyone.

notaz might correct me here, I'm not that tecchie, but I think that should mostly be it.

 

[WizardStan]

Wait, there's a proprietary blob for loading the proprietary blob? Well damn.

 

[_wb_]

Wait, there's a proprietary blob for loading the proprietary blob? Well damn.

There is a reason why the FOSS community doesn't like blobs. Before you know it, everything becomes blobbified.

 

[benoitb]

So the 3D driver would restrict the Xorg version but not the kernel version ? For me this is the main drawback of closed-source drivers: lack of ease of upgrade. It will be interesting to get Notaz's diagnostic here.

Just wanted to tell ED that the money for a Pyra preorder is already reserved on an account here. And I never owned a Pandora (did own a Sharp Zaurus and want the feeling again with current technology).

Also, will the 4G version of the Pyra be available at launch ?

 

[Exophase]

There is a reason why the FOSS community doesn't like blobs. Before you know it, everything becomes blobbified.

EDIT: I had a response here about pragmatism vs idealism in FOSS advocates. I must have been thinking this was the other thread which has already erupted into another code freedom argument. My bad, I don't want to turn this thread into that too.

 

[notaz]

The kernel driver part is open and based on Kernel 3.8, so it could be ported to a more recent kernel.


What needs to be reverse engineered it a tiny binary blob that is needed to load the binary blob for use with the X-Server.

"Tiny" blob is needed for any 3d to work at all.


For X support there is another large blob that is tied to specific old X version and was dropped completely by TI in "latest" (2013) driver release. That's not surprising as people who tried TI's Ubuntu 12.04 release reported it's extremely unstable, so instead of fixing it they just dropped all support. It's very unlikely we'll ever have 3d working under X.

AFAIR, without X it works (which is how we ran it last year on GamesCom - by killing X and running it using the driver directly).

That's what we'll always need, but we can probably avoid killing X, like we do on pandora now (if you install newer driver, X / windowed 3D doesn't work but we can keep X in background while 3D takes the whole screen).

The more updated blobs we hopefully will get end 2015 / early 2016 should hopefully work with a more recent X, so that the driver should work without hacking.

Still I think it's extremely unlikely anything will come out of that...

 

[Exophase]

"Tiny" blob is needed for any 3d to work at all.

This still needs to be done for current kernels, right? If so, is there any more information you can give that could help others get started on working on this? That is, if you don't plan to do it.

Inability to use 3D windowed is a shame but probably not a huge loss for most people.

 

[zz]

Aren't most 2D apps/games rendered through 3D these days anyway? or is GLES still available without the 3D driver?

 

[TrashyMG]

Wait, there's a proprietary blob for loading the proprietary blob? Well damn.

 
There is a reason why the FOSS community doesn't like blobs. Before you know it, everything becomes blobbified.

I know one boy who likes blobs...

 

[FaeMinx]

^ I saw that one coming a mile away.

 

[EvilDragon]

Inability to use 3D windowed is a shame but probably not a huge loss for most people.

I can't think of any reason to run 3D windowed on the Pyra.

Most people think of Blender, but Blender actually runs in fullscreen and has their own windows setup  

The kernel driver part is open and based on Kernel 3.8, so it could be ported to a more recent kernel.

What needs to be reverse engineered it a tiny binary blob that is needed to load the binary blob for use with the X-Server.

"Tiny" blob is needed for any 3d to work at all.For X support there is another large blob that is tied to specific old X version and was dropped completely by TI in "latest" (2013) driver release. That's not surprising as people who tried TI's Ubuntu 12.04 release reported it's extremely unstable, so instead of fixing it they just dropped all support. It's very unlikely we'll ever have 3d working under X.

AFAIR, without X it works (which is how we ran it last year on GamesCom - by killing X and running it using the driver directly).

That's what we'll always need, but we can probably avoid killing X, like we do on pandora now (if you install newer driver, X / windowed 3D doesn't work but we can keep X in background while 3D takes the whole screen).

Ah, thanks for clarification. I thought even the fullscreen driver uses X, that's what I misunderstood then. 

The more updated blobs we hopefully will get end 2015 / early 2016 should hopefully work with a more recent X, so that the driver should work without hacking.

Still I think it's extremely unlikely anything will come out of that...

Why not? Those processors from TI are new, and we already used SGX blobs from different systems (like the N900) on the pandora as well, haven't we?

 

[pmprog]

but we can keep X in background while 3D takes the whole screen

When you say this, will it be like the Pandora where it's stuck at 800x480, or will we be able to set the resolution? ie, in Allegro, if I try and create a 320x200 res window, it will fullscreen, and stick me in a corner (or is this more something to do with the Allegro build?)

 

[ptitSeb]

Most of my port do runs with the "FrameBuffer" mode, i.e., without X, so we can leave without 3D in X. There are a few exeption, but I guess some work around can be found (for the virtaulJaguar I may have to develop a simple SDL,it may be more tricky for Stellarium, but a solution might exist, using offscreen rendering).