search for: create_dumb2

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 clear rules what the ioctl does with specific > > > parameters, and we don't document how it has to be used. > > > > > > Perh...

...On 16/01/2025 11:38, Laurent Pinchart wrote: > 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 clear rules what the ioctl does with specific >>>> parameters, and we don't document how it has to be used. >>>> >>&...

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 it has to be used. > > > > Perhaps the situation is bad, and...

...itations 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 various hardware. > That affects dumb buffers as well. I don't think that there's an > immediate need for a CREATE_DUMB2, but it seems worth to keep in mind. Yes, the current CREATE_DUMB can't cover all the hardware. We do need CREATE_DUMB2, sooner or later. I just hope we can define and document a set of rules that allows using CREATE_DUMB for the cases where it sensibly works (and is already being used)....

...ave 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 various hardware. That affects dumb buffers as well. I don't think that there's an immediate need for a CREATE_DUMB2, but it seems worth to keep in mind. Best regards Thomas > > ?Tomi > -- -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Frankenstrasse 146, 90461 Nuernberg, Germany GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman HRB 36809 (AG Nuernberg...

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 is bad, and all we can really say is that...

...ossible to encode all this in a simple 32-bit value. So user- > space code has to be aware of all this and tweak bpp-based allocation to > make it work. Obviously you can use the current UAPI for your use case. > It's just not optimal or future proof. 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 is bad, and all we can really say is that CREATE_DUMB only works fo...

...ly the driver >> knows about. For example, there's another discussion on dri-devel >> about pitch- alignment requirements of DRM_FORMAT_MOD_LINEAR on >> various hardware. That affects dumb buffers as well. I don't think >> that there's an immediate need for a CREATE_DUMB2, but it seems worth >> to keep in mind. > > Yes, the current CREATE_DUMB can't cover all the hardware. We do need > CREATE_DUMB2, sooner or later. I just hope we can define and document > a set of rules that allows using CREATE_DUMB for the cases where it > sensibly wor...

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

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:

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.valkeinen at

...arge enough buffer via the current CREATE_DUMB and compute the individual planes itself. See [1] for an example. [1] https://gitlab.freedesktop.org/mesa/drm/-/blob/main/tests/modetest/buffers.c?ref_type=heads#L302 Does this work for you? Otherwise, I guess we should be talking about a possible CREATE_DUMB2 that fixes these shortcomings. Best regards Thomas > > ?Tomi > -- -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Frankenstrasse 146, 90461 Nuernberg, Germany GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman HRB 36809 (AG Nuernberg)