On 1/18/22 07:11, Gerd Hoffmann wrote:
> On Mon, Jan 17, 2022 at 02:29:47PM +0100, Geert Uytterhoeven wrote:
>> Hi Gerd,
>>
>> On Mon, Jan 17, 2022 at 1:57 PM Gerd Hoffmann <kraxel@xxxxxxxxxx> wrote:
>>>> b) to include new drivers (for old hardware) if they arrive (probably happens rarely but there can be).
>>>> I know of at least one driver which won't be able to support DRM....
>>>
>>> Hmm? I seriously doubt that. There is always the option to use a
>>> shadow framebuffer, then convert from standard drm formats to whatever
>>> esoteric pixel format your hardware expects.
>>>
>>> Been there, done that. Have a look at the cirrus driver. The physical
>>> hardware was designed in the early 90-ies, almost 30 years ago. These
>>> days it exists in virtual form only (qemu emulates it). Thanks to the
>>> drm driver it runs wayland just fine even though it has a bunch of
>>> constrains dictated by the hardware design.
>>
>> The Cirrus DRM driver supports TrueColor (RGB565/888 and ARGB8888)
>> modes only. The Cirrus fbdev driver also supports mochrome and 256
>> color modes.
>>
>> There exist some DRM drivers that do support DRM_FORMAT_C8, but none of
>> the "tiny" ones do. Same for DRM_FORMAT_RGB{332,233}.
>
> Adding that to the cirrus driver shouldn't be hard. I'm wondering
> whenever there are any userspace apps which would actually use that
> though.
The discussion is not about userspace apps.
It's about the case, that if existing fbdev drivers should be converted to
DRM, then they are currently required to run in TrueColor. Some of those cards/drivers
don't support TrueColor (which is problem #1), and even if they do, then
only with their existing 2D bitblt acceleration they are somewhat performance-wise
useable as framebuffer console (problem #2).
So, if DRM would natively support other formats, then it's not hard to
convert them to DRM.
Helge
