gdmgreeter exits if remote Xserver supports only RandR v1.1

[Uwe Geuder]

Binary package hint: gdm

1) $ lsb_release -rd
Description: Ubuntu 8.04.1
Release: 8.04

2) $ apt-cache policy gdm
gdm:
  Installed: 2.20.7-0ubuntu1.1
  Candidate: 2.20.7-0ubuntu1.1
  Version table:
 *** 2.20.7-0ubuntu1.1 0
        500 http://fi.archive.ubuntu.com hardy-updates/main Packages
        100 /var/lib/dpkg/status
     2.20.5-0ubuntu3 0
        500 http://fi.archive.ubuntu.com hardy/main Packages

3) What you expected to happen

 - enabled remote logins using gdmsetup, no other changes. (seems to default to gdmgreeter) (NB: This might make
your remote session vulnerable to attacks, don't do it if you don't understand the consequences)

- expected to be able login from a remote Xserver running XDMCP

4) What happened instead

Login screen was not displayed on remote Xserver

My debugging gave the following explanation

When talking to an X server supporting RandR v1.1 (instead of the current v1.2) gdmgreeter exits before displaying anything. There is no error message to the user.

With gdm [debug] Enable=True only 2 lines are found in syslog, which might be related to the problem

gdm[6110]: DEBUG: close_if_needed: Got G_IO_HUP on 9
gdm[6110]: DEBUG: close_if_needed: Got error on 9

However, these lines didn't tell me anything.
Using strace I found that gdmgreeter seems to be the culprit: (only lines looking important to me copied here)

open("/usr/share/X11/XErrorDB", O_RDONLY) = 6
read(6, "! $Xorg: XErrorDB,v 1.3 2000/08/"..., 37949) = 37949
close(6) = 0
write(2, "The program \'gdmgreeter\' receive"..., 583) = 583
exit_group(1)

However fd 2 seems to be /dev/null and I didn't find any information how to turn on logging.

(earlier)
open("/dev/null", O_RDWR) = 2

Using tcpdump/wireshark I found that the last request sent to the X server is RandR opcode 8. My X server replies with BadRequest. The Xserver is correct, because it supports only RandR v1.1 and opcode 8 was added for protocol version 1.2 (see http://gitweb.freedesktop.org/?p=xorg/proto/randrproto.git;f=randrproto.txt;a=blob)

Actually gdmgreeter queries the RandR version just before the bad request, but obviously it does not use the version information appropriately.

I'm not sure how common RandR v1.1 is these days. If the full support for the old protocol doesn't seem to be worth the effort, some better logging should be added. Alternatively, could gdmgreeter "fall back" to gdmlogin if the server supports only the old RandR protocol version?

Workaround: switch to gdmlogin. (Called "plain with facebrowser" in gdmsetup)

[Uwe Geuder (ubuntulp-ugeuder)]

Alternative work-around: Disable RandR altogether on your remote Xserver supporting only v1.1. gdmgreeter works fine now.

[Uwe Geuder (ubuntulp-ugeuder)]

The question is of course whether the bug is in gdmgreeter code proper or in some library it uses.

If anybody has some hints how to debug this? (maybe something easier than building gdmgreeter myself with debug indo and single-stepping through it)

[Sebastien Bacher (seb128)]

Thank you for your bug report

[Sebastien Bacher (seb128)]

could you try if that's still an issue in jaunty?

[Nathan Kidd (nathan-svn)]

This is still a problem with Jaunty:

(3) --> Request 145.0 QueryVersion (RANDR)
major_version 1
minor_version 3

(3) --> Request 145.8 GetScreenResources (RANDR)
window 0x59

(3) <-- Reply to Request 145.0 QueryVersion (RANDR)

sequence # 8 (578)
major_version 1
minor_version 1

[Sebastien Bacher (seb128)]

gdm has been rewritten in karmic so closing the bug, the new version uses a standard xorg session and should work if it doesn't open a new bug

[Nathan Kidd (nathan-svn)]

With the bug marked 'closed' for the next release, is there a policy for dealing with the brokenness that continues in 8.04 LTS, 8.10, and 9.04 ?