[Bug 197925] [amdgpu_dc][carrizo] multiple monitor handling errors
https://bugzilla.kernel.org/show_bug.cgi?id=197925 --- Comment #6 from Miłosz Rachwał (kbz...@milek7.pl) --- I just tested kernel built from Linus tree and everything works now, so probably it is already fixed. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 104034] Mesa/Radeonsi does not compile on musl due to endianess check
https://bugs.freedesktop.org/show_bug.cgi?id=104034 Bug ID: 104034 Summary: Mesa/Radeonsi does not compile on musl due to endianess check Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel@lists.freedesktop.org Reporter: lucas.francesc...@gmail.com QA Contact: dri-devel@lists.freedesktop.org https://lists.freedesktop.org/archives/mesa-dev/2016-November/134355.html used to need to apply this patch and everything went fine(mainline still wasnt compiling patchless anyway) but recently the source files changed and the patch does not work anymore the patch fails to apply and if i build it without the patch i get In file included from /var/tmp/portage/media-libs/mesa-/work/mesa-/src/amd/addrlib/gfx9/gfx9addrlib.cpp:36:0: /var/tmp/portage/media-libs/mesa-/work/mesa-/src/amd/addrlib/inc/chip/gfx9/gfx9_gb_reg.h:44:2: error: #error "BIGENDIAN_CPU or LITTLEENDIAN_CPU must be defined" #error "BIGENDIAN_CPU or LITTLEENDIAN_CPU must be defined" ^ which is the behavior i was having already w/o the patch since 2016 would you guys mindig fixing endianess dectection on musl libc? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH 0/2] Move scheduler out of AMDGPU
I'm wondering if GPU reset still work after this home move ...
-Original Message-
From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of
Christian K?nig
Sent: Friday, December 1, 2017 11:55 PM
To: Lucas Stach ; Deucher, Alexander
Cc: Grodzovsky, Andrey ; David Airlie
; amd-...@lists.freedesktop.org;
patchwork-...@pengutronix.de; dri-devel@lists.freedesktop.org;
ker...@pengutronix.de
Subject: Re: [PATCH 0/2] Move scheduler out of AMDGPU
Am 01.12.2017 um 16:28 schrieb Lucas Stach:
> Hi all,
>
> so this is the first step to make the marvelous AMDGPU scheduler
> useable for other drivers. I have a (mostly) working prototype of
> Etnaviv using the scheduler, but those patches need to keep baking for a
> while.
>
> I'm sending this out as I want to avoid rebasing this change too much
> and don't want to take people by surprise when the Etnaviv
> implementation surfaces. Also this might need some coordination
> between AMDGPU and Etnaviv, which might be good to get going now.
>
> Please speak up now if you have any objections or comments.
Looks good to me, but question is what is this based upon?
I strongly assume drm-next, so question is now if we have any patches inside
amd branches we should apply before doing this.
CCing Andrey as well cause he has some tasks assigned around the scheduler as
well.
Regards,
Christian.
>
> Regards,
> Lucas
>
> Lucas Stach (2):
>drm: move amd_gpu_scheduler into common location
>drm/sched: move fence slab handling to module init/exit
>
> drivers/gpu/drm/Kconfig| 5 +
> drivers/gpu/drm/Makefile | 1 +
> drivers/gpu/drm/amd/amdgpu/Makefile| 5 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu.h| 16 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 8 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c| 38 +--
> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 12 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c| 8 -
> drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c | 4 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_job.c| 22 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c | 14 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h | 12 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_sched.c | 20 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_sched.h | 2 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c | 6 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 8 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h| 4 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c| 8 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.h| 4 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c| 8 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_vce.h| 2 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c| 14 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h| 4 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 10 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h | 4 +-
> drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 4 +-
> drivers/gpu/drm/amd/amdgpu/uvd_v6_0.c | 8 +-
> drivers/gpu/drm/amd/amdgpu/uvd_v7_0.c | 8 +-
> drivers/gpu/drm/amd/scheduler/gpu_scheduler.h | 185 --
> drivers/gpu/drm/scheduler/Makefile | 4 +
> .../gpu/drm/{amd => }/scheduler/gpu_scheduler.c| 281
> +++--
> drivers/gpu/drm/{amd => }/scheduler/sched_fence.c | 122 +
> include/drm/gpu_scheduler.h| 171 +
> .../drm/gpu_scheduler_trace.h | 14 +-
> 34 files changed, 525 insertions(+), 511 deletions(-)
> delete mode 100644 drivers/gpu/drm/amd/scheduler/gpu_scheduler.h
> create mode 100644 drivers/gpu/drm/scheduler/Makefile
> rename drivers/gpu/drm/{amd => }/scheduler/gpu_scheduler.c (64%)
> rename drivers/gpu/drm/{amd => }/scheduler/sched_fence.c (58%)
> create mode 100644 include/drm/gpu_scheduler.h
> rename drivers/gpu/drm/amd/scheduler/gpu_sched_trace.h =>
> include/drm/gpu_scheduler_trace.h (83%)
>
___
amd-gfx mailing list
amd-...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 103808] [radeonsi, bisected] World of Warcraft scribbling all over screen
https://bugs.freedesktop.org/show_bug.cgi?id=103808 Chris Rankin changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: drm/sun4i: no picture when connected to a 4k display
Hi Hans,
On Thu, Nov 30, 2017 at 06:14:13PM +0100, Hans Verkuil wrote:
> Hi Maxime, Chen-Yu,
>
> When I connect my cubieboard running 4.15-rc1 to my 4k display I get
> no picture. Some digging found that there is no check against the
> upper pixelclock limit of the HDMI output, so X selects a 4kp60
> format at 594 MHz, which obviously won't work.
>
> I whipped up the quick patch below, but this information about the
> max support HDMI frequency should probably come from the device
> tree. Although for the A10 and A20 I guess it could also be
> hardcoded in the source since this code is only used for sun4i.
>
> Anyway, when I use this patch I get a proper 1080p60 picture.
Thanks for that patch!
> Regards,
>
> Hans
>
> Signed-off-by: Hans Verkuil
> ---
> diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
> b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
> index dda904ec0534..dc2f550f54ff 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
> @@ -208,8 +208,17 @@ static int sun4i_hdmi_get_modes(struct drm_connector
> *connector)
> return ret;
> }
>
> +static int sun4i_hdmi_mode_valid(struct drm_connector *connector,
> + struct drm_display_mode *mode)
> +{
> + if (mode->clock > 17)
> + return MODE_CLOCK_HIGH;
> + return MODE_OK;
> +}
> +
This is slightly more complicated than that. Even if the hardware
could be capable of achieving that rate, we might not be able to reach
it due to other constraints (such as other device already running that
would need to run at a particular rate.
A more elegant solution would be to call clk_round_rate on mode->clock
and see if the rate is close enough. You can have a look at what we
have in sun4i_rgb_mode_valid if you want.
It's still not optimal, as we have never been able to agree on what
"close enough" is and we just went to the other extreme. If you have
some input on that, it would be great :)
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 2/2] staging: ion: create one device entry per heap
On Wed, Nov 29, 2017 at 03:00:56PM +0100, Benjamin Gaignard wrote:
> 2017-11-28 14:32 GMT+01:00 Greg KH :
> > On Mon, Nov 06, 2017 at 04:59:45PM +0100, Benjamin Gaignard wrote:
> >> Instead a getting only one common device "/dev/ion" for
> >> all the heaps this patch allow to create one device
> >> entry ("/dev/ionX") per heap.
> >> Getting an entry per heap could allow to set security rules
> >> per heap and global ones for all heaps.
> >>
> >> Allocation requests will be only allowed if the mask_id
> >> match with device minor.
> >> Query request could be done on any of the devices.
> >>
> >> Signed-off-by: Benjamin Gaignard
> >> ---
> >> drivers/staging/android/TODO| 1 -
> >> drivers/staging/android/ion/Kconfig | 7
> >> drivers/staging/android/ion/ion-ioctl.c | 18 --
> >> drivers/staging/android/ion/ion.c | 62
> >> +
> >> drivers/staging/android/ion/ion.h | 15 ++--
> >> 5 files changed, 91 insertions(+), 12 deletions(-)
> >>
> >> diff --git a/drivers/staging/android/TODO b/drivers/staging/android/TODO
> >> index 687e0ea..8a11931 100644
> >> --- a/drivers/staging/android/TODO
> >> +++ b/drivers/staging/android/TODO
> >> @@ -8,7 +8,6 @@ TODO:
> >> ion/
> >> - Add dt-bindings for remaining heaps (chunk and carveout heaps). This
> >> would
> >> involve putting appropriate bindings in a memory node for Ion to find.
> >> - - Split /dev/ion up into multiple nodes (e.g. /dev/ion/heap0)
> >> - Better test framework (integration with VGEM was suggested)
> >>
> >> Please send patches to Greg Kroah-Hartman and Cc:
> >> diff --git a/drivers/staging/android/ion/Kconfig
> >> b/drivers/staging/android/ion/Kconfig
> >> index a517b2d..cb4666e 100644
> >> --- a/drivers/staging/android/ion/Kconfig
> >> +++ b/drivers/staging/android/ion/Kconfig
> >> @@ -10,6 +10,13 @@ menuconfig ION
> >> If you're not using Android its probably safe to
> >> say N here.
> >>
> >> +config ION_LEGACY_DEVICE_API
> >> + bool "Keep using Ion legacy misc device API"
> >> + depends on ION
> >
> > You want to default to Y here, so when you do 'make oldconfig' nothing
> > breaks, right?
> >
>
> I will add it.
>
> >> + help
> >> + Choose this option to keep using Ion legacy misc device API
> >> + i.e. /dev/ion
> >
> > You need more text here to describe the trade offs. Why would I not
> > want to keep doing this? What does turning this off get me? What does
> > keeping it on keep me from doing?
> >
> Does describe it like that sound better ?
> "Choose this option to keep using ION legacy misc device API
> i.e. /dev/ion. If this option isn't selected you will only
> have per heap device node (i.e /dev/ionX) and allocating buffer
> from an unique device node won't be possible."
I still don't know why I would not select such an option, other than it
would break my working Android system if I did so :)
Please try to explain it a bit better. For example, I really don't know
why you want to do this at all.
> >> -void ion_device_add_heap(struct ion_heap *heap)
> >> +static struct device ion_bus = {
> >> + .init_name = ION_NAME,
> >> +};
> >
> > Oh look, a struct device on the stack. Watch bad things happen :(
> >
> > This is a dynamic device, make it dynamic, or else you had better know
> > exactly what you are doing...
>
> The naming is bad here, I will rename it ion_parent because I use it to
> provide
> a parent to ion heap device either they won't go in /sys/bus/ion
Again, never use a static struct device, if you do, it is a _huge_ hint
the code is incorrect.
> >> - idev->debug_root = debugfs_create_dir("ion", NULL);
> >> - if (!idev->debug_root) {
> >> + ret = device_register(&ion_bus);
> >
> > You call device_register for something you are calling a bus??? Are you
> > _sure_ about this?
> >
> > What exactly are you creating in sysfs here? You are throwing around
> > "raw" devices, which is almost never what you ever want to do.
> > Especially for some random char driver.
>
> ion heap devices need a parent to be correctly put in /sys/bus/ion either they
> will go directly in /sys/bus directory. You are right name it ion_bus
> is confusing
> I will rename it ion_parent.
Again, what are you trying to show in sysfs? What type of
representation? What is the bus? What device type? Why in sysfs at
all?
> > How many different reference counted objects do you now have in this
> > structure? And what exactly is the lifetime rules involved in them?
> >
> > Hint, you never tried removing any of these from the system, otherwise
> > you would have seen the kernel warnings...
> >
>
> No I have never try because ION doesn't allow to be removed.
That seems odd, there's no way to free up all resources and remove the
module?
> > Step back here, what exactly do you want to do? What do you expect
> > sysfs to look like? What do you want /dev/ to look like?
> >
> > Where is the document
Re: PROBLEM: Asus C201 video mode problems on HDMI hotplug (regression)
Hi Nick,
On 01-12-2017 00:11, Nick Bowler wrote:
> Hi,
>
> On 2017-11-27 22:30 -0500, Nick Bowler wrote:
>> A note about the test setup: I had to remove the test equipment so I
>> no longer have any information about the video mode from the sink side
>> (like in the photos). Thus, with the current setup, I am using the
>> presense or absense of audio to determine whether the issue is present
>> or not.
>>
>> The test procedure is: boot up, start music, then hotplug the hdmi four
>> times. If sound is heard after all four connections, PASS; otherwise FAIL.
>>
>> - I retested on 4.15-rc1 to confirm that the issue is still present (it is).
>>
>> - I applied the functional revert from earlier on top of 4.15-rc1 and the
>>problem is fixed.
>>
>> - Returning to 4.15-rc1 and applying [Laurent Pinchart's] patch --
>>the issue is present again (no change in behaviour compared to
>>4.15-rc1).
> Another data point... the following patch appears sufficient to restore
> working behaviour.
>
> Cheers,
> Nick
>
> ---
> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 17 -
> 1 file changed, 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> index bf14214fa464..3118fbd8433d 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> @@ -1101,8 +1101,6 @@ static void dw_hdmi_phy_power_off(struct dw_hdmi *hdmi)
> static int dw_hdmi_phy_power_on(struct dw_hdmi *hdmi)
> {
> const struct dw_hdmi_phy_data *phy = hdmi->phy.data;
> - unsigned int i;
> - u8 val;
>
> if (phy->gen == 1) {
> dw_hdmi_phy_enable_powerdown(hdmi, false);
> @@ -1116,21 +1114,6 @@ static int dw_hdmi_phy_power_on(struct dw_hdmi *hdmi)
> dw_hdmi_phy_gen2_txpwron(hdmi, 1);
> dw_hdmi_phy_gen2_pddq(hdmi, 0);
>
> - /* Wait for PHY PLL lock */
> - for (i = 0; i < 5; ++i) {
> - val = hdmi_readb(hdmi, HDMI_PHY_STAT0) & HDMI_PHY_TX_PHY_LOCK;
> - if (val)
> - break;
> -
> - usleep_range(1000, 2000);
> - }
> -
> - if (!val) {
> - dev_err(hdmi->dev, "PHY PLL failed to lock\n");
> - return -ETIMEDOUT;
> - }
> -
> - dev_dbg(hdmi->dev, "PHY PLL locked %u iterations\n", i);
> return 0;
> }
>
I don't think you can do this. The phy pll lock check is
recommended and can indicate hw failure. Can you please check if
this untested, uncompiled patch makes it work correctly ?
-->8---
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index bf14214..456fc54 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -1669,7 +1669,7 @@ static void
hdmi_disable_overflow_interrupts(struct dw_hdmi *hdmi)
static int dw_hdmi_setup(struct dw_hdmi *hdmi, struct
drm_display_mode *mode)
{
- int ret;
+ int ret, vsync_len = mode->vsync_end - mode->vsync_start;
hdmi_disable_overflow_interrupts(hdmi);
@@ -1722,6 +1722,14 @@ static int dw_hdmi_setup(struct dw_hdmi
*hdmi, struct drm_display_mode *mode)
return ret;
hdmi->phy.enabled = true;
+ /* Reset all clock domains */
+ hdmi_writeb(hdmi, 0x00, HDMI_MC_SWRSTZ);
+
+ /* Rewrite vsync register to latch previous written values */
+ if (mode->flags & DRM_MODE_FLAG_INTERLACE)
+ vsync_len /= 2;
+ hdmi_writeb(hdmi, vsync_len, HDMI_FC_VSYNCINWIDTH);
+
/* HDMI Initialization Step B.3 */
dw_hdmi_enable_video_path(hdmi);
-->8---
I would expect this patch to end your wrong image issue but the
audio part may be a different problem.
Best Regards,
Jose Miguel Abreu
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/vc4: Release fence after signalling
We were never releasing the initial fence reference that is obtained
through dma_fence_init.
Link: https://github.com/anholt/linux/issues/122
Fixes: cdec4d361323 ("drm/vc4: Expose dma-buf fences for V3D rendering.")
Signed-off-by: Stefan Schake
---
drivers/gpu/drm/vc4/vc4_gem.c | 4 +++-
drivers/gpu/drm/vc4/vc4_irq.c | 1 +
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vc4/vc4_gem.c b/drivers/gpu/drm/vc4/vc4_gem.c
index 6c32c89..6385409 100644
--- a/drivers/gpu/drm/vc4/vc4_gem.c
+++ b/drivers/gpu/drm/vc4/vc4_gem.c
@@ -888,8 +888,10 @@ struct vc4_hang_state {
/* If we got force-completed because of GPU reset rather than
* through our IRQ handler, signal the fence now.
*/
- if (exec->fence)
+ if (exec->fence) {
dma_fence_signal(exec->fence);
+ dma_fence_put(exec->fence);
+ }
if (exec->bo) {
for (i = 0; i < exec->bo_count; i++) {
diff --git a/drivers/gpu/drm/vc4/vc4_irq.c b/drivers/gpu/drm/vc4/vc4_irq.c
index 61b2e53..26eddbb 100644
--- a/drivers/gpu/drm/vc4/vc4_irq.c
+++ b/drivers/gpu/drm/vc4/vc4_irq.c
@@ -139,6 +139,7 @@
list_move_tail(&exec->head, &vc4->job_done_list);
if (exec->fence) {
dma_fence_signal_locked(exec->fence);
+ dma_fence_put(exec->fence);
exec->fence = NULL;
}
vc4_submit_next_render_job(dev);
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 104037] [drm] GPU HANG: ecode 9:0:0x87f9bffb, in Xorg [1688], reason: Hang on rcs0, action: reset
https://bugs.freedesktop.org/show_bug.cgi?id=104037 Chris Wilson changed: What|Removed |Added QA Contact|intel-gfx-bugs@lists.freede |dri-devel@lists.freedesktop |sktop.org |.org Product|DRI |Mesa Component|DRM/Intel |Drivers/DRI/i915 Assignee|intel-gfx-bugs@lists.freede |dri-devel@lists.freedesktop |sktop.org |.org -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/vc4: Release fence after signalling
Quoting Stefan Schake (2017-12-02 17:40:39)
> We were never releasing the initial fence reference that is obtained
> through dma_fence_init.
>
> Link: https://github.com/anholt/linux/issues/122
> Fixes: cdec4d361323 ("drm/vc4: Expose dma-buf fences for V3D rendering.")
> Signed-off-by: Stefan Schake
Maarten wrote an identical patch,
20171130150253.17200-1-maarten.lankho...@linux.intel.com, if you could
coordinate between yourselves to deliver a reviewed patch to Eric that
would be great.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 103100] Performance regression with various games in drm-next-amd-staging Kernel
https://bugs.freedesktop.org/show_bug.cgi?id=103100 --- Comment #10 from Gregor Münch --- Ive updated test, with staging kernel and mesa from today: https://openbenchmarking.org/result/1712028-AL-GAMETEST322 Looks like I enabled performance governor by accident. But overall 4.11 is still faster- so it looks like there were some performance improvements in mesa in the last days. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 104034] Mesa/Radeonsi does not compile on musl due to endianess check
https://bugs.freedesktop.org/show_bug.cgi?id=104034 --- Comment #1 from Lucas Francesco --- Created attachment 135881 --> https://bugs.freedesktop.org/attachment.cgi?id=135881&action=edit the updated hack/fix well, it seems the inclusion of /addrlib/gfx9/chip on /Makefile.addrlib.am broke the old patch, so this is the new, updated patch, it would still be nice to have dectection mainline while using musl anyways -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
