Re: joydev.c and saitek cyborg evo force
On 11/08/07, Jiri Kosina <[EMAIL PROTECTED]> wrote:
> Force feedback functionality shouldn't be influenced in any means by this
> patch - FF implementation doesn't care about the values of the
> input_dev->abs{max,min,fuzz,flat}.
So it means the patch should work for all other joysticks as well?
That's good news... ;)
> But it is questionable whether your joystick is fully compliant with PID
> protocol or it implements some sort of vendor-specific one.
I wouldn't be surprised if it's vendor-specific, as their original
driver doesn't work quite well, I had to download a patched driver
from their website. Also, they seem to work it around (as I did) with
the auto-calibration.
Thanks for the help!
cheers,
--renato
Reclaim your digital rights, eliminate DRM, learn more at
http://www.defectivebydesign.org/what_is_drm
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: joydev.c and saitek cyborg evo force
On 10/08/07, Jiri Kosina <[EMAIL PROTECTED]> wrote: > does the attached patch (against 2.6.23-rc2) fix the problem with axis > ranges for you please? Hi Jiri, fixes perfectly. But it probably breaks the output range and kills the force-feedback. I couldn't find fftest for debian (the package with jstest doesn't have it) but I'll compile and run here to test. thanks, --renato Reclaim your digital rights, eliminate DRM, learn more at http://www.defectivebydesign.org/what_is_drm - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: joydev.c and saitek cyborg evo force
On 10/08/07, Jiri Kosina <[EMAIL PROTECTED]> wrote: > Renato, does force feedback work properly in Linux with this device? If > so, that would mean that the device has logical maximum and minimum for X > and Y axes different in input and output, and we would need to handle this > properly (we currently don't). Hi Jiri, Makes total sense to me. I've never tried force-feedback with it (or it never worked) as I don't know which games support it (I thought none did). I'll apply the patch and let you know. thanks! --renato Reclaim your digital rights, eliminate DRM, learn more at http://www.defectivebydesign.org/what_is_drm - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: joydev.c and saitek cyborg evo force
On 20/06/07, Jiri Kosina <[EMAIL PROTECTED]> wrote: Could you please send me the report descriptor of the device, so that I could debug it locally here? Hi Jiri, sorry for the delay, below the report descriptor and attached is the full report when I've connected the joystick. report descriptor (size 851, read 851) = 05 01 09 04 a1 01 09 01 a1 00 85 06 09 30 15 00 26 00 10 35 00 46 00 10 75 10 95 01 81 02 09 31 81 02 05 02 09 bb 26 ff 00 46 ff 00 75 08 81 02 05 09 19 01 29 0c 25 01 45 01 75 01 95 0c 81 02 05 01 09 39 25 07 46 3b 01 55 00 65 44 75 04 95 01 81 42 65 00 05 02 09 ba 26 ff 00 46 ff 00 75 08 81 02 c0 05 0f 09 92 a1 02 85 02 09 a6 09 a4 09 a0 09 9f 25 01 45 00 75 01 95 04 81 02 75 04 95 01 81 03 09 22 75 07 25 09 81 02 09 94 75 01 25 01 81 02 75 08 81 03 c0 09 21 a1 02 85 0b 09 22 25 09 91 02 09 25 a1 02 09 26 09 30 09 32 09 31 09 33 09 34 09 40 09 41 15 01 25 08 91 00 c0 09 53 25 0c 75 05 91 02 09 56 15 00 25 01 75 01 91 02 09 55 a1 02 05 01 09 30 09 31 95 02 91 02 c0 05 0f 09 50 27 fe ff 00 00 47 fe ff 00 00 75 10 95 01 55 fd 66 01 10 91 02 55 00 65 00 09 57 26 ff 00 46 68 01 75 08 65 44 91 02 65 00 09 54 27 fe ff 00 00 47 fe ff 00 00 75 10 55 fd 66 01 10 91 02 55 00 65 00 09 58 a1 02 05 0a 09 01 09 02 26 2b 01 45 00 95 02 91 02 c0 05 0f 09 a7 27 fe ff 00 00 47 fe ff 00 00 95 01 55 fd 66 01 10 91 02 55 00 65 00 c0 09 5a a1 02 85 0c 09 23 26 2b 01 45 00 91 02 09 5c 26 10 27 46 10 27 55 fd 66 01 10 91 02 55 00 65 00 09 5b 25 7f 75 08 91 02 09 5e 26 10 27 75 10 55 fd 66 01 10 91 02 55 00 65 00 09 5d 25 7f 75 08 91 02 c0 09 73 a1 02 85 0d 09 23 26 2b 01 45 00 75 10 91 02 09 70 15 81 25 7f 36 f0 d8 46 10 27 75 08 91 02 c0 09 6e a1 02 85 0e 09 23 15 00 26 2b 01 35 00 45 00 75 10 91 02 09 70 25 7f 46 10 27 75 08 91 02 09 6f 15 81 36 f0 d8 91 02 09 71 15 00 26 ff 00 35 00 46 68 01 91 02 09 72 26 10 27 46 10 27 75 10 55 fd 66 01 10 91 02 55 00 65 00 c0 09 5f a1 02 85 0f 09 23 26 2b 01 45 00 91 02 09 61 15 9c 25 64 36 f0 d8 46 10 27 75 08 91 02 09 62 91 02 09 60 16 0c fe 26 f4 01 75 10 91 02 09 65 15 00 26 e8 03 35 00 91 02 09 63 25 64 75 08 91 02 09 64 91 02 c0 09 77 a1 02 85 51 09 22 25 09 45 00 91 02 09 78 a1 02 09 7b 09 79 09 7a 15 01 25 03 91 00 c0 09 7c 15 00 26 fe 00 91 02 c0 09 92 a1 02 85 52 09 96 a1 02 09 9a 09 99 09 97 09 98 09 9b 09 9c 15 01 25 06 91 00 c0 c0 05 ff 0a 01 03 a1 02 85 40 0a 02 03 a1 02 1a 11 03 2a 20 03 25 10 91 00 c0 0a 03 03 15 00 27 ff ff 00 00 75 10 91 02 c0 05 0f 09 7d a1 02 85 43 09 7e 26 80 00 46 10 27 75 08 91 02 c0 09 85 a1 02 85 44 09 86 27 ff ff 00 00 45 00 75 10 91 02 09 87 91 02 09 88 91 02 c0 05 ff 0a 00 01 a1 02 85 81 05 01 09 30 15 81 25 7f 36 f0 d8 46 10 27 75 08 91 02 09 31 91 02 c0 05 0f 09 7f a1 02 85 0b 09 80 15 00 26 ff 7f 35 00 45 00 75 0f b1 03 09 a9 25 01 75 01 b1 03 09 83 26 ff 00 75 08 b1 03 09 84 25 10 b1 03 09 a8 a1 02 09 73 09 6e 09 5a 09 5f 95 04 b1 03 c0 c0 c0 cheers, --renato Reclaim your digital rights, eliminate DRM, learn more at http://www.defectivebydesign.org/what_is_drm joy-dmesg.log.gz Description: GNU Zip compressed data
Re: joydev.c and saitek cyborg evo force
On 12/06/07, Jiri Kosina <[EMAIL PROTECTED]> wrote: could you please apply the stupid patch below (against 2.6.20, I know you are using it :) ) and report the result? It should show us whether the values 0 and 4096 (which can be seen in your hid parsing debug dump) are correctly passed from HID to input, or they are garbled inside the hid layer somewhere already. Hi Jiri, Applied your patch and the log is below, thanks! --renato [ 6944.776870] input: USB HID v1.00 Joystick [Saitek Cyborg Evo Force] on usb-:00:0b.0-7 [ 6944.777254] usbcore: registered new interface driver usbhid [ 6944.790141] drivers/usb/input/hid-core.c: v2.6:USB HID core driver [ 6973.503388] usbcore: deregistering interface driver usbhid [ 6973.515956] usbcore: deregistering interface driver hiddev [ 6973.565396] usbcore: registered new interface driver hiddev [ 6973.571885] Key.LeftBtn [ 6973.571893] Key.RightBtn [ 6973.571901] Key.MiddleBtn [ 6973.571909] Relative.X [ 6973.571916] Relative.Y [ 6973.571924] Relative.Wheel [ 6973.573896] input: Dell Dell USB Mouse as /class/input/input40 [ 6973.574160] input: USB HID v1.10 Mouse [Dell Dell USB Mouse] on usb-:00:0b.0-3 [ 6973.587817] hid-debug: input GenericDesktop.X = 2056 [ 6973.587824] hid-debug: input GenericDesktop.Y = 2064 [ 6973.587829] hid-debug: input Simulation.Throttle = 130 [ 6973.587834] hid-debug: input Button.0001 = 0 [ 6973.587839] hid-debug: input Button.0002 = 0 [ 6973.587843] hid-debug: input Button.0003 = 0 [ 6973.587847] hid-debug: input Button.0004 = 0 [ 6973.587852] hid-debug: input Button.0005 = 0 [ 6973.587856] hid-debug: input Button.0006 = 0 [ 6973.587860] hid-debug: input Button.0007 = 0 [ 6973.587864] hid-debug: input Button.0008 = 0 [ 6973.587868] hid-debug: input Button.0009 = 0 [ 6973.587872] hid-debug: input Button.000a = 0 [ 6973.587876] hid-debug: input Button.000b = 0 [ 6973.587880] hid-debug: input Button.000c = 0 [ 6973.587885] hid-debug: input GenericDesktop.HatSwitch = 15 [ 6973.587889] hid-debug: input Simulation.Rudder = 255 [ 6973.588816] hid-debug: input PhysicalInterfaceDevice.00a6 = 1 [ 6973.588823] hid-debug: input PhysicalInterfaceDevice.00a4 = 1 [ 6973.588827] hid-debug: input PhysicalInterfaceDevice.00a0 = 0 [ 6973.588832] hid-debug: input PhysicalInterfaceDevice.009f = 0 [ 6973.588837] hid-debug: input PhysicalInterfaceDevice.0022 = 7 [ 6973.588841] hid-debug: input PhysicalInterfaceDevice.0094 = 0 [ 6973.589816] hid-debug: input PhysicalInterfaceDevice.0080 = 300 [ 6973.589822] hid-debug: input PhysicalInterfaceDevice.00a9 = 0 [ 6973.589826] hid-debug: input PhysicalInterfaceDevice.0083 = 10 [ 6973.589831] hid-debug: input PhysicalInterfaceDevice.0084 = 2 [ 6973.589836] hid-debug: input PhysicalInterfaceDevice.0073 = 1 [ 6973.589841] hid-debug: input PhysicalInterfaceDevice.006e = 12 [ 6973.589845] hid-debug: input PhysicalInterfaceDevice.005a = 12 [ 6973.589850] hid-debug: input PhysicalInterfaceDevice.005f = 8 [ 6973.596010] calling input_set_abs_params, code: 0, min: 0, max: 1000, fuzz: 10, flat: 100 [ 6973.596013] Absolute.X [ 6973.596022] calling input_set_abs_params, code: 1, min: 0, max: 1000, fuzz: 10, flat: 100 [ 6973.596024] Absolute.Y [ 6973.596033] calling input_set_abs_params, code: 6, min: 0, max: ff, fuzz: 0, flat: f [ 6973.596035] Absolute.Throttle [ 6973.596043] Key.Trigger [ 6973.596050] Key.ThumbBtn [ 6973.596058] Key.ThumbBtn2 [ 6973.596070] Key.TopBtn [ 6973.596077] Key.TopBtn2 [ 6973.596084] Key.PinkieBtn [ 6973.596091] Key.BaseBtn [ 6973.596099] Key.BaseBtn2 [ 6973.596106] Key.BaseBtn3 [ 6973.596113] Key.BaseBtn4 [ 6973.596120] Key.BaseBtn5 [ 6973.596128] Key.BaseBtn6 [ 6973.596136] calling input_set_abs_params, code: 10, min: 0, max: 7, fuzz: 0, flat: 0 [ 6973.596139] Absolute.Hat0X [ 6973.596147] calling input_set_abs_params, code: 7, min: 0, max: ff, fuzz: 0, flat: f [ 6973.596149] Absolute.Rudder [ 6973.596157] IGNORED [ 6973.596165] Key.BtnDead [ 6973.596172] IGNORED [ 6973.596180] IGNORED [ 6973.596187] IGNORED [ 6973.596194] IGNORED [ 6973.596201] IGNORED [ 6973.596208] IGNORED [ 6973.596215] IGNORED [ 6973.596223] IGNORED [ 6973.596230] IGNORED [ 6973.596237] IGNORED [ 6973.596244] IGNORED [ 6973.596251] IGNORED [ 6973.596258] IGNORED [ 6973.596265] IGNORED [ 6973.596272] IGNORED [ 6973.596280] calling input_set_abs_params, code: 0, min: 0, max: 1, fuzz: 0, flat: 0 [ 6973.596282] Absolute.X [ 6973.596290] calling input_set_abs_params, code: 1, min: 0, max: 1, fuzz: 0, flat: 0 [ 6973.596292] Absolute.Y [ 6973.596300] IGNORED [ 6973.596307] IGNORED [ 6973.596314] IGNORED [ 6973.596322] calling input_set_abs_params, code: 28, min: 0, max: 12b, fuzz: 1, flat: 12 [ 6973.596324] Absolute.Misc [ 6973.596333] calling input_set_abs_params, code: 29, min: 0, max: 12b, fuzz: 1, flat: 12 [ 6973.596335] Absolute.? [ 6973.596343] IGNORED [ 6973.596350] IGNORED [ 6973.596357] IGNORED [ 6973.596364] IGNORED [ 6973.596371] IGNORED [ 6973.596379] IGNORED [ 6973.596386] IGNORED [ 6973.596393] IGNORED [ 6973.5
Re: joydev.c and saitek cyborg evo force
On 12/06/07, Dmitry Torokhov <[EMAIL PROTECTED]> wrote: We need to find out why you see [-127, 127] range, because if joydev would see [0, 4096] range it would perform automatic correction and map values like this: c0: 2048, c1: 2048, c2: 262144, c3: 262144 Hi Dmitry, That's the values I got *after* calibration. Before, because the correction is set to a small signed value, it corrects wrongly and report a random mix of signed and unsigned values when moving in one direction... Which is fine as far as I can see. What utility did you use that reported [-127; 127] range? At joydev_connect, the last parameter "input_dev" reports me that range (dev->absmax[i] and dev->absmin[i]). When I turned on HID_DEBUG it reported [0, 4096] for both axis 0 and 1, which is correct so it must be between HID and joydev. My point is that the auto-calibration could automagically solve all range problems in all devices by zeroing the range and adapting the ranges afterwards. If it can affect other devices as well as joysticks, the calibration could happen in HID instead of joydev. cheers, --renato Reclaim your digital rights, eliminate DRM, learn more at http://www.defectivebydesign.org/what_is_drm - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: joydev.c and saitek cyborg evo force
On 12/06/07, Jiri Kosina <[EMAIL PROTECTED]> wrote: the thing is that the aim of this quirk is to normalize the values that are being reported by bogus devices, so we don't really want to trust the values they provide here, do we? Hi Jiri, I don't know about the other joysticks, but Saitek did reported [0, 4096] which is the right answer, but between HID and Joydev it was converted to [-127, 127]. I thought that the quirk was about that. But seeing the quirk code it seems that if the range doesn't match it forces [0, 256] (not trusting anything the device sends) and that's not really needed for Saitek. I'm not at all sure how the other devices behave and I do understand the difficulty in testing every single one. My opinion is that we shouldn't fall back to a hard-coded range for all types of errors and rely on user calibration. Normally, game users tend to dislike having to quit the game and recalibrate the joystick to restart the game again (I do, at least). Furthermore, dealing with every single type of error is impossible unless you have all devices available for a recursive test every time something change, which is not true. Therefore, my view is that the only neat solution to all that is to report the range as [0, 0] and auto-calibrate afterwards, while the device is in use and reporting the real range. I found out that, not all times the range goes to 4096, most of the time it stays as far as 4038, and setting the final range to that value (with auto-calibration) is even more precise than the reported by the device. The drawback is the few calculations done during the first movements of the joystick (function call and four small formulas) and the two "IF (a > b)" for every axis event afterwards. As this is my first kernel mode code I'm not sure how would that schedule with other kernel processes (normally I rely on kernel's scheduling process) but for a user-land program (real-time games included) I wouldn't say it's too much overhead. Let me know if I got it all backwards... ;) cheers, --renato Reclaim your digital rights, eliminate DRM, learn more at http://www.defectivebydesign.org/what_is_drm - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: joydev.c and saitek cyborg evo force
On 04/06/07, Renato Golin <[EMAIL PROTECTED]> wrote: > Well calibration using jscal might be needed, that should be fine. The > question is whether the ranges are now correct and calibration using jscal > works fine. Ok, so maybe in that case my automatic calibration is still worth to put on joydev.c and users from all joysticks in the quirk list would benefit. Hi Dmitry, The patch to joydev.c was updated on Andrew's list do you see any problem with it? cheers, --renato Reclaim your digital rights, eliminate DRM, learn more at http://www.defectivebydesign.org/what_is_drm - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: joydev.c and saitek cyborg evo force
On 04/06/07, Jiri Kosina <[EMAIL PROTECTED]> wrote:
sorry, don't fully understand - what do you mean by "got the messages but
not the fix"?
The range "detected" was 0 to 255 but both X and Y axis are reporting 4096.
I think that the code in drivers/hid/hid-input.c:
if ((device->quirks & HID_QUIRK_BADPAD) && (usage->code == ABS_X ||
usage->code == ABS_Y)) {
a = field->logical_minimum = 0;
b = field->logical_maximum = 255;
}
should get what's being reported from the device instead of hard-code
to 0 to 255 (which might not even be an unsigned range).
Well calibration using jscal might be needed, that should be fine. The
question is whether the ranges are now correct and calibration using jscal
works fine.
Ok, so maybe in that case my automatic calibration is still worth to
put on joydev.c
and users from all joysticks in the quirk list would benefit.
So please let me know whether the badpad quirk is the correct one for this
joystick. If so, I'll queue it in my tree for upstream.
Well, it did the trick if that's what you mean but would be better to
get the correct range from start... But I don't know how difficult it
is, so maybe we'll have to stick with the automatic calibration
afterwards...
cheers,
--renato
Reclaim your digital rights, eliminate DRM, learn more at
http://www.defectivebydesign.org/what_is_drm
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: joydev.c and saitek cyborg evo force
On 03/06/07, Jiri Kosina <[EMAIL PROTECTED]> wrote: Please try this patch on top of 2.6.20 Hi Jiri, Patched and run, we're almost there... I put an additional printk on usb/input/hid-core.c and hid/hid-input.c to assure I got the right copy, got the messages but not the fix. What joydev reports is a range between 0 and 255, which is better than -127 to 127 because it's unsigned but still requires further calibration. I have never used ubuntu, but why should that be that difficult? Just download vanilla kernel from kernel.org, use your distro's .config, make oldconfig && make ... ? The kernel is really simple, problem is that I use ubuntu since version 5 and did distupgrade to 6.06, 6.10 and now 7.04. Lots of configurations were changed, /dev structure, root points, mount, lvm and lots of changes were made since then. What's annoying me to get a personalized kernel now running is the lvm new configuration that I don't master yet (nor am willing to lately) and that's the only thing that breaks on my ubuntu with a personalized kernel. The filesystem changes were quite messy, on 6.10 I lost my swap space (kernel couldn't mount it) and I didn't have time to investigate properly. Now, with 7.04 it's back again... I'm too old to investigate every detail... ;) I'm sure if I get a fresh installation, kernel.org's kernel will work like a charm... cheers, --renato Reclaim your digital rights, eliminate DRM, learn more at http://www.defectivebydesign.org/what_is_drm - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: joydev.c and saitek cyborg evo force
On 31/05/07, Jiri Kosina <[EMAIL PROTECTED]> wrote: Yes, the problem with axis ranges definitely looks like that. Renato, could you please send me vendor id and product id of the joystick in question, I will send you a patch to test whether normalizing the values on hid-level (as we already do for several other joypads) will do the trick? Hi Jiri, 06a3:ffb5 Saitek PLC I'm using 2.6.20 and compiling new kernels for Ubuntu is a nightmare. Also, would be good not to need additional parameters for the general public. cheers, --renato Reclaim your digital rights, eliminate DRM, learn more at http://www.defectivebydesign.org/what_is_drm - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: joydev.c and saitek cyborg evo force
On 30/05/07, Renato Golin <[EMAIL PROTECTED]> wrote: On 30/05/07, Jiri Kosina <[EMAIL PROTECTED]> wrote: > do any data appear in the kernel log when you generate events with the > device (i.e. move the joystick, press the buttons, etc)? That should be > reported if DEBUG_DATA is defined properly on the older kernels. Hi Jiri, at last!! HID is reporting the axis' range correctly: May 30 23:19:07 jobim kernel: [ 3316.543445] hid-debug: input GenericDesktop.X = 2044 May 30 23:19:07 jobim kernel: [ 3316.543451] hid-debug: input GenericDesktop.Y = 2044 (...) May 30 23:19:07 jobim kernel: [ 3316.545490] INPUT(6)[INPUT] May 30 23:19:07 jobim kernel: [ 3316.545495] Field(0) May 30 23:19:07 jobim kernel: [ 3316.545499] Physical(GenericDesktop.Pointer) May 30 23:19:07 jobim kernel: [ 3316.545506] Usage(1) May 30 23:19:07 jobim kernel: [ 3316.545510] GenericDesktop.X May 30 23:19:07 jobim kernel: [ 3316.545517] Logical Minimum(0) May 30 23:19:07 jobim kernel: [ 3316.545522] Logical Maximum(4096) May 30 23:19:07 jobim kernel: [ 3316.545526] Physical Minimum(0) May 30 23:19:07 jobim kernel: [ 3316.545531] Physical Maximum(4096) May 30 23:19:07 jobim kernel: [ 3316.545536] Report Size(16) May 30 23:19:07 jobim kernel: [ 3316.545540] Report Count(1) May 30 23:19:07 jobim kernel: [ 3316.545545] Report Offset(0) May 30 23:19:07 jobim kernel: [ 3316.545550] Flags( Variable Absolute ) May 30 23:19:07 jobim kernel: [ 3316.545558] Field(1) May 30 23:19:07 jobim kernel: [ 3316.545562] Physical(GenericDesktop.Pointer) May 30 23:19:07 jobim kernel: [ 3316.545568] Usage(1) May 30 23:19:07 jobim kernel: [ 3316.545573] GenericDesktop.Y May 30 23:19:07 jobim kernel: [ 3316.545579] Logical Minimum(0) May 30 23:19:07 jobim kernel: [ 3316.545584] Logical Maximum(4096) May 30 23:19:07 jobim kernel: [ 3316.545588] Physical Minimum(0) May 30 23:19:07 jobim kernel: [ 3316.545593] Physical Maximum(4096) May 30 23:19:07 jobim kernel: [ 3316.545597] Report Size(16) May 30 23:19:07 jobim kernel: [ 3316.545602] Report Count(1) May 30 23:19:07 jobim kernel: [ 3316.545607] Report Offset(16) May 30 23:19:07 jobim kernel: [ 3316.545611] Flags( Variable Absolute ) Now, why joydev's input_dev is reporting -127, 127 just for the two first axis? Another problem is that the joystick reports 12 (1-12) buttons and joydev get's 0-12 (13 buttons): May 30 23:19:07 jobim kernel: [ 3316.543461] hid-debug: input Button.0001 = 0 May 30 23:19:07 jobim kernel: [ 3316.543466] hid-debug: input Button.0002 = 0 May 30 23:19:07 jobim kernel: [ 3316.543470] hid-debug: input Button.0003 = 0 May 30 23:19:07 jobim kernel: [ 3316.543474] hid-debug: input Button.0004 = 0 May 30 23:19:07 jobim kernel: [ 3316.543478] hid-debug: input Button.0005 = 0 May 30 23:19:07 jobim kernel: [ 3316.543482] hid-debug: input Button.0006 = 0 May 30 23:19:07 jobim kernel: [ 3316.543486] hid-debug: input Button.0007 = 0 May 30 23:19:07 jobim kernel: [ 3316.543490] hid-debug: input Button.0008 = 0 May 30 23:19:07 jobim kernel: [ 3316.543494] hid-debug: input Button.0009 = 0 May 30 23:19:07 jobim kernel: [ 3316.543498] hid-debug: input Button.000a = 0 May 30 23:19:07 jobim kernel: [ 3316.543502] hid-debug: input Button.000b = 0 May 30 23:19:07 jobim kernel: [ 3316.543506] hid-debug: input Button.000c = 0 cheers, --renato Reclaim your digital rights, eliminate DRM, learn more at http://www.defectivebydesign.org/what_is_drm - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: joydev.c and saitek cyborg evo force
On 30/05/07, Jiri Kosina <[EMAIL PROTECTED]> wrote: do any data appear in the kernel log when you generate events with the device (i.e. move the joystick, press the buttons, etc)? That should be reported if DEBUG_DATA is defined properly on the older kernels. Not at all... only my own debug messages from joydev (like: recalibrating for value 2048) when a new limit is reached. I've even changed "printk(KERN_DEBUG ...)" to a plain printk() as I do on joydev to avoid fall into the wrong log level but didn't work as well. I've changed USB DEBUG in menuconfig, saved the new conf. The files I've changed manually (undef -> define) were: -> drivers/hid/ hid-core.c:#undef DEBUG hid-core.c:#undef DEBUG_DATA hid-input.c:#undef DEBUG -> drivers/usb/input/ hid-core.c:#undef DEBUG hid-core.c:#undef DEBUG_DATA hid-ff.c:#undef DEBUG hid-tmff.c:#undef DEBUG than $ make drivers/hid/hid.ko drivers/usb/input/usbhid.ko $ rmmod usbhid hid ; modprobe usbhid hid the output from the last mail was on both /var/log/messages and syslog, although syslog had other messages from the network card (using ndiswrapper). cheers, --renato Reclaim your digital rights, eliminate DRM, learn more at http://www.defectivebydesign.org/what_is_drm - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: joydev.c and saitek cyborg evo force
On 30/05/07, Jiri Kosina <[EMAIL PROTECTED]> wrote: well I have changed the overall HID code design in 2.6.21 a little bit. Anyway, just hardcoding '#define DEBUG' and '#define DEBUG_DATA' (that's also important) in 2.6.20-and-older kernels should have similar result as CONFIG_HID_DEBUG in post-2.6.21. In your particular case, the DEBUG_DATA might really be more interesting. Yup, did both on all drivers/hid/*.c and drivers/usb/input/hid*.c recompiled and reloaded all modules (hid.ko, usbhid.ko and joydev.ko) But it's pathetic the fact that ubuntu's kernel have an option USB_DEBUG and on Makefile is says "if USB_DEBUG; aditional_opt= -DDEBUG" but inside the files all DEBUG flags are hardcoded undefined. Also, to turn on KERN_DEBUG messages I saw on kernel hacking webpages: $ echo 15 15 15 15 > /proc/sys/kernel/printk $ echo 8 > /proc/sys/kernel/printk I did it and monitored mesasges and syslog and both shows the same data... I guess that dump after mouse detection is DEBUG_DATA in place. cheers, --renato Reclaim your digital rights, eliminate DRM, learn more at http://www.defectivebydesign.org/what_is_drm - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: joydev.c and saitek cyborg evo force
On 21/05/07, Jiri Kosina <[EMAIL PROTECTED]> wrote:
could you please turn on the HID debugging support ("Device Drivers -> HID
devices -> HID debugging support" in menuconfig of any reasonably recent
kernel) and show the output that appears when the joystick is plugged in,
and also when you generate the events that are messed up? This would
hopefully avoid any confusion regarding what is really going on and we'll
see what we can do with it.
Hi Jiri,
Couldn't make the generic kernel work on Ubuntu, it's quite a mess.
The distro kernel have USB general debugging instead of HID_DEBUG but
I had to manually redefine DEBUG and DEBUG_DATA on all hid*.c sources
and recompile the modules.
The HID sources are quite different from 2.6.21 and 2.6.20 but I don't
know how much was because Canonical guys and how much it really
changed. :( I will eventually put a Gentoo on my old laptop and try it
for real, sorry I couldn't be of much help now...
The only additional thing I got from debugging hid.ko and usbhid.ko
was right after detecting the mouse so I guess it didn't help at all.
--renato
May 30 00:40:06 jobim kernel: [ 7151.757499] usbcore: deregistering
interface driver usbhid
May 30 00:40:06 jobim kernel: [ 7151.769001] usbcore: deregistering
interface driver hiddev
May 30 00:40:06 jobim kernel: [ 7151.786229] usbcore: registered new
interface driver hiddev
May 30 00:40:06 jobim kernel: [ 7151.792457] input: Dell Dell USB
Mouse as /class/input/input56
May 30 00:40:06 jobim kernel: [ 7151.792816] input: USB HID v1.10
Mouse [Dell Dell USB Mouse] on usb-:00:0b.0-3
May 30 00:40:06 jobim kernel: [ 7151.807413] input: Saitek Cyborg Evo
Force as /class/input/input57
May 30 00:40:06 jobim kernel: [ 7151.807766] input: USB HID v1.00
Joystick [Saitek Cyborg Evo Force] on usb-:00:0b.0-7
May 30 00:40:06 jobim kernel: [ 7151.808122] usbcore: registered new
interface driver usbhid
May 30 00:40:06 jobim kernel: [ 7151.808328]
drivers/usb/input/hid-core.c: v2.6:USB HID core driver
May 30 00:41:54 jobim kernel: [ 7260.252015] usbcore: deregistering
interface driver usbhid
May 30 00:41:54 jobim kernel: [ 7260.258180] usbcore: deregistering
interface driver hiddev
May 30 00:41:54 jobim kernel: [ 7260.276444] usbcore: registered new
interface driver hiddev
May 30 00:41:54 jobim kernel: [ 7260.293406] input: Dell Dell USB
Mouse as /class/input/input58
May 30 00:41:54 jobim kernel: [ 7260.293709] input: USB HID v1.10
Mouse [Dell Dell USB Mouse] on usb-:00:0b.0-3
May 30 00:41:54 jobim kernel: 09 02 26 2b 01 45 00 95 02 91 02 c0 05
0f 09 a7 27 fe ff 00 00 47 fe ff 00 00 95 01 55 fd 66 01 10 91 02 55
00 65 00 c0 09 5a a1 02 85 0c 09 23 26 2b 01 45 00 91 02 09 5c 26 10
27 46 10 27 55 fd 66 01 10 91 02 55 00 65 00 09 5b 25 7f 75 08 91 02
09 5e 26 10 27 75 10 55 fd 66 01 10 91 02 55 00 65 00 09 5d 25 7f 75
08 91 02 c0 09 73 a1 02 85 0d 09 23 26 2b 01 45 00 75 10 91 02 09 70
15 81 25 7f 36 f0 d8 46 10 27 75 08 91 02 c0 09 6e a1 02 85 0e 09 23
15 00 26 2b 01 35 00 45 00 75 10 91 02 09 70 25 7f 46 10 27 75 08 91
02 09 6f 15 81 36 f0 d8 91 02 09 71 15 00 26 ff 00 35 00 46 68 01 91
02 09 72 26 10 27 46 10 27 75 10 55 fd 66 01 10 91 02 55 00 65 00 c0
09 5f a1 02 85 0f 09 23 26 2b 01 45 00 91 02 09 61 15 9c 25 64 36 f0
d8 46 10 27 75 08 91 02 09 62 91 02 09 60 16 0c fe 26 f4 01 75 10 91
02 09 65 15 00 26 e8 03 35 00 91 02 09 63 25 64 75 08 91 02 09 64 91
02 c0 09 77 a1 02 85 51 09 22 25 09 45 00 91 02 09 78 a1 02 09 7b 09
79 09 7a 15 01 25 03 91 00 c0 09 7c 15 00 26 fe 00 91 02 c0
May 30 00:41:54 jobim kernel: 92 a1 02 85 52 09 96 a1 02 09 9a 09 99
09 97 09 98 09 9b 09 9c 15 01 25 06 91 00 c0 c0 05 ff 0a 01 03 a1 02
85 40 0a 02 03 a1 02 1a 11 03 2a 20 03 25 10 91 00 c0 0a 03 03 15 00
27 ff ff 00 00 75 10 91 02 c0 05 0f 09 7d a1 02 85 43 09 7e 26 80 00
46 10 27 75 08 91 02 c0 09 85 a1 02 85 44 09 86 27 ff ff 00 00 45 00
75 10 91 02 09 87 91 02 09 88 91 02 c0 05 ff 0a 00 01 a1 02 85 81 05
01 09 30 15 81 25 7f 36 f0 d8 46 10 27 75 08 91 02 09 31 91 02 c0 05
0f 09 7f a1 02 85 0b 09 80 15 00 26 ff 7f 35 00 45 00 75 0f b1 03 09
a9 25 01 75 01 b1 03 09 83 26 ff 00 75 08 b1 03 09 84 25 10 b1 03 09
a8 a1 02 09 73 09 6e 09 5a 09 5f 95 04 b1 03 c0 c0 c0
May 30 00:41:54 jobim kernel: [ 7260.320561] input: Saitek Cyborg Evo
Force as /class/input/input59
May 30 00:41:54 jobim kernel: [ 7260.320633] input: USB HID v1.00
Joystick [Saitek Cyborg Evo Force] on usb-:00:0b.0-7
May 30 00:41:54 jobim kernel: [ 7260.320654] usbcore: registered new
interface driver usbhid
May 30 00:41:54 jobim kernel: [ 7260.320660]
drivers/usb/input/hid-core.c: v2.6:USB HID core driver
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: joydev.c and saitek cyborg evo force
On 21/05/07, Jiri Kosina <[EMAIL PROTECTED]> wrote:
could you please turn on the HID debugging support ("Device Drivers -> HID
devices -> HID debugging support" in menuconfig of any reasonably recent
kernel) and show the output that appears when the joystick is plugged in,
and also when you generate the events that are messed up? This would
hopefully avoid any confusion regarding what is really going on and we'll
see what we can do with it.
Hi Jiri,
I was changing joydev.c in a tainted kernel (ubuntu 2.6.20) but with
an unchanged joy structure. I'm still trying to make the new kernel
(from kernel.org) run on my box but I'm getting a device-mapper error
several times per second and it seems is something related to mdadm
raid software it was installed. Will continue to try and get the HID
debug messages (as ubuntu's source doesn't have it)
Apart from that, I did the auto calibration for two reasons:
1. getting the min/max information from input_dev, the device was
giving me -127/127 instead of 0/4096. The problem can be below the
joydev.c level, on HID (as you say) but there's a second reason.
2. The windows driver, developed by saitek itself (I suppose) have
exactly the same behaviour. Every time I plug the joy in it's
uncalibrated, than I have to move around a few times and play. Not
much harassment, but I believe that, if they did it in their own
driver it's because they don't trust their own hardware.
Anyway, I'll continue with the kernel 2.6.21 in which I have enabled
HID debugging messages and will send you the logs as soon as I have
them.
cheers,
--renato
Reclaim your digital rights, eliminate DRM, learn more at
http://www.defectivebydesign.org/what_is_drm
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] joydev.c automatic re-calibration
On 23/05/07, Andrew Morton <[EMAIL PROTECTED]> wrote: A few patch protocol things: - Please always prepare patches in `patch -p1' form - Include a Signed-off-by: as per Documentation/SubmittingPatches, section 11. - Avoid including two copies of the patch in the one email. Inlined plain text is preferred, ext/plain attachments are grudgingly accepted. I descrambled the patch, fixed a reject and queued it up in the -mm tree for Dmitry's consideration, thanks. Hi Andrew, sorry for the confusion, I'm following up with Dimitri and Jiri and hopefully will have a patch following the protocol next time. ;) cheers, --renato Reclaim your digital rights, eliminate DRM, learn more at http://www.defectivebydesign.org/what_is_drm - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] joydev.c automatic re-calibration
On 23/05/07, Jiri Kosina <[EMAIL PROTECTED]> wrote: I have asked Renato to provide HID debugging output a few days ago - see http://lkml.org/lkml/2007/5/21/201 - but that was without reply. Sorry, didn't get the email. Renato, do you think you could try this, so that we can understand better if we can't put a HID quirk to normalize the values on HID-level somehow? Good idea. I've put some debugging (but posted in the wrong list) about the values my joystick is reporting. Will turn on HID debugging and post the results. cheers, --renato Reclaim your digital rights, eliminate DRM, learn more at http://www.defectivebydesign.org/what_is_drm - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] joydev.c automatic re-calibration
This small patch adds the automatic recalibration feature without
spoiling previously calibrated devices. It's a fix for those joysticks
that report faulty range, specially Saitek Cyborg Evo Force.
File: drivers/input/joydev.c
Fix:
- extracted code from joydev_connect to method
joydev_calculate_correction to be able to call it from both
joydev_event upon recalibration and joydev_connect during first
connection.
- on joydev_connect check ranges and zero calibration if found out of range
- on joydev_event, every time found out of range, update min/max and
recalculate the correction
PS: adding Signed-off-by line (is that it?)
Signed-off-by: Renato Golin <[EMAIL PROTECTED]>
$ diff -u joydev.c.original joydev.c
--- joydev.c.original 2007-05-22 22:23:43.0 +0100
+++ joydev.c2007-05-23 01:24:04.0 +0100
@@ -53,6 +53,8 @@
__u8 absmap[ABS_MAX + 1];
__u8 abspam[ABS_MAX + 1];
__s16 abs[ABS_MAX + 1];
+ __s16 absmin[ABS_MAX + 1];
+ __s16 absmax[ABS_MAX + 1];
};
struct joydev_list {
@@ -67,6 +69,19 @@
static struct joydev *joydev_table[JOYDEV_MINORS];
+static void joydev_calculate_correction(int min, int max, int axis,
struct joydev *joydev)
+{
+ int t, j = joydev->abspam[axis];
+ int flat = joydev->handle.dev->absflat[j];
+
+ joydev->corr[axis].coef[0] = (max + min) / 2 - flat;
+ joydev->corr[axis].coef[1] = (max + min) / 2 + flat;
+ if (!(t = ((max - min) / 2 - 2 * flat)))
+ return;
+ joydev->corr[axis].coef[2] = (1 << 29) / t;
+ joydev->corr[axis].coef[3] = (1 << 29) / t;
+}
+
static int joydev_correct(int value, struct js_corr *corr)
{
switch (corr->type) {
@@ -103,6 +118,14 @@
case EV_ABS:
event.type = JS_EVENT_AXIS;
event.number = joydev->absmap[code];
+ /* recalibration if needed */
+ if (value < joydev->absmin[code]) {
+ joydev->absmin[code] = value;
+ joydev_calculate_correction(value,
joydev->absmax[code], code, joydev);
+ } else if (value > joydev->absmax[code]) {
+ joydev->absmax[code] = value;
+
joydev_calculate_correction(joydev->absmin[code], value, code,
joydev);
+ }
event.value = joydev_correct(value,
joydev->corr + event.number);
if (event.value == joydev->abs[event.number])
return;
@@ -470,7 +493,7 @@
{
struct joydev *joydev;
struct class_device *cdev;
- int i, j, t, minor;
+ int i, j, minor;
for (minor = 0; minor < JOYDEV_MINORS && joydev_table[minor]; minor++);
if (minor == JOYDEV_MINORS) {
@@ -515,19 +538,21 @@
for (i = 0; i < joydev->nabs; i++) {
j = joydev->abspam[i];
- if (dev->absmax[j] == dev->absmin[j]) {
+ joydev->absmin[i] = dev->absmin[j];
+ joydev->absmax[i] = dev->absmax[j];
+ if (joydev->absmax[i] == joydev->absmin[i]) {
joydev->corr[i].type = JS_CORR_NONE;
joydev->abs[i] = dev->abs[j];
continue;
}
joydev->corr[i].type = JS_CORR_BROKEN;
joydev->corr[i].prec = dev->absfuzz[j];
- joydev->corr[i].coef[0] = (dev->absmax[j] +
dev->absmin[j]) / 2 - dev->absflat[j];
- joydev->corr[i].coef[1] = (dev->absmax[j] +
dev->absmin[j]) / 2 + dev->absflat[j];
- if (!(t = ((dev->absmax[j] - dev->absmin[j]) / 2 - 2 *
dev->absflat[j])))
- continue;
- joydev->corr[i].coef[2] = (1 << 29) / t;
- joydev->corr[i].coef[3] = (1 << 29) / t;
+
+ if (dev->abs[j] > joydev->absmax[i] || dev->abs[j] <
joydev->absmin[i]) {
+ printk("Joydev: Bad axis range, recalibrating
automatically\n");
+ joydev_calculate_correction(0, 0, i, joydev);
+ } else
+ joydev_calculate_correction(joydev->absmin[i],
joydev->absmax[i], i, joydev);
joydev->abs[i] = joydev_correct(dev->abs[j], joydev->corr + i);
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] joydev.c automatic re-calibration
On 23/05/07, Jiri Kosina <[EMAIL PROTECTED]> wrote: (Adding Dmitry to CC so that he doesn't miss it. Also, if you'd like to get your patch merged, you should add proper Signed-off-by line. Hi Jiri, Sorry, it's my first kernel patch, how do I add Signed-off-by line? I did with: $ diff -u original changed cheers, --renato Reclaim your digital rights, eliminate DRM, learn more at http://www.defectivebydesign.org/what_is_drm - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] joydev.c automatic re-calibration
This small patch adds the automatic recalibration feature without
spoiling previously calibrated devices. It's a fix for those joysticks
that report faulty range, specially Saitek Cyborg Evo Force.
File: drivers/input/joydev.c
Fix:
- extracted code from joydev_connect to method
joydev_calculate_correction to be able to call it from both
joydev_event upon recalibration and joydev_connect during first
connection.
- on joydev_connect check ranges and zero calibration if found out of range
- on joydev_event, every time found out of range, update min/max and
recalculate the correction
Patch below and attached.
cheers,
--renato
== PATCH BEGIN ==
--- joydev.c.original 2007-05-22 22:23:43.0 +0100
+++ joydev.c2007-05-23 01:24:04.0 +0100
@@ -53,6 +53,8 @@
__u8 absmap[ABS_MAX + 1];
__u8 abspam[ABS_MAX + 1];
__s16 abs[ABS_MAX + 1];
+ __s16 absmin[ABS_MAX + 1];
+ __s16 absmax[ABS_MAX + 1];
};
struct joydev_list {
@@ -67,6 +69,19 @@
static struct joydev *joydev_table[JOYDEV_MINORS];
+static void joydev_calculate_correction(int min, int max, int axis,
struct joydev *joydev)
+{
+ int t, j = joydev->abspam[axis];
+ int flat = joydev->handle.dev->absflat[j];
+
+ joydev->corr[axis].coef[0] = (max + min) / 2 - flat;
+ joydev->corr[axis].coef[1] = (max + min) / 2 + flat;
+ if (!(t = ((max - min) / 2 - 2 * flat)))
+ return;
+ joydev->corr[axis].coef[2] = (1 << 29) / t;
+ joydev->corr[axis].coef[3] = (1 << 29) / t;
+}
+
static int joydev_correct(int value, struct js_corr *corr)
{
switch (corr->type) {
@@ -103,6 +118,14 @@
case EV_ABS:
event.type = JS_EVENT_AXIS;
event.number = joydev->absmap[code];
+ /* recalibration if needed */
+ if (value < joydev->absmin[code]) {
+ joydev->absmin[code] = value;
+ joydev_calculate_correction(value,
joydev->absmax[code], code, joydev);
+ } else if (value > joydev->absmax[code]) {
+ joydev->absmax[code] = value;
+
joydev_calculate_correction(joydev->absmin[code], value, code,
joydev);
+ }
event.value = joydev_correct(value,
joydev->corr + event.number);
if (event.value == joydev->abs[event.number])
return;
@@ -470,7 +493,7 @@
{
struct joydev *joydev;
struct class_device *cdev;
- int i, j, t, minor;
+ int i, j, minor;
for (minor = 0; minor < JOYDEV_MINORS && joydev_table[minor]; minor++);
if (minor == JOYDEV_MINORS) {
@@ -515,19 +538,21 @@
for (i = 0; i < joydev->nabs; i++) {
j = joydev->abspam[i];
- if (dev->absmax[j] == dev->absmin[j]) {
+ joydev->absmin[i] = dev->absmin[j];
+ joydev->absmax[i] = dev->absmax[j];
+ if (joydev->absmax[i] == joydev->absmin[i]) {
joydev->corr[i].type = JS_CORR_NONE;
joydev->abs[i] = dev->abs[j];
continue;
}
joydev->corr[i].type = JS_CORR_BROKEN;
joydev->corr[i].prec = dev->absfuzz[j];
- joydev->corr[i].coef[0] = (dev->absmax[j] +
dev->absmin[j]) / 2 - dev->absflat[j];
- joydev->corr[i].coef[1] = (dev->absmax[j] +
dev->absmin[j]) / 2 + dev->absflat[j];
- if (!(t = ((dev->absmax[j] - dev->absmin[j]) / 2 - 2 *
dev->absflat[j])))
- continue;
- joydev->corr[i].coef[2] = (1 << 29) / t;
- joydev->corr[i].coef[3] = (1 << 29) / t;
+
+ if (dev->abs[j] > joydev->absmax[i] || dev->abs[j] <
joydev->absmin[i]) {
+ printk("Joydev: Bad axis range, recalibrating
automatically\n");
+ joydev_calculate_correction(0, 0, i, joydev);
+ } else
+ joydev_calculate_correction(joydev->absmin[i],
joydev->absmax[i], i, joydev);
joydev->abs[i] = joydev_correct(dev->abs[j], joydev->corr + i);
}
== PATCH END ==
--- joydev.c.original 2007-05-22 22:23:43.0 +0100
+++ joydev.c 2007-05-23 01:24:04.0 +0100
@@ -53,6 +53,8 @@
__u8 absmap[ABS_MAX + 1];
__u8 abspam[ABS_MAX + 1];
__s16 abs[ABS_MAX + 1];
+ __s16 absmin[ABS_MAX + 1];
+ __s16 absmax[ABS_MAX + 1];
};
struct joydev_list {
@@ -67,6 +69,19 @@
static struct joydev *joydev_table[JOYDEV_MINORS];
+static void joydev_calculate_correction(int min, int max, int axis, struct joydev *joydev)
+{
+ int t, j = joydev->abspam[axis];
+ int flat = joydev->handle.dev->absflat[j];
+
+ joydev->corr[axis].coef[0] = (max + min) / 2 - flat;
+ joydev->corr[axis].coef[1] = (max + min) / 2 + flat;
+ if (!(t = ((max - min) / 2 - 2 * flat)))
+ return;
+ joydev->corr[axis]
Re: joydev.c and saitek cyborg evo force
On 18/05/07, Renato Golin <[EMAIL PROTECTED]> wrote:
Problem is, on joydev_connect, when defining the corrections for every
axis, the joystick is reporting dev->absmax = 127 and dev->absmin =
-127 for both axis 0 and 1, so the correction is based on a signed
range when the joystick is actually sending an unsigned range.
Quick fix so I can play flightgear:
on joydev_connect, created absmin and absmax to avoid messing dev
variables (pointer)
if current position (dev->abs) is not in range:
if (dev->abs[j] > dev->absmax[j] || dev->abs[j] < dev->absmin[j]) {
absmin = 0;
absmax = dev->abs[j] * 2;
}
problems:
- it only works when joy is centred at connection
- it assumes the joy will report correct positions (instead of uncalibrated)
Now I'll figure out how to turn off button 12...
cheers,
--renato
Reclaim your digital rights, eliminate DRM, learn more at
http://www.defectivebydesign.org/what_is_drm
--- joydev.c 2007-04-12 18:15:56.0 +0100
+++ /usr/src/linux/drivers/input/joydev.c 2007-05-18 22:21:26.0 +0100
@@ -471,6 +471,7 @@
struct joydev *joydev;
struct class_device *cdev;
int i, j, t, minor;
+ int absmin, absmax;
for (minor = 0; minor < JOYDEV_MINORS && joydev_table[minor]; minor++);
if (minor == JOYDEV_MINORS) {
@@ -520,11 +521,20 @@
joydev->abs[i] = dev->abs[j];
continue;
}
+ /* Some joysticks don't report max/min correctly */
+ if (dev->abs[j] > dev->absmax[j] || dev->abs[j] < dev->absmin[j]) {
+ /* assume joystick is centered */
+ absmin = 0;
+ absmax = dev->abs[j] * 2;
+ } else {
+ absmin = dev->absmin[j];
+ absmax = dev->absmax[j];
+ }
joydev->corr[i].type = JS_CORR_BROKEN;
joydev->corr[i].prec = dev->absfuzz[j];
- joydev->corr[i].coef[0] = (dev->absmax[j] + dev->absmin[j]) / 2 - dev->absflat[j];
- joydev->corr[i].coef[1] = (dev->absmax[j] + dev->absmin[j]) / 2 + dev->absflat[j];
- if (!(t = ((dev->absmax[j] - dev->absmin[j]) / 2 - 2 * dev->absflat[j])))
+ joydev->corr[i].coef[0] = (absmax + absmin) / 2 - dev->absflat[j];
+ joydev->corr[i].coef[1] = (absmax + absmin) / 2 + dev->absflat[j];
+ if (!(t = ((absmax - absmin) / 2 - 2 * dev->absflat[j])))
continue;
joydev->corr[i].coef[2] = (1 << 29) / t;
joydev->corr[i].coef[3] = (1 << 29) / t;
joydev.c and saitek cyborg evo force
Hi, I'm a kernel newbie so please, pardon my French. I have a Saitek Cyborg Evo Force, a very good joystick with force- feedback. Problem is, on Windows it works well (its drivers know its own idiosyncrasies) but on Linux it gets a bit fuzzy. The behaviour is that, all axis are working fine, except up/down (elevator) and left/right (aileron) that gives me "random" signed/unsigned values. A smaller problem is that it's reporting 8 axis but have 6 only and 13 buttons but have only 12 and the 12th button is always pressed, messing fgjs setup utility. Digging drivers/input/joydev.c I found out that if I remove the correction (setting JS_CORR_NONE) the values come correct, in a range from 0 to 4096. Problem is, on joydev_connect, when defining the corrections for every axis, the joystick is reporting dev->absmax = 127 and dev->absmin = -127 for both axis 0 and 1, so the correction is based on a signed range when the joystick is actually sending an unsigned range. Also, because the module was expecting up to 127 on value and is getting 4094, when the correction does a left shift it might be setting the signal bit (leftmost) and that could explain why I'm getting random signed/unsigned values. The only way to know what is the real range is when you're actually pushing and pulling the stick so the change I'm willing to make is to recalibrate (ie. redefine the correction) whenever the raw value goes off limits. But that would only extend 127 to 4096 but won't change -127 to 0. Another alternative is to do a dynamic calibration whenever you move the stick from the beginning and not do it based on what the joystick is telling you to (ie. at connect time). But that might be a lot of useless work when the control gives you the correct range in the first place. At last, hardcoding "if (saitek)" is quite ugly but can be done for the sake of performance. comments, please. cheers, --renato Reclaim your digital rights, eliminate DRM, learn more at http://www.defectivebydesign.org/what_is_drm - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
