Handle the failure reply from the initial connection request.
"proto_item_append_text()" accepts "printf"-like formats; we don't need
to generate a string with a formatting routine and hand it to
"proto_item_append_text()", so don't do so.
When doing reassembly, the length that should be checked is the length
remaining in the tvbuff, not the length remaining in the packet, and
that length should be fetched with "tvb_ensure_length_remaining()" so
that if we *do* go past the end of the tvbuff we throw the appropriate
exception.
To determine whether a reply is a reply to the initial connection, check
the connection state and "initial connection reply" frame - don't check
the first byte of the message unless we've determined that the message
isn't an initial connection reply (the first byte of the initial
connection reply is the success/failure flag, so it could be 0 or 1).
Display window IDs in hex in replies, as we do in requests.
Fix the masks for Button3, Button4, and Button5 (it's a bitset, not a
button number - more than one mouse button can be down in an event,
although it can be a pain to try to click more than one button at the
same time).
svn path=/trunk/; revision=9544
Add support for parsing some X11 replies and events (and
the framework for handling X11 errors it looks like) to the
existing X11 code, which parses X11 requests.
It parses what is the most difficult part of the replies/events,
they Keycode stuff by parsing the Keyboardmapping replies and etc,
and then KeyPress, KeyRelease events and some related stuff (used
for a specific project).
Adding support for parsing the rest of the event/replies should not
be difficult, I think it will mostly consist of going through every
event/reply and add the missing calls for each dataitem i.e. register
the data, the remaining the eventcodes/replies are pretty
straightforward if I remember correctly.
All events and replies are reported, it's the "detailed" (-V option)
that's missing for most.
The replies, events and errors are listed in the Info column,
and are summarized in the protocol summary line.
Bogus if (tree) { } constructs have also been fixed.
List over other misc. stuff added:
- handle multiple outstanding requests.
- add AllocNamedColor to list of requests expecting a reply.
- body for parsing error replies.
- each packet can be sent to us multiple times, try to handle that.
- change request_length display to be what the client actually sends
for x11_request, not what it means (don't multiply by four).
- add some more opcodes expecting a reply (gone through all listed
in the ref. now, so should be complete).
- use hashtable and sequencenumber for matching reply to request.
svn path=/trunk/; revision=9520
to be using it for stuff that should be hex, and for stuff that should
be Boolean. Use BASE_DEC if it should be decimal, BASE_HEX if it should
be hex, and make it Boolean if it should be Boolean.
svn path=/trunk/; revision=7053
addresses.
When showing a list of keysyms, build the text representation of the
item for the list by appending keysyms to the text of the item as
dissected; this fixes a bug in the display of those keysums, and means
that we don't build a text string with the keysyms if we're not
generating the text representation.
svn path=/trunk/; revision=5179
Try to check whether the first request we see is an initial connection
request, and dissect it as such if so.
Get rid of the global "next_offset" variable.
Check for buffer overflows when building the summary item for a list
of keysyms.
Display BASE_DEC items in decimal, not hex.
svn path=/trunk/; revision=5173
specified - with or without a name for the list of values - and to roll
up *all* the tokens at the end into the blurb for the field.
Supply a base in "x11-fields" for all numeric fields, and supply a base
of NONE rather than a parent-field width for Boolean fields that aren't
bitfields.
svn path=/trunk/; revision=3342
Perl script that generates them, so that if we have to change those
fields we can do so more conveniently.
Remove the generated header files from CVS, and arrange that we generate
them when we do a build.
svn path=/trunk/; revision=3341
Guy Harris