Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758199AbXFLNI6 (ORCPT ); Tue, 12 Jun 2007 09:08:58 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1757943AbXFLNIb (ORCPT ); Tue, 12 Jun 2007 09:08:31 -0400 Received: from ug-out-1314.google.com ([66.249.92.175]:25539 "EHLO ug-out-1314.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757927AbXFLNI3 (ORCPT ); Tue, 12 Jun 2007 09:08:29 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=NEjI1h3czQhIfn6tAyvK/6izJrSt/BR8dNg/8dCoxdh+DhW0a0Q35jykrcXolPjPcsmvbInpTzmgHThbXm3822wQQbqORE5Q307UPUYhRWwKqx252/UQqVazFHgdg7AlUr7HZAyi9VgxamFwxzJFHBRsxPJP9/nzboK4L3LWSCk= Message-ID: Date: Tue, 12 Jun 2007 14:08:27 +0100 From: "Renato Golin" To: "Jiri Kosina" Subject: Re: joydev.c and saitek cyborg evo force Cc: linux-kernel@vger.kernel.org, "Dmitry Torokhov" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2401 Lines: 55 On 12/06/07, Jiri Kosina 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/