X Core Protocol Scheme

[Ilya Anfimov]

On Sat, Dec 12, 2015 at 06:31:55PM +0100, Michael Titke wrote:
> 

[skipped]

> >  This is described in Expose event paragraph in section 11 of the
> >protocol specification.
> >
> >btw, this automatically means  that  you  should  receive  Expose
> >events  on  the  window you want to draw and therefore select Ex-
> >posure in the event mask at a window creation.
> 
> Listening for expose events sounds like a good idea but the relation between
> graphics operation, their effect and expose events doesn't seem to be stated
> in the specifications. In the current experimental setup only keyboard

 It is.
 In  fact,  there is no relation between _graphic_ operations and
Expose events, and that fact is somehow  mentioned  both  in  de-
scription  of  WhenMapped hint in CreateWindow request and in de-
scription of Expose operation itself.

> events are in the event mask and it's a little bit surprising that the
> graphic operation has an effect only after a keyboard event has been
> received.

 It is not.
 You get your results just by coincidence.



[skipped]

> >>    the padding bytes at the end. Now I really made it to open a window and
> >  You  have specs of MIT Magic Cookie? You lucky guy, I don't have
> >this one.
> 
> It just needed some script "playing" the server to find out about the
> correct padding which usually should coincide with the terminating C string
> null byte.

 It does not (see another my message).

[skipped]

> core protocol requests to receive those mappings for the current maps in
> effect are ignored by the server.

 No.


[skipped]

> 
> >>    finally deliver the protocol specifications where these kinds of
> >>    interactions are layed out? Or some up to date updates on the core
> >>    protocol? But as I have heard the X server doesn't even know about all
> >>    registered extensions anymore - at least on Ubuntu with Unity one of
> >>    the first events to be received was an impossible operation code of 192
> >>    which wasn't reported by xdpyinfo to belong to any registered
> >  Extension  opcodes  assigned  by server at QueryExtension reply,
> >you should get that bytestream and find the extension  name  from
> >there. The number 192 may mean anything.
> 
> The QueryExtension request isn't implemented in the experimental setup right
> now but as stated /xdpyinfo/ didn't report that operation code.

 Bag my pardon: missed the word "Event" in you description.
 The  192 event is synthetic event with code 64, and I don't know
what it should mean. Mostly because never interested in possibil-
ity of bogus events -- just drop them.

> 
> 
> >>    extension. The current state of X11 is a bit puzzling: it when works
> >  Yes,  the  protocol is not trivial. But it is consistent and core is
> >well-documented.
> >
> >  There are some features or extensions which lacks  proper  docu-
> >mentation  (MIT-MAGIC-COOKIE-1  authentication, RENDER extension,
> >NV-GLX extension) but in fact all of them is crap, and you should
> >probably get rid of it.
> 
> The core protocol is trivial - just not well documented. ;-) The XKB

 Well, we have different opinions on this.