Received-SPF: pass (google.com: domain of linux-kernel+bounces-94157-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Message-ID: <313c3730-10dd-42aa-8bd0-9f0a8627c1bb@suse.de>
Date: Wed, 6 Mar 2024 16:33:01 +0100
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] drm/udl: Add ARGB8888 as a format
Content-Language: en-US
To: Doug Anderson <dianders@chromium.org>
Cc: dri-devel@lists.freedesktop.org, Rob Clark <robdclark@chromium.org>,
 Javier Martinez Canillas <javierm@redhat.com>,
 Daniel Vetter <daniel@ffwll.ch>, Dave Airlie <airlied@redhat.com>,
 David Airlie <airlied@gmail.com>,
 Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
 Maxime Ripard <mripard@kernel.org>, =?UTF-8?Q?Ma=C3=ADra_Canal?=
 <mcanal@igalia.com>, Sean Paul <sean@poorly.run>,
 =?UTF-8?B?VmlsbGUgU3lyasOkbMOk?= <ville.syrjala@linux.intel.com>,
 linux-kernel@vger.kernel.org
References: <20240227141928.1.I24ac8d51544e4624b7e9d438d95880c4283e611b@changeid>
 <60dc7697-d7a0-4bf4-a22e-32f1bbb792c2@suse.de>
 <CAD=FV=VSFEFPzFhvMKwc7D3NBgnDq9qRp6eN1stSuhBCi_HoMQ@mail.gmail.com>
From: Thomas Zimmermann <tzimmermann@suse.de>
Autocrypt: addr=tzimmermann@suse.de; keydata=
 xsBNBFs50uABCADEHPidWt974CaxBVbrIBwqcq/WURinJ3+2WlIrKWspiP83vfZKaXhFYsdg
 XH47fDVbPPj+d6tQrw5lPQCyqjwrCPYnq3WlIBnGPJ4/jreTL6V+qfKRDlGLWFjZcsrPJGE0
 BeB5BbqP5erN1qylK9i3gPoQjXGhpBpQYwRrEyQyjuvk+Ev0K1Jc5tVDeJAuau3TGNgah4Yc
 hdHm3bkPjz9EErV85RwvImQ1dptvx6s7xzwXTgGAsaYZsL8WCwDaTuqFa1d1jjlaxg6+tZsB
 9GluwvIhSezPgnEmimZDkGnZRRSFiGP8yjqTjjWuf0bSj5rUnTGiyLyRZRNGcXmu6hjlABEB
 AAHNJ1Rob21hcyBaaW1tZXJtYW5uIDx0emltbWVybWFubkBzdXNlLmRlPsLAjgQTAQgAOAIb
 AwULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBHIX+6yM6c9jRKFo5WgNwR1TC3ojBQJftODH
 AAoJEGgNwR1TC3ojx1wH/0hKGWugiqDgLNXLRD/4TfHBEKmxIrmfu9Z5t7vwUKfwhFL6hqvo
 lXPJJKQpQ2z8+X2vZm/slsLn7J1yjrOsoJhKABDi+3QWWSGkaGwRJAdPVVyJMfJRNNNIKwVb
 U6B1BkX2XDKDGffF4TxlOpSQzdtNI/9gleOoUA8+jy8knnDYzjBNOZqLG2FuTdicBXblz0Mf
 vg41gd9kCwYXDnD91rJU8tzylXv03E75NCaTxTM+FBXPmsAVYQ4GYhhgFt8S2UWMoaaABLDe
 7l5FdnLdDEcbmd8uLU2CaG4W2cLrUaI4jz2XbkcPQkqTQ3EB67hYkjiEE6Zy3ggOitiQGcqp
 j//OwE0EWznS4AEIAMYmP4M/V+T5RY5at/g7rUdNsLhWv1APYrh9RQefODYHrNRHUE9eosYb
 T6XMryR9hT8XlGOYRwKWwiQBoWSDiTMo/Xi29jUnn4BXfI2px2DTXwc22LKtLAgTRjP+qbU6
 3Y0xnQN29UGDbYgyyK51DW3H0If2a3JNsheAAK+Xc9baj0LGIc8T9uiEWHBnCH+RdhgATnWW
 GKdDegUR5BkDfDg5O/FISymJBHx2Dyoklv5g4BzkgqTqwmaYzsl8UxZKvbaxq0zbehDda8lv
 hFXodNFMAgTLJlLuDYOGLK2AwbrS3Sp0AEbkpdJBb44qVlGm5bApZouHeJ/+n+7r12+lqdsA
 EQEAAcLAdgQYAQgAIAIbDBYhBHIX+6yM6c9jRKFo5WgNwR1TC3ojBQJftOH6AAoJEGgNwR1T
 C3ojVSkIALpAPkIJPQoURPb1VWjh34l0HlglmYHvZszJWTXYwavHR8+k6Baa6H7ufXNQtThR
 yIxJrQLW6rV5lm7TjhffEhxVCn37+cg0zZ3j7zIsSS0rx/aMwi6VhFJA5hfn3T0TtrijKP4A
 SAQO9xD1Zk9/61JWk8OysuIh7MXkl0fxbRKWE93XeQBhIJHQfnc+YBLprdnxR446Sh8Wn/2D
 Ya8cavuWf2zrB6cZurs048xe0UbSW5AOSo4V9M0jzYI4nZqTmPxYyXbm30Kvmz0rYVRaitYJ
 4kyYYMhuULvrJDMjZRvaNe52tkKAvMevcGdt38H4KSVXAylqyQOW5zvPc4/sq9c=
In-Reply-To: <CAD=FV=VSFEFPzFhvMKwc7D3NBgnDq9qRp6eN1stSuhBCi_HoMQ@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi

Am 06.03.24 um 16:05 schrieb Doug Anderson:
> Hi,
>
> On Wed, Mar 6, 2024 at 4:07 AM Thomas Zimmermann <tzimmermann@suse.de> 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)