From owner-cvs-sys  Tue Sep 10 23:38:32 1996
Return-Path: owner-cvs-sys
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id XAA15683
          for cvs-sys-outgoing; Tue, 10 Sep 1996 23:38:32 -0700 (PDT)
Received: from ra.dkuug.dk (ra.dkuug.dk [193.88.44.193])
          by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id XAA15678;
          Tue, 10 Sep 1996 23:38:28 -0700 (PDT)
Received: (from sos@localhost) by ra.dkuug.dk (8.6.12/8.6.12) id IAA27277; Wed, 11 Sep 1996 08:34:23 +0200
Message-Id: <199609110634.IAA27277@ra.dkuug.dk>
Subject: Re: cvs commit:  src/sys/i386/isa syscons.c
To: bde@zeta.org.au (Bruce Evans)
Date: Wed, 11 Sep 1996 08:34:23 +0200 (MET DST)
Cc: cvs-all@freefall.freebsd.org, CVS-committers@freefall.freebsd.org,
        cvs-sys@freefall.freebsd.org, peter@freefall.freebsd.org
In-Reply-To: <199609102015.GAA02194@godzilla.zeta.org.au> from "Bruce Evans" at Sep 11, 96 06:15:48 am
From: sos@FreeBSD.org
Reply-to: sos@FreeBSD.org
X-Mailer: ELM [version 2.4 PL24]
Content-Type: text
Sender: owner-cvs-sys@FreeBSD.org
X-Loop: FreeBSD.org
Precedence: bulk

In reply to Bruce Evans who wrote:
> 
> >  Modified:    sys/i386/isa  syscons.c
> >  Log:
> >  Hack workaround XFree86 switching failure when used with /dev/sysmouse
> >  and xdm, possibly in general.
> >  
> >  What was happening was that the server was doing a tcsetattr(.. TCSADRAIN)
> >  on the mouse fd after a write.  Since /dev/sysmouse had a null t_oproc,
> >  the drain failed with EIO.  Somehow this spammed XFree86 (!@&^#%*& binary
> >  release!!), and the driver was left in a bogus state (ie: switch_in_progress
> >  permanently TRUE).

Hmm, that problem doesn't exist with Xinsides server (which I use
with my strange P9100 card). I'll have a look at this before commenting
further..

> This reminds me of what happens when crtscts is locked on for the mouse.
> My mouse doesn't supply CTS, so draining takes forever.  Killing XFree86
> require kill -9 from somewhere other than the console IIRC, and leaves
> the console driver in a bogus state.  Some graphics cards go into a
> strange state when XFree86 is started up again in this state.  Sometimes
> XFree86 manages to kill itself after a timeout, but the console driver
> is left in a bogus state.

Hmm, maybe its time I take a look at XFree86's screen switch code again
(well I did write it at sme point :) ), as the Xinside server
doesn't seem to suffer from all these problems...

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Soren Schmidt             (sos@FreeBSD.org)             FreeBSD Core Team
               So much code to hack -- so little time.