skk@sparc.COM (Stuart Kreitman) (01/29/91)
Greetings, wizards.
I am enhancing the T7 protocol test suite to reproduce all
error conditions as defined in the protocol specification. There
is unexpected behaviour in some of these. The MIT staff recommended
posting these questions on the net, so please no flames about
xtest@lcs.mit.edu. Admittedly, there is a small number of people
interested in these issues.
This is a long message. Please skip over if disinterested.
The running environment is: Sun SLC, Sun IPC, Solbourne 5000, all running
the MIT sample server X.V11R4 with patches 1-14.
Quoted phrases starting with the symbol QUOTE are taken from the
protocol spec.
-------------------------------------------------------------------------------
REQUEST: GrabKeyboard
PROBLEM: Reply with status GrabFrozen cannot be induced.
SCENARIO:
A test program opens two client connections to the X server.
The first client performs GrabKeyboard, GrabModeSync, expecting to
freeze the keyboard.
The second client performs GrabKeyboard, GrabModeAsync,
expecting to see a reply with status GrabFrozen
Instead, a reply with status AlreadyGrabbed results.
QUOTE: "This request actively grabs control of the keyboard.
...If keyboard-mode is Synchronous, the state of the keyboard
(as seen by means of the protocol) appears to freeze."
(This relates to the first client's GrabKeyboard request)
QUOTE: "The request fails with status Frozen if the keyboard is frozen
by an active grab of another client."
(This relates to the second client's GrabKeyboard request)
What is the relationship between GrabKeyboard and the keyboard
state called "Frozen"? Perhaps GrabKey is the only way to truly
freeze the keyboard.
I assume the solution will apply to pointer-mode mode as well.
REQUEST: UngrabKey
PROBLEM: No error is generated when an invalid KEYCODE is specified.
SCENARIO:
A client makes an UngrabKey, specifying a KEYCODE that is outside
the range [min-keycode .. max-keycode].
QUOTE: "...the key must be in the range specified by min-keycode
and max-keycode in the connection setup (or a Value error results"
(This is in the definition of GrabKey. The definition of
UngrabKey doesn't mention this at all, which may be an
intended omission)
REQUEST: ChangeWindowAttributes
PROBLEM: Defined cases of BadAccess doesn't cause an error
SCENARIO:
Before running the test, xdpyinfo says:
current input event mask: 0xd0001d
KeyPressMask ButtonPressMask ButtonReleaseMask
EnterWindowMask SubstructureRedirectMask PropertyChangeMask
ColormapChangeMask
My test program makes liberal use of GetWindowAttributes, and it confirms that
one can set these three event masks simultaneously for two clients.
QUOTE: "...only one client at a time can select for SubstructureRedirect,
only one client at a time can select for ResizeRedirect,
and only one client at a time can select for ButtonPress.
An attempt to violate these restrictions results in an Access error."
REQUEST: CopyGC
PROBLEM: Expected BadValue, Got Nothing
SCENARIO: A client makes a CopyGC request with an undefined bit in the ValueMask
REQUEST: ClearArea, CopyArea, CopyPlane, PutImage
PROBLEM: Expected BadValue, Got Nothing
SCENARIO: These requests are made with rectangles containing negative
values or very large values for x,y
QUOTE: RECTANGLE: [x,y: INT16, width,height: CARD16]
Are arbitrary rectangles permitted for the above requests? Couldn't one
specify a large positive or way negative coordinate and crash the server?
Perhaps ClearArea is clipped to the window's borders.
Perhaps CopyArea, CopyPlane, PutImage are clipped to the dimensions of
the drawable.
REQUEST: SetFontPath
PROBLEM: Request to set a path of multiple strings generates BadValue
This is about the only request in the book that uses LISTofSTR.
I am not bright enough to figure out how to correctly specify
multiple strings from the protocol spec. alone. I will compare my
test with Xlib, but in the meantime, could someone explain LISTofSTR
to me?
REQUEST: SetScreenSaver
PROBLEM: Expected BadValue, Got Nothing
SCENARIO: Various disallowed values do not generate BadValue:
timeout = -5, interval = -5, prefer-blanking = 666, allow-exposures = 666
QUOTE: "...setting a value to -1 restores the default. Other negative
values generate a Value error."
QUOTE: "prefer-blanking: { Yes, No, Default}
allow-exposures: { Yes, No, Default}"
REQUEST: AllocColorCells
PROBLEM: Expected BadValue, Got Nothing
SCENARIO: Various disallowed values do not generate BadValue:
colors=0, planes=-1
QUOTE: "The number of colors must be positive, and number of planes
must be nonnegative (or a Value error results)."
REQUEST: AllocColorPlanes
PROBLEM: Expected BadValue, Got Nothing
SCENARIO: Various disallowed values do not generate BadValue:
colors=0 red=-1 green=-1 blue=-1
QUOTE: "The number of colors must be positive, and the reds, greens,
and blues must be nonnegative (or a Value error results)."
REQUEST: FreeColors
PROBLEM: Expected BadAccess, Got Nothing
SCENARIO: Attempt to free a color on a Static VisualType
-------------------------------------------------------------------------------
All constructive comments will be very much appreciated.
Stuart Kreitman (415) 493-6912
767 Loma Verde Ave, Suite D
Palo Alto, CA 94303rws@expo.lcs.mit.EDU (Bob Scheifler) (01/29/91)
Not obvious why you point the finger at the protocol spec for most of these.
The second client performs GrabKeyboard, GrabModeAsync,
expecting to see a reply with status GrabFrozen
Instead, a reply with status AlreadyGrabbed results.
Correct.
"The request fails with status Frozen if the keyboard is frozen
by an active grab of another client."
The sentence just before this one takes precedence (that's why it comes first).
The definition of
UngrabKey doesn't mention this at all, which may be an
intended omission
Since it is not mentioned, it should be viewed as an intended omission,
so no error should be expected.
My test program makes liberal use of GetWindowAttributes, and it confirms
that one can set these three event masks simultaneously for two clients.
Perhaps you are confused by the wording, perhaps your server has a bug.
All three can be simultaneously set; the restriction is that two distinct
clients cannot simultaneously select for the same bit. If you think there
is a bug in the MIT R4 server, please submit a bug report along with a small
test program.
CopyGC
Expected BadValue, Got Nothing
A client makes a CopyGC request with an undefined bit in the ValueMask
A server bug, not a protocol bug.
ClearArea, CopyArea, CopyPlane, PutImage
Expected BadValue, Got Nothing
These requests are made with rectangles containing negative
values or very large values for x,y
No bug here. All values passed at the protocol level are legal for rectangles.
The server should clip.
SetScreenSaver
Expected BadValue, Got Nothing
Various disallowed values do not generate BadValue
Then your server has a bug. (The R4 server generates BadMatch, which is
also wrong.)
AllocColorCells
Expected BadValue, Got Nothing
Various disallowed values do not generate BadValue:
colors=0, planes=-1
Server bug for colors=0. Planes at the protocol level is CARD16, so
negative numbers are not possible (hence the nonnegative restriction
given in the protocol is redundant).
AllocColorPlanes
Expected BadValue, Got Nothing
Various disallowed values do not generate BadValue:
colors=0 red=-1 green=-1 blue=-1
Server bug for colors=0. Red/green/blue at the protocol level are CARD16, so
negative numbers are not possible (hence the nonnegative restriction given in
the protocol is redundant).
FreeColors
Expected BadAccess, Got Nothing
Attempt to free a color on a Static VisualType
It is not an error to free a cell that you have actually allocated. If
you attempted to free a cell that you had not allocated, then your server
has a bug. If you believe this is the case with an MIT R4 server, please
submit a bug report with a small test program.