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 be
you mind sending a patch for FB_DAMAGE_CLIPS as well?
Reviewed-by: Simon Ser
BTW, should we allow OUT_FENCE_PTR as well? Would that work as expected
with async flips?
Looks good to me as well, thank you!
Reviewed-by: Simon Ser
I've pushed both patches to drm-misc-fixes, thanks!
I've added a Fixes trailer accordingly.
I'll rebase my patch on top of these two.
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, 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.)
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 p
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, 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, 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 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
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 to
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()
> 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…
Pushed this one doc patch with Daniel's R-b on IRC.
Hm. This patch causes a regression for me. I was using primary + overlay
not covering the whole primary plane + cursor before. This patch breaks it.
This patch makes the overlay plane very useless for me, because the primary
plane is always under the overlay plane.
> Basically, we cannot draw the
Hi Rodrigo!
Thanks a lot for your reply! Comments below, please bear with me: I'm
a bit familiar with the cursor issues, but my knowledge of AMD hw is
still severely lacking.
On Wednesday, August 18th, 2021 at 15:18, Rodrigo Siqueira
wrote:
> On 08/18, Simon Ser wrote:
> >
Hi Nicholas!
On Tuesday, August 24th, 2021 at 16:56, Kazlauskas, Nicholas
wrote:
> It's easiest to under the hardware cursor as being constrained within
> the DRM plane specifications. Each DRM plane maps to 1 (or 2) hardware
> pipes and the cursor has to be drawn along with it. The cursor will
On Tuesday, August 24th, 2021 at 18:48, Harry Wentland
wrote:
> To elaborate on this a bit more, each HW plane's scanout engine
> has the ability to scan out a cursor, in addition to the plane's
> framebuffer. This cursor is drawn onto the plane at the scanout
> phase. Any further scaling, color
On Friday, August 27th, 2021 at 16:04, Harry Wentland
wrote:
> > Is it possible to draw the cursor only on the overlay pipe (not on the
> > primary
> > pipe), even though the overlay pipe doesn't cover the whole CRTC?
> >
> > Or will the overlay pipe crop the cursor image?
> >
>
> It will be cr
Ping, anyone up for a review?
Hi all,
Recently I've been discussing with various people [1] [2] about amdgpu's
handling of KMS planes. AMD hardware is a bit special when it comes to
the cursor plane, and it's not always 100% clear how that maps with the
KMS API.
Up until now we were using cursor and overlay planes in gamescop
ation.
Downgrade the log to a regular DRM atomic message. While at it, use
the new device-aware logging infrastructure.
This fixes error messages in the kernel when running gamescope [1].
[1]: https://github.com/Plagman/gamescope/issues/245
Signed-off-by: Simon Ser
Cc: Alex Deucher
Cc: Harry Wen
s need the native mode from the
EDID, check for it in amdgpu_dm_connector_ddc_get_modes.
Signed-off-by: Simon Ser
Cc: Alex Deucher
Cc: Harry Wentland
Cc: Nicholas Kazlauskas
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 28 +++
1 file changed, 28 insertions(+)
diff --git
lt in garbage
displayed on screen [1].
Fix this by adding a check for tiling flags for GFX8 and older.
The check is taken from radeonsi in Mesa (see how is_displayable
is populated in gfx6_compute_surface).
[1]: https://github.com/swaywm/wlroots/issues/3185
Signed-off-by: Simon Ser
Cc
Alex, Harry, Nicholas: any thoughts on this patch?
waywm/wlroots/issues/3185
Signed-off-by: Simon Ser
Cc: sta...@vger.kernel.org
Acked-by: Michel Dänzer
Cc: Alex Deucher
Cc: Harry Wentland
Cc: Nicholas Kazlauskas
Cc: Bas Nieuwenhuizen
---
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 31 +
1 file changed, 31 insertions(+)
diff
On Monday, September 27th, 2021 at 16:57, Alex Deucher
wrote:
> No objections from me with the WARN_ONCE change suggested by Michel.
Cool, just sent v2 with Michel's comment fixed.
ing advantage of the
overlay plane. Let's limit the check to ChromeOS.
[1]:
https://lore.kernel.org/amd-gfx/JIQ_93_cHcshiIDsrMU1huBzx9P9LVQxucx8hQArpQu7Wk5DrCl_vTXj_Q20m_L-8C8A5dSpNcSJ8ehfcCrsQpfB5QG_Spn14EYkH9chtg0=@emersion.fr/
Signed-off-by: Simon Ser
Cc: Alex Deucher
Cc: Harry Wentland
CRTC planes and check their scaling match
the cursor's.
Signed-off-by: Simon Ser
Cc: Alex Deucher
Cc: Harry Wentland
Cc: Nicholas Kazlauskas
Cc: Bas Nieuwenhuizen
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 49 +--
1 file changed, 34 insertions(+), 15 deleti
One include is v2, the other is v3, or am I missing something?
the CRTC planes and check their scaling match
the cursor's.
v4: fix typo in commit message (Harry)
Signed-off-by: Simon Ser
Cc: Alex Deucher
Cc: Harry Wentland
Cc: Nicholas Kazlauskas
Cc: Bas Nieuwenhuizen
Cc: Rodrigo Siqueira
Cc: Sean Paul
---
.../gpu/drm/amd/display/amdgpu
ing advantage of the
overlay plane. Let's limit the check to ChromeOS.
v4: fix ChromeOS detection (Harry)
[1]:
https://lore.kernel.org/amd-gfx/JIQ_93_cHcshiIDsrMU1huBzx9P9LVQxucx8hQArpQu7Wk5DrCl_vTXj_Q20m_L-8C8A5dSpNcSJ8ehfcCrsQpfB5QG_Spn14EYkH9chtg0=@emersion.fr/
Signed-off-by: Simon
> current->comm is "DrmThread" on my ChromeOS system.
Oops! I forgot that current->comm could be overwritten by user-space. Sent v4
which should address this by checking the executable name too.
Thanks for the review!
Ping
ersion.fr/
Signed-off-by: Simon Ser
Cc: Alex Deucher
Cc: Harry Wentland
Cc: Nicholas Kazlauskas
Cc: Bas Nieuwenhuizen
Cc: Rodrigo Siqueira
Cc: Sean Paul
Fixes: ddab8bd788f5 ("drm/amd/display: Fix two cursor duplication when using
overlay")
---
.../gpu/drm/amd/display/amdgpu_dm/amdg
> v5: fix conflict with linux-next
> >
> > [1]:
> > https://lore.kernel.org/amd-gfx/JIQ_93_cHcshiIDsrMU1huBzx9P9LVQxucx8hQArpQu7Wk5DrCl_vTXj_Q20m_L-8C8A5dSpNcSJ8ehfcCrsQpfB5QG_Spn14EYkH9chtg0=@emersion.fr/
> >
> > Signed-off-by: Simon Ser
> > Cc: Alex Deucher
On Tuesday, October 12th, 2021 at 11:24, Paul Menzel
wrote:
> Thank you for the explanation. Then I misunderstood commit ddab8bd7
> (drm/amd/display: Fix two cursor duplication when using overlay) from
> the Fixes tag, as commit ddab8bd7 does not mention Chrome OS, and also
> does not carry a fi
On Tuesday, October 12th, 2021 at 23:03, Alex Deucher
wrote:
> > > @Harry Wentland, @Simon Ser Do you have a preference on whether we
> > > apply this patch or revert ddab8bd788f5? I'm fine with either.
I'd prefer to revert because (1) the ChromeOS team seems to be
[1]:
https://lore.kernel.org/amd-gfx/JIQ_93_cHcshiIDsrMU1huBzx9P9LVQxucx8hQArpQu7Wk5DrCl_vTXj_Q20m_L-8C8A5dSpNcSJ8ehfcCrsQpfB5QG_Spn14EYkH9chtg0=@emersion.fr/
[2]:
https://lore.kernel.org/amd-gfx/20211011151609.452132-1-cont...@emersion.fr/
Signed-off-by: Simon Ser
Cc: Alex Deucher
Cc: Harr
On Tuesday, October 19th, 2021 at 01:03, Paul Menzel
wrote:
> Excuse my ignorance. Reading the commit message, there was a Linux
> kernel change, that broke Chrome OS userspace, right? If so, and we do
> not know if there is other userspace using the API incorrectly,
> shouldn’t the patch breaki
On Tuesday, October 19th, 2021 at 01:21, Paul Menzel
wrote:
> Am 19.10.21 um 01:06 schrieb Simon Ser:
> > On Tuesday, October 19th, 2021 at 01:03, Paul Menzel wrote:
> >
> >> Excuse my ignorance. Reading the commit message, there was a Linux
> >> kernel chang
Hi again,
On Tuesday, October 19th, 2021 at 10:25, Paul Menzel
wrote:
> Dear Simon,
>
>
> Am 19.10.21 um 10:10 schrieb Simon Ser:
> > On Tuesday, October 19th, 2021 at 01:21, Paul Menzel
> > wrote:
> >
> >> Am 19.10.21 um 01:06 schrieb Simon Ser:
> &
On Thursday, October 14th, 2021 at 17:35, Simon Ser wrote:
> This reverts commits ddab8bd788f5 ("drm/amd/display: Fix two cursor
> duplication
> when using overlay") and e7d9560aeae5 ("Revert "drm/amd/display: Fix overlay
> validation by considering cursors
On Friday, October 22nd, 2021 at 15:58, Alex Deucher
wrote:
> > Agreed that this patch is good but we'll need to also revert the
> > is_chromeos w/a.
>
> I've reverted that and applied this one. Thanks!
Ah, didn't realize I needed to revert that one too. Thank you!
On Tuesday, October 26th, 2021 at 18:03, Kazlauskas, Nicholas
wrote:
> If it's just an error in the log without a functional issue then maybe
> we should downgrade it to a debug statement in the case where it returns
> -ERESTARTSYS.
>
> If this is a functional issue (DRM not automatically retryi
Reviewed-by: Simon Ser
First off, let me reiterate that this feature would be invaluable as user-space
developers. It's often pretty difficult to figure out the cause of an EINVAL,
we have to ask users to follow complicated instructions [1] to grab DRM logs.
Then have to skim through several megabytes of logs to find the
Have you tested this? I have a similar patch, but the cursor position was off
when I tried it.
Accept non-linear buffers which use a multi-planar format, as long
as they don't use DCC.
Tested on GFX9 with NV12.
Signed-off-by: Simon Ser
Cc: Alex Deucher
Cc: Harry Wentland
Cc: Nicholas Kazlauskas
Cc: Bas Nieuwenhuizen
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
Hi,
Can you have a look at this patch?
Thanks,
Simon
On Friday, March 26th, 2021 at 5:59 PM, Simon Ser wrote:
> Accept non-linear buffers which use a multi-planar format, as long
> as they don't use DCC.
>
> Tested on GFX9 with NV12.
>
> Signed-off-by: Simon Ser
&
This error code-path is missing a drm_gem_object_put call. Other
error code-paths are fine.
Signed-off-by: Simon Ser
Fixes: 1769152ac64b ("drm/amdgpu: Fail fb creation from imported dma-bufs.
(v2)")
Cc: Alex Deucher
Cc: Harry Wentland
Cc: Nicholas Kazlauskas
Cc: Bas Nie
after converting
> the implicit modifier to an explicit modifier, so on GFX9+ all
> framebuffers should be checked here.
Thanks for the updated patch! It fixes the regressions I've got with
my modifier-aware user-space compositors.
Tested-by: Simon Ser
> There is a TODO about DCC al
On Wednesday, May 12th, 2021 at 3:04 PM, Ville Syrjälä
wrote:
> > Adoption:
> >
> > A KDE dev wants to implement the settings in the KDE settings GUI:
> >
> > https://gitlab.freedesktop.org/drm/amd/-/issues/476#note_912370
> >
> > Tuxedo Computers (my employer) wants to implement the settings de
Thanks for working on this! I've pushed a patch [1] to drm-misc-next which
touches the same function, can you rebase your patches on top of it?
[1]: https://patchwork.freedesktop.org/patch/467940/?series=98255&rev=3
On Friday, January 14th, 2022 at 15:16, Andy Shevchenko
wrote:
> Why not enum?
There is no enum for DRM format modifiers.
On Friday, January 14th, 2022 at 16:17, Andy Shevchenko
wrote:
> On Fri, Jan 14, 2022 at 03:07:21PM +0000, Simon Ser wrote:
> > On Friday, January 14th, 2022 at 15:16, Andy Shevchenko
> > wrote:
> >
> > > Why not enum?
> >
> > There is no enum for
On Tuesday, February 15th, 2022 at 13:04, Emil Velikov
wrote:
> Greetings everyone,
>
> Padron for joining in so late o/
>
> On Tue, 8 Feb 2022 at 08:42, Hsin-Yi Wang wrote:
> >
> > drm_dev_register() sets connector->registration_state to
> > DRM_CONNECTOR_REGISTERED and dev->registered to true
On Tuesday, February 15th, 2022 at 15:38, Emil Velikov
wrote:
> On Tue, 15 Feb 2022 at 13:55, Simon Ser wrote:
> >
> > On Tuesday, February 15th, 2022 at 13:04, Emil Velikov
> > wrote:
> >
> > > Greetings everyone,
> > >
> > > Padron fo
This allows to tie the log message to a specific DRM device.
Signed-off-by: Simon Ser
Cc: Alex Deucher
Cc: Harry Wentland
Cc: Nicholas Kazlauskas
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd
Do we really need to make this a public API?
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
This function is the same as drm_kms_helper_hotplug_event, but takes
a connector instead of a device.
Signed-off-by: Simon Ser
---
drivers/gpu/drm/drm_probe_helper.c | 20
include/drm/drm_probe_helper.h | 1 +
2 files changed, 21 insertions(+)
diff --git a/drivers/gpu
This function sends a hotplug uevent with a CONNECTOR property.
Signed-off-by: Simon Ser
---
drivers/gpu/drm/drm_sysfs.c | 25 +
include/drm/drm_sysfs.h | 1 +
2 files changed, 26 insertions(+)
diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
In drm_connector_register, use drm_sysfs_connector_hotplug_event
instead of drm_sysfs_hotplug_event, because the hotplug event
only updates a single connector.
Signed-off-by: Simon Ser
---
drivers/gpu/drm/drm_connector.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a
when sending HDCP property update
uevents, see drm_sysfs_connector_status_event.
This has been tested with a wlroots patch [1].
amdgpu has been updated to use these new fine-grained uevents.
[1]: https://github.com/swaywm/wlroots/pull/2959
Simon Ser (4):
drm/sysfs: introduce
When updating a single connector, use
drm_kms_helper_connector_hotplug_event instead of
drm_kms_helper_hotplug_event.
Signed-off-by: Simon Ser
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 8
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 4 ++--
2 files
On Wednesday, June 9th, 2021 at 17:03, Daniel Vetter wrote:
> On Wed, Jun 09, 2021 at 10:39:03AM +0000, Simon Ser wrote:
> > When a uevent only updates a single connector, add a CONNECTOR property
> > to the uevent. This allows user-space to ignore other connectors when
> >
when sending HDCP property update
uevents, see drm_sysfs_connector_status_event.
This has been tested with a wlroots patch [1].
amdgpu and the probe-helper has been updated to use these new fine-grained
uevents.
[1]: https://github.com/swaywm/wlroots/pull/2959
Simon Ser (7):
drm/sysfs
This function sends a hotplug uevent with a CONNECTOR property.
Signed-off-by: Simon Ser
---
drivers/gpu/drm/drm_sysfs.c | 25 +
include/drm/drm_sysfs.h | 1 +
2 files changed, 26 insertions(+)
diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
This function is the same as drm_kms_helper_hotplug_event, but takes
a connector instead of a device.
Signed-off-by: Simon Ser
---
drivers/gpu/drm/drm_probe_helper.c | 23 +++
include/drm/drm_probe_helper.h | 1 +
2 files changed, 24 insertions(+)
diff --git a/drivers
In drm_connector_register, use drm_sysfs_connector_hotplug_event
instead of drm_sysfs_hotplug_event, because the hotplug event
only updates a single connector.
Signed-off-by: Simon Ser
---
drivers/gpu/drm/drm_connector.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a
When updating a single connector, use
drm_kms_helper_connector_hotplug_event instead of
drm_kms_helper_hotplug_event.
Signed-off-by: Simon Ser
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 8
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 4 ++--
2 files
If an hotplug event only updates a single connector, use
drm_kms_helper_connector_hotplug_event instead of
drm_kms_helper_hotplug_event.
Signed-off-by: Simon Ser
---
drivers/gpu/drm/drm_probe_helper.c | 19 +++
1 file changed, 15 insertions(+), 4 deletions(-)
diff --git a
When link-status changes, send a hotplug uevent which contains the
connector and property ID. That way, user-space can more easily
figure out that only the link-status property of this connector has
been updated.
Signed-off-by: Simon Ser
---
drivers/gpu/drm/i915/display/intel_dp.c | 2 ++
1
Mention that connectors need to be referenced manually if they are
to be accessed after the iteration has progressed or ended.
Signed-off-by: Simon Ser
---
include/drm/drm_connector.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/include/drm/drm_connector.h b/include/drm
On Tuesday, June 22nd, 2021 at 11:50, Werner Sembach
wrote:
> Unknown is when no monitor is connected or is when the
> connector/monitor is disabled.
I think the other connector props (link-status, non-desktop, etc) don't
have a special "unset" value, and instead the value is set to a random
en
On Tuesday, June 22nd, 2021 at 09:15, Pekka Paalanen
wrote:
> yes, I think this makes sense, even if it is a property that one can't
> tell for sure what it does before hand.
>
> Using a pair of properties, preference and active, to ask for something
> and then check what actually worked is good
Add links to the issue tracker and the IRC channel for the amdgpu
driver.
Signed-off-by: Simon Ser
Cc: Alex Deucher
Cc: Christian König
Cc: Pan Xinhui
---
MAINTAINERS | 2 ++
1 file changed, 2 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 0dc84339cff4..78bf10a1f5d5 100644
--- a
ff-by: Xiaogang Chen
To the best of my knowledge, this sounds correct.
Please wrap your commit message into 80-character lines so that it's easier
to read. Regardless, this is:
Acked-by: Simon Ser
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Pushed to drm-misc-next with a re-formatted commit message, thanks for
your contribution!
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
This allows to tie the log message to a specific DRM device.
Signed-off-by: Simon Ser
Cc: Alex Deucher
Cc: Harry Wentland
Cc: Nicholas Kazlauskas
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd
supported.
Signed-off-by: Simon Ser
Cc: Alex Deucher
Cc: Harry Wentland
Cc: Nicholas Kazlauskas
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display
On Friday, February 19th, 2021 at 6:22 PM, Kazlauskas, Nicholas
wrote:
> We can support cursor plane, but only if we have an overlay plane
> enabled that's using XRGB/ARGB.
>
> This is what we do on Chrome OS for video playback:
>
> Cursor Plane - ARGB
> Overlay Plane - ARGB Desktop/UI w
On Friday, February 19th, 2021 at 6:41 PM, Kazlauskas, Nicholas
wrote:
> > Related: how does this affect scaling? Right now there is a check that makes
> > sure the cursor plane scaling matches the primary plane's. Should we instead
> > check that the cursor plane scaling matches the top-most XR
This allows to tie the log message to a specific DRM device.
Signed-off-by: Simon Ser
Cc: Alex Deucher
Cc: Harry Wentland
Cc: Nicholas Kazlauskas
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd
("drm/amd/display: check cursor scaling")
Signed-off-by: Simon Ser
Cc: Alex Deucher
Cc: Harry Wentland
Cc: Nicholas Kazlauskas
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 32 +++
1 file changed, 19 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/a
Make sure there's an underlying pipe that can be used for the
cursor.
Signed-off-by: Simon Ser
Cc: Alex Deucher
Cc: Harry Wentland
Cc: Nicholas Kazlauskas
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/dr
supported.
Signed-off-by: Simon Ser
Cc: Alex Deucher
Cc: Harry Wentland
Cc: Nicholas Kazlauskas
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display
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
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 10 ++
1
if the 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, re-introduce the cursor rotation property, and check
that its value matches the underlying plane's.
Signed-off-by: Simon Ser
Cc
Hi,
On Wednesday, December 23rd, 2020 at 6:48 AM, Cornij, Nikola
wrote:
> Another interim update: so far to me it looks like this is an issue if there's
> fewer than 24 pixels left on the screen when moving the FB outside of the left
> edge (e.g. with 300x300 FB size, it repros with X = -280).
On Monday, February 22nd, 2021 at 9:59 PM, Cornij, Nikola
wrote:
> [AMD Official Use Only - Approved for External Use]
>
> Hi Simon,
>
> Yes, I did have a chance to wrap this up, indeed :-)
>
> It turned out this and other similar setup was hitting a legit HW
> limitation. I added a patch (pleas
On Monday, February 22nd, 2021 at 8:25 PM, Souptick Joarder
wrote:
> >> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:9804:38:
> >> warning: variable 'i' is uninitialized when used here
> >> [-Wuninitialized]
>timing = &edid->detailed_timings[i];
>
On Tuesday, February 23rd, 2021 at 12:44 AM, Nathan Chancellor
wrote:
> On Mon, Feb 22, 2021 at 11:05:17PM +0000, Simon Ser wrote:
> > On Monday, February 22nd, 2021 at 8:25 PM, Souptick Joarder
> > wrote:
> >
> > > >> drivers/gpu/drm/amd/amdgpu/../d
On Tuesday, February 23rd, 2021 at 6:42 PM, Alex Deucher
wrote:
> yeah, fdo ran out of disk space so I moved to gitlab:
>
> https://gitlab.freedesktop.org/agd5f/linux/-/commits/drm-next
Ah, thanks for the info, my bad!
___
amd-gfx mailing list
amd-gfx
> Improved the patch, now in the process of getting it reviewed
> internally. It'll be posted for upstream thereafter.
Thanks, perfect!
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Changes in v2: drop "amd/display: fail on cursor plane without an
underlying plane". This retains the current behavior instead.
Simon Ser (5):
amd/display: convert DRM_DEBUG_ATOMIC to drm_dbg_atomic
amd/display: check cursor plane matches underlying plane
amd/display: add cursor
This allows to tie the log message to a specific DRM device.
Signed-off-by: Simon Ser
Cc: Alex Deucher
Cc: Harry Wentland
Cc: Nicholas Kazlauskas
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd
1 - 100 of 270 matches
Mail list logo
