On 03/31/2014 12:26 AM, Dr. H. Nikolaus Schaller wrote:
Am 30.03.2014 um 23:07 schrieb Michael Mrozek:
Am Sun, 30 Mar 2014 23:39:42 +0300 hat Grazvydas Ignotas grazvydas.ignotas@openpandora.org geschrieben:
Hi,
So I would not give up too fast. Saving a chip and reducing maximum resolution IMHO warrants investing some more time into potential software issues...
I'd much prefer the chip and lower res, all the above problems would just go away. That LG screen is clearly an overkill for me.
Same here - if the FullHD screen only works with a lot of issues and use a lot more battery due to performance needed, then that's really bad.
The Pandora has an awesome battery life and it often feels faster than a dualcore Cortex A9 phone, because it's pretty optimized.
These optimizations as well as the battery life is something I want to see on the Pyra as well.
So if TILER can't be used in an efficient way, then we need to change our plans.
Also, is users install standard SDL programs using the Debian Repo, or run a different distribution, all SDL programs will run in portrait mode...
Unless the TILER is set up in kernel and invisible to user space. I am not yet convinced that this is impossible.
For X apps it can be invisible since xf86-whatever driver does the buffer setup, but there is always extra copying involved for app to display something on screen through X, and that is slow.
For direct access it can't be invisible without extra overhead for hidden copies, because of the page format that TILER needs. However it's possible express something that matches TILER's page format in things like SDL and programs that don't assume linear buffer will work.
I'd say right now the main issues now are slowness and read failures; I could only reach 16fps for fullhd drawing while rotated, which is way below 60fps. Without rotation same code can do over 130fps..
Regarding SDL (I have zero experience with that). How do they access the frame buffer? Like Qt? I.e. query the /dev/fb for properties and then map to user space and write the bits directly?
It's more or less like that, yes, however you can't use the scalers through /dev/fb any more since omapfb driver was replaced with DRM based omapdrm. DRM also provides /dev/fb but the functionality is very limited, so DRM API has to be used, which means SDL will have to be rewritten/ported in either case.
Grazvydas