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

[deadinspace]

XFree86 heeft veel kritiek ontvangen voor het gebrek aan openheid dat het XFree86 developers team er op na hield. Doordat de ontwikkeling van XFree86 erg besloten was, was het vaak een langdurig proces voor externe developers om patches in XFree86 te krijgen.

Sinds enkele jaren (?) is hier een klein beetje verandering in gekomen, en nu lijkt er aanzienlijk meer verandering in te komen. Keith Packard (XFree86 core developer) zocht naar mogelijkheden tot een fork - iets dat de rest van het XFree86 team niet beviel. Toen Packard op eigen houtje zonder overleg met de rest van het team een bepaald deel van XFree86 aanpaste is hij uit het XFree86 core team gezet.

Dit conflict lijkt in ieder geval (direct of indirect) het gevolg te gaan hebben dat XFree86 development opener gaat worden. Meer developers laten zich nu horen en klagen over de geslotenheid van het XFree86 core team, waardoor zij hopenlijk hun development model wijzigen. Als ze dit niet doen, dan schat ik de kans dat Packard (of iemand anders) daadwerkelijk een fork start reëel in.

nieuwsartikel
KDE en Gnome developers' standpunt
Nieuwe, open ( :) ), XFree86 mailinglist voor discussie over X en XFree86
Discussie over X11 model

Heb je aanvullende informatie, of een (beargumenteerde) mening over deze affaire of X of XFree86 in zijn algemeen? Brand los

---

Ook is er in Kernel 2.5.x draadje.... een discussie op gang gekomen over XFree86 en het algemene desktop op GNU/Linux gebeuren. Aangezien die discussie nauwelijks nog aan de kernel gerelateerd is wil ik die discussie graag hierheen verplaatsen, want dit is een veel betere plaats om naar hartelust daarover te discussieren.

Ik zal hieronder de relevante posts uit het kernel-draadje herhalen, zodat de discussie makkelijk voortgezet kan worden.

Tot slot even het volgende: haal het X Window System (protocol) en XFree86 (implementatie) aub niet door elkaar, dat leidt altijd tot veel verwarring. Danku

[deadinspace]

---

link dikkebanaan schreef op Saturday 22 March 2003 17:50

Anoniem: 27915 schreef op 13 March 2003 @ 19:22:
Like? .

XFree doet alle soorten acceleraties die er zijn, maar omdat de interface en structuur wat moeilijk lijkt vinden mensen het kut. Heb je nou al eens werkelijk tests gedaan of het sneller zou worden als je een directe local-only blabla windows-achtige GUI bouwt? Wordt het sneller? Ligt dat aan X?

Een van de manieren om dit sneller te maken is directfb, maar dat is geen optie voor een X server. Directfb zou een X extensie kunnen zijn, maar voor de rest kan X zoveel meer... Die tiende van een duizendste van een seconde kan mij dan echt geen ruk schelen...

Ik had dit nog niet gelezen maar zou hier toch nog even op willen reageren, ook al is het offtopic (misschien moet er een XFree86 draadje worden geöpend?).

Een paar die ik nu snel kan bedenken:

- Brakke muis deceleratie
- Geen ondersteuning voor bv andere kleurmodellen (blegh, 32 bpp fb wordt niet eens normaal ondersteund)
- XFree86 zal in dit tempo hopeloos achterlopen wanneer de rest van de wereld over gaat op een UI die gebruik maakt van de 3d hardware (zie OS X en Longhorn)
- Tekenen van wm/app is brak (ie. zoals al eens vaker is uitgelegd door Havoc Pennington zou XFree86 alles in 1 stap, of eigenlijk op een manier tekenen waarop de gebruiker niet ziet dat de wm + app 2 verschillende onderdelen zijn)

Maar het ergste vind ik eigenlijk toch wel dat de meeste van die zgn 'core developers' van XFree86 tegenwoordig alleen nog maar op hun reet zitten toe te kijken, zitten te zeiken over politiek spul en tegenwoordig nooit meer een enkele regel code schrijven voor XFree86.
Een van deze core developers is zelfs overgelopen naar Windows (!) ik begrijp echt niet wat die kerel (en de andere 'backseat developers') in zo'n team zoekt als ie toch liever andere software gebruikt (zoals is aangegeven door hem zelf) en ook al een hele hoop jaren *niets* meer heeft gedaan om XFree86 vooruit te helpen..

_{(hier wordt btw op dit moment ook over gediscussiëerd op een nieuwe mailing list @ xfree86.org, naar aanleiding van het eruit schoppen door het core team van de enige developer die _wel_ veel deed om XFree86 te verbeteren)}

Het gaat mij iig helemaal niet meer om de snelheid op dit moment, dat zit wel goed wanneer de (1-na-laatste) closed source driver van NVIDIA wordt gebruikt (ik weet niet hoe stabiel/snel die van ATi is?)

---

link Beelzebubu schreef op Saturday 22 March 2003 21:27

Anoniem: 53023 schreef op 22 maart 2003 @ 17:50:
- XFree86 zal in dit tempo hopeloos achterlopen wanneer de rest van de wereld over gaat op een UI die gebruik maakt van de 3d hardware (zie OS X en Longhorn)

Dat is een applicatie kwestie, niet een X kwestie...

- Tekenen van wm/app is brak (ie. zoals al eens vaker is uitgelegd door Havoc Pennington zou XFree86 alles in 1 stap, of eigenlijk op een manier tekenen waarop de gebruiker niet ziet dat de wm + app 2 verschillende onderdelen zijn)

Double buffering, bedoel je? Eens.

Maar het ergste vind ik eigenlijk toch wel dat de meeste van die zgn 'core developers' van XFree86 tegenwoordig alleen nog maar op hun reet zitten toe te kijken, zitten te zeiken over politiek spul en tegenwoordig nooit meer een enkele regel code schrijven voor XFree86.
Een van deze core developers is zelfs overgelopen naar Windows (!) ik begrijp echt niet wat die kerel (en de andere 'backseat developers') in zo'n team zoekt als ie toch liever andere software gebruikt (zoals is aangegeven door hem zelf) en ook al een hele hoop jaren *niets* meer heeft gedaan om XFree86 vooruit te helpen..

Mjah, I know... Kutzooi aldaar... Zegt op zich weinig over X, meer over de XFree86 devvers... .

Waar ik bang voor ben, is dat bedrijven als ATI en nvidia heel lang zullen achteroverleunen qua commerciele driver development als de X standaard wordt weggegooid. Dat is toch het belangrijkste wat er nodig is om commerciele bedrijven zover te krijgen Linux te supporten...

En wees eerlijk, die opensource nv drivers zijn peanuts vergeleken met de nvidia drivers, geen discussie mogelijk...

---

link odysseus schreef op Saturday 22 March 2003 21:32

Anoniem: 27915 schreef op 22 maart 2003 @ 21:27:
Dat is een applicatie kwestie, niet een X kwestie...

Als je elke applicatie zijn eigen communicatie met 3D-hardware wilt laten uitvoeren, dan mag je, maar mij lijkt het niet handig . Natuurlijk kan een programma indien nodig SDL en dergelijke gebruiken, maar dat is duidelijk iets anders. Om zoiets echt te integreren, zou ik het liever op het niveau van X geïmplementeerd zien dan binnen KDE of Gnome. Tenslotte heeft XFree86 de benodigde hardwaretoegang, die bovenopliggende programma's niet altijd even makkelijk krijgen.

---

link Beelzebubu schreef op Sunday 23 March 2003 03:51

odysseus schreef op 22 March 2003 @ 21:32:
Als je elke applicatie zijn eigen communicatie met 3D-hardware wilt laten uitvoeren, dan mag je, maar mij lijkt het niet handig . Natuurlijk kan een programma indien nodig SDL en dergelijke gebruiken, maar dat is duidelijk iets anders. Om zoiets echt te integreren, zou ik het liever op het niveau van X geïmplementeerd zien dan binnen KDE of Gnome. Tenslotte heeft XFree86 de benodigde hardwaretoegang, die bovenopliggende programma's niet altijd even makkelijk krijgen.

Maar die interface is er al lang. openGL.

---

link dikkebanaan schreef op Sunday 23 March 2003 14:03

Anoniem: 27915 schreef op 22 March 2003 @ 21:27:
Dat is een applicatie kwestie, niet een X kwestie...

Ik heb het over een _widget toolkit_ die direct gebruik maakt van de hardware.
Dan bedoel ik dus dat Gtk en Qt dat moeten doen, niet de applicatie zelf ^[1]

Double buffering, bedoel je? Eens.

Dat zou idd een van de (beste) manieren wezen om dat probleem helemaal uit de wereld te helpen.
Voorlopig wordt er nog een hoop gehackt.. (zie xsync patches voor Gtk2/Metacity)

Mjah, I know... Kutzooi aldaar... Zegt op zich weinig over X, meer over de XFree86 devvers... .

Tjah.. het is te hopen dat er een fork komt.. die core developers lopen alleen maar uit hun (al dan niet virtuele) neus te vreten.

Waar ik bang voor ben, is dat bedrijven als ATI en nvidia heel lang zullen achteroverleunen qua commerciele driver development als de X standaard wordt weggegooid. Dat is toch het belangrijkste wat er nodig is om commerciele bedrijven zover te krijgen Linux te supporten...

En wees eerlijk, die opensource nv drivers zijn peanuts vergeleken met de nvidia drivers, geen discussie mogelijk...

btw. Lees dit stukje text van 9 Januari ook eens door (nog meer sappige roddels en achterklap ):
http://www.advogato.org/person/mharris/


[1] Meer:

Anoniem: 27915 schreef op 23 March 2003 @ 03:51:
[...]


Maar die interface is er al lang. openGL.

Je dacht toch niet echt dat mensen hun progs allemaal gaan maken op de 'Blender manier'?

---

link Beelzebubu schreef op Sunday 23 March 2003 16:45

Hoe bedoel je? Er is een openGL extensie in X, er zijn GtkGL widgets (er is vast ook een QtGL widget)... Wat wil je nog meer dan? Een toolkit die jouw gedachten uitleest en daar automatisch bugloze code van maakt? Ik dacht dat we die academische prutzooi (Linus: "build a solution so much around the problem it addresses so, that it will face the same problems that the original solution did address") toch wel genoeg hadden bediscussieerd nu...

Wat willen jullie nou dan?

[Anoniem: 60780]

Ik vind sommige kritiek op XFree86 wel terecht. Een daarvan is de bloat factor. Het is iets van 70 MB en daarmee groter dan Win95. En wat is dat nou allemaal met die ingebouwde raster fonts? Compleet wazig als je het mij vraagt . Nee, waar ik mijn hoop op vestig is Fresco. Ondersteunt alpha transparantie, is netwerk transparant door gebruik van CORBA technieken en niet onbelangrijk: het is heel behoorlijk gedocumenteerd.

[Anoniem: 27915]

Ik zal eens een meninkje geven, wordt ook wel tijd dat ik eens minder vaag ben...

Allereerst, X is allerminst perfect. Het heeft grote tekortkomingen en die moeten worden aangepakt.

Echter, X is al jaren de standaard grafische platform van Unix/Linux. Elke applicatie draait onder X. Alles draait onder X. Alles is X. Alles - zowel closed-source als open-source. Met name die eerste groep zal een probleem worden als je van X afstapt, zoals elke move van A naar B problemen met zich meebrengt. Door de belangrijkheid van X is dit zo goed als onmogelijk. Ook gezien de groeiende groep aan closed-source drivers (anders gezegd: het groeiende aantal fabrikanten die eindelijk zelf drivers schrijft in plaats van het door de opensource community laat doen) zie ik een move niet gebeuren: je raakt het stabiliteitsvertrouwen van die fabrikanten kwijt, en hun drivers. Dat wil niemand. Kortom, van X afstappen is bijzonder ongewenst. Teveel negatieve zij-effecten.

Liever zou ik doen wat Havoc Pennington ook al langer voorstelt en implementeert: X extensies om de tekorten op te vullen, met behoud van API/ABI compatibility. Op termijn kunnen deze extensies hetzelfde als wat een volledig nieuw platform zou kunnen.

Het enige probleem wat dan nog overblijft is de bloat van de X API en de libs. Qua libs is dit onzin, omdat het dynamically loaded crap is, dus het neemt alleen HD space in. Qua API: get used to it, X is niet voor de random developer, X is voor experts. Kernel coden is ook niet voor iedereen weggelegt. Troll intended. Serieus: je moet niet verwachten dat iedereen low-level kan gaan coden, dat is veel te makkelijk gedacht. De meeste mensen hebben dat ook niet nodig, Gtk+ (Qt) of desnoods zelfs Gnome (KDE) app development biedt meer dan genoeg mogelijkheden. Zelfs met Glade kom je al een behoorlijk eind.

Kortom: X is verre van perfect, maar X afschuiven is onzinnig. X perfectioneren is veel handiger dan volledig overnieuw beginnen. Uiteindelijk kom je in je nieuwe design problemen tegen die X al jarenlang geleden heeft opgelost, als variant op Linus Torvalds' flame op academische professoren met hun nieuwe oplossingen voor problemen die zo gecentreerd zijn rond dat ene probleem dat ze in tientallen andere kuilen vallen die door de originele oplossingen netjes werden opgelost. Moraal van het verhaal: kijk eerst of je het met de originele oplossing en/of een uitbreiding daarop kan oplossen. Redesignen is meestal niet nodig.

[odysseus]

Op het moment heb ik even niet de tijd om mijn mening volledig te onderbouwen, maar waar het op neerkomt is het volgende: op zich is XFree86 niet verkeerd (en is X11 ook niet verkeerd, al zou een backward-compatible X12 waarschijnlijk geen gek idee zijn), maar het development model is fout. Er zijn een stuk of wat mensen die schrijftoegang hebben tot de sources en die mensen kunnen maar een bepaalde hoeveelheid werk verrichten. Voorheen was het niet eens mogelijk om mailinglists te bekijken en zelf een developer worden kon je ook wel vergeten. Hoewel het project in naam wel een Free Software-project is, heeft het *te* veel trekjes van de Cathedral-style ontwikkeling. Keith Packard probeert daar iets aan te veranderen, maar slaagt er niet in. Zelf heb ik het idee dat hij wat teveel op die board-structuur focust, maar voor de rest lijk ik het wel met hem eens te zijn...hij heeft in ieder geval de afgelopen twee jaar het meeste zichtbare werk gedaan, dus hij verdient krediet als hij zegt dat er iets mis is. De ontwikkeling van XFree86 schiet door het kunstmatig veroorzaakte tekort aan core-developers niet op. In zo'n sfeer krijg je nooit een echt goede, moderne implementatie van X11.

* odysseus zou een volledig open ontwikkelde XFree86 willen zien, ongeveer op een manier zoals de kernel ontwikkeld wordt...een stabiele tak, maar zodra iemand dat wil ontstaat er toch meteen een zijstroom die vernieuwing brengt .

_{Goed idee dit topic, hier is best veel over te discussiëren .}

[FCA]

Inderdaad, de voortgang is veel te traag. Voorbeeld: ati-driver patches, van ati nota bena, worden gewoonweg genegeerd.
tekst

Verder vind ik het als niet-programmeur raar dat er geen DRI gelijktijdig met Xinerama kan werken.
Dat doet mij vermoeden dat beiden hele vieze hacks zijn, en dat daar nodig eens naar gekeken moet worden.
Na alles wat ik heb gelezen ziet het er uit als XFree86 aan knulligheid ten onder gaat.
Ze zouden goed moeten kijken hoe andere grote open-source projecten te werk gaan, zoals Gnome, KDE, de Linux-kernel, en veel meer contact moeten zoeken met de bedrijven die open-source ondersteunen, want velen van hun hebben er veel baat bij dat er een goede X server is.

[Anoniem: 78614]

Ik vraag me af hoe een Longhorn-achtig iets zou moeten werken met X.
De textures zitten in de applicatie, aan de client-side, en de acceleratie-hardware zit aan de server-side.
Moeten alle textures dan van te voren maar de server ingepompt worden? Zo ja, hoe gaat het texture-management werken dan? De clients weten niets van elkaar, en de server weet eigenlijk niets van de clients...
Ik vind OpenGL op X al een enorme hack, maar dat is in de regel beperkt tot een enkele applicatie tegelijk...
Hoe meerdere (in principe niet-lokale) clients tegelijkertijd een accelerated UI moeten gebruiken, is me totaal niet duidelijk.
Ik denk dat een Longhorn-achtig iets niet mogelijk zal zijn met het huidige X-model.
Is hier al over nagedacht door iemand?

[LollieStick]

Ik dacht dat XFree ook gewoon onder de GNU Public License viel? Dan mag iedereen de code toch aanpassen en modificeren zolang de copyright info maar vermeld staat?

Ik kan het mis hebben, maar als dat zo is en XFree houdt zich daar op deze manier niet aan, vind ik dus dat XFree dit geen GPL mag noemen. Je kunt het inzien maar daar houdt het mee op.

Ik vind het een slechte zaak...

[Anoniem: 27915]

De meeste acceleraties werken alleen lokaal. . Die werken dus niet via het client-/server-model.

[wizz33]

Mijn mening

Ik volg de de nieuwe forum@xfree86 mailingslist sins het op slashdot/linux today stond.

Die list heel intressant maar ik krijg de indruk dat bepaalde "core" devs het lieftst niks zouden veranderen, ze blijven maar het zelfde roepen, terwijl "honderdden" anderen ze probeeren om te praten.

Er gebeurd niks met de O zo belanrijke CVS-write acces, er staan ongeveer 10 posts van mensen die hun eigen CVS hebben draaien en zeker langer dan een jaar onderhouden en verbeteren. Het "core" team denkt er met niet eens aan om die CVS rechten te geven.

[kroeske]

ik ben absoluut geen kenner en ook geen devver, maar waarom wordt er niet een nieuw initiatief gestart op basis van de huidige Xfree86 code door devver die wel willen ontwikkelen/verbeteren? want wat ik nu lees is gewoonweg dat de core developers niet meer willen developen... (of zie ik dat verkeerd?)

[Anoniem: 59235]

Ach sweet sweet XFree86. Iemand zei ooit tegen me dat glibc "the source of all things good and evil" was. XFree86 is net zo'n project. Gigantisch. Oud. Gebonden aan afspraken, standaards en protocollen. De hele Open Source wereld zit vol met erorme, organisch gegroeide superprojecten waar niemand meer zonder kan. Soms wordt er gesnoeid (mozilla) soms wordt het redelijk in de hand gehouden (linux kernel).

We kunnen niet zonder XFree86; Fresco draai ik wel op m'n Hurd bak en de "core developers" oid nemen deze halve ``revolutie'' heel serieus; d'r is nog nooit zoveel veranderd op xfree86.org in zo'n korte tijd ;-).

Ik heb trouwens een hele tijd losse xfree86 bomen uit de DRI-tree getrokken voor hardware acclde drivers voor m'n G400, ging prima. Toen gebruikte ik net 3 maanden Linux.

Hoe dan ook, het komt allemaal wel goed. XFree86 heeft z'n onhebbelijkheden (ladingen vage x progjes die niemand gebruikt, rare toolkits en vast nog veel engere dingen) maar om nu te schreeuwen dat alles drastisch anders moet vind ik ook wat overdreven (niet dat iemand dat hier doet hoor, maar je hoort op slashdot wel eens wat).

Het komt uiteindelijk wel goed met X, echt waar. Al deze aandacht heeft het project trouwens heel erg veel goed gedaan, XFree86 komt vast (net als mozilla) weer in de publieke gratie.

Ohja, voor LinuxUser en iedereen diie het niet met me eens is, hier is de licence van de code: http://www.xfree86.org/legal/licence.html

Ga je gang. Veel plezier.

[Anoniem: 78614]

De meeste acceleraties werken alleen lokaal. . Die werken dus niet via het client-/server-model.

Erm dat is mijn punt toch ook? Dat die acceleraties niet kunnen werken als de client en server gescheiden zijn (en dat zijn ze in feite ook op hetzelfde systeem, want X is een client-server model)... Of wat bedoel je nou?

Laat ik es een voorbeeld geven...
Client a heeft een translucent window... Dit tekent hij op een texture, en upload het naar de server...
De server komt nu in geheugenproblemen... Hoe weet hij nu of hij de texture van client a uit moet swappen, of iets anders?
Hoe weet hij welke applicatie niet in gebruik is, en waarschijnlijk niet gebruikt zal worden?
En dan nog... Zal de server niet een enorme opslagplaats van redundant textures met UI-componentjes etc worden?
Of moet hij iedere keer de client opnieuw de zaak laten uploaden? En wordt dat niet teveel overhead van allerlei callbacks en geheugentransfers die niet nodig zijn? Etc....

Kortom, hoe ga je dat in godsnaam doen?
En als je het niet gaat doen, hoe ga je concurrentie met Longhorn, OS X etc aan?

[ Voor 54% gewijzigd door Anoniem: 78614 op 25-03-2003 01:02 ]

[Anoniem: 59235]

Beelzebubu bedoelde dat niet alles in XFree86 via een client/server model werkt en heeft daar gelijk in.

[Anoniem: 78614]

Beelzebubu bedoelde dat niet alles in XFree86 via een client/server model werkt en heeft daar gelijk in.

Ja, bv de OpenGL-hack, bedoel je?... maar daar heb ik het nu niet over... Ik heb het nu over een 3d-accelerated GUI, die compatible met X is... Hoe ga je dat doen?
Of waar hebben jullie het over? Jullie treden niet bepaald in detail ofzo...

[Anoniem: 59235]

Ja bv, of xvideo AFAIK.

OpenGL is niet zo'n hack hoor, ik kan nml. wel gewoon meerdere hardware geaccelde venstertjes draaien. Ik geloof zelfs dat tegenwoordig xinerama + dri werkt (maar dat weet ik niet zeker).

Anyway, het lijkt wel alsof je iets moeilijkers wil dan hoeft. Niemand *wil* een 3D-accelerated UI die netwerk transparant is. Gewoon allemaal local doen, zoals opengl gewoon al werkt met xfree86.

Ik geloof wel dat er ooit werd gewerkt aan netwerk transparante opengl dingen, maar geweldige framerates krijg je toch niet over je netwerkje.

Als je vraag is "Ik heb het nu over een 3d-accelerated GUI, die compatible met X is... Hoe ga je dat doen?" en met "compatible met X" bedoel je "netwerk transparent" dan is het antwoord heel eenvoudig: niet.

-[edit] typos

Misschien is dit meer wat je bedoelt? http://www.3dwm.org/frameset.html (3D window manager)

-[edit] link

[ Voor 15% gewijzigd door Anoniem: 59235 op 25-03-2003 01:25 ]

[Anoniem: 78614]

Ik bedoel niet dat het netwerk-transparant moet zijn... maar dat compatibiliteit met X betekent dat je vast zit aan het client-server model (in dit model wordt er geen onderscheid gemaakt tussen het al dan niet lokaal zijn van de client).

OpenGL werkt niet 'met xfree86'... OpenGL hackt een windowtje in xfree86 en tekent daar vrolijk lokaal doorheen... De server weet daar eigenlijk weinig of niets van...
Bij een 3d-accelerated UI is het verhaal dus behoorlijk anders.

Ik vraag me dus af wat de plannen zijn voor 3d-accelerated versies van X...
Want zoals het systeem nu werkt, zie ik geen mogelijkheid om het efficient te implementeren. Hooguit via een hoop redundancy en wat heuristics... maar dat gaat het natuurlijk niet redden tegen elegante oplossingen van Longhorn/OS X...

edit: Nee, 3dwm is niet wat ik bedoel... Ik bedoel een systeem zoals Longhorn, waarbij de gehele GUI via 3d-hardware geaccelereerd wordt (aa, scaling, blitting, scrolling, alphablend etc... alles kan met de moderne hardware). Het blijft echter wel gewoon een 2d-UI (specifieke 2d-hardware zal verdwijnen, en de 3d-pipelines nemen alle functionaliteit over... Longhorn wil dus ook maar meteen GDI door Direct3D vervangen, om overbodige drivers/emulatielayers te vermijden).

[ Voor 24% gewijzigd door Anoniem: 78614 op 25-03-2003 01:33 ]

[Anoniem: 59235]

idletoad, je bedoelt dus *wel* netwerk transparant. Misschien is mijn term wel verkeerd, maar "netwerk transparant" wil afaik zeggen dat het voor het werken van het gebeuren niet uitmaakt of er een netwerk zit tussen server en client. Wat dus hetzelfde is als "in dit model wordt er geen onderscheid gemaakt tussen het al dan niet lokaal zijn van de client".

Je kunt wel heel denigrerend zeggen dat "OpenGL een windowtje hackt", maar wil je het met enige snelheid doen, dan moet het voor zover ik weet ongeveer zo.

Waarom zou in hemelsnaam xfree86 zich druk moeten maken om een uitbreiding van het X protocol (wat jij in feite voorstelt) waar niemand op zit wachten, wat politiek veel te lastig is, en wat TOCH niet werkt omdat je netwerk daar ongeschikt voor is... (hoe jij je het voorstelt gooi je bv. vectoren/textures/etc/etc over het netwerk (of door een lokale socket) om daar aan de andere kant iets 3Digs van te renderen heh?)

Als MacOSX en Longhorn *wel* onderscheid maken tussen het al dan niet lokaal zijn van de client, waarom zou xfree86 dat niet mogen? Ja, als je het vergelijkt met hoe het tot nu toe ging bij X servers, dan is er een breuk ja. Nou en?

Of, als je hier geen genoegen mee neemt, dan wil ik best wel antwoorden dat ik werkelijk geen flauw idee heb of er plannen zijn voor een "3d-accelerated versies van X" (met "X", en "3d-accelerated" met een betekenis naar keuze) en al helemaal niet hoe dat dan zou moeten.

-[edit. Dit: (zou een nieuwe post moeten zijn) ]

(aa, scaling, blitting, scrolling, alphablend etc... alles kan met de moderne hardware).

Aah! Maar dan heb je vooral veel client side dingen! Dan hoef je helemaal niet het X protocol (totaal ;-)) om te gooien! Render clientside je fonts of je whatever aa-ed, of alphablended, op eventuele aanwijzingen van je x server...

Of je nu 8bits kleur doorstuurd of 24+8 (laatste 8 als aphachannel bv) maakt in feite voor je protocol niet uit, zolang je maar genoeg bandbreedte hebt... en dat wordt bij dat soort aantallen wel een beetje een probleem...

Hehehe, het is laat ja, het is laat. Maar nu begrijp ik eindelijk wat je bedoelt. Toch iets wat lijkt op http://www.fresco.org/.

Tsja, ik denk niet dat dat er ooit van komt. Ik denk eerder dat er een beetje doorgehannest gaat worden zoals het nu gaat. Gewoon, optioneel de font rendering over laten nemen door een bepaalde extensie, of optioneel de scaling laten doen door de 3d cap. van je video kaart. Voor een deel kunnen dit soort dingen al, ik kan met mijn G400 de XTexture extensie gebruiken voor xvideo dingen, ipv xvideo, dan scalet ie dus hardwarematig. Nadeel wel is dat dri dan niet meer werkt, dus het is vrij zinsloos als je af en toe opengl wil gebruiken.

Als je alleen wil aa-en, of scalen, of blitten, of scrollen, waarom haalde je dan die hele client/server dingen d'r bij? Dit soort dingen MOETEN toch clientside, en ALLEEN clientside? (Oef, tijd voor een link naar een rant van jwz over die achterlijke client/server nomenclatuur bij X, want ik geloof dat ik het nu heel erg fout doe, dus draai client/server maar om... )

[ Voor 42% gewijzigd door Anoniem: 59235 op 25-03-2003 02:54 ]

[deadinspace]

Ik zal op een aantal reacties reageren, maar eerst even mijn mening over dit hele gedoe:

Het X Window System kan nog prima mee. Eens zal het opgevolgd moeten worden door iets moderners, maar dat is op dit moment (of de komende 5 à 10 jaar) naar mijn mening absoluut niet nodig. Het X protocol is duidelijk flexibel gebleken, en extensies à la MIT-SHM, GLX, Xvideo, XRandR, XRender hebben bewezen dat X11 hiermee succesvol aan te passen is aan nieuwere hardware en software-eisen.

Maar dan is een fatsoenlijke X server natuurlijk wel een eis. En daar schort het af en toe wat aan. XRender belooft gaaf te worden, en heeft de potentie heel veel nieuws te bieden, maar een gedeeltelijke hardware-accelerated implementatie hiervan is gepland voor XFree86 5.0, waarvan het nog niet eens duidelijk is wanneer die gaat verschijnen. Dat schiet niet op.

XFree86 development heeft een schop nodig. Een fork zou denk ik zo slecht nog niet zijn. De fork wordt dan waarschijnlijk veel opener, en veel experimenteergrager. XFree86 kan zich dan aanpassen en meegaan (waardoor beide projecten van elkaar kunnen profiteren, desnoods via een experimental - production symbiose), of XFree86 kwijnt zachtjes weg terwijl de fork het overneemt.

Anoniem: 53023 schreef op 22 March 2003 @ 17:50:
- Geen ondersteuning voor bv andere kleurmodellen (blegh, 32 bpp fb wordt niet eens normaal ondersteund)

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 het ergste vind ik eigenlijk toch wel dat de meeste van die zgn 'core developers' van XFree86 tegenwoordig alleen nog maar op hun reet zitten toe te kijken, zitten te zeiken over politiek spul en tegenwoordig nooit meer een enkele regel code schrijven voor XFree86.

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.

Anoniem: 60780 schreef op 24 maart 2003 @ 22:49:
Ik vind sommige kritiek op XFree86 wel terecht. Een daarvan is de bloat factor. Het is iets van 70 MB en daarmee groter dan Win95.

Iets minder dan dat hoor
XFree86 + xlibs + allerlei fonts + xclients-base is 35 MB. Alleen XFree86 + xlibs (wat basaler) is 15 MB. En dat is dus inclusief drivers voor honderden videokaarten. Kon erger dus.

Nee, waar ik mijn hoop op vestig is Fresco.

Fresco is voor XFree86 wat de HURD is voor de Linux kernel.

Fresco is in design eleganter (al trek ik hun "wij dicteren de widgetset" idee in twijfel). Vooral het idee om alles zo vector-based mogelijk op te bouwen ipv pixel-based is zeer interessant en kan in de toekomst een belangrijke aanpak worden.

Maar op het moment zie ik in theorie voor Fresco's idee nog geen plaats op huidige computers. Laat staan in de praktijk met Fresco's huidige implementatie.

De HURD is technisch gezien ook eleganter en superieur aan de Linux kernel. Gebruik jij de HURD?

FCA schreef op 24 maart 2003 @ 23:55:
Verder vind ik het als niet-programmeur raar dat er geen DRI gelijktijdig met Xinerama kan werken.

Dat ligt dan aan jou of aan je drivers gok ik, want op een machine met een Matrox G450 en XFree86 hier werkt zowel Xinerama als accelerated 3D dmv DRI

Anoniem: 78614 schreef op 25 March 2003 @ 00:05:
Ik vraag me af hoe een Longhorn-achtig iets zou moeten werken met X.

Define "een Longhorn-achtig iets" ?

De clients weten niets van elkaar, en de server weet eigenlijk niets van de clients...

Je noemt ons verder in dit topic "weinig specifiek", maar zelf ben je ook een beetje vaag hoor Het zinnetje dat ik quote is juist heel erg van toepassing op X.

LinuxUser schreef op 25 maart 2003 @ 00:11:
Ik dacht dat XFree ook gewoon onder de GNU Public License viel? Dan mag iedereen de code toch aanpassen en modificeren zolang de copyright info maar vermeld staat?

Nee, niet GPL, maar hoofdzakelijk MIT X11 license, en deels andere (waaronder BSD-style, en vast ook wel stukjes (L)GPL).

Maar dat doet er niet toe; MIT X11 is net zo goed een Free license (anders zat XFree86 niet in Debian/main ).

Ik kan het mis hebben, maar als dat zo is en XFree houdt zich daar op deze manier niet aan, vind ik dus dat XFree dit geen GPL mag noemen. Je kunt het inzien maar daar houdt het mee op.

Ik vind het een slechte zaak...

Het is gewoon Free hoor. Als je wilt forken: ga je gang, het is volkomen legaal.

Het punt is dat een fork veel energie gaat verspillen. Een aantal van de XFree86 core members werken veel aan XFree86 en kennen de source goed. Als je XFree86 goed aan wil pakken, dan wil je liever met die mensen samenwerken dan direct met ze concurreren.

kroeske schreef op 25 March 2003 @ 00:30:
want wat ik nu lees is gewoonweg dat de core developers niet meer willen developen... (of zie ik dat verkeerd?)

Dat zie je verkeerd. Als de XFree86 core developers niks meer wilden doen, dan was er al lang een revolutie in het XFree86 development model geweest, of er was een fork gestart. Het grote punt is dat het XFree86 core team op een te gesloten manier werkt: slechts een paar (15 ?) man hebben cvs commit-access, dus als je iets aan de XFree86 main tree wil toevoegen, dan moet dat via één van die 15 man (waarvan de helft or so inderdaad niks doet).

Zelf bij het XFree86 core team gaan horen is vrijwel onmogelijk, omdat je daar zeer lastig binnenkomt.

Anoniem: 78614 schreef op 25 March 2003 @ 00:58:
Laat ik es een voorbeeld geven...
Client a heeft een translucent window... Dit tekent hij op een texture, en upload het naar de server...
De server komt nu in geheugenproblemen... Hoe weet hij nu of hij de texture van client a uit moet swappen, of iets anders?

Een applicatie moet pixmap alloceren, en die uploaden naar de server. Voor verdere acties refereert de client aan die pixmap (zonder hem opnieuw te uploaden). De server houdt die in het geheugen (een pixmap is gealloceerd voor een reden en mag niet zomaar weggeflikkerd worden).

Hoe weet hij welke applicatie niet in gebruik is, en waarschijnlijk niet gebruikt zal worden?

Wat boeit het of een applicatie "in gebruik" is?

En dan nog... Zal de server niet een enorme opslagplaats van redundant textures met UI-componentjes etc worden?

Niet direct redundant. Een X client alloceert een pixmap met een reden. Ze worden geacht die vrij te geven of te hergebruiken as they see fit.

Kortom, hoe ga je dat in godsnaam doen?

Is geen kwestie van "gaan doen", dat is minstens al een jaar of tien zo

Anoniem: 59235 schreef op 25 maart 2003 @ 01:18:
Ja bv, of xvideo AFAIK.
Ik geloof wel dat er ooit werd gewerkt aan netwerk transparante opengl dingen, maar geweldige framerates krijg je toch niet over je netwerkje.

OpenGL is al netwerk-transparant met XFree86. Tenminste, XFree86' GLX module werkt gewoon over het netwerk. Alleen DRI acceleratie werkt niet remote. Dat zou op te lossen kunnen zijn door XFree86' GLX module gebruik van DRI te laten maken ipv de clients zelf via xlibmesa3, maar er is om de een of andere reden (die mij even ontgaan is) niet voor die manier van acceleratie gekozen.

Als je vraag is "Ik heb het nu over een 3d-accelerated GUI, die compatible met X is... Hoe ga je dat doen?" en met "compatible met X" bedoel je "netwerk transparent" dan is het antwoord heel eenvoudig: niet.

Dat is onzinnig, zie boven. Mogelijk is het altijd.

Anoniem: 78614 schreef op 25 March 2003 @ 01:29:
(in dit model wordt er geen onderscheid gemaakt tussen het al dan niet lokaal zijn van de client).

Dat is niet helemaal waar. Het X Window System schrijft voor dat connecties tussen client en server geschied via TCP/IP of DecNET als de server en client op verschillende hosts draaien. Als de server en client op dezelfde host draaien, dan moet comminucatie via TCP/IP of DecNET mogelijk zijn, maar mag ook via een sneller locaal systeem gebeuren.

En dat doet XFree86 op GNU/Linux (en vele andere OSsen) ook. Als het allemaal lokaal draait worden Unix domain sockets gebruikt (aanzienlijk sneller dan een complete netwerk socket), en wordt shared memory gebruikt voor o.a. pixmaps.

OpenGL werkt niet 'met xfree86'... OpenGL hackt een windowtje in xfree86 en tekent daar vrolijk lokaal doorheen... De server weet daar eigenlijk weinig of niets van...

True, en toch niet helemaal. Als 3D via DRI gedaan wordt, dan klopt je verhaal. Maar XFree86 kan het zelf ook via GLX (zij het non-accelerated).

Ik vraag me dus af wat de plannen zijn voor 3d-accelerated versies van X...

Ik ook. Acceleratie van GLX lijkt me een interessante oplossing, maar ik ken te weinig van de details om te zeggen of dat (performance-) technisch haalbaar is. En ik weet al helemaal niet of ze het van plan zijn (voorlopig niet zou ik zeggen... Er zijn andere delen die aandacht verdienen).

edit: Nee, 3dwm is niet wat ik bedoel... Ik bedoel een systeem zoals Longhorn, waarbij de gehele GUI via 3d-hardware geaccelereerd wordt (aa, scaling, blitting, scrolling, alphablend etc... alles kan met de moderne hardware). Het blijft echter wel gewoon een 2d-UI (specifieke 2d-hardware zal verdwijnen, en de 3d-pipelines nemen alle functionaliteit over... Longhorn wil dus ook maar meteen GDI door Direct3D vervangen, om overbodige drivers/emulatielayers te vermijden).

Waarom is dit relevant? Het boeit niet door welke hardware het gerenderd wordt. De apps kunnen gewoon een 2D api gebruiken, als het OS dat rendert dmv de 3D hardware... Echt, het zal de applicaties aan hun reet roesten.

Anoniem: 59235 schreef op 25 March 2003 @ 01:52:
Voor een deel kunnen dit soort dingen al, ik kan met mijn G400 de XTexture extensie gebruiken voor xvideo dingen, ipv xvideo, dan scalet ie dus hardwarematig. Nadeel wel is dat dri dan niet meer werkt, dus het is vrij zinsloos als je af en toe opengl wil gebruiken.

Hmm, 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.

(Oef, tijd voor een link naar een rant van jwz over die achterlijke client/server nomenclatuur bij X, want ik geloof dat ik het nu heel erg fout doe...)

De X server is het programma dat het eigenlijke tekenwerk doet (naar de hardware, of via een andere laag zoals een kernel) en de input events opvangt. X clients zijn applicaties die gebruik maken van een X server om iets op het scherm te zetten.

Het is heel logisch hoor: een server luistert voor inkomende connecties, en biedt clients die connecten bepaalde diensten aan.
Waarom snapt iedereen dat voor Apache + Mozilla, maar niemand voor XFree86 + gimp ?

[Anoniem: 27915]

Anoniem: 78614 schreef op 25 March 2003 @ 01:29:
Ik bedoel niet dat het netwerk-transparant moet zijn... maar dat compatibiliteit met X betekent dat je vast zit aan het client-server model (in dit model wordt er geen onderscheid gemaakt tussen het al dan niet lokaal zijn van de client).

OpenGL werkt niet 'met xfree86'... OpenGL hackt een windowtje in xfree86 en tekent daar vrolijk lokaal doorheen... De server weet daar eigenlijk weinig of niets van...
Bij een 3d-accelerated UI is het verhaal dus behoorlijk anders.

Nee nee nee, je snapt XFree86 maar half.

De standaard windowing werkt via client/server. Het zal je vast wel opgevallen zijn dat er geen gigantische dataload over localhost/lo wordt geschreven als je een X sessie opent. Dat komt omdat lokaal hele andere delen van X werken dan remote. Remote is simpel: TCP/IP over network sockets. Client ene kant, server andere kant, data transfer van elke pixel, klaar. Lokaal werkt dit al heel anders, daar wordt shmem gebruikt, dus server en client (die in principe dus nu hetzelfde zijn) sharen de data pointer. Dus, geen data transfer. Perfect efficient. OpenGL werkt 't zelfde. In 't geval van openGL moet zowel de client als de server openGL rendering ondersteunen, ik weet niet of 't ook dezelfde machine moet zijn (volgens mij niet). Echter, als dat verschillende machines zijn, dan is acceleratie natuurlijk onmogelijk (hoe wil je remote de PCI/AGP bus aanspreken?). XVideo werkt alleen lokaal - zelfde reden.

Nu op naar jouw vraag over translucentie e.d. en het static houden van bitmap data/textures. X werkt in het ideale geval met een layered opbouw, waarin elke window die zichtbaar is gevraagd wordt zich te tekenen, in zo'n volgorde dat uiteindelijk je desktop ontstaat. Stel nu dat je dus alpha gebruikt - dan wordt de window daaronder gevraagd zich te tekenen, en vervolgens de window-on-top. Overigens houdt X een cache van de laatste pixmap, dus als je geen windows verschuift maar alleen de top window groter maakt, dan vallen pixels van de onderliggende windows gewoon weg en wordt er geen redraw event ge-emit.

X werkt ongelofelijk simpel. .

[igmar]

Anoniem: 60780 schreef op 24 March 2003 @ 22:49:
Ik vind sommige kritiek op XFree86 wel terecht. Een daarvan is de bloat factor. Het is iets van 70 MB en daarmee groter dan Win95. En wat is dat nou allemaal met die ingebouwde raster fonts? Compleet wazig als je het mij vraagt . Nee, waar ik mijn hoop op vestig is Fresco. Ondersteunt alpha transparantie, is netwerk transparant door gebruik van CORBA technieken en niet onbelangrijk: het is heel behoorlijk gedocumenteerd.

Je kan X niet vergelijken met win' 95. X is bedacht toen Gates nog z'n pampers volscheet, en draait op zowat alles wat er op deze wereld aan PC's bestaat. Windows '95 draait alleen op een Intel, en zonder patches draait het ook nog beroerd. Die bloat wordt mede veroorzaakt omdat alle videodrivers in de betreffende source zitten.

Een van de grootste problemen met X is de verkeerde architectuur, en de backwards compability. Het beste is gewoon van scratch af beginnen, zoals bv met een groot aantal delen van de 2.4 kernel is gedaan. Helaas zit je dan wederom met compabiliteit, dus het blijft eeb kip en ei probleem.

[Anoniem: 78614]

Als MacOSX en Longhorn *wel* onderscheid maken tussen het al dan niet lokaal zijn van de client, waarom zou xfree86 dat niet mogen? Ja, als je het vergelijkt met hoe het tot nu toe ging bij X servers, dan is er een breuk ja. Nou en?

Omdat je backward-compatibility wil (moet) hebben.
Je hebt niet zoveel aan een fancy hypermodern GUI-systeem als er geen enkele applicatie op draait.

Aah! Maar dan heb je vooral veel client side dingen! Dan hoef je helemaal niet het X protocol (totaal ;-)) om te gooien! Render clientside je fonts of je whatever aa-ed, of alphablended, op eventuele aanwijzingen van je x server...

Hoe krijg je die aanwijzingen dan? Niet via het huidige systeem.

Als je alleen wil aa-en, of scalen, of blitten, of scrollen, waarom haalde je dan die hele client/server dingen d'r bij? Dit soort dingen MOETEN toch clientside, en ALLEEN clientside?

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.

Define "een Longhorn-achtig iets" ?

Je mag jezelf wel eens beter informeren... Maar goed, ik had het al ergens hierboven uitgelegd.

Het zinnetje dat ik quote is juist heel erg van toepassing op X.

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.

Een applicatie moet pixmap alloceren, en die uploaden naar de server. Voor verdere acties refereert de client aan die pixmap (zonder hem opnieuw te uploaden). De server houdt die in het geheugen (een pixmap is gealloceerd voor een reden en mag niet zomaar weggeflikkerd worden).

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

Als de server en client op dezelfde host draaien, dan moet comminucatie via TCP/IP of DecNET mogelijk zijn, maar mag ook via een sneller locaal systeem gebeuren.

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.

Maar XFree86 kan het zelf ook via GLX (zij het non-accelerated).

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

Waarom is dit relevant? Het boeit niet door welke hardware het gerenderd wordt. De apps kunnen gewoon een 2D api gebruiken, als het OS dat rendert dmv de 3D hardware... Echt, het zal de applicaties aan hun reet roesten.

Het gaat erom dat het efficient moet gebeuren.
Verder is dat 3dwm volgens mij gewoon een extra layer... waar eerst de windowtjes gerenderd worden in software, op een texture, en dan in 3d geprojecteerd... dat heeft dus ook niet de voordelen.

Lokaal werkt dit al heel anders, daar wordt shmem gebruikt

Ook alleen maar als je zelf de code met Shm-APIs schrijft... En dan nog is de snelheidswinst zeer beperkt.

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

X is bedacht toen Gates nog z'n pampers volscheet

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...

Windows '95 draait alleen op een Intel

En wat heeft dat ermee te maken?

en zonder patches draait het ook nog beroerd

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

Die bloat wordt mede veroorzaakt omdat alle videodrivers in de betreffende source zitten.

Uhh, WAT?

[FCA]

deadinspace schreef op 25 March 2003 @ 03:40:
Ik zal op een aantal reacties reageren, maar eerst even mijn mening over dit hele gedoe:

Het X Window System kan nog prima mee. Eens zal het opgevolgd moeten worden door iets moderners, maar dat is op dit moment (of de komende 5 à 10 jaar) naar mijn mening absoluut niet nodig. Het X protocol is duidelijk flexibel gebleken, en extensies à la MIT-SHM, GLX, Xvideo, XRandR, XRender hebben bewezen dat X11 hiermee succesvol aan te passen is aan nieuwere hardware en software-eisen.

Maar dan is een fatsoenlijke X server natuurlijk wel een eis. En daar schort het af en toe wat aan. XRender belooft gaaf te worden, en heeft de potentie heel veel nieuws te bieden, maar een gedeeltelijke hardware-accelerated implementatie hiervan is gepland voor XFree86 5.0, waarvan het nog niet eens duidelijk is wanneer die gaat verschijnen. Dat schiet niet op.

XFree86 development heeft een schop nodig. Een fork zou denk ik zo slecht nog niet zijn. De fork wordt dan waarschijnlijk veel opener, en veel experimenteergrager. XFree86 kan zich dan aanpassen en meegaan (waardoor beide projecten van elkaar kunnen profiteren, desnoods via een experimental - production symbiose), of XFree86 kwijnt zachtjes weg terwijl de fork het overneemt.

Dat ligt dan aan jou of aan je drivers gok ik, want op een machine met een Matrox G450 en XFree86 hier werkt zowel Xinerama als accelerated 3D dmv DRI

Hmm... Inderdaad, hier werkt het ook inmiddels, maar volgens mij gaf 4.2.1 nog gewoon de melding dat er Xinerama gebruikt werd, en dat daarom DRI werd uitgeschakeld. Of misschien lag dat aan die brakke ATI proprietary drivers die niet met Xinerama werkten ofzo.
Afijn, ik werd misschien wat boos omdat ik nu al een paar maanden zit te kloten met 3D support met m'n Radeon 9500Pro op een nForce 2 onder Linux, en niemand dit nog aan de praat heeft gekregen. In mijn woede heb ik nu alle mogelijke bronnen beschuldigd.
Ik ben er nu achter waarom het niet werkt:
Een combinatie van proprietary drivers voor de nforce, de radeon, die niet geupdate worden of alleen werken met bepaalde dingen en een gebrek aan medewerking van XFree86 devvers met ATI.

Al met al geen prettige situatie, en ik vrees dat in de toekomst hierdoor nieuwe hardware alleen maar moeilijker ondersteund zal worden. Maar dat ligt natuurlijk ook aan de hardware vendors.

[Anoniem: 27915]

Anoniem: 78614 schreef op 25 March 2003 @ 10:11:
Omdat je backward-compatibility wil (moet) hebben.
Je hebt niet zoveel aan een fancy hypermodern GUI-systeem als er geen enkele applicatie op draait.
[...]
Hoe krijg je die aanwijzingen dan? Niet via het huidige systeem.

Weet jij wel hoe X werkt?

Dit doet X al lang!

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

3D en AA zijn volledig onafhankelijk. AA kan ook remote, afhankelijk van de server rendering.

Ook alleen maar als je zelf de code met Shm-APIs schrijft... En dan nog is de snelheidswinst zeer beperkt.

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

Dan mag je met bewijzen komen. Ik verzeker je dat via Shm X net zo snel draait als het zou draaien als het lokaal-only was.

Ik vrees dat jij de structuur van X nog niet helemaal kent... Heb je al eens in de X sources rondgewroet? X applicaties (dus straight op de X API, geen toplevel shit a la Pango, GDK-X11 ofzo - laat staan Gtk/Gnome/Qt/KDE) geprogrammeerd? Verdiep je er eens in voordat je zomaar iets roept!

[Anoniem: 78614]

Weet jij wel hoe X werkt?

Dit doet X al lang!

Hoe dan?

3D en AA zijn volledig onafhankelijk. AA kan ook remote, afhankelijk van de server rendering.

Daar gaat het niet om... je gaat geen AA in software doen... Dat schiet niet op. Dat doe je met 3d-hardware. Of had je dat nog niet begrepen?

Dan mag je met bewijzen komen. Ik verzeker je dat via Shm X net zo snel draait als het zou draaien als het lokaal-only was.

Ben ik het niet mee eens... Mijn geanimeerde windowtje ging met Shm van 14 naar wel 16 fps... In Windows draaide datzelfde geanimeerde windowtje toch zeker 20 fps.

Ik vrees dat jij de structuur van X nog niet helemaal kent... Heb je al eens in de X sources rondgewroet? X applicaties (dus straight op de X API, geen toplevel shit a la Pango, GDK-X11 ofzo - laat staan Gtk/Gnome/Qt/KDE) geprogrammeerd?

Ja dat heb ik, zowel met als zonder Shm, en geen speciale libs/widgets... alleen X.
Waarom meteen daarachter proberen te verschuilen?

Verdiep je er eens in voordat je zomaar iets roept!

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. Ik stop met deze discussie. Als we zo gaan beginnen, dan hoeft het niet meer... Arrogante drol.

[Anoniem: 53023]

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)

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.

[Anoniem: 27915]

Anoniem: 78614 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?

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... .

[ Voor 47% gewijzigd door Anoniem: 27915 op 25-03-2003 11:35 ]

[Anoniem: 60780]

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.

[igmar]

Anoniem: 53023 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.

[Anoniem: 60780]

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

[igmar]

Anoniem: 78614 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.

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

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: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: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.

[igmar]

Anoniem: 60780 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

[Anoniem: 60780]

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.)

[ Voor 16% gewijzigd door Anoniem: 60780 op 25-03-2003 12:21 ]

[Anoniem: 59235]

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.

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.

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.

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.

[wzzrd]

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

[Anoniem: 27915]

Anoniem: 59235 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...

[odysseus]

Anoniem: 60780 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 .

[Anoniem: 60780]

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

[Anoniem: 59235]

Anoniem: 27915 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!)

[wzzrd]

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...

[deadinspace]

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

Anoniem: 78614 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.

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.

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.

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.

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.

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.

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.

Anoniem: 53023 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.

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:

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.

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.

Anoniem: 60780 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

Anoniem: 59235 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.

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.

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

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?

[Anoniem: 59235]

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))

[MadEgg]

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.

[Anoniem: 14935]

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.

[deadinspace]

Anoniem: 59235 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).

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

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...)

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.

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.

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).

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.

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

[wzzrd]

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

[Anoniem: 32223]

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

[Erhnam]

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....

[Anoniem: 27915]

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...

[FailFr8er]

Anoniem: 27915 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

[deadinspace]

Erhnam schreef op 27 March 2003 @ 17:42:
Ze zouden de drivers gewoon naar de kernel moeten verplaatsen

Dat lijkt me inderdaad netter, maar dat gebeurt al tot op zekere hoogte (steeds meer fb drivers). Maar XFree86's drivers krijgen nog altijd meer aandacht.

Anoniem: 27915 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...

Zoals ik het bedoelde was in ieder geval dat er geen X-specifieke code kernelside komt. De kernel is dan volledig X11-agnostisch. Wat de kernel dan wel zou doen is de videohardware beheren en via een lowlevel abstractie (DRI + fbdev wellicht) aanbieden aan andere software, zoals XFree86 of Fresco:

deadinspace schreef op 25 March 2003 @ 22:32:
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).

Red Nalie schreef op 27 March 2003 @ 18:36:
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

Nee, het is de bedoeling dat de kernel volledig onpartijdig is in welke software erop gebruikt wordt. Dus geen speciale kernel-accomodaties voor bijvoorbeeld X11, KDE, Apache e.d.

Alsa is geen programma, maar het sound-subsystem van de Linux kernel (nouja, het experimentele sound-subsystem... Op het moment is OSS-lite het default).

[ Voor 18% gewijzigd door deadinspace op 27-03-2003 23:30 ]

[Erhnam]

http://xfree86.org/pipermail/forum/2003-March/000807.html

Weet een leuke link Zelfs SUN gaat zich er mee bemoeien..

http://www.osnews.com/story.php?news_id=3139

Nog een leuk artikel (The Next XFree86 Wars: XFT2 vs STSF)

[himlims_]

offtopic:
mag ik julle even bedankten voor jullie mooie onderbouwde reacties, ik ben in iedergeval een heel stuk wijzer geworden over X11 / XFree86 bedankt voor jullie kennis )

[Anoniem: 27915]

Een van de opvallende dingen uit dat document van Sun is dat ze het betalende lidmaatschap van X.org willen afschaffen - zou het dan toch eindelijk... .

[moto-moi]

Anoniem: 27915 schreef op 28 March 2003 @ 15:52:
Een van de opvallende dingen uit dat document van Sun is dat ze het betalende lidmaatschap van X.org willen afschaffen - zou het dan toch eindelijk... .

X.org zorgt toch alleen voor de definitie van(op dit moment) X11R6.
XFree86 is toch een van de vele 'versies' die X toepassen ? Of heb ik ergens een stukje uitleg gemist

[Anoniem: 27915]

moto-moi schreef op 28 March 2003 @ 15:59:
X.org zorgt toch alleen voor de definitie van(op dit moment) X11R6.
XFree86 is toch een van de vele 'versies' die X toepassen ? Of heb ik ergens een stukje uitleg gemist

Ja. Maar zou het niet mooi zijn om - onder de paraplu van X.org - extensies te kunnen schrijven (bv. wat freedesktop.org nu doet), zonder je meteen blauw/paars aan lidmaatschap te moeten betalen?

Dat is de voornaamste reden dat freedesktop.org nodig is - X.org is momenteel niet vrij toegankelijk voor iedereen. Het zou mooi zijn als dit weer gecentralizeerd kon worden.

[moto-moi]

Anoniem: 27915 schreef op 28 March 2003 @ 16:19:
Ja. Maar zou het niet mooi zijn om - onder de paraplu van X.org - extensies te kunnen schrijven (bv. wat freedesktop.org nu doet), zonder je meteen blauw/paars aan lidmaatschap te moeten betalen?

Dus als ik het goed begrijp kun je Xfree86 geeneens forken en doorontwikkelen met de standaard van X.org in het achterhoofd, omdat je die standaard niet zonder flink $$ te betalen in mag zien ? Dat is inderdaad geen prettig gegeven.
Al vraag ik me af hoe ze XFree86 dan 'free' beschikbaar kunnen maken, als dat zoveel geld kost

Dat is de voornaamste reden dat freedesktop.org nodig is - X.org is momenteel niet vrij toegankelijk voor iedereen. Het zou mooi zijn als dit weer gecentralizeerd kon worden.

* moto-moi mist de link met freedesktop.org even..
Het enige wat freedesktop.org volgens mij wil, is een standaard tussen (voornamelijk) KDE & Gnome ontwikkelen, waardoor je bijv. de 'panel'-apps onderling kan uitwisselen..

[Anoniem: 27915]

moto-moi schreef op 28 maart 2003 @ 17:11:
Dus als ik het goed begrijp kun je Xfree86 geeneens forken en doorontwikkelen met de standaard van X.org in het achterhoofd, omdat je die standaard niet zonder flink $$ te betalen in mag zien ? Dat is inderdaad geen prettig gegeven.
Al vraag ik me af hoe ze XFree86 dan 'free' beschikbaar kunnen maken, als dat zoveel geld kost

X.org betaalt mee aan XFree86... .

* moto-moi mist de link met freedesktop.org even..
Het enige wat freedesktop.org volgens mij wil, is een standaard tussen (voornamelijk) KDE & Gnome ontwikkelen, waardoor je bijv. de 'panel'-apps onderling kan uitwisselen..

... en dat zouden ze liever onder de paraplu doen van X, omdat het allemaal samenwerkingsverbanden gaan die onder de X.org paraplu horen te vallen.

[deadinspace]

moto-moi schreef op 28 March 2003 @ 17:11:
Dus als ik het goed begrijp kun je Xfree86 geeneens forken en doorontwikkelen met de standaard van X.org in het achterhoofd, omdat je die standaard niet zonder flink $$ te betalen in mag zien ?

Ik weet niet of je voor de X specificatie moet betalen, maar bovenstaand is geen probleem voor XFree86. Voor de POSIX specificatie moet je ook geld neerleggen, en we weten allemaal hoe het met de vrije implementaties zit

* moto-moi mist de link met freedesktop.org even..
Het enige wat freedesktop.org volgens mij wil, is een standaard tussen (voornamelijk) KDE & Gnome ontwikkelen, waardoor je bijv. de 'panel'-apps onderling kan uitwisselen..

Het X Window System specificeert hoe X clients en X servers comminuceren. Dat is op zich voldoende om X servers en X clients te interpreteren, maar niet voldoende voor een werkende desktop. Een voorbeeldje is een window title. Hoe weet een window manager hoe een window "heet" ?

Het X Window System biedt daarvoor Atoms. Dit zijn een soort variabelen op windows. Zo hebben windows een Atom genaamd WM_NAME. De string in WM_NAME wordt door windowmanagers weergegeven in bijvoorbeeld de titlebar.

Maar de namen van Atoms zijn vrij te kiezen. Als een programma zijn title in (ik noem maar wat) WM_TITLEBARNAME zet dan werkt dat niet als de windowmanager daar niet kijkt. Er moet dus vastgelegd worden hoe je je Atoms dient te noemen, en hoe je ze dient te gebruiken. Hiervoor is de ICCCM (Inter-Client Communication Conventions Manual) opgesteld. Veel zaken die je "for granted" neemt in een windowing system zijn hierin vastgelegd, zoals bijvoorbeeld colormaps, window titles, iconic state, positie informatie, etc, etc.

De Freedesktop spec is in feite een uitbreiding op de ICCCM, met meer nadruk op de modernere features van desktop omgevingen zoals pagers, docks, panels, shaded states, etc, etc. En het zou inderdaad mooi zijn als dat onder dezelfde paraplu zou kunnen vallen, al zou ik daar met het huidige X.org minder blij mee zijn.

[Erhnam]

Een fork is een feit geworden, blijkbaar vond Keith Packard de bugzilla en het open forum van xfree86 niet genoeg. Hij heeft het denk ik een paar dagen aangekeken maar nu is hij toch zelf begonnen. Hopelijk krijgen we van hun mooiere dingen te zien dan xfree86.

Hier een stukje:

Reading the notes of yesterday's teleconference with people like Mike Harris from Red Hat, fontconfig's Keith Packard and others, it seems that they have decided to actually do fork the XFree86 codebase or at least to create a parallel organization to "demonstrate how a scalable community might work" (they also seem to email eachother in a non-archived mailing list of a sort). They currently looking for a nice, catchy name for the project, but they have registered xwin.org just in case nothing better will come up. Reactions of the teleconference have been recorded at XFree's public mailing list.

Hier hun website: http://xwin.org/

Hier het artikel van osnews: http://www.osnews.com/comment.php?news_id=3267

Verder las ik dat Arpi van Mplayer ook het project heeft gejoined Ben benieuwd wat er allemaal voor een leuks gaat komen

[ Voor 23% gewijzigd door Erhnam op 13-04-2003 04:03 ]

[Anoniem: 27915]

Erhnam schreef op 13 april 2003 @ 03:54:
Verder las ik dat Arpi van Mplayer ook het project heeft gejoined Ben benieuwd wat er allemaal voor een leuks gaat komen

OMG! . Mea culpa, zojuist heeft Keith Packard zijn eigen doodvonnis getekend.

[odysseus]

Anoniem: 27915 schreef op 13 April 2003 @ 11:47:
OMG! . Mea culpa, zojuist heeft Keith Packard zijn eigen doodvonnis getekend.

Och, MPlayer is in ieder geval wel snel, dus misschien dat hij iets van dat voordeel in XWin naar voren kan laten komen...de public relations kan hij beter aan iemand anders overlaten .

[Anoniem: 27915]

Ik hoop voor Keith dat ze een automatische indent filter op die CVS server laten runnen... Die Arpi kan geweldig snelle code schrijven maar zelfs een aap maakt nog mooiere code. ( ).

[Anoniem: 53023]

Anoniem: 27915 schreef op 13 April 2003 @ 11:58:
Die Arpi kan geweldig snelle code schrijven maar zelfs een aap maakt nog mooiere code. ( ).

Je bedoelt dat alles aan elkaar geplakt lijkt te zijn (en de 1 spatie indents)?
Ziet er idd niet echt mooi uit ja..


Er zitten trouwens heel wat 'grote' namen bij dit 'nieuwe' project.. kan nog leuk worden

[Erhnam]

Leuk om weer even aan te halen... Er is een discussie gaande op slashdot: http://developers.slashdo...4&tid=152&tid=185&tid=189

Keith Packard is bezig met freedesktop.org zijn eigen X server (KDrive)(http://freedesktop.org/Software/xserver) verder uit te werken.

Screenshots zijn te vinden hier:

http://freedesktop.org/~keithp/screenshots/

Hier een voorbeeldje:



Verder is er op GnomeDesktop ook nog wat over te lezen:
http://www.gnomedesktop.o...de=thread&order=0&thold=1

[ Voor 17% gewijzigd door Erhnam op 13-11-2003 00:00 ]

[mOrPhie]

Zozo, shadows, transparantie, anti aliasing van windows. Eigenlijk precies die functies waarvan al tijden geroepen wordt dat deze in XFree86 missen, als ze nog een beetje mee willen doen met de nieuwe technieken die OSX en longhorn laten zien straks.

[Anoniem: 27915]

Het is trouwens allemaal off-screen gerendered, volgens die documentatie. Iemand enig idee over de snelheid van het geheel? X is al niet bijzonder snel... .

[mOrPhie]

Anoniem: 27915 schreef op 13 november 2003 @ 10:30:
Het is trouwens allemaal off-screen gerendered, volgens die documentatie. Iemand enig idee over de snelheid van het geheel? X is al niet bijzonder snel... .

Zoals ik het begrijp van de documentatie hangt dit dus af van de soort eye-candy die de developer wil aanbrengen. X Server biedt de mogelijkheid tot, niet de eye-candy zelf. Op die manier heb je geen hard-coded eye-candy en is er dus ruimte zat tot het wegwerken van performance issues. Deze eerste pre-release is dan denk ik ook alleen maar om te laten zien dat transculent windows, alpha blending, en 32bb kan. Het off-screen "probleem" is een 2e.

Afgezien van dat zou iemand het moeten installeren om inzage te krijgen in de performance.

Maar ik ben met je eens dat het op deze manier wel 'ns voor een flinke performance-drop zal zorgen.

[ajvdvegt]

mOrPhie schreef op 13 november 2003 @ 11:05:
Maar ik ben met je eens dat het op deze manier wel 'ns voor een flinke performance-drop zal zorgen.

Waarom? Het nieuwe systeem maakt juist slim gebruik van de hardware die aanwezig is in de meeste moderne computers; je 3D kaart. De transparantie en schaduws e.d. worden dus mbv. OpenGL weer gegeven. Als OpenGL dan ook gebruikt zou worden voor bv. het verplaatsen van vensters, dan wordt de desktop er juist sneller door .
En het allermooiste is dat dit aan de client-side wordt berekend; het werkt dus ook allemaal als je X over een netwerk draait. (je zal het wel willen uitzetten als op een machine werkt zonder 3D kaart, want zonder hulp van je hardware zal het inderdaad wel heel erg traag worden.)

[Anoniem: 27915]

En ga er nu eens vanuit dat de 3D support onder Linux voor de meeste gangbare videokaarten niet zo geweldig is?

Voorbeeldjes:
• 3dfx is weggieweg.
• geen 3D support voor trident kaarten (standaard in de meeste Toshiba laptops).
• veel laptops (met name de goedkoperen) hebben geen echte 3D support.
• SiS?
• Matrox support is ronduit kut.
etc...

[ Voor 5% gewijzigd door Anoniem: 27915 op 13-11-2003 14:53 ]

[mOrPhie]

Wat ik me afvraag. Waar haalt ajvdvegt vandaan dat deze X Server gebruik maakt van hardware-acceleratie (zoals opengl) voor rendering van de on-screen image?

Ik kan dat nergens uit afleiden.

[Anoniem: 53023]

Anoniem: 27915 schreef op 13 november 2003 @ 10:30:
Het is trouwens allemaal off-screen gerendered, volgens die documentatie. Iemand enig idee over de snelheid van het geheel? X is al niet bijzonder snel... .

Valt wel mee, er gaan al geruchten dat de snelheid beter is wanneer die compositie manager draait.

En we hebben het hier niet over XFree86 zelf maar over een X server gebaseerd op KDrive, afaik (alles wordt dus nog gerenderd in software, niet mbv de hardware, maar zelfs dat schijnt sneller te zijn dan in XF86).
En KDrive is voor zover ik weet altijd al sneller (en kleiner!) geweest dan het XF86 beest.

* Anoniem: 53023 is heel erg enthousiast over die compositie manager...

* Anoniem: 53023 gaat vanavond proberen (note: denk eraan om resolutie op 32 bpp te zetten, anders crasht de boel volgens sommige mensen die het al geprobeerd hebben)

[BoAC]

Er loopt ook een leuk draadje hierover op de Gentoo Forums KeithP's X Server: It's sexy
Hieruit blijkt dat de server alleen nog maar op vesa draaid, dus opengl zit er nog niet in
Afwachten dus

[ajvdvegt]

Goed, het kostte wat moeite om terug te vinden wat ik had gelezen, maar ik heb het dan toch gevonden (de blog van Havoc Pennington). En nu ik het teruglees moet ik zeggen dat ik alles wel een beetje optimistisch heb ingezien, maar ach . Het lijkt er wel op dat zoiets straks vrij eenvoudig in OpenGL te implementeren zou zijn (door wijzigingen aan de server kant van X), omdat de server nu alle vensters apart in zijn geheugen houdt, en die pas door de client over elkaar worden gelegd. Dat geeft de Window Manager eindelijk de optie deze stoere dingen te doen.

Maar als je OpenGL implementatie slecht is, neem je toch gewoon een Window Manager die dit soort dingen uitzet?

[ Voor 9% gewijzigd door ajvdvegt op 13-11-2003 19:52 ]

[mOrPhie]

Heeft iemand het al geinstalleerd? Ik wil het vandeweek gaan doen. Maar op gentoo-forums zijn er al een aantal die het gelukt is, werkend. Deze screenshot kwam daaruit rollen:

http://www.mindstab.net/msd/images/inferno/xserver.png

[Niek]

mOrPhie schreef op 16 november 2003 @ 12:16:
Heeft iemand het al geinstalleerd?
-snip-

Jep, ik heb hem hier al een tijdje van CVS draaien. Er zijn inmiddels ook ebuilds (snapshots van CVS) voor, heb ik begrepen. Screenshots (klikbaar):





Bij het afspelen van bijv film blijft het beeld perfect doorlopen onder de half transparante menu's. Het ziet er allemaal erg gelikt uit

Jammer dat op dit moment alleen Xvesa en Xfbdev bruikbaar zijn voor mij, de nVidia Xserver werkt niet (goed). Het probleem is (volgens Keith) dat de nVidia driver code in XFree86 zo brak ik dat het niet bruikbaar is voor de nieuwe xserver. Ik las laatst dat de MPlayer devvers het voor elkaar hebben gekregen een soort wrapper om de binary nVidia driver te maken zodat je met MPlayer accalerated video's kan afspelen in je console. Misschien dat we ook zoiets kunnen gebruiken als (tijdelijke oplossing) voor de nieuwe xserver.

[Anoniem: 27915]

Gebruikt die video (eerste screenshot) Xv? Zo ja, hoe de f*ck krijg je dat werkend? Dat is ubergeil, en zou (at first sight) onmogelijk moeten zijn met Xv-overlay. .

[Niek]

Anoniem: 27915 schreef op 17 november 2003 @ 11:17:
Gebruikt die video (eerste screenshot) Xv? Zo ja, hoe de f*ck krijg je dat werkend? Dat is ubergeil, en zou (at first sight) onmogelijk moeten zijn met Xv-overlay. .

Nope, is gewoon standaard X11 output met MPlayer. De FDO xserver ondersteund afaik helemaal geen XV op dit moment.

[BoAC]

Kwam net dit tegen op NewsForge: X.org and Xfree86 reform as a single group
Zouden we nu meer openheid krijgen in het project en meer leukere features

[Anoniem: 67624]

http://www.xfree86.org zegt anders van niet ?!?

[djc]

Anoniem: 67624 schreef op 23 januari 2004 @ 19:43:
http://www.xfree86.org zegt anders van niet ?!?

Slashdot en OSNews van wel, dus denk dat het wel klopt...

[odysseus]

NewsForge heeft al een update geplaatst, waarin ze duidelijk maken dat het niet gaat om een merge van de organisaties, maar om een samenwerking tussen verschillende developers van die organisaties .

[Erhnam]

XFree86.org denies the story. I think a more accurate description of the event might be something like, "XFree86 core developers leave XFree86, join X.org, remaining people of XFree86 are peeved".

vreemd... nu ontkennen ze het weer... ben benieuwd...

[Erhnam]

freedesktop.org xlibs 1.0 Released

http://www.osnews.com/comment.php?news_id=5796

Leuk artikeltje met veel links

[Niek]

Nieuws: http://yro.slashdot.org/y...223.shtml?tid=104&tid=189

Door de licentie verandering van XFree86 die pasgeleden is doorgevoerd vertikken veel distromakers het om XFree86 4.4 te packagen. Onder andere in RedHat (Fedore/RHEL), Gentoo, Debian en ook OpenBSD zul je dus geen nieuwere versies van meer XFree86 aantreffen.
Dit houd op korte termijn in dat distro's misschien de Xouvert branch zullen gebruiken of bij XFree86 4.3 zullen blijven, en in de toekomst zullen overstappen op de FDO xserver. Deze laatste is op dit moment druk in ontwikkeling, ergens aan het eind van dit jaar moeten de xserver en nieuwe extenties redelijk gestabiliseerd zijn. Hopelijk zullen ATI en nVidia hierna hun drivers ook aanpassen (de DRI drivers werken op dit moment al redelijk met de nieuwe xserver).

[smokalot]

The_Surfer schreef op 18 februari 2004 @ 19:10:
Nieuws: http://yro.slashdot.org/y...223.shtml?tid=104&tid=189

Door de licentie verandering van XFree86 die pasgeleden is doorgevoerd vertikken veel distromakers het om XFree86 4.4 te packagen. Onder andere in RedHat (Fedore/RHEL), Gentoo, Debian en ook OpenBSD zul je dus geen nieuwere versies van meer XFree86 aantreffen.
Dit houd op korte termijn in dat distro's misschien de Xouvert branch zullen gebruiken of bij XFree86 4.3 zullen blijven, en in de toekomst zullen overstappen op de FDO xserver. Deze laatste is op dit moment druk in ontwikkeling, ergens aan het eind van dit jaar moeten de xserver en nieuwe extenties redelijk gestabiliseerd zijn. Hopelijk zullen ATI en nVidia hierna hun drivers ook aanpassen (de DRI drivers werken op dit moment al redelijk met de nieuwe xserver).

wow, dat is nogal wat!

Overigens kun je ook mandrake aan dat lijstje toevoegen.

Kan me eigenlijk niet voorstellen dat XFree hier iets mee opschiet, dit zijn niet de minste namen, en voor zover ik begrijp is het vrij lastig (hoewel dubieus) om de GPL niet te breken bij het gebruik van XFree met de nieuwe licentie. Dus dan zullen er nog meer distro-makers volgen.

Moet zeggen dat ik hier een beetje een dubbel gevoel over heb, aan de ene kant heeft XFree zich duidelijk bewezen, maar aan de andere kant zou dit voor een hoop meer aandacht voor de FDO xserver kunnen zorgen, waardoor deze sneller volwassen wordt.

Wel jammer dat het net nu gebeurt, nu komt er dus geen XFree 4.4 in bv mandrake 10.0, dus ook geen resolutie/refresh on the fly veranderen...

[Anoniem: 17264]

Wat houd de nieuwe licensie in het kort dan in? Ik ben niet zo goed in juridische taal

[Anoniem: 73385]

Laten we iig hopen dat deze affaire positief uitpakt voor de desktop users ...

[Anoniem: 27915]

Anoniem: 17264 schreef op 18 februari 2004 @ 21:12:
Wat houd de nieuwe licensie in het kort dan in? Ik ben niet zo goed in juridische taal

"you may do anything except claim that you wrote it" in binary form. Consequentie is dat de end-user binary redistributie een soort disclaimer moet reproduceren ("(c) X bla"), zij het in end-user documentatie of in andere vorm. Dit is een soort extreme vorm van de "unchangeable section" van de GNU Free Documentation License" (*). Het verschil is dat dit niet over documentatie maar de code zelf gaat. Oftewel, ik mag de code niet 100% voor eigen gebruik editen; ik moet de genoemde disclaimer bewaren. dat is GPL-violation.

(*) note dat Debian de FDL niet als free beschouwt...

[blouweKip]

Nope, is gewoon standaard X11 output met MPlayer. De FDO xserver ondersteund afaik helemaal geen XV op dit moment.

nu wel

En ga er nu eens vanuit dat de 3D support onder Linux voor de meeste gangbare videokaarten niet zo geweldig is?

mja, ik vind persoonlijk de 3d support van nvidia (en 3dfx, maar dat zijn geen gangbare kaarten meer) echte super, tja, het is geen oss driver en glx implementatie maar dat doet daar niets aan af.

Overigens heb ik nu een recente versie draaien van fdo's xserver en de performance van de Xvesa driver is flink verbeterd (op mn laptop nog af en toe wat traagjes maar op mn workstation behoorlijk acceptabel>al zuigt die 60hz natuurlijk als je geen vesa 3.0 compatible kaart hebt en een crt monitor)

Ik hoop zelf dat de licensie wijziging van xfree86 iig rap de ondersteuning (oss en propriatary) zal doen toenemen

[mOrPhie]

Het heeft de frontpage nu ook gehaald.

nieuws: XFree86 4.4.0 mogelijk geboycot door distributeurs

[Anoniem: 107036]

Dit is een zeer interessante ontwikkeling. Zeker die screenshots met vector based graphics (die clock) zien er erg strak uit..

Mijns inziens moeten er nog een paar stappen genomen worden om een standaard te creeren die ook goed genoeg is voor de toekomst. Een van de belangrijkste is in mijn ogen de video drivers in de kernel. Dus niet zoals nu alleen voor XFree86 geschreven.
Ook moeten zaken als looking glass van sun gaan draaien op de nieuwe x11 server...

And last but certainly not least.. porteren naar FreeBSD want anders heb ik er nog geen drol aan

[cashewnut]

Anoniem: 107036 schreef op 25 februari 2004 @ 14:18:
Ook moeten zaken als looking glass van sun gaan draaien op de nieuwe x11 server...

Als Looking Glass het X-protocol gebruikt zou dat geen probleem moeten zijn volgens mij...

[Anoniem: 73385]

Anoniem: 107036 schreef op 25 februari 2004 @ 14:18:
Dit is een zeer interessante ontwikkeling. Zeker die screenshots met vector based graphics (die clock) zien er erg strak uit..

Mijns inziens moeten er nog een paar stappen genomen worden om een standaard te creeren die ook goed genoeg is voor de toekomst. Een van de belangrijkste is in mijn ogen de video drivers in de kernel. Dus niet zoals nu alleen voor XFree86 geschreven.
Ook moeten zaken als looking glass van sun gaan draaien op de nieuwe x11 server...

And last but certainly not least.. porteren naar FreeBSD want anders heb ik er nog geen drol aan

Groot gelijk, mede-FreeBSD fan .

[Apache]

Ik was vorige zaterdag (niet gisteren) op FOSDEM en heb zowel de voorstelling van DirectFB en FreeDesktop (door Meneer Keith Packard himself) mogen bijwonen.

Jammer genoeg heb ik op dit moment weinig tijd dus zal ik even samenvatten wat met nog het korts in het geheugen ligt, en ook nog ff vermelden dat Keith Packard een van de beste sprekers is met prachtige humor in alle voorstellingen die ik de voorbije jaren heb meegemaakt

Ik beperk me nu tot freedesktop, hoewel DirectFB ook knappe dingen liet zien, zoals QII in een transparant venster dat echt vlotjes translucent over de desktop heen en weer gesleept kon worden tot OpenGL apps die een volledig translucent achtergrond hadden zodat de opbjecten (een kegel en cilinder) mooi boven een grid zweefden op de desktop wat natuurlijk tot applaus leidde

Freedesktop, wel allereerst zijn er veel nieuwe extensions, zelfs de compositing manager, waar het geheel veel gebruik van maakt is er een, randr, damage extension.

De damage extension is iets wat detecteerd waar een verandering plaatsvind, bvb je klinkt op een drop down menu, wat eronder verschijnt is even een damaged zone.

De compositing manager gaat dan die damaged zone opnieuw opbouwen hoe het nodig is, bvb je klikt bovenaan in je browser op file en dat ding moet transparant zijn dan gaat de compositing manager blenden met het onderliggende stuk.

Elk venster op je desktop is een image, een canvas waar naar "geschilderd" word nl, hij kon ze ook makkelijk op die manier gewoon als data grabben, waarna hierop actie's (transformaties) kunnen worden uitgevoerd en de compositing manager dit allemaal samenvoegd.

Het had nog enkele nadelen bvb bij een menu waar background niet werd gespecifieerd, of translucent was oid ging de compositing manager niets mee moest doen zag je wat gekleurde puntjes, dit was omdat er een stuk geheugen werd vrijgemaakt maar daar werd nog niets mee gedaan en was dus gewoon een grafische voorstelling van bvb een malloc(200 * 300), ongeinitialiseerd dus, waarna hij crafty hackers uitdaagde om er een exploit voor te verzinnen

Het draaide in software, en ... het was niet super snel, waar hij het zelf over had was dat er nu tot 6-7x een copy van het venster zich in bevond en er dus echt wel vrij veel videogeheugen nodig is om het te te draaien.

Waar hij uiteindelijk naartoe wil is opengl als rendering backend voor de desktop waarbij hij ff verwees naar quartz op osX en dat dat nog niet voor de eerste release was en dat daarbij ook nog hulp nodig was van de driver developers, hij werkte nl al goed samen met ati en verwachtte dat ook nvidia zou volgen aangezien driver developers toch niet graag 2D support verbeterden en ze het dus ook leuker gingen vinden

Hij had enkele erg goede slides maar k'vrees dat die niet meteen online te vinden zullen zijn?
Er zijn iig wel veel foto's gemaakt van elke slide dus die vind je misschien nog wel ergens terug.

edit:

ooeh, t'is toch niet zo kort

edit:

m'n lift is er nog niet

Fosdem t'was in Brussel op de campus van ULB en er waren ong 2000 bezoekers, vnl developers die soms bij grotere projecten eigen developer rooms hadden oa mozilla, kde, etc, boven de toiletten hing het bordje met "SCO DEVELOPERS ROOM"

Echt specifiek over hoe het driver gebeuren er ging uitzien was hij niet, enkel dat het naar volledige 3D drivers zou gaan zodat het 2D stuk uit die software gedropt kon worden. Ik neem aan dat dat ook betrekking heeft op overlays ed

K'denk dat hij ook veel sneller kan leggen met grote namen als ati en nvidia omdat hij voor HP werkt en die hem ook steunen en z'n gigabit lijntje en server sponseren

[ Voor 16% gewijzigd door Apache op 29-02-2004 15:47 ]

[Anoniem: 73385]

Waar was die FOSDEM dan ?

Leuke kerel die Packard, aan zulke mensen heb je wat !

Maar ik begrijp dus dat hij van plan is om Ati/Nvidia etc over te halen drivers voor zijn oplossing te laten schrijven, ipv alles los van de driver te laten functioneren ?

Dat lijkt mij persoonlijk namelijk wel een goed idee, om de driverontwikkeling wat uniformer en dus beter te laten verlopen...

NB:
Hij kiest een gewaagde strategie, hij pikt de krenten van het brood van XFree86...
Als Nvidia et al voortaan geen drivers voor XFree86 gaat ontwikkelen dan móet het project wel een wisse dood sterven...

[dingstje]

Anoniem: 107036 schreef op 25 februari 2004 @ 14:18:
And last but certainly not least.. porteren naar FreeBSD want anders heb ik er nog geen drol aan

Waar wacht je nog op? Freebsd Porters Handbook en de sources is all you need

Overigens ben ik ook naar FOSDEM geweest, en ik vond het spijtig dat die mens van DirectFB niet gewoon is om te spreken voor een publiek (of zo kwam hij toch over). Op een bepaald moment zei hij '... and then eeh... eeeh... eeh.. eeeh let's just go on'. Hetgeen hij toonde was wel heel indrukwekkend, maar ik zag de CPU regelmatig constant 100% draaien (maar ja, QII in een transparant venster en het heen en weer hobbelen... hier zou het gewoon crashen :-P)

[Anoniem: 73385]

Nog een vraagje van mij.

Hoe kan het dat ze die semi-tranparante zaken kunnen showen op die screenshots ? (Alpha blending ofzo heette het ?)

Er werd een normale KDE-setup gebruikt zie ik, maar in KDE zit toch helemaal geen code die dergelijke grafische trucs aanroept ?

[ Voor 5% gewijzigd door Anoniem: 73385 op 29-02-2004 18:02 . Reden: typo, verduidelijking ]

[blouweKip]

Dat wordt dan ook gewoon gedaan door de x server zelf en is onafhankelijk van de wm/de die je gebruikt

[Anoniem: 73385]

En hoe weet die server wanneer hij dat moet toepassen ?

Ik neem aan dat niet alles in en uit fade...