EGL windows not respecting overscan

[adam.biltcliffe]

I am working on a Python library for 2D sprite-based games (pygame's lack of hardware acceleration on the pi being a dealbreaker in this regard and pyglet not currently supporting OpenGL ES).

At the moment my surface creation code is based on the examples in /opt/vc/src. However, while experimenting I have found that the EGL/dispmanx code used in hello_triangle and hello_dispmanx does not seem to respect the pi's overscan settings. While the console and X both seem to respect the settings in /boot/config.txt (easily verified by setting a very large overscan value), the display surfaces I am creating (and those created by hello_triangle et al.) seem to occupy the whole of each scanline.

Is there any way to ensure that surfaces are created with the appropriate size?

[dom]

The overscan settings from config.txt just apply to the standard framebuffer.
Anything created through dispmanx (e.g. Video and EGL overlays) do not consider the config.txt overscan settings.

You can compensate for overscan yourself, by altering the dispmanx dest_rect.

I'll have a think about whether I can apply the overscan settings to all dispmanx objects in a way that's not too ugly.

[adam.biltcliffe]

Is it possible to determine from the framebuffer how much overscan was applied, so that I can apply the same myself? (X respects it, so must have some way of doing this, right?)

[dom]

Is it possible to determine from the framebuffer how much overscan was applied, so that I can apply the same myself? (X respects it, so must have some way of doing this, right?)

X directly uses the same framebuffer as the console, so doesn't have to care about it.

You could use the "Get Overscan" property from here:
https://github.com/raspberrypi/firmware ... -interface

[adam.biltcliffe]

You could use the "Get Overscan" property from here:
https://github.com/raspberrypi/firmware ... -interface

Thanks, that looks like exactly what I was looking for.

Do I take it there is no C API for accessing the mailboxes?

[dom]

Do I take it there is no C API for accessing the mailboxes?

No, it is really designed for kernel drivers and bare-metal OS.
Because it requires writes to peripheral registers, it really needs either a kernel driver, or a "mmap" hack.

See vc_mem_update from:
https://github.com/raspberrypi/linux/bl ... 8/vc_mem.c

for an example of using the mailbox channel from a kernel driver.

But you might be better off waiting to see if I do the dispmanx overscan hack.
Or even better, find how to disable overscan on your TV.

[adam.biltcliffe]

Ok, thanks anyway. I can disable overscan on my own TV no problem, I'm just worried about causing unexpected behaviour for users who are happily using the default overscan settings on their own TVs and won't be aware of what causes the issue.

[dom]

There's an experimental feature in latest firmware.
overscan_scale=1

means that all dispmanx layers are scaled, including EGL and video.

[milhouse]

There's an experimental feature in latest firmware.
overscan_scale=1

means that all dispmanx layers are scaled, including EGL and video.

This feature works a treat and is essential for overscan settings to be respected by XBMC (in my case OpenELEC). It does however need to be documented in the Wiki (I see account registration is disabled...) otherwise XBMC users might think the overscan config.txt options are not working...