| Sarvatt | so much breakage in mesa master the past few days, been trying to update it for 2 days now and now r600 isn't building right | 01:00 |
|---|---|---|
| Sarvatt | - dri2_set_tex_buffer2(pDRICtx, target, GLX_TEXTURE_FORMAT_RGBA_EXT, dPriv); | 01:02 |
| Sarvatt | + dri2_set_tex_buffer2(pDRICtx, target, __DRI_TEXTURE_FORMAT_RGBA, dPriv); | 01:02 |
| Sarvatt | +#define __DRI_TEXTURE_FORMAT_RGBA 0x20DA | 01:02 |
| Sarvatt | ... | 01:02 |
| Sarvatt | oh whoops thought i read __DRM_TEXTURE_FORMAT_RGBA there | 01:02 |
| Sarvatt | ah i did, pasted the wrong thing | 01:03 |
| Sarvatt | - r600SetTexBuffer2(pDRICtx, target, GLX_TEXTURE_FORMAT_RGBA_EXT, dPriv); | 01:03 |
| Sarvatt | + r600SetTexBuffer2(pDRICtx, target, __DRM_TEXTURE_FORMAT_RGBA, dPriv); | 01:03 |
| bjsnider | i've got a dependent package issue here | 03:18 |
| bjsnider | it's a philosophical thing | 03:18 |
| bjsnider | if you want to use vdpau with va-api, you need a package called vdpau-video. that package links to the vaapi package, but not the other way around. | 03:20 |
| bjsnider | i'm thinking i should add vdpau-video as a dependent package of libva | 03:21 |
| bjsnider | even though there are other ways to use libva than vdpau. it can also be used with dxva | 03:22 |
| bjsnider | the developer however in his debian scripts did not do so | 03:22 |
| bryceh | bjsnider, what's the name of the developer? | 03:32 |
| bjsnider | gwenole beauchesne | 03:32 |
| bjsnider | frenchy | 03:32 |
| bryceh | don't know him | 03:34 |
| bryceh | bjsnider, I would recommend running this by jcristau first since he's well clued on the debian packaging of these things | 03:34 |
| bjsnider | right now, to get vlc with va-api you need to install vlc from my ppa | 03:35 |
| bjsnider | that pulls in a new version of ffmpeg, which pulls in libva | 03:35 |
| bjsnider | then you have to manually grab vdpau-video | 03:35 |
| bjsnider | that's the step that bugs me | 03:36 |
| RAOF | So libva is a wrapper around video-decode-acceleration APIs? | 03:36 |
| bjsnider | libva is the package name of va-api | 03:36 |
| bjsnider | i'm sort of using them interchangeably here | 03:36 |
| bjsnider | vdpau-video is the vdpau side of va-api | 03:37 |
| bjsnider | and in fact installs a driver file into /usr/lib/libva | 03:37 |
| bjsnider | i mean how much more linked together than can that get? | 03:37 |
| RAOF | Ah. So vdpau-video is a shim that implements VA-API over VDPAU? | 03:38 |
| bjsnider | yes, i guess so | 03:38 |
| bjsnider | so in my view, instaling libva should automatically pull in vdpau-video | 03:39 |
| RAOF | For final bonus points: does libva dlopen VA-API backends? | 03:39 |
| bjsnider | i think so. there are 3 backends | 03:40 |
| bjsnider | i'm not a programmer per se, so i'm not sure of what it's doing exactly, but all the vdpau-video package does is installs the vdpau driver | 03:41 |
| bjsnider | so libva is doing all the rest of the work | 03:41 |
| RAOF | So, what you'd like to see happen is for the libva binary package to Recommend: vdpau-video? | 03:41 |
| bjsnider | they should really be in the same package | 03:41 |
| bjsnider | no, not recommend, to actually depend on it | 03:42 |
| RAOF | Does vdpau-video have any other depends? | 03:42 |
| RAOF | It sounds to me like Recommends: is the right relationship - “will be found together in all but unusual circumstances” | 03:42 |
| bjsnider | it has no other explicit depends int he control file, only shlibs | 03:43 |
| bjsnider | givent he build-depends it is going to probably depend on libvdpau | 03:43 |
| bjsnider | if it's a recommends, then the user would still have to manually install it right? | 03:44 |
| RAOF | No; Ubuntu & Debian both install recommends by default. | 03:44 |
| bjsnider | waldo bastian is listed as the maintainer for this thing | 03:45 |
| bjsnider | maybe it's his fault | 03:45 |
| RAOF | Is there a bug open? | 03:45 |
| bjsnider | gwenole is in fact not mentioned in the control file | 03:45 |
| bryceh | oh yeah | 03:45 |
| bryceh | this library was one that came out with poulsbo | 03:46 |
| bryceh | waldo probably would be the right contact for it | 03:46 |
| RAOF | Everyone's favourite intel driver :) | 03:46 |
| bjsnider | the gma4500 can do hardware accel too | 03:47 |
| bryceh | I would get poulsbo drops with libva included, but libva wasn't released at that point so we had to delete it out. fun times | 03:47 |
| bjsnider | this works for nvidia cards too | 03:47 |
| bjsnider | witht he blob | 03:48 |
| bryceh | RAOF, btw did we ever sort out who has responsibility for nouveau-firmware? | 03:48 |
| superm1 | bjsnider, is libva on it's way into debian anytime soon? | 03:49 |
| RAOF | bryceh: I don't recall sorting that out, no. | 03:50 |
| bryceh | ahem | 03:55 |
| bryceh | uploaded | 03:55 |
| bjsnider | superm1, i don't know if it's in there now. but i just built all of it and tested vlc and hardware accel works fine here. it would be nice to get it into lucid | 03:55 |
| bjsnider | i can ask waldo about this, assuming he responds to the email i just sent him | 03:56 |
| superm1 | bjsnider, what state are the packages in? if it's gonna take too long to get them in debian, we can try to fast track them into ubuntu before the New package deadline | 03:56 |
| bjsnider | i didn't have to make any change to either package to get them to build | 03:56 |
| superm1 | i'm still a bit mixed up with how va-api and vdpau relate though | 03:56 |
| bjsnider | they build -dev packages and -dbg packages too | 03:56 |
| superm1 | va-api can use a vdpau backend, but not vice versa? | 03:57 |
| superm1 | so projects like ffmpeg that have support for vdpau already don't benefit at all | 03:57 |
| bjsnider | va-api can use vdpau, dxva, which is the ati thing, or one other... | 03:57 |
| superm1 | xvba is the ati thing | 03:57 |
| bryceh | mm standards | 03:57 |
| bjsnider | oh, right | 03:57 |
| bjsnider | libva's description is "VA API extensions for VDPAU and XvBA backends" | 03:58 |
| bjsnider | there is also an xvba-video package | 03:59 |
| bjsnider | i haven't built it. i wonder if it would work with fglrx? | 03:59 |
| superm1 | it's supposed to | 03:59 |
| superm1 | the guy developing it announces releases on the ati-beta mailing list all the time | 04:00 |
| bjsnider | gwenole? | 04:00 |
| superm1 | yeah | 04:00 |
| bjsnider | is there some rule that says you can't put these things in ubuntu if they're not in debian first? | 04:01 |
| RAOF | Mainly the rule of -ENOTIME. | 04:02 |
| superm1 | its generally beneficial to both | 04:02 |
| bjsnider | you can't have them in lucid just for testing before the stable release? | 04:03 |
| superm1 | so it's better to put it in debian and then be able to sync it from there | 04:03 |
| superm1 | then the debian folks are able to step up and help maintain it too | 04:03 |
| RAOF | That's what I meant be not enough time :) | 04:03 |
| bjsnider | i wonder what happens if you have both the xvba and vdpau packages installed... | 04:04 |
| bjsnider | does it try to use both? does it know enough not to use the xvba side on an nvidia system? | 04:04 |
| bjsnider | does the entire world explode? | 04:04 |
| superm1 | so on the client side, what supports va-api though so far? VLC? | 04:05 |
| superm1 | anything else? | 04:05 |
| bryceh | RAOF, weird, when I debdiff the udev nouveau changes, it produces infinite diffage | 04:05 |
| bjsnider | it's used through ffmpeg, which actually doesn't have to be patched at this point | 04:05 |
| bjsnider | gwenole has an mplayer patch which i haven't tested because mplayer works well as is | 04:06 |
| RAOF | superm1: I actually think gstreamer has some va-api support, too. | 04:07 |
| RAOF | Which would be nifty, because that means that things I actually care about support it. | 04:08 |
| superm1 | interesting | 04:08 |
| bjsnider | it would be nice to see gstreamer catch up to xine, mplayer, and vlc | 04:08 |
| bjsnider | and everything else | 04:08 |
| bjsnider | ugh, the xvba-video package has two separate "latest" tarballs, one for i686 and one for x86_64 | 04:13 |
| bjsnider | oh, the other thing is gnash. there's a patch to enable gnash to use it | 04:14 |
| bjsnider | va-api that is | 04:14 |
| virtuald | ås | 07:09 |
| RAOF | Really? | 07:09 |
| virtuald | no I'm just kidding | 07:10 |
| Belthazor | Good afternoon everyone! | 13:19 |
| Belthazor | at least in Europe | 13:19 |
| Belthazor | I have a problem: I'd like to install new stable stuff onto my production machine | 13:20 |
| Belthazor | but the x-org edgers ppa for karmic now tracks mesa 7.8 | 13:21 |
| jcristau | the edgers ppa is everything but stable stuff | 13:21 |
| Belthazor | which I don't want to use yet | 13:21 |
| Belthazor | yes, that's why I opted for mesa 7.7 | 13:21 |
| Belthazor | which was released in december | 13:21 |
| Belthazor | so I checked the x-updates ppa but that has only mesa 7.6.1 | 13:22 |
| Belthazor | which is too old | 13:22 |
| Belthazor | any plans for upgrading that to 7.7? | 13:23 |
| Belthazor | or any ideas where I can get that? there's git of course, but I'm lazy | 13:23 |
| tjaalton | backport mesa from lucid | 13:24 |
| Belthazor | is there an easy way for that? | 13:24 |
| tjaalton | grab the source and build | 13:24 |
| Belthazor | ppa or tutorial? | 13:24 |
| Belthazor | well, that's pretty much the same as git, I guess | 13:25 |
| tjaalton | why do you need 7.7? | 13:25 |
| Belthazor | I have an ATi rv710 | 13:25 |
| Belthazor | that already has 3D | 13:25 |
| tjaalton | okk | 13:26 |
| tjaalton | -k | 13:26 |
| Belthazor | worked nice on a pendrive install when it was in the edgers ppa | 13:26 |
| jcristau | building the r600 driver from 7.7-branch should take you about 10 minutes | 13:26 |
| Belthazor | yeah, maybe for an experienced user :) | 13:27 |
| Belthazor | so I assume there are no debs for this | 13:27 |
| jcristau | there are. it's called lucid. | 13:28 |
| Belthazor | that's true, but it was still not considered stable last I checked | 13:28 |
| Belthazor | my plan is to have karmic with mesa 7.7 and 2.6.32 and .33 when it will be stable | 13:29 |
| Belthazor | until lucid comes | 13:29 |
| Belthazor | can't I just add an official repo for lucid which has mesa? | 13:30 |
| Belthazor | X updates says: "This PPA is for stable upstream releases of X.org components." | 13:32 |
| Belthazor | that's why I asked if there were plans to upgrade it to mesa 7.7 | 13:33 |
| Belthazor | since the edgers for karmic now has 7.8 | 13:33 |
| tjaalton | lucid won't have .33 | 13:35 |
| tjaalton | we are concentrating on lucid, not karmic | 13:35 |
| tjaalton | and I doubt there are plans to update that ppa | 13:35 |
| tjaalton | for karmic | 13:35 |
| Belthazor | I know that lucid will have .32, but .33 has irq support for my card and hopefully .34 will bring power management | 13:39 |
| Belthazor | I doubt these will be backported, so until lucid+1 I guess I'll have to live with an "unofficial" kernel | 13:40 |
| Belthazor | "and I doubt there are plans to update that ppa" -- that's unfortunate | 13:41 |
| Sarvatt | bryceh: http://cgit.freedesktop.org/mesa/drm/commit/?id=4f0f871730b76730ca58209181d16725b0c40184 | 14:33 |
| Sarvatt | \o/ | 14:33 |
| tjaalton | and it works? | 14:35 |
| Sarvatt | i just woke up and saw it and the bug was closed, haven't built it yet | 14:35 |
| tjaalton | was that the blocker for 2.10? | 14:35 |
| Sarvatt | yup | 14:36 |
| tjaalton | ok, nice | 14:39 |
| tseliot | ah, right the Execbuf bug. So I can haz 2.10 now plz :-P ? | 14:45 |
| tseliot | superm1: I pushed my changes to the git repository yesterday | 15:24 |
| superm1 | cool. hopefully we'll see a build that can use them soon too now :) | 15:24 |
| tseliot | tjaalton: I added a provides abi 5 in the fglrx package in lucid | 15:25 |
| * tseliot nods | 15:25 | |
| tjaalton | tseliot: thanks | 15:25 |
| tseliot | tjaalton: thanks for reporting the problem. I thought it had that already | 15:25 |
| tjaalton | tseliot: it used to, but got dropped for some reason | 15:32 |
| tseliot | aah, ok | 15:32 |
| Sarvatt | one pass of "CAIRO_TEST_TARGET=xlib ./cairo-perf-trace cairo-traces/benchmark/*" stable with the libdrm update, looks promising because this could crash it easy yesterday | 16:07 |
| Sarvatt | ugh.. maybe I should start updaing ia32-libs on xorg-edgers as well, i've come across *so many* bug reports from people using edgers on x64 and not realizing wine uses the 32 bit libs so its using the distro mesa versions | 17:30 |
| Sarvatt | tjaalton: https://bugs.edge.launchpad.net/ubuntu/+source/mesa/+bug/459961 is fixed whenever mesa is updated. dont know if you want to add it to the changelog? already fixed in the ubuntu git branch with the 7.7-3 merge | 17:37 |
| ubottu | Ubuntu bug 459961 in mesa "radeon_dma.c:210: radeonRefillCurrentDmaRegion: Assertion `dma_bo->bo->cref == 1' failed." [Medium,Confirmed] | 17:37 |
| Sarvatt | changed it to fix commited, not sure about karmic | 17:39 |
| jcristau | libv: oh, so it's not just me who has no idea how x.org works, and who does what? | 17:40 |
| libv | jcristau: :))) | 17:47 |
| libv | i run the devroom | 17:47 |
| libv | and i do so without help from the foundation | 17:47 |
| jcristau | and you asked for help? | 17:48 |
| libv | the fosdem folk do most for me, the extra expense (about 25EUR or so per day of devroom) is not worth the hassle | 17:48 |
| libv | i did in the past | 17:48 |
| jcristau | ok | 17:48 |
| libv | first year i got 500usd, 2nd year i dropped the ball (RandR1.2 and stuff, remember?), third year i asked for 500EUR so we could have a local X.org foundation board member pick up the tab at the mirabelle (as this would be a "thank you" for everyone, and it would otherwise not cost a thing) | 17:49 |
| libv | daniels complained about these 500EURs | 17:49 |
| libv | while he had just spent a huge pile of money on cambridge | 17:49 |
| libv | then i decided: i do not need them, and i can refer people who want travel sponsorship to the board directly | 17:50 |
| jcristau | okay | 17:50 |
| libv | so fosdem has basically been free. last year the extra expenses were shared between suse (printing and nametags) and me (water/random things needed for the devroom) | 17:51 |
| libv | in any case, i wonder who got paid to go where | 17:51 |
| libv | and how this is spread between different individuals and companies | 17:51 |
| libv | i think the result will be that this money is used in a surprisingly limited fashion | 17:52 |
| jcristau | yeah it would be nice to have some reports of what goes on to members@ from time to time | 17:52 |
| libv | i personally have never received money from the foundation for my own expenses, only once did i ask for it, and later on there were issues, and i got like half my trainticket repaid by some other stash somewhere | 17:53 |
| libv | gusarov was referred to the board when he asked me for support for travel to fosdem, he got some money, this is the only fact i have about what the board did in the last year | 17:54 |
| libv | hehe | 17:55 |
| libv | David Nicol his answer | 17:55 |
| bryceh | Sarvatt, excellent. I'd asked yingying about that yesterday, so this is good news :-) | 18:03 |
| bryceh | Sarvatt, now I hope there aren't other bugs we're going to hit moving to 2.10? | 18:03 |
| jcristau | bryceh: hah. wishful thinking. | 18:04 |
| Sarvatt | all those people using UMS because KMS doesn't work right for them will be crying :) | 18:04 |
| Sarvatt | i would say we should update intel-gpu-tools to a newer version that has intel_reg_dump buuuut | 18:06 |
| Sarvatt | reading /sys/kernel/debug/dri/0/i915_regs hangs the system on 2.6.32 :) | 18:07 |
| jcristau | get anholt to release a tarball for it? | 18:07 |
| jcristau | libv: hah. this guy sounds like a clown. | 18:08 |
| libv | jcristau: he is, and i now love him for it | 18:10 |
| libv | jcristau: with this one sentence, he turned these elections into a complete farce | 18:10 |
| * jcristau will hold his vote for a little longer. | 18:11 | |
| libv | yup :) | 18:11 |
| libv | actually, these elections should be declared invalid | 18:11 |
| libv | jcristau: don't you find it kind of strange that there are mostly just .us citizens on the board? | 18:20 |
| Sarvatt | Duke`: if you didn't see the hang should be fixed with the latest libdrm in edgers, no need to rebuild that one :) | 19:19 |
| Duke` | Hi | 19:19 |
| Sarvatt | heyo | 19:19 |
| Duke` | well, I haven't seen it for some days | 19:19 |
| Duke` | but I had it sometimes | 19:19 |
| Duke` | less frequently | 19:19 |
| Duke` | so I don't know if there is a (partial) fix, or if my usage makes it crash less often | 19:20 |
| Sarvatt | do you have limited arb_fragment_shader support enabled in driconf? because i think i found another bug with that where it can cause an invalid batchbuffer hang just like the other one | 19:21 |
| Sarvatt | but that might have also been my pixman 17.3 snapshot causing it I think | 19:21 |
| Duke` | no, it's disabled | 19:23 |
| Sarvatt | how much uptime did you have at the most lately? longest i went without a hang was 3 days shortest was 110 seconds | 19:25 |
| Duke` | I could reach a full day. I power off my laptop before going to bed (sleep is hardware-broken) | 19:26 |
| Sarvatt | oops 117 seconds, [ 117.964249] [drm:i915_gem_execbuffer] *ERROR* Execbuf while wedged | 19:26 |
| Duke` | shortest for me was the time to reboot + to reopen the webpage which hanged me + scrolling 3 seconds :) | 19:27 |
| Sarvatt | that was boot, idle 1.5 minutes then open gnome-terminal :D | 19:27 |
| Duke` | intel: Handle resetting of input params after EINTR during SET_TILING | 19:37 |
| Duke` | that should fix it, right? | 19:37 |
| Sarvatt | yeah | 19:42 |
| Sarvatt | and the commit before it fixes a similar thing people on <=915 were getting with failure to install fence errors in dmesg | 19:53 |
| === yofel_ is now known as yofel | ||
| LLStarks | bryceh, is there anyone to set xrand full aspect as default? | 20:18 |
| bryceh | huh? | 20:18 |
| bryceh | LLStarks, dunno | 20:18 |
| LLStarks | this: xrandr --output LVDS1 --set "scaling mode" "Full aspect" | 20:19 |
| LLStarks | can we make it default? | 20:19 |
| LLStarks | i hate having to set it upon bootup | 20:19 |
| bryceh | I haven't had to set that up myself | 20:19 |
| LLStarks | i don't like how "full" is the default. | 20:20 |
| LLStarks | stretches 4:3 games too much | 20:20 |
| bryceh | it'd be best to convince upstream to change the default | 20:21 |
| bryceh | and then have me pull a patch from them | 20:21 |
| LLStarks | is there an x freeze i need to consider? | 20:21 |
| bryceh | for features, alpha-3 is the target | 20:22 |
| jbarnes | LLStarks: it was the default where supported for the X driver | 20:22 |
| jbarnes | LLStarks: for the kernel I'm not sure why it changed... post a patch and I'll ack it | 20:23 |
| BUGabundo | evening | 21:19 |
| Q-FUNK | are we gonna rebase our X to match Debian's 7.4.2 on time for Lucid? | 21:44 |
| Q-FUNK | ööö.. 1.7.4 | 21:45 |
| Sarvatt | the stable 1.7 branch is mostly just fixes, i dont think it counts for the feature freeze? its already queued up in git anyway | 22:30 |
| Q-FUNK | fixes are always welcome | 22:30 |
| Sarvatt | just hasnt been uploaded yet | 22:30 |
| Q-FUNK | ah, ok | 22:31 |
| Q-FUNK | I'm just a bit aparanoid about ensuring that -geode is still remotely usable on Lucid. | 22:31 |
| Sarvatt | nothing between 1.7.3.902 and 1.7.4 affects that anyway so no worries :D | 22:33 |
| Sarvatt | (on the xserver front) | 22:33 |
| Q-FUNK | well, there's already regressions when building the same geode source against 1.7, compared to 1.6, so I'm already worried. | 22:33 |
| herman_ | Sarvatt, | 22:40 |
| Sarvatt | ..kay | 22:41 |
| herman_ | hey, my ubuntu 9.10 is freezing sometimes, and stop all the activities and a i have to restart the notebook directly from the button on/off | 22:42 |
| herman_ | someone passed for the same problem? | 22:42 |
| joumetal | There is radeon kms bugs in lucid like bug #507148. Is following backtrace useful? | 23:04 |
| ubottu | Launchpad bug 507148 in xserver-xorg-driver-ati "[lucid] desktop runs out of video memory on ATI Radeon Mobility 7500" [Unknown,Confirmed] https://launchpad.net/bugs/507148 | 23:04 |
| joumetal | http://pastebin.com/m1055955 | 23:04 |
| joumetal | it's custom kernel with radeon module unloaded and reloaded with modeset=1. | 23:06 |
| RAOF | Sarvatt: Hm. System-wide nouveau_dri.so is not the problem; someone's obviously broken GL_EXT_texture_from_pixmap for nv40 in mesa git. | 23:27 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!