From owner-freebsd-hackers Sun Dec 10 11:34:35 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA03767 for hackers-outgoing; Sun, 10 Dec 1995 11:34:35 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id LAA03752 for ; Sun, 10 Dec 1995 11:34:27 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id MAA01469; Sun, 10 Dec 1995 12:32:42 -0700 From: Terry Lambert Message-Id: <199512101932.MAA01469@phaeton.artisoft.com> Subject: Re: Getting involved... To: cross@math.psu.edu (Dan Cross) Date: Sun, 10 Dec 1995 12:32:42 -0700 (MST) Cc: hackers@FreeBSD.ORG In-Reply-To: <199512100812.DAA11249@hausdorff.math.psu.edu> from "Dan Cross" at Dec 10, 95 03:12:19 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > I'm getting very interested in helping out with the FreeBSD effort. I've > been lurking for quite a while now, and running FreeBSD machines in several > places since June. > > Let me just say now, publically, that I am really impressed with a lot of > stuff, especially the things that have happened in the kernel. Also, the > stuff that didn't get shipped with 4.4BSD-Lite is really top notch.. > (ie, the block io stuff in vfs_bio.c is especially nifty just as an example.) > > At anyrate, I'd really like to get involved with active development, can > someone point me in the right direction to get started? Thanks! There is someone who wants keyclick. Lord knows why. This would be a good first project, with a minimum of kernel code involved. It would require gaining a small understanding of the console driver and how ioctl()'s are implemented (if you didn't know already). It *would* potentially require that you could build an X server from the XFree86 sources, but probably it would only require the sources to see what the X server is looking for so that the finished code would be compatible with "just working the next time X is released". Here is my response to the guy. I am including some of his text without permission, which I don't usually do, but since it is unattributed this shouldn't embarrass him: [ ... keyclick ... ] > > /usr/src/sys/i386/isa/syscons.c > > Found it; then realized two things. One, my new > box isn't isa, it is a PCI-bus. Prob'y makes no > difference, though, right? The console driverr > oughtta work for any bus...(?) Two, I've become > addicted to having _many_ xterms running. And > syscons.c is probably just for the monochrone > while-on-black console. No. The X server goes through the console for it's keyboard I/O and for some aspects of its video setup and staging for console switching. So the audio hooks that are missing in syscons.c are the ioctl's for the X server with regard to the console device it has open. And that's syscons. > Besides, on my 2.0.5 vers, I see nothing having > to do with keyclicks. Uh, that's because it doesn't support keyclicks (probably why you don't hear them 8-)). > CLK (cap lock) yes, and > tons more. But nothing for clicks/cks/clks. > Or anywhere else. In spkr.c, in tone(); but > nothing to drive is. So: lost. You will need to add a flag, probably to the per virtual console structure, that defaults to 0 and can be set to 0 or 1 by an ioctl you add. Then you will need to make the keyboard key_down event input routine look at the flag right before it returns. Besure it's *inside* the key repeat loop. And if a flag is there, you will need to make a call at a particular freq. that sounds like a square wave click, probably, with a sort duration, to the same code that does the bell. Then you will need to hack the syscons configuration utility to take an argument regarding keyclick and make the ioctl to turn it on or off... the utility is named "vidcontrol". Then you can test it outside of X and see if it works or not. If it does, then you can hack the ioctl call into the XSET X protocol server primitive in the X server code. It probably has some idea inside it to do it already, so you should look there first for standard ioctl name and parameters: it may be that if you define the right ioctl in the right header file (the one that tells it how to do console switching, etc.), then the X server will just call it for you magically. This would be the best approach, since avoiding changes to the xserver code is a very, very good thing to do. > > The XFree86 sources are a seperate package; use the package mechanism > > to install them from CDROM or the net. > > I've got the v2.05 CDROM. Slowly, very slowly, > getting X working with xdm and .xsession and so > forth. Do you know what I've got to hack in X > to make the speaker keyclick?? I've been looking > for the code to xset, but haven't found it. You need to modify the server sources, not the xset utility sources. > Is this C code I looking to modify, or one of > those Xconfig files? I'm continuing to poke > around, but thanks for your help! C code. You can see that the amount of hacking means that someone would have to want keyclick pretty bad to get it. 8-). ========================================================================= Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.