support for HW_SKIP_CONSOLE breaks use by blind people

[Samuel Thibault]

Michal Suchanek, le Sat 05 Jan 2013 23:44:39 +0100, a écrit :
> On 5 January 2013 23:04, Samuel Thibault <sthibault at debian.org> wrote:
> > Michal Suchanek, le Sat 05 Jan 2013 22:47:20 +0100, a écrit :
> >> > 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
> >
> > From the point of the user, it is. There is no reason why it should not
> > happen just like with other video drivers in the use case at stake.
> 
> Those video drivers render graphics. The dummy driver does not.

But input drivers are still the same.

> It's not the same case.

>From the user point of view it is: the user simply does not have a
screen to plug to his computer, and does not need any, anway, but the
use case is *exactly* the same: a user sitting in front of his computer,
wants to start an X session.

> >> It would be quite a few drivers to modify
> >
> > We can proceed just like video devices: only modify the void input
> > driver into saying it doesn't need a VT, and the core then avoids
> > allocating a VT only if *only* the dummy video driver and void input
> > driver are used.
> 
> Indeed, you could possibly say that the dummy driver does not need
> video output which then requires a VT switch and the void driver does
> not need a tty input which would require locking the tty.

The former is already done (and is the whole reason why it broke things
for blind people).  I'm asking which way is recommended to do the
latter.

> >> 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?
> >
> > I'm surprised that the discussion ends up with this way of thinking:
> > shouldn't it be the converse, i.e. a VT is always allocated *except* if
> > that is explicitly asked for by a special configuration? Otherwise we'll
> > keep having users saying that their special use does not trigger a VT
> > allocation...
> 
> But there is the problem. The dummy driver sets the flag because it
> does not need the tty. The evdev driver does need the tty but it has
> no flag to set because opening a tty is the default. The bug comes
> exactly from the thinking that switching tty is the default and only
> an exception to this rule is flagged.

It has been so for decades.  It's hard to call that a bug.

> It would be much saner for the driver to say that it needs the tty if
> and when it needs it.

But as was mentioned, it'd mean patching *all* drivers, since it's a
behavior change. Thus the proposition of continuing the same way as was
done with video devices: not tell in which case it's needed, but in
which cases it's *not* needed.

Now, about the "when it needs it", unfortunately it's not so simple ATM:
the core opens the console just once in InitOutput.  I'm a bit afraid of
moving that (and conversely, the dontVTSwitch flag) somewhere else to
make it dynamic: who knows what subtle bug that might introduce.

Samuel