Hi guys,
I've read the discussion, I think I understand the problem and I'll
get back to this thread with more information as soon as I've got some
internal feedback.
BTW, lovely to see so many MX Anywhere 2 users :)
-nestor
On Tue, Oct 30, 2018 at 6:48 PM Harry Cutts wrote:
>
> Thanks for
Hi guys,
I've read the discussion, I think I understand the problem and I'll
get back to this thread with more information as soon as I've got some
internal feedback.
BTW, lovely to see so many MX Anywhere 2 users :)
-nestor
On Tue, Oct 30, 2018 at 6:48 PM Harry Cutts wrote:
>
> Thanks for
On Fri, Aug 31, 2018 at 11:11 AM Nestor Lopez Casado
wrote:
>
>
>
> On Thu, Aug 30, 2018 at 10:38 PM Harry Cutts wrote:
>>
>> Hi Benjamin,
>>
>> On Thu, 30 Aug 2018 at 00:18, Benjamin Tissoires
>> wrote:
>> >> On Thu, Aug 30, 2018
On Fri, Aug 31, 2018 at 11:11 AM Nestor Lopez Casado
wrote:
>
>
>
> On Thu, Aug 30, 2018 at 10:38 PM Harry Cutts wrote:
>>
>> Hi Benjamin,
>>
>> On Thu, 30 Aug 2018 at 00:18, Benjamin Tissoires
>> wrote:
>> >> On Thu, Aug 30, 2018
Hello Florent,
In my view, this driver may not be a good idea. The default behaviour
of K290 is 'send multimedia keycodes' with the user given the choice
to change that behaviour via vendor commands. Putting a driver that
will unconditionally change that behaviour without the user's consent
might
Hello Florent,
In my view, this driver may not be a good idea. The default behaviour
of K290 is 'send multimedia keycodes' with the user given the choice
to change that behaviour via vendor commands. Putting a driver that
will unconditionally change that behaviour without the user's consent
might
Elias, Simon, Michal,
It is unfortunate that we didn't get back to you in 2013 when you
asked for help in reverse engineering, oftentimes we have conflicting
priorities and a particular request may be left laying around for some
time before being addressed. But please, don't hesitate to re-kick
Elias, Simon, Michal,
It is unfortunate that we didn't get back to you in 2013 when you
asked for help in reverse engineering, oftentimes we have conflicting
priorities and a particular request may be left laying around for some
time before being addressed. But please, don't hesitate to re-kick
the root
cause of the problem.
Cheers,
-nestor
On Fri, Feb 14, 2014 at 2:32 PM, Nestor Lopez Casado
wrote:
> We discussed this issue with one of the receiver firmware developers today.
>
> We do see a clear issue when more than one DJ command (those with report id
> 0x20, 0x
the root
cause of the problem.
Cheers,
-nestor
On Fri, Feb 14, 2014 at 2:32 PM, Nestor Lopez Casado
nlopezca...@logitech.com wrote:
We discussed this issue with one of the receiver firmware developers today.
We do see a clear issue when more than one DJ command (those with report id
0x20, 0x21
On Thu, Jan 16, 2014 at 10:50 PM, Jiri Kosina wrote:
> On Wed, 8 Jan 2014, Benjamin Tissoires wrote:
>
>> From: Benjamin Tisssoires
>>
>> This fix (not very clean though) should fix the long time USB3
>> issue that was spotted last year. The rational has been given by
>> Hans de Goede:
>
> Man
On Thu, Jan 16, 2014 at 10:50 PM, Jiri Kosina jkos...@suse.cz wrote:
On Wed, 8 Jan 2014, Benjamin Tissoires wrote:
From: Benjamin Tisssoires benjamin.tissoi...@redhat.com
This fix (not very clean though) should fix the long time USB3
issue that was spotted last year. The rational has been
Sorry, no html now.
On Tue, Dec 3, 2013 at 3:01 PM, Nestor Lopez Casado
wrote:
>
>
>
>
> On Tue, Dec 3, 2013 at 1:51 PM, Jiri Kosina wrote:
>>
>> On Tue, 3 Dec 2013, Olivier Gay wrote:
>>
>> > Without hidraw driver, we get this:
>> >
>&g
Sorry, no html now.
On Tue, Dec 3, 2013 at 3:01 PM, Nestor Lopez Casado
nlopezca...@logitech.com wrote:
On Tue, Dec 3, 2013 at 1:51 PM, Jiri Kosina jkos...@suse.cz wrote:
On Tue, 3 Dec 2013, Olivier Gay wrote:
Without hidraw driver, we get this:
3[ 210.131988] logitech-djreceiver
Hi Sarah,
On Fri, Jul 19, 2013 at 12:09 AM, Sarah Sharp
wrote:
> On Thu, Jul 18, 2013 at 04:28:01PM -0400, Peter Hurley wrote:
>> [ +cc Sarah Sharp, linux-usb ]
>>
>> On 07/18/2013 09:21 AM, Nestor Lopez Casado wrote:
>> >This reverts commit 8af6c08830
Hi Sarah,
On Fri, Jul 19, 2013 at 12:09 AM, Sarah Sharp
sarah.a.sh...@linux.intel.com wrote:
On Thu, Jul 18, 2013 at 04:28:01PM -0400, Peter Hurley wrote:
[ +cc Sarah Sharp, linux-usb ]
On 07/18/2013 09:21 AM, Nestor Lopez Casado wrote:
This reverts commit
Set querying_devices flag to true when we start the enumeration
process.
This was missing from the original patch. It never produced
undesirable effects as it is highly improbable to have a second
enumeration triggered while a first one was still in progress.
Signed-off-by: Nestor Lopez Casado
then a (re)enumeration is performed.
related bug:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1194649
Signed-off-by: Nestor Lopez Casado
---
drivers/hid/hid-logitech-dj.c | 45 +
drivers/hid/hid-logitech-dj.h |1 +
2 files changed, 46 insertions(+)
)enumeration is performed.
related bug:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1194649
Signed-off-by: Nestor Lopez Casado nlopezca...@logitech.com
---
drivers/hid/hid-logitech-dj.c | 45 +
drivers/hid/hid-logitech-dj.h |1 +
2 files changed, 46
Set querying_devices flag to true when we start the enumeration
process.
This was missing from the original patch. It never produced
undesirable effects as it is highly improbable to have a second
enumeration triggered while a first one was still in progress.
Signed-off-by: Nestor Lopez Casado
Added Benjamin.
On Mon, Jul 15, 2013 at 8:37 PM, Andrew de los Reyes wrote:
> I believe this commit was an optimization, so it should be okay to revert
> it.
>
> Nestor, can you confirm?
5962640 is not an optimization, is a workaround for the dropped
packets during enumeration. After
Added Benjamin.
On Mon, Jul 15, 2013 at 8:37 PM, Andrew de los Reyes a...@chromium.org wrote:
I believe this commit was an optimization, so it should be okay to revert
it.
Nestor, can you confirm?
5962640 is not an optimization, is a workaround for the dropped
packets during enumeration.
Hi all,
Sorry it took me some time to answer.
I extended the Logitech HIDPP10 specification here:
https://drive.google.com/folderview?id=0BxbRzx7vEV7eWmgwazJ3NUFfQ28=sharing
The document
"Logitech_hidpp10_specification_draft_Unifying_devices_receivers.doc"
now contains most of the relevant
Hi all,
Sorry it took me some time to answer.
I extended the Logitech HIDPP10 specification here:
https://drive.google.com/folderview?id=0BxbRzx7vEV7eWmgwazJ3NUFfQ28usp=sharing
The document
Logitech_hidpp10_specification_draft_Unifying_devices_receivers.doc
now contains most of the relevant
se the front panel it works flawlessly. Could this be related
> to my POS Intel motherboard?
>
> Kind regards and apologies if i raise a false alarm.
>
> Apostolos B.
> On 09/28/2012 10:57 AM, Nestor Lopez Casado wrote:
>
> Hello Josip,
>
> This really looks like a different
When i use a usb3 port it doesn't move at all and if i use a usb2 port its
slow. When i use the front panel it works flawlessly. Could this be related
to my POS Intel motherboard?
Kind regards and apologies if i raise a false alarm.
Apostolos B.
On 09/28/2012 10:57 AM, Nestor Lopez Casado
written by Benjamin Tissoires.
Signed-off-by: Nestor Lopez Casado
---
Hello Jiri, David,
I suggest we include this patch as this solves the issue with the
Unifying devices while we decide the future of the lock in hid-core.
Cheers,
Nestor
drivers/hid/hid-logitech
written by Benjamin Tissoires.
Signed-off-by: Nestor Lopez Casado nlopezca...@logitech.com
---
Hello Jiri, David,
I suggest we include this patch as this solves the issue with the
Unifying devices while we decide the future of the lock in hid-core.
Cheers,
Nestor
28 matches
Mail list logo
