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