sync with OpenBSD -current
This commit is contained in:
parent
acb2a22980
commit
455fea1627
GPG key ID:
F42C07F07E2E35B7
229 changed files with 25075 additions and 13981 deletions
|
|
@ -2568,7 +2568,6 @@ RecalculateMasterButtons(DeviceIntPtr slave)
|
|||
(maxbuttons - last_num_buttons) * sizeof(XkbAction));
|
||||
}
|
||||
|
||||
|
||||
memcpy(&event.buttons.names, master->button->labels, maxbuttons *
|
||||
sizeof(Atom));
|
||||
|
||||
|
|
|
|||
|
|
@ -801,7 +801,7 @@ glamor_dri3_open_client(ClientPtr client,
|
|||
int fd;
|
||||
drm_magic_t magic;
|
||||
|
||||
#ifndef __OpenBSD__
|
||||
#ifndef X_PRIVSEP
|
||||
fd = open(glamor_egl->device_path, O_RDWR|O_CLOEXEC);
|
||||
#else
|
||||
fd = priv_open_device(glamor_egl->device_path);
|
||||
|
|
|
|||
|
|
@ -1,2 +0,0 @@
|
|||
include $(top_srcdir)/manpages.am
|
||||
appman_PRE = Xdmx.man
|
||||
|
|
@ -1,732 +0,0 @@
|
|||
.\"
|
||||
.\" Copyright 2001-2004 Red Hat Inc., Durham, North Carolina.
|
||||
.\" All Rights Reserved.
|
||||
.\"
|
||||
.\" Permission is hereby granted, free of charge, to any person obtaining
|
||||
.\" a copy of this software and associated documentation files (the
|
||||
.\" "Software"), to deal in the Software without restriction, including
|
||||
.\" without limitation on the rights to use, copy, modify, merge,
|
||||
.\" publish, distribute, sublicense, and/or sell copies of the Software,
|
||||
.\" and to permit persons to whom the Software is furnished to do so,
|
||||
.\" subject to the following conditions:
|
||||
.\"
|
||||
.\" The above copyright notice and this permission notice (including the
|
||||
.\" next paragraph) shall be included in all copies or substantial
|
||||
.\" portions of the Software.
|
||||
.\"
|
||||
.\" THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
|
||||
.\" EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
|
||||
.\" MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
|
||||
.\" NON-INFRINGEMENT. IN NO EVENT SHALL RED HAT AND/OR THEIR SUPPLIERS
|
||||
.\" BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
|
||||
.\" ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
|
||||
.\" CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
|
||||
.\" SOFTWARE.
|
||||
.TH Xdmx 1 @vendorversion@
|
||||
.SH NAME
|
||||
Xdmx - Distributed Multi-head X server
|
||||
.SH SYNOPSIS
|
||||
.B Xdmx
|
||||
[:display] [option ...]
|
||||
.SH DESCRIPTION
|
||||
.I Xdmx
|
||||
is a proxy X server that uses one or more other X servers as its display
|
||||
devices. It provides multi-head X functionality for displays that might
|
||||
be located on different machines.
|
||||
.I Xdmx
|
||||
functions as a front-end X server that acts as a proxy to a set of
|
||||
back-end X servers. All of the visible rendering is passed to the
|
||||
back-end X servers. Clients connect to the
|
||||
.I Xdmx
|
||||
front-end, and everything appears as it would in a regular multi-head
|
||||
configuration. If Xinerama is enabled (e.g., with
|
||||
.B +xinerama
|
||||
on the command line), the clients see a single large screen.
|
||||
.PP
|
||||
.I Xdmx
|
||||
communicates to the back-end X servers using the standard X11 protocol,
|
||||
and standard and/or commonly available X server extensions.
|
||||
.SH OPTIONS
|
||||
In addition to the normal X server options described in the
|
||||
.I Xserver(@appmansuffix@)
|
||||
manual page,
|
||||
.I Xdmx
|
||||
accepts the following command line switches:
|
||||
.TP 8
|
||||
.BI "\-display " display-name
|
||||
This specifies the name(s) of the back-end X server display(s) to connect
|
||||
to. This option may be specified multiple times to connect to more than
|
||||
one back-end display. The first is used as screen 0, the second as screen 1,
|
||||
etc. If this option is omitted, the
|
||||
.B $DISPLAY
|
||||
environment variable is used as the single back-end X server display.
|
||||
.sp
|
||||
.TP 8
|
||||
.BI "\-xinput " input-source
|
||||
This specifies the source to use for XInput extension devices. The
|
||||
choices are the same as for
|
||||
.BR "\-input " ,
|
||||
described below, except that core devices on backend servers cannot be
|
||||
treated as XInput extension devices. (Although extension devices on
|
||||
backend and console servers are supported as extension devices under
|
||||
.IR Xdmx ).
|
||||
.sp
|
||||
.TP 8
|
||||
.BI "\-input " input-source
|
||||
This specifies the source to use for the core input devices. The choices are:
|
||||
.RS
|
||||
.TP 4
|
||||
.B dummy
|
||||
A set of dummy core input drivers are used. These never generate any
|
||||
input events.
|
||||
.sp
|
||||
.TP 4
|
||||
.B local
|
||||
The raw keyboard and pointer from the local computer are used. A
|
||||
comma-separated list of driver names can be appended.
|
||||
The following drivers have been implemented for Linux: usb-mou
|
||||
(a USB mouse driver), usb-kbd (a USB keyboard driver), and usb-oth (a
|
||||
USB non-keyboard, non-mouse driver). Additional drivers may be
|
||||
implemented in the future. Appropriate defaults will be used if no
|
||||
comma-separated list is provided.
|
||||
.sp
|
||||
.TP 4
|
||||
.I display-name
|
||||
If the display-name is a back-end server, then core input events are
|
||||
taken from the server specified. Otherwise, a console window will be
|
||||
opened on the specified display.
|
||||
.sp
|
||||
If the
|
||||
.I display-name
|
||||
is followed by ",xi" then XInput extension devices on the display will
|
||||
be used as
|
||||
.I Xdmx
|
||||
XInput extension devices. If the
|
||||
.I display-name
|
||||
is followed by ",noxi" then XInput extension devices on the display will
|
||||
.B not
|
||||
be used as
|
||||
.I Xdmx
|
||||
XInput extension devices. Currently, the default is ",xi".
|
||||
.sp
|
||||
If the
|
||||
.I display-name
|
||||
is followed by ",console" and the
|
||||
.I display-name
|
||||
refers to a display that is used as a backend display, then a console
|
||||
window will be opened on that display
|
||||
.B and
|
||||
that display will be treated as a backend display. Otherwise (or if
|
||||
",noconsole" is used), the display will be treated purely as a backend
|
||||
or a console display, as described above.
|
||||
.sp
|
||||
If the
|
||||
.I display-name
|
||||
is followed by ",windows", then outlines of the windows on the backend
|
||||
will be displayed inside the console window. Otherwise (or if
|
||||
",nowindows" is used), the console window will not display the outlines
|
||||
of backend windows. (This option only applies to console input.)
|
||||
.sp
|
||||
If the
|
||||
.I display-name
|
||||
is followed by ",xkb", then the next 1 to 3 comma-separated parameters
|
||||
will specify the keycodes, symbols, and geometry of the keyboard for
|
||||
this input device. For example, ",xkb,xfree86,pc104" will specify that
|
||||
the "xfree86" keycodes and the "pc104" symbols should be used to
|
||||
initialize the keyboard. For an SGI keyboard, ",xkb,sgi/indy(pc102)"
|
||||
might be useful. A list of keycodes, symbols, and geometries can be
|
||||
found in
|
||||
.IR @xkbdir@ .
|
||||
Use of keycodes, symbols and geometries for XKB configuration is
|
||||
deprecated in favor of the rules, layout, model, variant and options
|
||||
settings available via the -param command line switch.
|
||||
If this option is not specified, the input device will be queried,
|
||||
perhaps using the XKEYBOARD extension.
|
||||
.RE
|
||||
.sp
|
||||
.RS
|
||||
If this option isn't specified, the default input source is the first
|
||||
back-end server (the one used for screen 0). The console window shows
|
||||
the layout of the back-end display(s) and pointer movements and key
|
||||
presses within the console window will be used as core input devices.
|
||||
.sp
|
||||
Several special function keys are active, depending on the input
|
||||
source:
|
||||
.sp
|
||||
.RS
|
||||
.B Ctrl-Alt-q
|
||||
will terminate the
|
||||
.I Xdmx
|
||||
server in all modes.
|
||||
.sp
|
||||
.B Ctrl-Alt-g
|
||||
will toggle a
|
||||
server grab in console mode (a special cursor, currently a spider, is
|
||||
used to indicate an active server grab).
|
||||
.sp
|
||||
.B Ctrl-Alt-f
|
||||
will toggle fine-grain motion in console mode (a special cursor,
|
||||
currently a cross hair, is used to indicate this mode). If this mode is
|
||||
combined with a server grab, then the cursor will have 4 lines instead
|
||||
of only 2.
|
||||
.sp
|
||||
.BR Ctrl-Alt-F1 " through " Ctrl-Alt-F12
|
||||
will switch to another VC in local (raw) mode.
|
||||
.RE
|
||||
.RE
|
||||
.sp
|
||||
.TP 8
|
||||
.BI "-nomulticursor"
|
||||
This option turns off support for displaying multiple cursors on
|
||||
overlapped back-end displays. This option is available for testing and
|
||||
benchmarking purposes.
|
||||
.sp
|
||||
.TP 8
|
||||
.BI "-fontpath"
|
||||
This option sets the
|
||||
.I Xdmx
|
||||
server's default font path. This option can be specified multiple times
|
||||
to accommodate multiple font paths. See the
|
||||
.B "FONT PATHS"
|
||||
section below for very important information regarding setting the
|
||||
default font path.
|
||||
.sp
|
||||
.TP 8
|
||||
.BI "-configfile " filename
|
||||
Specify the configuration file that should be read. Note that if the
|
||||
.B \-display
|
||||
command-line option is used, then the configuration file will be
|
||||
ignored.
|
||||
.sp
|
||||
.TP 8
|
||||
.BI "-config " name
|
||||
Specify a configuration to use. The
|
||||
.I name
|
||||
will be the name following the
|
||||
.B virtual
|
||||
keyword in the configuration file.
|
||||
.sp
|
||||
.TP 8
|
||||
.BI "-stat " "interval screens"
|
||||
This option enables the display of performance statistics. The interval
|
||||
is in seconds. The screens is a count of the number of back-end screens
|
||||
for which data is printed each interval. Specifying 0 for screens will
|
||||
display data for all screens.
|
||||
.sp
|
||||
For each screen, the following information is printed: the screen
|
||||
number, an absolute count of the number of XSync() calls made
|
||||
(SyncCount), the rate of these calls during the previous interval
|
||||
(Sync/s), the average round-trip time (in microseconds) of the last 10
|
||||
XSync() calls (avSync), the maximum round-trip time (in microseconds) of
|
||||
the last 10 XSync calls (mxSync), the average number of XSync() requests
|
||||
that were pending but not yet processed for each of the last 10
|
||||
processed XSync() calls, the maximum number of XSync() requests that
|
||||
were pending but not yet processed for each of the last 10 processed
|
||||
XSync() calls, and a histogram showing the distribution of the times of
|
||||
all of the XSync() calls that were made during the previous interval.
|
||||
.sp
|
||||
(The length of the moving average and the number and value of histogram
|
||||
bins are configurable at compile time in the
|
||||
.B dmxstat.h
|
||||
header file.)
|
||||
.sp
|
||||
.TP 8
|
||||
.BI "-syncbatch " interval
|
||||
This option sets the
|
||||
.I interval
|
||||
in milliseconds for XSync() batching. An
|
||||
.I interval
|
||||
less than or equal to 0 will disable XSync() batching. The default
|
||||
.I interval
|
||||
is 100 ms.
|
||||
.sp
|
||||
.TP 8
|
||||
.BI "-nooffscreenopt"
|
||||
This option disables the offscreen optimization. Since the lazy window
|
||||
creation optimization requires the offscreen optimization to be enabled,
|
||||
this option will also disable the lazy window creation optimization.
|
||||
.sp
|
||||
.TP 8
|
||||
.BI "-nowindowopt"
|
||||
This option disables the lazy window creation optimization.
|
||||
.sp
|
||||
.TP 8
|
||||
.BI "-nosubdivprims"
|
||||
This option disables the primitive subdivision optimization.
|
||||
.sp
|
||||
.TP 8
|
||||
.BI "-noxkb"
|
||||
Disable use of the XKB extension for communication with the back end
|
||||
displays. (Combine with
|
||||
.B "-kb"
|
||||
to disable all use of XKB.)
|
||||
.sp
|
||||
.TP 8
|
||||
.BI "-depth " int
|
||||
This option sets the root window's default depth. When choosing a
|
||||
default visual from those available on the back-end X server, the first
|
||||
visual with that matches the depth specified is used.
|
||||
.sp
|
||||
This option can be combined with the
|
||||
.BI "-cc"
|
||||
option, which specifies the default color visual class, to force the use
|
||||
of a specific depth and color class for the root window.
|
||||
.sp
|
||||
.TP 8
|
||||
.BI "-norender"
|
||||
This option disables the RENDER extension.
|
||||
.sp
|
||||
.TP 8
|
||||
.BI "-noglxproxy"
|
||||
This option disables GLX proxy -- the build-in GLX extension
|
||||
implementation that is DMX aware.
|
||||
.sp
|
||||
.TP 8
|
||||
.BI "-noglxswapgroup"
|
||||
This option disables the swap group and swap barrier extensions in GLX
|
||||
proxy.
|
||||
.sp
|
||||
.TP 8
|
||||
.BI "-glxsyncswap"
|
||||
This option enables synchronization after a swap buffers call by waiting
|
||||
until all X protocol has been processed. When a client issues a
|
||||
glXSwapBuffers request, Xdmx relays that request to each back-end X
|
||||
server, and those requests are buffered along with all other protocol
|
||||
requests. However, in systems that have large network buffers, this
|
||||
buffering can lead to the set of back-end X servers handling the swap
|
||||
buffers request asynchronously. With this option, an XSync() request is
|
||||
issued to each back-end X server after sending the swap buffers request.
|
||||
The XSync() requests will flush all buffered protocol (including the
|
||||
swap buffers requests) and wait until the back-end X servers have
|
||||
processed those requests before continuing. This option does not wait
|
||||
until all GL commands have been processed so there might be previously
|
||||
issued commands that are still being processed in the GL pipe when the
|
||||
XSync() request returns. See the
|
||||
.BI "-glxfinishswap"
|
||||
option below if Xdmx should wait until the GL commands have been
|
||||
processed.
|
||||
.sp
|
||||
.TP 8
|
||||
.BI "-glxfinishswap"
|
||||
This option enables synchronization after a swap buffers call by waiting
|
||||
until all GL commands have been completed. It is similar to the
|
||||
.BI "-glxsyncswap"
|
||||
option above; however, instead of issuing an XSync(), it issues a
|
||||
glFinish() request to each back-end X server after sending the swap
|
||||
buffers requests. The glFinish() request will flush all buffered
|
||||
protocol requests, process both X and GL requests, and wait until all
|
||||
previously called GL commands are complete before returning.
|
||||
.sp
|
||||
.TP 8
|
||||
.BI "-ignorebadfontpaths"
|
||||
This option ignores font paths that are not available on all back-end
|
||||
servers by removing the bad font path(s) from the default font path
|
||||
list. If no valid font paths are left after removing the bad paths, an
|
||||
error to that effect is printed in the log.
|
||||
.sp
|
||||
.TP 8
|
||||
.BI "-addremovescreens"
|
||||
This option enables the dynamic addition and removal of screens, which
|
||||
is disabled by default. Note that GLXProxy and Render do not yet
|
||||
support dynamic addition and removal of screens, and must be disabled
|
||||
via the
|
||||
.BI "-noglxproxy"
|
||||
and
|
||||
.BI "-norender"
|
||||
command line options described above.
|
||||
.sp
|
||||
.TP 8
|
||||
.BI "-param"
|
||||
This option specifies parameters on the command line. Currently, only
|
||||
parameters dealing with XKEYBOARD configuration are supported. These
|
||||
parameters apply only to the core keyboard. Parameter values are
|
||||
installation-dependent. Please see
|
||||
.I @xkbdir@
|
||||
or a similar directory for complete information.
|
||||
.RS
|
||||
.TP 8
|
||||
.B XkbRules
|
||||
Defaults to "@XKB_DFLT_RULES@". Other values may include "sgi" and "sun".
|
||||
.sp
|
||||
.TP 8
|
||||
.B XkbModel
|
||||
Defaults to "@XKB_DFLT_MODEL@". When used with "base" rules, other values
|
||||
may include "pc102", "pc104", "microsoft", and many others. When
|
||||
used with "sun" rules, other values may include "type4" and "type5".
|
||||
.sp
|
||||
.TP 8
|
||||
.B XkbLayout
|
||||
Defaults to "@XKB_DFLT_LAYOUT@". Other country codes and "dvorak" are usually
|
||||
available.
|
||||
.sp
|
||||
.TP 8
|
||||
.B XkbVariant
|
||||
Defaults to "@XKB_DFLT_VARIANT@".
|
||||
.sp
|
||||
.TP 8
|
||||
.B XkbOptions
|
||||
Defaults to "@XKB_DFLT_OPTIONS@".
|
||||
.RE
|
||||
.SH "CONFIGURATION FILE GRAMMAR"
|
||||
The following words and tokens are reserved:
|
||||
.RS
|
||||
.B virtual
|
||||
.B display
|
||||
.B wall
|
||||
.B option
|
||||
.B param
|
||||
.B {
|
||||
.B }
|
||||
.B ;
|
||||
.B #
|
||||
.RE
|
||||
.PP
|
||||
Comments start with a
|
||||
.B #
|
||||
mark and extend to the end of the line. They may appear anywhere. If a
|
||||
configuration file is read into
|
||||
.BR xdmxconfig ,
|
||||
the comments in that file will be preserved, but will not be editable.
|
||||
.PP
|
||||
The grammar is as follows:
|
||||
.RS
|
||||
virtual-list ::= [ virtual-list ] | virtual
|
||||
|
||||
virtual ::=
|
||||
.B virtual
|
||||
[ name ] [ dim ]
|
||||
.B {
|
||||
dw-list
|
||||
.B }
|
||||
|
||||
dw-list ::= [ dw-list ] | dw
|
||||
|
||||
dw ::= display | wall | option
|
||||
|
||||
display ::=
|
||||
.B display
|
||||
name [ geometry ] [ / geometry ] [ origin ]
|
||||
.B ;
|
||||
|
||||
wall ::=
|
||||
.B wall
|
||||
[ dim ] [ dim ] name-list
|
||||
.B ;
|
||||
|
||||
option ::=
|
||||
.B option
|
||||
name-list
|
||||
.B ;
|
||||
|
||||
param ::=
|
||||
.B param
|
||||
name-list
|
||||
.B ;
|
||||
|
||||
param ::=
|
||||
.B param {
|
||||
param-list
|
||||
.B }
|
||||
|
||||
param-list ::= [ param-list ] | name-list
|
||||
.B ;
|
||||
|
||||
name-list ::= [ name-list ] | name
|
||||
|
||||
name ::= string | double-quoted-string
|
||||
|
||||
dim ::= integer
|
||||
.B x
|
||||
integer
|
||||
|
||||
geometry ::= [ integer
|
||||
.B x
|
||||
integer ] [ signed-integer signed-integer ]
|
||||
|
||||
origin ::=
|
||||
.B @
|
||||
integer
|
||||
.B x
|
||||
integer
|
||||
.RE
|
||||
.PP
|
||||
The name following
|
||||
.B virtual
|
||||
is used as an identifier for the configuration, and may be passed to
|
||||
.B Xdmx
|
||||
using the
|
||||
.B \-config
|
||||
command line option. The name of a display should be standard X display
|
||||
name, although no checking is performed (e.g., "machine:0").
|
||||
.PP
|
||||
For names, double quotes are optional unless the name is reserved or
|
||||
contains spaces.
|
||||
.PP
|
||||
The first dimension following
|
||||
.B wall
|
||||
is the dimension for tiling (e.g., 2x4 or 4x4). The second dimension
|
||||
following
|
||||
.B wall
|
||||
is the dimension of each display in the wall (e.g., 1280x1024).
|
||||
.PP
|
||||
The first geometry following
|
||||
.B display
|
||||
is the geometry of the screen window on the backend server. The second
|
||||
geometry, which is always preceeded by a slash, is the geometry of the
|
||||
root window. By default, the root window has the same geometry as the
|
||||
screen window.
|
||||
.PP
|
||||
The
|
||||
.B option
|
||||
line can be used to specify any command-line options (e.g.,
|
||||
.BR \-input ).
|
||||
(It cannot be used to specify the name of the front-end display.) The
|
||||
option line is processed once at server startup, just line command line
|
||||
options. This behavior may be unexpected.
|
||||
.SH "CONFIGURATION FILE EXAMPLES"
|
||||
Two displays being used for a desktop may be specified in any of the
|
||||
following formats:
|
||||
.RS
|
||||
.nf
|
||||
virtual example0 {
|
||||
display d0:0 1280x1024 @0x0;
|
||||
display d1:0 1280x1024 @1280x0;
|
||||
}
|
||||
.sp
|
||||
virtual example1 {
|
||||
display d0:0 1280x1024;
|
||||
display d1:0 @1280x0;
|
||||
}
|
||||
.sp
|
||||
virtual example2 {
|
||||
display "d0:0";
|
||||
display "d1:0" @1280x0;
|
||||
}
|
||||
.sp
|
||||
virtual example3 { wall 2x1 d0:0 d1:0; }
|
||||
.fi
|
||||
.RE
|
||||
A 4x4 wall of 16 total displays could be specified as follows (if no
|
||||
tiling dimension is specified, an approximate square is used):
|
||||
.RS
|
||||
.nf
|
||||
virtual example4 {
|
||||
wall d0:0 d1:0 d2:0 d3:0
|
||||
d4:0 d5:0 d6:0 d7:0
|
||||
d8:0 d9:0 da:0 db:0
|
||||
dc:0 dd:0 de:0 df:0;
|
||||
}
|
||||
.fi
|
||||
.RE
|
||||
.SH "FONT PATHS"
|
||||
The font path used by the
|
||||
.I Xdmx
|
||||
front-end server will be propagated to each back-end server,which
|
||||
requires that each back-end server have access to the exact same font
|
||||
paths as the front-end server. This can be most easily handled by
|
||||
either using a font server (e.g., xfs) or by remotely mounting the font
|
||||
paths on each back-end server, and then setting the
|
||||
.I Xdmx
|
||||
server's default font path with the
|
||||
-I "-fontpath"
|
||||
command line option described above.
|
||||
.PP
|
||||
For example, if you specify a font path with the following command line:
|
||||
.RS
|
||||
Xdmx :1 -display d0:0 -fontpath /usr/fonts/75dpi/ -fontpath /usr/fonts/Type1/ +xinerama
|
||||
.RE
|
||||
Then, /usr/fonts/75dpi/ and /usr/fonts/Type1/ must be valid font paths
|
||||
on the
|
||||
.I Xdmx
|
||||
server and all back-end server, which is d0 in this example.
|
||||
.PP
|
||||
Font servers can also be specified with the
|
||||
.I "-fontpath"
|
||||
option. For example, let's assume that a properly configured font
|
||||
server is running on host d0. Then, the following command line
|
||||
.RS
|
||||
Xdmx :1 -display d0:0 -display d1:0 -fontpath tcp/d0:7100 +xinerama
|
||||
.RE
|
||||
will initialize the front-end
|
||||
.I Xdmx
|
||||
server and each of the back-end servers to use the font server on d0.
|
||||
.PP
|
||||
Some fonts might not be supported by either the front-end or the
|
||||
back-end servers. For example, let's assume the front-end
|
||||
.I Xdmx
|
||||
server includes support Type1 fonts, but one of the back-end servers
|
||||
does not. Let's also assume that the default font path for
|
||||
.I Xdmx
|
||||
includes Type1 fonts in its font path. Then, when
|
||||
.I Xdmx
|
||||
initializes the default font path to load the default font, the font
|
||||
path that includes Type1 fonts (along with the other default font paths
|
||||
that are used by the
|
||||
.I Xdmx
|
||||
server) is sent to the back-end server that cannot handle Type1 fonts.
|
||||
That back-end server then rejects the font path and sends an error back
|
||||
to the
|
||||
.I Xdmx
|
||||
server.
|
||||
.I Xdmx
|
||||
then prints an error message and exits because it failed to set the
|
||||
default font path and was unable load the default font.
|
||||
.PP
|
||||
To fix this error, the offending font path must be removed from the
|
||||
default font path by using a different
|
||||
.I "-fontpath"
|
||||
command line option.
|
||||
.PP
|
||||
The
|
||||
.I "-fontpath"
|
||||
option can also be added to the configuration file as described above.
|
||||
.SH "COMMAND-LINE EXAMPLES"
|
||||
The back-end machines are d0 and d1, core input is from the pointer and
|
||||
keyboard attached to d0, clients will refer to :1 when opening windows:
|
||||
.RS
|
||||
Xdmx :1 -display d0:0 -display d1:0 +xinerama
|
||||
.RE
|
||||
.PP
|
||||
As above, except with core input from d1:
|
||||
.RS
|
||||
Xdmx :1 -display d0:0 -display d1:0 -input d1:0 +xinerama
|
||||
.RE
|
||||
.PP
|
||||
As above, except with core input from a console window on the local
|
||||
display:
|
||||
.RS
|
||||
Xdmx :1 -display d0:0 -display d1:0 -input :0 +xinerama
|
||||
.RE
|
||||
.PP
|
||||
As above, except with core input from the local keyboard and mouse:
|
||||
.RS
|
||||
Xdmx :1 -display d0:0 -display d1:0 -input local,usb-kbd,usb-mou +xinerama
|
||||
.RE
|
||||
Note that local input can be used under Linux while another X session is
|
||||
running on :0 (assuming the user can access the Linux console tty and
|
||||
mouse devices): a new (blank) VC will be used for keyboard input on the
|
||||
local machine and the Ctrl-Alt-F* sequence will be available to change
|
||||
to another VC (possibly back to another X session running on the local
|
||||
machine). Using Ctrl-Alt-Backspace on the blank VC will terminate the
|
||||
Xdmx session and return to the original VC.
|
||||
.PP
|
||||
This example uses the configuration file shown in the previous section:
|
||||
.RS
|
||||
Xdmx :1 -input :0 +xinerama -configfile filename -config example2
|
||||
.RE
|
||||
With this configuration file line:
|
||||
.RS
|
||||
option -input :0 +xinerama;
|
||||
.RE
|
||||
the command line can be shortened to:
|
||||
.RS
|
||||
Xdmx :1 -configfile filename -config example2
|
||||
.RE
|
||||
.SH "USING THE USB DEVICE DRIVERS"
|
||||
.P
|
||||
The USB device drivers use the devices called
|
||||
.IR /dev/input/event0 ", " /dev/input/event1 ", etc."
|
||||
under Linux. These devices are driven using the
|
||||
.I evdev
|
||||
Linux kernel module, which is part of the hid suite. Please note that
|
||||
if you load the
|
||||
.I mousedev
|
||||
or
|
||||
.I kbddev
|
||||
Linux kernel modules, then USB devices will appear as core Linux input
|
||||
devices and you will not be able to select between using the device only
|
||||
as an
|
||||
.I Xdmx
|
||||
core device or an
|
||||
.I Xdmx
|
||||
XInput extension device. Further, you may be unable to unload the
|
||||
.I mousedev
|
||||
Linux kernel module if
|
||||
.I XFree86
|
||||
is configured to use
|
||||
.I /dev/input/mice
|
||||
as an input device (this is quite helpful for laptop users and is set up
|
||||
by default under some Linux distributions, but should be changed if USB
|
||||
devices are to be used with
|
||||
.IR Xdmx ).
|
||||
.PP
|
||||
The USB device drivers search through the Linux devices for the first
|
||||
mouse, keyboard, or non-mouse-non-keyboard Linux device and use that
|
||||
device.
|
||||
.SH "KEYBOARD INITIALIZATION"
|
||||
.PP
|
||||
If
|
||||
.I Xdmx
|
||||
was invoked with
|
||||
.I \-xkb
|
||||
or was
|
||||
.B not
|
||||
compiled to use the XKEYBOARD extension, then a keyboard on a backend or
|
||||
console will be initialized using the map that the host X server
|
||||
provides.
|
||||
.PP
|
||||
If the XKEYBOARD extension is used for both
|
||||
.I Xdmx
|
||||
and the host X server for the keyboard (i.e., the backend or console X
|
||||
server), then the type of the keyboard will
|
||||
be obtained from the host X server and the keyboard under
|
||||
.I Xdmx
|
||||
will be initialized with that information. Otherwise, the default type
|
||||
of keyboard will be initialized. In both cases, the map from the host X
|
||||
server will
|
||||
.B not
|
||||
be used. This means that different initial behavior may be noted with
|
||||
and without XKEYBOARD. Consistent and expected results will be obtained
|
||||
by running XKEYBOARD on all servers and by avoiding the use of
|
||||
.I xmodmap
|
||||
on the backend or console X servers prior to starting
|
||||
.IR Xdmx .
|
||||
.PP
|
||||
If
|
||||
.I \-xkbmap
|
||||
is specified on the
|
||||
.I Xdmx
|
||||
command line, then that map will currently be used for all keyboards.
|
||||
.SH "MULTIPLE CORE KEYBOARDS"
|
||||
X was not designed to support multiple core keyboards. However,
|
||||
.I Xdmx
|
||||
provides some support for multiple core keyboards. Best results will be
|
||||
obtained if all of the keyboards are of the same type and are using the
|
||||
same keyboard map. Because the X server passes raw key code information
|
||||
to the X client, key symbols for keyboards with different key maps would
|
||||
be different if the key code for each keyboard was sent without
|
||||
translation to the client. Therefore,
|
||||
.I Xdmx
|
||||
will attempt to translate the key code from a core keyboard to the key
|
||||
code for the key with the same key symbol of the
|
||||
.B first
|
||||
core keyboard that was loaded. If the key symbol appears in both maps,
|
||||
the results will be expected. Otherwise, the second core keyboard will
|
||||
return a NoSymbol key symbol for some keys that would have been
|
||||
translated if it was the first core keyboard.
|
||||
.ig
|
||||
.SH ENVIRONMENT
|
||||
..
|
||||
.ig
|
||||
.SH FILES
|
||||
..
|
||||
.SH "SEE ALSO"
|
||||
.BR DMX "(@libmansuffix@), " X "(@miscmansuffix@), "
|
||||
.BR Xserver "(@appmansuffix@), " xdmxconfig "(@appmansuffix@), "
|
||||
.BR vdltodmx "(@appmansuffix@), " xfs "(@appmansuffix@), "
|
||||
.BR xkbcomp "(@appmansuffix@), " xkeyboard-config "(@miscmansuffix@)"
|
||||
.SH AUTHORS
|
||||
Kevin E. Martin
|
||||
.I <kem@redhat.com>,
|
||||
David H. Dawes
|
||||
.I <dawes@xfree86.org>,
|
||||
and
|
||||
Rickard E. (Rik) Faith
|
||||
.IR <faith@redhat.com> .
|
||||
.PP
|
||||
Portions of
|
||||
.I Xdmx
|
||||
are based on code from The XFree86 Project
|
||||
.RI ( http://www.xfree86.org )
|
||||
and X.Org
|
||||
.RI ( https://www.x.org ).
|
||||
Loading…
Add table
Add a link
Reference in a new issue