Triple monitor fun

I’ve finished another of my PC plans and upgraded to triple monitors. It was a big change for me – in the first few moments I wasn’t even sure if I’m going to get used to it, but soon I’ve started to love it. Much more (separated – and that’s good!) space for windows/terminals which I use a lot and a fantastic new way of more immersive gaming. It’s also much more appealing in terms of aesthetics. FYI I was using 2 24″ monitors before.

Obviously, my configuration couldn’t be standard, so let’s talk about quirks & tweaks.

I’m using 3 monitors with both Arch Linux host (GeForce 9800 GTX+) and Windows 7 gaming VM (GeForce GTX 960). To achieve comfortable change between those, I use HDMI switches placed under desk. Works great so far.

Monitors are mounted on a triple monitor stand. It was very difficult to find a good one. I was thinking about buying popular Ergotech one, but decided to try and buy less expensive (especially with shipping to Poland) and fairly new one from Duronic. I’m very happy with it in general, but it’s sturdy and hard to line up and level monitors perfectly, yet I’m almost there.

My 9800 GTX+ has only two outputs so to get all 3 screens working I need to use one output built-in onto motherboard GPU. Nvidia does all the rendering, Intel’s output is used only as transport route. I’ve needed to switch to Nouveau as it doesn’t work for me at all on Nvidia binary driver.

Script to turn on 3 monitors:

xrandr --setprovideroutputsource 1 0
xrandr --auto
xrandr --output HDMI3 --right-of DVI-I-1
xrandr --output DVI-I-2 --left-of DVI-I-1

I also utilize 3 monitors on Gaming VM – it’s working very well after enabling Surround in Nvidia GPU options. So far I’ve tested Witcher 3, Fallout New Vegas, Torchlight etc. and it’s marvelous!

There is also one non-trival advantage when using one system for 3-monitor-spanned gaming and another one for 3-monitor-no-spanned working. Switching between Surround/Eyefinity (spanning) would shuffle windows & icons when changed – doesn’t happen here.

Overall, it was new big thing for me and I’m very happy to have it. I’m definitely not crazy about ultra-wide monitors – these are too small for workplace (about size of 2 monitors) and would be very inefficient because of lack of angle if bigger, I hate the idea of curved ones, so there is really nothing better on market for me.

OQVEes5DaN-rMefsqEaIQg98eFXStf4zqTBouIhJArM=w1874-h928-noEdit: I forgot to add info about monitors used. So, there’s one BenQ G2450 in middle and BenQ GL2450 on sides (LED lighting). G2450 wasn’t accessible when I was ordering side monitors, so they have slightly different contrast/color, but are close enought to be good. These are nice for gaming (low/close to none input lag) and are *matte* which is omg-so big deal.

Ignoring hotplug monitor events on Arch Linux

Automatic hotplug event handling can be a problem, eg. when its run for monitors. I use HDMI splitter between my host OS and gaming VM and I didn’t like that my windows were all over the place when I’ve used it.

There are few ways to disable those (but still to be able to run them manually when needed!), but I’ve found only one method is able to run for all GPU drivers.

Most obvious method is xorg setting “UseHotplugEvents”. It’s great, but works only for Nvidia binary driver.

Section "Monitor"
# HorizSync source: edid, VertRefresh source: edid
Identifier "Monitor0"
VendorName "Unknown"
ModelName "BenQ G2450"
HorizSync 30.0 - 83.0
VertRefresh 50.0 - 76.0
Option "UseHotplugEvents" "False"
EndSection

There is also similar setting but in this case, for Intel driver only.

Aside of both of that, there may be need to disable automatic xrandr events in your DE.
Cinnamon:
gsettings set org.cinnamon.settings-daemon.plugins.xrandr active false
Gnome:
gsettings set org.gnome.settings-daemon.plugins.xrandr active false

About this independent one (I use it with Nouveau) – option is to disable udev completely (for a while). That means that it also won’t work for dynamic USB devices, etc. But it’s good enough if you need to disable monitor discovery for a moment and can turn it on later again.

sudo udevadm control --stop

sudo udevadm control --start

KVM/QEMU Gaming Machine

I’m using Linux as my main OS for some time now and I’m almost perfectly happy about it. Why almost? Because I’m a gamer and I don’t like compromises. So even if I totally support Linux-gaming revolution which Steam/Valve brought I won’t quit playing games which I’d like to play just because they don’t have Linux version. I was WINE using a lot, but it still didn’t support a lot of my games.

For some time I dual-booted with Windows. It was very irritating, because it forced me to close all my opened software, wait to shutdown first OS, wait to boot my computer and then start second OS… It was so irritating that when I bought notebook capable of ‘so-so’ running games, I connected it to the second input of my main monitor and played games like Diablo 3 on it (running Synergy for comfort).

That, of course, wasn’t best solution – two machines running instead of one and also my laptop’s GPU is way worse then my desktop one (no surprise). However I haven’t figured out better way until I found some info about VGA Passthrough.

That magic solution was my remaining piece – with help of KVM and Qemu, it allows to create virtual machine with its own, fully accessible graphic card. Passing CPU power and memory wasn’t problem for VMs for years but for PCI devices such as GPU it’s kinda revolution.

How does it work exactly? I’ve got two graphic cards, but I’m not using SLI neither Crossfire – my Arch Linux (primary OS) only sees GeForce 9800 GTX+ card and it’s using it exclusively. Second GPU – AMD Radeon 4850 in my case – is visible only for virtual machine with Windows and is available only for it – which means it’s properly detected by AMD drivers without any performance drops which happens when GPU’s emulated.

I’ve not actually ran any benchmarks, because it works just great. When I installed Diablo 3 and it just flew on high settings, I knew that’s exactly the solution I was looking for. Some other games I tested, like Disciples 3 or Assassin’s Creed 3 (which is rather GPU-heavy) also run with no difference than on the Windows-only system.

Instalation wasn’t pretty and it forced me to compile kernel with custom patches for Linux, add few kernel parameters into GRUB, some script-fiddling and also I was fighting for while to use nvidia proprietary driver instead of open-source one. On the other hand, I used virt-manager tool to configure VM and it was very nice and easy to use. Just set-up how much CPU cores and memory I want to add, create file image for disk, few more click to passthrough some devices like mouse, keyboard, integrated sound and GPU obviously – then it’s ready.

Zrzut ekranu z 2014-11-22 23:47:28The only really painful thing about this technology is required hardware. It requires VT-x (or AMD-V on AMD processors) which are quite common CPU extensions, but also VT-D (or IOMMU), which are not. It’s easy to check which Intel chips have them (sad thing for powergamers – almost none with overlocking abilities), but it’s very hard to find motherboards which must also support both of them. It’s so risky business that people are making lists of working hardware.

I went with AsRock Z77 Extreme4 motherboard and Core i5 3550 CPU, which both were confirmed few times to work with VGA Passthrough and I can say that it was very good decision. They aren’t so pricey, yet I like them both very much already. :) I gave 2 of 4 cores and 3 of my 8 GiBs RAM to VM, but I’m going to buy another 4 GiBs and give it exclusively for VM(s). I’m also going to change Radeon 4850 for some more powerful, eyefinity-capable GPU in next year. I’ll also setup “Lintendo” gaming VM (propably with SteamOS) so I don’t need to change both GPUs. ;)

What can I say more? I highly suggest all Linux-loving gamers to take a look at this technology and build it for yourself if you’re tech-savy enough – it took me about 1,5 days to set this up, but a lot of work was done thanks to excellent creators of guides which I link below.

Guides and other helpful links:

PCI passthrough via OVMF [Arch]

KVM VGA-Passthrough using the new vfio-vga support in kernel =>3.9 [Arch]

{Guide} Create a Gaming Virtual Machine [Fedora]

HOW-TO make dual-boot obsolete using XEN VGA passthrough [Linux Mint]

Network adapter configuration for KVM / Xen on Arch

VT-D How-To [Xen Wiki]

VFIO tips and tricks [excellent blog – start with their FAQ]

Some tips from me:

  • There’s big “battle” between Xen and KVM/Qemu – I was going to start with Xen, but it lost compatibility with Nvidia blob driver some time ago.
  • Don’t give up when Radeon GPU is passed through and it gives “Code 43” error with Microsoft’s default drivers – just install AMD one and you’re set! Lost some hours when trying to fix non-existing issue.
  • It’s rather obvious to me now, but it’s needed to use DKMS on self-compiled kernels for Nvidia driver.
  • Virt-manager has good VNC viewer built-in which is helpful especially when you’re configuring input devices.
  • Synergy’s great for optimising number of input devices in that setup, but it had some weird behaviour when cursor was passed from Linux host to Windows guest – now I passthrough USB mouse and KB, then I run Synergy server on virtual machine to control Linux on other then center monitors.
    Just use “relative mouse movement” and “lock cursor to screen” in Synergy, works excellent.

How to pause & restore application with keyboard shortcut in Linux

Small thing, but very useful IMO – using these two easy script, it’s possible to pause and then unpause currently selected application with keystroke.

To me it’s often the case that I want have some program to be available the second I want it, but unfortunatelly it’s eating a lot of CPU and blocking another programs, which I actually use in the moment. So, I’ve created scripts to make this program available and ready for me, but cost only some RAM.

Use carefully – it can also pause you DE. :)

pause_current_app.sh

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

active_window_id=$(xdotool getactivewindow)
active_window_pid=$(xdotool getwindowpid "$active_window_id")
kill -n 19 $active_window_pid

unpause_current_app.sh

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

active_window_id=$(xdotool getactivewindow)
active_window_pid=$(xdotool getwindowpid "$active_window_id")
kill -n 18 $active_window_pid

Save those scripts in some location (eg. ~/Scripts), make them executable by chmod +x filename and create a keyboard shortcut in keyboard settings of you DE (if you don’t use DE, I suppose you don’t need this tutorial).

In Cinnamon it looks like this:

pause_1 pause2

To not pause by mistake, I used ctrl+pause/break key for pausing and pause/break for restoring application (it does nothing when app’s not paused).

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. :)