| Message ID | 20240227141928.1.I24ac8d51544e4624b7e9d438d95880c4283e611b@changeid (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | drm/udl: Add ARGB8888 as a format | expand |
On Wed, 28 Feb 2024 at 00:19, Douglas Anderson <dianders@chromium.org> wrote: > > 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. > > 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. > > Fixes: c91acda3a380 ("drm/gem: Check for valid formats") > Signed-off-by: Douglas Anderson <dianders@chromium.org> > --- > > drivers/gpu/drm/udl/udl_modeset.c | 1 + > 1 file changed, 1 insertion(+) Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Hi, On Tue, Feb 27, 2024 at 3:26 PM Dmitry Baryshkov <dmitry.baryshkov@linaro.org> wrote: > > On Wed, 28 Feb 2024 at 00:19, Douglas Anderson <dianders@chromium.org> wrote: > > > > 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. > > > > 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. > > > > Fixes: c91acda3a380 ("drm/gem: Check for valid formats") > > Signed-off-by: Douglas Anderson <dianders@chromium.org> > > --- > > > > drivers/gpu/drm/udl/udl_modeset.c | 1 + > > 1 file changed, 1 insertion(+) > > Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> It's been ~a week, the fix is trivial, and according to MAINTAINERS this driver goes through drm-misc. ...so I've applied this with Dmitry's tag (thanks!) to drm-misc-fixes. 95bf25bb9ed5 drm/udl: Add ARGB8888 as a format -Doug
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@chromium.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[] = {
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. BR, -R > Best regards > Thomas > > > > > Fixes: c91acda3a380 ("drm/gem: Check for valid formats") > > Signed-off-by: Douglas Anderson <dianders@chromium.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) >
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. ;-) -Doug
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.
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
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 BR, -R > -- > Ville Syrjälä > Intel
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.
On Wed, Mar 6, 2024 at 3:24 PM Ville Syrjälä <ville.syrjala@linux.intel.com> wrote: > > 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? I think chrome compositor (as in CrOS) always just picks ARGB8888 because, on devices that support overlays/underlays, it will use underlays in some cases. Yes, lazy, and a userspace bug. But this worked previously until commit c91acda3a380 ("drm/gem: Check for valid formats"), so it seems to me like a clear case of kernel breaking userspace. I don't think we really have a choice other than to allow ARGB8888. A lot of drivers like simpledrm will never encounter the chrome compositor, so it is ofc an option to leave them as-is until someone reports a regression, which is maybe unlikely. I suppose udl is a special case because it can show up anywhere. BR, -R > Anyways, adding ARGB to even more drivers seems like a terrible > idea to me. > > -- > Ville Syrjälä > Intel
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[] = {
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. 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. Fixes: c91acda3a380 ("drm/gem: Check for valid formats") Signed-off-by: Douglas Anderson <dianders@chromium.org> --- drivers/gpu/drm/udl/udl_modeset.c | 1 + 1 file changed, 1 insertion(+)