lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <60dc7697-d7a0-4bf4-a22e-32f1bbb792c2@suse.de>
Date: Wed, 6 Mar 2024 13:07:02 +0100
From: Thomas Zimmermann <tzimmermann@...e.de>
To: Douglas Anderson <dianders@...omium.org>, dri-devel@...ts.freedesktop.org
Cc: Rob Clark <robdclark@...omium.org>,
 Javier Martinez Canillas <javierm@...hat.com>,
 Daniel Vetter <daniel@...ll.ch>, Dave Airlie <airlied@...hat.com>,
 David Airlie <airlied@...il.com>,
 Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
 Maxime Ripard <mripard@...nel.org>, Maíra Canal
 <mcanal@...lia.com>, Sean Paul <sean@...rly.run>,
 Ville Syrjälä <ville.syrjala@...ux.intel.com>,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH] drm/udl: Add ARGB8888 as a format

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.

>
> 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?

And udl is just one driver. Any other driver without ARGB8888, such as 
simpledrm or ofdrm, would be affected. Do these work?

Best regards
Thomas

>
> Fixes: c91acda3a380 ("drm/gem: Check for valid formats")
> Signed-off-by: Douglas Anderson <dianders@...omium.org>
> ---
>
>   drivers/gpu/drm/udl/udl_modeset.c | 1 +
>   1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/udl/udl_modeset.c b/drivers/gpu/drm/udl/udl_modeset.c
> index 7702359c90c2..0f8d3678770e 100644
> --- a/drivers/gpu/drm/udl/udl_modeset.c
> +++ b/drivers/gpu/drm/udl/udl_modeset.c
> @@ -253,6 +253,7 @@ static int udl_handle_damage(struct drm_framebuffer *fb,
>   static const uint32_t udl_primary_plane_formats[] = {
>   	DRM_FORMAT_RGB565,
>   	DRM_FORMAT_XRGB8888,
> +	DRM_FORMAT_ARGB8888,
>   };
>   
>   static const uint64_t udl_primary_plane_fmtmods[] = {

-- 
--
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)


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ