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

Bug#218615: xserver-xfree86: Crash in "Return To Castle Wolfenstein" causes mouse pointer to hang.



On Thu, Nov 13, 2003 at 04:11:27PM +0100, Friedrich Delgado Friedrichs wrote:
> Sorry for the long delay, it seems this is extremely hard to reproduce.

No problem; thanks for getting back to us.

> Branden Robinson schrieb:
> > A couple of observations:
> > 1) You're using NVidia's proprietary server driver.  I can't support
> >    that.  Can you reproduce the problem using a different brand of video
> >    card, or with the "vesa" or "vga" drivers?
> My nvidia card just gave up and I have an ATI Radeon card now. I'll see
> if I can reproduce this bug with the new card.

Okay, cool.

> > 2) It sounds like RTCW had the pointer grabbed when it died.  Most of
> >    what you saw was probably to be expected, then.
> Some people disagree. An acquaintance of mine stated that according to
> the xlib protocol specification an X-Client should not be able to stop
> the mouse pointer under any circumstances.

All right.  I'll take your word for it as I don't feel like reading the
X protocol spec at the moment.  :)

> Also the manpage of XGrabPointer states:
> -----
> The X server performs an UngrabPointer request automatically if the event
> window or confine_to window for an active pointer grab becomes not viewable
> or if window reconfiguration causes the confine_to window to lie completely
> outside the boundaries of the root window.
> -----

All right.

> According to said acquaintance this should also happen when the
> connection to the X Server is closed.

Yes, that would make sense.

> > Of course, it's not good that the X client crashed, but that's
> > proprietary software, too.
> I was not reporting a bug about Return To Castle Wolfenstein.
> 
> My general assumption (which may be false) is that an X Client (however
> buggy) should not be able to crash the X Server or make it unusable.

With the caveat that screen lockers kind of *are* supposed to make the X
server "unusable" (in a way), yes, that is a perfectly valid assumption.
The X server should never crash.  It should be able to cope with
arbitrarily malicious or malformed protocol requests.

> > So I guess the bug here is that the mouse's acceleration parameters got
> > messed up?
> 
> Next time this client crashes I'll take the time to investigate if
> there's any window or running process left, which could grab the
> pointer.

You may be interested in some relatively new XFree86 X server features
which are avilable in 4.2.0 and later:

XFree86(1x):

       Ctrl+Alt+Keypad‐Multiply
               Not treated specially by default.  If the AllowClose#
               downGrabs  XF86Config#4(5x) file option is specified,
               this key sequence kills clients with an  active  key#
               board  or  mouse grab as well as killing any applica#
               tion that may have locked the server, normally  using
               the XGrabServer(3x) Xlib function.

       Ctrl+Alt+Keypad#Divide
               Not  treated specially by default.  If the AllowDeac#
               tivateGrabs XF86Config#4(5x) file  option  is  speci#
               fied,  this  key sequence deactivates any active key#
               board and mouse grabs.

It's possible that RTCW is not *completely* crashing; perhaps some
process is still running that keeps the grab active.

-- 
G. Branden Robinson                |
Debian GNU/Linux                   |           //     // //  /     /
branden@debian.org                 |           EI 'AANIIGOO 'AHOOT'E
http://people.debian.org/~branden/ |

Attachment: signature.asc
Description: Digital signature


Reply to: