Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp5491441pxb; Wed, 26 Jan 2022 13:17:46 -0800 (PST) X-Google-Smtp-Source: ABdhPJxwRJ7N55flFRc/O/jpHiLFeLjVNlmgasqOmWNhBTDmk+eok36L5nEMPldjd4UnI3VbzC2r X-Received: by 2002:a17:902:ea12:: with SMTP id s18mr742470plg.163.1643231866651; Wed, 26 Jan 2022 13:17:46 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1643231866; cv=none; d=google.com; s=arc-20160816; b=KmsQPBVcDoPgV+RLFt47jYQHhggMlLDg7NTN+XXlFWZoGEeLGjT3qqvAJ80VRslaet NXa9VyvwwwYX3x1Yl2VqRatUyEgMc3rQaz2/ZKwKau0ThU91EyGnzYgffuVy/2XF/HSy X06ttbQa52kH3QTg3jQzhWegz0r4brY/sKhACdz9iiH1J0tYNxu/0xNut+776d/gLaIw OBduRzcLrpJLECQzC9/fKC88Vqsw/nDO8OAqsrk4N3uK2xM6Y7ok+1RwKGpbj7MEZiET WpQkoHa35G2FMmO0YfVuRIqkTIvhid8o1u1bVxL4mhdezYJN9AQvY8QWz0FMHdUfzDnC zn4Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:organization:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=bSj6nkMaPvQRGnMJkBwy3AA6734Lr7OzlUgE0eiRXHc=; b=KIVxX7tsOuq/HbAOmuMpuwRV+3EG265l6zW/Ca6AkNFgThksGJh60NCF4Z2LDX7pv8 7Oi9CoMEsZYnGH/8EoKIDgtCFBY/aixKy60Vh56QrKzv5R6NuT2iNApqLV+9ZAmQzfRB WlMJjKC1AIW5Xmwot6qtzeNewu+qKOybDPCQl3o06NuCiCI+o/ELVy+Gb/1ejmYU0CDO VzORYFgkeO8w44kKpJxa9q/uFek6A0ZUlz+HNf316adYvA0/osv04UZiZ26RtJ/KCXZ0 XaAxqCnLeYIioeTIZ+Gi6JJ5SnkDhrC62tiUlZ1+PpYBccIZDT6kbQdRKu8b4rQ9gV0G 6fqA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=XW8EqB97; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id 84si335966pga.173.2022.01.26.13.17.34; Wed, 26 Jan 2022 13:17:46 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=XW8EqB97; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236877AbiAZNIC (ORCPT + 99 others); Wed, 26 Jan 2022 08:08:02 -0500 Received: from mga07.intel.com ([134.134.136.100]:42168 "EHLO mga07.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234333AbiAZNIC (ORCPT ); Wed, 26 Jan 2022 08:08:02 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1643202482; x=1674738482; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=ufV8tnp4+s0eKaTq+EbumSk5nBwGFfL7ygpVjn/q6M8=; b=XW8EqB9705Brt0muiI9bsFX5yR0+zL+dc0c5NqXPjTqdjlFv1Wsrv8/1 Z6WfjGqEU8lZV6TBOF9cCdbe1DzqoQ5bmntGFVVDH91m1U8M1l5vUMw0e h+drQ/sdSuOYWwA7lBcCgTsEUZO7+qCOiczdWh1gcbktej8R7BLaZs1Dp +mVgvCbkdbXTrlZXhR2fVgCB+ObCdh5kHfCT4v0oc94Z7X7BsH1VfVsyY CttIH1TUaMTA+CQYFuGjl53sAmWgPtKN5Iz+FYKYsLlgmjvHD4PhxR3W1 1JgzHkWvNGrkRfZZWCqFtVdDrAa5nAytXYXsqorRWP9KAKOjNTcncXjZm g==; X-IronPort-AV: E=McAfee;i="6200,9189,10238"; a="309858908" X-IronPort-AV: E=Sophos;i="5.88,318,1635231600"; d="scan'208";a="309858908" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Jan 2022 05:08:01 -0800 X-IronPort-AV: E=Sophos;i="5.88,318,1635231600"; d="scan'208";a="581098861" Received: from smile.fi.intel.com ([10.237.72.61]) by fmsmga008-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Jan 2022 05:07:58 -0800 Received: from andy by smile.fi.intel.com with local (Exim 4.95) (envelope-from ) id 1nCi0h-00EbS3-GQ; Wed, 26 Jan 2022 15:06:51 +0200 Date: Wed, 26 Jan 2022 15:06:51 +0200 From: Andy Shevchenko To: Daniel Vetter Cc: Greg Kroah-Hartman , Andy Shevchenko , linux-fbdev@vger.kernel.org, Michael Hennerich , Helge Deller , linux-staging@lists.linux.dev, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, Phillip Potter , Carlis , Lee Jones , Heiner Kallweit Subject: Re: [PATCH v1 1/4] fbtft: Unorphan the driver Message-ID: References: <20220125202118.63362-1-andriy.shevchenko@linux.intel.com> <20220125202118.63362-2-andriy.shevchenko@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jan 26, 2022 at 11:31:45AM +0100, Daniel Vetter wrote: > On Wed, Jan 26, 2022 at 9:31 AM Greg Kroah-Hartman > wrote: > > On Tue, Jan 25, 2022 at 10:21:14PM +0200, Andy Shevchenko wrote: ... > > I'm ok with the files moving if the dri developers agree with it. It's > > up to them, not me. > > On one hand I'm happy anytime someone volunteers to help out. > > On the other hand ... why does it have to be resurrecting fbdev? > There's an entire community of people who really know graphics and > display and spent considerable amount of effort on creating useful and > documented helpers for pretty much anything you might ever want to do. Why nobody has converted these drivers to be DRM based? For all these years no new conversion happens except couple, which I don't even have a hardware to see. But I have the hardware that is supported exclusively by fbtft driver. > And somehow we have to go back to typing out things the hard way, with > full verbosity, for an uapi that distros are abandoning (e.g. even for > sdl the direction is to run it on top of drm with a compat layer, > afaiui fedora is completely ditching any userspace that still even > uses /dev/fb/0). And yes I know there's still some gaps in drm, > largely for display features which were really en vogue about 20 years > ago. And we're happy to add that support, if someone who still has > such hardware can put in the little bit of work needed ... > > I don't get this. I don't get how Fedora is related here. It's not useful to bury the /dev/fbX out for the devices that the use of are black-and-white output on small embedded systems. -- With Best Regards, Andy Shevchenko