Not everything is as fast as planned


maybe a good idea to go to greece and visit them anyway? Chill out, drink some Ouzo with them...may speed up things ;)
 
I hope the rotator actually works eventually. I can't imagine anyone would manufacture something that difficult to use!
 
Well, the question is not 200 or 300 but 1000 or 2000 :)


Sadly, not possible to get them yet, they are still working on the details.


So the first 1000 will have the current LCD for sure.



So, it sounds like your first batch is 1000.


At this point I think it would be very cool if you could get a video of a single unit booting and running on battery in a stand alone case before the end of the year.  That is a milestone that I've been looking forward to.


Everyone on the prototype and pre-pre-order should be fully aware that delays will happen at this stage in development.  None of them should be surprised.


IMHO 1000 sounds like a 'sweet spot' in the quantities.  20 or so prototypes, 200 pre-pre-orders leaves 780 - failure rate from 1000 units ~ -150 estimate, so 630 as a 'First Batch' pre-order.  Something in the range of 50% down up front would not be out of line.


That brings up another bit though.  Before taking the general 630 +/- more general type pre-orders, an actual retail price should probably be established.  It can be raised or lowered later, but remember from Pandora that it's easier to go down in price than up.
 
I had one of their computers. And I like their calculators. But I mean, why is this chip so much trouble? Is it that difficult in general, or is it our specific case?
 
I had one of their computers. And I like their calculators. But I mean, why is this chip so much trouble? Is it that difficult in general, or is it our specific case?



It's a pretty specialized piece of kit.  What other product(s) is it used in?
 
I hope the rotator actually works eventually. I can't imagine anyone would manufacture something that difficult to use!


It isn't complicated for use, the rotator works fine. Only sync is missing, but that's because we use MIPI in video stream mode whereas the sync-signal is only used in MIPI command mode.


That's a MIPI standard, not the fault of the rotator chip.
 


Unfortunately, Linux is not yet suited to use the command mode.


Command Mode basically is smarter: It doesn't send a constant video stream but only streams frames when the screen is updated. This saves power and works fine if you got something like Android, where the system handles all that.



It's perfect for smartphones which often simply show the same screen.



The rotator chip then sends a sync signal to the OMAP to let it know when to send the next frame and it's synced.



However with Linux, where different apps use different ways to access, each app would need to be changed so that it let's the command mode driver know that the screen content changed.



This is not really a feasible option, therefore, we need to work with the video stream driver.



There are multiple possible workarounds:


* Change the command mode driver and force it to update every frame, so that it behaves like the video stream driver.


* Configure the OMAP5 to wait for the sync signal once and then start the videostream (right now it simply starts the stream whenever you tell it to)
 
Last edited by a moderator:
So will the portrait displays with the rotator still work well, or will it be more worth it to wait for the models with the landscape displays? My main concern is battery life.


Also, when you mention about doing a pre-order, this is not for people who already preordered and have a voucher already, right?
 
* Configure the OMAP5 to wait for the sync signal once and then start the videostream (right now it simply starts the stream whenever you tell it to)


If you do something like this you should measure the interval between several sync signals and calibrate a timer to match this. Otherwise the difference in clocks will cause too much drift and eventually you'll fall out of sync. This method will still cause drift but it can possibly be mitigated to where it only becomes an issue after the unit is on for days or weeks. Maybe you'd need to occasionally try to resync.


That is, unless the OMAP5 and rotation chip have the same clock source (seems unlikely?)
 
notaz said:
15 minutes ago, notaz said: This delay should be used to check if we may get the portrait LCDs (you mentioned there might be a possibility for that), the rotator is a major software headache and we still basically don't have it working properly.
How did we do that on the pandora?
At pandora, there was already a portrait Display which dosnt neede a rotator ship


These smartphones are the cause everyone is making a non portrait display..
 
There are multiple possible workarounds:


* Change the command mode driver and force it to update every frame, so that it behaves like the video stream driver.


* Configure the OMAP5 to wait for the sync signal once and then start the videostream (right now it simply starts the stream whenever you tell it to)

Can the rotator chip be configured to generate the TE (tearing effect) signal on vsync? According to this PDF the OMAP can be configured (3.1.2 CMOS TE line) to send video data when triggered by the TE signal from the panel. If rotator chip can generate that signal then that would fix the issue, I think.


cmos_te_line.png


Of course, that PDF is all the knowledge I have about MIPI, so probably I'm talking nonsense. :lol:
 
Last edited by a moderator:
This delay should be used to check if we may get the portrait landscape LCDs (you mentioned there might be a possibility for that), the rotator is a major software headache and we still basically don't have it working properly.

I thought that issue was already fixed, hmm, bad news. But I always had the feeling that it will not really work when so much effort has to be put into an "simple" task to just rotate an screen output 90°...
default_ph34r.png



Maybe it would be the best if the Pyra just use the standard methods to rotate the screen, i'm sure the OMAP has a HW function for that without needing to much CPU power. Every phone can do it.
 
Last edited by a moderator:
Maybe it would be the best if the Pyra just use the standard methods to rotate the screen, i'm sure the OMAP has a HW function for that without needing to much CPU power. Every phone can do it.

The GPU does, but like stated long ago we don't want to be running the GPU 100% of the time. which why Nikolaus and EvilDragon planned on using the rotator chip. 
 
It should not eat that much GPU power I hope. Better than nothing if nothing else will work.


Hm, let's hope there will be more landscape mode screens available soon, now that VR glasses come out of the shadows...
 
Last edited by a moderator:
Thanks for the update ED. The problem with the case doesn't seem that relevant, just a small delay.


The rotator chip on the other hand worries me a lot. What if there is no way to solve make it work properly? Is there a plan B. How usable is the device bypassing the chip?
 
Thanks for the update ED. The problem with the case doesn't seem that relevant, just a small delay.


The rotator chip on the other hand worries me a lot. What if there is no way to solve make it work properly? Is there a plan B. How usable is the device bypassing the chip?



IMO the best alternative short of getting an actual proper landscape LCD (seems unlikely) is using the 2D accelerator to perform acceleration.


According to slaeshjag there's work that needs to be done getting the necessary kernel module ported to Pyra: https://boards.openpandora.org/topic/18156-how-to-get-rotation-working/?page=3#comment-392463


If this is made to work it'd be in a user space library, so I have no idea how it'd apply to X for example, or what the implications would be for using omapfb directly.
 
Last edited by a moderator:
Can anybody explain me a little deep what's the actual state of the rotator chip and what's about that "alternative" LCD? Thank you in advance.
 
Last edited by a moderator:
Back
Top