support for HW_SKIP_CONSOLE breaks use by blind people

[Samuel Thibault]

Michal Suchanek, le Wed 09 Jan 2013 22:46:37 +0100, a écrit :
> On 9 January 2013 01:33, Samuel Thibault <samuel.thibault at ens-lyon.org> wrote:
> > Samuel Thibault, le Wed 09 Jan 2013 00:55:13 +0100, a écrit :
> >> Michal Suchanek, le Tue 08 Jan 2013 22:26:50 +0100, a écrit :
> >> > > Well, I hope I have made my point clear: the blind user case should
> >> > > get exactly the same behavior with the dummy video driver (without
> >> > > configuring anything else) as the 99%-standard user case, with other
> >> > > video drivers. I.e. a VT gets allocated, switched to, and keyboard/mouse
> >> > > events there go to the server.
> >> >
> >> > And what's the point?
> >> >
> >> > You don't have a screen so you don't see the VT switched.
> >>
> >> But I *NEED* the VT to be able to choose whether keyboard/mouse events
> >> go to the server or to the linux console.
> >
> > By switching into/out the VT, I mean.
> 
> VT switching it totally irrelevant for input.

>From a technical point of view in the evdev case, it is irrelevant
indeed. From the user point of view, it is completely relevant.

> It happens that X has currently only one routine that switches VT and
> modifies the VT mode so that only X server gets input. The two things
> are separate, however.

Technically speaking, yes. From the user point of view, it shall be
linked, otherwise he'll get lost.

> It is a bug that VT mode is not modified when dummy driver is used
> with the standard evdev driver. It is not a bug that the VT is not
> switched, however.

Sorry, but it is an unwelcome change of behavior for blind users. In the
past the server *would* switch VT.

> And I don't see that happening by default with the dummy driver.

s/happening/coming back/

Samuel