Holger Macht wrote: > On Tue 15. Nov - 04:38:57, Michael Biebl wrote: >> 21.) [0.9.25/0.10.19] function keyword in init script is a bashism. Do >> you really need bash specific features? Otherwise it would be good to >> use #!/bin/sh in script header and check the scripts with >> "checkbashisms". That way you can replace the default shell with >> something lighter like dash. > > This would IMO be also good. But I'm not sure how much work this will > cause. Stefan, can you estimate if there are many bash specific features > in our scripts?
the init script can probably easily be cleared of bashisms, the helper scripts probably not. I think we should have a "generic" init-script which will run on any distribution (but probably not be as nice as the native scripts) and a collection of distribution specific scripts that fit nicely in the respective environment. The generic script should contain no bashisms, the distro-specific scripts can contain whatever the maintainer of the respective distro wants :-) >> 24.) [0.10.19] --enable-hal disables hal support ;-) >> Obviously not what you'd expect if you have a --disable-hal switch. > > Ups ;-) That's the "discover experienced users" switch :-) >> 25.) [0.9.25/0.10.19] Dependency on apmd: The powersaved script >> complains and exits if apmd is running. Is it safe to enforce the >> removal of the apmd if powersaved gets installed or are there >> applications that need apmd and its tools? I intended to add "Conflicts: >> apmd" to the powersaved package so that apmd gets deinstalled if you >> want to install powersaved. Is that the Right Way(TM) in your opinion? > > IMHO yes. On SUSE there are no tools that need apmd, or at least no tools > installed by default that need it. I never used it, so maybe Stefan can > tell us his opinion ;-) Yes. There is not much sense in having both installed. Some people might be accustomed to the "apm" command, but you can get similar information from powersave. >> 28.) Restore console resolution/state with vbetool. Don't know if it is >> safe to enable this but I find it quite annoying to switch to X and back >> to the console to restore the correct resolution of the console. 0.10.19 >> seems to have a script in contrib. > >>From what I know, vbetool can be dangerous sometimes. Seife? our X gurus strongly objected to have it readily available, so i did not integrate it but put it into contrib/ (that is the "use at your own risk" section :-) But hey, if he gets a patch from "upstream", what can a poor SUSE package maintainer do against that? I'll take a look how to integrate it best. The bad thing with this is that there are so many possibilities what you can do with vbetool, so we might end with --- VBETOOL_SUSPEND="vbetool vbestate save > /root/vbetool/vbestate" VBETOOL_RESUME="vbetool post; vbetool vbestate restore < /root/vbetool/vbestate" --- and then calling $VBETOOL_SUSPEND and $VBETOOL_RESUME at apropriate places. Ugly, i know. Any better ideas appreciated... >> 29.) Provide emulation for apmd. See point 25 for that. Would it be >> feasible to provide wrapper scripts like "apm" which provide the same >> interface as the original apm tools and call the corresponding powersave >> methods? > > I first have to check how much work this would be. If you like to do it, > go ahead ;-) if it is only simulating the output of "apm" this should be relatively easy (IIRC, this is mostly a "cat /proc/apm" and we should be able to simulate that). Invoking stuff (apm -S etc) should IMO point to powersave: # apm -S suspend actions not supported, please use "powersave -S|-s|-m". I mean - we want to get rid of legacy stuff, don't we? ;-) >> 30.) DB for working combinations of hardware (laptop), used >> framebuffer(vesa,vga16,..), possible suspend states, needed boot parameters. >> It would be great if we would start to collect data of known working >> settings. For my case (HP nx7000) I had to disable radeonfb and use >> vesafb and set the boot parameter acpi_sleep=s3_bios,s3_mode in order to >> get suspend_to_ram working. We could use this data during postinst to >> preset the values in @sysconfdir@/powersave. >> Maybe we could set up a web form where user can enter there working >> setup. What would be needed then: >> - hardware >> - kernel revision >> - used framebuffer >> - boot flags >> - suspend2disk working >> - suspend2ram working >> Anything else? >> >> That would mean a great benefit imo for users if they don't have to >> experiment with different bootflags etc. and just get a working setup. > > There is a list for suspend to ram in the linux kernel documentation in > Documentation/power/video.txt and something similar at > http://www.opensuse.org/HCL/Laptops. But you are right that there should > be an easy way to get users to integrate their own experiences. Have to > think about it a little more... > > Thomas is already working on some kind of post install script to adapt > some configurations. Maybe these things can be integrated... The problem is, that this will change with every BIOS version, every kernel version etc.pp. As much as i'd like to have such a DB, i fear that we won't see it soon. What we could provide is some infrastructure where a vendor can drop a "SUSPEND.INF" file which contains all the needed stuff and some config script then pokes the information from this file into the system. In an ideal world, the notebook vendor could then supply those "suspend driver files for kernel 2.6.42" on his download page (I'd bet that they will call them "drivers"). We'd need to discuss this and get to some conclusion which should then be implemented into as much distributions as possible. Well, a dream. >> I know the list got quite long and I've surely missed some points I >> wanted to address. Nevertheless I hope you all read till the end and >> give me some feedback on this points. I really appreciate your effort and am looking forward to implement most of this stuff. Patches are certainly always welcome :-) > Yes, thank you again for your feedback. One of our problems is that we do > not get in touch with other distributions that often, so there might be > some SUSE-specific things which we did not notice at all. So feedback from > other distribution users/maintainers is one important sources we have to > extend the package. And to express this again (i already talked to Holger about that: we are really willing to get rid of the SUSE-specific things (or maintain the distro-specific hacks either out of tree or maybe include a directory in CVS where those are kept) and make powersave an even better solutions for all linux users. It is just that we know SUSE best and this sometimes leads to solutions that are sub-optimal on other distributions :-) But we will work hard to fix that. >> Last but not least kudos to you all! I think (k)powersave is great >> software, let's try to make it better ;-) Thanks for the flowers :-) Have a nice weekend Stefan -- Stefan Seyfried \ "I didn't want to write for pay. I QA / R&D Team Mobile Devices \ wanted to be paid for what I write." SUSE LINUX Products GmbH, Nürnberg \ -- Leonard Cohen _______________________________________________ powersave-devel mailing list [email protected] http://forge.novell.com/mailman/listinfo/powersave-devel
