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
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: Meliss
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
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
Document flags accepted by the page-flip and atomic IOCTLs.
Signed-off-by: Simon Ser
Cc: Daniel Vetter
---
include/uapi/drm/drm_mode.h | 44 -
1 file changed, 43 insertions(+), 1 deletion(-)
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm
Note, the headers in include/drm/ must be updated in a special manner
from the kernel. See the README in the subdir for details.
On Wednesday, May 25th, 2022 at 00:03, Alex Deucher
wrote:
> > Why would anyone want to run at 8bpc when they have a panel with
> > higher color depth? So I think someone is going to be doing that
> > modeset eventually anyway.
>
> We used to do something similar, but then got piles of bug repor
On Wednesday, May 25th, 2022 at 10:35, Michel Dänzer
wrote:
> > Mind that "max bpc" is always in auto. It's only an upper limit, with
> > the assumption that the driver can choose less.
>
> It seems to me like the "max bpc" property is just kind of bad API,
> and trying to tweak it to cater to m
On Wednesday, May 25th, 2022 at 15:51, Daniel Vetter wrote:
> > > Ofc in reality you can still flood your compositor and they're not very
> > > robust, but with umf it's trivial to just hang your compositor forever and
> > > nothing happens.
> >
> > You can add that to the list of reasons why com
On Friday, May 6th, 2022 at 20:02, Jason Ekstrand wrote:
> diff --git a/include/uapi/linux/dma-buf.h b/include/uapi/linux/dma-buf.h
> index 46f1e3e98b02..70e213a0d7d9 100644
> --- a/include/uapi/linux/dma-buf.h
> +++ b/include/uapi/linux/dma-buf.h
> @@ -96,6 +96,24 @@ struct dma_buf_sync {
> *
The uAPI looks good to me as well, if that helps.
Acked-by: Simon Ser
Document how to obtain the size of a DMA-BUF. This is what
Wayland compositors are doing.
Mention the kernel version numbers from which DMA-BUF features are
available.
Signed-off-by: Simon Ser
Cc: Daniel Vetter
Cc: Jason Ekstrand
---
include/uapi/linux/dma-buf.h | 10 +++---
1 file
/sys/kernel/dmabuf/caps directory which allows the DMA-BUF
subsystem to advertise supported features. Add a
sync_file_import_export entry which indicates that importing and
exporting sync_files from/to DMA-BUFs is supported.
Signed-off-by: Simon Ser
Cc: Jason Ekstrand
Cc: Daniel Vetter
Cc: Bas
/sys/kernel/dmabuf/caps directory which allows the DMA-BUF
subsystem to advertise supported features. Add a
sync_file_import_export entry which indicates that importing and
exporting sync_files from/to DMA-BUFs is supported.
Signed-off-by: Simon Ser
Cc: Jason Ekstrand
Cc: Daniel Vetter
Cc: Bas
On Thursday, May 26th, 2022 at 19:40, Simon Ser wrote:
> diff --git a/Documentation/ABI/testing/sysfs-kernel-dmabuf-buffers
> b/Documentation/ABI/testing/sysfs-kernel-dmabuf-buffers
> index 5d3bc997dc64..682d313689d8 100644
> --- a/Documentation/ABI/testing/sysfs-kernel-dmabuf-buf
Documentation/ABI/testing/, add it to
MAINTAINERS
- Fix kernel version (Daniel)
- Remove unnecessary brackets (Jason)
- Fix SPDX comment style
Signed-off-by: Simon Ser
Reviewed-by: Jason Ekstrand
Cc: Daniel Vetter
Cc: Bas Nieuwenhuizen
Cc: Christian König
Cc: Greg KH
---
.../ABI/testing/sysfs
On Monday, May 30th, 2022 at 09:09, Christian König
wrote:
> I find a separate directory rather unusual, but can't come up with any
> better idea either.
>
> IIRC the security module had a mask file with names for the supported
> capabilities.
Are you referring to /sys/kernel/security/lsm?
Thi
On Monday, May 30th, 2022 at 09:20, Greg KH wrote:
> > > +static struct attribute *dma_buf_caps_attrs[] = {
> > > + &dma_buf_sync_file_import_export_attr.attr,
> > > + NULL,
> > > +};
> > > +
> > > +static const struct attribute_group dma_buf_caps_attr_group = {
> > > + .attrs = dma_buf_caps_attr
On Wednesday, June 1st, 2022 at 09:21, Pekka Paalanen
wrote:
> What's DSC?
Display Stream Compression. A "visually" lossless compression format
used between the GPU and the sink to reduce bandwidth usage.
https://vesa.org/vesa-display-compression-codecs/
Documentation/ABI/testing/, add it to
MAINTAINERS
- Fix kernel version (Daniel)
- Remove unnecessary brackets (Jason)
- Fix SPDX comment style
v4: improve sysfs code (Greg)
Signed-off-by: Simon Ser
Reviewed-by: Jason Ekstrand
Cc: Daniel Vetter
Cc: Bas Nieuwenhuizen
Cc: Christian König
Cc: Greg
On Thursday, June 2nd, 2022 at 07:40, Greg KH wrote:
> On Wed, Jun 01, 2022 at 04:13:14PM +0000, Simon Ser wrote:
>
> > To discover support for new DMA-BUF IOCTLs, user-space has no
> > choice but to try to perform the IOCTL on an existing DMA-BUF.
>
> Which is co
On Thursday, June 2nd, 2022 at 08:25, Greg KH wrote:
> On Thu, Jun 02, 2022 at 06:17:31AM +0000, Simon Ser wrote:
>
> > On Thursday, June 2nd, 2022 at 07:40, Greg KH g...@kroah.com wrote:
> >
> > > On Wed, Jun 01, 2022 at 04:13:14PM +, Simon Ser wrote:
> >
Reviewed-by: Simon Ser
Pushed to drm-misc-next, thanks!
On Wednesday, June 29th, 2022 at 16:46, Dennis Tsiang
wrote:
> Thanks for your comments. This is not intended to be used for KMS, where
> indeed there would be no difference. This proposal is for other Graphics
> APIs such as Vulkan, which requires the application to be explicit
> upfront about
Saleemkhan Jamadar (1):
tests/amdgpu/vcn:vcn encoder unit test
Sathishkumar S (1):
tests/amdgpu: fix decode test failure on VCN2.5
Simon Ser (6):
gen_table_fourcc: strip _MODIFIER suffix for INVALID
xf86drmMode: constify drmModeAtomicReq functions
xf86drmMode
Reviewed-by: Simon Ser
Both doc patches pushed, thanks. I had to manually edit them because they
wouldn't apply cleanly. Next time, please use git-send-email (see
https://git-send-email.io/ for setup instructions).
On Monday, April 4th, 2022 at 23:35, Randy Dunlap wrote:
> On 4/4/22 09:04, Simon Ser wrote:
>
> > Both doc patches pushed, thanks. I had to manually edit them because they
> > wouldn't apply cleanly. Next time, please use git-send-email (see
> > https://git-send-ema
On Tuesday, April 5th, 2022 at 16:39, Randy Dunlap
wrote:
> On 4/4/22 23:26, Javier Martinez Canillas wrote:
>
> > On 4/5/22 08:12, Simon Ser wrote:
> >
> > > On Monday, April 4th, 2022 at 23:35, Randy Dunlap rdun...@infradead.org
> > > wrote:
> >
On Tuesday, April 5th, 2022 at 19:58, Randy Dunlap
wrote:
> On 4/5/22 08:05, Simon Ser wrote:
>
> > On Tuesday, April 5th, 2022 at 16:39, Randy Dunlap rdun...@infradead.org
> > wrote:
> >
> > > On 4/4/22 23:26, Javier Martinez Canillas wrote:
> > >
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
Very nice plan! Big +1 for the overall approach.
On Thursday, April 7th, 2022 at 17:38, Hans de Goede
wrote:
> The drm_connector brightness properties
> ===
>
> bl_brightness: rw 0-int32_max property controlling the brightness setting
> of the connected displ
Hi Hans,
Thanks for your details replies!
On Thursday, April 7th, 2022 at 19:43, Hans de Goede
wrote:
> > On Thursday, April 7th, 2022 at 17:38, Hans de Goede
> > wrote:
> >
> >> The drm_connector brightness properties
> >> ===
> >>
> >> bl_brightness: rw
Is amdgpu_display_get_fb_info ever called with NULL tiling_flags/tmz_surface?
If not, there's no point in adding NULL checks.
Would it be an option to only support the KMS prop for Good devices,
and continue using the suboptimal existing sysfs API for Bad devices?
(I'm just throwing ideas around to see what sticks, feel free to ignore.)
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 NUL
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 shou
On Wednesday, April 13th, 2022 at 10:32, Daniel Vetter wrote:
> Inflicting hotplug complications on all userspace (including uevent
> handling for this hotpluggable backlight and everything) just because
> fixing the old crap systems is work is imo really not a good idea. Much
> better if we get
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
>
On Friday, August 26th, 2022 at 11:49, Sebastian Wick
wrote:
> > > +/*
> > > + * DRM_MODE_ATOMIC_ALLOW_MODESET
> > > + *
> > > + * Allow the update to result in visible artifacts such as a black
> > > screen.
> >
> > Maybe add:
> >
> > ...temporary or transient visible artifacts while the upd
On Friday, August 26th, 2022 at 15:10, Sebastian Wick
wrote:
> On Fri, Aug 26, 2022 at 2:17 PM Simon Ser cont...@emersion.fr wrote:
>
> > On Friday, August 26th, 2022 at 11:49, Sebastian Wick
> > sebastian.w...@redhat.com wrote:
> >
> > > > > +/*
>
This can help figure out why the kernel returns EINVAL from
user-space.
Signed-off-by: Simon Ser
Cc: Daniel Vetter
Cc: Lyude Paul
---
drivers/gpu/drm/drm_atomic_helper.c | 32 +++--
1 file changed, 26 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm
Sometimes drivers are missing logs when they return EINVAL.
Printing the failure here in common code can help understand where
EINVAL is coming from.
All other atomic_check() calls in this file already have similar
logging.
Signed-off-by: Simon Ser
Cc: Daniel Vetter
Cc: Lyude Paul
Sometimes drivers are missing logs when they return EINVAL.
Printing the failure here in common code can help understand where
EINVAL is coming from.
All other atomic_check() calls in this file already have similar
logging.
v2: add missing newlines
Signed-off-by: Simon Ser
Cc: Daniel Vetter
This helps user-space understand why an atomic commit fails.
v2: new patch
Signed-off-by: Simon Ser
---
drivers/gpu/drm/drm_bridge.c | 18 --
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
index
This can help figure out why the kernel returns EINVAL from
user-space.
v2: add missing newlines
Signed-off-by: Simon Ser
Cc: Daniel Vetter
Cc: Lyude Paul
---
drivers/gpu/drm/drm_atomic_helper.c | 32 +++--
1 file changed, 26 insertions(+), 6 deletions(-)
diff --git
CC Ville for the ASYNC bits, see below.
On Friday, August 26th, 2022 at 10:53, Pekka Paalanen
wrote:
> > +/**
> > + * DRM_MODE_PAGE_FLIP_EVENT
> > + *
> > + * Request that the kernel sends back a vblank event (see
> > + * struct drm_event_vblank) when the page-flip is done.
>
> ...with type =
Document flags accepted by the page-flip and atomic IOCTLs.
v2 (Pekka):
- Mention DRM_EVENT_FLIP_COMPLETE in DRM_MODE_PAGE_FLIP_EVENT docs.
- Expand DRM_MODE_ATOMIC_NONBLOCK and DRM_MODE_ATOMIC_ALLOW_MODESET
description.
Signed-off-by: Simon Ser
Cc: Daniel Vetter
Cc: Pekka Paalanen
Cc
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 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 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:
> >
> > 1
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 Xor
On Tuesday, August 30th, 2022 at 10:31, 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
> >simplifies user-space, but then user-space has no reliable way to figure
> >
(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
> >simplif
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
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 regist
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)
15 already 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
---
drive
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
nd
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
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
-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
else. 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 Vette
Avoid aliasing violation
Matthieu Herrb (1):
Remove unused 3rd parameter to open(2)
Ruijing Dong (2):
tests/amdgpu/vcn: align comments for AMDGPU_HW_IP_VCN_ENC
tests/amdgpu/vcn: add unified queue support in vcn4
Simon Ser (3):
xf86drm: add drmGetFormatName()
tests/modetest
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 hdr_o
Replace DRM_DEBUG_KMS() with drm_dbg_kms() which allows specifying
the DRM device to provide more context.
Signed-off-by: Simon Ser
---
drivers/gpu/drm/drm_framebuffer.c | 66 +++
1 file changed, 33 insertions(+), 33 deletions(-)
diff --git a/drivers/gpu/drm
On Friday, September 9th, 2022 at 12:23, Hans de Goede
wrote:
> "people using
> non fully integrated desktop environments like e.g. sway often use custom
> scripts binded to hotkeys to get functionality like the brightness
> up/down keyboard hotkeys changing the brightness. This typically involv
On Friday, September 9th, 2022 at 12:12, Hans de Goede
wrote:
> Phase 3: Deprecate /sys/class/backlight uAPI
>
>
> Once most userspace has moved over to using the new drm_connector
> brightness props, a Kconfig option can be added to stop exporting
>
On Friday, September 9th, 2022 at 15:53, Pekka Paalanen
wrote:
> On Fri, 09 Sep 2022 13:39:37 +
> Simon Ser cont...@emersion.fr wrote:
>
> > On Friday, September 9th, 2022 at 12:12, Hans de Goede hdego...@redhat.com
> > wrote:
> >
> > > Phase 3:
longer displayed (Daniel)
- Add note about sinks deciding to show artifacts on their own (Pekka, Daniel)
Signed-off-by: Simon Ser
Cc: Daniel Vetter
Cc: Pekka Paalanen
Cc: Ville Syrjala
---
include/uapi/drm/drm_mode.h | 63 -
1 file changed, 62 insertions
On Wednesday, September 28th, 2022 at 12:06, Pekka Paalanen
wrote:
> > +/**
> > + * DRM_MODE_PAGE_FLIP_FLAGS
> > + *
> > + * Bitmask of flags suitable for &drm_mode_crtc_page_flip_target.flags.
>
> Should this mention also drm_mode_crtc_page_flip.flags?
>
> UAPI header defines both structs.
d
ion about 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_support
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
Ville, 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/gp
nd
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-
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
15 already 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
-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
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
> > +
On Friday, September 30th, 2022 at 16:44, Ville Syrjälä
wrote:
> On Fri, Sep 30, 2022 at 04:20:29PM +0200, Sebastian Wick wrote:
>
> > On Fri, Sep 30, 2022 at 9:40 AM Pekka Paalanen ppaala...@gmail.com wrote:
> >
> > > On Thu, 29 Sep 2022 20:06:50 +0200
> > > Sebastian Wick sebastian.w...@redh
On Tuesday, July 12th, 2022 at 05:32, Zack Rusin wrote:
> To do that introduce DRM_CLIENT_CAP_SUPPORTS_VIRTUAL_CURSOR_PLANE
Nit: maybe we can name this "DRM_CLIENT_CAP_VIRTUAL_CURSOR_PLANE" or
even "DRM_CLIENT_CAP_VIRTUAL_CURSORS", since "CAP" already implies that
this is a capability that the D
Overall this looks pretty good to me, thanks for working on this!
Acked-by: Simon Ser
Adding zeis...@freebsd.org for FreeBSD. I'll try to see if I can ping
some NetBSD/OpenBSD folks too.
On Tuesday, November 12, 2019 4:03 PM, Daniel Vetter
wrote:
> Hi all,
>
> Dave and me chatted about this last week on irc. Essentially we have:
>
> $ git grep SPDX.*GPL -- ':(glob)drivers/gpu/dr
On Tuesday, October 8, 2019 6:03 PM, Daniel Vetter wrote:
> > > > > In any case, this doesn't change the patch itself. Probably something
> > > > > worth
> > > > > mentionning in the commit message.
> > > >
> > > > Yes, recording these use cases would be very nice.
> > >
> > > There's a lot more
On Tuesday, October 8, 2019 6:16 PM, Daniel Vetter wrote:
> On Tue, Oct 8, 2019 at 5:11 PM Simon Ser cont...@emersion.fr wrote:
>
> > On Tuesday, October 8, 2019 6:03 PM, Daniel Vetter dan...@ffwll.ch wrote:
> >
> > > > > > > In any case, this do
ses
duplicate zpos values (Pekka)
v5: reword commit message (Pekka, James)
v6: remove mention of Arm GPUs having planes which can't overlap,
because this isn't uAPI yet (Daniel)
Signed-off-by: Simon Ser
Reviewed-by: Pekka Paalanen
Cc: Marius Vlad
Cc: Daniel Vetter
Cc: James Qian Wan
On Monday, October 14, 2019 12:17 PM, Daniel Vetter wrote:
> Oleg, will you be looking at this? With the reproducer and full drm
> debugging enabled it shouldn't be too hard to figure out what's going on
> heere ...
Oleg is no longer working at Intel. I don't think he monitors dri-devel
anymore.
Hi all,
I've been working on adding VRR support to Sway [1] (a Wayland
compositor). The compositor just sets the VRR_ENABLED property.
This works fine for some screens, but causes flcikering for other
screens as expected [2]. Fixing the flickering is something we've
talked about last XDC [3]. The
On Thursday, March 12, 2020 11:45 AM, Michel Dänzer wrote:
> On 2020-03-11 9:09 p.m., Simon Ser wrote:
>
> > Hi all,
> > I've been working on adding VRR support to Sway [1] (a Wayland
> > compositor). The compositor just sets the VRR_ENABLED property.
> > Th
On Monday, March 16, 2020 5:04 PM, Jason Ekstrand wrote:
> Hopefully, that will provide some motivation for other compositors
> (kwin, gnome-shell, etc.) because they now have a real user of it in
> an upstream driver for a major desktop platform and not just a few
> weston examples. However, som
On Thursday, March 12, 2020 3:43 PM, Harry Wentland wrote:
> Not the main VRR expert and we're still discussing this internally but I
> think it'll very much depend on the display whether you'll see flicker
> in this case.
>
> The other complication is that for gaming we don't want to use the
> c
Hi,
> 1) Letting the VM-viewer window-system draw the cursor as it normally
> would draw it.
Why is this important? Can't the VM viewer hide the cursor and use a
sub-surface to manually draw the cursor plane configured by the guest?
This would also allow the compositor running inside the VM to c
> Hi,
>
> On 3/18/20 3:38 PM, Simon Ser wrote:
> > Hi,
> >
> >> 1) Letting the VM-viewer window-system draw the cursor as it normally
> >> would draw it.
> >
> > Why is this important? Can't the VM viewer hide the cursor and use a
> > s
On Thursday, March 19, 2020 10:57 AM, Pekka Paalanen
wrote:
> On Wed, 18 Mar 2020 14:38:48 +
> Simon Ser cont...@emersion.fr wrote:
>
> > Hi,
> >
> > > 1. Letting the VM-viewer window-system draw the cursor as it normally
> > > would draw it.
>
On Thursday, March 19, 2020 2:16 PM, Daniel Vetter wrote:
> On Thu, Mar 19, 2020 at 1:58 PM Pekka Paalanen ppaala...@gmail.com wrote:
>
> > On Thu, 19 Mar 2020 12:49:27 +0100
> > Hans de Goede hdego...@redhat.com wrote:
> >
> > > Hi,
> > > On 3/19/20 11:00 AM, Pekka Paalanen wrote:
> > >
> > > >
On Thursday, March 19, 2020 7:18 PM, Hans de Goede wrote:
> > > > The only way to fix that is to stop Weston from putting non-cursor
> > > > content on the cursor plane.
> > >
> > > Correct.
> >
> > Is that something that should be done?
> > If the hotspot property also had a "disabled" value, th
> >>> Is that something that should be done?
> >>> If the hotspot property also had a "disabled" value, then Weston could
> >>> set the hotspot to disabled when it is using the cursor plane for
> >>> non-cursor content and not lose the feature. And of course set hotspot
> >>> correctly when it in f
On Friday, March 20, 2020 11:59 AM, Thomas Hellström
wrote:
> On 3/20/20 10:13 AM, Pekka Paalanen wrote:
>
> > On Thu, 19 Mar 2020 23:57:09 +0100
> > Thomas Hellström (VMware) thomas...@shipmail.org wrote:
> >
> > > Hi,
> > > On 3/19/20 10:07 PM, Simo
> On Tue, 10 Sep 2019 11:20:16 +
> Simon Ser wrote:
>
> > On Tuesday, September 10, 2019 1:38 PM, Pekka Paalanen
> > wrote:
> >
> > > On Tue, 10 Sep 2019 10:09:55 +
> > > Simon Ser cont...@emersion.fr wrote:
> > >
> > > &g
that zpos
disambiguation via plane object IDs is a recommendation for drivers, not
something user-space can rely on.
v2: clarify drm_plane_state.zpos docs (Daniel)
Signed-off-by: Simon Ser
Cc: Pekka Paalanen
Cc: Marius Vlad
Cc: Daniel Vetter
---
drivers/gpu/drm/drm_blend.c | 8
401 - 500 of 1005 matches
Mail list logo
