From owner-freebsd-arch@FreeBSD.ORG Mon Feb 26 21:05:47 2007 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2F6B316A407 for ; Mon, 26 Feb 2007 21:05:47 +0000 (UTC) (envelope-from tshadwick+freebsd-arch.freebsd.org@oss-solutions.com) Received: from moogle.hksilver.net (mail.hksilver.net [208.231.66.99]) by mx1.freebsd.org (Postfix) with ESMTP id E494913C4AC for ; Mon, 26 Feb 2007 21:05:46 +0000 (UTC) (envelope-from tshadwick+freebsd-arch.freebsd.org@oss-solutions.com) Received: from [172.16.30.8] (chibi.shadwick.home [172.16.30.8]) by moogle.hksilver.net (8.13.8/8.13.4) with ESMTP id l1QKiw6b085947 for ; Mon, 26 Feb 2007 14:44:59 -0600 (CST) (envelope-from tshadwick+freebsd-arch.freebsd.org@oss-solutions.com) Message-ID: <45E3467E.2070000@oss-solutions.com> Date: Mon, 26 Feb 2007 14:43:42 -0600 From: Tony Shadwick User-Agent: Mail/News 1.5.0.2 (Macintosh/20060310) MIME-Version: 1.0 To: freebsd-arch@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: USB HID Driver help X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Feb 2007 21:05:47 -0000 I'm definitely not a high-end programmer, but I have gone to the trouble of working out the protocol for a USB light gun that is normally used on a Playstation 2 video game console. It has 10 buttons, and can track on-screen location if it has access to the composite sync video signal. http://forum.arcadecontrols.com/index.php?topic=60813.0 I've written just a basic parser for the gun. FreeBSD picks up the gun and gives it a ugen character device that I then take continuous input from. The protocol is 6 bytes long repeated pretty much as fast as the gun can send it. What I would like to do is create a USB HID driver for the gun so that things like MAME can use it, and for the fun of it perhaps even X11 pick it up as a mouse. There are two linux drivers out there already, one for the stock GunCon 2: http://mywebpages.comcast.net/bgoines78/ and one for a variant on the GunCon2 called "LCD Topgun": http://kaillera.com/topgun/ The oddity about this is that all version of the gun, 3rd party, first party, whatever, all present themselves as the same Vendor ID and Product ID, so there's no way (that I'm aware of) to distinguish a GunCo 2 from an LCD Topgun, from a Mad Catz lightgun, etc. Perhaps there are other values that can be queried to figure it out, but I'm not that far in yet. I've looked at the ugen driver, and it doesn't seem right that I copy that driver and just change values. I also don't know what headers need to be included to create basically a 10 button mouse. The Linux code isn't very portable in that regard. The basic logic is sound I suppose, but I've looked at the developer's handbook, and although it hits the very basics, there's nothing that say "this is how you would go about creating a valid HID driver for FreeBSD". It could be that I'm looking at it backwards, and the hardware is supposed to conform to a standard that the software expects, and really what I'm trying to do is a create a "middleware" that translates the gun's native protocol to HID standards, but if that's the case, how is the Linux driver doing it? Anyway, I'd appreciate any help! Tony From owner-freebsd-arch@FreeBSD.ORG Tue Feb 27 03:35:34 2007 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D816E16A468; Tue, 27 Feb 2007 03:35:34 +0000 (UTC) (envelope-from tshadwick+freebsd-arch.freebsd.org@oss-solutions.com) Received: from moogle.hksilver.net (mail.hksilver.net [208.231.66.99]) by mx1.freebsd.org (Postfix) with ESMTP id 6EDF813C4D9; Tue, 27 Feb 2007 03:35:34 +0000 (UTC) (envelope-from tshadwick+freebsd-arch.freebsd.org@oss-solutions.com) Received: from [172.16.30.8] (chibi.shadwick.home [172.16.30.8]) by moogle.hksilver.net (8.13.8/8.13.4) with ESMTP id l1R3aoBI000347; Mon, 26 Feb 2007 21:36:50 -0600 (CST) (envelope-from tshadwick+freebsd-arch.freebsd.org@oss-solutions.com) Message-ID: <45E3A704.90307@oss-solutions.com> Date: Mon, 26 Feb 2007 21:35:32 -0600 From: Tony Shadwick User-Agent: Mail/News 1.5.0.2 (Macintosh/20060310) MIME-Version: 1.0 To: Markus Brueffer References: <45E3467E.2070000@oss-solutions.com> <200702270345.13194.markus@FreeBSD.org> In-Reply-To: <200702270345.13194.markus@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arch@FreeBSD.org Subject: Re: USB HID Driver help X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Feb 2007 03:35:35 -0000 Markus Brueffer wrote: > Hi Tony, > > On Monday 26 February 2007 21:43, Tony Shadwick wrote: >> I'm definitely not a high-end programmer, but I have gone to the trouble >> of working out the protocol for a USB light gun that is normally used on >> a Playstation 2 video game console. It has 10 buttons, and can track >> on-screen location if it has access to the composite sync video signal. >> >> http://forum.arcadecontrols.com/index.php?topic=60813.0 >> >> I've written just a basic parser for the gun. FreeBSD picks up the gun >> and gives it a ugen character device that I then take continuous input >> from. The protocol is 6 bytes long repeated pretty much as fast as the >> gun can send it. > > Did you have uhid(4) in the kernel or loaded as module? If not, please try > loading the module and see if the device gets picked up by it (you need to > replug it after loading the module). > > Judging from the description of the protocol, it seems that the device is a > regular USB HID device. If it doesn't get picked up by uhid(4), it suffers > from the same problem as the gamepad of the Xbox360 by not exposing itself as > being a regular USB HID device and not providing a HID descriptor. Both can > be worked around but please verify first, that uhid(4) doesn't already > support the device. Writing an extra driver for this device is not > neccessary. > > Markus > I cannot check until tomorrow, but thank you for the pointers. I'll verify this for you then. Tony From owner-freebsd-arch@FreeBSD.ORG Tue Feb 27 08:39:16 2007 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 52D7316A400 for ; Tue, 27 Feb 2007 08:39:16 +0000 (UTC) (envelope-from markus@FreeBSD.org) Received: from mail-in-02.arcor-online.net (mail-in-02.arcor-online.net [151.189.21.42]) by mx1.freebsd.org (Postfix) with ESMTP id D81B113C4A3 for ; Tue, 27 Feb 2007 08:39:15 +0000 (UTC) (envelope-from markus@FreeBSD.org) Received: from mail-in-14-z2.arcor-online.net (mail-in-14-z2.arcor-online.net [151.189.8.31]) by mail-in-02.arcor-online.net (Postfix) with ESMTP id 1DAB92D9953; Tue, 27 Feb 2007 03:45:40 +0100 (CET) Received: from mail-in-02.arcor-online.net (mail-in-02.arcor-online.net [151.189.21.42]) by mail-in-14-z2.arcor-online.net (Postfix) with ESMTP id 107EC10104; Tue, 27 Feb 2007 03:45:40 +0100 (CET) Received: from ramses.kicks-ass.net (dslb-084-061-097-006.pools.arcor-ip.net [84.61.97.6]) by mail-in-02.arcor-online.net (Postfix) with ESMTP id EC6852D9953; Tue, 27 Feb 2007 03:45:39 +0100 (CET) Received: from cheops.phoenix (cheops.phoenix [192.168.1.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ramses.kicks-ass.net (Postfix) with ESMTP id E5FFBB83D; Tue, 27 Feb 2007 03:45:39 +0100 (CET) From: Markus Brueffer To: freebsd-arch@freebsd.org Date: Tue, 27 Feb 2007 03:45:05 +0100 User-Agent: KMail/1.9.5 References: <45E3467E.2070000@oss-solutions.com> In-Reply-To: <45E3467E.2070000@oss-solutions.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3170184.eGmmfpgMvQ"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200702270345.13194.markus@FreeBSD.org> Cc: Tony Shadwick Subject: Re: USB HID Driver help X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Feb 2007 08:39:16 -0000 --nextPart3170184.eGmmfpgMvQ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Tony, On Monday 26 February 2007 21:43, Tony Shadwick wrote: > I'm definitely not a high-end programmer, but I have gone to the trouble > of working out the protocol for a USB light gun that is normally used on > a Playstation 2 video game console. It has 10 buttons, and can track > on-screen location if it has access to the composite sync video signal. > > http://forum.arcadecontrols.com/index.php?topic=3D60813.0 > > I've written just a basic parser for the gun. FreeBSD picks up the gun > and gives it a ugen character device that I then take continuous input > from. The protocol is 6 bytes long repeated pretty much as fast as the > gun can send it. Did you have uhid(4) in the kernel or loaded as module? If not, please try= =20 loading the module and see if the device gets picked up by it (you need to= =20 replug it after loading the module). Judging from the description of the protocol, it seems that the device is a= =20 regular USB HID device. If it doesn't get picked up by uhid(4), it suffers= =20 from the same problem as the gamepad of the Xbox360 by not exposing itself = as=20 being a regular USB HID device and not providing a HID descriptor. Both can= =20 be worked around but please verify first, that uhid(4) doesn't already=20 support the device. Writing an extra driver for this device is not=20 neccessary. Markus =2D-=20 Markus Brueffer =A0 =A0| GPG-Key: http://people.FreeBSD.org/~markus/markus.= asc markus@brueffer.de | FP: 3F9B EBE8 F290 E5CC 1447 8760 D48D 1072 78F8 A8D4 markus@FreeBSD.org | FreeBSD: The Power to Serve! --nextPart3170184.eGmmfpgMvQ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQBF45s51I0Qcnj4qNQRAhc6AJ9y1amY+qJ20FHbZdyoBuHXtB+6jwCg11v/ DpIYYWxCvB06g9pSX8d7Uuo= =xAc4 -----END PGP SIGNATURE----- --nextPart3170184.eGmmfpgMvQ-- From owner-freebsd-arch@FreeBSD.ORG Tue Feb 27 09:30:32 2007 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6848616A401 for ; Tue, 27 Feb 2007 09:30:32 +0000 (UTC) (envelope-from petrus4@tpg.com.au) Received: from mail8.tpgi.com.au (smtp8.tpgi.com.au [220.244.226.118]) by mx1.freebsd.org (Postfix) with ESMTP id E4C2613C4AA for ; Tue, 27 Feb 2007 09:30:31 +0000 (UTC) (envelope-from petrus4@tpg.com.au) X-TPG-Antivirus: Passed Received: from owner704ff21d8 (60-240-156-60.tpgi.com.au [60.240.156.60]) by mail8.tpgi.com.au (envelope-from petrus4@tpg.com.au) (8.13.6/8.13.6) with SMTP id l1R9BIAi015064 for ; Tue, 27 Feb 2007 20:11:20 +1100 Message-ID: <000a01c75a4f$3ee32be0$3c9cf03c@owner704ff21d8> From: "Petrus" To: Date: Tue, 27 Feb 2007 20:11:19 +1100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Subject: The Amsterdam Compiler Kit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Feb 2007 09:30:32 -0000 Hi, I hope nobody minds me sending this here, but I looked at the list of mailing lists on the web site, and this seemed like the most relevant place. I was looking for alternate compilers to GCC a couple of days ago, and ended up finding the Amsterdam Compiler Kit. (http://sourceforge.net/projects/tack/) It's the compiler that Andrew Tanenbaum is apparently using for Minix. From what I read, it used to be commercial, and at one point Richard Stallman apparently actually asked him if it could be used as the basis of GCC, but it seems he was turned down. As you can see from the address though, it is now on Sourceforge, and is under the BSD license. I checked both Freshports and Google, and this apparently isn't something which anyone associated with FreeBSD has heard about yet, at least according to what Google brought up. I adamantly hope that this is something that FreeBSD could eventually use. If it was, it could be a major step I'm assuming in removing the BSDs' reliance on the GNU project entirely. Given the way the FSF has been behaving recently, that could only be a good thing. Unfortunately my own knowledge of C in particular is more or less entirely non-existent, so I would be unable to help get it into shape. It apparently only compiles binaries in the a.out format in particular, so I'm assuming that the FreeBSD developers would want to do at least some modification to it. Petrus From owner-freebsd-arch@FreeBSD.ORG Tue Feb 27 09:56:53 2007 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C6E4516A402 for ; Tue, 27 Feb 2007 09:56:53 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 8922613C461 for ; Tue, 27 Feb 2007 09:56:51 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id 1D539170DC; Tue, 27 Feb 2007 09:33:32 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.8/8.13.8) with ESMTP id l1R9XUSE036681; Tue, 27 Feb 2007 09:33:31 GMT (envelope-from phk@critter.freebsd.dk) To: "Petrus" From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 27 Feb 2007 20:11:19 +1100." <000a01c75a4f$3ee32be0$3c9cf03c@owner704ff21d8> Date: Tue, 27 Feb 2007 09:33:30 +0000 Message-ID: <36680.1172568810@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: freebsd-arch@freebsd.org Subject: Re: The Amsterdam Compiler Kit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Feb 2007 09:56:53 -0000 In message <000a01c75a4f$3ee32be0$3c9cf03c@owner704ff21d8>, "Petrus" writes: >I adamantly hope that this is something that FreeBSD could eventually use. Well, all it takes is for somebody to make FreeBSD compile with it and subsequently get the optimizer good enough to compete sensibly with GCC. A perfect project, go for it! -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Tue Feb 27 10:11:20 2007 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8BFF416A402 for ; Tue, 27 Feb 2007 10:11:20 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (c220-239-3-125.belrs4.nsw.optusnet.com.au [220.239.3.125]) by mx1.freebsd.org (Postfix) with ESMTP id 1794313C441 for ; Tue, 27 Feb 2007 10:11:19 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by turion.vk2pj.dyndns.org (8.13.8/8.13.8) with ESMTP id l1RABI0C042215; Tue, 27 Feb 2007 21:11:18 +1100 (EST) (envelope-from peter@turion.vk2pj.dyndns.org) Received: (from peter@localhost) by turion.vk2pj.dyndns.org (8.13.8/8.13.8/Submit) id l1RABIRd042214; Tue, 27 Feb 2007 21:11:18 +1100 (EST) (envelope-from peter) Date: Tue, 27 Feb 2007 21:11:18 +1100 From: Peter Jeremy To: Petrus Message-ID: <20070227101118.GD844@turion.vk2pj.dyndns.org> References: <000a01c75a4f$3ee32be0$3c9cf03c@owner704ff21d8> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="WRT3RXLOp/bBMgTI" Content-Disposition: inline In-Reply-To: <000a01c75a4f$3ee32be0$3c9cf03c@owner704ff21d8> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.13 (2006-08-11) Cc: freebsd-arch@freebsd.org Subject: Re: The Amsterdam Compiler Kit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Feb 2007 10:11:20 -0000 --WRT3RXLOp/bBMgTI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2007-Feb-27 20:11:19 +1100, Petrus wrote: >I was looking for alternate compilers to GCC a couple of days ago, and=20 >ended up finding the Amsterdam Compiler Kit.=20 >(http://sourceforge.net/projects/tack/) I recall this from when I was playing with minix. >I adamantly hope that this is something that FreeBSD could eventually use.= =20 Whilst there is some activity on it, the CVS repository contains a worryingly large number of files that apparently haven't been touched in more than a decade (some haven't been touched in 25 years). Based on a quick rummage around the repository, it doesn't appear to support any current-generation CPUs. The intersection between FreeBSD and TACK appears to consist of solely of the 80486. (There is also an arm tree but I don't know enough about the arm architecture to know if a 15 year old compiler is going to work with current chips). Possibly FreeBSD could eventually use the compiler but it would need a massive amount of work before it could even support the architectures that FreeBSD runs on. That said, the first step would be for someone to create a port of the compiler. Some of the backends may be of interest to people doing legacy or embedded work. --=20 Peter Jeremy --WRT3RXLOp/bBMgTI Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFF5APG/opHv/APuIcRAgR4AKCPdBx3WVViGt0+10afnVka9+4cUgCfb4za ZcVHxweMCknMFu6xDLnVgeY= =FNMT -----END PGP SIGNATURE----- --WRT3RXLOp/bBMgTI-- From owner-freebsd-arch@FreeBSD.ORG Tue Feb 27 10:12:13 2007 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B3B9C16A406 for ; Tue, 27 Feb 2007 10:12:13 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 7480E13C48E for ; Tue, 27 Feb 2007 10:12:13 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id E6D412085; Tue, 27 Feb 2007 10:52:03 +0100 (CET) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: 0.0/3.0 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on tim.des.no Received: from dwp.des.no (des.no [80.203.243.180]) by tim.des.no (Postfix) with ESMTP id 704D82049; Tue, 27 Feb 2007 10:52:03 +0100 (CET) Received: by dwp.des.no (Postfix, from userid 1001) id 559EDB874; Tue, 27 Feb 2007 10:52:03 +0100 (CET) From: des@des.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) To: "Petrus" References: <000a01c75a4f$3ee32be0$3c9cf03c@owner704ff21d8> Date: Tue, 27 Feb 2007 10:52:03 +0100 In-Reply-To: <000a01c75a4f$3ee32be0$3c9cf03c@owner704ff21d8> (petrus4@tpg.com.au's message of "Tue, 27 Feb 2007 20:11:19 +1100") Message-ID: <86r6schqrg.fsf@dwp.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-arch@freebsd.org Subject: Re: The Amsterdam Compiler Kit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Feb 2007 10:12:13 -0000 "Petrus" writes: > I was looking for alternate compilers to GCC a couple of days ago, > and ended up finding the Amsterdam Compiler Kit. > (http://sourceforge.net/projects/tack/) [...] I adamantly hope that > this is something that FreeBSD could eventually use. If it was, it > could be a major step I'm assuming in removing the BSDs' reliance on > the GNU project entirely. ACK is pretty much useless to us. It has no C++ or C99 frontend, and lacks backends for five of the eight platforms FreeBSD runs on. It also lacks an ELF linker, and is probably years if not decades behind GCC in terms of optimization. You should not underestimate the amount of effort and talent that has gone into GCC over the years. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Tue Feb 27 10:36:56 2007 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9341416A50F for ; Tue, 27 Feb 2007 10:36:56 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 518F013C48D for ; Tue, 27 Feb 2007 10:36:56 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 955E2207E; Tue, 27 Feb 2007 11:36:52 +0100 (CET) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: 0.0/3.0 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on tim.des.no Received: from dwp.des.no (des.no [80.203.243.180]) by tim.des.no (Postfix) with ESMTP id 7C5702049; Tue, 27 Feb 2007 11:36:52 +0100 (CET) Received: by dwp.des.no (Postfix, from userid 1001) id EA91DB874; Tue, 27 Feb 2007 11:36:51 +0100 (CET) From: des@des.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) To: "Petrus" References: <000a01c75a4f$3ee32be0$3c9cf03c@owner704ff21d8> <86r6schqrg.fsf@dwp.des.no> Date: Tue, 27 Feb 2007 11:36:51 +0100 In-Reply-To: <86r6schqrg.fsf@dwp.des.no> (Dag-Erling =?iso-8859-1?Q?Sm=F8r?= =?iso-8859-1?Q?grav's?= message of "Tue, 27 Feb 2007 10:52:03 +0100") Message-ID: <86k5y3j398.fsf@dwp.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-arch@freebsd.org Subject: Re: The Amsterdam Compiler Kit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Feb 2007 10:36:56 -0000 des@des.no (Dag-Erling Sm=F8rgrav) writes: > ACK is pretty much useless to us. It has no C++ or C99 frontend, and > lacks backends for five of the eight platforms FreeBSD runs on. It's even worse than that: ACK 6.0pre1 supports only the 8086. Presumably, support for additional platforms will be restored before 6.0 is released, but until then, it's a boat anchor... DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Tue Feb 27 15:05:02 2007 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9BCE116A402 for ; Tue, 27 Feb 2007 15:05:02 +0000 (UTC) (envelope-from freebsd-arch@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 429F613C481 for ; Tue, 27 Feb 2007 15:05:02 +0000 (UTC) (envelope-from freebsd-arch@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HM3e1-0000wN-Ow for freebsd-arch@freebsd.org; Tue, 27 Feb 2007 15:49:33 +0100 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 27 Feb 2007 15:49:33 +0100 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 27 Feb 2007 15:49:33 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-arch@freebsd.org From: Ivan Voras Date: Tue, 27 Feb 2007 15:49:21 +0100 Lines: 31 Message-ID: References: <000a01c75a4f$3ee32be0$3c9cf03c@owner704ff21d8> <86r6schqrg.fsf@dwp.des.no> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigDB29B3BB06E9325D7BCB1F7E" X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 1.5.0.9 (X11/20070110) In-Reply-To: <86r6schqrg.fsf@dwp.des.no> X-Enigmail-Version: 0.94.0.0 Sender: news Subject: Re: The Amsterdam Compiler Kit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Feb 2007 15:05:02 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigDB29B3BB06E9325D7BCB1F7E Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dag-Erling Sm=C3=B8rgrav wrote: > ACK is pretty much useless to us. It has no C++ or C99 frontend, and > lacks backends for five of the eight platforms FreeBSD runs on. It > also lacks an ELF linker, and is probably years if not decades behind > GCC in terms of optimization. Minix doesn't support FPU so the compiler may be also lacking support for it. --------------enigDB29B3BB06E9325D7BCB1F7E Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (FreeBSD) Comment: Using GnuPG with Thunderbird/FreeBSD - http://enigmail.mozdev.org iD8DBQFF5ETxldnAQVacBcgRAmarAJ9prtZ3s0rohQpXbipTY+wrrlsaoACfXgwu 5/YHOZ4W7EJxI3gpaifTdxo= =PJfx -----END PGP SIGNATURE----- --------------enigDB29B3BB06E9325D7BCB1F7E-- From owner-freebsd-arch@FreeBSD.ORG Tue Feb 27 23:06:07 2007 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 28EFA16A405 for ; Tue, 27 Feb 2007 23:06:07 +0000 (UTC) (envelope-from nate@root.org) Received: from root.org (root.org [67.118.192.226]) by mx1.freebsd.org (Postfix) with ESMTP id 0157513C48E for ; Tue, 27 Feb 2007 23:06:06 +0000 (UTC) (envelope-from nate@root.org) Received: (qmail 57726 invoked from network); 27 Feb 2007 22:16:35 -0000 Received: from ppp-71-139-18-69.dsl.snfc21.pacbell.net (HELO ?10.0.5.55?) (nate-mail@71.139.18.69) by root.org with ESMTPA; 27 Feb 2007 22:16:35 -0000 Message-ID: <45E4ADCD.4090909@root.org> Date: Tue, 27 Feb 2007 14:16:45 -0800 From: Nate Lawson User-Agent: Thunderbird 1.5.0.9 (X11/20070214) MIME-Version: 1.0 To: arch@freebsd.org X-Enigmail-Version: 0.94.2.0 Content-Type: multipart/mixed; boundary="------------020900080209080209010700" Cc: current@FreeBSD.org Subject: PATCH - update TSC freq when cpufreq changes it X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Feb 2007 23:06:07 -0000 This is a multi-part message in MIME format. --------------020900080209080209010700 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Attached is a patch that uses eventhandlers to update the TSC freq. This is important because DELAY() uses TSC directly (on i386 and amd64) but the rate calculated at boot changes if cpufreq is in use. It maintains current behavior that cpufreq transitions are denied if TSC is the active timecounter. The API is that there is a pre and post transition eventhandler that is called by the cpufreq core. The pre handler is passed the next state (including freq, power, etc.) and can store a non-zero status value in the output arg to indicate it wants to reject the transition. The post handler also is passed the next state and the result of the transition (0 on success). Once any issues are addressed, I'll update this for amd64, ALTQ, and possibly PC98. Non-x86 archs can stick with the current behavior if they're satisfied or hook the eventhandlers provided to DTRT. -- Nate --------------020900080209080209010700 Content-Type: text/plain; name="cpu_event.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="cpu_event.diff" Index: sys/i386/i386/tsc.c =================================================================== RCS file: /home/ncvs/src/sys/i386/i386/tsc.c,v retrieving revision 1.206 diff -u -r1.206 tsc.c --- sys/i386/i386/tsc.c 4 Aug 2006 07:56:35 -0000 1.206 +++ sys/i386/i386/tsc.c 27 Feb 2007 21:57:46 -0000 @@ -30,6 +30,8 @@ #include "opt_clock.h" #include +#include +#include #include #include #include @@ -52,14 +54,20 @@ TUNABLE_INT("kern.timecounter.smp_tsc", &smp_tsc); #endif +static eventhandler_tag evh_pre_tag, evh_post_tag; + static unsigned tsc_get_timecount(struct timecounter *tc); +static void tsc_freq_changing(void *arg, const struct cf_level *level, + int *status); +static void tsc_freq_changed(void *arg, const struct cf_level *level, + int *status); static struct timecounter tsc_timecounter = { tsc_get_timecount, /* get_timecount */ 0, /* no poll_pps */ - ~0u, /* counter_mask */ + ~0u, /* counter_mask */ 0, /* frequency */ - "TSC", /* name */ + "TSC", /* name */ 800, /* quality (adjusted in code) */ }; @@ -87,8 +95,13 @@ if (bootverbose) printf("TSC clock: %ju Hz\n", (intmax_t)tsc_freq); set_cputicker(rdtsc, tsc_freq, 1); -} + /* Register to find out about changes in CPU frequency. */ + evh_pre_tag = EVENTHANDLER_REGISTER(cpufreq_pre_change, + tsc_freq_changing, NULL, EVENTHANDLER_PRI_ANY); + evh_post_tag = EVENTHANDLER_REGISTER(cpufreq_post_change, + tsc_freq_changed, NULL, EVENTHANDLER_PRI_ANY); +} void init_TSC_tc(void) @@ -128,6 +141,38 @@ } } +/* + * If the TSC timecounter is in use, veto the pending change. It may be + * possible in the future to handle a dynamically-changing timecounter rate. + */ +static void +tsc_freq_changing(void *arg, const struct cf_level *level, int *status) +{ + static int once; + + if (*status == 0 && timecounter == &tsc_timecounter) { + if (!once) { + printf("timecounter TSC must not be in use when " + "changing frequencies; change denied\n"); + once = 1; + } + *status = EBUSY; + } +} + +/* Update TSC freq with the value indicated by the caller. */ +static void +tsc_freq_changed(void *arg, const struct cf_level *level, int *status) +{ + /* If there was an error during the transition, don't do anything. */ + if (*status != 0) + return; + + /* Total setting gives the new frequency in MHz. */ + tsc_freq = level->total_set.freq * 1000000; + tsc_timecounter.tc_frequency = tsc_freq; +} + static int sysctl_machdep_tsc_freq(SYSCTL_HANDLER_ARGS) { Index: sys/kern/kern_cpu.c =================================================================== RCS file: /home/ncvs/src/sys/kern/kern_cpu.c,v retrieving revision 1.23 diff -u -r1.23 kern_cpu.c --- sys/kern/kern_cpu.c 3 Mar 2006 02:06:04 -0000 1.23 +++ sys/kern/kern_cpu.c 27 Feb 2007 21:59:59 -0000 @@ -95,7 +95,6 @@ static int cpufreq_attach(device_t dev); static int cpufreq_detach(device_t dev); -static void cpufreq_evaluate(void *arg); static int cf_set_method(device_t dev, const struct cf_level *level, int priority); static int cf_get_method(device_t dev, struct cf_level *level); @@ -127,8 +126,6 @@ static devclass_t cpufreq_dc; DRIVER_MODULE(cpufreq, cpu, cpufreq_driver, cpufreq_dc, 0, 0); -static eventhandler_tag cf_ev_tag; - static int cf_lowest_freq; static int cf_verbose; TUNABLE_INT("debug.cpufreq.lowest", &cf_lowest_freq); @@ -176,8 +173,6 @@ SYSCTL_CHILDREN(device_get_sysctl_tree(parent)), OID_AUTO, "freq_levels", CTLTYPE_STRING | CTLFLAG_RD, sc, 0, cpufreq_levels_sysctl, "A", "CPU frequency levels"); - cf_ev_tag = EVENTHANDLER_REGISTER(cpufreq_changed, cpufreq_evaluate, - NULL, EVENTHANDLER_PRI_ANY); return (0); } @@ -202,18 +197,11 @@ numdevs = devclass_get_count(cpufreq_dc); if (numdevs == 1) { CF_DEBUG("final shutdown for %s\n", device_get_nameunit(dev)); - EVENTHANDLER_DEREGISTER(cpufreq_changed, cf_ev_tag); } return (0); } -static void -cpufreq_evaluate(void *arg) -{ - /* TODO: Re-evaluate when notified of changes to drivers. */ -} - static int cf_set_method(device_t dev, const struct cf_level *level, int priority) { @@ -222,26 +210,16 @@ struct cf_saved_freq *saved_freq, *curr_freq; struct pcpu *pc; int cpu_id, error, i; - static int once; sc = device_get_softc(dev); error = 0; set = NULL; saved_freq = NULL; - /* - * Check that the TSC isn't being used as a timecounter. - * If it is, then return EBUSY and refuse to change the - * clock speed. - */ - if (strcmp(timecounter->tc_name, "TSC") == 0) { - if (!once) { - printf("cpufreq: frequency change with timecounter" - " TSC not allowed, see cpufreq(4)\n"); - once = 1; - } - return (EBUSY); - } + /* We are going to change levels so notify the pre-change handler. */ + EVENTHANDLER_INVOKE(cpufreq_pre_change, level, &error); + if (error != 0) + return (error); CF_MTX_LOCK(&sc->lock); @@ -378,8 +356,15 @@ out: CF_MTX_UNLOCK(&sc->lock); + + /* + * We changed levels (or attempted to) so notify the post-change + * handler of new frequency or error. + */ + EVENTHANDLER_INVOKE(cpufreq_post_change, level, &error); if (error && set) device_printf(set->dev, "set freq failed, err %d\n", error); + return (error); } Index: sys/sys/cpu.h =================================================================== RCS file: /home/ncvs/src/sys/sys/cpu.h,v retrieving revision 1.3 diff -u -r1.3 cpu.h --- sys/sys/cpu.h 19 Feb 2005 06:13:25 -0000 1.3 +++ sys/sys/cpu.h 27 Feb 2007 19:49:37 -0000 @@ -1,5 +1,5 @@ /*- - * Copyright (c) 2005 Nate Lawson (SDG) + * Copyright (c) 2005-2007 Nate Lawson (SDG) * All rights reserved. * * Redistribution and use in source and binary forms, with or without @@ -29,6 +29,8 @@ #ifndef _SYS_CPU_H_ #define _SYS_CPU_H_ +#include + /* * CPU device support. */ @@ -118,6 +120,11 @@ int cpufreq_register(device_t dev); int cpufreq_unregister(device_t dev); +/* Eventhandlers that are called before and after a change in frequency */ +typedef void (*cpufreq_notify_fn)(void *, const struct cf_level *, int *); +EVENTHANDLER_DECLARE(cpufreq_pre_change, cpufreq_notify_fn); +EVENTHANDLER_DECLARE(cpufreq_post_change, cpufreq_notify_fn); + /* Allow values to be +/- a bit since sometimes we have to estimate. */ #define CPUFREQ_CMP(x, y) (abs((x) - (y)) < 25) --------------020900080209080209010700-- From owner-freebsd-arch@FreeBSD.ORG Wed Feb 28 00:19:24 2007 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D184916B5A2; Wed, 28 Feb 2007 00:19:24 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by mx1.freebsd.org (Postfix) with ESMTP id 5EC7A13C491; Wed, 28 Feb 2007 00:19:24 +0000 (UTC) (envelope-from max@love2party.net) Received: from [88.66.35.158] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu0) with ESMTP (Nemesis), id 0MKwh2-1HMCXG1ogj-0006Vq; Wed, 28 Feb 2007 01:19:19 +0100 From: Max Laier Organization: FreeBSD To: Nate Lawson Date: Wed, 28 Feb 2007 01:19:02 +0100 User-Agent: KMail/1.9.5 References: <45E4ADCD.4090909@root.org> In-Reply-To: <45E4ADCD.4090909@root.org> X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart12090080.RuxX3nTSIa"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200702280119.08987.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:61c499deaeeba3ba5be80f48ecc83056 X-Provags-ID2: V01U2FsdGVkX19IuyNlf0kZ5jwXnIVmgctu6TwsmDi0oYLkgqW lzdtzAzTmJsZV5vzYlvbrvHTH1Iw9QWVI0AADiz8iu7lu8ixog q42iKRyhvz5fiF/IGvnIg== Cc: freebsd-current@freebsd.org, freebsd-arch@freebsd.org Subject: Re: PATCH - update TSC freq when cpufreq changes it X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Feb 2007 00:19:24 -0000 --nextPart12090080.RuxX3nTSIa Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tuesday 27 February 2007 23:16, Nate Lawson wrote: > Attached is a patch that uses eventhandlers to update the TSC freq. > This is important because DELAY() uses TSC directly (on i386 and amd64) > but the rate calculated at boot changes if cpufreq is in use. > > It maintains current behavior that cpufreq transitions are denied if > TSC is the active timecounter. The API is that there is a pre and post > transition eventhandler that is called by the cpufreq core. The pre > handler is passed the next state (including freq, power, etc.) and can > store a non-zero status value in the output arg to indicate it wants to > reject the transition. The post handler also is passed the next state > and the result of the transition (0 on success). Any reason for passing the result to the post handler in by reference -=20 other than being able to re-use the same function type as in the pre=20 handler? API-wise this seems to be a mistake as one consumer could mess=20 up the result for the rest and the variable name "error" in the INVOKE=20 also suggests that this could be used to report back. > Once any issues are addressed, I'll update this for amd64, ALTQ, and > possibly PC98. Non-x86 archs can stick with the current behavior if > they're satisfied or hook the eventhandlers provided to DTRT. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart12090080.RuxX3nTSIa Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQBF5Mp8XyyEoT62BG0RAuczAJ9piNYhaOYLNzSFaT9S8dgPjW19lACeJkOP QFM0HizveGEwWhKVusvYWZs= =0Uha -----END PGP SIGNATURE----- --nextPart12090080.RuxX3nTSIa-- From owner-freebsd-arch@FreeBSD.ORG Wed Feb 28 02:24:00 2007 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1D10416C72E for ; Wed, 28 Feb 2007 02:24:00 +0000 (UTC) (envelope-from nate@root.org) Received: from root.org (root.org [67.118.192.226]) by mx1.freebsd.org (Postfix) with ESMTP id 04D2F13C428 for ; Wed, 28 Feb 2007 02:23:59 +0000 (UTC) (envelope-from nate@root.org) Received: (qmail 81904 invoked from network); 28 Feb 2007 00:42:05 -0000 Received: from ppp-71-139-18-69.dsl.snfc21.pacbell.net (HELO ?10.0.5.55?) (nate-mail@71.139.18.69) by root.org with ESMTPA; 28 Feb 2007 00:42:05 -0000 Message-ID: <45E4CFE8.6090509@root.org> Date: Tue, 27 Feb 2007 16:42:16 -0800 From: Nate Lawson User-Agent: Thunderbird 1.5.0.9 (X11/20070214) MIME-Version: 1.0 To: Max Laier References: <45E4ADCD.4090909@root.org> <200702280119.08987.max@love2party.net> In-Reply-To: <200702280119.08987.max@love2party.net> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, freebsd-arch@freebsd.org Subject: Re: PATCH - update TSC freq when cpufreq changes it X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Feb 2007 02:24:00 -0000 Max Laier wrote: > On Tuesday 27 February 2007 23:16, Nate Lawson wrote: >> Attached is a patch that uses eventhandlers to update the TSC freq. >> This is important because DELAY() uses TSC directly (on i386 and amd64) >> but the rate calculated at boot changes if cpufreq is in use. >> >> It maintains current behavior that cpufreq transitions are denied if >> TSC is the active timecounter. The API is that there is a pre and post >> transition eventhandler that is called by the cpufreq core. The pre >> handler is passed the next state (including freq, power, etc.) and can >> store a non-zero status value in the output arg to indicate it wants to >> reject the transition. The post handler also is passed the next state >> and the result of the transition (0 on success). > > Any reason for passing the result to the post handler in by reference - > other than being able to re-use the same function type as in the pre > handler? API-wise this seems to be a mistake as one consumer could mess > up the result for the rest and the variable name "error" in the INVOKE > also suggests that this could be used to report back. Yes, the main gaol was to reuse the function. Plus I thought in the future there might be some conceivable need to revoke a change after it had occurred ("oops! change right back!"). We wouldn't need to change an API to allow that. Unless there's a real problem with it, I'd like to keep that ability in the API. To make it clear though, I should probably assign error to some tmp var and pass that in to cpufreq_post_change handlers so it has no effect if the user overwrites it. -- Nate From owner-freebsd-arch@FreeBSD.ORG Wed Feb 28 08:42:36 2007 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6875216A401; Wed, 28 Feb 2007 08:42:36 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 2921313C461; Wed, 28 Feb 2007 08:42:36 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id DD20217462; Wed, 28 Feb 2007 08:42:34 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.8/8.13.8) with ESMTP id l1S8gWKi042794; Wed, 28 Feb 2007 08:42:34 GMT (envelope-from phk@critter.freebsd.dk) To: Nate Lawson From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 27 Feb 2007 14:16:45 PST." <45E4ADCD.4090909@root.org> Date: Wed, 28 Feb 2007 08:42:32 +0000 Message-ID: <42793.1172652152@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: arch@freebsd.org, current@freebsd.org Subject: Re: PATCH - update TSC freq when cpufreq changes it X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Feb 2007 08:42:36 -0000 In message <45E4ADCD.4090909@root.org>, Nate Lawson writes: >Attached is a patch that uses eventhandlers to update the TSC freq. Question: are we at a point where the TSC-frequency reported by ACPI is more precise than our own ad-hoc calibrations ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Wed Feb 28 20:17:30 2007 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2C9FA16A400 for ; Wed, 28 Feb 2007 20:17:30 +0000 (UTC) (envelope-from nate@root.org) Received: from root.org (root.org [67.118.192.226]) by mx1.freebsd.org (Postfix) with ESMTP id ECBA313C491 for ; Wed, 28 Feb 2007 20:17:27 +0000 (UTC) (envelope-from nate@root.org) Received: (qmail 21206 invoked from network); 28 Feb 2007 19:26:11 -0000 Received: from ppp-71-139-18-69.dsl.snfc21.pacbell.net (HELO ?10.0.5.55?) (nate-mail@71.139.18.69) by root.org with ESMTPA; 28 Feb 2007 19:26:11 -0000 Message-ID: <45E5D760.4030409@root.org> Date: Wed, 28 Feb 2007 11:26:24 -0800 From: Nate Lawson User-Agent: Thunderbird 1.5.0.9 (X11/20070214) MIME-Version: 1.0 To: Poul-Henning Kamp References: <42793.1172652152@critter.freebsd.dk> In-Reply-To: <42793.1172652152@critter.freebsd.dk> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: arch@freebsd.org, current@freebsd.org Subject: Re: PATCH - update TSC freq when cpufreq changes it X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Feb 2007 20:17:30 -0000 Poul-Henning Kamp wrote: > In message <45E4ADCD.4090909@root.org>, Nate Lawson writes: > >> Attached is a patch that uses eventhandlers to update the TSC freq. > > Question: are we at a point where the TSC-frequency reported by ACPI > is more precise than our own ad-hoc calibrations ? It's a valid question, but mostly irrelevant. This code only comes into play after the TSC freq has been changed by a cpufreq driver. If the freq never changes, we always use the original boot-calibrated value. For example, if the freq went from 1600 to 800 mhz, the original value is off by 100% with the current code. The values supplied by the cpufreq driver are definitely going to be a lot closer. In the long term, I have some calibration code that bde@ helped with that gets a very accurate value but may take a while to reach equilibrium (since it runs with interrupts enabled). This would only run once in a task thread the first time a given freq is chosen. Then we'd cache that value for that setting. -- Nate From owner-freebsd-arch@FreeBSD.ORG Wed Feb 28 20:23:23 2007 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8054E16A484; Wed, 28 Feb 2007 20:23:23 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 4249C13C4AA; Wed, 28 Feb 2007 20:23:23 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id F246217462; Wed, 28 Feb 2007 20:23:21 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.8/8.13.8) with ESMTP id l1SKNL2W070794; Wed, 28 Feb 2007 20:23:21 GMT (envelope-from phk@critter.freebsd.dk) To: Nate Lawson From: "Poul-Henning Kamp" In-Reply-To: Your message of "Wed, 28 Feb 2007 11:26:24 PST." <45E5D760.4030409@root.org> Date: Wed, 28 Feb 2007 20:23:21 +0000 Message-ID: <70793.1172694201@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: arch@freebsd.org, current@freebsd.org Subject: Re: PATCH - update TSC freq when cpufreq changes it X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Feb 2007 20:23:23 -0000 In message <45E5D760.4030409@root.org>, Nate Lawson writes: >Poul-Henning Kamp wrote: >It's a valid question, but mostly irrelevant. Not at all. It may be a lot cheaper for us to just use the value from the ACPI than to calibrate. Only in the increasingly rare case where TSC is used for timecounter AND the system isn't using NTP is the precise frequency really interesting. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Thu Mar 1 06:19:34 2007 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DA5F916A408 for ; Thu, 1 Mar 2007 06:19:34 +0000 (UTC) (envelope-from nate@root.org) Received: from root.org (root.org [67.118.192.226]) by mx1.freebsd.org (Postfix) with ESMTP id 8AD5C13C4BF for ; Thu, 1 Mar 2007 06:19:34 +0000 (UTC) (envelope-from nate@root.org) Received: (qmail 75603 invoked from network); 1 Mar 2007 06:19:36 -0000 Received: from ppp-71-139-18-69.dsl.snfc21.pacbell.net (HELO ?10.0.5.55?) (nate-mail@71.139.18.69) by root.org with ESMTPA; 1 Mar 2007 06:19:36 -0000 Message-ID: <45E67089.7070306@root.org> Date: Wed, 28 Feb 2007 22:19:53 -0800 From: Nate Lawson User-Agent: Thunderbird 1.5.0.9 (X11/20070214) MIME-Version: 1.0 To: Poul-Henning Kamp References: <70793.1172694201@critter.freebsd.dk> In-Reply-To: <70793.1172694201@critter.freebsd.dk> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: arch@freebsd.org, current@freebsd.org Subject: Re: PATCH - update TSC freq when cpufreq changes it X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2007 06:19:35 -0000 Poul-Henning Kamp wrote: > In message <45E5D760.4030409@root.org>, Nate Lawson writes: >> Poul-Henning Kamp wrote: > >> It's a valid question, but mostly irrelevant. > > Not at all. It may be a lot cheaper for us to just use the > value from the ACPI than to calibrate. Only in the increasingly > rare case where TSC is used for timecounter AND the system isn't > using NTP is the precise frequency really interesting. > Ah, that's something different. I don't think it's a good idea to use the provided value outright when something more empirical is available. With cpufreq modes like p4tcc or acpi_throttling, you only have a relative setting anyway (i.e. 50%) so you still have to measure the base freq at some point. Boot is a good place to do it. Ultimately, my goal is to re-calibrate (with intr on) each level the first time it's used, then cache it in cpufreq as the "real" freq. It will provide that value in the cf_level struct and then eventhandler consumers can use that. That value will be accurate and empirical. For now, the goal is to just get TSC matching reality a little better (say +/- 1% instead of +100% or so). -- Nate From owner-freebsd-arch@FreeBSD.ORG Fri Mar 2 15:16:08 2007 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BB21B16A404; Fri, 2 Mar 2007 15:16:08 +0000 (UTC) (envelope-from tshadwick+freebsd-arch.freebsd.org@oss-solutions.com) Received: from moogle.hksilver.net (mail.hksilver.net [208.231.66.99]) by mx1.freebsd.org (Postfix) with ESMTP id 7E37413C467; Fri, 2 Mar 2007 15:16:08 +0000 (UTC) (envelope-from tshadwick+freebsd-arch.freebsd.org@oss-solutions.com) Received: from [172.16.30.8] (chibi.shadwick.home [172.16.30.8]) by moogle.hksilver.net (8.14.0/8.13.4) with ESMTP id l22FGA6u085408; Fri, 2 Mar 2007 09:16:10 -0600 (CST) (envelope-from tshadwick+freebsd-arch.freebsd.org@oss-solutions.com) Message-ID: <45E83FB7.1060002@oss-solutions.com> Date: Fri, 02 Mar 2007 09:16:07 -0600 From: Tony Shadwick User-Agent: Mail/News 1.5.0.2 (Macintosh/20060310) MIME-Version: 1.0 To: Markus Brueffer References: <45E3467E.2070000@oss-solutions.com> <200702270345.13194.markus@FreeBSD.org> In-Reply-To: <200702270345.13194.markus@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.90/2701/Fri Mar 2 08:16:16 2007 on moogle.hksilver.net X-Virus-Status: Clean Cc: freebsd-arch@freebsd.org Subject: Re: USB HID Driver help X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2007 15:16:08 -0000 Sorry for being slow to respond. I tried doing kldload uhid, and was told "file already exists", so I take that to presume uhid is getting loaded at boot, thus perhaps you're right about needing to work around this. How would you suggest? Markus Brueffer wrote: > Hi Tony, > > On Monday 26 February 2007 21:43, Tony Shadwick wrote: >> I'm definitely not a high-end programmer, but I have gone to the trouble >> of working out the protocol for a USB light gun that is normally used on >> a Playstation 2 video game console. It has 10 buttons, and can track >> on-screen location if it has access to the composite sync video signal. >> >> http://forum.arcadecontrols.com/index.php?topic=60813.0 >> >> I've written just a basic parser for the gun. FreeBSD picks up the gun >> and gives it a ugen character device that I then take continuous input >> from. The protocol is 6 bytes long repeated pretty much as fast as the >> gun can send it. > > Did you have uhid(4) in the kernel or loaded as module? If not, please try > loading the module and see if the device gets picked up by it (you need to > replug it after loading the module). > > Judging from the description of the protocol, it seems that the device is a > regular USB HID device. If it doesn't get picked up by uhid(4), it suffers > from the same problem as the gamepad of the Xbox360 by not exposing itself as > being a regular USB HID device and not providing a HID descriptor. Both can > be worked around but please verify first, that uhid(4) doesn't already > support the device. Writing an extra driver for this device is not > neccessary. > > Markus > From owner-freebsd-arch@FreeBSD.ORG Fri Mar 2 15:46:04 2007 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 013B616A401; Fri, 2 Mar 2007 15:46:04 +0000 (UTC) (envelope-from tshadwick+freebsd-arch.freebsd.org@oss-solutions.com) Received: from moogle.hksilver.net (mail.hksilver.net [208.231.66.99]) by mx1.freebsd.org (Postfix) with ESMTP id 9637A13C428; Fri, 2 Mar 2007 15:46:03 +0000 (UTC) (envelope-from tshadwick+freebsd-arch.freebsd.org@oss-solutions.com) Received: from [172.16.30.8] (chibi.shadwick.home [172.16.30.8]) by moogle.hksilver.net (8.14.0/8.13.4) with ESMTP id l22Fk3DB085636; Fri, 2 Mar 2007 09:46:03 -0600 (CST) (envelope-from tshadwick+freebsd-arch.freebsd.org@oss-solutions.com) Message-ID: <45E846B7.9030801@oss-solutions.com> Date: Fri, 02 Mar 2007 09:45:59 -0600 From: Tony Shadwick User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: Tom Rhodes References: <45E3467E.2070000@oss-solutions.com> <200702270345.13194.markus@FreeBSD.org> <45E83FB7.1060002@oss-solutions.com> <20070302103957.7fd27ef9.trhodes@FreeBSD.org> In-Reply-To: <20070302103957.7fd27ef9.trhodes@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.90/2701/Fri Mar 2 08:16:16 2007 on moogle.hksilver.net X-Virus-Status: Clean Cc: markus@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: USB HID Driver help X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2007 15:46:04 -0000 Tom Rhodes wrote: > On Fri, 02 Mar 2007 09:16:07 -0600 > Tony Shadwick wrote: > >> Sorry for being slow to respond. I tried doing kldload uhid, and was >> told "file already exists", so I take that to presume uhid is getting >> loaded at boot, thus perhaps you're right about needing to work around >> this. How would you suggest? > > Or is included via the GENERIC kernel file. So you will need to > remove it from your kernel before using the module. > >> >> Markus Brueffer wrote: >>> Hi Tony, >>> >>> On Monday 26 February 2007 21:43, Tony Shadwick wrote: >>>> I'm definitely not a high-end programmer, but I have gone to the trouble >>>> of working out the protocol for a USB light gun that is normally used on >>>> a Playstation 2 video game console. It has 10 buttons, and can track >>>> on-screen location if it has access to the composite sync video signal. >>>> >>>> http://forum.arcadecontrols.com/index.php?topic=60813.0 >>>> >>>> I've written just a basic parser for the gun. FreeBSD picks up the gun >>>> and gives it a ugen character device that I then take continuous input >>>> from. The protocol is 6 bytes long repeated pretty much as fast as the >>>> gun can send it. >>> Did you have uhid(4) in the kernel or loaded as module? If not, please try >>> loading the module and see if the device gets picked up by it (you need to >>> replug it after loading the module). >>> >>> Judging from the description of the protocol, it seems that the device is a >>> regular USB HID device. If it doesn't get picked up by uhid(4), it suffers >>> from the same problem as the gamepad of the Xbox360 by not exposing itself as >>> being a regular USB HID device and not providing a HID descriptor. Both can >>> be worked around but please verify first, that uhid(4) doesn't already >>> support the device. Writing an extra driver for this device is not >>> neccessary. >>> >>> Markus >>> >> _______________________________________________ >> freebsd-arch@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-arch >> To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" >> > > We wre trying to establish that uhid was loaded to see whether the light gun was really an HID device or not, and if it is similar to the XBox controller that is, but doesn't get detected, we need to work around that problem. I'm asking how it is suggested that I work around the issue. I've never written a driver before. From owner-freebsd-arch@FreeBSD.ORG Fri Mar 2 16:02:33 2007 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B7B3E16A4E9 for ; Fri, 2 Mar 2007 16:02:33 +0000 (UTC) (envelope-from trhodes@FreeBSD.org) Received: from chipmunk.ai.net (axe.ai.net [205.134.161.26]) by mx1.freebsd.org (Postfix) with ESMTP id 6271B13C481 for ; Fri, 2 Mar 2007 16:02:33 +0000 (UTC) (envelope-from trhodes@FreeBSD.org) Received: from localhost (ip70-177-190-239.dc.dc.cox.net [70.177.190.239]) by chipmunk.ai.net (8.13.4/8.13.4) with SMTP id l22Fe3m9085806; Fri, 2 Mar 2007 10:40:04 -0500 (EST) (envelope-from trhodes@FreeBSD.org) Date: Fri, 2 Mar 2007 10:39:57 -0500 From: Tom Rhodes To: Tony Shadwick Message-Id: <20070302103957.7fd27ef9.trhodes@FreeBSD.org> In-Reply-To: <45E83FB7.1060002@oss-solutions.com> References: <45E3467E.2070000@oss-solutions.com> <200702270345.13194.markus@FreeBSD.org> <45E83FB7.1060002@oss-solutions.com> Organization: The FreeBSD Project X-Mailer: Sylpheed version 1.0.6 (GTK+ 1.2.10; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: markus@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: USB HID Driver help X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2007 16:02:33 -0000 On Fri, 02 Mar 2007 09:16:07 -0600 Tony Shadwick wrote: > Sorry for being slow to respond. I tried doing kldload uhid, and was > told "file already exists", so I take that to presume uhid is getting > loaded at boot, thus perhaps you're right about needing to work around > this. How would you suggest? Or is included via the GENERIC kernel file. So you will need to remove it from your kernel before using the module. > > > Markus Brueffer wrote: > > Hi Tony, > > > > On Monday 26 February 2007 21:43, Tony Shadwick wrote: > >> I'm definitely not a high-end programmer, but I have gone to the trouble > >> of working out the protocol for a USB light gun that is normally used on > >> a Playstation 2 video game console. It has 10 buttons, and can track > >> on-screen location if it has access to the composite sync video signal. > >> > >> http://forum.arcadecontrols.com/index.php?topic=60813.0 > >> > >> I've written just a basic parser for the gun. FreeBSD picks up the gun > >> and gives it a ugen character device that I then take continuous input > >> from. The protocol is 6 bytes long repeated pretty much as fast as the > >> gun can send it. > > > > Did you have uhid(4) in the kernel or loaded as module? If not, please try > > loading the module and see if the device gets picked up by it (you need to > > replug it after loading the module). > > > > Judging from the description of the protocol, it seems that the device is a > > regular USB HID device. If it doesn't get picked up by uhid(4), it suffers > > from the same problem as the gamepad of the Xbox360 by not exposing itself as > > being a regular USB HID device and not providing a HID descriptor. Both can > > be worked around but please verify first, that uhid(4) doesn't already > > support the device. Writing an extra driver for this device is not > > neccessary. > > > > Markus > > > > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > -- Tom Rhodes From owner-freebsd-arch@FreeBSD.ORG Fri Mar 2 16:10:34 2007 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5137A16A407; Fri, 2 Mar 2007 16:10:34 +0000 (UTC) (envelope-from trhodes@FreeBSD.org) Received: from chipmunk.ai.net (axe.ai.net [205.134.161.26]) by mx1.freebsd.org (Postfix) with ESMTP id 0F75713C48E; Fri, 2 Mar 2007 16:10:33 +0000 (UTC) (envelope-from trhodes@FreeBSD.org) Received: from localhost (ip70-177-190-239.dc.dc.cox.net [70.177.190.239]) by chipmunk.ai.net (8.13.4/8.13.4) with SMTP id l22GAbl5003004; Fri, 2 Mar 2007 11:10:38 -0500 (EST) (envelope-from trhodes@FreeBSD.org) Date: Fri, 2 Mar 2007 11:10:31 -0500 From: Tom Rhodes To: Tony Shadwick Message-Id: <20070302111031.6e485453.trhodes@FreeBSD.org> In-Reply-To: <45E846B7.9030801@oss-solutions.com> References: <45E3467E.2070000@oss-solutions.com> <200702270345.13194.markus@FreeBSD.org> <45E83FB7.1060002@oss-solutions.com> <20070302103957.7fd27ef9.trhodes@FreeBSD.org> <45E846B7.9030801@oss-solutions.com> Organization: The FreeBSD Project X-Mailer: Sylpheed version 1.0.6 (GTK+ 1.2.10; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: trhodes@FreeBSD.org, markus@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: USB HID Driver help X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2007 16:10:34 -0000 On Fri, 02 Mar 2007 09:45:59 -0600 Tony Shadwick wrote: > Tom Rhodes wrote: > > On Fri, 02 Mar 2007 09:16:07 -0600 > > Tony Shadwick wrote: > > > >> Sorry for being slow to respond. I tried doing kldload uhid, and was > >> told "file already exists", so I take that to presume uhid is getting > >> loaded at boot, thus perhaps you're right about needing to work around > >> this. How would you suggest? > > > > Or is included via the GENERIC kernel file. So you will need to > > remove it from your kernel before using the module. > > > >> > >> Markus Brueffer wrote: > >>> Hi Tony, > >>> > >>> On Monday 26 February 2007 21:43, Tony Shadwick wrote: > >>>> I'm definitely not a high-end programmer, but I have gone to the trouble > >>>> of working out the protocol for a USB light gun that is normally used on > >>>> a Playstation 2 video game console. It has 10 buttons, and can track > >>>> on-screen location if it has access to the composite sync video signal. > >>>> > >>>> http://forum.arcadecontrols.com/index.php?topic=60813.0 > >>>> > >>>> I've written just a basic parser for the gun. FreeBSD picks up the gun > >>>> and gives it a ugen character device that I then take continuous input > >>>> from. The protocol is 6 bytes long repeated pretty much as fast as the > >>>> gun can send it. > >>> Did you have uhid(4) in the kernel or loaded as module? If not, please try > >>> loading the module and see if the device gets picked up by it (you need to > >>> replug it after loading the module). > >>> > >>> Judging from the description of the protocol, it seems that the device is a > >>> regular USB HID device. If it doesn't get picked up by uhid(4), it suffers > >>> from the same problem as the gamepad of the Xbox360 by not exposing itself as > >>> being a regular USB HID device and not providing a HID descriptor. Both can > >>> be worked around but please verify first, that uhid(4) doesn't already > >>> support the device. Writing an extra driver for this device is not > >>> neccessary. > >>> > >>> Markus > >>> > >> _______________________________________________ > >> freebsd-arch@freebsd.org mailing list > >> http://lists.freebsd.org/mailman/listinfo/freebsd-arch > >> To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > >> > > > > > > We wre trying to establish that uhid was loaded to see whether the light > gun was really an HID device or not, and if it is similar to the XBox > controller that is, but doesn't get detected, we need to work around > that problem. I'm asking how it is suggested that I work around the > issue. I've never written a driver before. Oh, my bad. I thought you wanted to try the approach of unloading and then re-loading the module but was getting tripped up with the message above. Sorry, -- Tom Rhodes