Skip to content
yshui edited this page Aug 25, 2020 · 27 revisions
  • There are wiki pages on fd.o that guarantee you xcb and xlib works together. NO THEY DO NOT!
    1. If you for example let xcb manage the event queue, everything will break down.
      1. Xlib will kill your program on any error reply from X server.
      2. If you use DRI2, OpenGL won't work without an ugly hack
  • xcb has inherent thread unsafety baked in: https://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/118
  • In the shape extension, you can specify the shape of a window using a bitmap, but you can't get that bitmap back. You can only get rectangles. (several times the amount of data sent in extreme cases).
    1. Lots of the X protocol shows how limited the machines were back when X11 is designed. But there are also things like this.
  • On 64-bit systems, Xlib will pad 32-bit property values to 64-bit when returning them. Presumably a short-sighted hack made during the 64-bit transition. This causes code inconsistencies.
  • If there are 10 ways to do something, X will do all 10, poorly, then add in some extras.
    1. And all 10 ways will be missing bits and pieces so you can't just use one of them, you have to use all of them.
    2. Examples: the input system, the event system.
  • Xkb
    • From the name of the request XkbGetKbdByName, any reasonable person would assume it is a read-only request that doesn't change any of the server states. WRONG! It updates the server keymap.
    • Only way to find out current keymap is read the _XKB_RULE_NAMES prop of the root window. Which is not guaranteed to reflect the true keymap because it can be modified by anyone without affecting the keymap.
  • XFixes is an extension that "implements a collection of unrelated additions to the protocol." ... which include not just addition to the Core X protocol, but also to a bunch of other extensions too
    • Why add functionalities to the relevant extension, when I can just create an entire new extension for that purpose? /s
  • XRender
    • Defines a graphics-exposures flags for Picture, then say "this flag is ignored. GraphicsExposure events are never generated by this extension."
    • Composite method defines operations like PictOpDifference but did not define what it does. This function is there because it's an image operation implemented by pixman, which have no documentation whatsoever.
  • XRandR
    • RRGetScreenInfo returns a refresh rate... for which monitor?
  • Some information from X server is only available in events!
    • What window a window is on top of is only available in the ConfigureNotify event, otherwise you need to get the entire window stack to figure that out.
    • This means sometimes the application has to re-implement part of X server to keep track of certain states.
  • This comment here
  • This is an exact quote from the XRes spec:
    •  The protocol description of X Resource Extension version 1.1 has been
       either lost or has never been written. This specification documents
       version 1.0 based on reverse engineered library and server
       code. Version 1.1 has been accidentally released from the version
       control and while it doesn't have differences to version 1.0, this
       version is labeled 1.2 in order to remove the risk of confusion. In
       addition to the 1.0 description, this document introduces a new 1.2
       version of the extension.
      
  • Inconsistent coordinate systems. The origin can be inside or outside of the window border.
    • XShape choose to use the top left corner inside the border as the origin. But the border is part of a window's bounding shape! It has to use negative coordinates to describe the border.
  • There's no way to stay up-to-date with the X server
    • New notification could arrive while you are doing something to make your state stale. Therefore there is no way to know if what you get from a request is actually what you think you get.
    • Sometimes, this makes XGrabServer necessary.
      • And before you make any requests, you have to process all relevant events already in queue, so those events won't cause unnecessary invalidation later.
      • Or, you can discard events in queue that are older than your requests. Except some information is only efficiently obtainable via events.
  • Documentation is a joke.
    1. Open any xcb man page, and you will see long lists of TODO: NOT YET DOCUMENTED.
    2. The description is often as vague as possible, with important details left out.
    3. You sometimes have to WATCH LECTURES about certain X features to figure out how to use them, because there is zero documentation about them. Example: MIT-SHM fd passing.
  • Bugs
    1. Race conditions in event handling cause screen freeze when using compton (fixed)
Clone this wiki locally