hwdb: add a new db for the DPI/frequency settings of mice
Pointer acceleration for relative input devices (mice, trackballs, etc.)
applies to the deltas of the device. Alas, those deltas have no physical
reference point - a delta of 10 may be caused by a large movement of a
low-dpi mouse or by a minute movement of a high-dpi mouse.
Which makes pointer acceleration a bit useless and high-dpi devices
essentially unusable.
In an ideal world, we could read the DPI from the device directly and work
with that. In the world we actually live in, we need to compile this list
manually. This patch introduces the database, with the usual match formats
and a single property to be set on a device: MOUSE_DPI
That is either a single value for most mice, or a list of values for mice
that can change resolution at runtime. The exact format is detailed in the
hwdb file.
Note that we're explicitly overshooting the requirements we have for
libinput atm. Frequency could be detected in software and we don't
actually use the list of multiple resolutions (because we can't detect
when they change anyway). However, we might as well collect those values
from the get-go, adding/modifying what will eventually amount to hundreds
of entries is a bit cumbersome.
Note: we rely on the input_id builtin to tag us as mouse first, ordering
of the rules is important.
(David: fixed up typos and moved hwdb file into ./hwdb/)
2014-11-25 14:35:16 +03:00
# This file is part of systemd.
#
# Database for the DPI setting of mice, trackballs, other pointer devices that
# cannot be queried directly.
#
# The lookup keys are composed in:
# 70-mouse.rules
#
# Note: The format of the "mouse:" prefix match key is a
# contract between the rules file and the hardware data, it might
# change in later revisions to support more or better matches, it
# is not necessarily expected to be a stable ABI.
#
# Match string format:
# mouse:<subsystem>:v<vid>p<pid>:name:<name>:
#
# Supported subsystems: usb, bluetooth
# vid/pid as 4-digit hex lowercase vendor/product
#
# if vid/pid is unavailable, use
# mouse:*:name:<name>:
# if name is unavailable, use
# mouse:<subsystem>:v<vid>p<pid>:*
#
# For example, the following 5 matches all match the same mouse:
# mouse:usb:v17efp6019:name:Lenovo Optical USB Mouse:
# mouse:usb:*:name:Lenovo Optical USB Mouse:
# mouse:usb:v17efp6019:*
# mouse:*:name:Lenovo Optical USB Mouse:
#
2015-01-09 02:51:40 +03:00
# To add local entries, create a new file
# /etc/udev/hwdb.d/71-mouse-local.hwdb
# and add your rules there. To load the new rules execute (as root):
# udevadm hwdb --update
# udevadm trigger /dev/input/eventXX
# where /dev/input/eventXX is the mouse in question. If in
# doubt, simply use /dev/input/event* to reload all input rules.
#
# If your changes are generally applicable, open a bug report on
# http://bugs.freedesktop.org/enter_bug.cgi?product=systemd
# and include your new rules, a description of the device, and the
# output of
# udevadm info /dev/input/eventXX
# (or /dev/input/event*).
#
# Allowed properties are:
# MOUSE_DPI
# MOUSE_WHEEL_CLICK_ANGLE
#
#########################################
# MOUSE_DPI #
#########################################
#
hwdb: add a new db for the DPI/frequency settings of mice
Pointer acceleration for relative input devices (mice, trackballs, etc.)
applies to the deltas of the device. Alas, those deltas have no physical
reference point - a delta of 10 may be caused by a large movement of a
low-dpi mouse or by a minute movement of a high-dpi mouse.
Which makes pointer acceleration a bit useless and high-dpi devices
essentially unusable.
In an ideal world, we could read the DPI from the device directly and work
with that. In the world we actually live in, we need to compile this list
manually. This patch introduces the database, with the usual match formats
and a single property to be set on a device: MOUSE_DPI
That is either a single value for most mice, or a list of values for mice
that can change resolution at runtime. The exact format is detailed in the
hwdb file.
Note that we're explicitly overshooting the requirements we have for
libinput atm. Frequency could be detected in software and we don't
actually use the list of multiple resolutions (because we can't detect
when they change anyway). However, we might as well collect those values
from the get-go, adding/modifying what will eventually amount to hundreds
of entries is a bit cumbersome.
Note: we rely on the input_id builtin to tag us as mouse first, ordering
of the rules is important.
(David: fixed up typos and moved hwdb file into ./hwdb/)
2014-11-25 14:35:16 +03:00
# DPI settings are specified as
# MOUSE_DPI=<dpi>[@<frequency>]
#
# Where <dpi> is the resolution in dots per inch, and <frequency> the
2015-01-09 00:53:55 +03:00
# sampling frequency in Hz (optional). If a device supports dynamic
# frequency scaling, the maximum frequency should be used. For devices
# supporting multiple fixed frequencies, see below.
hwdb: add a new db for the DPI/frequency settings of mice
Pointer acceleration for relative input devices (mice, trackballs, etc.)
applies to the deltas of the device. Alas, those deltas have no physical
reference point - a delta of 10 may be caused by a large movement of a
low-dpi mouse or by a minute movement of a high-dpi mouse.
Which makes pointer acceleration a bit useless and high-dpi devices
essentially unusable.
In an ideal world, we could read the DPI from the device directly and work
with that. In the world we actually live in, we need to compile this list
manually. This patch introduces the database, with the usual match formats
and a single property to be set on a device: MOUSE_DPI
That is either a single value for most mice, or a list of values for mice
that can change resolution at runtime. The exact format is detailed in the
hwdb file.
Note that we're explicitly overshooting the requirements we have for
libinput atm. Frequency could be detected in software and we don't
actually use the list of multiple resolutions (because we can't detect
when they change anyway). However, we might as well collect those values
from the get-go, adding/modifying what will eventually amount to hundreds
of entries is a bit cumbersome.
Note: we rely on the input_id builtin to tag us as mouse first, ordering
of the rules is important.
(David: fixed up typos and moved hwdb file into ./hwdb/)
2014-11-25 14:35:16 +03:00
#
# The value of MOUSE_DPI is:
# - a single integer for single-resolution mice, e.g.
# MOUSE_DPI=800
# or, if the frequency is known:
# MOUSE_DPI=800@120
# - a space-separated list of resolutions for multi-resolution mice.
2014-12-10 19:41:54 +03:00
# The default resolution must be prefixed by an asterisk, the resolutions
hwdb: add a new db for the DPI/frequency settings of mice
Pointer acceleration for relative input devices (mice, trackballs, etc.)
applies to the deltas of the device. Alas, those deltas have no physical
reference point - a delta of 10 may be caused by a large movement of a
low-dpi mouse or by a minute movement of a high-dpi mouse.
Which makes pointer acceleration a bit useless and high-dpi devices
essentially unusable.
In an ideal world, we could read the DPI from the device directly and work
with that. In the world we actually live in, we need to compile this list
manually. This patch introduces the database, with the usual match formats
and a single property to be set on a device: MOUSE_DPI
That is either a single value for most mice, or a list of values for mice
that can change resolution at runtime. The exact format is detailed in the
hwdb file.
Note that we're explicitly overshooting the requirements we have for
libinput atm. Frequency could be detected in software and we don't
actually use the list of multiple resolutions (because we can't detect
when they change anyway). However, we might as well collect those values
from the get-go, adding/modifying what will eventually amount to hundreds
of entries is a bit cumbersome.
Note: we rely on the input_id builtin to tag us as mouse first, ordering
of the rules is important.
(David: fixed up typos and moved hwdb file into ./hwdb/)
2014-11-25 14:35:16 +03:00
# in the database must be as shipped by the manufacturer. e.g.
# MOUSE_DPI=400 *800 2000
#
# The order of resolutions is as configured by the HW manufacturer or in
# ascending order, whichever appropriate.
#
# The frequency must be given to either none or all resolutions. If the
2015-01-09 00:53:55 +03:00
# device supports multiple fixed frequencies, the order of items is
hwdb: add a new db for the DPI/frequency settings of mice
Pointer acceleration for relative input devices (mice, trackballs, etc.)
applies to the deltas of the device. Alas, those deltas have no physical
reference point - a delta of 10 may be caused by a large movement of a
low-dpi mouse or by a minute movement of a high-dpi mouse.
Which makes pointer acceleration a bit useless and high-dpi devices
essentially unusable.
In an ideal world, we could read the DPI from the device directly and work
with that. In the world we actually live in, we need to compile this list
manually. This patch introduces the database, with the usual match formats
and a single property to be set on a device: MOUSE_DPI
That is either a single value for most mice, or a list of values for mice
that can change resolution at runtime. The exact format is detailed in the
hwdb file.
Note that we're explicitly overshooting the requirements we have for
libinput atm. Frequency could be detected in software and we don't
actually use the list of multiple resolutions (because we can't detect
when they change anyway). However, we might as well collect those values
from the get-go, adding/modifying what will eventually amount to hundreds
of entries is a bit cumbersome.
Note: we rely on the input_id builtin to tag us as mouse first, ordering
of the rules is important.
(David: fixed up typos and moved hwdb file into ./hwdb/)
2014-11-25 14:35:16 +03:00
# MOUSE_DPI=r1@f1 r2@f1 r3@f1 r1@f2 r2@f2 r3@f2
#
# If the default manufacturer-set resolution is unclear, a resolution of
# 800 or 1000 should be set as default, if available. If neither is
# available, choose the "middle" resolution value of those available.
#
# The list may contain a single item which must be marked with an
# asterisk.
#
# Local changes to the a non-default resolution of the mouse (e.g. through
# third-party software) must not be entered into this file, use a local
# hwdb instead.
#
2015-01-09 02:51:40 +03:00
#########################################
# MOUSE_WHEEL_CLICK_ANGLE #
#########################################
#
# The angle in degrees per mouse wheel 'click', specified as
# MOUSE_WHEEL_CLICK_ANGLE=<degrees>
#
# Most mice have a 15 degree click stop (24 clicks per full rotation).
hwdb: add a new db for the DPI/frequency settings of mice
Pointer acceleration for relative input devices (mice, trackballs, etc.)
applies to the deltas of the device. Alas, those deltas have no physical
reference point - a delta of 10 may be caused by a large movement of a
low-dpi mouse or by a minute movement of a high-dpi mouse.
Which makes pointer acceleration a bit useless and high-dpi devices
essentially unusable.
In an ideal world, we could read the DPI from the device directly and work
with that. In the world we actually live in, we need to compile this list
manually. This patch introduces the database, with the usual match formats
and a single property to be set on a device: MOUSE_DPI
That is either a single value for most mice, or a list of values for mice
that can change resolution at runtime. The exact format is detailed in the
hwdb file.
Note that we're explicitly overshooting the requirements we have for
libinput atm. Frequency could be detected in software and we don't
actually use the list of multiple resolutions (because we can't detect
when they change anyway). However, we might as well collect those values
from the get-go, adding/modifying what will eventually amount to hundreds
of entries is a bit cumbersome.
Note: we rely on the input_id builtin to tag us as mouse first, ordering
of the rules is important.
(David: fixed up typos and moved hwdb file into ./hwdb/)
2014-11-25 14:35:16 +03:00
#
2014-12-13 02:16:45 +03:00
#
2015-04-23 04:10:04 +03:00
# Sort by brand, type (usb, bluetooth), DPI, frequency.
2014-12-13 02:16:45 +03:00
# For mice with switchable resolution, sort by the starred entry.
2015-06-04 09:05:08 +03:00
##########################################
# Apple
##########################################
# Apple MagicMouse
# Note: this device changes name once connected to a mac, the name ends up
# as $username`s mouse
mouse:bluetooth:v05acp030d:name:*:
MOUSE_DPI=1300@1000
2014-12-31 02:54:24 +03:00
##########################################
# Chicony
##########################################
# Chicony 2.4G Multimedia Wireless Kit MG-0919
mouse:usb:v04f2p0963:name:Chicony 2.4G Multimedia Wireless Kit:
MOUSE_DPI=1000@142
2014-12-08 02:17:26 +03:00
##########################################
# Dell
##########################################
# Dell USB Laser Mouse
mouse:usb:v046dpc063:name:DELL DELL USB Laser Mouse:
MOUSE_DPI=1000@125
2014-12-31 03:03:39 +03:00
##########################################
# Fujitsu Siemens
##########################################
mouse:usb:v0461p4d16:name:USB Optical Mouse:
MOUSE_DPI=500@125
2015-04-23 03:44:30 +03:00
##########################################
# HP
##########################################
# HP X1000
mouse:usb:v093ap2510:name:PixArt USB Optical Mouse:
MOUSE_DPI=1000@125
hwdb: add a new db for the DPI/frequency settings of mice
Pointer acceleration for relative input devices (mice, trackballs, etc.)
applies to the deltas of the device. Alas, those deltas have no physical
reference point - a delta of 10 may be caused by a large movement of a
low-dpi mouse or by a minute movement of a high-dpi mouse.
Which makes pointer acceleration a bit useless and high-dpi devices
essentially unusable.
In an ideal world, we could read the DPI from the device directly and work
with that. In the world we actually live in, we need to compile this list
manually. This patch introduces the database, with the usual match formats
and a single property to be set on a device: MOUSE_DPI
That is either a single value for most mice, or a list of values for mice
that can change resolution at runtime. The exact format is detailed in the
hwdb file.
Note that we're explicitly overshooting the requirements we have for
libinput atm. Frequency could be detected in software and we don't
actually use the list of multiple resolutions (because we can't detect
when they change anyway). However, we might as well collect those values
from the get-go, adding/modifying what will eventually amount to hundreds
of entries is a bit cumbersome.
Note: we rely on the input_id builtin to tag us as mouse first, ordering
of the rules is important.
(David: fixed up typos and moved hwdb file into ./hwdb/)
2014-11-25 14:35:16 +03:00
##########################################
# Lenovo
##########################################
2014-12-08 02:17:26 +03:00
# Lenovo Optical USB Mouse
hwdb: add a new db for the DPI/frequency settings of mice
Pointer acceleration for relative input devices (mice, trackballs, etc.)
applies to the deltas of the device. Alas, those deltas have no physical
reference point - a delta of 10 may be caused by a large movement of a
low-dpi mouse or by a minute movement of a high-dpi mouse.
Which makes pointer acceleration a bit useless and high-dpi devices
essentially unusable.
In an ideal world, we could read the DPI from the device directly and work
with that. In the world we actually live in, we need to compile this list
manually. This patch introduces the database, with the usual match formats
and a single property to be set on a device: MOUSE_DPI
That is either a single value for most mice, or a list of values for mice
that can change resolution at runtime. The exact format is detailed in the
hwdb file.
Note that we're explicitly overshooting the requirements we have for
libinput atm. Frequency could be detected in software and we don't
actually use the list of multiple resolutions (because we can't detect
when they change anyway). However, we might as well collect those values
from the get-go, adding/modifying what will eventually amount to hundreds
of entries is a bit cumbersome.
Note: we rely on the input_id builtin to tag us as mouse first, ordering
of the rules is important.
(David: fixed up typos and moved hwdb file into ./hwdb/)
2014-11-25 14:35:16 +03:00
mouse:usb:v17efp6019:name:Lenovo Optical USB Mouse:
MOUSE_DPI=1000@125
2014-12-10 19:38:47 +03:00
# ThinkPad USB Laser Mouse
mouse:usb:v17efp6044:name:ThinkPad USB Laser Mouse:
MOUSE_DPI=1200@125
hwdb: add a new db for the DPI/frequency settings of mice
Pointer acceleration for relative input devices (mice, trackballs, etc.)
applies to the deltas of the device. Alas, those deltas have no physical
reference point - a delta of 10 may be caused by a large movement of a
low-dpi mouse or by a minute movement of a high-dpi mouse.
Which makes pointer acceleration a bit useless and high-dpi devices
essentially unusable.
In an ideal world, we could read the DPI from the device directly and work
with that. In the world we actually live in, we need to compile this list
manually. This patch introduces the database, with the usual match formats
and a single property to be set on a device: MOUSE_DPI
That is either a single value for most mice, or a list of values for mice
that can change resolution at runtime. The exact format is detailed in the
hwdb file.
Note that we're explicitly overshooting the requirements we have for
libinput atm. Frequency could be detected in software and we don't
actually use the list of multiple resolutions (because we can't detect
when they change anyway). However, we might as well collect those values
from the get-go, adding/modifying what will eventually amount to hundreds
of entries is a bit cumbersome.
Note: we rely on the input_id builtin to tag us as mouse first, ordering
of the rules is important.
(David: fixed up typos and moved hwdb file into ./hwdb/)
2014-11-25 14:35:16 +03:00
##########################################
# Logitech
##########################################
2014-12-08 02:17:26 +03:00
# Note: devices using the Logitech Unifying receiver will need two entries,
# one for pre 3.19 with the wireless PID in the name, one for 3.19 with the
# model name. The usb vid/pid is the same for all those devices.
# Until 3.19 is available, this list just has the Wireless PID entry.
2014-12-13 02:20:51 +03:00
# Logitech M-BJ58 Optical Mouse
mouse:usb:v046dpc00e:name:Logitech USB-PS/2 Optical Mouse:
# Logitech MX310 Optical Mouse
mouse:usb:v046dpc01b:name:Logitech USB-PS/2 Optical Mouse:
2014-12-13 02:16:45 +03:00
# Logitech USB-PS/2 M-BT58
mouse:usb:v046dpc03e:name:Logitech USB-PS/2 Optical Mouse:
MOUSE_DPI=400@125
2014-12-22 01:18:55 +03:00
# Lenovo USB mouse model MO28UOL
mouse:usb:v04b3p310c:name:USB Optical Mouse:
MOUSE_DPI=400@142
2014-12-13 02:16:45 +03:00
# Logitech USB-PS/2 M-BZ96C
mouse:usb:v046dpc045:name:Logitech USB-PS/2 Optical Mouse:
MOUSE_DPI=600@125
2015-01-05 00:41:03 +03:00
# Logitech Wireless Mouse M325
2014-12-13 02:16:45 +03:00
mouse:usb:v046dpc52b:name:Logitech Unifying Device. Wireless PID:400a:
MOUSE_DPI=600@166
2015-01-16 04:11:10 +03:00
MOUSE_WHEEL_CLICK_ANGLE=20
2014-12-08 02:17:26 +03:00
2014-12-16 08:08:07 +03:00
# Logitech MX1000 Laser Cordless Mouse
mouse:usb:v046dpc50e:name:Logitech USB RECEIVER:
2014-12-08 02:17:26 +03:00
# Logitech Cordless Click! Plus
mouse:usb:v046dpc50e:name:Logitech USB Receiver:
2014-12-19 02:40:44 +03:00
# Logitech, Inc. RX 300 Optical Mouse
mouse:usb:v046dpc040:name:Logitech USB-PS/2 Optical Mouse:
2014-12-08 02:17:26 +03:00
MOUSE_DPI=800@125
2014-12-15 13:26:38 +03:00
# Logitech MX 518
mouse:usb:v046dpc01e:name:Logitech USB-PS/2 Optical Mouse:
MOUSE_DPI=400@125 *800@125 1600@125
2015-01-09 00:45:34 +03:00
# Logitech, Inc. RX 250 Optical Mouse
mouse:usb:v046dpc050:name:Logitech USB-PS/2 Optical Mouse:
MOUSE_DPI=800@142
2015-01-07 11:23:37 +03:00
# Logitech G400 (Wired)
mouse:usb:v046dpc245:name:Logitech Gaming Mouse G400:
MOUSE_DPI=400@1000 *800@1000 1800@1000 3600@1000
2015-01-09 02:33:27 +03:00
2014-12-15 19:15:16 +03:00
# Logitech G400s (Wired)
mouse:usb:v046dpc24c:name:Logitech G400s Optical Gaming Mouse:
MOUSE_DPI=400@1000 *800@1000 2000@1000 4000@1000
2015-05-08 04:56:45 +03:00
# Logitech M570 trackball
mouse:usb:v046dp1028:name:Logitech M570:
MOUSE_DPI=540@167
2014-12-13 02:16:45 +03:00
# Logitech Wireless Mouse M185
mouse:usb:v046dpc52b:name:Logitech Unifying Device. Wireless PID:4008:
# Logitech M705 (marathon mouse)
mouse:usb:v046dpc52b:name:Logitech Unifying Device. Wireless PID:101b:
MOUSE_DPI=800@166
2015-03-05 13:29:56 +03:00
# Logitech G5 Laser Mouse
mouse:usb:v046dpc049:name:Logitech USB Gaming Mouse:
2014-12-08 02:17:26 +03:00
# Logitech G500s Laser Gaming Mouse
hwdb: add a new db for the DPI/frequency settings of mice
Pointer acceleration for relative input devices (mice, trackballs, etc.)
applies to the deltas of the device. Alas, those deltas have no physical
reference point - a delta of 10 may be caused by a large movement of a
low-dpi mouse or by a minute movement of a high-dpi mouse.
Which makes pointer acceleration a bit useless and high-dpi devices
essentially unusable.
In an ideal world, we could read the DPI from the device directly and work
with that. In the world we actually live in, we need to compile this list
manually. This patch introduces the database, with the usual match formats
and a single property to be set on a device: MOUSE_DPI
That is either a single value for most mice, or a list of values for mice
that can change resolution at runtime. The exact format is detailed in the
hwdb file.
Note that we're explicitly overshooting the requirements we have for
libinput atm. Frequency could be detected in software and we don't
actually use the list of multiple resolutions (because we can't detect
when they change anyway). However, we might as well collect those values
from the get-go, adding/modifying what will eventually amount to hundreds
of entries is a bit cumbersome.
Note: we rely on the input_id builtin to tag us as mouse first, ordering
of the rules is important.
(David: fixed up typos and moved hwdb file into ./hwdb/)
2014-11-25 14:35:16 +03:00
mouse:usb:v046dpc24e:name:Logitech G500s Laser Gaming Mouse:
MOUSE_DPI=400@500 *800@500 2000@500
2014-12-08 02:17:26 +03:00
2014-12-13 02:16:45 +03:00
# Logitech B605 Wireless Mouse (also M505)
mouse:usb:v046dpc52b:name:Logitech Unifying Device. Wireless PID:101d:
MOUSE_DPI=900@166
2014-12-13 02:20:51 +03:00
# Logitech RX1000 Laser Mouse
mouse:usb:v046dpc046:name:Logitech USB Optical Mouse:
# Logitech M100 Optical Mouse
2014-12-13 02:16:45 +03:00
mouse:usb:v046dpc05a:name:Logitech USB Optical Mouse:
2014-12-31 16:28:52 +03:00
# Logitech USB Laser Mouse M-U0011-O rebranded as "terra Laser"
mouse:usb:v046dpc065:name:Logitech USB Laser Mouse:
2014-12-13 02:16:45 +03:00
MOUSE_DPI=1000@125
2014-12-31 02:56:16 +03:00
# Logitech MK260 Wireless Combo Receiver aka M-R0011
mouse:usb:v046dpc52e:name:Logitech USB Receiver:
MOUSE_DPI=1000@200
2014-12-08 02:17:26 +03:00
# Logitech G700 Laser Mouse (Wired)
mouse:usb:v046dpc06b:name:Logitech G700 Laser Mouse:
# Logitech G700 Laser Mouse (Wireless)
mouse:usb:v046dpc531:name:Logitech USB Receiver:
MOUSE_DPI=*1000@500 3800@500 500@1000 1500@1000 2000@1000
2014-12-31 03:07:28 +03:00
# Logitech USB Laser Mouse M-UAS144 [LS1 Laser Mouse]
mouse:usb:v046dpc062:name:Logitech USB Laser Mouse:
2015-01-09 22:28:32 +03:00
# Logitech USB Laser Mouse M-U0007
mouse:usb:v046dpc069:name:Logitech USB Laser Mouse:
2014-12-31 03:07:28 +03:00
MOUSE_DPI=1200@125
2014-12-08 02:17:26 +03:00
# Logitech T620 (or, the soap)
mouse:usb:v046dpc52b:name:Logitech Unifying Device. Wireless PID:4027:
MOUSE_DPI=1200@250
2014-12-13 02:16:45 +03:00
# Logitech ZoneTouch Mouse T400
mouse:usb:v046dpc52b:name:Logitech Unifying Device. Wireless PID:4026:
MOUSE_DPI=1300@166
2014-12-10 17:46:08 +03:00
2014-12-08 02:17:26 +03:00
# Logitech Ultrathin Touch Mouse
mouse:bluetooth:v046dpb00d:name:Ultrathin Touch Mouse:
MOUSE_DPI=1000@1000
2014-12-23 03:14:19 +03:00
# ImExPS/2 Logitech Wheel Mouse
mouse:ps2:*:name:ImExPS/2 Logitech Wheel Mouse:
MOUSE_DPI=400@250
2014-12-08 02:17:26 +03:00
##########################################
# Microsoft
##########################################
2015-02-16 19:14:20 +03:00
mouse:usb:v045ep0040:name:Microsoft Microsoft 3-Button Mouse with IntelliEye(TM):
2015-02-14 22:37:40 +03:00
MOUSE_DPI=400@125
2014-12-11 10:33:14 +03:00
# Note: unsure that these work, it's likely that all devices on these
# receivers show up with the same vid/pid/name
# Microsoft Sculpt Ergonomic Mouse
mouse:usb:v045ep07a5:name:Microsoft Microsoft® 2.4GHz Transceiver v9.0:
MOUSE_DPI=1000@142
2014-12-08 02:17:26 +03:00
# Microsoft Arc Touch Mouse USB
mouse:usb:v045ep07b1:name:Microsoft Microsoft® Nano Transceiver v1.0:
MOUSE_DPI=1400@142
2014-12-24 00:53:40 +03:00
# Microsoft Wireless Laser Mouse 8000
mouse:bluetooth:v045ep0702:name:Microsoft Wireless Laser Mouse 8000:
MOUSE_DPI=1000@1000
2015-05-21 08:39:11 +03:00
# Microsoft Arc Touch Mouse SE:
mouse:bluetooth:v045ep07f3:name:Arc Touch Mouse SE:
MOUSE_DPI=1000@2000
2014-12-08 02:17:26 +03:00
##########################################
# Oklick
##########################################
2014-12-26 02:20:48 +03:00
# Oklick 406S Bluetooth Laser Mouse
2014-12-08 02:17:26 +03:00
mouse:bluetooth:v056ep0061:name:Laser BTmouse:
MOUSE_DPI=*800@333 1600@333
2014-12-26 02:20:48 +03:00
##########################################
# Razer
##########################################
# Razer Abyssus
mouse:usb:v1532p0042:name:Razer Razer Abyssus:
MOUSE_DPI=3500@1000
2015-04-03 23:20:55 +03:00
##########################################
# Roccat
##########################################
# Roccat Lua (ROC-11-310)
mouse:usb:v1e7dp2c2e:name:ROCCAT ROCCAT Lua:
MOUSE_DPI=250@125 500@125 1000@125 1250@125 1500@125 1750@125 2000@125 250@250 500@250 1000@250 1250@250 1500@250 1750@250 2000@250 250@500 500@500 1000@500 1250@500 1500@500 1750@500 2000@500 250@1000 500@1000 *1000@1000 1250@1000 1500@1000 1750@1000 2000@1000
MOUSE_WHEEL_CLICK_ANGLE=15
