[ANNOUNCE] wayland 1.22.93
Simon Ser (2): server: document wl_display_add_socket_fd() ownership build: bump to version 1.22.93 for the RC1 release Vlad Zahorodnii (1): server: Clarify fd ownership in wl_client_create() git tag: 1.22.93 https://gitlab.freedesktop.org/wayland/wayland/-/releases/1.22.93/downloads/wayland-1.22.93.tar.xz SHA256: b22a93184cf4a1eb530453d560bc686aa6b69545ab69fba86ada447941033808 wayland-1.22.93.tar.xz SHA512: 8b12e3b2c76210dd85e9e82714ae60ebafd5028da294b8d132f765ef0235f25b0e9a5032faa02999652edf03abbb63a2fafb9043a9f29d4fbeca1d4355896803 wayland-1.22.93.tar.xz PGP: https://gitlab.freedesktop.org/wayland/wayland/-/releases/1.22.93/downloads/wayland-1.22.93.tar.xz.sig
[ANNOUNCE] wayland 1.22.92
This is the beta release for Wayland 1.23. Full commit history below. Julian Orth (1): protocol: explicitly describe wl_keyboard state Simon Ser (1): build: bump to version 1.22.92 for the beta release git tag: 1.22.92 https://gitlab.freedesktop.org/wayland/wayland/-/releases/1.22.92/downloads/wayland-1.22.92.tar.xz SHA256: dc0aefba6c9c287982733985ea9be7b529ee1cee214f03513fe4cee406a0a194 wayland-1.22.92.tar.xz SHA512: 172ecac3d1d9e60830482cbd382d2b6a35413e67bfd8865f999baca9a694d2c922feca00ec1435f465643397bc7c65136e2912b373aefaad26407b53bb4cfaef wayland-1.22.92.tar.xz PGP: https://gitlab.freedesktop.org/wayland/wayland/-/releases/1.22.92/downloads/wayland-1.22.92.tar.xz.sig
[ANNOUNCE] wayland 1.22.91
This is the alpha release for Wayland 1.23.
Besides numerous bugfixes and protocol clarifications, Wayland 1.23 includes
the following new features:
- A mechanism to set the size of the internal connection buffer used by
libwayland
- An enum-header mode for wayland-scanner to generate headers with only enums
- wayland-scanner now generates validator functions for enums on the server
side
- Protocols can now indicate with a "deprecated-since" XML attribute that a
request, event or enum entry is deprecated
- An API to set a name for a queue to aid debugging
- wl_client_get_user_data() and wl_client_set_user_data() to more easily attach
custom data to a client
- OpenBSD support
- A wl_shm.release request for proper cleanup of this global
Full commit history below.
6t8k (1):
cursor: memfd_create: try MFD_NOEXEC_SEAL
Alex Yang (1):
debug: Replace "@" with "#" in logs
Andreas Cord-Landwehr (1):
Consider pkgconfig sysroot for pkgdatadir
Ben Widawsky (1):
protocol: clarify scale expecations
Chloé Vulquin (1):
xcursor: catch theme inheritance loops
Colin Kinloch (1):
protocol: Undefine wl_display_sync callback data
Consolatis (1):
cursor: add aliases for cursor name spec
David Benjamin (2):
connection: avoid calling memcpy on NULL, 0
util: fix undefined behavior in wl_array_for_each
David Edmundson (1):
client: Add method to get display for a given proxy
Derek Foreman (2):
client: Allow setting names for queues
client: print debug events that have no listener
Erik Chen (1):
connection: Spruce up logging for client errors.
Francesco Guastella (1):
build: define tests in egl/meson.build when the 'tests' option is enabled
Isaac Freund (1):
wl_touch.cancel: document lack of frame event
John Lindgren (1):
connection: Small simplification to wl_connection_write()
Jordan Williams (1):
egl: Disable symbols check for static builds
Joshua Ashton (1):
event-loop: Handle EINTR and EAGAIN in wl_event_loop_dispatch
Julian Orth (2):
protocol: wl_subsurface will never be focused
Clarify behavior of buffer transformations
Kirill Chibisov (1):
protocol: clarify defaults with wl_compositor@v6
Kirill Primak (3):
protocol: improve wl_subsurface.{set_position,place_above} description
protocol: clarify pending wl_buffer destruction
event-loop: use wl_priv_signal for the destroy signal
Manuel Stoeckl (3):
protocol: add new shm formats
tests: drop misleading fixed-benchmark
connection: Dynamically resize connection buffers
Mikhail Gusarov (1):
doc: Improve wording for packed IDs
Peter Hutterer (1):
Add a triage-policies file for bugbot
Sebastian Wick (3):
protocol: specify the exact form of premultiplication
server: add wl_client_get_user_data/wl_client_set_user_data
protocol: define content updates and their internal queue
Simon Ser (45):
build: re-open main branch for regular development
protocol: disallow re-using wl_data_source
util: simplify wl_fixed_to_double()
server: stop wl_display_run() on dispatch error
build: override wayland-scanner dep
protocol: refer to wl_surface.offset in set_cursor
server: use bool in struct fields
tests: add missing proxy-test
egl: add missing ABI check test
tests: manually wrap libc functions
protocol: fix whitespace
cursor: check return value of snprintf()
ci: upgrade ci-templates
ci: upgrade Debian to bookworm
ci: upgrade FreeBSD to 13.2
protocol: refer to wl_surface.offset in wl_data_device.start_drag
gitlab: make issue template the default
util: simplify wl_fixed_from_double()
build: add a gen-scanner-test target
protocol: document wl_surface.offset for sub-surfaces
util: use C23 typeof if available
util: use C23 deprecated attribute
shm: fix resource versions
protocol: add wl_shm.release request
shm: implement version 2
protocol: mention wl_surface events from wl_output.{scale,transform}
Introduce enum wl_arg_type
connection: simplify wl_closure_lookup_objects() loop
client: simplify create_outgoing_proxy() loop
client: simplify create_proxies() loop
connection: use enum wl_arg_type in wl_message_count_arrays()
protocol: document that color channels provide electrical values
scanner: add new enum-header mode
tests: add scanner test for enum-header
util: convert macros to inline functions
ci: bump Meson version to 0.57
build: bump minimum Meson version to 0.57
ci: use --fatal-meson-warnings
ci: turn on -Dwerror=true for FreeBSD
scanner: add validators for enums
Add support for the deprecated-since XML attribute
protocol: mark wl_pointer.axis_discrete as deprecated
tests: add deprecated-sinc
[ANNOUNCE] Wayland 1.23.0 release schedule
Hi all, Here is the release schedule for Wayland 1.23.0: - Alpha: April 25th (in 2 weeks) - Beta: May 9th - RC1: May 23rd - First potential final release: May 30th Package maintainers are encouraged to pick up the pre-releases to make sure packaging can be tested (and fixed) before the stable release. Let me know if you'd like a pending patch to make it in the release. Thanks, Simon
Re: [RFC PATCH v4 10/42] drm/colorop: Add TYPE property
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 behave. Example:
"type" (immutable): enum {Overlay, Primary, Cursor} = Primary
Re: [PATCH] scanner.c: prefer strchr() over for loop and toupper() in place
I personally find the current code more readable.
Re: protocol rules question: is an array arg of object ids legal?
On Wednesday, December 27th, 2023 at 19:09, jleivent wrote: > Is it legal for a protocol message to contain an array arg where the > contents of the array are Wayland object ids? I don't see any instance > of this in any current protocol descriptions I have. Technically nothing prevents this, but this will be pretty awkward since client and server will need to convert to/from IDs (plus wrapping/unwrapping the wl_proxy for the client) and there won't be any type safety. In general it's better to have a request/event carrying a single object which can be sent multiple times to accumulate a list of objects.
Re: Issues with cursors (cursor-shape-v1)
For wlroots-based compositors this is passed down via XCURSOR_THEME and XCURSOR_SIZE just like on X11 although env vars aren't a good fit for configuration. There was an earlier xcursor-configuration protocol with per-seat live XCursor config which ended up being abandoned. I wouldn't recommend this approach, it's too complicated and roundabout. What exactly are the missing cursor shapes? I'm surprised it's not enough.
Re: (subset) [PATCH RFC v7 00/10] Support for Solid Fill Planes
On Monday, December 4th, 2023 at 18:51, Abhinav Kumar wrote: > > Where are the IGT and userspace for this uAPI addition? > > Yes, we made IGT changes to test and validate this. We will post them on > the IGT dev list shortly and CC you. > > We do not have a compositor change yet for this as we primarily used IGT > to validate this. Yes, please post the IGT. > Can we re-try to land this once IGT changes are accepted? There will need to be a user-space implementation as well, since this is a hard requirement for new uAPI [1]. Maybe I'll give this a go if I have time. [1]: https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#open-source-userspace-requirements
Re: (subset) [PATCH RFC v7 00/10] Support for Solid Fill Planes
On Saturday, December 2nd, 2023 at 22:41, Dmitry Baryshkov wrote: > On Fri, 27 Oct 2023 15:32:50 -0700, Jessica Zhang wrote: > > > Some drivers support hardware that have optimizations for solid fill > > planes. This series aims to expose these capabilities to userspace as > > some compositors have a solid fill flag (ex. SOLID_COLOR in the Android > > hardware composer HAL) that can be set by apps like the Android Gears > > test app. > > > > In order to expose this capability to userspace, this series will: > > > > [...] > > > Applied to drm-misc-next, thanks! Where are the IGT and userspace for this uAPI addition?
Re: Introducing xwayland-run, a set of small utilities to run X11 and Wayland clients
On Wednesday, November 29th, 2023 at 10:35, Olivier Fourdan wrote: > > I'd prefer this to be kept in your personal namespace: I'd prefer not to > > make > > this an official Wayland project. > > Well, that was quick! :) > > If I may, would it be possible to elaborate on the rationale behind your > opinion, is that because there is no interest at all, because of the quality > of the code, because of Python, or because it's partly about Xwayland and X11? To me the main downside is that this project has a hardcoded list of compositors. I don't think compositor-specific scripts are a good thing to have upstream. Moreover, last time I asked to make something an official Wayland project (IIRC Waypipe) the reply was "no". I don't see why this one would be any different.
Re: Introducing xwayland-run, a set of small utilities to run X11 and Wayland clients
On Wednesday, November 29th, 2023 at 10:10, Olivier Fourdan wrote: > So my question is, if there is any interest for such a project [4], should > this be moved to the wayland namespace in gitlab (we could even change the > name of the project), should that be added to the existing "wayland-utility" > project that we have already, or if there's no interest it's fine to stay in > my own gitlab namespace for now? I'd prefer this to be kept in your personal namespace: I'd prefer not to make this an official Wayland project. Simon
Re: [PATCH v6 6/6] drm/doc: Define KMS atomic state set
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: > > > > > 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: > > > > > > > > > > > > > > > > > > +An atomic commit with the flag > > > > > > > > > > > > > > DRM_MODE_PAGE_FLIP_ASYNC is allowed to > > > > > > > > > > > > > > +effectively change only the FB_ID property on any > > > > > > > > > > > > > > planes. No-operation changes > > > > > > > > > > > > > > +are ignored as always. [...] > > > > > > > > > > > > > > During the hackfest in Brno, it was mentioned that > > > > > > > > > > > > > > a commit which re-sets the same FB_ID could > > > > > > > > > > > > > > actually have an effect with VRR: It could trigger > > > > > > > > > > > > > > scanout of the next frame before vertical blank has > > > > > > > > > > > > > > reached its maximum duration. Some kind of > > > > > > > > > > > > > > mechanism is required for this in order to allow > > > > > > > > > > > > > > user space to perform low frame rate compensation. > > > > > > > > > > > > > > > > > > > > > > > > Xaver tested this hypothesis in a flipping the same fb > > > > > > > > > > > > in a VRR monitor > > > > > > > > > > > > and it worked as expected, so this shouldn't be a > > > > > > > > > > > > concern. > > > > > > > > > > > > Right, so it must have some effect. It cannot be simply > > > > > > > > > > > > ignored like in > > > > > > > > > > > > the proposed doc wording. Do we special-case re-setting > > > > > > > > > > > > the same FB_ID > > > > > > > > > > > > as "not a no-op" or "not ignored" or some other way? > > > > > > > > > > > > There's an effect in the refresh rate, the image won't > > > > > > > > > > > > change but it > > > > > > > > > > > > will report that a flip had happened asynchronously so > > > > > > > > > > > > the reported > > > > > > > > > > > > framerate will be increased. Maybe an additional > > > > > > > > > > > > wording could be like: > > > > > > > > > > > > > > > > > > > > Flipping to the same FB_ID will result in a immediate flip > > > > > > > > > > as if it was > > > > > > > > > > changing to a different one, with no effect on the image > > > > > > > > > > but effecting > > > > > > > > > > the reported frame rate. > > > > > > > > > > > > > > > > > > Re-setting FB_ID to its current value is a special case > > > > > > > > > regardless of > > > > > > > > > PAGE_FLIP_ASYNC, is it not? > > > > > > > > > > > > > > > > No. The rule has so far been that all side effects are observed > > > > > > > > even if you flip to the same fb. And that is one of my > > > > > > > > annoyances > > > > > > > > with this proposal. The rules will now be different for async > > > > > > > > flips > > > > > > > > vs. everything else. > > > > > > > > > > > > > > Well with the patches the async page-flip case is exactly the > > > > > > > same as > > > > > > > the non-async page-flip case. In both cases, if a FB_ID is > > > > > &
Re: [PATCH v6 6/6] drm/doc: Define KMS atomic state set
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 flag > > > > > > > > > > > > DRM_MODE_PAGE_FLIP_ASYNC is allowed to > > > > > > > > > > > > +effectively change only the FB_ID property on any > > > > > > > > > > > > planes. No-operation changes > > > > > > > > > > > > +are ignored as always. [...] > > > > > > > > > > > > During the hackfest in Brno, it was mentioned that a > > > > > > > > > > > > commit which re-sets the same FB_ID could actually have > > > > > > > > > > > > an effect with VRR: It could trigger scanout of the > > > > > > > > > > > > next frame before vertical blank has reached its > > > > > > > > > > > > maximum duration. Some kind of mechanism is required > > > > > > > > > > > > for this in order to allow user space to perform low > > > > > > > > > > > > frame rate compensation. > > > > > > > > > > > > > > > > > > > > Xaver tested this hypothesis in a flipping the same fb in a > > > > > > > > > > VRR monitor > > > > > > > > > > and it worked as expected, so this shouldn't be a concern. > > > > > > > > > > Right, so it must have some effect. It cannot be simply > > > > > > > > > > ignored like in > > > > > > > > > > the proposed doc wording. Do we special-case re-setting the > > > > > > > > > > same FB_ID > > > > > > > > > > as "not a no-op" or "not ignored" or some other way? > > > > > > > > > > There's an effect in the refresh rate, the image won't > > > > > > > > > > change but it > > > > > > > > > > will report that a flip had happened asynchronously so the > > > > > > > > > > reported > > > > > > > > > > framerate will be increased. Maybe an additional wording > > > > > > > > > > could be like: > > > > > > > > > > > > > > > > Flipping to the same FB_ID will result in a immediate flip as > > > > > > > > if it was > > > > > > > > changing to a different one, with no effect on the image but > > > > > > > > effecting > > > > > > > > the reported frame rate. > > > > > > > > > > > > > > Re-setting FB_ID to its current value is a special case > > > > > > > regardless of > > > > > > > PAGE_FLIP_ASYNC, is it not? > > > > > > > > > > > > No. The rule has so far been that all side effects are observed > > > > > > even if you flip to the same fb. And that is one of my annoyances > > > > > > with this proposal. The rules will now be different for async flips > > > > > > vs. everything else. > > > > > > > > > > Well with the patches the async page-flip case is exactly the same as > > > > > the non-async page-flip case. In both cases, if a FB_ID is included in > > > > > an atomic commit then the side effects are triggered even if the > > > > > property > > > > > value didn't change. The rules are the same for everything. > > > > > > > > I see it only checking if FB_ID changes or not. If it doesn't > > > > change then the implication is that the side effects will in > > > > fact be skipped as not all planes may even support async flips. > > > > > > Hm right. So the problem is that setting any prop = same value as > > > previous one will result in a new page-flip for asynchronous page-flips, > > > but will not result in any side-effect for asynchronous page-flips. > > > > > > Does it actually matter though? For async page-flips, I don't think this > > > would result in any actual difference in behavior? > > > > To sum this up, here is a matrix of behavior as seen by user-space: > > > > - Sync atomic page-flip > > - Set FB_ID to different value: programs hw for page-flip, sends uevent > > - Set FB_ID to same value: same (important for VRR) > > - Set another plane prop to same value: same > > A page flip is programmed even if FB_ID isn't touched? I believe so. Set CRTC_X on a plane to the same value as before, and the CRTC gets implicitly included in the atomic commit? > > - Set another plane prop to different value: maybe rejected if modeset > > required > > - Async atomic page-flip > > - Set FB_ID to different value: updates hw with new FB address, sends > > immediate uevent > > - Set FB_ID to same value: same (no-op for the hw) > > No-op implies it doesn't trigger scanning out a frame with VRR, if > scanout is currently in vertical blank. Is that the case? If so, async > flips can't reliably trigger scanning out a frame with VRR. By no-op I mean that the hw is programmed for an immediate async flip with the same buffer addr as the previous one. So this doesn't actually change anything.
Re: [PATCH v6 6/6] drm/doc: Define KMS atomic state set
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: > > > > > > > > > > > > > > +An atomic commit with the flag > > > > > > > > > > > > DRM_MODE_PAGE_FLIP_ASYNC is allowed to > > > > > > > > > > > > +effectively change only the FB_ID property on any > > > > > > > > > > > > planes. No-operation changes > > > > > > > > > > > > +are ignored as always. [...] > > > > > > > > > > > > During the hackfest in Brno, it was mentioned that a > > > > > > > > > > > > commit which re-sets the same FB_ID could actually have > > > > > > > > > > > > an effect with VRR: It could trigger scanout of the > > > > > > > > > > > > next frame before vertical blank has reached its > > > > > > > > > > > > maximum duration. Some kind of mechanism is required > > > > > > > > > > > > for this in order to allow user space to perform low > > > > > > > > > > > > frame rate compensation. > > > > > > > > > > > > > > > > > > > > Xaver tested this hypothesis in a flipping the same fb in a > > > > > > > > > > VRR monitor > > > > > > > > > > and it worked as expected, so this shouldn't be a concern. > > > > > > > > > > Right, so it must have some effect. It cannot be simply > > > > > > > > > > ignored like in > > > > > > > > > > the proposed doc wording. Do we special-case re-setting the > > > > > > > > > > same FB_ID > > > > > > > > > > as "not a no-op" or "not ignored" or some other way? > > > > > > > > > > There's an effect in the refresh rate, the image won't > > > > > > > > > > change but it > > > > > > > > > > will report that a flip had happened asynchronously so the > > > > > > > > > > reported > > > > > > > > > > framerate will be increased. Maybe an additional wording > > > > > > > > > > could be like: > > > > > > > > > > > > > > > > Flipping to the same FB_ID will result in a immediate flip as > > > > > > > > if it was > > > > > > > > changing to a different one, with no effect on the image but > > > > > > > > effecting > > > > > > > > the reported frame rate. > > > > > > > > > > > > > > Re-setting FB_ID to its current value is a special case > > > > > > > regardless of > > > > > > > PAGE_FLIP_ASYNC, is it not? > > > > > > > > > > > > No. The rule has so far been that all side effects are observed > > > > > > even if you flip to the same fb. And that is one of my annoyances > > > > > > with this proposal. The rules will now be different for async flips > > > > > > vs. everything else. > > > > > > > > > > Well with the patches the async page-flip case is exactly the same as > > > > > the non-async page-flip case. In both cases, if a FB_ID is included in > > > > > an atomic commit then the side effects are triggered even if the > > > > > property > > > > > value didn't change. The rules are the same for everything. > > > > > > > > I see it only checking if FB_ID changes or not. If it doesn't > > > > change then the implication is that the side effects will in > > > > fact be skipped as not all planes may even support async flips. > > > > > > Hm right. So the problem is that setting any prop = same value as > > > previous one will result in a new page-flip for asynchronous page-flips, > > > but will not result in any side-effect for asynchronous page-flips. > > > > > > Does it actually matter though? For async page-flips, I don't think this > > > would result in any actual difference in behavior? > > > Hi Simon
Re: [PATCH v6 6/6] drm/doc: Define KMS atomic state set
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 > > > > > > > > > > +effectively change only the FB_ID property on any planes. > > > > > > > > > > No-operation changes > > > > > > > > > > +are ignored as always. [...] > > > > > > > > > > During the hackfest in Brno, it was mentioned that a commit > > > > > > > > > > which re-sets the same FB_ID could actually have an effect > > > > > > > > > > with VRR: It could trigger scanout of the next frame before > > > > > > > > > > vertical blank has reached its maximum duration. Some kind > > > > > > > > > > of mechanism is required for this in order to allow user > > > > > > > > > > space to perform low frame rate compensation. > > > > > > > > > > > > > > > > Xaver tested this hypothesis in a flipping the same fb in a VRR > > > > > > > > monitor > > > > > > > > and it worked as expected, so this shouldn't be a concern. > > > > > > > > Right, so it must have some effect. It cannot be simply ignored > > > > > > > > like in > > > > > > > > the proposed doc wording. Do we special-case re-setting the > > > > > > > > same FB_ID > > > > > > > > as "not a no-op" or "not ignored" or some other way? > > > > > > > > There's an effect in the refresh rate, the image won't change > > > > > > > > but it > > > > > > > > will report that a flip had happened asynchronously so the > > > > > > > > reported > > > > > > > > framerate will be increased. Maybe an additional wording could > > > > > > > > be like: > > > > > > > > > > > > Flipping to the same FB_ID will result in a immediate flip as if it > > > > > > was > > > > > > changing to a different one, with no effect on the image but > > > > > > effecting > > > > > > the reported frame rate. > > > > > > > > > > Re-setting FB_ID to its current value is a special case regardless of > > > > > PAGE_FLIP_ASYNC, is it not? > > > > > > > > No. The rule has so far been that all side effects are observed > > > > even if you flip to the same fb. And that is one of my annoyances > > > > with this proposal. The rules will now be different for async flips > > > > vs. everything else. > > > > > > Well with the patches the async page-flip case is exactly the same as > > > the non-async page-flip case. In both cases, if a FB_ID is included in > > > an atomic commit then the side effects are triggered even if the property > > > value didn't change. The rules are the same for everything. > > > > I see it only checking if FB_ID changes or not. If it doesn't > > change then the implication is that the side effects will in > > fact be skipped as not all planes may even support async flips. > > Hm right. So the problem is that setting any prop = same value as > previous one will result in a new page-flip for asynchronous page-flips, > but will not result in any side-effect for asynchronous page-flips. > > Does it actually matter though? For async page-flips, I don't think this > would result in any actual difference in behavior? To sum this up, here is a matrix of behavior as seen by user-space: - Sync atomic page-flip - Set FB_ID to different value: programs hw for page-flip, sends uevent - Set FB_ID to same value: same (important for VRR) - Set another plane prop to same value: same - Set another plane prop to different value: maybe rejected if modeset required - Async atomic page-flip - Set FB_ID to different value: updates hw with new FB address, sends immediate uevent - Set FB_ID to same value: same (no-op for the hw) - Set another plane prop to same value: ignored, sends immediate uevent (special codepath) - Set another plane prop to different value: always rejected To me sync and async look consistent.
Re: [RFC PATCH v2 03/17] drm/vkms: Create separate Kconfig file for VKMS
On Thursday, October 19th, 2023 at 23:21, Harry Wentland wrote: > +++ b/drivers/gpu/drm/vkms/Kconfig > @@ -0,0 +1,15 @@ > +# SPDX-License-Identifier: GPL-2.0+ It seems like the original Kconfig uses GPL-2.0-only. I think it'd be safer to just re-use the exact same license here? With that fixed: Reviewed-by: Simon Ser
Re: [RFC PATCH v2 01/17] drm/atomic: Allow get_value for immutable properties on atomic drivers
Have you seen the comment on top? * Atomic drivers should never call this function directly, the core will read * out property values through the various ->atomic_get_property callbacks. It seems like atomic drivers shouldn't call drm_object_property_get_value() at all?
Re: [RFC PATCH v2 02/17] drm: Don't treat 0 as -1 in drm_fixp2int_ceil
Reviewed-by: Simon Ser
Re: [PATCH] drm/doc: describe PATH format for DP MST
On Tuesday, October 24th, 2023 at 09:36, Pekka Paalanen wrote: > Are DP MST port numbers guaranteed to be tied to the physical hardware > configuration (e.g. how cables are connected) and therefore stable > across reboots? What about stable across kernel upgrades? > > If I knew that, I could perhaps manufacture a stable identifier in > userspace by replacing the parent connector ID with a stable connector > designator. Hm, my assumption is that these are stable, but maybe that's also wrong? Ville, Dmitry, do you know whether the DP MST port numbers are guaranteed stable across reboots when retaining the exact same hardware configuration (not the software, maybe the user upgraded the kernel)?
[PATCH] drm/doc: describe PATH format for DP MST
This is already uAPI, xserver parses it. It's useful to document since user-space might want to lookup the parent connector. Additionally, people (me included) have misunderstood the PATH property for being stable across reboots, but since a KMS object ID is baked in there that's not the case. So PATH shouldn't be used as-is in config files and such. Signed-off-by: Simon Ser Cc: Pekka Paalanen Cc: Dmitry Baryshkov Cc: Daniel Vetter --- drivers/gpu/drm/drm_connector.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c index c3725086f413..392bec1355a3 100644 --- a/drivers/gpu/drm/drm_connector.c +++ b/drivers/gpu/drm/drm_connector.c @@ -1198,6 +1198,11 @@ static const u32 dp_colorspaces = * drm_connector_set_path_property(), in the case of DP MST with the * path property the MST manager created. Userspace cannot change this * property. + * + * In the case of DP MST, the property has the format + * ``mst:-`` where is the KMS object ID of the + * parent connector and is a hyphen-separated list of DP MST + * port numbers. Note, KMS object IDs are not stable across reboots. * TILE: * Connector tile group property to indicate how a set of DRM connector * compose together into one logical screen. This is used by both high-res -- 2.42.0
Re: [PATCH v6 6/6] drm/doc: Define KMS atomic state set
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 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 Mon, 16 Oct 2023 12:52:32 +0200 > > > > > > André Almeida andrealm...@igalia.com wrote: > > > > > > > > > > > > > Hi Michel, > > > > > > > > > > > > > > On 8/17/23 12:37, Michel Dänzer wrote: > > > > > > > > > > > > > > > On 8/15/23 20:57, André Almeida wrote: > > > > > > > > > > > > > > > > > From: Pekka Paalanen pekka.paala...@collabora.com > > > > > > > > > > > > > > > > > > Specify how the atomic state is maintained between userspace > > > > > > > > > and > > > > > > > > > kernel, plus the special case for async flips. > > > > > > > > > > > > > > > > > > Signed-off-by: Pekka Paalanen pekka.paala...@collabora.com > > > > > > > > > Signed-off-by: André Almeida andrealm...@igalia.com > > > > > > > > > [...] > > > > > > > > > > > > > > > > > +An atomic commit with the flag DRM_MODE_PAGE_FLIP_ASYNC is > > > > > > > > > allowed to > > > > > > > > > +effectively change only the FB_ID property on any planes. > > > > > > > > > No-operation changes > > > > > > > > > +are ignored as always. [...] > > > > > > > > > During the hackfest in Brno, it was mentioned that a commit > > > > > > > > > which re-sets the same FB_ID could actually have an effect > > > > > > > > > with VRR: It could trigger scanout of the next frame before > > > > > > > > > vertical blank has reached its maximum duration. Some kind of > > > > > > > > > mechanism is required for this in order to allow user space > > > > > > > > > to perform low frame rate compensation. > > > > > > > > > > > > > > Xaver tested this hypothesis in a flipping the same fb in a VRR > > > > > > > monitor > > > > > > > and it worked as expected, so this shouldn't be a concern. > > > > > > > Right, so it must have some effect. It cannot be simply ignored > > > > > > > like in > > > > > > > the proposed doc wording. Do we special-case re-setting the same > > > > > > > FB_ID > > > > > > > as "not a no-op" or "not ignored" or some other way? > > > > > > > There's an effect in the refresh rate, the image won't change but > > > > > > > it > > > > > > > will report that a flip had happened asynchronously so the > > > > > > > reported > > > > > > > framerate will be increased. Maybe an additional wording could be > > > > > > > like: > > > > > > > > > > Flipping to the same FB_ID will result in a immediate flip as if it > > > > > was > > > > > changing to a different one, with no effect on the image but effecting > > > > > the reported frame rate. > > > > > > > > Re-setting FB_ID to its current value is a special case regardless of > > > > PAGE_FLIP_ASYNC, is it not? > > > > > > No. The rule has so far been that all side effects are observed > > > even if you flip to the same fb. And that is one of my annoyances > > > with this proposal. The rules will now be different for async flips > > > vs. everything else. > > > > Well with the patches the async page-flip case is exactly the same as > > the non-async page-flip case. In both cases, if a FB_ID is included in > > an atomic commit then the side effects are triggered even if the property > > value didn't change. The rules are the same for everything. > > I see it only checking if FB_ID changes or not. If it doesn't > change then the implication is that the side effects will in > fact be skipped as not all planes may even support async flips. Hm right. So the problem is that setting any prop = same value as previous one will result in a new page-flip for asynchronous page-flips, but will not result in any side-effect for asynchronous page-flips. Does it actually matter though? For async page-flips, I don't think this would result in any actual difference in behavior?
Re: [PATCH RFC v6 01/10] drm: Introduce pixel_source DRM plane property
For the uAPI: Acked-by: Simon Ser
Re: [PATCH v6 6/6] drm/doc: Define KMS atomic state set
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 Mon, 16 Oct 2023 12:52:32 +0200 > > > > André Almeida andrealm...@igalia.com wrote: > > > > > > > > > Hi Michel, > > > > > > > > > > On 8/17/23 12:37, Michel Dänzer wrote: > > > > > > > > > > > On 8/15/23 20:57, André Almeida wrote: > > > > > > > > > > > > > From: Pekka Paalanen pekka.paala...@collabora.com > > > > > > > > > > > > > > Specify how the atomic state is maintained between userspace and > > > > > > > kernel, plus the special case for async flips. > > > > > > > > > > > > > > Signed-off-by: Pekka Paalanen pekka.paala...@collabora.com > > > > > > > Signed-off-by: André Almeida andrealm...@igalia.com > > > > > > > [...] > > > > > > > > > > > > > +An atomic commit with the flag DRM_MODE_PAGE_FLIP_ASYNC is > > > > > > > allowed to > > > > > > > +effectively change only the FB_ID property on any planes. > > > > > > > No-operation changes > > > > > > > +are ignored as always. [...] > > > > > > > During the hackfest in Brno, it was mentioned that a commit which > > > > > > > re-sets the same FB_ID could actually have an effect with VRR: It > > > > > > > could trigger scanout of the next frame before vertical blank has > > > > > > > reached its maximum duration. Some kind of mechanism is required > > > > > > > for this in order to allow user space to perform low frame rate > > > > > > > compensation. > > > > > > > > > > Xaver tested this hypothesis in a flipping the same fb in a VRR > > > > > monitor > > > > > and it worked as expected, so this shouldn't be a concern. > > > > > Right, so it must have some effect. It cannot be simply ignored like > > > > > in > > > > > the proposed doc wording. Do we special-case re-setting the same FB_ID > > > > > as "not a no-op" or "not ignored" or some other way? > > > > > There's an effect in the refresh rate, the image won't change but it > > > > > will report that a flip had happened asynchronously so the reported > > > > > framerate will be increased. Maybe an additional wording could be > > > > > like: > > > > > > Flipping to the same FB_ID will result in a immediate flip as if it was > > > changing to a different one, with no effect on the image but effecting > > > the reported frame rate. > > > > Re-setting FB_ID to its current value is a special case regardless of > > PAGE_FLIP_ASYNC, is it not? > > No. The rule has so far been that all side effects are observed > even if you flip to the same fb. And that is one of my annoyances > with this proposal. The rules will now be different for async flips > vs. everything else. Well with the patches the async page-flip case is exactly the same as the non-async page-flip case. In both cases, if a FB_ID is included in an atomic commit then the side effects are triggered even if the property value didn't change. The rules are the same for everything.
Re: [PATCH v6 5/6] drm: Refuse to async flip with atomic prop changes
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 mode ID, that could be referring to an identical mode.
>
> Signed-off-by: André Almeida
> ---
> v4: new patch
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 5 +++
> drivers/gpu/drm/drm_atomic_uapi.c | 52 +++--
> drivers/gpu/drm/drm_crtc_internal.h | 2 +-
> drivers/gpu/drm/drm_mode_object.c | 2 +-
> 4 files changed, 56 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 2c2c9caf0be5..1e2973f0e1f6 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -629,6 +629,11 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
> WARN_ON(!drm_modeset_is_locked(>mutex));
>
> if (!drm_mode_equal(_crtc_state->mode,
> _crtc_state->mode)) {
> + if (new_crtc_state->async_flip) {
> + drm_dbg_atomic(dev, "[CRTC:%d:%s] no mode
> changes allowed during async flip\n",
> +crtc->base.id, crtc->name);
> + return -EINVAL;
> + }
Hmm, so, I've been going back and forth about this for a loong time. Each
time I convince myself that one of the options we have is a good solution, I
think of the drawbacks and change my mind. To sum up:
- Forbid non-FB_ID props from being included in the atomic commit: makes it
painful for compositors, they need to have a special tearing codepath for no
real reason and the tearing API doesn't work the same as the non-tearing API
as Pekka said.
- Check any non-FB_ID props in the atomic commit, forbid changes here: we need
to use get_property(), which is a bit weird back-and-forth between u64s used
in the uAPI and actual underlying values stored in DRM structs. And the
MODE_ID check is a bit split between the set_property() function and the
check_modeset() one. Ideally we'd have a something_changed bool like we have
for modesets (mode_changed) but that would be a massive pain to plumb through
all of the props. Also get_property() is lightweight, it just casts whatever
struct field is being used to u64 and that's it.
All in all, I think I'd settle on the approach in this patch, but I'd prefer to
leave the MODE_ID stuff out. It would result in a less convoluted check, and I
can't think of any current compositor which re-creates the mode blob each
page-flip. That's not 100% consistent with the sync page-flip API, but I'm
worried about accumulating more special cases like this in the future.
Does that make sense?
> drm_dbg_atomic(dev, "[CRTC:%d:%s] mode changed\n",
> crtc->base.id, crtc->name);
> new_crtc_state->mode_changed = true;
> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> b/drivers/gpu/drm/drm_atomic_uapi.c
> index dfd4cf7169df..536c21f53b5f 100644
> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> @@ -972,13 +972,28 @@ int drm_atomic_connector_commit_dpms(struct
> drm_atomic_state *state,
> return ret;
> }
>
> +static int drm_atomic_check_prop_changes(int ret, uint64_t old_val, uint64_t
> prop_value,
> + struct drm_property *prop)
> +{
> + if (ret != 0 || old_val != prop_value) {
> + drm_dbg_atomic(prop->dev,
> +"[PROP:%d:%s] No prop can be changed during
> async flip\n",
> +prop->base.id, prop->name);
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
> +
> int drm_atomic_set_property(struct drm_atomic_state *state,
> struct drm_file *file_priv,
> struct drm_mode_object *obj,
> struct drm_property *prop,
> - uint64_t prop_value)
> + uint64_t prop_value,
> + bool async_flip)
> {
> struct drm_mode_object *ref;
> + uint64_t old_val;
> int ret;
>
> if (!drm_property_change_valid_get(prop, prop_value, ))
> @@ -995,6 +1010,13 @@ int drm_atomic_set_property(struct drm_atomic_state
> *state,
> break;
> }
>
> + if (async_flip) {
> + ret = drm_atomic_connector_get_property(connector,
> connector_state,
> + prop, _val);
> + ret = drm_atomic_check_prop_changes(ret, old_val,
> prop_value, prop);
Note to self: I was worried here to pass the "next" state to get_property(),
but it's before
Re: wl_surface::attach(NULL) release previous buffer?
> Ideally the release event would have been a wl_callback just like > wl_surface.frame is. I sent [1] to fix this. [1]: https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/137
Re: [PATCH] drm: support up to 128 drm devices
On Monday, July 17th, 2023 at 15:24, Emil Velikov wrote: > > > For going forward, here is one way we can shave this yak: > > > - update libdrm to max 64 nodes > > > - roll libdrm release, nag distributions to update to it // could be > > > folded with the next release below > > > - update libdrm to use name driven type detection > > > - roll libdrm release, nag distributions to update to it > > > - once ^^ release hits most distributions, merge the above proposed > > > kernel patch > > >- the commit message should explain the caveats and fixed libdrm > > > version > > >- we should be prepared to revert the commit, if it causes user > > > space regression - fix (see below) and re-introduce the kernel patch > > > 1-2 releases later > > > > That sounds really scary to me. I'd really prefer to try not to break the > > kernel uAPI here. > > > > With part in particular? Mind you I'm not particularly happy either, > since in essence it's like a controlled explosion. I believe there are ways to extend the uAPI to support more devices without breaking the uAPI. Michał Winiarski's patch for instance tried something to this effect. > > The kernel rule is "do not break user-space". > > Yes, in a perfect world. In practice, there have been multiple kernel > changes breaking user-space. Some got reverted, some remained. > AFAICT the above will get us out of the sticky situation we're in with > the least amount of explosion. > > If there is a concrete proposal, please go ahead and sorry if I've > missed it. I'm supposed to be off, having fun with family when I saw > this whole thing explode. > > Small note: literally all the users I've seen will stop on a missing > node (card or render) aka if the kernel creates card0...63 and then > card200... then (hard wavy estimate) 80% of the apps will be broken. That's fine, because that's not a kernel regression. Supporting more than 64 devices is a new kernel feature, and if some user-space ignores the new nodes, that's not a kernel regression. A regression only happens when a use-case which works with an older kernel is broken by a newer kernel.
Re: [PATCH] drm: support up to 128 drm devices
On Monday, July 17th, 2023 at 09:30, Emil Velikov wrote: > > I'm worried what might happen with old user-space, especially old libdrm. > > I also share the same concern. Although the bigger issue is not libdrm > - since we can update it and prod distributions to update it. > The biggest concern is software that cannot be rebuild/updated - > closed source and various open-source that has been abandoned. Well. Now that we have Flatpak and AppImage and friends, we're really likely to have old libdrm copies vendored all over the place, and these will stick around essentially forever. > For going forward, here is one way we can shave this yak: > - update libdrm to max 64 nodes > - roll libdrm release, nag distributions to update to it // could be > folded with the next release below > - update libdrm to use name driven type detection > - roll libdrm release, nag distributions to update to it > - once ^^ release hits most distributions, merge the above proposed > kernel patch >- the commit message should explain the caveats and fixed libdrm version >- we should be prepared to revert the commit, if it causes user > space regression - fix (see below) and re-introduce the kernel patch > 1-2 releases later That sounds really scary to me. I'd really prefer to try not to break the kernel uAPI here. The kernel rule is "do not break user-space".
Re: [PATCH] drm: support up to 128 drm devices
On Friday, July 14th, 2023 at 12:31, Simon Ser wrote: > Before this patch, 0..63 are for primary, 64..127 are for control (never > exposed by the kernel), 128..191 are for render, 2048..2112 are for accel. > After this patch, 0..127 are for primary, 64..191 are for control (never > exposed by the kernel), 128..255 are for render, 2048..2176 are for accel. Correction: reading the code, accel is handled separately. Additional find: the kernel creates sysfs control nodes because old user-space reads them to figure out whether a device is DRIVER_MODESET.
Re: [PATCH] drm: support up to 128 drm devices
(cc Daniel Vetter and Pekka because this change has uAPI repercussions)
On Friday, June 30th, 2023 at 13:56, James Zhu wrote:
> From: Christian König
>
> This makes room for up to 128 DRM devices.
>
> Signed-off-by: Christian König
> Signed-off-by: James Zhu
> ---
> drivers/gpu/drm/drm_drv.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 73b845a75d52..0d55c6f5 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -137,7 +137,7 @@ static int drm_minor_alloc(struct drm_device *dev,
> unsigned int type)
> r = idr_alloc(_minors_idr,
> NULL,
> 64 * type,
> - 64 * (type + 1),
> + 64 * (type + 2),
The type comes from this enum:
enum drm_minor_type {
DRM_MINOR_PRIMARY,
DRM_MINOR_CONTROL,
DRM_MINOR_RENDER,
DRM_MINOR_ACCEL = 32,
};
Before this patch, 0..63 are for primary, 64..127 are for control (never
exposed by the kernel), 128..191 are for render, 2048..2112 are for accel.
After this patch, 0..127 are for primary, 64..191 are for control (never
exposed by the kernel), 128..255 are for render, 2048..2176 are for accel.
I'm worried what might happen with old user-space, especially old libdrm.
When there are a lot of primary nodes, some would get detected as control
nodes, even if they aren't. Is this fine? This would at least be confusing
for information-gathering tools like drm_info. I'm not sure about other
consequences. Do we want to forever forbid the 64..127 range instead, so
that we have the guarantee that old libdrm never sees it?
I'm also worried about someone adding a new entry to the enum after
DRM_MINOR_RENDER (DRM_MINOR_ACCEL was specifically set to 32 so that new
node types could be added before). drm_minor_alloc() would blow up in this
case, because it'd use the 192..319 range, which overlaps with render.
I think a switch with explicit ranges (and WARN when an unknown type is
passed in) would be both easier to read and less risky.
> GFP_NOWAIT);
> spin_unlock_irqrestore(_minor_lock, flags);
> }
> --
> 2.34.1
Re: [PATCH v5 6/6] drm/doc: Define KMS atomic state set
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, and it will never be applied partially. This is the > +fundamental improvement of the atomic API over the older non-atomic API > which is > +referred to as the "legacy API". Applying intermediate state could > unexpectedly > +fail, cause visible glitches, or delay reaching the final state. > + > +An atomic commit can be flagged with DRM_MODE_ATOMIC_TEST_ONLY, which means > the Can we linkify these #defines? This can be done like so: … flagged with :c:macro:`DRM_MODE_ATOMIC_TEST_ONLY`, which means … This should create a link to the docs for this flag.
Re: [PATCH v4 1/6] drm: allow DRM_MODE_PAGE_FLIP_ASYNC for atomic commits
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 regular > > page-flip. > > + * > > + * Note, some hardware might need to perform one last synchronous page-flip > > + * before being able to switch to asynchronous page-flips. As an exception, > > + * the driver will return success even though that first page-flip is not > > + * asynchronous. > > What would happen if one commits another async KMS update before the > first page flip? Does one receive EAGAIN, does it amend the previous > commit? What happens to the timing feedback? > > This seems really risky to include tbh. I would prefer if we would not > add such special cases for now. This is not a new case, i915 already does this with the legacy API to address some hw issues. Sadly I don't think we can do anything about it.
Re: [RFC] Plane color pipeline KMS uAPI
Hi Christopher,
On Friday, June 9th, 2023 at 17:52, Christopher Braga
wrote:
> > The new COLOROP objects also expose a number of KMS properties. Each has a
> > type, a reference to the next COLOROP object in the linked list, and other
> > type-specific properties. Here is an example for a 1D LUT operation:
> >
> > Color operation 42
> > ├─ "type": enum {Bypass, 1D curve} = 1D curve
> > ├─ "1d_curve_type": enum {LUT, sRGB, PQ, BT.709, HLG, …} = LUT
> The options sRGB / PQ / BT.709 / HLG would select hard-coded 1D
> curves? Will different hardware be allowed to expose a subset of these
> enum values?
Yes. Only hardcoded LUTs supported by the HW are exposed as enum entries.
> > ├─ "lut_size": immutable range = 4096
> > ├─ "lut_data": blob
> > └─ "next": immutable color operation ID = 43
> >
> Some hardware has per channel 1D LUT values, while others use the same
> LUT for all channels. We will definitely need to expose this in the
> UAPI in some form.
Hm, I was assuming per-channel 1D LUTs here, just like the existing GAMMA_LUT/
DEGAMMA_LUT properties work. If some hardware can't support that, it'll need
to get exposed as another color operation block.
> > To configure this hardware block, user-space can fill a KMS blob with
> > 4096 u32
> > entries, then set "lut_data" to the blob ID. Other color operation types
> > might
> > have different properties.
> >
> The bit-depth of the LUT is an important piece of information we should
> include by default. Are we assuming that the DRM driver will always
> reduce the input values to the resolution supported by the pipeline?
> This could result in differences between the hardware behavior
> and the shader behavior.
>
> Additionally, some pipelines are floating point while others are fixed.
> How would user space know if it needs to pack 32 bit integer values vs
> 32 bit float values?
Again, I'm deferring to the existing GAMMA_LUT/DEGAMMA_LUT. These use a common
definition of LUT blob (u16 elements) and it's up to the driver to convert.
Using a very precise format for the uAPI has the nice property of making the
uAPI much simpler to use. User-space sends high precision data and it's up to
drivers to map that to whatever the hardware accepts.
Exposing the actual hardware precision is something we've talked about during
the hackfest. It'll probably be useful to some extent, but will require some
discussion to figure out how to design the uAPI. Maybe a simple property is
enough, maybe not (e.g. fully describing the precision of segmented LUTs would
probably be trickier).
I'd rather keep things simple for the first pass, we can always add more
properties for bit depth etc later on.
> > Here is another example with a 3D LUT:
> >
> > Color operation 42
> > ├─ "type": enum {Bypass, 3D LUT} = 3D LUT
> > ├─ "lut_size": immutable range = 33
> > ├─ "lut_data": blob
> > └─ "next": immutable color operation ID = 43
> >
> We are going to need to expose the packing order here to avoid any
> programming uncertainty. I don't think we can safely assume all hardware
> is equivalent.
The driver can easily change the layout of the matrix and do any conversion
necessary when programming the hardware. We do need to document what layout is
used in the uAPI for sure.
> > And one last example with a matrix:
> >
> > Color operation 42
> > ├─ "type": enum {Bypass, Matrix} = Matrix
> > ├─ "matrix_data": blob
> > └─ "next": immutable color operation ID = 43
> >
> It is unclear to me what the default sizing of this matrix is. Any
> objections to exposing these details with an additional property?
The existing CTM property uses 9 uint64 (S31.32) values. Is there a case where
that wouldn't be enough?
> Dithering logic exists in some pipelines. I think we need a plan to
> expose that here as well.
Hm, I'm not too familiar with dithering. Do you think it would make sense to
expose as an additional colorop block? Do you think it would have more
consequences on the design?
I want to re-iterate that we don't need to ship all features from day 1. We
just need to come up with a uAPI design on which new features can be built on.
> > [Simon note: an alternative would be to split the color pipeline into
> > two, by
> > having two plane properties ("color_pipeline_pre_scale" and
> > "color_pipeline_post_scale") instead of a single one. This would be
> > similar to
> > the way we want to split pre-blending and post-blending. This could be less
> > expressive for drivers, there may be hardware where there are dependencies
> > between the pre- and post-scaling pipeline?]
> >
> As others have noted, breaking up the pipeline with immutable blocks
> makes the most sense to me here. This way we don't have to predict ahead
> of time every type of block that maybe affected by pipeline ordering.
> Splitting the pipeline into two properties now means future
> logical splits would require introduction of further plane
Re: How to fetch the implicit sync fence for a GPU buffer?
On Friday, June 2nd, 2023 at 12:29, Michel Dänzer wrote: > > I’m wondering whether there’s an API -- maybe something analogous to > > drmPrimeHandleToFD() – that allows userspace to fetch a waitable fence fd > > for a dmabuf? > > A dma-buf fd itself can serve this purpose; it polls as readable when the GPU > has finished drawing to the buffer. If you _really_ need a sync_file FD, you can extract it via DMA_BUF_IOCTL_EXPORT_SYNC_FILE. This is a somewhat recent kernel uAPI.
Re: [RFC] Plane color pipeline KMS uAPI
On Friday, May 5th, 2023 at 15:30, Joshua Ashton wrote:
> > > AMD would expose the following objects and properties:
> > >
> > > Plane 10
> > > ├─ "type": immutable enum {Overlay, Primary, Cursor} = Primary
> > > └─ "color_pipeline": enum {0, 42} = 0
> > > Color operation 42 (input CSC)
> > > ├─ "type": enum {Bypass, Matrix} = Matrix
> > > ├─ "matrix_data": blob
> > > └─ "next": immutable color operation ID = 43
> > > Color operation 43
> > > ├─ "type": enum {Scaling} = Scaling
> > > └─ "next": immutable color operation ID = 44
> > > Color operation 44 (DeGamma)
> > > ├─ "type": enum {Bypass, 1D curve} = 1D curve
> > > ├─ "1d_curve_type": enum {sRGB, PQ, …} = sRGB
> > > └─ "next": immutable color operation ID = 45
>
> Some vendors have per-tap degamma and some have a degamma after the sample.
> How do we distinguish that behaviour?
> It is important to know.
Can you elaborate? What is "per-tap" and "sample"? Is the "Scaling" color
operation above not enough to indicate where in the pipeline the hw performs
scaling?
> > > Color operation 45 (gamut remap)
> > > ├─ "type": enum {Bypass, Matrix} = Matrix
> > > ├─ "matrix_data": blob
> > > └─ "next": immutable color operation ID = 46
> > > Color operation 46 (shaper LUT RAM)
> > > ├─ "type": enum {Bypass, 1D curve} = 1D curve
> > > ├─ "1d_curve_type": enum {LUT} = LUT
> > > ├─ "lut_size": immutable range = 4096
> > > ├─ "lut_data": blob
> > > └─ "next": immutable color operation ID = 47
> > > Color operation 47 (3D LUT RAM)
> > > ├─ "type": enum {Bypass, 3D LUT} = 3D LUT
> > > ├─ "lut_size": immutable range = 17
> > > ├─ "lut_data": blob
> > > └─ "next": immutable color operation ID = 48
> > > Color operation 48 (blend gamma)
> > > ├─ "type": enum {Bypass, 1D curve} = 1D curve
> > > ├─ "1d_curve_type": enum {LUT, sRGB, PQ, …} = LUT
> > > ├─ "lut_size": immutable range = 4096
> > > ├─ "lut_data": blob
> > > └─ "next": immutable color operation ID = 0
> > >
> > > To configure the pipeline for an HDR10 PQ plane (path at the top) and a
> > > HDR
> > > display, gamescope would perform an atomic commit with the following
> > > property
> > > values:
> > >
> > > Plane 10
> > > └─ "color_pipeline" = 42
> > > Color operation 42 (input CSC)
> > > └─ "matrix_data" = PQ → scRGB (TF)
>
> ^
> Not sure what this is.
> We don't use an input CSC before degamma.
>
> > > Color operation 44 (DeGamma)
> > > └─ "type" = Bypass
>
> ^
> If we did PQ, this would be PQ -> Linear / 80
> If this was sRGB, it'd be sRGB -> Linear
> If this was scRGB this would be just treating it as it is. So... Linear / 80.
>
> > > Color operation 45 (gamut remap)
> > > └─ "matrix_data" = scRGB (TF) → PQ
>
> ^
> This is wrong, we just use this to do scRGB primaries (709) to 2020.
>
> We then go from scRGB -> PQ to go into our shaper + 3D LUT.
>
> > > Color operation 46 (shaper LUT RAM)
> > > └─ "lut_data" = PQ → Display native
>
> ^
> "Display native" is just the response curve of the display.
> In HDR10, this would just be PQ -> PQ
> If we were doing HDR10 on SDR, this would be PQ -> Gamma 2.2 (mapped
> from 0 to display native luminance) [with a potential bit of headroom
> for tonemapping in the 3D LUT]
> For SDR on HDR10 this would be Gamma 2.2 -> PQ (Not intending to start
> an sRGB vs G2.2 argument here! :P)
>
> > > Color operation 47 (3D LUT RAM)
> > > └─ "lut_data" = Gamut mapping + tone mapping + night mode
> > > Color operation 48 (blend gamma)
> > > └─ "1d_curve_type" = PQ
>
> ^
> This is wrong, this should be Display Native -> Linearized Display Referred
In the HDR case, isn't this the inverse of PQ?
> > You cannot do a TF with a matrix, and a gamut remap with a matrix on
> > electrical values is certainly surprising, so the example here is a
> > bit odd, but I don't think that hurts the intention of demonstration.
>
> I have done some corrections inline.
>
> You can see our fully correct color pipeline here:
> https://raw.githubusercontent.com/ValveSoftware/gamescope/master/src/docs/Steam%20Deck%20Display%20Pipeline.png
>
> Please let me know if you have any more questions about our color pipeline.
As expected, I got the gamescope part wrong. I'm pretty confident that the
proposed API would still work since the AMD vendor-specific props would just
be exposed as color operation objects. Can you confirm we can make the
gamescope pipeline work with the AMD color pipeline outlined above?
Re: [RFC] Plane color pipeline KMS uAPI
On Thursday, May 11th, 2023 at 18:56, Joshua Ashton wrote: > When we are talking about being 'prescriptive' in the API, are we > outright saying we don't want to support arbitrary 3D LUTs, or are we > just offering certain algorithms to be 'executed' for a plane/crtc/etc > in the atomic API? I am confused... >From a kernel PoV: - Prescriptive = here are the available hardware blocks, feel free to configure each as you like - Descriptive = give me the source and destination color-spaces and I take care of everything This proposal is a prescriptive API. We haven't explored _that_ much how a descriptive API would look like, probably it can include some way to do Night Light and similar features but not sure how high-level they'd look like. A descriptive API is inherently more restrictive than a prescriptive API.
Re: [RFC] Plane color pipeline KMS uAPI
On Tuesday, May 9th, 2023 at 21:53, Dave Airlie wrote: > There are also other vendor side effects to having this in userspace. > > Will the library have a loader? > Will it allow proprietary plugins? > Will it allow proprietary reimplementations? > What will happen when a vendor wants distros to ship their > proprietary fork of said library? > > How would NVIDIA integrate this with their proprietary stack? Since all color operations exposed by KMS are standard, the library would just be a simple one: no loader, no plugin, no proprietary pieces, etc.
Re: [RFC] Plane color pipeline KMS uAPI
On Friday, May 5th, 2023 at 21:53, Daniel Vetter wrote:
> On Fri, May 05, 2023 at 04:06:26PM +0000, Simon Ser wrote:
> > On Friday, May 5th, 2023 at 17:28, Daniel Vetter wrote:
> >
> > > Ok no comments from me on the actual color operations and semantics of all
> > > that, because I have simply nothing to bring to that except confusion :-)
> > >
> > > Some higher level thoughts instead:
> > >
> > > - I really like that we just go with graph nodes here. I think that was
> > > bound to happen sooner or later with kms (we almost got there with
> > > writeback, and with hindsight maybe should have).
> >
> > I'd really rather not do graphs here. We only need linked lists as Sebastian
> > said. Graphs would significantly add more complexity to this proposal, and
> > I don't think that's a good idea unless there is a strong use-case.
>
> You have a graph, because a graph is just nodes + links. I did _not_
> propose a full generic graph structure, the link pointer would be in the
> class/type specific structure only. Like how we have the plane->crtc or
> connector->crtc links already like that (which already _is_ is full blown
> graph).
I really don't get why a pointer in a struct makes plane->crtc a full-blown
graph. There is only a single parent-child link. A plane has a reference to a
CRTC, and nothing more.
You could say that anything is a graph. Yes, even an isolated struct somewhere
is a graph: one with a single node and no link. But I don't follow what's the
point of explaining everything with a graph when we only need a much simpler
subset of the concept of graphs?
Putting the graph thing aside, what are you suggesting exactly from a concrete
uAPI point-of-view? Introducing a new struct type? Would it be a colorop
specific struct, or a more generic one? What would be the fields? Why do you
think that's necessary and better than the current proposal?
My understanding so far is that you're suggesting introducing something like
this at the uAPI level:
struct drm_mode_node {
uint32_t id;
uint32_t children_count;
uint32_t *children; // list of child object IDs
};
I don't think this is a good idea for multiple reasons. First, this is
overkill: we don't need this complexity, and this complexity will make it more
difficult to reason about the color pipeline. This is a premature abstraction,
one we don't need right now, and one I heaven't heard a potential future
use-case for. Sure, one can kill an ant with a sledgehammer if they'd like, but
that's not the right tool for the job.
Second, this will make user-space miserable. User-space already has a tricky
task to achieve to translate its abstract descriptive color pipeline to our
proposed simple list of color operations. If we expose a full-blown graph, then
the user-space logic will need to handle arbitrary graphs. This will have a
significant cost (on implementation and testing), which we will be paying in
terms of time spent and in terms of bugs.
Last, this kind of generic "node" struct is at odds with existing KMS object
types. So far, KMS objects are concrete like CRTC, connector, plane, etc.
"Node" is abstract. This is inconsistent.
Please let me know whether the above is what you have in mind. If not, please
explain what exactly you mean by "graphs" in terms of uAPI, and please explain
why we need it and what real-world use-cases it would solve.
Re: [RFC] Plane color pipeline KMS uAPI
On Friday, May 5th, 2023 at 17:28, Daniel Vetter wrote: > Ok no comments from me on the actual color operations and semantics of all > that, because I have simply nothing to bring to that except confusion :-) > > Some higher level thoughts instead: > > - I really like that we just go with graph nodes here. I think that was > bound to happen sooner or later with kms (we almost got there with > writeback, and with hindsight maybe should have). I'd really rather not do graphs here. We only need linked lists as Sebastian said. Graphs would significantly add more complexity to this proposal, and I don't think that's a good idea unless there is a strong use-case.
[RFC] Plane color pipeline KMS uAPI
Hi all,
The goal of this RFC is to expose a generic KMS uAPI to configure the color
pipeline before blending, ie. after a pixel is tapped from a plane's
framebuffer and before it's blended with other planes. With this new uAPI we
aim to reduce the battery life impact of color management and HDR on mobile
devices, to improve performance and to decrease latency by skipping
composition on the 3D engine. This proposal is the result of discussions at
the Red Hat HDR hackfest [1] which took place a few days ago. Engineers
familiar with the AMD, Intel and NVIDIA hardware have participated in the
discussion.
This proposal takes a prescriptive approach instead of a descriptive approach.
Drivers describe the available hardware blocks in terms of low-level
mathematical operations, then user-space configures each block. We decided
against a descriptive approach where user-space would provide a high-level
description of the colorspace and other parameters: we want to give more
control and flexibility to user-space, e.g. to be able to replicate exactly the
color pipeline with shaders and switch between shaders and KMS pipelines
seamlessly, and to avoid forcing user-space into a particular color management
policy.
We've decided against mirroring the existing CRTC properties
DEGAMMA_LUT/CTM/GAMMA_LUT onto KMS planes. Indeed, the color management
pipeline can significantly differ between vendors and this approach cannot
accurately abstract all hardware. In particular, the availability, ordering and
capabilities of hardware blocks is different on each display engine. So, we've
decided to go for a highly detailed hardware capability discovery.
This new uAPI should not be in conflict with existing standard KMS properties,
since there are none which control the pre-blending color pipeline at the
moment. It does conflict with any vendor-specific properties like
NV_INPUT_COLORSPACE or the patches on the mailing list adding AMD-specific
properties. Drivers will need to either reject atomic commits configuring both
uAPIs, or alternatively we could add a DRM client cap which hides the vendor
properties and shows the new generic properties when enabled.
To use this uAPI, first user-space needs to discover hardware capabilities via
KMS objects and properties, then user-space can configure the hardware via an
atomic commit. This works similarly to the existing KMS uAPI, e.g. planes.
Our proposal introduces a new "color_pipeline" plane property, and a new KMS
object type, "COLOROP" (short for color operation). The "color_pipeline" plane
property is an enum, each enum entry represents a color pipeline supported by
the hardware. The special zero entry indicates that the pipeline is in
"bypass"/"no-op" mode. For instance, the following plane properties describe a
primary plane with 2 supported pipelines but currently configured in bypass
mode:
Plane 10
├─ "type": immutable enum {Overlay, Primary, Cursor} = Primary
├─ …
└─ "color_pipeline": enum {0, 42, 52} = 0
The non-zero entries describe color pipelines as a linked list of COLOROP KMS
objects. The entry value is an object ID pointing to the head of the linked
list (the first operation in the color pipeline).
The new COLOROP objects also expose a number of KMS properties. Each has a
type, a reference to the next COLOROP object in the linked list, and other
type-specific properties. Here is an example for a 1D LUT operation:
Color operation 42
├─ "type": enum {Bypass, 1D curve} = 1D curve
├─ "1d_curve_type": enum {LUT, sRGB, PQ, BT.709, HLG, …} = LUT
├─ "lut_size": immutable range = 4096
├─ "lut_data": blob
└─ "next": immutable color operation ID = 43
To configure this hardware block, user-space can fill a KMS blob with 4096 u32
entries, then set "lut_data" to the blob ID. Other color operation types might
have different properties.
Here is another example with a 3D LUT:
Color operation 42
├─ "type": enum {Bypass, 3D LUT} = 3D LUT
├─ "lut_size": immutable range = 33
├─ "lut_data": blob
└─ "next": immutable color operation ID = 43
And one last example with a matrix:
Color operation 42
├─ "type": enum {Bypass, Matrix} = Matrix
├─ "matrix_data": blob
└─ "next": immutable color operation ID = 43
[Simon note: having "Bypass" in the "type" enum, and making "type" mutable is
a bit weird. Maybe we can just add an "active"/"bypass" boolean property on
blocks which can be bypassed instead.]
[Jonas note: perhaps a single "data" property for both LUTs and matrices
would make more sense. And a "size" prop for both 1D and 3D LUTs.]
If some hardware supports re-ordering operations in the color pipeline, the
driver can expose multiple pipelines with different operation ordering, and
user-space can pick the ordering it prefers by selecting the right pipeline.
The same scheme can be used to expose hardware blocks supporting multiple
precision levels.
That's pretty much all there is to it, but as always the devil
Re: Wayland client, cleanup on exit
On Tuesday, April 4th, 2023 at 13:26, Guillermo Rodriguez wrote: > Out of curiosity, for objects that are only released when a client > disconnects (such as wl_registry), how does the Wayland server know > how to release this if the client does not disconnect explicitly. in > other words how is the resource leak on the server side avoided if the > client just exits and the OS cleans up? libwayland-server notices that the socket is disconnected and cleans up all Wayland objects belonging to it.
Re: Wayland client, cleanup on exit
On Tuesday, April 4th, 2023 at 12:46, Guillermo Rodriguez Garcia wrote: > One further question: before posting this here, I was trying to verify > this by myself, and was wondering whether there is some sort of tool > that can be used to monitor resources currently in use in a Wayland > server. Does such a tool exist? I'm not aware of any. There is wlhax [1] which can be used to track which protocol objects are alive for a given client. There is the standard tooling to monitor allocated memory for a process. But I don't know of any tool to monitor Wayland objects in a server specifically. [1]: https://git.sr.ht/~kennylevinsen/wlhax
Re: Wayland client, cleanup on exit
Hi, On Tuesday, April 4th, 2023 at 12:16, Guillermo Rodriguez wrote: > Is it necessary to explicitly clean up and release any resources > before exit in a Wayland client? Does that happen automatically if > the process simply exits (in the same way that other resources such > as memory or fds are automatically released) ? If you don't explicitly cleanup resources allocated by libwayland, it's fine: the process won't leak any. IOW, resources allocated in a Wayland client are cleaned up by the OS as usual. Some people still prefer to explicitly clean up, e.g. to use tools like ASan/Valgrind. Simon
[ANNOUNCE] wayland 1.22.0
This is the official release for Wayland 1.22. This new release adds explicit events for the preferred buffer scale and transform, adds an event to indicate the pointer's physical scroll direction, adds a few new convenience functions, and includes various spec clarifications and bug fixes. Commit history since RC1 below. Simon Ser (1): build: bump to version 1.22.0 for the official release git tag: 1.22.0 https://gitlab.freedesktop.org/wayland/wayland/-/releases/1.22.0/downloads/wayland-1.22.0.tar.xz SHA256: 1540af1ea698a471c2d8e9d288332c7e0fd360c8f1d12936ebb7e7cbc2425842 wayland-1.22.0.tar.xz SHA512: fb1974efc8433e97254eb83fe28974198f2b4d8246418eb3d34ce657055461e0c97bc06dd52e5066ae91bbe05bac611dc49a0937ba226ac6388d5a47241efb12 wayland-1.22.0.tar.xz PGP: https://gitlab.freedesktop.org/wayland/wayland/-/releases/1.22.0/downloads/wayland-1.22.0.tar.xz.sig
[ANNOUNCE] wayland 1.21.93
Faith Ekstrand (1): Add a .mailmap file Simon Ser (1): build: bump to version 1.21.93 for the RC1 release git tag: 1.21.93 https://gitlab.freedesktop.org/wayland/wayland/-/releases/1.21.93/downloads/wayland-1.21.93.tar.xz SHA256: 0f1d3aa21e2bbcc15b4bd4d6e46d52c3e0d32e82fac8ef21b497c28e0bfa0a47 wayland-1.21.93.tar.xz SHA512: 97dccb75157fe46eec08d83b93fa2b158ddb91c83e8692930733beb6925d17e8f2f9d3b2a8976ea41335a4f25b5a327b5906f452d7fce4b850829f043b93d6b3 wayland-1.21.93.tar.xz PGP: https://gitlab.freedesktop.org/wayland/wayland/-/releases/1.21.93/downloads/wayland-1.21.93.tar.xz.sig
[ANNOUNCE] wayland 1.21.92
This is the beta release for Wayland 1.22. Full commit history below. Alexandros Frantzis (1): client: Do not warn about attached proxies on default queue destruction. Simon Ser (2): client: fix wl_display_disconnect() documentation build: bump version to 1.21.92 for the beta release git tag: 1.21.92 https://gitlab.freedesktop.org/wayland/wayland/-/releases/1.21.92/downloads/wayland-1.21.92.tar.xz SHA256: d5ed46e7dca8479614a7ef0518464e49fd4fa549ed6cdba963eabe12a6bccf81 wayland-1.21.92.tar.xz SHA512: ccc4c658859d4db7d9dd3fc8327d57095d37e5a6d88b1ecae9e32d33432afe49a3494c35bd868fd757964b3d43c2ae0cdce872c422af5441f3cbd96823b86cf0 wayland-1.21.92.tar.xz PGP: https://gitlab.freedesktop.org/wayland/wayland/-/releases/1.21.92/downloads/wayland-1.21.92.tar.xz.sig
[ANNOUNCE] wayland 1.21.91
This is the alpha release for Wayland 1.22. This new release adds explicit events for the preferred buffer scale and transform, adds an event to indicate the pointer's physical scroll direction, adds a few new convenience functions, and includes various spec clarifications and bug fixes. Full commit history below. Alexandros Frantzis (5): client: Track the proxies attached to a queue tests: Capture the test client log client: Warn when a queue is destroyed with attached proxies tests: Support tests that check for client failure client: Abort when trying to add an event to a destroyed queue Andri Yngvason (1): wayland-server: Add method to get global name Carlos Garnacho (1): server: Extend display name string size Daniel Stone (3): tests: Use bool for client test wayland-server: Add wl_client_add_destroy_late_listener tests: Ensure resource vs. client destroy handler order Fergus Dall (1): scanner: Fix undefined behavior around qsort Ian Douglas Scott (3): Do not allow nullable arrays, which were not correctly implemented Do not allow nullable `new_id` Document which type are nullable, and wire format for null value Kirill Primak (2): protocol: remove wl_subsurface lifetime contradiction protocol: add defunct_role_object error Marius Vlad (1): release.sh: Don't push *all* tags Mikhail Gusarov (2): protocol: wl_subsurface::destroy does not remove the role protocol: Clarify meaning of input region for cursors, DnD icons Olivier Fourdan (1): build: Make release.sh generic Peter Hutterer (1): protocol: add wl_pointer's axis relative physical direction Sebastian Wick (1): protocol: do not change pending x and y when attaching a buffer Simon Ser (19): build: re-open main branch for regular development Add release.sh util: name function typedef arguments server: don't document void return values cursor: make param names match with documentation ci: set ASAN_OPTIONS=detect_odr_violation=0 ci: upgrade images protocol: mention protocol error name in wl_subcompositor.get_subsurface protocol: add wl_compositor.error.bad_parent protocol: add note about wl_buffer/wl_callback version server: fail on global name overflow server: rename wl_display.id to next_global_name protocol: add wl_surface.preferred_buffer_scale protocol: add wl_surface.preferred_buffer_transform readme: drop paragraph about Weston readme: reword website description readme: convert to Markdown shm: fix segfault when accessing destroyed pool resource build: bump version to 1.21.91 for the alpha release Vlad Zahorodnii (1): protocol: reorder wl_data_offer.source_actions and wl_data_device.enter git tag: 1.21.91 https://gitlab.freedesktop.org/wayland/wayland/-/releases/1.21.91/downloads/wayland-1.21.91.tar.xz SHA256: 5381b18db7f1b98b1bcd71cf7740dec3382b34bea68e514f22672a6c1a4b418a wayland-1.21.91.tar.xz SHA512: 23839d241e4190ea29204a76d6041075c2b219e482a432c0afedef0fe8b14f42c709ca5c4c681d668a7d0ae27f28dd814b22f3e50449aca3627175d26867eba0 wayland-1.21.91.tar.xz PGP: https://gitlab.freedesktop.org/wayland/wayland/-/releases/1.21.91/downloads/wayland-1.21.91.tar.xz.sig
Re: [ANNOUNCE] Wayland 1.22.0 release schedule
On Tuesday, February 14th, 2023 at 14:23, Olivier Fourdan wrote: > > Let me know if you'd like a pending patch to make it in the release. > > Any chance to get !188 landed? > > https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/188 I've added it to the milestone.
[ANNOUNCE] libdisplay-info 0.1.1
This release fixes a typo in the pkg-config filename. Simon Ser (3): build: fix pkg-config filebase build: set pkg-config name and URL build: bump version to 0.1.1 git tag: 0.1.1 https://gitlab.freedesktop.org/emersion/libdisplay-info/-/releases/0.1.1/downloads/libdisplay-info-0.1.1.tar.xz SHA256: 0d8731588e9f82a9cac96324a3d7c82e2ba5b1b5e006143fefe692c74069fb60 libdisplay-info-0.1.1.tar.xz SHA512: 95c199211504af96816d92ec8e531bea993dd5d4a2935f1977f1e665b924b1628df25b81cd20da29543d008a8e6d757bdbceb09c74e031c0c213d60be9a10d7a libdisplay-info-0.1.1.tar.xz PGP: https://gitlab.freedesktop.org/emersion/libdisplay-info/-/releases/0.1.1/downloads/libdisplay-info-0.1.1.tar.xz.sig
[ANNOUNCE] Wayland 1.22.0 release schedule
Hi all, Here is the release schedule for Wayland 1.22.0: - Alpha: February 28th - Beta: March 14th - RC1: March 28th - First potential final release: April 4th Package maintainers are encouraged to pick up the pre-releases to make sure packaging can be tested (and fixed) before the stable release. Let me know if you'd like a pending patch to make it in the release. Thanks, Simon
[ANNOUNCE] libdisplay-info 0.1.0
This is the first release of libdisplay-info [1]. libdisplay-info is an EDID and DisplayID library. It provides a low-level API exposing all of the details of these formats, plus a high-level API which abstracts these details for common operations. The API isn't yet stable. For this release, the library includes full support for EDID, partial support for CTA-861-H, and very basic support for DisplayID 1.3. Thanks a lot to all contributors! [1]: https://gitlab.freedesktop.org/emersion/libdisplay-info Adarsh G M (1): di-edid-decode: help message for the executable Andrea Pappacoda (1): build: stop using meson's implicit setup command Joshua Ashton (4): memory-stream: Factor out memory-stream related code to a new file memory-stream: Add memory_stream_cleanup helper info: Use memory-stream API for di_info_parse_edid info: Use memory_stream_cleanup in di_info_get_serial Pekka Paalanen (11): tests/data: add HP Pavilion 27 Quantum Dot edid: fix uint16_t conversion warning Get size_t definition for info.h readme: mention edid-decode version readme: add Using section info: add getters for make, model and serial test: add high-level API test test: make edid-decode-diff.sh easier to run editorconfig: add python rules ci: install hwdata info: use PNP ID database for manufacturer names Sebastian Wick (22): edid: split the detailed timing signal union into separate structs cta: make HDR eotfs and descriptors directly accessible from the block edid: add support for color point descriptors edid: add support for Color Management Data descriptors edid: use the correct definition for maximum standard timings cta: add support for VESA Display Transfer Characteristic data block cta: parse short audio descriptors edid: add support for CVT timing code descriptors cta: include stddef.h for size_t ci: always build documentation cta: parse HDR Dynamic Metadata Data Block cta: add support for YCbCr 4:2:0 Video cta: add support for YCbCr 4:2:0 Capability Map di-edid-decode/cta: align VIC aspect ratio names test: Document where each EDID blob is from cdi-edid-decode/cta: Take interlacing into account when printing VICs cta: Add new data blocks from CTA-861.6 edid: Sync On Green Signal only is set if the bit is 0 and not 1 test: Bump edid-decode to newer version cta: add support for InfoFrame Data Block build: Set the library version and SOVERSION release: Add release instructions and script Simon Ser (165): Add .editorconfig ci: add .gitlab-ci.yml build: add Meson boilerplate build: tweak C warning options readme: add goals build: turn on -Wconversion ci: fix build stage not run in MRs Add very basic EDID functions Add skeleton for high-level API Add di_info_get_edid Add di-edid-decode utility edid: add vendor and product identification data build: enable POSIX.1-2008 Add di_info_get_product_name edid: add low-level API to enumerate extension blocks Add edid-decode testing infrastructure edid: use hex offsets edid: check that the blob size is divisible by the block size ci: fix tests with outdated edid-decode ci: always upload Meson logs as artifacts edid: validate extension block tag edid: document where extension block tags are defined edid: check extension block count field di-edid-decode: print extension block count edid: switch to a statically allocated extension array di-edid-decode: print block checksum ci: add junit report for tests ci: enable meson --fatal-meson-warnings ci: generate coverage information edid: add basic support for display descriptors edid: add support for product serial, name and data strings build: error out on -Wimplicit edid: introduce has_bit edid: introduce get_bit_range edid: parse digital video input definition edid: parse screen size edid: parse basic gamma edid: parse supported DPMS states edid: parse supported color encoding formats edid: parse other feature support flags di-edid-decode: only print serial number if non-zero test: add panasonic-mei96a2-dp EDID di-edid-decode: fix hang with a 32 KiB file readme: add building section readme: document fuzzing setup di-edid-decode: add optional arg to specify input filename edid: re-order display descriptor declarations in public header edid: prefix private functions with "_di_" build: set symbol visibility ci: mention how to force a container rebuild when pushing edid: add support for detailed timing definitions di-edid-decode: compute DTD aspect ratio edid: parse display range limits
Re: [RFC PATCH v3 0/3] Support for Solid Fill Planes
On Tuesday, January 31st, 2023 at 12:13, Pekka Paalanen wrote: > On Tue, 31 Jan 2023 10:06:39 + > Simon Ser wrote: > > > On Tuesday, January 31st, 2023 at 10:25, Pekka Paalanen > > wrote: > > > > > indeed, what about simply using a 1x1 framebuffer for real? Why was that > > > approach rejected? > > > > Ideally we don't want to allocate any GPU memory for the solid-fill > > stuff. And if we special-case 1x1 FB creation to not be backed by real > > GPU memory then we hit several situations where user-space expects a > > real FB but there isn't: for instance, GETFB2 converts from FB object > > ID to GEM handles. Even if we make GETFB2 fail and accept that this > > breaks user-space, then there is no way for user-space to recover the > > FB color for flicker-free transitions and such. > > > > This is all purely from a uAPI PoV, completely ignoring the potential > > issues with the internal kernel abstractions which might not be suitable > > for this either. > > I mean a real 1x1 buffer: a dumb buffer. > > It would be absolutely compatible with anything existing, because it is > a real FB. As a dumb buffer it would be trivial to write into and read > out. As 1x1 it would be tiny (one page?). Even if something needs to > raw-access uncached memory over 33 MHz PCI bus or whatever the worst > case is, it's just one pixel, so it's fast enough, right? And it only > needs to be read once when set, like USB display drivers do. The driver > does not need to manually apply any color operations, because none are > supported in this special case. > > One can put all these limitations and even pixel format in the plane > property that tells userspace that a 1x1 FB works here. > > To recap, the other alternatives under discussion I see right now are: > > - this proposal of dedicated fill color property > - stuffing something new into FB_ID property > > There is also the question of other kinds of plane content sources like > live camera feeds where userspace won't be shovelling each frame > individually like we do now. > > 1x1 dumb buffer is not as small and lean as a dedicated fill color > property, but the UAPI design questions seem to be much less. What's > the best trade-off and for whom? By "real memory" yes I mean the 1 page. Using a real buffer also brings back other discussions, e.g. the one about which pixel formats to accept.
Re: [RFC PATCH v3 0/3] Support for Solid Fill Planes
On Tuesday, January 31st, 2023 at 10:25, Pekka Paalanen wrote: > indeed, what about simply using a 1x1 framebuffer for real? Why was that > approach rejected? Ideally we don't want to allocate any GPU memory for the solid-fill stuff. And if we special-case 1x1 FB creation to not be backed by real GPU memory then we hit several situations where user-space expects a real FB but there isn't: for instance, GETFB2 converts from FB object ID to GEM handles. Even if we make GETFB2 fail and accept that this breaks user-space, then there is no way for user-space to recover the FB color for flicker-free transitions and such. This is all purely from a uAPI PoV, completely ignoring the potential issues with the internal kernel abstractions which might not be suitable for this either.
Re: [RFC PATCH v3 0/3] Support for Solid Fill Planes
On Wednesday, January 11th, 2023 at 23:29, Daniel Vetter wrote: > On Fri, Jan 06, 2023 at 04:33:04PM -0800, Abhinav Kumar wrote: > > Hi Daniel > > > > Thanks for looking into this series. > > > > On 1/6/2023 1:49 PM, Dmitry Baryshkov wrote: > > > On Fri, 6 Jan 2023 at 20:41, Daniel Vetter wrote: > > > > > > > > On Fri, Jan 06, 2023 at 05:43:23AM +0200, Dmitry Baryshkov wrote: > > > > > On Fri, 6 Jan 2023 at 02:38, Jessica Zhang > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > On 1/5/2023 3:33 AM, Daniel Vetter wrote: > > > > > > > On Wed, Jan 04, 2023 at 03:40:33PM -0800, Jessica Zhang wrote: > > > > > > > > Introduce and add support for a solid_fill property. When the > > > > > > > > solid_fill > > > > > > > > property is set, and the framebuffer is set to NULL, memory > > > > > > > > fetch will be > > > > > > > > disabled. > > > > > > > > > > > > > > > > In addition, loosen the NULL FB checks within the atomic commit > > > > > > > > callstack > > > > > > > > to allow a NULL FB when the solid_fill property is set and add > > > > > > > > FB checks > > > > > > > > in methods where the FB was previously assumed to be non-NULL. > > > > > > > > > > > > > > > > Finally, have the DPU driver use drm_plane_state.solid_fill and > > > > > > > > instead of > > > > > > > > dpu_plane_state.color_fill, and add extra checks in the DPU > > > > > > > > atomic commit > > > > > > > > callstack to account for a NULL FB in cases where solid_fill is > > > > > > > > set. > > > > > > > > > > > > > > > > Some drivers support hardware that have optimizations for solid > > > > > > > > fill > > > > > > > > planes. This series aims to expose these capabilities to > > > > > > > > userspace as > > > > > > > > some compositors have a solid fill flag (ex. SOLID_COLOR in the > > > > > > > > Android > > > > > > > > hardware composer HAL) that can be set by apps like the Android > > > > > > > > Gears > > > > > > > > app. > > > > > > > > > > > > > > > > Userspace can set the solid_fill property to a blob containing > > > > > > > > the > > > > > > > > appropriate version number and solid fill color (in RGB323232 > > > > > > > > format) and > > > > > > > > setting the framebuffer to NULL. > > > > > > > > > > > > > > > > Note: Currently, there's only one version of the solid_fill > > > > > > > > blob property. > > > > > > > > However if other drivers want to support a similar feature, but > > > > > > > > require > > > > > > > > more than just the solid fill color, they can extend this > > > > > > > > feature by > > > > > > > > creating additional versions of the drm_solid_fill struct. > > > > > > > > > > > > > > > > Changes in V2: > > > > > > > > - Dropped SOLID_FILL_FORMAT property (Simon) > > > > > > > > - Switched to implementing solid_fill property as a blob > > > > > > > > (Simon, Dmitry) > > > > > > > > - Changed to checks for if solid_fill_blob is set (Dmitry) > > > > > > > > - Abstracted (plane_state && !solid_fill_blob) checks to helper > > > > > > > > method > > > > > > > > (Dmitry) > > > > > > > > - Removed DPU_PLANE_COLOR_FILL_FLAG > > > > > > > > - Fixed whitespace and indentation issues (Dmitry) > > > > > > > > > > > > > > Now that this is a blob, I do wonder again whether it's not > > > > > > > cleaner to set > > > > > > > the blob as the FB pointer. Or create some kind other kind of > > > > > > > special data > > > > > > > source objects (because solid fill is by far not the only such > > > > > > > thing). > > > > > > > > > > > > > > We'd still end up in special cases like when userspace that > > > > > > > doesn't > > > > > > > understand solid fill tries to read out such a framebuffer, but > > > > > > > these > > > > > > > cases already exist anyway for lack of priviledges. > > > > > > > > > > > > > > So I still think that feels like the more consistent way to > > > > > > > integrate this > > > > > > > feature. Which doesn't mean it has to happen like that, but the > > > > > > > patches/cover letter should at least explain why we don't do it > > > > > > > like this. > > > > > > > > > > > > Hi Daniel, > > > > > > > > > > > > IIRC we were facing some issues with this check [1] when trying to > > > > > > set > > > > > > FB to a PROP_BLOB instead. Which is why we went with making it a > > > > > > separate property instead. Will mention this in the cover letter. > > > > > > > > > > What kind of issues? Could you please describe them? > > > > > > > > We switched from bitmask to enum style for prop types, which means it's > > > > not possible to express with the current uapi a property which accepts > > > > both an object or a blob. > > > > > > > > Which yeah sucks a bit ... > > > > > > > > But! > > > > > > > > blob properties are kms objects (like framebuffers), so it should be > > > > possible to stuff a blob into an object property as-is. Of course you > > > > need > > > > to update the validation code to make sure we accept either an fb or a > > > > blob for the internal
Re: [ANNOUNCE] pixfmtdb
On Monday, January 23rd, 2023 at 21:25, Sebastian Wick wrote: > Why is the TF defined for GL formats and both the primaries and TF for > Vulkan formats? The only exception here should be sRGB formats. Where > did you get the information from? This is what upstream dfdutils does [1]. Can you explain why you think it should be undefined instead of linear? I was wondering what to do for DRM formats regarding these. I think it would be worthwhile to do like Vulkan: set TF = linear, primaries = BT.709, pre-multiplied alpha = yes. These are the things KMS assume when there is no override (ie, when there is no KMS property saying otherwise). [1]: https://github.com/KhronosGroup/dfdutils/blob/5cd41cbdf63e80b00c085c6906a1152709e4c0f2/createdfd.c#L47
[ANNOUNCE] pixfmtdb
Hi all, In the last few days I've been working on a small new project, pixfmtdb [1]. It's a Web database of pixel format guides, it can be useful to understand how pixels are laid out in memory for a given format and which formats from various APIs are compatible with each other. pixfmtdb relies on the Khronos Data Format Specification [2] to describe each format. This means that each format is described with a standardized data blob, which can be re-used with other tools for other purposes. My future plans include adding more formats and format families to pixfmtdb, and make it easy to use the data for code generation, in particular for automatically generating tables containing metadata about formats, as used in Wayland compositors and other projects. I hope some of you can find this work useful, Simon [1]: https://pixfmtdb.emersion.fr [2]: https://www.khronos.org/dataformat
Re: [PATCH v3 0/6] Add support for atomic async page-flips
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 implemented here isn't smart enough. tl;dr there are still discrepancies between the regular code-path and the async page-flip one. Does that matter?
Re: [ANNOUNCE] Weston bug-fix release -- 11.0.1 and 10.0.3
Glad I could help Weston these last few years, and thank you for stepping up Marius!
Re: [PATCH v3 0/6] Add support for atomic async page-flips
Ville, any news on this?
[PATCH] drm/atomic: add quirks for blind save/restore
Two quirks to make blind atomic save/restore [1] work correctly:
- Mark the DPMS property as immutable for atomic clients, since
atomic clients cannot change it.
- Allow user-space to set content protection to "enabled", interpret
it as "desired".
[1]: https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/3794
Signed-off-by: Simon Ser
---
I don't have the motivation to write IGT tests for this.
drivers/gpu/drm/drm_atomic_uapi.c | 5 +++--
drivers/gpu/drm/drm_property.c| 7 +++
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index c06d0639d552..95363aac7f69 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -741,8 +741,9 @@ static int drm_atomic_connector_set_property(struct
drm_connector *connector,
state->scaling_mode = val;
} else if (property == config->content_protection_property) {
if (val == DRM_MODE_CONTENT_PROTECTION_ENABLED) {
- drm_dbg_kms(dev, "only drivers can set CP Enabled\n");
- return -EINVAL;
+ /* Degrade ENABLED to DESIRED so that blind atomic
+* save/restore works as intended. */
+ val = DRM_MODE_CONTENT_PROTECTION_DESIRED;
}
state->content_protection = val;
} else if (property == config->hdcp_content_type_property) {
diff --git a/drivers/gpu/drm/drm_property.c b/drivers/gpu/drm/drm_property.c
index dfec479830e4..dde42986f8cb 100644
--- a/drivers/gpu/drm/drm_property.c
+++ b/drivers/gpu/drm/drm_property.c
@@ -474,7 +474,14 @@ int drm_mode_getproperty_ioctl(struct drm_device *dev,
return -ENOENT;
strscpy_pad(out_resp->name, property->name, DRM_PROP_NAME_LEN);
+
out_resp->flags = property->flags;
+ if (file_priv->atomic && property == dev->mode_config.dpms_property) {
+ /* Quirk: indicate that the legacy DPMS property is not
+* writable from atomic user-space, so that blind atomic
+* save/restore works as intended. */
+ out_resp->flags |= DRM_MODE_PROP_IMMUTABLE;
+ }
value_count = property->num_values;
values_ptr = u64_to_user_ptr(out_resp->values_ptr);
--
2.38.1
Re: [RFC PATCH 1/3] drm: Introduce color fill properties for drm plane
cc'ing Pekka and wayland-devel for userspace devs feedback on the new uAPI.
On Saturday, October 29th, 2022 at 14:08, Dmitry Baryshkov
wrote:
> On 29/10/2022 01:59, Jessica Zhang wrote:
> > Add support for COLOR_FILL and COLOR_FILL_FORMAT properties for
> > drm_plane. In addition, add support for setting and getting the values
> > of these properties.
> >
> > COLOR_FILL represents the color fill of a plane while COLOR_FILL_FORMAT
> > represents the format of the color fill. Userspace can set enable solid
> > fill on a plane by assigning COLOR_FILL to a uint64_t value, assigning
> > the COLOR_FILL_FORMAT property to a uint32_t value, and setting the
> > framebuffer to NULL.
> >
> > Signed-off-by: Jessica Zhang
>
> Planes report supported formats using the drm_mode_getplane(). You'd
> also need to tell userspace, which formats are supported for color fill.
> I don't think one supports e.g. YV12.
>
> A bit of generic comment for the discussion (this is an RFC anyway).
> Using color_fill/color_fill_format properties sounds simple, but this
> might be not generic enough. Limiting color_fill to 32 bits would
> prevent anybody from using floating point formats (e.g.
> DRM_FORMAT_XRGB16161616F, 64-bit value). Yes, this can be solved with
> e.g. using 64-bit for the color_fill value, but then this doesn't sound
> extensible too much.
>
> So, a question for other hardware maintainers. Do we have hardware that
> supports such 'color filled' planes? Do we want to support format
> modifiers for filling color/data? Because what I have in mind is closer
> to the blob structure, which can then be used for filling the plane:
>
> struct color_fill_blob {
> u32 pixel_format;
> u64 modifiers4];
> u32 pixel_data_size; // fixme: is this necessary?
> u8 pixel_data[];
> };
>
> And then... This sounds a lot like a custom framebuffer.
>
> So, maybe what should we do instead is to add new DRM_MODE_FB_COLOR_FILL
> flag to the framebuffers, which would e.g. mean that the FB gets stamped
> all over the plane. This would also save us from changing if (!fb)
> checks all over the drm core.
>
> Another approach might be using a format modifier instead of the FB flag.
>
> What do you think?
First off, we only need to represent the value of a single pixel here. So I'm
not quite following why we need format modifiers. Format modifiers describe how
pixels are laid out in memory. Since there's a single pixel described, this
is non-sensical to me, the format modifier is always LINEAR.
Then, I can understand why putting the pixel_format in there is tempting to
guarantee future extensibility, but it also adds complexity. For instance, how
does user-space figure out which formats can be used for COLOR_FILL? Can
user-space use any format supported by the plane? What does it mean for
multi-planar formats? Do we really want the kernel to have conversion logic for
all existing formats? Do we need to also add a new read-only blob prop to
indicate supported COLOR_FILL formats?
We've recently-ish standardized a new Wayland protocol [1] which has the same
purpose as this new kernel uAPI. The conclusion there was that using 32-bit
values for each channel (R, G, B, A) would be enough for almost all use-cases.
The driver can convert these high-precision values to what the hardware expects.
The only concern was about sending values outside of the [0.0, 1.0] range,
which may have HDR use-cases.
So, there are multiple ways to go about this. I can think of:
- Put "RGBA32" in the name of the prop, and if we ever need a different
color format, pick a different name.
- Define a struct with an enum of possible fill kinds:
#define FILL_COLOR_RGBA32 1
#define FILL_COLOR_F32 2
struct color_fill_blob { u32 kind; u8 data[]; };
- Define a struct with a version and RGBA values:
struct color_fill_blob { u32 version; u32 rgba[4]; };
If we need to add more formats later, or new metadata:
struct color_fill_blob2 { u32 version; /* new fields */ };
where version must be set to 2.
- Define a struct with a "pixel_format" prop, but force user-space to use a
fixed format for now. Later, if we need another format, add a new prop to
advertise supported formats.
- More complicated solutions, e.g. advertise the list of supported formats from
the start.
[1]:
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/104
Re: [PATCH v3 0/6] Add support for atomic async page-flips
> > > 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
> > the ioctl going to succeed if you ask for an async change of some
> > random property while the crtc disabled, but fails if you ask for
> > the same async property change when the crtc is active?
> >
> > So another reason why rejecting most properties already at
> > the uapi level might be a good idea.
>
> And just to be clear this is pretty much what I suggest:
>
> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> b/drivers/gpu/drm/drm_atomic_uapi.c
> index 79730fa1dd8e..471a2c703847 100644
> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> @@ -1392,6 +1392,13 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
> goto out;
> }
>
> + if (arg->flags & DRM_MODE_PAGE_FLIP_ASYNC &&
> + prop != dev->mode_config.prop_fb_id) {
> + drm_mode_object_put(obj);
> + ret = -EINVAL;
> + goto out;
> + }
> +
> if (copy_from_user(_value,
> prop_values_ptr + copied_props,
> sizeof(prop_value))) {
>
>
> That would actively discourage people from even attempting the
> "just dump all the state into the ioctl" approach with async flips
> since even the props whose value isn't even changing would be rejected.
How does this sound?
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index 945761968428..ffd16bdc7b83 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -972,14 +972,26 @@ int drm_atomic_set_property(struct drm_atomic_state
*state,
struct drm_file *file_priv,
struct drm_mode_object *obj,
struct drm_property *prop,
- uint64_t prop_value)
+ uint64_t prop_value,
+ bool async_flip)
{
struct drm_mode_object *ref;
int ret;
+ uint64_t old_val;
if (!drm_property_change_valid_get(prop, prop_value, ))
return -EINVAL;
+ if (async_flip && prop != prop->dev->mode_config.prop_fb_id) {
+ ret = drm_atomic_get_property(obj, prop, _val);
+ if (ret != 0 || old_val != prop_value) {
+ drm_dbg_atomic(prop->dev,
+ "[PROP:%d:%s] cannot be changed during
async flip\n",
+ prop->base.id, prop->name);
+ return -EINVAL;
+ }
+ }
+
switch (obj->type) {
case DRM_MODE_OBJECT_CONNECTOR: {
struct drm_connector *connector = obj_to_connector(obj);
[PATCH v2] drm/syncobj: add IOCTL to register an eventfd
Introduce a new DRM_IOCTL_SYNCOBJ_EVENTFD IOCTL which signals an
eventfd from a syncobj.
This is useful for Wayland compositors to handle wait-before-submit.
Wayland clients can send a timeline point to the compositor
before the point has materialized yet, then compositors can wait
for the point to materialize via this new IOCTL.
The existing DRM_IOCTL_SYNCOBJ_TIMELINE_WAIT IOCTL is not suitable
because it blocks. Compositors want to integrate the wait with
their poll(2)-based event loop.
v2:
- Wait for fence when flags is zero
- Improve documentation (Pekka)
- Rename IOCTL (Christian)
- Fix typo in drm_syncobj_add_eventfd() (Christian)
Signed-off-by: Simon Ser
Cc: Jason Ekstrand
Cc: Daniel Vetter
Cc: Christian König
Cc: Bas Nieuwenhuizen
Cc: Daniel Stone
Cc: Pekka Paalanen
Cc: James Jones
---
Toy user-space available at:
https://paste.sr.ht/~emersion/674bd4fc614570f262b5bb2213be5c77d68944ac
drivers/gpu/drm/drm_internal.h | 2 +
drivers/gpu/drm/drm_ioctl.c| 2 +
drivers/gpu/drm/drm_syncobj.c | 143 +++--
include/drm/drm_syncobj.h | 6 +-
include/uapi/drm/drm.h | 22 +
5 files changed, 168 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
index 1fbbc19f1ac0..ca320e155b69 100644
--- a/drivers/gpu/drm/drm_internal.h
+++ b/drivers/gpu/drm/drm_internal.h
@@ -242,6 +242,8 @@ int drm_syncobj_wait_ioctl(struct drm_device *dev, void
*data,
struct drm_file *file_private);
int drm_syncobj_timeline_wait_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_private);
+int drm_syncobj_eventfd_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file_private);
int drm_syncobj_reset_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_private);
int drm_syncobj_signal_ioctl(struct drm_device *dev, void *data,
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index ca2a6e6101dc..95ec9a02f8a7 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -702,6 +702,8 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
DRM_RENDER_ALLOW),
DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_TIMELINE_WAIT,
drm_syncobj_timeline_wait_ioctl,
DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_EVENTFD, drm_syncobj_eventfd_ioctl,
+ DRM_RENDER_ALLOW),
DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_RESET, drm_syncobj_reset_ioctl,
DRM_RENDER_ALLOW),
DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_SIGNAL, drm_syncobj_signal_ioctl,
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index 0c2be8360525..659577ad8c07 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -185,6 +185,7 @@
#include
#include
+#include
#include
#include
#include
@@ -212,6 +213,20 @@ struct syncobj_wait_entry {
static void syncobj_wait_syncobj_func(struct drm_syncobj *syncobj,
struct syncobj_wait_entry *wait);
+struct syncobj_eventfd_entry {
+ struct list_head node;
+ struct dma_fence *fence;
+ struct dma_fence_cb fence_cb;
+ struct drm_syncobj *syncobj;
+ struct eventfd_ctx *ev_fd_ctx;
+ u64 point;
+ u32 flags;
+};
+
+static void
+syncobj_eventfd_entry_func(struct drm_syncobj *syncobj,
+ struct syncobj_eventfd_entry *entry);
+
/**
* drm_syncobj_find - lookup and reference a sync object.
* @file_private: drm file private pointer
@@ -274,6 +289,27 @@ static void drm_syncobj_remove_wait(struct drm_syncobj
*syncobj,
spin_unlock(>lock);
}
+static void
+syncobj_eventfd_entry_free(struct syncobj_eventfd_entry *entry)
+{
+ eventfd_ctx_put(entry->ev_fd_ctx);
+ dma_fence_put(entry->fence);
+ /* This happens either inside the syncobj lock, or after the node has
+* already been removed from the list */
+ list_del(>node);
+ kfree(entry);
+}
+
+static void
+drm_syncobj_add_eventfd(struct drm_syncobj *syncobj,
+ struct syncobj_eventfd_entry *entry)
+{
+ spin_lock(>lock);
+ list_add_tail(>node, >ev_fd_list);
+ syncobj_eventfd_entry_func(syncobj, entry);
+ spin_unlock(>lock);
+}
+
/**
* drm_syncobj_add_point - add new timeline point to the syncobj
* @syncobj: sync object to add timeline point do
@@ -288,7 +324,8 @@ void drm_syncobj_add_point(struct drm_syncobj *syncobj,
struct dma_fence *fence,
uint64_t point)
{
- struct syncobj_wait_entry *cur, *tmp;
+ struct syncobj_wait_entry *wait_cur, *wait_tmp;
+ struct syncobj_eventfd_entry *ev_fd_cur, *ev_fd_tmp;
struct dma_fence *prev;
dma_fence_get(fence);
@
Re: [RFC PATCH] drm/syncobj: add IOCTL to register an eventfd for a timeline
On Tuesday, October 11th, 2022 at 14:10, Christian König wrote: > Am 10.10.22 um 11:13 schrieb Simon Ser: > > On Sunday, October 9th, 2022 at 20:00, Christian König > > wrote: > > > >> Am 09.10.22 um 16:40 schrieb Simon Ser: > >> > >>> Introduce a new DRM_IOCTL_SYNCOBJ_TIMELINE_REGISTER_EVENTFD IOCTL > >>> which signals an eventfd when a timeline point completes. > >> I was entertaining the same though for quite a while, but I would even > >> go a step further and actually always base the wait before signal > >> functionality of the drm_syncobj and the eventfd functionality. That > >> would save us quite a bit of complexity I think. > > Hm what do you mean exactly? I'm not sure I'm following. > > Essentially we have the syncobj_wait_entry structure which is added to > the list whenever somebody starts to wait for a sequence which hasn't > materialized yet. > > Instead of extending this maybe just completely nuke the > syncobj_wait_entry handling and replace it with your implementation here. Hm, no sure I understand how that would work. We don't have an eventfd in the WAIT IOCTL... We could merge the two structs and figure out which callback to invoke based on which fields are filled, but I figured two separate structs would be make for a cleaner split.
Re: [RFC PATCH] drm/syncobj: add IOCTL to register an eventfd for a timeline
On Monday, October 10th, 2022 at 10:19, Pekka Paalanen
wrote:
> I'm completely clueless about this API.
No worries!
> > +/**
> > + * struct drm_syncobj_timeline_register_eventfd
> > + *
> > + * Register an eventfd to be signalled when a timeline point completes. The
> > + * eventfd counter will be incremented by one.
>
> Sounds nice.
>
> Since the action is to increment the counter by one, does it mean it
> will be possible to wait for a bunch of completions and have the
> eventfd poll return only when they have all signaled?
It is possible to perform the IOCTL multiple times with the same eventfd, but
eventfd semnatics would wake up user-space each time any timeline point
completes.
> > + */
> > +struct drm_syncobj_timeline_register_eventfd {
> > + __u32 handle;
>
> Handle of what?
drm_syncobj handle
> > + __u32 flags;
>
> What flags are allowed? Must be zero for now?
Same flags as the wait IOCTL.
Must be WAIT_AVAILABLE for now, but I'll implement the zero case as well (see
TODO).
> > + __u64 point;
>
> Is this some Vulkan thingy?
It's a drm_syncobj timeline thing. The timeline contains multiple sync points.
> > + __s32 fd;
>
> I guess the userspace needs to create an eventfd first, and pass it as
> the argument here? This is not creating a new eventfd itself?
Correct
> > + __u32 pad;
>
> Must be zero?
Indeed.
I'll spell out these requirements explicitly in the next version.
Re: [RFC PATCH] drm/syncobj: add IOCTL to register an eventfd for a timeline
On Sunday, October 9th, 2022 at 20:00, Christian König wrote: > Am 09.10.22 um 16:40 schrieb Simon Ser: > > > Introduce a new DRM_IOCTL_SYNCOBJ_TIMELINE_REGISTER_EVENTFD IOCTL > > which signals an eventfd when a timeline point completes. > > I was entertaining the same though for quite a while, but I would even > go a step further and actually always base the wait before signal > functionality of the drm_syncobj and the eventfd functionality. That > would save us quite a bit of complexity I think. Hm what do you mean exactly? I'm not sure I'm following. > As a general note I think the name > DRM_IOCTL_SYNCOBJ_TIMELINE_REGISTER_EVENTFD is just to long, just make > that DRM_IOCTL_SYNCOBJ_EVENTFD. Same for the function names as well. Agreed. > Additional to that I think we should also always have a graceful > handling for binary syncobjs. So please try to avoid making this special > for the timeline case (the timeline case should of course still be > supported). This makes sense to me.
[RFC PATCH] drm/syncobj: add IOCTL to register an eventfd for a timeline
Introduce a new DRM_IOCTL_SYNCOBJ_TIMELINE_REGISTER_EVENTFD IOCTL
which signals an eventfd when a timeline point completes.
This is useful for Wayland compositors to handle wait-before-submit.
Wayland clients can send a timeline point to the compositor
before the point has materialized yet, then compositors can wait
for the point to materialize via this new IOCTL.
The existing DRM_IOCTL_SYNCOBJ_TIMELINE_WAIT IOCTL is not suitable
because it blocks. Compositors want to integrate the wait with
their poll(2)-based event loop.
Signed-off-by: Simon Ser
Cc: Jason Ekstrand
Cc: Daniel Vetter
Cc: Christian König
Cc: Bas Nieuwenhuizen
Cc: Daniel Stone
Cc: Pekka Paalanen
Cc: James Jones
---
drivers/gpu/drm/drm_internal.h | 3 +
drivers/gpu/drm/drm_ioctl.c| 3 +
drivers/gpu/drm/drm_syncobj.c | 113 +++--
include/drm/drm_syncobj.h | 6 +-
include/uapi/drm/drm.h | 15 +
5 files changed, 133 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
index 1fbbc19f1ac0..4244e929b7f9 100644
--- a/drivers/gpu/drm/drm_internal.h
+++ b/drivers/gpu/drm/drm_internal.h
@@ -242,6 +242,9 @@ int drm_syncobj_wait_ioctl(struct drm_device *dev, void
*data,
struct drm_file *file_private);
int drm_syncobj_timeline_wait_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_private);
+int drm_syncobj_timeline_register_eventfd_ioctl(struct drm_device *dev,
+ void *data,
+ struct drm_file *file_private);
int drm_syncobj_reset_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_private);
int drm_syncobj_signal_ioctl(struct drm_device *dev, void *data,
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index ca2a6e6101dc..dcd18dba28b7 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -702,6 +702,9 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
DRM_RENDER_ALLOW),
DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_TIMELINE_WAIT,
drm_syncobj_timeline_wait_ioctl,
DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_TIMELINE_REGISTER_EVENTFD,
+ drm_syncobj_timeline_register_eventfd_ioctl,
+ DRM_RENDER_ALLOW),
DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_RESET, drm_syncobj_reset_ioctl,
DRM_RENDER_ALLOW),
DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_SIGNAL, drm_syncobj_signal_ioctl,
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index 0c2be8360525..401d09b56cf1 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -185,6 +185,7 @@
#include
#include
+#include
#include
#include
#include
@@ -212,6 +213,17 @@ struct syncobj_wait_entry {
static void syncobj_wait_syncobj_func(struct drm_syncobj *syncobj,
struct syncobj_wait_entry *wait);
+struct syncobj_eventfd_entry {
+ struct list_head node;
+ struct dma_fence_cb fence_cb;
+ struct eventfd_ctx *ev_fd_ctx;
+ u64 point;
+};
+
+static void
+syncobj_eventfd_entry_func(struct drm_syncobj *syncobj,
+ struct syncobj_eventfd_entry *entry);
+
/**
* drm_syncobj_find - lookup and reference a sync object.
* @file_private: drm file private pointer
@@ -274,6 +286,25 @@ static void drm_syncobj_remove_wait(struct drm_syncobj
*syncobj,
spin_unlock(>lock);
}
+static void
+syncobj_eventfd_entry_free(struct syncobj_eventfd_entry *entry)
+{
+ eventfd_ctx_put(entry->ev_fd_ctx);
+ /* This happens inside the syncobj lock */
+ list_del(>node);
+ kfree(entry);
+}
+
+static void
+drm_syncobj_add_eventfd(struct drm_syncobj *syncobj,
+ struct syncobj_eventfd_entry *entry)
+{
+ spin_lock(>lock);
+ list_add_tail(>node, >cb_list);
+ syncobj_eventfd_entry_func(syncobj, entry);
+ spin_unlock(>lock);
+}
+
/**
* drm_syncobj_add_point - add new timeline point to the syncobj
* @syncobj: sync object to add timeline point do
@@ -288,7 +319,8 @@ void drm_syncobj_add_point(struct drm_syncobj *syncobj,
struct dma_fence *fence,
uint64_t point)
{
- struct syncobj_wait_entry *cur, *tmp;
+ struct syncobj_wait_entry *wait_cur, *wait_tmp;
+ struct syncobj_eventfd_entry *ev_fd_cur, *ev_fd_tmp;
struct dma_fence *prev;
dma_fence_get(fence);
@@ -302,8 +334,10 @@ void drm_syncobj_add_point(struct drm_syncobj *syncobj,
dma_fence_chain_init(chain, prev, fence, point);
rcu_assign_pointer(syncobj->fence, >base);
- list_for_each_entry_safe(cur, tmp, >cb_list, node)
- syncobj_
Re: [RFC v2] drm/kms: control display brightness through drm_connector properties
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...@redhat.com wrote: > > > > > > > If it is supposed to be a non-linear luminance curve, which one is it? > > > > It would be much clearer if user space can control linear luminance > > > > and use whatever definition of perceived brightness it wants. The > > > > obvious downside of it is that it requires bits to encode changes that > > > > users can't perceive. What about backlights which only have a few > > > > predefined luminance levels? How would user space differentiate > > > > between the continuous and discrete backlight? What about > > > > self-emitting displays? They usually increase the dynamic range when > > > > they increase in brightness because the black level doesn't rise. They > > > > also probably employ some tonemapping to adjust for that. What about > > > > the range of the backlight? What about the absolute luminance of the > > > > backlight? I want to know about that all in user space. > > > > > > > > I understand that most of the time the kernel doesn't have answers to > > > > those questions right now but the API should account for all of that. > > > > > > Hi, > > > > > > if the API accounts for all that, and the kernel doesn't know, then how > > > can the API not lie? If the API sometimes lies, how could we ever trust > > > it at all? > > > > Make it possible for the API to say "I don't know". I'd much rather > > have an API tell me explicitly what it does and doesn't know instead > > of having to guess what data I can actually rely on. > > > > For example if the kernel knows the luminance is linear on one display > > and doesn't know anything about the other display and it exposes them > > both in the same way I can not possibly write any code which relies on > > exact control over the luminance for either display. > > > > > Personally I have the feeling that if we can even get to the level of > > > "each step in the value is a more or less perceivable change", that > > > would be good enough. Think of UI, e.g. hotkeys to change brightness. > > > You'd expect almost every press to change it a bit. > > > > The nice thing is that you can have that even if you have no further > > information about the brightness control and it might be good enough > > for some use cases but it isn't for others. > > > > > If an end user wants defined and controlled luminance, I'd suggest they > > > need to profile (physically measure) the response of the display at > > > hand. This is no different from color profiling displays, but you need > > > a measurement device that produces absolute measurements if absolute > > > control is what they want. > > > > If that's the kind of user experience you're after, good for you. I > > certainly want things to work out of the box which makes this just a > > big no-go. > > > I think if we have the information to make the default behaviour > better then we should do that. Ie. if the firmaware gives us a > table to remap the values for a more linear response we should > make use of that by default. > > We can of course provide a way for the user to plug in their own > actually measured data later. But IMO that doesn't even have to > happen in the initial implementation. Just need to avoid painting > ourselves totally in the corner in a way that would prevent later > additions like that. Yes. Please don't try to solve all of the problems at once. There have been many tries to add brightness to KMS, and having *something* would be a lot better than having nothing. If we try to have the perfect complete API from the start then we'll never get anything done.
Re: [PATCH v3 3/6] drm: introduce drm_mode_config.atomic_async_page_flip_not_supported
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 > > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > > @@ -3808,6 +3808,7 @@ static int amdgpu_dm_mode_config_init(struct > > amdgpu_device *adev) > > adev_to_drm(adev)->mode_config.prefer_shadow = 1; > > /* indicates support for immediate flip */ > > adev_to_drm(adev)->mode_config.async_page_flip = true; > > + adev_to_drm(adev)->mode_config.atomic_async_page_flip_not_supported = > > true; > > The flag polarity seems weird. Why opt out and not opt in? Explained in the commit message.
[PATCH v3 6/6] amd/display: indicate support for atomic async page-flips on DC
amdgpu_dm_commit_planes() already sets the flip_immediate flag for async page-flips. This flag is used to set the UNP_FLIP_CONTROL register. Thus, no additional change is required to handle async page-flips with the atomic uAPI. v2: make it clear this commit is about DC and not only DCN 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 --- 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/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c index 7500e82cf06a..44235345fd57 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -3808,7 +3808,6 @@ static int amdgpu_dm_mode_config_init(struct amdgpu_device *adev) adev_to_drm(adev)->mode_config.prefer_shadow = 1; /* indicates support for immediate flip */ adev_to_drm(adev)->mode_config.async_page_flip = true; - adev_to_drm(adev)->mode_config.atomic_async_page_flip_not_supported = true; adev_to_drm(adev)->mode_config.fb_base = adev->gmc.aper_base; -- 2.37.3
[PATCH v3 4/6] drm: allow DRM_MODE_PAGE_FLIP_ASYNC for atomic commits
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.
Document that drivers will reject atomic commits if an async
flip isn't possible. This allows user-space to fall back to
something 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
v3: add comment about Intel hardware which needs one last
sync page-flip before being able to switch to async (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/gpu/drm/drm_atomic_uapi.c | 28 +---
include/uapi/drm/drm_mode.h | 9 +
2 files changed, 34 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index 79730fa1dd8e..ee24ed7e2edb 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -1278,6 +1278,18 @@ static void complete_signaling(struct drm_device *dev,
kfree(fence_state);
}
+static void
+set_async_flip(struct drm_atomic_state *state)
+{
+ struct drm_crtc *crtc;
+ struct drm_crtc_state *crtc_state;
+ int i;
+
+ for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
+ crtc_state->async_flip = true;
+ }
+}
+
int drm_mode_atomic_ioctl(struct drm_device *dev,
void *data, struct drm_file *file_priv)
{
@@ -1318,9 +1330,16 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
}
if (arg->flags & DRM_MODE_PAGE_FLIP_ASYNC) {
- drm_dbg_atomic(dev,
- "commit failed: invalid flag
DRM_MODE_PAGE_FLIP_ASYNC\n");
- return -EINVAL;
+ if (!dev->mode_config.async_page_flip) {
+ drm_dbg_atomic(dev,
+ "commit failed: DRM_MODE_PAGE_FLIP_ASYNC
not supported\n");
+ return -EINVAL;
+ }
+ if (dev->mode_config.atomic_async_page_flip_not_supported) {
+ drm_dbg_atomic(dev,
+ "commit failed: DRM_MODE_PAGE_FLIP_ASYNC
not supported with atomic\n");
+ return -EINVAL;
+ }
}
/* can't test and expect an event at the same time. */
@@ -1418,6 +1437,9 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
if (ret)
goto out;
+ if (arg->flags & DRM_MODE_PAGE_FLIP_ASYNC)
+ set_async_flip(state);
+
if (arg->flags & DRM_MODE_ATOMIC_TEST_ONLY) {
ret = drm_atomic_check_only(state);
} else if (arg->flags & DRM_MODE_ATOMIC_NONBLOCK) {
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 86a292c3185a..b39e78117b18 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -942,6 +942,15 @@ struct hdr_output_metadata {
* Request that the page-flip is performed as soon as possible, ie. with no
* delay due to waiting for vblank. This may cause tearing to be visible on
* the screen.
+ *
+ * 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 regular page-flip.
+ *
+ * Note, some hardware might need to perform one last synchronous page-flip
+ * before being able to switch to asynchronous page-flips. As an exception,
+ * the driver will return success even though that first page-flip is not
+ * asynchronous.
*/
#define DRM_MODE_PAGE_FLIP_ASYNC 0x02
#define DRM_MODE_PAGE_FLIP_TARGET_ABSOLUTE 0x4
--
2.37.3
[PATCH v3 5/6] drm: introduce DRM_CAP_ATOMIC_ASYNC_PAGE_FLIP
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
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/drm_ioctl.c | 5 +
include/uapi/drm/drm.h | 10 +-
2 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index ca2a6e6101dc..5b1591e2b46c 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -302,6 +302,11 @@ static int drm_getcap(struct drm_device *dev, void *data,
struct drm_file *file_
case DRM_CAP_CRTC_IN_VBLANK_EVENT:
req->value = 1;
break;
+ case DRM_CAP_ATOMIC_ASYNC_PAGE_FLIP:
+ req->value = drm_core_check_feature(dev, DRIVER_ATOMIC) &&
+dev->mode_config.async_page_flip &&
+
!dev->mode_config.atomic_async_page_flip_not_supported;
+ break;
default:
return -EINVAL;
}
diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index 642808520d92..b1962628ecda 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h
@@ -706,7 +706,8 @@ struct drm_gem_open {
/**
* DRM_CAP_ASYNC_PAGE_FLIP
*
- * If set to 1, the driver supports _MODE_PAGE_FLIP_ASYNC.
+ * If set to 1, the driver supports _MODE_PAGE_FLIP_ASYNC for legacy
+ * page-flips.
*/
#define DRM_CAP_ASYNC_PAGE_FLIP0x7
/**
@@ -767,6 +768,13 @@ struct drm_gem_open {
* Documentation/gpu/drm-mm.rst, section "DRM Sync Objects".
*/
#define DRM_CAP_SYNCOBJ_TIMELINE 0x14
+/**
+ * DRM_CAP_ATOMIC_ASYNC_PAGE_FLIP
+ *
+ * If set to 1, the driver supports _MODE_PAGE_FLIP_ASYNC for atomic
+ * commits.
+ */
+#define DRM_CAP_ATOMIC_ASYNC_PAGE_FLIP 0x15
/* DRM_IOCTL_GET_CAP ioctl argument type */
struct drm_get_cap {
--
2.37.3
[PATCH v3 0/6] Add support for atomic async page-flips
This series adds support for DRM_MODE_PAGE_FLIP_ASYNC for atomic commits, aka. "immediate flip" (which might result in tearing). The feature was only available via the legacy uAPI, however for gaming use-cases it may be desirable to enable it via the atomic uAPI too. - Patchwork: 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. Changes in v3: add a note in the documentation 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_supported drm: allow DRM_MODE_PAGE_FLIP_ASYNC for atomic commits drm: introduce DRM_CAP_ATOMIC_ASYNC_PAGE_FLIP amd/display: indicate support for atomic async page-flips on DC .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 8 ++ .../amd/display/amdgpu_dm/amdgpu_dm_crtc.c| 10 +++ drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 1 + drivers/gpu/drm/drm_atomic_uapi.c | 28 +-- drivers/gpu/drm/drm_ioctl.c | 5 drivers/gpu/drm/i915/display/intel_display.c | 1 + drivers/gpu/drm/nouveau/nouveau_display.c | 1 + drivers/gpu/drm/vc4/vc4_kms.c | 1 + include/drm/drm_mode_config.h | 11 include/uapi/drm/drm.h| 10 ++- include/uapi/drm/drm_mode.h | 16 +++ 11 files changed, 88 insertions(+), 4 deletions(-) -- 2.37.3
[PATCH v3 2/6] amd/display: only accept async flips for fast updates
Up until now, amdgpu was silently degrading to vsync when
user-space requested an async flip but the hardware didn't support
it.
The hardware doesn't support immediate flips when the update changes
the FB pitch, the DCC state, the rotation, enables or disables CRTCs
or planes, etc. This is reflected in the dm_crtc_state.update_type
field: UPDATE_TYPE_FAST means that immediate flip is supported.
Silently degrading async flips to vsync is not the expected behavior
from a uAPI point-of-view. Xorg expects async flips to fail if
unsupported, to be able to fall back to a blit. i915 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 Kazlauskas
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 8
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crtc.c | 10 ++
2 files changed, 18 insertions(+)
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 7b19f444624c..44235345fd57 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -7629,7 +7629,15 @@ static void amdgpu_dm_commit_planes(struct
drm_atomic_state *state,
/*
* Only allow immediate flips for fast updates that don't
* change FB pitch, DCC state, rotation or mirroing.
+*
+* dm_crtc_helper_atomic_check() only accepts async flips with
+* fast updates.
*/
+ if (crtc->state->async_flip &&
+ acrtc_state->update_type != UPDATE_TYPE_FAST)
+ drm_warn_once(state->dev,
+ "[PLANE:%d:%s] async flip with non-fast
update\n",
+ plane->base.id, plane->name);
bundle->flip_addrs[planes_count].flip_immediate =
crtc->state->async_flip &&
acrtc_state->update_type == UPDATE_TYPE_FAST;
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crtc.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crtc.c
index 594fe8a4d02b..97ead857f507 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crtc.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crtc.c
@@ -388,6 +388,16 @@ static int dm_crtc_helper_atomic_check(struct drm_crtc
*crtc,
return -EINVAL;
}
+ /* Only allow async flips for fast updates that don't change the FB
+* pitch, the DCC state, rotation, etc. */
+ if (crtc_state->async_flip &&
+ dm_crtc_state->update_type != UPDATE_TYPE_FAST) {
+ drm_dbg_atomic(crtc->dev,
+ "[CRTC:%d:%s] async flips are only supported for
fast updates\n",
+ crtc->base.id, crtc->name);
+ return -EINVAL;
+ }
+
/* In some use cases, like reset, no stream is attached */
if (!dm_crtc_state->stream)
return 0;
--
2.37.3
[PATCH v3 3/6] drm: introduce drm_mode_config.atomic_async_page_flip_not_supported
This new field indicates whether the driver has the necessary logic
to support async page-flips via the atomic uAPI. This is leveraged by
the next commit to allow user-space to use this functionality.
All atomic drivers setting drm_mode_config.async_page_flip are updated
to also set drm_mode_config.atomic_async_page_flip_not_supported. We
will gradually check and update these drivers to properly handle
drm_crtc_state.async_flip in their atomic logic.
The goal of this negative flag is the same as
fb_modifiers_not_supported: we want to eventually get rid of all
drivers missing atomic support 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.
v2: only set the flag on atomic drivers (remove it on amdgpu DCE 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/atmel_hlcdc_dc.c | 1 +
drivers/gpu/drm/i915/display/intel_display.c | 1 +
drivers/gpu/drm/nouveau/nouveau_display.c | 1 +
drivers/gpu/drm/vc4/vc4_kms.c | 1 +
include/drm/drm_mode_config.h | 11 +++
6 files changed, 16 insertions(+)
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
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -3808,6 +3808,7 @@ static int amdgpu_dm_mode_config_init(struct
amdgpu_device *adev)
adev_to_drm(adev)->mode_config.prefer_shadow = 1;
/* indicates support for immediate flip */
adev_to_drm(adev)->mode_config.async_page_flip = true;
+ adev_to_drm(adev)->mode_config.atomic_async_page_flip_not_supported =
true;
adev_to_drm(adev)->mode_config.fb_base = adev->gmc.aper_base;
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
index f7e7f4e919c7..ffb3a2fa797f 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
@@ -639,6 +639,7 @@ static int atmel_hlcdc_dc_modeset_init(struct drm_device
*dev)
dev->mode_config.max_height = dc->desc->max_height;
dev->mode_config.funcs = _config_funcs;
dev->mode_config.async_page_flip = true;
+ dev->mode_config.atomic_async_page_flip_not_supported = true;
return 0;
}
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 40fbf8a296e2..e025b3499c9d 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -8621,6 +8621,7 @@ static void intel_mode_config_init(struct
drm_i915_private *i915)
mode_config->helper_private = _mode_config_funcs;
mode_config->async_page_flip = HAS_ASYNC_FLIPS(i915);
+ mode_config->atomic_async_page_flip_not_supported = true;
/*
* Maximum framebuffer dimensions, chosen to match
diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c
b/drivers/gpu/drm/nouveau/nouveau_display.c
index a2f5df568ca5..2b5c4f24aedd 100644
--- a/drivers/gpu/drm/nouveau/nouveau_display.c
+++ b/drivers/gpu/drm/nouveau/nouveau_display.c
@@ -699,6 +699,7 @@ nouveau_display_create(struct drm_device *dev)
dev->mode_config.async_page_flip = false;
else
dev->mode_config.async_page_flip = true;
+ dev->mode_config.atomic_async_page_flip_not_supported = true;
drm_kms_helper_poll_init(dev);
drm_kms_helper_poll_disable(dev);
diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
index 4419e810103d..3fe59c6b2cf0 100644
--- a/drivers/gpu/drm/vc4/vc4_kms.c
+++ b/drivers/gpu/drm/vc4/vc4_kms.c
@@ -1047,6 +1047,7 @@ int vc4_kms_load(struct drm_device *dev)
dev->mode_config.helper_private = _mode_config_helpers;
dev->mode_config.preferred_depth = 24;
dev->mode_config.async_page_flip = true;
+ dev->mode_config.atomic_async_page_flip_not_supported = true;
ret = vc4_ctm_obj_init(vc4);
if (ret)
diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
index 6b5e01295348..1b535d94f2f4 100644
--- a/include/drm/drm_mode_config.h
+++ b/include/drm/drm_mode_config.h
@@ -917,6 +917,17 @@ struct drm_mode_config {
*/
bool async_page_flip;
+ /**
+* @atomic_async_page_flip_not_supported:
+*
+* If true, the driver does not support async page-flips with the
+*
[PATCH v3 1/6] drm: document DRM_MODE_PAGE_FLIP_ASYNC
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/uapi/drm/drm_mode.h | 7 +++
1 file changed, 7 insertions(+)
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index fa953309d9ce..86a292c3185a 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -936,6 +936,13 @@ struct hdr_output_metadata {
};
#define DRM_MODE_PAGE_FLIP_EVENT 0x01
+/**
+ * DRM_MODE_PAGE_FLIP_ASYNC
+ *
+ * Request that the page-flip is performed as soon as possible, ie. with no
+ * delay due to waiting for vblank. This may cause tearing to be visible on
+ * the screen.
+ */
#define DRM_MODE_PAGE_FLIP_ASYNC 0x02
#define DRM_MODE_PAGE_FLIP_TARGET_ABSOLUTE 0x4
#define DRM_MODE_PAGE_FLIP_TARGET_RELATIVE 0x8
--
2.37.3
[ANNOUNCE] weston 11.0.0
This is the official release for Weston 11.0.0. Highlights for this release: - Continued work on color management infrastructure: In Weston 11, if you enable the tentative, experimental and WIP color management option, Weston will not only blend in linear light, but you can also set up a monitor ICC profile and Weston will do some kind of color mapping from sRGB to that profile. Furthermore, you can configure a monitor into HDR mode and deliver HDR characteristics from weston.ini to the monitor, but Weston will *not* produce proper HDR content yet, meaning the display is incorrect. - Various RDP improvements. - Performance improvements in the DRM backend. - Support for the wp_single_pixel_buffer_v1 protocol. - weston_buffer refactoring. - Groundwork for running multiple backends at the same time (e.g. KMS + RDP) and for multi-GPU support in the DRM backend. This is not supported yet, but may be in a future release. Breaking changes for users: - The cms-static and cms-colord plugins are now deprecated. - A number of features have been removed from desktop-shell: multiple workspaces, zoom, exposay. - wl_shell support has been removed (superseded by xdg-shell). - The fbdev backend has been removed (superseded by KMS). - weston-launch and launcher-direct have been removed (superseded by libseat). - The weston-info and weston-gears clients have been removed (weston-info is superseded by wayland-info). - The KMS max-bpc property is now set by default. If you experience black screens with (faulty) monitors, try lowering it in weston.ini. - Weston will now abort when running out of memory. Weston is not suitable for memory constrained environments. Simon Ser (1): build: bump to version 11.0.0 for the official release git tag: 11.0.0 https://gitlab.freedesktop.org/wayland/weston/-/releases/11.0.0/downloads/weston-11.0.0.tar.xz SHA256: a6138d4dc9554560ac304312df456019f4be025ec79130f05fb5f2e41c091e1d weston-11.0.0.tar.xz SHA512: 71554dc870e9c6832fdfb8f0e8dbcd7ad01c3827041c2f7fe4b7679df33b242fd00e7f0c8728d1aeecc648f8296a9d3fc502a66c91ec662f03086d9a28aab3ea weston-11.0.0.tar.xz PGP: https://gitlab.freedesktop.org/wayland/weston/-/releases/11.0.0/downloads/weston-11.0.0.tar.xz.sig
Re: Absolute mouse position
On Monday, September 19th, 2022 at 13:19, Jesse Van Gavere wrote: > Is it possible to somehow get the absolute mouse position relative to > a screen from Wayland as was possible in X11? It is something an > application of ours relies on to work properly and we’ve been trying > to see if we can make this work in both X11 and Wayland. No, this isn't possible, by design. Can you explain your use-case? Then maybe we can suggest a way to make it work on Wayland. Simon
[ANNOUNCE] weston 10.0.94
This is the RC2 release for Weston 11.0.0. Full commit history below. Alexandros Frantzis (1): libweston: Skip views without a layer assignment in output_mask calculations Derek Foreman (1): clients: Fix cursors when compositor gives wl_seat before wl_compositor Marius Vlad (1): clients/eventdemo: Remove duplicated param entries Pekka Paalanen (1): doc: remove directives deprecated in Doxygen 1.9.5 Simon Ser (1): build: bump to version 10.0.94 for the RC2 release git tag: 10.0.94 https://gitlab.freedesktop.org/wayland/weston/-/releases/10.0.94/downloads/weston-10.0.94.tar.xz SHA256: 85e6ed32f9e3425e7b4ba5e9a009d67d3b8523e1856d775af2bc93298bc02074 weston-10.0.94.tar.xz SHA512: a7da1d1bde8adff2bfb09fbe983b9b333c09e51daf6a435f3a0eb17bc9fa23fd26faeba8c7172ba34d8bad40a5ea9dbce8c589038838806b2cde2da7b39adadc weston-10.0.94.tar.xz PGP: https://gitlab.freedesktop.org/wayland/weston/-/releases/10.0.94/downloads/weston-10.0.94.tar.xz.sig
[ANNOUNCE] Weston 11.0 release schedule change
Hi, According to the previous schedule, a new Weston release is due today. However, we've decided to push back the release. We'd want to merge a few more bug fixes before the 11.0 release. The new schedule is as follows: - RC2: September 15th - First possible release: September 22nd As usual, we may do a RC3 if it turns out we need more time for fixes and reviews. Thanks, Simon
Re: [RFC v2] drm/kms: control display brightness through drm_connector properties
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: 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 > > > the backlight-devices under /sys/class/backlight. The plan is to > > > just disable the sysfs interface and keep the existing backlight-device > > > internal kernel abstraction as is, since some abstraction for (non GPU > > > native) backlight devices will be necessary regardless. > > > > > > It is unsure if we will ever be able to do this. For example 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 involves > > > e.g. the xbacklight utility. > > > > > > Even if the xbacklight utility is ported to use kms with the new connector > > > object brightness properties then this still will not work because > > > changing the properties will require drm-master rights and e.g. sway will > > > already hold those. > > > > I replied to this here in another thread 1. > > > > tl;dr I think it would be fine even for Sway-like compositors. > > Furthermore, if other compositors are like Weston in their KMS state > handling, and do not track which property has already been programmed > to KMS and which hasn't, and instead just smash all KMS properties > every update anyway (it's also great for debugging, you always have the > full state in flight), anything changed via sysfs will be immediately > reverted. > > Therefore I think there is a high probability that the external or > sysfs controls just naturally stop working anyway, even if the kernel > does not remove them first. Ah yes, that's a good point. And this wouldn't be a kernel regression, it would be user-space like Sway or Weston taking the decision to use the new uAPI in a way which breaks the sysfs interface. (User-space could also take the decision to _not_ break the sysfs interface, by implementing a simple "dirty" flag.)
Re: [RFC v2] drm/kms: control display brightness through drm_connector properties
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 > the backlight-devices under /sys/class/backlight. The plan is to > just disable the sysfs interface and keep the existing backlight-device > internal kernel abstraction as is, since some abstraction for (non GPU > native) backlight devices will be necessary regardless. > > It is unsure if we will ever be able to do this. For example 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 involves > e.g. the xbacklight utility. > > Even if the xbacklight utility is ported to use kms with the new connector > object brightness properties then this still will not work because > changing the properties will require drm-master rights and e.g. sway will > already hold those. I replied to this here in another thread [1]. tl;dr I think it would be fine even for Sway-like compositors. (Also note the utilities used right now are not xbacklight, but brightnessctl/light/brillo/etc [2]) [1]: https://lore.kernel.org/dri-devel/bZJU9OkYWFyaLHVa4XUE4d5iBTPFXBRyPe1wMd_ztKh5VBMu-EDNGoUDpvwtFn_u9-JMvN8QmIZVS3pzMZM_hZTkTCA9gOBnCGXc5HFmsnc=@emersion.fr/ [2]: https://github.com/swaywm/sway/wiki#xbacklight > The drm_connector brightness properties > === > > The new uAPI for this consists of 2 properties: > > 1. "display brightness": rw 0-int32_max property controlling the brightness > setting > of the connected display. The actual maximum of this will be less then > int32_max and is given in "display brightness max". > > Unlike the /sys/class/backlight/foo/brightness this brightness property > has a clear definition for the value 0. The kernel must ensure that 0 > means minimum brightness (so 0 should never turn the backlight off). > If necessary the kernel must enforce a minimum value by adding > an offset to the value seen in the property to ensure this behavior. > > For example if necessary the driver must clamp 0-255 to 10-255, which then > becomes 0-245 on the brightness property, adding 10 internally to writes > done to the brightness property. This adding of an extra offset when > necessary must only be done on the brightness property, > the /sys/class/backlight interface should be left unchanged to not break > userspace which may rely on 0 = off on some systems. > > Note amdgpu already does something like this even for /sys/class/backlight, > see the use of AMDGPU_DM_DEFAULT_MIN_BACKLIGHT in amdgpu. > > Also whenever possible the kernel must ensure that the brightness range > is in perceived brightness, but this cannot always be guaranteed. > > > 2. "display brightness max": ro 0-int32_max property giving the actual maximum > of the display's brightness setting. This will report 0 when brightness > control is not available. > > The value of "display brightness max" may change at runtime, either by > a legacy drivers/platform/x86 backlight driver loading after the drm > driver has loaded; or when plugging in a monitor which allows brightness > control over DDC/CI. In both these cases the max value will change from 0 > to the actual max value, indicating backlight control has become available > on this connector. The kernel will need to ensure that a hotplug uevent is sent to user-space at this point. Otherwise user-space has no way to figure out that the prop has changed. Overall this all looks very solid to me! Simon
Re: Meeting (BOF) at Plumbers Dublin to discuss backlight brightness as connector object property RFC?
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 involves > e.g. the xbacklight utility. > > Even if the xbacklight utility is ported to use kms with the new connector > object brightness properties then this still will not work because > changing the properties will require drm-master rights and e.g. sway will > already hold those." I don't think this is a good argument. Sway (which I'm a maintainer of) can add a command to change the backlight, and then users can bind their keybinding to that command. This is not very different from e.g. a keybind to switch on/off a monitor. We can also standardize a protocol to change the backlight across all non-fully-integrated desktop environments (would be a simple addition to output-power-management [1]), so that a single tool can work for multiple compositors. Simon [1]: https://gitlab.freedesktop.org/wlroots/wlr-protocols/-/issues/114
[ANNOUNCE] weston 10.0.93
This is the RC1 release for Weston 11.0.0. Full commit history below. Marius Vlad (2): libweston/backend-x11: Tracking previous events over multiple calls libweston/input: Assert if we're still having a notify listener installed Michael Olbrich (1): backend-drm: fix plane sorting Simon Ser (1): build: bump to version 10.0.93 for the RC1 release git tag: 10.0.93 https://gitlab.freedesktop.org/wayland/weston/-/releases/10.0.93/downloads/weston-10.0.93.tar.xz SHA256: 25c60e702b610e8c2132bb75eb19b013741aedaf58c75b6fda6b32969e1e5ff4 weston-10.0.93.tar.xz SHA512: 9267e60953fe593c99fd56de97bd099aaf2b050b7f9832307b9245bda137eca556919857d869559f379e5f5d475d5146b4930e3fc05998a833d0ad9fc6860c44 weston-10.0.93.tar.xz PGP: https://gitlab.freedesktop.org/wayland/weston/-/releases/10.0.93/downloads/weston-10.0.93.tar.xz.sig
Re: Retrieving monitor connection information
On Thursday, September 1st, 2022 at 13:36, Andrew Marshall
wrote:
> On Thu, 1 Sept 2022 at 12:01, Mikhail Gusarov wrote:
>
> >
> > In the described use-case compositor is most likely known and fixed.
>
> Yes, however can I guarantee that the output names will remain the same in
> the following scenarios -
>
> * Rebooting of the system
> * Disconnection and reconnection of display devices
>
> ?
No. KMS names ("DP-2") cannot be used for a reliable identifier.
wl_output.name specification states:
The name is not guaranteed to be persistent across sessions, thus cannot
be used to reliably identify an output in e.g. configuration files.
See the discussion at [1] for more info. To fix this, we'd need a new
wl_output event and a new KMS property.
[1]:
https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/109#note_813539
Re: Retrieving monitor connection information
On Thursday, September 1st, 2022 at 12:23, Andrew Marshall wrote: > > Why do you need to fetch this information? What's your use-case? > > A medical device outputs a camera display to each of four monitors, > attached to display port connectors on the graphics card. There is a > 1:1 relationship between camera outputs and displays, and a UI allows > assigning a specific camera output to a specific display port output. It seems like wl_output.name would be useful for this purpose. wl_output.description contains a human-readable string which can be included in the UI. Note, do not assume that wl_output.name will have any defined format. Some compositors will send e.g. "DP-2", some will send an arbitrary ID such as "CD6767WZ", etc.
Re: Retrieving monitor connection information
Hi, On Thursday, September 1st, 2022 at 11:23, Andrew Marshall wrote: > I have an application that requires the equivalent of the > `ConnectorNumber` and `ConnectorType` properties that are available > in the RandR protocol in X11 (see > https://github.com/freedesktop/xorg-xorgproto/blob/master/randrproto.txt) There is no equivalent to X11's RandR extension in Wayland. Why do you need to fetch this information? What's your use-case? Thanks, Simon
Re: [PATCH v2 4/6] drm: allow DRM_MODE_PAGE_FLIP_ASYNC for atomic commits
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_output_metadata {
> > * Request that the page-flip is performed as soon as possible, ie. with no
> > * delay due to waiting for vblank. This may cause tearing to be visible on
> > * the screen.
> > + *
> > + * 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 regular
> > page-flip.
> > */
> > #define DRM_MODE_PAGE_FLIP_ASYNC 0x02
> > #define DRM_MODE_PAGE_FLIP_TARGET_ABSOLUTE 0x4
>
> Hi Simon,
>
> recalling what Ville explained that enabling async flips might require
> one more sync flip first, how is that supposed to work?
>
> A TEST_ONLY commit is not allowed to change hardware state, and a
> failing real commit is not allowed to change hardware state either
> (right?), therefore a failing async flip cannot prepare the next flip
> to be async, meaning async will never work.
I'd blame it on bad hw, and make it one special quirk in the driver,
just like it does now.
Ville, thoughts?
[PATCH v2 6/6] amd/display: indicate support for atomic async page-flips on DC
amdgpu_dm_commit_planes() already sets the flip_immediate flag for async page-flips. This flag is used to set the UNP_FLIP_CONTROL register. Thus, no additional change is required to handle async page-flips with the atomic uAPI. v2: make it clear this commit is about DC and not only DCN 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/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/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c index c9195e7bb649..7f96d81f4e0d 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -3804,7 +3804,6 @@ static int amdgpu_dm_mode_config_init(struct amdgpu_device *adev) adev_to_drm(adev)->mode_config.prefer_shadow = 0; /* indicates support for immediate flip */ adev_to_drm(adev)->mode_config.async_page_flip = true; - adev_to_drm(adev)->mode_config.atomic_async_page_flip_not_supported = true; adev_to_drm(adev)->mode_config.fb_base = adev->gmc.aper_base; -- 2.37.2
[PATCH v2 5/6] drm: introduce DRM_CAP_ATOMIC_ASYNC_PAGE_FLIP
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: 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/drm_ioctl.c | 5 +
include/uapi/drm/drm.h | 10 +-
2 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index ca2a6e6101dc..5b1591e2b46c 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -302,6 +302,11 @@ static int drm_getcap(struct drm_device *dev, void *data,
struct drm_file *file_
case DRM_CAP_CRTC_IN_VBLANK_EVENT:
req->value = 1;
break;
+ case DRM_CAP_ATOMIC_ASYNC_PAGE_FLIP:
+ req->value = drm_core_check_feature(dev, DRIVER_ATOMIC) &&
+dev->mode_config.async_page_flip &&
+
!dev->mode_config.atomic_async_page_flip_not_supported;
+ break;
default:
return -EINVAL;
}
diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index 642808520d92..b1962628ecda 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h
@@ -706,7 +706,8 @@ struct drm_gem_open {
/**
* DRM_CAP_ASYNC_PAGE_FLIP
*
- * If set to 1, the driver supports _MODE_PAGE_FLIP_ASYNC.
+ * If set to 1, the driver supports _MODE_PAGE_FLIP_ASYNC for legacy
+ * page-flips.
*/
#define DRM_CAP_ASYNC_PAGE_FLIP0x7
/**
@@ -767,6 +768,13 @@ struct drm_gem_open {
* Documentation/gpu/drm-mm.rst, section "DRM Sync Objects".
*/
#define DRM_CAP_SYNCOBJ_TIMELINE 0x14
+/**
+ * DRM_CAP_ATOMIC_ASYNC_PAGE_FLIP
+ *
+ * If set to 1, the driver supports _MODE_PAGE_FLIP_ASYNC for atomic
+ * commits.
+ */
+#define DRM_CAP_ATOMIC_ASYNC_PAGE_FLIP 0x15
/* DRM_IOCTL_GET_CAP ioctl argument type */
struct drm_get_cap {
--
2.37.2
[PATCH v2 3/6] drm: introduce drm_mode_config.atomic_async_page_flip_not_supported
This new field indicates whether the driver has the necessary logic
to support async page-flips via the atomic uAPI. This is leveraged by
the next commit to allow user-space to use this functionality.
All atomic drivers setting drm_mode_config.async_page_flip are updated
to also set drm_mode_config.atomic_async_page_flip_not_supported. We
will gradually check and update these drivers to properly handle
drm_crtc_state.async_flip in their atomic logic.
The goal of this negative flag is the same as
fb_modifiers_not_supported: we want to eventually get rid of all
drivers missing atomic support 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.
v2: only set the flag on atomic drivers (remove it on amdgpu DCE 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 | 1 +
drivers/gpu/drm/i915/display/intel_display.c | 1 +
drivers/gpu/drm/nouveau/nouveau_display.c | 1 +
drivers/gpu/drm/vc4/vc4_kms.c | 1 +
include/drm/drm_mode_config.h | 11 +++
6 files changed, 16 insertions(+)
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 7f96d81f4e0d..c9195e7bb649 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -3804,6 +3804,7 @@ static int amdgpu_dm_mode_config_init(struct
amdgpu_device *adev)
adev_to_drm(adev)->mode_config.prefer_shadow = 0;
/* indicates support for immediate flip */
adev_to_drm(adev)->mode_config.async_page_flip = true;
+ adev_to_drm(adev)->mode_config.atomic_async_page_flip_not_supported =
true;
adev_to_drm(adev)->mode_config.fb_base = adev->gmc.aper_base;
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
index f7e7f4e919c7..ffb3a2fa797f 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
@@ -639,6 +639,7 @@ static int atmel_hlcdc_dc_modeset_init(struct drm_device
*dev)
dev->mode_config.max_height = dc->desc->max_height;
dev->mode_config.funcs = _config_funcs;
dev->mode_config.async_page_flip = true;
+ dev->mode_config.atomic_async_page_flip_not_supported = true;
return 0;
}
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 2a45a25e42fb..265492e6c135 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -8622,6 +8622,7 @@ static void intel_mode_config_init(struct
drm_i915_private *i915)
mode_config->helper_private = _mode_config_funcs;
mode_config->async_page_flip = HAS_ASYNC_FLIPS(i915);
+ mode_config->atomic_async_page_flip_not_supported = true;
/*
* Maximum framebuffer dimensions, chosen to match
diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c
b/drivers/gpu/drm/nouveau/nouveau_display.c
index a2f5df568ca5..2b5c4f24aedd 100644
--- a/drivers/gpu/drm/nouveau/nouveau_display.c
+++ b/drivers/gpu/drm/nouveau/nouveau_display.c
@@ -699,6 +699,7 @@ nouveau_display_create(struct drm_device *dev)
dev->mode_config.async_page_flip = false;
else
dev->mode_config.async_page_flip = true;
+ dev->mode_config.atomic_async_page_flip_not_supported = true;
drm_kms_helper_poll_init(dev);
drm_kms_helper_poll_disable(dev);
diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
index 4419e810103d..3fe59c6b2cf0 100644
--- a/drivers/gpu/drm/vc4/vc4_kms.c
+++ b/drivers/gpu/drm/vc4/vc4_kms.c
@@ -1047,6 +1047,7 @@ int vc4_kms_load(struct drm_device *dev)
dev->mode_config.helper_private = _mode_config_helpers;
dev->mode_config.preferred_depth = 24;
dev->mode_config.async_page_flip = true;
+ dev->mode_config.atomic_async_page_flip_not_supported = true;
ret = vc4_ctm_obj_init(vc4);
if (ret)
diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
index 6b5e01295348..1b535d94f2f4 100644
--- a/include/drm/drm_mode_config.h
+++ b/include/drm/drm_mode_config.h
@@ -917,6 +917,17 @@ struct drm_mode_config {
*/
bool async_page_flip;
+ /**
+* @atomic_async_page_flip_not_supported:
+*
+* If true, the driver does not support async page-flips with the
+* atomic uAPI. This is on
[PATCH v2 4/6] drm: allow DRM_MODE_PAGE_FLIP_ASYNC for atomic commits
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.
Document that drivers will reject atomic commits if an async
flip isn't possible. This allows user-space to fall back to
something 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 Vetter
Cc: Joshua Ashton
Cc: Melissa Wen
Cc: Alex Deucher
Cc: Harry Wentland
Cc: Nicholas Kazlauskas
Cc: Ville Syrjälä
---
drivers/gpu/drm/drm_atomic_uapi.c | 28 +---
include/uapi/drm/drm_mode.h | 4
2 files changed, 29 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index 79730fa1dd8e..ee24ed7e2edb 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -1278,6 +1278,18 @@ static void complete_signaling(struct drm_device *dev,
kfree(fence_state);
}
+static void
+set_async_flip(struct drm_atomic_state *state)
+{
+ struct drm_crtc *crtc;
+ struct drm_crtc_state *crtc_state;
+ int i;
+
+ for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
+ crtc_state->async_flip = true;
+ }
+}
+
int drm_mode_atomic_ioctl(struct drm_device *dev,
void *data, struct drm_file *file_priv)
{
@@ -1318,9 +1330,16 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
}
if (arg->flags & DRM_MODE_PAGE_FLIP_ASYNC) {
- drm_dbg_atomic(dev,
- "commit failed: invalid flag
DRM_MODE_PAGE_FLIP_ASYNC\n");
- return -EINVAL;
+ if (!dev->mode_config.async_page_flip) {
+ drm_dbg_atomic(dev,
+ "commit failed: DRM_MODE_PAGE_FLIP_ASYNC
not supported\n");
+ return -EINVAL;
+ }
+ if (dev->mode_config.atomic_async_page_flip_not_supported) {
+ drm_dbg_atomic(dev,
+ "commit failed: DRM_MODE_PAGE_FLIP_ASYNC
not supported with atomic\n");
+ return -EINVAL;
+ }
}
/* can't test and expect an event at the same time. */
@@ -1418,6 +1437,9 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
if (ret)
goto out;
+ if (arg->flags & DRM_MODE_PAGE_FLIP_ASYNC)
+ set_async_flip(state);
+
if (arg->flags & DRM_MODE_ATOMIC_TEST_ONLY) {
ret = drm_atomic_check_only(state);
} else if (arg->flags & DRM_MODE_ATOMIC_NONBLOCK) {
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_output_metadata {
* Request that the page-flip is performed as soon as possible, ie. with no
* delay due to waiting for vblank. This may cause tearing to be visible on
* the screen.
+ *
+ * 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 regular page-flip.
*/
#define DRM_MODE_PAGE_FLIP_ASYNC 0x02
#define DRM_MODE_PAGE_FLIP_TARGET_ABSOLUTE 0x4
--
2.37.2
[PATCH v2 2/6] drm: document DRM_MODE_PAGE_FLIP_ASYNC
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 insertions(+)
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index fa953309d9ce..86a292c3185a 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -936,6 +936,13 @@ struct hdr_output_metadata {
};
#define DRM_MODE_PAGE_FLIP_EVENT 0x01
+/**
+ * DRM_MODE_PAGE_FLIP_ASYNC
+ *
+ * Request that the page-flip is performed as soon as possible, ie. with no
+ * delay due to waiting for vblank. This may cause tearing to be visible on
+ * the screen.
+ */
#define DRM_MODE_PAGE_FLIP_ASYNC 0x02
#define DRM_MODE_PAGE_FLIP_TARGET_ABSOLUTE 0x4
#define DRM_MODE_PAGE_FLIP_TARGET_RELATIVE 0x8
--
2.37.2
[PATCH v2 1/6] amd/display: only accept async flips for fast updates
Up until now, amdgpu was silently degrading to vsync when
user-space requested an async flip but the hardware didn't support
it.
The hardware doesn't support immediate flips when the update changes
the FB pitch, the DCC state, the rotation, enables or disables CRTCs
or planes, etc. This is reflected in the dm_crtc_state.update_type
field: UPDATE_TYPE_FAST means that immediate flip is supported.
Silently degrading async flips to vsync is not the expected behavior
from a uAPI point-of-view. Xorg expects async flips to fail if
unsupported, to be able to fall back to a blit. i915 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
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 8
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crtc.c | 10 ++
2 files changed, 18 insertions(+)
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 9ab01c58bedb..7f96d81f4e0d 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -7613,7 +7613,15 @@ static void amdgpu_dm_commit_planes(struct
drm_atomic_state *state,
/*
* Only allow immediate flips for fast updates that don't
* change FB pitch, DCC state, rotation or mirroing.
+*
+* dm_crtc_helper_atomic_check() only accepts async flips with
+* fast updates.
*/
+ if (crtc->state->async_flip &&
+ acrtc_state->update_type != UPDATE_TYPE_FAST)
+ drm_warn_once(state->dev,
+ "[PLANE:%d:%s] async flip with non-fast
update\n",
+ plane->base.id, plane->name);
bundle->flip_addrs[planes_count].flip_immediate =
crtc->state->async_flip &&
acrtc_state->update_type == UPDATE_TYPE_FAST;
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crtc.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crtc.c
index 594fe8a4d02b..97ead857f507 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crtc.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crtc.c
@@ -388,6 +388,16 @@ static int dm_crtc_helper_atomic_check(struct drm_crtc
*crtc,
return -EINVAL;
}
+ /* Only allow async flips for fast updates that don't change the FB
+* pitch, the DCC state, rotation, etc. */
+ if (crtc_state->async_flip &&
+ dm_crtc_state->update_type != UPDATE_TYPE_FAST) {
+ drm_dbg_atomic(crtc->dev,
+ "[CRTC:%d:%s] async flips are only supported for
fast updates\n",
+ crtc->base.id, crtc->name);
+ return -EINVAL;
+ }
+
/* In some use cases, like reset, no stream is attached */
if (!dm_crtc_state->stream)
return 0;
--
2.37.2
[PATCH v2 0/6] Add support for atomic async page-flips
This series adds support for DRM_MODE_PAGE_FLIP_ASYNC for atomic commits, aka. "immediate flip" (which might result in tearing). The feature was only available via the legacy uAPI, however for gaming use-cases it may be desirable to enable it via the atomic uAPI too. - 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): amd/display: only accept async flips for fast updates drm: document DRM_MODE_PAGE_FLIP_ASYNC drm: introduce drm_mode_config.atomic_async_page_flip_not_supported drm: allow DRM_MODE_PAGE_FLIP_ASYNC for atomic commits drm: introduce DRM_CAP_ATOMIC_ASYNC_PAGE_FLIP amd/display: indicate support for atomic async page-flips on DC .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 8 ++ .../amd/display/amdgpu_dm/amdgpu_dm_crtc.c| 10 +++ drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 1 + drivers/gpu/drm/drm_atomic_uapi.c | 28 +-- drivers/gpu/drm/drm_ioctl.c | 5 drivers/gpu/drm/i915/display/intel_display.c | 1 + drivers/gpu/drm/nouveau/nouveau_display.c | 1 + drivers/gpu/drm/vc4/vc4_kms.c | 1 + include/drm/drm_mode_config.h | 11 include/uapi/drm/drm.h| 10 ++- include/uapi/drm/drm_mode.h | 11 11 files changed, 83 insertions(+), 4 deletions(-) -- 2.37.2
[ANNOUNCE] weston 10.0.92
This is the beta release for Weston 11.0.0. Full commit history below. Derek Foreman (3): Revert "clients/window: Fix animated cursors" Revert "clients/window: atomically update pointer cursor" clients: Set the hotspot with attach if we already have a valid cursor Erik Kurzinger (1): clients/simple-egl: call eglSwapInterval after eglMakeCurrent Marius Vlad (1): simple-egl: Update buffer_size dimensions when starting as maximized Simon Ser (1): build: bump to version 10.0.92 for the beta release git tag: 10.0.92 https://gitlab.freedesktop.org/wayland/weston/-/releases/10.0.92/downloads/weston-10.0.92.tar.xz SHA256: cd6cacc993df71fe377d6abf4387a9dbe956e49165818293fbdc6ec38a2f171c weston-10.0.92.tar.xz SHA512: 13f600f99036f10670da4de1c905ad0c862a7c2907a66cb761c35c004db428ae8ca98b0ad47b4dda1c5bff868a21b6601b82dd9fca401e4471aca57be1f8c05c weston-10.0.92.tar.xz PGP: https://gitlab.freedesktop.org/wayland/weston/-/releases/10.0.92/downloads/weston-10.0.92.tar.xz.sig
[ANNOUNCE] weston 10.0.91
ests/client-helper: use image-iter.h tests: pass image_header to image_check_get_roi() tests/client-helper: use image_header_from() more tests/yuv-buffer: use image-iter.h for rgb_image tests/internal-screenshot: use image-iter.h tests/alpha-blend: use image-iter.h gl-renderer: call it view_alpha in frag gl-renderer: move undo-premult to color_pipeline() gl-renderer: simplify main() in frag tests/alpha-blending: move unpremult to color_util tests: change rgb_diff_stat printing tests/color_util: constify *_stat_update() tests: add scalar_stat dumps tests/color_util: make rgb_diff_stat pos explicit tests: add rgb_diff_stat dumps tests/color_util: doc rgb_diff_stat and scalar_stat tests/alpha-blending: replace compare_float() with rgb_diff_stat tests/alpha-blending: use two_norm tolerance tests/color-icc-output: compare_float() to rgb_diff_stat tests/color-icc-output: use two-norm tolerance tests/color_util: expose color_float_apply_curve() tests/color-icc-output: add blending test compositor: deprecate cms-static and cms-colord plugins compositor: fix shutdown when xwayland failed to start Revert "xwayland: Don't dup() displayfd pipe" xwayland: move config reading up xwayland: do not weston_log() after fork() shared: fcntl uses int, not long shared: introduce os_fd_clear_cloexec() xwayland: do not snprintf() after fork() xwayland: use pipe2() xwayland: use execv() xwayland: do not use setenv() after fork() xwayland: do not check execve() return value README: drop note about a cairo build option ivi-shell: replace MEM_ALLOC() with mostly xcalloc() shared: rewrite fail_on_null() as abort_oom_if_null() clients/simple-touch: use xzalloc() for buffer shared/xalloc.h: do not rely on zalloc() README: establish no-malloc-failures policy pixman-renderer: let pixman allocate shadow backend-headless: let pixman allocate the image backend-headless: choose pixel format by drm_fourcc backend-wayland: restructure wayland_output_resize_surface() backend-x11: use shorthand for current_mode fullscreen-shell: fix black output libweston: add pixel_format_get_info_by_pixman() screen-share: use read_format consistently libweston: change read_format to struct pixel_format_info gl-renderer: use pixel_format_info in read_pixels backend-wayland: fix pixman buffer size Philipp Zabel (9): libweston: add opaque backend_id pointer to struct weston_head backend-drm: prepare virtual output API for heterogeneous outputs backend-drm: check that outputs and heads are in fact ours backend-headless: check that outputs and heads are in fact ours backend-rdp: check that outputs and heads are in fact ours backend-wayland: check that outputs and heads are in fact ours backend-x11: check that outputs and heads are in fact ours libweston: consolidate weston_compositor_create_output(_with_head) compositor: stop creating outputs without head Robert Mader (19): libweston/compositor: Cache buffer damage for synced subsurfaces tests: Add test for synced subsurfaces and buffer damage libweston/compositor: Do not map subsurfaces without buffer tests: Add test for subsurfaces mapping hierachies clients/simple-dmabuf-*: Increase buffer limit to four pixel-formats: Add support for 64bbp float RGB formats clients/simple-dmabuf-feedback: Add fallback print method for unknown formats backend-drm: Add failure reasons for failing gbm_bo_import clients/simple-dmabuf-feedback: use time instead of redraws libweston/linux-dmabuf: create surface feedback on demand libweston: Silence compiler warning rdp: Silence compiler warning clients/simple-dmabuf-feedback: Support multi-tranche feedbacks clients/simple-dmabuf-*: Use gbm_bo_create_with_modifiers2 clients/simple-egl: Use INT32_MAX for opaque region clients/simple-egl: Rename buffer_size to buffer_bpp clients/simple-egl: Rename geometry to buffer_size clients/simple-egl: Handle buffer scale and transform clients/simple-egl: Fix angle reset on benchmark interval Simon Ser (6): build: re-open main for regular development clients: drop weston-info build: add Meson fallback for wayland-protocols clients/simple-dmabuf-feedback: use presentation-time clients/simple-dmabuf-feedback: prettify output build: bump to version 10.0.91 for the alpha release Sören Meier (1): libbacklight: Fix backlight never gets initialized Takuro Ashie (1): Don't send compositor's global key bindings to the input method Thomas Petazzoni (1): compositor/main.c: use pixman renderer by default when gl-renderer not enabled
Re: Position set/get prototype template
Hi, As we already tried to explain numerous times in the previous thread: no, we are not adding requests and events to set/get the window position. If you are interested in fixing an app which doesn't work on Wayland because of this omission, please explain your use-case, and we can discuss solutions. If you are not interested in explaining the use-cases, and are just interested in blindly adding new features: sorry, but this isn't how we want to approach things. Thanks, Simon
Re: Window monitor-selection under Wayland
Hi, The xdg-session-management protocol extension [1] should help with that. Thanks, Simon [1]: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/18
Re: How to test whether a buffer is in linear format
On Saturday, August 6th, 2022 at 21:56, Hoosier, Matt wrote: > Any idea what’s up with some compositors adding code to infer > DRM_FORMAT_MOD_LINEAR semantics when the buffer’s modifiers are set > to 0? What does that mean? A buffer only has a single modifier, and LINEAR == 0. > Wlroots, for example, added this as a “safety net for drm drivers not > announcing modifiers”. > > https://source.puri.sm/Librem5/wlroots/-/merge_requests/63 This is not upstream wlroots. This change doesn't make sense to me at all. Either a driver supports modifiers and advertises support for it, either it doesn't and gbm_surface_create_with_modifiers fails. At any rate, forcing LINEAR in this code-path doesn't make sense.
