Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751096AbdCQIyo (ORCPT ); Fri, 17 Mar 2017 04:54:44 -0400 Received: from [148.251.143.178] ([148.251.143.178]:33645 "EHLO netline-mail3.netline.ch" rhost-flags-FAIL-FAIL-OK-OK) by vger.kernel.org with ESMTP id S1750980AbdCQIyn (ORCPT ); Fri, 17 Mar 2017 04:54:43 -0400 From: =?UTF-8?Q?Michel_D=c3=a4nzer?= Subject: Re: [PATCH] drm/fb-helper: Only reject FB changes if FB_MISC_USER_EVENT is set To: Daniel Stone Cc: Linux Kernel Mailing List , dri-devel References: <20170316095553.1586-1-michel@daenzer.net> Message-ID: <6ac07ce5-44a5-1823-1940-21c8e7bcfc5e@daenzer.net> Date: Fri, 17 Mar 2017 17:54:31 +0900 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1557 Lines: 33 On 16/03/17 07:09 PM, Daniel Stone wrote: > On 16 March 2017 at 09:55, Michel Dänzer wrote: >> Otherwise this can also prevent modesets e.g. for switching VTs. >> >> FB_MISC_USER_EVENT is set when the request originates from userspace, >> which is what we're interested in here according to the DRM_DEBUG >> output. >> >> Bugzilla: https://bugs.freedesktop.org/99841 >> Fixes: 865afb11949e ("drm/fb-helper: reject any changes to the fbdev") >> Signed-off-by: Michel Dänzer >> --- >> >> I'm not entirely sure why the values can not match for a VT switch. If >> anybody thinks this just papers over the real issue, please speak up. > > It happens for me in multi-head with different resolutions. A real > compositor will set native resolutions with separate framebuffers, and > then fbcon will try to set one buffer for both outputs. This works on > the output with the larger resolution, but the one with the smaller > resolution will fail due to [xy]res_virtual (IIRC) being different. That's more or less the line of thinking that lead me to writing this patch, based on the assumption that the fb->* values correspond to what was set by whatever we're VT switching from. However, it occurred to me that it's an invalid assumption; fb here is always fb_helper's framebuffer for fbdev. I think Ville is right that the tests are bogus in the first place. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer