I agree with the following solution. On Feb 17, 2014 8:42 AM, "Ted Felix" <[email protected]> wrote:
> On 02/11/2014 11:29 PM, Lingzhu Xiang wrote: > >> If now acpid users change rules to handle button/f20 for mic muting, >> and in the future udev maps something else to f20 in your case, then >> those rules will break again. >> > > But that's a configuration file change, not a code change. So that's > ok. The key is to avoid code changes at all costs. Give the users the > power to do what they need. > > Mapping both the micmute event and the F20 button to button/micmute in > the code limits the user's abilities. It also hides an implementation > detail that the users, unfortunately, should be aware of. > > I can. >> > > If you can work with button/f20, then let's go with that for an interim > fix. Then we can consider alternatives. > > Based on the particulars, I have a number of alternative solutions that >>> should solve your current issue and future-proof acpid at the same time. >>> >> > As an example of an alternative that would move the changes out of the > code and into the config files, we can implement a "remapping" feature in > acpid that would allow the user, through a config file, to remap an event > (say button/f20) to another event (say button/micmute). Then you've got > exactly what you want, and acpid code need not change in the future when > someone else would like to use F20 for something else. > > (Thanks for copying the entire email. My ISP's email server does not > like bugs.debian.org at all.) > > Ted. >
