Not everything is as fast as planned

[hns]

Which means the rotator is basically unusable in the video mode, I don't see how you can say it's not a fault of that chip. It could've provided some way to sync to the video stream but it does not. The only way to use it is the command mode, but OMAPs have no drivers for that (Nikolaus has another solution, see below, but I'm a bit skeptical).

It is difficult to find out whom to blame: the rotator chip that it can't sync on the vsync embedded in the incoming video stream in video mode or the omap5 dispc not being able to sync to an external vsync input (which the rotator provides) in video mode. So probably both are broken. Anyways, it does not help to find who should have done better, unless we find anyone (or anychip) who really does it better... In other words: we have to live with the hardware as it is (today).


My approach is indeed very old fashioned... TV sets from the '50ies did it that way to sync the vertical retrace of the electron beam to the incoming sync impulses. So it is probably too much vintage for today's digital technology that we do not believe that it can work before it is demonstrated 


But for the moment I am going back to fix issues with U-Boot / MLO.


Just to tell the story: I did use a precompiled U-Boot binary from 2013 on the EVM and prototypes so far. Now, for the new CPU board we have to change the pin multiplexing for the boot console to two different pins because they would conflict with the seconds SD slot signals. No big problem - except that U-Boot has completely changed the default environment parameters (from boot.scr to uEnv.txt, from uImage to zImage etc.). So this is the bigger problem - making Linux boot again... MLO/U-Boot already respond - but can't load the Linux that did boot this morning...


Issues like these are very time consuming for apparently easy tasks.

 

[Rockthesmurf]

Threads like this make me realise how little I know about electronics and Linux (vs software running on top). The rotator chip problem does seem like an interesting issue to solve but certainly out of scope for me.

 

[Wrath Of Khan]

I'll bet we will get there in the end, some genius will figure it out. Yes, Pyra will ship with imperfect software, its to be expected.


Should be much better than when the original pandora launched though, I'm guessing.

 

[fusion_power]

It is not a matter of "if" it can be fixed, it is a matter of "when".

That sounds better.    At least better than the other way round: time is there but it is not possible at all.  


I really thought, simply switching X and Y coordinates in the LCD image build up process is enough to make a landscape screen out of an portrait screen... 

 

[Not_a_Nick]

One thing is selling and shipping a product that everyone knows will be in construction software wise, but shipping something crippled by hardware i think it's a little more serious. Rather have everyone take their time and make sure it's eventually fixable in it's current state. The cost of the product isn't necessarily the one of a cheap toy and not everyone is technically prompt to the kind of prowess required to solve those kind of issues.

 

[comradekingu]

How does the Smach Z approach this particular issue then ?

Good question, I asked them. From their video they have a panel that doesnt appear to be connected at the side. It has the cable going in the top and a connection on the bottom.


However it may be that its just something they have hooked up to their otherwise dev-board setup.


I know ks requires functional prototypes, but it seems a devboard setup is all it takes(?)


Update: No answer, but they did fix the dead link i pointed out, and supplied a working one in the reply.


Update2: "The display is 5" with a capacitive touch panel of 10 Points and OLED technology. But the exact model it's to closed yet."

 

[erico]

Well, for the first batches, while a solution for the rotator is being hunted/developed, hardware rotation could do just fine right? Even if it sucks a bit more battery.

 

[mclien]

Well, the question is not 200 or 300 but 1000 or 2000

I might be over-optimistic, but perhaps waiting until after 32c3 might influence that a bit? (at least I hope for that...)

 

[ZXDunny]

I'll be waiting until the faulty first batch have all been sold before I order one, it would appear


D.

 

[Not_a_Nick]

I'll be waiting until the faulty first batch have all been sold before I order one, it would appear


D.

Guess i'll jump in that train of yours

 

[Wrath Of Khan]

What exactly is faulty about the first batch? Nothing yet that I'm aware of.


The possibility of using another screen in the future has been mooted but nothing concrete, as of yet.


Unless the rotator chip is significantly problematic, but we don't yet know the outcome of that.


I'll wait and see what Nikolaus and or notaz can do to fix the issue first.


We don't have a prototype yet so there's still kinks to work out. I'll wait and see. 


I'm confident a workaround will be found though.

 

[EvilDragon]

I'm taking about a delay in delivery, because of software not being ready yet to accommodate Vsync and ensure the first Pyra owners do not suffer from this ? It does not seem Notaz was very confident it could be fixed easily based on his post on this thread.

The device is already fully usable, even if you have tearing until the software solution is found.
The WIZ had the same issues. The Pandora had a lot of non-working things in the beginning.


Heck, a lot of XBox360 games have horrible tearing as they disable VSync completely to gain speed.



And I still see tearing on a lot of PC games...


So what would the reason be to delay here?

How does the Smach Z approach this particular issue then ?

Who knows. Probably using the GPU.

Which means the rotator is basically unusable in the video mode, I don't see how you can say it's not a fault of that chip. It could've provided some way to sync to the video stream but it does not. The only way to use it is the command mode, but OMAPs have no drivers for that (Nikolaus has another solution, see below, but I'm a bit skeptical).

The rotator follows the MIPI specs, which only have a tearing fix for command mode. That's more the fault of the MIPI specs and not the chip.
Yes, it's annoying that it can't simply use the video input timings, but you could also say it's annoying that all SoCs ignore the anti-tearing signal when run in video mode...


Well, I know there's a driver for the OMAP2+ DSS that supports command mode:


http://lxr.free-electrons.com/source/Documentation/arm/OMAP/DSS
 


Not sure how much that would work with omapdrm (I still haven't really understood how omapdss and omapdrm go together).

But with the release of the AM-Series which are using basically the same DSS as the OMAP5, chances are high there'll be a command mode driver available.

If there is nobody to work on that software update it is, don't you think?

Then I'll hire one. I've said that multiple times, haven't I?


At least two who want to fiddle around with low-level stuff will get a devboard.


About the possible landscape display notaz mentioned:


ZBOE might have a 5" landscape display available at some time. It was planned to be available sometime in April, but as it looks now, it might be end of next year IF it will ever be available...


Then we wouldn't have any issues.


But waiting for that would be crazy - as I'll probably run out of money at some time, waiting won't improve the specs of the Pyra and it could also be some crucial parts like the OMAP5 might not be available anymore.


So we can wait until the project dies because something like this happens or create a working hardware with some tearing issues on fast movements, but prepared so they can be overriden (when using the GPU) or fixed as the hardware is connected and software ideas to fix it exist already.


And if such a display EVER appears, the old units can be upgraded - we're modular, all you'd need to do is to replace the display PCB and the LCD and that's it.


What would you all prefer?


Should I now stop with everything, probably file for bankruptcy in a while (unless the magical hardware fix that needs no software work appears suddenly) or continue finishing the unit?

 

[txus]

What would you all prefer?


Should I now stop with everything, probably file for bankruptcy in a while (unless the magical hardware fix that needs no software work appears suddenly) or continue finishing the unit?

Damn, that's one tough decision you offer... But after giving it a lot of though, I think I'll go with option number 2.


ED, the Pyra is awesome as it is, and you and the rest of the team are doing an amazing job pushing this project forward. Go team! You are almost there!


And to those who say "I'll wait for the second batch/version/whatever", please rethink that. There will ALWAYS be something better waiting in the future, specially with electronics, and in this case the more successful the first batch is, the more possibilities of a better future version there are (or even a future version AT ALL). And like ED said, in case you want to upgrade, in the case of the Pyra you don't need to buy a complete device, just the desired module or part.

 

[elvissteinjr]

Don't forget that the screen is also an easily replaceable part later thanks to the display pcb. Upgrades there wouldn't be impossible later on.

 


Regarding bypassing the whole rotation deal in OpenGL applications, how would one do that in the most transparent way?
One could rotate the matrix, but my code uses glLoadIdentity() quite a bit. Render to texture would also work, but is slow (I have no FBOs on 1.1, unless I'm missing something here).

It's certainly possible and actually no biggie for my own code. But it would be cool if the Pyra wouldn't need modified sources for almost every app like we did on the Pandora. So yeah, working tear-free rotation would be really neat. Tearing in games is a bit meh.

 

[levi]

Well, one way is to get the rotator chip to work.  Then you won't need to modify any GPU code to rotate a screen.


I for one am excited to get on board with this project as soon as it's properly released (dependent on funds).  It was hard to maintain the excitement during the long wait for my Pandora, and while the one I eventually got had more RAM, a faster CPU, and nubs that were only a little unpredictable, I still think I'd rather have experienced more of the journey first hand.

 

[Not_a_Nick]

And to those who say "I'll wait for the second batch/version/whatever", please rethink that.

Doing the black sheep role here, but those who say that, me included, actually think this product costs a lot of money that needs to be earned through work. Let's face it, it's a small luxury and not a priority, at least for me. Considering that, i'm sure a few hundreds and i hope thousands will jump right in and get theirs and support all the expenses that have been taken by the team involved in this and by ED as the main investor.


Personally rather wait and see the evolution of things and some standards met, which is natural that aren't the same for everyone.

 

[Wrath Of Khan]

So the screen can easily be changed too, very nice. I seem to have forgotten that fact.


The pyra is modular so we may have a back-up plan and can swap the screen if needed and if available.


I don't have a problem with it. I'm in for a first batch Pyra. 


It was fun to get in early with the pandora back in the day too, for me at least.

 

[Wrath Of Khan]

Doing the black sheep role here, but those who say that, me included, actually think this product costs a lot of money that needs to be earned through work. Let's face it, it's a small luxury and not a priority, at least for me. Considering that, i'm sure a few hundreds and i hope thousands will jump right in and get theirs and support all the expenses that have been taken by the team involved in this and by ED as the main investor.


Personally rather wait and see the evolution of things and some standards met, which is natural that aren't the same for everyone.

Fair enough. Your entitled to your opinion.


I don't think there will be any major problems. Software will be a work in progress of course.


I'm used to such a concept as I had a Pandora way back, so I consider it part of the fun.


Let's wait and see.

 

[notaz]

Well, I know there's a driver for the OMAP2+ DSS that supports command mode:


http://lxr.free-electrons.com/source/Documentation/arm/OMAP/DSS

That's the one where each program needs to send a command to update the screen.

(I still haven't really understood how omapdss and omapdrm go together).

omapdss is the low lever driver that doesn't do anything by itself, it's only used by omapfb and omapdrm to access the hardware.


omapfb and omapdrm are mutually exclusive, you either use one or the other.


A few weeks ago it was decided to merge omapdss and omapdrm and delete omapfb, so in some future kernel there will only be omapdrm and nothing else.

Then I'll hire one. I've said that multiple times, haven't I?

It was a response to Askarus' remark which made it look like software will write itself and is not important at all.

ZBOE might have a 5" landscape display available at some time. It was planned to be available sometime in April, but as it looks now, it might be end of next year IF it will ever be available...

That's bad news then, I can only hope somebody can get the rotator to work properly.

 

[Grench]

The only reason any of us know about prototype or beta level issues at all is because of the openness of this project.  Making buying decision ultimatums based on pre-prototype software status is a lot like loudly threatening to get off the bus at the next stop.


Ed, ignore the few fools trolling for your response.  Get back to work on those prototypes.