Don't worry, todays Xorg releases do a pretty good job detecting hardware automatically without configuration files. If that doesn't work or if you need to override the defaults, then you can make a configuration file that just specifies the sections you need, and no longer need to provide a complete configuration for all possible sections. If you need to do this, and are using a distribution you will want to try the configuration tools provided by your distribution vendor first. If these don't work or if your vendor doesn't provide any you may let the server generate it's own configuration file by running: X -configure as root. It will create the configuration file xorg.conf.new in the home directory of the user who ran it (usually root). You should then copy this file to the default location /etc/X11/xorg.conf.
Please note: Xorg can only autodetect PCI and AGP video chipsets. If you still use an ISA/EISA/VL chipset you need to at least know the chipset vendor to specify the correct driver. Most drivers can then autodetect the chipset model.
On UN*X like systems the server is usually owned by root and runs with the SUID bit set so that it runs with root privileges even if started by an ordinary user. To check if your Xserver has the right permissions you have to locate the server binary. Usually the soft link /var/X11R6/bin/X points to the binary. Please do
ls -l /usr/X11R6/bin/X
obtain the binary the link points to (usually /usr/X11R6/bin/Xorg and do a:
ls -l /usr/X11R6/bin/Xorg
(Replace /usr/X11R6/bin/Xorg with the name of the binary pointed to by the link.) The result should look something like this:
-rws--x--x 1 root root 2019033 2003-03-17 14:26 /usr/X11R6/bin/Xorg
This file is owned by the user 'root' and has the SUID bit set (the 's' in -rws--x--x. If either one isn't true you need to fix this. Do
chown root:root /usr/X11R6/bin/Xorg
To make root owner of the file. (You have to be 'root' to do so). And
chmod u+s /usr/X11R6/bin/Xorg
to set the SUID bit. (Here again you may have to replace /usr/X11R6/bin/Xorg by the name of the binary you are using.)
Starting with version XFree86 4.3 there is the command line switch -br for the Xserver that changes the root window to a solid black. If you use startx please do:
startx -- -br
Please note: It is not easy to use any other color than black or white. At this point there is no other colormap entry than black or white in the colormap.
You need a new set of keyboard description files in /usr/X11R6/lib/X11/xkb/ that come with Xorg R6.7. Chances are that when you upgraded these files didn't get installed correctly. Try to reinstall these files and restart your Xserver.
There may be several reasons for this: You have an entry for a PS/2 mouse (on Linux on /dev/psaux) in your xorg.conf however you don't have a PS/2 mouse connected. This is actually a kernel problem. You should remove this device from your xorg.conf.
The RENDER extension preallocates some entries in the default colormap of the PseudoColor modes. This limits the number of entries available to clients. Some older 8bit clients are optimized for 254 entries in the 8bit palette (two are aloways set to white and black). If they cannot allocate all their colors they don't display correctly. In some cases changing a colormap entry is used to make certain objects blink. If there are not sufficient entries this blinking may not work.
You should make your software use a private colormap. If this isn't possible you can reduce the number or preallocated entries with a command line option to the Xserver: if you use startx to start your Xserver you can do:
startx -- -render mono
Please note that transparency or antialiasing may not work in this case.
I think there was a multihead FAQ someplace. I wonder where that's at?
Basically, you can have in the xorg.conf file:
Section "ServerLayout"
Identifier "DualHead"
Screen 0 "Screen0" 0 0
Screen 1 "Screen1" RightOf "Screen0"
InputDevice "Mouse0" "CorePointer"
InputDevice "Keyboard0" "CoreKeyboard"
EndSection
Start with a working single head configuration and create the second device and screen sections by cutting and pasting but assigning different Identifiers and, in the case of the device sections, different !BusIDs. Change the layout section to something like above.
If you have a single card with one chipset but two (or more) display connectors you have to create device sections for each connector with identical busID. To distinguish between the connectors you need to add the line
Screen n
where n is replaced by the number of the connector. (ie. n0,1,2...=).
Answer (hopefully) goes here.. :)
The answer to this is not straightforward and depends on which assumptions you are willing/able to make and what your usage model is. The first thing that should be noted is that X is a network service, so it is not enough to simply know the PID alone, you will need to know both the PID and hostname of the client, in case the client is running on a remote machine.
That said, there is a standard method for X clients to report their hostname and PID. This is via two properties, _NET_WM_PID and WM_CLIENT_MACHINE. The idea behind these properties is that window managers can query them and use them to label windows graphically or otherwise make use of them. Your application code can also query them. However, there are several caveats:
For anything more secure/robust you will need a server-side solution. Many local socket implementations provide a way to find out the PID of the remote end of a connection, such as getpeerucred(), which are kernel-based and cannot be spoofed. The server has a LocalClientCred() function that will return the values if supported. However, this will not work on remote connections.