DeviceKit-power and backlight brightness

Richard Hughes hughsient at gmail.com
Fri Jul 3 08:08:35 PDT 2009


2009/7/3 David Zeuthen <david at fubar.dk>:
> So you really need to revert that patch and stop trying to pretend to
> solve the worlds problems by violating the layering the rest of us are
> actually trying to make work. If you want to fix backlight, go hack on X
> or Wayland. Don't invent your own public interfaces just because you
> want some cheap wins.

I'm not going to revert the patch, but instead require people that use
the code to define I_KNOW_DKP_BACKLIGHT_IS_TEMPORARY, and add comments
to that effect to the DBus introspection file. I've added to my TODO
list to start working on XBACKLIGHT, but I'm simply not happy removing
backlight functionality for the majority of users for the sake of a
layering model, important tho it is. I'm the one supporting this
stuff, I'm the one processing bugzillas everyday, and I'm the one
where the buck stops. If I break brightness support for jrb again
(third time in three years) then I'm going to know about it.

At some point you have to compromise between breaking stuff that
already works and designing the perfect APIs.

If ajax ripped support out for non all X drivers that didn't support
KMS (even though we all know KMS is the future) then the people with
no display output would get rightly pissed off.

Until the drivers have caught up, we do need a temporary fallback. Now
in the case of HAL, the fallback was poking values to
/proc/acpi/ibm/backlight/brightness but trying to use sysfs first.
That was wrong, but we did it so things kept working until drivers
standardised on the backlight framework, and all the acpi drivers
converted to it. The mistake we did with hal (in this specific
instance) was not removing the fallbacks quickly enough.

Richard.


More information about the devkit-devel mailing list