support for HW_SKIP_CONSOLE breaks use by blind people

Michal Suchanek hramrach at gmail.com
Sat Jan 5 13:47:20 PST 2013


On 5 January 2013 19:06, Samuel Thibault <sthibault at debian.org> 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.

I don't think that an actual VT switch is required but setting up the
VT so that the input is not interpreted by the kernel is. It would be
quite a few drivers to modify so perhaps making a server flag would be
useful.

On x86 there is always the ACPI button but on some platforms nothing
like that is present so this flag would have to be set dynamically
when an input device is plugged in if set bu the input driver. Also
evdev handles keyboards and mice. Is plugging in a mouse enough to
warrant locking the tty? Is presence of synaptics or wacom device?

Thanks

Michal


More information about the xorg-devel mailing list