[RFC][PATCH 00/11] DRM driver for fbdev devices

[Michel Dänzer]

On 2019-03-27 10:41 a.m., Daniel Vetter wrote:
> On Wed, Mar 27, 2019 at 10:10 AM Thomas Zimmermann <tzimmermann at suse.de> wrote:
>> Am 26.03.19 um 15:53 schrieb Daniel Vetter:
>>>
>>> Looks surprisingly clean, at least from a quick read. Only big thing I
>>> noticed on the implementation side is that you probably want to use the
>>> simple display helpers. At least that's a much better fit for simple
>>> display hw supported by these fbdev drivers.
>>
>> I thought about using the simple-DRM helpers, but found that a full DRM
>> driver would be more helpful for porting over fbdev drivers. Unless
>> simple DRM is a hard requirement, I'd prefer to leave it this way.
>>
>> For those devices that only support a single pipeline, the conversion to
>> simple DRM should then be mandatory during the porting process.
> 
> fbdev only supports a single output, all multi-head extensions are
> driver specific ioctl hacks. Given that all you can do is switch it on
> or off (with a given mode), simple pipe helpers are the perfect fit
> for fbdev.
> 
> Some drivers might support more (like multiple heads, or at least
> different outputs), and those we should convert over. But at least for
> step 1 in converting fbdev drivers over, simple pipe is the right
> starting point I think.

Converting an fbdev driver to a KMS one loses some features:

1) Dynamically switching modes / colour formats via fbdev.
2) fbcon acceleration (or maybe this can be preserved?).

In turn, it allows exposing additional functionality:

3) Multiple outputs via KMS.


Is there any benefit in converting a driver without adding 3)? If not,
is simple pipe still a good starting point?


-- 
Earthling Michel Dänzer               |              https://www.amd.com
Libre software enthusiast             |             Mesa and X developer