A Linux és plug-and-play mindig remek szórakozásra ad lehetőségeket. Vegyük példának a Genius 8x6-os Mousepen rajztáblámm, amit a legtöbb szar, ipari-hulladék, stb. Windows alapból képes kezelni. Szerencsére egy occsó eszközről lévén szó, elég nagy tömegben van jelen, hogy Linuxos driver is legyen hozzá, mit valamilyen oknál fogva a Debian-os gyerekek nem tudtak abszolválni. Talán az lehet az oka, hogy a elsődlegesen Ubuntuhoz lett készítve és emiatt büdös. Engem különösebben nem zavart a dolog, annó dactumnál szépen beforgattam, beírtam pár sort az xorg.conf-ba és örültem. A nyomásérzékenység nem ment ugyan a gimpben, de az én szintemen elég volt a rajzolgatáshoz. Aztán jött egy kis szünet és kicsit leálltam a firkálással. A táblát félretettem, közben volt egy rendszer összeomlás is. Aztán megint viszketni kezdett az ujjam, szóval épp ideje volt újratelepíteni. Lerántottam az új wizardpen drivert, beforgattam belőttem az xorg.confot, aztán néztem mint Rozi a moziban. Se kép, se hang. Log megtúr. Némi nézelődés után rájöttem, hogy valami baja van az ABI számokkal. Ahum, szóval túl régi a X szerver. Az biza, lehet mert holdba van a csomag. Erre megtúrtam forrást, hátha könnyen áttudom ütni, de nem. Valami tökönszúrt GET_ABI_MAJOR makróval szórakozik, ennyi időm meg nincs rá. Mi lenne ha nem foglalkoznánk vele? Nosza, némi google-fu, és már be is került az ignoreABI a szerverflagek mellé. Erre az X dob egy hátast a wizardpen modullal együtt.
Logikus megoldás, hogy akkor frissítünk a rendszeren. Ááááh, azt csak úgy nem lehet, mert az aptitude mindenáron keepelni akarja a csomag állapotát. Az ötödik próbálkozás után feladtam. Nem értem, miért nem képesek csinálni egy "Kurvaanyádfrissítsdleaztaszájbabaszottcsomagotderögtön" gombot. Bizta rosszul tördeli a curses a hosszú, összefüggő sorokat. Ami nem megy aptituddal, megy apt-get-el. Alig egy óra alatt felupgradeltem az egészet, volt némi szívás a cairo-dockkal, de már elmúlt. Így már fekszik a modul.
Ekkor már éjfél elmúlt, én meg ötkor kelek, szóval, nyomtam egy rebootot, csak a biztonság kedvért. Nem kellett volna. A grubbol ugyanis lett egy grub2, és közben az udev megint betette a retkes lábát. Mert ugye, miért is ne lehetne logikusan megadni, hogy 1-es meghajtó,2-es partíció a root, oszt csókolom? Neeem, inkább root="kurvaszájbabaszottszáméskrikszkrakszsorozat". A szerencsétlen kernelem be is pánikolt tőle. Arról nem is beszélve, ha egy kernel paraméter nincs megadva, akkor annak talán oka van, és jó lenne migrálásnál békén hagyni, nem? Kiütöttem a szemetet a grubból, újraindítom a gépet. Szupi, megy minden, csak a tablet kivágja a bal felső sarokba a kurzort. Mindegy, alvás.
Napközben kicsit rágooglézek a problémára. A különféle bejegyzések alapján a szokásos, ahogy kell, ami logikus és működőképes volt azt csesszük szét és öntsük nyakon udev-el történet. Annyi kiderült, hogy a hiba oka mindig az eszköz automatikus felismerésével volt. Csakhogy, nekem kézzel be lett betonozva az xorg.conf-ba a beállítások. Kicsit molyolok a HAL és udev configokkal, de egyik sem segít. Mi lenne, ha kilőnénk az egész genyó autokonfigos szarakodást? Nosza, szerverflagsba megy is az AutoAddDevices false. X újraindít. Áhhh, megtaláltam az config orosz rulettjét. Ergó, ami kézzel volt rendesen konfigolva az ment, ami meg nem, hát az nem. Természetesen mi nem megy? A patkány és a billentyűzet. Tuti. Kíváncsi vagyok, mennyit agyalhattak rajta, hogy kitalálják ezt a szopatást.
Működő gépet, ugye nem indítunk újra, ezért gondoltam be ssh-zok a budiszerverről. Aham, csak ssh-znék, mert az aptitude vitte magával, mert az is holdon volt, és a x-szerver frissítési küzdelemben remove-ra került. Mondtam már, hogy imádom a GUI-s eszközöket? FTP-n keresztül meg nincs root, és ez így helyes.
Ekkor kezdtem kissé inkonzisztensen gondolkodni, de annyi még élt, hogy nálam alap: amin soros port van, azon fut soros terminál is. Nosza, soroskábel, laptop, termiál, login, nano, save, X újraindít. Jahm kérem, a soros port, az soros port... Még jó, hogy a soros login nem disztribből került fel a gépre. Hogy miért nem initd-n keresztül oldotam meg, az örök titok marad.
A probléma viszont továbbra is fennáll. Kurzor megy a bal felső sarokba.
Ismét belenézek a logba és lőn megvilágosodás:
Az X bekonfigolja a xorg.conf alapján a tabletet, aztán fogja magát és az udev alapján is bekonfigolja a tabletet. Az, hogy az etc/udev-ben ott figyelnek a szabályok, hogy miképp konfigolja, azt természetesen magasról leszarja. Kicsit nekiálltam az új xorg verzió doksiját olvasgatni, ahol némi feszültséget éreztem a szerzők és az udev közt, és bekerült egy opció, ami adott eszköz osztályoknál és eventeknél figyelmen kívül lehet hagyatni az udevet. Nosza.
Section "InputClass"
Identifier "evdev pointer catchall"
MatchIsPointer "on"
MatchDevicePath "/dev/input/event2"
Driver "evdev"
Option "Ignore" "On"
EndSection
X újraindít, és máris megy a tablet.
Felteszem a kérdést, hogy
a, miaretkeslófasznak vannak udev szabályok, ha sem az udev, sem az X nem veszi őket figyelembe?
b, miért kell egy adott eszközt 2 különálló rendszerben konfigurálni, hogy ne működjön egy harmadik alatt?
c, ha egy eszköz meg van adva konfig fileban és nincs hibajelenség, akkor miaretkeslófasznak próbálja az X ugyanazt az eszközt udev alapján konfigolni?
d, miért nincs valamilyen failsafe megoldás a konfigurációs hibákból adódó kizárások elkerülésére?
