[patch] hid: only dump report traffic with debug level 2
Currently using debug=1 with hid module prints out all sent and received
reports to the kernel log, while in many cases we only want to see the
report descriptors and hid-input mappings that are printed when a device
is probed.
Add new level debug=2, and only dump the report traffic with that level.
Signed-off-by: Anssi Hannula [EMAIL PROTECTED]
---
Index: linux-2.6.24-verbosehid/drivers/hid/hid-core.c
===
--- linux-2.6.24-verbosehid/drivers/hid/hid-core.c
+++ linux-2.6.24-verbosehid/drivers/hid/hid-core.c 2008-03-21
13:03:29.0 +0200
@@ -43,8 +43,8 @@
#ifdef CONFIG_HID_DEBUG
int hid_debug = 0;
-module_param_named(debug, hid_debug, bool, 0600);
-MODULE_PARM_DESC(debug, Turn HID debugging mode on and off);
+module_param_named(debug, hid_debug, int, 0600);
+MODULE_PARM_DESC(debug, HID debugging (0=off, 1=probing info, 2=continuous
data dumping));
EXPORT_SYMBOL_GPL(hid_debug);
#endif
Index: linux-2.6.24-verbosehid/drivers/hid/hid-debug.c
===
--- linux-2.6.24-verbosehid/drivers/hid/hid-debug.c
+++ linux-2.6.24-verbosehid/drivers/hid/hid-debug.c 2008-03-21
13:01:21.0 +0200
@@ -498,7 +498,7 @@
EXPORT_SYMBOL_GPL(hid_dump_device);
void hid_dump_input(struct hid_usage *usage, __s32 value) {
- if (!hid_debug)
+ if (hid_debug 2)
return;
printk(KERN_DEBUG hid-debug: input );
--
Anssi Hannula
Re: [patch] xpad: match xbox 360 devices with interface info (fwd)
Andrew Morton wrote:
On Mon, 3 Mar 2008 17:57:08 +0100 (CET)
Jiri Kosina [EMAIL PROTECTED] wrote:
While Dmitry is lost ...
--
Jiri Kosina
SUSE Labs
-- Forwarded message --
Date: Tue, 26 Feb 2008 02:44:24 +0200
From: Anssi Hannula [EMAIL PROTECTED]
To: Dmitry Torokhov [EMAIL PROTECTED]
Cc: linux-input@atrey.karlin.mff.cuni.cz, Jan Kratochvil [EMAIL
PROTECTED]
Subject: [patch] xpad: match xbox 360 devices with interface info
Match Xbox 360 controllers using the interface info, i.e. interface
class 255 (Vendor specific), subclass 93 and protocol 1, instead of
specifying the device ids individually. As the class is vendor-specific,
we have to still match against vendor id as well, though.
this was hopelessly mangled: leading spaces removed, wordwrapped, etc.
Resend, please.
Hopefully better this time:
From: Anssi Hannula [EMAIL PROTECTED]
Subject: [patch] xpad: match xbox 360 devices with interface info
Match Xbox 360 controllers using the interface info, i.e. interface
class 255 (Vendor specific), subclass 93 and protocol 1, instead of
specifying the device ids individually. As the class is vendor-specific,
we have to still match against vendor id as well, though.
Signed-off-by: Anssi Hannula [EMAIL PROTECTED]
---
drivers/input/joystick/xpad.c | 21 -
1 files changed, 16 insertions(+), 5 deletions(-)
diff --git a/drivers/input/joystick/xpad.c b/drivers/input/joystick/xpad.c
index 0380597..f525d42 100644
--- a/drivers/input/joystick/xpad.c
+++ b/drivers/input/joystick/xpad.c
@@ -91,6 +91,7 @@
#define XTYPE_XBOX0
#define XTYPE_XBOX360 1
+#define XTYPE_UNKNOWN 2
static int dpad_to_buttons;
module_param(dpad_to_buttons, bool, S_IRUGO);
@@ -138,7 +139,7 @@ static const struct xpad_device {
{ 0x1430, 0x, TX6500+ Dance Pad (first generation),
MAP_DPAD_TO_BUTTONS, XTYPE_XBOX },
{ 0x045e, 0x028e, Microsoft X-Box 360 pad, MAP_DPAD_TO_AXES,
XTYPE_XBOX360 },
{ 0x, 0x, Chinese-made Xbox Controller, MAP_DPAD_TO_AXES,
XTYPE_XBOX },
- { 0x, 0x, Generic X-Box pad, MAP_DPAD_UNKNOWN, XTYPE_XBOX }
+ { 0x, 0x, Generic X-Box pad, MAP_DPAD_UNKNOWN, XTYPE_UNKNOWN }
};
static const signed short xpad_btn[] = {
@@ -173,12 +174,20 @@ static const signed short xpad_abs_pad[] = {
-1 /* terminating entry */
};
-/* Xbox 360 has a vendor-specific (sub)class, so we cannot match it with only
- * USB_INTERFACE_INFO, more to that this device has 4 InterfaceProtocols,
- * but we need only one of them. */
+/* Xbox 360 has a vendor-specific class, so we cannot match it with only
+ * USB_INTERFACE_INFO (also specifically refused by USB subsystem), so we
+ * match against vendor id as well. Also, some Xbox 360 devices have multiple
+ * interface protocols, we only need protocol 1. */
+#define XPAD_XBOX360_VENDOR(vend) \
+ .match_flags = USB_DEVICE_ID_MATCH_VENDOR |
USB_DEVICE_ID_MATCH_INT_INFO, \
+ .idVendor = (vend), \
+ .bInterfaceClass = USB_CLASS_VENDOR_SPEC, \
+ .bInterfaceSubClass = 93, \
+ .bInterfaceProtocol = 1
+
static struct usb_device_id xpad_table [] = {
{ USB_INTERFACE_INFO('X', 'B', 0) },/* X-Box USB-IF not approved
class */
- { USB_DEVICE_INTERFACE_PROTOCOL(0x045e, 0x028e, 1) }, /* X-Box 360
controller */
+ { XPAD_XBOX360_VENDOR(0x045e) },/* Microsoft X-Box 360
controllers */
{ }
};
@@ -645,6 +654,8 @@ static int xpad_probe(struct usb_interface *intf, const
struct usb_device_id *id
xpad-xtype = xpad_device[i].xtype;
if (xpad-dpad_mapping == MAP_DPAD_UNKNOWN)
xpad-dpad_mapping = dpad_to_buttons;
+ if (xpad-xtype == XTYPE_UNKNOWN)
+ xpad-xtype = (intf-cur_altsetting-desc.bInterfaceClass ==
USB_CLASS_VENDOR_SPEC);
xpad-dev = input_dev;
usb_make_path(udev, xpad-phys, sizeof(xpad-phys));
strlcat(xpad-phys, /input0, sizeof(xpad-phys));
--
Anssi Hannula
[patch] xpad: match xbox 360 devices with interface info
Match Xbox 360 controllers using the interface info, i.e. interface
class 255 (Vendor specific), subclass 93 and protocol 1, instead of
specifying the device ids individually. As the class is vendor-specific,
we have to still match against vendor id as well, though.
Signed-off-by: Anssi Hannula [EMAIL PROTECTED]
---
The previous patch used -1 for XTYPE_UNKNOWN, which didn't work
properly as the field is u8. Now using 2, and patch is confirmed
working properly.
drivers/input/joystick/xpad.c | 21 -
1 files changed, 16 insertions(+), 5 deletions(-)
diff --git a/drivers/input/joystick/xpad.c b/drivers/input/joystick/xpad.c
index 0380597..f525d42 100644
--- a/drivers/input/joystick/xpad.c
+++ b/drivers/input/joystick/xpad.c
@@ -91,6 +91,7 @@
#define XTYPE_XBOX0
#define XTYPE_XBOX360 1
+#define XTYPE_UNKNOWN 2
static int dpad_to_buttons;
module_param(dpad_to_buttons, bool, S_IRUGO);
@@ -138,7 +139,7 @@ static const struct xpad_device {
{ 0x1430, 0x, TX6500+ Dance Pad (first generation),
MAP_DPAD_TO_BUTTONS, XTYPE_XBOX },
{ 0x045e, 0x028e, Microsoft X-Box 360 pad, MAP_DPAD_TO_AXES,
XTYPE_XBOX360 },
{ 0x, 0x, Chinese-made Xbox Controller, MAP_DPAD_TO_AXES,
XTYPE_XBOX },
- { 0x, 0x, Generic X-Box pad, MAP_DPAD_UNKNOWN, XTYPE_XBOX }
+ { 0x, 0x, Generic X-Box pad, MAP_DPAD_UNKNOWN, XTYPE_UNKNOWN }
};
static const signed short xpad_btn[] = {
@@ -173,12 +174,20 @@ static const signed short xpad_abs_pad[] = {
-1 /* terminating entry */
};
-/* Xbox 360 has a vendor-specific (sub)class, so we cannot match it with only
- * USB_INTERFACE_INFO, more to that this device has 4 InterfaceProtocols,
- * but we need only one of them. */
+/* Xbox 360 has a vendor-specific class, so we cannot match it with only
+ * USB_INTERFACE_INFO (also specifically refused by USB subsystem), so we
+ * match against vendor id as well. Also, some Xbox 360 devices have multiple
+ * interface protocols, we only need protocol 1. */
+#define XPAD_XBOX360_VENDOR(vend) \
+ .match_flags = USB_DEVICE_ID_MATCH_VENDOR |
USB_DEVICE_ID_MATCH_INT_INFO, \
+ .idVendor = (vend), \
+ .bInterfaceClass = USB_CLASS_VENDOR_SPEC, \
+ .bInterfaceSubClass = 93, \
+ .bInterfaceProtocol = 1
+
static struct usb_device_id xpad_table [] = {
{ USB_INTERFACE_INFO('X', 'B', 0) },/* X-Box USB-IF not approved
class */
- { USB_DEVICE_INTERFACE_PROTOCOL(0x045e, 0x028e, 1) }, /* X-Box 360
controller */
+ { XPAD_XBOX360_VENDOR(0x045e) },/* Microsoft X-Box 360
controllers */
{ }
};
@@ -645,6 +654,8 @@ static int xpad_probe(struct usb_interface *intf, const
struct usb_device_id *id
xpad-xtype = xpad_device[i].xtype;
if (xpad-dpad_mapping == MAP_DPAD_UNKNOWN)
xpad-dpad_mapping = dpad_to_buttons;
+ if (xpad-xtype == XTYPE_UNKNOWN)
+ xpad-xtype = (intf-cur_altsetting-desc.bInterfaceClass ==
USB_CLASS_VENDOR_SPEC);
xpad-dev = input_dev;
usb_make_path(udev, xpad-phys, sizeof(xpad-phys));
strlcat(xpad-phys, /input0, sizeof(xpad-phys));
--
Anssi Hannula
[patch] xpad: match xbox 360 devices with interface info
Match Xbox 360 controllers using the interface info, i.e. interface
class 255 (Vendor specific), subclass 93 and protocol 1, instead of
specifying the device ids individually. As the class is vendor-specific,
we have to still match against vendor id as well, though.
Signed-off-by: Anssi Hannula [EMAIL PROTECTED]
---
drivers/input/joystick/xpad.c | 21 -
1 files changed, 16 insertions(+), 5 deletions(-)
diff --git a/drivers/input/joystick/xpad.c b/drivers/input/joystick/xpad.c
index 0380597..f525d42 100644
--- a/drivers/input/joystick/xpad.c
+++ b/drivers/input/joystick/xpad.c
@@ -91,6 +91,7 @@
#define XTYPE_XBOX0
#define XTYPE_XBOX360 1
+#define XTYPE_UNKNOWN -1
static int dpad_to_buttons;
module_param(dpad_to_buttons, bool, S_IRUGO);
@@ -138,7 +139,7 @@ static const struct xpad_device {
{ 0x1430, 0x, TX6500+ Dance Pad (first generation),
MAP_DPAD_TO_BUTTONS, XTYPE_XBOX },
{ 0x045e, 0x028e, Microsoft X-Box 360 pad, MAP_DPAD_TO_AXES,
XTYPE_XBOX360 },
{ 0x, 0x, Chinese-made Xbox Controller, MAP_DPAD_TO_AXES,
XTYPE_XBOX },
- { 0x, 0x, Generic X-Box pad, MAP_DPAD_UNKNOWN, XTYPE_XBOX }
+ { 0x, 0x, Generic X-Box pad, MAP_DPAD_UNKNOWN, XTYPE_UNKNOWN }
};
static const signed short xpad_btn[] = {
@@ -173,12 +174,20 @@ static const signed short xpad_abs_pad[] = {
-1 /* terminating entry */
};
-/* Xbox 360 has a vendor-specific (sub)class, so we cannot match it with only
- * USB_INTERFACE_INFO, more to that this device has 4 InterfaceProtocols,
- * but we need only one of them. */
+/* Xbox 360 has a vendor-specific class, so we cannot match it with only
+ * USB_INTERFACE_INFO (also specifically refused by USB subsystem), so we
+ * match against vendor id as well. Also, some Xbox 360 devices have multiple
+ * interface protocols, we only need protocol 1. */
+#define XPAD_XBOX360_VENDOR(vend) \
+ .match_flags = USB_DEVICE_ID_MATCH_VENDOR |
USB_DEVICE_ID_MATCH_INT_INFO, \
+ .idVendor = (vend), \
+ .bInterfaceClass = USB_CLASS_VENDOR_SPEC, \
+ .bInterfaceSubClass = 93, \
+ .bInterfaceProtocol = 1
+
static struct usb_device_id xpad_table [] = {
{ USB_INTERFACE_INFO('X', 'B', 0) },/* X-Box USB-IF not approved
class */
- { USB_DEVICE_INTERFACE_PROTOCOL(0x045e, 0x028e, 1) }, /* X-Box 360
controller */
+ { XPAD_XBOX360_VENDOR(0x045e) },/* Microsoft X-Box 360
controllers */
{ }
};
@@ -645,6 +654,8 @@ static int xpad_probe(struct usb_interface *intf, const
struct usb_device_id *id
xpad-xtype = xpad_device[i].xtype;
if (xpad-dpad_mapping == MAP_DPAD_UNKNOWN)
xpad-dpad_mapping = dpad_to_buttons;
+ if (xpad-xtype == XTYPE_UNKNOWN)
+ xpad-xtype = (intf-cur_altsetting-desc.bInterfaceClass ==
USB_CLASS_VENDOR_SPEC);
xpad-dev = input_dev;
usb_make_path(udev, xpad-phys, sizeof(xpad-phys));
strlcat(xpad-phys, /input0, sizeof(xpad-phys));
--
Anssi Hannula
[patch] xpad: add more xbox 360 controller vendors
Add Mad Catz and 0x0e6f xbox360 controllers which are found in
xpad_device[] table in xpad.c into the vendor id list. Also add
Logitech into the vendor list for Logitech Chillstream gamepads.
Signed-off-by: Anssi Hannula [EMAIL PROTECTED]
---
--- ./drivers/input/joystick/xpad.co2008-01-12 16:37:20.0 +0200
+++ ./drivers/input/joystick/xpad.c 2008-01-12 17:30:24.0 +0200
@@ -188,6 +188,9 @@
static struct usb_device_id xpad_table [] = {
{ USB_INTERFACE_INFO('X', 'B', 0) },/* X-Box USB-IF not approved
class */
{ XPAD_XBOX360_VENDOR(0x045e) },/* Microsoft X-Box 360
controllers */
+ { XPAD_XBOX360_VENDOR(0x046d) },/* Logitech X-Box 360 style
controllers */
+ { XPAD_XBOX360_VENDOR(0x0738) },/* Mad Catz X-Box 360
controllers */
+ { XPAD_XBOX360_VENDOR(0x0e6f) },/* 0x0e6f X-Box 360 controllers
*/
{ }
};
--
Anssi Hannula
Re: sysfs change of input/event devices in 2.6.23rc breaks udev
Dmitry Torokhov wrote: On Saturday 15 September 2007 04:05, Andrew Morton wrote: On Mon, 10 Sep 2007 09:24:04 -0400 Dmitry Torokhov [EMAIL PROTECTED] wrote: On 9/10/07, Greg KH [EMAIL PROTECTED] wrote: On Mon, Sep 10, 2007 at 01:28:47AM -0400, Dmitry Torokhov wrote: On Sunday 09 September 2007 19:03, Kay Sievers wrote: On 9/8/07, Anssi Hannula [EMAIL PROTECTED] wrote: However, the change that broke id_path of udev is that /sys/class/input/event5/device is now a symlink to the inputX directory instead of being the same as the device symlink in inputX directory, i.e. to ../../../devices/platform/pcspkr in this case. Udev id_path uses that directory to construct the ID_PATH variable. Should the sysfs structure be reverted or should udev be adapted to handle traversing /device symlink twice? I think the former, as there should be considerably more time to adapt udev for coming changes in sysfs. Udev's path_id script is too dumb to follow the device link of stacked class devices in the CONFIG_SYSFS_DEPRECATED=y layout. Does this change fix it for you? http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff_plain;h=b1ac36ff5e3756cefc79967a26280056da31bf6f Hmm, fixing udev is good but users will not get the change in time. I think we need to adjust SYSFS_DEPRECATED code to produce old results. Something like the patch below. I wonder what Greg would think... Hm, I don't understand. Didn't the original conversion of the input layer by Kay not have this kind of problem? What did your changes do differently to cause this driver core change to be needed? If I understand it correctly Kay's convesion had the same issue. With class devices device link points to class_dev-device instead of class_dev-parent. If you want to keep compatibility with old sysfs layout when moving from class devices to regular devices then you need to skip couple of parents till you get to real device. This only matters for input because this was the only subsystem with class devices stacked. wonders where the rest of this thread went to Limbo ;) Anssi, could you please tell me if the patch fixes the issue on your box? It does. Did this userspace-visible post-2.6.22 regression get fixed? I'd like the patch to go through Greg if he is OK with it. -- Anssi Hannula
sysfs change of input/event devices in 2.6.23rc breaks udev
Hi! There seem to be changes in sysfs input structure between 2.6.22 and 2.6.23-rc5 which cause some breakage. With 2.6.22: # LC_ALL=C ls -l /sys/class/input/input4 total 0 drwxr-xr-x 2 root root0 Sep 8 12:51 capabilities/ lrwxrwxrwx 1 root root0 Sep 8 19:48 device - ../../../devices/platform/pcspkr/ drwxr-xr-x 2 root root0 Sep 8 12:51 event4/ drwxr-xr-x 2 root root0 Sep 8 12:51 id/ -r--r--r-- 1 root root 4096 Sep 8 19:48 modalias -r--r--r-- 1 root root 4096 Sep 8 19:48 name -r--r--r-- 1 root root 4096 Sep 8 19:48 phys lrwxrwxrwx 1 root root0 Sep 8 19:48 subsystem - ../../../class/input/ --w--- 1 root root 4096 Sep 8 19:48 uevent -r--r--r-- 1 root root 4096 Sep 8 19:48 uniq # ls -l /sys/class/input/event4 lrwxrwxrwx 1 root root 0 Sep 8 19:48 /sys/class/input/event4 - ../../class/input/input4/event4/ # ls -l /sys/class/input/event4/ total 0 -r--r--r-- 1 root root 4096 Sep 8 19:58 dev lrwxrwxrwx 1 root root0 Sep 8 19:58 device - ../../../../devices/platform/pcspkr/ lrwxrwxrwx 1 root root0 Sep 8 19:58 subsystem - ../../../../class/input/ --w--- 1 root root 4096 Sep 8 19:58 uevent With 2.6.23-rc5: # ls -l /sys/class/input/input5 total 0 drwxr-xr-x 2 root root0 Sep 8 19:47 capabilities/ lrwxrwxrwx 1 root root0 Sep 8 19:03 device - ../../../devices/platform/pcspkr/ drwxr-xr-x 2 root root0 Sep 8 19:47 id/ lrwxrwxrwx 1 root root0 Sep 8 19:47 input:event5 - ../../../class/input/event5/ -r--r--r-- 1 root root 4096 Sep 8 19:03 modalias -r--r--r-- 1 root root 4096 Sep 8 19:03 name -r--r--r-- 1 root root 4096 Sep 8 19:47 phys drwxr-xr-x 2 root root0 Sep 8 19:47 power/ lrwxrwxrwx 1 root root0 Sep 8 19:03 subsystem - ../../../class/input/ -rw-r--r-- 1 root root 4096 Sep 8 19:03 uevent -r--r--r-- 1 root root 4096 Sep 8 19:47 uniq # ls -l /sys/class/input/event5 total 0 -r--r--r-- 1 root root 4096 Sep 8 19:03 dev lrwxrwxrwx 1 root root0 Sep 8 19:03 device - ../../../class/input/input5/ drwxr-xr-x 2 root root0 Sep 8 19:48 power/ lrwxrwxrwx 1 root root0 Sep 8 19:03 subsystem - ../../../class/input/ -rw-r--r-- 1 root root 4096 Sep 8 19:03 uevent There are a few changes. There is no longer: /sys/class/input/eventX = /sys/class/input/inputX/eventX instead there is: /sys/class/inputX/input:eventX = /sys/class/input/eventX Notice the added input:. I don't know if any software depends on this, though. However, the change that broke id_path of udev is that /sys/class/input/event5/device is now a symlink to the inputX directory instead of being the same as the device symlink in inputX directory, i.e. to ../../../devices/platform/pcspkr in this case. Udev id_path uses that directory to construct the ID_PATH variable. Should the sysfs structure be reverted or should udev be adapted to handle traversing /device symlink twice? I think the former, as there should be considerably more time to adapt udev for coming changes in sysfs. -- Anssi Hannula
Re: sysfs change of input/event devices in 2.6.23rc breaks udev
Andrey Borzenkov wrote:
Anssi Hannula wrote:
Hi!
There seem to be changes in sysfs input structure between 2.6.22 and
2.6.23-rc5 which cause some breakage.
[...]
There is no longer:
/sys/class/input/eventX = /sys/class/input/inputX/eventX
instead there is:
/sys/class/inputX/input:eventX = /sys/class/input/eventX
Notice the added input:. I don't know if any software depends on this,
though.
However, the change that broke id_path of udev is that
/sys/class/input/event5/device is now a symlink to the inputX directory
instead of being the same as the device symlink in inputX directory,
i.e. to ../../../devices/platform/pcspkr in this case.
Udev id_path uses that directory to construct the ID_PATH variable.
Should the sysfs structure be reverted or should udev be adapted to
handle traversing /device symlink twice? I think the former, as there
should be considerably more time to adapt udev for coming changes in
sysfs.
I am using 2.6.23-rc5 in current cooker
Same kernel here, but on an older system (MDV2007.1). I tested with a
path_id from a recent udev as well, though, but the problem was there as
well.
and I did not notice any breakage;
could you please show example of wrong path? E.g. I have
{pts/0}% LC_ALL=C ll /dev/input/by-path
total 0
lrwxrwxrwx 1 root root 9 Sep 2 15:00
platform-i8042-serio-0-event-kbd - ../event0
lrwxrwxrwx 1 root root 9 Sep 2 15:00
platform-i8042-serio-1-event-mouse - ../event1
lrwxrwxrwx 1 root root 9 Sep 2 15:00
platform-i8042-serio-1-mouse - ../mouse0
and it looks pretty sane for me.
I don't have anything under /dev/input/by-path as the lookup in path_id
fails.
Oh, and I do not have CONFIG_SYSFS_DEPRECATED which probably explains why it
works for me :)
Probably.
{pts/0}% LC_ALL=C ll /sys/class/input/input2/
total 0
drwxr-xr-x 2 root root0 Sep 8 22:25 capabilities/
drwxr-xr-x 3 root root0 Sep 8 22:22 event2/
drwxr-xr-x 2 root root0 Sep 8 22:25 id/
-r--r--r-- 1 root root 4096 Sep 8 22:25 modalias
-r--r--r-- 1 root root 4096 Sep 8 22:25 name
-r--r--r-- 1 root root 4096 Sep 8 22:25 phys
drwxr-xr-x 2 root root0 Sep 8 22:25 power/
lrwxrwxrwx 1 root root0 Sep 8 22:25
subsystem - ../../../../class/input/
-rw-r--r-- 1 root root 4096 Sep 8 22:25 uevent
-r--r--r-- 1 root root 4096 Sep 8 22:25 uniq
What does this print as devpath for you:
$ udevinfo -q all --name=input/event0
For me on 2.6.23rc5 it prints:
P: /class/input/event0
and on 2.6.22:
P: /class/input/input0/event0
Both are detected as old sysfs layout by path_id, but only on 2.6.22
is there a /device symlink pointing to the expected location.
I suspect it prints something like /devices/xyz for you, right?
That seems to be detected as new sysfs layout by path_id and handled
differently.
this implies that SYSFS_DEPRECATED may be broken w.r.t. udev; OTOH it *is*
deprecated, is not it?
Indeed, at least regarding input subsystem, for which there was a recent
switchover [1] from class_device.
[1]
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=9657d75c5f0f7d0a9cb507521d3ad1436aea28c9
--
Anssi Hannula
Re: Force Feedback: Thrustmaster FGT Wheel quick-and-dirty in hid-lgff.c or hid-tmff.c
Gerald Folcher wrote: Dmitry Torokhov wrote: I wonder if the attached is all that is needed for your wheel to work... No, but I think I understand where is the confusion: It won't work because my wheel is the Force Feedback model, not the Rumble Force model which is cheaper but looks exactly the same. With your patch applied as is, my wheel will neither do rumble effects nor constant force effects, the force feedback test utilities 'ffcfstress' and 'ffmvforce' will spit an error message on startup and exit. And 'fftest' will think my wheel can do Rumble but trying such effects will effectively trigger hazardous constant forces on my wheel. But your patch would maybe work for the actual Rumble wheel if you change the id to 0x651, which is the id of the Rumble version according to the MS-Windows registry on a machine where I installed the Thrustmaster drivers (the registry is full of id's of the wheels supported by the driver). While the id of my wheel (Force Feedback) is: 0x654 (and according to the aforementioned MS-Windows registry there is also an id 0x652 for a Thrustmaster wheel with the same name). Could you perhaps provide the kernel log output when you plug your device in with CONFIG_HID_DEBUG enabled in kernel configuration? Thanks, -- Anssi Hannula
Re: [patch] hid: fix autocentering of PID devices
Jiri Kosina wrote: On Thu, 14 Jun 2007, Anssi Hannula wrote: do you have any idea what caused this to happen in 2.6.21 and not in earlier versions? Nope. Do you think it would be useful for me to bisect 2.6.20-2.6.21? I'd of course happily merge the fix which initializes the value properly into my tree, but I would be curious what broke it, to double check that we didn't break anything else along with it. Okay, I'll get back to you in a few days :) -- Anssi Hannula
Re: Logitech Spring FF
johann deneux wrote: I'm forwarding this mail to linux-input, that's a better place for this discussion. Richard is working on adding support for spring force feedback effects to the hid-lgff driver. On 4/7/07, Richard Bolkey [EMAIL PROTECTED] wrote: johann deneux wrote: Yes. It's possible to implement everything using a constant force effect updated at regular intervals. Are you working to extending the driver in the kernel, or are you doing the work in user-space? Working off the driver in the kernel. Can/should I do this in user space? I also noticed with the latest kernels there is a ff-memless.c. I'm not sure. Doing in the kernel would allow for a shorter update cycle, I think. I had initially intended to do what you are doing in the kernel, but I never actually finished the task. The correct way to implement this is to do it in ff-memless.c, and it already has the framework to do effect conversions. One of the problem I remember encountering was related to computing sine values when simulating a periodic effect. Is there a math lib available in the kernel? There is your fixp-arith.h in /drivers/input and apparently some random math functions in /lib. (and I think the fixp-arith.h should really be in /lib as well) Is that an attempt to do all effect calculations in a single module, and a driver like hid-lgff.c would just need to do the device recognitions? I guess so, but you should check with the author. Yes, it is. -- Anssi Hannula
