On the Samsung Series 5 Chromebook, the Synaptics ClickPad will sometimes not
send an 0xFA PS/2 ACK in response to a command byte during the reconnect
sequence following a resume from suspend. From our experiments, the failure can
happen during any byte of any of the commands in the reconnect
On Fri, 8 Feb 2013, Benjamin Tissoires wrote:
Hi guys,
so, here is the hid drivers cleanup. The aim is to remove as much as possible
direct calls to usbhid for hid drivers. Thus, other transport layers can use
the existing hid drivers (like I2C or uhid).
Henrik, patches 1 to 5 are yours.
On Sun, 17 Feb 2013, Rafi Rubin wrote:
Looks good, and I can confirm it works fine.
Applied, thanks.
--
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line unsubscribe linux-input in
the body of a message to majord...@vger.kernel.org
More majordomo info at
seems a special change for a special device
so, you may need to place this change with
corresponding CONFIG_xxx_xxx.
generally, if command F2 failed, we will assume
there's no ps2 device, it's normal,
or do you have some materials(SPEC) to specify
the change you have made?
在 2012-10-31三的 18:11
On Mon, 11 Feb 2013, Benjamin Tissoires wrote:
We now have two transport mediums: USB and I2C, where sensor hubs can
exists. So instead of constraining the driver to only these two we let it
to match any HID bus as long as the group is HID_GROUP_SENSOR_HUB.
Signed-off-by: Mika
On Wed, 13 Feb 2013, Ian Abbott wrote:
These are simple data acquistion boards, not HID devices and are handled
by the vmk80xx comedi driver. At least one of them (10cf:5500)
misidentifies itself as a HID in its USB interface descriptor. Ignore
all these devices.
Signed-off-by: Ian
On Mon, 18 Feb 2013, David Herrmann wrote:
The buttons of the Wii Remote Nunchuck extension are actually active low.
Fix the parser to forward the inverted values. The comment in the function
always said 0 == pressed but the implementation was wrong from the
beginning.
Cc:
Yes, I could add CONFIG_MOUSE_PS2_SYNAPTICS for the change as we only
need it for synaptics touchpad/touchpoint on lenovo's machines.
On Mon, Feb 18, 2013 at 5:26 PM, li guang lig.f...@cn.fujitsu.com wrote:
seems a special change for a special device
so, you may need to place this change with
Dmitry Torokhov wrote:
On Fri, Feb 15, 2013 at 03:51:41PM +0200, Kirill A. Shutemov wrote:
Johan Hedberg wrote:
Hi David,
On Fri, Feb 15, 2013, David Herrmann wrote:
On Fri, Feb 15, 2013 at 12:29 PM, Kirill A. Shutemov
kirill.shute...@linux.intel.com wrote:
Hi David and
Am 11.02.2013 11:31, schrieb Mika Westerberg:
We now have two transport mediums: USB and I2C, where sensor hubs can
exists. So instead of constraining the driver to only these two we let it
to match any HID bus as long as the group is HID_GROUP_SENSOR_HUB.
Signed-off-by: Mika Westerberg
On Mon, Feb 18, 2013 at 12:03:04PM +0100, Alexander Holler wrote:
Am 11.02.2013 11:31, schrieb Mika Westerberg:
We now have two transport mediums: USB and I2C, where sensor hubs can
exists. So instead of constraining the driver to only these two we let it
to match any HID bus as long as the
Am 18.02.2013 12:12, schrieb Mika Westerberg:
On Mon, Feb 18, 2013 at 12:03:04PM +0100, Alexander Holler wrote:
Am 11.02.2013 11:31, schrieb Mika Westerberg:
We now have two transport mediums: USB and I2C, where sensor hubs can
exists. So instead of constraining the driver to only these two we
On Mon, Feb 18, 2013 at 12:22:58PM +0100, Alexander Holler wrote:
Am 18.02.2013 12:12, schrieb Mika Westerberg:
On Mon, Feb 18, 2013 at 12:03:04PM +0100, Alexander Holler wrote:
Am 11.02.2013 11:31, schrieb Mika Westerberg:
We now have two transport mediums: USB and I2C, where sensor hubs can
Am 18.02.2013 12:33, schrieb Mika Westerberg:
On Mon, Feb 18, 2013 at 12:22:58PM +0100, Alexander Holler wrote:
Am 18.02.2013 12:12, schrieb Mika Westerberg:
On Mon, Feb 18, 2013 at 12:03:04PM +0100, Alexander Holler wrote:
Am 11.02.2013 11:31, schrieb Mika Westerberg:
We now have two
On Mon, Feb 18, 2013 at 12:37:52PM +0100, Alexander Holler wrote:
Am 18.02.2013 12:33, schrieb Mika Westerberg:
On Mon, Feb 18, 2013 at 12:22:58PM +0100, Alexander Holler wrote:
Am 18.02.2013 12:12, schrieb Mika Westerberg:
On Mon, Feb 18, 2013 at 12:03:04PM +0100, Alexander Holler wrote:
Am
Am 18.02.2013 12:54, schrieb Mika Westerberg:
On Mon, Feb 18, 2013 at 12:37:52PM +0100, Alexander Holler wrote:
Am 18.02.2013 12:33, schrieb Mika Westerberg:
On Mon, Feb 18, 2013 at 12:22:58PM +0100, Alexander Holler wrote:
Am 18.02.2013 12:12, schrieb Mika Westerberg:
On Mon, Feb 18, 2013
On Wed, 13 Feb 2013, Andrew de los Reyes wrote:
Here's the latest version of the patch. I believe it addresses all
outstanding comments.
Thanks!
-andrew
This patch separates struct hid_device's driver_lock into two. The
goal is to allow hid device drivers to receive input during their
Hi Magnus,
2013/2/14 Magnus Damm magnus.d...@gmail.com:
Hi Bastian,
On Fri, Feb 15, 2013 at 2:32 AM, Bastian Hecht hec...@gmail.com wrote:
When registering the interrupt handler we add the IRQF_NO_SUSPEND flag
to save the IRQ line from being disabled during suspension. This way we
keep the
From: Andrew de los Reyes a...@chromium.org
This patch series includes the latest version of the patch to separate
the HID driver lock into two. It also includes the first use of the
new API provided by that patch: a change to the Logitech Unifying
Receiver driver to detect attached peripherals
From: Andrew de los Reyes a...@chromium.org
This patch separates struct hid_device's driver_lock into two. The
goal is to allow hid device drivers to receive input during their
probe() or remove() function calls. This is necessary because some
drivers need to communicate with the device to
From: Andrew de los Reyes a...@chromium.org
This reverts commit 596264082f10dd4a567c43d4526b2f54ac5520bc.
The reverted commit was a workaround needed when drivers became unable
to communicate with devices during probe(). Now that such
communication is possible, the workaround is not needed.
From: Andrew de los Reyes a...@chromium.org
Historically, logitech-dj communicated with the device during probe()
to query the list of devices attached. Later, a change was introduced
to hid-core that prevented incoming packets for a device during
probe(), as many drivers are unable to handle
Hi David,
On Fri, Feb 15, 2013 at 12:46:55PM +0100, David Herrmann wrote:
Hi Kirill
On Fri, Feb 15, 2013 at 12:29 PM, Kirill A. Shutemov
kirill.shute...@linux.intel.com wrote:
Hi David and all,
There's claim in uhid.h that the interface is compatible even between
architectures. But
On Mon, Feb 18, 2013 at 11:28:40AM +0100, Jiri Kosina wrote:
On Fri, 15 Feb 2013, Dmitry Torokhov wrote:
Here's my attempt to fix the issue.
Not sure if tricks with padding in a good idea. We can just use __u64
instead of pointer, but it will require update of userspace to silence
IMS, an In Flight Entertainment System provider, has a number of seat displays
Linux. To interact with the user IMS uses a passenger Control Unit (PCU), which
communicates with Rave Display Unit via a USB interface.
Originally large part of the PCU handling was done from userspace and so it
Entertainment systems used in aircraft need additional keycodes for their
Passenger Control Units, so let's add them.
Signed-off-by: Dmitry Torokhov dmitry.torok...@gmail.com
---
include/uapi/linux/input.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/include/uapi/linux/input.h
The PCU is a device installed in the armrest of a plane seat and
is connected to IMS Rave Entertainment System. It has a set of control
buttons (Volume Up/Down, Attendant, Lights, etc) on one side and
gamepad-like controls on the other side.
Originally the device was handled from userspace and
The IMS PCU (Passenger Control Unit) device used custom protocol over serial
line, so it is presenting itself as CDC ACM device.
Now that we have proper in-kernel driver for it we need to black-list the
device in cdc-acm driver.
Signed-off-by: Dmitry Torokhov dmitry.torok...@gmail.com
---
On Mon, Feb 18, 2013 at 11:05:57AM -0800, Dmitry Torokhov wrote:
The IMS PCU (Passenger Control Unit) device used custom protocol over serial
line, so it is presenting itself as CDC ACM device.
Now that we have proper in-kernel driver for it we need to black-list the
device in cdc-acm
Signed-off-by: Paul Sbarra sbarra.p...@gmail.com
Looks good to me.
Signed-off-by: Simon Wood si...@mungewell.org
--
To unsubscribe from this list: send the line unsubscribe linux-input in
the body of a message to majord...@vger.kernel.org
More majordomo info at
Hi Jiri,
so, here is the hid drivers cleanup. The aim is to remove as much as
possible
direct calls to usbhid for hid drivers. Thus, other transport layers can use
the existing hid drivers (like I2C or uhid).
Henrik, patches 1 to 5 are yours. I just rebased and double-checked them.
Hi Dmitry,
On Sat, Feb 16, 2013 at 12:49 PM, Dmitry Torokhov
dmitry.torok...@gmail.com wrote:
Hi Simon,
On Fri, Feb 15, 2013 at 08:16:12PM -0800, Simon Glass wrote:
+ for (row = 0; row ckdev-rows; row++) {
+ if (cros_ec_keyb_row_has_ghosting(ckdev, buf, row))
+
On Mon, 2013-02-18 at 20:13 -0800, Simon Glass wrote:
On Sat, Feb 16, 2013 at 12:49 PM, Dmitry Torokhov
On Fri, Feb 15, 2013 at 08:16:12PM -0800, Simon Glass wrote:
+ for (row = 0; row ckdev-rows; row++) {
+ if (cros_ec_keyb_row_has_ghosting(ckdev, buf, row))
+
33 matches
Mail list logo