> > From what I understand, the AllowMouseOpenFail will allow me to keep the > > PS/2 mouse configured without having one plugged in. I plan to add that to > > my XFConfig, but it seems that allowing a mouse to fail open should be the > > default (especially a second mouse). > > That option only has an impact if the server fails to start without it. > > See a recent Xpert post by Egbert Eich for a possible explanation of the > problem. > > -- > Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer > XFree86 and DRI project member / CS student, Free Software enthusiast
I looked in the archives at http://marc.theaimsgroup.com and found the post Michel's talking about: > 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. Frank -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
