1680 lines
50 KiB
Groff
1680 lines
50 KiB
Groff
'\" t -*- coding: us-ascii -*-
|
|
.if \n(.g .ds T< \\FC
|
|
.if \n(.g .ds T> \\F[\n[.fam]]
|
|
.de URL
|
|
\\$2 \(la\\$1\(ra\\$3
|
|
..
|
|
.if \n(.g .mso www.tmac
|
|
.TH "xboxdrv " 1 2010-05-05 0.6.3 "User Commands"
|
|
.SH NAME
|
|
xboxdrv
|
|
\- A Xbox/Xbox360 gamepad driver that works in userspace
|
|
.SH SYNOPSIS
|
|
'nh
|
|
.fi
|
|
.ad l
|
|
\fBxboxdrv\fR \kx
|
|
.if (\nx>(\n(.l/2)) .nr x (\n(.l/5)
|
|
'in \n(.iu+\nxu
|
|
[OPTION]\&... [--] [COMMAND] [ARGUMENTS]
|
|
'in \n(.iu-\nxu
|
|
.ad b
|
|
'hy
|
|
.SH DESCRIPTION
|
|
\fBxboxdrv\fR is a driver for Xbox and Xbox360
|
|
gamepads. It works by reading the raw data from the controller
|
|
with the userspace library libusb and then passes the
|
|
interpreted data to the kernel via uinput. This
|
|
allows \fBxboxdrv\fR to provide regular joystick
|
|
and event devices, which makes it compatible with all Linux
|
|
software.
|
|
.PP
|
|
Aside from the pure driver, \fBxboxdrv\fR also
|
|
includes a rich set of configuration options that allow you to
|
|
tweak the abilities of the virtual input devices that xboxdrv
|
|
will create. This includes basic button and axis remapping, as
|
|
well as more complicated things like mouse and keyboard emulation,
|
|
auto-fire and throttle control emulation.
|
|
.PP
|
|
It is also possible for \fBxboxdrv\fR to read input
|
|
data directly from an event device, this allows to use the
|
|
configurability of \fBxboxdrv\fR on regular PC
|
|
joysticks, keyboards and mice and thus
|
|
lets \fBxboxdrv\fR serve a similar purpose
|
|
as \fBjoy2key\fR. See the
|
|
option \*(T<\fB\-\-evdev\fR\*(T> below for more information.
|
|
.PP
|
|
When a \*(T<\fBCOMMAND\fR\*(T> is provided xboxdrv will launch
|
|
that application and be running till that application exits.
|
|
This is a convenience function to make it easier to use xboxdrv
|
|
in wrapper scripts.
|
|
.SH OPTIONS
|
|
.SS "GENERAL OPTIONS"
|
|
.TP
|
|
\*(T<\fB\-h\fR\*(T>, \*(T<\fB\-\-help\fR\*(T>
|
|
Display help text and exit.
|
|
.TP
|
|
-V, --version
|
|
Print the version number and exit.
|
|
.TP
|
|
\*(T<\fB\-v\fR\*(T>, \*(T<\fB\-\-verbose\fR\*(T>
|
|
Print verbose messages.
|
|
.TP
|
|
\*(T<\fB\-\-help\-led\fR\*(T>
|
|
List possible values for the led.
|
|
.TP
|
|
\*(T<\fB\-\-help\-devices\fR\*(T>
|
|
List supported devices.
|
|
.TP
|
|
\*(T<\fB\-s\fR\*(T>, \*(T<\fB\-\-silent\fR\*(T>
|
|
Do not display events on console.
|
|
.TP
|
|
\*(T<\fB\-\-quiet\fR\*(T>
|
|
Do not display startup text.
|
|
.TP
|
|
\*(T<\fB\-L\fR\*(T>, \*(T<\fB\-\-list\-controller\fR\*(T>
|
|
List available controllers on the system.
|
|
.TP
|
|
\*(T<\fB\-\-list\-supported\-devices\fR\*(T>
|
|
List supported devices (used by xboxdrv-daemon.py).
|
|
.TP
|
|
\*(T<\fB\-\-list\-supported\-devices\-xpad\fR\*(T>
|
|
List supported devices in \*(T<\fIxpad.c\fR\*(T> style.
|
|
.TP
|
|
\*(T<\fB\-D\fR\*(T>, \*(T<\fB\-\-daemon\fR\*(T>
|
|
Run xboxdrv as daemon. This option hasn't been tested
|
|
much and it is not recommented to be used.
|
|
.TP
|
|
\*(T<\fB\-c\fR\*(T>, \*(T<\fB\-\-config\fR\*(T> \fIFILE\fR
|
|
Reads configuration information from \fIFILE\fR.
|
|
Configurations from file are handling as if they would
|
|
be command line options at the position
|
|
of \*(T<\fB\-\-config\fR\*(T> \fIFILE\fR.
|
|
|
|
The syntax
|
|
of \fIFILE\fR is
|
|
the familiar INI syntax used for many configuration
|
|
files. Regular key/value pairs must go into the
|
|
[xboxdrv] section. '#' and ';' can be used for comments.
|
|
Key names have for most part the same name as command
|
|
line options. Command line options that take a list of
|
|
input mappings (--ui-buttonmap, --ui-axismap,
|
|
--evdev-absmap, ...) can be split of into their own
|
|
section for better readability.
|
|
|
|
The \*(T<\fIexamples/\fR\*(T> directory contains
|
|
some example configuration files.
|
|
|
|
.nf
|
|
\*(T<[xboxdrv]
|
|
silent=true
|
|
deadzone=6000
|
|
dpad\-as\-button=true
|
|
trigger\-as\-button=true
|
|
|
|
[ui\-axismap]
|
|
x2=REL_X:10
|
|
y2=REL_Y:\-10
|
|
x1=KEY_A:KEY_D
|
|
y1=KEY_W:KEY_S
|
|
|
|
[ui\-buttonmap]
|
|
a=KEY_LEFTSHIFT
|
|
b=BTN_C
|
|
x=BTN_EXTRA
|
|
y=KEY_C
|
|
|
|
[ui\-buttonmap]
|
|
lb=BTN_RIGHT
|
|
rb=KEY_SPACE
|
|
|
|
[ui\-buttonmap]
|
|
lt=KEY_Z
|
|
rt=BTN_LEFT
|
|
|
|
[ui\-buttonmap]
|
|
dl=KEY_4
|
|
dr=KEY_2
|
|
du=REL_WHEEL:\-1:150
|
|
dd=REL_WHEEL:1:150
|
|
|
|
[ui\-buttonmap]
|
|
back=KEY_TAB
|
|
start=KEY_ESC
|
|
|
|
# EOF #\*(T>
|
|
.fi
|
|
.TP
|
|
\*(T<\fB\-\-alt\-config\fR\*(T> \fIFILE\fR
|
|
A shortcut for
|
|
writing \*(T<\fB\-\-ui\-new\fR\*(T> \*(T<\fB\-\-config\fR\*(T> \fIFILE\fR.
|
|
|
|
To load multiple configuration options use:
|
|
|
|
.nf
|
|
\*(T<xboxdrv \-\-config first.ini \-\-alt\-config second.ini \-\-alt\-config third.ini\*(T>
|
|
.fi
|
|
.TP
|
|
\*(T<\fB\-o\fR\*(T>, \*(T<\fB\-\-option\fR\*(T> \fINAME=VALUE\fR
|
|
Set an option as if it would come from a config file from the command line.
|
|
.TP
|
|
\*(T<\fB\-\-write\-config\fR\*(T> \fIFILE\fR
|
|
Write an example configuration file to \fIFILE\fR.
|
|
.SS "DEVICE OPTIONS"
|
|
.TP
|
|
\*(T<\fB\-d\fR\*(T>, \*(T<\fB\-\-detach\-kernel\-driver\fR\*(T>
|
|
Detaches the kernel driver that is currently associated
|
|
with the given device. This is useful when you have the
|
|
xpad module loaded and want to use xboxdrv without
|
|
unloading it.
|
|
.TP
|
|
\*(T<\fB\-i\fR\*(T>, \*(T<\fB\-\-id\fR\*(T> \fIN\fR
|
|
Use controller with id N (default: 0),
|
|
use \*(T<\fB\-\-list\-controller\fR\*(T> to obtain a list
|
|
of available controller.
|
|
.TP
|
|
\*(T<\fB\-w\fR\*(T>, \*(T<\fB\-\-wid\fR\*(T> \fIN\fR
|
|
Use wireless controller with wid N (default: 0).
|
|
.TP
|
|
\*(T<\fB\-\-device\-by\-path\fR\*(T> \fIBUS:DEV\fR
|
|
Use device BUS:DEV, do not do any scanning
|
|
.TP
|
|
\*(T<\fB\-\-device\-by\-id\fR\*(T> \fIVENDOR:PRODUCT\fR
|
|
Use device that matches VENDOR:PRODUCT (as returned by \fBlsusb\fR)
|
|
.TP
|
|
\*(T<\fB\-\-type\fR\*(T> \fITYPE\fR
|
|
Ignore autodetection and enforce the controller type. Possible values for \fITYPE\fR:
|
|
.RS
|
|
.TP 0.2i
|
|
\(bu
|
|
xbox
|
|
.TP 0.2i
|
|
\(bu
|
|
xbox-mat
|
|
.TP 0.2i
|
|
\(bu
|
|
xbox360
|
|
.TP 0.2i
|
|
\(bu
|
|
xbox360-wireless
|
|
.TP 0.2i
|
|
\(bu
|
|
xbox360-guitar
|
|
.RE
|
|
.SS "EVDEV OPTION"
|
|
.TP
|
|
\*(T<\fB\-\-evdev\fR\*(T> \fIDEVICE\fR
|
|
Allows you to read input data from a regular event
|
|
device. This allows you to
|
|
use \fBxboxdrv\fR on regular PC
|
|
joysticks. The data that is read from the event device
|
|
is converted internally into a XboxMsg object and then
|
|
passed through the same configuration pipeline as it
|
|
would be for a regular Xbox360 controller. This allows
|
|
you to make use of all the regular configurability, but
|
|
limits you to the number of axis and buttons that an
|
|
Xbox360 controller provides.
|
|
|
|
As a regular PC joystick will most likely already create
|
|
a \*(T<\fI/dev/input/jsX\fR\*(T> device by itself,
|
|
you might need to get rid of that so that a game will
|
|
properly detect the joystick device created
|
|
by \fBxboxdrv\fR. The easiest way to
|
|
accomplish that is to simply delete the old joystick and
|
|
rename the device that \fBxboxdrv\fR
|
|
created to \*(T<\fI/dev/input/js0\fR\*(T>. When you
|
|
use udev, this operation should be harmless and
|
|
automatically reverse itself when you remove the
|
|
controller and plug it back in or when you reboot the
|
|
computer.
|
|
.TP
|
|
\*(T<\fB\-\-evdev\-debug\fR\*(T>
|
|
The evdev event handler will print all received events
|
|
to stdout, this makes it easy to see which events a
|
|
given controller sends.
|
|
.TP
|
|
\*(T<\fB\-\-evdev\-no\-grab\fR\*(T>
|
|
By default the evdev driver will grab the device, thus
|
|
making it impossible for other applications to receive
|
|
events from that device. This is done to avoid confusing
|
|
applications, as otherwise an app would receive every
|
|
event twice, once from the original device and once from
|
|
the virtual xboxdrv one. In some cases this behaviour is
|
|
undesired, such when mapping only an other wise
|
|
unhandled subset of keys of an device, i.e. mapping the
|
|
multimedia keys on a keyboard, so this option turns the
|
|
grab off.
|
|
.TP
|
|
\*(T<\fB\-\-evdev\-absmap\fR\*(T> \fIABSMAP,...\fR
|
|
.nf
|
|
\*(T<ABSMAP = EVDEV_ABS [ "+", "\-" ] "=" XBOXAXIS ;\*(T>
|
|
.fi
|
|
|
|
Sets how evdev events are mapped to Xbox axis
|
|
events. An example configuration would look like this:
|
|
|
|
.nf
|
|
\*(T<\-\-evdev\-absmap ABS_X=x1,ABS_Y=y1,ABS_RZ=x2,ABS_THROTTLE=y2,ABS_HAT0X=dpad_x,ABS_HAT0Y=dpad_y\*(T>
|
|
.fi
|
|
|
|
\fBxboxdrv\fR will output on startup a full
|
|
list of event names that the given event device
|
|
supports and that can be used in place of \fIEVDEV_ABS\fR.
|
|
|
|
It is also possible to map half-axis with a command like:
|
|
|
|
.nf
|
|
\*(T<\-\-evdev\-absmap ABS_Y+=LT,ABS_Y\-=RT\*(T>
|
|
.fi
|
|
|
|
This will map the upward movement of the Y axis to the
|
|
left trigger and the downward movement to the right
|
|
trigger.
|
|
.TP
|
|
\*(T<\fB\-\-evdev\-keymap\fR\*(T> \fIKEYMAP\fR
|
|
Sets how evdev events are mapped to Xbox controller
|
|
events. An example configuration would look like this:
|
|
|
|
.nf
|
|
\*(T<\-\-evdev\-keymap BTN_TRIGGER=a,BTN_THUMB=b,BTN_THUMB2=x\*(T>
|
|
.fi
|
|
|
|
\fBxboxdrv\fR will output on start a full
|
|
list of event names that the given event device
|
|
supports.
|
|
.SS "STATUS OPTIONS"
|
|
.TP
|
|
\*(T<\fB\-l\fR\*(T>, \*(T<\fB\-\-led\fR\*(T> \fINUM\fR
|
|
Set LED status. Possible values for \fINUM\fR are:
|
|
|
|
\fBLED Status Codes\fR
|
|
.TS
|
|
r l.
|
|
T{
|
|
Num
|
|
T} T{
|
|
Behaviour
|
|
T}
|
|
.T&
|
|
r l.
|
|
T{
|
|
0
|
|
T} T{
|
|
off
|
|
T}
|
|
T{
|
|
1
|
|
T} T{
|
|
all blinking
|
|
T}
|
|
T{
|
|
2
|
|
T} T{
|
|
1/top-left blink, then on
|
|
T}
|
|
T{
|
|
3
|
|
T} T{
|
|
2/top-right blink, then on
|
|
T}
|
|
T{
|
|
4
|
|
T} T{
|
|
3/bottom-left blink, then on
|
|
T}
|
|
T{
|
|
5
|
|
T} T{
|
|
4/bottom-right blink, then on
|
|
T}
|
|
T{
|
|
6
|
|
T} T{
|
|
1/top-left on
|
|
T}
|
|
T{
|
|
7
|
|
T} T{
|
|
2/top-right on
|
|
T}
|
|
T{
|
|
8
|
|
T} T{
|
|
3/bottom-left on
|
|
T}
|
|
T{
|
|
9
|
|
T} T{
|
|
4/bottom-right on
|
|
T}
|
|
T{
|
|
10
|
|
T} T{
|
|
rotate
|
|
T}
|
|
T{
|
|
11
|
|
T} T{
|
|
blink
|
|
T}
|
|
T{
|
|
12
|
|
T} T{
|
|
blink slower
|
|
T}
|
|
T{
|
|
13
|
|
T} T{
|
|
rotate with two lights
|
|
T}
|
|
T{
|
|
14
|
|
T} T{
|
|
blink
|
|
T}
|
|
T{
|
|
15
|
|
T} T{
|
|
blink once
|
|
T}
|
|
.TE
|
|
.TP
|
|
\*(T<\fB\-q\fR\*(T>, \*(T<\fB\-\-quit\fR\*(T>
|
|
Exit xboxdrv after setting LED or rumble values.
|
|
.SS "CHATPAD OPTIONS (EXPERIMENTAL)"
|
|
Chatpad support is still experimental. Basic keyboard usage
|
|
will work, there is however currently no support for
|
|
customization or the green and orange key modifiers.
|
|
.PP
|
|
Starting xboxdrv multiple times in a row with
|
|
the \*(T<\fB\-\-chatpad\fR\*(T> option can crash the
|
|
controller. Unplugging it and plugging it back in should reset
|
|
it.
|
|
.TP
|
|
\*(T<\fB\-\-chatpad\fR\*(T>
|
|
Enables the support for the Xbox360 Chatpad. WARNING:
|
|
This is preliminary code, it will crash your gamepad
|
|
when xboxdrv is started multiple times and won't provide
|
|
proper keymapping for any of the umlauts and special
|
|
characters.
|
|
.TP
|
|
\*(T<\fB\-\-chatpad\-no\-init\fR\*(T>
|
|
This will start chatpad support with out sending the
|
|
init sequence, thus potentially avoiding crashing the
|
|
controller if xboxdrv is started multiple times.
|
|
.TP
|
|
\*(T<\fB\-\-chatpad\-debug\fR\*(T>
|
|
Output raw chatpad data to the stdout for debugging purpose.
|
|
.SS "HEADSET OPTIONS (EXPERIMENTAL, XBOX360 USB ONLY)"
|
|
Xboxdrv does not support the headset, the options below are
|
|
for developers only and will dump raw headset data, not .wav
|
|
files.
|
|
.TP
|
|
\*(T<\fB\-\-headset\fR\*(T>
|
|
Enable headset support and dump incomming data to stdout.
|
|
.TP
|
|
\*(T<\fB\-\-headset\-dump\fR\*(T> \fIFILE\fR
|
|
Enable headset support and dump incomming data to FILE.
|
|
.TP
|
|
\*(T<\fB\-\-headset\-play\fR\*(T> \fIFILE\fR
|
|
Enable headset support and send FILE to the headset for playback.
|
|
.SS "FORCE FEEDBACK"
|
|
.TP
|
|
\*(T<\fB\-\-force\-feedback\fR\*(T>
|
|
Enables the standard kernel force feedback interface. It
|
|
is disabled by default as it causes trouble with some
|
|
applications running in Wine.
|
|
|
|
Since the Xbox360 controller supports just rumble not full force
|
|
feedback, xboxdrv tries to emulate other effects. This emulation
|
|
hasn't been tested much and might not always work as expected. Bug
|
|
reports and test cases are welcome.
|
|
|
|
Note that you must close the application that is using force feedback
|
|
always before you close the xboxdrv driver, else you might end up with
|
|
a hanging non-interruptable xboxdrv process that will require a reboot
|
|
to get rid of.
|
|
.TP
|
|
\*(T<\fB\-\-rumble\-gain\fR\*(T> \fIAMOUNT\fR
|
|
You can change the rumble strength via:
|
|
|
|
.nf
|
|
\*(T<$ xboxdrv \-\-rumble\-gain 50%\*(T>
|
|
.fi
|
|
|
|
Values larger then 100% are possible as well and will
|
|
amplify small rumble commands, rumble commands already
|
|
at the maximum will stay unchanged.
|
|
.TP
|
|
\*(T<\fB\-R\fR\*(T>, \*(T<\fB\-\-test\-rumble\fR\*(T>
|
|
Pressing LT will move the left rumble motor and pressing
|
|
RT will move the right one. Rumble motor strength
|
|
depends on how hard you press. This is useful for
|
|
testing the rumble motors.
|
|
.TP
|
|
\*(T<\fB\-r\fR\*(T>, \*(T<\fB\-\-rumble\fR\*(T> \fIL,R\fR
|
|
Set the speed for both rumble motors. Values from 0 to 255 are accepted, the default is 0,0.
|
|
.SS "CONFIGURATION OPTIONS"
|
|
.TP
|
|
\*(T<\fB\-\-deadzone \fR\*(T>\fINUM\fR
|
|
The deadzone is the area at which the sticks do not report any
|
|
events. The default is zero, which gives the best sensitifity but
|
|
might also cause trouble in some games in that the character or camera
|
|
might move without moving the stick. To fix this one has to set the
|
|
value to something higher:
|
|
|
|
.nf
|
|
\*(T<$ xboxdrv \-\-deadzone 4000\*(T>
|
|
.fi
|
|
|
|
A value of 4000 works quite well for most games.
|
|
|
|
You can also give the deadzone in percentage:
|
|
|
|
.nf
|
|
\*(T<$ xboxdrv \-\-deadzone 15%\*(T>
|
|
.fi
|
|
.TP
|
|
\*(T<\fB\-\-deadzone\-trigger \fR\*(T>\fINUM\fR
|
|
The left and right trigger have a separate deadzone value which can be
|
|
specified with:
|
|
|
|
.nf
|
|
\*(T<$ xboxdrv \-\-deadzone\-trigger 15% \*(T>
|
|
.fi
|
|
.TP
|
|
\*(T<\fB\-b, \-\-buttonmap BUTTON=BUTTON,...\fR\*(T>
|
|
Button remapping is available via the \*(T<\fB\-\-buttonmap\fR\*(T> option. If you want
|
|
to swap button A and B start with:
|
|
|
|
.nf
|
|
\*(T<$ xboxdrv \-\-buttonmap A=B,B=A\*(T>
|
|
.fi
|
|
|
|
If you want all face buttons send out A button events:
|
|
|
|
.nf
|
|
\*(T<$ xboxdrv \-\-buttonmap B=A,X=A,Y=A\*(T>
|
|
.fi
|
|
|
|
Possible button names are (aliases are in parenthesis):
|
|
|
|
\fBButton Names\fR
|
|
.TS
|
|
allbox ;
|
|
l l.
|
|
T{
|
|
Name
|
|
T} T{
|
|
Description
|
|
T}
|
|
.T&
|
|
l l.
|
|
T{
|
|
start, back
|
|
T} T{
|
|
start, back buttons
|
|
T}
|
|
T{
|
|
guide
|
|
T} T{
|
|
big X-button in the middle (Xbox360 only)
|
|
T}
|
|
T{
|
|
a(1), b(2), x(3), y(4)
|
|
T} T{
|
|
face buttons
|
|
T}
|
|
T{
|
|
black, white
|
|
T} T{
|
|
black, white buttons (Xbox1 only, mapped to lb, rb on Xbox360)
|
|
T}
|
|
T{
|
|
lb(5), rb(6)
|
|
T} T{
|
|
shoulder buttons (Xbox360 only, mapped to black, white on Xbox1)
|
|
T}
|
|
T{
|
|
lt(7), rt(8)
|
|
T} T{
|
|
analog trigger (needs --trigger-as-button option)
|
|
T}
|
|
T{
|
|
tl, tr
|
|
T} T{
|
|
pressing the left or right analog stick
|
|
T}
|
|
T{
|
|
du(up), dd(down), dl(left), dr(right)
|
|
T} T{
|
|
dpad directions (needs --dpad-as-button option)
|
|
T}
|
|
T{
|
|
green, red, yellow, blue, orange
|
|
T} T{
|
|
guitar buttons
|
|
T}
|
|
.TE
|
|
.TP
|
|
\*(T<\fB\-\-axismap\fR\*(T> \fIAXIS=MAPPING,...\fR
|
|
Axis remapping is available via --axismap and works the same as button
|
|
mapping. In addition you can supply a sign to indicate that an axis
|
|
should be inverted. So if you want to invert the y1 axis start with:
|
|
|
|
.nf
|
|
\*(T<$ xboxdrv \-\-axismap \-Y1=Y1\*(T>
|
|
.fi
|
|
|
|
If you want to swap the left and right stick start with:
|
|
|
|
.nf
|
|
\*(T<$ xboxdrv \-\-axismap X2=X1,Y2=Y1,X1=X2,Y1=Y2\*(T>
|
|
.fi
|
|
|
|
Possible axis names are: x1, y1, x2, y2, lt, rt
|
|
|
|
Swaping lt or rt with x1, y1, x2, y2 will not work properly, since
|
|
their range is different.
|
|
.SS "UINPUT PRESET CONFIGURATION OPTIONS"
|
|
The following options are simple shortcuts for common
|
|
configurations that can be accomplished
|
|
by \*(T<\fB\-\-ui\-buttonmap\fR\*(T>
|
|
and \*(T<\fB\-\-ui\-axismap\fR\*(T>.
|
|
.TP
|
|
\*(T<\fB\-\-trigger\-as\-button\fR\*(T>
|
|
LT and RT send button instead of axis events
|
|
.TP
|
|
\*(T<\fB\-\-trigger\-as\-zaxis\fR\*(T>
|
|
Combine LT and RT to form a zaxis instead
|
|
.TP
|
|
\*(T<\fB\-\-dpad\-as\-button\fR\*(T>
|
|
The DPad sends button instead of axis events.
|
|
.TP
|
|
\*(T<\fB\-\-dpad\-only\fR\*(T>
|
|
Both sticks are ignored, only the DPad sends out axis
|
|
events. Useful for games that might get confused by
|
|
additional analog axis. Combining this option
|
|
with \*(T<\fB\-\-trigger\-as\-button\fR\*(T> is recommend
|
|
in most situations.
|
|
.TP
|
|
\*(T<\fB\-\-guitar\fR\*(T>
|
|
Sets a predefined button and axis mapping for use with
|
|
guitar controllers. This mainly gets rid of a few
|
|
unnecesary buttons and axis not used by a guitar
|
|
controller.
|
|
.TP
|
|
\*(T<\fB\-m, \-\-mouse\fR\*(T>
|
|
Lets the controller act as a mouse. It is indendical to:
|
|
|
|
.nf
|
|
\*(T<$ xboxdrv \e
|
|
\-\-dpad\-as\-button
|
|
\-\-deadzone 4000
|
|
\-\-trigger\-as\-zaxis
|
|
\-\-axismap "\-y2=y2,\-trigger=trigger"
|
|
\-\-ui\-axismap "x1=REL_X:15:20,y1=REL_Y:15:20,y2=REL_WHEEL:5:100,x2=REL_HWHEEL:5:100,trigger=REL_WHEEL:5:100"
|
|
\-\-ui\-buttonmap "a=BTN_LEFT,b=BTN_RIGHT,x=BTN_MIDDLE,y=KEY_ENTER,rb=KEY_PAGEDOWN,lb=KEY_PAGEUP,"
|
|
\-\-ui\-buttonmap "dl=KEY_LEFT,dr=KEY_RIGHT,du=KEY_UP,dd=KEY_DOWN,"
|
|
\-\-ui\-buttonmap "start=KEY_FORWARD,back=KEY_BACK,guide=KEY_ESC,tl=void,tr=void"\*(T>
|
|
.fi
|
|
|
|
You can customize it by the usual means, just make sure
|
|
that \*(T<\fB\-\-mouse\fR\*(T> comes before your
|
|
customization options on the command line.
|
|
|
|
Note that if you have your mouse buttons switched you must
|
|
adjust the above to match your mouse configuration or the
|
|
button events will come out wrong.
|
|
.TP
|
|
\*(T<\fB\-\-mimic\-xpad\fR\*(T>
|
|
Causes xboxdrv to use the same axis and button names as the xpad kernel driver.
|
|
.SS "UINPUT CONFIGURATION OPTIONS"
|
|
.TP
|
|
\*(T<\fB\-\-no\-uinput\fR\*(T>
|
|
Do not try to start uinput event dispatching, useful for debugging.
|
|
.TP
|
|
\*(T<\fB\-\-name DEVNAME\fR\*(T>
|
|
Changes the descriptive name the device will have
|
|
.TP
|
|
\*(T<\fB\-\-ui\-new\fR\*(T>
|
|
Allows the creation of an alternative uinput
|
|
configuration to which one can toggle at runtime by
|
|
pressing the ui-toggle button (defaults to guide).
|
|
|
|
.nf
|
|
\*(T<$ xboxdrv \e
|
|
\-\-mouse \e
|
|
\-\-ui\-new
|
|
\-\-ui\-axismap X1=ABS_X,Y1=ABS_Y \e
|
|
\-\-ui\-buttonmap A=JS_0,B=JS_1\*(T>
|
|
.fi
|
|
|
|
The above configuration would install mouse emulation as
|
|
first configuration and a simple joystick emulation as
|
|
second configuration. Allowing toggling between mouse
|
|
emulation and joystick handling by pressing the guide
|
|
button.
|
|
|
|
Not that \*(T<\fB\-\-ui\-new\fR\*(T> is currently limited
|
|
to only configurations done
|
|
with \*(T<\fB\-\-ui\-buttonmap\fR\*(T>
|
|
and \*(T<\fB\-\-ui\-axismap\fR\*(T>, autofire, throttle
|
|
emulation, deadzones and all other things can currently
|
|
not be switched at runtime.
|
|
.TP
|
|
\*(T<\fB\-\-ui\-clear\fR\*(T>
|
|
Removes all uinput mappings and will leave the driver in
|
|
a blank state and only map those things you added
|
|
yourself. If you only want to get rid of individual
|
|
buttons you can use the 'void' event.
|
|
.TP
|
|
\*(T<\fB\-\-ui\-toggle\fR\*(T> \fIXBOXBTN\fR
|
|
Sets the button that will be used to toggle between
|
|
different uinput configurations.
|
|
.TP
|
|
\*(T<\fB\-\-ui\-buttonmap\fR\*(T> \fIUIBUTTONSPEC,...\fR
|
|
.nf
|
|
\*(T<UIBUTTONSPEC = XBOXBUTTON [ "+" XBOXBUTTON ] [ "^" FILTER ] ... "=" ( RELSPEC | BTNSPEC | EXECSPEC ) ;
|
|
RELSPEC = [ DEVICEID "\-" ] "REL_" [ ":" [ VALUE ] [ ":" REPEAT ] ] ;
|
|
BTNSPEC = [ DEVICEID "\-" ] ( ( "BTN_" NAME ) | ( "KEY_" NAME ) ) { "+" BTNSPEC } ;
|
|
EXECSPEC = PROGRAM { ":" ARGUMENT } ;
|
|
XBOXBUTTON = "a" | "b" | "x" | "y" | "lb" | "rb" | "lt" | "rt" |
|
|
"tl" | "tr" | "start" | "select" | "back" | "guide" | "black" | "white" ;
|
|
FILTER = "toggle" | "invert" | "autofire" [ ":" RATE ] [ ":" DELAY ] | log [ ":" STRING ] ;
|
|
NAME = STRING ;
|
|
VALUE = NUMBER ;
|
|
REPEAT = NUMBER ;
|
|
DEVICEID = NUMBER ;\*(T>
|
|
.fi
|
|
|
|
Allows you to change the event code that is send to the
|
|
kernel for buttons. The usage is similar to the normal button
|
|
mapping, except that the right hand side is an event name from
|
|
\*(T<\fI/usr/include/linux/input.h\fR\*(T>. You can
|
|
use all \fBKEY_\fR or \fBBTN_\fR
|
|
codes for \*(T<\fB\-\-ui\-buttonmap\fR\*(T>.
|
|
|
|
If the right hand side is left empty all the supplied
|
|
filters will be added to the already existing button
|
|
binding instead of a new one.
|
|
|
|
Aside from the named keys, you can also give the input
|
|
code directly as number via the
|
|
syntax \fBKEY_#\fINUM\fB\fR.
|
|
|
|
Instead of the low level \fBKEY_\fR names,
|
|
which represent keycodes, you can also use the higher
|
|
level X11 keysyms \fBXK_\fR, the keysyms have
|
|
the advantage that they map directly to the key you
|
|
expect, while a \fBKEY_\fR name gets mungled
|
|
by the X11 keymap and will often not report what you
|
|
expect in case you use a keymap that is different then
|
|
your keyboard (i.e. dvorak on a qwerty keyboard).
|
|
|
|
A full list of X11 keysyms is available at
|
|
\*(T<\fI/usr/include/X11/keysymdef.h\fR\*(T>, note that you can only use those that
|
|
are reachable by your current keymap. Keysyms that are reachable via
|
|
multiple keycodes might break the mapping from keysym to evdev code.
|
|
|
|
For joystick buttons there is in addition to the \fBBTN_JOYSTICK\fR, \fBBTN_X\fR,
|
|
etc. macros the special name \fBJS_$NUM\fR, which sets the given button to
|
|
the $NUMS joystick button, i.e.:
|
|
|
|
.nf
|
|
\*(T<$ xboxdrv \-\-ui\-clear \-\-ui\-buttonmap A=JS_0,B=JS_1\*(T>
|
|
.fi
|
|
|
|
Note that this will only work if no other joystick
|
|
button ids are in the way.
|
|
|
|
You can also map a button to a \fBREL_\fR
|
|
event. In that case you can supply additional paramaters in the form of:
|
|
|
|
.nf
|
|
\*(T<$ xboxdrv \-\-ui\-buttonmap X=REL_???:VALUE:REPEAT\*(T>
|
|
.fi
|
|
|
|
\fIVALUE\fR gives the value of the event (default: 10)
|
|
|
|
\fIREPEAT\fR
|
|
gives the number of milisecond to pass before the event
|
|
is fired again (default: 5)
|
|
|
|
The special 'void' event allows you to clear any
|
|
existing bindings for a given button, which can be
|
|
useful in cases when a game only supports a limited
|
|
number of buttons.
|
|
|
|
You can also prepend a device_id to the UIBUTTONSPEC
|
|
which allows you to create multiple uinput devices. By
|
|
default 'auto' is assumed as device_id which
|
|
automatically try to do the right thing, sending
|
|
keyboard events to a keyboard device and mouse events to
|
|
a mouse device. Other possible values are 'mouse' and
|
|
\&'keyboard'. A device_id of '0' refers to the first
|
|
joystick device, values larger then 0 to the second,
|
|
third, etc.
|
|
|
|
Note that the 'mouse' and 'keyboard' device_id names do
|
|
not give you a mouse or keyboard device, these are just
|
|
symbolic names for the devices into which xboxdrv will
|
|
sort events that look like a mouse or keyboard
|
|
event. The final determination of which device gets
|
|
handled as what will be done by the Kernel or Xorg
|
|
depending on what events a device provides.
|
|
|
|
An example configuration makeing use of device_id would look like this:
|
|
|
|
.nf
|
|
\*(T<xboxdrv \-s \e
|
|
\-\-ui\-clear \e
|
|
\-\-ui\-buttonmap A=0\-JS_0,B=0\-JS_1 \-\-ui\-axismap X2=1\-ABS_X,Y2=1\-ABS_Y
|
|
\-\-ui\-buttonmap X=1\-JS_0,Y=1\-JS_1 \-\-ui\-axismap X2=1\-ABS_X,Y2=1\-ABS_Y\*(T>
|
|
.fi
|
|
|
|
In this example the left stick creates a joystick device
|
|
and the right stick creates a separate joystick device.
|
|
|
|
Instead of giving just a single button, it is also
|
|
possible to give two buttons
|
|
to \*(T<\fB\-\-ui\-buttonmap\fR\*(T> to allow shifting:
|
|
|
|
.nf
|
|
\*(T<xboxdrv \-s \e
|
|
\-\-ui\-clear \e
|
|
\-\-ui\-buttonmap A=JS_0,B=JS_1,LB+A=JS_2,LB+B=JS_3\*(T>
|
|
.fi
|
|
|
|
In this example LB acts as shift button, if A is pressed
|
|
without LB it will send out a JS_0 event, but if LB is
|
|
pressed it will send a JS_2 event instead. This allows
|
|
you to multiply the number of available buttons on the
|
|
controller.
|
|
|
|
See the section KEYBOARD EMULATION below on how to
|
|
resolve issues with Xorg not detecting the virtual
|
|
keyboard that xboxdrv creates.
|
|
|
|
You can also apply filters to button events:
|
|
|
|
.nf
|
|
\*(T<xboxdrv \-s \e
|
|
\-\-ui\-buttonmap A^toggle=JS_0\*(T>
|
|
.fi
|
|
|
|
Hold Button
|
|
|
|
You can send different events depending on how long a
|
|
button was pressed by:
|
|
|
|
.nf
|
|
\*(T<xboxdrv \e
|
|
\-\-ui\-buttonmap A=JS_0:JS_1:500\*(T>
|
|
.fi
|
|
|
|
This will send JS_0 events when the button is pressed
|
|
and switch to JS_1 events when the button was hold for
|
|
500 miliseconds.
|
|
|
|
Exec Button
|
|
|
|
You can bind a button to an application, so that the
|
|
application will be launched when the button was
|
|
pressed:
|
|
|
|
.nf
|
|
\*(T<xboxdrv \e
|
|
\-\-ui\-buttonmap A=exec:/home/juser/local/bin/screenshot.sh\*(T>
|
|
.fi
|
|
|
|
Macro Button
|
|
|
|
A button can be bound to a macros via:
|
|
|
|
.nf
|
|
\*(T<xboxdrv \e
|
|
\-\-ui\-buttonmap A=macro:/home/juser/.xboxdrv/somefile.macro\*(T>
|
|
.fi
|
|
|
|
The \*(T<\fI.macro\fR\*(T> file has the form of:
|
|
|
|
.nf
|
|
\*(T<
|
|
send KEY_LEFTSHIFT 1
|
|
wait 500
|
|
send KEY_LEFTSHIFT 0\*(T>
|
|
.fi
|
|
|
|
All abs, rel and key events can be send from a macro file.
|
|
|
|
For documentation on the filters you can apply to events
|
|
see [Button Filter].
|
|
.TP
|
|
\*(T<\fB\-\-ui\-axismap\fR\*(T> \fIUIAXISSPEC,...\fR
|
|
.nf
|
|
\*(T<UIAXISSPEC = [ XBOXBTN "+" ] XBOXAXIS { "^" FILTER } "=" ( RELSPEC | BTNSPEC | ABSSPEC ) ;
|
|
BTNSPEC = "KEY_" NAME ":" "KEY_" NAME ":" THRESHOLD ;
|
|
RELSPEC = "REL_" NAME ":" VALUE ":" REPEAT ;
|
|
ABSSPEC = "ABS_" NAME ;
|
|
FILTER = ( "calibration" | "cal" ) ":" MIN ":" CENTER ":" MAX |
|
|
( "sensitifity" | "sen" ) ":" SENSITIFITY |
|
|
( "deadzone" | "dead" ) ":" MIN ":" MAX ":" SMOOTH |
|
|
( "relative" | "rel" ) ":" SPEED |
|
|
( "responsecurve" | "response" | "resp" ) { ":" VALUE }
|
|
XBOXBTN = "a" | "b" | "x" | "y" | "start" | "back" | "guide" | "lb" | "rb" | ...
|
|
XBOXAXIS = "x1" | "y1" | "x2" | "y2" | "z" | "lt" | "rt" | "dpad_x" | "dpad_y" ;
|
|
VALUE = NUMBER ;
|
|
REPEAT = NUMBER ;
|
|
THRESHOLD = NUMBER ;
|
|
NAME = STRING ;\*(T>
|
|
.fi
|
|
|
|
Similar to \*(T<\fB\-\-ui\-buttonmap\fR\*(T> this option
|
|
allows you to change the event code that is send to the
|
|
kernel for axes. The events that are available are the
|
|
same as for \*(T<\fB\-\-ui\-buttonmap\fR\*(T>.
|
|
|
|
.nf
|
|
\*(T<$ xboxdrv \-\-ui\-axismap X1=REL_???:VALUE:REPEAT\*(T>
|
|
.fi
|
|
|
|
\fIVALUE\fR gives the maximum value of the event (default: 10)
|
|
|
|
\fIREPEAT\fR
|
|
gives the number of milisecond to pass before the event
|
|
is fired again (default: 5)
|
|
|
|
.nf
|
|
\*(T<$ xboxdrv \-\-ui\-axismap X1=KEY_UP:KEY_DOWN:THRESHOLD\*(T>
|
|
.fi
|
|
|
|
\fIKEY_UP\fR gives the keycode to be send when the axis is moved up
|
|
|
|
\fIKEY_DOWN\fR gives the keycode to be send when the axis is moved down
|
|
|
|
\fITHRESHOLD\fR gives the threshold that triggers the sending of an event
|
|
|
|
Just like \*(T<\fB\-\-ui\-buttonmap\fR\*(T>, you can
|
|
also use shift keys in place of the XBOXAXIS:
|
|
|
|
.nf
|
|
\*(T<$ xboxdrv \-\-ui\-axismap X1=ABS_X,LB+X1=ABS_RX\*(T>
|
|
.fi
|
|
|
|
This allows you to send ABS_X events normally and ABS_RX
|
|
events when the LB button is held down.
|
|
|
|
For information on how to use axis filters, see [Axis Filter].
|
|
.TP
|
|
\*(T<\fB\-\-square\-axis\fR\*(T>
|
|
The Xbox360 gamepad, as most other current day gamepads,
|
|
features a circular movement range, which restricts the
|
|
movement so that the distance to the center never gets
|
|
beyond 1. This means that when you have the controller
|
|
at the top/left the value reported is (0.7, 0.7)
|
|
(i.e. length 1, angle 45) instead of (1,1). This
|
|
behaviour is different then most classic PC joysticks,
|
|
which had a square range and would report (1,1) when
|
|
hold in the top/left corner.
|
|
|
|
Some old games (i.e. mostly DOS stuff) require a
|
|
square movement range and will not function properly
|
|
with the Xbox360 gamepad. Via the
|
|
\*(T<\fB\-\-square\-axis\fR\*(T> option you can work around this issue and diagonals will
|
|
be reported as (1,1).
|
|
.TP
|
|
\*(T<\fB\-\-four\-way\-restrictor\fR\*(T>
|
|
The \*(T<\fB\-\-four\-way\-restrictor\fR\*(T> option allows to
|
|
limit the movement on both analogsticks to only four
|
|
directions (up, down, left, right), the diagonals (up/left,
|
|
up/right, down/left, down/right) are filtered out from the
|
|
output. This option is useful for games such as Tetris, that
|
|
don't need diagonals and where you don't want to accidently
|
|
trigger the down-move while trying to do a left/right move.
|
|
.TP
|
|
\*(T<\fB\-\-dpad\-rotation\fR\*(T> \fIDEGREE\fR
|
|
Allows you to rotate the
|
|
dpad. \fIDEGREE\fR
|
|
must be a multiple of 45. This can be useful in
|
|
isometric games where the playfield itself is rotated,
|
|
thus a:
|
|
|
|
.nf
|
|
\*(T<xboxdrv \-\-dpad\-rotation 45\*(T>
|
|
.fi
|
|
|
|
Will give you controls that are relative to your
|
|
character instead of your viewpoint.
|
|
.TP
|
|
\*(T<\fB\-\-axis\-sensitivty \fR\*(T>\fIAXIS=SENSITIVITY\fR,...
|
|
The sensitive of an axis can be adjusted via --axis-sensitivty:
|
|
|
|
.nf
|
|
\*(T<$ xboxdrv \-\-axis\-sensitivty X1=\-1.0,Y1=\-1.0\*(T>
|
|
.fi
|
|
|
|
A value of 0 gives you the default linear sensitivity,
|
|
values larger then 0 will give you higher sensitivity,
|
|
while values smaller then 0 will give you lower
|
|
sensitivity. Sensitivity values in the range of [-1, 1]
|
|
will generally give good results, everything beyond that
|
|
won't be of much practical use.
|
|
|
|
Sensitivity works by applying:
|
|
|
|
.nf
|
|
\*(T<t = 2 ** sensitivity;
|
|
pos = (1.0f \- (1.0f \- pos) ** t) ** (1 / t);\*(T>
|
|
.fi
|
|
|
|
To the value of the axis, this means that both the
|
|
minimum value and the maximum value of the axis will
|
|
always stay the same, just the response inbetween
|
|
changes.
|
|
|
|
For a complete freeform way to change the axis response
|
|
see the \*(T<\fBResponse Curve Filter\fR\*(T>.
|
|
.TP
|
|
\*(T<\fB\-\-relative\-axis AXIS=NUM,...\fR\*(T>
|
|
The function \*(T<\fB\-\-relative\-axis\fR\*(T> allows you
|
|
to change the behaviour of an axis so that your movement
|
|
of it moves its value up or down instead of applying it
|
|
directly. This allows you to simulate throttle control
|
|
for flightsim games.
|
|
|
|
Since the axis might be upside down, you might want to use
|
|
the \*(T<\fB\-\-axismap\fR\*(T> function to reverse it.
|
|
|
|
.nf
|
|
\*(T<$ xboxdrv \-\-relative\-axis y2=64000 \-\-axismap \-y2=y2\*(T>
|
|
.fi
|
|
.TP
|
|
\*(T<\fB\-\-autofire BUTTON=FREQUENCY\fR\*(T>
|
|
Autofire mapping allows you to let a button automatically fire with a
|
|
given frequency in miliseconds:
|
|
|
|
.nf
|
|
\*(T<$ xboxdrv \-\-autofire A=250\*(T>
|
|
.fi
|
|
|
|
Combining \*(T<\fB\-\-autofire\fR\*(T> with button map allows you to have one button act
|
|
as autofire while another one, emitting the same signal, acts normally.
|
|
|
|
.nf
|
|
\*(T<$ xboxdrv \-\-autofire B=250 \-\-buttonmap B=A\*(T>
|
|
.fi
|
|
.TP
|
|
\*(T<\fB\-\-calibration \fR\*(T>\fICALIBRATIONSPEC\fR
|
|
If your gamepad for some reason can't reach the maximum value or isn't
|
|
centered properly you can fix that via the calibration options:
|
|
|
|
.nf
|
|
\*(T<$ xboxdrv \-\-calibration X2=\-32768:0:32767\*(T>
|
|
.fi
|
|
|
|
X2 is the axis name and the three values that follow are min, center
|
|
and max. Simply insert the values that jstest reports when your axis
|
|
is in the respective positions.
|
|
|
|
You can also use the calibration option if you want to make your
|
|
joystick more sensitive. A setting of:
|
|
|
|
.nf
|
|
\*(T<xboxdrv \-\-calibration AXIS=MIN:CENTER:MAX,...\*(T>
|
|
.fi
|
|
|
|
Will cause the joystick device report maximum position when your
|
|
stick is only moved half the way.
|
|
.TP
|
|
\*(T<\fB\-\-axis\-sensitivty \fR\*(T>\fIAXIS=SENSITIVITY\fR,...
|
|
The sensitive of an axis can be adjusted via --axis-sensitivty:
|
|
|
|
.nf
|
|
\*(T<$ xboxdrv \-\-axis\-sensitivty X1=\-2.0,Y1=\-2.0\*(T>
|
|
.fi
|
|
|
|
A value of 0 gives you the default linear sensitivity, values larger
|
|
then 0 will give you heigher sensitivity, while values smaller then 0
|
|
will give you lower sensitivity.
|
|
|
|
Sensitivity works by applying:
|
|
|
|
.nf
|
|
\*(T<t = 2 ** sensitivity;
|
|
pos = (1.0f \- (1.0f \- pos) ** t) ** (1 / t);\*(T>
|
|
.fi
|
|
|
|
To the value of the axis, thus both the min and max position will
|
|
always stay the same, only the values inbetween change.
|
|
.SH "INPUT FILTER"
|
|
Input filter allow to manipulate the events that come from the
|
|
controller. They can be used
|
|
on \*(T<\fB\-\-buttonmap\fR\*(T>, \*(T<\fB\-\-axismap\fR\*(T>, \*(T<\fB\-\-ui\-buttonmap\fR\*(T>
|
|
and \*(T<\fB\-\-ui\-axismap\fR\*(T>. The difference between the
|
|
two is that the \*(T<\fB\-\-ui\-...\fR\*(T> versions applies to
|
|
the uinput events, while the other version applies to Xbox360
|
|
controller events.
|
|
.SS "BUTTON FILTER"
|
|
.TP
|
|
\*(T<\fBtog\fR\*(T>, \*(T<\fBtoggle\fR\*(T>
|
|
The toggle filter will turn the button into a toggle
|
|
button, clicking the button will set it to pressed state
|
|
and pressing it again will unpress it. Useful for games
|
|
where you might want to permanently run or duck without
|
|
holding the button pressed.
|
|
.TP
|
|
\*(T<\fBinv\fR\*(T>, \*(T<\fBinvert\fR\*(T>
|
|
The invert filter will keep the button in pressed state
|
|
when it is not pressed and in unpressed state when it is
|
|
pressed.
|
|
.TP
|
|
\*(T<\fBauto\fR\*(T>, \*(T<\fBautofire\fR\*(T>:\fIRATE\fR:\fIDELAY\fR
|
|
The autofire filter allows to repeatatly send button
|
|
press events when the button is held down. It takes two
|
|
optional parameters:
|
|
|
|
\fIRATE\fR is the number of
|
|
miliseconds between button press events.
|
|
|
|
\fIDELAY\fR the amount of
|
|
miliseconds till the autofire will start, before that
|
|
delay the button will act as normal.
|
|
.TP
|
|
\*(T<\fBlog\fR\*(T>:\fISTRING\fR
|
|
The log filter will output everything to stdout that
|
|
goes through it to, this is useful for debugging the
|
|
filter. A \fISTRING\fR can be
|
|
provided as parameter that will be outputed before the
|
|
event.
|
|
.SS "AXIS FILTER"
|
|
.TP
|
|
\*(T<\fBcal\fR\*(T>, \*(T<\fBcalibration\fR\*(T>:\fIMIN\fR:\fICENTER\fR:\fIMAX\fR
|
|
See \*(T<\fB\-\-calibration\fR\*(T>.
|
|
.TP
|
|
\*(T<\fBsen\fR\*(T>, \*(T<\fBsensitivity\fR\*(T>:\fISENSITIVITY\fR
|
|
See \*(T<\fB\-\-axis\-sensitivity\fR\*(T>.
|
|
.TP
|
|
\*(T<\fBdead\fR\*(T>, \*(T<\fBdeadzone\fR\*(T>:\fIVALUE\fR, \*(T<\fBdeadzone\fR\*(T>:\fIMIN\fR:\fICENTER\fR:\fIMAX\fR
|
|
Deadzone filter applies a deadzone to the current axis.
|
|
If only \fIMIN\fR is provided, the
|
|
parameter will be interpreted
|
|
as \fI-MIN:MIN:1\fR. If the
|
|
argument is 1, smooth filtering will be applied so that
|
|
the end of the deadzone is 0. Setting the argument to 0
|
|
will apply a simple cut-off filter, where all events
|
|
smaller then the threshold are ignored.
|
|
.TP
|
|
\*(T<\fBrel\fR\*(T>, \*(T<\fBrelative\fR\*(T>:\fISPEED\fR
|
|
See \*(T<\fB\-\-relative\-axis\fR\*(T>.
|
|
.TP
|
|
\*(T<\fBresp\fR\*(T>, \*(T<\fBresponse\fR\*(T>:\fIVALUES\fR:...
|
|
The response curve filter allows you to completely
|
|
change the way an axis reacts. The filter takes a list
|
|
of \fIVALUES\fR that are then
|
|
linearly interpolated and spread across the full range
|
|
of the axis. An example would look like this:
|
|
|
|
.nf
|
|
\*(T<xboxdrv \e
|
|
\-\-ui\-axismap x1^resp:\-32768:\-4000:0:4000:32767\*(T>
|
|
.fi
|
|
|
|
Here the X1 axis is manipulated so that it will have a
|
|
lower sensitivity in the center and a higher one on the
|
|
outside.
|
|
.TP
|
|
\*(T<\fBlog\fR\*(T>:\fISTRING\fR
|
|
The log filter will output everything to stdout that
|
|
goes through it to, this is useful for debugging the
|
|
filter. A \fISTRING\fR can be
|
|
provided as parameter that will be outputed before the
|
|
event.
|
|
.SH "RUNNING XBOXDRV"
|
|
Plug in your Xbox360 gamepad and then unload the xpad driver via:
|
|
.PP
|
|
.nf
|
|
\*(T<$ rmmod xpad\*(T>
|
|
.fi
|
|
.PP
|
|
If you want to permanently unload it add the following line to
|
|
\*(T<\fI/etc/modprobe.d/blacklist.conf\fR\*(T>:
|
|
.PP
|
|
.nf
|
|
\*(T<blacklist xpad\*(T>
|
|
.fi
|
|
.PP
|
|
Next you have to load the uinput kernel module which allows userspace
|
|
programms to create input devices and the joydev module which gives
|
|
you the \*(T<\fI/dev/input/jsX\fR\*(T> device:
|
|
.PP
|
|
.nf
|
|
\*(T<$ modprobe uinput
|
|
$ modprobe joydev\*(T>
|
|
.fi
|
|
.PP
|
|
You also have to make sure that you have access rights to
|
|
/dev/input/uinput, either add yourself to the appropriate group,
|
|
adjust the permissions or run xboxdrv as root.
|
|
.PP
|
|
Once ensured that xpad is out of the way and everything is in place
|
|
start the userspace driver with:
|
|
.PP
|
|
.nf
|
|
\*(T<$ xboxdrv\*(T>
|
|
.fi
|
|
.PP
|
|
Or in case you don't have the neccesary rights (being in group root
|
|
should often be enough) start the driver as root via:
|
|
.PP
|
|
.nf
|
|
\*(T<$ sudo xboxdrv\*(T>
|
|
.fi
|
|
.PP
|
|
This will create /dev/input/js0 and allow you to access the gamepad
|
|
from any game. To exit the driver press Ctrl-c.
|
|
If you have multiple wired controllers you need to start multiple instances
|
|
of the xboxdrv driver and append the -i argument like this:
|
|
.PP
|
|
.nf
|
|
\*(T<$ xboxdrv \-i 1\*(T>
|
|
.fi
|
|
.PP
|
|
If you have multiple wireless controller you need to start multiple
|
|
instances of the xboxdrv driver and append the --wid argument like
|
|
this:
|
|
.PP
|
|
.nf
|
|
\*(T<$ xboxdrv \-\-wid 1\*(T>
|
|
.fi
|
|
.PP
|
|
You have to sync the wireless controller as usual.
|
|
.PP
|
|
This will then use the second detected controller, see to see which id
|
|
your controller has:
|
|
.PP
|
|
.nf
|
|
\*(T<$ xboxdrv \-\-list\-controller\*(T>
|
|
.fi
|
|
.PP
|
|
When everything works as expected it is recomment that you run xboxdrv
|
|
with the silent option:
|
|
.PP
|
|
.nf
|
|
\*(T<$ xboxdrv \-\-silent\*(T>
|
|
.fi
|
|
.PP
|
|
This will suppress the logging of events to the console and will
|
|
gurantee that no uneccesarry CPU cycles are wasted.
|
|
.PP
|
|
If you want to abuse the led or rumble of the gamepad for notification
|
|
in scripts you can do see via:
|
|
.PP
|
|
.nf
|
|
\*(T<$ xboxdrv \-\-led 10 \-\-rumble 30,30 \-\-quit\*(T>
|
|
.fi
|
|
.PP
|
|
This will cause a mild rumble and the led to rotate, you can stop it
|
|
again via, which also happens to be the command you can use to stop
|
|
your Xbox360 controller from blinking:
|
|
.PP
|
|
.nf
|
|
\*(T<$ xboxdrv \-\-\-led 0 \-\-rumble 0,0 \-\-quit\*(T>
|
|
.fi
|
|
.PP
|
|
For rumble to work make sure you have connected the
|
|
controller to a USB port that has enough power, an unpowered USB
|
|
hub might not work.
|
|
.SH TESTING
|
|
Knowing how to test a xboxdrv configuration is absolutely crucial in
|
|
understanding what is wrong in a given setup. Testing the
|
|
configuration in a game is most often not helpful, since you won't see
|
|
the true cause beyond endless layers of abstraction between you and
|
|
the actual events. Luckily there are a few tools you can use to test,
|
|
all of these are command line based and it is recomment that you get
|
|
familar with them when you want to do any more complex configuration.
|
|
.SS EVTEST
|
|
evtest lets you read raw input events from \*(T<\fI/dev/input/eventX\fR\*(T>. The
|
|
event devices are the very core of all event handling, things like the
|
|
joystick devices are derived from the event device, so if you want to
|
|
fix some issue on the joystick device, you have to fix the event
|
|
device.
|
|
.PP
|
|
evtest is available in the tools/ directory, you might also find it in
|
|
your distribution.
|
|
.SS JSTEST
|
|
jstest lets you read the output out of a joystick event device (/dev/input/js0).
|
|
.PP
|
|
jstest is available in the tools/ directory or as part of your
|
|
distribution.
|
|
.SS SDL-JSTEST
|
|
sdl-jstest lets you see events as games using SDL see them. This is
|
|
very important when you want to set and test the SDL_LINUX_JOYSTICK
|
|
environment variables.
|
|
.PP
|
|
Currently available via:
|
|
.PP
|
|
.nf
|
|
\*(T<$ svn co svn://svn.berlios.de/windstille/trunk/sdl\-jstest\*(T>
|
|
.fi
|
|
.SS XEV
|
|
xev lets you see the events that Xorg sees. Note however that you
|
|
might not see all events, since some will be grapped by your Window
|
|
manager before they reach xev, this is normal.
|
|
.PP
|
|
xev is part of every Linux distribution, on Ubuntu its available via:
|
|
.PP
|
|
.nf
|
|
\*(T<$ apt\-get install x11\-utils\*(T>
|
|
.fi
|
|
.SS JSCALC
|
|
Do not use this tool, for current day joysticks it doesn't do
|
|
anything useful, so don't touch it, it won't fix your problems.
|
|
.SS MOUSE
|
|
No tools for testing the output on /dev/input/mouseX are known.
|
|
.SS NOTE
|
|
If the tools provide no output at all, this might not be due to a
|
|
wrong configuration, but due to Xorg grabbing your event device and
|
|
locking it, see Xorg section for possible fixes.
|
|
.SH EXAMPLES
|
|
.SS "KEYBOARD EMULATION"
|
|
The following configuration works for games that are
|
|
played with keyboard, like Flash games or games that don't
|
|
support a joystick. You might have to adjust the keybindings
|
|
to fit the game:
|
|
.PP
|
|
.nf
|
|
\*(T<$ xboxdrv \e
|
|
\-\-ui\-clear \e
|
|
\-\-ui\-buttonmap a=XK_a,b=XK_b,x=XK_x,y=XK_y \e
|
|
\-\-ui\-buttonmap dl=XK_Left,dr=XK_Right,du=XK_Up,dd=XK_Down\*(T>
|
|
.fi
|
|
.SS "PRINCE OF PERSIA OR TOMB RAIDER ANNIVERSARY IN WINE "
|
|
Start \fBxboxdrv\fR with:
|
|
.PP
|
|
.nf
|
|
\*(T<$ xboxdrv \-\-trigger\-as\-button \-s \*(T>
|
|
.fi
|
|
.PP
|
|
The triggers are not regonized in these games when they
|
|
are analog, so we have to handle them as buttons.
|
|
.SS "FIGHTING GAMES WITH DATEL ARCADE PRO JOYSTICK:"
|
|
The left and right trigger get turned into digital buttons. All axis
|
|
except the dpad are ignored. RB and RT are mapped to act as if buttons
|
|
1,2 and 3 are pressed simultaniously (useful for some special
|
|
attacks). Instead of using the native button names, the
|
|
1,2,3,... aliases are used, which makes things easier to edit:
|
|
.PP
|
|
.nf
|
|
\*(T<$ xboxdrv \-\-dpad\-only \e
|
|
\-\-trigger\-as\-button \e
|
|
\-\-buttonmap lb=1,x=2,y=3,lt=4,a=5,b=6,rb=1,rb=2,rb=3,rt=4,rt=5,rt=6\*(T>
|
|
.fi
|
|
.SS "CH FLIGHTSTICK EMULATION IN DOSBOX:"
|
|
In \*(T<\fIdosbox.conf\fR\*(T> set:
|
|
.PP
|
|
.nf
|
|
\*(T<[joystick]
|
|
joysticktype = ch\*(T>
|
|
.fi
|
|
.PP
|
|
Start xboxdrv with:
|
|
.PP
|
|
.nf
|
|
\*(T<$ xboxdrv \-s \e
|
|
\-\-trigger\-as\-zaxis \-\-square\-axis \e
|
|
\-\-relative\-axis y2=64000 \-\-axismap \-y2=x2,x2=y2\*(T>
|
|
.fi
|
|
.PP
|
|
Your right analog stick will act as trottle control, the trigger as
|
|
rudder.
|
|
.SS SAUERBRATEN
|
|
First analogstick gets mapped te cursor keys, second
|
|
analogstick gets mapped to mouse. Note: This is just an
|
|
incomplete example, not a perfectly playable configuration,
|
|
you have to do tweaking yourself.
|
|
.PP
|
|
.nf
|
|
\*(T<$ xboxdrv \e
|
|
\-\-ui\-axismap x2=REL_X:10,y2=REL_Y:\-10,x1=KEY_LEFT:KEY_RIGHT,y1=KEY_UP:KEY_DOWN \e
|
|
\-\-ui\-buttonmap a=BTN_RIGHT,b=BTN_LEFT,x=BTN_EXTRA \e
|
|
\-\-ui\-buttonmap rb=KEY_5,lb=KEY_6,lt=BTN_LEFT,rt=BTN_RIGHT \e
|
|
\-\-ui\-buttonmap y=KEY_ENTER,dl=KEY_4,dr=KEY_2,du=KEY_1,dd=KEY_3,back=KEY_TAB,start=KEY_ESC \e
|
|
\-s \-\-deadzone 6000 \-\-dpad\-as\-button \-\-trigger\-as\-button\*(T>
|
|
.fi
|
|
.SS WARSOW
|
|
Note: This is just an incomplete example, not a perfectly playable
|
|
configuration, you have to do tweaking yourself.
|
|
.PP
|
|
.nf
|
|
\*(T<$ xboxdrv \e
|
|
\-\-ui\-axismap x2=REL_X:10,y2=REL_Y:\-10,x1=KEY_A:KEY_D,y1=KEY_W:KEY_S \e
|
|
\-\-ui\-buttonmap a=KEY_LEFTSHIFT,b=BTN_C,x=BTN_EXTRA,y=KEY_C \e
|
|
\-\-ui\-buttonmap lb=BTN_RIGHT,rb=KEY_SPACE \e
|
|
\-\-ui\-buttonmap lt=KEY_Z,rt=BTN_LEFT \e
|
|
\-\-ui\-buttonmap dl=KEY_4,dr=KEY_2,du=REL_WHEEL:\-1:150,dd=REL_WHEEL:1:150 \e
|
|
\-\-ui\-buttonmap back=KEY_TAB,start=KEY_ESC \e
|
|
\-s \-\-deadzone 6000 \-\-dpad\-as\-button \-\-trigger\-as\-button\*(T>
|
|
.fi
|
|
.SS "USING MOUSE EMULATION AND JOYSTICK AT THE SAME TIME"
|
|
To use mouse emulation and joystick at the same time you have
|
|
to register two uinput configuration with xboxdrv, this works
|
|
via:
|
|
.PP
|
|
.nf
|
|
\*(T<$ xboxdrv \-\-ui\-new \-\-mouse\*(T>
|
|
.fi
|
|
.PP
|
|
The \*(T<\fB\-\-ui\-new\fR\*(T> option will open up a second
|
|
configuration and all configuration options on the right side
|
|
of it will go there, while everything on the left side of it
|
|
will go into the first configuration. Toggling between the
|
|
configurations works with the guide button, you can have as
|
|
many configuratios as you want.
|
|
.SH "SDL NOTES"
|
|
To let SDL know which axis act as a hat and which act as normal axis
|
|
you have to set an environment variable:
|
|
.PP
|
|
.nf
|
|
\*(T<
|
|
$ SDL_LINUX_JOYSTICK="'Xbox Gamepad (userspace driver)' 6 1 0"
|
|
$ export SDL_LINUX_JOYSTICK\*(T>
|
|
.fi
|
|
.PP
|
|
You might also need in addition use this (depends on the way SDL was compiled):
|
|
.PP
|
|
.nf
|
|
\*(T<
|
|
$ SDL_JOYSTICK_DEVICE="/dev/input/js0"
|
|
$ export SDL_JOYSTICK_DEVICE\*(T>
|
|
.fi
|
|
.PP
|
|
This will let the DPad act as Hat in SDL based application. For
|
|
many games the driver will work without this, but especially in
|
|
Dosbox this variable is very important.
|
|
.PP
|
|
If you use options in xboxdrv that change the number of axis you
|
|
have to adjust the variable accordingly, see:
|
|
.TP 0.2i
|
|
\(bu
|
|
\(laftp://ptah.lnf.kth.se/pub/misc/sdl-env-vars\(ra
|
|
.TP
|
|
SDL_LINUX_JOYSTICK
|
|
Special joystick configuration string for linux. The format is
|
|
\*(T<\fB"name numaxes numhats numballs"\fR\*(T>
|
|
where name is the name string of the joystick (possibly in single
|
|
quotes), and the rest are the number of axes, hats and balls
|
|
respectively.
|
|
.TP
|
|
SDL_JOYSTICK_DEVICE
|
|
Joystick device to use in the linux joystick driver, in addition to the usual: \*(T<\fI/dev/js*\fR\*(T>, \*(T<\fI/dev/input/event*\fR\*(T>, \*(T<\fI/dev/input/js*\fR\*(T>
|
|
.SH TROUBLESHOOTING
|
|
.SS "\(dqNO XBOX OR XBOX360 CONTROLLER FOUND\(dq"
|
|
This means that either your controller isn't plugged in or not
|
|
recognized by the driver. To fix this you need to know the idVendor
|
|
and the idProduct numbers, which you can find out via:
|
|
.PP
|
|
.nf
|
|
\*(T<$ lsusb \-v\*(T>
|
|
.fi
|
|
.PP
|
|
Once done you can try to add them to this array in \*(T<\fIxpad_device.cpp\fR\*(T>:
|
|
.PP
|
|
.nf
|
|
\*(T<XPadDevice xpad_devices[] = { ... }\*(T>
|
|
.fi
|
|
.PP
|
|
If you have success with that, send a patch
|
|
to <\*(T<grumbel@gmx.de\*(T>>, if not, contact me too, I
|
|
might be able to provide additional help.
|
|
.PP
|
|
As an alternative you can also use the --device and --type option to
|
|
enforce a USB device as well as a controller type an bypass any auto
|
|
detection.
|
|
.SS "\(dqUNKNOWN DATA: BYTES: 3 DATA: ...\(dq"
|
|
This means that your controller is sending data that isn't understood
|
|
by the driver. If your controller still works, you can just ignore it,
|
|
the Xbox360 controller seems to send out useless data every now and
|
|
then. If your controller does not work and you get plenty of those
|
|
lines when you move the sticks or press buttons it means that your
|
|
controller talks an un-understood protocol and some reverse
|
|
enginiering is required. Contact <\*(T<grumbel@gmx.de\*(T>> and include the output
|
|
of:
|
|
.PP
|
|
.nf
|
|
\*(T<$ lsusb \-v\*(T>
|
|
.fi
|
|
.PP
|
|
Along with all the "Unknown data" lines you get.
|
|
.SS "PROGRAM STARTS AND THEN JUST DOES NOTHING"
|
|
This is what the program is supposed to do. After you started it, it
|
|
will give you basically two devices, a new /dev/input/eventX and a
|
|
/dev/input/jsX. You can access and test your controller with jstest
|
|
and evtest applications (available from your distribution or in the
|
|
tools/ subdirectory). Or in case you want just see if your driver is
|
|
working correctly you can pass the -v option:
|
|
.PP
|
|
.nf
|
|
\*(T<$ xboxdrv \-v\*(T>
|
|
.fi
|
|
.PP
|
|
This will cause the driver to output all the events that it received
|
|
from the controller.
|
|
.SS "\(dqERROR: NO STUITABLE UINPUT DEVICE FOUND\(dq"
|
|
Make sure that uinput and joydev kernel modules are loaded. Make sure
|
|
that you have a /dev/input/uinput, /dev/uinput or /dev/misc/uinput and
|
|
permissions to access it.
|
|
.PP
|
|
Before reporting this as a bug make sure you have tested if the driver
|
|
itself works with:
|
|
.PP
|
|
.nf
|
|
\*(T<$ xboxdrv \-\-no\-uinput \-v\*(T>
|
|
.fi
|
|
.SS "THE WIRELESS CONTROLLER DOESN'T WORK"
|
|
You have to sync the controller befor it can be used, restart of the
|
|
driver isn't needed and the driver should let you now when it recieves
|
|
a connection after you sync the controller.
|
|
.SH "KEYBOARD EMULATION"
|
|
When you try to let xboxdrv send a keyboard events
|
|
via \*(T<\fB\-\-ui\-buttonmap\fR\*(T>
|
|
or \*(T<\fB\-\-ui\-axismap\fR\*(T> Xorg must register the device
|
|
as keyboard device to work properly. This seems to work
|
|
automatically when you bind more then two keyboard keys, if you
|
|
bind less you need to create the
|
|
file \*(T<\fI/etc/hal/fdi/preprobe/xboxdrv.fdi\fR\*(T>
|
|
containing:
|
|
.PP
|
|
.nf
|
|
\*(T<
|
|
<?xml version="1.0" encoding="UTF\-8"?>
|
|
<deviceinfo version="0.2">
|
|
<device>
|
|
<match key="input.product" string="Xbox Gamepad (userspace driver) \- Keyboard Emulation">
|
|
<addset key="info.capabilities" type="strlist">input.keys</addset>
|
|
</match>
|
|
</device>
|
|
</deviceinfo>\*(T>
|
|
.fi
|
|
.PP
|
|
This will tell HAL and later Xorg that xboxdrv acts as keyboard.
|
|
.SH "XORG TROUBLE"
|
|
If you start xboxdrv and instead of having a fully working
|
|
joystick, you end up controlling the mouse that might be due to
|
|
recent changes in Xorg and its device hotplug handling. There
|
|
are four workarounds, the one that involves
|
|
editing \*(T<\fI/etc/hal/fdi/policy/preferences.fdi\fR\*(T>
|
|
is the recommont one.
|
|
.SS "TEMPORARY WORKAROUND USING HAL-DEVICE"
|
|
Get the device id from hal:
|
|
.PP
|
|
.nf
|
|
\*(T<$ hal\-find\-by\-property \-\-key 'info.product' \-\-string 'Xbox Gamepad (userspace driver)'\*(T>
|
|
.fi
|
|
.PP
|
|
Then remove the device from hal with:
|
|
.PP
|
|
.nf
|
|
\*(T<$ hal\-device \-r $DEVICEID\*(T>
|
|
.fi
|
|
.SS "TEMPORARY WORKAROUND USING XINPUT"
|
|
Second workaround works with xinput:
|
|
.PP
|
|
.nf
|
|
\*(T<$ xinput list
|
|
$ xinput set\-int\-prop $DEVICEID 'Device Enabled' 32 0\*(T>
|
|
.fi
|
|
.SS "PERMANENT WORKAROUND USING .FDI FILES"
|
|
The former two workarounds are just temporary and have to be redone
|
|
after each start of xboxdrv, the last workaround is a permanent one:
|
|
.PP
|
|
You have to edit:
|
|
.PP
|
|
\*(T<\fI/etc/hal/fdi/policy/preferences.fdi\fR\*(T>
|
|
.PP
|
|
And insert the following lines:
|
|
.PP
|
|
.nf
|
|
\*(T<
|
|
<match key="input.product" string="Xbox Gamepad (userspace driver)">
|
|
<remove key="input.x11_driver" />
|
|
</match>\*(T>
|
|
.fi
|
|
.SS "PERMANENT WORKAROUND BY DISABLING DEVICE AUTO DETECTION"
|
|
A fourth workaround involved disabling the autodetection of Xorg
|
|
completly, you can do that by adding the following lines to
|
|
\*(T<\fI/etc/X11/xorg.conf\fR\*(T>:
|
|
.PP
|
|
.nf
|
|
\*(T<Section "ServerFlags"
|
|
Option "AutoAddDevices" "False"
|
|
EndSection\*(T>
|
|
.fi
|
|
.PP
|
|
Note that without auto detection you will have to manually configure
|
|
all your mice and keyboards or your Xorg Server won't start up
|
|
properly. So unless you are already familiar with editing Xorg you
|
|
better avoid this workaround. Workaround 3) has basically the same
|
|
effect, except that auto detection only gets disabled for the single
|
|
device it is causing problems.
|
|
.SH "WACOM TROUBLE"
|
|
In recent kernels a Wacom graphic tablet creates a joystick device, so
|
|
xboxdrv or any other real joysticks ends up as \*(T<\fI/dev/input/js1\fR\*(T> instead
|
|
of \*(T<\fI/dev/input/js0\fR\*(T>. In many games this causes the joystick to not
|
|
function any more.
|
|
.PP
|
|
A temporary workaround for this is to simply delete the joystick
|
|
device js0 and replace it with a symbolic link js1 via:
|
|
.PP
|
|
.nf
|
|
\*(T<$ sudo ln \-sf /dev/input/js1 /dev/input/js0\*(T>
|
|
.fi
|
|
.PP
|
|
This workaround will only last till the next reboot, since the device
|
|
names are dynamically created, but for the time being there doesn't
|
|
seem to any other way to easily work around this issue.
|
|
.SH "UINPUT TROUBLE"
|
|
On Ubuntu 9.04 the permissions of the uinput device have changed to
|
|
0640, meaning only root has access to the device. To change this back
|
|
so that users in the group root have access the device and in turn can
|
|
run xboxdrv without sudo you have to create a file called:
|
|
.PP
|
|
\*(T<\fI/etc/udev/rules.d/55\-permissions\-uinput.rules\fR\*(T>
|
|
.PP
|
|
With the content:
|
|
.PP
|
|
.nf
|
|
\*(T<KERNEL=="uinput", MODE="0660", GROUP="root"\*(T>
|
|
.fi
|
|
.SH "WINE TROUBLE"
|
|
When using the Xbox360 gamepad in Wine it is not specially handled as
|
|
Xbox360 gamepad, this means games will not display the proper button
|
|
labels, but just numbers (i.e. 'Btn1' instead of 'A' for
|
|
example). Aside from that it should work fine.
|
|
.PP
|
|
XInput support (the DirectInput replacment, not the Xorg xinput)
|
|
is as of August 2010 not implemented in Wine, so games that
|
|
require XInput and don't have an DirectInput fallback will not
|
|
work with a Xbox360 controller, unofficial patches however do exist.
|
|
.SH "FORCE FEEDBACK PROGRAMMING"
|
|
For documentation on the FF interface see:
|
|
.TP 0.2i
|
|
\(bu
|
|
\(lahttp://github.com/github/linux-2.6/blob/f3b8436ad9a8ad36b3c9fa1fe030c7f38e5d3d0b/Documentation/input/ff.txt\(ra
|
|
.TP 0.2i
|
|
\(bu
|
|
\*(T<\fI/usr/include/linux/input.h\fR\*(T>
|
|
.PP
|
|
Additional, non Linux related, force feedback related
|
|
information can be found at:
|
|
.TP 0.2i
|
|
\(bu
|
|
.URL http://www.immersion.com/developer/downloads/ImmFundamentals/HTML/ ""
|
|
.TP 0.2i
|
|
\(bu
|
|
.URL http://msdn.microsoft.com/en-us/library/bb219655(VS.85).aspx ""
|
|
.PP
|
|
\fBfftest\fR is an application you can use to test the force feedback
|
|
interface.
|
|
.PP
|
|
Force feedback is disabed by default since it seems to causes trouble
|
|
in certain application, namely "Tomb Raider: Legend" when run in Wine
|
|
it crashes at startup when rumble is enabled, while it works perfectly
|
|
normal when rumble is disabled.
|
|
.PP
|
|
"Tomb Raider: Anniversary" running in Wine seems to work together with
|
|
xboxdrv and rumble, but hasn't been intensivly tested.
|
|
.SH "WRITING START-UP SCRIPTS FOR GAMES"
|
|
When you want configurability and automatic launching, it is recomment
|
|
that you write little startup scripts for your games, such as this:
|
|
.PP
|
|
.nf
|
|
\*(T<#!/bin/sh
|
|
|
|
# Start xboxdrv and remember its PID in the variable XBOXPID
|
|
xboxdrv \-\-trigger\-as\-button \-s &
|
|
XBOXPID=$!
|
|
|
|
# Give xboxdrv a second to startup and create the device
|
|
sleep 1
|
|
|
|
# Launch your favorite game
|
|
your_favorite_game
|
|
|
|
# Kill xboxdrv and wait for it to finish
|
|
kill $XBOXPID
|
|
wait $XBOXPID
|
|
|
|
# EOF #\*(T>
|
|
.fi
|
|
.PP
|
|
That way you can individually configure every game and not
|
|
have to worry about launching xboxdrv manually.
|
|
.SH BUGS
|
|
X11 keysyms might not work correctly in \*(T<\fB\-\-ui\-buttonmap a=XK_Foobar\fR\*(T>
|
|
when Foobar is mapped to multiple keycodes in the keymap.
|
|
.PP
|
|
Workaround: Use \fBKEY_\fR instead or cleanup your keymap
|
|
.PP
|
|
Force feedback support is brittle, if you Ctrl-c the driver in the
|
|
wrong moment you will end up with a dead uninterruptable process and
|
|
basically have to reboot. This looks like it might be a kernel issue
|
|
and not a xboxdrv one.
|
|
.PP
|
|
Workaround: Kill the app that uses xboxdrv before xboxdrv itself.
|
|
.PP
|
|
Report bugs to Ingo Ruhnke <\*(T<grumbel@gmx.de\*(T>>.
|
|
.SH COPYRIGHT
|
|
Copyright \(co 2010 Ingo Ruhnke <\*(T<grumbel@gmx.de\*(T>>
|
|
License GPLv3+: GNU GPL version 3 or later
|
|
.URL http://gnu.org/licenses/gpl.html ""
|
|
\&. This is free software: you
|
|
are free to change and redistribute it. There is NO WARRANTY,
|
|
to the extent permitted by law.
|
|
.SH "SEE ALSO"
|
|
\fBxboxdrv-daemon\fR(1),
|
|
\fBevtest\fR(1),
|
|
\fBjstest\fR(1),
|
|
\fBxev\fR(1),
|
|
\fBfftest\fR(1),
|
|
\fBlsusb\fR(1)
|