Hi
Am 06.03.24 um 16:05 schrieb Doug Anderson:
Hi,
On Wed, Mar 6, 2024 at 4:07 AM Thomas Zimmermann <tzimmermann@xxxxxxx> wrote:
Hi,
sorry that I did not see the patch before.
Am 27.02.24 um 23:19 schrieb Douglas Anderson:
Even though the UDL driver converts to RGB565 internally (see
pixel32_to_be16() in udl_transfer.c), it advertises XRGB8888 for
compatibility. Let's add ARGB8888 to that list.
We had a heated discussion about the emulation of color formats. It was
decided that XRGB8888 is the only format to support; and that's only
because legacy userspace sometimes expects it. Adding other formats to
the list should not be done easily.
Sorry! I wasn't aware of the previous discussion and nobody had
brought it up till now. As discussed on #dri-devel IRC, I've posted a
revert:
https://lore.kernel.org/r/20240306063721.1.I4a32475190334e1fa4eef4700ecd2787a43c94b5@changeid
This makes UDL devices work on ChromeOS again after commit
c91acda3a380 ("drm/gem: Check for valid formats"). Prior to that
commit things were "working" because we'd silently treat the ARGB8888
that ChromeOS wanted as XRGB8888.
This problem has been caused by userspace. Why can it not be fixed there?
I guess the one argument I could make is that the kernel isn't
supposed to break userspace. Before the extra format validation patch,
AKA commit c91acda3a380 ("drm/gem: Check for valid formats"),
userspace worked. Now it doesn't.
That being said, one can certainly argue that userspace was working in
the past simply due to relying on a bug. ...and in such a case fixing
the bug in userspace is preferred.
I don't personally know _how_ to fix userspace but it feels like it
should be possible.
And udl is just one driver. Any other driver without ARGB8888, such as
simpledrm or ofdrm, would be affected. Do these work?
It's the ChromeOS compositor. I can totally believe that those drivers
don't work. In this case, though, those drivers aren't needed by a USB
peripheral that someone might plug in. ;-)
If you can fix to problem in the compositor, that would be the correct
solution. If it's really not possible, we'd have to figure out something
else.
We supported various combinations of source and destination formats in
the kernel. But that results in state explosion at some point. And we
wanted to move conversion code to userspace where possible. So only
XRGB8888 was allowed, as it's sometimes necessary to support legacy
userspace. (Ironically, one could make that argument for ARGB and the
ChromeOS compositor. :) We even have code that works around incorrect
ARGB reported by hardware or firmware, so that userspace absolutely does
not see ARGB for the primary planes of simpledrm/ofdrm. [1]
Best regards
Thomas
[1]
https://elixir.bootlin.com/linux/v6.7/source/drivers/gpu/drm/drm_format_helper.c#L1158
-Doug
--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)
