! Please note that this is a snapshot of our old Bugzilla server, which is read only since May 29, 2020. Please go to gitlab.xfce.org for our new server !
Deprecate use of HAL
Status:
RESOLVED: FIXED
Product:
Xfce4-power-manager
Component:
General

Comments

Description Cody A.W. Somerville 2010-01-05 20:52:51 CET
HAL is no longer maintained and is in the process of being deprecated by the DeviceKit stack. Please update xfce4-power-manager to remove its dependency on HAL.
Comment 1 Ali Abdallah editbugs 2010-01-06 12:00:08 CET
Devkit power branch is ready since more than three months, but just waiting to see what the devkit guys are going to do, i'm affraid about the stupid re-naming of devkit-power and devkit-disks to upower and udisks.
Comment 2 Ali Abdallah editbugs 2010-02-02 11:16:45 CET
First HAL free release is out today, 0.9.90, please have a look into it, i think i should be able to release the stable 1.0.0 in a month.

Please note that HAL is optionally used for brightness handling fallback in case xrandr failed to manage the backlight panel (if and only if xfpm is compiled with and HAL is running) you can disable that by adding --disable-hal.
Comment 3 Martin Pitt 2010-10-20 10:23:06 CEST
In a customer project of ours we don't want to install hal (deprecated, slow boot, etc.), but the X.org graphics driver for the ARM dove framebuffer isn't capable of proper XRandR brightness setting. gnome-power-manager solved this by adding a small "gpm-backlight-helper" program which runs as root (through pkexec) and offers PolicyKit controlled brightness changing. The helper pokes the brightness values into /sys, like hal used to do. Would you accept a patch for this?

With that, the only remaining HAL bits in x-p-m are the hal button bits. I haven't looked into those, but the only true way to handle those are to listen for these button events on the evdev input devices. This already does work in current XFCE (perhaps xfce4-session is handling those?), so it doesn't seem to be that important.
Comment 4 Martin Pitt 2010-10-20 15:59:10 CEST
Created attachment 3151 
Drop HAL brightness backend, add polkit sysfs backend

This patch throws out the HAL brightness backend and adds a xfpm-power-backlight-helper and uses that if XRandR isn't available. Since it uses polkit, it needs to be conditionalized on ENABLE_POLKIT.

I tested this successfully on my laptop in those combinations:

 * --disable-hal, --enable-polkit:
   * with using XRandR backend (which my chip/driver supports)
   * without XRandR (by returning FALSE in xfpm_brightness_setup_xrandr()); then it uses the sysfs helper, which works fine

 * --disable-hal, --disable-polkit:
   * with using XRandR (still working fine)
   * without XRandR (now it shows that brightness control is not available).

The helper is 95% identical with the one in gnome-power-manager (I just removed the unnecessary i18n and the g_type_init()), and has been out in the field with GNOME 2.32 and some distros, and has proven to work.

Please let me know if you have further questions about this. The patch looks a bit messy, due to diff trying to interleave the replaced hal functions with the "helper" ones, sorry.

BTW, using --disable-polkit is currently broken, I'll send another (simple) patch to fix it.
Comment 5 Martin Pitt 2010-10-20 15:59:48 CEST
Created attachment 3152 
fix building with --disable-polkit

In order to test the new backend with --disable-polkit, I needed to fix that option. Simple patch attached, and tested in both cases.
Comment 6 Martin Pitt 2010-10-20 16:02:08 CEST
> With that, the only remaining HAL bits in x-p-m are the hal button bits.
> I haven't looked into those, but the only true way to handle those are
> to listen for these button events on the evdev input devices.

... and in fact that's precisely what src/xfpm-button.c already does, and that works perfectly. I built with --disable-hal, and brightness keys just work:

TRACE[xfpm-button.c:122] xfpm_button_filter_x_events(): Key press: ((XfpmButtonKey) BUTTON_MON_BRIGHTNESS_DOWN)

So perhaps it's time to purge the remainders of HAL from the source? Please let me know if you want me to write a patch.
Comment 7 Ali Abdallah editbugs 2011-01-04 12:52:35 CET
(In reply to comment #6)
> > With that, the only remaining HAL bits in x-p-m are the hal button bits.
> > I haven't looked into those, but the only true way to handle those are
> > to listen for these button events on the evdev input devices.
> 
> ... and in fact that's precisely what src/xfpm-button.c already does, and that
> works perfectly. I built with --disable-hal, and brightness keys just work:
> 
> TRACE[xfpm-button.c:122] xfpm_button_filter_x_events(): Key press:
> ((XfpmButtonKey) BUTTON_MON_BRIGHTNESS_DOWN)
> 
> So perhaps it's time to purge the remainders of HAL from the source? Please let
> me know if you want me to write a patch.

Thanks very much for this patch, applied, i'll remove the HAL code completely and then do a release later on today.

Thanks again and sorry for the late reply, i was very busy.
Comment 8 Martin Pitt 2011-01-04 13:08:46 CET
No problem at all, thanks for applying it!

Bug #6116

Reported by:
Cody A.W. Somerville
Reported on: 2010-01-05
Last modified on: 2011-02-14

People

Assignee:
Ali Abdallah
CC List:
1 user

Version

Version:
Unspecified

Attachments

Additional information