Raphael Hertzog wrote:
On Mon, 18 Jun 2007, Bart Samwel wrote:
Well, it would allow me to use acpi-support and actually make sense
of /etc/acpid/* by removing all the stuff that I will never need.
This is Debian, after all...
I'd rather improve the organization of the package (which it definitely
needs) than splitting it up. You see, it's not a large package, it's
just a bit disorganized. And that's the fault of upstream (which is
Ubuntu).
You must keep in mind that acpi-support is something that's supposed to
not exist. It's only filling gaps so that it actually work with the
deficiencies of the drivers and the hardware.
Yeah, I do keep that in mind. So I want to keep the differences to
upstream small as well -- but I do want to fix the bugs that do appear.
OTOH, the situation basically means that architectural wishlist items
are unlikely to be solved, unless the upstream cooperates.
In the long term, the goal is to reduce the number of different cases and
certainly shrink the size of the package. Maybe move some functionalities
in other parts of the system (gnome-power-manager, acpid, etc).
Shrinking the package would be a good thing. I think there are some
potential problems with the target locations you mention as well:
- acpid is a very basic mechanism daemon. Many of this stuff doesn't
belong in the base ACPI mechanism either.
- gnome-power-manager is only fine if you're running gnome. OTOH
acpi-support works too if you're on a bare terminal. We already defer
some of our control to gnome-power-manager and its KDE twin when they're
running, but we can't assume they always are.
[rant] The first time I saw gnome-power-manager presented (I think it
was at FOSDEM 2006) I immediately had strong objections to the idea of a
gnome-specific power management daemon. IMHO there should be a
*system-wide* power management policy daemon, controlled by a
desktop-specific UI and a system-wide policy file. It's just crazy that
the only way to prevent users from shutting down/hibernating/putting to
sleep a system is by firewalling the dbus messages that are sent to the
hal daemon. And that the first user to log in gets to run the "master"
gnome-power-manager daemon under his own account. Perhaps this model is
fixed by now, but still, the basic design was so flawed and
single-user-Ubuntu-Gnome-focused it was basically unfixable. (I'm sorry
if any of the original authors are listening in, this was just my
initial impression of the whole thing.) [/rant]
Anyway, now that we're thinking about this already, for the phasing out
of acpi-support I would be thinking of steps such as:
1. Splitting off the sleep/hibernate *mechanism* (as opposed to the
policy) into one or several different packages. We could have a virtual
package "hibernation", provided by several implementation packages, such
as the "hibernate" package, or a split-off version of acpi-support's own
hibernation code. This would also give us a clean way to get rid of this
wishlist item:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=405563
2. Moving all of the special key conversion stuff into the kernel. These
should be generic keys, you shouldn't need to convert this stuff.
Actually, I saw some LKML activity recently that indicated that a
project to do this, and to make most laptop keyboards "just work" is
underway. The project is titled "Unf*ck my keyboard", see for instance
this message:
http://lkml.org/lkml/2007/5/31/137
3. Laptop-specific mechanisms for screen brightness should be included
in kernel drivers for /sys/class/backlight.
4. As a final nail in the coffin of acpi-support, the remaining policy
stuff should be moved into a desktop-agnostic "system event and power
policy daemon", which would basically be a split-off gnome-power-manager
back-end with a system-wide default policy configuration file. This
daemon would also have to control some additional policy regarding the
response to certain acpi events (such as special keys being pressed).
I guess that (2) and (3) are slowly being done already. No work is being
done towards something like (1) and (4). I'm actually considering doing
(4) myself. I've actually been considering this for quite some time
because the current situation with the various power-management policy
daemons and packages is irritating the hell out of me. :-)
So I think that reorganizing this package is mainly lost work unless you
manage to become upstream together with Ubuntu. Matthew Garrett is not
interested in that but you might want to ask Paul Sladen who made the 4 or
5 last Ubuntu uploads.
I will definitely ask him to consider this. With joint efforts we might
be able to reduce acpi-support a little sooner rather than later.
BTW, I know this has been a pretty long rant and that many of the things
I wrote here are probably not going to happen soon. I'm just trying to
figure out what future directions there might be, and what I could do to
make them happen, and to make acpi-support obsolete. :-)
Cheers,
Bart
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
