search for: drm_mode_size_dumb

...c alignments. The calculation of these values is inconsistent and duplicated among drivers. The results for formats with bpp < 8 are incorrect. This series fixes this for most drivers. Default scanline pitch and buffer size are now calculated with the existing 4CC helpers. There is a new helper drm_mode_size_dumb() that calculates scanline pitch and buffer size according to driver requirements. The series fixes the common GEM implementations for DMA, SHMEM and VRAM. It further changes most implementations of dumb_create to use the new helper. A small number of drivers has more complicated calculations and...

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&g...

Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch and buffer size. Align the pitch to a multiple of 8. Signed-off-by: Thomas Zimmermann <tzimmermann at suse.de> Cc: Tomi Valkeinen <tomi.valkeinen at ideasonboard.com> --- drivers/gpu/drm/omapdrm/omap_gem.c | 15 +++++++-------- 1 file changed, 7...

Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch and buffer size. No alignment required. Signed-off-by: Thomas Zimmermann <tzimmermann at suse.de> Cc: Zack Rusin <zack.rusin at broadcom.com> Cc: Broadcom internal kernel review list <bcm-kernel-feedback-list at broadcom.com> --- drivers/g...

Hi! On 09/01/2025 16:57, Thomas Zimmermann wrote: > 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.valkei...

Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch and buffer size. The hardware requires the scnaline pitch to be a multiple of 32 pixels. Therefore compute the byte size of 32 pixels in the given color mode and align the pitch accordingly. Signed-off-by: Thomas Zimmermann <tzimmermann at suse.de> Cc:...

Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch and buffer size. The hardware requires the framebuffer width to be a multiple of 8. The scanline pitch has be large enough to support this. Therefore compute the byte size of 8 pixels in the given color mode and align the pitch accordingly. Signed-off-by: Th...

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: Sui Jingfeng <suijingfeng at loongson.cn> Cc: Sui Jingfeng <sui.jingfeng at linux.dev> --- drivers/gpu/drm/l...

Hi Am 15.01.25 um 11:13 schrieb Tomi Valkeinen: > Hi! > > On 09/01/2025 16:57, Thomas Zimmermann wrote: >> 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 Valkei...

...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 why we would want to change the behavior of CREATE_DUMB. I see no upside, but I see the chance of regressions. Tomi

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 >

Hi, On 15/01/2025 12:26, Thomas Zimmermann wrote: > Hi > > > Am 15.01.25 um 11:13 schrieb Tomi Valkeinen: >> Hi! >> >> On 09/01/2025 16:57, Thomas Zimmermann wrote: >>> 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> >>...

...bit of code duplication >> among DRM's memory managers. Each calculates scanline pitch and >> buffer size from the given arguments, but the implementations are >> inconsistent in how they treat alignment and format support. Later >> patches will unify this code on top of drm_mode_size_dumb() as >> much as possible. >> >> drm_mode_size_dumb() uses existing 4CC format helpers to interpret the >> given color mode. This makes the dumb-buffer interface behave similar >> the kernel's video= parameter. Again, current per-driver implementations >> like...

...river_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() which just calculates using the bpp, without the drm_driver_color_mode_format() path? Or does the drm_driver_color_mode_format() path provide some value for the drivers that do not currently do anything similar? Tomi

...d > 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() which just > calculates using the bpp, without the drm_driver_color_mode_format() > path? Or does the drm_driver_color_mode_format() path provide some > value for the drivers that do not currently do anything similar? With the RGB-only rule, using drm_driver_color_mode_format() makes...

On Wed, 15 Jan 2025 at 14:20, Tomi Valkeinen <tomi.valkeinen at ideasonboard.com> wrote: > No disagreement there, we need CREATE_DUMB2. > > My point is that we have the current UAPI, and we have userspace using > it, but we don't have clear rules what the ioctl does with specific > parameters, and we don't document how it has to be used. > > Perhaps the situation

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: > >

On Wed, Jan 15, 2025 at 02:34:26PM +0000, Daniel Stone wrote: > On Wed, 15 Jan 2025 at 14:20, Tomi Valkeinen wrote: > > No disagreement there, we need CREATE_DUMB2. > > > > My point is that we have the current UAPI, and we have userspace using > > it, but we don't have clear rules what the ioctl does with specific > > parameters, and we don't document how

On Thu, Jan 16, 2025 at 10:43:40AM +0200, Laurent Pinchart wrote: > On Wed, Jan 15, 2025 at 02:34:26PM +0000, Daniel Stone wrote: > > On Wed, 15 Jan 2025 at 14:20, Tomi Valkeinen wrote: > > > No disagreement there, we need CREATE_DUMB2. > > > > > > My point is that we have the current UAPI, and we have userspace using > > > it, but we don't have

...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() which just > >> calculates using the bpp, without the drm_driver_color_mode_format() > >> path? Or does the drm_driver_color_mode_format() path provide some > >> value for the drivers that do not currently do anything similar? > > > > With the RGB-only rule,...