The long journey towards a working display

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:
Good stuff, thanks for the continued updates.

ED, you have a really high frame rate camera, right? Would it be possible to at some point capture 60Hz or higher video of something with a lot of motion and contrast? Like Sonic or Bonk's Revenge emulated.
 Yes, that would be pretty cool, a ghosting comparison between the Pandora and Pyra screens!

The resolution is insane, if you wouldn't know better you could think it's a 21" monitor on those pictures :)
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.
Good news.

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.
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.
Last edited by a moderator:
1920 x 1080 operations ~= 2000k operations

800 x 480 operations ~= 400K operations

Means 5 times the overhead for scaling, rotations and flipping.
Last edited by a moderator:
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.
Last edited by a moderator:
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. 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.
Last edited by a moderator:
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.
Last edited by a moderator:
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 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.