[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#169427: without "AllowMouseOpenFail" causes X _keyboard_ to fail silently if _mouse_ is not plugged in



On Fri, Dec 20, 2002 at 04:17:59PM +0100, Frank Murphy wrote:
> > P.R. Patil writes:
> > > Dear All,
> > >       If ps mouse is not connected to the pc then it hangs the kbd. 
> > > Can any one solve the problem?Thanks and Regds,
> >
> > This is not the fault of the Xserver.
> >
> > It is partly the fault of the archaic hardware design:
> > When you open the PS/2 mouse device without a mouse being connected the
> > chipset will generate a fault data byte after a long timeout period. Since
> > this data byte doesn't get serviced (appearantly no interrupt is generated)
> > the keyboard/mouse controller doesn't generate any interrupt for any
> > further events. If at all the kernel needs to handle this.
> >
> > The funny thing is: if you access the keyboard thru an ioctl (ie when
> > terminating X or by setting the keyboard rate) the fault package is
> > serviced and the keyboard starts working again.
> >
> > If at all this problem needs to be handled in the kernel.
> > 
> > Egbert.
> 
> So it seems that this bug should be reassigned to the Linux kernel. I'd be 
> interested to know if those having problems are able to use gpm, or some 
> other text-based, mouse-enabled programs without killing the keyboard.

This is a problem that I hit a while back in gpm, it is a simple one but
also one nearly impossible to deal with in X, only vaguely possible to
deal with in gpm.

Basicly it works like this, on some motherboards, with /some/ kernel
versions (I /believe/ it is no longer an issue with 2.4.20, probably
fixed a little before that, but someone who can reproduce this please
check), if there is no PS/2 mouse attached, and we attempt to write to
/dev/psaux, we lose.

The write blocks forever, even with non-blocking IO enabled, and the
keyboard is dead.

HOWEVER, if the program in question is killed and thus the device
closed, keyboard access remains.

How I solved this in gpm was straight forward enough, I set an alarm to
go off 5 seconds after each right, and when the write returns I cancel
it, if the write actually blocks then the alarm kills gpm and people get
the keyboard back.

Obviously, that same trick is really not much of an option for X.

Welcome to a hell that can only be fixed in the kernel. (=:]

Zephaniah E. Hull.
Debian gpm maintainer.
> 
> Frank

-- 
	1024D/E65A7801 Zephaniah E. Hull <warp@babylon.d2dc.net>
	   92ED 94E4 B1E6 3624 226D  5727 4453 008B E65A 7801
	    CCs of replies from mailing lists are requested.

Hey, if you've mlock'ed more than your available memory, there's nothing
the VM layer can do. Except maybe a nice printk("Kiss your *ss goodbye");
  -- Linus

Attachment: pgpjpLOUkvvIg.pgp
Description: PGP signature


Reply to: