Re: Missing vsync support in Vivante drivers

[Carlos Rafael Giani <dv@pseudoterminal.org>]

On 2014-03-19 01:26, Eric Nelson wrote:
> 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
> customer.
>
> 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.
>
> http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/tree/drivers/video/mxc/mxc_ipuv3_fb.c?h=imx_3.0.35_4.1.0#n862 
>
>
> 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:
>     http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/tree/drivers/video/mxc/mxc_ipuv3_fb.c?h=imx_3.10.17_1.0.0_beta#n870 
>
>
> You can see this at run-time by looking in
> /sys/class/graphics/fb0/virtual_size.
>
>     # cat /sys/class/graphics/fb0/mode
>     U:1280x800p-59
>     # cat /sys/class/graphics/fb0/virtual_size
>     1280,800
>
> 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.
>
> Regards,
>
>
> Eric


Hello Eric,

are there any updates on this? With the Weston imx patches, tearing-free 
X11 is less urgent, but still very welcome, and some installations just 
absolutely need X11.

Carlos