Automatic Screen Detection And Configuration Under Awesome WM

Recently I’m mainly interested in automating my day-to-day tasks on Linux laptop. I’ve started with automating back-up process, now come time to automate external screen detection (and configuration).

For couple of months I was struggling with ZSH history to find XRandR commands that enables and disables external screen. During that time I was almost sure that there is another way of handling this task … since eg. Gnome was doing it automatically. First idea was to find part of Gnome that is responsible for this feature and simply just integrate it with Aersome WM. But my from-time-to-time raw searches didn’t snow any interesting resources. Therefore I’ve decided that I must done it by my self … this is how screenful project was born.

What is screenful ?

It is simple extension to Awesome WM that allows you (with little knowledge of Lua and XRandR params) automatically configure connected screen. It integrates udev drm/change event with Awesome and XRandR. First of all there is udev rule that when drm/change event appears inform screenful about output change in particular card. Then screenful will “calculate” which card output was connected/disconnected, computes screen id based on EDID and finally run configured action. When configuration file doesn’t have specified configuration for this id then screenles will append commented configuration for it and run default action.

What is unique in screenful ?

Same as Awesome WM config file, the screenful config file is a Lua script! Therefore you can do anything you can imagine when external monitor is connected/disconnected. For example you can switch mplayer default audio output when you HD TV set is connected using HDMI cable then change it back when you disconnecting HDMI cable. Also you can reorganize yours tags and windows using Awesome Lua API … and more … Honestly I doubt that you can achieve similar behaviour in any different Window Manager 😉

Project is hosted on github if you encounter any issues or have ideas about new functionalities in screenful feel free to fork me, fill a bug or mail me 😉

Automatic backup in Linux

Some time ago I’ve started backing up my laptop hard drive in any case of failure. Until today I was simply connecting external back-up-drive and manually launching mount && rsync command from zsh history. But this requires that always after connecting this special device I need to go to terminal, log in as root then find this back up command and run it.

Recently I was wondering how this process could be improved or even done automatically. I had few requirements:

  • it should be fully automated
  • system should inform me that back up process was started and that it ends
  • this notification should be done as some system pop up in X windows

So I’ve come with a solution that connects udev, DBus notification and awesome wm naughty library … and it is really simple 😉

How it works ? When you connects back-up-device udev will pick up this event, create a symbolic link to /dev/backup, then launch backup script. This script will send a notification through DBus, this event will be received by naughty and displayed as a simple notification in Awesome WM. After sending notification signal the backup script will mount given device and launch rsync command. After successful synchronization backup device will be unmonted and another notification signal will be send to inform you that you can now disconnect it.

How to achieve this ?

First of all we need to figure out UUID of our back up device (I assume that /dev/sdb2 is yours back-up-partition) :

# blkid /dev/sdb2
/dev/sdb2: UUID="97377fed-edaf-407b-9e02-5c6cecd6dceb" SEC_TYPE="ext2" TYPE="ext3"

Then we need to create new udev rule in /etc/udev/rules.d we can call it 99-backup.rules:

ENV{ID_FS_UUID}=="97377fed-edaf-407b-9e02-5c6cecd6dceb", SYMLINK+="backup"
ACTION=="add", ENV{ID_FS_UUID}=="97377fed-edaf-407b-9e02-5c6cecd6dceb", RUN+="backup"

Of course you need to replace my UUID with one you get from blkid command. Those two lines are responsible for creating symbolic link called backup in /dev directory to device with given UUID; second line will launch backup script when device with given UUID is added.

Finally we need to create our backup script and put it into /lib/udev directory. Here is content of this script:

function show_notification() {
	su $USER -c "export DISPLAY=':0.0'; \
		export XAUTHORITY='/home/$USER/.Xauthority'; \
		/usr/bin/dbus-send --type=method_call --dest=org.freedesktop.Notifications \
			/org/freedesktop/Notifications  org.freedesktop.Notifications.Notify string:'' \
			uint32:0 string:'' string:'$1' string:'' array:string:'' array:string:'' int32:$MSG_TIMEOUT"
function backup() {
	show_notification "Backup process started! Do NOT disconnect backup device."
	mount /dev/backup /mnt/backup
	ionice -c 3 rsync -az --delete --exclude=/dev --exclude=/mnt --exclude=/media --exclude=/run --exclude=/proc --exclude=/tmp --exclude=/sys --exclude=/var/log --exclude=/var/run / /mnt/backup
	umount /mnt/backup
	show_notification "Backup process successed! You can disconnect backup device."
backup &

In this file you only need to change USER variable to yours UNIX user name, also you can adjust MSG_TIMEOUT to your needs (-1 means that default value will be taken). Most difficult part in this script was to figure out how to send DBus notification from root to regular user, since all window managers create and listen on theirs own session scoped buses. As you can notice we can force dbus-send command to send signal to proper bus instance by executing this command on behalf of  given user and with exported DISPLAY and XAUTHORITY variables.

Full source code is available on github. Have a nice and pleasant back up’s 😉 -ck3 + bfs401

I’ve recently move from vanilla kernel to -ck kernel flavor.  What is -ck ? This is set of patches by Con Kolivas that improves desktop performance. By default -ck patches includes Brain Fuck Scheduler (bfs also by Con Kolivas); this scheduler is designed to improve system interactivity and responsiveness in small system, where “small” means less then 16 cpu’s/cores/threads.

Few days ago the new version of vanilla kernel ( was released, two or three days before the new version of bfs (401) was also released. Unfortunately -ck patches didn’t get an update, so I’ve decided to play a little bit with it.

First of all I’ve spotted that -ck apples bfs as a first patch, so second step wast to find out where bfs patch ends … this was a really easy task. With this knowledge I could easily extract old version of bfs from -ck3. Then both patches can be contacted and applied on vanilla First compilation shows that function above_background_load was removed from bfs401, fortunately it was used only once 😉

I’m using this kernel ( for two days without any problems so it seams that my combination of those patches doesn’t brake anything. If you want to try this on your own, here is

Backported fix suspend/resume issue in brcmsmac

Few days ago my Macbook just died therefore I was forced to buy a new laptop cialis overnight. After a quick overview on marked I’ve decided to buy an Toshiba Portege R700 with Intel i5 processor. Unfortunately it has an Broadcom 4727 Wi-Fi card with is only supported by staging brcm80211 module. Generally it works pretty well on 2.6.37 kernel, if you shutdown and power up laptop, but when  you use suspend like I do it doesn’t get up after resume. The module needs to be reloaded to work again.

Thanks to Arend van Spriel this issue were fixed but patch that was send on linux-wireless mailing list doesn’t apply on vanilla 2.6.37 sources.  To get this working I decided to back port this patch, and it appears to be was very simple task ;). So if you are have similar problems with BCM4727 on 2.6.37 like I had here is a patch that clearly apples on 2.6.37 and fix this issue.

diff -uNr drivers-orig/staging/brcm80211/sys/wl_mac80211.c drivers/staging/brcm80211/sys/wl_mac80211.c
--- drivers-orig/staging/brcm80211/sys/wl_mac80211.c   2011-01-05 01:50:19.000000000 +0100
+++ drivers/staging/brcm80211/sys/wl_mac80211.c    2011-01-13 17:28:50.000000000 +0100
@@ -299,7 +299,6 @@
    wl_info_t *wl = hw->priv;
-  wl_down(wl);
@@ -336,6 +335,14 @@
 static void
 wl_ops_remove_interface(struct ieee80211_hw *hw, struct ieee80211_vif *vif)
+  struct wl_info *wl;
+  wl = HW_TO_WL(hw);
+  /* put driver in down state */
+  WL_LOCK(wl);
+  wl_down(wl);
+  WL_UNLOCK(wl);
@@ -1356,7 +1363,6 @@
    return 0;
 static int wl_suspend(struct pci_dev *pdev, pm_message_t state)
    wl_info_t *wl;
@@ -1371,11 +1377,12 @@
        return -ENODEV;
+  /* only need to flag hw is down for proper resume */
-  wl_down(wl);
    wl->pub->hw_up = false;
-  pci_save_state(pdev, wl->pci_psstate);
+  pci_save_state(pdev);
    return pci_set_power_state(pdev, PCI_D3hot);
@@ -1399,7 +1406,7 @@
    if (err)
        return err;
-  pci_restore_state(pdev, wl->pci_psstate);
+  pci_restore_state(pdev);
    err = pci_enable_device(pdev);
    if (err)
@@ -1411,13 +1418,12 @@
    if ((val & 0x0000ff00) != 0)
        pci_write_config_dword(pdev, 0x40, val & 0xffff00ff);
-  WL_LOCK(wl);
-  err = wl_up(wl);
-  WL_UNLOCK(wl);
+  /*
+   *  done. driver will be put in up state
+   *  in wl_ops_add_interface() call.
+   */
    return err;
-#endif                /* LINUXSTA_PS */
 static void wl_remove(struct pci_dev *pdev)
@@ -1452,10 +1458,8 @@
 static struct pci_driver wl_pci_driver = {
  .name  = "brcm80211",
  .probe = wl_pci_probe,
  .suspend = wl_suspend,
  .resume  = wl_resume,
-#endif                /* LINUXSTA_PS */
  .remove   = __devexit_p(wl_remove),
  .id_table = wl_id_table,
diff -uNr drivers-orig/staging/brcm80211/sys/wl_mac80211.h drivers/staging/brcm80211/sys/wl_mac80211.h
--- drivers-orig/staging/brcm80211/sys/wl_mac80211.h   2011-01-05 01:50:19.000000000 +0100
+++ drivers/staging/brcm80211/sys/wl_mac80211.h    2011-01-13 17:17:39.000000000 +0100
@@ -84,9 +84,7 @@
    unsigned long flags;        /* current irq flags */
 #endif             /* BCMSDIO */
    bool resched;       /* dpc needs to be and is rescheduled */
-  u32 pci_psstate[16];   /* pci ps-state save/restore */
    /* RPC, handle, lock, txq, workitem */
    rpc_info_t *rpc;    /* RPC handle */

BTW. This laptop works pretty good on linux. All parts seams to be working properly (I didn’t tested bluetooth, and finger print scaner because I don’t use it), there are only problems after resuming system from suspend like above described problem with BCM4727 (other problems are connected with back light changing and graphics performance).


It seams that this patch is included in kernel 2.6.38-rc3

Gitosis dodanie repo

Prace nad programem do inżynierki zaszły już tak “daleko”, że wypadało by gdzieś ten kod przetrzymywać dla bezpieczeństwa. Dobrym dodatkowym feature’m byla by też możliwość jego wersjonowania … jako, że jakiś temu postawiłem sobie własne repo git’a (dwie (1, 2) z zamierzonych trzech części opisu instalacji zostały już opublikowane) wybór był oczywisty.

Początkowo zadanie wydawało się bardzo banalne … dodać repozytorium do gitosis i wszystko powinno się zrobić automatycznie … cóż tak niestety nie było. Dla potomności (oraz mojej często wątpliwej pamięci) postanowiłem opisać całą procedurę.

Będzie do tego potrzebna nam konfiguracja gitosis. Jako że jest ona przetrzymywana jako jedno z repozytoriów nie powinno być żadnych problemów z jej uzyskaniem. Tak więc jeżeli nie mamy już jakiejś kopi na dysku wywołujemy komendę:

git clone ssh://

Następnie edytujemy plik gitosis.conf w którym odajemy nowe repo:

[repo nazwa-nowego-repo]
owner = joe
description = opis

No i niby wygląda na to, że to wszystko … niestety nie jest tak łatwo, z tego co doświadczyłem to  gitosis wymaga, żeby każde repo posiadało osobną grupę o tej samej nazwie (możliwe, że można to jakoś przekonfigurować ale ja nie znalazłem takich informacji). Więc nie pozostaje nam nic innego jak dodać kolejną grupę:

[group nazwa-nowego-repo]
owner = joe
writable = nazwa-nowego-repo
members = joe

Zapisujemy zmiany i za pomocą git push wypychamy je na serwer … no to konfiguracje gitosis mamy za sobą. Teraz zostało nam jeszcze utworzyć repo ;>

Tak więc w lokalnym systemie tworzymy sobie nowy katalog albo wchodzimy do katalogu projektu który chcemy wrzucić do repo, w środku wywołujemy git init, następnie przy użyciu git add dodajemy wszystkie pliki do commit’a. Potem commit’ujemy zmiany do lokalnego repo (git commit -m “initial commit”) … no i teraz najważniejsze, dodajemy nasze zdalne repo:

git remote add dowolna-nazwa-repo ssh://

i tryumfalnie wypychamy wszystko na serwer

git push dowolna-nazwa-repo --all

To tyle, wszystko powinno działać … przynajmniej na razie u mnie działa ;>

Dziś lub jutro dodam wpis odnośnie aktualnego stanu wtyczki dodającej obsługę git’a dla Eclipse 😉 będzie to bardzo szybkie overview funkcjonalności których do tej pory użyłem/używałem.

Wpis o git’cie i eclipse jest prawie gotowy, zostało mi jeszcze opisać branche’owanie, merge’owanie, push’owanie oraz pull’owanie i wstawić screenshot’y 😉

Dziś git też mnie pokonał 😐 … okazało się, że aktualnie plugin nie wspiera merge’owania branche’y, a push’owanie i fetch’owanie jest zbyt skomplikowane żeby opisywać je w jednym wpisie (zwłaszcza jeżeli nie ma się z tym zbyt wiele doświadczenia). Postaram się skończyć wpis jutro (zapamiętać: jutro nigdy nie umiera ;)) i go opublikować.