support for HW_SKIP_CONSOLE breaks use by blind people

[Peter Hutterer]

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.

Cheers,
   Peter


> Section "InputDevice"
> 	Identifier	"Generic Keyboard"
> 	Driver		"evdev"
> 	Option		"XkbModel"	"geniuskb19e"
> 	Option		"XkbLayout"	"fr,brai"
> 	Option		"XkbVariant"	"oss,"
> 	Option          "XkbOptions"    "compose:lwin,compose:rwin,nbsp:level3n,grp:shift_caps_toggle"
> EndSection
> 
> Section "InputDevice"
> 	Identifier	"Configured Mouse"
> 	Driver		"mouse"
> 	Option		"CorePointer"
> 	Option		"Device"		"/dev/gpmdata"
> 	Option		"Protocol"		"IntelliMouse"
> 	Option		"Emulate3Buttons"	"true"
> EndSection
> 
> Section "Device"
> 	Identifier	"Configured Video Device"
> 	Driver	"dummy"
> EndSection
> 
> Section "Monitor"
> 	Identifier	"Configured Monitor"
> EndSection