On Tue, Dec 12, 2006 at 01:40:18AM +0100, Pavel Machek wrote:
> > Yes. Only that it is a bit annoying that you need hal for something as
> > lowlevel as
> > putting your machine to sleep.
But you need somehting running as root anyway to run pm-suspend (or some
similar script). The normal user does not want to become root, stop services
and then run "s2ram". She wants to close the lid or click on some applet
and have the machine sleep. Nowadays it looks like HAL and pm-utils are
the way to achieve that goal.
I fought against this solution for quite some time, but today i realize
that this probably only will turn out usefull if it will be one common
solution among all the major distributions and if it will work the same
on all of them.
> Well.. perhaps patch for PCIids based whitelist would be acceptable,
> too. I do not like HAL, either, but we are afraid that for desktop
> machines, rules are going to be complex...
Or just switch completely from DMI based to PCI-ID based list.
Once we have the exact vendor and subvendor of the graphics card and the
host bridge, we are basically down to a machine identification anyway.
Maybe even closer than with our DMI table, if we look at the hp nx7400
identification problems that we have recently...
IIRC Matthew Garrett posted something about using PCI-ids to identify the
machines some time back on the HAL list. Matthew, can you give a hint
which IDs would be best to achieve our goal of safely identifying the
machine and the graphics card?
One problem is, how we can transition from using the "old" DMI list to the
"new" PCI list, but maybe just having them both, first matching against
the PCI list, then, if nothing is found, matching against the DMI list
(and maybe, in "s2ram -n" mode, also tell the user "PCI identification is
foo, the machine is only in DMI list, please mail this info to suspend-devel"
would help to speed up the transition).
> ...but OTOH maybe we can just write the rules in C? Coming up with
> good rules is going to be hard (and highly qualified task), anyway, so
> maybe C does not add that much effort?
It makes it relatively hard to take a whitelist.c from a newer version
and put it into an older revision. And i think quite some distributions
would like to be able to do that (i certainly would like to).
It also makes it probably harder to convert to/from the HAL .fdi files
automatically. And most people will be using HAL anyway, so you will
need to import the data the HAL guys will get through nice point-and-click
frontends from their users into the suspend whitelist.
I have no strong feelings (anymore :-) about this, since i think the way
to go is to implement the whitelist in HAL, so in a relatively short time
nobody will care about the whitelist in s2ram anymore.
Best regards,
Stefan
--
Stefan Seyfried
QA / R&D Team Mobile Devices | "Any ideas, John?"
SUSE LINUX Products GmbH, Nürnberg | "Well, surrounding them's out."
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Suspend-devel mailing list
Suspend-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/suspend-devel
