/srv/irclogs.ubuntu.com/2010/05/20/#ubuntu-x.txt

=== BUGabundo_NCISLA is now known as BUGabundo_TBBT
RAOFtjaalton: In the mesa merge, why did you keep the “unexport LDFLAGS”?  I've test-built on amd64 without it, and it builds fine.  Was there some other subtlety that this change was fixing?01:14
SarvattRAOF: I believe you can nuke that, it was over a year ago and Tormod fixed it upstream afaik01:53
RAOFYeah, I've been checking.01:54
RAOFAMD64 builds just fine.01:54
RAOFAnd now that we actually build the intel DRI on i386 again, it's time to find a sponsor!01:54
Sarvattback in the mesa 7.4 days01:54
Sarvattthink it was this - http://cgit.freedesktop.org/mesa/mesa/commit/?id=9cb3cdec76b679f15c591955084bd48e91a3214201:55
* Sarvatt can't wait for xrandr 1.4 to stop all these virtual screen resolution > max texture size and compiz broken bug reports02:08
RAOFOh? 1.4 is the magical version that will fix that?02:09
Sarvattyeah adds per-crtc pixmaps02:10
Sarvatt+   • Per-crtc pixmaps. This provides for multiple scan-out buffers02:10
Sarvatt+     which applications can create and assign to arbitrary collections02:10
Sarvatt+     of crtcs. These pixmaps can be associated with a window for use02:10
Sarvatt+     with OpenGL or drawn to directly.02:10
Sarvattoh i totally missed the later discussion - http://www.mail-archive.com/xorg-devel@lists.x.org/msg07846.html02:14
Sarvattack they're uploading backported kernels to lucid? do you know if they know about how nouveau is going to be totally broken by that RAOF?02:17
RAOFSarvatt: Yes; we discussed that at UDS.02:18
RAOFI was vaguely aware of that blueprint before, but hadn't quite twigged as to the consequences.02:19
RAOFThe answer is: there shall be madness.02:19
RAOFOr, rather, that we'll do some ungodly symlink-the-appropriate-libdrm-on-boot hack.02:20
Sarvatti guess we can drop libgl1-mesa-swx11-i686 here soon huh? :D02:41
Sarvattnoticed gcc-4.5 uses i686 as the default arch02:41
Sarvattoh gcc 4.4 now too, nice02:42
RAOFSarvatt: That's a good point.02:53
SarvattRAOF: oh wow good catch on that mesa problem, I didn't notice since I use an external debian/ with all of the gallium changes04:00
Sarvattthe i686 arch changes.. 04:01
Sarvattactually it does affect me too, hah!04:01
RAOFAre you not testing your built packages? :)04:02
Sarvattonly popped up in the past few days since maverick is using gcc-4.4 still as default and that was just switched, looks like i915 and friends are still the old versions04:02
Sarvatti dont think i've even built mesa since the gcc change04:02
Sarvattlooking now though04:03
Sarvattnope it was today - Date: Wed, 19 May 2010 11:28:26 +020004:03
Sarvattbuilt mesa yesterday04:03
Sarvattugh going to cause hell for lucid, i'll have to add more conditionals instead of just changing things04:12
RAOFWe don't support lpia; why not switch on i386 arch rather than DEBIAN_HOST_GNU_CPU?04:12
tjaaltonRAOF: yeah that was overlooked for some time, nice that it got dropped04:59
tjaaltonI can upload mesa if it's ready04:59
RAOFLuke's got it in #ubuntu-desktop, unless you'd prefer to take it yourself.05:00
tjaaltonnah that's fine05:00
Bernardohi05:32
Sarvattnot sure what the proper method to bring in llvm is in for libgl1-mesa-dri-gallium, llvmpipe needs it to be used but its not picked up. recommends?06:00
Sarvattdoing it as a recommends brings in llvm-dev and oprofile also06:00
RAOFWhat requires llvmpipe?06:09
tjaaltonRAOF: the swrast driver aiui07:22
RAOFDo the other drivers fall back to swrast for anything?  If so, we need it.  If not, meh.07:24
tjaaltonwe have the non-gallium version of it07:27
tjaaltonso yes07:27
tjaaltonumm, no we don't need the gallium one, but it's a lot faster :)07:27
RAOFYeah, I've heard.07:29
RAOFBut the gallium drivers don't care which swrast gets used?07:29
tjaaltonactually llvmpipe is the gallium version of swrast07:29
tjaaltondon't think so07:30
tjaaltonand then there's softpipe, which is probably closer to swrast performance wise07:30
RAOFWith the interesting converse: do users of non-gallium drivers get faster software fallbacks with llvmpipe?07:30
tjaaltonit it'd replace swrast then yes07:30
tjaaltonwell, at least that's how I'd see it but I've no evidence of how it works07:31
RAOFHeh.07:31
tjaaltonso, don't count on my words ;)07:32
tjaaltonSarvatt: probably need logs about the "didn't pick it up" part07:32
jcristaumesa should likely have used DEB_HOST_ARCH_CPU rather than the GNU version09:34
jcristaulooks like this was my fault, sigh09:36
tjaalton:)09:37
jcristauhmm raof left :(09:45
coz_hey guys...anything change on lucid where we can now install the official nvidia driver??09:47
tjaaltonnope09:52
coz_tjaalton,  ooo darn... do you have any information that that will change? i really dont want to go back to karmic09:54
tjaaltoncoz_: it won't change, lucid is released09:54
tjaaltoninstalling the driver from nvidia.com breaks your system09:55
coz_tjaalton,  you mean in general^^?09:55
tjaaltonand fills launchpad with obscure bugs09:55
tjaaltonit replaces system libs and then upgrades won't work etc09:56
coz_tjaalton,  thats not the true at all.. depending on card  and who manufactured it along with system configuration...the nvidia driver offered via hardware drivers doesn always work across the board... chaning drivers  can reduce the amount cpu useage  by X  considerably... 09:56
coz_tjaalton,  thats why nouveau is not going to be any different for that matter09:57
coz_a single driver on all systems with all configurations is a pipe dream09:57
tjaaltoneh, there are three blobs to choose from, depending on your card09:57
tjaaltonor four, I've lost count09:57
coz_tjaalton,  thats not workable though   only one driver is current09:57
tjaaltonand not current enough I take?09:58
coz_tjaalton,  well again depending on system config and video card  no  not current enough...considering that nvidia puts out beta drivers with many bug fixes  but none of those fixes make it into ubuntu for 6 months at best509:58
coz_best09:58
tjaaltongo blame them09:59
tjaaltonI don't know if there are plans to update the driver09:59
coz_tjaalton,  well no   its not their fault I cant install on lucid09:59
tjaaltonin lucid09:59
tjaaltonit's their fault to have their release schedule09:59
tjaaltonand bugs in the driver09:59
coz_tjaalton,  you mean like lucid relesing with bugs?10:00
tjaaltonsome bugs can be fixed10:00
coz_right10:00
tjaaltonnvidia's blobs always bring new ones10:00
jcristauSarvatt: fix in debian-unstable git for mesa's debian/rules, fwiw.10:01
tseliotcoz_: I've uploaded the latest nvidia driver to lucid-proposed but it hasn't been approved yet10:57
coz_tjaalton,  ok thats cool :)10:57
coz_tseliot,  sorry 10:57
coz_tseliot,  thats cool10:57
coz_tjaalton,   sorry10:57
asacin mesa source there seem to be GLES headers et al ... are those packaged somewhere?15:17
jcristauprobably not15:19
asac_jcristau: sorry had reconnect. did you say anything besides "probably not" ?15:26
jcristauno15:26
asac_why is that: "probably not"?15:27
Sarvattbecause we dont ship libGLES in mesa15:27
jcristaubecause there hasn't been a reason to package them15:27
asac_Sarvatt: but we could produce that from that source or do we need some other source packaged for that?15:28
asac_ok so how can we get that packaged? would like to provide clutter gles packages, but i think i need this first ;)15:28
jcristaui have no idea if the ES stuff in mesa is production quality, what it's useful for, how it's built, or whatever15:29
jcristaualso i don't know if there are any free gles drivers15:31
Sarvattasac_: i'm pretty sure you are going to need the sdk libgles/egl headers for each target to build against instead of the mesa ones, that really needs looking into15:31
asac_Sarvatt: hmm. so you say the mesa ones are useless? if we move to real drivers?15:33
asac_otherwise i wonder what kind of packages to produce for "egl"15:33
asac_just libgles0-mesa* i guess15:34
Sarvatti'm not sure, but thats the impression i'm under. mesa is going to ship libegl here soon for this wayland stuff15:34
Sarvattegl is seperate from libgles though15:36
Sarvatthttp://sarvatt.com/downloads/patches/egl.patch15:38
Sarvattstarted it but haven't done much yet if you want to use any of that15:38
Sarvatti really was under the impression you'15:40
Sarvattre going to need to build things against the vendor sdk's headers though15:40
jcristauSarvatt: so there's no unified ABI like there is for libGL.so.1?15:41
Sarvattcomparing the headers to the powervr now15:41
Sarvattfor egl at least it looks like there is, theres just some egl_dri2 specific stuff added to the mesa ones it looks like but gles is the one i'm not sure of15:42
asac_Sarvatt: ok so we get egl ... hmmm15:46
SarvattlibGLES_CL.so libGLES_CM.so -- those are in the powervr sdk and not in mesa, doesn't look promising :)15:48
asac_Sarvatt: does mesa have libGLES.so at all?15:49
Sarvattoh i could be wrong there, haven't actually built mesa libgles, thought it was libGLES.so and libGLESv2.so15:49
SarvattName: glesv1_cm15:52
SarvattDescription: Mesa OpenGL ES 1.1 CM library15:52
jcristau#elif defined(_EGL_PLATFORM_X)15:53
jcristau   const char *es1_libname = "libGLESv1_CM.so";15:53
jcristau   const char *es2_libname = "libGLESv2.so";15:53
Sarvattsrc/mapi/es1api/Makefile15:54
Sarvattconfigs/linux-opengl-es15:57
jcristauhmm.  docs/opengles.html.  seems it can use the dri drivers if built with --enable-gles1 --enable-gles216:01
Sarvattoh i'm doing everything on master, looks like theres a bunch of stuff missing in 7.8 thats in a seperate branch - http://cgit.freedesktop.org/mesa/mesa/log/?h=7.8-gles16:03
Sarvattjcristau: thanks for fixing the mesa cpu mess, much cleaner than what I was going to do :D16:26
asac_jcristau: does that mean we could package something up?16:31
asac_with egl and gles?16:31
asac_you think you could give that a stab? i would then see what clutter says when i build it against it ;)16:31
jcristauENOTIME16:35
jcristaui can take patches though16:35
jcristau:)16:35
jcristaubut raof sounded like he wanted to work on that.  from the mail he sent to {debian,ubuntu}-x16:36
asac_thx. will talk to him16:36
Sarvattsheesh i'm starting to like bzr more and more, bzr branch git://whatever.git works :D i pushed the mesa packaging changes to https://code.edge.launchpad.net/~xorg-edgers/mesa/packaging so other people can commit unlike http://sarvatt.com/git/cgit.cgi/mesa/16:47
rippsHi, I'm having an issue with 2.6.34 radeon drm. I'm not sure if this is the right place to ask, but I figure you guys might have an idea what's going on. Whenever I resume from suspend Xorg fails to resume properly, instead just giving me a black screen and a mouse cursor that has glitched graphics. When I switch to a VT, I have "drm:radeon_cs_ioctl failed to schedele IB" repeating constantly. Stopping X makes them stop, but it resumes 16:54
jcristau#radeon would probably be better.16:55
Bernardohi20:36
=== Bernardo is now known as Bernardo|away
=== apachelogger_ is now known as darthvader
=== darthvader is now known as apachelogger
=== BUGabundo is now known as BUGabundo_Cougar
Sarvattit sure would be nice if abi breaks in xserver were required to put something in the subject about it :)22:25
jcristaui think most mention it22:31
* Sarvatt bookmarks http://cgit.freedesktop.org/xorg/xserver/log/hw/xfree86/common/xf86Module.h22:32
Sarvattlooks like theres a bunch of abi bumps queued up, just want to get ready for it22:34
Sarvatteh wait it's the abi bumps without actually bumping the version numbers that screw me up22:35
Sarvattwow the libxfont rebuild has been queued for almost a week22:37
rippsis there an easier method to move dri-galluium/r300_dri.so to dri/r300_dri.so. Having to move and replace the file every time xorg-edgers updates is kind of a hassle23:04
ilmaridpkg-divert?23:05
Sarvattripps: still not sure what I want to do there23:08
Sarvattthe gallium stuff really is just for testing and it works fine with the dri-searchpath thingy outside of aiglx :(23:08
Sarvatttormod has a seperate ppa where he builds it with gallium by default (and only r300) 23:10
Sarvatthttps://edge.launchpad.net/~xorg-edgers/+archive/radeon23:11
Sarvattreally would hate to start adding diverts there and risk screwing things up23:13
Sarvatthmm maybe have libgl1-mesa-dri-gallium replace libgl1-mesa-dri and install to /usr/lib/dri?23:13
Sarvattbut then if someone removed libgl1-mesa-dri-gallium the libgl1-mesa-dri libs wouldn't be there, and ppa-purge wouldn't downgrade it23:15
rippsSarvatt: I like that last idea23:18
rippsIf dri-gallium is a marked as a replace for mesa-dri, wouldn't it then just install mesa-dri during a downgrade?23:19
Sarvattdo you know a way to make libgl1-mesa-dri be reinstalled if someone removed libgl1-mesa-dri-gallium? thats too nasty of a problem to do23:19
Sarvatti hit this *alot* when we had libdrm-dev replacing linux-libc-dev, it would be real bad with the dri drivers hitting it23:20
rippsI honestly don't know the particulars of the downgrade system in apt as well as I should. Most devs, when asked about it, tell me not to try it :/23:20
Sarvattit doesn't reinstall the replaced package on removal, no :(23:21
Sarvattit would just remove the libs in /usr/lib/dri 23:21
rippsSarvatt: is tormod's ppa in sync with xorg-edgers? or will it always take precedence over xorg-edgers?23:22
Sarvattand it thinks libgl1-mesa-dri is still installed in that state23:22
Sarvattno you'd have to only get mesa from the radeon ppa, xorg-edgers is usually newer23:23
Sarvatti dont update the radeon one when i do xorg-edgers, tormod uses a different set of hooks to build those and i have too much to update as it is :D23:23
rippsY'see, that's a problem, I want to test out all the newer xorg components, not just mesa...23:23
Sarvattcant you just pin the mesa packages to only download from that ppa?23:24
rippsTechnically, it would be easy to setup a secondary gallium ppa that depends on xorg-edgers, and than just increase the epoch on the gallium mesa package23:25
Sarvattask tormod to do that, thats what it is now outside of the epoch :)23:25
rippsSarvatt: I'm not very familiar with pinning, last time I tried it I kinda screwed up my apt, is there a guide with a decent description?23:25
Sarvatthttps://edge.launchpad.net/~tormodvolden -- shoot him an email and ask him to bump the epoch, it makes sense to do that23:27
Sarvattjust a matter of adding -e 1 to his auto-xorg-git invocation23:28
Sarvattoh wait, he doesn't build that PPA against xorg-edgers, sorry about that23:28
Sarvattthought he did..23:28
Sarvattguess i could always just drop classic swrast and r300 and throw the gallium ones in -dri for a bit and see how many complaints we get :D23:37
Sarvattno, bad bad idea, what am I thinking23:37
SarvattKMS only23:37

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!