Date: Mon, 22 Mar 2021 20:46:52 -0700 From: Chris <bsd-lists@bsdforge.com> To: Christos Margiolis <christos@christosmarg.xyz> Cc: freebsd-hackers@freebsd.org Subject: Re: [GSoC 2021] Project Proposal Message-ID: <9ebb79352343bf31c9f46381d5678d65@bsdforge.com> In-Reply-To: <20210322161802.zouhvffwcuibwtmb@pleb> References: <20210322144928.ry75v5nlfhpzcfir@pleb> <93c692373cf35aae8dab4f1c63c38d08@bsdforge.com> <20210322161802.zouhvffwcuibwtmb@pleb>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2021-03-22 09:18, Christos Margiolis wrote: > On Mon, Mar 22, 2021 at 08:41:20AM -0700, Chris wrote: >> Every version of mixer that I have run keeps state in /var/db/mixerN-state: >> vol 100:100 pcm 100:100 >> where N is (0-9) which represents a previous state. This has been the case >> for >> as long as I can remember. It's much the same WiFi lease(s). Unless I'm >> missing >> something IMHO it's current incarnation seems trivial to work with / >> manipulate. >> One might consider using JSON notation in it to allow for more advanced >> features >> and manipulation / reading / status I suppose. >> I'm not trying to take the wind out of your sails, or anything. Just >> sharing >> my own personal observation. :-) >> >> --Chris > > Interesting, I didn't really know about that, so I'll have to look more into > it > for sure. In any case, I still think my main argument stands that a library > which can be used by all userland programs that might want to have access > to the mixer will be of benefit. > > I've already mentioned a few use cases in my initial email. Even in the case > that you outlined - the state already being cached in `/var/db/mixerN-state` > - > I think that libmixer(3) could provide with functions that deal with those > files, > instead of having the programmer find ways to deal with them. > > mixer(8) at the moment still doesn't have the option to mute/unmute the > mixer even with those files existing, so having a library handle all > that stuff, will make mixer(8) basically a frontend for the library and > will have cleaner code. And as I've already said in the previous email, > other > programs such as MixerTUI could use the library too. I think that makes > things more extensible; after all, many FreeBSD programs already follow > that design (library + a frontend for it). Like I said; I'm not trying to take the wind out of your sails. I just thought that it might interest you to know about the state file, and it's location. :-) I'm also inclined to agree; a "helper" library may well better leverage "conveniences" for mixer. Even if it only made it easier to manipulate the state file. ;-) It's all good, and don't get the idea I'm trying to shut you down, or anything like that. :-) Good luck, and best wishes! --Chris > ---------------------------------------------- > Christos Margiolis <christos@christosmarg.xyz> > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9ebb79352343bf31c9f46381d5678d65>