Oh well, if AMD modifiers are documented via "read Mesa source code",
then I'll just leave everything as-is and libdrm/drm_info/drmdb will
just print "who knows" instead of something actually useful when hitting
such modifiers. Sorry, I have no more free time to donate here.
Sorry for the huge delay. Generally this looks good but maybe we
could explain a bit more what "bottom up" means exactly since it
may not be super obvious.
Maybe something among these lines?
Bottom up means that the first CRTCs in the array should be used
first. For instance, if the drive
y for FB_ID on the
primary plane (instead of skipping for FB_ID on any plane).
Fixes: 0e26cc72c71c ("drm: Refuse to async flip with atomic prop changes")
Signed-off-by: Simon Ser
Reviewed-by: André Almeida
Tested-by: Xaver Hugl
Cc: Alex Deucher
Cc: Christian König
Cc: Michel Dänzer
Cc
I've pushed both patches to drm-misc-fixes, thanks!
I've added a Fixes trailer accordingly.
I'll rebase my patch on top of these two.
the gfx12 modifiers that Mesa exposes.
The modifier u64 bit layout is not supposed to be "Mesa-specific".
It's shared by multiple userspace components. It needs to be defined
properly in drm_fourcc.h.
Please, can you read my questions and answer them?
> From: Simon Ser
> Sent
Looks good to me as well, thank you!
Reviewed-by: Simon Ser
and easy to get wrong.
> From: Alex Deucher
> Sent: July 1, 2024 13:09
> To: Simon Ser ; Olsak, Marek
> Cc: Pillai, Aurabindo ; DRI Development
> ; Siqueira, Rodrigo
> ; Deucher, Alexander ;
> Bas Nieuwenhuizen
> Subject: Re: AMD GFX12 modifiers
>
> + Marek
&
Hi all!
In 7ceb94e87bff ("drm/amd: Add gfx12 swizzle mode defs"), some
definitions were added for GFX12 modifiers. However I'm not quite sure
I understand how these work.
Tile values seem to not be in the same namespace as GFX9 through GFX11,
is that correct? In other words, can GFX9 ~ GFX11 modi
BTW, should we allow OUT_FENCE_PTR as well? Would that work as expected
with async flips?
you mind sending a patch for FB_DAMAGE_CLIPS as well?
Reviewed-by: Simon Ser
y for FB_ID on the
primary plane (instead of skipping for FB_ID on any plane).
Fixes: 0e26cc72c71c ("drm: Refuse to async flip with atomic prop changes")
Signed-off-by: Simon Ser
Cc: André Almeida
Cc: Alex Deucher
Cc: Christian König
Cc: Michel Dänzer
Cc: Ville Syrjälä
---
.
ci: upgrade debian container to bookworm
ci: upgrade FreeBSD VM to 14.1
Nicolas Caramelli (1):
Remove libm in libdrm dependencies
Simon Ser (2):
Sync headers with drm-next
build: bump version to 2.4.122
git tag: libdrm-2.4.122
https://dri.freedesktop.org/libdrm/libdrm
On Thursday, February 29th, 2024 at 11:52, Daniel Vetter
wrote:
> I think some weston (or whatever compositor you like) config file support
> to set a bunch of "really only way to configure is by hand" output
> properties would clear the bar here for me. Because that is a feature I
> already men
On Wednesday, May 22nd, 2024 at 15:36, Mario Limonciello
wrote:
> > To be perfectly honest with you, I haven't given that much though. I
> > used the 'bpc' and 'colorspace' property in debugfs, since I could not
> > find that information anywhere else. And since I also needed to verify
> > the p
On Tuesday, May 21st, 2024 at 19:27, Leo Li wrote:
> I wonder if flags would work better than enums? A compositor can set something
> like `REQUIRE_ACCURACY & REQUIRE_LOW_LATENCY`, for example.
(FWIW, the KMS uAPI has first-class support for bitfields.)
This makes sense to me in general. I like the fact that it's simple and
vendor-neutral.
Do we want to hardcode "panel" in the name? Are we sure that this will
ever only apply to panels?
Do we want to use a name which reflects the intent, rather than the
mechanism? In other words, something like "
On Tuesday, May 14th, 2024 at 22:42, Laurent Pinchart
wrote:
> My experience on Arm platforms is that the KMS drivers offer allocation
> for scanout buffers, not render buffers, and mostly using the dumb
> allocator API. If the KMS device can scan out YUV natively, YUV buffer
> allocation should
On Wednesday, May 8th, 2024 at 17:49, Daniel Vetter wrote:
> On Wed, May 08, 2024 at 09:38:33AM +0100, Daniel Stone wrote:
>
> > On Wed, 8 May 2024 at 09:33, Daniel Vetter dan...@ffwll.ch wrote:
> >
> > > On Wed, May 08, 2024 at 06:46:53AM +0100, Daniel Stone wrote:
> > >
> > > > That would ha
Sounds good to me.
Reviewed-by: Simon Ser
Reviewed-by: Simon Ser
>
> Stop printing the driver date at init, and start returning the empty
> string "" as driver date through the DRM_IOCTL_VERSION ioctl.
Sounds good to me.
Acked-by: Simon Ser
BTW, I wonder if the driver version number (major/minor/patch) is useful?
Do drivers update it?
On Monday, April 22nd, 2024 at 10:58, Ville Syrjala
wrote:
> drm_color_ctm_3x4 is some undocumented amgdpu private
> uapi and thus has no business being in drm_mode.h.
> At least move it to some amdgpu specific header, albeit
> with the wrong namespace as maybe something somewhere
> is using thi
On Thursday, March 28th, 2024 at 19:47, Rob Clark wrote:
> any chance I could talk you into pushing to drm-misc-fixes?
Oh sorry, I thought you had access… Pushed with a minor edit to remove
unnecessary parentheses to make checkpatch happy!
Makes sense to me!
Reviewed-by: Simon Ser
Note, the kernel already sends synthetic page-flip events when a CRTC goes
from on → off. I think it would make sense to do the same for all pending
page-flips before the device is destroyed in the kernel.
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
On Monday, March 4th, 2024 at 15:04, Garg, Nemesa wrote:
> This is generic as sharpness effect is applied post blending. Depending
> on the color gamut, pixel format and other inputs the image gets
> blended and once we get blended output it can be sharpened based on
> strength value provided by
Reviewed-by: Simon Ser
On Wednesday, February 28th, 2024 at 17:14, Maxime Ripard
wrote:
> > I don't know what the rules were 8 years ago, but the current uAPI rules
> > are what they are, and a new enum entry is new uAPI.
>
> TBF, and even if the wayland compositors support is missing, this
> property is perfectly us
ical hardware (Pekka)
> v4: Update the docs to indicate the list is "in order of preference"
> Add a a link to the mutter MR
>
> Cc: Simon Ser
> Cc: Jonas Ådahl
> Cc: Daniel Stone
> Cc: Sameer Lattannavar
> Cc: Sebastian Wick
> Acked-by: Harry Wen
On Monday, February 26th, 2024 at 18:23, Dave Stevenson
wrote:
> You want the commit text for a patch adding a new enum to state that
> the whole property isn't expected to be used through the UAPI? OK, I
> can roll a v2 if that is your desire.
By definition, anything new exposed by the kernel
Reviewed-by: Simon Ser
Pushed to drm-misc-fixes with two minor edits to make scripts/checkpatch.pl
happy (commit reference cut off a final dot, and comment needs "*/" on its own
line).
On Thursday, February 22nd, 2024 at 11:34, Simon Ser
wrote:
> On Thursday, February 22nd, 2024 at 11:32, Simon Ser cont...@emersion.fr
> wrote:
>
> > Thanks, pushed to drm-misc-next!
>
> As I write this, I realize I should've pushed the first patch to
> drm-mi
On Thursday, February 22nd, 2024 at 11:32, Simon Ser
wrote:
> Thanks, pushed to drm-misc-next!
As I write this, I realize I should've pushed the first patch to
drm-misc-fixes instead… Sorry about the fuss…
Sima, Dave, what is the right thing to do here? Push a duplicate commit
to
Sorry for the delay. The first patch is also Reviewed-by me, the rest
is Acked-by because I only skimmed through them.
Thanks, pushed to drm-misc-next! Please do ping about patches when they
slip through the cracks.
How much of this is Intel-specific? Are there any hardware vendors with
a similar feature? How much is the "sharpness" knob tied to Intel hardware?
Pushed to drm-misc-next, thanks!
> Do we really need this much flexibility, especially for the first driver
> adding the first few additional properties?
AFAIU we'd like to allow more props as well, e.g. cursor position…
Reviewed-by: Simon Ser
Eric Engestrom (1):
radeon: fix missing stencil_tile_mode initialisation in the
linear/fallback case
Pierre-Eric Pelloux-Prayer (1):
amdgpu: fix use-after-free
Simon Ser (2):
Sync headers with drm-next
build: bump version to 2.4.120
git tag: libdrm-2.4.120
https
Are we sure that all drivers handle these two props properly with async
page-flips? This is a new codepath not taken by the legacy uAPI.
Style nit: the indentation is a bit off, the continuation lines don't
align with the parenthesis.
The whole series is:
Reviewed-by: Simon Ser
On Wednesday, December 13th, 2023 at 15:16, Pekka Paalanen
wrote:
> > > It is protected/shielded/fortified from all the kernel and userspace,
> > > but a more familiar word to describe that is inaccessible.
> > > "Inaccessible buffer" per se OTOH sounds like a useless concept.
> > >
> > > It is
Bubble up any error to the caller.
Signed-off-by: Simon Ser
Cc: Maxime Ripard
Cc: Kees Cook
Cc: Dave Stevenson
---
drivers/gpu/drm/vc4/vc4_plane.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c
index
Is there a chance to pick a better name than "secure" here?
"Secure" is super overloaded, it's not clear at all what it means from
just the name. Something like "restricted" would be an improvement.
On Wednesday, November 29th, 2023 at 13:45, Maxime Ripard
wrote:
>
>
> Hi,
>
> Thanks for writing this down
>
> On Thu, Nov 16, 2023 at 03:53:20PM +, Simon Ser wrote:
>
> > On Thursday, November 9th, 2023 at 08:45, Simon Ser cont...@emersion.fr
&g
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
Acked-by: Simon Ser
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 Friday, December 1st, 2023 at 10:57, Pekka Paalanen
wrote:
> > > +An atomic commit can be flagged with DRM_MODE_ATOMIC_TEST_ONLY, which
> > > means the
> >
> > It would be nice to link DRM_MODE_ATOMIC_TEST_ONLY to the actual docs here.
> > This can be done with markup such as:
> >
> >
Thanks for writing these docs! A few comments below.
On Thursday, November 30th, 2023 at 21:07, 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 ch
On Wednesday, November 22nd, 2023 at 13:49, Javier Martinez Canillas
wrote:
> Any objections to merge the series ?
No objections from me :)
Thanks! This iteration of the first 3 patches LGTM, I've pushed them to
drm-misc-next. I've made two adjustments to make checkpatch.pl happy:
- s/uint64_t/u64/
- Fix indentation for a drm_dbg_atomic()
pwetty on big-endian
util: add pwetty support for big-endian RGB565
modetest: add support for big-endian XRGB1555/RGB565
Jonas Karlman (1):
modetest: add support for DRM_FORMAT_NV{15,20,30}
Neil Armstrong (1):
modetest: switch usage to proper options grammar
Simon Ser (4
It seems like commits were re-ordered at some point. I think we need "drm:
introduce drm_mode_config.atomic_async_page_flip_not_supported" to come before
"drm: allow DRM_MODE_PAGE_FLIP_ASYNC for atomic commits" because the latter
uses atomic_async_page_flip_not_supported. Similarly, "drm: Refuse to
On Thursday, November 9th, 2023 at 08:45, Simon Ser wrote:
> User-space sometimes needs to allocate scanout-capable memory for
> GPU rendering purposes. On a vc4/v3d split render/display SoC, this
> is achieved via DRM dumb buffers: the v3d user-space driver opens
> the prim
ndling expects the backing storage/upload buffer not to change for a
> given plane. If the upload buffer changes between page flips, the new
> upload buffer has to be updated as a whole. Hence no damage handling then.
Why would these concepts be specific to user-space? The kernel could
better handle buffer damage instead of forcing full damage, by doing
something similar to what user-space does.
Anyways:
Reviewed-by: Simon Ser
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
On Friday, November 10th, 2023 at 15:01, Maxime Ripard
wrote:
> On Fri, Nov 10, 2023 at 11:21:15AM +0000, Simon Ser wrote:
>
> > On Thursday, November 9th, 2023 at 20:17, Maxime Ripard mrip...@kernel.org
> > wrote:
> >
> > > > Can we add another function
On Friday, November 10th, 2023 at 15:13, Maxime Ripard
wrote:
> > > > We've talked with Sima at XDC about adding a symlink pointing to the
> > > > DMA heap and extra metadata files describing priorities and such.
> > > > However we don't actually need that part for the purposes of v3d --
> > > >
On Thursday, November 9th, 2023 at 20:17, Maxime Ripard
wrote:
> > Can we add another function pointer to the struct drm_driver (or
> > similar) to do the allocation, and move the actual dmabuf handling
> > code into the core?
>
> Yeah, I agree here, it just seems easier to provide a global hoo
On Thursday, November 9th, 2023 at 20:09, Maxime Ripard
wrote:
> On Thu, Nov 09, 2023 at 03:31:44PM +0000, Simon Ser wrote:
> > > > - What would be a good name for the heap? "vc4" is maybe a bit naive and
> > > > not precise enough. Something wi
On Thursday, November 9th, 2023 at 19:38, Dave Stevenson
wrote:
> Hi Simon
>
> On Thu, 9 Nov 2023 at 17:46, Simon Ser wrote:
> >
> > On Thursday, November 9th, 2023 at 16:42, Dave Stevenson
> > wrote:
> >
> > > > > - What would be a go
Reviewed-by: Simon Ser
Reviewed-by: Simon Ser
On Thursday, November 9th, 2023 at 16:42, Dave Stevenson
wrote:
> > > - What would be a good name for the heap? "vc4" is maybe a bit naive and
> > > not precise enough. Something with "cma"? Do we need to plan a naming
> > > scheme to accomodate for multiple vc4 devices?
> >
> > That's a gen
On Thursday, November 9th, 2023 at 16:14, T.J. Mercier
wrote:
> > + exp_info.priv = vc4; / TODO: unregister when unloading */
> > +
>
> So unregistering a heap isn't currently possible, but we're trying to
> enable that here:
> https://lore.kernel.org/all/20231106120423.23364-7-yunfei.d...@medi
On Thursday, November 9th, 2023 at 13:14, Maira Canal wrote:
> On 11/9/23 04:45, Simon Ser wrote:
> > User-space sometimes needs to allocate scanout-capable memory for
> > GPU rendering purposes. On a vc4/v3d split render/display SoC, this
> > is achieved via DRM dumb buffer
Thanks for the feedback Iago! I've replied to Maxime and I believe that
covers your questions as well.
On Thursday, November 9th, 2023 at 10:11, Maxime Ripard
wrote:
> > - Does this approach make sense to y'all in general?
>
> Makes sense to me :)
Great to hear!
> > - What would be a good name for the heap? "vc4" is maybe a bit naive and
> > not precise enough. Something with "cma"? Do we need
on unload.
[1]: https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/4414
Signed-off-by: Simon Ser
Cc: Maxime Ripard
Cc: Daniel Vetter
Cc: Daniel Stone
Cc: Erico Nunes
Cc: Iago Toral Quiroga
Cc: Maíra Canal
Cc: Thomas Zimmermann
---
drivers/gpu/drm/vc4/Makefile |
This is necessary to create DMA heaps in other modules
(e.g. graphics drivers).
Signed-off-by: Simon Ser
Cc: Sumit Semwal
Cc: Benjamin Gaignard
Cc: Brian Starkey
Cc: John Stultz
Cc: "T.J. Mercier"
---
drivers/dma-buf/dma-heap.c | 2 ++
1 file changed, 2 insertions(+)
diff --git
On Monday, October 30th, 2023 at 11:22, Dmitry Baryshkov
wrote:
> On Mon, 30 Oct 2023 at 12:13, Simon Ser cont...@emersion.fr wrote:
>
> > On Monday, October 30th, 2023 at 10:47, Dmitry Baryshkov
> > dmitry.barysh...@linaro.org wrote:
> >
> > > On Mon, 30 O
On Monday, October 30th, 2023 at 10:47, Dmitry Baryshkov
wrote:
> On Mon, 30 Oct 2023 at 10:19, Heikki Krogerus
> heikki.kroge...@linux.intel.com wrote:
>
> > On Mon, Oct 23, 2023 at 09:24:33PM +0300, Dmitry Baryshkov wrote:
> >
> > > On 15 September 2023 15:14:35 EEST, Heikki Krogerus
> > >
re?
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 Thursday, October 26th, 2023 at 21:16, Simon Ser wrote:
> On Thursday, October 26th, 2023 at 19:55, Erik Kurzinger
> ekurzin...@nvidia.com wrote:
>
> > Is there anything else needed for this fix to be merged? I have shared
> > an accompanying patch for the IGT test
On Thursday, October 26th, 2023 at 19:55, Erik Kurzinger
wrote:
> Is there anything else needed for this fix to be merged? I have shared
> an accompanying patch for the IGT test suite here
> https://lists.freedesktop.org/archives/igt-dev/2023-August/060154.html
Do you also happen to have user-s
Thinking about this again, it seems like you could start with just simple
enumerated modifiers like Intel does, and then only switch to more
complicated logic with macros and fields if there is an actual need in
the future.
Would be good to have an overview comment to explain how bits in the
modifier are used and how everything is tied up together, e.g. what the
type and tile mode mean. Also some docs for
DRM_FORMAT_MOD_VERISILICON_TYPE_NORMAL
would be nice. (If there is no other type, this can be removed, the bits
w
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
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 Monday, October 23rd, 2023 at 10:42, Michel Dänzer
wrote:
> On 10/23/23 10:27, Simon Ser wrote:
>
> > On Sunday, October 22nd, 2023 at 12:12, Michel Dänzer
> > michel.daen...@mailbox.org wrote:
> >
> > > On 10/17/23 14:16, Simon Ser wrote:
> > &g
On Sunday, October 22nd, 2023 at 12:12, Michel Dänzer
wrote:
> On 10/17/23 14:16, Simon Ser wrote:
>
> > After discussing with André it seems like we missed a plane type check
> > here. We need to make sure FB_ID changes are only allowed on primary
> > planes.
>
>
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
On Monday, October 23rd, 2023 at 10:14, Albert Esteve
wrote:
> On Mon, Oct 23, 2023 at 9:55 AM Simon Ser wrote:
>
> > On Monday, October 23rd, 2023 at 09:46, Albert Esteve
> > wrote:
> >
> > > Link to the IGT test covering this patch (already merged):
&g
On Monday, October 23rd, 2023 at 09:46, Albert Esteve
wrote:
> Link to the IGT test covering this patch (already merged):
> https://lists.freedesktop.org/archives/igt-dev/2023-July/058427.html
Hmm. IGT should not be merged before the kernel, because as long as the
kernel is not merged there mig
Acked-by: Simon Ser
ing.
v2: no change
Signed-off-by: Simon Ser
Cc: Hans de Goede
Cc: Dennis Filder
Cc: Daniel Vetter
Cc: Pekka Paalanen
Cc: Rob Clark
Cc: Sean Paul
Cc: Daniel Stone
---
drivers/gpu/drm/drm_framebuffer.c | 51 +++
1 file changed, 31 insertions(+), 20 deletions(-)
di
94
[4]: https://lists.freedesktop.org/archives/igt-dev/2023-October/063294.html
Signed-off-by: Simon Ser
Acked-by: Pekka Paalanen
Cc: Hans de Goede
Cc: Dennis Filder
Cc: Daniel Vetter
Cc: Rob Clark
Cc: Sean Paul
Cc: Daniel Stone
---
drivers/gpu/drm/drm_crtc_internal.h | 2 ++
drivers/gp
Samuel Pitoiset (2):
amdgpu: amdgpu_drm.h for new GPUVM fault ioctl
amdgpu: add support for querying VM faults information
Simon Ser (3):
xf86drm: mark DRM_MAX_MINOR as deprecated
ci: bump FreeBSD to 13.2
build: bump version to 2.4.117
git tag: libdrm-2.4.11
For the uAPI:
Acked-by: Simon Ser
After discussing with André it seems like we missed a plane type check
here. We need to make sure FB_ID changes are only allowed on primary
planes.
Reviewed-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:
> >
devel/20170509153654.23464-1-robdcl...@gmail.com/
[2]:
https://lore.kernel.org/dri-devel/20211006151921.312714-1-cont...@emersion.fr/
[3]: https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/4394
[4]: https://lists.freedesktop.org/archives/igt-dev/2023-October/063294.html
Signed-off-by: Simo
1 - 100 of 920 matches
Mail list logo
