support for HW_SKIP_CONSOLE breaks use by blind people

[Peter Hutterer]

On Mon, Jan 07, 2013 at 01:43:16PM +0100, Michal Suchanek wrote:
> On 7 January 2013 05:08, Peter Hutterer <peter.hutterer at 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 <sthibault at 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