Hozzászólások
-
Bejegyzés
-
Mindig csak a kernel verzióhoz írt patch-et használd mert nem fog mûködni! Ez nagyon fontos!!!!
Egyébként az a baj, hogy fordítva közelíted meg a dolgot.
A normális az lenne, hogy „mit akarok, milyen hw-em van” -> „benne van a kernelemben” -> „ha nincs betenni”.
Elképzelhetõ, hogy nem is kell patch…A kernel pachelésrõl itt olvashatsz, ráadásul magyarul (sõt patch elérések is vannak, és a website-ok linkjei is, amin le van írva, hogy mire való)
http://www.hup.hu/wiki/index.php/Linux_kernel_patchelés
[align=right][snapback]148306[/snapback][/align]Helló Vizsla!
Igazad van, kicsit rosszul közelítettem meg a problémámat. Megpróbálom összefoglalni:
– Tehát adott egy újonnan feltelepített UHU 1.2 rendszer, amelynek 2.6.9-19-es kernele, a kernel-headers és a kernel-source fájlok az UHU ftp szerverérõl lettek frissítve 2.6.9-21-re.– A frissen telepített rendszer nem ad vissza keycode-ot a 16 db multimédiás billentyûbõl 6 db. lenyomására.
Ugyanez nem jelentkezett gondként a korábbi UHU 1.1-ben.– Hosszas vizsgálódás eredményeként kiderült, hogy a billentyûkhöz keycode-ot rendelõ setkeycodes parancsra és annak párjára, a getkeycodes parancsra a rendszer az alábbi hibaüzenetekkel reagál:
a getkeycodes-re:
„KDGETKEYCODE: Nem létezõ eszköz
failed to get keycode for scancode 0x59
0x58: 88″a setkeycodes xx yyy-ra:
„KDSETKEYCODE: Nem létezõ eszköz
failed to set scancode xx for keycode yy– Sikerült kideríteni, hogy egy újonnan fordított 2.6.12-5-ös „vanilla” kernellel bootolva a fenti hiba nem jelentkezik, mûködik a getkeycodes és a setkeycodes parancs, a 6 db, keycode-al nem rendelkezõ billentyûkhöz a setkeycodes paranccsal hozzá lehet rendelni keycode-ot, ezt követõen minden multimédiás billentyû látható.
– Fentiek alapján az a következtetés alakult ki, hogy a 2.6.9-19(21)-es kernelben van a hiba. Ezzel párhuzamosan az is kiderült, hogy a fenti problémát nem okozó 2.6.12-5-ös kernelbe viszont nincs beforgatva a supermount, ami viszont a 2.6.9-19(21)-es kernellel jól mûködik.
– Itt választás elé kerültem:
a.) vagy megpatch-elem a 2.6.12-5-ös kernelt a supermount patch-el, és utána fordítok egy 2.6.12-5-ös kernelt supermount támogatással; vagy
b.) megpróbálom megpatch-elni a régi, 2.6.9-19(21)-es kernelt egy olyan patch-el, amelyik a getkeycodes és setkeycodes parancsokra nem ad hibaüzenetet.Nos, számomra könnyebbnek tûnt az a.) változat választása, hiszen a 2.6.12-5-ös kernelt már sikerült lefordítani. Nem jött be, a patch-elés sikerült (a https://svn.uhulinux.hu/packages/1.2/kernel/patches/30-fs könyvtárból letöltött supermount patch-el), azonban patch-elés után a kernelfordítás egy idõ után hibaüzenettel megszakad. Ahogy korábban írtam, én nem vagyok linux-guru, nem tudok mit kezdeni a hibaüzenetekkel, csak a végeredmény érthetõ: Error!
A b.) változat szimpatikusabb, hiszen itt csak olyan foltot kellene találni, ami a szóban forgó hibaüzenetet okozza, azt a kernelrészt meg kellene patch-elni, majd újraforgatni a 2.6.9-19(21)-es kernelt, amelyhez végül is az egész UHU 1.2 igazítva lett.
Nos, ez sem sikerült, a fentebb megjelölt címen egyik patch gyûjtõkönyvtárban sem találtam olyan patch-et, amely a billentyûzettel lenne kapcsolatos (legalábbis az én tudásom szerint).
Erre c.) megoldásként megpróbáltam a 2.6.9-19(21)-os kernelt a kernel.org-ról letöltött (http://www.kernel.org/pub/linux/kernel/v2.6/patch-2.6.12.gz) full patch-al megfoltozni, hogy 2.6.12-es legyen belõle. Ez sem jött be, a foltozás során rengeteg hibaüzenet keletkezik, és már a make menuconfig sem indul el.” Azóta már teljesen eltávolítottam a 2.6.12-5-ös kernel könyvtárát,”
Nézz rá az /usr/include könytárban a linkek hova mutatnak!
Ha a fent emlitett könyvtárba akkor nem is csoda hogy nem talélja!
Az /usr/include könytárat jobb nem piszkálni. 🙂
Amit vizsla is említett velem is elõfordult gentoo alatt,
csak az aktuális kernel forrásába linkeléssel sikerült megoldani, hogy a fordítás menjen.
[align=right][snapback]148188[/snapback][/align]Esetleg még próbálkozz CD-rõl újra pakolni amit leszedtél
dpkg -i /ahol_/a csomag_van/csomagnév.uhu
Nekem még anno uhu1.0 alatt volt, hogy manuálba nem szándékosan letöröltem a bzImage-t.supermount-2.0.4-2.6.3.patch.gz
2.6.12-05„a teljesen újratelepített, frissített kernel forrásának könyvtárában /usr/src/linux/ alatt az /include könyvtárban érintetlenül megvan minden, hiszen ez újonnan települt, még érintetlen, mert egyáltalán nem indul a make menuconfig.”
Nem, azzal, hogy eltávolítottad a kernel headereket pont ezeket távolítottad el, amiket hiányol.alatt az /usr/include/linux könyvtárban keresi a fcntl.h nevû filet
vagy a /usr/src/linux/include/asm könyvtárban (ez talán valószínûbb, hiszen ez a sajátja)
csinálj egy linket és menni fog – valami miatt nem tudja, hogy intel 386 kompatibilis – nekem még nem fordult elõ, de már sokaknak igen (bizonyára a headerek eltávolítása miatt)
(most, ha zsaru lennék azt mondanám: „Higgy nekem, hisz zsaru vagyok!” :)))
[align=right][snapback]148133[/snapback][/align]Helló Vizsla!
Hiszen írtam, hogy ma ismét letöltöttem az UHU ftp szerverérõl a 2.6.9-21-es kernelt, annak headers és source csomagjait is, és újratelepítettem mindhármat. Tehát az elõzõleg kiürített /usr/src könyvtárba a Synaptic ismét betette az éppen csak letöltött szûz kernel csomagokat (mindhármat.). Hogy biztos legyek a dolgomban, még a lemezeket is kiszedtem, nehogy véletlenül a nem frissített kernelcsomagok települjenek, hanem a /var/cache/apt/archives könyvtárból történt a telepítés. Ez tehát egy teljesen új csomagtelepítés. A /usr/src/linux/include könyvtárban pedig az asm link az asm-i386-ra mutat. A hibaüzenetek sorait is átnéztem, de az általad példaként felhozott fcntl.h is megtalálható mind az include/linux, mind a /include/asm-i386 könyvtárban. De ugyanígy megvannak a hibaüzenetben hivatkozott
scripts/basic/fixdep.c:105:23: sys/types.h: Nem létezõ fájl vagy könyvtár
scripts/basic/fixdep.c:106:22: sys/stat.h: Nem létezõ fájl vagy könyvtár
scripts/basic/fixdep.c:107:22: sys/mman.h: Nem létezõ fájl vagy könyvtár, stb. sorok is a helyükön.
Azt nem tudom, hogy a fixdep.c-ben alkalmazott szintaktika helyes-e.
Részlet:
#include
#include
#include , stb. Azt viszont nem tudom, hogy amiket be kell include-olni, azok hol találhatók.
Nem ellenõriztem végig a hibaüzenet összes sorát, de szerintem minden a helyén van. Hogy mégsem ismeri fel a fixdep script a dolgokat, annak talán az lehet az oka, hogy az adott programnyelv interpreter-je hibás, de én azt sem ttudom, hogy melyik az.Tehát szerintem nem a kernelforrás és a header csomag a hibás, mert az fent van, méghozzá frissiben.
„Az UHU Linux levelezõ listán Koblinger Egmont azt a tájékoztatást adta, hogy az UHU 1.2-höz járó eredeti kernel legalább 200 féle patch-el meg lett foltozva. Nos, én erre nem vállalkozhatok”
De mi a fenének is?
Azt kell használni, ami neked kell… az uhu-nak 5 millió különbözõ hw konfiguráción kell mûködni, a tiédnek meg 1-en.
csinálj egy asm nevû linket a linux/include/asm-i386-ra (ha ez egy 32 bites intel kompatibilis processzor)
esetleg a /usr/include/linux könyvtár lett eltávolítva (vagy üres, vagy rossz link)valamelyik a kettõ közül
[align=right][snapback]148105[/snapback][/align]Helló Vizsla!
Az elsõ észrevételem arra vonatkozott, hogy úgy látszik, az Egmont nem tudta megmondani, melyik patch felelõs a /media használatáért, melyik a supermount lehetõségért, stb.
[align=right][snapback]147911[/snapback][/align]
Az UHU Linux levelezõ listán Koblinger Egmont azt a tájékoztatást adta, hogy az UHU 1.2-höz járó eredeti kernel legalább 200 féle patch-el meg lett foltozva. Nos, én erre nem vállalkozhatok a 2.6.12-5-ös kernellel kapcsolatban, inkább visszatértem az eredeti kernelhez. Azonban a fordítgatások során történhetett valami, mert eddig mindig el tudtam indítani a make menuconfig-ot, bármelyik kernelt akartam fordítani. Viszont a 2.6.12-5-ös kernel fordítása és kipróbálása során semmi olyat nem tettem, amivel a lenti hibaüzenetek generálását kiválthattam volna.
Hogy biztos legyek a dolgomban, ma ismét letöltöttem és újratelepítettem a teljes frissített kernelt, forrását és headert, de a helyzet nem változott, a make menuconfig nem indul el. Mi ilyenkor a teendõ?fantan
Tehát a make menuconfig (vagy config vagy xconfig) hibaüzenetei:
root:/usr/src/linux# make menuconfig
HOSTCC scripts/basic/fixdep
scripts/basic/fixdep.c:105:23: sys/types.h: Nem létezõ fájl vagy
könyvtár
scripts/basic/fixdep.c:106:22: sys/stat.h: Nem létezõ fájl vagy könyvtár
scripts/basic/fixdep.c:107:22: sys/mman.h: Nem létezõ fájl vagy könyvtár
scripts/basic/fixdep.c:108:20: unistd.h: Nem létezõ fájl vagy könyvtár
scripts/basic/fixdep.c:109:19: fcntl.h: Nem létezõ fájl vagy könyvtár
scripts/basic/fixdep.c:110:20: string.h: Nem létezõ fájl vagy könyvtár
scripts/basic/fixdep.c:111:20: stdlib.h: Nem létezõ fájl vagy könyvtár
scripts/basic/fixdep.c:112:19: stdio.h: Nem létezõ fájl vagy könyvtár
In file included
from /usr/lib/gcc-lib/i586-uhu-linux/3.3.4/include/syslimits.h: 7,
from /usr/lib/gcc-lib/i586-uhu-linux/3.3.4/include/limits.h:11,
from scripts/basic/fixdep.c:113:
/usr/lib/gcc-lib/i586-uhu-linux/3.3.4/include/limits.h:122:75: limits.h:
Nem lét ezõ fájl vagy könyvtár
scripts/basic/fixdep.c:114:19: ctype.h: Nem létezõ fájl vagy könyvtár
scripts/basic/fixdep.c:115:23: arpa/inet.h: Nem létezõ fájl vagy
könyvtár
scripts/basic/fixdep.c: In function `usage’:
scripts/basic/fixdep.c:129: warning: implicit declaration of function
`fprintf’
scripts/basic/fixdep.c:129: error: `stderr’ undeclared (first use in
this functi on)
scripts/basic/fixdep.c:129: error: (Each undeclared identifier is
reported only once
scripts/basic/fixdep.c:129: error: for each function it appears in.)
scripts/basic/fixdep.c:130: warning: implicit declaration of function
`exit’
scripts/basic/fixdep.c: In function `print_cmdline’:
scripts/basic/fixdep.c:135: warning: implicit declaration of function
`printf’
scripts/basic/fixdep.c: At top level:
scripts/basic/fixdep.c:138: error: `NULL’ undeclared here (not in a
function)
scripts/basic/fixdep.c: In function `grow_config’:
scripts/basic/fixdep.c:151: warning: implicit declaration of function
`realloc’
scripts/basic/fixdep.c:151: warning: assignment makes pointer from
integer witho ut a cast
scripts/basic/fixdep.c:152: error: `NULL’ undeclared (first use in this
function )
scripts/basic/fixdep.c:153: warning: implicit declaration of function
`perror’
scripts/basic/fixdep.c: In function `is_defined_config’:
scripts/basic/fixdep.c:169: warning: implicit declaration of function
`memcmp’
scripts/basic/fixdep.c: In function `define_config’:
scripts/basic/fixdep.c:182: warning: implicit declaration of function
`memcpy’
scripts/basic/fixdep.c: In function `use_config’:
scripts/basic/fixdep.c:201: error: `PATH_MAX’ undeclared (first use in
this func tion)
scripts/basic/fixdep.c:215: warning: implicit declaration of function
`tolower’
scripts/basic/fixdep.c:201: warning: unused variable `s’
scripts/basic/fixdep.c: At top level:
scripts/basic/fixdep.c:220: error: parse error before „size_t”
scripts/basic/fixdep.c:221: warning: function declaration isn’t a
prototype
scripts/basic/fixdep.c: In function `parse_config_file’:
scripts/basic/fixdep.c:222: error: `map’ undeclared (first use in this
function)
scripts/basic/fixdep.c:222: error: `len’ undeclared (first use in this
function)
scripts/basic/fixdep.c:228: warning: implicit declaration of function
`ntohl’
scripts/basic/fixdep.c:239: warning: implicit declaration of function
`isalnum’
scripts/basic/fixdep.c: In function `strrcmp’:
scripts/basic/fixdep.c:252: warning: implicit declaration of function
`strlen’
scripts/basic/fixdep.c: In function `do_config_file’:
scripts/basic/fixdep.c:263: error: storage size of `st’ isn’t known
scripts/basic/fixdep.c:267: warning: implicit declaration of function
`open’
scripts/basic/fixdep.c:267: error: `O_RDONLY’ undeclared (first use in
this func tion)
scripts/basic/fixdep.c:269: error: `stderr’ undeclared (first use in
this functi on)
scripts/basic/fixdep.c:273: warning: implicit declaration of function
`fstat’
scripts/basic/fixdep.c:275: warning: implicit declaration of function
`close’
scripts/basic/fixdep.c:278: warning: implicit declaration of function
`mmap’
scripts/basic/fixdep.c:278: error: `NULL’ undeclared (first use in this
function )
scripts/basic/fixdep.c:278: error: `PROT_READ’ undeclared (first use in
this fun ction)
scripts/basic/fixdep.c:278: error: `MAP_PRIVATE’ undeclared (first use
in this f unction)
scripts/basic/fixdep.c:278: warning: assignment makes pointer from
integer witho ut a cast
scripts/basic/fixdep.c:287: warning: implicit declaration of function
`munmap’
scripts/basic/fixdep.c:263: warning: unused variable `st’
scripts/basic/fixdep.c: At top level:
scripts/basic/fixdep.c:292: error: parse error before „size_t”
scripts/basic/fixdep.c:293: warning: function declaration isn’t a
prototype
scripts/basic/fixdep.c: In function `parse_dep_file’:
scripts/basic/fixdep.c:294: error: `map’ undeclared (first use in this
function)
scripts/basic/fixdep.c:295: error: `len’ undeclared (first use in this
function)
scripts/basic/fixdep.c:297: error: `PATH_MAX’ undeclared (first use in
this func tion)
scripts/basic/fixdep.c:299: warning: implicit declaration of function
`strchr’
scripts/basic/fixdep.c:301: error: `stderr’ undeclared (first use in
this functi on)
scripts/basic/fixdep.c:297: warning: unused variable `s’
scripts/basic/fixdep.c: In function `print_deps’:
scripts/basic/fixdep.c:334: error: storage size of `st’ isn’t known
scripts/basic/fixdep.c:338: error: `O_RDONLY’ undeclared (first use in
this func tion)
scripts/basic/fixdep.c:340: error: `stderr’ undeclared (first use in
this functi on)
scripts/basic/fixdep.c:350: error: `NULL’ undeclared (first use in this
function )
scripts/basic/fixdep.c:350: error: `PROT_READ’ undeclared (first use in
this fun ction)
scripts/basic/fixdep.c:350: error: `MAP_PRIVATE’ undeclared (first use
in this f unction)
scripts/basic/fixdep.c:350: warning: assignment makes pointer from
integer witho ut a cast
scripts/basic/fixdep.c:334: warning: unused variable `st’
scripts/basic/fixdep.c: In function `traps’:
scripts/basic/fixdep.c:369: error: `stderr’ undeclared (first use in
this functi on)
make[1]: *** [scripts/basic/fixdep] Error 1
make: *** [scripts_basic] Error 2„KDGETKEYCODE: Nem létezõ eszköz
failed to get keycode for scancode 0x59
0x58: 88″
Hát ott valami más gond van, mert azt írja, hogy „Nem létezõ eszköz”…
Keres rá a neten a KDGETKEYCODE: no such device, vagy a KDGETKEYCODE: unknown device kifejezésekre… valamelyik bejön, nem tudom hogy van angolul; ha angolul írta, akkor úgy.
[align=right][snapback]147723[/snapback][/align]Helló Vizsla!
Hosszas kínlódás után mára sikerült UHU 1.2 alatt leforgatnom a 2.6.12-5-ös „vanilla” kernelt, ami a fordítást követõen bootoláskor hibaüzenet nélkül lefut, legalábbis nem íródik ki egyetlen egy hibaüzenet sem,
a /var/log alatti logfájlokat átnézve sem találtam olyan bejegyzést, ami hibára utalna (az én szerény tudásom szerint).
Elindul a hang, elindul az adsl kapcsolat, ki tudok menni az Internetre, elindul az X is, elsõ ránézésre minden lényeges dolog elindul. Azonban van több érdekes hiányosság is, amelyekbõl most néhányban kérnék segítséget:Elõtte azonban annyit, ezzel az új kernellel sem láthatók az érintett multimédiás billentyûk – megjegyzem, a többi MM billentyû kódja is más, mint az eredeti kernel esetén -, azonban legalább midenyik kódját le lehet kérdezni, rá lehet definiálni keycode-kat (ezt meg is csináltam úgy, hogy a /etc/rc.boot könyvtárba elhelyeztem egy utolsóként lefutó szkriptet, ami bootoláskor beállítja a szükséges kódokat, ezeket aztán X alatt az xbindkeys-el be tudtam állítani saját igényeim szerint [mind a 16-ot]).
Ami az alábbi hibát illeti:
„KDGETKEYCODE: Nem létezõ eszköz
failed to get keycode for scancode 0x59
0x58: 88″, ez az új kernellel megszûnt, a getkeycodes paranccsal szépen le lehet kérdezni a keycode táblát, ezt fel is használtam a keycode-ok hozzárendeléséhez.Tehát a kérdések:
1.Mivel az x nyers kóddal dolgozik elképzelhetõ, hogy x alatt mégis fog mûködni, ami konzolból nem…
Ezt a sort rakd be az /etc/X11/xorg.conf vagy /etc/XF86Config file Section „imputdevice” indentifier „keyboard” szekcióba:
Option „XkbModel” „geniuscomfy”Majd indítsd újra az x-et… talán mûködik.
Vagy egy grafikus megoldás:
http://lineak.sourceforge.net
(A KWD-910-as benne van :))Vagy van gnome-hoz (ha azt használsz) egy másik megoldás:
http://devin.com/acme/Elvileg mindhárom bejöhet (az elsõnek talán kisebb a valószínûsége)
A kernellel meg ha nem muszáj, akkor ne kínlódj… egyébként, ha a hibákat beírod, vagy a hw-t, akkor abban is segítünk.
[align=right][snapback]147532[/snapback][/align]Helló Vizsla!
Amint a legelsõ levelemben írtam, jelenleg UHU 1.2 Rajt!-ot használok, ezzel szeretnék legalább ugyanolyan eredményeket elérni, mint egykor az UHU 1.1 Kamionnal. Minden, amit írok, az UHU 1.2 Rajt!-ra érvényes.
Az /etc/X11/xorg.conf-ba berakott: >> Option „XkbModel” „geniuscomfy” <<
sor csak akkor érvényes, ha a modell „genius”, ugyanis az /etc/X11/xkb/rules-ben található xorg-ban és xorg.lst-ben a felsorolt ugynevezett „inet”-internetes billentyûzettípusok között csak genius, vagy geniuscomfy2 található, a genius a Genius Comfy KB-16M / Genius MM keyboard KWD-910-es, a geniuscomfy2 pedig a Genius Comfy KB-21e Scroll modellre vonatkozik.
Egyébként igazad van, ez a próbálkozás valóban nem hozott eredményt.
Nem tudom, miért olyan érdekes, hogy a multimédiás billentyûim lenyomásakor villan egyet a vinyó LED-je, hiszen – szerintem – ez csak azt jelzi, hogy a rendszer érzékeli ezeknek a billentyûknek a lenyomását is. Vagy rosszul értem, és ez nem jó?A LinEAK-ot én már SuSE alatt is ismertem, de nem azt használtam, hanem az xev programmal kiolvastam a 16 multimédiás billentyû keycode-ját, és az .Xmodmap szerkesztésével ezekhez a keycode-okhoz hozzárendeltem az F13-F28 jelentéseket. A SuSE alatt KDE-t használtam, a kmenuedit programmal a 16 db multimédiás billentyût mint gyorsbillentyûket hozzárendeltem számomra fontos alkalmazásokhoz, tehát nem multimédia vezérlésre, hanem más feladatokra használtam. Az ALT, CTRL, WIN billentyûkkel kombinálva 48 db alkalmazást tudtam indítani a 16 db. multimédiás billentyûvel.
Ez a megoldás az UHU 1.1 Kamion alatt is mûködött, a SuSE-ban használt .Xmodmap-ot fel tudtam használni UHU 1.1 alatt is. Késõbb rájöttem, hogy UHU-ban – mivel itt a Gnome-ot használom – a gkb_default.xmm-et kell szerkesztenem a billentyû hozzárendelésekhez. Még késõbb rájöttem, hogy sokkal egyszerûbb az xbindkeys nevû programmal parancsokat, alkalmazásokat hozzárendelni a multimédiás billentyûkhöz. Persze ehhez az kell, hogy ezen billentyûk mindegyike lenyomáskor visszaadjon nyers kódot. Az UHU 1.2-ben azonban nem így van. A 16 db multimédiás billentyûbõl csak 10 db ad vissza nyers kódot, a többi 6 halott. Ez így van X alatt is, amikor az xev programmal próbálom megállapítani a keycode-okat, és szöveges módban is, amikor a showkey programmal própálom megállapítani a nyers kódokat, azaz a showkey -s parancsra a 16-ból csak 10 ad vissza lenyomási és elengedési kódot, a többi 6 semmit. Ugyanakkor a vinyó LED-je utóbbiak lenyomására is!!! reagál, igaz kicsit másképp, mint az érvényes 10 billentyû lenyomására.
A gépem egy másik partíciójára próbaképpen újra feltelepítettem az UHU 1.1-et, és ugyanezeket az ellenõrzéseket elvégeztem. A disztribúció egyébként most is fent van, ezzel ellenõrzõm, hol találok olyan pontot, amibe bele tudnék kapaszkodni a továbblépéshez.
Nos, UHU 1.1-ben a showkey -s parancsra mind a 16 billentyû ad vissza nyers kódot, igaz, hogy az UHU 1.2-ben is mûködõ 10 billentyû nyers kódja eltér az UHU 1.1-ben kapottaktól. Innentõl kezdve – ha nem is lennének hozzárendelve a billentyûkhöz keycode-ok, akkor a setkeycodes paranccsal ez elvégezhetõ lenne – az xbindkeys-el azt állítok be, amit akarok.
Nálam a fõ probléma az, hogy 6 billentyûhöz nem rendelõdik hozzá nyers kód, nem tudom, miért.
Az újonnan forgatott – egyébként ezer sebbõl vérzõ – 2.6.12-5-ös kernellel sem generálódnak kódok az említett 6 billentyûhöz. Emiatt a kernelforgatás eredményérõl lemondok, szerintem nem ott van a baj, ráadásul nem akarom tetézni a gondokat az új kernel buherálásával.
Fentiek miatt nem bízom sem a LinEAK-ban, sem az acme-ban, hiszen mindkettõnek szüksége lenne a nyers kódokra, amik nincsenek. Ráadásul egyiket sem sikerül forrásból lefordítanom, mert mindegyik hiányol különbözõ könyvtárakat, és nincs belõlük UHU csomag.…………………
„Nem értem, mire vonakozik a kérdésed, hogy: „Ez milyen kb egyébként?””
Bocs, milyen billentyûzet (a pontos típusszámot, ne csak a márkát).
…………………
[align=right][snapback]147490[/snapback][/align]Helló! A billentyûm típusát már a témaindító levélben megírtam, tehát:
Genius Comfy KB-16M, modell number: KWD-910Közben ismét fordítottam egy új kernelt, ez legalább bootol, de ezzel sem megy az X, ráadásul már a bootfolyamat során teleírja hibaüzenetekkel a képernyõt.
Ezek aztán számomra kínaiul vannak. Ja, és az eredeti gond változatlan: az ominózus 6 db multimédiás billentyûnek változatlanul nincs scancode-ja.Az egész probléma nem ér meg ennyi kínlódást.
Hát ez a legkevesebb, ami ilyen esetben történhet…
„Erre aztán visszaállítottam mindent az eredeti kernelre, mert azt még sikerült kiderítenem az új kernel esetén (az eredeti .configgal készített 2.6.12.5-ös), hogy sajnos ez sem generál scancode-ot ahhoz a 6 multimédiás billentyûhöz, ami miatt egyáltalán nekiálltam a kernelforgatásnak.”
Ez milyen kb egyébként?
[align=right][snapback]147448[/snapback][/align]Helló!
Tudom én, hogy a saját konfigurálású kernel a legjobb, azonban én leragadtam a
2.2.x-es verzióknál, azokban még viszonylag minden érthetõ volt.
A 2.6.x-es verzióknál viszont olyan sok beállítás van a konfigurálás során, hogy azoknak legfeljebb a 10%-át értem. Ezért nem is sikerült az „én” kernelem.
Nem értem, mire vonakozik a kérdésed, hogy: „Ez milyen kb egyébként?”
Ha a kernel méretére, akkor az eredeti kb. 2,2 MB (kicsomagolva), az enyém pedig kb 1,7 MB méretû lett.
Gondolom, azért nem bootolt, mert én a konfigurálásnál nagyon sok – az eredeti .config-ban modulként beállitott dolgot letiltottam, mert úgy itéltem meg, hogy nekem nincs rá szükségem. Ezek között bizonyára volt olyasmi, aminek be kéne töltõdni. Nem tudom pl. azt sem, hogy a kernelfordítás során a /usr/src/linux könyvtárban létrejövõ System.map nevû fájllal le kell-e cserélni a /boot-ban lévõt, és egyebek. Mint mondtam, én nem vagyok programozó, én csak találomra, illetve a különbözõ leírásokban található dolgok szolgai követésével végzem a kernel-fordítási feladatot.
Mi legyen pl. a /boot könyvtárban lévõ initrd-vel. Hiszen az is az eredeti kernelhez tartozik. Sehol nem találtam utalást arra, kell-e és ha igen, hogyan készíteni új initrd fájlt.
legutóbbi hsz