tana@ee.sophia.ac.jp (Yoshiyuki Tanaka) (10/24/90)
I have installed X11R4 on the sparcstation 1 (Sun OS 4.03) patched with fix-1 to fix-14. Everything seems to work except for the client "xlock". It dies with the following 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: 25 Current serial number in output stream: 25 -------------------------------------------------------------------- I had a similar problem with "xterm", but I found out that a patch wasn't successful on a source file in the Xt library. I have that fixed now. I noticed that both the xlock on X11R4 and R3 dies the same way (On the R4 server). Is this problem due to some backward compatibility flag I set when compiling the whole system ? Also, is there an easy way to pin point the problem from an error message such as the one I included above? I don't know much about programming in X. Thanks in advance.. ---------------------------------------------------------------------------- Yoshiyuki Tanaka Sophia University, Tokyo Japan. Dept of Electrical & Electronic Enginerring Deiters Laboratory. Email: tana@bob.ee.sophia.ac.jp ----------------------------------------------------------------------------
dave@SAM.CS.OLEMISS.EDU (10/29/90)
The source in the X11R4 distribution for xlock does not work. I picked up the latest release on expo.lcs.mit.edu under the contrib directory. It works just great. dave
mouse@LARRY.MCRCIM.MCGILL.EDU (10/29/90)
> I have installed X11R4 on the sparcstation 1 (Sun OS 4.03) patched > with fix-1 to fix-14. Everything seems to work except for the client > "xlock". It dies with the following 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 Quick kludge-around: xset bc. Fix: have xlock pass a valid event mask to XGrabPointer. > Also, is there an easy way to pin point the problem from an error > message such as the one I included above? I don't know much about > programming in X. Run the program under a debugger, turn on synchronous mode by patching the _Xdebug variable to 1, and set a breakpoint at exit. That's what I've found most useful in such circumstances. der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
havia@serifos.Helsinki.FI (Jyrki Havia) (10/29/90)
In article <TANA.90Oct24154056@lauda.ee.sophia.ac.jp> you write: > >I have installed X11R4 on the sparcstation 1 (Sun OS 4.03) patched >with fix-1 to fix-14. Everything seems to work except for the client >"xlock". It dies with the following message: [removed... A VERY familiar message :-)] >I noticed that both the xlock on X11R4 and R3 dies the same way (On >the R4 server). Is this problem due to some backward compatibility >flag I set when compiling the whole system ? No. This is due to a bug in R3 server, and R3 xlock. As the bug get fixed, somebody forget to fix xlock, which 'used' that bug. I have made a very simple patch for xlock. You can also set the R4 server to 'bug-to-bug' compatibility mode with R3 server by executing command 'xset bc'. >Also, is there an easy way to pin point the problem from an error >message such as the one I included above? I don't know much about >programming in X. Well, as you have source code to look, the line Major opcode of failed request: 26 (X_GrabPointer) in error message gives a hint which X protocol reguest failed. Here it is XGrabPointer(...) request. I first tracked the problem down to the server, and there is sequence (something like, we do not have sources on-line) of code if (!bug_mode) { if (events BUTTON_PRESS or BUTTON_RELEASE are requested explisitly) fail } So, I looked the xlock code, and there the 4th argument to XGrabPointer is -1, ie. all bits on. THAT is a BUG! There is (In Xlib or Xprotocol ref.) a statement like: 'When grabbing the cursor, you should newer ask for Buttonxxxxxx -events, as they are implicitly requested'. Someone has read that (or it should have read from the beginning) '.. must not ..' instead of '.. should not ..'. The patch I made includes the feature, that any movement of mouse will bring the password-asking screen to life. I like that, and some of my fellows don't like it. It is easy to disbale by removign events PointerMotionMask and MotionNotify from this patch. ----- Patch follows -------- *** xlock.c.orig Mon Aug 20 16:02:22 1990 --- xlock.c Mon Aug 20 16:34:08 1990 *************** *** 253,259 **** GrabModeAsync, GrabModeAsync, CurrentTime); if (status != GrabSuccess) error("%s: couldn't grab keyboard! (%d)\n", status); ! status = XGrabPointer(dsp, w, True, -1, GrabModeAsync, GrabModeAsync, None, mycursor, CurrentTime); if (status != GrabSuccess) --- 253,259 ---- GrabModeAsync, GrabModeAsync, CurrentTime); if (status != GrabSuccess) error("%s: couldn't grab keyboard! (%d)\n", status); ! status = XGrabPointer(dsp, w, True, PointerMotionMask, GrabModeAsync, GrabModeAsync, None, mycursor, CurrentTime); if (status != GrabSuccess) *************** *** 265,271 **** XChangeGrabbedCursor(cursor) Cursor cursor; { ! XGrabPointer(dsp, w, True, -1, GrabModeAsync, GrabModeAsync, None, cursor, CurrentTime); } --- 265,271 ---- XChangeGrabbedCursor(cursor) Cursor cursor; { ! XGrabPointer(dsp, w, True, PointerMotionMask, GrabModeAsync, GrabModeAsync, None, cursor, CurrentTime); } *************** *** 483,489 **** init(dsp, w, gc, color, inittime, count); } XNextEvent(dsp, &event); ! } while (event.type != ButtonPress && event.type != KeyPress); } void --- 483,491 ---- init(dsp, w, gc, color, inittime, count); } XNextEvent(dsp, &event); ! } while (event.type != ButtonPress && ! event.type != KeyPress && ! event.type != MotionNotify); } void ---- Jyrki Havia : havia@cc.helsinki.fi University of Helsinki, : havia@finuha Department of Computer Science : HYLKA::HAVIA
tana@lauda.ee.sophia.ac.jp (Yoshiyuki Tanaka) (10/29/90)
The xlock in the X11R4 distribution is buggy. I was able to get a fixed version at expo.lcs.mit.edu. Thanks to everyone who mailed me telling me this. ---------------------------------------------------------------------------- Yoshiyuki Tanaka Sophia University, Tokyo Japan. Dept of Electrical & Electronic Enginerring Deiters Laboratory. Email: tana@bob.ee.sophia.ac.jp ----------------------------------------------------------------------------
fischer@iesd.auc.dk (Lars P. Fischer) (10/30/90)
In article <TANA.90Oct24154056@lauda.ee.sophia.ac.jp> tana@ee.sophia.ac.jp (Yoshiyuki Tanaka) writes: >I have installed X11R4 on the sparcstation 1 (Sun OS 4.03) patched >with fix-1 to fix-14. Everything seems to work except for the client >"xlock". It dies with the following 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: 25 > Current serial number in output stream: 25 >-------------------------------------------------------------------- xlock isn't quite up to X11R4. Try xset bc (bc = back compatibility) should fix it. Another option is to get a fixed version of xlock. /Lars -- Lars Fischer, fischer@iesd.auc.dk | NeXT: A disaster looking for a place CS Dept., Univ. of Aalborg, DENMARK. | to happen -- Bill Joy