On Tue, 13 Oct 2026 at 15:11, Thomas Zimmermann <[email protected]> wrote: > > Hi > > Am 12.10.26 um 19:08 schrieb Ho Jie Feng: > > Add a helper for devices that use packed UYVY but accept XRGB8888 > > framebuffers. > > Is there a description of UYVY available somewhere? This is for a reverse engineered usb display adapter, which accepts input in bytes of U, Y, V, Y in that order. I'm not sure what counts as a description, apart from it matching DRM_FORMAT_UYVY?
This patch is meant to move this out of the driver: https://github.com/rhgndf/ms912x/blob/main/ms912x_transfer.c#L153 > > > > Signed-off-by: Ho Jie Feng <[email protected]> > > --- > > This is used for a driver, ms912x that I will be submitting. It only > > supports uyvy framebuffers. > > Please resubmit as part of the driver series. We're not going to merge > it without callers anyway. > ... > For naming, please follow the conventions used by the other helpers in > this file. Will send the driver in with this patch and its fixes, thanks for the review. > ... > > + v = drm_pixel_rgb2_to_v_bt601(r, g, b); > > + u = drm_pixel_rgb2_to_u_bt601(r, g, b); > > + > > + transfer_buffer[dst_offset++] = u; > > + transfer_buffer[dst_offset++] = y1; > > + transfer_buffer[dst_offset++] = v; > > + transfer_buffer[dst_offset++] = y2; > > Rather that writing bytes individually, use put_unaligned_le32() or a > similar helper. Byte order within a pixel is little endian, although > I'm not sure what this means for UYVY. This is meant to be sent over a usb transfer, so byte order needs to be the same on both little and big endian systems. > > ... > > +static inline u32 drm_pixel_rgb_to_y_bt601(u32 r, u32 g, u32 b) > > +{ > > + const u32 luma = (16U << 16) + 16829 * r + 33039 * g + 6416 * b + > > 32768; > > + > > + return luma >> 16; > > +} > > + > > +static inline u32 drm_pixel_rgb2_to_u_bt601(u32 r2, u32 g2, u32 b2) > > +{ > > + const u32 u = (128U << 17) - 9714 * r2 - 19071 * g2 + 28784 * b2 + > > 65536; > > + > > + return u >> 17; > > +} > > + > > +static inline u32 drm_pixel_rgb2_to_v_bt601(u32 r2, u32 g2, u32 b2) > > +{ > > + const u32 v = (128U << 17) + 28784 * r2 - 24103 * g2 - 4681 * b2 + > > 65536; > > + > > + return v >> 17; > > +} > > + > > These helpers seem too fine-grained. IMHO it would be better to have a > helper like drm_pixel_rgb_to_uyvy() that takes two RGB values and > returns the assembled 16-bit UYVY value. Makes sense. > Best regards > Thomas > > > /* > > * Conversion from ARGB8888 > > */ > > diff --git a/include/drm/drm_format_helper.h > > b/include/drm/drm_format_helper.h > > index 2b5c1aef80b0e..e50f96e07484c 100644 > > --- a/include/drm/drm_format_helper.h > > +++ b/include/drm/drm_format_helper.h > > @@ -136,4 +136,8 @@ void drm_fb_xrgb8888_to_gray2(struct iosys_map *dst, > > const unsigned int *dst_pit > > const struct iosys_map *src, const struct > > drm_framebuffer *fb, > > const struct drm_rect *clip, struct > > drm_format_conv_state *state); > > > > +void drm_fb_xrgb8888_to_uyvy(struct iosys_map *dst, const unsigned int > > *dst_pitch, > > + const struct iosys_map *src, const struct > > drm_framebuffer *fb, > > + const struct drm_rect *clip, struct > > drm_format_conv_state *state); > > + > > #endif /* __LINUX_DRM_FORMAT_HELPER_H */ > > -- > -- > Thomas Zimmermann > Graphics Driver Developer > SUSE Software Solutions Germany GmbH > Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com > GF: Stefan Gaiser, Jochen Jaser, Abhinav Puri, (HRB 36809, AG Nürnberg) > >
