ports/166647: [patch] nvidia-settings should ignore disconnected display devices

David Wolfskill david at catwhisker.org
Wed Apr 4 16:30:06 UTC 2012


>Number:         166647
>Category:       ports
>Synopsis:       [patch] nvidia-settings should ignore disconnected display devices
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-ports-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed Apr 04 16:30:05 UTC 2012
>Closed-Date:
>Last-Modified:
>Originator:     David Wolfskill
>Release:        FreeBSD 8.3-PRERELEASE i386
>Organization:
Wolfskill & Dowling Residence
>Environment:
System: FreeBSD g1-227.catwhisker.org 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #355 233868M: Wed Apr  4 04:16:15 PDT 2012     root at g1-227.catwhisker.org:/common/S1/obj/usr/src/sys/CANARY  i386

>Description:
	As discussed (e.g.) in
	<http://ubuntuforums.org/showthread.php?t=1047029>, if one uses
	nvidia-settings to make use of a second display, then disables
	the second display and disconnects it, a subsequent invocation
	of nvidia-settings (e.g., to connect a different display) may
	(will?) cause nvidia-settings to display a message such as:

	Unable to load X Server Display Configuration page:

	Failed to find display device 0x00000001 on screen 0 (on GPU-0)
	while parsing metamode:

	'CRT-0: nvidia-auto-select @1280x1024 +1440+0'


	if one tries to select "X Server Display Configuration".

	And at that point, it is no longer possible (in my experience,
	despite trying the circumventions mentioned in the above-cited
	ubuntuforums.org post) to perform any X Server Display
	Configuration using nvidia-settings --even if the display
	is re-attached ... unless one applies the attached patch
	and rebuilds nvidia-settings.


	A comment about the patch: it seemed to me that the existing
	behavior of nvidia-setting (whining and refusing to do anything
	because a display that used to be there wasn't there any more)
	was ... well, "unfortunate" (to say it politely).  So I changed
	the code to bypass displays that it can't find -- which seems to
	me to be ... well, almost sensible.


	I note that ideally, this change would be made upstream.  That,
	or some other change would be made upstream to fix the problem.
	In the mean time, the attached patch does resolve it for me,
	and we thus have a way to make the FreeBSD port usable despite
	the bug.

>How-To-Repeat:
	I think I covered it fairly well in Description.
>Fix:

	Drop the attached patch into the port's files directory as
	patch-ctkdisplayconfig-utils.c, then rebuild the port.

--- src/gtk+-2.x/ctkdisplayconfig-utils.c	2012-04-04 08:53:02.000000000 -0700
+++ src/gtk+-2.x/ctkdisplayconfig-utils.c	2012-04-04 08:59:26.000000000 -0700
@@ -1383,15 +1383,7 @@
         /* Match device bitmask to an existing display */
         display = gpu_get_display(screen->gpu, device_mask);
         if (!display) {
-            *err_str = g_strdup_printf("Failed to find display device 0x%08x "
-                                       "on screen %d (on GPU-%d)\nwhile "
-                                       "parsing metamode:\n\n'%s'",
-                                       device_mask,
-                                       screen->scrnum,
-                                       NvCtrlGetTargetId(screen->gpu->handle),
-                                       orig_mode_str);
-            nv_error_msg(*err_str);
-            goto fail;
+            continue;
         }
 
>Release-Note:
>Audit-Trail:
>Unformatted:



More information about the freebsd-ports-bugs mailing list