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
S
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
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
I personally find the current code more readable.
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,
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
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
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 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
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
On Monday, November 13th, 2023 at 11:15, Pekka Paalanen
wrote:
>
>
> On Mon, 13 Nov 2023 09:44:15 +0000
> Simon Ser cont...@emersion.fr wrote:
>
> > On Monday, November 13th, 2023 at 10:38, Pekka Paalanen ppaala...@gmail.com
> > wrote:
> >
> &g
On Monday, November 13th, 2023 at 10:41, Michel Dänzer
wrote:
> On 11/13/23 10:18, Simon Ser wrote:
>
> > On Monday, October 23rd, 2023 at 10:25, Simon Ser cont...@emersion.fr wrote:
> >
> > > > > > > > > > > > +An atomic commit with the
On Monday, November 13th, 2023 at 10:38, Pekka Paalanen
wrote:
> On Mon, 13 Nov 2023 09:18:39 +
> Simon Ser cont...@emersion.fr wrote:
>
> > On Monday, October 23rd, 2023 at 10:25, Simon Ser cont...@emersion.fr wrote:
> >
> > > > > > >
On Monday, October 23rd, 2023 at 10:25, Simon Ser wrote:
> > > > > > > > > > +An atomic commit with the flag DRM_MODE_PAGE_FLIP_ASYNC is
> > > > > > > > > > allowed to
> > > > > > > > > > +effective
ense here?
With that fixed:
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?
Reviewed-by: Simon Ser
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
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
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
For the uAPI:
Acked-by: Simon Ser
On Monday, October 16th, 2023 at 17:10, Ville Syrjälä
wrote:
> On Mon, Oct 16, 2023 at 05:52:22PM +0300, Pekka Paalanen wrote:
>
> > On Mon, 16 Oct 2023 15:42:16 +0200
> > André Almeida andrealm...@igalia.com wrote:
> >
> > > Hi Pekka,
> > >
> > > On 10/16/23 14:18, Pekka Paalanen wrote:
> >
On Tuesday, August 15th, 2023 at 20:57, André Almeida
wrote:
> Given that prop changes may lead to modesetting, which would defeat the
> fast path of the async flip, refuse any atomic prop change for async
> flips in atomic API. The only exceptions are the framebuffer ID to flip
> to and the
> 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 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
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
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
(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
> ---
>
On Saturday, July 8th, 2023 at 00:40, André Almeida
wrote:
> +KMS atomic state
> +
> +
> +An atomic commit can change multiple KMS properties in an atomic fashion,
> +without ever applying intermediate or partial state changes. Either the
> whole
> +commit succeeds or fails,
On Tuesday, July 4th, 2023 at 19:06, Sebastian Wick
wrote:
> > + * When used with atomic uAPI, the driver will return an error if the
> > hardware
> > + * doesn't support performing an asynchronous page-flip for this update.
> > + * User-space should handle this, e.g. by falling back to a
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
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
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
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
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
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 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
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 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
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.
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
.
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
Glad I could help Weston these last few years, and thank you for
stepping up Marius!
Ville, any news on this?
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(-)
diff --g
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
> > > 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
> >
)
- 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
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
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
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 t
, 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
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
On Friday, September 30th, 2022 at 15:53, Ville Syrjälä
wrote:
> > diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > index 44235345fd57..7500e82cf06a 100644
> > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> >
-off-by: Simon Ser
Reviewed-by: André Almeida
Reviewed-by: Alex Deucher
Cc: Joshua Ashton
Cc: Melissa Wen
Cc: Harry Wentland
Cc: Nicholas Kazlauskas
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm
, Pekka)
Signed-off-by: Simon Ser
Co-developed-by: André Almeida
Signed-off-by: André Almeida
Reviewed-by: André Almeida
Reviewed-by: Alex Deucher
Cc: Daniel Vetter
Cc: Joshua Ashton
Cc: Melissa Wen
Cc: Harry Wentland
Cc: Nicholas Kazlauskas
Cc: Ville Syrjälä
---
drivers/gpu/drm
This new kernel capability indicates whether async page-flips are
supported via the atomic uAPI. DRM clients can use it to check
for support before feeding DRM_MODE_PAGE_FLIP_ASYNC to the kernel.
Make it clear that DRM_CAP_ASYNC_PAGE_FLIP is for legacy uAPI only.
Signed-off-by: Simon Ser
bout Intel hardware,
add R-b tags.
Tested on an AMD Picasso iGPU (Simon) and an AMD Vangogh GPU (André).
Simon Ser (6):
drm: document DRM_MODE_PAGE_FLIP_ASYNC
amd/display: only accept async flips for fast updates
drm: introduce drm_mode_config.atomic_async_page_flip_not_supported
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
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
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
. 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
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
):
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
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,
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:
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 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
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
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
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
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
>
On Wednesday, August 31st, 2022 at 09:50, Pekka Paalanen
wrote:
> > diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> > index 86a292c3185a..cce1a1bea645 100644
> > --- a/include/uapi/drm/drm_mode.h
> > +++ b/include/uapi/drm/drm_mode.h
> > @@ -942,6 +942,10 @@ struct
-off-by: Simon Ser
Cc: Joshua Ashton
Cc: Melissa Wen
Cc: Alex Deucher
Cc: Harry Wentland
Cc: Nicholas Kazlauskas
Cc: André Almeida
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b
This new kernel capability indicates whether async page-flips are
supported via the atomic uAPI. DRM clients can use it to check
for support before feeding DRM_MODE_PAGE_FLIP_ASYNC to the kernel.
Make it clear that DRM_CAP_ASYNC_PAGE_FLIP is for legacy uAPI only.
Signed-off-by: Simon Ser
Cc
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
. 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
This is a subset of [1], included here because a subsequent patch
needs to document the behavior of this flag under the atomic uAPI.
v2: new patch
[1]: https://patchwork.freedesktop.org/patch/500177/
Signed-off-by: Simon Ser
---
include/uapi/drm/drm_mode.h | 7 +++
1 file changed, 7
behaves
this way.
This patch aligns amdgpu with uAPI expectations and returns a failure
when an async flip is not possible.
v2: new patch
Signed-off-by: Simon Ser
Cc: Joshua Ashton
Cc: Melissa Wen
Cc: Alex Deucher
Cc: Harry Wentland
Cc: Nicholas Kazlauskas
Cc: André Almeida
---
drivers/gpu/drm
v1: https://patchwork.freedesktop.org/series/107683/
- User-space patch: https://github.com/Plagman/gamescope/pull/595
- IGT patch: https://patchwork.freedesktop.org/series/107681/
Main changes in v2: add docs, fail atomic commit if async flip isn't
possible.
Tested on an AMD Picasso iGPU.
Simon Ser (6):
a
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.fre
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 inte
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
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
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
On Thursday, August 4th, 2022 at 19:00, samuel ammonius
wrote:
> apps such as popups and dialogs are usually supposed to start either
> at the center of the screen or the center of their parent app
That's usually what compositors do: center apps by default. But it's to
the compositor and user
Hi!
On Thursday, July 28th, 2022 at 20:54, Jim Shargo wrote:
> TL;DR: I'm working on extending VKMS and wanted feedback from other
> compositor/wayland devs.
Very nice, thanks for reaching out!
> - What VKMS features could help your testing the most?
I think the most valuable features are
1 - 100 of 479 matches
Mail list logo
