From: Pekka Paalanen <ppaalanen@gmail.com>
To: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
Cc: dri-devel@lists.freedesktop.org,
"Simon Ser" <contact@emersion.fr>,
intel-gfx@lists.freedesktop.org,
"Jonas Ådahl" <jadahl@redhat.com>,
"Daniel Stone" <daniel@fooishbar.org>
Subject: Re: [Intel-gfx] [PATCH 1/2] drm: Introduce plane SIZE_HINTS property
Date: Tue, 14 Feb 2023 11:42:27 +0200 [thread overview]
Message-ID: <20230214114227.7fa94b78@eldfell> (raw)
In-Reply-To: <20230209135105.4137872c.pekka.paalanen@collabora.com>
[-- Attachment #1: Type: text/plain, Size: 969 bytes --]
On Thu, 9 Feb 2023 13:51:05 +0200
Pekka Paalanen <pekka.paalanen@collabora.com> wrote:
> Maybe we could refine this so that userspace uses the stride and height
> implied by the caps for allocation, and then use the exact cursor image
> size for AddFB2? And have drivers pick any size between those two they
> can use. The kernel would need the userspace to promise that the
> padding is always zero-initialized, so the driver can simply scan out
> any area of the buffer it needs.
>
> Then we don't need SIZE_HINTS.
Would there be any problem with this?
If this works, it would seem the superior solution to me, because
userspace does not need to guess or test for the exact right size.
Simply allocate at the CAP size, pad the cursor image with transparent
pixels, and let the kernel scan out the optimal area.
And if the kernel needs to do a pixel format conversion, it only needs
to do the optimal minimum amount of work.
Thanks,
pq
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Pekka Paalanen <ppaalanen@gmail.com>
To: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
Cc: dri-devel@lists.freedesktop.org, intel-gfx@lists.freedesktop.org,
"Jonas Ådahl" <jadahl@redhat.com>
Subject: Re: [Intel-gfx] [PATCH 1/2] drm: Introduce plane SIZE_HINTS property
Date: Tue, 14 Feb 2023 11:42:27 +0200 [thread overview]
Message-ID: <20230214114227.7fa94b78@eldfell> (raw)
In-Reply-To: <20230209135105.4137872c.pekka.paalanen@collabora.com>
[-- Attachment #1: Type: text/plain, Size: 969 bytes --]
On Thu, 9 Feb 2023 13:51:05 +0200
Pekka Paalanen <pekka.paalanen@collabora.com> wrote:
> Maybe we could refine this so that userspace uses the stride and height
> implied by the caps for allocation, and then use the exact cursor image
> size for AddFB2? And have drivers pick any size between those two they
> can use. The kernel would need the userspace to promise that the
> padding is always zero-initialized, so the driver can simply scan out
> any area of the buffer it needs.
>
> Then we don't need SIZE_HINTS.
Would there be any problem with this?
If this works, it would seem the superior solution to me, because
userspace does not need to guess or test for the exact right size.
Simply allocate at the CAP size, pad the cursor image with transparent
pixels, and let the kernel scan out the optimal area.
And if the kernel needs to do a pixel format conversion, it only needs
to do the optimal minimum amount of work.
Thanks,
pq
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2023-02-14 9:42 UTC|newest]
Thread overview: 78+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-08 4:09 [Intel-gfx] [PATCH 0/2] drm: Add plane SIZE_HINTS property Ville Syrjala
2023-02-08 4:09 ` Ville Syrjala
2023-02-08 4:09 ` [Intel-gfx] [PATCH 1/2] drm: Introduce " Ville Syrjala
2023-02-08 4:09 ` Ville Syrjala
2023-02-08 6:09 ` [Intel-gfx] " kernel test robot
2023-02-08 6:09 ` kernel test robot
2023-02-08 6:09 ` kernel test robot
2023-02-08 6:09 ` kernel test robot
2023-02-08 6:09 ` kernel test robot
2023-02-08 6:09 ` kernel test robot
2023-02-08 12:13 ` Pekka Paalanen
2023-02-08 12:13 ` Pekka Paalanen
2023-02-08 13:03 ` [Intel-gfx] " Ville Syrjälä
2023-02-08 13:03 ` Ville Syrjälä
2023-02-08 21:16 ` [Intel-gfx] " Ville Syrjälä
2023-02-08 21:16 ` Ville Syrjälä
2023-02-09 11:51 ` Pekka Paalanen
2023-02-09 11:51 ` Pekka Paalanen
2023-02-14 9:42 ` Pekka Paalanen [this message]
2023-02-14 9:42 ` Pekka Paalanen
2023-02-14 10:27 ` Ville Syrjälä
2023-02-14 10:27 ` Ville Syrjälä
2023-02-14 11:17 ` Pekka Paalanen
2023-02-14 11:17 ` Pekka Paalanen
2023-02-14 11:35 ` Ville Syrjälä
2023-02-14 11:35 ` Ville Syrjälä
2023-02-08 16:51 ` Harry Wentland
2023-02-08 16:51 ` Harry Wentland
2023-02-08 21:10 ` [Intel-gfx] [PATCH v2 " Ville Syrjala
2023-02-08 21:10 ` Ville Syrjala
2023-02-09 11:58 ` [Intel-gfx] " Pekka Paalanen
2023-02-09 11:58 ` Pekka Paalanen
2023-02-09 13:10 ` [Intel-gfx] " Ville Syrjälä
2023-02-09 13:10 ` Ville Syrjälä
2023-02-10 9:44 ` [Intel-gfx] " Pekka Paalanen
2023-02-10 9:44 ` Pekka Paalanen
2023-02-09 14:16 ` [Intel-gfx] " Jonas Ådahl
2023-02-09 14:16 ` Jonas Ådahl
2023-02-14 9:25 ` [Intel-gfx] " Ville Syrjälä
2023-02-14 9:25 ` Ville Syrjälä
2023-02-14 9:54 ` [Intel-gfx] " Jonas Ådahl
2023-02-14 9:54 ` Jonas Ådahl
2023-02-14 10:28 ` [Intel-gfx] " Ville Syrjälä
2023-02-14 10:28 ` Ville Syrjälä
2023-02-14 11:01 ` [Intel-gfx] " Jonas Ådahl
2023-02-14 11:01 ` Jonas Ådahl
2023-02-14 11:19 ` [Intel-gfx] " Ville Syrjälä
2023-02-14 11:19 ` Ville Syrjälä
2023-02-22 18:34 ` [Intel-gfx] " Ville Syrjälä
2023-02-22 18:34 ` Ville Syrjälä
2023-02-14 19:27 ` [Intel-gfx] " Harry Wentland
2023-02-14 19:27 ` Harry Wentland
2023-02-14 19:59 ` [Intel-gfx] " Ville Syrjälä
2023-02-14 19:59 ` Ville Syrjälä
2023-03-13 16:33 ` [Intel-gfx] [PATCH v3 " Ville Syrjala
2023-03-13 16:33 ` Ville Syrjala
2023-03-17 10:34 ` [Intel-gfx] " Jonas Ådahl
2023-03-17 10:34 ` Jonas Ådahl
2023-03-17 11:33 ` [Intel-gfx] " Ville Syrjälä
2023-03-17 11:33 ` Ville Syrjälä
2023-03-17 12:21 ` [Intel-gfx] " Jonas Ådahl
2023-03-17 12:21 ` Jonas Ådahl
2023-03-17 12:29 ` [Intel-gfx] " Jonas Ådahl
2023-03-17 12:29 ` Jonas Ådahl
2023-03-17 13:15 ` [Intel-gfx] " Ville Syrjälä
2023-03-17 13:15 ` Ville Syrjälä
2023-03-17 13:18 ` [Intel-gfx] " Jonas Ådahl
2023-03-17 13:18 ` Jonas Ådahl
2023-03-17 13:13 ` [Intel-gfx] " Ville Syrjälä
2023-03-17 13:13 ` Ville Syrjälä
2023-02-08 4:09 ` [Intel-gfx] [PATCH 2/2] drm/i915: Add SIZE_HINTS property for cursors Ville Syrjala
2023-02-08 4:09 ` Ville Syrjala
2023-02-08 4:50 ` [Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm: Add plane SIZE_HINTS property Patchwork
2023-02-08 5:17 ` [Intel-gfx] ✗ Fi.CI.BAT: failure " Patchwork
2023-02-08 23:15 ` [Intel-gfx] ✓ Fi.CI.BAT: success for drm: Add plane SIZE_HINTS property (rev2) Patchwork
2023-02-09 21:27 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
2023-03-13 17:49 ` [Intel-gfx] ✓ Fi.CI.BAT: success for drm: Add plane SIZE_HINTS property (rev3) Patchwork
2023-03-14 21:59 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230214114227.7fa94b78@eldfell \
--to=ppaalanen@gmail.com \
--cc=contact@emersion.fr \
--cc=daniel@fooishbar.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jadahl@redhat.com \
--cc=ville.syrjala@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.