Yearly Archives: 2013

Apple Wired Keyboard on Arch Linux

MB110LL
Magnificient ArchWiki specifies optimal way to use Apple KB on Arch Linux, however because of some changes in udev module AUR package un-apple-keyboard doesn’t really work out of the box. Edit: Looks like it’s working okay now.

To make changes like:

  • Adds a /etc/modprobe.d/hid_apple.conf file which enables the F keys by default, as above.
  • Uses keyfuzz to remap F13-15 to PrintScreen/SysRq, Scroll Lock, and Pause, respectively
  • Swaps the ordering of the Alt and Meta (Command) keys to match all other keyboards, again using keyfuzz.
  • Applies these changes automatically when you plug in your keyboard, with a udev rule.

We’ve got to enable keyfuzz by systemctl enable keyfuzz and run additional keyfuzz script on boot. I just add execution to my /home/username/.bashrc file:

sudo keyfuzz -s -d /dev/input/by-id/usb-Apple__Inc_Apple_Keyboard-event-kbd < /etc/keyfuzz/apple_aluminium.keyfuzz

To make it execute passwordless it’s also needed to make light change in /etc/sudoers file, eg.


(... some lines)
username ALL=NOPASSWD: /usr/bin/keyfuzz

Also I experienced strange problem that holding left and down arrows sometimes doesn’t repeat key action. To workaround it there’s additional change on startup (so .bashrc again).

xset r 113; xset r 116

And now it’s perfect! Fn+F1-F19 button combinations are great to assign some additional functions also.

Source 1: https://wiki.archlinux.org/index.php/Apple_Keyboard
Source 2: https://aur.archlinux.org/packages/un-apple-keyboard/

Nowe Cinnamon i Nemo – ściąganie napisów do filmów [QNapi]

Korzystam ze skądinąd popularnego DE Cinnamon, będącego forkiem GNOME-Shell, nakierowanym na “klasyczną” obsługę peceta. Jest bardzo łatwy w obsłudze i oferuje ogromne możliwości dostosowania go pod siebie. Używa domyślnie menedżera plików Nemo – forka Nautiliusa z kolei. Owy menedżer dotychczas cierpiał na brak możliwości podpinania akcji pod menu kontekstowe, przez co nie można było chociażby wygodnie ściągnąć napisów do filmu/odcinka serialu.

Pojawiła się nowa wersja Cinnamona (i Nemo), oznaczona jako 1.8, wspierająca Actions API, czyli właśnie akcje poprzez menu kontekstowe. Nie omieszkałem go wykorzystać i napisać prostego skryptu do ściągania napisów poprzez QNapi – oto i on:

Aż oczy bolą, czyli kontrola jasności monitora na desktopie

Gdy pracuje się cały dzień przy komputerze, warto zadbać o komfort – a jedną z rzeczy najbardziej ów komfort psującą, jest ból oczu powodowany zbyt dużym natężeniem światła. Póki nie wejdą na rynek duże, kolorowe monitory e-inkowe bez opóźnień (oj, chciałbym takie do pracy nad kodem), będziemy odczuwać skutki ciągłego uderzania jasnego monitora.

cat_eyes_animation_1_W ciągu dnia – chcąc nie chcąc – trzeba “walczyć” ze światłem naturalnym, za to od wieczora wypadałoby zmniejszyć jasność. Na laptopach zazwyczaj nie jest to problem – prawie każdy system wspiera programową kontrolę jasności matrycy. Na desktopach, niestety, nie jest to takie proste. Nikt nie będzie przecież przynajmniej dwa razy dziennie ustawiał jasności przez przyciski na monitorze.

W tym miejscu mógłbym polecić program f.lux (Linux/OSX/Windows), który wprawdzie nie kontroluje jasności, ale kontroluje wyświetlane przez monitory barwy, aby jak najmniej raniły oczy w ciągu dnia i nocy – tylko nie każdemu, jak i mi, muszą odpowiadać “zniekształcone” kolory. Obejście problemu – ale nie rozwiązanie.

Pod Windowsem korzystałem z małego programu Desktop Lighter, który umożliwia nadpisanie standardowej jasności systemu, za pomocą “paska przewijania” (w paskudnym interfejsie) i skrótów klawiszowych. Nie powalało to na automatyczną kontrolę jasności, ale przynajmniej można było ją własnoręcznie ustalać na żądanie.

Co pod Linuksem? Oczywiście jest prościej ;-). Wystarczy wykorzystać mechanizm XRandr, przeznaczony do ogólnego zarządzania ekranami podłączonymi do komputera. Proponuję tutaj dwa rozwiązania – jedno, które wymaga okiełznania komend terminalowych i drugie, zautomatyzowane.

1) Obsługa surowa

Xrandrowi należy podać identyfikatory monitorów, których jasność chcemy modyfikować. W celu ich poznania używamy… samego xrandra.

xrandr -q

Polecenie to wyświetli w terminalu aktualne listę podłączonych monitorów wraz z ich trybami. Interesujące wpisy przybierają formę “DVI-0″,”VGA-0″,”DVI-1” i podobne. Na przykład w wyniku

Screen 0: minimum 320 x 200, current 3600 x 1080, maximum 8192 x 8192
 DVI-0 connected 1920x1080+1680+0 (normal left inverted right x axis y axis) 531mm x 298mm
 1920x1080 60.0*+
 1680x1050 59.9
 1680x945 60.0
 1400x1050 74.9 59.9
 1600x900 60.0
 1280x1024 75.0 60.0
 1440x900 75.0 59.9
 1280x960 60.0
 1366x768 60.0
 1360x768 60.0
 1280x800 74.9 59.9
 1152x864 75.0
 1280x768 74.9 60.0
 1280x720 60.0
 1024x768 75.1 70.1 60.0
 1024x576 60.0
 832x624 74.6
 800x600 72.2 75.0 60.3 56.2
 848x480 60.0
 640x480 72.8 75.0 60.0
 720x400 70.1
 DIN disconnected (normal left inverted right x axis y axis)
 DVI-1 connected 1680x1050+0+30 (normal left inverted right x axis y axis) 473mm x 296mm(...)

Moje monitory są rozpoznane jako DVI-0 i DVI-1.

Po zapoznaniu się z identyfikatorami, można już zmienić jasność. Wykonuje się to poleceniem:

xrandr --output DVI-0 --brightness 0.5

Gdzie DVI-0 to identyfikator, “0.5” to określenie jasności od 0 do 1 (koniecznie z kropką).

2) Obsługa zautomatyzowana

Oczywiście, taka obsługa nie jest zbyt wygodna. Warto stworzyć parę skryptów, by usprawnić cały proces.

Poleceniem:

sudo nano /usr/bin/setlight

tworzymy (jako root, przy podaniu odpowiedniego hasła) skrypt “setlight”. Jego zadaniem będzie zmiana jasności na podaną argumentem wartość dla wszystkich monitorów.

Kod skryptu (wklejamy Ctrl+V, zapisujemy Ctrl+X, potwierdzamy “T”):

#!/bin/sh
#by dRaiser
#http://draiser.net

OUTPUTS=$(xrandr |awk '$2 ~ /connected/ {print $1}')
EXECUTE=""
for CURRENT in $OUTPUTS
do
xrandr --output $CURRENT --brightness $1
done

Nadajemy uprawnienia do wykonywania skryptu:

sudo chmod +x /usr/bin/setlight

W tym momencie można już kontrolować jasność prostym poleceniem:

setlight 0.5

Co jest już o niebo wygodniejsze.
To jednak jeszcze nie koniec, osobiście stworzyłem sobie dwa jeszcze mniejsze skrypty – “lighter” i “darker”, do ustawiania predefiniowanych schematów na “dzień” i na “wieczór/noc”.

sudo nano /usr/bin/lighter

Kod skryptu:

#!/bin/sh
#by dRaiser
#http://draiser.net
setlight 1
sudo nano /usr/bin/darker

Kod skryptu:

#!/bin/sh
#by dRaiser
#http://draiser.net
setlight 0.7

Prawo do wykonywania:

sudo chmod +x /usr/bin/lighter
sudo chmod +x /usr/bin/darker

Pozostało jeszcze zadanie crona (harmonogramu automatycznych poleceń), które uruchomi obie komendy o odpowiednich godzinach, np 12 i 20. Najwygodniej utworzyć je graficznym edytorem “Scheduled tasks” (jeśli go nie posiadamy, instalujemy poleceniem

sudo apt-get install gnome-schedule

w systemach debianopochodnych.

W edytorze dodajemy dwa zadania:

2013-04-20-1536242013-04-20-153635

Poprawka: W polu “Command” składnia polecenia powinna zawierać komendę: “export DISPLAY=:0.0 ;” przed wywołaniem lighter/darker.

export DISPLAY=:0.0 ;lighter
export DISPLAY=:0.0 ;darker

I automat “rusza”. Codziennie o godzinie 12 monitor(y) zostaną rozjaśnione, o 20 z kolei przyciemnione. W każdej chwili można go też przestawić na żądanie poleceniami:

lighter
darker

(70% jest według mnie optymalne na wieczór+noc). Jeśli ktoś woli, można nawet utworzyć aktywator (launcher) z ładną ikonką, uruchamiający dowolne z poleceń – też zadziała.

Różnica przy korzystaniu ze ściemnianego w razie potrzeby monitora jest, w mojej opinii, ogromna.  Polecam też monitory matowe, nieodbijające za dużo światła. :)

Linux – po prostu działa, tylko nie wszędzie

Niejaki Miguel de Icaza, do niedawna programista mocno wspierający rozwój Linuksa – konkretniej współzałożyciel GNOME (najpopularniejsze środowisko graficzne) i deweloper MONO, czyli upraszczając “.NET dla UNIXów”, zakrzyczał. Na tyle donośnie, że jego krzyk odbił się szerokim echem pośród społeczności.

Wykrzyczał był on, że Linux to obecnie Czarnobyl (szkoda, że nie sodoma i gomora) i w przeciwieństwie do Mac OSX, straszliwie problematyczna platforma, na której nic nie działa. Pan Icaza był zaskoczony zabierając MacBooka na urlop, że usypianie i łapanie sieci mu działa bezproblemowo, sugerując, że pod pingwinem się to nie zdarza.

Zaskakuje mnie w tej wypowiedzi (pełna), jak i we wszelkich podobnych, że porównuje się stabilność pingwina nie do OSX na zwykłym pececie, ale do OSX na dedykowanym sprzęcie od Apple’a. Ja wiem, że tylko takie rozwiązanie jest wspierane, a nawet według licencji Apple’a nie można zrobić inaczej, ale Linux – uwaga, uwaga – też świetnie działa jako desktopowy system na ogromnej ilości konfiguracji. Zapewne nigdy nie będzie tak, żeby działał na każdej – ktoś musi pisać sterowniki – ale tym bardziej nie jest tak z systemem Apple’a.

Kupując laptopa pod OSX, wybieramy MacBooka, a nie ThinkPada, bo mamy pewność, że na nim zadziała. Dlaczego więc kupując laptopa i planując używać pod nim Linuksa nie sprawdzamy (w jednej z baz sprzętowych), czy jest on kompatybilny z planowanym OS?

Ostatnio kupując laptopa nie olałem sprawy i nie stwierdziłem, że skoro Windows na nim śmiga, to Linux też zaskoczy, co doprowadziłoby zapewne do wielu kłopotów; poszukałem potencjalnych problemów, wybrałem sensowną i popularną architekturę, a teraz wszystko* mi działa z marszu – grafika, dźwięk, usypianie, wifi i inne podstawowe sprawy, nawet klawisze multimedialne system obsłużył bez minimalnej nawet konfiguracji. Wybierając sprzęt pod biurkowy desktop, też zwracam uwagę na kompatybilność – tutaj jest nawet prościej.

Nie ma co siać mitu, że Linux to darmowy Windows, który zadziała na wszystkim, bo to błąd. Kupujemy sposób na korzystanie z komputera – system – więc dobierajmy sprzęt pod niego, a nie w drugą stronę.

* za wyjątkiem dwóch kart graficznych – ale wiedziałem o tym przy zakupie i gdyby to nie było problematyczne, wyłączyłbym zintegrowaną i zostawiłbym wyłącznie mocnego AMD;

Kontrola obrotów wentylatora na płytach Asus

Parę dni po przeniesieniu głównego środowiska na Linuksa zorientowałem się, że wentylator zamontowany na procesorze działa zdecydowanie aktywniej niż na Windowsie. O ile tam poradził sobie z kontrolą niezawodny SpeedFan (albo, o zgrozo, ASUS AI Suite), to na Linuksie uważaną za skuteczną metodą jest wykorzystanie dwóch małych aplikacji – fancontrol i konfiguratora doń, tj pwmconfig (a także sensors dla sprawdzenia aktualnych temperatur).

Niestety, już polecenie sudo pwmconfig zwracało błąd polegający na nieznalezieniu kompatybilnych modułów. Jako że moja płyta nie jest zbyt popularna (Asus P5K SE/EPU), trochę się naszukałem rozwiązań – wreszcie zaryzykowałem z dodaniem informacji do bootloadera (GRUB), które teoretycznie miała pomóc w przypadku innej, starszej płycie Asusa. Szczęśliwie zadziałało, obroty i temperatury są w normie, więc mogę je z czystym sumieniem polecić. Jakkolwiek uwaga – Wiki Arch Linuksa podaje, że owo rozwiązanie może być niebezpieczne (sekcja “Sensors not working since Linux 2.6.31”).

Edytujemy plik /etc/default/grub

sudo nano /etc/default/grub

Zmieniamy (albo dodajemy, jeśli jest nieobecna/zakomentowana) linijkę o następującej treści:

GRUB_CMDLINE_LINUX=""

Na docelową:

GRUB_CMDLINE_LINUX="acpi_enforce_resources=lax"

Rekonfigurujemy GRUBa poleceniem:

sudo update-grub

I wreszcie uruchamiamy ponownie system.

sudo reboot

Wreszcie wywołujemy z powodzeniem konfigurację pwmconfig, która pozwali nam kolejno ustalić dopuszczalne wartości minimalne i maksymalne temperatur i prędkości wentylatorów.

sudo pwmconfig

Testujemy konfigurację poleceniem:

sudo fancontrol

Jeśli zadziała, dodajemy komendę “fancontrol” do poleceń uruchamianych wraz z systemem.

Instalacja OwnCloud z użyciem lighttpd i sqlite

OwnCloud, czyli nasz prywatny Dropbox – Malinowe Pi

Przyjemna i prosta solucja do uruchomienia serwera OwnCloud (dlaczego to świetne rozwiązanie?) na słabszym sprzęcie – na przykładzie Raspberry Pi. Uruchamiałem go na apache2 + mysql i mój mini-NAS oparty na terminalu HP T5520 nie dał rady wydajnościowo – teraz spróbuję ponownie.

Edit: Krótka piłka: z lightppd & sqlite i na T5520 jest super. :)

Wingamelauncher, czyli skrypty wspierające automatyczne uruchamianie gier Windows spod Linuksa

Pomiń gadaninę i przejdź do konkretów

Tak się złożyło, że kontynuuję temat zmian “systemowych” (poprzednio przechodziłem na niewspieranego przez Xperię X10 Android 4 ICS) – po raz kolejny w życiu próbuję przenieść cały swój “ekosystem” pod Linuksa.

Zawsze dużo korzystałem z Linuksów, a w ostatnim czasie stan ten osiągnął apogeum. Systemy uniksowe mają sensowną organizację, szybki i sprawny rozwój, wspaniałego basha i tuziny innych rozwiązań (repozytoria, żeby wspomnieć najbardziej bolesny chyba brak), które mnie zdecydowanie przekonują. Doszło do tego, że do większości operacji typu kopie zapasowe, synchronizacja danych, zacząłem pisać skrypty bashowe, uruchamiane w Cygwinie (upraszczając, jest to warstwa tłumacząca polecenia linuksowe na Windows).

Co kilka lat próbowałem przenosić swój ekosystem na Linuksa, ale koniec końców zawsze miałem jakiś krytyczny problem z obsługą swojego sprzętu i mówiłem sobie “kiedyś” – w końcu to “kiedyś” nadeszło.

Zawsze coś…

Nie chcę się skupiać na wszystkich narzędziach, z których korzystam – na to jeszcze będzie czas, próbuję dostosować jakieś IDE pod siebie, przenieść swoje prototypy gier na silniki OpenGL-owe, generalnie jest jeszcze za wcześnie.

Skoncentruję się za to na nieoczywistym rozwiązaniu, które sobie wprowadziłem – tytułowym zestawie skryptów do szybkiego przełączania się pod Windows i automatycznego uruchamiania gier wideo, klikając tylko na skrót w Linuksie.

Dlaczego w ogóle mam taką potrzebę? Nigdy nie jest idealnie – w PC mam kartę graficzną ATI Radeon HD 4850, która po przejęciu przez AMD jest niezbyt wspierana przez producenta, przez co sterowniki działają, powiedzmy, tak sobie – nie mogę grać poprzez WINE z wydajnością, która by mnie satysfakcjonowała.

Rozwiązanie!

Oczywistym jest więc, że przełączam się na Windows w celu rozrywki growej.

Uważam za skrajnie niewygodne konieczność opuszczenia systemu, następnie odczekania kilku minut na możliwość ledwo zalogowania się do Windows, odczekania kolejnej chwili na załadowanie się podstawowych usług, żeby w końcu móc włączyć – ręcznie – wybrany tytuł.

Moje rozwiązanie na pewno nie jest idealne, ale sprawia, że włączenie gry spod Linuksa to wybranie skrótu i odczekanie chwili, po której odpowiednia gra jest uruchomiona i czeka na użytkownika.

Część 1 – Rozbieranie Windows

Niezbędna jest pewna konfiguracja Windowsa – na moim PC stacjonuje Windows 8 z Classic Shell, który pomija ekran startowy.

1. Wyłączyłem konieczność logowania w Windows – niestety jest to niezbędne, aby rozwiązanie było wygodne.

* Wciskamy Win+R, żeby uruchomić menu uruchamiania, wpisujemy “control userpasswords2”;
* W wyświetlonym oknie odznaczamy opcję “Users must enter a user name and password to use this computer” (mam angielskiego windowsa, opcja po polsku opisana będzie podobnie do “użytkownicy musza podać nazwę użytkownika i hasła, by używać tego komputera”).

2. Utworzyłem plik skryptowy wingamelauncher.bat (treść na razie nie jest istotna, może być pusty), utworzyłem do niego skrót i umieściłem go w windowsowym autostarcie.

3. Utworzyłem w tej samej lokalizacji, co wingamelauncher.bat, drugi skrypt – “recreatewgl.bat” o takiej treści:

DEL H:\wingamelauncher.bat
ECHO start calc.exe>H:\wingamelauncher.bat

Oczywiście ścieżkę trzeba zmodyfikować pod swoją lokalizację. Skrypt ten będzie uruchamiany po włączeniu gry, modyfikując wingamelauncher.bat aby nie włączyła się automatycznie ponownie. Zamiast niej będzie odpalony kalkulator – takie tymczasowe rozwiązanie.

Część 2 – Ubieranie Linuksa

1. Tutaj było znacznie więcej zabawy. Zacząłem od zerknięcia do GRUBa, którym wpisem jest u mnie Windows, a którym Linuks – standardowo będzie to wpis trzeci i pierwszy.

Numery te trzeba podać w kolejności od zera – więc 2 i 0.

2. Edytowałem (jako root) plik /etc/default/grub, żeby ustalić zapisywanie ostatniej ładowanej pozycji – by móc je modyfikować z poziomu skryptów.

sudo gedit /etc/default/grub

Zakomentowałem linijkę:

GRUB_DEFAULT="0"

I dodałem inną:

GRUB_DEFAULT="saved"

3. Uwaga, to nie jest ładne rozwiązanie – edytowałem pętle GRUBa 2, aby przywracać domyślne ustawienie po wybraniu innej opcji. Jeśli nie przeszkadza Ci fakt, że po uruchomieniu skryptu domyślnie będzie wybierany Windows, możesz tego rozwiązania nie stosować.

To rozwiązanie ma sporą wadę, m.in. dlatego, że będzie kasowane przez system przy każdej aktualizacji GRUBa – jeśli opracuję inną metodę, to oczywiście polecę.

Otworzyłem plik /boot/grub/grub.cfg:

sudo gedit /boot/grub/grub.cfg

Znalazłem wpisy dla moich systemów (rozpoczynają się od “menuentry”):

menuentry 'Linux Mint 14 Cinnamon 64-bit, 3.5.0-17-generic (/dev/sda8)' --class linuxmint --class gnu-linux --class gnu --class os {
recordfail
gfxmode $linux_gfx_mode
insmod gzio
insmod part_msdos
insmod ext2
set root='hd0,msdos8'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos8 --hint-efi=hd0,msdos8 --hint-baremetal=ahci0,msdos8 e3df731f-6c30-4b10-8088-e7d0311c4102
else
search --no-floppy --fs-uuid --set=root e3df731f-6c30-4b10-8088-e7d0311c4102
fi
linux /boot/vmlinuz-3.5.0-17-generic root=UUID=e3df731f-6c30-4b10-8088-e7d0311c4102 ro quiet splash $vt_handoff
initrd /boot/initrd.img-3.5.0-17-generic

}

Dodałem polecenie “savedefault 0“, które sprawiło, że po wybraniu pozycji, ustawienie będzie zresetowane i następnym razem w GRUBie zostanie wybrana automatycznie pierwsza opcja (z indeksem 0).

menuentry 'Linux Mint 14 Cinnamon 64-bit, 3.5.0-17-generic (/dev/sda8)' --class linuxmint --class gnu-linux --class gnu --class os {
savedefault 0
recordfail
gfxmode $linux_gfx_mode
insmod gzio
insmod part_msdos
insmod ext2
set root='hd0,msdos8'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos8 --hint-efi=hd0,msdos8 --hint-baremetal=ahci0,msdos8 e3df731f-6c30-4b10-8088-e7d0311c4102
else
search --no-floppy --fs-uuid --set=root e3df731f-6c30-4b10-8088-e7d0311c4102
fi
linux /boot/vmlinuz-3.5.0-17-generic root=UUID=e3df731f-6c30-4b10-8088-e7d0311c4102 ro quiet splash $vt_handoff
initrd /boot/initrd.img-3.5.0-17-generic

}

Analogiczną zmianę wykonałem dla wpisu Windows – powinien znajdować się jeden-dwa bloki niżej.

4. Edytowałem uprawnienia dla uruchamianie komend w pliku /etc/sudoers, żeby skrypty mogły uruchamiać się bez zapytania o hasło administratora:

sudo gedit /etc/sudoers

Na końcu pliku, przed komendą “#includedir /etc/sudoers.d”, dodałem następujące wiersze:

draiser ALL=(ALL)NOPASSWD:/usr/bin/wingamelauncher
draiser ALL=(ALL)NOPASSWD:/home/draiser/Skrypty/wingamelauncher.sh
draiser ALL=(ALL)NOPASSWD:/usr/sbin/grub-reboot
draiser ALL = NOPASSWD: /sbin/shutdown
draiser ALL=NOPASSWD: /usr/sbin/s2disk

Gdzie “draiser” to nazwa mojego użytkownika (można podać też “ALL” jako zamiennik dla wszystkich użytkowników), a skrypty podane po “NOPASSWD:” to moje lokalizacje skryptu, który zaraz będę prezentował, dodatkowo także odnośniki do systemowych funkcji rebootu ze zmianą kolejności w GRUB, wyłączania systemu i hibernacji.

5*. Krok opcjonalny – s2disk, czyli hibernacja przed ponownym uruchamianiem

Początkowo napisałem skrypt tak, aby po prostu restartował system, ale oczywiście zdecydowanie wygodniej jest, kiedy zapisuje stan pamięci na dysku, a następnie, już po ponownym włączeniu Linuksa, powraca do niego.

Do tego rozwiązania potrzebna jest partycja SWAP o rozmiarze zbliżonym do ilości pamięci RAM w PC, a także pakiet uswsusp, który instalujemy metodą:

sudo apt-get install uswsusp

Jest on konfigurowany po instalacji (wystarczy podać mu lokalizację partycji swap w formacie /dev/sdXY, np /dev/sda1) i następnie nadaje się do użytku.

6. Napisałem następnie właściwy skrypt, który miał za zadanie utworzyć plik wingamelauncher.bat (usuwając poprzednio istniejący) dla Windowsa, wybrać pozycję w GRUBie na Windows i wreszcie zrestartować system – albo korzystając z hibernacji (patrzy krok 5), albo standardowo.

#!/bin/sh
#wingamelauncher - sh linux part
#by dRaiser
#http://draiser.net
if [ -f /mnt/Multimedia/wingamelauncher.bat ]
then
rm /mnt/Multimedia/wingamelauncher.bat
fi
echo "\"$1\"\r\nrecreatewgl.bat" > /mnt/Multimedia/wingamelauncher.bat
sudo grub-reboot 2
#sudo shutdown -r now
sudo s2disk -P 'shutdown method = reboot'

Potrzebne są w nim 3 modyfikacje – czyli podanie właściwej lokalizacji pliku wingamelauncher.bat z punktu widzenia Linuksa – u mnie to punkt montowania “/mnt/Multimedia”, a następnie, w zależności od wybranej metody rebootu:

1) Dla hibernacji przed rebootem, z użyciem pakietu uswsusp, pozostawienie bez zmian;
2) Dla rozwiązania bez hibernacji – usunięcie albo zakomentowanie znakiem “#” linijki “sudo s2disk(…)”, za to odkomentowanie (usunięcie znaku “#”) linijki “sudo shutdown -r now”.

7. Następnie umieściłem link symboliczny do skryptu w katalogu /usr/bin, żeby był wygodnie uruchamiany z dowolnego miejsca w systemie:

sudo ln -s /home/draiser/Skrypty/wingamelauncher.sh /usr/bin/wingamelauncher

Gdzie “/home/draiser/Skrypty/wingamelauncher.sh” to oczywiście fizyczna lokalizacja zapisanego skryptu.

8. Pozostał w zasadzie tylko ostatni krok, tj. utworzenie aktywatora (skrótu) do uruchamiania konkretnej gry. W każdym środowisku graficznym tworzenie launchera wygląda podobnie, pozwolę sobie więc podać wyłącznie schemat polecenia aktywatora:

wingamelauncher "H:\Program Files\Diablo III\Diablo III\Diablo III.exe"

Gdzie ścieżka podana jako parametr polecenia to fizyczna lokalizacja pliku uruchomieniowego gry – widoczna dla Windows.

Na koniec

Jeśli wszystko poszło poprawnie, to uruchomienie skryptu powinno bezproblemowo zamknąć (albo zahibernować) Linuksa, wybrać w GRUB automatycznie Windows, uruchomić go, zalogować się, włączyć launcher Diablo 3. Słowem – wystarczy wyklikać skrót i zrobić sobie kilkuminutową przerwę, a następnie można już siekać bestie. :)

Niegłupim pomysłem jest odchudzenie Windowsa, żeby uruchamiał się możliwie najszybciej, powyłączanie zbędnych usług, et cetera.

Rozwiązanie powinno działać zarówno pod GRUB, jak i GRUB2; systemami debianopochodnymi, jak i resztą.

Zdaję sobie sprawę, że pewnie całą sprawę można rozwiązać lepiej/prościej – pisałem w bashu zawsze “przy okazji” i dopiero zaczynam bawić się weń na poważniej, ale nie znalazłem gotowego rozwiązania dla tego problemu – może komuś, poza mną, się ono przyda. Oczywiście można w ten sposób uruchomić cokolwiek, nie tylko gry. ;)

Grafika pochodzi z artykułu Blizzard sprawdzi się na Linuksie w 2013.