Scott Cheloha <[email protected]> wrote: > speaker(4) is a whimsical thing, but I don't think we should have a > dedicated chiptune interpreter in the kernel. > > This patch unhooks the driver and the manpage from the build. The > driver is built for alpha, amd64, and i386. > > A subsequent patch will move all relevant files to the attic and clean > up manpage cross references. > > Nothing in base or xenocara includes <dev/spkrio.h>. > > I see a couple SPKRTONE and SPKRTUNE symbols in ports, but I imagine > those ports don't use the symbols if they are missing. > > ok?
PCEngines' APU2 [1] attach spkr(4) and I have used it in the past for some rudimentary monitoring, beeping when a certain condition is met. It does the big advantage of being something that can be done offline. I don't have experience with device drivers development, but the code for it doesn't seem bad nor complex nor rot-prone, and stayed basically unmodified since it was imported. I can understand having a music language interpreter in the kernel being the only bad thing about it. In that case, wouldn't it be an option to keep the core of driver and move the language interpreter to userland? Something like spkrctl(8). I can probably put that together over the weekend in fact, if patch or GTFO is the norm. [1]: https://pcengines.ch/apu2.htm -Lucas
