(In reply to ib from comment #0)
> Patch 44915d6953076849b69a017f6fc8234b0f254362 caused a regression.
> 
> When using xf86-input-keyboard for keyboard input without utilizing evdev,
> udev, hal, systemd-logind, X starts on the current tty, because the X server
> enables keeptty then (which is even forced with patch
> bd6cacdd36615e9b8136aeb86c3924a404785977 now).
> 
> This, however, prevents the linux kbd driver from working.

How exactly does this prevent the linux kbd driver from working? I don't see how keeptty would stop that from working ?

(In reply to Hans de Goede from comment #1)
> How exactly does this prevent the linux kbd driver from working? I don't see
> how keeptty would stop that from working ?

Well, I'm no expert for the linux kbd driver (Peter certainly is). What I experience is that pressing whatever key has no effect whatsoever, i.e. there seem to be either no key events or the events aren't captured. Preventing the server from detaching its initial controlling terminal doesn't seem to work with linux kbd and xf86-input-keyboard.

this is an xinit problem, not a startx problem. specfically, this line in  xinit.c:

          /*
           * prevent server from getting sighup from vhangup()
           * if client is xterm -L
           */
          setpgid(0,getpid());

just before the server is execvp'd. I can't find any reference to -L and vhangup() in the xterm sources, and this line dates back to the original import from xfree86.

An archaeological dig in the ancient X Consortium history has found a little more:

That bit of xinit goes back as far as our source history does, to the initial
integration in 1988:
http://cgit.freedesktop.org/~alanc/xc-historical/commit/xc/programs/xinit/xinit.c?id=6904d79e8aeb08a602779bfa0715153cc3ed3bd2

The -L flag was removed from xterm in 1989, but apparently no one remembered
the hack in xinit to work around it:
http://cgit.freedesktop.org/~alanc/xc-historical/commit/xc/programs/xterm?id=46fc268c21d01cf0d664c84e5d03f785b2b2e5ce

(In reply to Peter Hutterer from comment #3)
> this is an xinit problem, not a startx problem. specfically, this line in 
> xinit.c:

I don't mind a fix in xinit.c either, if I only get a working keyboard again.

ok, I spent most of the day trying to bisect this but there are too many moving targets and between rebooting and handling fs errors I gave up. Patch is on he list, it seems to make things work again but I don't understand why.

http://patchwork.freedesktop.org/patch/45505/

Hi,

(In reply to Peter Hutterer from comment #6)
> ok, I spent most of the day trying to bisect this but there are too many
> moving targets and between rebooting and handling fs errors I gave up. Patch
> is on he list, it seems to make things work again but I don't understand why.
> 
> http://patchwork.freedesktop.org/patch/45505/

I'm afraid that this causes a regression, with this patch the Xserver no
longer cleanly exits when the last client disconnects.

Test-case:

-Fully up2date 64 bit Fedora-22 system
-xinit rpm package build with this patch
-do: "startx /usr/bin/xterm -title foo"
-exit the shell in the xterm
-now Xorg hangs using aprox 100% cpu, strace shows that it
 sits in a select() loop

Regards,

Hans

commit 65739ef047233567e6053fc57464a42ffe69e989
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Wed Mar 25 13:37:09 2015 +1000

    linux: bring our process group to the foreground (#89653)