elf
/
xcb-studies
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

Friggin' Github Flavored Markdown

This commit is contained in:
Elf M. Sternberg 2022-02-27 11:06:33 -08:00
parent 9c7c7b9914
commit e6d836b005
1 changed files with 20 additions and 20 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

40
docs/XCB_Cheatsheet.md
View File

@ -16,9 +16,9 @@ string predates the URL standard.
Part of the problem with untangling the hierarchy in X-Windows is that
it's meant to be extremely malleable and re-usable. [The Wikipedia
article](https://en.wikipedia.org/wiki/X_Window_System_protocols_and_architecture)
article](/uri https://en.wikipedia.org/wiki/X_Window_System_protocols_and_architecture)
says that the `display` has a top-level window; The [Xlib
Tutorial](https://tronche.com/gui/x/xlib/introduction/overview.html)
Tutorial](/uri https://tronche.com/gui/x/xlib/introduction/overview.html)
says a `screen` is a physical monitor, and a workstation can have more
than one screen, but each screen has its own top-level window. But
both of these statements are inaccurate!
@ -39,10 +39,10 @@ them, assigning `crtc` devices to each `output`, and choosing a
default set-up that will support running your
instance of GTK or KDE or whatever.
<aside>You kids have it easy. Before the existence of modern,
self-describing hardware, we had to hand-enter every single one of
these details, and if you got a detail wrong it was possible to burn
out your video card or monitor!</aside>
> ASIDE: You kids have it easy. Before the existence of modern,
> self-describing hardware, we had to hand-enter every single one of
> these details, and if you got a detail wrong it was possible to burn
> out your video card or monitor!
For example, in a two-monitor set up X will have a single `screen`
with a single root `window` spanning both monitors, but there would be
@ -63,21 +63,21 @@ currently tracking to the new orientation. Most modern window
managers are pretty good about re-arranging the screen to manage this
change!
<aside>It makes no sense for a virtualized `output` device, one which
has no actual display visible to the human eye, to have a `crtc`.
It's orientation doesn't matter. If it ever _is_ displayed to a human
being it will be in a virtualizing environment such as
[Xephyr](https://en.wikipedia.org/wiki/Xephyr), in which case it will
be getting its `crtc` information from the host **X** display.</aside>
<aside>I'm still not sure how all this interacts with a window manager
that has 'workspaces', such as Gnome-Mate. Which means I could be
entirely wrong about this whole thing! On the other hand, it could be
as simple as every workspace having it's own pseudo-root-window, and
being dependent upon the `crtc` object for screen dimensions and pixel
mapping. [I have to read this
carefully](https://jichu4n.com/posts/how-x-window-managers-work-and-how-to-write-one-part-i/).</aside>
> ASIDE: It makes no sense for a virtualized `output` device, one which
> has no actual display visible to the human eye, to have a `crtc`.
> It's orientation doesn't matter. If it ever _is_ displayed to a human
> being it will be in a virtualizing environment such as
> [Xephyr](/uri https://en.wikipedia.org/wiki/Xephyr), in which case it will
> be getting its `crtc` information from the host **X** display.</aside>
> ASIDE: I'm still not sure how all this interacts with a window manager
> that has 'workspaces', such as Gnome-Mate. Which means I could be
> entirely wrong about this whole thing! On the other hand, it could be
> as simple as every workspace having it's own pseudo-root-window, and
> being dependent upon the `crtc` object for screen dimensions and pixel
> mapping. [I have to read this
> carefully](/uri https://jichu4n.com/posts/how-x-window-managers-work-and-how-to-write-one-part-i/).</aside>
>
TODO: I haven't yet figured out the bit about remapping the tablet's
touchscreen inputs, so that when you place your finger or stylus on
the screen **X** maps the pointer location to the right place.