Nouveau - Mar 2017 - [PATCH xf86-video-nouveau] Do not register hotplug without RandR

When using Xinerama, RandR is automatically disabled, and calling RR
routines will trigger an assert() because the RR keys/resources are
not set, leading to an Xserver abort.

Hotplug makes little sense without RandR, so no need to install a
udev monitor if RandR is not available.

Ported from intel driver, original work by:
Chris Wilson <chris at chris-wilson.co.uk>

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98383
Signed-off-by: Mariusz Bialonczyk <manio at skyboo.net>
---
 src/drmmode_display.c | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/src/drmmode_display.c b/src/drmmode_display.c
index dd9fa27..ae29d9a 100644
--- a/src/drmmode_display.c
+++ b/src/drmmode_display.c
@@ -1556,6 +1556,15 @@ drmmode_udev_notify(int fd, int notify, void *data)
 }
 #endif
 
+static bool has_randr(void)
+{
+#if HAS_DIXREGISTERPRIVATEKEY
+	return dixPrivateKeyRegistered(rrPrivKey);
+#else
+	return *rrPrivKey;
+#endif
+}
+
 static void
 drmmode_uevent_init(ScrnInfoPtr scrn)
 {
@@ -1564,6 +1573,12 @@ drmmode_uevent_init(ScrnInfoPtr scrn)
 	struct udev *u;
 	struct udev_monitor *mon;
 
+	/* RandR will be disabled if Xinerama is active, and so generating
+	 * RR hotplug events is then forbidden.
+	 */
+	if (!has_randr())
+		return;
+
 	u = udev_new();
 	if (!u)
 		return;
-- 
2.11.0

Chris, could you have a look at this since it's allegedly your work in
the intel driver and let us know if it's reasonable? I'm definitely
not enough of an X driver guy to rule one way or the other.

On Wed, Mar 29, 2017 at 4:07 PM, Mariusz Bialonczyk <manio at skyboo.net>
wrote:
> When using Xinerama, RandR is automatically disabled, and calling RR
> routines will trigger an assert() because the RR keys/resources are
> not set, leading to an Xserver abort.
>
> Hotplug makes little sense without RandR, so no need to install a
> udev monitor if RandR is not available.
>
> Ported from intel driver, original work by:
> Chris Wilson <chris at chris-wilson.co.uk>
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98383
> Signed-off-by: Mariusz Bialonczyk <manio at skyboo.net>
> ---
>  src/drmmode_display.c | 15 +++++++++++++++
>  1 file changed, 15 insertions(+)
>
> diff --git a/src/drmmode_display.c b/src/drmmode_display.c
> index dd9fa27..ae29d9a 100644
> --- a/src/drmmode_display.c
> +++ b/src/drmmode_display.c
> @@ -1556,6 +1556,15 @@ drmmode_udev_notify(int fd, int notify, void *data)
>  }
>  #endif
>
> +static bool has_randr(void)
> +{
> +#if HAS_DIXREGISTERPRIVATEKEY
> +       return dixPrivateKeyRegistered(rrPrivKey);
> +#else
> +       return *rrPrivKey;
> +#endif
> +}
> +
>  static void
>  drmmode_uevent_init(ScrnInfoPtr scrn)
>  {
> @@ -1564,6 +1573,12 @@ drmmode_uevent_init(ScrnInfoPtr scrn)
>         struct udev *u;
>         struct udev_monitor *mon;
>
> +       /* RandR will be disabled if Xinerama is active, and so generating
> +        * RR hotplug events is then forbidden.
> +        */
> +       if (!has_randr())
> +               return;
> +
>         u = udev_new();
>         if (!u)
>                 return;
> --
> 2.11.0
>
> _______________________________________________
> Nouveau mailing list
> Nouveau at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau

On Wed, Mar 29, 2017 at 07:03:12PM -0400, Ilia Mirkin
wrote:
> Chris, could you have a look at this since it's allegedly your work in
> the intel driver and let us know if it's reasonable? I'm definitely
> not enough of an X driver guy to rule one way or the other.
Yup, it is from

commit 1a489142c8e6a4828348cc9afbd0f430d3b1e2d8
Author: Chris Wilson <chris at chris-wilson.co.uk>
Date:   Tue Oct 23 23:43:50 2012 +0100

    sna: Disable RandR hotplug events if Xinerama is enabled
    
    Since RandR itself is disabled if Xinerama is enabled, for example with
    ZaphodHeads, calling RRGetInfo() upon a hotplug event generates an
    assertion.
    
    Reported-by: Stephen Liang <inteldriver at angrywalls.com>
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=55260
    Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>

and covers a quite obscure mix of features that results in no RandR.
Hmm, now with the link-status property there is a reason why the ddx
might want to handle hotplug even if it doesn't propagate the event on,
but so far link-status DP retraining in userspace is an i915.ko only
"feature".
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre