A linux server is running an xdm supporting XDMCP, it is connected to from various different Linux and OS X boxes using XDMCP via an X -query <server> command.

Once the user is logged in the window manager is started, which is mostly controlled from the keyboard using an assigned meta key.


The assigned meta key needs to depend on the platform of the box that connects to the linux server. How do I figure out what the platform is behind the connected X server?


I cannot use the DISPLAY environment variable to switch on, the IPs of the connecting boxes are assigned by DHCP and give no clue what the platform of the box is.

I know the -class option to X can be used to set the display class, which then could be used to set defaults for the various display classes in Xresources. However I don't know how to get the class of the connected Xserver from the command line (or a little custom C program) and furthermore, I don't know how to get the value of an Xresource that would be configured with that class.

Ideally the used meta key could be configured on the box running the X server, so that the linux server running the xdm does not need any reconfiguration when a new type of platform is introduced in the setup.

What is the best way to go about this? Is it possible to determine the platform the X server is running on? Can some configuration option be passed from the Xserver to the window manager scripts? Is there a better way to resolve this?

1 Answer 1


This particular problem would be easy to solve if you set up keyboard mappings so that the same keysym and modifier is assigned to the Meta key everywhere.

You can get some information about the server via the xrdb program. The server defines some property which xrdb makes available through preprocessing. You can print them out with xrdb -symbols. For example,

xrdb -Dsymbols | sed -n 's/-DSERVERHOST=//p'

prints the hostname of the X server. You can define specific resources for a particular server host with C preprocessing constructs:

#ifdef SRVR_darkstar

Here's a shell script that turns xrdb symbols into shell environment variables. Use it with something like eval "$(xrdb_sh_prefix=X_ xrdb-sh)".

# Access xrdb #define's from the shell

# For each binding that xrdb(1) would give to the preprocessor, print
# If $xrdb_sh_export is not empty, also print "export NAME".
# If $xrdb_sh_prefix is not empty, prefix it to each NAME in output.
# Shell metacharacters are preceded by `\' in VALUEs. NAMEs are
# assumed to be admissible C identifiers.
# Example:
#   xrdb_sh_export=y xrdb_sh_prefix=X_ xrdb-sh
# outputs somthing like
#    X_SERVERHOST=drongo
#    export X_SERVERHOST
#    X_VENDOR=The\ XFree86\ Project\,\ Inc
#    export X_VENDOR
# ...
# The output of this program is typically used in a Bourne shell thus:
#   eval "`xrdb_sh_prefix=X_ xrdb-sh`"

if [ -n "$xrdb_sh_export" ]; then
  awk_export='print "export " name'
awk -v prefix="$xrdb_sh_prefix" '
  /^-D/ {
    $0 = substr($0, 3)
    eq = match($0, /=/)
    name = (prefix) (eq ? substr($0, 1, eq-1) : $0)
    if (eq) {
        $0 = substr($0, eq+1)
        sub(/^\"/, ""); sub(/\"$/, "")
        gsub(/[^0-9A-Z_a-z]/, "\\\\&")
    } else {
        $0 = ""
    print name "=" $0
  /^exit=[0-9]+$/ {sub(/^.*=/, ""); exit $0}
' <<EOF
`{ xrdb "$@" -symbols || echo exit=$?; } | $sort || echo exit=$?`

Another approach would be to set custom properties on the root window from the server side, for example with xprop. Query those properties (again with xprop) from the client side.

xprop -set Server_arch "$(uname -m)"
  • Unfortunately option one is a no-go since I cannot require users to set up their keymap in a certain way just for this one server, they will be connecting to other servers and using their X locally which could get messed up or require people to do all kinds of reconfiguration on their own boxes or on the other servers.
    – wich
    Sep 19, 2012 at 0:59
  • @wich You'd be setting up the keymap by a call to xmodmap or xkb, or a setting in /etc/xorg.conf, on the X server side. Sep 19, 2012 at 1:09
  • The X_SERVERHOST also seems a no-go, for me it just gives the IP of the box running the X server, just like it is in $DISPLAY in the environment. As mentioned it's a DHCP environment, so I cannot infer anything from the IP itself.
    – wich
    Sep 19, 2012 at 1:32
  • re: keymap Exactly, which is what I cannot require from people, adding some info tag in whichever way is one thing, but asking people to modify their keymap is not okay in this environment
    – wich
    Sep 19, 2012 at 1:34
  • As for xprop, I could not get it working yet, but aside from that the problem is that the X server is not yet running before the X -query is made, and after that xprop does not have access on the connecting box, an xhost +<IP from $DISPLAY> would need to be executed on the server box, or something similar. Even then my xprop failed for some unknown reason, which I have not yet been able to solve.
    – wich
    Sep 19, 2012 at 1:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.