Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751997AbdHBX2a (ORCPT ); Wed, 2 Aug 2017 19:28:30 -0400 Received: from mail-io0-f196.google.com ([209.85.223.196]:36802 "EHLO mail-io0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751184AbdHBX23 (ORCPT ); Wed, 2 Aug 2017 19:28:29 -0400 MIME-Version: 1.0 X-Originating-IP: [2a02:168:5640:0:960b:2678:e223:c1c6] In-Reply-To: <8ef4c8cb-59d9-a201-55fc-b7878c6790c7@lechnology.com> References: <1501601201-32590-1-git-send-email-david@lechnology.com> <20170802094638.egbninloeganxdrp@phenom.ffwll.local> <8ef4c8cb-59d9-a201-55fc-b7878c6790c7@lechnology.com> From: Daniel Vetter Date: Thu, 3 Aug 2017 01:28:27 +0200 X-Google-Sender-Auth: 4ctPS9bIPGMY8GYEb7xxnd4cLCw Message-ID: Subject: Re: [PATCH] drm/fb-helper: pass physical dimensions to fbdev To: David Lechner Cc: dri-devel , Linux Kernel Mailing List , Daniel Vetter Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1654 Lines: 40 On Wed, Aug 2, 2017 at 6:37 PM, David Lechner wrote: > On 08/02/2017 04:46 AM, Daniel Vetter wrote: >> >> On Tue, Aug 01, 2017 at 10:26:41AM -0500, David Lechner wrote: >>> >>> The fbdev subsystem has a place for physical dimensions (width and height >>> in mm) that is readable by userspace. Since DRM also knows these >>> dimensions, pass this information to the fbdev device. >>> >>> Signed-off-by: David Lechner >> >> >> Still in the wrong function. Also please add some notation about what you >> changed when resubmitting a patch (it took me a while to remember that I >> replied to you already). That makes patch reviewing more efficient. >> > > Sorry for being so dense. :-/ > > I did read your first reply at least 10 times. All of the terminology is > foreign to me, but after sleeping on it a few days, I think it is slowly > soaking into my brain. No problem, the code is fairly convoluted. One more question on your v3: From reading fbdev code I don't see any place that overwrites the physical dimensions except the fill_var helper function (which is called deep down from register_framebuffer). If we entirely remove the var.width/height assignments from that (including the -1 default) and move all of it into setup_crtcs, would that work? I kinda don't like have the same logic in 2 completely different places, once for driver load and once for hotplug handling. That tends to cause bugs (because then no one bothers to test hotplug handling or the boot-up case properly). Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch