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
S
On Friday, September 9th, 2022 at 12:23, Hans de Goede
wrote:
> "people using
> non fully integrated desktop environments like e.g. sway often use custom
> scripts binded to hotkeys to get functionality like the brightness
> up/down keyboard hotkeys changing the brightness. This typically involv
On Friday, September 9th, 2022 at 12:12, Hans de Goede
wrote:
> Phase 3: Deprecate /sys/class/backlight uAPI
>
>
> Once most userspace has moved over to using the new drm_connector
> brightness props, a Kconfig option can be added to stop exporting
>
On Friday, September 9th, 2022 at 15:53, Pekka Paalanen
wrote:
> On Fri, 09 Sep 2022 13:39:37 +
> Simon Ser cont...@emersion.fr wrote:
>
> > On Friday, September 9th, 2022 at 12:12, Hans de Goede hdego...@redhat.com
> > wrote:
> >
> > > Phase 3:
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, w
):
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
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 m
. 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
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
nd
on radeon)
Signed-off-by: Simon Ser
Reviewed-by: André Almeida
Reviewed-by: Alex Deucher
Cc: Daniel Vetter
Cc: Joshua Ashton
Cc: Melissa Wen
Cc: Harry Wentland
Cc: Nicholas Kazlauskas
Cc: Ville Syrjälä
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 1 +
drivers/gpu/drm/atmel-
15 already behaves
this way.
This patch aligns amdgpu with uAPI expectations and returns a failure
when an async flip is not possible.
v2: new patch
Signed-off-by: Simon Ser
Reviewed-by: André Almeida
Reviewed-by: Alex Deucher
Cc: Joshua Ashton
Cc: Melissa Wen
Cc: Harry Wentland
Cc: Nicholas
ion about Intel hardware,
add R-b tags.
Tested on an AMD Picasso iGPU (Simon) and an AMD Vangogh GPU (André).
Simon Ser (6):
drm: document DRM_MODE_PAGE_FLIP_ASYNC
amd/display: only accept async flips for fast updates
drm: introduce drm_mode_config.atomic_async_page_flip_not_support
This 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
Ville, Pekka)
Signed-off-by: Simon Ser
Co-developed-by: André Almeida
Signed-off-by: André Almeida
Reviewed-by: André Almeida
Reviewed-by: Alex Deucher
Cc: Daniel Vetter
Cc: Joshua Ashton
Cc: Melissa Wen
Cc: Harry Wentland
Cc: Nicholas Kazlauskas
Cc: Ville Syrjälä
---
drivers/gp
-off-by: Simon Ser
Reviewed-by: André Almeida
Reviewed-by: Alex Deucher
Cc: Joshua Ashton
Cc: Melissa Wen
Cc: Harry Wentland
Cc: Nicholas Kazlauskas
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm
On Friday, September 30th, 2022 at 15:53, Ville Syrjälä
wrote:
> > diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > index 44235345fd57..7500e82cf06a 100644
> > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > +
On Friday, September 30th, 2022 at 16:44, Ville Syrjälä
wrote:
> On Fri, Sep 30, 2022 at 04:20:29PM +0200, Sebastian Wick wrote:
>
> > On Fri, Sep 30, 2022 at 9:40 AM Pekka Paalanen ppaala...@gmail.com wrote:
> >
> > > On Thu, 29 Sep 2022 20:06:50 +0200
> > > Sebastian Wick sebastian.w...@redh
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
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
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 wil
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 S
)
- 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
> > > 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
> >
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 f
edesktop.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(-)
dif
Ville, any news on this?
Glad I could help Weston these last few years, and thank you for
stepping up Marius!
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 implemen
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 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 exp
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 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 re
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 f
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 .ed
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 releas
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
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.
hen 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=de
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
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
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: 1540af1ea698a471c2d8e9d288332c7e0fd360c8f1d12936ebb7e7cbc24
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 a
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.
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
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
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
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
> >
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
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
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 (inpu
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
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 LU
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 regul
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, an
(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
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
>
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
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 lib
> 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
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 mod
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:
> >
For the uAPI:
Acked-by: Simon Ser
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
e 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/
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 pe
Reviewed-by: Simon Ser
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?
With that fixed:
Reviewed-by: Simon Ser
On Monday, October 23rd, 2023 at 10:25, Simon Ser wrote:
> > > > > > > > > > +An atomic commit with the flag DRM_MODE_PAGE_FLIP_ASYNC is
> > > > > > > > > > allowed to
> > > > > > > > > > +effective
On Monday, November 13th, 2023 at 10:38, Pekka Paalanen
wrote:
> On Mon, 13 Nov 2023 09:18:39 +
> Simon Ser cont...@emersion.fr wrote:
>
> > On Monday, October 23rd, 2023 at 10:25, Simon Ser cont...@emersion.fr wrote:
> >
> > > > > > >
On Monday, November 13th, 2023 at 10:41, Michel Dänzer
wrote:
> On 11/13/23 10:18, Simon Ser wrote:
>
> > On Monday, October 23rd, 2023 at 10:25, Simon Ser cont...@emersion.fr wrote:
> >
> > > > > > > > > > > > +An atomic commit with the
On Monday, November 13th, 2023 at 11:15, Pekka Paalanen
wrote:
>
>
> On Mon, 13 Nov 2023 09:44:15 +0000
> Simon Ser cont...@emersion.fr wrote:
>
> > On Monday, November 13th, 2023 at 10:38, Pekka Paalanen ppaala...@gmail.com
> > wrote:
> >
> &g
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-utili
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 y
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
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
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 th
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, b
I personally find the current code more readable.
On Tuesday, March 12th, 2024 at 16:02, Pekka Paalanen
wrote:
> This list here is the list of all values the enum could take, right?
> Should it not be just the one value it's going to have? It'll never
> change, and it can never be changed.
Listing all possible values is how other properties be
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 re
c: 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 interna
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
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
_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
Commit history since RC1 below.
Hugo Osvaldo Barrera (1):
protocol: clarify divergence in compositor behaviour
Si
On Friday, May 31st, 2024 at 15:26, Hoosier, Matt
wrote:
> Drew or Simon, does either of
> https://github.com/swaywm/wlroots/blob/master/protocol/wlr-screencopy-unstable-v1.xml
> or
> https://github.com/swaywm/wlroots/blob/master/protocol/wlr-export-dmabuf-unstable-v1.xml
> strike you as a g
On Friday, May 31st, 2024 at 16:39, Andri Yngvason wrote:
> Hi Matt,
>
> fös., 31. maí 2024 kl. 13:26 skrifaði Hoosier, Matt matt.hoos...@garmin.com:
>
> > Hi,
> >
> > Yeah. I agree that although I can prototype something quick and dirty here
> > as a change to weston_output_capture_v1, it's
On Friday, May 31st, 2024 at 16:45, Simon Ser wrote:
> > See:
> > https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/124
> >
> > > My goal is to implement this screen capture with a guarantee that the
> > > copy comes from a KMS wri
dd support for the HDMI Audio Data Block
cta: HDMI Audio: Add a failure when NonMixed is supported without MS
build: build edid-decode as subproject
Simon Ser (22):
build: bump version to 0.2.0-dev
build: fix invalid library version
readme: add IRC channel
test/data
This is a bugfix release for Wayland 1.23.
Joaquim Monteiro (1):
meson: Fix use of install_data() without specifying install_dir
Kirill Primak (1):
Put WL_DEPRECATED in front of the function declarations
Sebastian Wick (1):
client: Handle proxies with no queue
Simon Ser (4
I think this can be folded into "drm/colorop: Add atomic state print for
drm_colorop".
On Thursday, October 3rd, 2024 at 22:01, Harry Wentland
wrote:
> From: Alex Hung
>
> It is to be used to enable HDR by allowing userpace to create and pass
> 3D LUTs to kernel and hardware.
>
> 1. new drm_colorop_type: DRM_COLOROP_3D_LUT.
> 2. 3D LUT modes define hardware capabilities to user
Would be nice to have user-space uAPI docs for the colorop properties.
Just like we have for other KMS object types:
https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html#standard-connector-properties
Internal kernel docs aren't great for user-space developers, because
user-space developers have n
Shouldn't this patch come before the others, otherwise we're exposing
unconditionally color OP uAPI to user-space in-between the first patch
and this one?
Usually we try to not have a broken kernel in intermediate commits. It's
important for bisecting.
On Sunday, October 13th, 2024 at 17:19, Simon Ser wrote:
> Would be nice to have user-space uAPI docs for the colorop properties.
> Just like we have for other KMS object types:
> https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html#standard-connector-properties
Ah, I suppose s
On Friday, December 20th, 2024 at 10:46, Campbell Barton
wrote:
> > Instead, we've standardized a protocol to set semantic cursor shapes:
> > https://gitlab.freedesktop.org/wayland/wayland-protocols/-/tree/main/staging/cursor-shape?ref_type=heads
> >
> > Does that help?
>
> It's not a solution
Hi!
This has been discussed before, with an XCursor configuration protocol
proposal:
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/21
However that approach turned out to be quite complex, and a bit
backwards (back-and-forth and duplicated work in compositors and client
On Wednesday, January 22nd, 2025 at 20:48, Harry Wentland
wrote:
> On 2025-01-13 13:23, Simon Ser wrote:
>
> > > v4:
> > > - Don't block setting of COLOR_RANGE and COLOR_ENCODING
> > > when client cap is set
> >
> > Can you remind me why the
On Wednesday, January 22nd, 2025 at 22:05, Harry Wentland
wrote:
> On 2025-01-15 02:56, Simon Ser wrote:
>
> > Is this "ignore" something we could do at the core DRM level, instead
> > of doing it in all drivers? e.g. by silently ignoring user-space requests
>
On Thursday, January 23rd, 2025 at 21:06, Harry Wentland
wrote:
> On 2025-01-15 03:00, Simon Ser wrote:
>
> > Is this 125 magic number something we can expect other hardware to
> > implement as well?
>
> It's based on MS's CCCS interpretation of 80 nits as 1.
401 - 500 of 567 matches
Mail list logo
