Debian Bug report logs - #696965
support for HW_SKIP_CONSOLE breaks use by blind people

version graph

Package: xserver-xorg-video-dummy; Maintainer for xserver-xorg-video-dummy is Debian X Strike Force <debian-x@lists.debian.org>; Source for xserver-xorg-video-dummy is src:xserver-xorg-video-dummy.

Reported by: Samuel Thibault <samuel.thibault@ens-lyon.org>

Date: Sun, 30 Dec 2012 00:09:01 UTC

Severity: important

Tags: patch, upstream

Found in version xserver-xorg-video-dummy/1:0.3.3-2

Forwarded to xorg-devel@lists.x.org

Reply or subscribe to this bug.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, xorg-devel@lists.x.org, Debian X Strike Force <debian-x@lists.debian.org>:
Bug#696965; Package xserver-xorg-video-dummy. (Sun, 30 Dec 2012 00:09:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Samuel Thibault <samuel.thibault@ens-lyon.org>:
New Bug report received and forwarded. Copy sent to xorg-devel@lists.x.org, Debian X Strike Force <debian-x@lists.debian.org>. (Sun, 30 Dec 2012 00:09:04 GMT) Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Samuel Thibault <samuel.thibault@ens-lyon.org>
To: submit@bugs.debian.org
Subject: support for HW_SKIP_CONSOLE breaks use by blind people
Date: Sun, 30 Dec 2012 01:07:47 +0100
[Message part 1 (text/plain, inline)]
Package: xserver-xorg-video-dummy
Version: 1:0.3.3-2
Severity: important
Tags: upstream

Hello,

Unfortunately I've gotten the bug report only now...

In upstream commit e39d9a26

@@ -801,7 +804,7 @@ dummyDriverFunc(ScrnInfoPtr pScrn, xorgDriverFuncOp op, pointer ptr)
+           (*flag) = HW_SKIP_CONSOLE;

This has broken the use of Xorg by blind people who don't have a screen:
since drivers tend to abort when no screen is connected, blind people
would use the dummy driver.  But now that the dummy driver itself tells
not to open the console, keypresses are not eaten by the Xorg server,
thus making the whole Xorg session completely unusable.

What was the rationale for the change?  I can understand that in some
situation people would not want to open the console, but I would have
rather made it an option, and have made it not enabled by default,
because the blind people who need the dummy driver do not necessarily
have much technical knowledge beyond "use the dummy driver", while
people who want to use the dummy driver with no VT most probably
understand what that means, and would be able to enable the option.

This was unfortunately actually already shipped in Squeeze.  The attached
patch can be used by people for now to avoid the issue, I'll work on
adding an option upstream.

Samuel
[patch (text/plain, attachment)]

Set Bug forwarded-to-address to 'xorg-devel@lists.x.org'. Request was from Samuel Thibault <sthibault@debian.org> to control@bugs.debian.org. (Sun, 30 Dec 2012 00:27:18 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian X Strike Force <debian-x@lists.debian.org>:
Bug#696965; Package xserver-xorg-video-dummy. (Sun, 30 Dec 2012 03:12:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Samuel Thibault <sthibault@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian X Strike Force <debian-x@lists.debian.org>. (Sun, 30 Dec 2012 03:12:03 GMT) Full text and rfc822 format available.

Message #12 received at 696965@bugs.debian.org (full text, mbox):

From: Samuel Thibault <sthibault@debian.org>
To: 696965@bugs.debian.org, xorg-devel@lists.x.org
Subject: [PATCH] support for HW_SKIP_CONSOLE breaks use by blind people
Date: Sun, 30 Dec 2012 04:09:51 +0100
Control: tags 696965 + patch

Hello,

Samuel Thibault, le Sun 30 Dec 2012 01:07:47 +0100, a écrit :
> I would have rather made it an option, and have made it not enabled
> by default, because the blind people who need the dummy driver do
> not necessarily have much technical knowledge beyond "use the dummy
> driver", while people who want to use the dummy driver with no VT most
> probably understand what that means, and would be able to enable the
> option.

Here is a patch proposal.

Samuel



Add OpenConsole option to dummy devices

This permits to choose whether the dummy device wants the console. The
driver will make the core open the console if at least one device wants
it.

Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>

diff --git a/src/dummy_driver.c b/src/dummy_driver.c
index 6062c39..0ec5f4b 100644
--- a/src/dummy_driver.c
+++ b/src/dummy_driver.c
@@ -118,11 +118,13 @@ static SymTabRec DUMMYChipsets[] = {
 };
 
 typedef enum {
-    OPTION_SW_CURSOR
+    OPTION_SW_CURSOR,
+    OPTION_OPEN_CONSOLE
 } DUMMYOpts;
 
 static const OptionInfoRec DUMMYOptions[] = {
     { OPTION_SW_CURSOR,	"SWcursor",	OPTV_BOOLEAN,	{0}, FALSE },
+    { OPTION_OPEN_CONSOLE,	"OpenConsole",	OPTV_BOOLEAN,	{0}, FALSE },
     { -1,                  NULL,           OPTV_NONE,	{0}, FALSE }
 };
 
@@ -812,9 +814,36 @@ dummyDriverFunc(ScrnInfoPtr pScrn, xorgDriverFuncOp op, pointer ptr)
     
     switch (op) {
 	case GET_REQUIRED_HW_INTERFACES:
+	{
+	    Bool OpenConsole = FALSE;
+	    GDevPtr *devSections;
+	    int numDevSections, i;
+
+	    /*
+	     * Find the config file Device sections that match this
+	     * driver
+	     */
+	    numDevSections = xf86MatchDevice(DUMMY_DRIVER_NAME, &devSections);
+
+	    for (i = 0; i < numDevSections; i++) {
+		OptionInfoPtr Options;
+
+		if ((Options = malloc(sizeof(DUMMYOptions))))
+		{
+		    Bool DeviceOpenConsole = TRUE;
+		    memcpy(Options, DUMMYOptions, sizeof(DUMMYOptions));
+		    xf86ProcessOptions(-1, devSections[i]->options, Options);
+		    xf86GetOptValBool(Options, OPTION_OPEN_CONSOLE, &DeviceOpenConsole);
+		    if (DeviceOpenConsole)
+			OpenConsole = TRUE;
+		    free(Options);
+		}
+	    }
+
 	    flag = (CARD32*)ptr;
-	    (*flag) = HW_SKIP_CONSOLE;
+	    (*flag) = OpenConsole ? 0 : HW_SKIP_CONSOLE;
 	    return TRUE;
+	}
 	default:
 	    return FALSE;
     }



Added tag(s) patch. Request was from Samuel Thibault <sthibault@debian.org> to 696965-submit@bugs.debian.org. (Sun, 30 Dec 2012 03:12:03 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian X Strike Force <debian-x@lists.debian.org>:
Bug#696965; Package xserver-xorg-video-dummy. (Mon, 31 Dec 2012 18:27:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Michal Suchanek <hramrach@gmail.com>:
Extra info received and forwarded to list. Copy sent to Debian X Strike Force <debian-x@lists.debian.org>. (Mon, 31 Dec 2012 18:27:03 GMT) Full text and rfc822 format available.

Message #19 received at 696965@bugs.debian.org (full text, mbox):

From: Michal Suchanek <hramrach@gmail.com>
To: Samuel Thibault <sthibault@debian.org>, 696965@bugs.debian.org, xorg-devel@lists.x.org
Subject: Re: [PATCH] support for HW_SKIP_CONSOLE breaks use by blind people
Date: Mon, 31 Dec 2012 19:22:13 +0100
Hello,

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.

Thanks

Michal



Information forwarded to debian-bugs-dist@lists.debian.org, Debian X Strike Force <debian-x@lists.debian.org>:
Bug#696965; Package xserver-xorg-video-dummy. (Tue, 01 Jan 2013 00:27:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Cyril Brulebois <kibi@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian X Strike Force <debian-x@lists.debian.org>. (Tue, 01 Jan 2013 00:27:03 GMT) Full text and rfc822 format available.

Message #24 received at 696965@bugs.debian.org (full text, mbox):

From: Cyril Brulebois <kibi@debian.org>
To: Michal Suchanek <hramrach@gmail.com>, 696965@bugs.debian.org
Cc: Samuel Thibault <sthibault@debian.org>, xorg-devel@lists.x.org
Subject: Re: Bug#696965: [PATCH] support for HW_SKIP_CONSOLE breaks use by blind people
Date: Tue, 1 Jan 2013 01:23:15 +0100
[Message part 1 (text/plain, inline)]
Michal Suchanek <hramrach@gmail.com> (31/12/2012):
> 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 commit message probably {c,sh}ould include some bits of the
initial bug report (http://bugs.debian.org/696965); that should answer
your question.

Mraw,
KiBi.
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian X Strike Force <debian-x@lists.debian.org>:
Bug#696965; Package xserver-xorg-video-dummy. (Tue, 01 Jan 2013 01:39:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Samuel Thibault <sthibault@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian X Strike Force <debian-x@lists.debian.org>. (Tue, 01 Jan 2013 01:39:03 GMT) Full text and rfc822 format available.

Message #29 received at 696965@bugs.debian.org (full text, mbox):

From: Samuel Thibault <sthibault@debian.org>
To: Michal Suchanek <hramrach@gmail.com>
Cc: 696965@bugs.debian.org, xorg-devel@lists.x.org
Subject: Re: [PATCH] support for HW_SKIP_CONSOLE breaks use by blind people
Date: Tue, 1 Jan 2013 02:36:57 +0100
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.

Samuel



Information forwarded to debian-bugs-dist@lists.debian.org, Debian X Strike Force <debian-x@lists.debian.org>:
Bug#696965; Package xserver-xorg-video-dummy. (Tue, 01 Jan 2013 02:21:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Alan Coopersmith <alan.coopersmith@oracle.com>:
Extra info received and forwarded to list. Copy sent to Debian X Strike Force <debian-x@lists.debian.org>. (Tue, 01 Jan 2013 02:21:03 GMT) Full text and rfc822 format available.

Message #34 received at 696965@bugs.debian.org (full text, mbox):

From: Alan Coopersmith <alan.coopersmith@oracle.com>
To: Samuel Thibault <sthibault@debian.org>, Michal Suchanek <hramrach@gmail.com>, 696965@bugs.debian.org, xorg-devel@lists.x.org
Subject: Re: [PATCH] support for HW_SKIP_CONSOLE breaks use by blind people
Date: Mon, 31 Dec 2012 17:46:47 -0800
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.

People who want to use dummy output with real input should have input
devices configured - those who want an Xvfb like experience can use
the dummy video driver and either use the void input driver or configure
their servers to have no input drivers loaded.

-- 
	-Alan Coopersmith-              alan.coopersmith@oracle.com
	 Oracle Solaris Engineering - http://blogs.oracle.com/alanc



Information forwarded to debian-bugs-dist@lists.debian.org, Debian X Strike Force <debian-x@lists.debian.org>:
Bug#696965; Package xserver-xorg-video-dummy. (Sat, 05 Jan 2013 01:15:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Samuel Thibault <sthibault@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian X Strike Force <debian-x@lists.debian.org>. (Sat, 05 Jan 2013 01:15:03 GMT) Full text and rfc822 format available.

Message #39 received at 696965@bugs.debian.org (full text, mbox):

From: Samuel Thibault <sthibault@debian.org>
To: Alan Coopersmith <alan.coopersmith@oracle.com>
Cc: Michal Suchanek <hramrach@gmail.com>, 696965@bugs.debian.org, xorg-devel@lists.x.org
Subject: Re: support for HW_SKIP_CONSOLE breaks use by blind people
Date: Sat, 5 Jan 2013 02:10:28 +0100
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?

Samuel



Information forwarded to debian-bugs-dist@lists.debian.org, Debian X Strike Force <debian-x@lists.debian.org>:
Bug#696965; Package xserver-xorg-video-dummy. (Sat, 05 Jan 2013 17:57:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Michal Suchanek <hramrach@gmail.com>:
Extra info received and forwarded to list. Copy sent to Debian X Strike Force <debian-x@lists.debian.org>. (Sat, 05 Jan 2013 17:57:03 GMT) Full text and rfc822 format available.

Message #44 received at 696965@bugs.debian.org (full text, mbox):

From: Michal Suchanek <hramrach@gmail.com>
To: Samuel Thibault <sthibault@debian.org>, Alan Coopersmith <alan.coopersmith@oracle.com>, Michal Suchanek <hramrach@gmail.com>, 696965@bugs.debian.org, xorg-devel@lists.x.org
Subject: Re: support for HW_SKIP_CONSOLE breaks use by blind people
Date: Sat, 5 Jan 2013 18:55:28 +0100
On 5 January 2013 02:10, Samuel Thibault <sthibault@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?

Thanks

Michal



Information forwarded to debian-bugs-dist@lists.debian.org, Debian X Strike Force <debian-x@lists.debian.org>:
Bug#696965; Package xserver-xorg-video-dummy. (Sat, 05 Jan 2013 18:09:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Samuel Thibault <sthibault@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian X Strike Force <debian-x@lists.debian.org>. (Sat, 05 Jan 2013 18:09:03 GMT) Full text and rfc822 format available.

Message #49 received at 696965@bugs.debian.org (full text, mbox):

From: Samuel Thibault <sthibault@debian.org>
To: Michal Suchanek <hramrach@gmail.com>
Cc: Alan Coopersmith <alan.coopersmith@oracle.com>, 696965@bugs.debian.org, xorg-devel@lists.x.org
Subject: Re: support for HW_SKIP_CONSOLE breaks use by blind people
Date: Sat, 5 Jan 2013 19:06:05 +0100
[Message part 1 (text/plain, inline)]
Michal Suchanek, le Sat 05 Jan 2013 18:55:28 +0100, a écrit :
> On 5 January 2013 02:10, Samuel Thibault <sthibault@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.

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.

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.

Samuel
[xorg.conf (text/plain, attachment)]
[Xorg.1.log (text/plain, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian X Strike Force <debian-x@lists.debian.org>:
Bug#696965; Package xserver-xorg-video-dummy. (Sat, 05 Jan 2013 21:51:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Michal Suchanek <hramrach@gmail.com>:
Extra info received and forwarded to list. Copy sent to Debian X Strike Force <debian-x@lists.debian.org>. (Sat, 05 Jan 2013 21:51:03 GMT) Full text and rfc822 format available.

Message #54 received at 696965@bugs.debian.org (full text, mbox):

From: Michal Suchanek <hramrach@gmail.com>
To: Samuel Thibault <sthibault@debian.org>, Michal Suchanek <hramrach@gmail.com>, Alan Coopersmith <alan.coopersmith@oracle.com>, 696965@bugs.debian.org, xorg-devel@lists.x.org
Subject: Re: support for HW_SKIP_CONSOLE breaks use by blind people
Date: Sat, 5 Jan 2013 22:47:20 +0100
On 5 January 2013 19:06, Samuel Thibault <sthibault@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@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



Information forwarded to debian-bugs-dist@lists.debian.org, Debian X Strike Force <debian-x@lists.debian.org>:
Bug#696965; Package xserver-xorg-video-dummy. (Sat, 05 Jan 2013 22:09:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Samuel Thibault <sthibault@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian X Strike Force <debian-x@lists.debian.org>. (Sat, 05 Jan 2013 22:09:03 GMT) Full text and rfc822 format available.

Message #59 received at 696965@bugs.debian.org (full text, mbox):

From: Samuel Thibault <sthibault@debian.org>
To: Michal Suchanek <hramrach@gmail.com>
Cc: Alan Coopersmith <alan.coopersmith@oracle.com>, 696965@bugs.debian.org, xorg-devel@lists.x.org
Subject: Re: support for HW_SKIP_CONSOLE breaks use by blind people
Date: Sat, 5 Jan 2013 23:04:24 +0100
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.

> 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.

> 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...

Samuel



Information forwarded to debian-bugs-dist@lists.debian.org, Debian X Strike Force <debian-x@lists.debian.org>:
Bug#696965; Package xserver-xorg-video-dummy. (Sat, 05 Jan 2013 22:48:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Michal Suchanek <hramrach@gmail.com>:
Extra info received and forwarded to list. Copy sent to Debian X Strike Force <debian-x@lists.debian.org>. (Sat, 05 Jan 2013 22:48:03 GMT) Full text and rfc822 format available.

Message #64 received at 696965@bugs.debian.org (full text, mbox):

From: Michal Suchanek <hramrach@gmail.com>
To: Samuel Thibault <sthibault@debian.org>, Michal Suchanek <hramrach@gmail.com>, Alan Coopersmith <alan.coopersmith@oracle.com>, 696965@bugs.debian.org, xorg-devel@lists.x.org
Subject: Re: support for HW_SKIP_CONSOLE breaks use by blind people
Date: Sat, 5 Jan 2013 23:44:39 +0100
On 5 January 2013 23:04, Samuel Thibault <sthibault@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. It's
not the same case.

>
>> 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.

>
>> 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 would be much saner for the
driver to say that it needs the tty if and when it needs it.

Thanks

Michal



Information forwarded to debian-bugs-dist@lists.debian.org, Debian X Strike Force <debian-x@lists.debian.org>:
Bug#696965; Package xserver-xorg-video-dummy. (Sat, 05 Jan 2013 22:57:07 GMT) Full text and rfc822 format available.

Acknowledgement sent to Samuel Thibault <sthibault@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian X Strike Force <debian-x@lists.debian.org>. (Sat, 05 Jan 2013 22:57:07 GMT) Full text and rfc822 format available.

Message #69 received at 696965@bugs.debian.org (full text, mbox):

From: Samuel Thibault <sthibault@debian.org>
To: Michal Suchanek <hramrach@gmail.com>
Cc: Alan Coopersmith <alan.coopersmith@oracle.com>, 696965@bugs.debian.org, xorg-devel@lists.x.org
Subject: Re: support for HW_SKIP_CONSOLE breaks use by blind people
Date: Sat, 5 Jan 2013 23:52:53 +0100
Michal Suchanek, le Sat 05 Jan 2013 23:44:39 +0100, a écrit :
> On 5 January 2013 23:04, Samuel Thibault <sthibault@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



Information forwarded to debian-bugs-dist@lists.debian.org, Debian X Strike Force <debian-x@lists.debian.org>:
Bug#696965; Package xserver-xorg-video-dummy. (Sat, 05 Jan 2013 22:57:09 GMT) Full text and rfc822 format available.

Acknowledgement sent to Samuel Thibault <sthibault@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian X Strike Force <debian-x@lists.debian.org>. (Sat, 05 Jan 2013 22:57:09 GMT) Full text and rfc822 format available.

Message #74 received at 696965@bugs.debian.org (full text, mbox):

From: Samuel Thibault <sthibault@debian.org>
To: Michal Suchanek <hramrach@gmail.com>, Alan Coopersmith <alan.coopersmith@oracle.com>, 696965@bugs.debian.org, xorg-devel@lists.x.org
Subject: Re: support for HW_SKIP_CONSOLE breaks use by blind people
Date: Sat, 5 Jan 2013 23:55:35 +0100
Samuel Thibault, le Sat 05 Jan 2013 23:52:53 +0100, a écrit :
> Michal Suchanek, le Sat 05 Jan 2013 23:44:39 +0100, a écrit :
> > On 5 January 2013 23:04, Samuel Thibault <sthibault@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.

(and just work with it immediately. Having an actual output or not does
not change the matter).

Samuel



Information forwarded to debian-bugs-dist@lists.debian.org, Debian X Strike Force <debian-x@lists.debian.org>:
Bug#696965; Package xserver-xorg-video-dummy. (Mon, 07 Jan 2013 04:30:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Peter Hutterer <peter.hutterer@who-t.net>:
Extra info received and forwarded to list. Copy sent to Debian X Strike Force <debian-x@lists.debian.org>. (Mon, 07 Jan 2013 04:30:05 GMT) Full text and rfc822 format available.

Message #79 received at 696965@bugs.debian.org (full text, mbox):

From: Peter Hutterer <peter.hutterer@who-t.net>
To: Samuel Thibault <sthibault@debian.org>, Michal Suchanek <hramrach@gmail.com>, Alan Coopersmith <alan.coopersmith@oracle.com>, 696965@bugs.debian.org, xorg-devel@lists.x.org
Subject: Re: support for HW_SKIP_CONSOLE breaks use by blind people
Date: Mon, 7 Jan 2013 14:08:32 +1000
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@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.

Cheers,
   Peter


> Section "InputDevice"
> 	Identifier	"Generic Keyboard"
> 	Driver		"evdev"
> 	Option		"XkbModel"	"geniuskb19e"
> 	Option		"XkbLayout"	"fr,brai"
> 	Option		"XkbVariant"	"oss,"
> 	Option          "XkbOptions"    "compose:lwin,compose:rwin,nbsp:level3n,grp:shift_caps_toggle"
> EndSection
> 
> Section "InputDevice"
> 	Identifier	"Configured Mouse"
> 	Driver		"mouse"
> 	Option		"CorePointer"
> 	Option		"Device"		"/dev/gpmdata"
> 	Option		"Protocol"		"IntelliMouse"
> 	Option		"Emulate3Buttons"	"true"
> EndSection
> 
> Section "Device"
> 	Identifier	"Configured Video Device"
> 	Driver	"dummy"
> EndSection
> 
> Section "Monitor"
> 	Identifier	"Configured Monitor"
> EndSection




Information forwarded to debian-bugs-dist@lists.debian.org, Debian X Strike Force <debian-x@lists.debian.org>:
Bug#696965; Package xserver-xorg-video-dummy. (Mon, 07 Jan 2013 12:45:07 GMT) Full text and rfc822 format available.

Acknowledgement sent to Michal Suchanek <hramrach@gmail.com>:
Extra info received and forwarded to list. Copy sent to Debian X Strike Force <debian-x@lists.debian.org>. (Mon, 07 Jan 2013 12:45:07 GMT) Full text and rfc822 format available.

Message #84 received at 696965@bugs.debian.org (full text, mbox):

From: Michal Suchanek <hramrach@gmail.com>
To: Peter Hutterer <peter.hutterer@who-t.net>
Cc: Samuel Thibault <sthibault@debian.org>, Alan Coopersmith <alan.coopersmith@oracle.com>, 696965@bugs.debian.org, xorg-devel@lists.x.org
Subject: Re: support for HW_SKIP_CONSOLE breaks use by blind people
Date: Mon, 7 Jan 2013 13:43:16 +0100
On 7 January 2013 05:08, Peter Hutterer <peter.hutterer@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@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



Information forwarded to debian-bugs-dist@lists.debian.org, Debian X Strike Force <debian-x@lists.debian.org>:
Bug#696965; Package xserver-xorg-video-dummy. (Tue, 08 Jan 2013 06:36:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Peter Hutterer <peter.hutterer@who-t.net>:
Extra info received and forwarded to list. Copy sent to Debian X Strike Force <debian-x@lists.debian.org>. (Tue, 08 Jan 2013 06:36:03 GMT) Full text and rfc822 format available.

Message #89 received at 696965@bugs.debian.org (full text, mbox):

From: Peter Hutterer <peter.hutterer@who-t.net>
To: Michal Suchanek <hramrach@gmail.com>
Cc: Samuel Thibault <sthibault@debian.org>, Alan Coopersmith <alan.coopersmith@oracle.com>, 696965@bugs.debian.org, xorg-devel@lists.x.org
Subject: Re: support for HW_SKIP_CONSOLE breaks use by blind people
Date: Tue, 8 Jan 2013 16:33:51 +1000
On Mon, Jan 07, 2013 at 01:43:16PM +0100, Michal Suchanek wrote:
> On 7 January 2013 05:08, Peter Hutterer <peter.hutterer@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@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




Information forwarded to debian-bugs-dist@lists.debian.org, Debian X Strike Force <debian-x@lists.debian.org>:
Bug#696965; Package xserver-xorg-video-dummy. (Tue, 08 Jan 2013 07:09:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Peter Hutterer <peter.hutterer@who-t.net>:
Extra info received and forwarded to list. Copy sent to Debian X Strike Force <debian-x@lists.debian.org>. (Tue, 08 Jan 2013 07:09:03 GMT) Full text and rfc822 format available.

Message #94 received at 696965@bugs.debian.org (full text, mbox):

From: Peter Hutterer <peter.hutterer@who-t.net>
To: Samuel Thibault <samuel.thibault@ens-lyon.org>
Cc: "X.Org Devel List" <xorg-devel@lists.freedesktop.org>, Michal Suchanek <hramrach@gmail.com>, Alan Coopersmith <alan.coopersmith@oracle.com>, 696965@bugs.debian.org
Subject: [PATCH RFC] xfree86: add option -notty to prevent VT allocation
Date: Tue, 8 Jan 2013 17:05:16 +1000
Provided the driver permits it, Xorg -notty will not create a VT on startup.
Currently this driver list includes dummy and qxl only.

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
---
This seems to do the job, it restores the original behaviour by default, but
started with -notty the server skips the VT allocation provided all drivers
set HW_SKIP_CONSOLE. 

 hw/xfree86/common/xf86Init.c | 7 ++++++-
 hw/xfree86/man/Xorg.man      | 4 ++++
 2 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/hw/xfree86/common/xf86Init.c b/hw/xfree86/common/xf86Init.c
index 1695dbf..c266be3 100644
--- a/hw/xfree86/common/xf86Init.c
+++ b/hw/xfree86/common/xf86Init.c
@@ -93,7 +93,7 @@
 #ifdef XF86PM
 void (*xf86OSPMClose) (void) = NULL;
 #endif
-static Bool xorgHWOpenConsole = FALSE;
+static Bool xorgHWOpenConsole = TRUE;
 
 /* Common pixmap formats */
 
@@ -1455,6 +1455,11 @@ ddxProcessArgument(int argc, char **argv, int i)
         return 1;
     }
 
+    if (!strcmp(argv[i], "-notty")) {
+        xorgHWOpenConsole = FALSE;
+        return 1;
+    }
+
     /* OS-specific processing */
     return xf86ProcessArgument(argc, argv, i);
 }
diff --git a/hw/xfree86/man/Xorg.man b/hw/xfree86/man/Xorg.man
index 0cd5a10..7d77afd 100644
--- a/hw/xfree86/man/Xorg.man
+++ b/hw/xfree86/man/Xorg.man
@@ -333,6 +333,10 @@ as root (i.e, with real-uid 0).
 .TP 8
 .B \-nosilk
 Disable Silken Mouse support.
+.TP8
+.B \-notty
+If supported by the driver, do not allocate a VT. If one ore more drivers
+require a VT, this flag has no effect.
 .TP 8
 .B \-novtswitch
 Disable the automatic switching on X server reset and shutdown to the
-- 
1.8.1




Information forwarded to debian-bugs-dist@lists.debian.org, Debian X Strike Force <debian-x@lists.debian.org>:
Bug#696965; Package xserver-xorg-video-dummy. (Tue, 08 Jan 2013 11:45:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Samuel Thibault <sthibault@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian X Strike Force <debian-x@lists.debian.org>. (Tue, 08 Jan 2013 11:45:03 GMT) Full text and rfc822 format available.

Message #99 received at 696965@bugs.debian.org (full text, mbox):

From: Samuel Thibault <sthibault@debian.org>
To: Peter Hutterer <peter.hutterer@who-t.net>
Cc: "X.Org Devel List" <xorg-devel@lists.freedesktop.org>, Michal Suchanek <hramrach@gmail.com>, Alan Coopersmith <alan.coopersmith@oracle.com>, 696965@bugs.debian.org
Subject: Re: [PATCH RFC] xfree86: add option -notty to prevent VT allocation
Date: Tue, 8 Jan 2013 12:43:20 +0100
Hello,

Peter Hutterer, le Tue 08 Jan 2013 17:05:16 +1000, a écrit :
> Provided the driver permits it, Xorg -notty will not create a VT on startup.
> Currently this driver list includes dummy and qxl only.

I'd rather call it -novt, just like -novtswitch, -sharevts, vtXX.
Only the -keeptty option is really at the tty level, not the VT.

> This seems to do the job, it restores the original behaviour by default, but
> started with -notty the server skips the VT allocation provided all drivers
> set HW_SKIP_CONSOLE. 

Indeed, it looks fine for me.

Samuel



Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Thu Apr 17 00:38:14 2014; Machine Name: buxtehude.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.