On the road to libfprint and fprintd 2.0, we've been fixing some long-standing bugs, including one that required porting our PAM module from dbus-glib to sd-bus, systemd's D-Bus library implementation.
As you can imagine, I have confidence in my ability to write bug-free code at the first attempt, but the foresight to know that this code will be buggy if it's not tested (and to know there's probably a bug in the tests if they run successfully the first time around). So we will have to test that PAM module, thoroughly, before and after the port.
Replacing fprintd
First, to make it easier to run and instrument, we needed to replace fprintd itself. For this, we used dbusmock, which is both a convenience Python library and way to write instrumentable D-Bus services, and wrote a template. There are a number of existing templates for a lot of session and system services, in case you want to test the integration of your code with NetworkManager, low-memory-monitor, or any number of other services.
We then used this to write tests for the command-line utilities, so we can both test our new template and test the command-line utilities themselves.
Replacing gdm
Now that we've got a way to replace fprintd and a physical fingerprint reader, we should write some tests for the (old) PAM module to replace sudo, gdm, or the login authentication services.
Co-workers Andreas Schneier and Jakub Hrozek worked on pam_wrapper, an LD_PRELOAD library to mock the PAM library, and Python helpers to write simple PAM services. This LWN article explains how to test PAM applications, and PAM modules.
After fixing a few bugs in pam_wrapper, and combining with the fprintd dbusmock work above, we could wrap and test the fprintd PAM module like it never was before.
Porting to sd-bus
Finally, porting the PAM module to sd-bus was pretty trivial, a loop of 1) writing tests that work against the old PAM module, 2) porting a section of the code (like the fingerprint reader enumeration, or the timeout support), and 3) testing against the new sd-bus based code. The result was no regressions that we could test for.
Conclusion
Both dbusmock, and pam_wrapper are useful tools in your arsenal to write tests, and given those (fairly) easy to use CIs in GNOME and FreeDesktop.org's GitLabs, it would be a shame not to.
You might also be interested in umockdev, to mock a number of device types, and mocklibc (which combined with dbusmock powers polkit's unattended CI)
Showing posts with label dbus. Show all posts
Showing posts with label dbus. Show all posts
Wednesday, 1 April 2020
Sunday, 10 January 2016
Support for "Airplane mode" keys
As we were working on audio jack notifications, and were wondering whether the type of notification we'd pop up in this case could be reused in other cases, I encountered a feature request that could now be solved easily with the rfkill D-Bus service we added to gnome-settings-daemon for the 3.10 release.
If you have keyboard buttons on your laptop to enable or disable Bluetooth, or Airplane mode, you can now use them. Note that the "UWB" toggle key will toggle the whole airplane mode mainly because no in-kernel driver uses it, and nobody remembers what UWB is.
Note that the labels and icons used are still subject to changes. In particular as you can see that the labels are too long for lower resolutions.
If you have keyboard buttons on your laptop to enable or disable Bluetooth, or Airplane mode, you can now use them. Note that the "UWB" toggle key will toggle the whole airplane mode mainly because no in-kernel driver uses it, and nobody remembers what UWB is.
Note that the labels and icons used are still subject to changes. In particular as you can see that the labels are too long for lower resolutions.
Friday, 22 May 2015
iio-sensor-proxy 1.0 is out!
Modern (and some less modern) laptops and tablets have a lot of builtin sensors: accelerometer for screen positioning, ambient light sensors to adjust the screen brightness, compass for navigation, proximity sensors to turn off the screen when next to your ear, etc.
Enabling
We've supported accelerometers in GNOME/Linux for a number of years, following work on the WeTab. The accelerometer appeared as an input device, and sent kernel events when the orientation of the screen changed.
Recent devices, especially Windows 8 compatible devices, instead export a HID device, which, under Linux, is handled through the IIO subsystem. So the first version of iio-sensor-proxy took readings from the IIO sub-system and emulated the WeTab's accelerometer: a few too many levels of indirection.
The 1.0 version of the daemon implements a D-Bus interface, which means we can support more than accelerometers. The D-Bus API, this time, is modelled after the Android and iOS APIs.
Enjoying
Accelerometers will work in GNOME 3.18 as well as it used to, once a few bugs have been merged[1]. If you need support for older versions of GNOME, you can try using version 0.1 of the proxy.
As we've adding ambient light sensor support in the 1.0 release, time to put in practice best practice mentioned by Owen's post about battery usage. We already had code like that in gnome-power-manager nearly 10 years ago, but it really didn't work very well.
The major problem at the time was that ambient light sensor reading weren't in any particular unit (values had different meanings for different vendors) and the user felt that they were fighting against the computer for the control of the backlight.
Richard fixed that though, adapting work he did on the ColorHug ALS sensor, and the brightness is now completely in the user's control, and adapts to the user's tastes. This means that we can implement the simplest of UIs for its configuration.
This will be available in the upcoming GNOME 3.17.2 development release.
Looking ahead
For future versions, we'll want to export the raw accelerometer readings, so that applications, including games, can make use of them, which might bring up security issues. SDL, Firefox, WebKit could all do with being adapted, in the near future.
We're also looking at adding compass support (thanks Elad!), which Geoclue will then export to applications, so that location and heading data is collected through a single API.
Richard and Benjamin Tissoires, of fixing input devices fame, are currently working on making the ColorHug-ALS compatible with Windows 8, meaning it would work out of the box with iio-sensor-proxy.
Links
We're currently using GitHub for bug and code tracking. Releases are mirrored on freedesktop.org, as GitHub is known to mangle filenames. API documentation is available on developer.gnome.org.
[1]: gnome-settings-daemon, gnome-shell, and systemd will need patches
Enabling
We've supported accelerometers in GNOME/Linux for a number of years, following work on the WeTab. The accelerometer appeared as an input device, and sent kernel events when the orientation of the screen changed.
Recent devices, especially Windows 8 compatible devices, instead export a HID device, which, under Linux, is handled through the IIO subsystem. So the first version of iio-sensor-proxy took readings from the IIO sub-system and emulated the WeTab's accelerometer: a few too many levels of indirection.
The 1.0 version of the daemon implements a D-Bus interface, which means we can support more than accelerometers. The D-Bus API, this time, is modelled after the Android and iOS APIs.
Enjoying
Accelerometers will work in GNOME 3.18 as well as it used to, once a few bugs have been merged[1]. If you need support for older versions of GNOME, you can try using version 0.1 of the proxy.
Orientation lock in action
As we've adding ambient light sensor support in the 1.0 release, time to put in practice best practice mentioned by Owen's post about battery usage. We already had code like that in gnome-power-manager nearly 10 years ago, but it really didn't work very well.
The major problem at the time was that ambient light sensor reading weren't in any particular unit (values had different meanings for different vendors) and the user felt that they were fighting against the computer for the control of the backlight.
Richard fixed that though, adapting work he did on the ColorHug ALS sensor, and the brightness is now completely in the user's control, and adapts to the user's tastes. This means that we can implement the simplest of UIs for its configuration.
Power saving in action
This will be available in the upcoming GNOME 3.17.2 development release.
Looking ahead
For future versions, we'll want to export the raw accelerometer readings, so that applications, including games, can make use of them, which might bring up security issues. SDL, Firefox, WebKit could all do with being adapted, in the near future.
We're also looking at adding compass support (thanks Elad!), which Geoclue will then export to applications, so that location and heading data is collected through a single API.
Richard and Benjamin Tissoires, of fixing input devices fame, are currently working on making the ColorHug-ALS compatible with Windows 8, meaning it would work out of the box with iio-sensor-proxy.
Links
We're currently using GitHub for bug and code tracking. Releases are mirrored on freedesktop.org, as GitHub is known to mangle filenames. API documentation is available on developer.gnome.org.
[1]: gnome-settings-daemon, gnome-shell, and systemd will need patches
Thursday, 17 October 2013
More power management changes
As is becoming common, we will have some more power management changes in GNOME 3.12, though those changes will also affect other desktops, whether they use UPower's D-Bus interface, or libupower-glib, the helper library.
The goals of the exercise were simple:
Out with the old
The deprecated interfaces for Suspend, Hibernate, etc. are finally removed, after being obsoleted by logind. We've also removed the QoS interface that nobody was using, and the out-dated battery recall support. It's not that batteries don't explode any more, it's that they don't all come from known-bad batches.
In with the new
We have 2 new properties on each of the devices.
WarningLevel which uses daemon-side configurations to tell you whether a device's battery level is low, critically low, or whether we're about to take action on that critical level.
We also have IconName, which replaces some cut'n'pasted code between desktop components. If your desktop environment has many more icons for all types of devices on low battery, for example, you can ignore this property and use the code you always have.
Using those new properties usefully is the new DisplayDevice object. It groups all the batteries and UPSes in the daemon into one, easy to use object that you can use to display a single status icon in your shell chrome. Obviously, if you want to show more devices, the individual batteries and UPSes are still available through the usual means. And it obviously has the 2 new properties mentioned above, so your session daemon can get told when to show notifications for low batteries.
And finally, using that new combined DisplayDevice is the critical battery action policies. As mentioned above, multi-user systems could not hibernate without requiring the user to enter an administrator password, which is less than convenient when your machine is running out of UPS power fast. The configuration for that policy is now in the daemon itself, with sane defaults, and it will hibernate the machine for you.
And to the modernisation
libupower-glib now uses GDBus, even if the daemon doesn't. The daemon however sends PropertiesChanged signals which means that modern D-Bus bindings will automatically get the new values for properties, instead of polling the daemon. The DeviceChanged and Changed signals have thus been removed.
API changes
They are numerous, too many to mention here. I've posted to the device-kit mailing-list with a list of changes that were made, reply there if you have any questions regarding using UPower in your application or session daemons.
Miscellaneous
systemd >= 207 will save your brightness settings across reboots, and the upcoming systemd 209 will have support for saving keyboard backlight across reboots.
I've made attempts at supporting Intel Rapid Start in systemd, but this will actually require kernel changes. Hopefully we should be able to land this by the time GNOME 3.12 is released.
The goals of the exercise were simple:
- reduce wake-ups on the daemon and on the client side
- reduce code duplication amongst desktop environments, and even within the same environment (composite battery, anyone?)
- moving some policy actions to a lower level (one could not request hibernation or suspend when multiple users were logged in without interaction and passwords)
Out with the old
The deprecated interfaces for Suspend, Hibernate, etc. are finally removed, after being obsoleted by logind. We've also removed the QoS interface that nobody was using, and the out-dated battery recall support. It's not that batteries don't explode any more, it's that they don't all come from known-bad batches.
In with the new
We have 2 new properties on each of the devices.
WarningLevel which uses daemon-side configurations to tell you whether a device's battery level is low, critically low, or whether we're about to take action on that critical level.
We also have IconName, which replaces some cut'n'pasted code between desktop components. If your desktop environment has many more icons for all types of devices on low battery, for example, you can ignore this property and use the code you always have.
Using those new properties usefully is the new DisplayDevice object. It groups all the batteries and UPSes in the daemon into one, easy to use object that you can use to display a single status icon in your shell chrome. Obviously, if you want to show more devices, the individual batteries and UPSes are still available through the usual means. And it obviously has the 2 new properties mentioned above, so your session daemon can get told when to show notifications for low batteries.
And finally, using that new combined DisplayDevice is the critical battery action policies. As mentioned above, multi-user systems could not hibernate without requiring the user to enter an administrator password, which is less than convenient when your machine is running out of UPS power fast. The configuration for that policy is now in the daemon itself, with sane defaults, and it will hibernate the machine for you.
And to the modernisation
libupower-glib now uses GDBus, even if the daemon doesn't. The daemon however sends PropertiesChanged signals which means that modern D-Bus bindings will automatically get the new values for properties, instead of polling the daemon. The DeviceChanged and Changed signals have thus been removed.
API changes
They are numerous, too many to mention here. I've posted to the device-kit mailing-list with a list of changes that were made, reply there if you have any questions regarding using UPower in your application or session daemons.
Miscellaneous
systemd >= 207 will save your brightness settings across reboots, and the upcoming systemd 209 will have support for saving keyboard backlight across reboots.
I've made attempts at supporting Intel Rapid Start in systemd, but this will actually require kernel changes. Hopefully we should be able to land this by the time GNOME 3.12 is released.
Saturday, 22 November 2008
A bit of visibility
fprintd (the D-Bus libfprint front-end with PolicyKit goodness) now has something visible for people to see: Documentation!
Still a bunch more TODOs on the list, but work on the front-end for enrollment should start soon.
Still a bunch more TODOs on the list, but work on the front-end for enrollment should start soon.
Subscribe to:
Posts (Atom)