| Commit message (Collapse) | Author | Age |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Leaving the fd open means we still get keyboard events after VT switching
away. Coming back, some of these events are replayed on the application that
has the current focus.
Reproduceable:
1. open terminal, focus.
2. VT switch away
3. type something, preferably a password
4. VT switch back, trigger a mouse event
5. Observe the X server guessing your password.
Closing the fd on DEVICE_OFF fixes this. Reopen is handled by the reopen
code introduced with
commit 9930477cbeb4acfd070ae70894d13ffabfc347b8
Author: Peter Hutterer <peter.hutterer@redhat.com>
Date: Tue Aug 26 14:33:40 2008 +0930
Attempt to re-open devices on read errors.
Launchpad Bug 276887
<https://bugs.edge.launchpad.net/ubuntu/+source/xorg-server/+bug/276887>
(cherry picked from commit ccd48d2f50231e2837e0984833641ac79f327ba4)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Coming back from resume may leave us with a file descriptor that can be opened
but fails on the first read (ENODEV).
In this case, try to open the device until it becomes available or until the
predefined count expires. To be safe, we cache the information from the device
and compare against it when we re-open. This way we ensure that if the
topology changes under us, we don't open a completely different device. If a
device has changed, we disable it.
Adds option "ReopenAttempts" <int>
Conflicts:
man/evdev.man
src/evdev.c
src/evdev.h
|
| |
|
|
|
|
|
|
|
|
| |
Keycodes over 255 are silently ignored in the server. The least we can do is
put a warning in the logs.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit c1f7f8c3d22ecae7839f82ea8b584069f54f1f5e)
|
|
|
|
|
|
|
| |
Fixes file descriptor leak.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit d9097df01b01afaf946fa04fca8ae8ab7108ff21)
|
|
|
|
| |
(cherry picked from commit 5c074af5a9abba138023e3bc6954d1062f7c36dd)
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
With this fix, on my PowerBook HAL hotplugging correctly detects my USB mouse,
and no longer thinks keyboards have random numbers of mouse buttons. :)
The LONG_BITS and NBITS macro definitions are stolen from xf86-input-synaptics.
Signed-off-by: Michel Dänzer <michel@tungstengraphics.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
[cherry-picked from master and fixed the trivial conflict -- jcristau]
|
|
|
|
|
|
| |
Report correct versions instead of
"compiled for 0.0.0, module version = 1.0.0"
(cherry picked from commit 2b7edaa4ab88e192d7285d39b4834d1e535b94d0)
|
| |
|
|
|
|
|
|
|
|
| |
After suspend/resume, sometimes the device doesn't come back up on the same
node. Since we do not call PreInit for the device (which would detect this
situation), we continue to try to read a nonexisting file, spamming the log
file with "Read Error".
(cherry picked from commit bf0d81011e19a8bb5bbd80c6b496c8ae257b4f2c)
|
|
|
|
| |
(cherry picked from commit ef4bb69c1a64e784fef1c758ee439372ba329b0a)
|
|
|
|
|
| |
Hook taken from xserver's Makefile.am
(cherry picked from commit ec23c6b2f550f2679226da907c1d022295d453f1)
|
|
|
|
|
|
|
| |
greater than BTN_TASK.
Signed-off-by: Peter Hutterer <peter@cs.unisa.edu.au>
(cherry picked from commit 0830676a0ce3618eae9cf4c072998c16e164c687)
|
| |
|
|
|
|
|
| |
Follow-up to 76800bfa75807e49398380b902f6c0f547cd4c0e.
(cherry picked from commit 5a0ea39b79b27b7c3117661a21e7ab5eba3c9b24)
|
|
|
|
|
| |
Signed-off-by: Peter Hutterer <peter@cs.unisa.edu.au>
(cherry picked from commit 373e13ae353d1e0022f8821adc528ebc5411d47d)
|
|
|
|
|
|
|
|
|
| |
This ensures that the middle button emulation is re-enabled after VT switch,
otherwise the block handler that deals with the timeouts would not get
re-registered.
Signed-off-by: Keith Packard <keithp@keithp.com>
(cherry picked from commit 76800bfa75807e49398380b902f6c0f547cd4c0e)
|
| |
|
| |
|
|
|
|
|
| |
This avoids segfaults when HAL is restarted behind our backs. Also, only init
MB emulation when the device actually has a button.
|
|
|
|
| |
1.99.3 had a nasty bug, so here's a quick update.
|
|
|
|
|
|
| |
Default setting is still "on" until middle button is pressed. If the options
is however explicitly stated in the config file, it takes the value from the
config file, no matter if a middle button is present.
|
|
|
|
| |
Less SIGABRTs are less exciting, but sometimes boredom is what we want.
|
| |
|
|
|
|
|
|
| |
Devices may report middle mouse buttons even if they don't have one (PS/2
devices just don't know any better), so we can't be sure until we see the
event.
|
|
|
|
| |
Ported from xf86-input-mouse, with a few cleanups.
|
| |
|
|
|
|
|
|
|
|
|
| |
The commit b4a5a204 fixed an issue, where we can't move the pointer to
other screens and this happens in current master branch again. This commit
ports the old commit to the current master branch.
Signed-off-by: Sven Wegener <swegener@gentoo.org>
Signed-off-by: Peter Hutterer <peter@cs.unisa.edu.au>
|
|
|
|
| |
Thanks to Sven Wegener for pointing out the incorrect previous version.
|
|
|
|
|
|
|
| |
GetMotionEvents() doesn't exist, led to compile errors with servers pre-MPX
merge. Thanks to Sven Wegener for pointing this out.
This reverts commit 42422d8f69e6806e1adfd93017cac064a75041c7.
|
| |
|
|
|
|
|
|
|
|
|
| |
If the grab fails, this is most likely a sign that the device has been grabbed
already (probably by a device specified in xorg.conf). So let's not add the
device to the server's input device list, since it won't generate events
anyway.
Exception: keyboards and kernel 2.4 are not affected.
|
| |
|
|
|
|
| |
Signed-off-by: Peter Hutterer <peter@cs.unisa.edu.au>
|
| |
|
|
|
|
|
|
|
| |
In the mouse driver, these options are only used if XFree86LOADER is
undefined. configure.ac in the xserver forces said define to 1 if we're
building the xfree86 DDX, so I don't see the point of having them around.
Especially since they weren't used in evdev anyway.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a bit of a mess. The MS Optical Desktop 2000 registers both relative
and absolute axes on the same device (the mouse). The absolute axes have a
valid min/max range for x/y and thus overwrite the x/y relative axes in the
server (no, this is not a server bug). And I wouldn't be surprised if other
devices have similar issues.
Since the device only sends relative events after that, the mouse is
essentially restricted to the min..max range of 0..255. The server simply
doesn't do unrestricted relative axis and restricted absolute axis on the same
device (not for the same axis numbers anyway).
|
|
|
|
| |
Stopps meta/super key from autorepeating
|
|
|
|
| |
Pretty much dead code anyway.
|
|
|
|
|
| |
Some Microsoft mice have this wrong. And it seems like a sensible thing
to do anyway.
|
|
|
|
|
|
|
|
| |
Not many mice do this, but some do, Apple Mighty Mouse in particular, and
it makes click-and-drag pretty much impossible to use.
Arguably we should filter _all_ repeat events from the kernel and handle
synthesizing them in the server.
|
|
|
|
|
|
| |
Don't do this in the button map. That's writeable by clients, which means
they have the chance to get it wrong. Just swap right and middle around
in event dispatch before you get to the user's map.
|
|
|
|
|
| |
Or at least, refuse to recognise the config option. It's nonsensical to
use a model of something other than evdev, and it'll just break if you try.
|
|
|
|
| |
Fixes 2b334d6b69d7dde5d553c638e134ebdf974749f3.
|
| |
|
| |
|