Currently, evdev has working 32bit compatibility and uinput does not. uinput
needs the input_event code that evdev uses, so let's refactor it so it can
be shared.
[dtor@mail.ru: add fix for force feedback compat issues]
Signed-off-by: Philip Langdale <philipl@overt.org>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
This is a pair of Xen para-virtual frontend device drivers:
drivers/video/xen-fbfront.c provides a framebuffer, and
drivers/input/xen-kbdfront provides keyboard and mouse.
The backends run in dom0 user space.
The two drivers are not in two separate patches, because the
intermediate step (one driver, not the other) is somewhat problematic:
the backend in dom0 needs both drivers, and will refuse to complete
device initialization unless they're both present.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
This patch adds a very simple input power event to APM user suspend
event bridge. Its currently only works for the systems using the
emulated APM driver but could easily be extended to work with anything
with a true APM BIOS too.
This covers a standard embedded system need which is to suspend when the
user presses a suspend button. It leaves options open to system
integrators to ignore (or unload) this code and implement their own more
complex event handling system.
Its hidden behind the EMBEDDED Kconfig option since its only likely to
be of use to embedded style systems. It can be built as a module so the
"hardcoded" policy can easily be removed from the kernel at runtime if
desired too.
Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
To work around deficiences in Kconfig that allows to "select"
a symbol without automatically selecting all dependencies for
that symbol move input-polldev from drivers/input/misc to
drivers/input thus removing extra dependency on CONFIG_INPUT_MISC.
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
This will allow concentrating all input devices in one place
in {menu|x|q}config.
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
Delete the never-compiled source file drivers/input/power.c, and
remove its entry from the corresponding Makefile, as there is no
Kconfig file that refers to the config option INPUT_POWER
Signed-off-by: Robert P. J. Day <rpjday@mindspring.com>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
This modifies Makefiles and Kconfigs to properly reflect the creation of
generic HID layer.
It also removes the dependency of BROKEN, which was introduced by the
first patch in series (see the comment). Also updates credits.
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Consolidate core implementing memoryless devices in one module; added
support for gain and envelopes and periodic => rumble conversion.
Signed-off-by: Anssi Hannula <anssi.hannula@gmail.com>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Implement a new force feedback interface, in which all non-driver-specific
operations are separated to a common module. This includes handling effect
type validations, locking, etc.
The effects are now file descriptor specific instead of the previous strange
half-process half-fd specific behaviour. The effect memory of devices is not
emptied if the root user opens and closes the device while another user is
using effects. This is a minor change and most likely no force feedback
aware programs are affected by this negatively.
Otherwise the userspace interface is left unaltered.
Signed-off-by: Anssi Hannula <anssi.hannula@gmail.com>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
This will allow building input core module from several files
which is needed for the reworked force feedback support.
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.
Let it rip!
Philip Langdale