At least an automatic rotate mode can probably be coded inside glshim. It will handle the display then (and automatically turn off rotator at load and on at exit, using a environement variable). The mouse will still need to be handled by the game (invert X / Y), but that's a start.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.
That's the one where each program needs to send a command to update the screen.EvilDragon said:2 hours ago, EvilDragon said:
Well, I know there's a driver for the OMAP2+ DSS that supports command mode:
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...
Unless...At least an automatic rotate mode can probably be coded inside glshim. It will handle the display then (and automatically turn off rotator at load and on at exit, using a environement variable). The mouse will still need to be handled by the game (invert X / Y), but that's a start.
Yes, when the display is directly connected to the SoC. This also works without any issues.EvilDragon said:10 hours ago, EvilDragon said: 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...
I don't want to belabor this point too much, but most displays synchronize on their inputs, not the other way around. And there are actually some good reasons for this. If the same clock domain controls the display controller, processor, audio etc it's a lot easier to keep these things synchronized without worrying about time shifting anything or checking synchronization.
With all respect, but you're confusing ultimatums with options. Respect for others opinions and options should remain, lets not slide to the cheap insult here.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.
Finding good developers is the challenge then, wasn't there some bad experiences during the Pandora development?Well, once the Pyra sells, there is money coming in which can be used to pay some fulltime development. That's what I plan. The better it sells, the more money is available for that.
And that's what really matters.The device is already fully usable, even if you have tearing until the software solution is found.
Exactly, just like with the CPU/SoC board, good modular designs open up a lot of possibilities, which is why I will be more than comfortable to go for a first run Pyra. I wish to support this project any way that I can.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.
I full heatedly believe that this is a project that is well worth being behind. Obviously with the world as it is it's hard for things to always go perfectly and it's absolutely amazing just how well things have been going thus far with this project. There's a lot of people that just need to step back and take a good deep breath.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?
Can you ask them? As long as your project is not directly competing with theirs, they should be able to help.What I'm asking myself though is... there seem to be others who have used command mode panels with Linux.
Here is an example panel driver (command mode) in use with the OMAP:
How did they solve the issue with the non-updating signal? I can't imagine they recompiled all of the Linux apps to work with command mode.
What's the trick here?