frank@giza.cis.ohio-state.edu (Frank Adelstein) (08/01/90)
Some of our users are having problems when they run xlock. It will blank the screen, and then immediately exit with the message: X Error of failed request: BadValue (integer parameter out of range for operation) Major opcode of failed request: 26 (X_GrabPointer) Minor opcode of failed request: 0 Resource id in failed request: 0xffff Serial number of failed request: 29 Current serial number in output stream: 29 I haven't had that problem myself, and I can't see anything different in their environment that would cause it. Has anyone seen this before, and is there some simple cause and equally simple fix for this? Other details: X11R4 (with fix-12) on a Sun SLC running SunOS 4.1 running twm (problem still there with no wm). Thanks. --Frank Adelstein. frank@cis.ohio-state.edu
brock@SUMEX-AIM.STANFORD.EDU (Kevin Brock) (08/01/90)
I've seen the same problem before, but not with xlock. XGrabPointer uses the GrabPointer protocol, which expects to be sent an event mask for the window which is a SETofPOINTEREVENT. The problem is that SETofPOINTEREVENT is an event mask in which certain bits ( 0xffff8003, in fact) *must* be set to zero. The problem arises when the application doesn't check the event mask of the window on which it calls XGrabPointer. In the HP widgets VPanedWindow, for instance, XGrabPointer is called with XtBuildEventMask(widget) for the event mask value, and it doesn't perform any checks on the event mask. In that particular case I've *never* seen it work without a patch, but it sounds like what's happening in xlock is just a variation on a theme. ------------------------------- Kevin Brock brock@sumex-aim.stanford.edu -------
mouse@LARRY.MCRCIM.MCGILL.EDU (08/10/90)
> Some of our users are having problems when they run xlock. It will > blank the screen, and then immediately exit with the message: > X Error of failed request: BadValue (integer parameter out of range for operation) > Major opcode of failed request: 26 (X_GrabPointer) > Minor opcode of failed request: 0 > Resource id in failed request: 0xffff Almost certainly, xlock is doing a GrabPointer with an event-mask of ~0, or -1, or some such. This is wrong; the event-mask is not allowed to specify bits that do not correspond to anything valid. The R3 server carelessly let clients get away with this; the R4 server checks things properly. The correct fix is to make xlock pass a proper event mask. If you can't/won't do this, for whatever reason, you can also put the R4 server into bug-compatibility mode with "xset bc". der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu