Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751700AbdCPKJG (ORCPT ); Thu, 16 Mar 2017 06:09:06 -0400 Received: from mga09.intel.com ([134.134.136.24]:29702 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751475AbdCPKJF (ORCPT ); Thu, 16 Mar 2017 06:09:05 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.36,170,1486454400"; d="scan'208";a="1123394732" Date: Thu, 16 Mar 2017 12:09:00 +0200 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= To: Michel =?iso-8859-1?Q?D=E4nzer?= Cc: dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] drm/fb-helper: Only reject FB changes if FB_MISC_USER_EVENT is set Message-ID: <20170316100900.GC31595@intel.com> References: <20170316095553.1586-1-michel@daenzer.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20170316095553.1586-1-michel@daenzer.net> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2415 Lines: 59 On Thu, Mar 16, 2017 at 06:55:53PM +0900, Michel D?nzer wrote: > From: Michel D?nzer > > 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. So why is the kernel allowed to violate this? The checks look somewhat bogus to me anyway. The 'virtual size == fb size' check makes some kind of sense. Although I don't see why the virtual resolution couldn't be smaller than the fb size. But requiring that the visible resolutionn matches the fb size as well definitely seems wrong. Maybe Cc whoever broke this? > > 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. > > drivers/gpu/drm/drm_fb_helper.c | 7 ++++--- > 1 file changed, 4 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c > index f6d4d9700734..9663f3b8f287 100644 > --- a/drivers/gpu/drm/drm_fb_helper.c > +++ b/drivers/gpu/drm/drm_fb_helper.c > @@ -1259,9 +1259,10 @@ int drm_fb_helper_check_var(struct fb_var_screeninfo *var, > * Changes struct fb_var_screeninfo are currently not pushed back > * to KMS, hence fail if different settings are requested. > */ > - if (var->bits_per_pixel != fb->format->cpp[0] * 8 || > - var->xres != fb->width || var->yres != fb->height || > - var->xres_virtual != fb->width || var->yres_virtual != fb->height) { > + if ((info->flags & FBINFO_MISC_USEREVENT) && > + (var->bits_per_pixel != fb->format->cpp[0] * 8 || > + var->xres != fb->width || var->yres != fb->height || > + var->xres_virtual != fb->width || var->yres_virtual != fb->height)) { > DRM_DEBUG("fb userspace requested width/height/bpp different than current fb " > "request %dx%d-%d (virtual %dx%d) > %dx%d-%d\n", > var->xres, var->yres, var->bits_per_pixel, > -- > 2.11.0 > > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Ville Syrj?l? Intel OTC