Discussion in 'Pyra News' started by EvilDragon, Mar 7, 2014.
I can't do more pictures yet, I need the adapter PCB
It looks great and I like such in deep "how to" storys. ^^ There must be an Book: "Making of Pyra".
The screen seems to be really high res, what tiny fonts it produces! I guess I will need better glasses to read anything on it. Of course you can zoom every browser but the only Browser that can zoom a page without making the actual browser Window bigger was the classic Opera. (It can re-format an webpage to always fit onto the screen, no matter how big the font is or how much you zoom in, great invention! B) )
For Pyra Desktop Usage it seems we will need Icons with at least 48x48 Pixel, my "graphical view" onto things is already in action. :lol:
Wonderful! Now let's see a red and white chequered ball bouncing around that screen
Hold it 3" from your face and wear these - instant 50" monitor effect...
Yes, that is a joke.
Only because no one has posted it yet.
It's amazing how some constructors don't want us to use their products.
So I just noticed something. This will have the same problem as the shield. The screen is portrait and your mounting it in landscape so everything is going to need to be rotated 90 degrees. I had to scrap a project I was working on because it wasn't using x11 and I couldn't find a easy and efficient way of rotating everything. Did the Pandora have this same issue/setup? If a solution similar to not using x to rotate is found would you guys mind sharing this info?
On pandora, you can rotate the framebuffer via the framebuffer hardware that the OMAP has. Same hardware that does the scaling and overlays.
The OMAP5 features multiple framebuffer and scaling hardware.
We're trying to include the rotation lowlevel in the kernel, so that it will be a 1920x1080 screen for Linux.
It's unclear how well it'll work though, especially on this insane resolution..
What do you call insane?
Didn't you notice the 4K displays advertised everywhere?
Who cares about full HD any more?
(At least we're better than the iPhone )
There's a magnitude more pixels than the Pandora being flipped 60 times a second. That's a lot of overhead. That's also the problem with the shield. If dedicated hardware exists with drivers to use it it may not be that big a deal.
1920 x 1080 operations ~= 2000k operations
800 x 480 operations ~= 400K operations
Means 5 times the overhead for scaling, rotations and flipping.
Hardware scaling and rotation. No overhead.
Yep, that's also the reason we should test this as soon as possible - so in worst case, we can switch to a different display.
If we can get that hardware rotation working working well, it should also be possible to offer different resolutions in Linux (like 1280x720) and the hardware will scale it to the displays resolution.
It seems the OMAP3 can do this:
So it should be possible somehow with the OMAP5 as well.
And it seems to work with a simple argument...?
xrandr --fb widthxheight
Reconfigures the screen to the specified size. All configured monitors must fit within this size. When this option is not provided, xrandr computes the smallest screen size that will hold the set of configured outputs;
this option provides a way to override that behaviour.
I dont see how this is a performance hit.
As for scaling, hardware scaling 1920x1080 down to 1280x720 produces pixelmapping errors fullscreen. Instead try to adjust the DPI setting to something that fits a multiple of a perfect alignment.
http://askubuntu.com/questions/197828/how-to-find-and-change-the-screen-dpi was a nice explanation of how.
Also could take a real closeup of the pixels to see how the rgb is arranged, which can be set accordingly. Xfce has that built into the panel settings.
Colour calibration is also possible, one of the benefits of not running android or iOS.
Xrandr doesn't help if we don't support that in the low level hardware - as the only resolution usable would be 1920x1080.
I know 1280x720 is not proper integer scaling to 1920x1080, it was just as an example (and I'm not sure if you could see the scaling artifacts with such resolutions anyways)
DPI setting helps making the text and icons of the desktop more readable by increasing the size, but it won't increase the rendering speed.
If the low level driver would do that with a hardware scaler, X and programs would render at a lower resolution which uses less CPU.
xrandr can have a huge performance hit, that's not how you want to handle rotation.
According to the OMAP543x TRM it uses "TILER" like OMAP4, there's no VRFB (section 10.2.4.7). Hopefully the OMAP4 TILER kernel support will be sufficient for it.
Well, it seems to be possible to test using a bootarg.
The OMAP5 has been created with FullHD displays in mind, so hopefully it should be enough.
Will test when I get the adapter next week.
Separate names with a comma.