support for HW_SKIP_CONSOLE breaks use by blind people

[Timothy Meade]

On Jan 8, 2013 2:28 AM, "Peter Hutterer" <peter.hutterer at who-t.net> wrote:
>
> 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


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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.x.org/archives/xorg-devel/attachments/20130108/2226b39d/attachment-0001.html>