Eee Atom CPU control - testing
-
- Posts: 5464
- Joined: Fri 10 Jun 2005, 05:12
- Location: Australia
Better still, the CPU settings should be with radiobuttons.
But I don't know how to script the backend for this.
But I don't know how to script the backend for this.
- Attachments
-
- eee-atom-2.jpg
- (16.2 KiB) Downloaded 1063 times
Hi tempestuous
Nice gui. (ATM I am the only download and I did that before work around 5.30am this morning)
I'll take a look. 'zigbert' is my tutor so all should be how you want it to look.
Cheers
[Side note: I compiled the driver for the rtl8187se for k2.6.30.5 and posted (with appropriate warnings) in this ("Users (For the regulars)") forum. Just want to make sure it looks fine to you. For me, almost 24 hrs running on my 701sd and no dropouts.]
Nice gui. (ATM I am the only download and I did that before work around 5.30am this morning)
I'll take a look. 'zigbert' is my tutor so all should be how you want it to look.
Cheers
[Side note: I compiled the driver for the rtl8187se for k2.6.30.5 and posted (with appropriate warnings) in this ("Users (For the regulars)") forum. Just want to make sure it looks fine to you. For me, almost 24 hrs running on my 701sd and no dropouts.]
Puppy Linux Blog - contact me for access
Well I had a crack at an improved gui. It works.
I replaced the 3 scripts (calling the fsb changes) with a functions script ala zigbert and added a calling script. That is necessary (for me) to refresh the gui with the new status.
The fan scripts are included and the call to them is from the functions script too. There is a delay while the gui refreshes (caused by the system changes) so I added a splash screen informing the user.
The dotpet retains the original pinstall.sh script
Here it is...
NOTE: for testing.
Cheers
I replaced the 3 scripts (calling the fsb changes) with a functions script ala zigbert and added a calling script. That is necessary (for me) to refresh the gui with the new status.
The fan scripts are included and the call to them is from the functions script too. There is a delay while the gui refreshes (caused by the system changes) so I added a splash screen informing the user.
The dotpet retains the original pinstall.sh script
Here it is...
NOTE: for testing.
Cheers
- Attachments
-
- eee-gui.jpg
- (21.04 KiB) Downloaded 982 times
-
- eee-test-Atom-CPU.pet
- (11.62 KiB) Downloaded 421 times
Puppy Linux Blog - contact me for access
-
- Posts: 5464
- Joined: Fri 10 Jun 2005, 05:12
- Location: Australia
No problem. Will do it this evening. Only thing, when the gui is started the radio button at the top is checked by default, so when you start there is no indication of what mode you used last. Do you think there is a need for a "current mode" button?tempestuous wrote:Hey that's great that you made a gui. Before I intgrate it into the Eee hotkeys package, just a note -
with radiobuttons, the "Current Mode of Atom CPU: xxx" text becomes redundant, because the radiobuttons not only allow you to change mode, they're also an indicator of the current mode.
Cheers
Puppy Linux Blog - contact me for access
I made a new gui for the package that I downloaded. I made it before I checked in on this thread so it does not have radio buttons as tempestuous suggested. It is simply a variation on the one I made for pupeeecontrol.pet.
- Attachments
-
- eeecontrol.png
- (14.47 KiB) Downloaded 1055 times
-
- Posts: 5464
- Joined: Fri 10 Jun 2005, 05:12
- Location: Australia
That's my point; good scripting could avoid this.01micko wrote:when the gui is started the radio button at the top is checked by default
When the gui is launched, the right backend script should determine the CPU FSB state, and highlight the correct radiobutton.
Maybe we need the expertise of Dougal or Zigbert.
Similarly, when the user changes the CPU FSB state, the backend script should re-read the state, and keep the new radiobutton highlighted only if this new state is confirmed to be true.
When testing, you should try to create a situation where the script fails, this is the principle of rigorous testing.
For example, you could temporarily enter the wrong command within the gtkdialog script to change to a particular CPU FSB state. This creates a good test for the gui - because when the user selects that particular radiobutton to change the state, the gui should highlight that new radiobutton only temporarily, then jump back to the previous highlight when its script determines that the state has failed to change. This would confirm that the gui is telling you the truth!
No. The gui should indicate the current mode without the user needing to consciously press something to find out.01micko wrote:Do you think there is a need for a "current mode" button?
dawnsboy, yes I based these gui's on the same basic controls as you had in your older Pupeeecontrol gui, but you will see that the significant difference is the "Current speed of CPU ..." text display, which Pupeeecontrol did not have.
But I still consider this form of user-interface design rough and inadequate.
With the current 2-button display, the choice of "which" button to press is unintuitive. The user must read the information about what their current FSB state is, then select the "other" button if they decide that they want to change this state.
@tempestuous
I have been the grateful beneficiary of your fine work. I appreciate being able to install and use the various drivers and applications that you have created for the eeepc. I doubt that I would be using Puppy Linux if it were not for those packages ( and I do enjoy using Puppy Linux). I ask that you forgive me if I have offended you with my simplistic offering.
I personally think that the idea being developed for a GUI with radio buttons is the way to go with the Atom processor as it has significantly greater capabilities than my 701 with the Intel Celeron M processor and would of course be capable of much more than two or three steps in speed change (that would be a mess having that many buttons for one purpose). I believe that having control of the fan configuration is probably more pertinent to the Atom processor as well.
I originally became interested in creating the GUI that I eventually placed in the pupeeecontrol.pet file because the fan on my system always operated continuously at 100% whether it needed to or not. It seemed like a good idea to include the buttons for changing cpu speeds in the same gui. Jakfish suggested in an offhand way that he would appreciate it if someone would make a gui for the original package. That is how that gui came about.
I eventually discovered that if I remove the battery when plugged in that my 701 (with your eee module loaded) does a fine job of regulating fan speeds without any help from me. So the only real reason that I have for even dropping back to 630MHz is to save power when running on the battery. Generally the fan runs at 40% with 630MHz selected on battery. As a result I don't use pupeeecontrol very often any more. Especially since there seems to be 110Hz AC wherever I travel. A simple two button gui with or without fan control is all that is needed for that. So I shared the one I made for my own use.
Personally I favor one even simpler than that for the 701.
I have been the grateful beneficiary of your fine work. I appreciate being able to install and use the various drivers and applications that you have created for the eeepc. I doubt that I would be using Puppy Linux if it were not for those packages ( and I do enjoy using Puppy Linux). I ask that you forgive me if I have offended you with my simplistic offering.
I personally think that the idea being developed for a GUI with radio buttons is the way to go with the Atom processor as it has significantly greater capabilities than my 701 with the Intel Celeron M processor and would of course be capable of much more than two or three steps in speed change (that would be a mess having that many buttons for one purpose). I believe that having control of the fan configuration is probably more pertinent to the Atom processor as well.
I originally became interested in creating the GUI that I eventually placed in the pupeeecontrol.pet file because the fan on my system always operated continuously at 100% whether it needed to or not. It seemed like a good idea to include the buttons for changing cpu speeds in the same gui. Jakfish suggested in an offhand way that he would appreciate it if someone would make a gui for the original package. That is how that gui came about.
I eventually discovered that if I remove the battery when plugged in that my 701 (with your eee module loaded) does a fine job of regulating fan speeds without any help from me. So the only real reason that I have for even dropping back to 630MHz is to save power when running on the battery. Generally the fan runs at 40% with 630MHz selected on battery. As a result I don't use pupeeecontrol very often any more. Especially since there seems to be 110Hz AC wherever I travel. A simple two button gui with or without fan control is all that is needed for that. So I shared the one I made for my own use.
Personally I favor one even simpler than that for the 701.
- Attachments
-
- eeecontrol1.png
- (11.68 KiB) Downloaded 950 times
Well I'm stumped at the moment trying to get the radiobuttons to remember.
The gui is quite simple, in fact so simple that it may be possible to get rid of the functions script entirely. It all depends on the outcome of the radiobutton problem.
There are only a few examples of radiobutton retention (?) in stock Puppy (and those methods are not working) and not much documentation on gtkdialog on the web.
I might post my code on zigbert's 'howto' thread and see what happens. I'm sure someone can help.
Everything else works as expected, even threw in some icons and a temp button, showing a splash of the current cpu temp
Here's how it looks..
The gui is quite simple, in fact so simple that it may be possible to get rid of the functions script entirely. It all depends on the outcome of the radiobutton problem.
There are only a few examples of radiobutton retention (?) in stock Puppy (and those methods are not working) and not much documentation on gtkdialog on the web.
I might post my code on zigbert's 'howto' thread and see what happens. I'm sure someone can help.
Everything else works as expected, even threw in some icons and a temp button, showing a splash of the current cpu temp
Here's how it looks..
- Attachments
-
- neweeegui.jpg
- (18.12 KiB) Downloaded 1007 times
Puppy Linux Blog - contact me for access
-
- Posts: 5464
- Joined: Fri 10 Jun 2005, 05:12
- Location: Australia
dawnsboy, heck no. No offence at all.
I have a perfectionist attitude, myself (it's a character fault), but I respect and admire everyone else's attempts to do whatever works for them.
My own expertise is in TV/media production, but I do have some exposure to interface design from when I was involved with internet video streaming 10 years ago. I was taught that fundamentally, interfaces should always report the outcome of what users ask of them. So if you ask your interface to change CPU speed to 900MHz, for example, the interface should indicate success or failure.
01micko, I agree that giving users access to temperature has merit, but I disagree with your particular implementation ie. requiring the user to consciously "ask" for the temperature.
We need to be mindful that the hotkeys package I provided contains Dougal's automatic fan speed control daemon, so strictly speaking it's not necessary to monitor the temperature. The daemon is quietly watching the temperature, and adjusting fan speed accordingly.
Ideally, I would like to see the permanent CPU temp/fan speed indicators which aarf illustrated, be integrated within the Eee scripts.
aarf, how about telling use what application that is? It's certainly not standard in Puppy.
Unfortunately, I suspect that the application which displays the fan speed uses a different mechanism than used by Dougal's script, so we would need to ask Dougal to rewrite his script.
I have a perfectionist attitude, myself (it's a character fault), but I respect and admire everyone else's attempts to do whatever works for them.
My own expertise is in TV/media production, but I do have some exposure to interface design from when I was involved with internet video streaming 10 years ago. I was taught that fundamentally, interfaces should always report the outcome of what users ask of them. So if you ask your interface to change CPU speed to 900MHz, for example, the interface should indicate success or failure.
01micko, I agree that giving users access to temperature has merit, but I disagree with your particular implementation ie. requiring the user to consciously "ask" for the temperature.
We need to be mindful that the hotkeys package I provided contains Dougal's automatic fan speed control daemon, so strictly speaking it's not necessary to monitor the temperature. The daemon is quietly watching the temperature, and adjusting fan speed accordingly.
Ideally, I would like to see the permanent CPU temp/fan speed indicators which aarf illustrated, be integrated within the Eee scripts.
aarf, how about telling use what application that is? It's certainly not standard in Puppy.
Unfortunately, I suspect that the application which displays the fan speed uses a different mechanism than used by Dougal's script, so we would need to ask Dougal to rewrite his script.
- Attachments
-
- aarf-CPUtemp-fanspeed.jpg
- (4.97 KiB) Downloaded 1010 times
tempestuous
That is Pwidgets, (what aarf is dispalying), a frontend for Conky designed by zigbert which WhoDo had as standard in 4.2.1, and, where I learned some code.
I could possibly adjust that particular code to display fan output correctly in Pwidgets .
It would also be possible to display cpu temperature automatically periodically, in one of a number of forms. For example with a splash or (if there is a jwm expert out there)as a panel applet.
Thanks
That is Pwidgets, (what aarf is dispalying), a frontend for Conky designed by zigbert which WhoDo had as standard in 4.2.1, and, where I learned some code.
I could possibly adjust that particular code to display fan output correctly in Pwidgets .
It would also be possible to display cpu temperature automatically periodically, in one of a number of forms. For example with a splash or (if there is a jwm expert out there)as a panel applet.
Thanks
Puppy Linux Blog - contact me for access
Hi tempestous
Ok, I now have the gui working correctly with the radiobuttons remembering their configuration.
I did manage to make it work without a functions file but it is way too slow and not acceptable. The problem is, that it takes a few seconds (probably faster on Atom) for the system to recognise the new mode and gtkdialog lags well and truly behind that. With the functions file everything appears to happen in an instant. The only drawback is that the "Set CPU Mode" button is necessary.
I added a "Eee" logo and a puppy logo, but I can get rid of these. It was mainly to take up that little bit of vacant real estate in the gui. If you like them I can refine them because the "Eee" logo is only a rough draft. I also used Dougal's fan icon on the fan config button.
It was necessary to add a file for the radiobuttons to "read" such that they stayed in configuration, it's only 53 bytes. Zigbert uses a similar method in "Pfind", NathanF also in "Nathan Wallpaper Setter".
Pic below.
I hope this is what you need.
Cheers
Ok, I now have the gui working correctly with the radiobuttons remembering their configuration.
I did manage to make it work without a functions file but it is way too slow and not acceptable. The problem is, that it takes a few seconds (probably faster on Atom) for the system to recognise the new mode and gtkdialog lags well and truly behind that. With the functions file everything appears to happen in an instant. The only drawback is that the "Set CPU Mode" button is necessary.
I added a "Eee" logo and a puppy logo, but I can get rid of these. It was mainly to take up that little bit of vacant real estate in the gui. If you like them I can refine them because the "Eee" logo is only a rough draft. I also used Dougal's fan icon on the fan config button.
It was necessary to add a file for the radiobuttons to "read" such that they stayed in configuration, it's only 53 bytes. Zigbert uses a similar method in "Pfind", NathanF also in "Nathan Wallpaper Setter".
Pic below.
I hope this is what you need.
Cheers
- Attachments
-
- eeenewer.jpg
- (20.03 KiB) Downloaded 1020 times
Puppy Linux Blog - contact me for access
-
- Posts: 5464
- Joined: Fri 10 Jun 2005, 05:12
- Location: Australia
Bravo, 01micko.
Yes, I expected that an "apply" button was likely to be necessary.
If you PM me a dotpet or gzipped tarball I will post it with the Eee hotkeys package.
But your assignment will only be complete when you have done a Celeron version, too!
Are you up for it?
With Celeron there are just two (useful) states: 630 MHz and 900 MHz
The two scripts to activate are /usr/bin/normalclock and /usr/bin/overclock
which are inherited from dawnsboy's older Pupeeecontrol package. You will notice that these scripts go through a series of FSB speed changes, so that the speed is progressively "scaled" up or down, rather than "jumped".
Actually, the name of the script "overclock" is wrong in this case, since 900 MHz is the full operating speed of the Eee's CeleronM CPU. The processor is normally underclocked to 630 MHz to save power. jakfish has discovered that any further underclocking will not achieve noticeable improvement in power consumption.
This is the command to determine the current FSB/voltage settings -
When the Eee is in default mode, the result will be -
The first entry is the FSB speed (70 MHz).
You can extract just this value with -
FSB speed "70" means CPU speed of 630MHz, and
FSB speed "100" means CPU speed of 900MHz.
Yes, I expected that an "apply" button was likely to be necessary.
If you PM me a dotpet or gzipped tarball I will post it with the Eee hotkeys package.
But your assignment will only be complete when you have done a Celeron version, too!
Are you up for it?
With Celeron there are just two (useful) states: 630 MHz and 900 MHz
The two scripts to activate are /usr/bin/normalclock and /usr/bin/overclock
which are inherited from dawnsboy's older Pupeeecontrol package. You will notice that these scripts go through a series of FSB speed changes, so that the speed is progressively "scaled" up or down, rather than "jumped".
Actually, the name of the script "overclock" is wrong in this case, since 900 MHz is the full operating speed of the Eee's CeleronM CPU. The processor is normally underclocked to 630 MHz to save power. jakfish has discovered that any further underclocking will not achieve noticeable improvement in power consumption.
This is the command to determine the current FSB/voltage settings -
Code: Select all
cat /proc/eee/fsb
Code: Select all
70 24 1
You can extract just this value with -
Code: Select all
cat /proc/eee/fsb | awk '{print $1}'
FSB speed "100" means CPU speed of 900MHz.
Well it's done.. for the Atom anyway.
I refined the pixmap a little, looks better. If you want to get rid of it just delete "
<pixmap>
<input file>/usr/share/eeecontrol/eee-pup-s.png</input>
</pixmap>
"
from the eee-testing file.
Added tooltips for the 2 big buttons.
Tested and tested, working fine.
I just put the files, in hierarchy, in a folder and tarballed. They will merge with existing, including the fan icon and the logos pixmap.
Cheers
I refined the pixmap a little, looks better. If you want to get rid of it just delete "
<pixmap>
<input file>/usr/share/eeecontrol/eee-pup-s.png</input>
</pixmap>
"
from the eee-testing file.
Added tooltips for the 2 big buttons.
Tested and tested, working fine.
I just put the files, in hierarchy, in a folder and tarballed. They will merge with existing, including the fan icon and the logos pixmap.
Cheers
- Attachments
-
- eee-atom-stuff.tar.gz
- (5.6 KiB) Downloaded 406 times
Puppy Linux Blog - contact me for access
hehe, posted at same time!
Yep, the Celeron gui is the next mission. With what I learned here it should be ok maybe by tonight.
Cheers.
Yep, the Celeron gui is the next mission. With what I learned here it should be ok maybe by tonight.
Cheers.
Puppy Linux Blog - contact me for access
-
- Posts: 5464
- Joined: Fri 10 Jun 2005, 05:12
- Location: Australia
One more thing, no calling script so it cannot be run from commandline unless you type the full path.
(I did alter the logo, and I did think of that, if you want just put in a puppy logo)
__________________________________________
(a little later)
Well I made a puppy logo only. It is offset to counteract the alignment gtkdialog uses. It looks fine and will avoid any nasty issues (er, if asus get nasty).
EDIT: I just redid the puppy logo, it was too wide.(5:05PM)
(I did alter the logo, and I did think of that, if you want just put in a puppy logo)
__________________________________________
(a little later)
Well I made a puppy logo only. It is offset to counteract the alignment gtkdialog uses. It looks fine and will avoid any nasty issues (er, if asus get nasty).
Code: Select all
<pixmap>
<input file>/usr/share/eeecontrol/puppy.png</input>
</pixmap>
- Attachments
-
- puppy.png
- (1.32 KiB) Downloaded 978 times
-
- eee-pup.png
- (33.51 KiB) Downloaded 964 times
Puppy Linux Blog - contact me for access
Hmmmm...
I have a Celeron but I cannot test my pet. Mine is the Eeepc 701SD , which has been conforming to all the Atom commands. I guess they (asus) upgraded more than the wireless chipset in the 701SD. None of the other commands designed for Celerons work, all dotpets installed in order and rebooted. (..that hurt because it was running for 4 days )
Anyway, I coded all the necessary changes to make the gui appear intuitive (it's the same as the Atom gui minus 1 radiobutton). I hope it works because I was flying blind. Thanks to tempestuous and dawnsboy.
I'm releasing this as a dotpet because it needs to be tested, there should be no dire consequences, but, in saying that I can accept no responsibility. No need for a screeny because it is the same, less a button, as the Atom gui.
Really a new thread should be started for "Eee Celeron" testing.
Cheers
EDIT: .pet removed, see newer post.
I have a Celeron but I cannot test my pet. Mine is the Eeepc 701SD , which has been conforming to all the Atom commands. I guess they (asus) upgraded more than the wireless chipset in the 701SD. None of the other commands designed for Celerons work, all dotpets installed in order and rebooted. (..that hurt because it was running for 4 days )
Anyway, I coded all the necessary changes to make the gui appear intuitive (it's the same as the Atom gui minus 1 radiobutton). I hope it works because I was flying blind. Thanks to tempestuous and dawnsboy.
I'm releasing this as a dotpet because it needs to be tested, there should be no dire consequences, but, in saying that I can accept no responsibility. No need for a screeny because it is the same, less a button, as the Atom gui.
Really a new thread should be started for "Eee Celeron" testing.
Cheers
EDIT: .pet removed, see newer post.
Last edited by 01micko on Sat 03 Oct 2009, 22:01, edited 1 time in total.
Puppy Linux Blog - contact me for access
Hi,
just installed eeecontrol-CeleronM-CPU-test.pet. Running it from Menu->System nothing happens. Running from terminal I getRunning eee-fan-config.sh seems to work.
Please tell me if I miss something.
~ Rolf
just installed eeecontrol-CeleronM-CPU-test.pet. Running it from Menu->System nothing happens. Running from terminal I get
Code: Select all
eee-fan-ctrl.sh: Error: failed to load module eee.ko
Please tell me if I miss something.
~ Rolf
Ich verwende "frugal", und das ist gut so. :wink:
Raspberry Pi without Puppy? No, thanks.
Raspberry Pi without Puppy? No, thanks.
-
- Posts: 5464
- Joined: Fri 10 Jun 2005, 05:12
- Location: Australia
rhadon, you need to install eee-0.2-k2.6.30.5.petrhadon wrote:Code: Select all
eee-fan-ctrl.sh: Error: failed to load module eee.ko
from
http://www.murga-linux.com/puppy/viewto ... 452#346452