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. _______________________________________________ [email protected]: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
