X, Wayland, Mir

Azoknak akik esetleg lemaradtak róla: az ATi kiadta a FireGL kártyáinak a legújabb 2.9.6-os verziójú drivereit. Szóbeszédek szerint ezek a FireGL driverek kompatibilisek a 8500-as Radeon kártyával.Ezen kívül a FireGL 8800 driverek működnek a Radeon 8500-as kártyákkal, és a FireGL Z1 / X1 driverek működnek a Radeon 9000 Pro-kal. Hogy mik vannak... ;-)

Többen fejlesztik a fetchmail-t, mint az XFree86-ot?

Érdemes olvasgatni mostanában az Xfree86 levlistát, mert érdekes dolgok történnek. Olyan dolgokról hallani, hogy lecserélik a fontconfig-ot a Sun által készített stsf-vel, hogy az XFree86 társ-alapítója David Wexelblat azt mondta, hogy az Xfree86 napjainkban elavult, és változtatni kell rajta. Szerinte le kell cserélni egy direct rendering modellel (persze megtartva a visszafele kompatibilitást). Keith Packard egy nyílt felhívást adot közzé, amelyben egy új írányító csapat létrehozására szólít fel. Szerinte a problémák a következőek:

• behatárolt számú fejlesztői erőforrások
  
  szerinte a fetchmail project 800 fejlesztővel dolgozik, amíg az utolsó két évre visszamenőleg az XFree86 hozzájárulók száma max. 250 fő
• Lassú kiadási ütemterv
  
  Az Xfree 4.2 2002 januárjában jelent meg. Azóta az ATi radeon chip-nek 27 új driver verziója került bele az XFree86-ba. Ha valaki ezeket használni akarta, akkor várnia kellett több mint egy évet (2003. február) a Xfree 4.3 megjelenéséig, vagy használhatta a ki nem adott verziókat.
• hiányzik az együttműködés a többi projectekkel
  
  szerinte jobban együtt kellene működni az olyan projectekkel mint a KDE vagy a GNOME
• nem átláthatóak a fejlesztői projectek
  
  Azt sem lehet tudni, hogy ki tartozik egyáltalán a fejlesztők közé. A honlapon erre nézve nem lehet infót találni, az új fejlesztők nevét a maximum a levlistákból, és README fileokból lehet kiolvasni.
  

Szóval úgy néz ki, hogy több ember is elégedetlen a jelenlegi vezetéssel, a fejlesztés ütemével, és a szervezeti felépítéssel. Reméljük, hogy megtalálják a legjobb utat, és ezzel mi felhasználók, csak nyerni fogunk.



Kapcsolódó cikk:

Úgy néz ki, hogy a XFree86 fork-olódni fog?

Úgy néz ki, hogy az XFree86 Core Team egyik volt tagja - Keith Packard - (aki nemrégiben még tag volt) forkolni akarja az XFree86 fejlesztéseit.Packard azon dolgozik, hogy egy meghívásos alapú fejlesztői csapatot hozzon létre, amely csapat tagjai a fejlesztési eredményeket, az X jövőjét egy privát listán beszélnék meg. Az Xfree86 team ezzel egy időben arra törekedik, hogy még nyitottabb legyen, így harcolva a fork ellen. Keith Packard egyébként egy hozzáértő fejlesztő, aki az FontConfig, és Xft projecteken dolgozik.

Bővebben itt.

Hajnal óta letölthetők a RandR-es XFree86 binárisai is a szokásos helyről. Relnotes-ot szintén itt találsz a snapshots könyvtárban. Branden most nagyon aktív, folyamatosan frissítette a 4.2.1 csomagot, úgyhogy minden remény megvan arra, hogy hamarosan elkezdi a 4.3-at. Jó forgatást-átméretezést-frekiváltást kívánok!

Végre itt van. Ez a jó hír. A rossz hír, hogy egyelőre csak CVS-ből lehet szedni. A másik jó hír, hogy ma estére - ha tartják magukat az igéretekhez - már elérhető lesz rendesen. A másik rossz hír viszont, hogy ki tujda, hogy mikorra lesz meg .deb csomagban.

Az X.org - a szervezet, amely az X11R6 speceifikációk fejlődésének dolgait igazgatja - kiadott egy hang szervert az X-hez, amely a MAS névre hallgat. A MAS az X11 szerverrel kompatibilisen épül be a felhasználók rendszerébe. A segítségével a grafikus események könnyebben szinkronizálhatóak az audio alapú eseményekkel, a profi minőségű multimédia, és kiegészítő alkalmazások támogatására. A MAS jelentése "Media Application Server," és MIT licence alatt terjesztik. A fejlesztését a Shiman Associates végzi. (Slashdot)

A MaximumPC volt olyan szerencsés, hogy tesztelhette az nVIDIA új GeForce FX névre hallgató kártyáját. Amikor először hallani lehetett a kártyáról akkor még az NV30 kódnéven futott. Most az nVIDIA átadott (állítóltag) egy teszt példányt az új kártyából a fent említett weboldalnak. A kártya és a hozzá adott driverek még csiszolatlanok, az nVIDIA kérte is a weboldal tesztereit, hogy ezt feltétlenül hangsúlyozzák ki a teszteredmények kihirdetésekor. A kártyát az ATI Radeon 9700 Pro-val hasonlították össze.

Az eredmények:A Quake III-ban 600x1200, 32-bit színmélységben, és 2x-es anti-aliasing (élsimítás) mellett, a GeForce FX kb. 40%-kal volt gyorsabb az ATI Radeon 9700 Pro-nál ugyanazon beállítások mellett. A GeForce majdnem 20%-kal volt gyorsabb a 9700 Pro-nál az Unreal Tournament 2003 Asbestos fly-by demoban ugyanazoknál a beállításoknál. Viszont a 3DMark 2001:SE Game 4 mérésben ugyanazoknál a beállításoknál a Radeon 9700 kb. 10% gyorsabb volt a GeForce FX-nél.

Mit is jelent ez? Azt, hogy a GeForce FX nagyon gyors -- egyedül a memória sávszélesség okozhat gondot. A GeForce FX 128-bit széles memória busszal rendelkezik, ami 500MHz-en fut, és így a maximum memóriaátviteli sebesség 16GB/sec. Szemben a Radeon 9700-zal, ami 256-bit memória busz szélességgel rendelkezik, ez 325MHz-en fut, és így az átviteli sebessége 19.8GB/sec.

Számszerű adatok:

GeForce FX

Quake3 Demo001, 1600x1200 2xAA: 209fps

UT 2003 Asbestos, 1600x1200 2xAA: 140fps

3DMark Game4, 1600x1200 2xAA: 41fps

Radeon 9700 Pro

Quake3 Demo001, 1600x1200 2xAA: 147fps

UT 2003 Asbestos, 1600x1200 2xAA: 119fps

3DMark Game4, 1600x1200 2xAA: 45fps

Ütős kártya lesz. Ja és ne felejtsük el, hogy ez csak egy BETA kártya.

A weboldal itt. Forrás Slashdot.

Itt egy nem hivatalos patch azoknak, akik ki szeretnék próbálni az nVIDIA kártyájukat glx gyorsított driverrel a 2.5.44-es kernel alatt.

A foltok az nVIDIA hivatalos NVIDIA_kernel-1.0-4191 nevű driveréhez készültek.

FIGYELEM! Kizárólag saját felelőségre!

A folttal kezelt hivatalos driver használható a Linux 2.5, 2.4-rmap* kernelekkel. A hivatalos drivert először az NVIDIA_kernel-1.0-4191-2.5-tl.diff patch-csel kell kezelni, majd utána, mivel a 2.5.54 kernel modul loadere változott szükség van az NVIDIA_kernel-1.0-4191-2.5.54.diff nevű foltra.

Sajnos szokás szerint az AMD + nVIDIA + AGP kezeléssel megint baj van, nem elég a "mem=nopentium" workaround ami a 2.5-ös kernelben van. A gép az X szerver indításkor megfagyhat ha a workaround be van kapcsolva.

Változások logja, részletes leirás:These files have undergone basic testing, but are distributed without any warranty. Please note that using the "mem=nopentium" workaround for the AMD Athlon/AGP stability problem on Linux is known to not work as expected on Linux 2.5 (your system may freeze upon starting X with this option set).

If you are experiencing problems with ACPI support enabled, this may be due to the "new" ACPI PCI IRQ routing. You can disable support for this mechanism with the pci=noacpi boot-time kernel parameter. If this doesn't help, you may need to disable the ACPI subsystem with acpi=off.

The credit for the first 1.0-4191 update goes to Alistair Strachan (alistair@devzero.co.uk).

Linux 2.5 (update) updated 01/03/2003

• As of Linux 2.5.54, the Linux kernel module loader no longer handles common sections, attempting to load kernel modules with common symbols will result in "Invalid module format" errors. The nv-kernel.o object file distributed by NVIDIA apparently wasn't built with -fno-common, the nvidia.o kernel module is rejected.

  This patch changes how nvidia.o is linked to force all common symbols into the .bss section.

• Fixes the machine dependant include path to reflect the new paths in Linux 2.5.53 and later kernels. You will need to apply the 1.0-4191 patch (see below) first.
  

Linux 2.5, 2.4-rmap* updated 12/27/2002
• With this update, NVIDIA's AGP GART driver works properly with the 2.5 compatibility patch on Linux 2.4 (vanilla, -rmap*) kernels again. This had been broken with the first NVIDIA 1.0-4191 Linux 2.5 patch.
• This version fixes a memory leak in the PTE lookup macro on Linux 2.5 or 2.4-rmap kernels, where calls to pte_offset_map were not properly matched by calls to pte_unmap (see the recent "rmap and nvidia?" thread on the LKML for details).

  The credit for this update goes to O. Sezer and Andrew McGregor.

• This patch is the 1.0-4191 equivalent of the 1.0-3123 for Linux 2.5 tasklet patch, including the update for recent Linux kernel module interface changes.
• The page_alloc.c BUG fix referred to below has been integrated into this NVIDIA driver release, the corresponding patch is thus no longer needed or even compatibel with this release.
  

Lerágott csont, minden flamek alapja az nVIDIA linuxos meghajtója. Úgy látszik, hogy még nem elégszer lett a téma körüljárva, mert a Hell.Surfers@cwctv.net címről egy felhasználó egy nagyon hosszú threadet indított el az LKML-en, "Why is Nvidia given GPL'd code to use in closed source drivers?" subject-tel. A témát mindenki magáénak érezte, hiszen rengetegen szóltak hozzá az ünnepek alatt. nVIDIA fanok és gyűlölők, érvek pro és kontra a Linux listán.

A thread itt kezdődik, és itt folytatódik.

Kissé megkésett hír, de lényegében itt az X 4.3, legalábbis a 4.2.99.3 snapshot a már emlegetett RandR technológiával és a Gimp Tool Kit 2.2, amely szintén támogatja ezt a bővítést. A már végleges 4.3 éppen egy hónap múlva lészen kiadva egyidejűleg a New York-i Linux Conference & Expo-val, és az ausztrál Linux konferenciával. Szomorú, de még mindig nincsen az XFree86-nak magyar mirrorja, de a snapshot azért természetesen letölthető:e célból a legjobb ellátogatni a project oldalára. Különlegesen boldog karácsonyt, Branden!

sorry, h. ennyire nem volt módom követni az eseményeket, de hát ez a karácsony...! Megígérem, ezentúl jó leszek.