Bug 487044

I'd question whether this sort of package is even needed in Fedora.

The killswitches can be handled through HAL and an interface to it, brightness should be handled through either HAL, or X11, and the rest of the configuration should probably have nice defaults, instead of requiring users to toggle the "smart fan control".

(In reply to comment #1)
> I'd question whether this sort of package is even needed in Fedora.
> 
> The killswitches can be handled through HAL and an interface to it,

They don't work currently and yes, I know, I should submit a bug report. I will when I have some time to sit on it. In the meantime, I've found this little tool which works (at least partially), so I packaged it for myself and decided to share with the rest of Fedora.

> brightness should be handled through either HAL, or X11,

Setting brightness works already and this tool doesn't even touch it.

> and the rest of the configuration
> should probably have nice defaults, instead of requiring users to toggle the
> "smart fan control".

Maybe, but there's also a setting that overclocks the CPU to 1.8GHz (1.6GHz is normal). Do we have something like that in Fedora? And besides, with all that Windows-mimicking going on lately, why oppose the inclusion of a tool that Eee users have present in their Windows XP installations? ;)

(In reply to comment #2)
> (In reply to comment #1)
> > I'd question whether this sort of package is even needed in Fedora.
> > 
> > The killswitches can be handled through HAL and an interface to it,
> 
> They don't work currently and yes, I know, I should submit a bug report.
> I will when I have some time to sit on it.

Scratch that, it seems to be working, but it only works as a bi-state switch and doesn't work for the built-in bluetooth at all.

Windows mimicking? Anyway, that's besides the point. There are standard interfaces for killswitches, hotkey setup, and brightness control[1]. So this shouldn't be on the tracker for netbook bugs. Fixing whatever needs fixing to use the standard interfaces should be.

[1]: You say it doesn't touch brightness, but http://greg.geekmind.org/eee-control/#features lists "Extended LCD brightness (brighter and darker than the default range, not supported on all models)"

Probably off-topic wrt. reviewing, but I am wondering, ...

* most netbooks are very similar, so why is this tool restricted/limited to eee's (rsp. to a subset of them, as some remarks above seem to indicate).
* How do netbook focused distros handle this kind of problems? One package per hw-manufacturer/per model?

I'm a novice with bugzilla but here are my two cents:
* the super performance setting overclocks the fsb, so if you also have cpufreq-applet in the tray, it looks inconsistent (it continues to report the max available scaling freq)
* overclocking my 900 model while running a yum transaction crashes my system at 85°C core temp
* the graphics used as tray-icon is possibly a reg. trademark

I was interested in this package initially, but maybe could be left to some 3rd party repo

(In reply to comment #4)
> Fixing whatever needs fixing to use the standard interfaces should be.

Totally agree. Then stuff "just works" with no random binaries being present.

Just chiming in.  I don't have much use for overlapping features of this as well but there are a few items that are not overlapping that I'd like to use.

- FSB overclocking.  If you have a 900 with infamously slow 16G SSD then this makes a noticeable difference in usability (under Windows XP anyways).

- Automatic FSB overclocking.  By that I mean something that monitors when your on battery power and disables overclocking and also notifiws you.  Not sure I wish to use this feature unless the daemon is also actively monitoring CPU temp. and also disabling.  Going purely from Comment #6 it might not be... but then whats the related "smart fan control" about?

- Tray menu to disable Webcam and Card Reader.  Looking around /sys/bus, it looks like the onboard card reader does not support auto suspending.  It would be nice to disable that device when on battery for extended periods.  Disabling Wifi and Bluetooth overlaps with keyboard toggles but a common menu for all devives would be nice.

Overclocking is a questionable reason to package this since harm could occur to hardware... but the power savings feature of disabling hardware is more interesting.

Current rawhide is looking very good, power wise, and I have no numbers to back up disabling card reader or webcam results in noticeable savings.

Created attachment 349189 [details]
Updated spec to 0.9.3 release

My eee pc was feeling sluggish so I went ahead and updated spec file to support latest release of eee-control.  This will install a /etc/eee-control.conf that enables all features; even without custom kernel module.

Created attachment 349190 [details]
Spec File for 0.9.3 release

Previous attachement was SRPM containing needed additional source files... Here is spec alone for review.

Regarding the latest build, it builds and installs correctly for me (f11 on an 1000he).  Starting the service does:

http://fpaste.org/MnH2/

More generally, is there something exposed to set the FSB speed in Fedora already?

Just noticed a parallel effort at: http://fedora-eee.com/ 

I sent the packager there a mail, hoping to combine efforts/knowledge here.

I've lost access to my eee-pc so I can't help debug things now.  From ouptut in #11 it looks like perhaps you've misconfigured your /etc/eee-control.conf.  Since upgrading/installing RPM won't overwrite an old copy, you may want to delete it before installing RPM.

Is modification of the conf file required?  I just left it as defaults - the README doesn't really say.

I doubt we are allowed to ship eee-icon.png. I also want to remind you of
https://fedoraproject.org/wiki/Packaging:Guidelines#Trademarks_in_Summary_or_Description

Any updates? When will this package be available for testing in Fedora repos?

Why don't you get involved? Submit a package, become a packager and review this package.

(In reply to comment #17)
> Why don't you get involved? Submit a package, become a packager and review this package.    

I think we can do better than "why don't you become a computer programmer if you want this to proceed?".

At a minimum we need a new icon and that hasn't been changed yet.  That would be a contribution most users could achieve.

FWIW, I still use this because my eee randomly shuts off bits of hardware at the BIOS level and eee-control can turn them back on.  It also keep the fan a bit more relaxed.

(In reply to comment #18)

> I think we can do better than "why don't you become a computer programmer if
> you want this to proceed?".

Nobody expects somebody to become a programmer, we are talking about packaging and reviewing here. In case you didn't konw, Valent already is a Fedora ambassador for years now and as such it should be possible for him to read the packaging and the review guidelines in order to get involved instead of just nagging other people for ages.

@Chistopher I have other priorities, and I'm just asking politely not nagging. If you feel nagged please feel free to ignore me.

I'm working on other project to make Fedora better and making a custom Fedora remix, taking over management of Fedora Geo spin and lots of other things... and asking politely for a update on progress of this package.

Oh, and a patch is needed for more recent ASUS BIOS'es due to some device renaming for AHCI.  Should we assume current BIOS'es here and patch or somehow try to keep a map of old BIOS's (ick).

It doesn't appear that there's been any comment from the submitter since March of 2009.  Can we just close this now?

A newer eee-control was released by author in May so at least it can be made to work with latest UPower DBUS events.

But I see less and less need for it.  Here is run down of its features (this is latest status from my comment #8):

* All hotkeys are sent as standard /dev/input/event* and can be mapped using apps such as Gnome Shortcuts.
* Wireless is hooked up to standard rfkill kernel interface and disabling wifi/bluetooth works standard ways.
* Sensor status is using standard interfaces and so can use most any gnome applet to monitor.
* With latest kernel power savings work (say kernel 2.6.34 or newer) and more recent eee pc's (say anything above 9 inches) I see no power savings via powertop for disabling camera or card reader.  eeepc-wmi driver (for Eee PC that ship with Windows 7) doesn't have an interface for these anyways.

That leaves useful features of:

* Disabling touchpad when plugging in a mouse.  Well, it doesn't do this automatically.  Its just a toggle which can be mapped to hotkey anyways using Gnome shortcuts (I think all Eee PC's have a Fn-* hotkey for disabling touchpad).
* Automatically adjusting Super-Hybrid-Engine for power savings.

The last one is extremely useful part of this application.  

I've personally written some small scripts to perform this last item in around 30 lines of code.  So I personally will not be pursuing eee-control anymore (or updating its spec file although I'm not original submitter).

Thanks Chris.

Dominik, in light of Chris' statements in comment #24, are you still interested in packaging eee-control for Fedora? Or should this request now be closed?

I asked him on IRC and he indicated that he would soon submit an updated package:

[Friday 05 November 2010] [09:04:06] <tibbs>    Rathann|work: Is there anything specific you'd like to do with your really old review tickets?
[Friday 05 November 2010] [09:04:26] <Rathann|work>     tibbs: which one?
[Friday 05 November 2010] [09:04:46] <tibbs>    .bug 487044
[Friday 05 November 2010] [09:04:49] <tibbs>    For one.
[Friday 05 November 2010] [09:04:49] <zodbot>   tibbs: Bug 487044 Review Request: eee-control - Asus Eee PC hardware control and configuration tool - https://bugz
illa.redhat.com/show_bug.cgi?id=487044
[Friday 05 November 2010] [09:04:52] <Rathann|work>     ah
[Friday 05 November 2010] [09:05:10] <tibbs>    I'm just trying to clean up the ancient ones.
[Friday 05 November 2010] [09:05:18] <Rathann|work>     yeah, I have an updated package to submit
[Friday 05 November 2010] [09:05:48] <tibbs>    OK, just making sure.  Otherwise I'd close it early next week.
[Friday 05 November 2010] [09:06:05] <Rathann|work>     I've been pretty much out of time for the last months, but I should have much more free time from now on
[Friday 05 November 2010] [09:06:20] <tibbs>    Oh, no problem.  That's the same situation I've been in.
[Friday 05 November 2010] [09:06:24] <Rathann|work>     so I'll get back to all my neglected stuff :)

Updated:

Spec URL: http://rathann.fedorapeople.org/review/eee-control.spec
SRPM URL: http://rathann.fedorapeople.org/review/eee-control-0.9.6-1.fc12.src.rpm

And for the record:
(In reply to comment #24)
> * Wireless is hooked up to standard rfkill kernel interface and disabling
> wifi/bluetooth works standard ways.

rfkill doesn't work for my bluetooth, eee-control does.

> * With latest kernel power savings work (say kernel 2.6.34 or newer) and more
> recent eee pc's (say anything above 9 inches) I see no power savings via
> powertop for disabling camera or card reader.

Well, I have one of the 9in eees and I see savings in powertop (on F-13).

(In reply to comment #27)
> Updated:
> 
> Spec URL: http://rathann.fedorapeople.org/review/eee-control.spec
> SRPM URL:
> http://rathann.fedorapeople.org/review/eee-control-0.9.6-1.fc12.src.rpm
> 
> And for the record:
> (In reply to comment #24)
> > * Wireless is hooked up to standard rfkill kernel interface and disabling
> > wifi/bluetooth works standard ways.
> 
> rfkill doesn't work for my bluetooth, eee-control does.

I peeked into eee-control-daemon script and it looks like its using rfkill to turn off bluetooth.  Can you expand on what you mean?

Does your Fn-F2 key turn off wlan but not bluetooth?  Or are you just saying you want a control that turns off bluetooth but not wlan (eee-control gives a GUI to toggle just one using rfkill).

> 
> > * With latest kernel power savings work (say kernel 2.6.34 or newer) and more
> > recent eee pc's (say anything above 9 inches) I see no power savings via
> > powertop for disabling camera or card reader.
> 
> Well, I have one of the 9in eees and I see savings in powertop (on F-13).

Thats a fair statement and why I threw in "above 9 inches" part.  So probably these 9 and 7 inch models need the disable HW features and Super Hybrid Engine parts where as above 9 inches need only SHE part.

BTW: Since I last last wrote, I found out we can get touchpad toggle working out of the box.  We just need to change eeepc-laptop/wmi to send F22 instead of F13.  I'm working with upstream (kernel and udev) to get this working.

(In reply to comment #28)
> > rfkill doesn't work for my bluetooth, eee-control does.
> 
> I peeked into eee-control-daemon script and it looks like its using rfkill to
> turn off bluetooth.  Can you expand on what you mean?

Actually, it seems that my bluetooth device got into some strange state and I kept getting usb errors in dmesg. A hard reset (poweroff and take out the battery) seems to have helped. Now both eee-control and rfkill work fine.

> Does your Fn-F2 key turn off wlan but not bluetooth?  Or are you just saying
> you want a control that turns off bluetooth but not wlan (eee-control gives a
> GUI to toggle just one using rfkill).

Is there another gui? It seems a bit stupid to have to use root priviledges just to turn bluetooth on/off.

> Thats a fair statement and why I threw in "above 9 inches" part.  So probably
> these 9 and 7 inch models need the disable HW features and Super Hybrid Engine
> parts where as above 9 inches need only SHE part.

Maybe that could be made part of the acpi-cpufreq or thereabouts?

> BTW: Since I last last wrote, I found out we can get touchpad toggle working
> out of the box.  We just need to change eeepc-laptop/wmi to send F22 instead of
> F13.  I'm working with upstream (kernel and udev) to get this working.

Cool!

(In reply to comment #29)
> (In reply to comment #28)
> 
> > Does your Fn-F2 key turn off wlan but not bluetooth?  Or are you just saying
> > you want a control that turns off bluetooth but not wlan (eee-control gives a
> > GUI to toggle just one using rfkill).
> 
> Is there another gui? It seems a bit stupid to have to use root priviledges
> just to turn bluetooth on/off.

I don't have bluetooth but google says something about installing gnome-bluetooth and it installs a udev rule to enable user permission for rfkill.  There is also supposed to be an applet with it to enable/disable using rfkill.

> 
> > Thats a fair statement and why I threw in "above 9 inches" part.  So probably
> > these 9 and 7 inch models need the disable HW features and Super Hybrid Engine
> > parts where as above 9 inches need only SHE part.
> 
> Maybe that could be made part of the acpi-cpufreq or thereabouts?

You mean the SHE part? Since people prefer for this to change based on AC/Battery, its more a user land thing.

So eee-control or similar is definitely the right direction for controlling the SHE part and the camera+card reader disable part since that has no overlap with standard laptop features.  I would personally prefer if we could remove the overlapping features from eee-control as not to confuse end users... but thats just an opinion.

Thanks Dominik!

Just a few things here that need attention. 

Also note that unless you plan to package this for EPEL, you don't need:
  * the BuildRoot:
  * rm -rf %{buildroot} under %install
  * the %clean section.

Please rebuild to fix the issues below:

 - = N/A
 / = Check
 ! = Problem
 ? = Not evaluated

=== REQUIRED ITEMS ===
 [!] Rpmlint output is clean:
      $ rpmlint SPECS/eee-control.spec 
      SPECS/eee-control.spec:10: W: macro-in-comment %{name}
      SPECS/eee-control.spec:10: W: macro-in-comment %{version}
      SPECS/eee-control.spec: W: invalid-url Source0: eee-control-0.9.6.tar.gz
      0 packages and 1 specfiles checked; 0 errors, 3 warnings.

      $ rpmlint SRPMS/eee-control-0.9.6-1.fc14.src.rpm 
      eee-control.src: W: spelling-error Summary(en_US) Asus -> Aus, Asur, Apus
      eee-control.src: W: spelling-error %description -l en_US hotkeys -> hot keys, hot-keys, hotcakes
      eee-control.src:10: W: macro-in-comment %{name}
      eee-control.src:10: W: macro-in-comment %{version}
      eee-control.src: W: invalid-url Source0: eee-control-0.9.6.tar.gz
      1 packages and 0 specfiles checked; 0 errors, 5 warnings.
 
      $ rpmlint RPMS/i686/eee-control-0.9.6-1.fc14.i686.rpm 
      eee-control.i686: W: spelling-error Summary(en_US) Asus -> Aus, Asur, Apus
      eee-control.i686: W: spelling-error %description -l en_US hotkeys -> hot keys, hot-keys, hotcakes
      eee-control.i686: W: non-conffile-in-etc /etc/xdg/autostart/eee-control-tray.desktop
      eee-control.i686: W: spurious-executable-perm /usr/share/doc/eee-control-0.9.6/eee-dispswitch.sh
      eee-control.i686: W: spurious-executable-perm /usr/share/doc/eee-control-0.9.6/eee-control-query
      eee-control.i686: W: no-manual-page-for-binary eee-control-daemon
      eee-control.i686: W: no-manual-page-for-binary eee-control-tray
      eee-control.i686: W: service-default-enabled /etc/rc.d/init.d/eee-control-daemon
      eee-control.i686: W: incoherent-subsys /etc/rc.d/init.d/eee-control-daemon $prog
      eee-control.i686: W: incoherent-init-script-name eee-control-daemon ('eee-control', 'eee-controld')
      1 packages and 0 specfiles checked; 0 errors, 10 warnings.

      $ rpmlint RPMS/i686/eee-control-debuginfo-0.9.6-1.fc14.i686.rpm 
      1 packages and 0 specfiles checked; 0 errors, 0 warnings.

      eee-control.spec: W: invalid-url Source0: eee-control-0.9.6.tar.gz
      See notes below on tarball

      eee-control.i686: W: non-conffile-in-etc /etc/xdg/autostart/eee-control-tray.desktop
      This is as expected, no problem

      eee-control.i686: W: spurious-executable-perm /usr/share/doc/eee-control-0.9.6/eee-dispswitch.sh
      eee-control.i686: W: spurious-executable-perm /usr/share/doc/eee-control-0.9.6/eee-control-query
      These (and eee-control-setup.sh) shouldn't be in doc, should they?

      eee-control.i686: W: service-default-enabled /etc/rc.d/init.d/eee-control-daemon
      This is intentional and necessary, right?

      eee-control.i686: W: incoherent-subsys /etc/rc.d/init.d/eee-control-daemon $prog
      eee-control.i686: W: incoherent-init-script-name eee-control-daemon ('eee-control', 'eee-controld')
      The init script name should be the same as the package name in lower case. 


 [/] Package is named according to the Package Naming Guidelines.
 [/] Spec file name must match the base package %{name}, in the format
%{name}.spec.
 [/] Package meets the Packaging Guidelines including the Language specific
items
 [!] Package is licensed with an open-source compatible license and meets other
legal requirements as defined in the legal section of Packaging Guidelines.
      As Christoph Wickert points out in Comment #15, the package contains Asus' Eee logo, in eee-icon.png and eee-icon-small.png. Where do the other icons in the same directory come from?



 [!] License field in the package spec file matches the actual license.
      ISC license properly identified for the main file, but some icons in /usr/share/eee-control are from the GNOME icon set, which is GPL
      (see icons here: http://people.freedesktop.org/~jimmac/icons/#git and license here: http://art.gnome.org/ )



 [-] If (and only if) the source package includes the text of the license(s) in
its own file, then that file, containing the text of the license(s) for the
package is included in %doc.
 [-] Spec file is legible and written in American English.
 [!] Sources used to build the package matches the upstream source, as provided
in the spec URL.
      The git operations you documented got me the source, but I couldn't generate a tarball with the same md5sum. Please note the steps you used to generate the tarball; this will have to include removing the Eee logos noted above, since if we can't ship these in the binary, we can't ship them in source either.



 [/] Package successfully compiles and builds into binary rpms on at least one
supported architecture.
     Builds for i686: http://koji.fedoraproject.org/koji/taskinfo?taskID=2599687
 [/] Package is not known to require ExcludeArch
      Package uses ExclusiveArch as it is specific to 32-bit x86 machines
 [/] All build dependencies are listed in BuildRequires, except for any that
are listed in the exceptions section of Packaging Guidelines.
 [/] The spec file handles locales properly (with the %find_lang macro)
 [-] ldconfig called in %post and %postun if required.
 [/] Package does not bundle copies of system libraries
 [/] Package is not relocatable.
 [/] Package must own all directories that it creates.
 [/] Package does not contain duplicates in %files.
 [!] Permissions on files are set properly
      Check the various scripts currently in /usr/share/doc/eee-control-0.9.6/



 [/] %files section includes a %defattr(...) line
 [/] Package consistently uses macros.
 [-] Large documentation files are in a -doc subpackage, if required.
 [!] Package uses nothing in %doc for runtime.
      Check the various scripts currently in /usr/share/doc/eee-control-0.9.6/



 [-] Header files in -devel subpackage, if present.
 [-] Static libraries in -static subpackage, if present.
 [-] Development .so files in -devel subpackage, if present.
 [-] -devel packages require base package with full versioning.
 [/] Package does not contain any libtool archives (.la).
 [/] Package contains a properly installed %{name}.desktop file if it is a GUI
application.
 [/] Package does not own files or directories owned by other packages.
 [/] Filenames are valid UTF-8

=== SUGGESTED ITEMS ===

 [/] Package does not include license text files separate from upstream.
 [-] Description and summary sections in the package spec file contains
translations for supported Non-English languages, if available.
 [/] Reviewer should test that the package builds in mock.
     Tested through koji: http://koji.fedoraproject.org/koji/taskinfo?taskID=2599687
 [/] Package should compile and build into binary rpms on all supported
architectures.
 [?] Package functions as described.
 [/] Scriptlets must be sane, if used.
 [-] Subpackages other than -devel require the base package as a fully versioned
dependency
 [-] The placement of pkgconfig(.pc) files is correct (normally in -devel)
 [-] File based requires are sane.
 [!] Package contains man pages for binaries and scripts.
      Unfortunately, package contains no man pages, but this is not a blocker.

Is My EEE PC 1215N not supported by eee-cintrol? ):

The latest version of this package I can find is eee-control-0.9.6-1.fc13.i686
It doesn't run out of the box on F14+, because of some minor issues with python version and ioport. I've made it work on my machine, but I haven't packaged it (I'm not very proficient in making rpms). I don't have the spec/src.rpm package for that release but there is a mandriva srpm here: http://rpm.pbone.net/index.php3/stat/4/idpl/16622114/dir/mandrake_other/com/eee-control-0.9.6-4-mdv2011.0.i586.rpm.html

The two features of the package that are not provided by anything else are (IMO):
- CPU fsb options (performance, normal, powersave). This is using /sys/devices/platform/eeepc/cpufv for this, which comes from eeepc-laptop kernel module
- fan control / information. This is using some ioports hardcoded in the app.

If you know any of these two being provided by something else, or at least for a different laptop model, so the packages can be merged.

This is an FYI to those following this report.

I have recently learned that the "cpufv" part is being controlled by the "tuned" package available in Fedora if you have an Atom based Eee PC.  I keep meaning to submit patches so it works with older Eee PC's as well... but I haven't so far.

It also does a bunch of other tweaks to save power so you may want to consider installing it.  Lots of good info on how to use it here:

http://docs.fedoraproject.org/en-US/Fedora/15/html/Power_Management_Guide/index.html

It has one config option were it will change cpufv based on CPU load... Not so much on AC/Battery... but its close enough for me.  I hope to help improve it over time.

I guess that leaves the fan control / info not provided by another package but I've never used that part so do not know enough to look at what options are available.

(In reply to comment #34)
> I guess that leaves the fan control / info not provided by another package but
> I've never used that part so do not know enough to look at what options are
> available.

The lm_sensors package gives fan speed and CPU temperature, and the fancontrol program (from the package) can be used to set the speed of the fan according to the CPU temp.

This fancontrol program is not packaged like a daemon, but this shouldn't be hard to do.

I've lost interest in packaging this. If anyone would like to take over, feel free to reopen or submit a new review request using my package.