[discussie] X.org en Linux-Graphics - de toekomst

quote:

deadinspace schreef op 25 March 2003 @ 03:40:
Dat is niet waar, 32 bpp wordt gewoon ondersteund. Als je in XFree86's config "24" opgeeft voor de colordepth, dan zal XFree86 naar eigen inzicht kiezen of 24 of 32 bpp gebruikt moet worden. Hoe XFree86 dat beslist weet ik niet, maar ik meende dat 32 bpp werd gekozen waar mogelijk. Ook weet ik dat dit te overriden is (lees de manpages maar eens).

Maar die laatste 8 bits worden niet gebruikt dus het is gewoon waardeloos.
Het zou trouwens kunnen dat dit alleen maar het geval is wanneer er een kaart van NVIDIA wordt gebruikt.. (welke geen 24 bpp ondersteund)

Maar wat ik eigenlijk bedoelde met andere 'kleurmodellen' is bv ondersteuning voor 64, 96 of zelfs 128 bpp.. (en dat gaat uiteraard in de richting van floating point formaten, welke al helemaal niet worden ondersteund in XFree86)

quote:

Dat is een beetje oneerbiedig en kort door de bocht. Een aantal (niet allemaal nee) van de core developers doen _echt_ wel veel. Alleen die paar zijn niet genoeg om zo'n enorme source tree te onderhouden. Dat is ook één van de dingen die moeten veranderen: het aantal developers dat werkelijk aan de code mag zitten.

Daarom had ik het ook over de _meeste_ core developers.

quote:

idletoad schreef op 25 March 2003 @ 10:37:
Hoe dan?
[...]
Kijk jij zelf liever uit wat je roept, altijd meteen maar roepen dat de ander er niets van begrepen heeft... Irritante kwaal in de linux-community.

Dat zegt toch genoeg?

quote:

Ik stop met deze discussie. Als we zo gaan beginnen, dan hoeft het niet meer... Arrogante drol.

Mjah...

[edit]
Gewoon voor de grap - weet je hoe lang, irritant en slepend sommige discussies in een community soms zijn? Uiteindelijk kom je er wel uit, maar je moet bewijzen leveren voor dat wat jij zegt... Als iemand me een patch opstuurt, denk je dat die er zomaar in gaat? Ben jij daar gek, ik wil bewijzen en reproduceerbaarheid. Als ik redenen heb om te geloven dat het anders werkt dan die persoon denkt, dan gaat die patch er niet in totdat ik overtuigd ben.

Ondanks dat jij zegt dat je een window hebt die 14 of 16 of 20 fps haalt, vraag ik me toch echt af hoe bekend jij bent in dit development proces... Dan ben ik maar arrogant, maar ik ben er volgens mij toch een stuk bekender in dan jij... .

Beelzebubu wijzigde dit bericht 25-03-2003 11:35 (47%)

quote:

Maar die laatste 8 bits worden niet gebruikt dus het is gewoon waardeloos.
Het zou trouwens kunnen dat dit alleen maar het geval is wanneer er een kaart van NVIDIA wordt gebruikt.. (welke geen 24 bpp ondersteund)

Normaal gesproken worden die laatste 8 bits ook gebruikt voor alpha transparantie. De 'gewone' kleuren worden wel vastgelegd door die 24 bits (8 bits voor rood, 8 bits voor blauw en 8 bits voor groen. Laatste 8 bits voor alpha dus.) X doet geen alpha inderdaad, helaas.

quote:

dikkebanaan schreef op 25 maart 2003 @ 11:13:
Maar die laatste 8 bits worden niet gebruikt dus het is gewoon waardeloos.
Het zou trouwens kunnen dat dit alleen maar het geval is wanneer er een kaart van NVIDIA wordt gebruikt.. (welke geen 24 bpp ondersteund)

Maar wat ik eigenlijk bedoelde met andere 'kleurmodellen' is bv ondersteuning voor 64, 96 of zelfs 128 bpp.. (en dat gaat uiteraard in de richting van floating point formaten, welke al helemaal niet worden ondersteund in XFree86)

Wat is daar het nut van als ik vragen mag ?? Als ik me kan herinneren kan een menselijk ook niet meer als ongeveer 7 miljoen verschillende kleuren onderscheiden. Wat is dan in hemelsnaam het nut van 64 of zelfs 128 bpp ??? Leuk voor de marketimggeilen onder ons, maar geen praktisch nut.

Zoals ik al zei: bij 32 bits kleuren wordt er slechts 8 bits voor alpha transparantie gebruikt. Het is daarmee dus mogelijk om slechts 255 verschillende alpha tinten te maken. En dat is dus echt wel te zien. Hoe de bitsverdeling bij 64 en 128 bpp precies zit, weet ik niet. Maar ik kan je wel vertellen dat de transparantie een stuk beter wordt

quote:

idletoad schreef op 25 March 2003 @ 10:11:
X is bedacht toen Gates nog z'n pampers volscheet

AUB GEEN reacties mixen in 1 post, extreem irritant.

quote:

Nee. Het is in begin jaren 80 ontwikkeld, en volgens mij was de eerste bruikbare versie er in 1984... Windows stamt uit omstreeks 1985... Dus zoveel verschil zit er niet...

Dat was Athena van het MIT. X werd een echte standaard in 1986.

Windows '95 draait alleen op een Intel

quote:

En wat heeft dat ermee te maken?

Zeker nog nooit geprogrammeerd ?? Wel eens te maken gehad met alignment problemen, verschillende compilers, platformspecifieke ellende, etc. Met een architectuur heb je die problemen niet, wat aangezien in code scheelt.

quote:

quote:en zonder patches draait het ook nog beroerd

Ga jij eens een XFree86 uit 1995 draaien zonder patches? Dan praten we verder.

1984 vs 1995 vind ik een aanzienlijk verschil. Da's 10 jaar. X windows heeft nooit als doel gehad om snel te zijn. En voor een from scratch design is Windows '95 (en uberhaupt win32) uitermate beroerd te noemen.

quote:

quote:Die bloat wordt mede veroorzaakt omdat alle videodrivers in de betreffende source zitten.
Uhh, WAT?

Het aantal procenten wat drivers is is vrij groot in de X source.

quote:

jointm1k schreef op 25 March 2003 @ 12:02:
Zoals ik al zei: bij 32 bits kleuren wordt er slechts 8 bits voor alpha transparantie gebruikt. Het is daarmee dus mogelijk om slechts 255 verschillende alpha tinten te maken. En dat is dus echt wel te zien. Hoe de bitsverdeling bij 64 en 128 bpp precies zit, weet ik niet. Maar ik kan je wel vertellen dat de transparantie een stuk beter wordt

Ah, OK.. Ik ben dan ook leek op grafisch gebied, niks gezegd

Oja, ik weet het weer hoe het zat: Met 64 en 128 bpp kaarten kun je beter met layers werken. Bv, met photoshoppen of een video programma. Met 64 bbp kaarten kun je namelijk 2 x 32 bits layers op elkaar plempen, en met 128 bpp maar liefst 4! Met een 32 bits kaart kun je natuurlijk ook verschillende lagen video materiaal op elkaar doen, alleen loop je dan de kans dat je tegen een soort kleuren aliasing oploopt. Je kunt die wel ondervangen door de CVE / Conventioneel RAM de kleuren te laten interpoleren naar een 32 bits kleur, maar dat is een heel langdurig karweitje. Je kunt beter gewoon het framebuffer van je videokaart uitrusten voor het werken met verschillende lagen. Gaat een stuk sneller

////Edit: het had dus niets te maken met alfa transparantie. Ik was ff in de war Om alfa transparantie beter te maken, kun je bijvoorbeeld gebruik maken van 10 bits per kleur ipv 8. (De matrox parhelia doet dit bijvoorbeeld.)

jointm1k wijzigde dit bericht 25-03-2003 12:21 (16%)

Hoei! Dan wordt je wakker en is er een soort flamewar losgebarsten. Anyway, m'n naam werd genoemd af en toe en daar wilde ik nog even reageren. Flame on verder hoor, stoor je niet aan mij.

quote:

OpenGL is al netwerk-transparant met XFree86. Tenminste, XFree86' GLX module werkt gewoon over het netwerk. Alleen DRI acceleratie werkt niet remote.

Juist. Je server rendert dus je frame en stuurt die over het trage trage netwerk (niet te vergelijken met je mobo), toch? Dat wordt dus geen, hmm, quake 3 spelen. Of zelfs maar naar friggin' glxgears kijken. Dat is wat ik bedoelde.

quote:

mm, wat bedoel je precies? Hardware overlay + scaling + colorspace conversion kan gewoon via de Xvideo extensie, AFAIK zeker op de G400. En, what's more, tegelijk met DRI accelerated 3D.

Jeah, hardware overlay iig. Maar scaling weet ik niet zeker, maar zou goed kunnen hoor. Anyway, waar ik het over had was dit: uit de man pag (maar er zijn vast betere voorbeelden)

Option "TexturedVideo" "boolean"
This has XvImage support use the texture engine
rather than the video overlay. This option is only
supported by the G200 and G400, and only in 16 and
32 bits per pixel. Default: off.

quote:

Waarom snapt iedereen dat voor Apache + Mozilla, maar niemand voor XFree86 + gimp ?

Welk programma levert de data? Apache bijvoorbeeld. De server dus. Welk programma zorgt ervoor dat je iets ziet? Mozilla. De client dus.

Nou, dat maakt je progjes de server, en je X server de client. :-) Shit, ik moet echt die rant eens opzoeken, was heel erg grappig.

Ok, ik ben dus een n00b op X gebied, maar het verbaast me dat er zoveel over het netwerk-model van X gesproken wrodt hier. Is dat nog relevant? Mijn eerste gedachte is van niet. Overigens denk ik dat een fork een goede zaak zou zijn voor X, een spreekwoordelijke schop onder de respectievelijke konten van een aantal core devvers kan wellicht geen kwaad. Ik hoop dan ook dat die kerel die eruit is getrapt nog even de CVS-tree heeft leeg geleeched

quote:

bahsj schreef op 25 March 2003 @ 12:40:
Welk programma levert de data? Apache bijvoorbeeld. De server dus. Welk programma zorgt ervoor dat je iets ziet? Mozilla. De client dus.

Als je een mailtje stuurt, wie rendert? De server. Wie stuurt de data? De client. Waarom dan opeens wel?

Doe even niet zo flamerig/kortzichtig...

quote:

jointm1k schreef op 25 March 2003 @ 12:19:
////Edit: het had dus niets te maken met alfa transparantie. Ik was ff in de war Om alfa transparantie beter te maken, kun je bijvoorbeeld gebruik maken van 10 bits per kleur ipv 8. (De matrox parhelia doet dit bijvoorbeeld.)

offtopic:
De Parhelia doet dat eigenlijk juist niet. Die is net als de meeste andere moderne (op DX8-gebaseerde) kaarten 32-bit, maar gebruikt niet acht bits maar tien bits per kleur. Dat betekent dat er (32 - 3 * 10 =) 2 bits overblijven voor transluency...dat is dus juist veel minder dan bij andere kaarten, die hiervoor acht bits reserveren in een 4 * 8 configuratie .

Hm, op die manier had ik het niet bekeken. Ik dacht namelijk dat die 10 bit voor elk kanaal werd gebruikt, dus ook voor het alfa kanaal. Kennelijk niet dus

quote:

Beelzebubu schreef op 25 March 2003 @ 13:34:
[...]


Als je een mailtje stuurt, wie rendert? De server. Wie stuurt de data? De client. Waarom dan opeens wel?

Doe even niet zo flamerig/kortzichtig...

WTF? Dude, ik gaf alleen maar aan *waarom* mensen het zouden kunnen omdraaien...

*Jouw* vergelijking gaat trouwens echt totaal mank. Ik had het nauwelijks over renderen maar over "ervoor zorgen dat je iets ziet". Dat is dus in jouw geval alsnog je mail client.

Komop Beelzebubu, ben je nu echt zo kortzichtig dat je niet begrijpt dat users datgene wat ze gebruiken om mee naar dingen te kijken (zoals een X server) zien als client en datgene dat levert waar ze naar kijken, zien als server?

Tsss... wil je de fouten van anderen inzichtelijk maken, is het een flame, of erger nog, "kortzichtig"... Social skills lacken wel weer in de OS discussies. ;-)

(N.B.: 1) dit is *wel* een flame. 2) dit is een zinloze discussie; I have no quarrel with thee!)

bahsj, jongen, ik raad je aan even beter te kijken wie je als tegenstander zoekt hier...
Ik durf wel te zeggen dat Beelzebubu niet de minste is hier (understatement) en dat ik (geloof ik, ondanks mijn tekortkomingen op dit onderwerp) meer zie in Beelzebubu's standpunt. Maar goed, het lijkt me bijzonder verstandig als we dit off-topic flame-uitstapje met de mantel der liefde bedekken en verder praten over het onderwerp waarover de draad gaat: de toekomst van X...

Kunnen we ook lief doen tegen elkaar?
Dit is een poging tot discussie, geen poging tot flamewar

quote:

idletoad schreef op 25 maart 2003 @ 10:11:
Omdat X nu eenmaal zo werkt. De server en de client zijn compleet gescheiden, alleen verbonden door een socket (of evt. Shm, maar dat is ook niet fantastisch)... En dus is samenwerking tussen de twee een groot probleem.

Een GUI app op Windows is ook compleet gescheiden, door de mmu hardware op je CPU

Wat is je probleem? Het gebruik van een socket + shm ipv systemcalls? Dat is raar, want een socket + shm is niet per definitie trager dan een systemcall.

quote:

Je mag jezelf wel eens beter informeren...

Nee, jij mag je wat beter uitdrukken. Dit is een discussie over X11 en XFree86. Als jij er dan een Windows-techniek bij sleept, leg dan ook uit waar je het precies over hebt, aangezien je hier niet mag verwachten dat wij meteen weten waar jij het over hebt als je "zoals Longhorn" zegt.

quote:

Misschien wel, maar het had totaal geen informatieve waarde, en droeg niets bij tot de discussie.. Ik kan ook wel gaan roepen "linux is een opensource kernel".
Waarheid als een koe, maar het zegt niets. Beetje meer uitleg mag, samenhang, graag.

Ehm, ik quootte een zin die jij schreef. Als je zelf van mening bent dat het niks zegt, waarom schreef je die zin dan überhaupt?

Ik quootte je en zei dat het evengoed op X van toepassing is juist omdat ik wilde aangeven dat het weinig toegevoegde waarde had.

quote:

Maar die pixmap gaat nu op een texture gemapt worden, in videogeheugen met beperkte opslag.

Dat mag XFree86 dus naar eigen inzicht doen. XFree86 heeft een aantal pixmaps van clients, en een eindige hoeveelheid videogeheugen. Welke pixmaps hij in het videogeheugen mapt en hoe hij dat doet is verder totaal onafhankelijk van het X protocol. Verschillende X servers kunnen dat totaal anders aanpakken.

Hoe XFree86 het exact doet weet ik niet.

quote:

Ja dat weet ik ook wel. Maar aangezien je dezelfde API-calls maakt, heb je daar weinig mee te maken. Het is TRANSPARANT, zoals al tig keer geroepen is. Hoe het geimplementeerd is, maakt niet uit... Je krijgt niet ineens extra functionaliteit en extra samenwerking door een client lokaal te draaien... En daar zit het probleem.

Dat hoeft helemaal geen probleem te zijn. Je hoeft geen extra functionaliteit te krijgen als het lokaal draait. Waar het om gaat is dat, als het lokaal draait, extra acceleratie mogelijk is.

quote:

Wat heb je nu aan non-accelerated 3d? Dan heb je meteen al de bovengenoemde voordelen niet meer (aa etc...).

Je hebt er niks aan, maar ik wilde even aangeven dat netwerk-transparent OpenGL wel mogelijk is. Dat het op dit moment niet accelerated is als het over het netwerk gaat is AFAIK volledig een implementatie-probleem, maar accelerated OpenGL over het netwerk moet ook mogelijk zijn.

quote:

Naja, ik hoor het al, kennelijk heeft nog niemand hierover nagedacht...

En even later klaag je dat andere mensen arrogant zijn? Je kan er zelf ook redelijk wat van.

quote:

dikkebanaan schreef op 25 March 2003 @ 11:13:
Maar die laatste 8 bits worden niet gebruikt dus het is gewoon waardeloos.

Duh, die laatste 8 bits worden in Windows ook nooit gebruikt. Dat komt omdat 32 bpp uitsluitend gebruikt wordt omdat 32-bit aligned adressen makkelijker (sneller) zijn te adresseren door je CPU en je videokaart.

Die laatste 8 bit worden in het video framebuffer niet voor alpha gebruikt.

quote:

Het zou trouwens kunnen dat dit alleen maar het geval is wanneer er een kaart van NVIDIA wordt gebruikt.. (welke geen 24 bpp ondersteund)

En waar baseer je dat op? Uit de XF86Config-4 manpage:

quote:

This sets the pixmap format to use for depth 24. Allowed values for bpp are 24 and 32. Default: 32 unless driver constraints don't allow this (which is rare). Note: some clients don't behave well when this value is set to 24.

Dus: XFree86 gebruikt gewoon 32 bpp, tenzij 32 niet mogelijk is, of je het override naar 24.

quote:

Maar wat ik eigenlijk bedoelde met andere 'kleurmodellen' is bv ondersteuning voor 64, 96 of zelfs 128 bpp.. (en dat gaat uiteraard in de richting van floating point formaten, welke al helemaal niet worden ondersteund in XFree86)

Nee, dat ondersteunt XFree86 inderdaad niet. Ik moet de eerste betaalbare hardware die het kan ook nog zien
Tegen de tijd dat consumenten-videokaarten 48 bpp snappen zal XFree86 dat heus wel gaan ondersteunen hoor.

quote:

jointm1k schreef op 25 March 2003 @ 12:19:
Oja, ik weet het weer hoe het zat: Met 64 en 128 bpp kaarten kun je beter met layers werken. Bv, met photoshoppen of een video programma. Met 64 bbp kaarten kun je namelijk 2 x 32 bits layers op elkaar plempen, en met 128 bpp maar liefst 4! Met een 32 bits kaart kun je natuurlijk ook verschillende lagen video materiaal op elkaar doen, alleen loop je dan de kans dat je tegen een soort kleuren aliasing oploopt. Je kunt die wel ondervangen door de CVE / Conventioneel RAM de kleuren te laten interpoleren naar een 32 bits kleur, maar dat is een heel langdurig karweitje. Je kunt beter gewoon het framebuffer van je videokaart uitrusten voor het werken met verschillende lagen. Gaat een stuk sneller

Volgensmij draaf je een beetje door... AFAIK bieden die grotere colordepths alleen dat: grotere colordepth.

Het (al dan niet met transparency) blitten van textures, pixmaps en meer staat daar los van

quote:

bahsj schreef op 25 March 2003 @ 12:40:
Juist. Je server rendert dus je frame en stuurt die over het trage trage netwerk (niet te vergelijken met je mobo), toch? Dat wordt dus geen, hmm, quake 3 spelen. Of zelfs maar naar friggin' glxgears kijken. Dat is wat ik bedoelde.

Nee.

De X client (glxgears bijvoorbeeld) stuurt de OpenGL data (dus wat gerenderd moet worden) over het netwerk naar de X server (XFree86). XFree86 is dan degene die het rendert. Het wordt dus op de juiste plaats gerenderd, alleen op deze manier niet accelerated. Maar dat moet dus best te implementeren zijn.

quote:

Jeah, hardware overlay iig. Maar scaling weet ik niet zeker, maar zou goed kunnen hoor.

Ik kan in ieder geval op mijn G450 film kijken (met mplayer en gebruik van de Xvideo extensie) met hardware overlay, hardware scaling en hardware colorspace conversion. En tegelijkertijd kan ik DRI gebruiken
En de G400 kan dat afaik ook.

quote:

Option "TexturedVideo" "boolean"
This has XvImage support use the texture engine
rather than the video overlay. This option is only
supported by the G200 and G400, and only in 16 and
32 bits per pixel. Default: off.

Ah, dit zorg er blijkbaar voor dat voor Xvideo de texture engine wordt gebruikt ipv de overlay hardware. Ik weet niet wat dat voor een potentiele voordelen heeft

quote:

Welk programma levert de data? Apache bijvoorbeeld. De server dus. Welk programma zorgt ervoor dat je iets ziet? Mozilla. De client dus.

Dat is irrelevant. Als je met een FTP client upload, dan levert de client ook de data.

In een client-server architectuur initieert de client een connectie, en de server accepteert (of weigert) die connectie. Mozilla connect met Apache. Lftp connect met proftpd. Glxgears connect met XFree86. See?

quote:

XFree86 is dan degene die het rendert. Het wordt dus op de juiste plaats gerenderd, alleen op deze manier niet accelerated. Maar dat moet dus best te implementeren zijn.

Serieus? Lijkt ook nog te kloppen volgens http://dri.sourceforge.ne...ure.html#REMOTE-RENDERING ;-)

Dude, snap prima hoor waarom wat server/client heet bij X, ik gaf alleen antwoord op je vraag "Waarom snapt iedereen dat voor Apache + Mozilla, maar niemand voor XFree86 + gimp ?". Ik vind echt niet dat die naamgeving omver moet, ik kijk wel uit, ik gaf alleen antwoord op je eerdere vraag... ;-) Wat lezen mensen toch slecht af en toe... ;-) Gelukkig maar hoor, anders had ik nog enorm op m'n lazer kunnen krijgen voor de onzin die ik gisternacht opschreef (gauw teruglezen!).

Zit de hardware scaling van mplayer niet in de mga_vid driver? Uit de README ergens:

mga_vid is a kernel module that utilitizes the Matrox g200/g400 video
scaler/overlay unit to perform YUV->RGB colorspace conversion and
arbitrary video scaling.

Dus zou ik niet willen zeggen dat het bij mplayer via xvideo gebeurt, ik neem aan dat je mga_vid gebruikt met je G450? Het zou OOK kunnen via xvideo, maar zoals ik al zei, weet ik dat niet, en mplayer als voorbeeldje gebruiken disambigueert het niet in dit geval ;-) ...

Ja natuurlijk kun je dan ook DRI gebruiken! Huh? Wat een rare linux setup hebben sommigen mensen toch... ;-)

Met texture engine ipv overlay hardware heb je waarschijnlijk het voordeel dat je, well, geen colorkey gekleurde venstertjes meer hebt waar je het blauw van ziet als je ze verplaatst.

Ohja, maar verder over X :-). Ik ben eigenlijk prima tevreden, maar ik heb zo'n 3 jaar geleden m'n graf. kaart ook gekocht op de Linux ondersteuning. Crashes vallen wel mee tegenwoordig, de AA is foeilelijk (gebruiken mensen dat echt? Maar ik vind ClearType wat toch "goed" wordt gevonden ook niet om aan te zien (alleen op een CRT gezien trouwens)). Dus, zoals ik al zei, denk ik dat X wel zo verder kabbelt, en dat vind ik prima. ;-) Keith Packard die aan xrender heeft gewerkt is wel uit de core devs geflikkerd maar ik denk niet dat xrender nu over de kop gaat hoor. Daar is het veel te leuk voor ;-).

Een fork van XFree86 zou ik niet erg vinden, ik vraag me alleen af of Keith genoeg mensen bij elkaar kan krijgen om X een beetje bij te houden. Ik moet er wel niet aan denken dat nvidia of ati moeten kiezen (of 2 verschillende drivers uitbrengen) waar ze hun binary-only drivers voor uitbrengen... Het argument waarom Linus tegen binary-only drivers is gaat dan ook weer op dus.

Dus denken jullie dat het sowieso politiek lukt om X te forken als dat nodig zou zijn? Zijn er voorbeelden te bedenken van andere grote OS projecten die geforkt zijn waar bepaalde vendors voor de een, en andere voor het andere deel kozen? Samba hou ik niet zo bij, maar hoe zit het daar bijvoorbeeld met vendor acceptatie van de (in vriendschap gepleegde) fork? (maar bij samba is de compatibiliteit niet zo'n issue, want compatibiliteitsrelatie is euclidisch (en symmetrisch))

quote:

Van www.xfree.org
Bugzilla for XFree86
[18 March 2003]

XFree86 is proud to announce Bugzilla. The hardware has been generously donated by Hewlett-Packard Company and graciously hosted by netSweng. We encourage to you log both your bugs and enhancement requests there.

Gaat dit ook betekenen dat ze wat opener worden in het accepteren van patches, bugfixes en dergelijke? Want geen bugzilla is een van de argumenten die ik gehoord in de kernel thread meen ik.

Ik hoop wel dat ze eens wat sneller worden met het fixen van bugs, want zelfs security gerelateerde bugs duren vrij lang.

Zo zijn de recent gevonden terminal emulator problemen (window title reporting bug, ed) al lang aan xfree gemeld (rxvt), maar pas recent eindelijk gefixed.

quote:

bahsj schreef op 25 maart 2003 @ 20:04:
Serieus? Lijkt ook nog te kloppen volgens http://dri.sourceforge.ne...ure.html#REMOTE-RENDERING ;-)

Woei, en accelerated remote 3D staat nog op de TODO lijst ook (ik had die hele FAQ nog niet gezien/gelezen).

quote:

Dude, snap prima hoor waarom wat server/client heet bij X, ik gaf alleen antwoord op je vraag "Waarom snapt iedereen dat voor Apache + Mozilla, maar niemand voor XFree86 + gimp ?". Ik vind echt niet dat die naamgeving omver moet, ik kijk wel uit, ik gaf alleen antwoord op je eerdere vraag...

Ik dacht dus dat je er echt problemen mee had

quote:

Zit de hardware scaling van mplayer niet in de mga_vid driver? Uit de README ergens:

mga_vid is a kernel module that utilitizes the Matrox g200/g400 video
scaler/overlay unit to perform YUV->RGB colorspace conversion and
arbitrary video scaling.

Dus zou ik niet willen zeggen dat het bij mplayer via xvideo gebeurt, ik neem aan dat je mga_vid gebruikt met je G450? Het zou OOK kunnen via xvideo, maar zoals ik al zei, weet ik dat niet, en mplayer als voorbeeldje gebruiken disambigueert het niet in dit geval ;-) ...

Oh, ik had helemaal niet aan mga_vid gedacht, maar ik zei wel expliciet dat ik Xvideo gebruikte... Het is dus alleen ambigu als je aan mijn woorden twijfelde. En dat doe je niet, toch?

Maar anyhow: nee, ik gebruik mga_vid niet. Ik gebruik gewoon de Xvideo extensie (via mplayers sdl output driver btw), en de standaard bij XFree86 geleverde mga drivers. Xv werkt dus ook in andere apps (die het gebruiken...)

quote:

Met texture engine ipv overlay hardware heb je waarschijnlijk het voordeel dat je, well, geen colorkey gekleurde venstertjes meer hebt waar je het blauw van ziet als je ze verplaatst.

Oh, idd. Stom dat ik daar niet aan dacht. Niet dat dat zo'n killer voordeel is, maar toch.
Trouwens: nog iets. Volgensmij is met de standaard overlay hardware maar één overlay mogelijk. Je kan dan dus niet in twee windows tegelijk gebruik maken van Xvideo. Via de texture engine misschien wel.

quote:

Ohja, maar verder over X :-). Ik ben eigenlijk prima tevreden, maar ik heb zo'n 3 jaar geleden m'n graf. kaart ook gekocht op de Linux ondersteuning. Crashes vallen wel mee tegenwoordig, de AA is foeilelijk (gebruiken mensen dat echt? Maar ik vind ClearType wat toch "goed" wordt gevonden ook niet om aan te zien (alleen op een CRT gezien trouwens)). Dus, zoals ik al zei, denk ik dat X wel zo verder kabbelt, en dat vind ik prima. ;-) Keith Packard die aan xrender heeft gewerkt is wel uit de core devs geflikkerd maar ik denk niet dat xrender nu over de kop gaat hoor. Daar is het veel te leuk voor ;-).

Ik ben ook redelijk tevreden over XFree86 zoals het hier draait. Crashes zijn extreem zeldzaam, zowel op mijn desktop (G450) als op mijn laptop (ATi rage mobility ding).

Maar dat wil niet zeggen dat XFree86 niet voor verbeteringen vatbaar is. Dat accelerated remote 3D is iets dat nog op de Todo lijst staat. XRender moet nog véél aan gebeuren. XFree86 verdient op bepaalde vlakken een complete rewrite (want sommige dingen kunnen echt nog wel efficienter). Betere drivers is (ikzelf heb dan weinig te klagen, maar dat gaat natuurlijk niet op voor alle drivers) ook iets dat aandacht verdient. XRandR is nog niet af, en zelfs dat is al relatief laat. En XFree86 mag van mij compleet on-the-fly gereconfigd kunnen worden, maar dat zit er voorlopig ook niet in.

En dat zijn dan nog de dingen die imho moeten gebeuren. Dat zijn nog niet eens de experimentelere dingen. Zo heeft XFree86 afaik interne scheduling problemen. Er is al meerdere malen een nieuw thread-per-client model voorgesteld, maar daar gebeurt (bij gebrek aan mankracht volgensmij) niks mee. En zo'n model zou zeker interessant zijn, zeker in combinatie met Linux 2.6.

Er is dus nog genoeg te doen, maar op het tempo waarmee het op dit moment gaat duurt het gewoon lang, erg lang. En dat is zonde. Daarom vind ik het wel prettig dat er nu aandacht aan geschonken wordt.

quote:

Een fork van XFree86 zou ik niet erg vinden, ik vraag me alleen af of Keith genoeg mensen bij elkaar kan krijgen om X een beetje bij te houden. Ik moet er wel niet aan denken dat nvidia of ati moeten kiezen (of 2 verschillende drivers uitbrengen) waar ze hun binary-only drivers voor uitbrengen... Het argument waarom Linus tegen binary-only drivers is gaat dan ook weer op dus.

Wellicht is het netter om de drivers kernelside te doen, en de mogelijkheden via een framebuffer en DRI device (ofzo) aan userland apps aan te bieden. Dan kan XFree86 gewoon van fbdev + DRI gebruik maken voor het displayen, en zich voor de rest totaal richten op het X protocol (plus extensies) en andere zaken.

Bijkomend voordeel is dan dat je niet vastzit aan XFree86 voor de drivers. Niet dat ik een fan ben van binary drivers (allesbehalve dat).

quote:

Dus denken jullie dat het sowieso politiek lukt om X te forken als dat nodig zou zijn?

Ja, ik denk van wel. Er zullen uiteraard mensen op hun tenen getrapt zijn, maar ik denk dat er genoeg mensen blij zouden zijn met één of meerdere open projecten waar vrijer aan gewerkt kan worden en meer geexperimenteerd kan worden. Maar ik kan er uiteraard naast zitten.

Een oplossing waarin, zonder fork, fijn met XFree86 verder wordt gegaan onder een opener development model juich ik overigens ook toe. Meer nog dan een fork.

quote:

MadEgg schreef op 25 March 2003 @ 20:47:
Gaat dit ook betekenen dat ze wat opener worden in het accepteren van patches, bugfixes en dergelijke? Want geen bugzilla is een van de argumenten die ik gehoord in de kernel thread meen ik.

Het lijkt iig een stap in de juiste richting

Hier staat een commentaar van Steve Swales, voorzitter van X.Org. Kon het niet zo snel vinden hierboven. Enjoy

Het heeft geen zin te reageren op replies van idletoad. Deze clone is inmiddels gebanned en kan dus niet meer reageren. Ik heb daarom een aantal replies getrashed. Graag op een vriendelijke manier verder discussieren

Waarom neemt Linus er niet een standpunt in? Ze zouden de drivers gewoon naar de kernel moeten verplaatsen en dat ze door producenten worden aangeleverd, zoals Nvidia dat nu ook al doet. Implementeer gewoon een deel in de kernel.. krijgt het zoiezo meer aandacht en dan kunnen ze zich wat meer op wat andere dingen focusen....

DRI zit toch in de kernel?

Het probleem is volgens mij dat je dan applicatie-specifieke code (X is geen onderdeel van Linux!) in de kernel gooit, Linus is daar niet zo dol op, volgens mij...

quote:

Beelzebubu schreef op 27 maart 2003 @ 18:18:
DRI zit toch in de kernel?

Het probleem is volgens mij dat je dan applicatie-specifieke code (X is geen onderdeel van Linux!) in de kernel gooit, Linus is daar niet zo dol op, volgens mij...

Wordt dat niet al veel langer gedaan (of ligt dit misschien aan mij)
Voornamelijk bij hardware support progs ed (alsa ed), kan aan mij liggen hoor, ben niet echt bekend met dit soort zaken