Oszczędzanie energii - Toshiba Portege R500
Po publikacji artykułu o konfiguracji notebooka Toshiba Portege R500 pod systemem Debian GNU/Linux wiele osób odezwało się do mnie z pytaniem "Jak to jest możliwe, że Twój laptop działa tak długo i pobiera tak mało prądu?! To niemożliwe!". Niedowierzali tym słowom:
Na podstawowej baterii z włączonymi wszystkimi urządzeniami (Bluetooth, WiFi, podłączone dwa telefony pod USB) na maksymalnym podświetleniu notebook działa 4 godziny bez przerwy, przy założeniu oszczędzania energii pobór mocy spada do... 6W co umożliwia nieprzerwaną pracę biurową przez (uwaga!) 9 godzin! Oczywiście, to tylko teoretyczne założenie, w praktyce nie osiągnąłem jeszcze na podstawowej baterii czasu dłuższego niż 7 godzin.
Pierwszy screen obrazuje sytuację, gdy wszystkie możliwości sprzętu są aktywne, działa karta Wi-Fi, Bluetooth, jasność matrycy jest ustawiona na maksymalny poziom etc. KPowerSave informuje, że czas działania laptopa oscyluje w granicach 5 godzin (bateria jest maksymalnie naładowana).
Drugi zrzut ekranu wykonałem, gdy wyłączyłem WiFi, moduł Bluetooth oraz przyciemniłem matrycę do poziomu 2/7 (gdzie 7/7 to maksymalna wartość, 1/7 to minimalna a 0/7 to wyłączone podświetlenie matrycy). Dodatkowo wyłączyłem obsługę PCMCIA oraz kart SD (generują bardzo dużo przerwań). KPowerSave poinformował, że notebook powinien pracować około 6 godzin i 44 minut, jednak PowerTop uruchomiony w tle pokazuje długoterminowe działanie w granicach 7 i pół godziny. To maksymalny wynik jaki udało mi się uzyskać nie uciekając się do prób zaawansowanego oszczędzania energii. Niestety, mój kernel wywołuje dużo przerwań między swoimi dwoma rdzeniami, co jest bolączką jądra 2.6.24. Nie mam zamiaru go na razie zmieniać, zbyt leniwy jestem ;-). Sądzę, że mógłbym po odpowiednim dobraniu jądra zyskać około pół godziny.
Oczywiście, można posunąć się dalej! W tym celu napisałem prosty skrypt Basha, który wywołany na Toshibie Portege R500 włączy wszystkie możliwe funkcje oszczędzania energii i pozwoli pracować na podstawowej baterii do 9 godzin. Skrypt wyłącza następujące urządzenia:
- Porty USB
- Czytnik kard SD oraz slot PCMCIA
- Kartę bezprzewodową (karta ethernet działa)
- Kartę dźwiękową
- CDROM
- Zmniejsza podświetlenie matrycy do najniższego poziomu (1/7)
- Wyłącza obsługę NFS (generuje sporo przerwań)
Zapytacie "po co?!". Jasne, to sztuka dla sztuki :-). Po prostu lubię się bawić ;-). I jeszcze bardziej - lubię pisać w Bashu :-). Ponadto - używam tego skryptu jadąc pociągiem, gdy piszę np. nowy artykuł, dokańczam swoje programy lub po prostu oglądam film (wtedy włączam tylko kartę dźwiękową).
Skrypt znajdziecie TUTAJ
Przetestowany został na dystrybucyjnym jądrze Debiana w wersji 2.6.24, nie zamieszczam go w całości, gdyż ma 221 linijek.
Po kilku modyfikacjach można go z powodzeniem używać na dowolnym laptopie - zmianić należy funkcję odpowiedzialną za włączanie//wyłączenia karty wifi, Bluetooth oraz karty dźwiękowej.
Enjoy!
Bluetooth Proximity
Posiadasz laptopa z wbudowanym interfejsem BlueTooth? Korzystasz z telefonu//palmtopa z Bluetooth? Ten artykuł może Ciebie zainteresować.
Gdy tylko zakupiłem nowego laptopa zamarzyła mi się dodatkowa funkcja wykorzystująca BlueTooth. Chciałem, aby laptop automatycznie blokował ekran gdy tylko odejdę od niego po czym logował się automatycznie gdy zasiądę przy klawiaturze. Troszkę szperania w google, troszeczkę własnej inwencji i oto jest :-). Skrypt BlueTooth Proximity:
#!/bin/bash
DEVICE="MAC"
CHECK_INTERVAL=2
THRESHOLD="-1"
PID=0
START_CMD='true'
FAR_CMD='dcop kdesktop KScreensaverIface lock'
NEAR_CMD='dcop kdesktop KScreensaverIface quit'
HCITOOL="/usr/bin/hcitool"
DEBUG="/tmp/logi"
connected=1
function msg {
echo "$1" >> $DEBUG
}
function check_connection {
connected=0;
found=0
for s in `$HCITOOL con`; do
if [[ "$s" == "$DEVICE" ]]; then
found=1;
fi
done
if [[ $found == 1 ]]; then
connected=1;
else
msg 'Attempting connection...'
if [ -z "`$HCITOOL cc $DEVICE 2>&1`" ]; then
msg 'Connected.'
connected=1;
else
connected=0;
fi
fi
}
function check_xscreensaver {
PID=`ps -C xscreensaver --no-heading | awk '{ print $1 }'`
if [ "$PID" == "" ]; then
$START_CMD &
fi
}
name=`$HCITOOL name $DEVICE`
msg "Monitoring proximity of \"$name\" [$DEVICE]";
state="near"
while /bin/true; do
check_xscreensaver
check_connection
if [[ $connected -eq 1 ]]; then
rssi=`$HCITOOL rssi $DEVICE | sed -e 's/RSSI return value: //g'`
if (( "$rssi" <= $THRESHOLD )); then
if [[ "$state" == "near" ]]; then
msg "*** Device \"$name\" [$DEVICE] has left proximity"
state="far"
echo "daleko - wlaczam screena"
$FAR_CMD
echo $?
fi
else
if [[ "$state" == "far" ]]; then
msg "*** Device \"$name\" [$DEVICE] is within proximity"
state="near"
sleep 7;
$NEAR_CMD
kdialog --passivepopup "Urządzenie w zasięgu Bluetooth, odblokowanie ekranu" 5
$START_CMD &
fi
fi
msg "state = $state, RSSI = $rssi, PID = $PID"
else
if [[ "$state" == "near" ]]; then
msg "*** Device \"$name\" [$DEVICE] has been disconnected"
state="far"
$FAR_CMD > /dev/null 2>&1
fi
fi
sleep $CHECK_INTERVAL
done
Oryginał znajduje się pod tym adresem, ja jednakże nieznacznie go zmodyfikowałem aby odpowiadał moim preferencjom. W konfiguracji skryptu znajdujemy następujące parametry:
- DEVICE="MAC" - MAC zastępujemy MAC'iem naszego urządzenia
- CHECK_INTERVAL=2 - jak często ma być sprawdzane połączenie
- THRESHOLD="-1" - odległość, wartość dobrana eksperymentalnie
- FAR_CMD='dcop kdesktop KScreensaverIface lock' - komenda wywołana gdy urządzenie nie jest w zasięgu
- NEAR_CMD='dcop kdesktop KScreensaverIface quit' - analogicznie komenda wykonana przy "wejściu" w zasięg
- DEBUG="/tmp/logi" - gdzie zrzucane będą logi
Skrypt najlepiej umieścić w /bin/btprox
# cp btprox /bin/btprox
Ostatnim krokiem jest udostępnienie użytkownikowi bez uprawnień korzystania z hcitool i l2ping.
# chmod +s /usr/bin/hcitool # chmod +s /usr/bin/l2ping
I tyle. Odpalamy btprox i sprawdzamy działanie skryptu :-).
Podobną funkcjonalność oferuje nam bluez-utils wersji >3.0 jednak u mnie i kilku moich kolegów to po prostu nie działa. Ekran zostaje zablokowany gdy komórka całkowicie wyjdzie poza zasięg BlueTooth co może sprawdza się w gorszych chipsetach, jednak u mnie BT łapie na ponad 10 metrów przez dwie ściany...
Touchlib i OpenTouch czyli ekrany wielodotykowe
Pamiętacie film „Raport Mniejszości”? John Anderton korzystał w nim z ekranu dotykowego dużej rozdzielczości do „podglądania” przyszłości. Fikcja? Nie, ta technologia jest już w zasięgu ręki! No, może nie podglądanie przyszłości :-).
Ekran wielodotykowy to urządzenie, które pozwala komunikować się z użytkownikiem poprzez wygodny interfejs panelu dotykowego. Co go jednak wyróżnia to możliwość rozpoznawania wielu równoczesnych zdarzeń, np. używania panelu przez kilka osób jednocześnie.
Firma Microsoft zaprojektowała i stworzyła Microsoft Surface. Projektem zainteresowało się wojsko, kasyna w Vegas i największe hotele świata. Możecie sobie tylko wyobrazić jak wiele pieniędzy to może kosztować.
O samym Microsoft Surface możecie poczytać tutaj a prezentację macie poniżej:
Zapytacie pewnie – a jaki ma to związek z Wolnym Oprogramowaniem? Ma i to dość spory. Touchlib i OpenTouch to otwarte biblioteki do obsługi paneli wielodotykowych. Co ciekawe OpenTouch rozwijane jest przez naszego rodaka: Pawła Sołygę!.
No to super. Mamy całkowicie otwarte biblioteki do obsługi panelu wielodotykowego ale… ciągle nie mamy samego ekranu… Więc czemu sobie takowego nie zbudować?
NUI Group to grupa miłośników technologii naturalnych interfejsów komunikacyjnych. Na ich stronie oraz forum możemy znaleźć osoby, które zajmują się tworzeniem na własną rękę ekranów w technologii Frustrated Total Internal Reflection (FTIR). Sam mechanizm takiego panelu działa na zasadzie całkowitego węwnętrznego odbicia w dość grubej warstwie pleksi.
Złożenie ekranu wielodotykowego jest dość drogie i zajmuje troszkę czasu. Mały ekran 12×15cm możemy zbudować za około 600zł, duże panele (ponad metr szerokości) kosztować nas mogą do kilku tysięcy złotych. Po szczegółowe informacje na temat budowy zapraszam na forum NUI Group, a poniżej krótka prezentacja z możliwości własnego panelu wielodotykowego obsługiwanego przez otwarte bilbioteki touchlib:
Prezentację konkretnego zastosowania możecie zobaczyć na tej stronie (polecam).
Jak się to ma do systemu GNU/Linux? Touchlib i OpenTouch można bez problemu uruchomić i oprogramować pod dowolnym systemem Linuksowym. Dodatkowo – istnieje projekt MPX. MPX to modyfikacja Serwera X tak, aby mógł on korzystać z bilbioteki TouchLib. Wyobrażacie sobie na tym Compiza? :-)
I już na koniec: Touchlib jest wieloplatformowy (uruchamia się na praktycznie każdym sprzęcie, od Maców po PC), wydajny (szybkie działanie zapewnia średniej klasy komputer PC), skalowalny i wolny. Cóż więcej chcieć? Chyba zaczynam odkładać pieniążki na MyBox – mały panel wielodotykowy budowany przez NUI Group za cenę około 250zł. Niestety, nie wyświetla on obrazu, pozwala tylko pobawić się samych Touchlib…
Interfejs do wysyłania smsów via sms-pl
Napisałem sobie prosty skrypt do wysyłania smsów poprzez program sms-pl (dostępny w repozytoriach). Jego konfiguracja opiera się na wprowadzeniu dwóch linijek do pliku /etc/smsrc w których zawrzemy nasz login i hasło do płatnej bramki sms (sposób edycji znajdziemy w dokumentacji programu), możliwe także jest skorzystanie z bezpłatnych bramek sms! Po odpowiednim skonfigurowaniu sms-pl możemy już korzystać z poniższego skryptu: (w przypadku korzystania z innej bramki niż miastoplusa należy wyedytować jedną linijkę w skrypcie)
#!/bin/bash
numer=$(kdialog --inputbox "Wyślij sms pod numer:")
tresc=$(kdialog --textinputbox "Wprowadź treść:")
kdialog --passivepopup "Wysyłam wiadomość..." 4
sms -g miastoplusa -n "$numer" -m "$tresc"
if [ $? == 1 ]; then
kdialog --sorry "Sms nie wysłany, spróbuj ponownie"
else
kdialog --passivepopup "Wiadomość wysłana!" 3
fi
exit 0
Zamieniąc odpowiednio kdialog na xdialog lub dialog skrypt będzie działać też w innych środowiskach graficznych niż KDE (możliwe że konieczna będzie drobna zmiana skryptu).
Wiem że to banalne, wiem że są odpowiednie programy do robienia tego samego. Wolę jednak korzystać z własnych rozwiązań.
DCOP - komunikacja międzyprocesowa
Zastanawialiście się kiedyś, czemu Iceweasel tak chętnie 'wskakuje' na pasek kicker, Opera tak ładnie ładuje się do tray'a a Wasz ulubiony player muzyczny oferuje Wam wygodne sterowanie głośnością czy też paskiem postępu utworu przez mini-interfejs? Desktop Communication Protocol [DCOP] to protokół umożliwiający komunikację między procesami w środowisku KDE3. W momencie gdy piszę te słowa KDE4 zbliża się wielkimi krokami (3 miesiące), a wraz z nim całkowite odejście od DCOP w kierunku D-BUS SYSTEM, więc póki jeszcze czas postaram się opisać to cudowne narzędzie - ot dla potomnych :-).
Przyjrzyjmy się zatem interfejsowi DCOP, a konkretniej - klientem DCOP. Używając skonfigurowanego dopełniania poleceń w Bashu możemy przeglądać strukturę aplikacji w bardzo wygodny sposób.
$ dcop kaccess khotkeys kmix ksmserver kcookiejar kicker knotify kwin kded klauncher konqueror-6695 kdesktop klipper konsole-9344
Widzimy tutaj wszystkie programy korzystające z interfejsu DCOP do wymiany informacji. Chcemy "skontaktować się" z kmix odpowiadającym za mikser systemowy. Wpiszmy zatem:
$ dcop kmix kmix Mixer0 kmix-mainwindow#1 Mixer1 MainApplication-Interface qt
Otrzymaliśmy wykaz wszystkich funkcji, jakie oferuje nam kmix. Posiadam w systemie dwie karty dźwiękowe, zatem mam do dyspozycji Mixer0 oraz Mixer1. Sprawdzę, czy Mixer0 to moja podstawowa karta dźwiękowa.
$ dcop kmix Mixer0 mixerName Intel 82801DB-ICH4
Tak jest. Zacznijmy zatem "magię". Mixer0 oferuje nam takie funkcje:
$ dcop kmix Mixer0 absoluteVolume int mute setMute absoluteVolumeMax interfaces open setRecordSource absoluteVolumeMin isAvailableDevice QCStringList setVolume bool isRecordSource QString toggleMasterMute close long setAbsoluteVolume toggleMute decreaseVolume masterMute setBalance void functions masterVolume setMasterMute volume increaseVolume mixerName setMasterVolume
I już po krótkiej zabawie możemy (konsolowo!) zmieniać głośność, wyciszać kartę czy też nawet zamknąć program. Aby dowiedzieć się, w jaki sposób używać wybranej funkcji wpisujemy:
$ dcop kmix Mixer0 QCStringList interfaces() QCStringList functions() void setVolume(int deviceidx,int percentage) void setMasterVolume(int percentage) void increaseVolume(int deviceidx) void decreaseVolume(int deviceidx) int volume(int deviceidx) int masterVolume() void setAbsoluteVolume(int deviceidx,long int absoluteVolume) long int absoluteVolume(int deviceidx) long int absoluteVolumeMin(int deviceidx) long int absoluteVolumeMax(int deviceidx) void setMute(int deviceidx,bool on) void setMasterMute(bool on) void toggleMute(int deviceidx) void toggleMasterMute() bool mute(int deviceidx) bool masterMute() void setRecordSource(int deviceidx,bool on) bool isRecordSource(int deviceidx) void setBalance(int balance) bool isAvailableDevice(int deviceidx) QString mixerName() int open() int close()
Skorzystajmy z tego i wyciszmy naszą kartę:
$ dcop kmix Mixer0 setMute 0 1
I ponownie ją włączmy:
$ dcop kmix Mixer0 setMute 0 0
Zabawy z DCOP nie ograniczają się tylko do tak prostych spraw, jak sterowanie głośnością czy zamykanie aplikacji. Pokaże Wam teraz, jak można użyć DCOP do oskryptowania własnego "wyświetlacza" tekstów aktualnego utworu na ekranie. Potrzebujemy do tego uruchomionego Amaroka.
$ dcop amarok player
Nie wklejam tutaj wyniku tej komendy, gdyż jest on zbyt duży :-). Amarok daje nam dostęp do tak wielkiej ilości funkcji poprzez interfejs DCOP, że z wykorzystaniem języków skryptowych możemy napisać własny "wrapper" czy też mini-interfejs dla tej kobyłki. Zobaczmy na kilka przykładów:
$ dcop amarok player nowPlaying LOST HORIZON - World Through My Fateless Eyes
$ dcop amarok player currentTime 0:48
$ dcop amarok player lyrics
Ostatnia komenda pokaże nam tekst aktualnie odtwarzanego utworu (o ile mamy skonfigurowany moduł Lyrics w skryptach Amaroka). Jak zatem pokazać to cudo na ekranie? Skorzystamy z Conky :-). Najpierw stwórzmy skrypt "lyrics"
$ cat /bin/lyrics
#!/bin/bash
dcop amarok > /dev/null
if [ $? != 0 ]; then
echo "Amarok nie jest włączony";
else
dcop amarok player lyrics
fi
exit 0
I podepnijmy go pod Amaroka (linijka do wklejenia w Conky'm, wyjście poddane obróbce "śmieci" xml'a).:
${execi 10 lyrics | tail -n +2 | sed "s/'/'/g"}
Tym oto prostym sposobem zmusiliśmy Conky do ukazywania tekstu aktualnego utworu. Podobnie możemy konfigurować swoje skrypty odwołujące się do danego programu (co widać w skrypcie "lyrics" w instrukcji warunkowej 'if'. Ale czy to koniec?
Oczywiście że nie! Czemu by nie użyć DCOP jako systemu powiadomień (np. o nowej poczcie, albo o wydarzeniu)? To się da zrobić!
$ dcop knotify default notify eventname appname 'Witaj swiecie!' '' '' 2 0
Opis poszczególnych parametrów funkcji "notify" uzyskamy poprzez:
$ dcop knotify Notify | grep notify void notify(QString event,QString fromApp,QString text,QString sound,QString file,int present,int level) void notify(QString event,QString fromApp,QString text,QString sound,QString file,int present,int level,int winId) void notify(QString event,QString fromApp,QString text,QString sound,QString file,int present,int level,int winId,int eventId)
Jak widzicie interfejs DCOP jest bardzo wygodny dla programistów języków skryptowych (np. jak w moim przypadku - Basha). Sprawia, że moje programy otrzymują nowe funkcjonalności i działają w różnych warunkach (np. potrafią sprawdzać, czy dany program jest uruchomiony czy nie, jeśli nie wyświetlać graficzne powiadomienie itp.). DCOP posiada jeszcze jeden, ogromny plus. Jest bardzo szybki. W moim odczucie o wiele szybszy od D-BUS. Nie rozumiem czemu twórcy KDE4 zrezygnowali z DCOP. Obiecują interfejs zastępczy, wrapper zapytań. Mówią że będzie kompatybilnie. Już to widzę... Ja od DCOP niezbyt chcę odchodzić. I na koniec kilka ciekawostek:
$ dcop kdesktop KDesktopIface runAutoStart
W ten sposób KDE uruchamia wbudowany Autostart.
$ dcop kdesktop KBackgroundIface setWallpaper
Wasz program ma zmieniać domyślną tapetę?
$ dcop kdesktop KDesktopIface setIconsEnabled
Ukrywać ikony?
$ dcop knotify default notify eventname appname 'Gorion TVN-Style HACK3d!!!!111' '' '' 2 0
I straszyć kumpla? :-)) Życzę Wam miłej zabawy w odkrywaniu możliwości tego systemu!
I jak zwykle: ENJOY! Bo Linux to masa zabawy :-)
Pytanie na marginesie: czy Gnome posiada podobny interfejs? Czy używa D-BUS? Przyznaję - nie wiem bo nie używam od bardzo dawna.
