@@ -44,19 +44,21 @@ static __u8 *sony_report_fixup(struct histructsony_sc*sc=hid_get_drvdata(hdev);if((sc->quirks&VAIO_RDESC_CONSTANT)&&-*rsize>=56&&rdesc[54]==0x81&&rdesc[55]==0x07){-hid_info(hdev,"Fixing up Sony Vaio VGX report descriptor\n");+*rsize>=56&&rdesc[54]==0x81&&rdesc[55]==0x07){+hid_info(hdev,+"Fixing up Sony RF Receiver report descriptor\n");rdesc[55]=0x06;}/* The HID descriptor exposed over BT has a trailing zero byte */if((((sc->quirks&SIXAXIS_CONTROLLER_USB)&&*rsize==148)||-((sc->quirks&SIXAXIS_CONTROLLER_BT)&&*rsize==149))&&-rdesc[83]==0x75){+((sc->quirks&SIXAXIS_CONTROLLER_BT)&&*rsize==149))&&+rdesc[83]==0x75){hid_info(hdev,"Fixing up Sony Sixaxis report descriptor\n");memcpy((void*)&rdesc[83],(void*)&sixaxis_rdesc_fixup,sizeof(sixaxis_rdesc_fixup));}+returnrdesc;}
From: Antonio Ospite <hidden> Date: 2013-01-15 09:37:45
On Tue, 15 Jan 2013 12:43:48 +0900
Fernando Luis Vázquez Cao [off-list ref] wrote:
Hi Fernando,
Some Vaio desktop computers, among them the VGC-LN51JGB multimedia PC, have
a RF receiver, multi-interface USB device 054c:0374, that is used to connect
a wireless keyboard and a wireless mouse.
The keyboard works flawlessly, but the mouse (VGP-WMS3 in my case) does not
seem to be generating any pointer events. The problem is that the mouse pointer
is wrongly declared as a constant non-data variable in the report descriptor
(see lsusb and usbhid-dump output below), with the consenquence that it is
@@ -44,19 +44,21 @@ static __u8 *sony_report_fixup(struct histructsony_sc*sc=hid_get_drvdata(hdev);if((sc->quirks&VAIO_RDESC_CONSTANT)&&-*rsize>=56&&rdesc[54]==0x81&&rdesc[55]==0x07){-hid_info(hdev,"Fixing up Sony Vaio VGX report descriptor\n");+*rsize>=56&&rdesc[54]==0x81&&rdesc[55]==0x07){+hid_info(hdev,+"Fixing up Sony RF Receiver report descriptor\n");
Changing the message does make sense, but try to avoid mixing
functional changes with style changes (I am referring to the change of
indentation here).
If you _really_ want to change the style send a separate patch stating
clearly in the commit message that there are no functionality changes.
This makes the review easier for both kind of patches.
quoted hunk
rdesc[55] = 0x06; } /* The HID descriptor exposed over BT has a trailing zero byte */ if ((((sc->quirks & SIXAXIS_CONTROLLER_USB) && *rsize == 148) ||- ((sc->quirks & SIXAXIS_CONTROLLER_BT) && *rsize == 149)) &&- rdesc[83] == 0x75) {+ ((sc->quirks & SIXAXIS_CONTROLLER_BT) && *rsize == 149)) &&+ rdesc[83] == 0x75) {
Ditto, style changes.
quoted hunk
hid_info(hdev, "Fixing up Sony Sixaxis report descriptor\n"); memcpy((void *)&rdesc[83], (void *)&sixaxis_rdesc_fixup, sizeof(sixaxis_rdesc_fixup)); }+
Thanks,
Antonio
--
Antonio Ospite
http://ao2.it
A: Because it messes up the order in which people normally read text.
See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
@@ -44,19 +44,21 @@ static __u8 *sony_report_fixup(struct histructsony_sc*sc=hid_get_drvdata(hdev);if((sc->quirks&VAIO_RDESC_CONSTANT)&&-*rsize>=56&&rdesc[54]==0x81&&rdesc[55]==0x07){-hid_info(hdev,"Fixing up Sony Vaio VGX report descriptor\n");+*rsize>=56&&rdesc[54]==0x81&&rdesc[55]==0x07){+hid_info(hdev,+"Fixing up Sony RF Receiver report descriptor\n");
Changing the message does make sense, but try to avoid mixing
functional changes with style changes (I am referring to the change of
indentation here).
Oops, that was unintended. I will be replying to this email with an updated version.
Thanks,
Fernando
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
@@ -45,7 +45,7 @@ static __u8 *sony_report_fixup(struct hiif((sc->quirks&VAIO_RDESC_CONSTANT)&&*rsize>=56&&rdesc[54]==0x81&&rdesc[55]==0x07){-hid_info(hdev,"Fixing up Sony Vaio VGX report descriptor\n");+hid_info(hdev,"Fixing up Sony RF Receiver report descriptor\n");rdesc[55]=0x06;}
On Tue, 15 Jan 2013, Fernando Luis Vázquez Cao wrote:
Some Vaio desktop computers, among them the VGC-LN51JGB multimedia PC, have
a RF receiver, multi-interface USB device 054c:0374, that is used to connect
a wireless keyboard and a wireless mouse.
The keyboard works flawlessly, but the mouse (VGP-WMS3 in my case) does not
seem to be generating any pointer events. The problem is that the mouse pointer
is wrongly declared as a constant non-data variable in the report descriptor
(see lsusb and usbhid-dump output below), with the consequence that it is
ignored by the HID code.
Add this device to the have-special-driver list and fix up the report
descriptor in the Sony-specific driver which happens to already have a fixup
for a similar firmware bug.
From: Fernando Luis Vazquez Cao <hidden> Date: 2013-01-16 05:17:57
Hi Jiri,
On 2013/01/16 01:02, Jiri Kosina wrote:
On Tue, 15 Jan 2013, Fernando Luis Vázquez Cao wrote:
quoted
Some Vaio desktop computers, among them the VGC-LN51JGB multimedia PC, have
a RF receiver, multi-interface USB device 054c:0374, that is used to connect
a wireless keyboard and a wireless mouse.
The keyboard works flawlessly, but the mouse (VGP-WMS3 in my case) does not
seem to be generating any pointer events. The problem is that the mouse pointer
is wrongly declared as a constant non-data variable in the report descriptor
(see lsusb and usbhid-dump output below), with the consequence that it is
ignored by the HID code.
Add this device to the have-special-driver list and fix up the report
descriptor in the Sony-specific driver which happens to already have a fixup
for a similar firmware bug.
Applied, thanks.
Thank you.
I noticed that the patch was tagged "for-3.9". Does this mean
that it is too late to get it merged during the current release
cycle?
If possible, I would like to get it backported to 3.7-stable (and
possibly 3.2 stable), since without it a whole family of Sony
desktop computers is unusable under Linux out of the box.
Should I do it myself or do you have a process in place for HID
stable patches?
Regards,
Fernando
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, 16 Jan 2013, Fernando Luis Vazquez Cao wrote:
I noticed that the patch was tagged "for-3.9". Does this mean
that it is too late to get it merged during the current release
cycle?
I currently don't have anything queued for 3.8, and this particular patch
doesn't justify a separate pull request.
Once it's in Linus' tree, it can be easily pushed out to all existing
-stable branches (including 3.8-stable, once it's created).
If I am gfoing to be sending pull request for 3.8 to Linus still due to
some important bugfix, I will be including this.
If possible, I would like to get it backported to 3.7-stable (and
possibly 3.2 stable), since without it a whole family of Sony desktop
computers is unusable under Linux out of the box. Should I do it myself
or do you have a process in place for HID stable patches?
If the patch had
Cc: stable@vger.kernel.org
in it, it'd be picked for -stable queue automatically. Otherwise, anyone
is free to take it once it's in Linus' tree and sent to to
stable@vger.kernel.org for inclusion.
Hope this helps,
--
Jiri Kosina
SUSE Labs
From: Fernando Luis Vazquez Cao <hidden> Date: 2013-01-22 05:58:04
On Wed, 2013-01-16 at 11:44 +0100, Jiri Kosina wrote:
On Wed, 16 Jan 2013, Fernando Luis Vazquez Cao wrote:
quoted
I noticed that the patch was tagged "for-3.9". Does this mean
that it is too late to get it merged during the current release
cycle?
I currently don't have anything queued for 3.8, and this particular patch
doesn't justify a separate pull request.
Once it's in Linus' tree, it can be easily pushed out to all existing
-stable branches (including 3.8-stable, once it's created).
If I am gfoing to be sending pull request for 3.8 to Linus still due to
some important bugfix, I will be including this.
Ok, thank you for the explanation. I really appreciate it.
quoted
If possible, I would like to get it backported to 3.7-stable (and
possibly 3.2 stable), since without it a whole family of Sony desktop
computers is unusable under Linux out of the box. Should I do it myself
or do you have a process in place for HID stable patches?
If the patch had
Cc: stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
in it, it'd be picked for -stable queue automatically.
I considered doing that but I thought and upstream commit
ID was needed.
Otherwise, anyone is free to take it once it's in Linus' tree and sent
to to stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org for inclusion.
So it is the standard procedure. I just wanted to make
sure whether you wanted to have all the -stable patches
funnelled through you. I will send the patch to -stable
directly and Cc you as soon as it makes it into Linus'
tree.
By the way, I will be replying to this email with a
follow-up patch that I forgot to send the last time
around. It is just documentation for the quirk.
Thanks,
Fernando
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Fernando Luis Vázquez Cao <hidden> Date: 2013-01-22 06:21:30
Document what the fix-up is does and make it more robust by ensuring
that it is only applied to the USB interface that corresponds to the
mouse (sony_report_fixup() is called once per interface during probing).
Cc: linux-input@vger.kernel.org
Cc: linux-usb@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Fernando Luis Vazquez Cao <redacted>
Signed-off-by: Jiri Kosina <redacted>
---
diff -urNp linux-3.8-rc4-orig/drivers/hid/hid-sony.c linux-3.8-rc4/drivers/hid/hid-sony.c
On Tue, 22 Jan 2013, Fernando Luis Vazquez Cao wrote:
quoted
quoted
If possible, I would like to get it backported to 3.7-stable (and
possibly 3.2 stable), since without it a whole family of Sony desktop
computers is unusable under Linux out of the box. Should I do it myself
or do you have a process in place for HID stable patches?
If the patch had
Cc: stable@vger.kernel.org
in it, it'd be picked for -stable queue automatically.
I considered doing that but I thought and upstream commit
ID was needed.
Yes, that's necessary in case you are cherry-picking a commit already
present in Linus' tree that doesn't have explicit "Cc:
stable@vger.kernel.org". Otherwise, -stable tree maintainer is
automatically picking up commits that appear in Linus tree with this tag.
quoted
Otherwise, anyone is free to take it once it's in Linus' tree and sent
to to stable@vger.kernel.org for inclusion.
So it is the standard procedure. I just wanted to make sure whether you
wanted to have all the -stable patches funnelled through you.
It's not strictly necessary. I get copied on them when they are queued in
-stable queue anyway.
By the way, I will be replying to this email with a follow-up patch that
I forgot to send the last time around. It is just documentation for the
quirk.
On Tue, 22 Jan 2013, Fernando Luis Vázquez Cao wrote:
Document what the fix-up is does and make it more robust by ensuring
that it is only applied to the USB interface that corresponds to the
mouse (sony_report_fixup() is called once per interface during probing).
Applied.
--
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Fernando Luis Vázquez Cao <hidden> Date: 2013-05-01 00:25:22
Hi Jiri,
On Tue, 2013-01-15 at 17:02 +0100, Jiri Kosina wrote:
On Tue, 15 Jan 2013, Fernando Luis Vázquez Cao wrote:
quoted
Some Vaio desktop computers, among them the VGC-LN51JGB multimedia PC, have
a RF receiver, multi-interface USB device 054c:0374, that is used to connect
a wireless keyboard and a wireless mouse.
The keyboard works flawlessly, but the mouse (VGP-WMS3 in my case) does not
seem to be generating any pointer events. The problem is that the mouse pointer
is wrongly declared as a constant non-data variable in the report descriptor
(see lsusb and usbhid-dump output below), with the consequence that it is
ignored by the HID code.
Add this device to the have-special-driver list and fix up the report
descriptor in the Sony-specific driver which happens to already have a fixup
for a similar firmware bug.
Applied, thanks.
It looks like after the merge of the the sony and steelseries
branches the hid core hunk was left out, which means that
this fix-up is never applied.
I will be replying to this email with a fix.
Thanks,
Fernando
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Fernando Luis Vázquez Cao <hidden> Date: 2013-05-01 00:26:32
It looks like the manual merge 0d69a3c731e120b05b7da9fb976830475a3fbc01 ("Merge
branches 'for-3.9/sony' and 'for-3.9/steelseries' into for-linus") accidentally
removed Sony RF receiver with USB product id 0x0374 from the "have special
driver" list, effectively nullifying a464918419f94a0043d2f549d6defb4c3f69f68a
("HID: add support for Sony RF receiver with USB product id 0x0374"). Add the
device back to the list.
Cc: stable@vger.kernel.org
Signed-off-by: Fernando Luis Vazquez Cao <redacted>
---
diff -urNp linux-3.9/drivers/hid/hid-core.c linux-3.9-fix/drivers/hid/hid-core.c
On Wed, 1 May 2013, Fernando Luis Vázquez Cao wrote:
quoted hunk
It looks like the manual merge 0d69a3c731e120b05b7da9fb976830475a3fbc01 ("Merge
branches 'for-3.9/sony' and 'for-3.9/steelseries' into for-linus") accidentally
removed Sony RF receiver with USB product id 0x0374 from the "have special
driver" list, effectively nullifying a464918419f94a0043d2f549d6defb4c3f69f68a
("HID: add support for Sony RF receiver with USB product id 0x0374"). Add the
device back to the list.
Cc: stable@vger.kernel.org
Signed-off-by: Fernando Luis Vazquez Cao <redacted>
---
diff -urNp linux-3.9/drivers/hid/hid-core.c linux-3.9-fix/drivers/hid/hid-core.c
Thanks a lot for noticing. Applied.
--
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html