On Fri, 2015-11-20 at 11:00 +0100, Jiri Kosina wrote:
> On Thu, 5 Nov 2015, Oliver Neukum wrote:
>
> > If an event is discarded the device stays idle.
> > Just reverse the order of check and marking busy.
> >
> > Signed-off-by: Oliver Neukum <oneu...@suse
On Mon, 2015-11-23 at 18:37 +0100, Adrien Vergé wrote:
> > Makes one wonder however whether we shouldn't be applying
> ALWAYS_POLL to
> > all ELAN devices by default anyway.
>
> True! But I don't want to risk breaking anything on other models in
> this patch.
ALWAYS_POLL just extends an existing
If an event is discarded the device stays idle.
Just reverse the order of check and marking busy.
Signed-off-by: Oliver Neukum <oneu...@suse.com>
---
drivers/hid/usbhid/hid-core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hid/usbhid/hid-core.c b/drive
On Tue, 2015-09-22 at 11:22 -0400, Alan Stern wrote:
> On Tue, 22 Sep 2015, Oliver Neukum wrote:
>
> > Cancel, yes, going to low power is a consequence which needn't bother
> > the power subsystem.
>
> Going to low power needn't involve the power subsystem? That
On Tue, 2015-09-22 at 10:15 -0400, Alan Stern wrote:
> On Tue, 22 Sep 2015, Oliver Neukum wrote:
>
> > Indeed. We can handle output to suspended devices by waking them.
> > I don't see why this case is different. We are talking about input
> > only.
> >
>
On Mon, 2015-09-21 at 16:02 -0400, Alan Stern wrote:
> On Mon, 21 Sep 2015, Dmitry Torokhov wrote:
>
> > > What happens if the "inhibit" control is turned on and the driver puts
> > > the device into runtime suspend, but then an I/O request arrives?
> > >
> > > If the I/O request originated
On Wed, 2015-09-09 at 22:25 +0200, Rafael J. Wysocki wrote:
> > >
> > > I'd doubt that. Suppose you put the phone into your pocket while
> > > the device isn't suspended. The continuous stream of spurious
> events
> > > will keep it awake.
>
> Why would they be regarded as spurious then? They
On Tue, 2015-09-08 at 10:44 -0400, Alan Stern wrote:
> It would not put the device into runtime suspend immediately, like you
> are proposing. Instead it would mean the same as the "auto" mode,
> except that remote wakeup should be disabled during runtime suspend.
Hi,
this proposal is
On Wed, 2015-09-09 at 14:22 +0200, Rafael J. Wysocki wrote:
> > Note that when the screen is turned-on again, we want to resume the
> > touchscreen so that it can send events again.
Why is it impractical to close the fd for the touchscreen?
>
> In fact, then, what you need seems to be the
On Tue, 2015-09-08 at 01:10 +, Tirdea, Irina wrote:
> However, in the scenario I mentioned this is exactly what is happening.
> When turning off the screen of a mobile device, the user space
Would you explain why user space doesn't simply stop using those
devices, which in turn will make
On Mon, 2015-07-20 at 23:03 +0200, Yann Cantin wrote:
Signed-off-by: Yann Cantin yann.can...@laposte.net
---
Documentation/ABI/testing/sysfs-driver-ebeam | 53 ++
drivers/input/misc/Kconfig | 22 +
drivers/input/misc/Makefile | 1 +
On Mon, 2015-06-29 at 13:16 +0200, Jiri Kosina wrote:
On Mon, 29 Jun 2015, Oliver Neukum wrote:
Last time we were testing this, autosuspend for USB HID devices was quite
a disaster.
Do you have any idea whether udev developers tested the autosuspend on
by
default for USB
On Sat, 2015-06-27 at 08:29 +0200, Jiri Kosina wrote:
On Fri, 26 Jun 2015, Greg Kroah-Hartman wrote:
Last time we were testing this, autosuspend for USB HID devices was quite
a disaster.
Do you have any idea whether udev developers tested the autosuspend on by
default for USB HID devices
On Wed, 2015-05-13 at 13:25 +0200, Jiri Kosina wrote:
On Tue, 12 May 2015, Laura Abbott wrote:
Like other KVM switches, the Aten DVI KVM switch needs a
quirk to avoid spewing errors:
[791759.606542] usb 1-5.4: input irq status -75 received
[791759.614537] usb 1-5.4: input irq status
When usbhid closes a device which was awake only because remote
wakeup was required but not provided, the interface must go through
a get/put cycle or the core will never reattempt to suspend the device.
This brakes runtime PM for all joysticks.
Signed-off-by: Oliver Neukum oneu...@suse.de
Hi,
I found a problem with the close() function of usbhid.
It fails to properly suspend device that don't support
remote wake-up. The power core does not retry an autosuspend
that failed due to a lack of support for remote wake-up.
So there needs to be a _put() if the need for remote wake-up
is
Replace old pr_* with dev_* debugging macros
Signed-off-by: Oliver Neukum oneu...@suse.de
---
drivers/input/ff-core.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/input/ff-core.c b/drivers/input/ff-core.c
index f50f6dd..b81c88c 100644
--- a/drivers/input
On Thu, 2015-04-02 at 14:26 +0200, Jiri Kosina wrote:
On Wed, 1 Apr 2015, Oliver Neukum wrote:
I am postponing all these before it is clarified that this is indeed a
case reporter is able to reproduce on different system as well to rule
out
the possibility of hub being the actual
There is a typo in a device ID
Signed-off-by: Oliver Neukum oneu...@suse.de
CC: sta...@vger.kernel.org
---
drivers/hid/hid-ids.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 56a4ed6..4ee0fb0 100644
--- a/drivers/hid/hid
Hi,
please don't apply them. There's a typo in an ID.
I'll resubmit.
Regards
Oliver
--
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,
I am getting reports from a customer running an unintentional
stress test for this quirk. I would have to add a dozen mice
in the medium term. Is that desirable?
Should we make the quirk the default? Or add a module parameter
to let the pessimistic users with multiple desktop rodents
select
On Thu, 2015-03-26 at 10:06 -0400, Benjamin Tissoires wrote:
On Thu, Mar 26, 2015 at 7:44 AM, Oliver Neukum oneu...@suse.de wrote:
Hi,
I would like to kill drivers/hid/hid-ids.h and replace it
with numerical IDs in the files using it.
There are two reasons for that.
1
On Fri, 2015-03-27 at 09:49 +0100, Oliver Neukum wrote:
On Thu, 2015-03-26 at 10:06 -0400, Benjamin Tissoires wrote:
Well, yes, so you needed to grep for MULTI_INPUT. The entries would
still have been present, just with nummerical IDs.
Especially as I see stuff like this:
0c3910c255
On Fri, 2015-03-27 at 09:18 -0400, Benjamin Tissoires wrote:
On Fri, Mar 27, 2015 at 5:29 AM, Oliver Neukum oneu...@suse.de wrote:
Hi,
I am getting reports from a customer running an unintentional
stress test for this quirk. I would have to add a dozen mice
in the medium term
Hi,
I would like to kill drivers/hid/hid-ids.h and replace it
with numerical IDs in the files using it.
There are two reasons for that.
1. It is a layering violation. There should not be a private
data base for USB IDs in HID.
2. It serves no purpose and adds work. Anyone who adds a quirk
or a
On Mon, 2015-03-16 at 22:37 +0100, Jiri Kosina wrote:
On Mon, 16 Mar 2015, Pavel Machek wrote:
Oliver Neukum oneu...@suse.de wrote:
+ ret = usb_interrupt_msg(dev, usb_sndintpipe(dev, 0x02),
+ buf2, sizeof(buf2
On Thu, 2015-03-19 at 11:12 +0100, Pavel Machek wrote:
On Thu 2015-03-19 10:54:22, Oliver Neukum wrote:
On Thu, 2015-03-19 at 10:38 +0100, Pavel Machek wrote:
On Thu 2015-03-19 10:14:21, Oliver Neukum wrote:
On Mon, 2015-03-16 at 22:37 +0100, Jiri Kosina wrote:
Are you sure
On Thu, 2015-03-19 at 10:38 +0100, Pavel Machek wrote:
On Thu 2015-03-19 10:14:21, Oliver Neukum wrote:
On Mon, 2015-03-16 at 22:37 +0100, Jiri Kosina wrote:
Are you sure CONFIG_DMA_API_DEBUG wouldn't warn here?
As far as I can tell, it will not warn. The problem
+};
+
+static int sis_ts_suspend(struct i2c_client *client, pm_message_t mesg);
+static int sis_ts_resume(struct i2c_client *client);
+
+#endif /* _LINUX_SIS_I2C_H */
--
Oliver Neukum oneu...@suse.de
--
To unsubscribe from this list: send the line unsubscribe linux-input in
the body of a message
},
{ USB_VENDOR_ID_SIS_TOUCH, USB_DEVICE_ID_SIS1030_TOUCH, HID_QUIRK_NOGET
},
{ USB_VENDOR_ID_SUN, USB_DEVICE_ID_RARITAN_KVM_DONGLE, HID_QUIRK_NOGET
},
--
Oliver Neukum oneu...@suse.de
--
To unsubscribe from this list: send the line unsubscribe linux-input in
the body of a message to majord
On Mon, 2015-02-09 at 20:44 +0200, Lauri Kasanen wrote:
On Mon, 09 Feb 2015 11:08:01 +0100
Oliver Neukum oneu...@suse.de wrote:
+ ret = usb_interrupt_msg(dev, usb_sndintpipe(dev, 0x02),
+ buf2, sizeof(buf2),
+ transfered
On Sat, 2015-02-07 at 15:48 +0200, Lauri Kasanen wrote:
Without this, my Gasia Co.,Ltd PS(R) Gamepad would not send
any events. Now everything works including the leds.
Based on work by Andrew Haines and Antonio Ospite.
cc: Antonio Ospite a...@ao2.it
cc: Andrew Haines andrewd...@aol.com
On Fri, 2015-01-16 at 18:59 +0800, 曾婷葳 (tammy_tseng) wrote:
Hey, Oliver
On Mon, Jan 12, 2015 at 7:50 PM, Oliver Neukum oneu...@suse.de wrote:
On Mon, 2015-01-12 at 18:53 +0800, 曾婷葳 (tammy_tseng) wrote:
(Skip the code diff...)
Again macros for endianness
And the driver has a great
On Mon, 2015-01-12 at 18:53 +0800, 曾婷葳 (tammy_tseng) wrote:
Hi,
This package of patch is to add support for multitouch behavior for SiS touch
products.
The patch of SiS i2c multitouch driver is in input/touchscreen.
Signed-off-by: Tammy Tseng tammy_ts...@sis.com
---
diff --git
On Mon, 2015-01-05 at 23:28 +0100, Gabriele Mazzotta wrote:
Make image sensors and cr48 sensors report widths and fix the
calculation of width and pressure values in some cases.
Changes since v1:
- Rebased on 35393dcb2ed3
- Get widths from AGM packets too
- Include support for cr48
On Fri, 2015-01-09 at 18:36 +0800, 曾婷葳 (tammy_tseng) wrote:
Signed-off-by: Tammy Tseng tammy_ts...@sis.com
---
The patch for i2c multitouch driver in input/touchscreen:
linux-3.18.1/drivers/input/touchscreen/Kconfig | 14 -
linux-3.18.1/drivers/input/touchscreen/Makefile |4 -
On Mon, 2014-11-24 at 16:56 -0800, Benson Leung wrote:
Hi Oliver,
On Mon, Nov 24, 2014 at 1:13 AM, Oliver Neukum oneu...@suse.de wrote:
But there is very little to be gained by switching off remote wakeup.
The additional energy consumption devices with remote wakeup enabled
On Fri, 2014-11-21 at 17:00 -0800, Benson Leung wrote:
If devices are already asleep with this flag enabled, that means that
they are presently configured for remote wake.
Yes, but that doesn't matter. The drivers must be ready for a device
being resumed at any time. Remote wakeup just adds
);
+ if (error) {
+ /* Continue initializing if it's the last try
*/
+ if (retry_cnt MAX_RETRIES - 1)
+ continue;
+ }
Regards
Oliver
--
Oliver Neukum oneu...@suse.de
On Thu, 2014-11-20 at 09:47 -0800, Dmitry Torokhov wrote:
Hi Oliver,
On Thu, Nov 20, 2014 at 11:31:30AM +0100, Oliver Neukum wrote:
+static int elants_i2c_initialize(struct elants_data *ts)
+{
+ struct i2c_client *client = ts-client;
+ int error, retry_cnt
The touchscreen needs the same quirk as the other models.
Signed-off-by: Oliver Neukum oneu...@suse.de
Reported-by: Bryan Poling poli0...@umn.edu
CC: sta...@vger.kernel.org
---
drivers/hid/hid-ids.h | 1 +
drivers/hid/usbhid/hid-quirks.c | 1 +
drivers/usb/core/quirks.c | 3
there when clearing needs_remote_wakeup. This will
add that to usbhid_close as well as usbhid_stop.
Interesting, but this has the side effect of waking devices
that are asleep just to remove the flag.
Regards
Oliver
--
Oliver Neukum oneu...@suse.de
--
To unsubscribe from
There is a second mouse sharing the same vendor strings
but different IDs.
Signed-off-by: Oliver Neukum oneu...@suse.de
---
drivers/hid/hid-ids.h | 1 +
drivers/hid/usbhid/hid-quirks.c | 2 ++
2 files changed, 3 insertions(+)
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
This mouse keeps disconnecting in runlevel 3. It needs the
ALWAYS_POLL quirk.
Signed-off-by: Oliver Neukum oneu...@suse.de
---
drivers/hid/hid-ids.h | 1 +
drivers/hid/usbhid/hid-quirks.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid
On Fri, 2014-08-22 at 14:23 -0400, Alan Stern wrote:
On Sat, 23 Aug 2014, vichy wrote:
from your patch, I have some questions:
a. in Alan's version, if both HID_CLEAR_HALT and HID_RESET_PENDING are
set, hid_reset will both clear ep halt and reset devcie.
But in original one, even
On Wed, 2014-07-16 at 14:08 -0400, Alan Stern wrote:
I am not so much concerned about userspace, but about reusing of as
much of existing PM framework in the drivers. Right now it is very
hard to correctly track dependencies between general open/close,
system suspend/resume, and various
On Wed, 2014-06-18 at 19:05 +0300, Janne Kanniainen wrote:
This driver adds support for USB controlled led panels that exists in
MSI GT683R laptop
+static int gt683r_led_probe(struct hid_device *hdev,
+ const struct hid_device_id *id)
+{
+ int i;
+ int ret;
+
On Thu, 2014-04-24 at 12:32 +0200, Michal Malý wrote:
On Wednesday 23 of April 2014 15:41:03 Oliver Neukum wrote:
On Tue, 2014-04-22 at 15:59 +0200, Michal Malý wrote:
static int drff_play(struct input_dev *dev, void *data,
-struct ff_effect *effect
On Tue, 2014-04-22 at 15:59 +0200, Michal Malý wrote:
+/* Some devices might have a limit on how many uncombinable effects
+ * can be played at once */
+static int mlnx_upload_conditional(struct mlnx_device *mlnxdev,
+ const struct ff_effect *effect)
+{
+
On Tue, 2014-04-22 at 15:59 +0200, Michal Malý wrote:
static int holtekff_play(struct input_dev *dev, void *data,
-struct ff_effect *effect)
+const struct mlnx_effect_command *command)
{
struct hid_device *hid = input_get_drvdata(dev);
On Tue, 2014-04-22 at 15:59 +0200, Michal Malý wrote:
static int drff_play(struct input_dev *dev, void *data,
-struct ff_effect *effect)
+ const struct mlnx_effect_command *command)
{
struct hid_device *hid =
On Wed, 2014-04-23 at 08:59 -0700, Dmitry Torokhov wrote:
On Wed, Apr 23, 2014 at 02:12:59PM +0200, Oliver Neukum wrote:
On Tue, 2014-04-22 at 15:59 +0200, Michal Malý wrote:
+/* Some devices might have a limit on how many uncombinable effects
+ * can be played at once */
+static int
On Mon, 2014-02-17 at 21:23 +0800, Daniel J Blueman wrote:
Across 5+ years of kernels, I've been seeing occasional (1-2 times per
day) key-stuck issues where eg a fn+delete combo repeats delete until
I press delete again. I've seen this happen with fn+ctrl+left, leaving
left held and likewise
On Thu, 2013-10-24 at 18:26 +0900, hyunhee.kim wrote:
Hi,
Thanks for your review.
I resent patch v3 after removing wrong wrapping.
I made one toggle function because enable/disable functions have redundant
codes and another reviewer suggested it.
Is it better to separate it into two
On Fri, 2013-08-16 at 22:25 +0200, Yann Cantin wrote:
+/* IRQ */
+static int ebeam_read_data(struct ebeam_device *ebeam, unsigned char *pkt)
+{
+
+/*
+ * Packet description : 8 bytes
+ *
+ * nop packet : FF FF FF FF FF FF FF FF
+ *
+ * pkt[0] : Sensors
+ * bit 1 : ultrasound signal
On Wednesday 17 April 2013 11:03:09 Benjamin Tissoires wrote:
+static void appleir_remove(struct hid_device *hid)
+{
+ struct appleir *appleir = hid_get_drvdata(hid);
+ del_timer_sync(appleir-key_up_timer);
+ hid_hw_stop(hid);
+ kfree(appleir);
+}
Hi,
this looks
On Tuesday 05 March 2013 18:55:42 Ming Lei wrote:
All these drivers suspend in multiple steps, where each step can
fail. If a later step fails then they revert any previously successful
step before returning the failure, thereby ensuring that the
device/driver state when suspend returns is
On Tuesday 05 March 2013 21:08:09 Ming Lei wrote:
On Tue, Mar 5, 2013 at 8:50 PM, Oliver Neukum oneu...@suse.de wrote:
In other words, if we don't handle errors, there must be no errors,
otherwise it doesn't matter what we do in the error case. We'd leave
the problem to generic layers
On Wednesday 05 September 2012 21:58:06 Yann Cantin wrote:
As ebeams are the only devices to my knowledge that work that way, i don't
think
a common API can be common, unless we mean an in-kernel generic purpose
calibration
API for input devices (stellar away for me), or a userland one
On Friday 24 August 2012 16:42:20 Yann Cantin wrote:
Hi,
Le 24/08/2012 13:41, Oliver Neukum a écrit :
On Friday 24 August 2012 11:37:45 Yann Cantin wrote:
Hi,
Le 23/08/2012 09:23, Oliver Neukum a écrit :
On Thursday 23 August 2012 00:11:54 Yann Cantin wrote:
These functions
On Friday 24 August 2012 11:37:45 Yann Cantin wrote:
Hi,
Le 23/08/2012 09:23, Oliver Neukum a écrit :
On Thursday 23 August 2012 00:11:54 Yann Cantin wrote:
These functions are identical. You should unify them.
Removed reset_resume from the driver (optional, and not needed
On Sunday 12 August 2012 18:16:22 Dâniel Fraga wrote:
I mean, it seems that with kernel 3.4 simply moving the mouse
would wake up the usb port and now with kernel 3.5 it only works if I
press a button.
So, kernel 3.5 is supposed to wake up the usb port when we move
the mouse or
62 matches
Mail list logo
