Kezdőlap › Fórumok › Videokártyák › Egyéb › Ati Radeon támogatás Linux alatt
- This topic has 22 hozzászólás, 4 résztvevő, and was last updated 14 years, 1 months telt el by
pointux.
-
SzerzőBejegyzés
-
2011-05-28-08:15 #2202919
Nem vagyok ám pazarló, csak itt betelt a pohár.
Nem is azt mondtam, hogy te pazarolsz, hanem azt, hogy erre akarnak rákényszeríteni. 😉
Ami különösen durva volt, - és ez a "linux" (vagy a disztro) sara! - hogy egy ilyen kártyával magától sem a live, sem a telepített nem adott képet a monitoron. Ha nem megy, elvárnám, hogy magától, könyörgés nélkül menjen át (vissza) VESA-ba, azután majd csinálom továb, ha akarom.
Nem, ami durva, hogy linux alatt már egy telepítés sem képes menni 3d nélkül. Windows alatt - kis túlzással - az idősebb gyerekeken kívül egy sima vga is elég mindenre. Azt hiszem a linux átesett a ló túloldalára, ráadásul úgy, hogy amihez meg kellene a kattintgatás, arra meg nincs általános megoldás, csak disztró specifikus.Nem kell, hogy a linux osx legyen, mert alkalmatlan rá. Attól, hogy egy trabantot átfestünk pirosra, ráteszünk egy ló emblémát, nem lesz ferrari. Aztán meg senkinek nem működik semmi. 🙁 Persze, kínos, ha ez már a telepítőnél így van. :DDD (Bocs! :))
Fiatalabb koromban elég sokat drivereztem, az elsőt még MP/M alá írtam! (1970-es évek második felében) 😀
2011-05-28-11:29 #2202920Az xorg-ról meg ne is beszéljünk. Csak nem tán úgy gondolod, hogy egy alacsony szintű device driver azért nem fejleszthető, mert az őt használó magasabb szintű sw apija változik? (Mellesleg az xorg apit használó sw-ek miért képesek használni?)Sőt, ha olyan magas szinten lenne megírva a driver, mint pl. mesa függvénykönyvtár (de akármilyen módon) simán csinálnának egy mes wrappert, hogy működjenek mesa alatt. Bár nem a leghatékonyabb módszer, de leggyorsabb és legpraktikusabb. (De ez veszély - sajnos - nem fenyeget minket, linuxos társadalmat.)
Nem azt mondtam, hogy az xorg változása miatt nem lehet írni. Hanem azt mondtam, hogy egyrészt ez nehezítés. Másrészt meg ez miatt nem lehet azt megcsinálni, hogy a régi kártyák drivereit az új xorg-gal fordítjuk, mert az új xorg miatt már nem fordul. Érted, mire gondolok?
2011-05-28-12:08 #22029211) A driverek hiányának semmi köze az xorghoz, csak a driver gyártóknak. (És nem is nehezíti meg a driver írását.)2) A régi kártyák pedig azért nem működnek a gyári driverrel, mert a gyártó nem támogatja. (Az xorg-nak ehhez megint semmi köze.) R6xx<=3) És pont xorg driverei azok, melyek (hiányos információik alapján - ugyan -, de) támogatják a régi kártyákat. Tudom, hisz pont ezért váltottam rá. <=R6xx<4) Az xorg nyilván az új gyári driver csomagot támogatja (amiben nincsenek támogatva a régi kártyák). Miért is támogatna egy 100 éves kódod, amire már nincs támogatás? (Megint más kérdés, hogy saját felelősségre meg lehet hekkelni.) Más kérdés, hogy ez nehézséget okoz(hat) a felhasználónak, de ne írjuk az xorg számlájára.Ezekből a pontokból nem pont az következik, hogy az xorg változása a nehezítés a gyári drivernek. Maximum pont a fordítottja. (Ha egy fejlesztést lehet nehezítésnek tekinteni. Álláspontom szerint nem.)
2011-05-28-12:58 #22029222. pontra: ha a régi kártyád (régebbi verziójú) meghajtóprogramját működésre tudnád bírni az új xorg-gal, én aszondom, teljesen tökéletes lenne. Engem különösebben nem érdekelne, ha mondjuk egy 3 éves kártyához mondjuk 2 éves meghajtóprogit használnék, miközben sok új verzió jelenik meg. De mivel a régi meghajtóprogramok nem működnek együtt az új xorgokkal, ezért ez a lehetőség elszáll. Mivel a gyártó az új verziójú meghajtókból kiveszi a régebbi kártyák támogatását, és nem tart fenn egy „legacy”-ágat (mint pl. az nvidia), addig vagy a nyílt forrású driver marad vagy pedig egy olyan repó, amelyben régebbi xorg van, és _minden_ grafikus program erre van fordítva (amely lehetséges), és így tudsz használni régebbi meghajtóprogit.Érted most már, hogy miért lenne (ebből a szempontból) jó, ha az xorg és a kernel is egy kicsit állandóbb API-val rendelkezne?
2011-05-28-14:13 #2202923ha a régi kártyád (régebbi verziójú) meghajtóprogramját működésre tudnád bírni az új xorg-gal, én aszondom, teljesen tökéletes lenne.
Mint mondtam meg tudod oldani. Átírod az xorg függvényeit, hogy ne az új eszközkezelő függvényeket várja, hanem a régieket, amit nem támogat az amd... és vállalod a felelősséget. Csak nem értem, hogy mi köze van ennek az xorg-hoz. Vagy várjuk el az xorg-hoz, hogy az új driverek helyett a régieket támogassa, mert neked az a jó. Két olyan apróságról nem is beszélve, hogy 1) ezáltal az új kártyák nem fognak működni, 2) az új hw képességek függvényeit meg mondjuk "törölni" kell, hogy ne okozzon hibát, mivel hw, és driver, stb. már nem lesz mögötte. (És ezzel vissza is alakítottuk az új xorgot egy csomó hibalehetőséggel a régivé. No, de akkor minek is az új xorg?)1) Ha régi xorg-ot, akarsz, akkor meg van a lehetőséged rá.2) A régi kártyákat a gyártó nem támogatja és kész. Nincs hozzá új driver. Ismétlem, ehhez semmi köze az xorgnak.3) Van nyílt forráskódú driver, amit akár használni is tudsz, az új xorggal is.4) Érdekes, hogy bizonyos drivereket nem zavar, hogy változik az api. (De - ismétlem - mi köze van az xorg apinak, egy alacsony szintű device driver fejlesztéséhez? Te sem gondolod komolyan, hogy egy device driver írását egy megjelenítési protokoll, gui keretrendszer fogja meghatározni. Mondjuk az egyszerűség kedvéért egy device drivert érdekelni fogja, hogy az egyik gui putpixel, a másik pl. point függvényt használ mondjuk egy pont kirajzolására? Vagy érdekelni fogja, hogy a point függvény mondjuk ír egy log file-ba is?)5) Az api annyit változik, amit a hw-ek, lehetőségek és célszerűség lehetővé, ill szükségessé teszi... és nem mondjuk viccből. És, ha ez gondot okoz, akkor visszautalnék az 1-es pontra, de akár lehet nyílt drivert is használni. (És lehet xp-t használni, ha a vista nem jön be.) Ezek persze csak a megoldási javaslatok, de annak, hogy pl. az xorg apija fogja meghatározni, vagy értékelhető módon befolyásolni a drivert, annak nincs értelme. Sőt annak is több értelme van, ha azt mondod, hogy a felhasználói programok (mondjuk játékok) befolyásolják a driver írást - azzal, igény van komolyabb driverekre.
2011-05-28-15:36 #22029241. Igen, megvan a lehetőség rá. Ekkor használsz forrásalapú disztrót, vagy pedig semmit nem frissítesz, vagy pedig egy olyan repót használsz…2. Én se mondtam, hogy van köze ehhez az xorg-nak. Nem tudom, honnan veszed.3. Tudod használni, a régebbi kártyákhoz. Az újabbakhoz is, de ott a 3d-gyorsítás még elég vacak. Tapasztalataim alapján a nyílt forrású radeon inkább a régebbi kártyákon produkál normális teljesítményt, az újabbakon nem.4. Próbálj egy régebbi verziójú nvidia driver-t újabb xorg-ra. Vagy fordítva 🙂 Meg persze a kernel is "inkompatibilis idejű" legyen!Hogy hogyan használ xorg-ot, nem tudom, én nem vagyok fejlesztő. Én csak azt tudom, hogy az fglrx modul használ xorg-os libeket is. Tehát függ tőlük:[bash]$ readelf -d /usr/lib/xorg/modules/dri/fglrx_dri.so | grep "NEEDED.*libX" 0x00000001 (NEEDED)
2011-05-28-18:10 #22029252. Én se mondtam, hogy van köze ehhez az xorg-nak. Nem tudom, honnan veszed.
Nem másolom be az összeset, de imho állandóan azt fejtegeted, hogy az xorg api változása nehezíti meg a driver fejlesztést:
Úgy gondolom, hogy nemcsak az ATI-ra kell kenni mindent, hanem a Linux illetve annak fejlesztése is sáros. Az, hogy az xorg-nak állandóan változik az API-ja, nem épp könnyítés akármilyen fejlesztésnek is. Ha nem változna ennyire, akkor a régi kártyák régi verziójú ATI-meghajtóit nyugodtan lehetne használni (...)
Én csak azt tudom, hogy az fglrx modul használ xorg-os libeket is. Tehát függ tőlük:
No, itt jön elő, hogy a gpl-nek és a gyár (gyakorlatilag érthetetlen*) titoktartásánal egyszerre kell teljesülnie. Ez pedig csak úgy valósítható meg, hogy az elérhető gpl kódhoz készítenek egy ragasztót. Mivel fordítva - noha az lenne a gyorsabb, egyszerűbb, praktikusabb nem megy - mivel a gyártó kódja titkos.*Annál is inkább, mert pl. ellopni sem lehet a kódod, mivel a kártyához adják. Noha lehet illegálisan tökéletesíteni, de ebből a gyártónak milyen kára származna.
De egy dolog nem világos: ha azt mondod, hogy az fglrx nem használja az xorg-ot (merthogy mi köze van hozzá?), akkor újabb xorg-ok mellett miért nem lehet használni a régebbi fglrx drivereket?
Nem azt mondtam, hogy nem használja, hanem azt, hogy a driver fejlesztését nem határozza meg és nem is nehezíti.És hogy miért nem lehet telepíteni? Mivel a gyártó titkosította a függvényeket (azaz nem lehet hozzáírni), sőt meggátolta az újrafordítást is! Továbbá önmaga nem hajlandó lefordítani, holott dinamikus függvény linkek vannak benne. Ez utóbbi viszont azt jelenti, hogy a függőség a "téma" szempontjából jelentéktelen (használatlan) részének változásával is elő lehet idézni mondjuk egy szegmentációs hibát.De még ezzel a változással és ezzel a magatartással is csak annyit kellene többnyire csinálnia a gyártónak, hogy fél pillanat alatt - a kód megváltoztatása nélkül - hozzáfordítja az új függőséghez... de még ennyire sem képes.De ugye a linuksz a szar... meg az xorg.Egyébként amilyen függvényeket használ a driver (jobbára ilyen, mint xfree, xopendisplay stb.) az 100 éve változatlan (de senkinek nem okoz gondot, gtk, qt xfce stb.) - legalábbis a nevét és paramétereit tekintve, mert ebben a helyzetben is legfeljebb ez számít. Az, hogy mit tartalmaz, az már nem.Egyébként meg, ha api változás miatt nem működne a driver, azt sem lehetne a linux számlájára írni. Mivel 100 éves adott esetben driverekről van szó. Azaz pl. senki nem háborog, ha pl. egy xp driver nem jó mondjuk egy vistára, vagy pl. egy 98-as egy xp-re. Igaz ott nem is kell háborogni, mert a gyártó legyártja. De, ha linuxnál tesz egy nagyot a gyártó a linuxra, akkor természetesen a linux a szar.Persze, hogy a linuksz a szar, amikor ahhoz nem gyártanak drivert. A windóz nem lehet szar, mert ahhoz gyártanak.No, ez a véleményem a dologról.
2011-05-28-21:02 #2202926No, itt jön elő, hogy a gpl-nek és a gyár (gyakorlatilag érthetetlen*) titoktartásánal egyszerre kell teljesülnie. Ez pedig csak úgy valósítható meg, hogy az elérhető gpl kódhoz készítenek egy ragasztót. Mivel fordítva - noha az lenne a gyorsabb, egyszerűbb, praktikusabb nem megy - mivel a gyártó kódja titkos.*Annál is inkább, mert pl. ellopni sem lehet a kódod, mivel a kártyához adják. Noha lehet illegálisan tökéletesíteni, de ebből a gyártónak milyen kára származna.
Ehhez azt tennem hozza, hogy a kovetkezo dolgok bonyolithatjak a helyzetet:Megtortenhet, hogy a gyarto a driver bizonyos reszeit licenszeli. Ilyenkor bele kell egyezzen az is, akitol vette a kodot, hogy kiadhassa. Lasd Intel esetet az Imagination Technologies-al
2011-05-29-04:45 #2202927A kodlopas lehetosegevel az a problema, hogy nem a cegtol lopjak el a kodot, hanem a konkucencia vadolja meg a driver irojat, hogy peldaul serti valamelyik szabadalmat / szoftver szabadalmat, vagy tole masolt ki tudja mit, stb. Ebbol pedig vegtelen perek szulethetnek.
Szabadalmat nyilván nem sérthet. Egyébként megveszem teljes jogú használatra a kódodat sem sem sérthet jogokat. A saját hw, vagy sw fejlesztés em okozhat gondot.Bár az meg elég szomorú, hogy "tröszt szerződéseket" kötnek, de ezeket könnyen lehetne nem gpl modulba tenni, mivel a ragsztó, driver illesztó program és az alkalmazások kódja is nyitott minden fejlesztőnek.Hát, az meg, hogy ki tudja, ki, kitől vett, vagy kitől másolt. :DDD No, ebből szoktak a gpl sértések lenni. 😀 A hatalommal való visszaéléseken kívül ez lehet a legnagyobb probléma. Sokszor nem adhatják ki a kódot, mert kiderülne, hogy lopott. A ms-nál pl. amúgy is kiderült... no ilyenkor szokta a ms (utólag) ""nagylelkűen"" - nagy dérrel-dúrral bejelentve - ""támogatni"" az os közösséget. :DD
Kiadott driver kod gondot okozhat meg a digital rights management (drm) (felhasznalo ellen iranyulo funkcionalitas) vedelmenere, bizonyos operacios rendszerek eseten (windows).
Ez nem ok a teljes kód visszatartására. Parsze linuksz alatt sem így, sem úgy nem működnek ezek a funkciók.Ha pl. a gyártó által (legalább elcsúsztatva) kiadott gpl kódban lenne egy kereskedelmi (feltételes) link (dinamikus link formájában), akkor a felhasználó (teljesen mindegy, hogy disztrib kiadója, vagy végfelhasználó) eldönthetné, hogy akarja-e használni.Ezzel mególdódna a normális driver kérdése, a "gpl only" mód lehetősége, sőt a pszeudo hw-es jogvédelem is. Sőt a dinamikus libekkel sem lenne semmi gond, mivel ezúttal a libeket használó kód forrása lenne hozzáférhető és nem a dinamikus linké, azaz bármikor lefordítható lenne. Minek következtében megszűnne az uzsolt által említett probléma. Még abban az esetben is megszűne, ha a gyártó nem támogatja a régi hw-eket, úgyanis bárki készíthetne foltot.
Az ilyen tipusu problemak miatt a gyarto nem kap meg bizonyos papirokat microsofttol, es piacot veszit.
Vagy pont fordítva. (Ilyen ügyek miatt a ms és az apple is veszített már pert.) Egyébként már az is elég lenne, ha a ms elveszítené a kínai és európai piacok nagy részét. Ez meglehetősen könnyen előferdülhet manapság.Apropó, a ms hegemóniára nagyon jó példa, hogy egyes linux (ill. egyéb nyílt forrású) beágyazott rendszerek nem támogatják csak a ms-ot. Pl. vegyünk egy múltimédiás központot (tv, doboz, akármi), mely képes hd tartalmat is lejátszani, általában csak fat rendszerről - ami ugye önmagában is nevetséges (kizárólag üzleti szempont), mivel a fat alkalmatlan normális hd tartalmak tárolására. No, és itt jön a gpl/linux/lgpl/stb., mely lehetővé teszi/tette az ntfs-hez való korlátozott hozzáférést. Azaz elérhetővé vált a hd tartalom kezelése. Persze a többi alkalmas és véletlenül "bármely" os által támogatott file-rendszerek támogatása letiltásra került. Miért is? Ne zavarjuk meg a felhasználót azzal, hogy olyan file-rendszerek is léteznek, melyek alkalmasak a feladatra (ráadásul még ingyenesek is). Sőt olyan cégről is tudok, melyeknek a termékében volt ext3 támogatás, aztán a következő termékben már egyszerűen megszűnt és csak a fat maradt. (Gondolom az ext3 támogatás instabil volt és egyébként is alkalmatlan a hd tárolásra ezért maradt a fat. :DDD Vagy esetleg annyit mondott a ms: elnézzük neked, hogy legális nyílt kód felhasználásával támogatod a ms-ot, ahelyett hogy nem tejelsz, de cserébe kizárólagos file-rendszert akarunk.)Inkább ezeket a cégeket kellene feljelenteni. Persze van is rá példa. A gpl és piaci befolyással való visszaéléseket pl. rendszeresen veszíti el a ms is.
Ez a modul kepes hardveresen dekodolni videokat, gyorsabban es hatekonyabban, mint a CPU. Sajnos nem adtak ki errol a modulrol semmilyen dokumentaciot, mert osszefugg a windowos drm funkcionalitassal.
No, ez az amit gpl-be nem lehet kiadni, mert a drm sérti a gpl-t.De gpl-be lehet írni egy play_with_uvd zárt kódú "függvényt", úgy meghívva, hogy figyelmeztessen, hogy ellentétes a kernel gpl szellemével. És egyszerűbb, mint az xorg-ot félig újraírva gpl sértést okozni, ill. generálni az uzsolt által említett "új verziókkal nem működik" problémát. (Vagy mindkettőt.)És mindenki boldog. Hogy ez nincs így, annak feltehetőleg egy oka lehet, hogy a háttérben pénzek mozoghatnak és a közhiedelemmel ellentétben a pénz boldogít. A multiknak pedig csak a rövid távú haszonszerzés számít. (És még örülhetünk is neki, mert érdekes módon ez a multik Achilles-sraka.)
Referenciakent javaslom a phoronix forumait; neha AMD alkalmazottak is irnak oda.
Mármint ezeket az információkat, vagy véleményt fogalmaznak meg - adott esetben. Mert mondjuk a vélemény - imho - érdekelne mindenkit. (Jó, persze az infók is, csak az sokunk által nagy vonalakban már ismert. A bővebb infó meg nyilván titok, hisz tirok.)(Hehe, no eddig is csodálkoztam, hogy olvas engem valaki, de ezt a regényt... :DDD)
2011-05-29-22:02 #2202928Itt van par link a phoronoixrol, ahol hasonlo temat targyalnak:drm es driverek esete:
Most of our sales are to big OEMs. OEMs want Windows WHQL certification from Microsoft. WHQL certification requires DRM support. If we say "no thank you, we don't want to participate in your DRM ideas" then OEMs will just buy from someone else, and the biggest chunk of our market disappears. It's possible that there might be a retail market that would accept uncertified Windows drivers and all the hassles which go along with them, but realistically I think we would be talking about Linux-consumer-only products.
drm itt isitt a zart forrasu meghajtokrol van szoMeg van sok hozzaszolas, amit erdemes idezni; kesobb talan osszegyujtom oket.
-
SzerzőBejegyzés
- Be kell jelentkezni a hozzászóláshoz.
legutóbbi hsz