On 14/12/2015 07:52, Alan Coopersmith wrote:
On 12/11/15 01:02 PM, Michael Titke wrote:
Hello!
As part of a first incursion into the possibility to implementing
native support
for X starting from the wire protocol (w/o any Xlib/XCB support) I
ran into a
couple of situations where documentation didn't match implementation.
The first surprise was the "magic" of the MIT Magic Cookie which
needs that
little deviation from the protocol encoding where you have to put the
padding
bytes at the end. Now I really made it to open a window and receive
key codes
destined for it but no keysyms as the request for the keyboard
mappings is
silently ignored. The XKB extension as far as I understand it
essentially
replaced that? But there is no addendum to core protocol specifications.
All the extensions, such as XKB, should be documented as well on
http://www.x.org/releases/X11R7.7/doc/index.html
XKB is "X Keyboard Extension" there.
My question is: will this continue like this? Are there any plans to
finally
deliver the protocol specifications where these kinds of interactions
are layed
out? Or some up to date updates on the core protocol?
The core protocol hasn't changed in years, there shouldn't be much to
update.
Why update? It's about the parts where one shouldn't (or can't) use the
core protocol anymore. At some point they decided to support
"implementors" of toolkits directly (instead of delivering shiny
standard documents)? The reason to update would be: when someone needs
low level functionality one usually starts from the core protocol. But
the core protocol hasn't been updated to mention the need to support for
example the X keyboard extension. Each and every extension seems to be
documented but the only way to find out about current best practices and
else is to "scan" every documenting file of every extension and the
source code of a reference library plus trial and error prototyping? And
if I don't receive the key code to key symbol mappings by means of the
core protocol even though the current prototype implementation adheres
to its description then maybe the core protocol has been changed? That
bad start where the position of the padding bytes of some authentication
data (called magic cookie) contraddicts the described protocol encoding
seems to repeat: even that is a "documentable", I'd say.
But as I have heard the server doesn't even know about all registered
extensions anymore
The X server knows about all the extensions currently supported and
enabled for it. It's not required to support all extensions and never
has been.
- 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.
As documented in the Core Protocol spec, the 8th bit of the event code
is used
to mark if the event came from the server or a client - strip that bit
off to
get the code mapped to those reported by xdpyinfo.
http://www.x.org/releases/X11R7.7/doc/xproto/x11protocol.html#event_format
Thank you! Then it's the operation code 64 and belongs to a registered
extension then.
It's easy to make mistakes when implementing things on a bit and byte
level but
if anyone knows the "one true sequence" to draw a real circle that
would be
helpful. The FAQ mentions the Xlib flush/sync mechanism but I wasn't
able to
find any correspondence in the wire protocol and it seems to affect
the xlib
client buffers only.
Flush is simply writing the contents of the Xlib buffer from memory to
the socket.
Sync is doing a flush followed by sending a GetInputFocus request,
waiting
for the response, and then discarding it.
Thank you! That confirms my suspicion that I'll have to use "bogus"
events from time to time to flush or sync graphics and state reflections
(which isn't any problem when known). But my original intention to
contact X.org stems from the fact that these kinds of interactions
between clients and servers aren't well documented but could be as part
of the protocol.
_______________________________________________
[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
