Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751290AbeACSEr (ORCPT + 1 other); Wed, 3 Jan 2018 13:04:47 -0500 Received: from mx2.suse.de ([195.135.220.15]:47114 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751230AbeACSEq (ORCPT ); Wed, 3 Jan 2018 13:04:46 -0500 Subject: Re: [RFC PATCH v2 03/13] bootsplash: Flush framebuffer after drawing To: Alan Cox , Oliver Neukum Cc: Daniel Vetter , bernhard.rosenkranzer@linaro.org, dri-devel@lists.freedesktop.org, philm@manjaro.org, michal@markovi.net, b.zolnierkie@samsung.com, Stefan Dirsch , Takashi Iwai , linux-fbdev@vger.kernel.org, linux-kernel@vger.kernel.org References: <20171213194755.3409-1-mstaudt@suse.de> <20171213194755.3409-4-mstaudt@suse.de> <20171213213506.GD26573@phenom.ffwll.local> <20171219122313.GE26573@phenom.ffwll.local> <8bbb0497-4a10-2f81-0040-6e7cd4e7353c@suse.de> <20171219135715.GG26573@phenom.ffwll.local> <1513692473.14829.14.camel@suse.com> <20171231125326.6e4d912b@alans-desktop> From: Max Staudt Message-ID: <02b45e84-aacb-801b-e1a2-d53707a3de6d@suse.de> Date: Wed, 3 Jan 2018 19:04:43 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <20171231125326.6e4d912b@alans-desktop> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: On 12/31/2017 01:53 PM, Alan Cox wrote: > On Tue, 19 Dec 2017 15:07:53 +0100 > Oliver Neukum wrote: > >> Am Dienstag, den 19.12.2017, 14:57 +0100 schrieb Daniel Vetter: >>>> Would you like me to extend the FB API or not? >>> >>> Yes. Well for real I'd like you to do kms, so maybe you need to explain >>> why exactly you absolutely have to use fbdev (aka which driver isn't >>> supported by drm that you want to enable this on). >> >> Hi, >> >> those would be at a minimum efifb, vesafb, xenfb >> Those are obviously not sexy, but from a practical point of view >> they are the minimum you need to support. > > I think it's more constructive to look at it the other way around. What > drivers do we have that actually need to be used which don't have DRM > equivalents - and how do we fix that instead ? It's *at least* the above named drivers: efifb, vesafb, xenfb. Max