support for HW_SKIP_CONSOLE breaks use by blind people

[Michal Suchanek]

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.

Thanks

Michal