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

[c0deaddict]

Hoe zit het nou met de nieuwe X.org
Er zou toch een versie 7.0 komen waarin grote delen van de oude X Server herschreven zouden worden ?
Want nu is X.Org niet veel meer dan XFree86 met een paar extra extensies ... (toch ?)

[dawuss]

KLEI_j0s schreef op maandag 17 januari 2005 @ 22:24:
Hoe zit het nou met de nieuwe X.org
Er zou toch een versie 7.0 komen waarin grote delen van de oude X Server herschreven zouden worden ?
Want nu is X.Org niet veel meer dan XFree86 met een paar extra extensies ... (toch ?)

Als het goed is wordt in de nieuwe X.org de hele boel netjes gemodulariseerd. X.org is zeker meer dan een fork van XFree86 met wat extra's. Op het moment wordt vooral nagedacht over de toekomst van de architectuur rond X zelf. Ze zitten daar heus niet stil

[Anoniem: 27915]

Jullie bedoelen KDrive? Da's de opvolger van X.org waar Keith Packard en dergelijke aan werken. Flink alpha, maar te volgen via de freedesktop.org repositories. Enkelen durvals hier op GoT hebben het geloof ik zelfs draaien...

[Erhnam]

Anoniem: 27915 schreef op maandag 17 januari 2005 @ 23:19:
Jullie bedoelen KDrive? Da's de opvolger van X.org waar Keith Packard en dergelijke aan werken. Flink alpha, maar te volgen via de freedesktop.org repositories. Enkelen durvals hier op GoT hebben het geloof ik zelfs draaien...

freedesktop.org repositories... Heb jij een url voor mij? Ben wel benieuwd!

[Anoniem: 27915]

http://www.freedesktop.org/wiki/Software_2fXserver
http://www.freedesktop.org/wiki/Software_2fxlibs

[Erhnam]

http://blog.drinsama.de/erich/en/linux

Nog wat kleine probleempjes in de laatste releases. Ziet er naar uit dat het allemaal wat langer op zich laat wachten.

[dawuss]

Wat mij wel erg tegenvalt in de huidige releases van de X.org XServer, is dat de composite extensie niet tegelijk geladen kan worden met GLX driver. Ik hoop dat ze dat snel gaan implementeren, want het is een behoorlijke tegenvaller.

[Bananenplant]

Misschien een open deur, maar weet iemand of x.org ook tzt in debian gaat komen..?

[sampoo]

ucchan schreef op woensdag 26 januari 2005 @ 14:06:
Misschien een open deur, maar weet iemand of x.org ook tzt in debian gaat komen..?

Tzt komt x.org om debian. Maar reken maar niet dat het vlot zal zijn. debian's eigen patches op Xfree86 maken het retestabiel en x.org zal voorlopig te unstable zijn om zelf in debian "unstable" een plekje te vinden.

[Anoniem: 27915]

Wat een gelul. . Debian is simpelweg te traag, en da's niet voor 't eerst...

[dawuss]

Anoniem: 27915 schreef op donderdag 27 januari 2005 @ 00:15:
Wat een gelul. . Debian is simpelweg te traag, en da's niet voor 't eerst...

Volgens mij was het een bewuste keuze X.org niet in debian op te nemen voor het helemaal gemodulariseerd is, omdat er anders veel overbodig werk gebeurt.

[mOrPhie]

dawuss schreef op donderdag 27 januari 2005 @ 00:26:
[...]

Volgens mij was het een bewuste keuze X.org niet in debian op te nemen voor het helemaal gemodulariseerd is, omdat er anders veel overbodig werk gebeurt.

Getuige de vele discussies hieromtrend op de x.org mailinglist, is het nog helemaal niet zeker dat X.org modular gaat worden. Er zijn nog veel voorstanders van de monolitic tree en veel verschillende meningen over een een modular x.org. En als het modular gaat worden, zal dat zoveel werk gaan kosten, dat met het aantal developers nu, het nog wel een tijdje zal duren voordat de modular-release het daglicht ziet. Misschien praten we dan over R6.9 of wellicht zelfs R7. R7 zal immers ingrijpende veranderingen ondergaan en een modular tree past daarom in dat rijtje thuis.

Of dat dus de exacte reden is waarom debian nog niet is overgestapt op X.Org betwijfel ik dus. Ik ga nog steeds mee met de theorie van beelzebubu.

[Erhnam]

mOrPhie schreef op donderdag 27 januari 2005 @ 00:58:
[...]


Getuige de vele discussies hieromtrend op de x.org mailinglist, is het nog helemaal niet zeker dat X.org modular gaat worden. Er zijn nog veel voorstanders van de monolitic tree en veel verschillende meningen over een een modular x.org. En als het modular gaat worden, zal dat zoveel werk gaan kosten, dat met het aantal developers nu, het nog wel een tijdje zal duren voordat de modular-release het daglicht ziet. Misschien praten we dan over R6.9 of wellicht zelfs R7. R7 zal immers ingrijpende veranderingen ondergaan en een modular tree past daarom in dat rijtje thuis.

Of dat dus de exacte reden is waarom debian nog niet is overgestapt op X.Org betwijfel ik dus. Ik ga nog steeds mee met de theorie van beelzebubu.

De reden waarom Dabian nog niet is overgegaan is omdat er nog te veel veranderingen en wijzigingen plaatsvinden op de x.org tree, met gevolg dat er nog te veel issues en bugs in de tree zitten... (zie de blogs/planet) Dabian vernieuwt onderdelen pas als gebleken is dat ze echt stabiel zijn. Ik verwacht dat ze niet tijden lang kunnen achterblijven (omdat andere onderdelen gnome/kde wel vooruit gaan) en op een bepaald moment moeten ze wel een versie uit de tree accepten. Deze zouden ze dan eventueel zelf kunnen verbeteren met patches om zo meer stabiliteit te brengen.

[Erhnam]

Alan Coopersmith: Xorg 6.8.2 release candidate 3

http://blogs.sun.com/roll...50125#xorg_6_8_2_release1

Overige newsbronnen:

http://planet.freedesktop.org/

http://www.technorati.com/tag/Xorg

[ Voor 31% gewijzigd door Erhnam op 27-01-2005 10:56 ]

[DeMoN]

Anoniem: 27915 schreef op donderdag 27 januari 2005 @ 00:15:
Wat een gelul. . Debian is simpelweg te traag, en da's niet voor 't eerst...

Beetje offtopic, maar waarom zou Debian nou weer te traag zijn?
Omdat alles binary is?

[ Voor 7% gewijzigd door DeMoN op 27-01-2005 13:18 ]

[Erhnam]

DeMoN schreef op donderdag 27 januari 2005 @ 13:17:
[...]
Beetje offtopic, maar waarom zou Debian nou weer te traag zijn?
Omdat alles binary is?

Trager != snelheid.

Dabian is wat 'trager' op het gebied van vernieuwing. Ze geven de voorkeur aan stabiliteit boven vernieuwing. Om die reden nemen ze niet het nieuwste van het nieuwste op in hun tree's en zijn dus wat trager met het oppakken van de laatste releases.

[DeMoN]

Erhnam schreef op donderdag 27 januari 2005 @ 13:26:
[...]


Trager != snelheid.

Dabian is wat 'trager' op het gebied van vernieuwing. Ze geven de voorkeur aan stabiliteit boven vernieuwing. Om die reden nemen ze niet het nieuwste van het nieuwste op in hun tree's en zijn dus wat trager met het oppakken van de laatste releases.

omg, ja dat weet ik.. verkeerd opgevat en dat zelfs na het hele topic gelezen te hebben.

* DeMoN gaat koffie halen

[Anoniem: 27915]

Erhnam schreef op donderdag 27 januari 2005 @ 09:28:
De reden waarom Dabian nog niet is overgegaan is omdat er nog te veel veranderingen en wijzigingen plaatsvinden op de x.org tree, met gevolg dat er nog te veel issues en bugs in de tree zitten... (zie de blogs/planet) Dabian vernieuwt onderdelen pas als gebleken is dat ze echt stabiel zijn. Ik verwacht dat ze niet tijden lang kunnen achterblijven (omdat andere onderdelen gnome/kde wel vooruit gaan) en op een bepaald moment moeten ze wel een versie uit de tree accepten. Deze zouden ze dan eventueel zelf kunnen verbeteren met patches om zo meer stabiliteit te brengen.

Volgens mij haal je een aantal dingen enorm gruwelijk door elkaar. De blogs die je aanhaalt, gaan over de CVS versie van X.org, evenals de "vele veranderingen in de tree". Dat is een goed iets, dat geeft namelijk aan dat het project actief ontwikkeld wordt. En inderdaad, dan kan er veel instabiliteit inkruipen. Daarom zul je weinig gekken vinden die CVS draaien.

Daarom heeft men het fantastische moderne concept van releases uitgevonden. Zo is er bijvoorbeeld een X.org release gedaan, welke keurig goed werkt op bijvoorbeeld Fedora. Die release zou evenzogoed in Debian kunnen. Echter, Debian wil graag compatibiliteit behouden (legacy) met XFree86, en wil daarom graag met een generiek provides-systeem gaan werken. Dit betekent feitelijk dat je XFree86 en X.org beiden kan draaien en dat een van beiden genoeg is om als depends: voor enig ander pakket te dienen zonder intern te conflicteren. Dat blijkt echter niet zo makkelijk. Fedora is simpelweg overgestapt (de simpele approach).

Dat Debian moeilijk doet is begrijpelijk, ze supporten een enorme tyfuszooi aan vage obscure hardware, maar consequentie blijft staan: ze zijn traag. .

[Erhnam]

Hier weer een kleine update:

XGL: Draai X met een opengl backend:

http://lists.freedesktop....2004-November/004358.html

http://nat.org/2005/february/

source:

http://cvs.freedesktop.org/xserver/xserver/hw/xgl/

Goede blogs:
http://www.technorati.com/tag/Xorg
http://blog.drinsama.de/erich/en/linux
http://planet.freedesktop.org/

[ Voor 21% gewijzigd door Erhnam op 10-02-2005 09:34 ]

[mOrPhie]

Xgl is alweer een paar maanden geleden hoor.

Overigens is Xgl verre van ideaal. De complete output wordt naar een fullscreen glx-window gegooit. Dit is te verhelpen natuurlijk, maar heeft als nadeel dat hij een eigen custom windowmanager heeft moeten hacken.

Ik heb het toentertijd ook geprobeerd te builden, maar heb het na 3 avonden klooien opgegeven.

[_JGC_]

Anoniem: 27915 schreef op donderdag 27 januari 2005 @ 16:12:
[...]


Volgens mij haal je een aantal dingen enorm gruwelijk door elkaar. De blogs die je aanhaalt, gaan over de CVS versie van X.org, evenals de "vele veranderingen in de tree". Dat is een goed iets, dat geeft namelijk aan dat het project actief ontwikkeld wordt. En inderdaad, dan kan er veel instabiliteit inkruipen. Daarom zul je weinig gekken vinden die CVS draaien.

Daarom heeft men het fantastische moderne concept van releases uitgevonden. Zo is er bijvoorbeeld een X.org release gedaan, welke keurig goed werkt op bijvoorbeeld Fedora. Die release zou evenzogoed in Debian kunnen. Echter, Debian wil graag compatibiliteit behouden (legacy) met XFree86, en wil daarom graag met een generiek provides-systeem gaan werken. Dit betekent feitelijk dat je XFree86 en X.org beiden kan draaien en dat een van beiden genoeg is om als depends: voor enig ander pakket te dienen zonder intern te conflicteren. Dat blijkt echter niet zo makkelijk. Fedora is simpelweg overgestapt (de simpele approach).

Dat Debian moeilijk doet is begrijpelijk, ze supporten een enorme tyfuszooi aan vage obscure hardware, maar consequentie blijft staan: ze zijn traag. .

Mja, is Xorg net zo portable naar alle architecturen waar debian op verkrijgbaar is als de huidige XFree86 4.3.0 dat is op dit moment?

Wat betreft het provides systeem: ik zie problemen bij debian als ze xorg en xfree86 tegelijk gaan supporten: Xorg heeft een paar nieuwe libraries en extenties waar programma's tegen gaan linken. Deze programma's werken dan niet meer op de oude XFree86. Op Archlinux hebben we dat hacky opgelost door gewoon die libs uit Xorg te lichten en in de XFree86 tree te patchen en vervolgens een rebuild te doen. Alle maintainers bakken tegen Xorg, terwijl arme zieluge ATi users destijds aan XFree86 vast zaten.

[Erhnam]

x.org 6.8.2:

http://linux.slashdot.org...0/1735240&tid=104&tid=106

[Niek]

Erhnam schreef op donderdag 10 februari 2005 @ 20:50:
x.org 6.8.2:

http://linux.slashdot.org...0/1735240&tid=104&tid=106

Torrentje: klik
Changelog: http://x.org/XOrg_Press_Releases/X11R6.8.2.html

Ziet er uit dat het vooral een paar bugfixes zijn

[Erhnam]

Misschien nog wat leuks:

http://linuxreviews.org/features/3ddesktop/

3d-desktop:

http://fedoranews.org/tchung/3ddesktop/
http://desk3d.sourceforge.net/

[mOrPhie]

3Ddesktop heeft niets met X11-development te maken. Het is een desktop-switch tool, puur voor de eye-candy.

[Erhnam]

XDevConf 2005 overview:

http://primates.ximian.com/~federico/news-2004-04.html#30

[Erhnam]

http://www.freedesktop.org/Software/Xgl

Om dit aan te zetten:
http://gentoo-wiki.com/TIP_Xorg_X11_and_Transparency

Xgl ontwikkelingen!

[ Voor 40% gewijzigd door Erhnam op 01-03-2005 16:32 ]

[mOrPhie]

AllowGLXWithComposite != Xgl

Mensen moeten hun mailinglists en documentatie beter lezen.
Er was ooit een probleem met composite, dat OpenGL-applicaties composite deden crashen. Deze vrij nieuwe optie heeft dit probleem opgelost. Dit heeft echter helemaal _niets_ met Xgl te maken.

Xgl is een interpratie van X11 naar OpenGL. Hierdoor ontstaat een heavy geaccellereerde XServer die op dit moment niets meer is dan een fullscreen GLX-window in een bestaande X11-Server. Gezien de vele discussies op de mailinglists is wel te veronderstellen dat een hoop mensen interesse hebben in de techniek. Dat is waarom developers nu bezig zijn met "GL" als ware backend voor x.org te gaan implementeren. Hiervoor zal waarschijnlijk GLX ontzien worden en een apart iets bedacht worden (of al bedacht zijn?). GLX richt zich namelijk op windows binnen een X11-implementatie, terwijl het doel is de hele X-Server met opengl-technieken te renderen. De echte mogelijkheden zijn mij nog niet precies duidelijk, maar dat de mogelijkheden waarschijnlijk koel zijn voor het oog is een ding wat zeker is.

[Anoniem: 27915]

De echt interessante zaken zijn hedentendage de integratie van Cairo in de X client toolkits. Hierdoor gebruik je voor geavanceerde drawing materie (bv. curved lines, alpha, RGB scaling, ...) gebruik van je videokaart z'n hardware functies (mits ondersteund). Dit maakt bestaande zaken soms sneller, maar is vooral interessant voor nieuwe snufjes. Denk bijvoorbeeld aan het zien van een window terwijl die minimized wordt (animatie), het hebben van een directe window overview als je alt-tab doet (en instant switch als je window wisselt), en nog wat van dat soort dingen. Basically wat Apple in OS X doet. Ik verwacht dit in GNOME 2.12 of 2.14 voor 't eerste op de user desktop te zien.

[mOrPhie]

Helemaal mee eens beelzebubu. Ik heb verschillende gtkcairo-dingen gecompileerd om te testen en ik ben zeer onder de indruk. Cairo gaat zeker een belangrijke innovatie in X betekenen.

Om dat aan te vullen. Arthur, de painting-engine van Qt 4.0, zal zeer waarschijnlijk ook cairo gaan ondersteunen, naast OpenGL en Xlib.

[BoAC]

mOrPhie schreef op dinsdag 01 maart 2005 @ 21:55:
Helemaal mee eens beelzebubu. Ik heb verschillende gtkcairo-dingen gecompileerd om te testen en ik ben zeer onder de indruk. Cairo gaat zeker een belangrijke innovatie in X betekenen.

Om dat aan te vullen. Arthur, de painting-engine van Qt 4.0, zal zeer waarschijnlijk ook cairo gaan ondersteunen, naast OpenGL en Xlib.

Alleen zonder glitz is cairo 10x trager. Maar glitz is nog een library die bovenop X11 draait zoals beelzebubu al zei..

Hoewel: Cairo backends

[ Voor 5% gewijzigd door BoAC op 02-03-2005 08:04 ]

[mOrPhie]

Even een kick om te melden dat http://www.xfree86.org/ ons hetvolgende nieuws brengt:

Solid like a Rock: 4.5.0 goes Live
It is on our website and ready to download. 4.5.0 was born yesterday and the delivery I hear wa smooth. Get a copy now. It's just terrific....details to follow.

Ik houd de maillinglists van XFree86 niet bij en heb dus geen idee wat er zo "terrific" aan is. Eén ding is zeker: Ik ben best wel benieuwd naar de details.

[laurencevde]

http://www.xfree86.org/4.5.0/RELNOTES3.html

[Erhnam]

Hele zooi fancy stuff! Spinnende windows, Draaiende desktops met filmpjes spelend rechts onderin het overzicht! Dit mag je niet missen:

K00l Luminocity OpenGL Videos

http://www.gnome.org/~seth/blog/xshots





http://www.gnome.org/~set...ey-hoot/WobblyWindows.avi
http://www.gnome.org/~set...ot/WorkspaceSwitching.avi
http://www.gnome.org/~set...key-hoot/MovieOfMovie.avi
http://www.gnome.org/~set...ot/TransparentWindows.avi


http://www.gnome.org/~seth/blog/relations
http://galaxy.osnews.com/email.php?blog_id=672

[BoAC]

Erhnam schreef op donderdag 24 maart 2005 @ 09:50:
Hele zooi fancy stuff! Spinnende windows, Draaiende desktops met filmpjes spelend rechts onderin het overzicht! Dit mag je niet missen:

K00l Luminocity OpenGL Videos

http://www.gnome.org/~seth/blog/xshots

[afbeelding]

[afbeelding]

http://www.gnome.org/~set...ey-hoot/WobblyWindows.avi
http://www.gnome.org/~set...ot/WorkspaceSwitching.avi
http://www.gnome.org/~set...key-hoot/MovieOfMovie.avi
http://www.gnome.org/~set...ot/TransparentWindows.avi


http://www.gnome.org/~seth/blog/relations
http://galaxy.osnews.com/email.php?blog_id=672

Heb ik vandaag ook toevallig gezien via gnomedesktop
Ik denk dat deze fancy 'toys' niet geschikt zijn voor de gewone desktop omdat het vermoeiend is, maar voor presentatie-doeleinden zeker interessant

[Sir Isaac]

Helemaal me BoAC eens. Toen ik die filmpjes zag dacht ik: "Hé, kunnen jullie je niet met nuttiger dingen bezig houden?" Prima om de videokaart in te zetten voor de desktop, bijv door je hele desktop pixel onafhankelijk te maken, maar dit soort onzin zit ik niet op te wachten.

[Erhnam]

Sir Isaac schreef op donderdag 24 maart 2005 @ 10:25:
Helemaal me BoAC eens. Toen ik die filmpjes zag dacht ik: "Hé, kunnen jullie je niet met nuttiger dingen bezig houden?" Prima om de videokaart in te zetten voor de desktop, bijv door je hele desktop pixel onafhankelijk te maken, maar dit soort onzin zit ik niet op te wachten.

Onzin! Ik vind het helemaal geweldig. Behalve dat alles sneller wordt ziet het er ook nog eens stukken fraaier uit! Verder zorgen al de fancy effecten er voor dat je precies weet waar de muis is en welk window je vast hebt, doordat de aandacht er meer op wordt gevestigd. Een pop-up bv of een uitklappend menu is daardoor sneller te herkennen en maakt het werken stukken fijner! Zaken zoals het in de tray afspelen van het filmpje vind ik ook zeer handig.

[ Voor 8% gewijzigd door Erhnam op 24-03-2005 12:09 ]

[smokalot]

Leuk dat er mensen zijn die dit soort dingen implementeren. Ik denk dat je dit niet moet zien als dingen die in gnome gaan komen, maar een manier om te testen hoe je sommige dingen op kunt lossen. De effecten die in gnome (en, hoop ik, ook in KDE) terecht zullen komen zullen functioneler zijn.

Er kan nog veel gebeuren om desktop's beter te laten voelen, de foutjes die bij het renderen gemaakt worden zorgen ervoor dat het niet solide aanvoelt. Dit soort dingen kan helpen.

[Anoniem: 27915]

BoAC schreef op donderdag 24 maart 2005 @ 09:53:
Ik denk dat deze fancy 'toys' niet geschikt zijn voor de gewone desktop omdat het vermoeiend is, maar voor presentatie-doeleinden zeker interessant

De ontwikkelaars gebruiken luminocity als "toy". Ze proberen grappige dingen uit, ze kijken naar de artistieke mogelijkheden van het systeem, performance-issues, etc. Het is echt niks anders dan "spelen". Uiteindelijk zijn zij ook mensen. . Laat ze zich lekker uitleven, doen we toch allemaal wel eens? En ondertussen kunnen ze op deze manier de gehele backend goed testen en stabiel en snel maken.

In metacity, de GNOME window manager, zullen uiteindelijk functionele toevoegingen komen, zoals faded drop-down menus, slick minimize (a la apple), semi-translucent pop-up dialogs (en evt. ook menus), etcetera. Eye-candy met een functie. Maar dat komt later wel. . Alles op z'n tijd.

[BoAC]

Ik heb niet gezegd dat het onzinnig is Zie de ontwikkelaars zelf:Luminocity

Over the last week or so, I've been working on a new toy, a combination window manager and compositing manager with GL output called 'luminocity'. Note the word toy: I have no intention of ever worrying about all the edge cases and broken legacy clients that you need in a real window manager.

[mOrPhie]

Persoonlijk vind ik dit soort dingen juist heel erg interessant. Linux op de desktop heeft zich voor mij allang bewezen. De software is er, de makkelijke installaties zijn er. Dat developers zich nu gaan bezig houden met fancy window-dingetjes zoals dit is juist heel begrijpelijk. Het is linux-gebruikers-eigen om te zeuren over hardware-gebruikende dingen. Mensen, het is ook uit te zetten als je het niet wilt.

Nee, ik vind dit juist wel leuk. Het bewijst dat linux grafisch gewoon tot heel veel in staat is en eye-candy verkoopt. Kijk alleen al hoeveel mensen in windows dat StyleXP gebruiken, of hoeveel mensen er karamba gebruiken terwijl diezelfde info commandline beschikbaar is. Of de fluxbox-gebruiker het er nu mee eens is of niet. Imho krijgen de laatste maanden (het laatste jaar?) developers het door: Het oog wil ook wat.

[Erhnam]

Er is nu ook een wiki met hoe je dit opzet:

http://live.gnome.org/Luminocity

[BoAC]

Erhnam schreef op maandag 28 maart 2005 @ 19:53:
Er is nu ook een wiki met hoe je dit opzet:

http://live.gnome.org/Luminocity

_{Wat houd je tegen om het zelf te proberen op te zetten ipv het hier te vragen?}

[mOrPhie]

Voor de mensen die het leuk vinden: In het screenshots topic had ik al wat laten zien, maar er waren wat requests om filmpjes geweest. Ik ben even met xvidcap en mencoder gaan stoeien en ben met dit filmpje gekomen een paar dagen terug: http://crew.tweakers.net/...ocity/luminocity_lavc.avi.

[mkools24]

mOrPhie schreef op zaterdag 02 april 2005 @ 09:42:
Voor de mensen die het leuk vinden: In het screenshots topic had ik al wat laten zien, maar er waren wat requests om filmpjes geweest. Ik ben even met xvidcap en mencoder gaan stoeien en ben met dit filmpje gekomen een paar dagen terug: http://crew.tweakers.net/...ocity/luminocity_lavc.avi.

Erg strak gedaan die capture! Dus het kan wel

Maar hoe heb je dat gedaan met xvidcap?
Ik ben uren aan het stoeien geweest maar het was niet vooruit te branden!

Mijn CPU ging steeds op 100% draaien zodra ik de capture startte.

Start je xvidcap onder luminocity of onder je gewone X desktop?
Heb je misschien een korte tutorial? Welke codecs ed, of cmd-line je gebruikt?

Wat me verder opviel bij luminocity is dat de shell box erg traag en schokkerig ging, terwijl apps zoals firefox en andere xwindows apps wel gewoon vloeiend gingen, maar dat zie ik niet terug in jou capture waar de shellbox wel snel gaat.

[DeMoN]

mOrPhie schreef op zaterdag 02 april 2005 @ 09:42:
Voor de mensen die het leuk vinden: In het screenshots topic had ik al wat laten zien, maar er waren wat requests om filmpjes geweest. Ik ben even met xvidcap en mencoder gaan stoeien en ben met dit filmpje gekomen een paar dagen terug: http://crew.tweakers.net/...ocity/luminocity_lavc.avi.

* DeMoN kwijl van mond wegveegt

[Anoniem: 27915]

Dude, dat is zwaar ziek. . Ziet d'r verder wel cool uit. Mooi hoor. .

[mOrPhie]

mkools24 schreef op maandag 11 april 2005 @ 09:05:
[...]

Start je xvidcap onder luminocity of onder je gewone X desktop?

Ik heb een 640x480 (luminocity 4xdesktop-taal is dat dus 640x1920) window gemaakt en met xvidcap precies die inhoud gecaptured vanaf mijn gewone X-Desktop.

Technisch gezien kun je xvidcap niet in de luminocity omgeving draaien, of je zou gewoon de effecten niet meekrijgen. Xvidcap maakt namelijk gebruik van XFake. XFake is een X-Server (gebaseerd op fd.o kdrive) die alleen op de offscreen-buffer schrijft, maar dit wordt niet geflusht naar de grafische kaart. Luminocity leest de composite-gegevens uit van de XFake server en gebruikt z'n eigen composite-manager om dit in opengl te vertalen. Wat je dus ziet is dus geen nested X-window, maar puur een OpenGL window. Dat is ook de reden waarom deze techniek in z'n kinderschoenen staat. Puur gezien is dit namelijk inefficient als wat. Xgl (en technieken als Glitz) gaan hier sterk verandering in brengen. Maar dat duurt nog wel even. Luminocity is in elk geval een goed prototype om je ideeen op te botvieren.

Heb je misschien een korte tutorial? Welke codecs ed, of cmd-line je gebruikt?

Ik zit nu niet achter m'n eigen PC en heb dus xvidcap niet zo snel bij de hand, maar het kwam neer op iets dergelijks als:

code:

xvidcap --continue yes --file test.mpg --time 30

xvidcap start dan met de gui en de opgegeven parameters. Er zit een knop op die gui om je window te selecteren. Hij pakt dan de juiste "cap_geometry" automatisch.

Met mencoder heb ik het encode naar lavc, zodat de windows-users het filmpje ook konden kijken.

Wat me verder opviel bij luminocity is dat de shell box erg traag en schokkerig ging, terwijl apps zoals firefox en andere xwindows apps wel gewoon vloeiend gingen, maar dat zie ik niet terug in jou capture waar de shellbox wel snel gaat.

Heb je de patch voor xserver wel gedaan? Deze had bij mij geen effect, maar kan bij veel mensen problemen oplossen.

Nog iets algemeens. Luminocity doet de texture van de windowoppervlakken dynamisch veranderen, door het uit XComposite te lezen en het als texture aan opengl aan te bieden. Dit had hij wellicht wat slimmer op kunnen lossen met dynamische textures. Nu is scrollen en dergelijke erg traag. Of ik moet iets gigantisch fout hebben gedaan. Enfin, daar ben ik nog mee bezig. Maar ik vroeg me dus af of meerdere mensen er last van hadden. Als ik namelijk niet de enige ben, dan wil ik wellicht wat gaan hacken in de OpenGL-code van luminocity.

[mkools24]

Dank voor de duidelijke uitleg mOrPhie!

Ik draaide zelf Luminocity in een 1280x4096 scherm, wellicht is dat al trager, en ik draai het onder Gnome 2.10 die weer op 1600x1200 draait (onder blackbox ging het al sneller).

Verder had ik xvidcap verkeerd ingesteld en ging hij allemaal losse bestandjes aanmaken van 3 mb per stuk (mpeg), ik ga vanavond nog eens stoeien met de parameters.
(Ik heb geen ervaring met xvidcap).

De patch heb ik inderdaad gedraaid en daarna de boel opnieuw gecompiled, precies volgens de instructie op de wiki page.
De shellbox is vergelijkbaar traag met het scrollen waar jij het over had.

Alles is bloedsnel en gaat vloeiend, behalve de shellbox en het scrollen in bijv. Firefox, dat gaat met horten en stoten.

Maar goed het is ook zwaar alpha en er moet zeker nog veel verbeterd worden maar het begin is er

Ik ben ook nog met Looking Glass bezig en daar zijn ze al iets verder, het zou leuk zijn als ze die woobly windows ook in lg3d konden implementeren, ik zal het daar eens in het forum gooien


Edit:

Btw, ik gebruikte gnome-terminal als shell, misschien gebruik jij een andere die wel snel gaat.
Ik draai het onder Slackware 10.1 met Dropline gnome 2.10, kernel 2.6.10, Nvidia GF6800GT

[ Voor 19% gewijzigd door mkools24 op 12-04-2005 10:42 ]

[irondog]

Naar aanleiding van een reactie op mijn screenshots in: irondog in "Post hier je Non-Windows screenshots - D..." wil ik dit topic uit de sloot halen.
Ik hoop dat dit interessante topic weer tot leven komt en dat het screenshot topic: Post hier je Non-Windows screenshots - Deel 6 niet al te veel vervuild wordt met posts zonder screenies.

In het genoemde topic heb ik screenshots gepost van een Gnome Desktop die draait op een experimentele X server genaamd XGL. Deze X server maakt gebruik van OpenGL en wel de OpenGL support in de bestaande Xorg-X11 server. XGL is dus een geneste X server (een X server die draait op de meest populaire X server in Linux).

Datafeest schreef op woensdag 18 januari 2006 @ 21:52:
Het ziet er heel cool uit . Maar ik vraag me serieus af of dat XGL op de desktop momenteel werkelijk een meerwaarde heeft. Vertel eens

Misschien is niet iedereen net zo blij met eye candy als ik, maar werkelijk niemand zit (graag) te wachten op hardware compleet die uit zijn neus vreet terwijl de desktop traag aanvoelt. De nabije toekomst gaat hierin verandering brengen. De meerwaarde van eyecandy en performance weegt voor mij nu al op tegen de instabiliteit die ik erbij cadeau krijg. Deze instabiliteit betekent voor mij op dit moment dat bijvoorbeeld KDE niet werkt en dat het installeren / configureren van XGL nu nogal lastig is.

Zoals ik het nu draai is het natuurlijk niet een eindoplossing, maar de potentie is er gewoon. Ik krijg het als __normale gebruiker__ al aan de praat, het werkt en hoe!
Complexe X11 programma's als webbrowsers en Gnome werken gewoon zonder crashes, artifacten of performance problemen. Ik zou bijna durven zeggen dat X11 nog nooit zo soepel heeft aangevoeld. Dat wil veel zeggen.
Mijn ervaring met linux leert me, dat programma's waarvan het gross van de features geïmplementeerd zijn (en functioneren) slechts tijd nodig hebben om bij het grote publiek terecht te komen. Bij XGL is dat misschien niet helemaal van toepassing: het is niet alleen erg alpha, maar ook laat de gebruite oplossing nog te wensen over. XGL is wel een belangrijke stap in de richting van een vlotte en mooie Linux desktop voor de normale gebruiker.

De volgende logische stap is stabiliteit. Een mogelijke eindoplossing (ja, ik maak ff een grote sprong) is dat een toekomstige X11 server van GLX gebruik kan maken en dat doet indien gewenst. Het "nesten" van een X server (zoals dat nu gebeurt bij XGL) is een van de voornaamste zaken die we willen zien verdwijnen.

[RSpliet]

Jij draait Gentoo zie ik... dat betekent dat jij alles van source af compiled. Aangezien ik X.org niet graag compile als Fedora user, vroef ik mij af; kan ik XGL ook als module voor X.org werkend krijgen?

[irondog]

Ff een lopend shotje:
http://tienstra4.flatnet.tudelft.nl/~gerte/pic/xgl.avi

Seven of Nine schreef op woensdag 18 januari 2006 @ 23:34:
Jij draait Gentoo zie ik... dat betekent dat jij alles van source af compiled. Aangezien ik X.org niet graag compile als Fedora user, vroef ik mij af; kan ik XGL ook als module voor X.org werkend krijgen?

Als ik het goed begrijp zal XGL deel uit gaan maken van de nieuwe Xorg-X11 (7.1). Als het goed is, is de XGL code al in Xorg cvs te vinden. Dus het antwoord zou ja moeten zijn.

Hier zijn wat instructies:
http://www.hboeck.de/item/266

Ik heb deze instructies (met een foefje hier en daar) gevolgd. Aangezien er veel gaande is kunnen de instructies snel achterhaald zijn.

[Anoniem: 107502]

Wellicht interessant om te vermelden over XGL is dat Novell heeft het XGL development heeft gekaapt/geforked, maar ze zouden van plan zijn hun code binnenkort vrij te geven. Een KDE developer, Aaron Seigo, heeft hier wat over geschreven in zijn blog. Wellicht weet je het al als je Planet KDE leest.

http://aseigo.blogspot.co...ouldnt-be-it-be-nice.html
http://aseigo.blogspot.co...s-end-of-zacks-visit.html

[kenneth]

Dat is al gebeurd: http://lists.freedesktop..../2006-January/011922.html

[Ace]

Lijkt me leuk om dit aan te praat te gaan prutsen, maar voor ik er aan ga beginnen (heb al verschillende tutorials en howto's gevondeen) wilde ik weten of dat mogelijk is met een dual screen setup?

Dat kan ik namelijk nergens terugvinden.

[RSpliet]

irondog schreef op donderdag 19 januari 2006 @ 00:20:
Ff een lopend shotje:
http://tienstra4.flatnet.tudelft.nl/~gerte/pic/xgl.avi


[...]

Als ik het goed begrijp zal XGL deel uit gaan maken van de nieuwe Xorg-X11 (7.1). Als het goed is, is de XGL code al in Xorg cvs te vinden. Dus het antwoord zou ja moeten zijn.

Hier zijn wat instructies:
http://www.hboeck.de/item/266

Ik heb deze instructies (met een foefje hier en daar) gevolgd. Aangezien er veel gaande is kunnen de instructies snel achterhaald zijn.

Wordt wel een hel dan om te regelen. De helft van die development packages zitten niet in de Fedora repo. Ik mag dus hopen dat X.org 7.1 nog in FC5 gaat passen, zelf alles compilen duurt mij te lang.

[smokalot]

XGL is inderdaad heel erg gaaf, het biedt zo ontzettend veel mogelijkheden, doordat windows gewoon openGL objecten zijn, en je er alle transformaties mee kunt uitvoeren.

Op dit moment is het een nested X server, maar wat ik begrijp is dat het later direct de grafische kaart als backend kan hebben (EGL). Maar ook de win32 API, en OSX. Meteen heel veel backends dus.

Ik hoop dat er vooral veel softwareondersteuning van komt, zodat veel mensen het kunnen gaan gebruiken, ook mensen met iets oudere hardware. Pas als er genoeg mensen zijn die de beschikking over XGL hebben zullen KDE en gnome alles netjes integreren. En pas dan zal dit meer zijn dan een speeltje, en werkelijk de productiviteit verhogen. (al is het maar omdat mensen dan eindelijk overstappen vanaf windows ;-) )

Trouwens, irondog, je zegt dat mplayer de xvideo driver gebruikt, klopt dat? ik dacht namelijk dat xvideo direct naar de grafsiche kaart ging, waardoor je m niet openGL kunt transformeren?

[zAo]

Irondog, welke nvidia driver gebruik je? De nv-driver of de binary van Nvidia zelf?

Ik wil het deze week gaan proberen op een Ubuntu Dapper machine, kijken hoever ik kom Iemand ervaringen met Ubuntu - Xgl?

[irondog]

smokalot schreef op donderdag 19 januari 2006 @ 14:56:
XGL is inderdaad heel erg gaaf, het biedt zo ontzettend veel mogelijkheden, doordat windows gewoon openGL objecten zijn, en je er alle transformaties mee kunt uitvoeren.

Op dit moment is het een nested X server, maar wat ik begrijp is dat het later direct de grafische kaart als backend kan hebben (EGL). Maar ook de win32 API, en OSX. Meteen heel veel backends dus.

Grappig, maar X11 applicaties gebruik ik eigenlijk nooit buiten Linux. Ik heb wel eens gespeeld met Xorg en KDE onder Windows, maar daarmee houdt het op. Misschien wordt dat later inderdaad wel ietsje leuker. Ik zie meer in een native port van bijvoorbeeld kdelibs dan alt+tabben tussen Explorer en KDE in EGL. Maar dat ter zijde.

Ik hoop dat er vooral veel softwareondersteuning van komt, zodat veel mensen het kunnen gaan gebruiken, ook mensen met iets oudere hardware.

Dat is gewoon wachten tot Kwin en Metacity (luminocity?) zelf composite functies gaan aanroepen. Externe composite managers zijn hacky tooltjes en demonstreren de mogelijkheden. Window managers en andere applicaties moeten uiteindelijk zelf compsite functies gaan gebruiken. Verder werkt composite beter in XGL dan in Xorg, maar composite is er al en ook voor het grote publiek.

Pas als er genoeg mensen zijn die de beschikking over XGL hebben zullen KDE en gnome alles netjes integreren.

Zo klinkt het als een hoge horde, maar ik denk dat het allemaal wel mee valt. Langzaam maar zeker worden nu composite effecten als transparantie en schaduwen opgenomen in applicaties. Goede integratie van andere effecten kan nog wel even duren ja.

En pas dan zal dit meer zijn dan een speeltje, en werkelijk de productiviteit verhogen. (al is het maar omdat mensen dan eindelijk overstappen vanaf windows ;-) )

Mijn mening is dat we nu een hele kleine stap voor liggen op Windows (maar nog steeds jaren achter op OSX)

smokalot schreef op donderdag 19 januari 2006 @ 14:56:Trouwens, irondog, je zegt dat mplayer de xvideo driver gebruikt, klopt dat? ik dacht namelijk dat xvideo direct naar de grafsiche kaart ging, waardoor je m niet openGL kunt transformeren?

Ik start mplayer met -vo xv en het werkt. Ik heb me hier eerlijk gezegd wel over verbaasd. Ik dacht dat hardware heel anders gebruikt wordt bij zowel 2d als 3d (GLX) als video (overlay, hardware scaler). Het werkt bij mij, maar helaas heb ik gelezen dat dit niet voor iedereen het geval is.

Zoals na te lezen is in het screenshot topic heb ik me al tijden geërgerd dat XV en GLX zo brak zijn met composite, dit maakte composite bijna volstrekt waardeloos op mijn dagelijkse desktop. Met XGL werken composite managers gewoon wel fatsoenlijk bij mij. Wobbly is bij mij de hele desktop en mplayer is daar geen uitzondering op. Op mijn pc houd ik mijn CPU load bij het afspelen van Avi's op niet-origineel formaat in mplayer met XV gewoon ruim boven de 60% terwijl ik met de windows speel.

zAo schreef op donderdag 19 januari 2006 @ 17:40:
Irondog, welke nvidia driver gebruik je? De nv-driver of de binary van Nvidia zelf?

Ik wil het deze week gaan proberen op een Ubuntu Dapper machine, kijken hoever ik kom Iemand ervaringen met Ubuntu - Xgl?

Alleen de binary Nvidia drivers hebben goede acceleratie. Ik gebruik Xorg 7.0 met Nvidia 1.0.8178.

[RSpliet]

zAo schreef op donderdag 19 januari 2006 @ 17:40:
Ik wil het deze week gaan proberen op een Ubuntu Dapper machine, kijken hoever ik kom Iemand ervaringen met Ubuntu - Xgl?

Kijkt u hier eens :)

[zAo]

Seven of Nine schreef op donderdag 19 januari 2006 @ 19:15:
[...]

Kijkt u hier eens :)

Dank, alleen is het nog veel leuker: sinds kort zit Xglx in de Dapper repo's

Begin volgende week even proberen om het fullscreen goed te laten werken, want na even proberen was het nog een gedoe om alle programma's te forwarden naar :1.

Hoe kan ik trouwens Xglx standaard laten starten, fullscreen dan?

[Aphelion]

[b][message=25043928,noline]irondog schreef op donderdag 19 januari 2006 @ 18:47
Alleen de binary Nvidia drivers hebben goede acceleratie. Ik gebruik Xorg 7.0 met Nvidia 1.0.8178.

Hoe heb jij de driver aan de praat gekregen? Ik heb ubuntu dapper, maar het pakket nvidia-kernel 8167 is niet beschikbaar. Nu heb ik geprobeerd om met de NVIDIA-Installer de drivers zelf te compileren. Dit ging voor zo ver ik weet goed (kernel sources met een make oldconfig). Nu ben ik echter nogsteeds niet instaat om NVIDIA-GLX te installeren vanwege de depency.

Heel graag probeer ik op mijn Ubuntu systeem de XGLX uit!

[smokalot]

irondog schreef op donderdag 19 januari 2006 @ 18:47:
[...]
Grappig, maar X11 applicaties gebruik ik eigenlijk nooit buiten Linux. Ik heb wel eens gespeeld met Xorg en KDE onder Windows, maar daarmee houdt het op. Misschien wordt dat later inderdaad wel ietsje leuker. Ik zie meer in een native port van bijvoorbeeld kdelibs dan alt+tabben tussen Explorer en KDE in EGL. Maar dat ter zijde.

Windows als backend is vooor mij vooral handig om remote dingen te draaien. Hopelijk komt er uiteindelijk iets als NX wat ook Xgl gebruikt.

[...]
Dat is gewoon wachten tot Kwin en Metacity (luminocity?) zelf composite functies gaan aanroepen. Externe composite managers zijn hacky tooltjes en demonstreren de mogelijkheden. Window managers en andere applicaties moeten uiteindelijk zelf compsite functies gaan gebruiken. Verder werkt composite beter in XGL dan in Xorg, maar composite is er al en ook voor het grote publiek.
[...]
Zo klinkt het als een hoge horde, maar ik denk dat het allemaal wel mee valt. Langzaam maar zeker worden nu composite effecten als transparantie en schaduwen opgenomen in applicaties. Goede integratie van andere effecten kan nog wel even duren ja.

Ik vind composite inderdaad een goed vooorbeeld, het is voor iedereen beschikbaar inmiddels, maar voor bijna niemand met werkbare snelheid. Kwin heeft een beetje ondersteuning voor composite, maar het is buggy, onvolledig en traag. En aangezien volgens mij nu alleen maar een paar mensen met een r200 kaart met fatsoenlijke snelheid composite kunnen gebruiken zal dat binnenkort niet veranderen. Ik hoop dus dat Xgl bij meer mensen fatsoenlijk zal werken.

[...]
Mijn mening is dat we nu een hele kleine stap voor liggen op Windows (maar nog steeds jaren achter op OSX)

Als Xgl stabiel en volledig is vind ik dit een grote stap voor op windows. OSX is nu een stuk verder, maar Xgl biedt net zoveel mogelijkheden als Aqua, en ik hoop dat die mogelijkheden ook gebruikt worden. Het voordeel van vrije software is dat iedereen er zelf mee kan spelen, en features kan toevoegen. Ik vind dat er functionaliteit mist in Aqua op het moment, die zou in KDE/gnome wel toegevoegd kunnen worden.

[...]

Ik start mplayer met -vo xv en het werkt. Ik heb me hier eerlijk gezegd wel over verbaasd. Ik dacht dat hardware heel anders gebruikt wordt bij zowel 2d als 3d (GLX) als video (overlay, hardware scaler). Het werkt bij mij, maar helaas heb ik gelezen dat dit niet voor iedereen het geval is.

Zoals na te lezen is in het screenshot topic heb ik me al tijden geërgerd dat XV en GLX zo brak zijn met composite, dit maakte composite bijna volstrekt waardeloos op mijn dagelijkse desktop. Met XGL werken composite managers gewoon wel fatsoenlijk bij mij. Wobbly is bij mij de hele desktop en mplayer is daar geen uitzondering op. Op mijn pc houd ik mijn CPU load bij het afspelen van Avi's op niet-origineel formaat in mplayer met XV gewoon ruim boven de 60% terwijl ik met de windows speel.

(heb je het nu over load of over gebruik? een load van 0.6 is niet veel, een gebruik van 60% wel.)

[...]
Alleen de binary Nvidia drivers hebben goede acceleratie. Ik gebruik Xorg 7.0 met Nvidia 1.0.8178.

Volgens mij moet de binary ati-driver ook goed genoeg werken, en de open source radeon (r200/r300) lijken me ook snel genoeg.

Even iets anders trouwens, als ik het goed begrijp heeft XGI nieuwe drivers voor linux, inclusief source! Dit hadden ze ook aangekondigd. Als ik in de package kijk zie ik wel een paar binary-only bestanden, maar wellicht dat die ook nog vrij worden.

Dat betekent dat de XGI volari 8300 de beste 3d-kaart is die goede, volledige drivers heeft. Radeons werken een stuk trager met de open source drivers dan met de gesloten, en nvidia is al helemaal een ramp met de nv driver. Deze kaart is goedkoop (50E), en redelijk snel, iig voldoende voor desktop gebruik.

Als deze kaart inderdaad fatsoenlijke open source driverondersteuning krijgt ga ik hem zeker kopen!

[blouweKip]

Ik vind composite inderdaad een goed vooorbeeld, het is voor iedereen beschikbaar inmiddels, maar voor bijna niemand met werkbare snelheid. Kwin heeft een beetje ondersteuning voor composite, maar het is buggy, onvolledig en traag. En aangezien volgens mij nu alleen maar een paar mensen met een r200 kaart met fatsoenlijke snelheid composite kunnen gebruiken zal dat binnenkort niet veranderen. Ik hoop dus dat Xgl bij meer mensen fatsoenlijk zal werken.

Ik zal mn pc nog eens een schouderklopje geven dan, composite is hier stabiel en supersnel (kwin in dit geval, schaduwen en transparante inactive windows aan) en ik heb (gelukkige) niet eens een r200

[smokalot]

blouweKip schreef op zaterdag 21 januari 2006 @ 14:00:
[...]

Ik zal mn pc nog eens een schouderklopje geven dan, composite is hier stabiel en supersnel (kwin in dit geval, schaduwen en transparante inactive windows aan) en ik heb (gelukkige) niet eens een r200

maar wel een nvidia? volgens mij zijn er een heleboel mensen die daar problemen mee hebben, vooral in combinatie met glx, xv en/of xinerama.

Ik begreep dat de r200 op dit moment het snelst is met composite, omdat deze EXA ondersteunt. Bij mij was dit nog steeds enigszins traag, maar wel werkbaar. Dat was wel met een duron 1600, in mijn nieuwe Athlon 64 past mijn r200 niet.

[Cyphax]

smokalot schreef op zaterdag 21 januari 2006 @ 14:52:
[...]

maar wel een nvidia? volgens mij zijn er een heleboel mensen die daar problemen mee hebben, vooral in combinatie met glx, xv en/of xinerama.

Ik begreep dat de r200 op dit moment het snelst is met composite, omdat deze EXA ondersteunt. Bij mij was dit nog steeds enigszins traag, maar wel werkbaar. Dat was wel met een duron 1600, in mijn nieuwe Athlon 64 past mijn r200 niet.

Er zijn een aantal driverversies geweest die de boel deed crashen, na een paar seconden al (ongeacht of je nu wat deed of niet), dat heb ik zelf ook ondervonden. Nieuwere versies van de nVidia drivers draaien wel vrij stabiel: ik heb het zelf een korte tijd getest en geen crashes gehad. Er kwamen wel andere bugs bij kijken (mbt de overlay bijvoorbeeld, video naar fullscreen zetten gaf wat vervelende, niet-kritieke problemen maar geen instabiliteit) maar dat gaf je zelf ook wel aan. In de basis is het wel vrij stabiel in ieder geval.
Ik heb overigens niet lang gewerkt met die eyecandy.. weinig behoefte aan en mijn windowmanager doet maar zo weinig met graphics dat het weinig toevoegt.

[ Voor 12% gewijzigd door Cyphax op 21-01-2006 15:04 ]

[irondog]

smokalot schreef op zaterdag 21 januari 2006 @ 13:51:
[...]
(heb je het nu over load of over gebruik? een load van 0.6 is niet veel, een gebruik van 60% wel.)

Ik zeg het compleet verkeerd -> foutje.
Dit is wat ik bedoelde: Ik houd het idle process ruim boven de 60% als ik met mplayer op niet origineel formaat ga wobbly-en. Zonder dat gespeel blijft ie natuurlijk zelfs boven de 95% idle.

Aphelion schreef op zaterdag 21 januari 2006 @ 13:49:
Hoe heb jij de driver aan de praat gekregen? Ik heb ubuntu dapper, maar het pakket nvidia-kernel 8167 is niet beschikbaar. Nu heb ik geprobeerd om met de NVIDIA-Installer de drivers zelf te compileren. Dit ging voor zo ver ik weet goed (kernel sources met een make oldconfig). Nu ben ik echter nogsteeds niet instaat om NVIDIA-GLX te installeren vanwege de depency.

Heel graag probeer ik op mijn Ubuntu systeem de XGLX uit!

Ik kan geen Ubuntu specifieke instructies geven, sorry.

smokalot schreef op zaterdag 21 januari 2006 @ 13:51:

Windows als backend is vooor mij vooral handig om remote dingen te draaien.

WTF? Is X11 dat niet dan? XGL is juist prima voor remote desktop gebruik juist omdat het een X11 server is. Je start een programma remote et voila, het wordt geacellereerd getekend op je lokale bureau. Okay, windows en NX doen het qua bandbreedte misschien beter dan X11.

Hopelijk komt er uiteindelijk iets als NX wat ook Xgl gebruikt.

Dat volg ik helemaal niet, maja.

Ik vind composite inderdaad een goed vooorbeeld, het is voor iedereen beschikbaar inmiddels, maar voor bijna niemand met werkbare snelheid. Kwin heeft een beetje ondersteuning voor composite, maar het is buggy, onvolledig en traag.

Kwin ondersteunt het onvolledig ja. Maar buggy en traag? Buggy en traag is Composite in Xorg met Nvidia ja.

Als Xgl stabiel en volledig is vind ik dit een grote stap voor op windows.

Houd jij rekening met de ontwikkelingen in Vista? Zelf heb ik nog geen goed werkende eye candy gezien (niet beter dan in de huidige Xorg/KDE), maar ze zijn er ook mee bezig.

Even iets andes trouwens, als ik het goed begrijp heeft XGI nieuwe drivers voor linux
[..]
Als deze kaart inderdaad fatsoenlijke open source driverondersteuning krijgt ga ik hem zeker kopen!

Hmn. Klinkt goed ja.

smokalot schreef op zaterdag 21 januari 2006 @ 14:52:
maar wel een nvidia? volgens mij zijn er een heleboel mensen die daar problemen mee hebben, vooral in combinatie met glx, xv en/of xinerama.

Ja. Het is een onbruikbare ramp.

Ik begreep dat de r200 op dit moment het snelst is met composite, omdat deze EXA ondersteunt. Bij mij was dit nog steeds enigszins traag, maar wel werkbaar. Dat was wel met een duron 1600, in mijn nieuwe Athlon 64 past mijn r200 niet.

Ik heb juist die r200 met EXA, vet, gaaf, vlekkeloos, snel en goed werkend gehad. Vlak voor de final release van Xorg-7.0 (in een van de laatste RC's) is dit hopeloos naar de hell gegaan. Dit wordt erkend door ontwikkelaars en schijnt een probleem te zijn in EXA.

Ik heb dus zo'n r200 met composite, maar sinds een maand geleden werkt het niet meer zoals in de eerdere RC's van Xorg. Dat de r200 het snelst is met composite is wat mij betreft een achterhaald verhaal

edit:
Overigens wil ik er aan toevoegen dat ik tuxracer gespeeld heb met die opensource drivers. Dat werkte goed, dus XGL misschien ook wel (een beetje).

edit:
Geprobeerd en XGL werkt hier niet met de open-source r200 drivers.

[ Voor 9% gewijzigd door irondog op 21-01-2006 21:07 ]

[smokalot]

irondog schreef op zaterdag 21 januari 2006 @ 19:25:
[...]
Ik zeg het compleet verkeerd -> foutje.
Dit is wat ik bedoelde: Ik houd het idle process ruim boven de 60% als ik met mplayer op niet origineel formaat ga wobbly-en. Zonder dat gespeel blijft ie natuurlijk zelfs boven de 95% idle.

Ah ok, dat valt heel erg mee idd.

WTF? Is X11 dat niet dan? XGL is juist prima voor remote desktop gebruik juist omdat het een X11 server is. Je start een programma remote et voila, het wordt geacellereerd getekend op je lokale bureau. Okay, windows en NX doen het qua bandbreedte misschien beter dan X11.

Ja, dat bedoel ik! Ik bedoel dat X11 op windows handig en belangrijk is, omdat je dan gebruik kunt maken van de netwerktransparantie. Als je dan nog steeds hardware composite ondersteuning heeft is dat erg prettig.

[...]
Dat volg ik helemaal niet, maja.

NX gebruikt ook een X server om alles te tonen, als dat GLX is kun je nog steeds alle hardware versnelling gebruiken, en alle gave effecten.

[...]

Kwin ondersteunt het onvolledig ja. Maar buggy en traag? Buggy en traag is Composite in Xorg met Nvidia ja.

Mmm, bij mij was het dus buggy en traag. Af en toe kreeg een window opeens een transparantie van 68%, zomaar.

[...]
Houd jij rekening met de ontwikkelingen in Vista? Zelf heb ik nog geen goed werkende eye candy gezien (niet beter dan in de huidige Xorg/KDE), maar ze zijn er ook mee bezig.

Ik heb niet veel vertrouwen in de grafische kwaliteiten van Vista, ik heb tot nu toe alleen nog maar een transparante taakbalk gezien. Ik geloof best dat de mogelijkheden er zullen zijn, maar ik heb niet het idee dat die gebruikt gaan worden.

Ik heb juist die r200 met EXA, vet, gaaf, vlekkeloos, snel en goed werkend gehad. Vlak voor de final release van Xorg-7.0 (in een van de laatste RC's) is dit hopeloos naar de hell gegaan. Dit wordt erkend door ontwikkelaars en schijnt een probleem te zijn in EXA.

Ik heb dus zo'n r200 met composite, maar sinds een maand geleden werkt het niet meer zoals in de eerdere RC's van Xorg. Dat de r200 het snelst is met composite is wat mij betreft een achterhaald verhaal

edit:
Overigens wil ik er aan toevoegen dat ik tuxracer gespeeld heb met die opensource drivers. Dat werkte goed, dus XGL misschien ook wel (een beetje).

edit:
Geprobeerd en XGL werkt hier niet met de open-source r200 drivers.

Ik weet vrij zeker dat de originele wobbly windows-videos zijn geschoten op een r200, dus ik verwacht dat het toch wel werkend te krijgen is. Maar het zal trager zijn dan met een recente nvidia.

[zAo]

Hoe kan ik Xglx standaard gebruiken? Ik gebruik GDM + Gnome 2.13.4
EDIT: Never mind; ik haalde Xgl en Xglx door elkaar. Op Ubuntu heb je dus alleen Xglx

[ Voor 40% gewijzigd door zAo op 22-01-2006 15:56 ]

[Aphelion]

zAo schreef op zondag 22 januari 2006 @ 12:29:
Hoe kan ik Xglx standaard gebruiken? Ik gebruik GDM + Gnome 2.13.4
EDIT: Never mind; ik haalde Xgl en Xglx door elkaar. Op Ubuntu heb je dus alleen Xglx

Wat is het verschil tussen Xegl en Xglx? ik kom er niet uit.. Ik heb nu Xglx draaien, maa rkrijg glxcompmgr niet aan de praat, hoe moet je die compilen?

[smokalot]

meer info over EGL: http://www.freedesktop.org/wiki/Xegl

[Aphelion]

Beste tweakers;) na een hele avond rotzooien ben ik een flink stuk verder.
Ik heb nu Xglx (dus niet Xgl) draaien en kan er programma's in starten. Als ik nu glxcompmgr start krijg ik echter de melding dat de extentie 'GLX' niet is geladen op de displkay waarin Xglx draait. Hoe los ik dit op? ik heb me radeloos gezocht maar kom echt niet verder.

[irondog]

smokalot schreef op zondag 22 januari 2006 @ 22:41:
meer info over EGL: http://www.freedesktop.org/wiki/Xegl

Ik was een paar dagen geleden al erg (positief) verrast over de kwaliteit en het up-to-date zijn van de informatie op deze pagina. Goede link!

Aphelion schreef op maandag 23 januari 2006 @ 00:14:
Beste tweakers;) na een hele avond rotzooien ben ik een flink stuk verder.
Ik heb nu Xglx (dus niet Xgl) draaien en kan er programma's in starten. Als ik nu glxcompmgr start krijg ik echter de melding dat de extentie 'GLX' niet is geladen op de displkay waarin Xglx draait. Hoe los ik dit op? ik heb me radeloos gezocht maar kom echt niet verder.

Heb je configure aangeroepen met --enable-glx?

Aphelion schreef op zondag 22 januari 2006 @ 20:33:

Wat is het verschil tussen Xegl en Xglx? ik kom er niet uit.. Ik heb nu Xglx draaien, maa rkrijg glxcompmgr niet aan de praat, hoe moet je die compilen?

De link van Smokalot gaat op de eerste vraag in. Waar haal je de sources vandaan? Uit de xgl-0-0-1 branch van de Xorg repository of nog uit de xserver repository?

[ Voor 9% gewijzigd door irondog op 23-01-2006 01:08 ]

[Aphelion]

irondog schreef op maandag 23 januari 2006 @ 00:59:
[...]

Ik was een paar dagen geleden al erg (positief) verrast over de kwaliteit en het up-to-date zijn van de informatie op deze pagina. Goede link!

[...]

Heb je configure aangeroepen met --enable-glx?

[...]

De link van Smokalot gaat op de eerste vraag in. Waar haal je de sources vandaan? Uit de xgl-0-0-1 branch van de Xorg repository of nog uit de xserver repository?

Ik heb de CVS link gebruikt van freedesktop.

Xglx komt uit een package van ubuntu, is het een idee dat ik die anders me de hand ga compilen? glxcompmgr heb ik gecompiled maar geen idee of dat met --enable-glx was. Als je het hier bedoelt dan zal ik dat voor de zekerheid nog even moeten doen.

Overigens misschien weet je of ik dit ook goed / fout doe?

Vanuit een xserver (xorg) in een terminal:
Xglx -ac -display :0 :1 -fullscreen &
Display=:1 gnome-terminal &
In deze terminal:
glxinfo (geeft aan dat GLX ontbreekt)
glxcompmgr (geeft aan dat display 1:0 geen GLX bevat

Ik heb namelijk ook iets gelezen over de drivers (mesa) die glxcompmgr moet gebruiken maar het is me niet duidelijk hoe ik dat specificeer.

Het is in ieder geval duidelijk dat ik met mijn 2 jaar linux desktop ervaring nogsteeds niet voldoende weet van een dergelijk systeem als dat ik weet op een windows systeem. Maar van fouten leert men

[ Voor 25% gewijzigd door Aphelion op 23-01-2006 01:26 ]

[blouweKip]

maar wel een nvidia? volgens mij zijn er een heleboel mensen die daar problemen mee hebben, vooral in combinatie met glx, xv en/of xinerama.

Werkt perfect, xrender aan en iedere versie van de nvidia drivers die ik tot nu toe heb gebruikt met mn composite ready x was snel/stabiel

Ik begreep dat de r200 op dit moment het snelst is met composite, omdat deze EXA ondersteunt. Bij mij was dit nog steeds enigszins traag, maar wel werkbaar. Dat was wel met een duron 1600, in mijn nieuwe Athlon 64 past mijn r200 niet.

Geen id, de oss drivers ondersteunen idd exa, of dat wat uitmaakt op de snelheid kan ik niet zeggen omdat ik met composite met schaduwen en transparantie nauwelijks vertraging bemerk (met mn nvidia kaartje)

[zAo]

Aphelion schreef op maandag 23 januari 2006 @ 01:25:
[...]


Ik heb de CVS link gebruikt van freedesktop.

Xglx komt uit een package van ubuntu, is het een idee dat ik die anders me de hand ga compilen? glxcompmgr heb ik gecompiled maar geen idee of dat met --enable-glx was. Als je het hier bedoelt dan zal ik dat voor de zekerheid nog even moeten doen.

Overigens misschien weet je of ik dit ook goed / fout doe?

Vanuit een xserver (xorg) in een terminal:
Xglx -ac -display :0 :1 -fullscreen &
Display=:1 gnome-terminal &
In deze terminal:
glxinfo (geeft aan dat GLX ontbreekt)
glxcompmgr (geeft aan dat display 1:0 geen GLX bevat

Ik heb namelijk ook iets gelezen over de drivers (mesa) die glxcompmgr moet gebruiken maar het is me niet duidelijk hoe ik dat specificeer.

Het is in ieder geval duidelijk dat ik met mijn 2 jaar linux desktop ervaring nogsteeds niet voldoende weet van een dergelijk systeem als dat ik weet op een windows systeem. Maar van fouten leert men

Wat ik bedoelde met Xglx en Xgl, is dat Xglx een nest in een draaiende Xorg is. In Ubuntu kun je Xgl niet standalone draaien omdat de Xorg nog niet gecompileerd is met --enable-xgl. Een kwestie van tijd dus wil je Xgl leuk kunnen draaien op Ubuntu Dapper. Of je haalt Xgl & Xorg uit CVS, maar bij mij was dit geen succes

[irondog]

Omdat je pakketten als mesa, glitz en Xorg-x11 moet updaten voordat je überhaupt aan XGL kunt beginnen is het waarschijnlijk nogal lastig om dit werkend te krijgen op Ubuntu.

Aphelion schreef op maandag 23 januari 2006 @ 01:25:

Ik heb de CVS link gebruikt van freedesktop.

Dat is niet echt een duidelijk antwoord. Met welk commando doe je de CVS checkout?

Xglx komt uit een package van ubuntu, is het een idee dat ik die anders me de hand ga compilen? glxcompmgr heb ik gecompiled maar geen idee of dat met --enable-glx was. Als je het hier bedoelt dan zal ik dat voor de zekerheid nog even moeten doen.

Nee, --enable-glx is niet voor glxcompmgr. Wat is trouwens het resultaat van

code:

ldd /usr/bin/glxcompmgr

Let op dat glxcompmgr de libGl van mesa moet gebruiken! Als ik de verkeerde gebruik (die van Nvidia) krijg ik ook dat ik GLX mis. Maar dat is bij jou niet het enige probleem denk ik.............

Overigens misschien weet je of ik dit ook goed / fout doe?

Vanuit een xserver (xorg) in een terminal:
Xglx -ac -display :0 :1 -fullscreen &
Display=:1 gnome-terminal &
In deze terminal:
glxinfo (geeft aan dat GLX ontbreekt)
glxcompmgr (geeft aan dat display 1:0 geen GLX bevat

Tja, ziet er wel goed uit. Maaruh, dat glxinfo zegt dat GLX ontbreekt doet me vermoeden dat je het met deze build nooit aan de gang zult krijgen. Zelf compilen is dan de oplossing. Zorg ervoor dat je MESA draait uit CVS en dat je de source van XGL als volgt binnenhaalt:

code:

cvs -d ":pserver:[e-mail]:/cvs/xorg" checkout  -r xgl-0-0-1 -d xgl-xorg xserver/xorg

[Aphelion]

glxcompmgr staat bij mij in/ usr/local/bin, niet in /bin. Denk niet dat het uitmaakt. Results:

code:

        linux-gate.so.1 =>  (0xffffe000)
        libpng12.so.0 => /usr/lib/libpng12.so.0 (0xb7ed9000)
        libXcomposite.so.1 => /usr/lib/libXcomposite.so.1 (0xb7ed6000)
        libXdamage.so.1 => /usr/lib/libXdamage.so.1 (0xb7ed3000)
        libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0xb7ecf000)
        libGL.so.1 => /usr/lib/libGL.so.1 (0xb7e4c000)
        libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb7e29000)
        libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7cfa000)
        libX11.so.6 => /usr/lib/libX11.so.6 (0xb7c14000)
        libXext.so.6 => /usr/lib/libXext.so.6 (0xb7c07000)
        libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb7c04000)
        libz.so.1 => /usr/lib/libz.so.1 (0xb7bf0000)
        libGLcore.so.1 => /usr/lib/libGLcore.so.1 (0xb7431000)
        libnvidia-tls.so.1 => /usr/lib/libnvidia-tls.so.1 (0xb742f000)
        /lib/ld-linux.so.2 (0xb7f0d000)
        libXau.so.6 => /usr/lib/libXau.so.6 (0xb742c000)

Hoe zou ik voor mekaar krijgen dat ik de Mesa libs gebruik?

Overigens heb ik nu jou CVS commando uitgevoerd en ga proberen te compileren wat overigens de volgende meldingen heeft:

code:

configure.ac:435: error: possibly undefined macro: XTRANS_CONNECTION_FLAGS
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.

Overigens hebben we het nu over Xgl, en ik probeer het met Xglx, mag dat iets uitmaken?

Overigens oppert iemand hierboven dat dit niet goed wilt werken in Ubuntu. Nu ik toch veel bezig ben met rotzooien is het een idee een andere distro te nemen. Zou dit wel goed mogelijk zijn in de laatste debian of is gentoo een beter idee om te rotzooien met alle laatste CVS builds die ter berschikking zijn?

[ Voor 30% gewijzigd door Aphelion op 23-01-2006 11:29 ]

[zAo]

Aphelion schreef op maandag 23 januari 2006 @ 11:24:
[....]
Overigens hebben we het nu over Xgl, en ik probeer het met Xglx, mag dat iets uitmaken?

Overigens oppert iemand hierboven dat dit niet goed wilt werken in Ubuntu. Nu ik toch veel bezig ben met rotzooien is het een idee een andere distro te nemen. Zou dit wel goed mogelijk zijn in de laatste debian of is gentoo een beter idee om te rotzooien met alle laatste CVS builds die ter berschikking zijn?

Wanneer je Ubuntu Dapper (Testing, Xorg RC4) gebruikt zou dat goed moeten wezen. Ik meen alleen dat er ebuilds van Xorg CVS zijn; dat vergemakkelijkt het werk wel aanzienlijk. Debian lijkt me helemaal moeilijk aangezien stable nog nieteens Xorg gebruikt, maar XFree86.

Kunnen jullie Xgl 'standalone' draaien? Ik kom niet verder dan een 'nest' zeg maar. Ik zou Xgl namelijk graag standaard gebruiken als X-server.

[irondog]

Aphelion schreef op maandag 23 januari 2006 @ 11:24:
glxcompmgr staat bij mij in/ usr/local/bin, niet in /bin. Denk niet dat het uitmaakt. Results:

code:

        libnvidia-tls.so.1 => /usr/lib/libnvidia-tls.so.1 (0xb742f000)

Niet goed.

Hoe zou ik voor mekaar krijgen dat ik de Mesa libs gebruik?

Een mogelijke oplossing is om glxcompmgr draaien in een shell waar de LD_LIBRARY_PATH omgevingsvariable wijst naar de juiste directory (de directory met de mesa versie van libGl).

code:

LD_LIBRARY_PATH="/pad/naar/libGl/" /usr/local/bin/glxcompmgr

Overigens heb ik nu jou CVS commando uitgevoerd en ga proberen te compileren wat overigens de volgende meldingen heeft:

code:

configure.ac:435: error: possibly undefined macro: XTRANS_CONNECTION_FLAGS
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.

Het lijkt erop dat autoconf bepaalde macro's niet heeft. Heb je alle development packages? Heb je wel Xorg-7.0?
7.0 is de enige autotooled Xorg versie en compilen gaat je echt niet lukken op oudere versies. Zorg dat je 7.0 draait + alle development packages (en dat zullen er veel zijn)!

Overigens hebben we het nu over Xgl, en ik probeer het met Xglx, mag dat iets uitmaken?

Als ik de source compileer, krijg ik /usr/bin/Xgl (wat natuurlijk eigenlijk min of meer Xglx is). De terminologie is inmiddels een beetje vervaagd, men kan Xgl namelijk als zogenaamde "standalone Xserver" draaien door het vanaf een console te starten. Stiekum start de Xgl binary natuurlijk gewoon /usr/bin/X.

Overigens oppert iemand hierboven dat dit niet goed wilt werken in Ubuntu. Nu ik toch veel bezig ben met rotzooien is het een idee een andere distro te nemen. Zou dit wel goed mogelijk zijn in de laatste debian of is gentoo een beter idee om te rotzooien met alle laatste CVS builds die ter berschikking zijn?

Die ebuilds maken het leven wel makkelijker. Merk wel op dat je eerst Xorg moet compilen en die is nog niet stable op Gentoo.

[Anoniem: 107502]

kenneth schreef op donderdag 19 januari 2006 @ 13:43:
Dat is al gebeurd: http://lists.freedesktop..../2006-January/011922.html

Hmm, dat wist ik nog niet, bedankt dat je het zegt. Ik heb daar namelijk niets over gelezen op Planet KDE waar ze eerst meldden dat Novell XGL had "overgenomen".

[ Voor 3% gewijzigd door Anoniem: 107502 op 23-01-2006 16:31 ]

[Sappie]

Opgevist uit de Gentoo forums, erg leuk:

http://membres.lycos.fr/athome93/MVI_1949_bis.AVI
http://membres.lycos.fr/athome93/MVI_1950_bis.AVI
http://membres.lycos.fr/athome93/MVI_1951_bis.AVI
http://membres.lycos.fr/athome93/MVI_1952_bis.AVI

[irondog]

Sappie schreef op vrijdag 03 februari 2006 @ 18:21:
Opgevist uit de Gentoo forums, erg leuk:

http://membres.lycos.fr/athome93/MVI_1949_bis.AVI
http://membres.lycos.fr/athome93/MVI_1950_bis.AVI
http://membres.lycos.fr/athome93/MVI_1951_bis.AVI
http://membres.lycos.fr/athome93/MVI_1952_bis.AVI

Fuck, sappie was weer eens vergeten uit te loggen op me PC.

[ Voor 8% gewijzigd door irondog op 03-02-2006 18:23 ]

[smokalot]

erg stoer om te zien! ben blij dat er van de mogelijkheden nu al goed gebruik gemaakt wordt. De wobbly windows doen het net een beetje echter voelen, expose-achtige functie om venster te kiezen, een zoom functie voor als je simpelweg iets wilt vergroten, enz. Ik hoop dat je ook gewoon een venster inclusief alle inhoud kunt vergroten, bijvoorbeeld omdat je anders de kleine lettertjes niet kunt lezen, of omdat de window-borders en menu's enzo je gewoon teveel ruimte innemen. Websites kun je vaak de letters groter of kleiner maken, maar dan verneuk je de layout altijd, is ook weer niet de bedoeling. Ik zou liever hebben dat je naast het resizen dmv het slepen van een hoek van het venster ook een *werkelijke* resize doet dmv slepen met shift ingedrukt oid.

Jammer dat Novell het project zo gekaapt heeft, maar wel erg netjes wat ze allemaal doen. Ik hoop echt dat dit allemaal redelijk snel stabiel wordt en in Xorg terecht komt. Hoe sneller dat gebeurt, hoe meer er ook in de ontwikkeling van KDE4 meegenomen kan worden.

[Anoniem: 105830]

Zijn dat virtuele desktops?? F.ck... ziet er tof uit!

[Da Fox]

Forbidden

You don't have permission to access /athome93/MVI_1950_bis.AVI on this server.

Helaas zijn ze offline gehaald
Ik wil ze graag zien, is er iemand die ze nog heeft en kan uploaden / alternative links heeft?

[irondog]

smokalot schreef op vrijdag 03 februari 2006 @ 18:52:
Ik hoop dat je ook gewoon een venster inclusief alle inhoud kunt vergroten, bijvoorbeeld omdat je anders de kleine lettertjes niet kunt lezen, of omdat de window-borders en menu's enzo je gewoon teveel ruimte innemen.

Bij mij werkte dat onder gnome wel goed, zelfs configureerbaar. Ik kon het via de gconf editor onder een bepaalde toetsencombinatie binden. Je kunt dan dus inzoomen op bijvoorbeeld een stuk teskt in je browser, maar ook op een willekeurig ander deel van je desktop. Je zoom positie verander je door je muis te bewegen.

Websites kun je vaak de letters groter of kleiner maken, maar dan verneuk je de layout altijd, is ook weer niet de bedoeling. Ik zou liever hebben dat je naast het resizen dmv het slepen van een hoek van het venster ook een *werkelijke* resize doet dmv slepen met shift ingedrukt oid.

Ja, dat gaat dus met de zoom plugin van glxcompmgr. Wobbly, rotate, room, fade en shadows zijn allemaal glxcompmgr plugins die ik als prutser al gebruikt heb.

Jammer dat Novell het project zo gekaapt heeft, maar wel erg netjes wat ze allemaal doen.

Waarom jammer? Zo schiet het tenminste wel op!

Ik hoop echt dat dit allemaal redelijk snel stabiel wordt en in Xorg terecht komt.

Het komt heus wel snel in Xorg hoor. Check hoe hard het nu gaat, ze lijken wat mijn betreft al in de stabilisatie fase te zitten. Maar we hebben het nog steeds over een nested Xserver. Dat is natuurlijk prachtig, maar geen echte eindoplossing.

Hoe sneller dat gebeurt, hoe meer er ook in de ontwikkeling van KDE4 meegenomen kan worden.

Een bruikbare KDE4 is anderhalf, twee jaar van ons verwijderd.

Da Fox schreef op vrijdag 03 februari 2006 @ 21:38:
Ik wil ze graag zien, is er iemand die ze nog heeft en kan uploaden / alternative links heeft?

http://tienstra4.flatnet....erte/pic/MVI_1949_bis.AVI
http://tienstra4.flatnet....erte/pic/MVI_1950_bis.AVI
http://tienstra4.flatnet....erte/pic/MVI_1951_bis.AVI
http://tienstra4.flatnet....erte/pic/MVI_1952_bis.AVI

[Erhnam]

Hier staan ze nu ook, dan wel officieel:

http://www.novell.com/linux/xglrelease/

Hier kan je ook de XGL downloaden. Compiz wordt na de X meeting openbaar gemaakt (begint vandaag).

Now, the actual decoration rendering was split out into a separate process. Today Compiz has its own internal rendering of the window decorations which uses Cairo and an alpha channel to render its decorations.

But someone could write a Gnome/Metacity decoration renderer or a KDE decoration rendered. Both would allow existing window manager themes to integrate with Compiz.

Xgl has already been checked into the public repositories, Compiz will be checked in after David Reveman's presentation at the X conference.

Nog een link met meer informatie: http://en.opensuse.org/Xgl

[ Voor 65% gewijzigd door Erhnam op 08-02-2006 14:41 ]

[kenneth]

irondog schreef op vrijdag 03 februari 2006 @ 22:28:
Een bruikbare KDE4 is anderhalf, twee jaar van ons verwijderd.

De meeste kdedevs hoor ik spreken over een public beta deze herfst? Dat is dus iets meer dan een half jaar nog, ik schat dan nog drie maanden tot de release oid.

[smokalot]

mja, van mij mogen ze er ietsje langer over doen, als dat betekent dat er meer dingen zijn die volledig vernieuwd kunnen worden.

KIOslaves bijvoorbeeld, die moeten echt beter.

En ik hoop dat er ook goed gebruik gemaakt wordt van Xgl, of iig EXA.

[Erhnam]

Overzicht van de plugins is nu ook beschikbaar:

http://en.opensuse.org/Compiz

De source ook:

http://cvs.freedesktop.org/xapps/compiz/

[ Voor 28% gewijzigd door Erhnam op 09-02-2006 21:09 ]

[zAo]

Zeker de moeite waard om te kijken; de volledige presentatie.

http://www.freedesktop.org/~davidr/xgl-demo1.xvid.avi

[irondog]

zAo schreef op donderdag 09 februari 2006 @ 20:55:
Zeker de moeite waard om te kijken; de volledige presentatie.

Zeker de moeite om het te gaan installeren

Maaruh, ik heb nog niet veel nuttigs kunnen doen met compiz in KDE. Heeft iemand al succes hiermee? Ik ben voorlopig al tevreden over kompmgr in XGL. Ik kan het nu tenminste filmpljes afspelen zonder kompmgr tijdelijk uit te schakelen.

kenneth schreef op woensdag 08 februari 2006 @ 15:20:
[...]
De meeste kdedevs hoor ik spreken over een public beta deze herfst? Dat is dus iets meer dan een half jaar nog, ik schat dan nog drie maanden tot de release oid.

Heb je ooit al beseft hoe fucking groot KDE is? Misschien is er in de herfst een eerste versie compileerbaar, maar KDE4 is wat mij betreft pas klaar als je dezelfde hoeveelheid kwalitatief hoogstaande applicaties hebt als nu en geen enkele Qt3/kde3 dependancy overhoudt. Als je naast het porten nieuwe innovaties wil tonen, ben je gewoon ziekelijk veel tijd kwijt.

[kenneth]

Heb je ooit al beseft dat de kdedevs dat ook wel weten? Toch zeggen sommigen dat een beta in de herfst mogelijk is. Lees planetkde.org maar

En kdelibs4 compileert btw al, dus het gaat op zich best rap.

[irondog]

Ooit wel eens gezien hoe vaak er vertragingen optreden?

Maar goed, twee jaar is wat pessimistisch misschien.

[smokalot]

irondog schreef op donderdag 09 februari 2006 @ 22:24:
[...]
Zeker de moeite om het te gaan installeren

Maaruh, ik heb nog niet veel nuttigs kunnen doen met compiz in KDE. Heeft iemand al succes hiermee? Ik ben voorlopig al tevreden over kompmgr in XGL. Ik kan het nu tenminste filmpljes afspelen zonder kompmgr tijdelijk uit te schakelen.

Ik wil het misschien ook wel installeren, maar aangezien dat best wat werk zou kunnen zijn (heb m geinstalleerd, maar krijg na 3 seconden segfaults) zou ik wel willen weten hoe het onder KDE werkt dan.

Als ik het goed begrijp is compiz zowel een window manager als een composite manager? dus een vervanger voor kwin? En welke effecten werken er dan?

[Arx]

Ik las laatst nog in de Developers Journal dat ze mikken op 2de kwartaal 2007. Ach, KDE3.5 is een mooie release.

Iemand enig idee wat voor specs je nodig hebt om xgl met alle toeters en bellen te draaien?

[irondog]

smokalot schreef op donderdag 09 februari 2006 @ 23:08:Ik wil het misschien ook wel installeren, maar aangezien dat best wat werk zou kunnen zijn (heb m geinstalleerd, maar krijg na 3 seconden segfaults) zou ik wel willen weten hoe het onder KDE werkt dan.

Ik heb nu voor het eerst KDE draaien zonder artifacten en crashes. Bij Gnome werkte het al veel eerder goed.

Als ik het goed begrijp is compiz zowel een window manager als een composite manager? dus een vervanger voor kwin? En welke effecten werken er dan?

Volgens mij is dat inderdaad zo. Ik kan compiz niet starten als kwin of twm draait. Als je --replace meegeeft dan wordt de huidige windowmanager gekilled en compiz gestart. Dit bleek voor mij (onder KDE dus) bijzonder onbruikbaar want window borders e.d. verdwijnen gewoon.

Voor compiz zijn net zoals bij glxcompmgr een aantal plugins beschikbaar. Voorbeelden zijn de plugins voor schaduwen, transparantie, zoomen, cubus, roteren (v.d. cubus) en de wobbly windows. Compiz heeft daarnaast ook plugins die niet bij glxcompmgr nog niet bestonden. Hierbij hoort o.a. een plugin die het minimisen en maximisen van windows animeert.

De bestaande composite functies werken gewoon onder XGL. Transset, xcompmgr en dus ook kompmgr functioneren prima. Omdat de laatste goed in KDE/Kwin geïntegreerd is houd ik het hier maar even bij. Compiz lijkt mij ook eerder voor Gnome ontworpen.

[kenneth]

Nog even voor irondog

quote: http://software.newsforge.../07/2059202.shtml?tid=130

Ian Geiser, a KDE developer and official US representative for the KDE project, says KDE 4 will most likely be released in late 2006, though internal debate could push the release back to early 2007.

En ja, het gaat uitlopen

[DeMoN]

Even een kick want ik ben een link tegen gekomen met een artikel die zeer de moeite waard is!

Voor iedereen die het weer even op een rijtje wil hebben w.b.t. X, GL-X, AIGLX, XGL:
http://www.freesoftwarema...celerated_x/index_p1.html