All of lore.kernel.org
 help / color / mirror / Atom feed
* Missing vsync support in Vivante drivers
@ 2014-03-18 21:39 Carlos Rafael Giani
  2014-03-19  0:26 ` Eric Nelson
  0 siblings, 1 reply; 3+ messages in thread
From: Carlos Rafael Giani @ 2014-03-18 21:39 UTC (permalink / raw)
  To: meta-freescale@yoctoproject.org

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?


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Missing vsync support in Vivante drivers
  2014-03-18 21:39 Missing vsync support in Vivante drivers Carlos Rafael Giani
@ 2014-03-19  0:26 ` Eric Nelson
  2014-05-01  9:50   ` Carlos Rafael Giani
  0 siblings, 1 reply; 3+ messages in thread
From: Eric Nelson @ 2014-03-19  0:26 UTC (permalink / raw)
  To: Carlos Rafael Giani, meta-freescale@yoctoproject.org

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


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Missing vsync support in Vivante drivers
  2014-03-19  0:26 ` Eric Nelson
@ 2014-05-01  9:50   ` Carlos Rafael Giani
  0 siblings, 0 replies; 3+ messages in thread
From: Carlos Rafael Giani @ 2014-05-01  9:50 UTC (permalink / raw)
  To: Eric Nelson, meta-freescale@yoctoproject.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


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2014-05-01 10:00 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-03-18 21:39 Missing vsync support in Vivante drivers Carlos Rafael Giani
2014-03-19  0:26 ` Eric Nelson
2014-05-01  9:50   ` Carlos Rafael Giani

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.