[00:53] tjaalton, I see there's some xorg-server changes queued in git; is there a reason they're not uploaded yet? === Sarvatt_ is now known as Sarvatt [01:43] looks like xf86-input-wacom moved to sourceforge git now - http://sourceforge.net/mailarchive/forum.php?thread_name=20100106065734.GA20435%40barra.bne.redhat.com&forum_name=linuxwacom-devel [01:44] i cant work out the udev rules/xorg.conf entries to get it working for the life of me but people have it working fine with hal even with input abi 9 :( [01:47] huh [02:04] I dont get it but I'm not getting the batchbuffer IO errors with 2.4.17 and mesa 7.7, I must have just been hitting an error that was in 2.4.16 and fixed before 2.4.17 when I was crashing with 2.9.1 before. [02:05] other people in that bug were saying they didnt get it with 2.9.1 so I guess its something in the newer ddx making it need the older libdrm not to crash [02:08] i need it to crash now that i've got a kernel with the better batchbuffer dump built in that ickle was asking for so i'm going back to edgers, no crash with x-testing packages since they were uploaded though [02:09] Sarvatt, excellent [02:10] sounds like libdrm/mesa can be uploaded now [02:10] I'll touch base with timo tomorrow to see if there's anything else to do before uploading (and see if he wants to do it or if I should) [02:12] i was thinking about it, and is intel 2.10 a good idea for the LTS really? I still see quite alot of bugs with people not able to use KMS, just worried about dropping UMS support entirely [02:12] thats painful to say because I love my crack versions :D [02:12] dunno [02:13] there's pros and cons, I don't have a solid opinion [02:15] hi. is anyone using nouveau? [02:15] Yup. [02:15] Well, not right now, but yes in general. [02:16] i installed it today [02:16] and i'm having this issue with fonts: [02:16] * RAOF is no longer sure how appropriate “nouveau by default" in lucid will be. [02:16] :p [02:16] http://dl.dropbox.com/u/659315/screenshots/fonts_nouveau.png [02:16] i'm also kind of questioning dropping hal for udev as custom patches that are really different than upstream, and doesnt seem like the whole udev/inputclass stuff will be up to snuff until xserver 1.9 since its in feature freeze now and tseliots changes for udev tags might not make it until then? seems like we're going to need xorg.conf.d for wacom but I probably dont understand the whole situation. i'm not sure if the xorg.conf.d stuff is even [02:16] backportable since it bumps the input abi 2 times over 1.7 [02:17] afv: When you say "installed", what do you mean exactly? :) [02:18] i'm using lucid with 2.6.33 [02:18] and using xorg edgers ppa [02:18] And what card? Have you installed the nouveau-firmware package (if you've got a geforce 8 or above?) [02:19] yeah nouveau really seems lucid+1 too, would be so much easier when its in the actual kernel and it's still so volatile [02:19] it's installed [02:19] Sarvatt, yeah I had a bad feeling about dropping hal, and it seems my worry was justified [02:19] 01:00.0 VGA compatible controller: nVidia Corporation G72M [Quadro NVS 110M/GeForce Go 7300] (rev a1) [02:19] asus laptop [02:21] Sarvatt: Yeah; I'm not confident that we'll be able to do any backporting of kernel fixes, and even their DDX work is more xserver 1.8 focused. [02:23] Also, it seems no one in the kernel team is tasked with actually driving it :) [02:23] afv, where did you get the .33 kernel? [02:23] form http://kernel.ubuntu.com/~kernel-ppa/mainline [02:23] from* [02:24] rc2 [02:24] If you've got the DDX from xorg-edgers then you've also got nouveau-kernel-source, so it doesn't really matter. [02:24] RAOF, what do you mean abou the remark about nouveau by default on lucid? [02:25] bjsnider: I'm no longer convinced that it is a good idea. [02:25] surely you can't think the nv ddriver is a better idea... [02:25] I really do at least [02:26] The nv driver doesn't require a kernel module that it will be really difficult to backport fixes to. [02:26] every day there are people who come into +1 and complain that nv has given them a glorious black screen [02:27] It would be lovely to give users a non-crap nvidia driver by default, but if we're assuming that they're using the open driver as a stepping-stone to the binary driver, then I don't think nouveau-by-default buys us much except backporting headaches. [02:27] personally I'd rather vesa be the default over -nv, just need a screen to be able to install the blob through the gui :D [02:27] you mean in the sense that you're not going to be using the .33 kernel? [02:28] bjsnider: Right. But more than that, I don't think using the .33 kernel would buy us much, either; nouveau will continue to be developed against drm-next. [02:28] It'd make the lucid release easier, but in a year's time that's not going to be very relevant. [02:29] Sarvatt: Is there any hardware that nv drives that vesa doesn't? That's a nice thought :) [02:29] and supporting it in a LTS would be a nightmare with how much it changes on a week to week basis [02:29] RAOF, yes, i do have the nouveau-kernel-source installed [02:29] vesa works on igp's! :D [02:29] then don't change it [02:29] just get a decent build in there and freeze it like that [02:29] bjsnider: We can't drop nouveau into main and then not support it. That's the whole point of main! [02:30] well, then explain to me how fedora is able to get around these issues [02:30] the changes are going to be too major to backport upstream fixes at some point [02:30] By not supporting it. [02:30] they haven't used nouveau in RHEL? [02:31] I don't think so, no. [02:31] I could be wrong here, but that would seem crazy. [02:32] but you can't be expected to fix bugs that are not fixed upstream [02:32] if lucid is to go by, we'd probably only actively do support/backports to it for a month or so after release [02:32] yeah thats what I mean by fedora doesn't, fedora doesnt support nouveau for long outside of making people update to new releases :D [02:32] I guess it would work if they paid darktama to backport all the fixes to whatever kernel/libdrm/Xserver versions RHEL uses. [02:32] for lucid, after alpha-1 we generally only did security fixes and a few random targets of opportunity [02:33] bryyce: By "lucid", you mean... Karmic? Hardy? [02:33] ya mean hardy bryyce? [02:33] ah right, hardy [02:34] anyway, I suspect what we (you guys and me) will want to do is put driver updates into a ppa for users that need them [02:34] especially with nouveau that'll be a lot less trouble than doing a lot of backporting [02:34] Yes. [02:35] and I definitely agree that being aggressive about using vesa whereever we're uncertain about nouveau is a dandy idea [02:35] open to suggestions on that [02:35] vesa will probably give you a broken screen resolution [02:35] ...until you install the binary driver. [02:36] bjsnider, yeah but who cares, the user will just use it as a bridge to -nvidia [02:36] Which is what we're targetting here. [02:36] what about old junk pre-geforce 6k? they can't use the blob [02:36] with -nv they're not getting 3D, which these days is becoming more and more a requirement [02:37] Man, I hope we'll be able to turn on nouveau gallium by 10.10; gnome-shell will be an unhappy camper with nv. [02:37] bjsnider, well it's not like we'll be deleting -nv, just wouldn't have it as the default [02:37] bjsnider: They install one of the *many* legacy versions of nvidia-glx? [02:37] We haven't dropped any of our 4 nvidia-glx packages, have we? [02:38] not afaik [02:38] i haven't checked [02:38] do they work with the newer x servers? [02:38] Fair point. [02:38] or kernels [02:38] has anybody tested that? [02:38] afv: I'm about to upload a new nouveau-kernel-source; feel free to try with that. [02:39] they are usually brought up to date for newer xservers and kernel [02:39] yes but the 177 for instance wouldn't have been touched for aloooong time now [02:39] Nvidia tests, and I've been working with our QA team to get test procedures in place for the binary drivers [02:39] all but the 96.xx series were updated for xserver 1.7 [02:39] I think the oldest legacy driver may not have been rebuilt [02:40] 96.xx is geforce 2 and older i think [02:40] retaining -nv for just those oldest ones might make sense [02:40] RAOF, sure, i'll try it. thanks. :) i'm going also to upgrade from .33 rc2 to rc3 [02:41] So the cards that the binary driver doesn't work on are also the cards that nouveau has the worst performance on. Sweet. [02:41] but it would be nice if we could stop putting attention on -nv and just focus efforts to supporting -nouveau [02:41] nouveau will get you x-video and stuff like that on an old riva tnt2, and you can't use any of the 177 or later blobs, and there are other showstoppers on the 96/71 blobs [02:41] since nvidia spends a total of 5 minutes a year working on them [02:41] and nv [02:41] afv: Kernel upgrades probably won't do much for nouveau; nouveau-kernel-source replaces all the drm infrastructure anyway. [02:41] ok :) [02:42] bjsnider: If we really wanted to use novueau as a feature-driver we'd need to make sure it's not slower than vesa on those cards. [02:43] a feature driver? is that what vesa is? [02:43] RAOF, and what about 3d? is the guide at http://nouveau.freedesktop.org/wiki/GalliumHowto ok to follow? [02:44] afv: Yeah. You should get a not-too-shabby compiz experience, if my 7600go is any indication. [02:45] hmm [02:45] i tried that today [02:45] nv is great for those, its just igp's, newer cards and those hybrid graphics laptops that really melt down with nv from what i've seen [02:45] bjsnider: You're suggesting that we use nouveau on the really old cards because nouveau supports interesting features, but on really old cards there's the problem that the acceleration setup time exceeds the actual acceleration, so the driver is slower than no acceleration. [02:45] RAOF, the gnome-shell guys told me in their channel that gnome-panel is not in fact being removed as an option in gnome-3, so don't worry about gallium by 10.10 [02:45] and some agp-pci-e bridge chip nvidia cards [02:45] but there's a "gmake" at the page that i didn't use :s [02:45] where's gmake from? [02:45] i get a "No command 'gmake' found, did you mean:" [02:46] i really hope to have nouveau gallium packaged in edgers by the time lucid releases, its really nice even now [02:46] that would be really nice [02:46] Sarvatt: Apart from the kernel panics, of course. [02:47] lol [02:47] yeah, i saw alot of commits supposedly fixing gpu hangs under 3d to nouveau a few days ago, at least for nv50 [02:48] RAOF, there are a couple of people over in +1 that have riva tnt2 cards i think. perhaps they know already if nouveau is fast enough [02:49] bjsnider: Yes. DanaG is one of them, and he complains that it's much slower than no acceleration. [02:49] cant imagine using nouveau on one of those, pixmaps + 16mb vram fun [02:50] am i supposed to run glxgears using "$ LD_LIBRARY_PATH="/home/afv/.temp/nouveau/mesa/lib/" LIBGL_DRIVERS_PATH="/home/afv/.temp/nouveau/mesa/lib/gallium" glxgears"? [02:50] for example [02:50] afv: Yeah. I tend to just export those variables and run stuff normally, though. [02:50] ok. but then i get a "Mesa warning: couldn't open libtxc_dxtn.so, software DXTn compression/decompression unavailable [02:50] " [02:51] Funky! [02:51] yup that looks right, i just set up a bash alias for it -- alias gallium='LD_LIBRARY_PATH="/opt/mesa/lib/" LIBGL_DRIVERS_PATH="/opt/mesa/lib/gallium"' [02:51] nice [02:51] do you have LIBGL_DEBUG=1 set afv? [02:51] should only see that if you do [02:51] For what it's worth, that guide is a bit old, and doesn't use the same set of configure flags that I use, but looks right. [02:51] I gather the main thing that is behind the push for nouveau is to get Ubuntu able to do KMS and show the fancy boot stuff across all the major gfx cards out of the box [02:52] running glxgears: http://pastebin.com/d461e9adf [02:52] Sarvatt, hmm, i don't think so :s [02:53] but if we are not confident that nouveau is solid enough for Lucid, then I'd be willing to try pushing back on it. But we'd really need to make a convincing case [02:53] As long as no one wants to actually support it with bug fixes, I think it'll be fine. [02:54] yeah like I said, I think most realistically we'll just point people to PPAs [02:55] As a piece of snapshot code right now, I think it's a better default nvidia driver than nv. [02:55] I could see us pushing backports for a few weeks post-release for any critical issues while it's still reasonably easy to backport stuff [02:55] still too quirky on my nv86 for me to say that :( [02:55] kms isn't only for boot [02:55] it also does fast vt switching [02:56] would want to isolate the chips that only work with KMS with nouveau as well, I havent seen a list yet but mine is one of them [02:56] bjsnider, yeah I know but that isn't a feature that many beyond us geeks care about ;-) [02:57] Yes, but that's a bit irrelevant for nvidia; the binary blob doesn't (and won't, I think) do kms, what we're really trying to support is "nice initial boot until you install the blob" [02:57] nerds [02:57] geeks bite the heads off chickens in a circus [02:57] nerds are sour candy that comes in a little box [02:57] Because people, quite reasonably, want 3D. And we *definitely* aren't going to ship that :). [02:58] bryyce, well played, number six. [02:58] if this was a normal release I would for sure be pushing for it but it being a LTS... I'm happy to use a PPA :D [02:58] I've never heard "geek" used in that fashion; in all the usages I've seen, “geek" is not pajoritive. [02:58] Wheras “nerd" is. Anyway... [02:59] yeah [02:59] and biting heads off chickens is cool [02:59] RAOF, I'll make a note to doublecheck with the kernel team about nouveau, either tomorrow or early next week [03:00] Ok. Thanks. [03:00] I'm not sure how I can be helpful there at the moment :) [03:01] i've got my bets on 2.6.34-rc2 being out before lucid :D [03:01] could be [03:02] and fixes needed for nouveau not being easily backportable to 2.6.32 [03:02] it's kind of funny (or sad), prior to UDS everyone was saying, "Let's be conservative about what we change in Lucid so we can really make what we have solid" [03:03] and then at UDS, day by day we got more and more X changes set as requirements... dropping HAL, nouveau, changing to the new wacom driver, etc. [03:03] And now it's all like “nouveau! kms! puppies!"? [03:04] I found it quite frustrating [03:04] i'm surprised how cracky its being in some areas (like the extreme boot speed aggressiveness causing other problems) and conservative in others (like the kernel version) [03:05] yeah [03:05] afv: nouveau-kernel-source uploaded; give it half an hour or so and it should be available for you. [03:05] if we had 4 months i can see it but i was under the assumption things were going to freeze alot earlier [03:06] half hour?! ppa builds got faster, had to wait 10 hours for the last round of ddx builds [03:06] the boot guys really drove hard for a lot of changes that I personally think are biting off a lot to chew [03:06] oh i think you built a gallium debug module afv [03:06] i dont get messages like that [03:07] is the kernel team happy with the idea of using the .32 kernel again? [03:07] bjsnider, the ones I talked to seemed enthusiastic about it [03:10] It's going to be an lts kernel release, isn't it? And IIRC RedHat will be using it, and suse, so we'll be in good company there. [03:15] hmm, Sarvatt, anyway i can't run compiz.. [03:15] do packages in backports build against other components in backports? because you can almost bet there will be libdrm updates needed to build new nouveau in backports [03:15] RAOF, thanks! [03:16] afv I use ./configure --enable-glx-tls --with-dri-drivers= --enable-gallium-nouveau --disable-gallium-intel --disable-gallium-radeon --disable-gallium-svga --with-state-trackers=glx,dri --with-demos=xdemos,demos,trivial,tests [03:16] afv: Does compiz segfault? [03:16] but i think the configure options have changed since the last time i built it [03:16] been alot of change in gallium configure flags in mesa master in the past few weeks [03:16] Because that's what it was doing for me most recently :) [03:17] nop. i get some weird stuff (like a white but transparent layer over the screen. lol) [03:17] Sarvatt, thanks, i'll use that [03:17] i think that wiki page had you compile in debug [03:19] compiz: http://pastebin.com/d328aeba1 [03:19] oh nice they updated the wiki [03:19] Sarvatt, hmm, maybe, it does have a "--enable-debug" [03:21] you can ignore the libtxc_dxtn.so error though, everyone gets that if they dont have it installed and use debug [03:23] guess i'll package up this libkms next time i update libdrm in edgers [03:25] ok :) [03:25] Libkms? [03:26] RAOF, do you know of nouveau has the same power-management issue that radeon has with the kms driver? where the card is constantly at full-throttle? [03:27] rebooting.. [03:27] "Preparing to replace nouveau-kernel-source 0.0.15+git20091231-0~10.04~ppa1 (using nouveau-kernel-source_0.0.15+git20100108-0~10.04~ppa1_all.deb) ..." [03:28] bjsnider: I haven't noticed it; I seem to get approximately the same (crappy) battery life with nouveau as nvidia. [03:30] I get ALOT less battery life with nouveau, its always running at full clock speed on my 8400M GS [03:30] brb. i hope :p [03:30] like 40 minutes vs 1 hour 50 minutes [03:30] It's possible that my 7600 just doesn't have any appreciable throttling. [03:31] yeah mine has 3 power states and its usually at 120mhz with the blob [03:31] Maybe mine's stuck on lowest throttle with nouveau :) [03:32] it probably doesnt lower the voltage at the different speeds on the older cards is my guess [03:32] That may well be it. [03:32] Sarvatt, what card do you have? [03:32] 8400M GS [03:33] how long have you had that laptop? [03:33] 2 years or so [03:33] wow [03:34] you've far exceeded the lifespan for a bumpgate chip as far as i'm concerned [03:35] yeah I got this one as a replacement for an older model that went through 3 replacements due to the crappy BGA mounted nvidia chips [03:36] i havent even really used it in 1.5 years since i got a netbook, its mostly run headless so that might be why :D [03:36] i figure the card in my rig has only lasted 2 years because it always remains at the same temp, because i never turn it off [03:36] ah, i c [03:49] hmm, this was not good :p [03:50] and my apt/cache folder just disappeared :s [03:51] Xorg log: http://pastebin.com/d1e65e6d6 [03:53] afv: Hows about dmesg; the problem is that nouveau's kernel module hasn't loaded, and the DDX won't work without it. [03:53] (In fact, the DDX is about to have the non-KMS codepath removed, too). [03:56] i didn't save dmesg :\ [03:56] but i have something like "kernel: [ 34.250444] Xorg[4301]: segfault at 18 ip 00000018 sp bffefc5c error 4 in Xorg[8048000+19f000]" at syslog [03:56] Yeah. Everything will break if you don't have the kernel module loaded. [03:56] right [03:56] well, i gotta go now [03:57] will be back later [03:57] thanks for all the help =) [03:57] keep up the good work [03:57] c ya [04:05] afv: FWIW I've just got compiz a-runnin' again on my 7600go [04:07] nice :) [04:07] bbl [04:31] ...and GPU lockup again. [04:32] it's not a lockup it's an unscheduled lack of complete functionality [04:38] No, it's an actual lockup. [05:07] still no libxcb update.. did it get held up because of the new libxcb-dri2 package maybe? [05:28] Can I force radeon/fglrx to POST my card when X starts? [06:58] bryyce: I wanted to be sure that the libdri/libglx stuff is done before uploading it [06:59] I didn't notice that change until tseliot was gone [07:12] tjaalton, okay [07:13] and looks like mesa needs to move libGL to somewhere else than /usr/lib for the alternatives to work... [07:13] it's getty uglier every day :/ [07:13] getting [07:13] I don't like how everything is changed to cater for nvidia [07:14] heh, yeah this is the kinda stuff pitti was worried would happen [07:14] we'd be using this forever, or as long as nvidia ships blobs [07:15] RAOF: I'm pretty sure RHEL6 will have nouveau by default [07:15] but they have the manpower to maintain it [07:16] it would be great if mark did what he said here http://www.markshuttleworth.com/archives/95 [07:17] as pointed out by airlied on dri-devel@ during the nouveau discussion.. [07:19] oh well, enough ranting, more waking up ;) [07:26] Sarvatt: we wouldn't have to bump the api twice, in fact not at all since the inputclass bump was only for wacom IIRC (and that can be patched in the driver) [07:26] need to check [07:30] yep [07:30] the other abi bump was due to "Add type name argument to CreateNewResourceType" [07:31] tjaalton, maybe you should email mark to remind him of that ;-) [07:31] bryyce: really? :) [07:31] it's too late for lucid anyway I think [07:32] actually, half the problem is that it's hard to find X.org engineers wanting to come work for us [07:33] yeah [07:34] but as a general rule canonical tends to focus resources more to integration and polish than to raw development, especially at the driver level [07:34] but I think it's partly due to the devel community thinking C wouldn't let them continue upstream work, but mostly just distro stuff [07:34] hehe, spot on :) [07:35] well and if you think about it, redhat is kind of unique in the amount of upstream development they do [07:36] but that is a business strategy they use, that lets them sell themselves to customers [07:37] oh boy, didnt notice the mesa problem with the PPA nvidia there [07:38] the way I see it is that after some point the organisation needs to contribute more upstream work to be a "valuable player" or something such [07:39] and that's what "the others" think [07:39] LIBGL_ALWAYS_INDIRECT=1 glxgears/compiz/whatever works but Error: couldn't get an RGB, Double-buffered visual without [07:40] you didn't notice there was no compiz? :) [07:40] dont use it, nope [07:41] tjaalton, it doesn't matter. They still complain anyway. Look at how heavily I worked with upstream on QA for -intel this past year, pushed bug reports up, quirks, lots of testing, documentation, and on and on [07:42] bryyce: but you're just one man :) [07:43] tjaalton, so? upstream (well, specifically RedHat) still does not recognize any of that as having contributed any value upstream [07:47] bryyce: my point was that there's only so much one man can do, and that can get lost in the noise [07:47] I know it's not fair to compare to RH [07:47] tjaalton, true, it still is quite demotivating to me personally to hear all this. Makes me want to go work on launchpad or something instead. ;-) [07:48] haha [07:48] heck, we actually have 3 paid people full time on X, and it's still not noticed [07:48] you have? [07:48] but redhat's been at this game for a lot longer, I think give canonical time and we'll see [07:50] tjaalton, well, we have one kernel guy full time devoted to X (sconklin this release, andy last time), and for lucid alberto is on X 4 out of 5 days [07:51] bryyce: ok, didn't know that [07:51] so if I haven't noticed that, what does it tell ;) [07:51] * tjaalton runs [07:51] yeah exactly [07:52] well, honestly with us all buried under the deluge of incoming bug reports it's hard to really put time into anything beyond fighting fires [07:53] when I'm feeling really cynical I think to myself that if we had more people who could do work upstream, I'd have them sit on the hands of upstream developers so they quit changing all this shit ;-) [07:54] of course then I'm sure our own Dx team would come up with some brilliant shit that should be changed upstream... [07:56] hehe :) [07:59] and we'd still get ripped because we'd be working on foo, when upstream would rather have us doing bar [08:00] well, with X there should be less chance for that. apps, sure [08:00] tjaalton, heh now you've got *me* ranting ;-) [08:01] bryyce: that was to be expected ;) [08:02] aanyway, back to reality. I'll test the inputclass/x.c.d patches skipping the abi bump [08:07] hmm, need to go shoveling. we got maybe 50cm snow already [08:08] wow [08:19] and next week I'll be joining the rest of the family in lapland, where there is -35 right now :P [08:19] got wacom working! [08:19] C [08:20] Sarvatt: ya [08:20] +y [08:20] http://pastebin.ubuntu.com/353354/ [08:20] woohoo [08:21] took 2 udev rules [08:21] show 'em [08:21] needed one to make the input/wacom symlink and another for xserver handling, one sec [08:22] yeah the package always had the first one [08:23] http://pastebin.ubuntu.com/353356/ [08:23] i'm not using the old packaging, didnt have any luck with the old xserver-xorg-input-wacom.rules file [08:25] do all the buttons work? or xsetwacom? [08:26] graphires working right, i'm digging out my intuos 3 now to test extra buttons [08:28] trying to find where i built this wacom, didnt install xsetwacom with the package but it built [08:33] yeah all looks to be working fine [08:36] http://pastebin.ubuntu.com/353361/ [08:36] picked up the extra pad of buttons on the intuos and such and they work [08:37] sweet [08:37] could you put the source somewhere, I'll try it on my aiptek/waltop [08:38] sure one sec [08:38] this wont work for serial tablets though since they're tty, i saw thjaeger posting patches to try to get it working on the linuxwacom-devel list [08:39] mine is usb [08:40] I suspect it'll fail miserably, but we'll see [08:40] intuos4 was out of stock :/ [08:40] and still is [08:41] http://sarvatt.com/downloads/xserver-xorg-input-wacom_0.10.3+git20100106.tar.gz [08:42] oh man.. intuos4 L up for an auction [08:42] the packaging is screwy, i just took thjaeger's latest and threw it in a new git checkout, it needs to install xsetwacom and not install the hal stuff on top of needing udev rules [08:42] L? [08:42] A4 wide size [08:43] oh nice [08:43] only a few months old, 360e :P [08:43] this intuos3 4x6 cost way too much [08:46] they are pricey [08:48] why did tseliot want libvdpau in main? [08:48] does something in main support building against it? [08:49] dont think that udev rule is going to work since the vendor doesnt match, looks like the hal fdi file was what let waltop work [08:49] superm1: isn't that required by nvidia or is it just for development? [08:49] Sarvatt: I'll fix that part [08:49] oh you're here [08:49] ffmpeg or mplayer? [08:49] tseliot, it's only needed if your application supports vdpau acceleration [08:49] or gstreamer? [08:49] which is mostly ffmpeg apps like mplayer and mythtv right now [08:49] i dont think gstreamer has support yet [08:50] at least i havent heard of it if it does [08:50] superm1: and shouldn't nvidia recommend that package? [08:50] tseliot, no it shouldnt [08:50] the apps that use it should [08:50] had this discussion with some people in debian and with bjsnider [08:51] if anything there could maybe be an enhances [08:51] ok, so basic support for vdpau lives in the driver but if you want to use it you'll have to install an additional package [08:51] well not entirely accurate [08:51] the basic support to open an implementation lives in the libvdpau package. the nvidia implementation lives in the nvidia package [08:52] the user wont have to install the second package either [08:52] it will be a shlibdeps for any package built against libvdpau-dev [08:52] Oh, there's some implementation in libvdpau? I thought it was basically “make it easy to dynamically load the appropriate library when it's available". [08:52] ah [08:53] the implementation itself doesnt live in libvdpau, no. [08:53] support to "open an implementation" [08:53] so dynamically loading the library is right [08:53] ok [08:54] superm1: also, any ideas as to why libGL.so.1 provided by nvidia is not loaded before libGL.so.1 provided by mesa? http://pastebin.ubuntu.com/353366/ [08:55] the hal fdi was adding wacom, and the udev rules just matched wacom product id's so i dont know that its going to work unless you add your tablets product id to the udev rule? [08:55] superm1: the path to the former is in /etc/ld.so.conf.d [08:56] Sarvatt: it doesn't use the kernel module [08:56] tseliot, hm. not positive.. [08:56] tseliot, where's the path to the mesa one referenced? [08:56] also ld.so.conf.d? [08:56] superm1: I think our last resort would be to use preload [08:57] tseliot, ugh that's not a good solution to rely on [08:57] because every app would have to do that [08:57] superm1: no, there's no need to specify /usr/lib as it's automatically picked up [08:57] /lib and /usr/lib are trusted paths, used by default [08:58] Sarvatt: meaning that the funcionality is limited, but at least pressure sensitivity worked at some point [08:59] tjaalton: right [08:59] tseliot, how does mandriva get around this? [08:59] i would think the priorities would work out identically [08:59] I'm talking to them right now [09:00] yes, they should and the same system seems to work well for them [09:00] are they maybe also using LD_LIBRARY_PATH too? [09:01] that would explain it [09:02] it looks like they don't [09:02] does the kernel recognize it as a tablet? imagine that 67-xorg-wacom.rules would pick it up if so since it loads wacom for all ID_INPUT_TABLET [09:04] Sarvatt: haven't tried yet ;) [09:11] Sarvatt: yes it does [09:12] id_input adds ID_INPUT_TABLET=1 [09:15] i cant load wacom without that extra udev rule making the symlink, but maybe thats just because i'm using the wacom module.. the old udev rule only touched things with a wacom product id from what i see [09:16] and it just matched some extra things that work with it like waltop in the fdi [09:43] Sarvatt: heh, I need a patch from the wacom list to make it work with inputclass [09:46] but lunch first [09:49]