search for: multiplanar

...l >>> plane. >> >> Yes, I think that makes sense. That's a long road, though =). So my >> question is, is CREATE_DUMB really unsuitable for other than simple >> RGB formats, or can it be suitable if we just define how the userspace >> should use it for multiplanar, subsampled formats? > > That would duplicate format and hardware information in user-space. Some But we already have that, don't we? We have drivers and userspace that support, say, NV12 via dumb buffers. But (correct me if I'm wrong) we don't document how CREATE_DUMB has to...

...e. >>> >>> Yes, I think that makes sense. That's a long road, though =). So my >>> question is, is CREATE_DUMB really unsuitable for other than simple >>> RGB formats, or can it be suitable if we just define how the >>> userspace should use it for multiplanar, subsampled formats? >> >> That would duplicate format and hardware information in user-space. Some > > But we already have that, don't we? We have drivers and userspace that > support, say, NV12 via dumb buffers. But (correct me if I'm wrong) we > don't docum...

...uffer for each individual >> plane. > > Yes, I think that makes sense. That's a long road, though =). So my > question is, is CREATE_DUMB really unsuitable for other than simple > RGB formats, or can it be suitable if we just define how the userspace > should use it for multiplanar, subsampled formats? That would duplicate format and hardware information in user-space. Some hardware might have odd per-plane limitations that only the driver knows about. For example, there's another discussion on dri-devel about pitch-alignment requirements of DRM_FORMAT_MOD_LINEAR on v...

...sting odd cases that already bend the UAPI's rules. > > I have to disagree here. > > On the platforms I have been using (omap, tidss, xilinx, rcar) the dumb > buffers are the only buffers you can get from the DRM driver. The dumb > buffers have been used to allocate linear and multiplanar YUV buffers > for a very long time on those platforms. > > I tried to look around, but I did not find any mentions that CREATE_DUMB > should only be used for RGB buffers. Is anyone outside the core > developers even aware of it? > > If we don't use dumb buffers there, where...

...end the UAPI's rules. > > > > I have to disagree here. > > > > On the platforms I have been using (omap, tidss, xilinx, rcar) the dumb > > buffers are the only buffers you can get from the DRM driver. The dumb > > buffers have been used to allocate linear and multiplanar YUV buffers > > for a very long time on those platforms. > > > > I tried to look around, but I did not find any mentions that CREATE_DUMB > > should only be used for RGB buffers. Is anyone outside the core > > developers even aware of it? > > > > If we don&...

...>>>> Yes, I think that makes sense. That's a long road, though =). So my >>>> question is, is CREATE_DUMB really unsuitable for other than simple >>>> RGB formats, or can it be suitable if we just define how the >>>> userspace should use it for multiplanar, subsampled formats? >>> >>> That would duplicate format and hardware information in user-space. Some >> >> But we already have that, don't we? We have drivers and userspace that >> support, say, NV12 via dumb buffers. But (correct me if I'm wrong) we...

...e DRM format and returns a buffer for each individual > plane. Yes, I think that makes sense. That's a long road, though =). So my question is, is CREATE_DUMB really unsuitable for other than simple RGB formats, or can it be suitable if we just define how the userspace should use it for multiplanar, subsampled formats? Tomi

...d because of the > existing odd cases that already bend the UAPI's rules. I have to disagree here. On the platforms I have been using (omap, tidss, xilinx, rcar) the dumb buffers are the only buffers you can get from the DRM driver. The dumb buffers have been used to allocate linear and multiplanar YUV buffers for a very long time on those platforms. I tried to look around, but I did not find any mentions that CREATE_DUMB should only be used for RGB buffers. Is anyone outside the core developers even aware of it? If we don't use dumb buffers there, where do we get the buffers? Maybe...

...he UAPI's rules. >>> I have to disagree here. >>> >>> On the platforms I have been using (omap, tidss, xilinx, rcar) the dumb >>> buffers are the only buffers you can get from the DRM driver. The dumb >>> buffers have been used to allocate linear and multiplanar YUV buffers >>> for a very long time on those platforms. >>> >>> I tried to look around, but I did not find any mentions that CREATE_DUMB >>> should only be used for RGB buffers. Is anyone outside the core >>> developers even aware of it? >>> &g...

...>>>> I have to disagree here. >>>> >>>> On the platforms I have been using (omap, tidss, xilinx, rcar) the dumb >>>> buffers are the only buffers you can get from the DRM driver. The dumb >>>> buffers have been used to allocate linear and multiplanar YUV buffers >>>> for a very long time on those platforms. >>>> >>>> I tried to look around, but I did not find any mentions that >>>> CREATE_DUMB >>>> should only be used for RGB buffers. Is anyone outside the core >>>> develo...

Hi Am 15.01.25 um 15:20 schrieb Tomi Valkeinen: [...] > > 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 is bad, and all we can really say is that > CREATE_DUMB only works for use with

...gt; >>>>> On the platforms I have been using (omap, tidss, xilinx, rcar) the >>>>> dumb >>>>> buffers are the only buffers you can get from the DRM driver. The >>>>> dumb >>>>> buffers have been used to allocate linear and multiplanar YUV buffers >>>>> for a very long time on those platforms. >>>>> >>>>> I tried to look around, but I did not find any mentions that >>>>> CREATE_DUMB >>>>> should only be used for RGB buffers. Is anyone outside the core &gt...

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