From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pb0-f46.google.com (mail-pb0-f46.google.com [209.85.160.46]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id 6783FE00480 for ; Tue, 18 Mar 2014 17:27:01 -0700 (PDT) Received: by mail-pb0-f46.google.com with SMTP id rq2so8027608pbb.19 for ; Tue, 18 Mar 2014 17:27:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Dnxo4kpTJmbMtyNHCNOZ8aiaOAE4xxdWG+w8urcF7NE=; b=P3P3rLiWeQfC333jK5CUsVU8IsrJq3dqByuMtbIvFWdsuKK5Kj2ajEPf0d2oga5zIn iLApExoWDfQ8iA6dbHRRwYuLJFQnsfFGWJDq1CiAifD9UFUNwxst6st/gY6/Lac7Zy2+ vjgSDUGm3E4skZjRryL2ncidRR3RaMcinfQ2xOJukegQ8NIu5Y2e69WAbqRPgFlmeiWo t0TuIotveucPWSmmYsBKNv7tFuK453hPf1fm2ocz9eGtHPNjQuaiefGjKHWgDFTL2p9e V6wS8zvoTKlP3n5arzHQfZuehdOx/y7aMf3a+QhtVuM9edRuy9SV5F9AIT/eOjb+tjFJ N/xg== X-Gm-Message-State: ALoCoQl2xyd9Ghaa15rlaMJG+qCo6FOxnM2nJ6XOYyqusHHQwTM5ovJV9MDVZ5CfD+tsDdVkiczc X-Received: by 10.68.200.74 with SMTP id jq10mr44882pbc.169.1395188820986; Tue, 18 Mar 2014 17:27:00 -0700 (PDT) Received: from [192.168.0.53] ([63.226.49.26]) by mx.google.com with ESMTPSA id sx8sm94818292pab.5.2014.03.18.17.26.58 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 18 Mar 2014 17:26:59 -0700 (PDT) Message-ID: <5328E44D.4040201@boundarydevices.com> Date: Tue, 18 Mar 2014 17:26:53 -0700 From: Eric Nelson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Carlos Rafael Giani , "meta-freescale@yoctoproject.org" References: <5328BD2A.2080800@pseudoterminal.org> In-Reply-To: <5328BD2A.2080800@pseudoterminal.org> Subject: Re: Missing vsync support in Vivante drivers X-BeenThere: meta-freescale@yoctoproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Usage and development list for the meta-fsl-* layers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Mar 2014 00:27:04 -0000 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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