Received-SPF: pass (google.com: domain of linux-kernel+bounces-94711-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Date: Thu, 7 Mar 2024 01:24:12 +0200
From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= <ville.syrjala@linux.intel.com>
To: Rob Clark <robdclark@gmail.com>
Cc: Thomas Zimmermann <tzimmermann@suse.de>,
	Douglas Anderson <dianders@chromium.org>,
	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>,
	=?iso-8859-1?Q?Ma=EDra?= Canal <mcanal@igalia.com>,
	Sean Paul <sean@poorly.run>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] drm/udl: Add ARGB8888 as a format
Message-ID: <Zej7HOLVOAMtWvrn@intel.com>
References: <20240227141928.1.I24ac8d51544e4624b7e9d438d95880c4283e611b@changeid>
 <60dc7697-d7a0-4bf4-a22e-32f1bbb792c2@suse.de>
 <CAF6AEGs2zCP1SWPzxz4v2CU--yyEsN0+PS3dKM1nOuGyVkCpLg@mail.gmail.com>
 <ZeiGi4l1lL_fYJ69@intel.com>
 <CAF6AEGs1ce2xzuo3xEO+xgj+0iCi59nM8AiTwBfEhwZZ2w6Vww@mail.gmail.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAF6AEGs1ce2xzuo3xEO+xgj+0iCi59nM8AiTwBfEhwZZ2w6Vww@mail.gmail.com>

On Wed, Mar 06, 2024 at 07:37:16AM -0800, Rob Clark wrote:
> On Wed, Mar 6, 2024 at 7:06 AM Ville Syrjälä
> <ville.syrjala@linux.intel.com> wrote:
> >
> > On Wed, Mar 06, 2024 at 06:49:15AM -0800, Rob Clark wrote:
> > > On Wed, Mar 6, 2024 at 4:18 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.
> > >
> > > OTOH it is fixing a kernel change that broke userspace
> > >
> > > > >
> > > > > 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?
> > >
> > > Probably any driver where ARGB8888 is equivalent to XRGB8888 (ie.
> > > single primary plane, etc) should advertise both.
> >
> > To me that seemes likely to trick userspace developers into
> > assuming that ARGB is always available, and then when they
> > finally try on hardware that doesn't have ARGB it'll just
> > fail miserably.
> 
> I think that ship has sailed already, at least for any drivers that
> previously silently accepted ARGB8888

Perhaps. Although I don't actually understand what kind of weird
userspace people are running if it somehow expects ARGB to be there,
but only for some specific kms drivers. Is said userspace really
somehow checking which kms driver is present and then just ignoring
the pixel format list exposed by the driver? Or is it just some
super hw specific thing where they can just assume a specific kms
driver?

Anyways, adding ARGB to even more drivers seems like a terrible
idea to me.

-- 
Ville Syrjälä
Intel