[meta-freescale] Missing vsync support in Vivante drivers

Eric Nelson eric.nelson at boundarydevices.com
Tue Mar 18 17:26:53 PDT 2014

Hi Carlos,

On 03/18/2014 02:39 PM, Carlos Rafael Giani wrote:
> Hello,
> in the past, there has always been a problem with vsync, OpenGL ES
> output, and X11. Very noticeable tearing affects all such applications.
> So far, neither Vivante nor Freescale have ever commented on this. Is
> there anything known? Should the newest drivers fix this?

You have odd timing. I was just looking into this today for a

In our kernels and the Freescale kernels. there seems to be an
issue with the default allocation of the frame-buffer, such that
only space for  a single buffer is present.


Without a larger allocation, I don't think the frame buffer
driver has any way of swapping cleanly at vertical sync.

The 3.10.17-beta kernel seems to do the same thing:

You can see this at run-time by looking in

	# cat /sys/class/graphics/fb0/mode
	# cat /sys/class/graphics/fb0/virtual_size

You can also alter things by using sysfs:
	# echo 1280,1600 > /sys/class/graphics/fb0/virtual_size

After changing the size, the FBIO_PAN ioctl does the right
thing. i.e.:

	variable_info.yoffset = x;
	err = ioctl(fdfb,FBIOPAN_DISPLAY,&variable_info);

And you can see the same thing using /sys/class/graphics/fb0/pan.

It's not clear to me who should be doing this though.

In an X environment, I would expect this to be controlled
through xorg.conf somehow, but my attempts to get fbdev
and shadowfb proved fruitless.

I haven't had a chance to look into the Vivante X driver
and I'm not sure where the OpenGL stack this should be
performed, but since the timing really has to be coordinated
by the frame-buffer, there should be a call somewhere.

In my immediate customer case, using the frame buffer calls
directly is sufficient.



More information about the meta-freescale mailing list