>Number:         488
>Category:       port-i386
>Synopsis:       pcvt can lose keyboard control if you start an X server from an xterm
>Confidential:   no
>Severity:       serious
>Priority:       low
>Responsible:    gnats-admin (GNATS administrator)
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Sep 18 19:20:02 1994
>Originator:     John Kohl
>Organization:
>Release:        NetBSD-1.0_BETA
>Environment:
System: NetBSD kolvir 1.0_BETA NetBSD 1.0_BETA (KOLVIR) #16: Thu Sep 15 22:03:20 EDT 1994 jtk@kolvir:/u1/NetBSD-1.0/src/sys/arch/i386/compile/KOLVIR i386


>Description:
I think I tracked down the problem I had on NetBSD-current/i386 with
pcvt and losing keyboard control to a fresh X server trying to grab the
graphics mode on the same virtual console as an existing server.


>How-To-Repeat:
I didn't have problems when I ran 'xinit -- :1' from another virtual
console; only when I ran it _from within an xterm_ did I have problems.

>Fix:

Here's a patch which seems to fix the immediate problem; it makes the
VT_SETMODE fail if something tries to set process mode on the same VT as
an active process.  However, this doesn't mean that "xinit -- vtY :1"
will start an X server on vtY--the context at the time of the VT_PROCESS
may still be the current virtual console if the existing X server
doesn't yield before the new one tries to set VT_PROCESS mode.  Maybe
there's some missing handshake on the console switch completing.

==John

*** 1.1	1994/08/05 01:39:53
--- pcvt_ext.c	1994/08/07 02:55:52
***************
*** 2297,2302 ****
--- 2297,2306 ----
  #endif /* PCVT_FAKE_SYSCONS10 */
  
  	case VT_SETMODE:
+ 		if (vsp->smode.mode == VT_PROCESS &&
+ 		    ((struct vt_mode *)data)->mode == VT_PROCESS &&
+ 		    vsp->proc != p)
+ 			return EBUSY;		/* already in use on this VT */
  		vsp->smode = *(struct vt_mode *)data;
  		if(vsp->smode.mode == VT_PROCESS) {
  			vsp->proc = p;


>Audit-Trail:
>Unformatted: