Revision tags: v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12, v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5, v6.6.4, v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6, v6.5.9 |
|
#
87b3b45c |
| 23-Oct-2023 |
Zack Rusin <zackr@vmware.com> |
drm: Disable the cursor plane on atomic contexts with virtualized drivers
commit 4e3b70da64a53784683cfcbac2deda5d6e540407 upstream.
Cursor planes on virtualized drivers have special meaning and req
drm: Disable the cursor plane on atomic contexts with virtualized drivers
commit 4e3b70da64a53784683cfcbac2deda5d6e540407 upstream.
Cursor planes on virtualized drivers have special meaning and require that the clients handle them in specific ways, e.g. the cursor plane should react to the mouse movement the way a mouse cursor would be expected to and the client is required to set hotspot properties on it in order for the mouse events to be routed correctly.
This breaks the contract as specified by the "universal planes". Fix it by disabling the cursor planes on virtualized drivers while adding a foundation on top of which it's possible to special case mouse cursor planes for clients that want it.
Disabling the cursor planes makes some kms compositors which were broken, e.g. Weston, fallback to software cursor which works fine or at least better than currently while having no effect on others, e.g. gnome-shell or kwin, which put virtualized drivers on a deny-list when running in atomic context to make them fallback to legacy kms and avoid this issue.
Signed-off-by: Zack Rusin <zackr@vmware.com> Fixes: 681e7ec73044 ("drm: Allow userspace to ask for universal plane list (v2)") Cc: <stable@vger.kernel.org> # v5.4+ Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Dave Airlie <airlied@redhat.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Hans de Goede <hdegoede@redhat.com> Cc: Gurchetan Singh <gurchetansingh@chromium.org> Cc: Chia-I Wu <olvaffe@gmail.com> Cc: dri-devel@lists.freedesktop.org Cc: virtualization@lists.linux-foundation.org Cc: spice-devel@lists.freedesktop.org Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Acked-by: Simon Ser <contact@emersion.fr> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231023074613.41327-2-aesteve@redhat.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
d7afdf36 |
| 11-Dec-2023 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm: Don't unref the same fb many times by mistake due to deadlock handling
commit cb4daf271302d71a6b9a7c01bd0b6d76febd8f0c upstream.
If we get a deadlock after the fb lookup in drm_mode_page_flip_
drm: Don't unref the same fb many times by mistake due to deadlock handling
commit cb4daf271302d71a6b9a7c01bd0b6d76febd8f0c upstream.
If we get a deadlock after the fb lookup in drm_mode_page_flip_ioctl() we proceed to unref the fb and then retry the whole thing from the top. But we forget to reset the fb pointer back to NULL, and so if we then get another error during the retry, before the fb lookup, we proceed the unref the same fb again without having gotten another reference. The end result is that the fb will (eventually) end up being freed while it's still in use.
Reset fb to NULL once we've unreffed it to avoid doing it again until we've done another fb lookup.
This turned out to be pretty easy to hit on a DG2 when doing async flips (and CONFIG_DEBUG_WW_MUTEX_SLOWPATH=y). The first symptom I saw that drm_closefb() simply got stuck in a busy loop while walking the framebuffer list. Fortunately I was able to convince it to oops instead, and from there it was easier to track down the culprit.
Cc: stable@vger.kernel.org Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231211081625.25704-1-ville.syrjala@linux.intel.com Acked-by: Javier Martinez Canillas <javierm@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v6.5.8, v6.5.7, v6.5.6, v6.5.5, v6.5.4, v6.5.3, v6.5.2, v6.1.51, v6.5.1, v6.1.50, v6.5, v6.1.49, v6.1.48, v6.1.46, v6.1.45, v6.1.44, v6.1.43, v6.1.42, v6.1.41, v6.1.40, v6.1.39, v6.1.38, v6.1.37, v6.1.36, v6.4, v6.1.35, v6.1.34, v6.1.33, v6.1.32, v6.1.31, v6.1.30, v6.1.29, v6.1.28, v6.1.27, v6.1.26, v6.3, v6.1.25, v6.1.24, v6.1.23, v6.1.22, v6.1.21, v6.1.20, v6.1.19, v6.1.18, v6.1.17, v6.1.16, v6.1.15, v6.1.14, v6.1.13, v6.2, v6.1.12, v6.1.11, v6.1.10, v6.1.9, v6.1.8, v6.1.7, v6.1.6, v6.1.5, v6.0.19, v6.0.18, v6.1.4, v6.1.3, v6.0.17 |
|
#
51342cc0 |
| 03-Jan-2023 |
Sean Paul <seanpaul@chromium.org> |
drm/docs: Explicitly document default CRTC background behavior
Add a paragraph explaining that the default behavior for areas which are not covered by planes or where planes are blending with the CR
drm/docs: Explicitly document default CRTC background behavior
Add a paragraph explaining that the default behavior for areas which are not covered by planes or where planes are blending with the CRTC background, is black.
This is alluded to in the "pixel blend mode" property docs, but not called out explicitly.
Reviewed-by: Simon Ser <contact@emersion.fr> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230103152738.1213785-1-sean@poorly.run
show more ...
|
Revision tags: v6.1.2, v6.0.16, v6.1.1, v6.0.15, v6.0.14, v6.0.13, v6.1, v6.0.12, v6.0.11, v6.0.10, v5.15.80, v6.0.9, v5.15.79, v6.0.8, v5.15.78, v6.0.7, v5.15.77, v5.15.76, v6.0.6, v6.0.5, v5.15.75, v6.0.4, v6.0.3, v6.0.2, v5.15.74, v5.15.73, v6.0.1, v5.15.72, v6.0, v5.15.71, v5.15.70, v5.15.69, v5.15.68 |
|
#
e71def05 |
| 09-Sep-2022 |
Thomas Zimmermann <tzimmermann@suse.de> |
drm/plane: Allocate planes with drm_universal_plane_alloc()
Provide drm_univeral_plane_alloc() to allocate and initialize a plane. Code for non-atomic drivers uses this pattern. Convert them to the
drm/plane: Allocate planes with drm_universal_plane_alloc()
Provide drm_univeral_plane_alloc() to allocate and initialize a plane. Code for non-atomic drivers uses this pattern. Convert them to the new function. The modeset helpers contain a quirk for handling their color formats differently. Set the flag outside plane allocation.
The new function is already deprecated to some extend. Drivers should rather use drmm_univeral_plane_alloc() or drm_universal_plane_init().
v2: * kerneldoc fixes (Javier) * grammar fixes in commit message
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com> # nouveau Link: https://patchwork.freedesktop.org/patch/msgid/20220909105947.6487-3-tzimmermann@suse.de
show more ...
|
#
7221941c |
| 09-Sep-2022 |
Thomas Zimmermann <tzimmermann@suse.de> |
drm/plane: Remove drm_plane_init()
Open-code drm_plane_init() and remove the function from DRM. The implementation of drm_plane_init() is a simple wrapper around a call to drm_universal_plane_init()
drm/plane: Remove drm_plane_init()
Open-code drm_plane_init() and remove the function from DRM. The implementation of drm_plane_init() is a simple wrapper around a call to drm_universal_plane_init(), so drivers can just use that instead.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Lyude Paul <lyude@redhat.com> # nouveau Acked-by: Jyri Sarha <jyri.sarha@iki.fi> Link: https://patchwork.freedesktop.org/patch/msgid/20220909105947.6487-2-tzimmermann@suse.de
show more ...
|
Revision tags: v5.15.67, v5.15.66, v5.15.65, v5.15.64, v5.15.63, v5.15.62, v5.15.61, v5.15.60, v5.15.59, v5.19, v5.15.58, v5.15.57, v5.15.56, v5.15.55, v5.15.54, v5.15.53, v5.15.52, v5.15.51, v5.15.50, v5.15.49, v5.15.48, v5.15.47, v5.15.46, v5.15.45, v5.15.44, v5.15.43, v5.15.42, v5.18, v5.15.41, v5.15.40, v5.15.39, v5.15.38, v5.15.37, v5.15.36, v5.15.35, v5.15.34, v5.15.33, v5.15.32, v5.15.31, v5.17, v5.15.30, v5.15.29, v5.15.28, v5.15.27, v5.15.26, v5.15.25, v5.15.24, v5.15.23, v5.15.22, v5.15.21, v5.15.20, v5.15.19, v5.15.18, v5.15.17, v5.4.173, v5.15.16, v5.15.15, v5.16, v5.15.10, v5.15.9, v5.15.8, v5.15.7 |
|
#
4b674dd6 |
| 03-Dec-2021 |
Steven Price <steven.price@arm.com> |
drm/plane: Move range check for format_count earlier
While the check for format_count > 64 in __drm_universal_plane_init() shouldn't be hit (it's a WARN_ON), in its current position it will then lea
drm/plane: Move range check for format_count earlier
While the check for format_count > 64 in __drm_universal_plane_init() shouldn't be hit (it's a WARN_ON), in its current position it will then leak the plane->format_types array and fail to call drm_mode_object_unregister() leaking the modeset identifier. Move it to the start of the function to avoid allocating those resources in the first place.
Signed-off-by: Steven Price <steven.price@arm.com> Signed-off-by: Liviu Dudau <liviu.dudau@arm.com> Link: https://lore.kernel.org/dri-devel/20211203102815.38624-1-steven.price@arm.com/
show more ...
|
#
8be57683 |
| 28-Jan-2022 |
Tomohito Esaki <etom@igel.co.jp> |
drm: add support modifiers for drivers whose planes only support linear layout
The LINEAR modifier is advertised as default if a driver doesn't specify modifiers.
v2: - rebase to the latest master
drm: add support modifiers for drivers whose planes only support linear layout
The LINEAR modifier is advertised as default if a driver doesn't specify modifiers.
v2: - rebase to the latest master branch (5.16.0+) + "drm/plane: Make format_mod_supported truly optional" patch [1] [1] https://patchwork.freedesktop.org/patch/467940/?series=98255&rev=3
v3: - change the order as follows: 1. add fb_modifiers_not_supported flag 2. add default modifiers 3. remove allow_fb_modifiers flag
v5: - change default_modifiers array from non-static to static - remove terminator in default_modifiers array - use ARRAY_SIZE to get the format_modifier_count - update sanity check in plane init func to use the fb_modifiers_not_supported - modify kernel docs
Signed-off-by: Tomohito Esaki <etom@igel.co.jp> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20220128060836.11216-3-etom@igel.co.jp
show more ...
|
#
d14f0c20 |
| 26-Dec-2021 |
José Expósito <jose.exposito89@gmail.com> |
drm/plane: Make format_mod_supported truly optional
The documentation for "drm_plane_funcs.format_mod_supported" reads:
This *optional* hook is used for the DRM to determine if the given format
drm/plane: Make format_mod_supported truly optional
The documentation for "drm_plane_funcs.format_mod_supported" reads:
This *optional* hook is used for the DRM to determine if the given format/modifier combination is valid for the plane. This allows the DRM to generate the correct format bitmask (which formats apply to which modifier), and to validate modifiers at atomic_check time.
*If not present*, then any modifier in the plane's modifier list is allowed with any of the plane's formats.
However, where the function is not present, an invalid IN_FORMATS blob property with modifiers but no formats is exposed to user-space.
This breaks the latest Weston [1]. For testing purposes, I extracted the affected code to a standalone program [2].
Make "create_in_format_blob" behave as documented.
[1] https://gitlab.freedesktop.org/wayland/weston/-/blob/9.0/libweston/backend-drm/kms.c#L431 [2] https://github.com/JoseExposito/drm-sandbox/blob/main/in_formats.c
Signed-off-by: José Expósito <jose.exposito89@gmail.com> Reviewed-by: Simon Ser <contact@emersion.fr> Signed-off-by: Simon Ser <contact@emersion.fr> Link: https://patchwork.freedesktop.org/patch/msgid/20211226112503.31771-2-jose.exposito89@gmail.com
show more ...
|
#
978e3d02 |
| 03-Dec-2021 |
Steven Price <steven.price@arm.com> |
drm/plane: Move range check for format_count earlier
[ Upstream commit 4b674dd69701c2e22e8e7770c1706a69f3b17269 ]
While the check for format_count > 64 in __drm_universal_plane_init() shouldn't be
drm/plane: Move range check for format_count earlier
[ Upstream commit 4b674dd69701c2e22e8e7770c1706a69f3b17269 ]
While the check for format_count > 64 in __drm_universal_plane_init() shouldn't be hit (it's a WARN_ON), in its current position it will then leak the plane->format_types array and fail to call drm_mode_object_unregister() leaking the modeset identifier. Move it to the start of the function to avoid allocating those resources in the first place.
Signed-off-by: Steven Price <steven.price@arm.com> Signed-off-by: Liviu Dudau <liviu.dudau@arm.com> Link: https://lore.kernel.org/dri-devel/20211203102815.38624-1-steven.price@arm.com/ Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
#
978e3d02 |
| 03-Dec-2021 |
Steven Price <steven.price@arm.com> |
drm/plane: Move range check for format_count earlier
[ Upstream commit 4b674dd69701c2e22e8e7770c1706a69f3b17269 ]
While the check for format_count > 64 in __drm_universal_plane_init() shouldn't be
drm/plane: Move range check for format_count earlier
[ Upstream commit 4b674dd69701c2e22e8e7770c1706a69f3b17269 ]
While the check for format_count > 64 in __drm_universal_plane_init() shouldn't be hit (it's a WARN_ON), in its current position it will then leak the plane->format_types array and fail to call drm_mode_object_unregister() leaking the modeset identifier. Move it to the start of the function to avoid allocating those resources in the first place.
Signed-off-by: Steven Price <steven.price@arm.com> Signed-off-by: Liviu Dudau <liviu.dudau@arm.com> Link: https://lore.kernel.org/dri-devel/20211203102815.38624-1-steven.price@arm.com/ Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
Revision tags: v5.15.6, v5.15.5, v5.15.4, v5.15.3, v5.15.2, v5.15.1, v5.15, v5.14.14, v5.14.13, v5.14.12, v5.14.11, v5.14.10, v5.14.9, v5.14.8, v5.14.7, v5.14.6, v5.10.67, v5.10.66, v5.14.5, v5.14.4, v5.10.65, v5.14.3, v5.10.64, v5.14.2, v5.10.63, v5.14.1, v5.10.62, v5.14, v5.10.61, v5.10.60 |
|
#
0ae865ef |
| 30-Jul-2021 |
Cai Huoqing <caihuoqing@baidu.com> |
drm: Fix typo in comments
fix typo for drm
v1->v2: respin with the change "iff ==> implies that"
Signed-off-by: Cai Huoqing <caihuoqing@baidu.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll
drm: Fix typo in comments
fix typo for drm
v1->v2: respin with the change "iff ==> implies that"
Signed-off-by: Cai Huoqing <caihuoqing@baidu.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210730132729.376-1-caihuoqing@baidu.com
show more ...
|
Revision tags: v5.10.53 |
|
#
ba6cd766 |
| 23-Jul-2021 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/plane: Move drm_plane_enable_fb_damage_clips into core
We're trying to have a fairly strict split between core functionality that defines the uapi, including the docs, and the helper functions t
drm/plane: Move drm_plane_enable_fb_damage_clips into core
We're trying to have a fairly strict split between core functionality that defines the uapi, including the docs, and the helper functions to implement it.
Move drm_plane_enable_fb_damage_clips and associated kerneldoc into drm_plane from drm_damage_helper.c to fix this.
Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210723083457.696939-3-daniel.vetter@ffwll.ch
show more ...
|
#
c7fcbf25 |
| 23-Jul-2021 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/plane: check that fb_damage is set up when used
There's two stages of manual upload/invalidate displays: - just handling dirtyfb and uploading the entire fb all the time - looking at damage clip
drm/plane: check that fb_damage is set up when used
There's two stages of manual upload/invalidate displays: - just handling dirtyfb and uploading the entire fb all the time - looking at damage clips
In the latter case we support it through fbdev emulation (with fb_defio), atomic property, and with the dirtfy clip rects.
Make sure at least the atomic property is set up as the main official interface for this. Ideally we'd also check that drm_atomic_helper_dirtyfb() is used and that fbdev defio is set up, but that's quite a bit harder to do. Ideas very much welcome.
From a cursor audit drivers seem to be getting this right mostly, but better to make sure. At least no one is bypassing the accessor function.
v2: - use drm_warn_once with a meaningful warning string (José) - don't splat in the atomic check code for everyone (intel-gfx-ci)
Reviewed-by: José Roberto de Souza <jose.souza@intel.com> (v1) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210723083457.696939-2-daniel.vetter@ffwll.ch
show more ...
|
Revision tags: v5.10.52, v5.10.51, v5.10.50, v5.10.49, v5.13, v5.10.46, v5.10.43, v5.10.42, v5.10.41, v5.10.40, v5.10.39, v5.4.119, v5.10.36, v5.10.35 |
|
#
bfebd42d |
| 06-May-2021 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/modifiers: Enforce consistency between the cap an IN_FORMATS
It's very confusing for userspace to have to deal with inconsistencies here, and some drivers screwed this up a bit. Most just ommitt
drm/modifiers: Enforce consistency between the cap an IN_FORMATS
It's very confusing for userspace to have to deal with inconsistencies here, and some drivers screwed this up a bit. Most just ommitted the format list when they meant to say that only linear modifier is allowed, but some also meant that only implied modifiers are acceptable (because actually none of the planes registered supported modifiers).
Now that this is all done consistently across all drivers, document the rules and enforce it in the drm core.
v2: - Make the capability a link (Simon) - Note that all is lost before 5.1.
v3: - Use drm_WARN_ON (Lyude)
Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com> Reviewed-by: Emil Velikov <emil.velikov@collabora.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Acked-by: Maxime Ripard <maxime@cerno.tech> Cc: Simon Ser <contact@emersion.fr> Reviewed-by: Lucas Stach <l.stach@pengutronix.de> Cc: Pekka Paalanen <pekka.paalanen@collabora.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210506132343.2873699-1-daniel.vetter@ffwll.ch
show more ...
|
Revision tags: v5.10.34, v5.4.116, v5.10.33, v5.12, v5.10.32, v5.10.31, v5.10.30, v5.10.27, v5.10.26, v5.10.25, v5.10.24, v5.10.23, v5.10.22, v5.10.21, v5.10.20, v5.10.19, v5.4.101, v5.10.18, v5.10.17 |
|
#
92f1d09c |
| 16-Feb-2021 |
Sakari Ailus <sakari.ailus@linux.intel.com> |
drm: Switch to %p4cc format modifier
Switch DRM drivers from drm_get_format_name() to %p4cc. This gets rid of a large number of temporary variables at the same time.
Signed-off-by: Sakari Ailus <sa
drm: Switch to %p4cc format modifier
Switch DRM drivers from drm_get_format_name() to %p4cc. This gets rid of a large number of temporary variables at the same time.
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Petr Mladek <pmladek@suse.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20210216155723.17109-4-sakari.ailus@linux.intel.com
show more ...
|
Revision tags: v5.11, v5.10.16, v5.10.15, v5.10.14 |
|
#
97ecfff4 |
| 15-Jan-2021 |
Simon Ser <contact@emersion.fr> |
drm/doc: document the type plane property
Add a new entry for "type" in the section for standard plane properties.
v3: improve paragraph about mixing legacy IOCTLs with explicit usage, note that a
drm/doc: document the type plane property
Add a new entry for "type" in the section for standard plane properties.
v3: improve paragraph about mixing legacy IOCTLs with explicit usage, note that a driver may support cursors without cursor planes (Daniel)
v4: fixing rebase gone wrong
v5: - Fix typo (Daniel) - Mention CAP_ATOMIC instead of CAP_UNIVERSAL_PLANES when referring to atomic test-only commits (Daniel) - Add newlines at end of sections (Daniel)
Signed-off-by: Simon Ser <contact@emersion.fr> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210115110626.12233-2-contact@emersion.fr
show more ...
|
#
a5e92ef3 |
| 09-Jan-2021 |
Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> |
drm: Check actual format for legacy pageflip.
With modifiers one can actually have different format_info structs for the same format, which now matters for AMDGPU since we convert implicit modifiers
drm: Check actual format for legacy pageflip.
With modifiers one can actually have different format_info structs for the same format, which now matters for AMDGPU since we convert implicit modifiers to explicit modifiers with multiple planes.
I checked other drivers and it doesn't look like they end up triggering this case so I think this is safe to relax.
Signed-off-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Zhan Liu <zhan.liu@amd.com> Acked-by: Christian König <christian.koenig@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Fixes: 816853f9dc40 ("drm/amd/display: Set new format info for converted metadata.") Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210110021142.28221-1-bas@basnieuwenhuizen.nl
show more ...
|
Revision tags: v5.10 |
|
#
0a1b813f |
| 10-Dec-2020 |
Philipp Zabel <p.zabel@pengutronix.de> |
drm/plane: add drmm_universal_plane_alloc()
Add an alternative to drm_universal_plane_init() that allocates and initializes a plane and registers drm_plane_cleanup() with drmm_add_action_or_reset().
drm/plane: add drmm_universal_plane_alloc()
Add an alternative to drm_universal_plane_init() that allocates and initializes a plane and registers drm_plane_cleanup() with drmm_add_action_or_reset().
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
show more ...
|
#
96962e3d |
| 11-Dec-2020 |
Simon Ser <contact@emersion.fr> |
drm: require each CRTC to have a unique primary plane
User-space expects to be able to pick a primary plane for each CRTC exposed by the driver. Make sure this assumption holds in drm_mode_config_va
drm: require each CRTC to have a unique primary plane
User-space expects to be able to pick a primary plane for each CRTC exposed by the driver. Make sure this assumption holds in drm_mode_config_validate.
Use the legacy drm_crtc.primary field to check this, because it's simpler and we require drivers to set it anyways. Accumulate a set of primary planes which are already used for a CRTC in a bitmask. Error out if a primary plane is re-used.
v2: new patch
v3: - Use u64 instead of __u64 (Jani) - Use `unsigned int` instead of `unsigned` (Jani)
v4: - Use u32 instead of u64 for plane mask (Ville) - Use drm_plane_mask instead of BIT (Ville) - Fix typos (Ville)
Signed-off-by: Simon Ser <contact@emersion.fr> Reviewed-by: Daniel Vetter <daniel@ffwll.ch> Acked-by: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Pekka Paalanen <ppaalanen@gmail.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201211184634.74534-4-contact@emersion.fr
show more ...
|
#
a7ecf003 |
| 17-Dec-2020 |
Simon Ser <contact@emersion.fr> |
drm/doc: fix reference to drm_format_modifier_blob
The documentation build system recognizes "struct XXX" references and generates links for them.
Signed-off-by: Simon Ser <contact@emersion.fr> Cc:
drm/doc: fix reference to drm_format_modifier_blob
The documentation build system recognizes "struct XXX" references and generates links for them.
Signed-off-by: Simon Ser <contact@emersion.fr> Cc: Pekka Paalanen <ppaalanen@gmail.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20201217113220.102271-4-contact@emersion.fr
show more ...
|
#
77a71abb |
| 17-Dec-2020 |
Simon Ser <contact@emersion.fr> |
drm/doc: introduce new section for standard plane properties
Introduce a new "Standard Plane Properties" section for properties defined in drm_plane.c. Move the mis-placed IN_FORMATS docs there.
Si
drm/doc: introduce new section for standard plane properties
Introduce a new "Standard Plane Properties" section for properties defined in drm_plane.c. Move the mis-placed IN_FORMATS docs there.
Signed-off-by: Simon Ser <contact@emersion.fr> Reviewed-by: Daniel Vetter <daniel@ffwll.ch> Cc: Pekka Paalanen <ppaalanen@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201217113220.102271-3-contact@emersion.fr
show more ...
|
#
2200736a |
| 11-Dec-2020 |
Simon Ser <contact@emersion.fr> |
drm: require a non_NULL drm_crtc.primary
If a CRTC is missing a legacy primary plane pointer, a lot of things will be broken for user-space: fbdev stops working and the entire legacy uAPI stops work
drm: require a non_NULL drm_crtc.primary
If a CRTC is missing a legacy primary plane pointer, a lot of things will be broken for user-space: fbdev stops working and the entire legacy uAPI stops working.
Require all drivers to populate drm_crtc.primary to prevent these issues. Warn if it's NULL.
Signed-off-by: Simon Ser <contact@emersion.fr> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201211184634.74534-3-contact@emersion.fr
show more ...
|
#
9999587b |
| 11-Dec-2020 |
Simon Ser <contact@emersion.fr> |
drm: rework description of primary and cursor planes
The previous wording could be understood by user-space evelopers as "a primary/cursor plane is only compatible with a single CRTC" [1].
Reword t
drm: rework description of primary and cursor planes
The previous wording could be understood by user-space evelopers as "a primary/cursor plane is only compatible with a single CRTC" [1].
Reword the planes description to make it clear the DRM-internal drm_crtc.primary and drm_crtc.cursor planes are for legacy uAPI.
[1]: https://github.com/swaywm/wlroots/pull/2333#discussion_r456788057
Signed-off-by: Simon Ser <contact@emersion.fr> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201211184634.74534-1-contact@emersion.fr
show more ...
|
#
a3d0d834 |
| 06-Dec-2020 |
Simon Ser <contact@emersion.fr> |
drm: fix typos in plane and CRTC overviews
Fix one missing letter, and one duplicate struct field reference.
Signed-off-by: Simon Ser <contact@emersion.fr> Cc: Daniel Vetter <daniel@ffwll.ch> Revie
drm: fix typos in plane and CRTC overviews
Fix one missing letter, and one duplicate struct field reference.
Signed-off-by: Simon Ser <contact@emersion.fr> Cc: Daniel Vetter <daniel@ffwll.ch> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/3gESG7rm6lCex6qBZnl3YXTfefKZODEvJ4DX4RoI1cY@cp4-web-040.plabs.ch
show more ...
|
Revision tags: v5.8.17 |
|
#
5c759eda |
| 20-Oct-2020 |
Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com> |
drm: Introduce plane and CRTC scaling filter properties
Introduce per-plane and per-CRTC scaling filter properties to allow userspace to select the driver's default scaling filter or Nearest-neighbo
drm: Introduce plane and CRTC scaling filter properties
Introduce per-plane and per-CRTC scaling filter properties to allow userspace to select the driver's default scaling filter or Nearest-neighbor(NN) filter for upscaling operations on CRTC and plane.
Drivers can set up this property for a plane by calling drm_plane_create_scaling_filter() and for a CRTC by calling drm_crtc_create_scaling_filter().
NN filter works by filling in the missing color values in the upscaled image with that of the coordinate-mapped nearest source pixel value.
NN filter for integer multiple scaling can be particularly useful for for pixel art games that rely on sharp, blocky images to deliver their distinctive look.
changes since: v6: * Move property doc to existing "Standard CRTC Properties" and "Plane Composition Properties" doc comments (Simon) changes since v3: * Refactor code, add new function for common code (Ville) changes since v2: * Create per-plane and per-CRTC scaling filter property (Ville) changes since v1: * None changes since RFC: * Add separate properties for plane and CRTC (Ville)
Link: https://github.com/xbmc/xbmc/pull/18194 Link: https://github.com/xbmc/xbmc/pull/18567 Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Acked-by: Simon Ser <contact@emersion.fr> Acked-by: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201020161427.6941-2-pankaj.laxminarayan.bharadiya@intel.com
show more ...
|