Friggin' Github Flavored Markdown
This commit is contained in:
parent
9c7c7b9914
commit
e6d836b005
|
@ -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.
|
||||||
|
|
Loading…
Reference in New Issue