| bryyce | tjaalton, I see there's some xorg-server changes queued in git; is there a reason they're not uploaded yet? | 00:53 |
|---|---|---|
| === Sarvatt_ is now known as Sarvatt | ||
| Sarvatt | 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:43 |
| Sarvatt | 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:44 |
| bryyce | huh | 01:47 |
| Sarvatt | 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:04 |
| Sarvatt | 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:05 |
| Sarvatt | 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:08 |
| bryyce | Sarvatt, excellent | 02:09 |
| bryyce | sounds like libdrm/mesa can be uploaded now | 02:10 |
| bryyce | 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:10 |
| Sarvatt | 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 |
| Sarvatt | thats painful to say because I love my crack versions :D | 02:12 |
| bryyce | dunno | 02:12 |
| bryyce | there's pros and cons, I don't have a solid opinion | 02:13 |
| afv | hi. is anyone using nouveau? | 02:15 |
| RAOF | Yup. | 02:15 |
| RAOF | Well, not right now, but yes in general. | 02:15 |
| afv | i installed it today | 02:16 |
| afv | 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 | |
| afv | :p | 02:16 |
| afv | http://dl.dropbox.com/u/659315/screenshots/fonts_nouveau.png | 02:16 |
| Sarvatt | 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 |
| Sarvatt | backportable since it bumps the input abi 2 times over 1.7 | 02:16 |
| RAOF | afv: When you say "installed", what do you mean exactly? :) | 02:17 |
| afv | i'm using lucid with 2.6.33 | 02:18 |
| afv | and using xorg edgers ppa | 02:18 |
| RAOF | And what card? Have you installed the nouveau-firmware package (if you've got a geforce 8 or above?) | 02:18 |
| Sarvatt | 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 |
| afv | it's installed | 02:19 |
| bryyce | Sarvatt, yeah I had a bad feeling about dropping hal, and it seems my worry was justified | 02:19 |
| afv | 01:00.0 VGA compatible controller: nVidia Corporation G72M [Quadro NVS 110M/GeForce Go 7300] (rev a1) | 02:19 |
| afv | asus laptop | 02:19 |
| RAOF | 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:21 |
| RAOF | Also, it seems no one in the kernel team is tasked with actually driving it :) | 02:23 |
| bjsnider | afv, where did you get the .33 kernel? | 02:23 |
| afv | form http://kernel.ubuntu.com/~kernel-ppa/mainline | 02:23 |
| afv | from* | 02:23 |
| afv | rc2 | 02:24 |
| RAOF | 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 |
| bjsnider | RAOF, what do you mean abou the remark about nouveau by default on lucid? | 02:24 |
| RAOF | bjsnider: I'm no longer convinced that it is a good idea. | 02:25 |
| bjsnider | surely you can't think the nv ddriver is a better idea... | 02:25 |
| Sarvatt | I really do at least | 02:25 |
| RAOF | The nv driver doesn't require a kernel module that it will be really difficult to backport fixes to. | 02:26 |
| bjsnider | every day there are people who come into +1 and complain that nv has given them a glorious black screen | 02:26 |
| RAOF | 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 |
| Sarvatt | 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 |
| bjsnider | you mean in the sense that you're not going to be using the .33 kernel? | 02:27 |
| RAOF | 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 |
| RAOF | It'd make the lucid release easier, but in a year's time that's not going to be very relevant. | 02:28 |
| RAOF | Sarvatt: Is there any hardware that nv drives that vesa doesn't? That's a nice thought :) | 02:29 |
| Sarvatt | and supporting it in a LTS would be a nightmare with how much it changes on a week to week basis | 02:29 |
| afv | RAOF, yes, i do have the nouveau-kernel-source installed | 02:29 |
| Sarvatt | vesa works on igp's! :D | 02:29 |
| bjsnider | then don't change it | 02:29 |
| bjsnider | just get a decent build in there and freeze it like that | 02:29 |
| RAOF | bjsnider: We can't drop nouveau into main and then not support it. That's the whole point of main! | 02:29 |
| bjsnider | well, then explain to me how fedora is able to get around these issues | 02:30 |
| Sarvatt | the changes are going to be too major to backport upstream fixes at some point | 02:30 |
| RAOF | By not supporting it. | 02:30 |
| Sarvatt | they haven't used nouveau in RHEL? | 02:30 |
| RAOF | I don't think so, no. | 02:31 |
| RAOF | I could be wrong here, but that would seem crazy. | 02:31 |
| bjsnider | but you can't be expected to fix bugs that are not fixed upstream | 02:32 |
| bryyce | 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 |
| Sarvatt | 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 |
| RAOF | I guess it would work if they paid darktama to backport all the fixes to whatever kernel/libdrm/Xserver versions RHEL uses. | 02:32 |
| bryyce | for lucid, after alpha-1 we generally only did security fixes and a few random targets of opportunity | 02:32 |
| RAOF | bryyce: By "lucid", you mean... Karmic? Hardy? | 02:33 |
| Sarvatt | ya mean hardy bryyce? | 02:33 |
| bryyce | ah right, hardy | 02:33 |
| bryyce | 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 |
| bryyce | especially with nouveau that'll be a lot less trouble than doing a lot of backporting | 02:34 |
| RAOF | Yes. | 02:34 |
| bryyce | and I definitely agree that being aggressive about using vesa whereever we're uncertain about nouveau is a dandy idea | 02:35 |
| bryyce | open to suggestions on that | 02:35 |
| bjsnider | vesa will probably give you a broken screen resolution | 02:35 |
| RAOF | ...until you install the binary driver. | 02:35 |
| bryyce | bjsnider, yeah but who cares, the user will just use it as a bridge to -nvidia | 02:36 |
| RAOF | Which is what we're targetting here. | 02:36 |
| bjsnider | what about old junk pre-geforce 6k? they can't use the blob | 02:36 |
| bryyce | with -nv they're not getting 3D, which these days is becoming more and more a requirement | 02:36 |
| RAOF | 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 |
| bryyce | bjsnider, well it's not like we'll be deleting -nv, just wouldn't have it as the default | 02:37 |
| RAOF | bjsnider: They install one of the *many* legacy versions of nvidia-glx? | 02:37 |
| RAOF | We haven't dropped any of our 4 nvidia-glx packages, have we? | 02:37 |
| bryyce | not afaik | 02:38 |
| bjsnider | i haven't checked | 02:38 |
| bjsnider | do they work with the newer x servers? | 02:38 |
| RAOF | Fair point. | 02:38 |
| bjsnider | or kernels | 02:38 |
| bjsnider | has anybody tested that? | 02:38 |
| RAOF | afv: I'm about to upload a new nouveau-kernel-source; feel free to try with that. | 02:38 |
| bryyce | they are usually brought up to date for newer xservers and kernel | 02:39 |
| bjsnider | yes but the 177 for instance wouldn't have been touched for aloooong time now | 02:39 |
| bryyce | Nvidia tests, and I've been working with our QA team to get test procedures in place for the binary drivers | 02:39 |
| Sarvatt | all but the 96.xx series were updated for xserver 1.7 | 02:39 |
| bryyce | I think the oldest legacy driver may not have been rebuilt | 02:39 |
| Sarvatt | 96.xx is geforce 2 and older i think | 02:40 |
| bryyce | retaining -nv for just those oldest ones might make sense | 02:40 |
| afv | RAOF, sure, i'll try it. thanks. :) i'm going also to upgrade from .33 rc2 to rc3 | 02:40 |
| RAOF | 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 |
| bryyce | but it would be nice if we could stop putting attention on -nv and just focus efforts to supporting -nouveau | 02:41 |
| bjsnider | 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 |
| bjsnider | since nvidia spends a total of 5 minutes a year working on them | 02:41 |
| bjsnider | and nv | 02:41 |
| RAOF | afv: Kernel upgrades probably won't do much for nouveau; nouveau-kernel-source replaces all the drm infrastructure anyway. | 02:41 |
| afv | ok :) | 02:41 |
| RAOF | 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:42 |
| bjsnider | a feature driver? is that what vesa is? | 02:43 |
| afv | RAOF, and what about 3d? is the guide at http://nouveau.freedesktop.org/wiki/GalliumHowto ok to follow? | 02:43 |
| RAOF | afv: Yeah. You should get a not-too-shabby compiz experience, if my 7600go is any indication. | 02:44 |
| afv | hmm | 02:45 |
| afv | i tried that today | 02:45 |
| Sarvatt | 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 |
| RAOF | 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 |
| bjsnider | 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 |
| Sarvatt | and some agp-pci-e bridge chip nvidia cards | 02:45 |
| afv | but there's a "gmake" at the page that i didn't use :s | 02:45 |
| afv | where's gmake from? | 02:45 |
| afv | i get a "No command 'gmake' found, did you mean:" | 02:45 |
| Sarvatt | i really hope to have nouveau gallium packaged in edgers by the time lucid releases, its really nice even now | 02:46 |
| afv | that would be really nice | 02:46 |
| RAOF | Sarvatt: Apart from the kernel panics, of course. | 02:46 |
| afv | lol | 02:47 |
| Sarvatt | yeah, i saw alot of commits supposedly fixing gpu hangs under 3d to nouveau a few days ago, at least for nv50 | 02:47 |
| bjsnider | 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:48 |
| RAOF | bjsnider: Yes. DanaG is one of them, and he complains that it's much slower than no acceleration. | 02:49 |
| Sarvatt | cant imagine using nouveau on one of those, pixmaps + 16mb vram fun | 02:49 |
| afv | 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 |
| afv | for example | 02:50 |
| RAOF | afv: Yeah. I tend to just export those variables and run stuff normally, though. | 02:50 |
| afv | ok. but then i get a "Mesa warning: couldn't open libtxc_dxtn.so, software DXTn compression/decompression unavailable | 02:50 |
| afv | " | 02:50 |
| RAOF | Funky! | 02:51 |
| Sarvatt | 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 |
| afv | nice | 02:51 |
| Sarvatt | do you have LIBGL_DEBUG=1 set afv? | 02:51 |
| Sarvatt | should only see that if you do | 02:51 |
| RAOF | 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 |
| bryyce | 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:51 |
| afv | running glxgears: http://pastebin.com/d461e9adf | 02:52 |
| afv | Sarvatt, hmm, i don't think so :s | 02:52 |
| bryyce | 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 |
| RAOF | As long as no one wants to actually support it with bug fixes, I think it'll be fine. | 02:53 |
| bryyce | yeah like I said, I think most realistically we'll just point people to PPAs | 02:54 |
| RAOF | As a piece of snapshot code right now, I think it's a better default nvidia driver than nv. | 02:55 |
| bryyce | 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 |
| Sarvatt | still too quirky on my nv86 for me to say that :( | 02:55 |
| bjsnider | kms isn't only for boot | 02:55 |
| bjsnider | it also does fast vt switching | 02:55 |
| Sarvatt | 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 |
| bryyce | bjsnider, yeah I know but that isn't a feature that many beyond us geeks care about ;-) | 02:56 |
| RAOF | 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 |
| bjsnider | nerds | 02:57 |
| bjsnider | geeks bite the heads off chickens in a circus | 02:57 |
| bryyce | nerds are sour candy that comes in a little box | 02:57 |
| RAOF | Because people, quite reasonably, want 3D. And we *definitely* aren't going to ship that :). | 02:57 |
| bjsnider | bryyce, well played, number six. | 02:58 |
| Sarvatt | 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 |
| RAOF | I've never heard "geek" used in that fashion; in all the usages I've seen, “geek" is not pajoritive. | 02:58 |
| RAOF | Wheras “nerd" is. Anyway... | 02:58 |
| bryyce | yeah | 02:59 |
| bryyce | and biting heads off chickens is cool | 02:59 |
| bryyce | RAOF, I'll make a note to doublecheck with the kernel team about nouveau, either tomorrow or early next week | 02:59 |
| RAOF | Ok. Thanks. | 03:00 |
| RAOF | I'm not sure how I can be helpful there at the moment :) | 03:00 |
| Sarvatt | i've got my bets on 2.6.34-rc2 being out before lucid :D | 03:01 |
| bryyce | could be | 03:01 |
| Sarvatt | and fixes needed for nouveau not being easily backportable to 2.6.32 | 03:02 |
| bryyce | 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:02 |
| bryyce | 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 |
| RAOF | And now it's all like “nouveau! kms! puppies!"? | 03:03 |
| bryyce | I found it quite frustrating | 03:04 |
| Sarvatt | 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:04 |
| bryyce | yeah | 03:05 |
| RAOF | afv: nouveau-kernel-source uploaded; give it half an hour or so and it should be available for you. | 03:05 |
| Sarvatt | if we had 4 months i can see it but i was under the assumption things were going to freeze alot earlier | 03:05 |
| Sarvatt | half hour?! ppa builds got faster, had to wait 10 hours for the last round of ddx builds | 03:06 |
| bryyce | the boot guys really drove hard for a lot of changes that I personally think are biting off a lot to chew | 03:06 |
| Sarvatt | oh i think you built a gallium debug module afv | 03:06 |
| Sarvatt | i dont get messages like that | 03:06 |
| bjsnider | is the kernel team happy with the idea of using the .32 kernel again? | 03:07 |
| bryyce | bjsnider, the ones I talked to seemed enthusiastic about it | 03:07 |
| RAOF | 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:10 |
| afv | hmm, Sarvatt, anyway i can't run compiz.. | 03:15 |
| Sarvatt | 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 |
| afv | RAOF, thanks! | 03:15 |
| Sarvatt | 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 |
| RAOF | afv: Does compiz segfault? | 03:16 |
| Sarvatt | but i think the configure options have changed since the last time i built it | 03:16 |
| Sarvatt | been alot of change in gallium configure flags in mesa master in the past few weeks | 03:16 |
| RAOF | Because that's what it was doing for me most recently :) | 03:16 |
| afv | nop. i get some weird stuff (like a white but transparent layer over the screen. lol) | 03:17 |
| afv | Sarvatt, thanks, i'll use that | 03:17 |
| Sarvatt | i think that wiki page had you compile in debug | 03:17 |
| afv | compiz: http://pastebin.com/d328aeba1 | 03:19 |
| Sarvatt | oh nice they updated the wiki | 03:19 |
| afv | Sarvatt, hmm, maybe, it does have a "--enable-debug" | 03:19 |
| Sarvatt | you can ignore the libtxc_dxtn.so error though, everyone gets that if they dont have it installed and use debug | 03:21 |
| Sarvatt | guess i'll package up this libkms next time i update libdrm in edgers | 03:23 |
| afv | ok :) | 03:25 |
| RAOF | Libkms? | 03:25 |
| bjsnider | 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:26 |
| afv | rebooting.. | 03:27 |
| afv | "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:27 |
| RAOF | bjsnider: I haven't noticed it; I seem to get approximately the same (crappy) battery life with nouveau as nvidia. | 03:28 |
| Sarvatt | I get ALOT less battery life with nouveau, its always running at full clock speed on my 8400M GS | 03:30 |
| afv | brb. i hope :p | 03:30 |
| Sarvatt | like 40 minutes vs 1 hour 50 minutes | 03:30 |
| RAOF | It's possible that my 7600 just doesn't have any appreciable throttling. | 03:30 |
| Sarvatt | yeah mine has 3 power states and its usually at 120mhz with the blob | 03:31 |
| RAOF | Maybe mine's stuck on lowest throttle with nouveau :) | 03:31 |
| Sarvatt | it probably doesnt lower the voltage at the different speeds on the older cards is my guess | 03:32 |
| RAOF | That may well be it. | 03:32 |
| bjsnider | Sarvatt, what card do you have? | 03:32 |
| Sarvatt | 8400M GS | 03:32 |
| bjsnider | how long have you had that laptop? | 03:33 |
| Sarvatt | 2 years or so | 03:33 |
| bjsnider | wow | 03:33 |
| bjsnider | you've far exceeded the lifespan for a bumpgate chip as far as i'm concerned | 03:34 |
| Sarvatt | 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:35 |
| Sarvatt | 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 |
| bjsnider | 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 |
| bjsnider | ah, i c | 03:36 |
| afv | hmm, this was not good :p | 03:49 |
| afv | and my apt/cache folder just disappeared :s | 03:50 |
| afv | Xorg log: http://pastebin.com/d1e65e6d6 | 03:51 |
| RAOF | 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 |
| RAOF | (In fact, the DDX is about to have the non-KMS codepath removed, too). | 03:53 |
| afv | i didn't save dmesg :\ | 03:56 |
| afv | 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 |
| RAOF | Yeah. Everything will break if you don't have the kernel module loaded. | 03:56 |
| afv | right | 03:56 |
| afv | well, i gotta go now | 03:56 |
| afv | will be back later | 03:57 |
| afv | thanks for all the help =) | 03:57 |
| afv | keep up the good work | 03:57 |
| afv | c ya | 03:57 |
| RAOF | afv: FWIW I've just got compiz a-runnin' again on my 7600go | 04:05 |
| afv | nice :) | 04:07 |
| afv | bbl | 04:07 |
| RAOF | ...and GPU lockup again. | 04:31 |
| bjsnider | it's not a lockup it's an unscheduled lack of complete functionality | 04:32 |
| RAOF | No, it's an actual lockup. | 04:38 |
| Sarvatt | still no libxcb update.. did it get held up because of the new libxcb-dri2 package maybe? | 05:07 |
| wgrant | Can I force radeon/fglrx to POST my card when X starts? | 05:28 |
| tjaalton | bryyce: I wanted to be sure that the libdri/libglx stuff is done before uploading it | 06:58 |
| tjaalton | I didn't notice that change until tseliot was gone | 06:59 |
| bryyce | tjaalton, okay | 07:12 |
| tjaalton | and looks like mesa needs to move libGL to somewhere else than /usr/lib for the alternatives to work... | 07:13 |
| tjaalton | it's getty uglier every day :/ | 07:13 |
| tjaalton | getting | 07:13 |
| tjaalton | I don't like how everything is changed to cater for nvidia | 07:13 |
| bryyce | heh, yeah this is the kinda stuff pitti was worried would happen | 07:14 |
| tjaalton | we'd be using this forever, or as long as nvidia ships blobs | 07:14 |
| tjaalton | RAOF: I'm pretty sure RHEL6 will have nouveau by default | 07:15 |
| tjaalton | but they have the manpower to maintain it | 07:15 |
| tjaalton | it would be great if mark did what he said here http://www.markshuttleworth.com/archives/95 | 07:16 |
| tjaalton | as pointed out by airlied on dri-devel@ during the nouveau discussion.. | 07:17 |
| tjaalton | oh well, enough ranting, more waking up ;) | 07:19 |
| tjaalton | 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 |
| tjaalton | need to check | 07:26 |
| tjaalton | yep | 07:30 |
| tjaalton | the other abi bump was due to "Add type name argument to CreateNewResourceType" | 07:30 |
| bryyce | tjaalton, maybe you should email mark to remind him of that ;-) | 07:31 |
| tjaalton | bryyce: really? :) | 07:31 |
| tjaalton | it's too late for lucid anyway I think | 07:31 |
| bryyce | actually, half the problem is that it's hard to find X.org engineers wanting to come work for us | 07:32 |
| tjaalton | yeah | 07:33 |
| bryyce | 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 |
| tjaalton | 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 |
| tjaalton | hehe, spot on :) | 07:34 |
| bryyce | well and if you think about it, redhat is kind of unique in the amount of upstream development they do | 07:35 |
| bryyce | but that is a business strategy they use, that lets them sell themselves to customers | 07:36 |
| Sarvatt | oh boy, didnt notice the mesa problem with the PPA nvidia there | 07:37 |
| tjaalton | 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:38 |
| tjaalton | and that's what "the others" think | 07:39 |
| Sarvatt | LIBGL_ALWAYS_INDIRECT=1 glxgears/compiz/whatever works but Error: couldn't get an RGB, Double-buffered visual without | 07:39 |
| tjaalton | you didn't notice there was no compiz? :) | 07:40 |
| Sarvatt | dont use it, nope | 07:40 |
| bryyce | 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:41 |
| tjaalton | bryyce: but you're just one man :) | 07:42 |
| bryyce | tjaalton, so? upstream (well, specifically RedHat) still does not recognize any of that as having contributed any value upstream | 07:43 |
| tjaalton | bryyce: my point was that there's only so much one man can do, and that can get lost in the noise | 07:47 |
| tjaalton | I know it's not fair to compare to RH | 07:47 |
| bryyce | 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:47 |
| tjaalton | haha | 07:48 |
| bryyce | heck, we actually have 3 paid people full time on X, and it's still not noticed | 07:48 |
| tjaalton | you have? | 07:48 |
| bryyce | but redhat's been at this game for a lot longer, I think give canonical time and we'll see | 07:48 |
| bryyce | 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:50 |
| tjaalton | bryyce: ok, didn't know that | 07:51 |
| tjaalton | so if I haven't noticed that, what does it tell ;) | 07:51 |
| * tjaalton runs | 07:51 | |
| bryyce | yeah exactly | 07:51 |
| bryyce | 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:52 |
| bryyce | 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:53 |
| bryyce | of course then I'm sure our own Dx team would come up with some brilliant shit that should be changed upstream... | 07:54 |
| tjaalton | hehe :) | 07:56 |
| bryyce | and we'd still get ripped because we'd be working on foo, when upstream would rather have us doing bar | 07:59 |
| tjaalton | well, with X there should be less chance for that. apps, sure | 08:00 |
| bryyce | tjaalton, heh now you've got *me* ranting ;-) | 08:00 |
| tjaalton | bryyce: that was to be expected ;) | 08:01 |
| tjaalton | aanyway, back to reality. I'll test the inputclass/x.c.d patches skipping the abi bump | 08:02 |
| tjaalton | hmm, need to go shoveling. we got maybe 50cm snow already | 08:07 |
| bryyce | wow | 08:08 |
| tjaalton | and next week I'll be joining the rest of the family in lapland, where there is -35 right now :P | 08:19 |
| Sarvatt | got wacom working! | 08:19 |
| tjaalton | C | 08:19 |
| tjaalton | Sarvatt: ya | 08:20 |
| tjaalton | +y | 08:20 |
| Sarvatt | http://pastebin.ubuntu.com/353354/ | 08:20 |
| Sarvatt | woohoo | 08:20 |
| Sarvatt | took 2 udev rules | 08:21 |
| tjaalton | show 'em | 08:21 |
| Sarvatt | needed one to make the input/wacom symlink and another for xserver handling, one sec | 08:21 |
| tjaalton | yeah the package always had the first one | 08:22 |
| Sarvatt | http://pastebin.ubuntu.com/353356/ | 08:23 |
| Sarvatt | i'm not using the old packaging, didnt have any luck with the old xserver-xorg-input-wacom.rules file | 08:23 |
| tjaalton | do all the buttons work? or xsetwacom? | 08:25 |
| Sarvatt | graphires working right, i'm digging out my intuos 3 now to test extra buttons | 08:26 |
| Sarvatt | trying to find where i built this wacom, didnt install xsetwacom with the package but it built | 08:28 |
| Sarvatt | yeah all looks to be working fine | 08:33 |
| Sarvatt | http://pastebin.ubuntu.com/353361/ | 08:36 |
| Sarvatt | picked up the extra pad of buttons on the intuos and such and they work | 08:36 |
| tjaalton | sweet | 08:37 |
| tjaalton | could you put the source somewhere, I'll try it on my aiptek/waltop | 08:37 |
| Sarvatt | sure one sec | 08:38 |
| Sarvatt | 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:38 |
| tjaalton | mine is usb | 08:39 |
| tjaalton | I suspect it'll fail miserably, but we'll see | 08:40 |
| tjaalton | intuos4 was out of stock :/ | 08:40 |
| tjaalton | and still is | 08:40 |
| Sarvatt | http://sarvatt.com/downloads/xserver-xorg-input-wacom_0.10.3+git20100106.tar.gz | 08:41 |
| tjaalton | oh man.. intuos4 L up for an auction | 08:42 |
| Sarvatt | 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 |
| Sarvatt | L? | 08:42 |
| tjaalton | A4 wide size | 08:42 |
| Sarvatt | oh nice | 08:43 |
| tjaalton | only a few months old, 360e :P | 08:43 |
| Sarvatt | this intuos3 4x6 cost way too much | 08:43 |
| tjaalton | they are pricey | 08:46 |
| superm1 | why did tseliot want libvdpau in main? | 08:48 |
| superm1 | does something in main support building against it? | 08:48 |
| Sarvatt | 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 |
| tseliot | superm1: isn't that required by nvidia or is it just for development? | 08:49 |
| tjaalton | Sarvatt: I'll fix that part | 08:49 |
| superm1 | oh you're here | 08:49 |
| Sarvatt | ffmpeg or mplayer? | 08:49 |
| superm1 | tseliot, it's only needed if your application supports vdpau acceleration | 08:49 |
| Sarvatt | or gstreamer? | 08:49 |
| superm1 | which is mostly ffmpeg apps like mplayer and mythtv right now | 08:49 |
| superm1 | i dont think gstreamer has support yet | 08:49 |
| superm1 | at least i havent heard of it if it does | 08:50 |
| tseliot | superm1: and shouldn't nvidia recommend that package? | 08:50 |
| superm1 | tseliot, no it shouldnt | 08:50 |
| superm1 | the apps that use it should | 08:50 |
| superm1 | had this discussion with some people in debian and with bjsnider | 08:50 |
| superm1 | if anything there could maybe be an enhances | 08:51 |
| tseliot | 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 |
| superm1 | well not entirely accurate | 08:51 |
| superm1 | the basic support to open an implementation lives in the libvdpau package. the nvidia implementation lives in the nvidia package | 08:51 |
| superm1 | the user wont have to install the second package either | 08:52 |
| superm1 | it will be a shlibdeps for any package built against libvdpau-dev | 08:52 |
| RAOF | 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 |
| tseliot | ah | 08:52 |
| superm1 | the implementation itself doesnt live in libvdpau, no. | 08:53 |
| superm1 | support to "open an implementation" | 08:53 |
| superm1 | so dynamically loading the library is right | 08:53 |
| tseliot | ok | 08:53 |
| tseliot | 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:54 |
| Sarvatt | the hal fdi was adding <match key="info.product" contains_outof="Wacom;WALTOP;WACOM"> <merge key="input.x11_driver" type="string">wacom</merge>, 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 |
| tseliot | superm1: the path to the former is in /etc/ld.so.conf.d | 08:55 |
| tjaalton | Sarvatt: it doesn't use the kernel module | 08:56 |
| superm1 | tseliot, hm. not positive.. | 08:56 |
| superm1 | tseliot, where's the path to the mesa one referenced? | 08:56 |
| superm1 | also ld.so.conf.d? | 08:56 |
| tseliot | superm1: I think our last resort would be to use preload | 08:56 |
| superm1 | tseliot, ugh that's not a good solution to rely on | 08:57 |
| superm1 | because every app would have to do that | 08:57 |
| tseliot | superm1: no, there's no need to specify /usr/lib as it's automatically picked up | 08:57 |
| tjaalton | /lib and /usr/lib are trusted paths, used by default | 08:57 |
| tjaalton | Sarvatt: meaning that the funcionality is limited, but at least pressure sensitivity worked at some point | 08:58 |
| tseliot | tjaalton: right | 08:59 |
| superm1 | tseliot, how does mandriva get around this? | 08:59 |
| superm1 | i would think the priorities would work out identically | 08:59 |
| tseliot | I'm talking to them right now | 08:59 |
| tseliot | yes, they should and the same system seems to work well for them | 09:00 |
| superm1 | are they maybe also using LD_LIBRARY_PATH too? | 09:00 |
| tseliot | that would explain it | 09:01 |
| tseliot | it looks like they don't | 09:02 |
| Sarvatt | 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:02 |
| tjaalton | Sarvatt: haven't tried yet ;) | 09:04 |
| tjaalton | Sarvatt: yes it does | 09:11 |
| tjaalton | id_input adds ID_INPUT_TABLET=1 | 09:12 |
| Sarvatt | 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:15 |
| Sarvatt | and it just matched some extra things that work with it like waltop in the fdi | 09:16 |
| tjaalton | Sarvatt: heh, I need a patch from the wacom list to make it work with inputclass | 09:43 |
| tjaalton | but lunch first | 09:46 |
| Sarvatt | tseliot: if i strace ldconfig it messes with the /usr/lib/nvidia-current stuff before the /usr/lib stuff.. | 09:49 |
| tjaalton | sweet, InputClass & xorg.conf.d works(tm) | 10:22 |
| tjaalton | though it also tries to load drivers for /dev/input/mouse*, which is confusing | 10:25 |
| tjaalton | and wacom loaded too, but doesn't do anything :) | 10:25 |
| tseliot | nice | 10:28 |
| tjaalton | input-events doesn't show any events either | 10:30 |
| jcristau | wacom_drv might grab the device | 10:31 |
| jcristau | so make sure to test from a vt | 10:31 |
| tjaalton | it works for the keyboard though, but I will | 10:31 |
| tjaalton | whoa, it _does_ work from a vt | 10:32 |
| tjaalton | hmm and I think whot is off by now | 10:32 |
| jcristau | evdev doesn't grab so the keyboard is fine, yes | 10:33 |
| jcristau | but synaptics and wacom... | 10:33 |
| tjaalton | hmm ok | 10:33 |
| jcristau | bryyce: i'm not sure counting tseliot as "working on X" is quite accurate, from what i can see he's working on nvidia and fglrx. which isn't quite the same thing. | 10:50 |
| tseliot | jcristau: ??? | 10:50 |
| tseliot | jcristau: this is only my 1st task | 10:51 |
| tseliot | as soon as I'm done with the alternatives system I can spend time on open drivers and X in general | 10:52 |
| jcristau | okay then. we'll see. | 10:53 |
| tjaalton | now you woke up the bear ;) | 10:53 |
| tseliot | jcristau: were you replying to something that bryyce said? I think I'm missing context here | 10:54 |
| jcristau | yes | 10:54 |
| JamieBennett | I'm trying to determine if 3D acceleration is available in X so we can either install a 2D or 3D netbook-launcher interface on ARM devices. What's the best way to determine this? | 10:54 |
| tseliot | glxinfo | grep direct | 10:55 |
| tseliot | (in theory) | 10:55 |
| JamieBennett | why in theory? | 10:57 |
| tseliot | it should work | 10:58 |
| tjaalton | tseliot: yeah I was chatting (ranting) with bryyce about the priorities and upstream contributions :) | 10:58 |
| JamieBennett | OK, I'll do some experimenting, thanks | 10:58 |
| tjaalton | got upset about the nouveau situation, and how it could be better | 10:58 |
| tjaalton | tseliot: btw, is the libglx/libdri change in xserver good to go? | 10:59 |
| tseliot | tjaalton: oh, I see. As soon as I finish this I'll be able to work on the input.d class as promised to upstream. I would also like to help with open (graphics) drivers. We'll see | 10:59 |
| tjaalton | sure | 11:00 |
| tjaalton | and great to hear | 11:00 |
| tseliot | tjaalton: yes, those are fine. The nvidia part is required now | 11:01 |
| jcristau | (glxinfo|grep direct won't tell you whether stuff is accelerated) | 11:06 |
| JamieBennett | jcristau: any other thoughts if thats not it? | 11:08 |
| jcristau | look for the renderer string | 11:08 |
| tseliot | right, only if you have direct rendering | 11:08 |
| JamieBennett | so glxinfo | grep 'renderer string' | 11:09 |
| jcristau | tseliot: which you always have. | 11:09 |
| tseliot | jcristau: not always | 11:09 |
| jcristau | unless you don't have it on purpose, but then you know. | 11:10 |
| tseliot | or your system is partially broken | 11:10 |
| JamieBennett | jcristau, tseliot: Is there anyway of determining this without glxinfo? We don't have that in our live images. | 11:24 |
| tseliot | you can install mesa-utils | 11:24 |
| tseliot | which contains glxinfo | 11:24 |
| tseliot | tjaalton: I think I'll just move libGL.so* to /usr/lib/standard-x11 (as I did for libglx.so and libdri.so) and use alternatives to point to other that or nvidia or whatever we select | 11:59 |
| tseliot | this will make sure that, as it already happens in some linux games (as the Mandriva developer told me), if they dlopen libGL.so.1 directly things will still work | 12:00 |
| tjaalton | tseliot: hrm, so the outcome is that in order to be able to select the GL implementation, we had to change three non-blob packages. and irreversibly, most likely | 12:03 |
| tseliot | tjaalton: x, mesa, libxvmc (even though the 3rd one could be avoided) | 12:04 |
| tseliot | but yes | 12:04 |
| tseliot | :-/ | 12:05 |
| tjaalton | I guess there's no going back, so commit & upload what you need | 12:14 |
| tseliot | right, I'm getting mesa from git as we speak | 12:16 |
| tseliot | tjaalton, jcristau: do we override configs/linux (in mesa) in the debian/rules? | 14:04 |
| tjaalton | tseliot: they are not used since autoconfig | 14:04 |
| tseliot | ok | 14:05 |
| tseliot | tjaalton: I've found out what sets the ".note.ABI-tag" in mesa that breaks things for us | 14:11 |
| tseliot | src/mesa/x86/glapi_x86.S | 14:11 |
| tseliot | generated by src/mesa/glapi/gl_x86_asm.py | 14:12 |
| tseliot | and the other x86_64 script | 14:12 |
| tseliot | the ABI-tag is set if we enable tls | 14:12 |
| tseliot | #if defined(GLX_USE_TLS) && defined(__linux__) | 14:13 |
| tjaalton | why doesn't mandriva enable it? the only reason why fedora doesn't is selinux | 14:14 |
| tjaalton | and that'll change sooner or later | 14:14 |
| tseliot | let's what they say | 14:14 |
| jcristau | what does that supposedly "break"? | 14:15 |
| tseliot | jcristau: well it doesn't really break anything. It simply makes ldconfig believe that the libGL.so.1 in mesa is a completely different library from what other vendors, say nvidia, provide | 14:17 |
| tseliot | libGL.so.1 (libc6, OS ABI: Linux 2.4.20) => /usr/lib/libGL.so.1 | 14:17 |
| tseliot | libGL.so.1 (libc6) => /usr/lib/nvidia-current/libGL.so.1 | 14:17 |
| tseliot | the first one is from mesa | 14:18 |
| tseliot | tjaalton: I've come up with a solution that doesn't suck :-) | 15:27 |
| tseliot | tjaalton: i.e. we simply install libGL.so* to /usr/lib/mesa (or whatever) and the file in ld.so.conf.d/ (that we already use) will make ldconfig look for libGL.so* look in the right place | 15:29 |
| tseliot | (well, it doesn't suck too much) | 15:29 |
| tjaalton | tseliot: ok | 15:42 |
| tseliot | tjaalton: so the diff in mesa will be very small | 15:42 |
| tjaalton | that's good | 15:42 |
| apw | bryyce, hey are we good for alpha-2 to have ATI radeon KMS enabled? | 15:56 |
| tjaalton | it wasn't already? | 15:57 |
| tjaalton | apparently not, I thought it was enabled after alpha1 :) | 16:00 |
| apw | tjaalton, it was an is enabled since just after alpha-1, just making sure 'you' are ok with it remaining so for an annouced released | 16:02 |
| tjaalton | apw: ah, ok | 16:02 |
| Sarvatt | pretty sure its almost guaranteed you're not going to have 3d acceleration on any arm platform, we disable egl and stuff in mesa | 16:16 |
| tjaalton | hm? | 16:17 |
| BUGabundo_work | hi | 16:33 |
| BUGabundo_work | bug 504149 | 16:33 |
| ubottu | Launchpad bug 504149 in xorg "[lucid] after update keyboard and mouse do not work in X" [Low,Won't fix] https://launchpad.net/bugs/504149 | 16:34 |
| BUGabundo_work | if anyone cares to take a look, and help me save my (and probably many other Lucid user) systems | 16:34 |
| tjaalton | why? | 16:34 |
| BUGabundo_work | tseliot: ^^^^^^^ | 16:34 |
| tjaalton | your logs indicate that hal is working normally, so what's wrong? | 16:36 |
| BUGabundo_work | tjaalton: no mouse or keyboard in my system | 16:37 |
| BUGabundo_work | after upgrades from two days ago | 16:37 |
| BUGabundo_work | and yesterday reboot | 16:37 |
| BUGabundo_work | touchpad works, actually | 16:37 |
| tjaalton | ok, probably due to the faster boot work | 16:37 |
| BUGabundo_work | if i stop GDM i can use keyb in TTY | 16:38 |
| tjaalton | so, pretty please, dist-upgrade and be done with it | 16:38 |
| BUGabundo_work | cant! | 16:38 |
| BUGabundo_work | it forces the removal of nvidia driver and kernel | 16:38 |
| tjaalton | surely you can live without nvidia for a few days? | 16:38 |
| BUGabundo_work | days? | 16:38 |
| tjaalton | kernel? no it doesn't | 16:38 |
| BUGabundo_work | been like that for 1 month | 16:38 |
| tjaalton | yeah, and you updated anyway? | 16:38 |
| BUGabundo_work | no | 16:38 |
| BUGabundo_work | i never dist-upgrade when _important_ packages are touched | 16:39 |
| tjaalton | hehehe | 16:39 |
| BUGabundo_work | aptitude safe-upgrade only | 16:39 |
| tjaalton | so expect breakage | 16:39 |
| BUGabundo_work | i do | 16:39 |
| BUGabundo_work | but not being locked out of my own system | 16:39 |
| tjaalton | dist-upgrade ftw | 16:40 |
| BUGabundo_work | i wouldnt been running +1 for 3 years not expecting breakage | 16:40 |
| BUGabundo_work | very funny | 16:40 |
| tjaalton | yes it is | 16:40 |
| BUGabundo_work | how about packaging proper matching X with close source drivers ? | 16:40 |
| tjaalton | I don't understand what you are asking on that bug | 16:40 |
| tjaalton | hehe | 16:40 |
| BUGabundo_work | that would be funny too | 16:40 |
| BUGabundo_work | :\ | 16:40 |
| tjaalton | yes, I'm laughing | 16:40 |
| BUGabundo_work | oh i bet | 16:41 |
| BUGabundo_work | i'm laughting too... for not being and ATI user | 16:41 |
| tjaalton | bug 494166 | 16:41 |
| BUGabundo_work | ohh wait... i'm too.. debian unstalbe at work | 16:41 |
| ubottu | Launchpad bug 494166 in nvidia-graphics-drivers-96 "[lucid] nvidia-glx can't work with new xorg 7.5" [Medium,In progress] https://launchpad.net/bugs/494166 | 16:41 |
| * BUGabundo_work subs | 16:41 | |
| BUGabundo_work | tjaalton: can u assure me the return of my input devices after dist upgrade, and provide a proper downgrade route, in case that fails ? | 16:43 |
| tjaalton | the downgrade path is to install karmic | 16:43 |
| BUGabundo_work | ahah | 16:43 |
| tjaalton | if you desperately need the nvidia | 16:43 |
| BUGabundo_work | do that to all your testers | 16:43 |
| BUGabundo_work | and be left with a borked final system | 16:43 |
| tjaalton | eh? | 16:43 |
| BUGabundo_work | no, i dont want nvidia that bad | 16:44 |
| BUGabundo_work | i want my mouse and keyb.... *that bad* | 16:44 |
| tjaalton | yes, I bet it works | 16:44 |
| BUGabundo_work | 100$ and u are on | 16:44 |
| BUGabundo_work | i need to pay my new WD | 16:44 |
| BUGabundo_work | u can start helping | 16:44 |
| tjaalton | since this is the first bug about this.. | 16:44 |
| tjaalton | and I need a wacom :) | 16:44 |
| BUGabundo_work | well, second | 16:44 |
| BUGabundo_work | i subbed to that bug | 16:44 |
| tjaalton | just because you didn't dist-upgrade | 16:45 |
| BUGabundo_work | well... dont break X and ask for the removel of N packages including a kernel image | 16:46 |
| tjaalton | what kernel image?? | 16:46 |
| tjaalton | there's a reason for the video abi conflicts you know | 16:46 |
| BUGabundo_work | cant say out of my head | 16:46 |
| tjaalton | since your nvidia wouldn't work with 1.7 | 16:46 |
| BUGabundo_work | i know | 16:46 |
| BUGabundo_work | new X | 16:46 |
| BUGabundo_work | i know and i understand | 16:46 |
| tjaalton | then why do you complain? | 16:47 |
| BUGabundo_work | hence the reason i didnt dist-upgrade | 16:47 |
| BUGabundo_work | tjaalton: cause it broke my input methods | 16:47 |
| tjaalton | no, that's the plumbing | 16:47 |
| tjaalton | and we went to udev input handling before alpha1, so hal was never tested nor meant to be used | 16:48 |
| BUGabundo_work | i know | 16:49 |
| BUGabundo_work | it wasnt there!! | 16:49 |
| jcristau | actually it's expected to break, the fdi enabling X i-h was removed from hal | 16:49 |
| BUGabundo_work | that's the secondary bug | 16:49 |
| BUGabundo_work | seems it was pulled again into my system | 16:49 |
| bjsnider | hal was? | 16:51 |
| tjaalton | jcristau: oh right, so no way hal can work | 16:51 |
| tjaalton | hmm no, running the old version it should | 16:51 |
| tjaalton | jcristau: damn, didn't read it well enough :) | 16:52 |
| jcristau | tjaalton: might be a good idea to have the new hal Break old xserver-xorg-core just to make sure? | 16:52 |
| tjaalton | jcristau: yes, why not | 16:52 |
| tjaalton | jcristau: pushed 1.7.4 | 16:54 |
| jcristau | ok | 16:55 |
| tjaalton | bjsnider: hal is needed on some laptops for gnome-power-manager. it will be modified to run only when needed | 16:55 |
| bjsnider | oh, cool | 16:55 |
| bjsnider | that kind of sucks though, doesn't it? it has to be installed by everybody ony for that one small use-case | 16:56 |
| tjaalton | yes | 16:56 |
| tjaalton | :) | 16:56 |
| bjsnider | gnome-power-manager needs to be slapped around a bit | 16:57 |
| tjaalton | BUGabundo_work: so, the way to make hal work again is to go back to the version on karmic | 16:57 |
| tjaalton | bjsnider: yeah I think it'll get fixed sooner or later, but not necessarily for lucid | 16:57 |
| tjaalton | heh, "All the X drivers need to support XBACKLIGHT before we can turn it off completely" | 16:58 |
| tjaalton | https://wiki.ubuntu.com/Halsectomy | 16:58 |
| jcristau | why the shouting? | 16:58 |
| jcristau | :) | 16:58 |
| tjaalton | <g> | 16:59 |
| BUGabundo_work | so either downgrade hal, or distupgrade, lose nvidia, what get my self into what hell, until nvidia release 1.7 compatible driver | 17:03 |
| BUGabundo_work | ok... at least i have a choise | 17:04 |
| bjsnider | does the blob not work with the new x server? | 17:04 |
| bjsnider | everybody who's emailed me about it says it does | 17:05 |
| tjaalton | bjsnider: which version? | 17:07 |
| tjaalton | BUGabundo_work: there is a compatible one available, it's just not packaged yet | 17:07 |
| tjaalton | but soon | 17:07 |
| bjsnider | 185/190/195 | 17:07 |
| tjaalton | 190 is on tseliot's ppa | 17:07 |
| bjsnider | i packaged all 3 for lucid at one point until yesterday and everybody reported to me that they worked | 17:08 |
| tjaalton | oh, the old packaging | 17:08 |
| tjaalton | sure | 17:08 |
| bjsnider | right, the old packaging | 17:08 |
| tjaalton | anyway, gotta go | 17:08 |
| kaloss | buenas | 17:09 |
| kaloss | mi tarjtea grafica | 17:09 |
| kaloss | no acepta los afectos visuales | 17:09 |
| jcristau | in english please | 17:10 |
| bjsnider | i think he's saying he can't enable visual effects | 17:10 |
| tseliot | kaloss: puede depender de varios motivos pero tienes que hablar inglés | 17:10 |
| jcristau | i got that much :) | 17:10 |
| kaloss | yes | 17:10 |
| kaloss | my efeccts visual | 17:10 |
| kaloss | my moptherboard pc chips 955 integrated | 17:11 |
| kaloss | :o | 17:11 |
| tseliot | kaloss: did you file about report about it? | 17:12 |
| kaloss | seen here----> http://paste.ubuntu.com/353541/ | 17:15 |
| tseliot | heck | 17:21 |
| tseliot | I meant to say, did you file a bug report about it? | 17:21 |
| tseliot | kaloss: no, unfortunately you won't get 3D effects with a VIA card | 17:22 |
| jcristau | ugh via | 17:22 |
| jcristau | tough luck. | 17:22 |
| * tseliot nods | 17:22 | |
| jcristau | almost as bad as poulsbo ;) | 17:23 |
| tseliot | now you're reading my mind... | 17:23 |
| bjsnider | i thought via had opened everything up and hired a couple of the openchrome guys? | 17:26 |
| tseliot | no, 3D is still proprietary | 17:26 |
| jcristau | i very much doubt "everything" | 17:26 |
| bjsnider | aren't they developing a gallium driver? | 17:27 |
| tseliot | had they opened everything, things would have been in much better shape now | 17:27 |
| tseliot | but even with gallium you can keep it closed | 17:28 |
| tseliot | :-/ | 17:28 |
| bjsnider | well, they're definitely better than they used to be | 17:28 |
| bjsnider | which isn't saying much, because there was no place to go but up for them | 17:29 |
| tseliot | :-) | 17:29 |
| tseliot | tjaalton: I'm rebuilding mesa locally now. If it works, I'll push my changes for X and Mesa to git and we can start uploading things | 17:33 |
| tseliot | i.e. patch for X: http://pastebin.ubuntu.com/353554/ | 17:38 |
| tseliot | patch for mesa: http://pastebin.ubuntu.com/353556/ | 17:38 |
| tseliot | tjaalton: ok, pushed to git | 17:59 |
| tseliot | why shall I use debuild -I".git" -S -sa -v$previousUbuntuVersion ? | 18:01 |
| tseliot | the -v part | 18:01 |
| jcristau | see dpkg-genchanges(1) | 18:05 |
| tseliot | jcristau: aah, ok, it makes sense now | 18:06 |
| tseliot | but still -sa shouldn't be required unless is a new upstream release | 18:10 |
| tseliot | -S should be enough | 18:11 |
| bjsnider | -Sd | 18:11 |
| bjsnider | or -S -sd | 18:12 |
| bjsnider | i thought | 18:12 |
| tseliot | -sd Forces the exclusion of the original source and includes only the diff. | 18:13 |
| tseliot | -S Specifies that only the source should be uploaded (no binary packages will be included). | 18:13 |
| bjsnider | right, so if i'm just changing the build scripts that's what i do | 18:15 |
| tseliot | either of them should be ok in this case | 18:16 |
| bjsnider | and the ppa build system and my rig both have the same orig tarball, so that's why it wor,s | 18:16 |
| * tseliot -> dinner (brb) | 18:19 | |
| Sarvatt | jcristau: dunno if you saw but the remove render reclock commit went to stable, definitely still needs powersave=0 on top of that here though, i'm still getting flickering after resume without it. still dont understand why powersave=0 doesnt fix it without that commit as well though | 18:44 |
| jcristau | Sarvatt: okay. i think i'll get the debian kernel people to set powersave to 0 by default and call it quits... thanks for the heads up | 18:45 |
| Sarvatt | you install a /etc/modprobe.d/intel-kms.conf with the driver, why not just throw it in there? | 18:46 |
| Sarvatt | err i915-kms.conf | 18:47 |
| jcristau | because it's safe to do in the kernel | 18:47 |
| jcristau | and if it's going to be temporary it's better done there | 18:47 |
| Sarvatt | true, it breaks <.32 adding it in the modprobe.d/i915-kms.conf | 18:48 |
| Sarvatt | i915 doesnt load because of the invalid parameter on 2.6.31 when i add it in there | 18:48 |
| jcristau | assuming the intel people get their stuff working in .33 i'd rather not have to clean things up when we bump the kernel | 18:48 |
| Sarvatt | i'm glad linus seems to not care about feature freezes for intel and pulls drm-intel-next whenever its ready :D | 18:53 |
| Sarvatt | ok i guess its time to drop xserver from xorg-edgers, going to have to put a big warning for people to revert those packages manually at the top and hope people read it :D | 18:53 |
| Sarvatt | if I delete it ppa-purge wont revert it though, ugh | 18:55 |
| Sarvatt | tjaalton: seems like we could hack together a wacom package that only works for usb devices now doesn't it? I wish thjaeger came on irc, looks like he's working on extending it to work for serial devices using tty instead of just input | 19:01 |
| Sarvatt | http://sourceforge.net/mailarchive/forum.php?thread_name=4B42A1BB.6060706%40gmail.com&forum_name=linuxwacom-devel | 19:01 |
| Sarvatt | he's sent me patches that do work for the old 0.8.x wacom packages under input abi 7 but that only works with hal | 19:02 |
| Sarvatt | i'm an idiot when it comes to udev so I can't figure out why the old udev (non-xorg one) doesn't work but my one that just creates the input/wacom symlink does | 19:04 |
| Sarvatt | old udev rules file I mean | 19:04 |
| bryyce | apw, yep +1 from me | 19:09 |
| === vish is now known as mac_v | ||
| === mac_v is now known as vish | ||
| tseliot | bryyce, tjaalton: I have uploaded my changes to X and Mesa. I'll upload libxvmc now | 19:11 |
| thopiekar-t91 | hi | 19:14 |
| thopiekar-t91 | is there a site on the net that provides new poulsbo drivers | 19:15 |
| thopiekar-t91 | ? | 19:15 |
| thopiekar-t91 | I copied fails builds from other repos to my and made them work on my ppa:thopiekar/poulsbo | 19:17 |
| thopiekar-t91 | http://launchpad.net/~thopiekar/+archive/poulsbo | 19:17 |
| tseliot | thopiekar-t91: we don't support poulsbo any more | 19:18 |
| thopiekar-t91 | is there a alternative.. | 19:18 |
| jcristau | vesa.. | 19:18 |
| tseliot | but you will find some unofficial repositories on ubuntuforums.org | 19:18 |
| thopiekar-t91 | can you at least help me to get it work.. | 19:18 |
| tseliot | use them at your own risk though | 19:18 |
| thopiekar-t91 | tseliot: the howtos there are using ubuntu mobiles jaunty ppa but I want to push them to karmic | 19:19 |
| thopiekar-t91 | jcristau: I think I'm using atm vesa .. it's really eating my battery's energy :/ | 19:20 |
| tseliot | thopiekar-t91: http://swiss.ubuntuforums.org/showthread.php?t=1253406 | 19:20 |
| tseliot | feel free to push whatever you like in your ppa | 19:20 |
| thopiekar-t91 | yes but these packages doesn't work.. ok I will work on it, thank you anyway.. | 19:22 |
| bryyce | tseliot, with those changes, what's next on the todo for the alternatives stuff? | 19:23 |
| tseliot | bryyce: the 3 nvidia flavours (which I'm ready to upload) | 19:24 |
| tseliot | then I would like to upload screen-resolution-extra, nvidia-common, nvidia-settings and (when pitti is online) the new jockey | 19:24 |
| * bryyce nods | 19:25 | |
| tseliot | bryyce: screen-resolution-extra is used by nvidia-settings to use policykit | 19:25 |
| tseliot | i.e. no more sudo with nvidia-settings | 19:25 |
| tseliot | bryyce: I think I'll make some additional changes to the alternatives system but this will be after alpha 2 | 19:26 |
| Sarvatt | this whole setup breaks being able to use drivers directly from nvidia doesn't it? | 19:27 |
| tseliot | Sarvatt: if nvidia-common is installed, the nvidia-installer will stop | 19:27 |
| bryyce | Sarvatt, IIUI you would need to uninstall the ubuntu driver, then you could install from upstream | 19:27 |
| Sarvatt | ah I purge nvidia* when I use the nvidia drivers | 19:27 |
| tseliot | but yes, the nvidia-installer, even if successful won't work because of the ld.so.conf.d stuff | 19:28 |
| Sarvatt | just thought the shuffling of libs might screw it up somehow | 19:28 |
| tseliot | and I'll fix this | 19:28 |
| tseliot | I was talking to the Mandriva guys about it today | 19:28 |
| tseliot | we can cooperate on this | 19:29 |
| tseliot | (as we use the same system) | 19:29 |
| bryyce | nice | 19:29 |
| tseliot | :-) | 19:29 |
| Sarvatt | alot of people are using the upstream driver because the distro ones dont work right now (me included) so it might warrant a release note for alpha 2 on how it that doesn't work at the moment | 19:31 |
| Sarvatt | is what I was thinking | 19:31 |
| tseliot | Sarvatt: it's a good idea | 19:31 |
| bjsnider | i think that the 195 driver should be used instead of the 190 for lucid | 19:32 |
| tseliot | bjsnider: sure, as soon as it's released as stable | 19:32 |
| Sarvatt | 195 will probably be the stable release any time now I'd bet | 19:32 |
| Sarvatt | super easy to update with all this work now at least :D | 19:32 |
| * tseliot nods | 19:32 | |
| bjsnider | tseliot, yes but lucid isn't stable so why do you have to package a stable nvidia driver? | 19:32 |
| bjsnider | Sarvatt, not super easy. the 195 contains 6 new files that have to be packaged | 19:33 |
| tseliot | bjsnider: what if nvidia doesn't release it as stable in time for Lucid's release? | 19:33 |
| bjsnider | they will. no question | 19:33 |
| tseliot | in general, this is my approach, especially with things that I can't fix | 19:34 |
| Sarvatt | actually, 190.53 isn't even a stable release yet is it? | 19:34 |
| tseliot | namely proprietary stuff | 19:34 |
| tseliot | yes, it was promoted to stable | 19:34 |
| tseliot | recently | 19:34 |
| bjsnider | tseliot, i just figure, what with those new files, why not put them into the build scripts now while you're working on them as opposed to having to jump back into them knee-deep in a month? | 19:34 |
| Sarvatt | ah indeed it is | 19:35 |
| bjsnider | plus kde users should be using the 195 since it accelerates xrender for the first time | 19:35 |
| tseliot | bjsnider: I can put 195 in a PPA and experiment there | 19:35 |
| bjsnider | cool | 19:36 |
| bjsnider | there are two shared libs that will have to be execstacked and linked | 19:36 |
| bjsnider | and a file that goes in /etc | 19:36 |
| bjsnider | 3 opencl headers | 19:37 |
| tseliot | now we have this deadline that is alpha 2 and I have to make sure that things work in time for alpha 2, then I can think of the rest | 19:37 |
| tseliot | ah, good to know | 19:37 |
| bjsnider | i just figured it would be easier on you to do this work while the build scripts are all in your mind as opposed to leaving it for a month and then having to pick it all up again | 19:38 |
| Sarvatt | are the headers in a standard place? picked up by the current install globs? | 19:38 |
| bjsnider | no | 19:38 |
| bjsnider | they are in /usr/lib/CL | 19:38 |
| bjsnider | i don't think the installer would pick them up | 19:38 |
| bjsnider | i think the installer would pick up /usr/lib/libnvidia-compiler.so.195.xx | 19:39 |
| bjsnider | but it would have to be linked in the .links file | 19:39 |
| bjsnider | the windows driver is already at 195, and the linux team likes to stay current with that, so they'll be switching as soon as they get the major bugs out of the 195 | 19:41 |
| Sarvatt | great, nvidia-current-cl nvidia-current-cl-dev packages then..? is there any generic libcl it hooks into? | 19:42 |
| tseliot | wait, what? | 19:42 |
| bjsnider | i thought we didn't want to split anything off | 19:42 |
| tseliot | one will end up in nvidia-current, the rest in nvidia-current-dev I guess | 19:43 |
| bjsnider | the two libs would be in nvidia-current, the 3 headers in the dev package | 19:43 |
| bryyce | Sarvatt, are we considering that libdrm execbuf bug solved with latest mesa/libdrm? I see the bug report is still open upstream | 19:43 |
| bjsnider | and then there's an /etc file | 19:44 |
| tseliot | bjsnider: what's in /etc ? | 19:44 |
| Sarvatt | bryyce: I still have the problem with an updated intel ddx but not with 2.9.1 | 19:44 |
| Sarvatt | but no problem with libdrm/mesa updates without updating the ddx | 19:44 |
| bryyce | Sarvatt, weird okay, so as long as we don't upgrade -intel we can go ahead with upgrading libdrm/mesa? | 19:45 |
| soren | I've been messing around with my drivers lately (part manually, part from tseliot's restricted-blah-blah ppa, and part ubuntu repositories), and finally the nv driver is working for me, but DRI does not seem to be working. Is this expected, or did I mess something up along the way? (Using the "nv" driver, by the way) | 19:46 |
| bjsnider | tseliot, /etc/OpenCL/vendors/nvidia.icd -- it contains this: libcuda.so | 19:46 |
| bryyce | tjaalton, ^ is uploading the new libdrm/mesa on your todo list? If not, should I give it a go? Would be nice to have done for a2 | 19:46 |
| Sarvatt | I'm really confident enough to say yes to that after 4 days testing, libdrm 2.4.16 alone had a crashing problem that must have been been fixed in 2.4.17 (there were a few intel bug fixes) | 19:46 |
| tseliot | soren: what did you take from my PPA? | 19:47 |
| soren | tseliot: Let's put it this way: It's in my sources.list, and apt says I'm all up-to-date. | 19:47 |
| tseliot | bjsnider: hmm... I'll ask nvidia about it | 19:47 |
| bjsnider | soren, glx isn't working? | 19:47 |
| bjsnider | good idea | 19:48 |
| soren | bjsnider: Well... 5 minutes ago, glxinfo just gave some error (sorry, I forget the exact error), which was caused by libdri.so was pointing to the nvidia-current one. | 19:48 |
| tseliot | soren: /var/log/Xorg.0.log ? and the output of update-alternatives --display gl_conf please | 19:48 |
| soren | bjsnider: Now, I do get some useful output, but "direct rendering: No (LIBGL_ALWAYS_INDIRECT set) | 19:49 |
| soren | " | 19:49 |
| soren | tseliot: gl_conf? What's that? | 19:49 |
| Sarvatt | the bug was so severe before i never had over 24 hours uptime with the newer ddx, 4 days *trying* to crash it by repeatedly loading a folder with hundreds of videos and letting it make thumbnails and deleting those thumbnails and repeating when I couldnt last 2 rounds of that before seems like its fine to me | 19:49 |
| tseliot | soren: the master link | 19:49 |
| soren | Ah, I see. | 19:49 |
| bryyce | Sarvatt, ok good to hear | 19:49 |
| bryyce | Sarvatt, happen to know if updating libdrm/mesa is on tjaalton's todo list for a2? | 19:50 |
| soren | tseliot: Hahah, that's pointing at /usr/lib/nvidia-current/ld.so.conf | 19:50 |
| tseliot | soren: type: sudo update-alternatives --set gl_conf /usr/lib/standard-x11/ld.so.conf and then do an ldconfig | 19:50 |
| soren | tseliot: As I said: "part manual fiddling" :) | 19:50 |
| tseliot | always with sudo | 19:50 |
| soren | tseliot: Sure, sure. | 19:50 |
| tseliot | soren: when all is in place jockey will deal with that | 19:50 |
| Sarvatt | I have no idea :( seems like he wanted to push it ASAP though and the libdrm is blocking alot of other possible updates | 19:51 |
| Sarvatt | but I think he wanted to adjust libdrm so it replaces headers again which intel 2.10 needs to build | 19:51 |
| soren | tseliot: That did not do the trick. I'll pastebin my xorg.0.log. | 19:52 |
| bryyce | ah right | 19:52 |
| jcristau | soren: if you still have LIBGL_ALWAYS_INDIRECT set, unset it? | 19:52 |
| soren | http://pastebin.com/fbb2dba5 | 19:53 |
| soren | jcristau: Um... I didn't set anything. Is it an environment variable? | 19:53 |
| bryyce | Sarvatt, ok I'll touch base with him when he's around but won't pick at it myself for now | 19:53 |
| jcristau | yes | 19:53 |
| bjsnider | wow, the nvidia driver package for windows is 105 MB | 19:53 |
| soren | jcristau: Oh, wow. It is an environment variable. Where the heck did that come from? | 19:53 |
| tseliot | soren: BTW nvidia doesn't provide libdri.so. Even if you select nvidia you will use libdri.so from X11 | 19:54 |
| Sarvatt | JamieBenett: I'm almost positive you arent going to get accelerated GL on any arm platform in ubuntu right now, they all have proprietary graphics accelerators that would need to interface their opengl ES implementations with egl for acceleration as far as I know | 19:54 |
| soren | tseliot: I didn't say all my manual fiddling was sane :) | 19:54 |
| tseliot | heh | 19:54 |
| soren | Um... What would set LIBGL_ALWAYS_INDIRECT ? | 19:55 |
| jcristau | something that's trying to run compiz? | 19:55 |
| Sarvatt | any we dont even build mesa with egl support (not that I know that would work with things) | 19:55 |
| Sarvatt | i think mythtv sets it too? could be really mistaken there | 19:56 |
| jcristau | i'm not ruling out any mythtv stupidity | 19:57 |
| Sarvatt | arm 3D acceleration on linux is worse than paulsboro, most use powervr too :( | 19:58 |
| soren | jcristau: Ok, if I unset LIBGL_ALWAYS_INDIRECT, glxinfo says "direct rendering: Yes". | 19:58 |
| jcristau | (not that "direct rendering: Yes" means anything) | 19:58 |
| jcristau | (in terms of gl acceleration, that is) | 19:58 |
| Sarvatt | i think if you can get a kernel blob interface up you might be able to get it working with gallium though | 19:59 |
| soren | jcristau: I'm learning a lot today. How can I tell whether it's software rendering or not? | 19:59 |
| soren | Hahah: OpenGL renderer string: Software Rasterizer | 19:59 |
| tseliot | yes, if glx is broken usually you get only errors from glxinfo | 19:59 |
| jcristau | soren: right, that. | 19:59 |
| soren | jcristau: So what makes the difference here? What provides the drivers for hardware accelerated glx (is that the right terminology)? | 20:01 |
| soren | Is that mesa? | 20:02 |
| bryyce | soren, yes, for most of the open source drivers | 20:03 |
| soren | Fascinating :) | 20:04 |
| bryyce | with nv, the developers seem to prefer that users needing gl use -nvidia instead | 20:05 |
| bryyce | so gl support for -nv is fairly behind the times | 20:06 |
| soren | So when my memory is trying to convince me that I used to have compiz running with nv, it's lying? | 20:06 |
| tseliot | you can still use compositing with xrender | 20:06 |
| tseliot | with nv | 20:07 |
| tseliot | I think I did that with KDE 4 once | 20:07 |
| hyperair | huh? you can? | 20:07 |
| hyperair | O_O | 20:07 |
| tseliot | openGL is much better | 20:07 |
| hyperair | hmm | 20:07 |
| soren | Oh, well. | 20:08 |
| tseliot | you can try that with a Kubuntu live image | 20:08 |
| tseliot | note: I'm not suggesting that you do it ;) | 20:08 |
| soren | I suppose I'll try to get nvidia working instead. | 20:09 |
| tseliot | soren: with my PPA + the new xserver and mesa that will soon arrive directly in Lucid, 3D acceleration should work | 20:10 |
| soren | tseliot: update-alternatives --set /usr/lib/nvidia-current/ld.so.conf gl_conf, and then s/nv/nvidia/ in xorg.conf, and I should be golden? | 20:11 |
| soren | tseliot: You mean for nvidia or nv? | 20:11 |
| tseliot | soren: "update-alternatives --set gl_conf /usr/lib/nvidia-current/ld.so.conf" and yes, I was referring to nvidia :-) | 20:11 |
| soren | tseliot: Uh, right, sure, that's what I meant (the update-alternatives thing). :) | 20:12 |
| * soren is lying. | 20:12 | |
| soren | I'm actually using --config | 20:12 |
| tseliot | :-D | 20:12 |
| tseliot | that's easier | 20:12 |
| soren | lots | 20:12 |
| * soren takes this config for a spin | 20:12 | |
| soren | tseliot: I get a bunch of "Xlib: extension "GLX" missing on display ":0.0".", when I run glxinfo now. Xorg.0.log says: | 20:14 |
| soren | [ 0.034084] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so | 20:14 |
| soren | dlopen: libGLcore.so.1: cannot open shared object file: No such file or directory | 20:15 |
| tseliot | soren: did you do ldconfig and do you have my new x and mesa? | 20:15 |
| soren | Everything is up-to-date, but I forgot ldconfig. | 20:17 |
| * soren tries | 20:17 | |
| tseliot | soren: are the new mesa and X already in lucid??? | 20:18 |
| soren | tseliot: No clue. | 20:18 |
| soren | tseliot: Probably not, since you ask that way. | 20:18 |
| soren | I was trying to answer your question :) | 20:19 |
| soren | apt does not want to install any updates, so I've got whatever's freshest in the archive and/or your ppa. | 20:19 |
| tseliot | https://launchpad.net/ubuntu/+source/xorg-server/2:1.7.3.902-1ubuntu2/+build/1436731 | 20:19 |
| tseliot | https://launchpad.net/ubuntu/+source/mesa/7.6.1~rc3-1ubuntu2/+build/1436737 | 20:19 |
| tseliot | and the answer seems to be no ;) | 20:20 |
| * soren waits another three hours then :) | 20:21 | |
| soren | tseliot: I'll stop bothering you now. :) | 20:23 |
| tseliot | soren: no problem, I'll spend the night waiting for the packages to build ;) | 20:24 |
| tjaalton | bryyce: yes, those are ready | 20:41 |
| tjaalton | we can munge the headers after a2, if needed | 20:41 |
| bryyce | tjaalton, sounds good | 20:44 |
| bryyce | tjaalton, ok do libdrm and mesa need anything before they get uploaded, or are they want to go now? | 20:45 |
| tjaalton | bryyce: mesa needs to be merged with tseliot's latest change, nothing else | 20:45 |
| tjaalton | I've got local 'ubuntu-test' branches for both | 20:46 |
| tjaalton | wonder if they would be useful on git.d.o | 20:46 |
| tjaalton | for future work | 20:46 |
| tseliot | another mesa? | 20:46 |
| tjaalton | 7.7 :) | 20:46 |
| tseliot | nice | 20:46 |
| bryyce | ok | 20:49 |
| bryyce | I'll work on some of the other merges | 20:49 |
| tjaalton | bryyce: btw, the versions_current lists -amd and -via, both of which are dupes (-geode, -openchrome). those could be filtered out | 21:00 |
| bryyce | tjaalton, ok; added to my todo list | 21:03 |
| tjaalton | bryyce: thanks | 21:03 |
| knittl | hi, i need help with xorg graphics drivers :D | 21:09 |
| knittl | everytime i boot i get an error message about ubuntu running in low graphics mode | 21:10 |
| knittl | exiting to console and starting gdm works fine though | 21:10 |
| tjaalton | so gdm didn't start the first time | 21:10 |
| knittl | i get the message with nvidia drivers from tseliot's ppa, with and without xorg.conf and even with drivers apt-get purged | 21:11 |
| knittl | tjaalton: probably | 21:11 |
| tjaalton | there's some race condition with the booting process on lucid | 21:11 |
| tjaalton | it's not a driver bug though | 21:11 |
| knittl | ok, so this is a known issue? | 21:11 |
| tjaalton | at least to me, since I get it all the time | 21:11 |
| knittl | ok :) | 21:11 |
| tjaalton | the Xorg.0.log was not updated, neither were the gdm logfiles.. so those would suggest that gdm didn't start at all | 21:12 |
| tjaalton | but failsafe did | 21:12 |
| tjaalton | and since upstart doesn't log boot msgs... | 21:12 |
| knittl | i just tried to reinstall nvidia-current via jockey, but this time i got an error message | 21:13 |
| ScislaC | So... haven't asked in a couple weeks and feel it's due. Any chance that we'll get wacom input drivers again in lucid anytime soon? :) | 21:13 |
| bryyce | ScislaC, nope | 21:13 |
| ScislaC | bryyce: Oh well... I'll just keep holding off on updating. I just feel like I don't help much with testing when I'm not up to date. | 21:14 |
| BUGabundo | evening | 21:14 |
| tjaalton | we might get something for some ppa though | 21:14 |
| BUGabundo | following tjaalton advice i dist upgraded | 21:15 |
| BUGabundo | now my lucid is in low grafics mode | 21:15 |
| tjaalton | but not in the archive until the debian maintainer is ok with it | 21:15 |
| BUGabundo | but at least mouse and keyb work :\ | 21:15 |
| knittl | hi BUGabundo :D | 21:16 |
| BUGabundo | hey knittl | 21:17 |
| BUGabundo | guys any nvidia or nv driver i can use to get proper resulotion ? | 21:17 |
| knittl | BUGabundo: just exit to console and type sudo service gdm start | 21:17 |
| knittl | i've had the problem for some time now | 21:17 |
| tjaalton | BUGabundo: nv doesn't work? | 21:18 |
| tjaalton | logfile hen | 21:18 |
| tjaalton | then | 21:18 |
| BUGabundo | can i install the one in PPA? | 21:18 |
| BUGabundo | if so, why isnt it in archive? | 21:18 |
| BUGabundo | tjaalton: havent tested NV. thats why i'm asking | 21:18 |
| BUGabundo | install nvidia vdpau PPA | 21:30 |
| BUGabundo | removed my xserver-xorg | 21:30 |
| tjaalton | no you should have -nv installed. if not, install xserver-xorg-video-all | 21:31 |
| BUGabundo | let me se | 21:32 |
| BUGabundo | tjaalton: no. -video.all is not here | 21:32 |
| BUGabundo | so how do u purpose i fix the blog? | 21:32 |
| BUGabundo | Pblob | 21:32 |
| BUGabundo | installing X takes nvidia (even from PPA) | 21:33 |
| tjaalton | use tseliot's ppa | 21:35 |
| BUGabundo | why aint that stuff in x-edger PPA or archive yet? | 21:35 |
| tjaalton | because it isn't ready | 21:36 |
| tjaalton | or wasn't | 21:36 |
| BUGabundo | tjaalton: link please? | 21:37 |
| BUGabundo | found it | 21:37 |
| BUGabundo | err | 21:38 |
| BUGabundo | tseliot ppa only has up to karmic | 21:38 |
| BUGabundo | no lucid package | 21:38 |
| tjaalton | look closed | 21:38 |
| tjaalton | closer | 21:38 |
| tjaalton | there are many ppa's | 21:38 |
| * BUGabundo blames google | 21:39 | |
| BUGabundo | x-testing ? | 21:39 |
| tjaalton | no | 21:40 |
| BUGabundo | saw it | 21:40 |
| BUGabundo | prop.impor | 21:40 |
| BUGabundo | ok. package list update . now what? install blob? | 21:41 |
| tjaalton | i guess | 21:41 |
| BUGabundo | tjaalton: which one? | 21:41 |
| BUGabundo | i dont see a 185 / 190 / 195 | 21:41 |
| tjaalton | you also need the latest mesa/xserver from the main archive | 21:41 |
| tjaalton | -current | 21:42 |
| BUGabundo | tjaalton: which package name, please? | 21:42 |
| tjaalton | nvidia-current | 21:42 |
| tjaalton | please, not too hard to look at the ppa | 21:42 |
| BUGabundo | no such thing in my apt db | 21:43 |
| BUGabundo | nor is nvidia-current in that ppa | 21:43 |
| tjaalton | sure is | 21:43 |
| tjaalton | rest is left as an excercise | 21:43 |
| tjaalton | -> | 21:43 |
| BUGabundo | i'm sorry | 21:44 |
| BUGabundo | i dont see it | 21:44 |
| BUGabundo | nor can i find it with aptitude | 21:44 |
| BUGabundo | i see nvidia-common | 21:44 |
| BUGabundo | and | 21:44 |
| BUGabundo | nvidia-graphics | 21:44 |
| bjsnider | tjaalton, nvidia-current is not in alberto's ppa. it is call nvidia-graphics-drivers | 21:46 |
| BUGabundo | barf | 21:46 |
| tjaalton | then what's this: https://edge.launchpad.net/~albertomilone/+archive/proprietary-video-improvements/+files/nvidia-current_190.53-0ubuntu1~proprietaryppa22_amd64.deb | 21:47 |
| BUGabundo | no idea | 21:48 |
| BUGabundo | need a screenshot of https://launchpad.net/~albertomilone/+archive/proprietary-video-improvements/+packages ? | 21:48 |
| BUGabundo | cause its not there | 21:48 |
| tjaalton | what about "view package details"? | 21:48 |
| bjsnider | tjaalton, that is created from the nvidia-graphics-drivers package | 21:48 |
| tjaalton | bjsnider: yes, I thought he was looking for the binary package | 21:48 |
| tjaalton | apt should find it anyway, after an apt-get update.. | 21:49 |
| BUGabundo | did that | 21:49 |
| BUGabundo | nothing | 21:49 |
| BUGabundo | prob didnt build for 64bits | 21:50 |
| tjaalton | both are there | 21:50 |
| BUGabundo | grrr | 21:50 |
| BUGabundo | rebooting | 21:50 |
| BUGabundo | and trying again | 21:50 |
| tjaalton | that won't help apt | 21:50 |
| BUGabundo | i know | 21:51 |
| BUGabundo | but i'm frustrated | 21:51 |
| BUGabundo | ok | 21:52 |
| BUGabundo | sudo gdm stop | 21:52 |
| BUGabundo | now looking for the driver | 21:52 |
| BUGabundo | http://paste.ubuntu.com/353644/ | 21:53 |
| BUGabundo | and | 21:53 |
| BUGabundo | http://paste.ubuntu.com/353645 | 21:53 |
| tjaalton | who's alberto-milano? | 21:54 |
| tjaalton | ie. the url is wrong.. | 21:54 |
| BUGabundo | one - too many | 21:55 |
| tjaalton | milone, not milaon | 21:55 |
| tjaalton | milano | 21:55 |
| tjaalton | so, two typos | 21:55 |
| BUGabundo | thanks | 21:56 |
| BUGabundo | my eyes are terribly tired | 21:56 |
| BUGabundo | already put my eye drops | 21:56 |
| tjaalton | copypaste ftw | 21:56 |
| BUGabundo | lets see if it improbes | 21:56 |
| BUGabundo | tjaalton: humm yeah | 21:56 |
| BUGabundo | :( | 21:57 |
| BUGabundo | i still cant see them | 21:57 |
| tseliot | tjaalton: lol | 22:01 |
| BUGabundo | tseliot: i'm sorry, but its not funny | 22:02 |
| tseliot | BUGabundo: add ppa:albertomilone/proprietary-video-improvements from the Software sources program | 22:02 |
| BUGabundo | i understand you work very hard in providing | 22:02 |
| BUGabundo | this package the best u can | 22:02 |
| tseliot | I was laughing about my name | 22:02 |
| tseliot | or of what became of my name ;) | 22:03 |
| BUGabundo | but when it subums an user system like this without proper upgrade path, it suck | 22:03 |
| BUGabundo | ok | 22:03 |
| BUGabundo | i see current | 22:03 |
| BUGabundo | but not -graphics | 22:03 |
| tseliot | experimental releases are not intended to be used by everyone | 22:04 |
| tjaalton | you want current | 22:04 |
| tseliot | yep | 22:04 |
| BUGabundo | instrallng | 22:04 |
| tjaalton | but your main mirror probably doesn't have the needed mesa/xserver | 22:04 |
| BUGabundo | tseliot: i've commited myseft 3 years ago to run at least one box in +1 | 22:04 |
| tjaalton | tseliot: maybe you should add a Depends on those | 22:04 |
| tjaalton | for the nvidia* | 22:04 |
| BUGabundo | so i can test, and provide good feedback | 22:04 |
| BUGabundo | allowing we all to have a good release after 6 monts | 22:05 |
| tseliot | tjaalton: aren't transitional packages enough? | 22:06 |
| tjaalton | tseliot: no I mean depends on mesa/xserver | 22:06 |
| tseliot | note: I haven't uploaded nvidia in Lucid yet | 22:06 |
| tjaalton | since 3d doesn't work with the old ones | 22:06 |
| bjsnider | that is going in today right? | 22:06 |
| tseliot | yep | 22:06 |
| tseliot | an archive admin will have to approve nvidia-current though | 22:07 |
| bjsnider | yeah, i'm telling everybody to get rid of the ppa versions that use the old package system | 22:07 |
| BUGabundo | ok | 22:07 |
| BUGabundo | i got -current from PPA | 22:07 |
| BUGabundo | do i need to manually choose a mesa too ? | 22:08 |
| tseliot | tjaalton: 3d for nvidia doesn't work with those. 3D with open driver does work | 22:08 |
| tjaalton | just make sure you have 7.6.1~rc3-1ubuntu2 | 22:08 |
| tjaalton | tseliot: umm what? | 22:08 |
| tjaalton | tseliot: you need the new mesa for the libs to be sorted out, right? | 22:09 |
| BUGabundo | tjaalton: i dont! installing | 22:09 |
| BUGabundo | libosmesa6 right? | 22:09 |
| tjaalton | -nv never had 3d, and never will | 22:09 |
| tjaalton | BUGabundo: no | 22:09 |
| BUGabundo | no? | 22:10 |
| BUGabundo | all others are dgb or dev | 22:10 |
| tjaalton | what you already have installed, just that the version should be that | 22:10 |
| tseliot | tjaalton: aah, you mean versioned dependencies on X and mesa | 22:10 |
| tjaalton | you don't need to install any new packages | 22:10 |
| tjaalton | tseliot: yes | 22:10 |
| BUGabundo | rebooting | 22:11 |
| tjaalton | BUGabundo: then again, that version isn't published yet, so it's not available | 22:11 |
| BUGabundo | lets see how this goes | 22:11 |
| BUGabundo | BAHA | 22:11 |
| tseliot | 7.6.1~rc3-1ubuntu2 is what you want | 22:11 |
| tjaalton | libdrm uploaded | 22:11 |
| BUGabundo | waiittt | 22:11 |
| BUGabundo | i have 1280*800 | 22:11 |
| BUGabundo | this darn cpu stuck in PERFORMENCE is killing me | 22:12 |
| BUGabundo | compiz doesnt start | 22:13 |
| BUGabundo | do u guys need a trace? | 22:13 |
| tjaalton | no | 22:13 |
| tjaalton | what I said, you need the new mesa, but it's not available yet | 22:13 |
| BUGabundo | ok | 22:13 |
| BUGabundo | so tommorrow i just remove the PPA | 22:13 |
| BUGabundo | and upgrade normaly= | 22:14 |
| BUGabundo | ? | 22:14 |
| tjaalton | probably so | 22:14 |
| * tseliot nods | 22:14 | |
| BUGabundo | and we are going with nvidia 190? | 22:14 |
| tseliot | BUGabundo: temporarily, yes | 22:15 |
| BUGabundo | hey, i can change my GPU power mode now :D | 22:15 |
| BUGabundo | do u guys need a nvidia-bug-report.sh log ? | 22:15 |
| tjaalton | for what? | 22:16 |
| BUGabundo | i dunno | 22:16 |
| BUGabundo | just trying to help | 22:16 |
| BUGabundo | providing what ever my system can pump out | 22:16 |
| BUGabundo | so u guys can check for probs *before* hand | 22:16 |
| BUGabundo | but since u dont, I thanks you all for your hard work | 22:17 |
| BUGabundo | and will now use my laptop to flash my new WDTV | 22:17 |
| bjsnider | it provides nvidia bug report codes that we don't understand mostly | 22:17 |
| BUGabundo | with a new oficial rom, so i can see my movies | 22:17 |
| BUGabundo | thanks | 22:17 |
| tjaalton | mesa 7.7 uploading.. slowly, killing my irc | 22:18 |
| soren | tseliot: Yay! It works now. Thanks! | 22:20 |
| tseliot | tjaalton: I'm a bit concerned about those dependencies. What shall I depend on? libgl1-mesa-glx ( >= 7.6.1~rc3-1ubuntu2) and xserver-xorg-core (>= 2:1.7.3.902-1ubuntu2) ? | 22:20 |
| tseliot | soren: does it already? | 22:21 |
| tseliot | maybe mesa was published | 22:21 |
| soren | tseliot: I grabbed the binaries from Launchpad. | 22:21 |
| tjaalton | tseliot: something like that, yes | 22:21 |
| soren | tseliot: No, mesa still isn't published. | 22:21 |
| tseliot | aah | 22:21 |
| tseliot | ok | 22:21 |
| soren | Oh, it was /just/ published. | 22:22 |
| soren | It wasn't 10 minutes ago. | 22:22 |
| tseliot | tjaalton: by the time nvidia is approved, builds and is published I bet mesa will be on every server in the world | 22:22 |
| * tseliot hasn't uploaded nvidia yet | 22:23 | |
| tjaalton | tseliot: as you wish | 22:23 |
| tseliot | ;) | 22:23 |
| * tseliot starts uploading nvidia-current | 22:27 | |
| tjaalton | xorg merged & uploaded | 22:48 |
| tseliot | good | 22:48 |
| bryyce | \o/ | 22:53 |
| * tseliot uploading nvidia-173 | 22:54 | |
| Sarvatt | in our mesa 7.7, shouldnt we be bumping the libdrm-dev build-dep version to 2.4.17 because we use libdrm-radeon1? | 23:06 |
| tjaalton | well yes, but since it already depends on .15 which isn't available, we should be good | 23:07 |
| tjaalton | I mean, .17 will be available and it fails to build with the current .14 | 23:07 |
| tjaalton | err, doesn't even try to build | 23:07 |
| tjaalton | it's in depwait | 23:08 |
| Sarvatt | darn flickering after resume, the latest 01-07 2.6.33-999 kernel didnt have the drm-intel-next pull in it it looks like | 23:11 |
| bryyce | <vorlon> bryyce: fwiw, the xorg upload for the nvidia colormap fix has also fixed my intel crash-on-lid-close bug :) | 23:17 |
| tjaalton | bryyce: whaaat :) | 23:17 |
| Sarvatt | how the heck | 23:17 |
| Sarvatt | oh maybe it was in 1.7.4 | 23:17 |
| bjsnider | what does one have to do with another | 23:18 |
| tseliot | come on, don't you believe in magic? :-P | 23:18 |
| tjaalton | Sarvatt: yes, most likely | 23:18 |
| Sarvatt | forgot it was a version bump in the latest upload, i didnt see how just the gamma fix woulda fixed it | 23:18 |
| bjsnider | i'll believe it when i can build against its header file | 23:18 |
| bryyce | <vorlon> heh, well, my backtrace also had some color-related stuff in it :) | 23:19 |
| bryyce | <vorlon> I think the crash was specifically related to X trying to query the gamma on an output that had been turned off immediately prior | 23:20 |
| tjaalton | it would be nice to verify that it's what fixed it, and add that to the mvo's patch. should help getting reviewed/ack'ed upstream | 23:21 |
| tseliot | all the nvidia packages are now in Lucid | 23:23 |
| tseliot | I'll upload the other pieces tomorrow | 23:24 |
| bryyce | tjaalton, *nod* | 23:25 |
| bryyce | <vorlon> man, I'm not bisecting over this :) | 23:27 |
| tjaalton | hehe | 23:28 |
| Sarvatt | you know, tormod had a problem with that exact hunk in xserver for a few months when i was packaging up xorg 7.5 for karmic | 23:28 |
| * slangasek metoo! | 23:28 | |
| slangasek | I have this exact same bug | 23:28 |
| slangasek | ;) | 23:28 |
| Sarvatt | he was crashing until this commit http://cgit.freedesktop.org/xorg/xserver/commit/?id=75795637c7160f1579dbe81c2d7600e85b1d141f | 23:28 |
| Sarvatt | there was a long discussion on the gamma problem there on xorg-devel i think, might be something interesting in there | 23:29 |
| Sarvatt | It also contains a fix from Adam Jackson to not crash on xserver 1.7, but please note that it still doesn't work correctly on that release because the server never calls the old-style colormap setup code. | 23:32 |
| Sarvatt | redhat still uses nv for some chipsets, wonder if they have any patches for it | 23:32 |
| tjaalton | yes, http://lists.x.org/archives/xorg-devel/2009-May/000982.html | 23:33 |
| tjaalton | and continued the next month | 23:34 |
| Sarvatt | screwing with that hunk might cause regressions on non -nv is all i was thinking, yeah thats the same chipset tormod was having problems with I think | 23:34 |
| tjaalton | we'll see | 23:35 |
| tjaalton | everyone signing off for the weekend, just the right time to upload a ton of stuff :P | 23:35 |
| tjaalton | slangasek: what was your bug # again? | 23:36 |
| slangasek | tjaalton: 494680 | 23:37 |
| Sarvatt | looks like it only affects G80+ cards under -nv too | 23:39 |
| tjaalton | thanks | 23:39 |
| Sarvatt | shifting G80+ pci ids to use vesa would probably be better if it ends up causing problems. odd i didnt get any email from xorg-devel about that patch | 23:42 |
| tjaalton | well slangasek has an intel, and it fixed the lid-closing crasher, so it's not just -nv | 23:42 |
| Sarvatt | looks similar slangasek - http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=554450 | 23:45 |
| ubottu | Debian bug 554450 in xserver-xorg-video-intel "xserver-xorg-video-intel: server crash on external monitor when using gnome-screensaver" [Normal,Open] | 23:45 |
| tjaalton | indeed it does | 23:45 |
| Sarvatt | dpms off with multiple monitor related maybe? | 23:46 |
| slangasek | all of these keywords seem to apply :) | 23:47 |
| Sarvatt | like I know KDE does a dpms off on lid close from tracking down another bug it had awhile back (dont know what you're using) | 23:48 |
| Sarvatt | do you have g-p-m set to "do nothing" on lid close? | 23:50 |
| Sarvatt | or blank screen? | 23:50 |
| Sarvatt | i really dont know how its all connected at the moment but you might want to try disabling activate screensaver when idle in gnome-screensaver and set g-p-m to do nothing on lid close and try it out | 23:53 |
| Sarvatt | if it didnt happen when booting with nomodeset would also be good to know | 23:55 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
