search for: create_dumb

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

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. > > > > > > Per...

...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, 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...

...n 15/01/2025 13:37, Thomas Zimmermann wrote: > Hi > > > Am 15.01.25 um 11:58 schrieb Tomi Valkeinen: > [...] >>> These are all good points. Did you read my discussion with Andy on >>> patch 2? I think it resolves all the points you have. The current >>> CREATE_DUMB >> >> I had missed the discussion, and, indeed, the patch you attached fixes >> the problem on Xilinx. > > Great. Thanks for testing. > >> >>> ioctl is unsuited for anything but the simple RGB formats. The bpp >> >> It's a bit difficult...

...mermann wrote: >> Hi >> >> >> Am 15.01.25 um 11:58 schrieb Tomi Valkeinen: >> [...] >>>> These are all good points. Did you read my discussion with Andy on >>>> patch 2? I think it resolves all the points you have. The current >>>> CREATE_DUMB >>> >>> I had missed the discussion, and, indeed, the patch you attached >>> fixes the problem on Xilinx. >> >> Great. Thanks for testing. >> >>> >>>> ioctl is unsuited for anything but the simple RGB formats. The bpp >>>...

...e 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 simple RGB formats, and the > > >> behavior for all other formats is platform specific. But I think even > > >> that would be valuable in the UAPI docs. > > > > > > To be honest, I would not want to specify behavior for anything but...

...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 simple RGB formats, and the >> behavior for all other formats is platform specific. But I think even >> that would be valuable in the UAPI docs. > > To be honest, I would not want to specify behavior for anything but the > linear RGB formats. If anyt...

Hi Am 15.01.25 um 11:58 schrieb Tomi Valkeinen: [...] >> These are all good points. Did you read my discussion with Andy on >> patch 2? I think it resolves all the points you have. The current >> CREATE_DUMB > > I had missed the discussion, and, indeed, the patch you attached fixes > the problem on Xilinx. Great. Thanks for testing. > >> ioctl is unsuited for anything but the simple RGB formats. The bpp > > It's a bit difficult to use, but is it really unsuited? bitsper...

...API, 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 simple RGB formats, and the > >> behavior for all other formats is platform specific. But I think even > >> that would be valuable in the UAPI docs. > > > > To be honest, I would not want to specify behavior for anything but the > > linear...

...gt; 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 simple RGB formats, and the > behavior for all other formats is platform specific. But I think even > that would be valuable in the UAPI docs. To be honest, I would not want to specify behavior for anything but the linear RGB formats. If anything, I'd take Dani...

...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 why we would want to change the behavior of CREATE_DUMB. I...

...n'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 simple RGB formats, and the >>>>>>> behavior for all other formats is platform specific. But I think >>>>>>> even >>>>>>> that would be valuable in the UAPI docs. >>>>>> To be honest, I would n...

...t;>>>> 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 simple RGB formats, and the >>>>> behavior for all other formats is platform specific. But I think even >>>>> that would be valuable in the UAPI docs. >>>> To be honest, I would not want to specify behavior for anything but the >&...

...t; 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 simple RGB formats, and the >>>>>> behavior for all other formats is platform specific. But I think even >>>>>> that would be valuable in the UAPI docs. >>>>> To be honest, I would not want to specify behavior for anything b...

On 19/01/2025 16:59, Sui Jingfeng wrote: >>>> But userspace must be able to continue allocating YUV buffers through >>>> CREATE_DUMB. >>> >>> I think, allocating YUV buffers through CREATE_DUMB interface is just >>> an *abuse* and *misuse* of this API for now. >>> >>> Take the NV12 format as an example, NV12 is YUV420 planar format, have >>> two planar: the Y-planar and the U...

...rains 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: >> >> If (bpp < 8 || is_power_of_two(bpp)) >> ????bpp means bitsperpixel >> ????pitch is args->width * args->bpp / 8, aligned up to driver- >> specific-align >> else >> ????bpp is a legacy parameter, and we deal with it case by case. &g...

...gt;>> >>> >>> Am 15.01.25 um 11:58 schrieb Tomi Valkeinen: >>> [...] >>>>> These are all good points. Did you read my discussion with Andy on >>>>> patch 2? I think it resolves all the points you have. The current >>>>> CREATE_DUMB >>>> >>>> I had missed the discussion, and, indeed, the patch you attached >>>> fixes the problem on Xilinx. >>> >>> Great. Thanks for testing. >>> >>>> >>>>> ioctl is unsuited for anything but the simple RG...

...a different use case. Best regards Thomas > > Harmonizing code is fine, but I think that can be done with a function > that only does the fallback-case. > > So... I can only speak for the platforms I'm using and maintaining, > but I'd rather keep the old behavior for CREATE_DUMB that we've had > for ages. > > ?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)

Hi, On 2025/1/19 23:22, Tomi Valkeinen wrote: > On 19/01/2025 16:59, Sui Jingfeng wrote: > >>>>> But userspace must be able to continue allocating YUV buffers through >>>>> CREATE_DUMB. >>>> >>>> I think, allocating YUV buffers through CREATE_DUMB interface is just >>>> an *abuse* and *misuse* of this API for now. >>>> >>>> Take the NV12 format as an example, NV12 is YUV420 planar format, have >>>> two planar...