[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <02b45e84-aacb-801b-e1a2-d53707a3de6d@suse.de>
Date: Wed, 3 Jan 2018 19:04:43 +0100
From: Max Staudt <mstaudt@...e.de>
To: Alan Cox <gnomes@...rguk.ukuu.org.uk>,
Oliver Neukum <oneukum@...e.com>
Cc: Daniel Vetter <daniel@...ll.ch>, bernhard.rosenkranzer@...aro.org,
dri-devel@...ts.freedesktop.org, philm@...jaro.org,
michal@...kovi.net, b.zolnierkie@...sung.com,
Stefan Dirsch <sndirsch@...e.com>,
Takashi Iwai <tiwai@...e.com>, linux-fbdev@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH v2 03/13] bootsplash: Flush framebuffer after drawing
On 12/31/2017 01:53 PM, Alan Cox wrote:
> On Tue, 19 Dec 2017 15:07:53 +0100
> Oliver Neukum <oneukum@...e.com> 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
Powered by blists - more mailing lists