Ez a bejegyzés a --szopás-- 50 árnyalatát fogja bemutatni, igazi szakmai pornográfia következik.

Munkámból kifolyólag foglalkozom C, C++ / QT, Freepascal, Vhdl programozással és hardver fejlesztéssel, szóval nem unatkozom. Az a mondás is nagyon igaz, hogy minél jobban értesz valamihez, annál nehezebben megoldható problémákkal szembesülsz. ?Murphy?

Szóval "az úgy volt", hogy került hozzám egy X86-os tablet, amit Windowszal és Androiddal árulnak. Igen ám, de én Linuxos arc vagyok és ami tud bootolni egy pendriveról, arra bizony gátlástalanul rakok Linuxot. Így történt ezúttal is, az akkor legújabb Linux Mint Cinnamon (18.3) kiadásával. Prímán ment a tableten, kezelte az érintőképernyőt ahogy kell, a felületet be tudtam állítani tableten kényelmes méretűre, rászabtam a képernyő billentyűzetet, csak hát valami hiányzott, méghozzá a hangja, mert az bizony nem volt...

Hohó mondom itt valami gebasz van, mert Windows alatt megy a hang. Uccu, lássuk mit mond a dmesg, ahol a kernel üzeneteit lehet olvasni.

rt5640 i2c-10EC5640:00: Device with ID register 0x6271 is not rt5640/39
bytcr_rt5640 bytcr_rt5640: ASoC: CODEC DAI rt5640-aif1 not registered
bytcr_rt5640 bytcr_rt5640: devm_snd_soc_register_card failed -517

Szóval az RT5640 az egy, az SOC-be beépített Realtek hangeszköz. Viszont itt azt írja, hogy barátom, ez bizony nem az az eszköz. Ekkor átmentem Windows alá, ahol azt mondta magáról a driver, hogy RT5640-es hangeszközre került telepítésre. Itt lett gyanús a dolog, mivel tényszerűen tudtam, hogy bizony RT5672-es hangeszköz van a tabletben. Na ekkor elkezdtem keresni a google-ben és bizony találtam is hasonló problémát. [link]

A keresésem tovább folytatódott, így eljutottam a Linux kernelig. Valamennyire ismertem már a kernel dolgait, mert egyrészt beágyazott eszközökre fordítottam már kernelt, másrészt pedig nem először fordult elő, hogy valamilyen Windows alatt jelentkező hardverfejlesztési probléma megoldásához bizony a Linux kernelből forrásából, vagy az ahhoz írt patchekből szereztem információt. Nem egyszerű a hardveresek élete na...

A kernel forrását böngészve viszont nem jutottam sokkal előrébb, ekkor gondoltam egy merészet és emailt írtam az ott látott egyik email címre. Így rövid úton eljutottam az Intel egyik Linuxos fejlesztőjéhez, aki számomra meglepő módon nagyon segítőkész volt és elmondta, hogy ez már nem az első ilyen hardver amivel találkoznak, ahol nem megfelelő ACPI azonosító (i2c-10EC5640:00) van beállítva a hardverhez.

Elmondta azt is, hogy Windows alatt csak azért működik a hangeszköz, mert ellentétben a Linuxos driverrel, az nem ellenőrzi a hardvert, hogy ténylegesen az-e, aminek mondja magát. Regiszter szinten azonos lehet a két hangeszköz, így tud működni az RT5672, mint RT5640... Ilyen a véletlenek összecsengése.

Ez egészen idáig sikersztori, de ekkor kezdtem el foglalkozni vele, hogy beleírok a kernel forrásába és csinálok egy quirk-et erre az eszközre, ahogy az a Thinkpad10-nél is szerepel a forrásban. Nos hátőőő először a tableten álltam neki kernelt javítani és fordítani, ennek az volt az oka, hogy az itthoni gépeimen Arch leszármazott disztrók vannak, a tableten pedig Linux Mint ami Ubuntu alapú, az meg Debian leszármazott és ezek nem rokonok... Lehet meg lehetett volna oldani máshogy, de jó volt az így. Mondjuk szegény tabletnek 4-5 órájába telt egy fordítás és nem egyszer szívtam meg, hogy elfogyott a tárhely félúton...
A normál Linux kernel fordításához egy olyan 26GB tárhelyre van szükség, a nyers kernel forrás mérete "mindössze" 840MB körül van, ami szöveges C fájlokból jön össze...

Sikerült alapszinten megoldanom a megfelelő driver betöltését ennél a tabletnél, de valami nem volt az igazi. Egyik bootolásnál jó volt, másiknál nem. Mondom ugyanaz a kód fut le minden alkalommal, olyan nincs, hogy egyszer jó, egyszer nem... Ilyeneket produkált a boot folyamat:

[ 13.415662] rt5640 i2c-10EC5640:00: Device with ID register 0x6271 is not rt5640/39
[ 13.432526] dw_dmac INTL9C60:00: DesignWare DMA Controller, 8 channels
[ 13.454389] rt5645 i2c-10EC5640:00: i2c-10EC5640:00 supply avdd not found, using dummy regulator
[ 13.454457] rt5645 i2c-10EC5640:00: Linked as a consumer to regulator.0
[ 13.454461] rt5645 i2c-10EC5640:00: i2c-10EC5640:00 supply cpvdd not found, using dummy regulator
[ 13.468174] mei_txe 0000:00:1a.0: NFC MEI VERSION: IVN 0x1 Vendor ID 0x1 Type 0x1
...
[ 13.741277] i2c_hid i2c-SMO91D0:00: failed to retrieve report from device.
[ 13.859155] rt5645 i2c-10EC5640:00: Device with ID register 0x6271 is not rt5645 or rt5650

Itt eljutottam arra a pontra, hogy nem tudtam mi a franc van. Ekkoriban segítséget sem igen kaptam, így megakadt a dolog és félretettem 4 hónapig a témát.

Aztán már nem is tudom melyik pirulát vettem be, de Morpheus megmutatta, hogy milyen mély a nyúl ürege... (a fiatalok kedvéért, ez az 1999-es The Matrix ikónikus jelenete. Minden szinkronparódia apja, a hazai "Vektor" pedig itt látható: [link] )

No de visszatérve... Szóval eltelt kb. 4 hónap, engem meg idegesített, hogy itt áll a tablet mellettem és hol szól a hang, hol nem. Mondom nem igaz, hogy nem tudom megoldani... Ekkoriban került egy Pop! OS is a gépre [link], mert kellett egy rendszer, ahol a legfrisebb mesa csomagokat kapom, ami a mostanában egyre könnyebbé váló Linuxos gaminghez elengedhetetlen. No nem is ez a lényeg, de a Pop is Ubuntu alapú, így mindenféle nehézség nélkül tudtam rajta kernelt fordítani a tabletre. Csak mint érdekesség, ami ott a 4 magos Atom procinak 4-5 óra volt, az a Ryzennek 12 szállal 4GHz-en 20..25 perc.
Most ha nagyon advanced arc lennék, akkor a kernel fordítás eredményéül megszületett 3 darab .deb bináris állományt ssh-n keresztül telepítettem volna a tabletre, de ennyire nem értek hozzá (az Inteles kontakt mondta nekem, hogy ott náluk így csinálják a tesztelést), így szépen pendrive segítségével oldottam meg az 1 méter távolság áthidalását. Noooooooob

Átnyergeltem az ekkor célegyenesben lévő 5.1-es kernel forrására, aztán elkezdtem újra kísérletezni a javítással. Rá kellett jönnöm, hogy bizony nem elég csak a driver betöltését helyreraknom, magát a hangeszközt is konfigurálni kell, mert miért ne, tud működni analóg és digitális mikrofonokkal is, a jack csatlakozó bedugását 3 különböző konfigurációban képes érzékelni és így tovább... Ismerve a kapcsolást, azt tudtam, hogy hogyan kellene felépíteni a pin-kiosztás "quirk"-et, csak itt belefutottam abba, hogy ezek a hardvert érintő kódrészletek nincsenek sehol se dokumentálva...

Egy ehhez hasonló [link] patch alatti beszélgetésben találtam meg például azt, hogy a JD_MODE3 jelenti az 1.8V-os vonalra felhúzott jack detect lábat. Ha nincs bent jack csati, akkor 1.8V-on van a láb, ha bent van, akkor meg nullán.

.driver_data = (unsigned long *)(RT5670_DMIC_EN |
+ RT5670_DMIC2_INR |
+ RT5670_DEV_GPIO |
+ RT5670_JD_MODE3),

Mit látni itt? Hogy engedélyezzük a digitális mikrofont, az pedig INR pinre van kötve és 3-as módban van a jack detect. Hogy a GPIO-s sor mit csinál arról semmilyen információt nem sikerült szereznem, de minden ilyen .driver_data résznél amit láttam ott volt, szóval biztos jó az úgy...
Szóval attól, hogy valami nyílt forrású, még nem feltétlen dokumentált a külvilág felé... Ez is ilyen. Persze az is igaz, hogy igazából csak az Intel számára van ezeknek a részeknek jelentősége.

Ezek után már jól állt a helyzet, mert amikor volt hang (és itt az amikor-on van a hangsúly), akkor ment minden. Mikrofon, fejhallgató, hangszórók, minden. Kivéve amikor nem... Most jön a csavar.

Feltűnt, hogy egy hdmi_lpe_audio hangeszköz is hol ott van a hangeszközök között, hol nem. Korábban is volt, de gondoltam, hogy csak az SOC kimenete HDMI porthoz, így nem foglalkoztam vele. Azért itt kicsit keresgéltem a neten, erre találtam is egy rakás hibabejelentést, amikben ezt a cuccot említik. Na mondom WTF van itt, tiltsuk szépen le.
Úgy is tettem, kapott egy blacklistet a etc/modprobe.d fájlban az snd_hdmi_lpe_audio modul, na utána egyből rend lett, minden bootolás gyönyörű trillázással fejeződik be, mintha tíz Sokol rádió zengné az áldást!

Írom a tapasztalataimat az Inteles kollégának, aztán jött a válasz hamar, hogy jah igen, volt egy bug az snd_hdmi_lpe_audio-val a pulseaudioban, de már valamikor 2018 első felében javították. Ekkor fogtam gyanút...
A kernel szintjén a hangeszközt az ALSA kezeli, az eddig említett javítások mind ott történtek. Ez felett lakik a PulesAudio ami sok mindent csinál, bőven többet annál amit mondani tudnék róla. A legújabb Linux Mint volt ekkor a tableten, szépen frissítve, így gondoltam naivan, hogy friss a PulseAudio is... Na persze nem az, természetesen egyel régebbi mint lennie kellene, még 2017-es kiadású, így már a fejlesztés legelső napja óta szopok amiatt, hogy ezt a disztrót raktam fel, valamilyen mondjuk Arch leszármazott, rolling kiadási modellt használó disztró helyett.

Miután ezen PulseAudio dolgon túltettem magam, jött a katarzis, hogy végre kész van a patch és be is lehetne küldeni, mert az Inteles kolléga amúgy is mondta, hogy küldjem el a javításokat és így majd nem kell mindig kézzel kernelt fordítanom magamnak. - Ja, mert elküldeni a javításokat olyan egyszerű. Persze.

Szóval... Hogyan is készül egy patch fájl? Vagy egy diff fájl? Van a régi forrás meg van az új, a kettőből meg lesz egy diff. Vagy patch. Vagy kiscica. Tudta a franc... Honnan is kellett volna tudnom? Ezen a ponton még nem gondoltam, hogy GIT-et [link] kell mindenre használni, szóval a régi és az új fájlokat git --diff paranccsal összehasonlítottam, az meg kiköpte a különbséget egy fájlba.

Oké, tehát van egy fájlom... Hogy kerül az alsa-devel [link] levelezési listára? Egyáltalán mi a tököm az a levelezési lista?

No, hát őőőőő a levelezési lista az egy archaikus valami, amit nem ma találtak ki... Lényegében egy adott formátumú levelet kell rá küldeni, és akkor az bekerül a többi mellé, hozzá lehet szólni meg minden, mindezt emailben.
Itt kaptam egy kis segítséget, miszerint csak kövessem a leírást a témában: [link] - csaknem 900 sor. Itt már éreztem, hogy szopás lesz ebből (is).

Röviden összefoglalva, egy levélnek így kell kinéznie (mbox vagy milyen formátum):

Tárgy mező:
[PATCH] kezdettel, rövid leírással

Szöveg törzs:
Téma leírása
üres sor
Signed-off-by: név + email cím
---
diff --git a/ori/sound/soc/codecs/rt5670.c b/new/sound/soc/codecs/rt5670.c
index 9a03710..37cce04 100644
--- a/ori/sound/soc/codecs/rt5670.c
+++ b/new/sound/soc/codecs/rt5670.c
@@ -1,4 +1,4 @@
-/*
+/*
* rt5670.c -- RT5670 ALSA SoC audio codec driver
*
* Copyright 2014 Realtek Semiconductor Corp.
@@ -2882,6 +2882,18 @@ static const struct dmi_system_id dmi_platform_intel_quirks[] = {
RT5670_DEV_GPIO |
RT5670_JD_MODE3),
},
+ {
+ .callback = rt5670_quirk_cb,
+ .ident = "Aegex 10 tablet (RU2)",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "AEGEX"),
+ DMI_MATCH(DMI_PRODUCT_VERSION, "RU2"),
+ },
+ .driver_data = (unsigned long *)(RT5670_DMIC_EN |
+ RT5670_DMIC2_INR |
+ RT5670_DEV_GPIO |
+ RT5670_JD_MODE3),
+ },
{}
};

Ugye milyen szép így tabulálva? Na nekem nem ilyen lett. Mivel először gmail-ből küldtem sima levélként a cuccot, az ott a copy paste műveletnél a tabulátorokat lecserélte szóközökre... Na meg is lett az eredménye:

> static const struct dmi_system_id byt_table[] = {
> {
> .callback = byt_thinkpad10_quirk_cb,
> @@ -75,6 +82,14 @@ static const struct dmi_system_id byt_table[] = {
> DMI_EXACT_MATCH(DMI_BOARD_NAME, "0E57"),
> },
> },
> + {
> + /* Aegex 10 tablet (RU2) */
> + .callback = byt_aegex10_quirk_cb,
> + .matches = {
> + DMI_MATCH(DMI_SYS_VENDOR, "AEGEX"),
> + DMI_MATCH(DMI_PRODUCT_VERSION, "RU2"),
> + },
> + },

indentation and kernel style?

Ilyen blokkokat kaptam vissza... Az indentation az csipkézést jelent, a kernel style az meg nem olyan mint a gangnam styl rettenet, hanem a tabulátorok használatára figyelmeztet.
Ez az egész szopás szekció azért van, mert bár az Inteles kolléga felajánlotta, hogy beküldi a javításomat, de ugyanakkor a véleménye szerint nekem kellene csinálni mert nem árt ha megtanulom. Én meg hallgattam rá.

No de ekkor kezdtem kiborulni, mert a netes leírások valahogy nem akartak segíteni rajtam, semmi sem úgy működött, ahogy azt én szerettem volna. Ekkor kaptam a tanácsot, hogy a git send-email segítségével kellene patch-et beküldeni, mert akkor az úgy megy be, ahogy kell.

Oké, újabb szopás kör, ugyanis ez GIT-es repositoryt igényel. Ugyan kisebb projekteknél már használtam GIT-et, de ilyesmit még nem csináltam benne, így fogalmam sem volt róla, hogy a módosításaimat egy commit-ba kell foglalni, majd pedig abból a commitból lehet a git format-patch -1 segítségével 0001-akármi.patch fájlt generálni. A -1 itt az 1-es commit ID-t jelenti.

Kicsit furcsálltam ezt a dolgot, mert eleve nem a kernel git repós verzióját szedtem le, hanem annak a .tar tömörített verzióját, mivel az sokkal gyorsabban lejött. (na itt rontottam el, igen, már az elején )

Aztán azért csak-csak meglett a patch fájl, de hogyan küldöm el? Ekkor ugyan megkértem az Inteles kontaktot, hogy segítsen ki és küldje be helyettem, de azt a választ kaptam, hogy csináljam csak meg, hogy megtanuljam.

A git send-email az SMTP-t használ, amit nekem kell konfigurálni [link]. Minden népszerű levelező tud SMTP-t, a gmail is. Csak most éppen egy hónapja nem működik se nekem, se másnak. 1 óra kínlódás után találtam meg az erről árulkodó google hibajegyet, így nekiálltam új email címet regisztrálni...

Amit először találtam az ment volna faszán, de hát náluk az SMTP az fizetős extra, mert miért ne... Szóval ezt gyorsan töröltem is, végül a zohomail lett a befutó.

Node... a .patch fájlok szerkezete MIME sorokkal is el van látva amit legjobb tudomásom szerint ki kell szedni a fájlból. Ekkor kicsit vacakolta a git committal és a patch fájl gyártással, aminek az lett az eredménye, hogy a patch-em V2-es verziójában nem hozzáadott, hanem törölt sorok voltak:

- {
- .callback = rt5670_quirk_cb,
- .ident = "Aegex 10 tablet (RU2)",
- .matches = {
- DMI_MATCH(DMI_SYS_VENDOR, "AEGEX"),
- DMI_MATCH(DMI_PRODUCT_VERSION, "RU2"),
- },
- .driver_data = (unsigned long *)(RT5670_DMIC_EN |
- RT5670_DMIC2_INR |
- RT5670_DEV_GPIO |
- RT5670_JD_MODE3),
- },
{}
};

mert nem vettem észre, hogy egy revert-elt commitból csináltam a patchet. Gyerekek, ezért nem szabad éjszaka levelezési listákra írogatni alvás helyett!

Jól van mondom, most vagy soha... Szépen újrakezdtem az egész patch gyártós részt, normális comittal, kivettem a fájlból a felesleget, majd beküldtem és láss csodát, harmadjára sikerrel jártam! https://patchwork.kernel.org/patch/10970711/

Nem sokkal később már be is került a megfelelő helyre egy git pull-request személyében az 5.2-es kernelhez: https://patchwork.kernel.org/patch/10992225/

Aki jártas ezekben a mailing-list témákban, az nyilván fogta a fejét, hogy mekkora egy nooooooooob vagyok... Jogos persze, de én csak egy egyszerű, Linux-fag villamosmérnök vagyok, honnan kellene ismernem ezeket a vagy rosszul vagy rettentően túldokumentált dolgokat?

Így a végére csak annyit mondanék, hogy megérte. Tanultam egy rakás új dolgot, miközben otthagytam a kezem nyomát valamin, ami minden bizonnyal túl fog élni engem és téged is, és ez jó érzés.

Egy mondattal visszatérve a --szopás-- 50 árnyalatára:
Mi kreáljuk a saját démonjainkat. (by vasember)