On Mon, Feb 02, 2015 at 12:57:24PM +0100, Lennart Poettering wrote: > On Fri, 30.01.15 08:12, Peter Hutterer (peter.hutte...@who-t.net) wrote: > > > Hi, > > > > I need some sort of way of assigning udev properties on the fly to a device, > > but I'm short of ideas how to do this sensibly. > > THis is explicitly not supported. Conceptually udev only supports new, > change and removed events, and there's no way to change only > individual props. if you want to change individual props, you need to > plug them into the rules files, and retrigger the device as a whole, > which will not only refresh the props you are interested but all props > of the device. > > > A bit more context: > > The libinput test suite works by setting up uinput devices for each test > > case, then hooking libinput contexts up to those devices. libinput itself > > uses some udev properties to adjust internal behaviours. That works for real > > hardware because the rules are written for that (and we can require a make > > install) but uinput devices don't have the same hierarchy and thus don't > > trigger those rules. Plus, requiring an install before running the test > > suite isn't very nice. > > > > So basically what I'd like would be a udev_device_set_property() call or > > something similar. We're in control of the uinput and the libinput bits, > > i.e. there are no race conditions to worry about. > > > > Because of uinput, the test suite runs as root. One solution would be to > > drop a custom test rule, reload, create the uinput device, run the test, > > rm the rule again. Not pretty though, I was hoping there was something > > nicer. > > > > Any ideas? > > Sorry, this is not available, and we explicitly don't want that as > people would misuse it if it existed. It would require inventing a new > notifciation scheme for individual prop changes, and we don#t want > that. > > Note that udev reads udev rules from /run, so you could drop them > there, then retrigger the device (by writing "change" into the > device's uevent file in /sys), and remove the rule afterwards. > > Other than that umockdev and LD_PRELOAD hacks might be options for > test cases like this...
ok, no worries. thanks for the answers, we're going with the /run option now, which isn't 100% perfect but close enough for the tests we need at the moment. Cheers, Peter _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel