Spanning GUI over multiple framebuffers

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Spanning GUI over multiple framebuffers

Jump to solution
3,502 Views
danielleloader
Contributor III

We have a Qt 5 application running on our iMX6 Quad which we want to span multiple screens but we do not want to use multiple Qt windows.

For this I believe Qt needs to be provided with a single large framebuffer which we would then need to split up and write to the individual output buffers to achieve the extended display.

The two displays we’re using are the same size (10 inch 1280x800) and placed horizontally adjacent. One is driven by DISP0 (parallel LCD output) and the other is driven by LDB1 (LVDS output).

Has anyone else achieved this set-up without a window-manager and windowed application? We want to take advantage of the GPU’s hardware acceleration, is this possible using a single virtual framebuffer? Or should we be looking at a different solution?

Thanks

Dani

Labels (4)
1 Solution
1,766 Views
smspatrick
Contributor III

First solution:

Change this framebuffer:

Virtual Framebuffer Driver

To produce three different vfb sharing the same physical memory, but with different resolutions, offsets and strides (left and right boarders)

it is 1280*2 x 800 x 3 x 4(3) Bytes large (double view, tripple buffered, 4(3)Bytes per Pixel), take care to span the base resolution before to the next multiple of 32, 1280x32 is OK, some special gpu maybe need multiple of 64)

The first one has zero offest and stride and will be used by qt as the rendering surface (something like this:

eglCreateWindowSurface(eglDisplay, eglConfig, vfb_id, NULL);)

where vfb_id is the integer file id after loading.

The second and third one has a stride of half horizontal reslution and zero(for the left) and 1280(for the right) offset. Pass these two vfb's to the displays (don't know how to exactly do that, but the linux framebuffer system is capable of handling this)

There can also be some issues during the non-sync behavior of all three vfbs and the gpu buffer swapping. (I use the tripple buffer since normal double force most egl-settings to forward copy and prevent efficent swaps)

Another solution, but there could be some performance issues:

A large 2560x800 FBO as rendering surface for qt, and at a last pass: rendering the FBO as Texture to both displays afterwards (only use left or right half, use GL_NEAREST for better performance and sharpness for the testure setup). This should work, as long as the gpu supports such large textures.

Hope some of the ideas might help.

View solution in original post

4 Replies
1,767 Views
smspatrick
Contributor III

First solution:

Change this framebuffer:

Virtual Framebuffer Driver

To produce three different vfb sharing the same physical memory, but with different resolutions, offsets and strides (left and right boarders)

it is 1280*2 x 800 x 3 x 4(3) Bytes large (double view, tripple buffered, 4(3)Bytes per Pixel), take care to span the base resolution before to the next multiple of 32, 1280x32 is OK, some special gpu maybe need multiple of 64)

The first one has zero offest and stride and will be used by qt as the rendering surface (something like this:

eglCreateWindowSurface(eglDisplay, eglConfig, vfb_id, NULL);)

where vfb_id is the integer file id after loading.

The second and third one has a stride of half horizontal reslution and zero(for the left) and 1280(for the right) offset. Pass these two vfb's to the displays (don't know how to exactly do that, but the linux framebuffer system is capable of handling this)

There can also be some issues during the non-sync behavior of all three vfbs and the gpu buffer swapping. (I use the tripple buffer since normal double force most egl-settings to forward copy and prevent efficent swaps)

Another solution, but there could be some performance issues:

A large 2560x800 FBO as rendering surface for qt, and at a last pass: rendering the FBO as Texture to both displays afterwards (only use left or right half, use GL_NEAREST for better performance and sharpness for the testure setup). This should work, as long as the gpu supports such large textures.

Hope some of the ideas might help.

1,766 Views
danielleloader
Contributor III

Patrick,

Thank you very much for your suggestions. They are similar to what we expected and I think they will help us.

I will update on our progress.

Danielle

0 Kudos
Reply
1,766 Views
pj0585
Contributor III

Hi Danielle,

Were you able to do the steps that Patrick describes ? Did the trick work for you?

I'm also stuck at a similar point. I have a vague idea of what Patrick is suggesting but not sure how to do it. If you have successfully implemented it then could you help me with the steps?

-Pj

0 Kudos
Reply
1,766 Views
danielleloader
Contributor III

Hi Pj,

Sorry I did not see your post, I didn't get an email notification from Jive.

Did you manage to implement your own solution in the end?

Dani

0 Kudos
Reply