On Tue, 13 Oct 2026 at 20:32, Thomas Zimmermann <[email protected]> wrote: > > Hi > > Am 13.10.26 um 14:17 schrieb Jie Feng: > > 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? > > I see. The format exists already in DRM. > > > > > 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. > > DRM formats always refer to little endian. As it is implemented now, > it's not clear what the endianess of your output is. Please duplicate > the other helpers' logic. They all pack the output with appropriate > helpers. If the USB device requires BE, you have to write a separate > conversion helper for that. > > BTW, you have an OOB access if the line width is not a multiple of 2. How should I handle this? Rounding it within the helper doesn't seem to make sense and the function return is a void, so it can't return -EINVAL.
Other helpers ignore the -ENOMEM error when drm_format_conv_state_reserve fails, so should it follow this convention? Alternatively, drm_fb_xfrm can be exported, and let the driver define the rgb->yuv coefficients? But I think it is fine since _to_gray8 also cites BT.601.
