View source for X notes

{{#addbodyclass:tag_tech}}
{{ShellsAndAdmin}}
{{stub}}

See also [[Remote X windows]]


==Concepts==
The terminology can be a little confusing: 

* '''X clients''' are the programs; they connect to an X server and tell it how to draw themselves.

* An '''X server''' is the thing that accepts and actually draws programs. 
** On linux this is Xorg (do some other unices still use XFree86?{{verify}})
** On windows you can get an X server via Xming (free), cygwin (free), Exceed (?), WinaXe (?), 
** The *nix VNC server is an X server

* An X '''display''' corresponds to a particular viewport, independent of others. Displays are uniquely referencable, and are the things X clients actually connect to.
<!--
** A simple single-monitor setup will usually have exactly one display, {{inlinecode|:0}}, which is rendered by your video card. This localhost setup is now usually capable of more fancy things than remote-displayed X.
** You can have multiple displays, for example for systems that allow multiple local graphical logins ("log in as another user"). Only one of them is rendered by the graphics card
** Multiple monitors '''if''' they are being rendered by separate X servers, such as many-terminal setups. However, many people use multiple monitors to show a single X display (usually meaning multiple '''screens''' under a display, e.g. :0.0, :0.1, although some methods of extension are ignorant of screens)}}.
** VNC is an X server, so also creates a locally referenced display, but which won't be rendered on a local monitor
-->

* '''display manager''' - the graphical thing with which you log in locally. Mostly just a program run by the way X is ''usually'' started.

* '''window manager''' - the thing that makes the graphical boxes resizable after you log in.




===DISPLAYs elsewhere===

The X protocol is networked by nature (though there are a handful of footnotes to that, see e.g. the next section), so you can display programs on other computers. 

The localhost-display target of <tt>:0</tt> is actually an abbreviated use; the fuller form is ''<tt>hostname:displaynumber.screennumber</tt>''

* hostname defaults to localhost if omitted {{comment|(which on unices will often mean the use of unix sockets rather than IP)}}. Note that a number of X extension only work on localhost. Particularly some of the fancy graphics details.

* screennumber defaults to 0. This is there only for multi-monitor setups (because they share input devices). You can usually ignore this completely.


You can send programs elsewhere...
* explicitly, like <tt>xclock -display 192.0.2.33:0</tt>, or 

* by have it read from the enviroment, e.g. after you did a <tt>export DISPLAY=192.0.2.33:0</tt>. 
The latter tends to be rather more convenient.

===X11, Xorg, Weyland, Mir===
{{stub}}

<!--

'''Then and now'''

The historic implementations of X on PCs were:
: Xfree86 (1991..2008 or so) and 
: Xorg (2004 onwards)
Both were also the [[de-facto standard]]s/implementations of their time.


The original X11 design comes from a time of different priorities. 

X11 is a protocol describing a client-server setup, was [[Remote_desktops#X_windows_over_the_network|network-oriented]].
{{comment|(This also made it a good choice to be able to cheaply set up an office with many screens, by having a single workhorse computer doing most of the work for multiple users, and e.g. a dozen physical [https://en.wikipedia.org/wiki/Thin_client thin-client] X terminals doing little more than drawing the result. This probably wasn't the most common way to run X, but some places very much appreciated the option)}}

Relatedly, the X11 protocol was designed at a time where remote user's bandwidth was measured in ''kilobits'',
meaning it was focused on transferring ''descriptions'' of widgets, e.g.
: ''"draw a button of this size at these coordinates"'' style commands rather than 
: "here's a ten thousand pictue image that also happen to also be a region you should react to (so, a button)


As better computational and graphical hardware became more affordable, 
it made more sense to run both sides (program and the drawing) on the same host,
meaning X client and X server were now almost always on the same host.

And people wanted 3D.

And people wanted hardware-decoded video (because HD content is 20+ million pixels per second and sort of ''requires'' that).

And people wanted multiple monitors, and hotpluggable.



Yet in the process of making X11 do fancier things, devs were not willing to break backwards compatibility of X11's core.

This is cool in the sense that almost anything still runs, and most anything can still run over the network.

Yet, years and years of backwards compatible patchery later, the real-world X11 internally became an increasingly weird thing.

Since the the specs of X11 were never meant for this, it required said specs being being bent increasingly much,
''just'' to locally do fancier graphics without being glitchy and/or slow.


A lot of X extensions happened,  in part because more [[IPC]]-like interfaces were ''necessary'' to do these things at all.
But these extensions grew complex, co-dependent, conditional, messy.  Some were retired and replaced from scratch out of sheer frustration.
If you've messed with linux for a while, you will have heard of some of these names, like Xinerama, XRandr, DRI. They are part of the reason X works quite quickly ''locally''.


In part because of of that "X server only does basic drawing", 
if you wanted fancy graphics, X itself wouldn't really help you
but of course programs themselves could cover themselves in as much pixely rendering as they wanted. 

Locally, drawing those is just a few RAM copies, so we didn't notice this shift in responsibilities.


Remotely, though, you will notice that "drawing things on screen" now requires sending 
In some cases this is not all that different from trying to send video over the network in the dumbest way possible: with bare pixels.

That is to say, it will work, but it will ''not'' be fast.
It may be perfectly fine over LAN, and not so much over anything with higher latency and/or lowish bandwidth.


Try it. 
SSH into another workstation in the same LAN, run a browser. 
Very usable, might even work for smallish video, though you can perceive a sluggishness.

Now SSH into work, run a browser.
That's not misconfiguration, that's the nature of prerendered-style X over even slightly higher latency.



Also yes, a lot of the fancy stuff doesn't function on it at all.
Modern stuff will often still function because even though they very much prefer the varied extensions, they will often have fallbacks. But it won't look great ''or'' be very fast.




'''What is the X server, really?'''

Additionally, people realized that with most X clients rendering stuff ''themselves'', the X server has very little left to do but blit big pixmaps.

Yes, all the old fast widgety stuff is still there, but it's never being used (and even if an app does, modern window managers will probably be compositing alongside everything else{{verify}}).

In other words, X has is mostly just a compositor[https://en.wikipedia.org/wiki/Compositing_window_manager].
Blending efficiently is why 'compositor' became a relevant, relatively new term in X, and matters to hardware accelerated things.
Again, mostly same-host stuff.

This also implies that transferring pixmaps efficiently is now quite important.
The X11 protocol wasn't really set up to transfer pixmaps this way, we just made it do it anyway.

It ''works'' perfectly well, it turns out to be a less efficient than it could be, 
partly because of the X11 protocol,
partly because of the Xorg implementation. 
There is more indirection than you'ld think, 
there are more round-trips than necessary if you're using it only as a compositor.



There is further criticism of old X11. 

One of the larger ones is that it was never designed for strict security.
It was not imagined that different X clients to an X server should not be able to snoop on each other.
Not the largest issue at all (if you don't trust people, why are they on your host in the first place),
but one which we might as well address (e.g. allowing multitenant with less worry).


The combination of the last two points asks whether we might design a better system.


'''Weyland''' {{comment|(and in this broad view, Mir is basically the same as Weyland)}}

Weyland is mostly just simpler than the layers-of-duct-tape thing that is Xorg.

In fact it's mostly just a compositor, since that was all that were were using Xorg for anyway,
and this alone already avoids a bunch of ping-ponging overhead that X11/Xorg must do because it must work on smaller  pixmaps.



X11 is immediate-mode - which means there is no such thing as a frame.

Weyland intentionally models frames. This makes elimination of flicker and tearing easier.


X11 was sometimes too low-level to have responsibilities be clear, 
e.g. relating to input (which was also a security issue).
Weyland makes the compositor do this.

(Security-wise, that's not actually a full solution. Weyland partly just goes "it's a userspace problem", which is partly better, but e.g. screen-locking is... sort of worse? That is, we have understood for a long time that secure screen locking is an OS problem. Weyland specifically doesn't do that. There have been various bugs with people crashing the screen lock and geting access. That's sort of an inexcusable failure mode that Xorg didn't allow. To be fair, those bugs are fixed and now it's ''probably'' more secure than the X11 way. But under wayland we ''cannot'' have screensavers.)




'''Resistance to Weyland'''

So, there is a "it doesn't seem broken, don't fix it with something different" attitude to keeping Xorg, 
and rejecting the Waylands and Mirs of the world.

This is, partly, because you have never written X code.



There is also an idea that it would give up the networked nature of X11. 

As discussed above, that transparency has been semi-broken a long time ago by fancy graphics.
That is, you can do it, but it's almost impossible to do efficiently.

-->

See also:
* https://www.youtube.com/watch?v=cQoQE_HDG8g "The real story behind Wayland and X"

==X authentication==
{{stub}}

{{comment|(mostly interesting in the context of ssh, su, and perhaps local-network trickery)}}


Authentication can be done...
* per '''host'''
** ...more specifically every connection originating on a host
** using {{inlinecode|xhost}}, which sets policies for a running X server (a runtime thing)
** simple
** most parts are too coarse-grained to be good on multi-user systems - but look at SI:


* via '''cookie'''
** ...which are (randomly generated) shared secrets
** using the <tt>MIT-MAGIC-COOKIE-1</tt>  or  <tt>XDM-AUTHORIZATION-1</tt> method/protocol, which both store a secret in ~/.Xauthority
** In SSH, this is part of the connection setup
** it's not hard to do manually {{comment|(which can be useful in the presence of things like [[su]] and [[screen]])}}

* per '''user'''
** using the <tt>SUN-DES-1</tt> protocol (RPC-based) (stores only the principal in ~/.Xauthority), or
** using the <tt>MIT-KERBEROS-5</tt> protocol



===xhost===
{{stub}}

xhost manages a list of entries that allow specific remote hosts to connect to us.

Half the time this is too coarse-grained (and overlaps with basic firewalling), but has its uses.


Entries are in the form {{inlinecode|family:name}}, where families are:
 inet      IPv4 host  (name resolved to numeric address on add {{verify}}, except for localhost {{verify}})
 inet6     IPv6 host  (name resolved to numeric address on add)
 krb       Kerberos V5 principal
 local     domain sockets? (or loopback?)  (note: '''ignores name value''')
 nis       [[NIS]] network name
 dnet      DECnet host
 si        Server Interpreted

Notes:
* local means domain sockets, which are what gets used when DISPLAY looks  like {{inlinecode|:1}}

* localhost is a special case of inet{{verify}}

* SI is an interesting one, because it allows extensions like (more details in {{manpage|Xsecurity}}):
 si:localuser:root
 si:localgroup:staff
 si:hostname:example.com

* {{inlinecode|xhost +}} means "disable all checking, regardless of what's on my list"
: useful during debugging, e.g. when verifying whether it's e.g. your xhost settings or your firewall that's blocking things
: but in general you '''never''' want to say "the entire world". Because you're counting on someone else's firewall to save you


Show current list:
 xhost

Add to list {{comment|(default is +, so e.g. the first two are equivalent)}}:
 xhost +example.com
 xhost example.com
 
 xhost +local:
 xhost +si:localuser:root
 
 xhost +nis:john@
 xhost +nis:unix.uid@domainname


Remove from list {{comment|(match string from xhost list exactly)}}:
 xhost -example.com


TODO:
* some people suggest that local: take arguments, but this is ignored (just useful for your bookkeeping)

===Xauth===

<!--
{{stub}}

Xauth is generally a per-display shared secret approach.

Entries are essentially (secret, display) tuples {{comment|(so a user can run and separately manage multiple X displays)}}


When a local X server is started, it generates a cookie and writes it to <tt>~/.Xauthority</tt>
so that (only) the user that started this session can read it. 
(presumably specifically {{inlinecode|xauth generate}} which also registers that with the X server?{{verify}})

From then on, any X client from that user can read that secret - which authenticates them to the specific X server {{comment|(assuming they're trying to connect to the right one)}}.


Tunneling, like SSH, will use xauth generate to add to .Xauthority (...on what SSH-wise is the server), to allow SSH to connect clients using this (presumably works because xauth generate contacts the X server)



Note that only {{inlinecode|xauth generate}} contacts the X server{{verify}}, most other commands just show .Xauthorty entries to you.

The man points out the main function to this command is probably copying Xauthority entries to other accounts (to let them use currently-valid secrets).



Show current list:
 xauth list


Add a random cookie
 xauth generate :0 .
 


Notes: 
* the single . there is a shorthand for MIT-MAGIC-COOKIE-1

* {{inlinecode|xauth generate}}
: is a newer form {{comment|(previously it'd be more like {{inlinecode|xauth add :0 . `mcookie`}}, where mcookie just generates a random 128-bit number, and isn't otherwise special)}}
: it gets a random number from the SECURITY extension instead
: it allows the trusted/untrusted distinction from SECURITY
: TODO: does that mean only generate adds authentication, and add is only an alternative to merge?

* SSH doing X forwarding is doing MIT-MAGIC-COOKIE-1 stuff for you 
: note that -X is untrusted so the sane default, and -Y is trusted
: keep in mind that there's a good reason SSH itself usually only allows X connections from its loopback

* if someone is allowed via xhost allows something, xauth isn't even checked {{verify}}



Notes on .Xauthority:
* it's insecure if anyone else but you can read this

* it is possible to not be the owner, e.g. if your first X command was something sudo'd




'''untrusted versus trusted'''

A '''trusted''' client has full access to the display. 

An '''untrusted''' client cannot reach resources owned by of trusted clients - see also [https://www.x.org/releases/X11R7.6/doc/xextproto/security.html the SECURITY extension]

tl;dr:
: most apps are fine running untrusted, and this is more secure.
: a few things will need to be trusted.
:: Including things from before that extension that just ''assume'' they can do everything
: xauth add/generate add untrusted entries by default {{verify}}



SUN-DES-1 is based on a NIS server acting as a network principal,
so only applies when you have one.




If you want to extract part of .Xauthority to go elsewhere:
 xauth extract - $DISPLAY 
...is basically .Xauthority file filtered for the given display.
This can e.g. be handed to {{inlinecode|xauth merge -}}



See also:
* http://tech.zhenhua.info/2010/03/ssh-xauth-and-x11-forward-after-user.html
* http://www.acm.uiuc.edu/workshops/cool_unix/xauth.html
* http://gdwarner.blogspot.nl/2009/09/trickyness-that-is-called-xhost-xauth.html
* http://zweije.home.xs4all.nl/xauth-6.html
* http://brooknet.no-ip.com/~lex/public/xcookies.html

https://zweije.home.xs4all.nl/xauth-6.html

TODO: See descriptions of xauth cookies like [http://scv.bu.edu/Graphics/access_ctrl.html] and [http://www.xfree86.org/current/X.7.html]

-->

===further notes===
<!--

MIT-MAGIC-COOKIE-1 sends the key plainly so is snoopable, 
while XDM-AUTHORIZATION-1 and SUN-DES-1 add some encryption.


This used to matter a lot more before remote X11 was typically done over SSH.



-->


===See also (auth)===

* http://en.wikipedia.org/wiki/X_Window_authorization

* {{manpage|xhost}}

* {{manpage|xauth}}

* {{manpage|Xsecurity}}

===Related warnings/errors===

====Warning: No xauth data; using fake authentication data for X11 forwarding====
<!--
There is no xauth data for your display, as you could inspect with
 xauth list
You can generate it with 
 xauth generate :0 

-->



===="MIT-MAGIC-COOKIE-1 data did not match"====

"MIT-MAGIC-COOKIE-1 data did not match" usually means you've SSH'd in, then switched to another user (e.g. with [[su]]).

The technical reason is that the authorization it negotiated earlier is in the account you logged into, not the one you've switched to now.


If you can, consider SSHing to to that other user directly.


There are frequently reasons you can't, e.g. it's a passwordless account.

A workaround is to get the secret and put it in the new account, for example:
<syntaxhighlight lang="bash">
# before the su, find out the display that applies, and the cookie that belongs to it:
user@somehost $ echo $DISPLAY
localhost:10.0

user@host $ xauth list | grep 10
somehost/unix:10  MIT-MAGIC-COOKIE-1  50bffebd529039b0578209c48520f0ff

# now switch user and tell it the secret
$ su - otheruser
otheruser@host $ xauth add somehost/unix:10 MIT-MAGIC-COOKIE-1 50bffebd529039b0578209c48520f0ff
</syntaxhighlight >


Comments:
* Taken from : http://www.debian-administration.org/articles/494
: ...which tries to list the specific applicable cookie, but in a way that may not always work

=X startup and config=
==Startup scripts==
{{stub}}
(i.e. executed)
<!--

There are two ways of starting X: 
: directly, with {{inlinecode|xinit}} / {{inlinecode|startx}} or such, or
: session-managed via a graphical login ('''display manager''') 



'''Scripish files'''

* '''xinitrc''' is mostly used when invoking xinit (or startx), ''not'' by most window managers
** <tt>/etc/X11/xinit/xinitrc</tt>
** ~/.xinitrc


* '''xprofile''' are shell lines that are executed ''before'' the window manager is started
** /etc/xprofile
** ~/.xprofile
:: some setups read the system but not the user one {{verify}}

* '''xsession''' are shell lines executed when a user logs in
: not all DMs run this - or will only run their own instead
: /etc/X11/Xsession.d an analogue of the shell-specific /etc/profile.d/


Note that being scripts, you regularly want to add &amp; to lines added to these files.
If you don't, X will often wait until the particular application finishes before finishing the rest of the script - or even the window manager.
-->
===system and user xsession===
<!--
Used (only) when you use a display manager (XDM, GDM, KDM, etc) to log in, not when you use <tt>startx</tt>.

* Xsession.d (/etc/Xsession.d/*) contains files that will be run at the start of each user's session (not always present, though?{{verify}})

* ~/.xsession (executed by the display manager after login, given that user xsessions are configured to be allowed)
** may default to dm's default .xsession if you do not have your own
** may be used to start a different window manager {{verify}}
** Usually reads system Xresources (standard part of this file, you rarely want to remove that)
** Reads user ~/.Xresources (given that user Xresources are configured to be allowed)

-->
===details to specific display managers and window managers===
<!--
For GDM:
* /etc/gdm/PreSession/Default


For KDM, 
* <tt>/usr/kde/''version''/share/config/kdm/Xstartup</tt>
* <tt>/usr/kde/''version''/share/config/kdm/Xsession</tt>

For KDE: 
* placing scripts in <tt>~/.kde/Autostart/</tt> gives very similar results to using .xsession



-->

==Startup config files==
(i.e. Parsed, not executed)
<!--
* Xresources is primarily used to hand configuration variables to programs, either to easily override defaults (e.g. widget colors, xterm behaviour - the latter of which can also include things like 'what to launch for URLs'), or as an alternative to a configuration interface.


* Xdefaults


* Xmodmap (system and ~/.Xmodmap) can be used to change the input method
: You'ld rarely want a user xmodmap. 
: It e.g. has use disabling the caps lock, but you can put that in other startup scripts by calling xmodmap.
 xmodmap -e "clear Lock"
: And e.g. map it to control, or tab
 xmodmap -e "keycode 66 = Control_L"
 xmodmap -e "keycode 66 = Tab"



-->

=X keyboard=
''Unfortunately, there are like five people in the world who understand the X keyboard model--I'm not one of them--and three are insane. It's that bad.'' --&nbsp;Tim&nbsp;Showalter 

===<tt>KeyCode</tt>===
What your keyboard sends over its wire are (varying-sized) keycodes. Very usually, these cannot be changed at all.

Any particular keyboard may have more, fewer, and different keys than any other specific keyboard. Consider special alphabetic characters on region-specific keyboards, multimedia keys, a laptop's Fn, and more.


The way keys map to keycodes may vary between keyboards. Sometimes these details conflict somewhat, which is why you have to tell your computer about your keyboard if you have something regional or otherwise special.


{{comment|(Side note: '''<tt>KeyCap</tt>''' refers to what is physically printed on the key. It's present in X keyboard configuration seemingly purely to be able to present a visual version of the keyboard (configuration) and for 'you are now pressing this' testing.)}}.

===<tt>KeySym</tt> and modifiers===
Since each key has a single keycode, but those can differ between keyboards.

Also remember that most keys have more than one function.
For example, on the US keyboard, comma and less-than are on the same physical key, but this isn't always the case. 

Your computer has to decide what each keycode actually means for the keyboard in use, 
and what happens with which modifiers (Shift, Fn).



This is something every OS deals with, and 90% of it is you telling it what keyboard layout you have.

In X:
 

'''KeySyms''' are (usually well-named) things with an atomic meaning, such as a comma, less-than sign, small p, capital P, and so on.


For each unique keyboard type, you want to specify a map from <tt>KeyCode</tt>s to a (single) <tt>KeySym</tt>.

This is where things start less than intuitive, because most everyone thinks of keyboards in a very functional way, the most minimal, habitual way.
However, a mental step back is required as keys and meanings are not actually so directly linked.

Consider that we are quite used to keys having multiple meanings: using shift to get a {{inlinecode|&lt;}} and {{inlinecode|,}}, or a small p and capital P, out of the same key. On the keyboard interpretation side of things, you probably want to model the difference between alphabetic versus nonalphabetic keys: consider how you expect (Caps) Lock to only have effect on alphabetic keys, while Shift has effect on  ''all'' keys that have a second meaning (which is almost all keys).

This is also where modifiers get involved.


====Modifier intro====
Modifiers deserve special mention, because they end up being much of the practical complexity in the X keyboard model. 


There are three modifiers with pre-set semantics: Shift, Lock, and Control. 

There are also five modifiers ''without'' explicit meaning: <tt>Mod1</tt> through <tt>Mod5</tt> {{comment|(for, if you care about the internals, a total of eight modifier bits)}}. 

Note that most keyboards have a Shift and a Caps Lock, most have a Control, and keys such as Option, Apple, Windows, Amiga - and to some degree Alt - don't have pre-set meaning. {{comment|(...and actually, there exists a Shift Lock, which behaves differently from Caps Lock -- consider how caps lock doesn't get &lt; from the , key -- but I'm going to ignore it completely)}}.


While Shift as a ''modifier'' has special status to the interpretation on the computer side, Shift as the key you can touch is nothing special on the hardware level, it sends (and repeats) a keycode like any other. If you wanted you could switch the meaning of your shift key and the letter u. If you're ''weird'', that is.

Shift, Alt and such need to be mapped just like any other key, but (almost always) get special treatment because they are (almost always) treated as modifiers. 
In the case of Shift, you need map it to both the Shift modifier, and to a particular KeySym, like Shift_L or Shift_R<!-- so that you can refer to it-->.


====Shift and Lock, and their involvement in KeySym entries====
The X keyboard model designers decided that the Shift/Lock behaviour is important and usual enough to model directly. For this reason, KeySym entries can consist of multiple values, which define the alternatives, if any, you get when you use (only) the Shift or Lock modifier.

You map to an array of four <tt>KeySym</tt>s, seen as two groups with two entries each {{comment|(Actually eight, in four pairs, but Group 3 and 4 are rarely used, and even group 2 isn't necessarily used)}}, and you can use shorthands when declaring the KeySym array:
 "K1"         means/expands to   "K1 NoSymbol K1 NoSymbol"
 "K1 K2"      means/expands to   "K1 K2 K1 K2"
 "K1 K2 K3"   means/expands to   "K1 K2 K3 NoSymbol"


This shorthand is followed up by more expansion to ease work for alphabetic keys: ''if'' a group's second entry is NoSymbol, and the first entry is alphabetic, then the first and second entry should be the lowercase and uppercase form of that character (respectively).
If the first ''isn't'' alphabetic, both entries mean the same thing. 

<!--
The entry for the P key would conceptually be "p P" but because of the above could be abbreviated to "p". The entry for the -_ key would probably be "- _" 
-->

Now, when you actually ''use'' a key, you use one of the two entries (in the current group) based on the Lock and Shift modifiers:
 No shift, no lock: first entry
 
                    ({{key|p}}&rarr;<tt>p</tt>)
 
 
 Shift:             second entry
 
                    (Shift-{{key|p}}&rarr;<tt>P</tt>, Shift-{{key|-}}&rarr;<tt>_</tt>)
 
 
 Lock:              if second entry is alphabetic: second entry, otherwise the first entry
 
                    (Lock-{{key|p}}&rarr;<tt>P</tt>, Lock-{{key|-}}&rarr;<tt>-</tt>)
 
 
 Shift+Caps:        If second entry is alphabetic: first entry, otherwise the second       
 
                    (Shift-Lock-{{key|p}}&rarr;<tt>p</tt>, Shift-Lock-{{key|-}}&rarr;<tt>_</tt>)

{{comment|(The rules are different if you have a Shift Lock key rather than a Caps Lock. I'm still ignoring that)}}

====Groups and Mode_switch====
The groups can be switched between using something that is mapped to KeySym <tt>Mode_switch</tt>. It effectively works as a second shift, meaning each key could have four different meanings (though often three in practice). Regional keyboards and laptops have a key to an effect like this, like AltGr or Fn.


You could get creative with this. You could, for example, add a non-latin alphabet, and map caps lock away from Lock (few people like or use their caps lock) and instead map it to Mod_switch, meaning it's now the key that accesses that 'second keyboard' -- or just use this to make CapsLock-E, CapsLock-5, or CapsLock-2 produce a Euro sign (usually printed on one of those keys). 
Or heck, you could make Mod_switch produce Phonetic characters or ROT13 text. Or Al-Bhed, if you're that muck of a geek anyway:) 

Note, however, that special input is often more flexible, and more portable to other computers, if you use software to do this, such as UIM or SCIM, instead of redefining your keyboard map.

===Multi_key (a.k.a Compose)===
Multi_key, not to be confused with Switch_mode, allows you to compose a character from several others.

If you 
* map something (say, the right Menu key, or Caps Lock) to Multi_key, 
* define compositions that you want
...you can use, for example, ''Compose''{{key|'}}{{key|a}} to produce &aacute;.


====More modifiers details====
As mentioned, the X model focuses quite a bit on modifiers. Shift and Lock are already explained. 

Mod[1-5] are used to map Alt, Super (often the Windows key), Menu, Hyper (?) and such. Mod bits are not always mapped the same way. 

If you use KDE or GNOME (possibly others) there is often a keyboard configuration application. 


Alt_L and Alt_R and Meta (which is not the same as Alt - a few keyboards have both) are regularly mapped onto Mod1. Applications shouldn't assume this, but some do. For example, emacs does, and calls it Meta{{verify}}, though they should technically check this with the X modifier map (run {{inlinecode|xmodmap}} to see yours).


<!--
Unsorted stuff:

X programs get these remapped events, and can choose to see just the text they produce (ASCII, possibly with >0x80 use)

To see the keyboard map - and be able to redefine it - take a look at {{inlinecode|xkeycaps}}. 

<!--
Consider that:
                                                  normal   lock shift control    shift-control   shift-lock
  left square/left curly bracket (US keyboard)      [       [     {    0x1B          0x1B            {     
  minus-and-underscore           (US keyboard)      -       -     _      -           0x1F            _     
  p                                                 p       P     P    0x10          0x10            p     
(It looks like in this context, Lock and control do not combine, and act as control. That is, control-lock counts as control, and shift-control-lock as  shift-control)
-->

===Repeating===
Repeating seems to be per-key behaviour at X-level (maybe because it is filtered?), but often is not handled as reported{{verify}}.
-->


===See also===
* http://www.jwz.org/xkeycaps/man.html
* http://tldp.org/HOWTO/Intkeyb/x772.html


[[Category:Unices]]

=Multiple X screens, xrandr=
{{old}}

==Multiple monitors - different methods==
===Clone===
The same on all outputs. Generally useless, other than in specific situations (e.g. monitor+projector combinations).

===Separate X instances===
Separate in terms of input, rendering surfaces, and whatnot.

Now regularly used for multi-user login. 


===Multiple X screens===
X itself supports running multiple separate displays in the same X instance. Separate in terms of rendering targets. For example, windows cannot appear half on one, half on another.

Window managers usually treat these as completely separate too. 
You can move the mouse back and forth, so if you don't mind the separation, this may serve your needs.

Not so commonly used.


===(Merged rendering)===
There are a few different implementations of the idea of gluing different configured physical screens into one logical X screen. The fact that it will end up rendered on multiple physical things may be transparent to most of X.

Implementations:
* Xinerama is the open version
* MergedFB is technically better but not as supported
* TwinView is nVidia's implementation
* Big Desktop is ATI's name 


====Xinerama====
An extension of X, and transparent to drivers, so this option may work the most setups. It is in some ways a simple-and-stupid hack, however (it e.g. duplicates resources to get around the fact that X Core has resources per screen). 

Usual implications:
* hardware 3D and/or video overlays may work only on one screen (at all, or at a time)

* You cannot rotate parts of a xinerama setup - XRanrR is disabled when xinerama is enabled. May be supported in future versions. (written when?{{verify}})

* You cannot change the configuration on the fly, or even easily base it on detection, which matters in some situations, such as when you use an external screen on a laptop.


====MergedFB====
Similar idea to Xinerama, better implementation: supports 3D on all heads, supports XRandR{{verify}}.

However, the driver has to specifically support it. A number of open drivers have relatively experimental support, some usable. Commercial nVidia and ATI drivers do not ({{verify}}).


====TwinView====
Needs binary nVidia driver.

Supports XRandR {{verify}}


====Big Desktop====
Needs binary ATI driver{{verify}}.

Supports XRandR {{verify}}

fglrxconfig

==Other==
==XRandR, a.k.a RandR==
The X Resize and Rotate Extension (a.k.a. X RandR, XRandR, RandR) allows resolution changes on-the-fly, and also rotation assuming your setup supports it.

===Check===
To double-check whether X is loading it, check the X log:
 grep -i randr /var/log/X*.log
You'ld see something like:
 (==) RandR enabled
 (II) Initializing built-in extension RANDR
or even
 (II) intel(0): RandR 1.2 enabled, ignore the following RandR disabled message.
 (--) RandR disabled
 (II) Initializing built-in extension RANDR

===xrandr===
<tt>xrandr</tt> is the command line interface to the RandR extension. 

====capability query====
Without any options it will report what it can do. To query separate displays (e.g. on a dual-monitor setup):
 xrandr -q
...and for specific displays, which is useful on multi-head monitors set up with different dispalys:
 xrandr -q -d :0.0
 xrandr -q -d :0.1

====resolution change====
You can change the resolution on-the-fly by specifying one of the numbers {{comment|(if you do this automatically from some script, you could specify a specific resolution if you want that script to be portable between setups)}}
 xrandr -q 1 

====rotation====
When you do a query, you will see the relevant options below the list of resolutions, something like:
 Rotations possible - normal
 Reflections possible - none

This particular output mens that reflection is not supported, and that there is only one rotation, 'normal' - in other words, that rotation is not supported. There seem to be various reasons, including:
* the card does not support it
* the driver does not support it
* the current X config does not support it:
** the combination of X extensions does not allow it {{verify}} (Which? XV? Xcomposite?)

TODO: Look at the effects of TwinView and xinerama. Do both imply you can't?


===gnome-randr-applet===
{{stub}}

===nvidia-settings===
{{stub}}

=Unsorted=

MergeFB
Clone

http://www.ogmaciel.com/?p=272



===Drag-window shortcut===

In the olden days
* Alt-leftmouse moved the window.
* Alt-rightmouse resized the window (often picking up the bottom right corner)


GNOME seems to have changed this to Alt+F7 and Alt+F8, but can be set back to the classical mode with:
 gsettings set org.gnome.desktop.wm.preferences mouse-button-modifier '<Alt>'
 gsettings set org.gnome.desktop.wm.preferences resize-with-right-button true

https://askubuntu.com/questions/1336681/how-to-set-altmouse-drag-to-move-the-window-and-ctrlmouse-to-resize-the-window




===Weyland does not support screen savers===

In weyland, blanking and locking are handled in the display manager.

There are edge cases in screen-saving under X11 details that this fixes, 
but it means no screen saver at all.


It also means that tools like xtrlock (lock screen but keep showing windows)
cannot function properly anymore.



===Clipboard===

'''"Why do I seem to have two clipboards?"''' / '''"Why is it pasting something different from what I copied"'''

<!--
* X has its own clipboard-like thing, from days of yore

* A display manager may add its own, and usually does, e.g. to add your very reasonable modern expectation of Ctrl-C, Ctrl-V actually working.

(are cut buffers a different-yet and obsolete mechanism?)


'''More on X clipboard(s)'''

X11's actually has ''multiple'' clipboardy things, but in most cases you will be interacting only with its '''primary selection''',
the thing that holds whatever text you selected last (with mouse or keyboard) and paste from with middle-mouse (there is no keyboard standard, though terminals may take from there if you use Shift-Insert)

It seems that historically, 'selection' was more literal, pointing into a progam's text,
where another could fetch "thing that is currently selected".{{verify}}
These days, it looks more like selecting does a copy, and you get that copy.{{verify}}




'''"Can I disable the X11 mechanism?"'''

To a degree, yes.

You could also just... not use it, since it does ''not'' interfere with Ctrl-C Ctrl-V.


'''"Can I synchronize the two?"'''

Yes, there are tools to do that.

There are variants of their configuration, 
but if selection overwrites the ctrl-c clipboard,
remember that ''any'' selection does that,
and you will probably quickly find that to be more annoying than helpful.





---

You may have two completely different clipboard in parallel. 

More, actually -- it has various '''selections''' (to use its terminology), 
only one of which you can also call its clipboard.


Primary and secondary are the other two selections.

Cut buffers are not selections; they're a different and obsolete mechanism


In everyday use, 
* the '''primary selection''' is the thing that 
** holds whatever text you selected last (with mouse or keyboard)
** paste from 
*** mouse: with middle-mouse   (often emulated with left+right, e.g. for touchpads - 2-button mice are very rare now)
*** keyboard: no standard.  Terminal apps added the converntion of Shift-Insert, other apps may use the same for other sources as well
*** menu: no standard

* a secondary selection is not used by anything anymore


There is an X11


* a '''cutbuffer'''

* (a '''clipboard''')



"I don't like there being two. Can't we just synchronize that?"

We sure can. 

However, the primary selection is... a selection. 
If you are e.g. in the habit of selecting the text you want to replace with what is in the cliboard.
-->

<!--
parcellite

https://unix.stackexchange.com/questions/188977/operate-x-clipboard-from-command-line


https://superuser.com/questions/68170/how-can-i-merge-the-gnome-clipboard-and-the-x-selection

https://github.com/rickyrockrat/parcellite

-->

===Maximum number of clients reached===
<!--
There is a hardcoded limit of 255 clients (some distros compile it with a higher number).

Counting the clients for a given display (defaulting to $DISPLAY)
 xlsclients    # | wc -l


Counting windows: (relevant or not?)
 xwininfo -root -children    # | wc 



https://askubuntu.com/questions/4499/how-can-i-diagnose-debug-maximum-number-of-clients-reached-x-errors


https://www.redhat.com/archives/rhl-beta-list/2009-May/msg00751.html
-->

[[Category:Unices]]