Monochrome/greyscale and software dithering in the kernel

[Noralf Trønnes]

Den 03.08.2017 17.46, skrev Daniel Vetter:
> On Thu, Aug 3, 2017 at 5:24 PM, David Lechner <david at lechnology.com> wrote:
>> On 08/03/2017 09:58 AM, Noralf Trønnes wrote:
>>> Hi,
>>>
>>> The tinydrm/repaper driver is monochrome, but I have just used an
>>> emulation format XRGB8888, since monochrome support is scarce in
>>> userspace. I'm using ITU BT.601 to convert from rgb to greyscale and
>>> then use the msb for monochrome.
>>>
>>> Now I'm asked if we can implement Floyd–Steinberg dithering in the driver
>>> to make it more useful, so userspace can work reasonably well with
>>> default tools/libs. I did have that in the first stage of the driver
>>> development, but decided against it, since I figured this was the
>>> responsibility of userspace not the kernel. But personally it doesn't
>>> really matter to me either way.
>>>
>>> So the question is, can I say yes to such an addition?
>>>
>> IMHO, if we add monochorme/grayscale support to DRM, then I think using
>> dithering for the "compatibility mode" XRGB8888 emulation would be a good
>> idea. But until then, I don't think I would like it because unless you are
>> displaying photos it will probably causes some noticeable distortion.
> I'd suggest for monochrome displays we forgo dithering entirely. The
> XRGB8888 stuff is just there to make sure userspace can expect that
> format to work, but that's it. If you want your greyscale to look
> good, then pls directly render greyscale in userspace.
>
> There's 15+ years of history on why drm doesn't do any rendering in
> the kernel, and there's reasons for that. XRGB8888 really was an
> exception since otherwise normal distro's won't even boot up, but
> that's going to be the _only_ exception. And we're going to make it
> work with the minimal amount of kernel code, i.e. no fancing
> dithering, scaling, interpolation or anything like that.

Thanks for clarifying, now I have some real arguments instead of just a 
hunch.

Noralf.