On Jan 8, 2013 2:28 AM, "Peter Hutterer" <<a href="mailto:peter.hutterer@who-t.net">peter.hutterer@who-t.net</a>> wrote: > > On Mon, Jan 07, 2013 at 01:43:16PM +0100, Michal Suchanek wrote: > > On 7 January 2013 05:08, Peter Hutterer <<a href="mailto:peter.hutterer@who-t.net">peter.hutterer@who-t.net</a>> wrote: > > > On Sat, Jan 05, 2013 at 07:06:05PM +0100, Samuel Thibault wrote: > > >> Michal Suchanek, le Sat 05 Jan 2013 18:55:28 +0100, a écrit : > > >> > On 5 January 2013 02:10, Samuel Thibault <<a href="mailto:sthibault@debian.org">sthibault@debian.org</a>> wrote: > > >> > > Alan Coopersmith, le Mon 31 Dec 2012 17:46:47 -0800, a écrit : > > >> > >> On 12/31/12 05:36 PM, Samuel Thibault wrote: > > >> > >> > Michal Suchanek, le Mon 31 Dec 2012 19:22:13 +0100, a écrit : > > >> > >> >> why is that patch needed? > > >> > >> >> > > >> > >> >> It is quite non-obvious why would dummy driver require a console under > > >> > >> >> any circumstances. It does not render anything anywhere so does not > > >> > >> >> use console for anything. > > >> > >> > > > >> > >> > The console *is* needed for keyboard input. > > >> > >> > > > >> > >> > Again, the use case is blind people who have use of possessing an actual > > >> > >> > screen, and thus don't have any, and thus have to use the dummy driver. > > >> > >> > > >> > >> So it sounds like that should be handled by the input driver, not the > > >> > >> output driver. > > >> > > > > >> > > Ok, that makes sense. Input drivers however don't currently have a way > > >> > > to request the core to callxf86OpenConsole, similar to the absence of > > >> > > the HW_SKIP_CONSOLE flag in the case of video drivers. > > >> > > > > >> > > What do you recommend to add to the InputDriverRec? A driverFunc method > > >> > > like video drivers? Something else? > > >> > > > >> > I still don't understand the problem. The evdev driver opens the evdev > > >> > device when loaded and reads input there. That happens even with dummy > > >> > video driver so long as you do not carefully prevent the evdev driver > > >> > from loading, does it not? > > >> > > >> It does not. See for instance the attached xorg.conf, then I run from > > >> vt1 > > >> > > >> xinit /usr/bin/fvwm -- :1 > > >> > > >> there is no VT switch, and pressing ^C 5s later kills the server (while > > >> we'd want ^C to just go to the server). The resulting Xorg.1.log is > > >> attached. > > > > > > while it shows the issue, this is not a good example. the config section for > > > the keyboard isn't referenced from the layout so it doesn't apply, and the > > > config for the mouse is ignored because input hotplugging is enabled. so > > > only the dummy driver section applies, the rest of this config has no effect. > > > > > >> What I understand is that evedev does open things, but since no VT was > > >> allocated, the evdev driver does not eat keypresses, i.e. from its point > > >> of view it's as if we had switched away from an allocated VT. > > > > > > evdev reads data off /dev/input/eventX and it doesn't need a console. > > > > > > but without xf86OpenConsole() and ioctl(KDSKBMODE), the events are also > > > sent to the console. this is your real problem, since both get the event and > > > you can kill your server. we've had this issue years back after switching to > > > evdev as standard driver, and then when we removed the EVIOCGRAB from evdev. > > > > > >> So what Alan suggested is that the evdev driver simply tells the core > > >> that it needs a VT to work properly. I'm now just asking which way that > > >> should be done. > > > > > > I'm not sure this is the right approach. evdev doesn't need a VT to work > > > properly, I've got a use-case here (automated testing) that works perfectly > > > well without a VT. plus, with hotplugging you don't actually know if and > > > when an evdev device will be added. > > > > > > so the solution here would be to only call xf86OpenConsole() when a keyboard > > > device comes up. on the plus side, if the evdev driver is broken this would > > > allow you to Ctrl+C the server. On the minus side, there's a window where > > > you can Ctrl+C the server until the device has been added. > > > > > > your use-case (or mine, depending on your POV) seems to need not a console > > > switch but an option to enable/disable keyboard input from being sent to the > > > console. this is the solution we should be looking at, imo. > > > > The evdev driver is loaded and can tell anything to the X server only > > when an evdev device is detected. > > > > Note that on x86 it is always loaded to handle acpi button but on > > other platforms it may be loaded only when an actual input device is > > attached. > > > > So even with hotpulg if it was the evdev driver telling the X server > > it would tell it only when a device actually exists. > > > > Also it is not sufficient to grab the terminal when a keyboard > > appears. Mice are also used by the terminal and arbitrary action can > > be performed by terminal program receiving the mouse input. I am not > > sure how this is arbitrated but since there is no problem now the > > current code in X server presumably takes care of that also when > > invoked. > > > > Note that almost every input driver except void requires that the X > > server prevents the terminal form reciving input including kbd, > > synaptics, wacom, .. Only complex pointing devices that do not have > > mouse-compatible fallback do not require that. I am not sure the X > > server supports any at this time. > > fwiw, the reason synaptics and wacom stop the terminal from receiving input > is a side-effect and not a primary motivation. the grab we put on the device is to > avoid duplicate devices in X (e.g. device added with /dev/input/wacom and > /dev/input/event0 both being added as separate devices), not so much any > worry about the console. we're at a point where both drivers work just fine > without the grab - at least in the default configurations. > > Cheers, > Peter Maybe I'm missing something, auto detecting if VT switch is needed means introducing an inconsistencty. Dummy and evdev can both work without allocating a VT, and there are cases where that may be useful, such as debugging a server or input driver. Would an explict -forcetty or -forcevtalloc be an option? There are already distro specific configuration scripts for setting up Linux for blind user, could they add this option when they configure the dummy output?