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 | // // // / /
[EMAIL PROTECTED] | EI 'AANIIGOO 'AHOOT'E
http://people.debian.org/~branden/ |
signature.asc
Description: Digital signature
