On 27 March 2012 19:00, Adam Williamson <awilliam@xxxxxxxxxx> wrote: > On Sun, 2012-03-25 at 13:22 +0100, Ian Malone wrote: > >> Or indeed, if anyone can show me where this is documented. All I've >> managed to find with google are git commits and irrelevant mailing >> list fragments. systemd-logind isn't documented, >> /lib/udev/rules.d/70-uaccess.rules appears to deal with this, but what >> I've seen so far appears to say that udev handling of this is being >> deprecated for systemd, > > 70-uaccess.rules is in fact owned by systemd. This is the systemd > handling of it. > Interesting, not sure how you'd tell that. I've now noticed the header # This file is part of systemd. And rpm -qf confirms that, but why don't systemd and udev get into conflict over it? >> also there are no suitable ID_ in there, which >> brings me back to the question of choosing suitable names. Is there a >> list of reserved names or naming rules? If you were creating >> site-specific rules presumably they could go in /etc/... To have the >> package for the software add its own rules would Fedora accept a new >> ID_ into wherever ID_ needs to go? (70-uaccess.rules?). > > That is what you need, yes. AIUI, anyway. My experience with this is in > the context of libconcord, which handles Harmony remote controls; Kay > got ID_REMOTE_CONTROL added to udev (at the time) and 70-uaccess.rules > owned by systemd (now) for libconcord to use in its udev rules file. > Thanks for that. I'd run some discussion of the ID_REMOTE_CONTROL property and it did look like the most relevant situation. Nice to have some confirmation. >> I assume that >> setting TAG+="uaccess" directly (assuming that's what's needed, is it? >> how should I know?) in a device rule would be frowned on. > > I believe so, yeah. The idea is to handle categories of device together > so that admins can more easily customize the behaviour, I think. Yes, Kay has confirmed this on the systemd devel list. -- imalone -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
