search for: drm_driver_color_mode_format

...forms too that support non-simple non-RGB > >> formats via dumb buffers): without this patch, in both drivers, the > >> pitch calculations just take the bpp as bit-per-pixels, align it up, > >> and that's it. > >> > >> With this patch we end up using drm_driver_color_mode_format(), and > >> aligning buffers according to RGB formats figured out via heuristics. > >> It does happen to work, for the formats I tested, but it sounds like > >> something that might easily not work, as it's doing adjustments based > >> on wrong format. > &...

...apdrm or > xilinx (probably other platforms too that support non-simple non-RGB > formats via dumb buffers): without this patch, in both drivers, the > pitch calculations just take the bpp as bit-per-pixels, align it up, > and that's it. > > With this patch we end up using drm_driver_color_mode_format(), and > aligning buffers according to RGB formats figured out via heuristics. > It does happen to work, for the formats I tested, but it sounds like > something that might easily not work, as it's doing adjustments based > on wrong format. > > Should we have another versi...

...if this change is good for omapdrm or xilinx (probably other platforms too that support non-simple non-RGB formats via dumb buffers): without this patch, in both drivers, the pitch calculations just take the bpp as bit-per-pixels, align it up, and that's it. With this patch we end up using drm_driver_color_mode_format(), and aligning buffers according to RGB formats figured out via heuristics. It does happen to work, for the formats I tested, but it sounds like something that might easily not work, as it's doing adjustments based on wrong format. Should we have another version of drm_mode_size_dumb() wh...

...x (probably other platforms too that support non-simple non-RGB >> formats via dumb buffers): without this patch, in both drivers, the >> pitch calculations just take the bpp as bit-per-pixels, align it up, >> and that's it. >> >> With this patch we end up using drm_driver_color_mode_format(), and >> aligning buffers according to RGB formats figured out via heuristics. >> It does happen to work, for the formats I tested, but it sounds like >> something that might easily not work, as it's doing adjustments based >> on wrong format. >> >> Shou...

...n-simple non-RGB > > >> formats via dumb buffers): without this patch, in both drivers, the > > >> pitch calculations just take the bpp as bit-per-pixels, align it up, > > >> and that's it. > > >> > > >> With this patch we end up using drm_driver_color_mode_format(), and > > >> aligning buffers according to RGB formats figured out via heuristics. > > >> It does happen to work, for the formats I tested, but it sounds like > > >> something that might easily not work, as it's doing adjustments based > > >> on...

...b buffers almost sounds like going backwards. >> video= parameter is bad, > > Who told you that? Video= is still the way to specify an initial display > mode to the kernel and it will remain so. You did =). "It aligns dumb buffers and video=". I understand the need for drm_driver_color_mode_format() for video=. But I think it's bad for CREATE_DUMB, at least for the platforms which have never aimed for "RGB-only". So you're not in favor of a drm_mode_size_dumb() version that does not use drm_driver_color_mode_format(), for these platforms? I'm still at loss as to wh...

...on-RGB >>>>> formats via dumb buffers): without this patch, in both drivers, the >>>>> pitch calculations just take the bpp as bit-per-pixels, align it up, >>>>> and that's it. >>>>> >>>>> With this patch we end up using drm_driver_color_mode_format(), and >>>>> aligning buffers according to RGB formats figured out via heuristics. >>>>> It does happen to work, for the formats I tested, but it sounds like >>>>> something that might easily not work, as it's doing adjustments based >>>>...

...gt;>> formats via dumb buffers): without this patch, in both drivers, the >>>>>> pitch calculations just take the bpp as bit-per-pixels, align it up, >>>>>> and that's it. >>>>>> >>>>>> With this patch we end up using drm_driver_color_mode_format(), and >>>>>> aligning buffers according to RGB formats figured out via heuristics. >>>>>> It does happen to work, for the formats I tested, but it sounds like >>>>>> something that might easily not work, as it's doing adjustments based >...

Hi Am 15.01.25 um 14:33 schrieb Tomi Valkeinen: [...] >> Yeah, there are constrains in the scanline and buffer alignments and >> orientation. And if we say that bpp==12 means NV12, it will be a >> problem for all other cases where bpp==12 makes sense. > > I feel I still don't quite understand. Can't we define and document > CREATE_DUMB like this: > >

...this patch, in both drivers, the >>>>>>> pitch calculations just take the bpp as bit-per-pixels, align it >>>>>>> up, >>>>>>> and that's it. >>>>>>> >>>>>>> With this patch we end up using drm_driver_color_mode_format(), and >>>>>>> aligning buffers according to RGB formats figured out via >>>>>>> heuristics. >>>>>>> It does happen to work, for the formats I tested, but it sounds >>>>>>> like >>>>>>> someth...

Hi Am 16.01.25 um 11:03 schrieb Tomi Valkeinen: [...] > Aligning video= and dumb buffers almost sounds like going backwards. > video= parameter is bad, Who told you that? Video= is still the way to specify an initial display mode to the kernel and it will remain so. Of course, it is better to auto-detect settings, but that's for a different use case. Best regards Thomas >

...the two planes with: 240 x 576 with 32 bitspp 120 x 288 with 64 bitspp This worked, and if I look at the DRM_IOCTL_MODE_CREATE_DUMB in the docs, I can't right away see anything there that says my tactic was not allowed. The above doesn't work anymore with this patch, as the code calls drm_driver_color_mode_format(), which fails for 64 bitspp. It feels a bit odd that DRM_IOCTL_MODE_CREATE_DUMB will try to guess the RGB fourcc for a dumb buffer allocation. So, what to do here? Am I doing something silly? What's the correct way to allocate the buffers for XV15? Should I just use 32 bitspp for the plan...

.../drm/drm_client_setup.c b/drivers/gpu/drm/drm_client_setup.c index c8ca5afaa47a..5373a892f097 100644 --- a/drivers/gpu/drm/drm_client_setup.c +++ b/drivers/gpu/drm/drm_client_setup.c @@ -64,6 +64,6 @@ void drm_client_setup_with_color_mode(struct drm_device *dev, unsigned int color { u32 fourcc = drm_driver_color_mode_format(dev, color_mode); - drm_client_setup_with_fourcc(dev, fmt); + drm_client_setup_with_fourcc(dev, fourcc); } EXPORT_SYMBOL(drm_client_setup_with_color_mode); diff --git a/drivers/gpu/drm/mgag200/mgag200_drv.c b/drivers/gpu/drm/mgag200/mgag200_drv.c index 6623ee4e3277..29087e2398df 100644 --- a/dr...

...2 bitspp > 120 x 288 with 64 bitspp > > This worked, and if I look at the DRM_IOCTL_MODE_CREATE_DUMB in the > docs, I can't right away see anything there that says my tactic was > not allowed. > > The above doesn't work anymore with this patch, as the code calls > drm_driver_color_mode_format(), which fails for 64 bitspp. It feels a > bit odd that DRM_IOCTL_MODE_CREATE_DUMB will try to guess the RGB > fourcc for a dumb buffer allocation. > > So, what to do here? Am I doing something silly? What's the correct > way to allocate the buffers for XV15? Should I just use...

...ch * args->height); + u32 fourcc; + const struct drm_format_info *info; + u64 pitch_align; + int ret; + + /* + * Adreno needs pitch aligned to 32 pixels. Compute the number + * of bytes for a block of 32 pixels at the given color format. + * Use the result as pitch alignment. + */ + fourcc = drm_driver_color_mode_format(dev, args->bpp); + if (fourcc == DRM_FORMAT_INVALID) + return -EINVAL; + info = drm_format_info(fourcc); + if (!info) + return -EINVAL; + pitch_align = drm_format_info_min_pitch(info, 0, SZ_32); + if (!pitch_align || pitch_align > U32_MAX) + return -EINVAL; + ret = drm_mode_size_dumb(dev,...

...+ /* + * Hardware requires the framebuffer width to be aligned to + * multiples of 8. The mode-setting code handles this, but + * the buffer pitch has to be aligned as well. Set the pitch + * alignment accordingly, so that the each scanline fits into + * the allocated buffer. + */ + fourcc = drm_driver_color_mode_format(drm, args->bpp); + if (fourcc == DRM_FORMAT_INVALID) + return -EINVAL; + info = drm_format_info(fourcc); + if (!info) + return -EINVAL; + pitch_align = drm_format_info_min_pitch(info, 0, SZ_8); + if (!pitch_align || pitch_align > U32_MAX) + return -EINVAL; + ret = drm_mode_size_dumb(drm, a...

Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch and buffer size. Align the pitch according to hardware requirements. Signed-off-by: Thomas Zimmermann <tzimmermann at suse.de> Cc: Laurent Pinchart <laurent.pinchart at ideasonboard.com> Cc: Tomi Valkeinen <tomi.valkeinen at ideasonboard.com> --- drivers/gpu/drm/xlnx/zynqmp_kms.c | 7 +++++-- 1 file changed, 5

...s the bpp, and adjust width accordingly, it would also have worked. So, I expect the fallback to be an exception, And by working I mean that I can run my apps fine, but the internal operation would sure be odd: allocating any YUV buffer will cause drm_mode_size_dumb() to get an RGB format from drm_driver_color_mode_format(), and get a drm_format_info_min_pitch() for an RGB format. >>>> So, I'm all for a new ioctl, but I don't right away see why the >>>> current ioctl couldn't be used. Which makes me wonder about the >>>> drm_warn() in your patch, and the "user...

...64 bitspp >> >> This worked, and if I look at the DRM_IOCTL_MODE_CREATE_DUMB in the >> docs, I can't right away see anything there that says my tactic was >> not allowed. >> >> The above doesn't work anymore with this patch, as the code calls >> drm_driver_color_mode_format(), which fails for 64 bitspp. It feels a >> bit odd that DRM_IOCTL_MODE_CREATE_DUMB will try to guess the RGB >> fourcc for a dumb buffer allocation. >> >> So, what to do here? Am I doing something silly? What's the correct >> way to allocate the buffers for XV1...

...> + * For example XRGB8888 and BGRX8888 both have a color mode of 32. >> + * It is possible to use different formats for dumb-buffer allocation >> + * and rendering as long as all involved formats share the same >> + * color-mode constant. >> + */ >> + fourcc = drm_driver_color_mode_format(dev, args->bpp); > This will return -EINVAL with bpp drm_mode_legacy_fb_format doesn't support, > such as(NV15, NV20, NV30, bpp is 10)[0] Thanks for taking a look. That NV-related code at [0] is a 'somewhat non-idiomatic use' of the UAPI. The dumb-buffer interface really just...