- I don't know my hardware, how can I configure X?
- How do I set the correct permissions of my Xserver binary?
- When I start X can I get the root window display a solid color instead of the 'root cross stitch'?
- My keyboard is dead, what can I do?
- I seem to be unable to allocate a sufficient number of colors in 8 bit.
- How do I set up a multihead configuration?
- How can I configure the Xserver bell (xkbbell) to use the sound subsystem of my computer? (ALSA, OSS, etc.)
- How do I find out which process owns a given window?
Don't worry, todays configuration tools do a pretty good job detecting hardware automatically. If you 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 can use the tools shipped with X.Org. You may want to use the graphical tool
xorgcfg to do your Xserver configuration or 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
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
/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
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
- monitor section for that monitor.
- device sections. One for each card. Use the !BusID token to specify which card is which.
- screen sections. Each referencing the separate card, but both can reference the single monitor section.
- server layout section that references both screens, eg:
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
n is replaced by the number of the connector. (ie.
How can I configure the Xserver bell (xkbbell) to use the sound subsystem of my computer? (ALSA, OSS, etc.)
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,
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:
- Their use is recommended but not required. Not all X clients set them.
- Applications and toolkits that do set them often do so only on a single window which may not be anywhere close to either the root window or the "leaf" windows reported by mouse events. In this case, use of XQueryTree is required to traverse the window hierarchy to find it.
- Most Importantly, the contents of the properties is entirely within the control of the application itself! This means that a malicious application could easily report false values!
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.