Created attachment 111383 [details]
Patch (commit 1 of 2): factor out for reuse a function to lookup device by bus ID

*Symptom*: startx (and xinit) from a virtual console (as root) fails to start the X server with the following error:

(EE) ARMSOC(0): ERROR: Cannot set the DRM interface version.
(EE) Screen(s) found, but none have a usable configuration.
Fatal server error: (EE) no screens found(EE)

This is with xf86-video-armsoc (both Arch package xf86-video-armsoc-git 1:219.f16b5c8-2 and xf86-video-armsoc-odroid 237.3bdf799-1) on Linux 3.8.13.28-3-ARCH armv7h on Samsung Exynos 4412 on Hardkernel Odroid U3 board. However, the problem is not strictly platform-specific (see below).

*The problem*: kernel drm module debug output (drm.debug=1 on kernel command line) shows that set version ioctl (nr=0x07) to the drm device from the armsoc driver fails with EACCESS (-13), see attached kernel log. This is because the armsoc driver's device file descriptor does not have the 'master' priviledge. The server opens the /dev/dri/card0 device through systemd-logind, which sets the server's file descriptor to be the master via ioctl nr=0x1e from systemd-logind process. Later, the armsoc driver opens the device, but its file
descriptor is not master because the server's descriptor is still open and is the master.

The device is opened via systemd-logind by the server during bus probing without regard to whether the driver SUPPORTS_SERVER_FD, i.e. does not explicitly open the device file but fetches the descriptor via an attribute initialized by the server. However, (only) if a non-SERVER_FD driver
does implement the 'platformProbe', then the server releases the file descriptor through the systemd-logind before further probing in the driver.
The armsoc driver does not implement 'platformProbe' and relies on fallback to 'Probe', the path on which the above release logic does not take place.

In summary, this problem seems to affect all drivers, like armsoc, that (1) do not SUPPORTS_SERVER_FD, and (2) do not implement the 'platformProbe' method but only the older 'Probe' method.

*Potential solutions* (both tested and make startx succeed):
(A) A workaround is to build the server with './configure --disable-systemd-logind'.
(B) Attached patchset moves the descriptor release logic slightly up the stack so that it applies to both drivers with 'platformProbe' and with 'Probe' instead of only to the former. Tested against recent xorg/xserver master 3b5be33fc55b3090d996014fa56603edb9c1d411.

*Details on patch*:

Original callchain:
    InitOutput
      xf86BusProbe
        xf86platformProbe
          xf86PlatformDeviceProbe
            get_drm_info
              systemd_logind_take_fd
        xf86BusConfig
          xf86CallDriverProbe
            platformProbeDev [if drv->platformProbe exists]
               probeSingleDevice            
                 doPlatformProbe
                   systemd_logind_release_fd [if not SUPPORTS_SERVER_FD]
                   drv->platformProbe
            drv->Probe [if drv->platformProbe does not exist]

Patched callchain:
      ...
      xf86CallDriverProbe
        systemd_logind_release_fd [if not SUPPORTS_SERVER_FD]
        platformProbeDev [if drv->platformProbe exists]
           probeSingleDevice            
             doPlatformProbe
               drv->platformProbe
        drv->Probe [if drv->platformProbe does not exist]

Attached is an Arch PKGBUILD for building the package and testing the patch (derived from https://projects.archlinux.org/svntogit/packages.git/tree/trunk?h=packages/xorg-server): makepkg -si PKGBUILD --asroot

*Sidenotes*:

(1) This problem is not fatal to display managers (LightDM), because the request for the file descriptor from the systemd-logind never succeeds in the first place, because association with a logind session fails: '(EE) systemd-logind: failed to get session: PID 8464 does not belong to any known session' in X server log.

(2) This problem happens to not manifest (as severely) if server is started on a virtual console different from the current session where startx is run, e.g. when running 'startx -- :0 vt3' on vt2. This is a sideeffect: the VT switch event triggers systemd-logind to 'pause' the drm device, which involves droping master, just in time before the armsoc driver needs it. The server does start but it ends up outside of an active logind session (the vt2 session goes from 'active' to 'online' state, and there is no other session created). As a result, input devices don't work. Running xserver in a non-controlling VT seems to run into separate issues (Bug 81932), in the present bug report the concern is with running it in the controlling VT.

(3) This problem affects LibDRM: the /dev/dri/card0 device is wrongly determined to be in use, because drmGetBusid returns a non-zero value, and is skipped, preventing server startup. See attached debug output from 'export LIBGL_DEBUG=verbose; startx'. To debug the original issue, libDRM was patched to override this 'in use' decision. This patch is not necessary once the underlying issue is fixed in the server.