Xorg Rants

• 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, a lot of things could break down. For example, if you OpenGL coupled with DRI2 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 read that bitmap back from the Xserver. You can only get rectangles. In worst case, this would require several times the amount of data to be sent.
  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:
     1. Xinput and Xinput2. Instead of updating Xinput, a new extension is created. They have some overlaps, and Xinput2 in general does more. But actually Xinput2 cannot do everything Xinput can do.
     2. The event system. Core events vs XGE.
• 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, Xserver and the clients are inherently racy.
  • New event could arrive while you are doing something to make your state stale. Therefore there is no way to know if the information you get from a query is actually what you think you get, or a request would do what you think it would do.
  • 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)
     • Details: the picom mainloop basically does this: poll on the X connection, when it becomes readable, ask Xlib for events, handle them, update the screen, then go back to poll. The bug is, when asked for events, Xlib mistakenly ask xcb to read events into xcb's buffer, without realizing it. If, in rare cases, an event happens to arrive at exactly this point, it will be read into xcb's without Xlib knowing about it. So it would tell picom there are no events, while there are actually events sitting in xcb's buffer. This might not always be too bad. However, the type of Damage event used by picom is edge triggered, new events won't be generated until the old event is cleared. So, if picom goes to poll while there are Damage events sitting in xcb's buffer, it won't get new Damage events even if the windows are being updated, causing the screen to appear frozen.
• https://www.youtube.com/watch?v=RIctzAQOe44