[MPlayer-users] SVGA locking - workaround

[Glyn]

The SVGA-locking-the-console bug (see earlier thread with lots of posts from me)
was annoying me so much that I had a look at what was going on.  It seems that
the getch2 functions aren't necessary for -vo svga, and when they are used,
the calls to the vga_ functions (which change the console's text-handling
themselves) combined with the getch2_dis/enable functions mess up the console so
that is has to be reset.

I've come up with a way around this - I've disabled the call to getch2_enable
when -vo is svga - using this patch:

Index: mplayer.c
===================================================================
RCS file: /cvsroot/mplayer/main/mplayer.c,v
retrieving revision 1.483
diff -u -r1.483 mplayer.c
--- mplayer.c	26 Apr 2002 12:52:06 -0000	1.483
+++ mplayer.c	30 Apr 2002 14:33:16 -0000
@@ -763,7 +763,11 @@
 
 // We must enable getch2 here to be able to interrupt network connection
 // or cache filling
-if(!use_stdin && !slave_mode){
+if(!use_stdin && !slave_mode
+#ifdef HAVE_SVGALIB
+    && strcmp(video_driver?video_driver:video_out_drivers[0]->get_info()->short_name, "svga") 
+#endif
+    ){
   getch2_enable();  // prepare stdin for hotkeys...
   inited_flags|=INITED_GETCH2;
   mp_msg(MSGT_CPLAYER,MSGL_DBG2,"\n[[[init getch2]]]\n");


It's almost certainly not the right way of doing things, but it stops the
problem until a proper fix can be done.

It also prevents the console from becoming frozen when mplayer isn't running as
root, because normally it would exit with
  svgalib: Cannot get I/O permissions 
and never call uninit(), but with this change applied, failing to call uninit
doesn't cause any permanent damage.

Is this fix some use, or am I just wasting your time?

Glyn

-- 
glyn.kennington at hertford.ox.ac.uk

Can I buy a drink here, or are you just going to throw limes at me?