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