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