Hi!
It just happened again.
This time with the ati driver and enemy territory. Enemy Territory
was killed by the OOM Killer and because of that, it doesn't really
make sense to report a bug in ET (unless I can argue that it uses
excessive amounts of memory, but there was a different memory-hungry
process running at that time).
I could see no process left of enemy territory which could hold a
mouse grab. The mouse was "stuck" in the upper left corner of the X
Window, which was still at the resolution I used to play ET.
I even did xwininfo -root -tree, to see if I could identify any window
that might belong to ET.
Again, restarting ET and quitting gave me the mouse pointer back, but
with the acceleration screwed up.
Branden Robinson schrieb:
> > 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. :)
Uhm, I did not read the protocol spec either. But said person is
usually trustworthy with those things.
> > According to said acquaintance this should also happen when the
> > connection to the X Server is closed.
> Yes, that would make sense.
Well, apparently ET was killed, so the connection to the X-Server
should have been closed. This gives me a way to reproduce that
problem.
Indeed, killing all ET processes with SIGKILL gives me the symptoms I
described.
> > 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.
Screen lockers grab the server, afaik. Killing xscreensaver with
SIGKILL while the screen is locked will get me back to my desktop.
According to the manpage, the root window might be screwed up with
some windowmanagers, which need to be restarted after xscreensaver was
killed.
> > > So I guess the bug here is that the mouse's acceleration parameters got
> > > messed up?
That seems to be one part of the issue.
Of course typing in a quick "xset" doesn't really hurt.
> Ctrl+Alt+Keypad‐Multiply
> Ctrl+Alt+Keypad#Divide
Both have no effect in that situation (Yes, I enabled them in my XF86Config).
> It's possible that RTCW is not *completely* crashing; perhaps some
> process is still running that keeps the grab active.
Can't find anything.
HTH
Friedel
--
Friedrich Delgado Friedrichs <friedel@nomaden.org>
Attachment:
signature.asc
Description: Digital signature