From: Marcus Sundberg <mackan@stacken.kth.se>
  To  : ggi-develop@eskimo.com
  Date: Thu, 13 May 1999 19:38:28 +0200

Re: fbdev/linvtsw problem

Jon M. Taylor wrote:
> 
>         I have been seeing this problem for a while now, and since I just did
> a fresh degas checkout and install on my box which was just upgraded from
> Redhat 5.2 to 6.0 and the problem is still present I guess I'd better bring
> it up.  The problem is that I cannot run any GGI apps using the fbdev target
> unless I am root.  I have set the permissions on /dev/fbx correctly.  Another
> odd thing is that XGGI 1.6.0 still works fine!  Only programs built against
> LibGGI within the last month or so on my system exhibit this behavior.
> 
>         What happens is that the program hangs until I do a VT switch,
> whereupon I get a signal 11 error message when I switch back and the program
> has terminated.  Using the X target, everything works fine.  Wierd.  I'm
> using the vesafb/2.2.5-15 (redhat 6.0 default kernel), but it happens even if
> I load a KGIcon driver.  It is easy to get around the problem by running
> everything as root, but that shouldn't be necessary.  Anway....
> 
> Here's the GGI_DEBUG=255 output (demo.c):
> 
> LibGII: Debugging=255
> LibGGI: Debugging=255
> LibGGI: ggiOpen("display-fbdev") called
> LibGGI: Loading driver display-fbdev
> LibGGI: _ggiAddDL(0x804e9a8, "display-fbdev", "(null)", 0x1) called
> LibGGI: _ggiLoadDL("/usr/local/lib/ggi/display/fbdev.so", 0x1) called
> LibGGI: hand.handle=0x804ecf8
> LibGGI: hand.init=0x40134e1c
> LibGGI: hand.cleanup=0x401355cc
> LibGGI: _ggiLoadDL returned 0x804eff0
> LibGGI: display-fbdev: GGIdlinit start.
> LibGGI: display-fbdev: Using VT 2.
> LibGGI: display-fbdev: Determined VT 2 is on FB 0
> LibGGI: _ggiAddDL(0x804e9a8, "helper-linux-vtswitch", "(null)", 0x0) called
> LibGGI: _ggiLoadDL("/usr/local/lib/ggi/display/lin_vtsw.so", 0x0) called
> LibGGI: hand.handle=0x804f868
> LibGGI: hand.init=0x4002460c
> LibGGI: hand.cleanup=0x40024760
> LibGGI: _ggiLoadDL returned 0x804fba8
> LibGGI: L/vtswitch: Using VT 2.
> 
> ...and here's where it hangs up.  After switching away and back again, I
> see the following:
> 
> LibGGI: L/vtswitch: open OK.

This doesn't make sense at all. :(
Here's the code block in question:

	GGIDPRINT_MISC("L/vtswitch: Using VT %d.\n", priv->vthandling.vtnum);
	
	if (priv->vthandling.onconsole) {
		/* Disable normal text on the console */
		ioctl(priv->vtfd, KDSETMODE, KD_GRAPHICS);
	}
	
	/* Unfortunately, we need to take control over VT switching like
	 * Xfree and SVGAlib does.  Sigh.
	 */
	ioctl(priv->vtfd, VT_GETMODE, &qry_mode);

	qry_mode.mode = VT_PROCESS;
	qry_mode.relsig = SWITCHSIG;
	qry_mode.acqsig = SWITCHSIG;
	
	priv->vt_switched_away = 0;
	vtvisual = vis;

	setsig(SWITCHSIG, switching_handler);

	if (ioctl(priv->vtfd, VT_SETMODE, &qry_mode) < 0) {
		perror("L/vtswitch: Setting VT mode failed");
		restore_vt(priv);
		close(priv->vtfd);
		priv->vtfd = -1;
		return -1;
	}
	
	GGIDPRINT_MISC("L/vtswitch: open OK.\n");

I can't see any reason why any of the ioctl()s or the setsig() would
block. Could you stuff some more DPRINTs in there to find out exactly
what syscall it is that blocks?

> LibGGI: 0 = dlh->init(0x804e9a8,"(null)",0xbffeca74) - helper-linux-vtswitch
> LibGII: Allocating input structure
> LibGII: _giiEvQueueAllocate(0x804fc40) called
> LibGII: Got queue_set: 0x804fdc8
> LibGII: giiOpen adding "linux-kbd", "/dev/tty2", (nil)
> LibGII: _giiLoadDL("linux-kbd","(NULL)") called
> LibGII: hand.handle=0x804fe60
> LibGII: hand.init=0x4013b9e8
> LibGII: _giiLoadDL returned 0x8050190
> LibGII: linux_kbd starting.(args="/dev/tty2",argptr=(nil))
> LibGII: Linux-kbd: opening tty
> LibGII: Linux-kbd: calling tcgetattr()
> LibGII: Linux-kbd: calling tcsetattr()
> LibGII: Linux-kbd: going to MEDIUMRAW mode
> LibGII: Linux-kbd: init OK.
> LibGII: _giiEvQueueAdd(0x804fc40, 0xbffec454) called
> LibGII: _giiEvQueueSetup() called
> LibGII: _giiEvQueueSetup alloced 0x80509a8
> LibGII: Adding event type 1, size 116 at pos 0
> LibGII: linux_kbd fully up
> LibGII: 0=dlh->init(0x804fc40,"/dev/tty2",(nil)) - linux-kbd
> LibGII: _giiUpdateCache(0x804fc40) called
> LibGII: Found fd: 6
> LibGII: Allocating input structure
> LibGII: _giiEvQueueAllocate(0x80529b8) called
> LibGII: Got queue_set: 0x8052b40
> LibGII: giiOpen adding "linux-mouse", "auto", 0xbffecae4
> LibGII: _giiLoadDL("linux-mouse","(NULL)") called
> LibGII: hand.handle=0x8052bd8
> LibGII: hand.init=0x40140a54
> LibGII: _giiLoadDL returned 0x8052f18
> LibGII: linux_mouse starting.(args="auto",argptr=0xbffecae4)
> LibGII: linux_mouse: prot=`ps2' dev=`/dev/mouse' opts=`'
> LibGII: linux-mouse: Opened mouse file '/dev/mouse' ReadOnly.
> LibGII: Allocating input structure
> LibGII: _giiEvQueueAllocate(0x8052f78) called
> LibGII: Got queue_set: 0x8053100
> LibGII: giiOpen adding "input-mouse", "9,ps2", (nil)
> LibGII: _giiLoadDL("input-mouse","(NULL)") called
> LibGII: hand.handle=0x8053190
> LibGII: hand.init=0x40143a90
> LibGII: _giiLoadDL returned 0x80534b0
> LibGII: -22=dlh->init(0x8052f78,"9,ps2",(nil)) - input-mouse

Oh nice, you found a bug in input-mouse. Some mice requires an
init sequence to be written to them to put them into native mode.
For plain PS/2 we have an init sequence to reset the mouse, but
it isn't strictly necessary, so we shouldn't fail if writing to
the mouse device doesn't work.

> LibGII: _giiEvQueueDestroy(0x8052f78) called
> LibGII: Desttroying 0x8053100, 0x8053104
> LibGII: _giiEvQueueDestroy going 0, (nil)
> LibGII: _giiEvQueueDestroy going 1, (nil)
> LibGII: _giiEvQueueDestroy going 2, (nil)
> LibGII: _giiEvQueueDestroy going 3, (nil)
> LibGII: _giiEvQueueDestroy going 4, (nil)
> LibGII: _giiEvQueueDestroy going 5, (nil)
> LibGII: _giiEvQueueDestroy going 6, (nil)
> LibGII: _giiEvQueueDestroy going 7, (nil)
> LibGII: _giiEvQueueDestroy going 8, (nil)
> LibGII: _giiEvQueueDestroy going 9, (nil)
> LibGII: _giiEvQueueDestroy going 10, (nil)
> LibGII: _giiEvQueueDestroy going 11, (nil)
> LibGII: _giiEvQueueDestroy going 12, (nil)
> LibGII: _giiEvQueueDestroy going 13, (nil)
> LibGII: _giiEvQueueDestroy done
> LibGII: linux_mouse cleanup
> LibGII: tcsetattr failed.
> LibGII: linux_mouse: exit OK.
> Terminating on signal 11

Here you found a bug in input-linux-mouse.
If opening input-mouse fails the private structure was free()d twice.

Fixes for input-mouse and input-linux-mouse has been commited, but
I need more info about the linvtsw problem before I can make a guess
about what's wrong.

//Marcus
-- 
-------------------------------+------------------------------------
        Marcus Sundberg        | http://www.stacken.kth.se/~mackan
 Royal Institute of Technology |       Phone: +46 707 295404
       Stockholm, Sweden       |   E-Mail: mackan@stacken.kth.se