dce@smsc.sony.com (David Elliott) (12/16/89)
In the current version I have of xlock (R3 and R4Beta), there are two calls to XGrabPointer() with an event mask of -1, which caused a problem with the Sony R3 server (invalid argument). I changed it to NoEventMask, and xlock worked. I then tried changing it to a mask made by OR'ing together all the masks listed in <X11/X.h>, and that didn't work. I started looking at the events one at a time, and found that KeyPressMask and KeyReleaseMask were both invalid, but ButtonPressMask and ButtonReleaseMask are fine (this makes sense, since grabbing the pointer has nothing to do with Key events). Is -1 a special value meaning "all events that apply", so that the server should accept the value unquestioningly? Or, should xlock be more specific with its event mask in this case? -- David Elliott dce@smsc.sony.com | ...!{uunet,mips}!sonyusa!dce | (408)944-4073 "As I never read this newsgroup or my email, please send replies via carrier pigeon."
klee@chico.pa.dec.com (Ken Lee) (12/19/89)
In article <1989Dec16.002825.10200@smsc.sony.com>, dce@smsc.sony.com (David Elliott) writes: > Is -1 a special value meaning "all events that apply", so that the > server should accept the value unquestioningly? Or, should xlock > be more specific with its event mask in this case? The XGrabPointer event mask has type unsigned int, so, on most hardware with sloppy compilers, putting a -1 in there will be converted to a word with all bits on. What a hack. Ken Lee DEC Western Software Laboratory, Palo Alto, Calif. Internet: klee@decwrl.dec.com uucp: uunet!decwrl!klee
rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (12/19/89)
calls to XGrabPointer() with an event mask of -1, which caused a problem with the Sony R3 server (invalid argument). That actually makes it a post-R3 server, then. :-) This is a typical bug in R3 clients that will cause them to lose against strict R4 servers. Is -1 a special value meaning "all events that apply", -1 is not treated special by the server. The set of legal bits for the event mask in an XGrabPointer is defined in the protocol specification for GrabPointer (page 379 in the DP book) as SETofPOINTEREVENT. This set is given on page 349. Bit encodings are shown on page 545.
dce@smsc.sony.com (David Elliott) (12/19/89)
In article <2296@bacchus.dec.com> klee@decwrl.dec.com writes: >In article <1989Dec16.002825.10200@smsc.sony.com>, dce@smsc.sony.com >(David Elliott) writes: >> Is -1 a special value meaning "all events that apply", so that the >> server should accept the value unquestioningly? Or, should xlock >> be more specific with its event mask in this case? > >The XGrabPointer event mask has type unsigned int, so, on most hardware >with sloppy compilers, putting a -1 in there will be converted to a >word with all bits on. What a hack. I understand that part (I noticed the 'unsigned' in the manual), and I even accept its use (though maybe a define for AllEvents would be a better idea). The question that remains is: should XGrabPointer accept a mask with all 1's as "all events that apply", or should it check the value and raise an error if it sees any events that aren't correct for that call? If one application has made the assumption that this will work because it works on at least one server, and if X doesn't define it not to, other application writers may do the same thing. -- David Elliott dce@smsc.sony.com | ...!{uunet,mips}!sonyusa!dce | (408)944-4073 "As I never read this newsgroup or my email, please send replies via carrier pigeon."
klee@chico.pa.dec.com (Ken Lee) (12/19/89)
In article <1989Dec19.005753.16316@smsc.sony.com>, dce@smsc.sony.com (David Elliott) writes: > The question that remains is: should XGrabPointer accept a mask with > all 1's as "all events that apply", or should it check the value and > raise an error if it sees any events that aren't correct for that > call? Well, the protocol spec (p. 379 in the DP book) does specifically say the event mask is a SETofPOINTEREVENT. Setting bits for events not in this set does technically violate the protocol, so servers should be free to reject the requests. I understand that the X11R4 sample servers will include a bugged-mode to accept sloppy protocol. Ken Lee DEC Western Software Laboratory, Palo Alto, Calif. Internet: klee@decwrl.dec.com uucp: uunet!decwrl!klee