Date: Wed, 24 Mar 2021 10:27:28 +0200 From: Christos Margiolis <christos@christosmarg.xyz> To: Alfonso Siciliano <alfix86@gmail.com> Cc: freebsd-hackers@freebsd.org Subject: Re: [GSoC 2021] Project Proposal Message-ID: <20210324082728.wycjsodiy5wdjfip@pleb> In-Reply-To: <20210323232747.80b0c7413c758e0d30d50727@gmail.com> References: <20210322144928.ry75v5nlfhpzcfir@pleb> <93c692373cf35aae8dab4f1c63c38d08@bsdforge.com> <20210322161802.zouhvffwcuibwtmb@pleb> <d5924e61-842a-54d6-8a3e-1908225baeb2@quip.cz> <20210322175529.kadptzccf7vhtz27@pleb> <20210323232747.80b0c7413c758e0d30d50727@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Mar 23, 2021 at 11:27:47PM +0100, Alfonso Siciliano wrote: > I know the problem, my solution in mixertui.c was to define `struct item` with > `.lvol|.rvol|.lmute|.rmute`, however mixer(8) is an one-shot program so mixerd > or /var/db/mixerN-state could make sense, but why not the ideal solution: > to implement SNDCTL_MIX_EXTINFO, MIXT_ONOFF and the other missing mixer ioctls > avoiding computation and daemons in userland? That sounds like a cleaner and more extensible solution indeed, hadn't thought about it. > However if you are considering to add the support for virtual_oss the library > could became interesting. virtual_oss is something I too think would make a good addition to the library. Thing is at the moment I need to find someone who's interested in mentoring this project for GSoC as soon as possible. If someone appears that then we'll have time for more interesting additions. ---------------------------------------------- Christos Margiolis <christos@christosmarg.xyz> https://christosmarg.xyz
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20210324082728.wycjsodiy5wdjfip>