ing unknown reports to the receiver node? Is there
any technical limitation to do that? I am not too familiar with this part of the
code.
Cheers,
Filipe Laíns
signature.asc
Description: This is a digitally signed message part
01 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
>
> With or without the patch and error messages the mouse has always worked.
>
> Regards
> Mark
Yes, sorry about that. The following patch should fix it, can you confirm?
You probably didn't notice any breakage becaus
On Fri, 2021-02-05 at 16:14 +0100, Jiri Kosina wrote:
> On Sat, 23 Jan 2021, Filipe Laíns wrote:
>
> > From: Filipe Laíns
> >
> > Tested with the G Pro X Superlight. libratbag sees the device, as
> > expected, and input events are passing trough.
> >
> &
On Fri, 2021-02-05 at 10:18 +0100, Jiri Kosina wrote:
> On Sat, 30 Jan 2021, Filipe Laíns wrote:
>
> > From: Filipe Laíns
> >
> > In e400071a805d6229223a98899e9da8c6233704a1 I added support for the
> > receiver that comes with the G602 device, but unfortunately I
From: Filipe Laíns
In e400071a805d6229223a98899e9da8c6233704a1 I added support for the
receiver that comes with the G602 device, but unfortunately I screwed up
during testing and it seems the keyboard events were actually not being
sent to userspace.
This resulted in keyboard events being broken
On Sat, 2021-01-30 at 21:27 +0100, Hans de Goede wrote:
> Hi,
>
> On 1/30/21 8:14 PM, Filipe Laíns wrote:
> > Hans,
> >
> > You added support for non unifying receivers in
> > 74808f9115cee2bb53e7161432959f3e87b631e4, could you please test and make
> > sur
Oops
On Sat, 2021-01-30 at 19:14 +, Filipe Laíns wrote:
> this cause any breakage with your devices?
this *doesn't* cause
--
Filipe Laíns
signature.asc
Description: This is a digitally signed message part
Hans,
You added support for non unifying receivers in
74808f9115cee2bb53e7161432959f3e87b631e4, could you please test and make sure
this cause any breakage with your devices?
AFAIK, they could only break if they have a 0x01 report which is different from
kbd_descriptor.
Cheers,
Filipe Laíns
From: Filipe Laíns
In e400071a805d6229223a98899e9da8c6233704a1 I added support for the
receiver that comes with the G602 device, but unfortunately I screwed up
during testing and it seems the keyboard events were actually not being
sent to userspace.
This resulted in keyboard events being broken
From: Filipe Laíns
Tested and is working :)
Signed-off-by: Filipe Laíns
---
drivers/hid/hid-logitech-hidpp.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c
index 291c6b4d26b7..54a289510a7d 100644
--- a/drivers/hid/hid
From: Filipe Laíns
Tested with the G Pro X Superlight. libratbag sees the device, as
expected, and input events are passing trough.
https://github.com/libratbag/libratbag/pull/1122
The receiver has a quirk where the moused interface doesn't have a
report ID, I am not sure why, perhaps
From: Filipe Laíns
This new connection type is the new iteration of the Lightspeed
connection and will probably be used in some of the newer gaming
devices. It is currently use in the G Pro X Superlight.
This patch should be backported to older versions, as currently the
driver will panic when
On Fri, 2021-01-08 at 15:55 +0100, Jiri Kosina wrote:
> On Fri, 8 Jan 2021, Filipe Laíns wrote:
> > The problem here is that hidpp20_query_battery_info_1004() does not set
> > battery voltage, it is also the battery level. The best alternative Ican
> > think
> > of
On Fri, 2021-01-08 at 14:44 +0100, Jiri Kosina wrote:
> On Mon, 4 Jan 2021, la...@archlinux.org wrote:
>
> > From: Filipe Laíns
> >
> > This new feature present in new devices replaces the old Battery Level
> > Status (0x1000) feature. It keeps essentially the s
:)
The lightspeed receivers we support all have the DJ interface, these new ones do
not. But yeah, I think it should just work, or at least be simple to make it
work.
Cheers,
Filipe Laíns
signature.asc
Description: This is a digitally signed message part
2) would be the easier on userspace, as it keeps the same interface we
use for DJ receivers for other Logitech HID++ receivers and avoids all userspace
apps to have to reimplement the same discovery logic.
Any thoughts?
[1] https://github.com/libratbag/libratbag/pull/1071
Cheers,
Filipe Laíns
On Wed, 2021-01-06 at 10:34 +0100, Bastien Nocera wrote:
> On Mon, 2021-01-04 at 18:29 +, la...@archlinux.org wrote:
> > From: Filipe Laíns
> >
> > This new feature present in new devices replaces the old Battery
> > Level
> > Status (0x1000) featu
Tested. The device gets correctly exported to userspace and I can see
mouse and keyboard events.
Signed-off-by: Filipe Laíns
---
drivers/hid/hid-logitech-dj.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/hid/hid-logitech-dj.c b/drivers/hid/hid-logitech-dj.c
index 1ffcfc9a1e03
On Mon, 2020-07-06 at 14:41 +0200, Maciej S. Szmigiero wrote:
> On 06.07.2020 14:38, Filipe Laíns wrote:
> > On Sun, 2020-07-05 at 19:34 +0200, Maciej S. Szmigiero wrote:
> > > These messages appear each time the mouse wakes from sleep, in my
> > > case
> > >
uct dj_receiver_dev *djrcv_dev,
> memset(buf, 0, HIDPP_REPORT_SHORT_LENGTH);
>
> buf[0] = REPORT_ID_HIDPP_SHORT;
> - buf[1] = 0xFF;
> + buf[1] = HIDPP_RECEIVER_INDEX;
> buf[2] = 0x80;
> buf[3] = 0x00;
> buf[4] = 0x00;
> --
> 2.27.0
This is correct :)
Reviewed-by: Filipe Laíns
Cheers,
Filipe Laíns
signature.asc
Description: This is a digitally signed message part
hidpp->vertical_wheel_counter.wheel_multiplier = multiplier;
> - hid_info(hidpp->hid_dev, "multiplier = %d\n", multiplier);
> + hid_dbg(hidpp->hid_dev, "wheel multiplier = %d\n", multiplier);
> return 0;
> }
>
I have seen this being useful in som
ncerns were address and the patch looks correct.
Benjamin, Jiri, are there any implications to keep in mind of always
polling the device every time we need to read the voltage? I don't
expect anything major, I just thought there might something there I
should keep in the back of my mind.
Cheers,
F
ONNECTED)
>
> Yeah, I it will do exactly that for v3, which allows to drop the flag
> variables and avoid using a long.
>
>
> > Same thing here. We should see if the device supports the DJ protocol
> > and add it in hid-logitech-dj instead.
>
> It doesn't seem to b
G703 Hero Gaming Mouse over USB */
Same thing here. We should see if the device supports the DJ protocol
and add it in hid-logitech-dj instead.
Most of my comments here are nitpicks, I am not sure how strict
Benjamin/Jiri are about that.
Cheers,
Filipe Laíns
signature.asc
Description: This is a digitally signed message part
? If so, we need to know if it is used by other
devices. Or better, see if it supports the DJ protocol and add it to
hid-logitech-dj instead.
> { /* Logitech G703 Gaming Mouse over USB */
> HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, 0xC087) },
> { /* Logitech G703 Hero Gaming Mouse over USB */
Cheers,
Filipe Laíns
signature.asc
Description: This is a digitally signed message part
On Fri, 2019-10-11 at 10:54 +0200, Benjamin Tissoires wrote:
> On Fri, Oct 11, 2019 at 10:49 AM Filipe Laíns
> wrote:
> > On Fri, 2019-10-11 at 00:57 +, Mazin Rezk wrote:
> > > On Saturday, October 5, 2019 9:04 PM, Mazin Rezk <
> > > mn...@protonmail.com> w
a = HIDPP_QUIRK_HI_RES_SCROLL_X2121 },
> {}
> };
>
> --
> 2.23.0
>
The series now looks great, thanks!
Benjamin, I can confirm that up to now all BLE devices don't have short
reports. I am not sure if you still want to only enable tested devices
but from an architectural standpoint everything here should be fine.
Mazin, you can have my
Reviewed-by: Filipe Laíns
for the series.
Thank you,
Filipe Laíns
will
> keep it
> the way it was for now. This could probably be changed in a different
> and
> unrelated patch.
Ah, sorry. On my quick look it seemed to be included in the patch
:facepalm:.
Thanks,
Filipe Laíns
signature.asc
Description: This is a digitally signed message part
hdev);
> }
>
> + /* Cache feature indexes and IDs to check reports faster */
> + if (hidpp->protocol_major >= 2) {
> + if (hidpp20_get_features(hidpp)) {
> + hid_err(hdev, "%s:hidpp20_get_features returned
> error\n"
ou should only add the mice you tested. We are not sure if
this devices actually do work properly with the current stack. I will
try to test some devices after Tuesday.
Filipe Laíns
signature.asc
Description: This is a digitally signed message part
ying this in my first review. Since then I have done
some testing and I discovered that if we want to get accurate upower
support we will need the values exposed by the 3rd byte to be
exported properly.
I am not sure about the endianness of chargeStatus but you can find
that easily.
Thank you!
Filipe Laíns
signature.asc
Description: This is a digitally signed message part
tery_props[num_battery_props++] =
> POWER_SUPPLY_PROP_CAPACITY_LEVEL;
>
> + if (hidpp->capabilities & HIDPP_CAPABILITY_BATTERY_VOLTAGE)
> + battery_props[num_battery_props++] =
> + POWER_SUPPLY_PROP_VOLTAGE_NOW;
> +
> battery = >battery;
>
> n = atomic_inc_return(_no) - 1;
> @@ -3407,7 +3537,10 @@ static void hidpp_connect_event(struct
> hidpp_device *hidpp)
> else
> hidpp10_query_battery_status(hidpp);
> } else if (hidpp->capabilities &
> HIDPP_CAPABILITY_HIDPP20_BATTERY) {
> - hidpp20_query_battery_info(hidpp);
> + if (hidpp->capabilities &
> HIDPP_CAPABILITY_BATTERY_VOLTAGE)
> + hidpp20_query_battery_voltage_info(hidpp);
> + else
> + hidpp20_query_battery_info(hidpp);
> }
> if (hidpp->battery.ps)
> power_supply_changed(hidpp->battery.ps);
Reviewed-by: Filipe Laíns
Thank you,
Filipe Laíns
signature.asc
Description: This is a digitally signed message part
On Fri, 2019-08-23 at 16:32 +0200, Benjamin Tissoires wrote:
> The problem I have with quirks, and that I explained to Filipe on IRC
> is that this is kernel ABI. Even if there is a very low chance we have
> someone using this, re-using the same drv_data bit in the future might
> break someone's
happy either way, so just let me know what you guys decide.
I am also fine either way so I think we should just re-send the first
revision of your patch set as Benjamin requested.
Thank you,
Filipe Laíns
signature.asc
Description: This is a digitally signed message part
events
>
> drivers/hid/hid-logitech-hidpp.c | 150
> ++-
> 1 file changed, 147 insertions(+), 3 deletions(-)
>
This is OK. However since we now have a feature discovery routine I
think the code should use that instead of quirks. I will send a patch
making this change.
You can have my
R
(2):
> Revert "HID: logitech-hidpp: add USB PID for a few more supported
> mice"
> HID: logitech-hidpp: remove support for the G700 over USB
>
> drivers/hid/hid-logitech-hidpp.c | 22 --
> 1 file changed, 22 deletions(-)
>
Reviewed-by: Fi
This patchs adds the new Lightspeed receiver. Currently it seems to only
be used in the G305.
Signed-off-by: Filipe Laíns
---
drivers/hid/hid-ids.h | 3 ++-
drivers/hid/hid-logitech-dj.c | 13 +++--
2 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/hid/hid
On Thu, 2019-07-18 at 15:03 +0100, Filipe Laíns wrote:
> This receiver seems to only be used in the G305.
>
> Signed-off-by: Filipe Laíns
> ---
> drivers/hid/hid-ids.h | 1 +
> drivers/hid/hid-logitech-dj.c | 4
> 2 files changed, 5 insertions(+)
>
> d
This receiver seems to only be used in the G305.
Signed-off-by: Filipe Laíns
---
drivers/hid/hid-ids.h | 1 +
drivers/hid/hid-logitech-dj.c | 4
2 files changed, 5 insertions(+)
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 884356feb016..e5d0fd85e61d 100644
On Wed, 2019-07-17 at 13:31 +0200, Jiri Kosina wrote:
> On Tue, 16 Jul 2019, Filipe Laíns wrote:
>
> > Signed-off-by: Filipe Laíns
>
> We generally don't accept empty changelogs for the kernel. I've added at
> least a few words, and comitted.
>
> This applie
Signed-off-by: Filipe Laíns
---
drivers/hid/hid-logitech-hidpp.c | 32 +++-
1 file changed, 31 insertions(+), 1 deletion(-)
diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c
index e3b6245bf4b2..21268c9fa71a 100644
--- a/drivers/hid/hid
Signed-off-by: Filipe Laíns
---
drivers/hid/hid-ids.h | 1 +
drivers/hid/hid-logitech-dj.c | 4
2 files changed, 5 insertions(+)
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index ab9d382b067d..884356feb016 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid
this should help people identify the receiver. there are several
receivers used in gaming mice. the "lightspeed" technology is pretty
well advertise so this won't just be an obscure name.
Signed-off-by: Filipe Laíns
---
drivers/hid/hid-ids.h | 2 +-
drivers/hid/hid-logitec
pecifically to prevent that.
Wasn't this what you started in your previous patch? Why move away from
it?
Thank you,
Filipe Laíns
3DCE 51D6 0930 EBA4 7858 BA41 46F6 33CB B0EB 4BF2
signature.asc
Description: This is a digitally signed message part
44 matches
Mail list logo
