Bug#169427: without "AllowMouseOpenFail" causes X _keyboard_ to fail silently if _mouse_ is not plugged in
> > 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
Reply to: