On Mon, Jan 07, 2013 at 01:43:16PM +0100, Michal Suchanek wrote: > On 7 January 2013 05:08, Peter Hutterer <peter.hutte...@who-t.net> 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 <sthiba...@debian.org> 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 -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130108063350.ga5...@yabbi.redhat.com