On Wednesday 07 August 2013 15:34:08 Jiri Kosina wrote:
> On Wed, 7 Aug 2013, Peter Wu wrote:
> > [..]
> > I have applied Manoj's patch[1] on top of 3.11-rc4 which seem to fix the
> > issue. One observation is that the new device is named /dev/hidraw1
> > instead of /dev/hidraw0. Example:
> >
> >
hidraw_release in 3.11-rc4
On Wed, 7 Aug 2013, Peter Wu wrote:
> > does the patch below fix the problem you are seeing?
> That one is already in 3.11-rc4 as far as I can see. Also, that code
> can probably simplified by moving the mutex_unlock after the out
> label, remov
On Wed, 7 Aug 2013, Peter Wu wrote:
> > does the patch below fix the problem you are seeing?
> That one is already in 3.11-rc4 as far as I can see. Also, that code can
> probably simplified by moving the mutex_unlock after the out label, removing
> the need to duplicate the mutex_unlock.
>
> Re
On Wednesday 07 August 2013 03:01:26 Jiri Kosina wrote:
> On Tue, 6 Aug 2013, Peter Wu wrote:
> > While debugging upowerd (with Logitech Unifying receiver via hidraw),
> > I came across this list corruption warning.
>
> Peter,
>
> does the patch below fix the problem you are seeing?
That one is a
On Tue, 6 Aug 2013, Peter Wu wrote:
> While debugging upowerd (with Logitech Unifying receiver via hidraw),
> I came across this list corruption warning.
Peter,
does the patch below fix the problem you are seeing?
---
drivers/hid/hidraw.c |2 +-
1 files changed, 1 insertions(+), 1 deletion
Hi,
While debugging upowerd (with Logitech Unifying receiver via hidraw),
I came across this list corruption warning. It probably has something
to do with me removing the receiver and re-inserting it while the file
descriptor to /dev/hidraw0 was still open. journalctl excerpt is on the
bottom of t
6 matches
Mail list logo