[04:51] <LLStarks> bryceh, why does nvidia-current keep getting pulled on my intel box. it keeps ****ing up my libgl.
[04:54] <bjsnider> i believe nvidia-current is always installed by default. it is only activated if done manually through jockey
[04:57] <tjaalton> not true
[04:57] <tjaalton> I don't have it
[04:58] <bjsnider> maybe he has a metapackage or something
[04:58] <bjsnider> nvidia-common?
[04:59] <tjaalton> that's installed on every system, but it doesn't pull -current
[05:00] <tjaalton> LLStarks: purge it, it should say what depends on it
[05:00] <bjsnider>  restricted modules?
[05:00] <tjaalton> apt-cache rdepends nvidia-current shows the deps
[05:00] <LLStarks> i do, but somehow it ends up back on my system once in a while.
[05:00] <tjaalton> one of those is the culprit
[05:00] <LLStarks> i don't know how to keep my libgl alternates from changing
[05:01] <tjaalton> well trace the deps from aptitude
[05:01] <LLStarks> well, how i do use the proper libgl without uninstalling nvidia-current?
[05:01] <tjaalton> uncheck it from jockey
[05:03] <bjsnider> i don't see why nvidia-current couldn't be installed on any system, as well as fglrx, as long as it isn't activated and isn't in the xorg.conf file, if there is one
[05:04] <bjsnider> but i thought that was supposed to be the policy in lucid
[05:05] <tjaalton> yes, it _can_ be installed and not used, but they are not installed by default
[05:05] <LLStarks> it's getting activated somehow and i forgot the update-alternatives command for libgl.
[05:06] <bjsnider> so then jockey prompts the user to not only activate it but to actually install it too
[05:06] <LLStarks> i don't use jockey driver manager
[05:06] <tjaalton> bjsnider: at least the first time, yes
[05:08] <bjsnider> is nouveau installed by default?
[05:08] <tjaalton> yes
[05:08] <bjsnider> oh my goodness that's funny
[05:08] <tjaalton> why?
[05:08] <bjsnider> nvidia is the preferred driver
[05:08] <tjaalton> by whom?
[05:09] <bjsnider> typical nvidia users
[05:09] <tjaalton> could be
[05:09] <tjaalton> ubuntu has never installed it (or fglrx) by default
[05:09] <tjaalton> and doing so wuld be a pr loss among the devs
[05:10] <tjaalton> would
[05:10] <bjsnider> installed but _not_ activated
[05:10] <bjsnider> would be a pr loss?
[05:10] <tjaalton> yes
[05:10] <bjsnider> but it would be easier on users
[05:11] <tjaalton> why? they still need to enable it
[05:11] <tjaalton> besides there is no space on the cd's
[05:11] <bjsnider> true
[05:11] <bjsnider> there would be on the dvd
[05:11] <bjsnider> and the network install
[05:12] <tjaalton> I don't think it's ever going to be installed by default
[05:12] <bjsnider> this boils down to a FOSS issue correct?
[05:13] <tjaalton> it's already made as easy as possible, no need to go further
[05:13] <tjaalton> lucid+1 will have nouveau 3D-support
[05:14] <tjaalton> so even less of a reason to push for the blob
[05:33] <tjaalton> speaking of nouveau, starting a second session fails when checking the drm, and then the first session breaks as well
[05:34] <tjaalton> it's like the vt's were on top of the X session, since the mouse cursor works and changes as if there were windows under it
[15:57] <ryanakca> Is there a reason xorg depends on x11-apps instead of simply recommending or suggesting it?
[15:58] <jcristau> hysterical raisins i'd think
[15:58] <ryanakca> I doubt people really use xlogo, xbiff, xedit, xeyes, xgc & co any more
[15:59] <jcristau> otoh what harm are they doing?
[16:00] <ryanakca> jcristau: They take up space on the LiveCD that doesn't need to be taken up :)
[16:01] <ryanakca> If someone has been long around to use xbiff or xman or xclock, they've been long around enough to apt-get install x11-apps
[16:01] <jcristau> oh.  i guess there are people who care about that..
[21:29] <fabounet> @saravatt / bryceh / jcristau : Hi
[21:30] <fabounet> I was told you could help regarding some problems Cairo-Dock has with some graphic cards
[21:33] <fabounet> s/saravatt/Sarvatt
[21:33] <matttbe> I'm sure: They watch TV (USA vs. Canada) ^^
[21:34] <matttbe> (but I don't say the current result :P )
[21:35] <RAOF> fabounet: It's probably a good idea to just state the problems cairo-dock has with some graphics cards; there are others who could help, too.
[21:35] <fabounet> yep, I'm looking forward to solve this, if possible
[21:36] <fabounet> actually it seems some drivers still have an incomplete support of OpenGL 2.0
[21:37] <fabounet> old ATI, but also some Intel cards
[21:37] <fabounet> the problem seems to come from the lack of pbuffers support
[21:37] <jcristau> and?
[21:37] <jcristau> afaik pbuffers are deprecated
[21:38] <fabounet> they are part of opengl though
[21:38] <fabounet> and supported on most cards
[21:38] <jcristau> not on the free drivers iirc
[21:38] <fabounet> sometimes indirect rendering gives good results
[21:39] <fabounet> do you mean pbuffers are banned from Intel drivers now ?
[21:40] <jcristau> probably not.
[21:41] <jcristau> but i still don't know what your problem is
[21:41] <fabounet> the situation varies depending the card
[21:41] <fabounet> for instance on nettbooks (GMA450), using indirect rendering makes everything works, but on not GMA800
[21:41] <jcristau> what's gma800?
[21:42] <fabounet> maybe it was an other number, don't remember exactly.
[21:42] <fabounet> some more evoluted model
[21:42] <fabounet> had this bug recently
[21:43] <fabounet> anyway all Intel cards don't behave the same
[21:43] <RAOF> Isn't it pretty much always the client's responsibility to check for needed GL extensions & fallback if necessary?  Can't you detect the presence of the necessary GL support & react appropriately?
[21:43] <fabounet> I was expecting they would eventually have the same level of support for OpenGL2.0
[21:44] <jcristau> i915 can't go above 1.4 or 1.5 according to wikipedia
[21:44] <fabounet> well I do detect the presence of pbuffers.
[21:44] <fabounet> bt soetimes indirect rendering is needed to make them work
[21:44] <fabounet> and sometimes it's the opposite (Gallium ATi R3xx drivers)
[21:45] <jcristau> i965 can do 2.0 or 2.1
[21:45] <fabounet> seems there is no definite method to be sure
[21:45] <RAOF> I do recall compiz wanting a GLX call to determine what GL extensions a particular context supports, so it could discriminate between extensions supported with a direct context & those only supported with an indirect context.
[21:46] <fabounet> that would be helpful
[21:47] <fabounet> currently I check that GLX is >= 1.3
[21:47] <fabounet> if not, then it's unclear
[21:47] <jcristau> anyway from what i understood (i know nothing of GL) the recommended method is to use fbos instead of pbuffers.
[21:47] <fabounet> do you remember the way to be sure whether indirect rendering would be needed ?
[21:48] <RAOF> That's my (somewhat second hand) understanding, too.
[21:48] <fabounet> fbo is younger than pbuffer, is it more supported though ?
[21:49] <jcristau> #dri-devel might be a better place for this, it has people who know gl and write those drivers..
[21:50] <fabounet> ok, well I'll go and ask them then.
[21:50] <fabounet> thanks for your advices !
[22:03] <jcristau> seems like i didn't misremember too much :)
[22:04] <fabounet> yep, seems I'll have to rewrite some part with fbo ^^
[22:43] <RAOF> What's meant to be shipping drm.h at this point?  I can't build nouveau because I can't find drm.h :)
[22:46] <tjaalton> linux-libc-dev
[22:49] <libv> which interestingly also carries driver specific headers.
[22:51] <RAOF> Ah.  Why is linux-libc-dev not providing drm.h for me?
[22:52] <Sarvatt> if you're using edgers its libdrm-dev and you have to reinstall it every time theres a linux-libc-dev update
[22:53] <Sarvatt> hope jcristau's libdrm header patch goes upstream :)
[22:53] <RAOF> Hm.  Maybe that did'nt get replaced when I un-edgered.
[22:53] <Sarvatt> yeah i have a note on the page saying you need to reinstall linux-libc-dev when you switch away from edgers
[23:01] <Sarvatt> hmm looks like xserver-xorg-video-intel 2.10.901 requires >= xserver 1.7 now? http://launchpadlibrarian.net/39848281/buildlog_ubuntu-karmic-i386.xserver-xorg-video-intel_2:2.10.901%2Bgit20100226.a0ee9c3d-0ubuntu0sarvatt~karmic_FAILEDTOBUILD.txt.gz