On Wednesday, May 22nd, 2024 at 15:36, Mario Limonciello
wrote:
> > To be perfectly honest with you, I haven't given that much though. I
> > used the 'bpc' and 'colorspace' property in debugfs, since I could not
> > find that information anywhere else. And since I also needed to verify
> > the
On Tuesday, May 21st, 2024 at 19:27, Leo Li wrote:
> I wonder if flags would work better than enums? A compositor can set something
> like `REQUIRE_ACCURACY & REQUIRE_LOW_LATENCY`, for example.
(FWIW, the KMS uAPI has first-class support for bitfields.)
This makes sense to me in general. I like the fact that it's simple and
vendor-neutral.
Do we want to hardcode "panel" in the name? Are we sure that this will
ever only apply to panels?
Do we want to use a name which reflects the intent, rather than the
mechanism? In other words, something like
On Tuesday, March 12th, 2024 at 16:02, Pekka Paalanen
wrote:
> This list here is the list of all values the enum could take, right?
> Should it not be just the one value it's going to have? It'll never
> change, and it can never be changed.
Listing all possible values is how other properties
> Do we really need this much flexibility, especially for the first driver
> adding the first few additional properties?
AFAIU we'd like to allow more props as well, e.g. cursor position…
Thanks! This iteration of the first 3 patches LGTM, I've pushed them to
drm-misc-next. I've made two adjustments to make checkpatch.pl happy:
- s/uint64_t/u64/
- Fix indentation for a drm_dbg_atomic()
It seems like commits were re-ordered at some point. I think we need "drm:
introduce drm_mode_config.atomic_async_page_flip_not_supported" to come before
"drm: allow DRM_MODE_PAGE_FLIP_ASYNC for atomic commits" because the latter
uses atomic_async_page_flip_not_supported. Similarly, "drm: Refuse
On Monday, November 13th, 2023 at 11:15, Pekka Paalanen
wrote:
>
>
> On Mon, 13 Nov 2023 09:44:15 +0000
> Simon Ser cont...@emersion.fr wrote:
>
> > On Monday, November 13th, 2023 at 10:38, Pekka Paalanen ppaala...@gmail.com
> > wrote:
> >
> &g
On Monday, November 13th, 2023 at 10:41, Michel Dänzer
wrote:
> On 11/13/23 10:18, Simon Ser wrote:
>
> > On Monday, October 23rd, 2023 at 10:25, Simon Ser cont...@emersion.fr wrote:
> >
> > > > > > > > > > > > +An atomic commit with the
On Monday, November 13th, 2023 at 10:38, Pekka Paalanen
wrote:
> On Mon, 13 Nov 2023 09:18:39 +
> Simon Ser cont...@emersion.fr wrote:
>
> > On Monday, October 23rd, 2023 at 10:25, Simon Ser cont...@emersion.fr wrote:
> >
> > > > > > >
On Monday, October 23rd, 2023 at 10:25, Simon Ser wrote:
> > > > > > > > > > +An atomic commit with the flag DRM_MODE_PAGE_FLIP_ASYNC is
> > > > > > > > > > allowed to
> > > > > > > > > > +effective
On Monday, October 23rd, 2023 at 10:42, Michel Dänzer
wrote:
> On 10/23/23 10:27, Simon Ser wrote:
>
> > On Sunday, October 22nd, 2023 at 12:12, Michel Dänzer
> > michel.daen...@mailbox.org wrote:
> >
> > > On 10/17/23 14:16, Simon Ser wrote:
> >
On Sunday, October 22nd, 2023 at 12:12, Michel Dänzer
wrote:
> On 10/17/23 14:16, Simon Ser wrote:
>
> > After discussing with André it seems like we missed a plane type check
> > here. We need to make sure FB_ID changes are only allowed on primary
> > planes.
>
>
On Tuesday, October 17th, 2023 at 14:10, Ville Syrjälä
wrote:
> On Mon, Oct 16, 2023 at 10:00:51PM +0000, Simon Ser wrote:
>
> > On Monday, October 16th, 2023 at 17:10, Ville Syrjälä
> > ville.syrj...@linux.intel.com wrote:
> >
> > > On Mon, Oct 16, 2023 at
After discussing with André it seems like we missed a plane type check
here. We need to make sure FB_ID changes are only allowed on primary
planes.
Reviewed-by: Simon Ser
On Monday, October 16th, 2023 at 17:10, Ville Syrjälä
wrote:
> On Mon, Oct 16, 2023 at 05:52:22PM +0300, Pekka Paalanen wrote:
>
> > On Mon, 16 Oct 2023 15:42:16 +0200
> > André Almeida andrealm...@igalia.com wrote:
> >
> > > Hi Pekka,
> > >
> > > On 10/16/23 14:18, Pekka Paalanen wrote:
> >
On Tuesday, August 15th, 2023 at 20:57, André Almeida
wrote:
> Given that prop changes may lead to modesetting, which would defeat the
> fast path of the async flip, refuse any atomic prop change for async
> flips in atomic API. The only exceptions are the framebuffer ID to flip
> to and the
On Thursday, August 17th, 2023 at 21:33, Dmitry Baryshkov
wrote:
> We have been looking for a way to document that the corresponding DP
> port is represented by the USB connector on the device.
>
> Consequently, I believe the best way to document it, would be to use
> DisplayPort / USB, when
On Thursday, August 17th, 2023 at 15:46, Harry Wentland
wrote:
> On 2023-08-17 09:44, Harry Wentland wrote:
>
> > On 2023-08-17 06:53, Simon Ser wrote:
> >
> > > The commit 1347385fe187 ("drm/amd/display: don't expose rotation
> > > prop for cur
Allow user-space to use the cursor plane with a rotated underlying
plane under the condition that both planes have the same rotation.
Signed-off-by: Simon Ser
Cc: Alex Deucher
Cc: Harry Wentland
Cc: Nicholas Kazlauskas
Cc: Michel Dänzer
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
We don't want a semi-transparent overlay to make the cursor plane
semi-transparent as well. Same for the pixel blend mode.
Signed-off-by: Simon Ser
Cc: Alex Deucher
Cc: Harry Wentland
Cc: Nicholas Kazlauskas
Cc: Michel Dänzer
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 14
he primary plane is rotated, then the cursor plane
will incorrectly be rotated as well even though it doesn't have a
rotation property.
To fix this, check that the underlying plane isn't rotated.
Signed-off-by: Simon Ser
Cc: Alex Deucher
Cc: Harry Wentland
Cc: Nicholas Kazlauskas
Cc: Mic
.
Signed-off-by: Simon Ser
Cc: Alex Deucher
Cc: Harry Wentland
Cc: Nicholas Kazlauskas
Cc: Michel Dänzer
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd
Changes in v3: rebase, split cursor rotation patch into 2.
Simon Ser (4):
amd/display: add cursor check for YUV underlying pipe
amd/display: add cursor alpha and blend mode checks
amd/display: add cursor rotation check
amd/display: re-introduce cursor plane rotation prop
.../gpu/drm/amd
On Thursday, August 3rd, 2023 at 22:44, Laurent Pinchart
wrote:
> On Thu, Aug 03, 2023 at 03:31:16PM +0000, Simon Ser wrote:
>
> > On Thursday, August 3rd, 2023 at 17:22, Simon Ser cont...@emersion.fr wrote:
> >
> > > The KMS docs describe "subconnector&qu
On Thursday, August 3rd, 2023 at 17:36, Dmitry Baryshkov
wrote:
> On Thu, 3 Aug 2023 at 18:31, Simon Ser cont...@emersion.fr wrote:
>
> > On Thursday, August 3rd, 2023 at 17:22, Simon Ser cont...@emersion.fr wrote:
> >
> > > The KMS docs describe "subconnect
On Thursday, August 3rd, 2023 at 17:22, Simon Ser wrote:
> The KMS docs describe "subconnector" to be defined as "downstream port" for
> DP.
> Can USB-C (or USB) be seen as a DP downstream port?
To expand on this a bit: I'm wondering if we're mixing apples and
ora
On Wednesday, August 2nd, 2023 at 21:23, Dmitry Baryshkov
wrote:
> >> >> + { DRM_MODE_SUBCONNECTOR_USB, "USB" }, /* DP */
> >> >
> >> > Should this be DRM_MODE_SUBCONNECTOR_USB_C and "USB-C", in case we get
> >> > another USB type later ?
> >>
> >> Hmm, which id should I use
On Tuesday, July 25th, 2023 at 04:55, André Almeida
wrote:
> It's not clear what we should do about non-robust OpenGL apps after GPU
> resets, so I'll try to summarize the topic, show some options and my
> proposal to move forward on that.
>
> Em 27/06/2023 10:23, André Almeida escreveu:
>
>
On Saturday, July 8th, 2023 at 00:40, André Almeida
wrote:
> +KMS atomic state
> +
> +
> +An atomic commit can change multiple KMS properties in an atomic fashion,
> +without ever applying intermediate or partial state changes. Either the
> whole
> +commit succeeds or fails,
On Tuesday, July 4th, 2023 at 19:06, Sebastian Wick
wrote:
> > + * When used with atomic uAPI, the driver will return an error if the
> > hardware
> > + * doesn't support performing an asynchronous page-flip for this update.
> > + * User-space should handle this, e.g. by falling back to a
Thanks! All of the core DRM patches (1-6) are
Reviewed-by: Simon Ser
On Tuesday, June 6th, 2023 at 22:25, Harry Wentland
wrote:
> + if (supported_colorspaces != 0 && (colorspaces & BIT(i)) == 0)
This patch actually also introduces a change in behavior: passing no
colorspace will make the function advertise all colorspaces. I have a
hard time
On Tuesday, June 6th, 2023 at 22:26, Harry Wentland
wrote:
> -int drm_mode_create_hdmi_colorspace_property(struct drm_connector *connector)
> +int drm_mode_create_hdmi_colorspace_property(struct drm_connector *connector,
> + u32 supported_colorspaces)
>
On Tuesday, June 6th, 2023 at 22:25, Harry Wentland
wrote:
> We an use bitfields to track the support ones for HDMI
Typo: "We can"
On Friday, May 26th, 2023 at 18:40, Sebastian Wick
wrote:
> On Thu, May 25, 2023 at 9:18 PM Harry Wentland harry.wentl...@amd.com wrote:
>
> > We want compositors to be able to set the output
> > colorspace on DP and HDMI outputs, based on the
> > caps reported from the receiver via EDID.
>
>
On Friday, May 26th, 2023 at 18:27, Sebastian Wick
wrote:
> > + * @DRM_MODE_COLORIMETRY_DEFAULT:
> > + * Driver specific behavior.
> > + * @DRM_MODE_COLORIMETRY_NO_DATA:
> > + * Driver specific behavior.
>
> TBH this is still confusing me. Is DEFAULT really just driver specific
> behavior?
Reviewed-by: Simon Ser
On Tuesday, March 7th, 2023 at 16:10, Harry Wentland
wrote:
> * This enum is used to indicate DP VSC SDP Colorimetry formats.
> * It is based on DP 1.4 spec [Table 2-117: VSC SDP Payload for DB16 through
> - * DB18] and a name of enum member follows DRM_MODE_COLORIMETRY definition.
> + * DB18]
On Friday, February 10th, 2023 at 10:37, Pekka Paalanen
wrote:
> On Thu, 09 Feb 2023 17:03:19 +
> Simon Ser cont...@emersion.fr wrote:
>
> > On Thursday, February 9th, 2023 at 17:38, Joshua Ashton jos...@froggi.es
> > wrote:
> >
> > > > I mean, the
On Thursday, February 9th, 2023 at 17:38, Joshua Ashton
wrote:
> > I mean, the strings are the uAPI, not the integers, right?
>
> Both are uAPI these days.
Yes. The integers are uAPI, if you change them you'll break libliftoff
users. There is an old thread discussing this somewhere. The tl;dr
On Wednesday, January 25th, 2023 at 21:04, Thomas Zimmermann
wrote:
> Not having connectors indicates a driver bug.
Is it? What if all connectors are of the DP-MST type, ie. they are
created on-the-fly?
Reviewed-by: Simon Ser
On Friday, January 13th, 2023 at 17:59, Maíra Canal wrote:
> + /* Verify that the modifier is supported. */
> + if (r->modifier[0] && drm_drv_uses_atomic_modeset(dev) &&
> + !drm_any_plane_has_format(dev, r->pixel_format, r->modifier[0])) {
> + drm_dbg_kms(dev,
Hm, unfortunately I think we need to keep the check in amdgpu for the
same reason as i915: amdgpu will pick a modifier if user-space didn't
supply one on GFX9+.
I wonder if that also applies to vmwgfx? Maybe that would be a reason
to have the check in framebuffer_init()? (Not sure!)
Hm, thinking about this again, there's still something which is a bit
off with the new approach. Let's say the caller sets MODE_ID to another
blob ID, but with the same blob payload. DRM core is smart enough to
figure out that the mode didn't change and skip the modeset. However,
the check
On Wednesday, November 30th, 2022 at 16:23, André Almeida
wrote:
> On 11/28/22 06:30, Simon Ser wrote:
>
> > The PID is racy, the user-space daemon could end up killing an
> > unrelated process… Is there any way we could use a pidfd instead?
>
> Is the PID race conditi
The PID is racy, the user-space daemon could end up killing an
unrelated process… Is there any way we could use a pidfd instead?
Ville, any news on this?
This breaks the "size" out-parameter.
> > > So no tests that actually verify that the kernel properly rejects
> > > stuff stuff like modesets, gamma LUT updates, plane movement,
> > > etc.?
> >
> > Pondering this a bit more, it just occurred to me the current driver
> > level checks might easily lead to confusing behaviour. Eg. is
> >
On Friday, September 30th, 2022 at 15:53, Ville Syrjälä
wrote:
> > diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > index 44235345fd57..7500e82cf06a 100644
> > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> >
-off-by: Simon Ser
Reviewed-by: André Almeida
Reviewed-by: Alex Deucher
Cc: Joshua Ashton
Cc: Melissa Wen
Cc: Harry Wentland
Cc: Nicholas Kazlauskas
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm
, Pekka)
Signed-off-by: Simon Ser
Co-developed-by: André Almeida
Signed-off-by: André Almeida
Reviewed-by: André Almeida
Reviewed-by: Alex Deucher
Cc: Daniel Vetter
Cc: Joshua Ashton
Cc: Melissa Wen
Cc: Harry Wentland
Cc: Nicholas Kazlauskas
Cc: Ville Syrjälä
---
drivers/gpu/drm
This new kernel capability indicates whether async page-flips are
supported via the atomic uAPI. DRM clients can use it to check
for support before feeding DRM_MODE_PAGE_FLIP_ASYNC to the kernel.
Make it clear that DRM_CAP_ASYNC_PAGE_FLIP is for legacy uAPI only.
Signed-off-by: Simon Ser
and
on radeon)
Signed-off-by: Simon Ser
Reviewed-by: André Almeida
Reviewed-by: Alex Deucher
Cc: Daniel Vetter
Cc: Joshua Ashton
Cc: Melissa Wen
Cc: Harry Wentland
Cc: Nicholas Kazlauskas
Cc: Ville Syrjälä
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 1 +
drivers/gpu/drm/atmel-hlcdc
behaves
this way.
This patch aligns amdgpu with uAPI expectations and returns a failure
when an async flip is not possible.
v2: new patch
Signed-off-by: Simon Ser
Reviewed-by: André Almeida
Reviewed-by: Alex Deucher
Cc: Joshua Ashton
Cc: Melissa Wen
Cc: Harry Wentland
Cc: Nicholas Kazlauskas
This is a subset of [1], included here because a subsequent patch
needs to document the behavior of this flag under the atomic uAPI.
v2: new patch
[1]: https://patchwork.freedesktop.org/patch/500177/
Signed-off-by: Simon Ser
Reviewed-by: André Almeida
Reviewed-by: Alex Deucher
---
include
bout Intel hardware,
add R-b tags.
Tested on an AMD Picasso iGPU (Simon) and an AMD Vangogh GPU (André).
Simon Ser (6):
drm: document DRM_MODE_PAGE_FLIP_ASYNC
amd/display: only accept async flips for fast updates
drm: introduce drm_mode_config.atomic_async_page_flip_not_supported
On Wednesday, August 31st, 2022 at 09:50, Pekka Paalanen
wrote:
> > diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> > index 86a292c3185a..cce1a1bea645 100644
> > --- a/include/uapi/drm/drm_mode.h
> > +++ b/include/uapi/drm/drm_mode.h
> > @@ -942,6 +942,10 @@ struct
-off-by: Simon Ser
Cc: Joshua Ashton
Cc: Melissa Wen
Cc: Alex Deucher
Cc: Harry Wentland
Cc: Nicholas Kazlauskas
Cc: André Almeida
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b
This new kernel capability indicates whether async page-flips are
supported via the atomic uAPI. DRM clients can use it to check
for support before feeding DRM_MODE_PAGE_FLIP_ASYNC to the kernel.
Make it clear that DRM_CAP_ASYNC_PAGE_FLIP is for legacy uAPI only.
Signed-off-by: Simon Ser
Cc
. For instance, Xorg falls back to a blit.
Another option is to wait as close to the next vblank as
possible before performing the page-flip to reduce latency.
v2: document new uAPI
Signed-off-by: Simon Ser
Co-developed-by: André Almeida
Signed-off-by: André Almeida
Cc: Daniel Vetter
Cc
and
on radeon)
Signed-off-by: Simon Ser
Cc: Daniel Vetter
Cc: Joshua Ashton
Cc: Melissa Wen
Cc: Alex Deucher
Cc: Harry Wentland
Cc: Nicholas Kazlauskas
Cc: André Almeida
Cc: Ville Syrjälä
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 1 +
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
This is a subset of [1], included here because a subsequent patch
needs to document the behavior of this flag under the atomic uAPI.
v2: new patch
[1]: https://patchwork.freedesktop.org/patch/500177/
Signed-off-by: Simon Ser
---
include/uapi/drm/drm_mode.h | 7 +++
1 file changed, 7
behaves
this way.
This patch aligns amdgpu with uAPI expectations and returns a failure
when an async flip is not possible.
v2: new patch
Signed-off-by: Simon Ser
Cc: Joshua Ashton
Cc: Melissa Wen
Cc: Alex Deucher
Cc: Harry Wentland
Cc: Nicholas Kazlauskas
Cc: André Almeida
---
drivers/gpu/drm
v1: https://patchwork.freedesktop.org/series/107683/
- User-space patch: https://github.com/Plagman/gamescope/pull/595
- IGT patch: https://patchwork.freedesktop.org/series/107681/
Main changes in v2: add docs, fail atomic commit if async flip isn't
possible.
Tested on an AMD Picasso iGPU.
Simon Ser (6):
a
On Tuesday, August 30th, 2022 at 16:42, Alex Deucher
wrote:
> > Hm, can you elaborate on the difference between "immediate flip" (as in
> > UNP_FLIP_CONTROL) and GRPH_SURFACE_UPDATE_H_RETRACE_EN? What are their
> > relationship with KMS's concept of "async flips"?
>
> The display surface
On Tuesday, August 30th, 2022 at 16:06, Alex Deucher
wrote:
> On Tue, Aug 30, 2022 at 3:08 AM Simon Ser cont...@emersion.fr wrote:
>
> > On Friday, August 26th, 2022 at 16:39, Alex Deucher alexdeuc...@gmail.com
> > wrote:
> >
> > > On Fri, Aug 2
(Oops, I replied to the wrong thread. Re-sending to the correct one.)
On Tuesday, August 30th, 2022 at 10:41, Michel Dänzer
wrote:
> > For the atomic uAPI, we need to pick on of these two approaches:
> >
> > 1. Let the kernel fall back to a sync flip if async isn't possible. This
> >
On Tuesday, August 30th, 2022 at 12:24, Ville Syrjälä
wrote:
> > > The current behaviour is to fall back to a blit if the async
> > > flip fails. So you still get the same effective behaviour, just
> > > not as efficient. I think that's a reasonable way to handle it.
> >
> > That's purely an
On Tuesday, August 30th, 2022 at 10:08, Ville Syrjälä
wrote:
> > In the documentation patch discussion [1], it appears it's not clear what
> > drivers should do when async flip isn't possible with the legacy uAPI.
> >
> > For the atomic uAPI, we need to pick on of these two approaches:
> >
> >
On Friday, August 26th, 2022 at 16:39, Alex Deucher
wrote:
> On Fri, Aug 26, 2022 at 3:38 AM Simon Ser wrote:
> >
> > On Thursday, August 25th, 2022 at 20:22, Alex Deucher
> > wrote:
> >
> > > On Wed, Aug 24, 2022 at 11:09 AM
On Friday, August 26th, 2022 at 10:19, Ville Syrjälä
wrote:
> On Wed, Aug 24, 2022 at 03:08:55PM +0000, Simon Ser wrote:
> > This new kernel capability indicates whether async page-flips are
> > supported via the atomic uAPI. DRM clients can use it to check
> > for s
On Thursday, August 25th, 2022 at 20:22, Alex Deucher
wrote:
> On Wed, Aug 24, 2022 at 11:09 AM Simon Ser cont...@emersion.fr wrote:
>
> > amdgpu_dm_commit_planes already sets the flip_immediate flag for
> > async page-flips. This flag is used to set the UNP_FLIP_CONTROL
tch:
https://github.com/Plagman/gamescope/pull/595
IGT patch:
https://patchwork.freedesktop.org/series/107681/
Tested on an AMD Picasso iGPU.
Simon Ser (4):
drm: introduce drm_mode_config.atomic_async_page_flip_not_supported
drm: allow DRM_MODE_PAGE_FLIP_ASYNC for atomic commits
drm:
This new kernel capability indicates whether async page-flips are
supported via the atomic uAPI. DRM clients can use it to check
for support before feeding DRM_MODE_PAGE_FLIP_ASYNC to the kernel.
Make it clear that DRM_CAP_ASYNC_PAGE_FLIP is for legacy uAPI only.
Signed-off-by: Simon Ser
Cc
uAPI. The mode_set_base callbacks unconditionally set the
GRPH_SURFACE_UPDATE_H_RETRACE_EN field of the GRPH_FLIP_CONTROL
register to 0, which disables async page-flips.
Signed-off-by: Simon Ser
Cc: Daniel Vetter
Cc: Joshua Ashton
Cc: Melissa Wen
Cc: Alex Deucher
Cc: Harry Wentland
Cc: Nicholas
If the driver supports it, allow user-space to supply the
DRM_MODE_PAGE_FLIP_ASYNC flag to request an async page-flip.
Set drm_crtc_state.async_flip accordingly.
Signed-off-by: Simon Ser
Cc: Daniel Vetter
Cc: Joshua Ashton
Cc: Melissa Wen
Cc: Alex Deucher
Cc: Harry Wentland
Cc: Nicholas
for async flips. New drivers should not
set this flag, instead they should support atomic async flips (if
they support async flips at all). IOW, we don't want more drivers
with async flip support for legacy but not atomic.
Signed-off-by: Simon Ser
Cc: Daniel Vetter
Cc: Joshua Ashton
Cc: Melissa Wen
the panel orientation prop with "Normal",
and update it accordingly when probing.
At any rate, I've tested v2 on the Deck and it works properly.
Tested-by: Simon Ser
Thanks,
Simon
[1]:
https://lore.kernel.org/dri-devel/CAMavQKJUpYP8jo2JDGMYNBGtbPSSO7z9BAComm5JQoty=hp...@mail.gma
Acked-by: Simon Ser
CC amd-gfx
On Monday, August 1st, 2022 at 15:52, Imre Deak wrote:
> The API change introduced in
>
> commit 30c637151cfa ("drm/plane-helper: Export individual helpers")
>
> was missed in the conflict resolution of
>
> commit d93a13bd75b9 (&qu
On Tuesday, July 26th, 2022 at 17:47, Dan Carpenter
wrote:
> On Tue, Jul 26, 2022 at 03:27:54PM +0000, Simon Ser wrote:
>
> > plane->state->fb is NULL iff afb is NULL. There is an early return to
> > make sure the dereferences don't cause a segfault.
>
Hi,
plane->state->fb is NULL iff afb is NULL. There is an early return to
make sure the dereferences don't cause a segfault.
Simon
es the above issue.
>
> [1] https://lkml.org/lkml/2019/6/5/18
>
> Fixes: 8ba16d599374 ("drm/fourcc: Add AMD DRM modifiers.")
> Signed-off-by: Carlos Llamas
Reviewed-by: Simon Ser
Cc'ing Bas as well
> ---
> include/uapi/drm/drm_fourcc.h | 4 ++--
> 1 file chang
Reviewed-by: Simon Ser
On Tuesday, June 14th, 2022 at 20:30, Alex Deucher
wrote:
> On Tue, Jun 14, 2022 at 2:16 PM Simon Ser cont...@emersion.fr wrote:
>
> > On Monday, June 13th, 2022 at 22:01, Rodrigo Siqueira
> > rodrigo.sique...@amd.com wrote:
> >
> > > Amdgpu driver is used
On Monday, June 13th, 2022 at 22:01, Rodrigo Siqueira
wrote:
> Amdgpu driver is used in an extensive range of devices, and each ASIC
> has some specific configuration. As a result of this variety, sometimes
> it is hard to identify the correct block that might cause the issue.
> This commit
On Friday, April 8th, 2022 at 15:21, Grigory Vasilyev wrote:
> Simon Ser and Bas Nieuwenhuizen, do you understand that you are
> proposing to make the code less safe in the future? In the future,
> someone might rewrite the code and we'll get an error.
I don't think we should blindly
On Friday, April 8th, 2022 at 13:28, Bas Nieuwenhuizen
wrote:
> On Fri, Apr 8, 2022 at 12:01 PM Simon Ser cont...@emersion.fr wrote:
>
> > Is amdgpu_display_get_fb_info ever called with NULL
> > tiling_flags/tmz_surface?
> > If not, there's no point in adding NULL che
Is amdgpu_display_get_fb_info ever called with NULL tiling_flags/tmz_surface?
If not, there's no point in adding NULL checks.
I've tested this patch and it fixes my bug [1]. Thanks!
Tested-by: Simon Ser
[1]: https://gitlab.freedesktop.org/drm/amd/-/issues/1734
Thanks a lot for you patch! I've noticed as well that amdgpu ignores
the plane alpha property [1]. I'll try to find time to test it.
[1]: https://gitlab.freedesktop.org/drm/amd/-/issues/1734
On Tuesday, March 15th, 2022 at 08:13, Dave Airlie wrote:
> Just one thing comes to mind reading this, racy PID reuse.
>
> process 1234 does something bad to GPU.
> process 1234 dies in parallel to sysfs notification being sent.
> other process 1234 reuses the pid
> new process 1234 gets
On Wednesday, March 9th, 2022 at 11:24, Christian König
wrote:
> Am 09.03.22 um 11:10 schrieb Simon Ser:
> > On Wednesday, March 9th, 2022 at 10:56, Pierre-Eric Pelloux-Prayer
> > wrote:
> >
> >> Would it be possible to include the app parameters as well?
&g
On Wednesday, March 9th, 2022 at 10:56, Pierre-Eric Pelloux-Prayer
wrote:
> Would it be possible to include the app parameters as well?
Can all processes read sysfs events?
There might be security implications here. The app parameters might
contain sensitive information, like passwords or
Hi,
Maybe it would be a good idea to state the intended use-case in the
commit message? And explain why the current (driver-specific IIRC) APIs
aren't enough?
Since this introduces new uAPI, can you point to a user-space patch
which uses the new uAPI? See this link for more info on DRM
On Friday, February 18th, 2022 at 12:54, Hans de Goede
wrote:
> On 2/18/22 12:39, Simon Ser wrote:
> > On Friday, February 18th, 2022 at 11:38, Hans de Goede
> > wrote:
> >
> >> What I'm reading in the above is that it is being considered to allow
> >&g
On Friday, February 18th, 2022 at 11:38, Hans de Goede
wrote:
> What I'm reading in the above is that it is being considered to allow
> changing the panel-orientation value after the connector has been made
> available to userspace; and let userspace know about this through a uevent.
>
> I
1 - 100 of 230 matches
Mail list logo
