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

View File

@ -16,9 +16,9 @@ string predates the URL standard.
Part of the problem with untangling the hierarchy in X-Windows is that 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 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 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 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 than one screen, but each screen has its own top-level window. But
both of these statements are inaccurate! 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 default set-up that will support running your
instance of GTK or KDE or whatever. instance of GTK or KDE or whatever.
<aside>You kids have it easy. Before the existence of modern, > ASIDE: You kids have it easy. Before the existence of modern,
self-describing hardware, we had to hand-enter every single one of > 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 > these details, and if you got a detail wrong it was possible to burn
out your video card or monitor!</aside> > out your video card or monitor!
For example, in a two-monitor set up X will have a single `screen` 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 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 managers are pretty good about re-arranging the screen to manage this
change! change!
<aside>It makes no sense for a virtualized `output` device, one which > 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`. > 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 > It's orientation doesn't matter. If it ever _is_ displayed to a human
being it will be in a virtualizing environment such as > being it will be in a virtualizing environment such as
[Xephyr](https://en.wikipedia.org/wiki/Xephyr), in which case it will > [Xephyr](/uri https://en.wikipedia.org/wiki/Xephyr), in which case it will
be getting its `crtc` information from the host **X** display.</aside> > 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: 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 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 touchscreen inputs, so that when you place your finger or stylus on
the screen **X** maps the pointer location to the right place. the screen **X** maps the pointer location to the right place.