bug#5938: Unnecessary fail when XGetVisualInfo returns multiple records

bug#5938: Unnecessary fail when XGetVisualInfo returns multiple records

[Lynn Winebarger]

Package: emacs
Version: 23.1.50; 23.1.1; 22.2.1

When invoking emacs on a remote session using Xephyr, it responds
emacs: Can't get proper X visual info
In version 22 there is a newline after the message, in version 23
there is no newline.

I've traced the problem to the function select_visual in the file xfns.c.  If
the resource database does not specify a preference, it attempts to use
the default visual by getting a screen number and visual id from the supplied
dpyinfo structure.

For some reason Xephyr returns multiple records corresponding to the
same visual id.
This shows up in xpdyinfo as well, output at the end of this email.
The default id is 0x21,
and there are two identical entries for it.  Every other visual id has
a single record.
The offending code is in this block:
    {
      int n_visuals;
      XVisualInfo *vinfo, vinfo_template;

      dpyinfo->visual = DefaultVisualOfScreen (screen);

      vinfo_template.visualid = XVisualIDFromVisual (dpyinfo->visual);
      vinfo_template.screen = XScreenNumberOfScreen (screen);
      vinfo = XGetVisualInfo (dpy, VisualIDMask | VisualScreenMask,
                              &vinfo_template, &n_visuals);
      if (n_visuals != 1)    /* PROBLEM */
        fatal ("Can't get proper X visual info");

      dpyinfo->n_planes = vinfo->depth;
      XFree ((char *) vinfo);
    }
It seems that simply checking for n_visuals>1 would be sufficient.  In
this particular bug,
the 2 XVisualInfo structures returned are actually identical,
including pointing to the same
Visual structure.

output of xdpyinfo:
[lynn@heraclitus /usr/local/share/doc/X11-1.4.5]$ xdpyinfo -display :1
name of display:    :1.0
version number:    11.0
vendor string:    The X.Org Foundation
vendor release number:    10601000
X.Org version: 1.6.1
maximum request size:  16777212 bytes
motion buffer size:  256
bitmap unit, bit order, padding:    32, LSBFirst, 32
image byte order:    LSBFirst
number of supported pixmap formats:    7
supported pixmap formats:
    depth 1, bits_per_pixel 1, scanline_pad 32
    depth 4, bits_per_pixel 4, scanline_pad 32
    depth 8, bits_per_pixel 8, scanline_pad 32
    depth 15, bits_per_pixel 16, scanline_pad 32
    depth 16, bits_per_pixel 16, scanline_pad 32
    depth 24, bits_per_pixel 32, scanline_pad 32
    depth 32, bits_per_pixel 32, scanline_pad 32
keycode range:    minimum 8, maximum 255
focus:  window 0x2e0ccc3, revert to Parent
number of extensions:    23
    BIG-REQUESTS
    Composite
    DAMAGE
    DOUBLE-BUFFER
    DPMS
    GLX
    Generic Event Extension
    MIT-SCREEN-SAVER
    MIT-SHM
    RANDR
    RENDER
    SGI-GLX
    SHAPE
    SYNC
    X-Resource
    XC-MISC
    XFIXES
    XFree86-DRI
    XINERAMA
    XInputExtension
    XKEYBOARD
    XTEST
    XVideo
default screen number:    0
number of screens:    1

screen #0:
  print screen:    no
  dimensions:    1024x768 pixels (347x260 millimeters)
  resolution:    75x75 dots per inch
  depths (7):    1, 4, 8, 15, 16, 24, 32
  root window id:    0xdf
  depth of root window:    24 planes
  number of colormaps:    minimum 1, maximum 1
  default colormap:    0x20
  default number of colormap cells:    256
  preallocated pixels:    black 0, white 16777215
  options:    backing-store NO, save-unders NO
  largest cursor:    1024x768
  current input event mask:    0xfa8033
    KeyPressMask             KeyReleaseMask           EnterWindowMask
    LeaveWindowMask          ExposureMask             StructureNotifyMask
    SubstructureNotifyMask   SubstructureRedirectMask FocusChangeMask
    PropertyChangeMask       ColormapChangeMask
  number of visuals:    99
  default visual id:  0x21
  visual:
    visual id:    0x21
    class:    TrueColor
    depth:    24 planes
    available colormap entries:    256 per subfield
    red, green, blue masks:    0xff0000, 0xff00, 0xff
    significant bits in color specification:    8 bits
  visual:
    visual id:    0x21
    class:    TrueColor
    depth:    24 planes
    available colormap entries:    256 per subfield
    red, green, blue masks:    0xff0000, 0xff00, 0xff
    significant bits in color specification:    8 bits
  visual:
    visual id:    0x22
    class:    DirectColor
    depth:    24 planes
    available colormap entries:    256 per subfield
    red, green, blue masks:    0xff0000, 0xff00, 0xff
    significant bits in color specification:    8 bits
  visual:
    visual id:    0xd3
    class:    TrueColor
    depth:    24 planes
    available colormap entries:    256 per subfield
    red, green, blue masks:    0xff0000, 0xff00, 0xff
    significant bits in color specification:    8 bits
  visual:
    visual id:    0xd4
    class:    TrueColor
    depth:    24 planes
    available colormap entries:    256 per subfield
    red, green, blue masks:    0xff0000, 0xff00, 0xff
    significant bits in color specification:    8 bits
  visual:
    visual id:    0xd5
    class:    TrueColor
    depth:    24 planes
    available colormap entries:    256 per subfield
    red, green, blue masks:    0xff0000, 0xff00, 0xff
    significant bits in color specification:    8 bits
[...]

bug#5938: Unnecessary fail when XGetVisualInfo returns multiple records

[Jan Djärv]

Lynn Winebarger skrev:
> Package: emacs
> Version: 23.1.50; 23.1.1; 22.2.1
> 
> When invoking emacs on a remote session using Xephyr, it responds
> emacs: Can't get proper X visual info
> In version 22 there is a newline after the message, in version 23
> there is no newline.
> 
> I've traced the problem to the function select_visual in the file xfns.c.  If
> the resource database does not specify a preference, it attempts to use
> the default visual by getting a screen number and visual id from the supplied
> dpyinfo structure.
> 
> For some reason Xephyr returns multiple records corresponding to the
> same visual id.
> This shows up in xpdyinfo as well, output at the end of this email.
> The default id is 0x21,
> and there are two identical entries for it.  Every other visual id has
> a single record.

It sounds like a bug to return two identical visuals, I haven't seen that widh 
Xephyr.  But in any case, Emacs should not abort.  On the whole, the whole 
checking of visual is kind of redundant anyway, DefaultVisualOfScreen shall 
always exist.

Fix checked in.

	Jan D.