Xorg vooruitgang

[Flydude]

Tijdje geleden hadden we een topic over de toekomst van het X windowing systeem. Inmiddels hebben we de X.org fork en hebben we een nieuwe release.

Ik heb hem net ge-emerge-d. Behalve dat de Keyboard-module tegenwoordig met een kleine 'k' is, deed-ie het verder prima.

De vraag is natuurlijk: zijn we blij met de richting waarin X zich beweegt? Er zijn nogal wat extensions bijgekomen waar ik de gevolgen nog niet direct van kan overzien maar waarover ze op Slashdot in ieder geval erg enthousiast waren.

Ik heb het idee dat er behoorlijk wat gesleuteld wordt aan X en dat de vaart er goed inzit. Dat laatste zal ongetwijfeld komen doordat er al heel wat code klaar lag die in XFree nooit aan bod is gekomen.

En wat ik natuurlijk ook wil weten: wat zijn de ervaringen met x.org's X11R6.8.0?

[blouweKip]

Ik draai het hier en ik ben er iig over te spreken, het voelt iig wat "snappier" dan xfree (4.3.99 hiervoor) en de composite support is ook wel mooi (nu nog afwachten wat ermee gedaan gaat worden, met proof-of-concept progjes als xcompmgr en transset kun je iig al een indruk krijgen wat mogelijk is --> en het draait supersnel als je driver goede render support heeft)

xdamage is daarnaast best vet, op die manier kan je de netwerkoverhead iig flink verminderen als je X remote draait

Naast dit vind ik zaken als cairo en glitz (opengl backend) ook wel interessant, eindelijk de mogelijkheid om een desktop alla mac osx te krijgen (ja, ik vind eyecandy en zut als expose een flinke verbetering)

[rb338]

De keyboard module is verouderd en verdwijnt binnenkort. Daarvoor in de plaats is kbd gekomen, dit kun je dus beter alvast vervangen in je xorg.conf zodat je straks niet voor onverwachte problemen komt te staan.

Ik heb hier X.org 6.8.0 ook emerged vanmiddag, maar door die klote ATi-drivers loopt het hier gigantisch brak. Ik kan die composite extensie dus ook niet gebruiken, want dan kan ik nieteens meer fatsoenlijk scrollen door een webpage oid.

Iemand een Radeon 9600XT kopen?

[mOrPhie]

Ik ben erg te spreken over x.org. Ik hou mezelf erg betrokken bij de development ervan, middels het bijhouden van de mailinglists, het participeren in discussies op de mailinglists en op IRC en het testen van elke release (vanaf 6.7.99.1 ben ik gaan testen). Op dit moment ben ik een beetje in kwin aan het hacken om te kijken of we deze argb kunnen laten gebruiken. Mooie alhpa-blended borders kan geen kwaad zeg maar. Deze patches zijn voor metacity al beschikbaar.

Er zijn op dit moment grootse plannen om zomaar 40% van de code te herschrijven. Memory-management, network-transperantie, driver-management (XAA niet?) en dergelijke zullen een gedaanteverandering ondergaan en heel X vele malen sneller moeten maken. Het mooie aan x.org vind ik dat de development compleet open is en dat ze heel erg open staan voor ideeen van buitenaf. Dat brengt nu dit soort gedurfde radicale veranderingen in de code, welke xfree86 nooit wilde doen uit pure conservatisme als je het mij vraagt.

Keith Packard e.a. zijn hard bezig geweest op XComposite, XFixes en XDamage in x.org te krijgen. Helaas is gebleken dat deze onderdelen nog niet stabiel genoeg zijn om standaard gebruikt te kunnen worden. De Composite-extension staat dus default uit in de R6.8 release. Voor de volgende release (project "radicale veranderingen" zeg maar), zal Composite wel compleet ondersteund in zitten.

rb338 schreef op 10 september 2004 @ 00:00:
Ik heb hier X.org 6.8.0 ook emerged vanmiddag, maar door die klote ATi-drivers loopt het hier gigantisch brak. Ik kan die composite extensie dus ook niet gebruiken, want dan kan ik nieteens meer fatsoenlijk scrollen door een webpage oid.

Heb je dit in je device-section staan?

code:

        Option          "AGPFastWrite" "On"
        Option          "RenderAccel" "On"

[blouweKip]

Een heel klein beetje offtopic, maar een leuke patch voor xcompmgr is de fade patch

patch

Deze patch zorgt ervoor dat windows en menu's langzaam van doorzichtig naar volledig zichtbaar faden (nu nog een manier om die snelheid on the fly aan te passen)

na het patchen xcompmgr -fFc draaien en nog meer leuke nutteloze eyecandy zooi

[ Voor 3% gewijzigd door blouweKip op 10-09-2004 02:00 ]

[Wilke]

Hier werkt 't leuk, maar niet als ik Xinerama aan heb staan.

Als ik dat uitschakel kan ik prima alle leuke eye-candy features even uitproberen (yup, ik heb het net vandaag ook maar even ge-emerged ), maar tegelijk met het tweede scherm gaat het dus hopeloos mis - varierend van alle vensters die verdwijnen (soms zie je alleen de drop shadows, soms ook uberhaupt niks behalve de achtergrond), tot crashende X-server zodra je op een muisknop drukt.

Hoe dan ook, als proof-of-concept is xcompmgr zeker interessant, dit schept absoluut zeer interessante mogelijkheden voor de toekomst

[rb338]

mOrPhie schreef op 10 september 2004 @ 00:52:
[...]
Heb je dit in je device-section staan?

code:

        Option          "AGPFastWrite" "On"
        Option          "RenderAccel" "On"

Had ik er niet in staan, er vanuit gaande dat het alleen voor nvidia kaarten is. Maar dan nog loopt het brak. Ik heb sowieso al maanden problemen met ATi drivers. Als ik de driver gewoon draai, dus met DRI en hardware accelleration etc, krijg ik een blank screen of death bij elke GL-app.

Zal zo maar 's naar Mycom gaan om te vragen wat mijn opties zijn wbt inruilen van mijn ATi kaart. TV-out wil namelijk ook nog wel eens flippen, en dat doet ie zelfs in Windows. Daarnaast krijg ik soms artifacts in 2D, zowel in Linux als Windows...

En ik heb deze kaart al 's omgeruild want de koeler van de vorige hield er spontaan mee op Geen Sapphire meer voor mij dus...

[Niek]

mOrPhie schreef op 10 september 2004 @ 00:52:
Ik ben erg te spreken over x.org. Ik hou mezelf erg betrokken bij de development ervan, middels het bijhouden van de mailinglists, het participeren in discussies op de mailinglists en op IRC en het testen van elke release (vanaf 6.7.99.1 ben ik gaan testen). Op dit moment ben ik een beetje in kwin aan het hacken om te kijken of we deze argb kunnen laten gebruiken. Mooie alhpa-blended borders kan geen kwaad zeg maar. Deze patches zijn voor metacity al beschikbaar.

Ik kan het mis hebben, maar ik hoorde dat er al XComposite support in KWin HEAD zit (net als Konsole overig) Misschien daar eens naar kijken? Overigens is dit een leuke tutorial om XComposite te leren kennen: http://ktown.kde.org/~fredrik/composite_howto.html
Wat andere applicaties die op dit moment al 'Composite-ready' zijn: Komposé en Skippy-XD. Ik verwacht ook binnenkort patches voor bijv Kicker zodat geminimaliseerde apps real-time zichtbaar blijven (ala MacOS X, waar je Quicktime ziet doorlopen in je docker).
Aan het Gnome-front zie je ook al nieuwe ideeen, zo heeft de VNC server die in 2.8 (correct me if I'm wrong) komt ook XComposite support, zodat polling niet nodig is.

Er zijn op dit moment grootse plannen om zomaar 40% van de code te herschrijven. Memory-management, network-transperantie, driver-management (XAA niet?) en dergelijke zullen een gedaanteverandering ondergaan en heel X vele malen sneller moeten maken. Het mooie aan x.org vind ik dat de development compleet open is en dat ze heel erg open staan voor ideeen van buitenaf. Dat brengt nu dit soort gedurfde radicale veranderingen in de code, welke xfree86 nooit wilde doen uit pure conservatisme als je het mij vraagt.

Er staan idd grote dingen aan te komen Cairo/glitz backend moet rendering veel sneller maken. XAA heeft een rewrite nodig om bijvoorbeeld window resizing sneller te maken als xcompmgr draait. NX zal ook wel zijn weg vinden in XOrg, waardoor netwerktransparantie nog beter (session resume bijv) en vele malen sneller (NX heeft zelfs minder bandwidth dan Citrix nodig) wordt.

rb338 schreef op 10 september 2004 @ 08:37:
[...]

Had ik er niet in staan, er vanuit gaande dat het alleen voor nvidia kaarten is. Maar dan nog loopt het brak. Ik heb sowieso al maanden problemen met ATi drivers. Als ik de driver gewoon draai, dus met DRI en hardware accelleration etc, krijg ik een blank screen of death bij elke GL-app.
(...)

RenderAccel werkt ook op andere kaarten, AFAIK is het ook geimplementeerd in de ATi en Matrox drivers. But then again, nVidia is en blijft op dit moment gewoon de beste keuze als je Linux/FreeBSD draait. Verwacht overigens geen snelheidswonderen met een nVidia kaart en xcompmgr draaiend, resizing van windows is gewoon sloom en artifacts bij verslepen blijf je houden (iig op dit moment).

[mOrPhie]

The_Surfer schreef op 10 september 2004 @ 09:59:
[...]
Ik kan het mis hebben, maar ik hoorde dat er al XComposite support in KWin HEAD zit (net als Konsole overig) Misschien daar eens naar kijken?

Die ken ik. Dat is support om met je scrolwheel de transparantie van een window te veranderen en support om dropdown shadows aan te zetten zoals deze door xcompmgr worden getekend. Support voor ARGB (en dus alpha blending voor anti-aliased borders) heb ik echter nog niet gezien. Hoe dit op te lossen ben ik nu dus (een klein beetje) naar aan het kijken.

[Verwijderd]

Ik heb een heel eind geleden eens XOrg geinstalleerd. Grafisch ging alles normaal, behalve voor het keyboard. Dat was xkb error na error. De voorgestelde oplossingen op forums.gentoo.org hielpen spijtig genoeg niet.

Ik wil het graag eens opnieuw proberen. Maar mijn pc weer uren laten compilen op XOrg en Gnome zie ik momenteel niet direct zitten Alles werkt nu perfect (Gnome 2.6.0 + XFree86-4)

Weet iemand hoe Xorg en Gnome 2.7.x het doen ? Laatst toonde iemand mij screenshots van deze combinatie en wat me opviel waren de schaduwen en transparancy effecten.
Is dat nu iets van Xorg of van Gnome ?

[mOrPhie]

Verwijderd schreef op 10 september 2004 @ 12:21:
Is dat nu iets van Xorg of van Gnome ?

Beide.

X.org distribueert op dit moment XComposite mee. Een extensie die ervoor zorgt dat eye-candy op het window zelf en backpixmaps mogelijk zijn. Metacity in CVS/head (en dus in gnome 2.7.x, I presume) implementeerd wat mogelijkheden van Xcomposite in de vorm van dropshadows en transparante windows.

Let wel, dit is slechts een fractie van wat met XComposite mogelijk is. Mooiere en leukere (en nuttige) toepassingen ervan zullen de eerstkomende maanden gaan komen gok ik.

[_Squatt_]

Verwijderd schreef op 10 september 2004 @ 12:21:
Ik wil het graag eens opnieuw proberen. Maar mijn pc weer uren laten compilen op XOrg en Gnome zie ik momenteel niet direct zitten Alles werkt nu perfect (Gnome 2.6.0 + XFree86-4)

Als je Xorg compileert hoeft Gnome niet opnieuw te gebeuren.

[blouweKip]

Verwacht overigens geen snelheidswonderen met een nVidia kaart en xcompmgr draaiend, resizing van windows is gewoon sloom en artifacts bij verslepen blijf je houden (iig op dit moment).

Ik hoor meer mensen hierover maar ik heb toch een andere ervaring, bij mij draait alles met xcompmgr aan gewoon praktisch net zo snel als zonder, heb ik geen actifacts bij het slepen (wat op zn beurt ook gewoon lekker smooth gaat) en is het resizen van windows niet merkbaar trager dan zonder xcompmgr, zelfs als ik een divx draai en het venster (en de film, gebruik makend van de x11 driver) transparant maak dan nog is het verslepen van zo'n venster volledig smooth.

Ik heb tot nu toe maar 1 probleem gezien, en dat is dat wanneer xcompmgr crasht terwijl je een applicatie gebruikt met xv overlay deze daarna wat probleemjes heeft , het herstarten van die app lost dat dan weer op.

Wat me wel is opgevallen is dat de composite manager van metacity zelf de hele zooi enorm vertraagt (als je metacity gebruikt dus geen composite support erin bouwen)

[Verwijderd]

Ik hoop dat als X.org straks in Debian Unstable komt dat ik Xfree86 makkelijke kan vervangen.

Ik heb geen zin om me desktop helemaal opnieuw te gaan bouwen.

Zoiezo dan eerst maar een backup.

[Flying_Thunder]

Weet iemand toevallig al of er Debian packages van zijn? Heb nog niks kunnen vinden namelijk... anders wordt het toch compilen

[Verwijderd]

Flying_Thunder schreef op 10 september 2004 @ 15:09:
Weet iemand toevallig al of er Debian packages van zijn? Heb nog niks kunnen vinden namelijk... anders wordt het toch compilen

Heb ook lopen zoeken.. Het schijnt dat Debian eerst Sarge gaat releasen (het verdere hoe en wat weet ik ook niet) met Xorg en daarna Xorg ook in Unstable gaan stoppen. Debian moet gewoon van z'n luie reet af komen en Xorg packagen

[Schmoove]

Zijn hiervan ook ergens Fedora (Core 2) RPMs beschikbaar?

[mOrPhie]

Verwijderd schreef op 10 september 2004 @ 15:19:
[...]


Heb ook lopen zoeken.. Het schijnt dat Debian eerst Sarge gaat releasen (het verdere hoe en wat weet ik ook niet) met Xorg en daarna Xorg ook in Unstable gaan stoppen. Debian moet gewoon van z'n luie reet af komen en Xorg packagen

Beetje makkelijk roepen over een distro welke voornamelijk gevoed wordt door vrijwilligers.

[ Voor 67% gewijzigd door mOrPhie op 10-09-2004 15:23 ]

[Creepy]

Verwijderd schreef op 10 september 2004 @ 15:19:
[...]


Heb ook lopen zoeken.. Het schijnt dat Debian eerst Sarge gaat releasen (het verdere hoe en wat weet ik ook niet) metzonder Xorg maar met XFree86 4.3 en daarna Xorg ook in Unstable gaan stoppen. Debian moet gewoon van z'n luie reet af komen en Xorg packagen

[Niek]

blouweKip schreef op 10 september 2004 @ 13:31:
[...]

Ik hoor meer mensen hierover maar ik heb toch een andere ervaring, bij mij draait alles met xcompmgr aan gewoon praktisch net zo snel als zonder, heb ik geen actifacts bij het slepen (wat op zn beurt ook gewoon lekker smooth gaat) en is het resizen van windows niet merkbaar trager dan zonder xcompmgr, zelfs als ik een divx draai en het venster (en de film, gebruik makend van de x11 driver) transparant maak dan nog is het verslepen van zo'n venster volledig smooth.

Nou weet ik niet welke specs jij hebt, maar veel slomer zal mijn systeem niet kunnen zijn (AMD64 3000, laatste nVidia drivers, 2.6.8 en alles draaiend op ~amd64). Ik ben blijkbaar niet de enige met het probleem, want op de XOrg ML ontstaat nu een discussie van meerdere mensen die het hebben (link). Ik heb zo'n vermoeden dat het wel eens iets in de AMD64 driver van nVidia zou kunnen zijn, ik ben benieuwd wat er zo uitkomt. Ik ga iig van het weekend even XOrg compilen op mijn andere XP 1800 bak, kijken of het daar inderdaad sneller gaat.

Ik heb tot nu toe maar 1 probleem gezien, en dat is dat wanneer xcompmgr crasht terwijl je een applicatie gebruikt met xv overlay deze daarna wat probleemjes heeft , het herstarten van die app lost dat dan weer op.

(...)

Is een bekend probleem, zie oa dit. Het is ook al een paar keer gemeld op #mplayerdev maar het schijnt toch echt een xcompmgr bug te zijn.

[mOrPhie]

Hier een P4 1,6 Ghz met Nvidia GeForce 420 Go op mijn laptop. Dropshadows en transparante windows gaan gewoon smooth en geen probleem, echte het resizen is traag en geeft artifacts. Het is dus niet AMD64-specifiek.

Misschien dat BlauweKip z'n device-section uit xorg.conf kan tonen of daar nog iets anders in staat?

Op m'n desktop (R200) werkt alles snel, behalve transparante windows (akelig traag) en het resizen is ook net als op mijn laptop; traag + artifacts. Ik gebruik DRI omdat bij de officiele ATI-Drivers heel XComposite niet goed geladen schijnt te worden. Bij het starten van xcompmgr krijg ik de melding: "Damage extension not loaded".

[Niek]

Erg vreemd, afgaand op de berichten op IRC schijnen sommige mensen het probleem helemaal niet te hebben en anderen wel. Een filmpje van het probleem zoals het zich voordoet is hier te vinden: http://www.nbl.fi/~nbl48/composite.avi
blouweKip, kan je bovenstaande filmpje eens checken en kijken of het bij jou echt sneller is? Zo ja, zou je inderdaad even de relevante sections uit je xorg.conf willen posten (+specs)?

[Verwijderd]

Problemen of geen problemen, ik heb groot vertrouwen in dit project en ik hoop dat iedereen het een kans gunt. Desalniettemin vraag ik me af of ze geen "lite" versie zouden kunnen bouwen waarin geen netwerkfuncties e.d. geimplementeerd zijn (hier maak ik wel gebruik van, maar ik ken genoeg mensen die dat niet doen).

[Verwijderd]

Verwijderd schreef op 10 september 2004 @ 21:36:
Problemen of geen problemen, ik heb groot vertrouwen in dit project en ik hoop dat iedereen het een kans gunt. Desalniettemin vraag ik me af of ze geen "lite" versie zouden kunnen bouwen waarin geen netwerkfuncties e.d. geimplementeerd zijn (hier maak ik wel gebruik van, maar ik ken genoeg mensen die dat niet doen).

Het is wel vaker naar voren gebrach.
En zover ik weet is de netwerk transparante laag er bijna niet uit te slopen, omdat dit de structuur is waarop het gebouwt is.
Zelfs als je X gewoon lokaal draait, gaat al het verkeer via een socket. (lokaal dan wel via een unix socket en niet via een netwerk socket.)
Het ombouwen zou mogelijk neerkomen op een fiks stuk van X ombouwen.
waarbij je je af kunt vragen, of het dan niet slimmer is een compleet nieuw model te maken.
Wat ook al meerdere keren is gedaan. (zie elke andere X server)
Maar dan zit je wel weer met crappy, of miniem support voor jouw kaart.
en/of een verdomt kleine userbase.

En verder is de traag/log heid van X meestal te weiten aan andere dingen.
b.v. de responsivness van applicaties die in X draaien.

als disclamer moet ik er wel bij zetten, dat ik alles wat ik weet weet uit voorgaande topics over xfree. dus weet er eigenlijk geen zak vanaf

[smokalot]

Verwijderd schreef op 10 september 2004 @ 21:36:
Problemen of geen problemen, ik heb groot vertrouwen in dit project en ik hoop dat iedereen het een kans gunt. Desalniettemin vraag ik me af of ze geen "lite" versie zouden kunnen bouwen waarin geen netwerkfuncties e.d. geimplementeerd zijn (hier maak ik wel gebruik van, maar ik ken genoeg mensen die dat niet doen).

Dat punt is al vaker bediscussieerd in oa [rml][ discussie] X11 en XFree86 - problemen en toekomst[/rml].

De vraag is waarom je een lite-versie zou willen. Het is niet sneller (zie dat topic, en ook http://www.y-windows.org/about.html).

Er zijn ook projectjes zoals kdrive, ook wel tiny-x genoemd, directFB, freedesktop.org xserver (niet x.org dus).

Op zich voelt X.org (of XFree) wat log aan, en dan vooral tijdens het compileren. Enkele tientallen MBs, je bent uren bezig met compilen, oa omdat alle drivers gecompileerd worden, terwijl je er maar 1tje gebruikt.

Ik hoop dat tijdens de komende code-opschoning en herstructurering van X.org alles wat beter in elkaar komt te zitten, wellicht met een configuratie-optie oid, zodat je alleen je eigen driver kunt kiezen.

Maar goed, op zich is dat ook niet echt nodig, de meeste mensen gebruiken nu eenmaal alleen binaries, en die paar MB dat die binaries groot zijn is ook geen probleem voor een beetje moderne PC.

[_Squatt_]

smokalot schreef op 10 september 2004 @ 23:03:
[...]
Op zich voelt X.org (of XFree) wat log aan, en dan vooral tijdens het compileren. Enkele tientallen MBs, je bent uren bezig met compilen, oa omdat alle drivers gecompileerd worden, terwijl je er maar 1tje gebruikt.

Ik hoop dat tijdens de komende code-opschoning en herstructurering van X.org alles wat beter in elkaar komt te zitten, wellicht met een configuratie-optie oid, zodat je alleen je eigen driver kunt kiezen.

Ik kon (in ieder geval bij XFree86, Xorg nog niet zelf gecompileerd) gewoon in mijn host.def alle overbodige drivers weglaten.

[Jaap-Jan]

Verwijderd schreef op 10 september 2004 @ 15:19:
[...]


Heb ook lopen zoeken.. Het schijnt dat Debian eerst Sarge gaat releasen (het verdere hoe en wat weet ik ook niet) met Xorg en daarna Xorg ook in Unstable gaan stoppen. Debian moet gewoon van z'n luie reet af komen en Xorg packagen

Wat rustiger kan ook wel , het is zeker niet zo dat ze X.org niet gaan gebruiken, maar ze wachten eerst af totdat X.org een modulaire structuur krijgt, wat pas in de release ná 6.8 gaat gebeuren.

Ik sleep dit van een draadje in het neowin forum.

Het stukje van Daniel Stone waar het om draait: http://lists.debian.org/debian-x/2004/05/msg00431.html met de quote die ook op neowin wordt aangemerkt als de crux:

Thus, in my mind, the only viable option is to stick with our heavily
patched 4.3, and to use that as a springboard straight to the modular
tree, completely avoiding the switch to the X.Org monolithic tree, which
is a lot of work for really very little gain.

Kortom, als de X.org Xserver modulair is pleuren ze het er meteen in, omdat het switchen naar de op het moment monolytische X.org meer moeite kost dan dat het oplevert.

[Verwijderd]

Ik heb ooit op een gentoo RvS servertje K-Drive gecompiled. Daarna wou ik MatchBox gebruiken als UI, lekker klein en snel. Het beestje weigerde echter dienst, omdat K-Drive niet XFree86 is

Heb er toen ook nergens info over gevonden voor met k-drive.
Dan maar de oude methode: SSH & Shell

[rb338]

Xorg 6.8 draait als een zonnetje nu!
Alleen jammer dat Metacity 2.8.4 (en de CVS gister ook nog) niet goed samenwerken met de composite extensie. Maar dat is een kwestie van even wachten op 2.8.5

Heb overigens mijn Radeon 9600XT gister omgeruild bij Mycom. Voor 20 euro extra kreeg ik een GeForce 6800LE

[mOrPhie]

_Squatt_ schreef op 11 september 2004 @ 00:44:
[...]

Ik kon (in ieder geval bij XFree86, Xorg nog niet zelf gecompileerd) gewoon in mijn host.def alle overbodige drivers weglaten.

Dit kan in xorg ook.

rb338 schreef op 11 september 2004 @ 10:58:
Heb overigens mijn Radeon 9600XT gister omgeruild bij Mycom. Voor 20 euro extra kreeg ik een GeForce 6800LE

En werkt composite en transparante windows daar goed mee? Ook met resizen?

[blouweKip]

Hier een P4 1,6 Ghz met Nvidia GeForce 420 Go op mijn laptop. Dropshadows en transparante windows gaan gewoon smooth en geen probleem, echte het resizen is traag en geeft artifacts. Het is dus niet AMD64-specifiek.

Ik zit nu ook achter een laptop (2ghz celeron/gf 420 go) en daar is resizen (en ook transparantie) idd een stuk trager

Misschien dat BlauweKip z'n device-section uit xorg.conf kan tonen of daar nog iets anders in staat?

Zodra ik weer achter mn desktop pc zit zal ik er eens naar kijken, maar zo uit mn hoofd heb ik naast nvagp en renderaccel niet veel bijzonders aanstaan

blouweKip, kan je bovenstaande filmpje eens checken en kijken of het bij jou echt sneller is? Zo ja, zou je inderdaad even de relevante sections uit je xorg.conf willen posten (+specs)?

Het is duidelijker sneller dan in dat filmpje, wat ik op dat filmpje zie komt iig dichter in de buurt van de snelheid/traagheid die ik op mn laptop ervaar
Zodra ik weer achter mn pc zit zal ik mn device sectie eens posten en ik zal eens kijken of ik met xvidcap een filmpje kan maken

specs: 5900xt/nvidia-driver:1.0.6111/kernel 2.6.8(love-sources)@gentoo

[AlterEgo]

Ik heb inmiddels aangetoond dat de composite extensie kuickshow (kdegraphics) verstiert:
kuickshow laat alleen nog maar zwarte vlakken zien (zelfs na hercompilatie (Gentoo)).

De weergave van foto's in Digikam is ook verstoord: er wordt een "transparant" rest-image weergegeven in plaats van de afbeelding zelf. Ook hier levert hercompilatie niets op.

Morphie, je hebt wel gelijk, maar het duurde erg lang voordat ik de "fout" aan composite kon toeschrijven.

[ Voor 24% gewijzigd door AlterEgo op 12-09-2004 10:38 ]

[rb338]

mOrPhie schreef op 11 september 2004 @ 13:46:
[...]

En werkt composite en transparante windows daar goed mee? Ook met resizen?

Ja als ik KDE of niks gebruik ziet het er perfect uit, alles loopt soepeltjes
Alleen metacity gooit roet in 't eten. Maar dat heeft dus niks met de hardware te maken.

[mOrPhie]

AlterEgo schreef op 11 september 2004 @ 22:37:
Ik heb het idee dat de composite extensie kuickshow (kdegraphics) verstiert:
kuickshow laat alleen nog maar zwarte vlakken zien (zelfs na hercompilatie (Gentoo)).

Deze bug is bekend, maar was 1) geen blocker en 2) schijnt het een bug van kuickshow te zijn en niet van Composite. Er zou wel een oplossing voor gemaakt kunnen worden in composite, maar een aanpassing in kuickshow zou geprefereerd worden. Dit omdat er meer applicaties "broken" zijn. Zoals de flashplugin die heel X kan doen crashen (schijnt). Allemaal zou er een aparte oplossing voor in composite geschreven kunnen worden, maar de oorzaak ligt niet direct bij composite, maar bij de applicaties zelf, zo heb ik begrepen. Er was een tijdje geleden een discussie over in de mailinglists.

Wat er gebeurd is dat x.org een mailtje stuurt naar alle developers van programma's die broken zijn met de request dit te fixen. Al dan niet met een patch bijgevoegd. Linus Torvalds doet dit met linux net zo. Als linux continu aan compatibility moest blijven denken, hadden innoverende features nooit doorgang kunnen vinden. Het in alpha-status op de hoogte stellen van de developers van de problemen is dus de beste oplossing. Zij hebben dan genoeg tijd om het probleem voor de release op te lossen. Let wel, composite is nog niet nog lang niet af. Daarom is het ook standaard disabled.

Overigens zijn er veel mensen die het niet eens zijn met die benadering hoor, dus als je die discussie wilt voeren, doe dat dan in de mailinglist en niet met mij, da's nuttiger.

[Bergen]

Ik heb de boel op mijn Sarge systeempje ook even gecompileerd en 't draait allemaal netjes. Ik heb alleen 1 probleem en 1 vaag verschijnsel.

Eerst het vage verschijnsel: alle webpagina's worden met anti aliased lettertjes weergegeven, behalve de T.net frontpage! De hele FP wordt weergegeven in de oude fontsets. Ik heb verder nog geen enkele pagina kunnen vinden die er 'last' van heeft. Erg raar dit. Ik heb 't geprobeerd in Mozilla, Galeon en Epiphany en alle 3 vertonen ze dezelfde kuren.

Dan het probleem: xcompmgr krijg ik niet aan de praat. Ik heb 'm binnengehaald via CVS en start dan het autogen-script, maar dat levert foutmeldingen op:

~/xcompmgr$ ./autogen.sh
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal  --output=aclocal.m4t
autoreconf: `aclocal.m4' is created
autoreconf: configure.ac: tracing
autoreconf: configure.ac: not using Libtool
autoreconf: running: /usr/bin/autoconf
autoreconf: running: /usr/bin/autoheader
autoreconf: running: automake --add-missing --copy
configure.ac: 9: `automake requires `AM_CONFIG_HEADER', not `AC_CONFIG_HEADER'
automake: configure.ac: installing `./install-sh'
automake: configure.ac: installing `./mkinstalldirs'
automake: configure.ac: installing `./missing'
automake: configure.ac: installing `./config.guess'
automake: configure.ac: installing `./config.sub'
automake: Makefile.am: installing `./INSTALL'
automake: Makefile.am: installing `./COPYING'
configure.ac: 9: required file `./[config.h].in' not found
autoreconf: automake failed with exit status: 1

De foutmelding over AM_CONFIG_HEADER/AC_CONFIG_HEADER komt wel veel voor op Google maar biedt geen duidelijk oplossing. Als ik autoconf eenmaal draai kan ik daarna prima configure draaien, maar make zeurt vervolgens opnieuw dat [config.h].in ontbreekt. Simpelweg AC in AM veranderen in configure.ac werkt ook niet... Maar dat zou ook te makkelijk zijn. Kent iemand dit probleem?

[edit]
De bovenstaande output gebruikt ook weer niet ge-antialiased lettertjes. Geeft op zich niet, maar toch.
In andere GTK1-apps (xMule, XMMS) ziet alles er nu ook stukken beter uit! De supergrote fonts zijn nu van prachtig normaal formaat!

[ Voor 9% gewijzigd door Bergen op 12-09-2004 19:32 ]

[Verwijderd]

Bergen: ./autogen.sh is bedoeld voor ontwikkelaars, gebruikers horen ./configure te gebruiken.

[Bergen]

Zeker weten? (Ja jij kunt 't weten natuurlijk ) Ik volg gewoon deze howto en daar wordt 't netjes in uitgelegd.

Zelfs de officiële Xserver Install Guide vertelt je voor elk pakket autogen.sh te gebruiken. Wat is daar zo verkeerd aan?

Maargoed, die 2e levert ook steeds weer een knullige foutmelding op:

configure.ac:28: version mismatch.  This is Automake 1.7.9,
configure.ac:28: but the definition used by this AM_INIT_AUTOMAKE
configure.ac:28: comes from Automake 1.4-p6.  You should recreate
configure.ac:28: aclocal.m4 with aclocal and run automake again.

In de guide wordt automake 1.7.x vereist (niet hoger) en die heb ik dus. Ik verwijder aclocal.m4, maak een nieuwe aan met aclocal en start automake opnieuw, maar deze melding blijft terugkomen.

Weet jij een betere manier om xcompmgr aan de praat te krijgen?

[edit] hmm schiet me nu te binnen dat dit topic over de vooruitgang van Xorg hoort te gaan, niet over compilatiefouten. Als ik er niet uit kom start ik wel ff een nieuw topicje. Excuses.

[ Voor 63% gewijzigd door Bergen op 12-09-2004 23:13 ]

[mOrPhie]

Verwijderd schreef op 12 september 2004 @ 21:55:
Bergen: ./autogen.sh is bedoeld voor ontwikkelaars, gebruikers horen ./configure te gebruiken.

Waar je die wijsheid vandaan haalt weet ik niet, maar autogen.sh maakt het configurescript juist aan. Ofwel: autogen.sh _moet_ je juist draaien.

Bergen schreef op 12 september 2004 @ 22:29:
In de guide wordt automake 1.7.x vereist (niet hoger) en die heb ik dus.

Wat zegt

code:

# automake --version

bij jou? Soms zitten 2 versies elkaar in de weg en zul je wat simlinks moeten maken/aanpassen. Dit probleem komt voornamelijk bij debian voor schijnt.
(ik had het ook ooit)

[Sendy]

Als je autogen.sh _moet_ draaien zijn de ontwikkelaars niet wijs Met GNU autotools is het juist de bedoeling dat je alleen configure draait en daarna make.

Als je zelf met de autotools gewerkt heb weet je dat de tools best veranderen (er schijnt nogal een ontwikkel-gat te zijn geweest): daarom is het heel belangrijk om precies dezelfde versies als de ontwikkelaars gebruiken te hebben. ./configure bevat alleen de resulterende shell code.

Als het archief een configure bevat, zou ik gewoon proberen _alleen_ die te gebruiken.

[Bergen]

Yep had ik al gezien... automake is een alternatives-symlink, die had ik al opnieuw gelinked aan automake-1.7, dus --version geeft keurig 1.7.9 aan.

Sendy: uiteraard, maar bij de CVS-versie zitten geen configurescripts. Ik kan me ook voorstellen dat men bij elke update in de CVS-tree niet opnieuw een configurescript wil gaan maken...

[ Voor 40% gewijzigd door Bergen op 12-09-2004 23:47 ]

[mOrPhie]

Sendy schreef op 12 september 2004 @ 23:39:
Als het archief een configure bevat, zou ik gewoon proberen _alleen_ die te gebruiken.

1) die bevat ie niet
2) het is helemaal geen release, hell, xcompmgr is meer een spele/test-dingetje en niet eens bedoelt om echt gebruikt te worden.
3) ./autogen werkt gied, dus why bother?!
4) ik ben met je eens dat ./configure meer bekend is en eik gebruikt dient te worden, maar om ontwikkelaars "niet wijs" te noemen vind ik ver gaan. xcompmgr hoort in de eerste plaats niet eens gebruikt te worden door gebruikers, maar dat hou je toch niet tegen.

[Sendy]

Bergen >

Nee, maar je hoeft ook niet bij iedere update een nieuw configure script maken. Alleen bij updates waar er een module bijkomt of waar aan het buildsysteem iets is veranderd. En je moet dus niet iedere dag een nieuwe versie van de buildtools installeren

Morphie >
Ik weet niet precies tegen wie je die 4 punten opsomt, maar als je mijn post goed gelezen had had je kunnen zien dat je helemaal niet kan garanderen dat 3) autogen.sh gied werkt. Als je een iets andere versie van de tools gebruikt werkt namelijk niet meer.

Maar je hebt natuurlijk gelijk dat het een test versie is die helemaal niet makkelijk te bouwen hoeft te zijn.

[ Voor 46% gewijzigd door Sendy op 13-09-2004 00:01 ]

[Bergen]

Ik ben er uit. In /usr/bin stond een oude aclocal, in /usr/local/bin stond de juiste (behorende bij automake 1.7.9). Die gelinked aan 1.7, nu werkt alles weer netjes, maar 't is toch een beetje een rommeltje nu. Zometeen maar ff de links nalopen en kijken of alles staat zoals het hoort te staan want de boel raakt zo wel aardig in de war. Maargoed, ik ben blij, we gaan aan de slag.

Sendy schreef op 12 september 2004 @ 23:55:
Bergen >

Nee, maar je hoeft ook niet bij iedere update een nieuw configure script maken. Alleen bij updates waar er een module bijkomt of waar aan het buildsysteem iets is veranderd.

Ah ok, ik snap em. Tnx.

[ Voor 30% gewijzigd door Bergen op 13-09-2004 00:02 ]

[Flying_Thunder]

Japie_17 schreef op 11 september 2004 @ 02:01:
[...]

Wat rustiger kan ook wel , het is zeker niet zo dat ze X.org niet gaan gebruiken, maar ze wachten eerst af totdat X.org een modulaire structuur krijgt, wat pas in de release ná 6.8 gaat gebeuren.

Ik sleep dit van een draadje in het neowin forum.

Het stukje van Daniel Stone waar het om draait: http://lists.debian.org/debian-x/2004/05/msg00431.html met de quote die ook op neowin wordt aangemerkt als de crux:
[...]


Kortom, als de X.org Xserver modulair is pleuren ze het er meteen in, omdat het switchen naar de op het moment monolytische X.org meer moeite kost dan dat het oplevert.

Mja, maar ik zie ook nergens unofficial packages ofzo... Is ook niet makkelijk om te maken, maar toch had ik wel verwacht dat tenminste 1 iemand 't zou packen

[TGEN]

Mijn ervaring met Xorg onder NetBSD is vooralsnog bar en boos.

[Niek]

* Niek komt er net achter waarom zijn resizing zo sloom was
AGP voor mijn mobo (K8T800) werdt nog niet ondersteund in 2.6.7. Ik draai nu 2.6.8 en met 6111 icm AGPGART gaat het een stuk sneller (al is het nog niet 100% optimaal). De volgende versie van de nVidia drivers zal overigens een hoop verbeteringen in de RENDER acceleratie hebben, dus ik heb goede hoop
Overigens krijg ik mplayer icm xcompmgr niet aan de praat (zelfs niet met -vo x11), iemand een vergelijkbaar probleem?

[Flydude]

Ik heb de xcompmgr aangezwengeld (eindelijk tijd voor) en dat zag er leuk uit. Transparency is wel grappig, maar om nou het hele window transparant te maken vind ik nog wat overdreven. Hopelijk komt KDE binnenkort met aanpassingen die gebruik maken van de nieuwe mogelijkheden.
Dropshadows zijn erg handig. Ik krijg nu alleen wel overal dropshadows terwijl ik die eigenlijk alleen bij windowtjes wil en niet bij de taakbalk.

Maar goed, het is work in progress en het ziet er goed uit. Ben benieuwd wat KDE en Gnome ermee gaan doen om het eye-candy gehalte te verhogen (en en passant ook de functionaliteit, natuurlijk).

Om verder te voorkomen dat dit een Los-hier-je-x.org-6.8.0-problemen-op topic wordt, toch nog maar even de startvraag. Is men ook tevreden met de kant waar xorg naar toe gaat? Zijn er specifieke wensen die nog niet op de rol staan?

Beetje benieuwd naar de requirements, zeg maar.

[ Voor 1% gewijzigd door Flydude op 14-09-2004 10:24 . Reden: typo ]

[_JGC_]

Verwijderd schreef op 10 september 2004 @ 15:19:
[...]


Heb ook lopen zoeken.. Het schijnt dat Debian eerst Sarge gaat releasen (het verdere hoe en wat weet ik ook niet) met Xorg en daarna Xorg ook in Unstable gaan stoppen. Debian moet gewoon van z'n luie reet af komen en Xorg packagen

Sarge zal gereleased worden met xfree86 4.3.0, xorg is van latere zorg.

Debian loopt standaard een of meerdere versies van Xfree86 achter, omdat het een enorm pakket is wat heel rottig is te porten naar andere architecturen dan i386. Bij een distro als archlinux is het heel simpel: je hebt alleen i386, en je hoeft niet eens te testen, je compileert de zooi en je uploadt het, de users zoeken het zelf maar uit.

Op dit moment zie ik weinig tot geen plannen voor xorg support, aangezien de site van de X strike force met geen woord rept over xorg support:
http://people.debian.org/~branden/

[Bergen]

Flydude schreef op 14 september 2004 @ 10:24:
Dropshadows zijn erg handig. Ik krijg nu alleen wel overal dropshadows terwijl ik die eigenlijk alleen bij windowtjes wil en niet bij de taakbalk.

Dan moet je de C even toevoegen bij de commandline options, dus bijvoorbeeld ipv xcompmgr -cf doe je -cfC. Uit de source:

case 'C':
    excludeDockShadows = True;
    break;

[Bergen]

Notitie: 6.8.1 is uit.

The X.Org Foundation is pleased to announce X11R6.8.1, the latest
stable release of X.Org, the X standard implementation.

This version is purely a security release, addressing multiple integer
and stack overflows in libXpm, the X Pixmap library; all known versions
of X (both XFree86 and X.Org) are affected, so all users of X are
strongly encouraged to upgrade. Vendors should have patches available
for their versions of X.

The CVE numbers for these vulnerabilities are CAN-2004-0687 (integer
overflows) and CAN-2004-0688 (stack overflows).

For the 6.8.1 release, two choices have been provided -- the standard
set of seven tarballs, and a single tarball.

If you download the traditional split tarballs, the first three contain
everything except the fonts and general X11 documentation. Those three
are sufficient for building X11R6.8 if you already have a set of fonts.
The fourth and fifth contain the fonts. The sixth contains the source
for the general X11 documentation. The seventh contains the general
X11 documentation in hardcopy format.

For the single tarball (xorg-6.8.0.tar.gz), everything described in the
previous paragraph is available in the single tarball.

Downloads are available from:
http://freedesktop.org/~xorg/X11R6.8.1/src/

[ Voor 7% gewijzigd door Bergen op 15-09-2004 16:27 . Reden: blä ]

[Verwijderd]

/me is onder de indruk

Het is een tijd geleden (+/- driekwart jaar) dat ik geprobeerd heb om Linux als workstation te gebruiken. Wat is er een vooruitgang geboekt zeg

Schone Debian 3.1 installatie, 2.6.8 kernel en een eigengebakken X.org 6.8.0 icm KDE 3.2.2: Woei, wat een snelheid. Het is de eerste keer is dat ik het bijna sneller aan vind voelen dan Windows. Alles start ook snel op en loopt lekker. En dat zonder enige drivers van ATi.

Voor mijn gevoel is X weer op de goede weg, want het ging wel heel traag met de ontwikkeling

[mpol]

Flydude schreef op 14 september 2004 @ 10:24:
Om verder te voorkomen dat dit een Los-hier-je-x.org-6.8.0-problemen-op topic wordt, toch nog maar even de startvraag. Is men ook tevreden met de kant waar xorg naar toe gaat? Zijn er specifieke wensen die nog niet op de rol staan?

Weet iemand wat er gaat gebeuren met rootwindows? Ik zou daar graag wat ontwikkeling in zien. Zoals het nu is gebruiken de grote desktops (KDE, GNOME, XFce) niet meer de rootwindow, maar gebruiken ze een borderless maximised window over de rootwindow, om hier hun dingetjes op te doen zoals icons tekenen, wachten op events (muisklik voor menu), etc. Het nadeel is dat je dus niets meer hebt aan je rootwindow, en ik wil hem graag terug. Ik wil root-tail, xplanet en mplayer -rootwin kunnen draaien. Dat kan nu ook, maar je ziet er niks van :-) En er zijn wel hacks voor die software om het wel te laten werken, maar ja, het zijn gewoon hacks, en ik wil mijn rootwindow terug. De enige optie om die nu terug te krijgen is om terug te gaan naar een windowmanager en de wereld van de desktops te verlaten.
Wat ik van de XFce devs had begrepen is het te moeilijk om de rootwindow te gebruiken voor hun desktop, daarom gebruiken ze hun eigen borderless window, met de mededeling dat de andere desktops dat ook doen, dus het is acceptabel. Ze wachten op Xorg om er wat voor te verzinnen.

[Spider.007]

Inmiddels installeer ik al een aantal weken lang netjes de nieuwste Xorg versies; maar toch merk ik geen enkel verschil met voorgaande versies. Heeft iemand enig idee of de wat minder vaak geupdate WM's (XFCE v4.2 ofzo) ook al bezig zijn met de features die Xorg nu gaat bieden? En waarom is het changelog zo onmogelijk te vinden op de Xorg website?

@mpol; interessant punt. Zou het toevoegen van features aan het rootwindow hier een oplossing voor kunnen verzinnen? Ik snap ook niet helemaal waarom dit idee van het rootwindow momenteel zo ondergesneeuwt is; zelfs XFCE gooit er een eigen xfdesktop overheen wat als enige functionalteit een middle-mouse-button menu toevoegt

[mpol]

Bij XFce is er nu een discussie over composite features. Er is iemand die er aan werkt (Olivier zelf), maar hij heeft nog niet iets wat goed werkt. Het komt alleen in 4.2 als het ook in de alpha versie van 4.2 zit. Zo niet dan wordt het verschoven naar 4.4 (volgend jaar...). Als het wel in 4.2 komt, dan wordt het ws. default gedisabled.