hal-set-property does not support the argument --direct. This is used by several xf86-input-* packages. The issue is that some of these devices require helper scripts that must be called during hal initialization. Usually these packages contain HAL fdi policy files that add a key to info.callouts.add for the respective device, which gets executed as hal is starting up if the device is detected. The issue is that these scripts usually want to call hal-set-property to change various keys within hal. Since hal has not yet fully started, the normal method of communication over dbus is unavailable, and hal-set-property returns immediately with a 'Could not initialize connection to hald' error. The attached patch adds the option --direct, which allows for an alternative method of communicating with hal while it is starting up, but dbus communication is /not/ yet available. Tested against hal-0.5.11-r8 (x86 and amd64). Reproducible: Always Steps to Reproduce: 1. Install hal 2. Install a package like xf86-input-vmmouse 3. Observe as xf86-input-vmmouse's helper script, /usr/lib/hal/hal-probe-vmmouse, fails because hal-set-property cannot connect to hal, since hal-set-property does not support --direct; even if the --direct argument is removed from hal-probe-vmmouse, hal-set-property will /still/ fail because hal is not yet ready for communication over the dbus socket. Actual Results: Ultimately, this causes issues where various helper scripts in the xf86-input-* packages fail, since they cannot call hal-set-property to modify various values inside hal. In the case of xf86-input-vmmouse, the helper script hal-probe-vmmouse fails to launch hal-set-property and properly set the key input.x11_driver to "vmmouse", and instead it remains as "evdev". When starting X.org with hal support, X will improperly load the IMPS/2 driver, instead of loading the vmmouse driver which offers full VMware mouse support (because input.x11_driver was not set to "vmmouse"). Expected Results: If hal-set-property supports --direct (which it doesn't, currently), then any helper script executed while hal is **starting up** (but cannot be communicated to over dbus), can still talk to hald via a "direct" method that bypasses the dbus socket. This allows the helper scripts to modify key values as expected.
Created attachment 192806 [details, diff] hal-set-property --direct support Patch for hal-0.5.11 (and higher?)- adds --direct support to hal-set-property, to bypass dbus communication so that helper programs added to various devices via fdi policies can still call hal-set-property while hal is starting up (but dbus communication is unavailable) to modify various keys.
Has this patch been approved by upstream?
Yes, it's in hal 0.5.13 - now in the tree.
