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.
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
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.
--
-Alan Coopersmith- alan.coopersm...@oracle.com
Oracle Solaris Engineering - http://blogs.oracle.com/alanc
_______________________________________________
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s
