| Sarvatt | building a new one now with that patch applied to see if it's any faster :) | 00:06 |
|---|---|---|
| Sarvatt | plymouth is kind of useless as-is otherwise since it loads the firmware so slow :( | 00:07 |
| RAOF | Yeah. | 00:08 |
| RAOF | Checking out nouveau_grctx.c it doesn't look like anything amazingly wrong is happening. | 00:12 |
| Sarvatt | sheesh this laptop is burning hot with nouveau | 00:13 |
| Sarvatt | WHOOPS | 00:13 |
| Sarvatt | nevermind, building the new lbm :) | 00:13 |
| RAOF | You've already uploaded one based on rc6, and this is your personal voodoo-generator-patched version, right? | 00:14 |
| Sarvatt | i'm just building this locally, wasnt planning on putting it on edgers/nouveau unless you think we should? | 00:14 |
| RAOF | I don't think we should. Unless someone stops us shipping nouveau-firmware, I think that's the right thing to use until the voodoo generator goes mainline. | 00:15 |
| Sarvatt | yeah | 00:16 |
| Sarvatt | have to try all of this stuff out on a non-nvidia machine still | 00:18 |
| Sarvatt | dont have any ati that can use a PPA though (its a powerpc) and thats what i'm worried about | 00:19 |
| RAOF | I'd also like someone to try it out on a PPC-nvidia machine, too. | 00:21 |
| RAOF | My Intel laptop is perfectly happy running xorg-edgers/nouveau | 00:22 |
| Sarvatt | you installed linux-backports-modules-nouveau on it? | 00:23 |
| Sarvatt | is it using drm or lbm-drm if so? | 00:24 |
| Sarvatt | this lbm stuff doesnt apply to ports arches it looks like anyway | 00:25 |
| Sarvatt | rebooting into a voodoo generator lbm-nouveau now | 00:25 |
| RAOF | I installed linux-backports-modules-nouveau on it; it's using standard drm. | 00:28 |
| Sarvatt | http://pastebin.com/fc76bc53 | 00:28 |
| RAOF | That's freaky and weird. | 00:29 |
| Sarvatt | only visual change was it had a black screen until plymouth instead of an 80x25 with a blinking cursor, no change in that plymouth wasnt up until right before X | 00:29 |
| RAOF | It's pulled up fb0 @ 3sec, then waits until 13sec to actually finish probing your output & switching modes. | 00:30 |
| Sarvatt | http://sarvatt.com/downloads/arcueid-lucid-20100203-6.png | 00:31 |
| Sarvatt | yeah thats strange | 00:31 |
| RAOF | You've got your display on, right? | 00:32 |
| RAOF | Or is the laptop still headless? | 00:32 |
| Sarvatt | yeah i'm on that machine now | 00:33 |
| apw | RAOF, Sarvatt you are not menat to run MUNGE-NOUVEAU ... it occurs at build time | 00:33 |
| Sarvatt | wanted to be sure that wasnt the problem | 00:33 |
| RAOF | apw: Yeah, we figured that out pretty quickly. Thanks anyway :) | 00:34 |
| apw | you'll be telling me my shit makes sense next | 00:34 |
| RAOF | Quite a lot of sense, yes. :) | 00:35 |
| RAOF | Sarvatt: Feel like booting that laptop with some drm debugging enabled? | 00:35 |
| Sarvatt | doing it now | 00:36 |
| Sarvatt | http://sarvatt.com/downloads/nouveau.debug.log | 00:38 |
| RAOF | apw: Is there any special reason that linux-backports-modules-nouveau is only i386 & amd64? Nouveau should work - and there's relevant nvidia hardware - on PPC as well. | 00:39 |
| RAOF | Sarvatt: I'm not sure that's actually nouveau's fault, now. It looks like nouveau is set up & ready to go @ 3sec, then gets asked to do a modeset @ 13sec, and after that everything is right. | 00:43 |
| kklimonda | Sarvatt, the new lbm you have uploaded looks broken - all .debs are 5KB | 00:50 |
| Sarvatt | oh nasty | 00:55 |
| Sarvatt | RAOF: mind uploading yours? looks like a bunch of files got corrupted on my filesystem | 00:57 |
| Sarvatt | everything in updates/ is 0 bytes | 00:58 |
| * RAOF bumps the version and uploads. | 00:58 | |
| Sarvatt | sorry about that :( | 00:58 |
| RAOF | S'ok. | 00:59 |
| Sarvatt | ok the plymouth problem isn't even nouveau specific, my intel machine is having the same problem since the update to plymouth 0.8.0~-8 | 01:09 |
| RAOF | I don't think I've booted this intel laptop recently enough to pick that up. | 01:09 |
| RAOF | Also, I need to bust out the busybox to mount my dm-crypt home anyway. | 01:10 |
| Sarvatt | can't shutdown or suspend or anything with this plymouth because it just hangs | 01:10 |
| Sarvatt | which is the default plymouth theme again? | 01:11 |
| Sarvatt | ah --reset works | 01:11 |
| Sarvatt | theres nothing plymouth related in the initrd anymore when i extract it | 01:12 |
| * kklimonda said so | 01:12 | |
| kklimonda | ;) | 01:12 |
| Sarvatt | ugh, i haven't been following #ubuntu-devel today, alot of talk about it's broken-ness right now :D | 01:15 |
| bryce2 | pitti and I debugged the rethrow signals patch | 01:54 |
| bryce2 | it works now and I've uploaded it to lucid. | 01:54 |
| bryce2 | cya | 01:54 |
| Sarvatt | so apparently the change to not having a splash for more than a second is an intentional change now | 01:58 |
| Sarvatt | <slangasek> you could set the FRAMEBUFFER=y option in /usr/share/initramfs-tools/conf-hooks.d/ to force it | 01:58 |
| Sarvatt | thats what we have to do to see the splash | 01:58 |
| Sarvatt | no plymouth in the initrd so it's mountall (virtual-filesystems) -> udev -> udevtrigger -> plymouth-splash then X with it's less than 1 second start time now :) | 02:00 |
| kklimonda | Sarvatt, dont forget about ureadahead | 02:03 |
| RAOF | Ok. | 02:03 |
| RAOF | I wonder why my laptop throws up the splash early, then. | 02:04 |
| kklimonda | it does boot really fast though - but the experience sucks although the pre3 lbm package helped me - no londer weird colors at boot but the expected console | 02:04 |
| Sarvatt | it's a shame because it was a really nice boot process yesterday and you didn't get to see it because of that :D | 02:06 |
| Sarvatt | having the splash up at 2 seconds at full resolution was nice | 02:08 |
| Sarvatt | phew yeah changing OPTION=FRAMEBUFFER to OPTION=FRAMEBUFFER=Y at the top of /usr/share/initramfs-tools/hooks/plymouth and doing an update-initramfs -u got it back in the initrd | 02:15 |
| RAOF | Now, does that make nouveau bring up a nice framebuffer earlier? | 02:17 |
| Takyoji | Looking for testers of proprietary drivers on 10.04? | 02:17 |
| Takyoji | (just joined the mailing list, and noticed a message in the archives for the ubuntu-bugsquad mailing list) | 02:18 |
| Sarvatt | http://paste.ubuntu.com/368600/ | 02:19 |
| Sarvatt | XD | 02:19 |
| Sarvatt | rebooting now to find out | 02:19 |
| Sarvatt | http://pastebin.com/f7a4c889e | 02:24 |
| Sarvatt | 6 seconds in it showed up, udev starts like 10 seconds sooner this way too | 02:24 |
| Sarvatt | it still waits for mountall and fsck checks where it didnt before | 02:26 |
| Sarvatt | so its not as early as before, the fsck stuff happened underneath the splash before | 02:26 |
| Sarvatt | but i get about 10 seconds of splash and can see the progress bar this way instead of just a flicker before X starts | 02:26 |
| RAOF | Oh! It's probably udev that triggers the console update. | 02:42 |
| Sarvatt | we might get classic mesa drivers for nv0x-nv2x in edgers by the time lucid releases too :) | 02:48 |
| Sarvatt | heck, i could import and build it now | 02:49 |
| Sarvatt | http://cgit.freedesktop.org/~currojerez/mesa/commit/?h=mesa-next&id=9d4bcd1afb7b483954ef96af65397c2cf687eb65 | 02:50 |
| Sarvatt | vish: http://cgit.freedesktop.org/mesa/drm/commit/?id=1802e1a4e747b5906d3af10c4a53fd457eddcbb4 | 02:51 |
| Sarvatt | fix for your log spam if the ddx patch didnt fix it completely | 02:51 |
| Sarvatt | maybe we should just do a git checkout of libdrm if nouveau is going in anytime soon | 02:52 |
| RAOF | How easy is it to make mesa build the gallium drivers, too? | 02:53 |
| RAOF | I guess it's easier to add a classic driver to the build than to work out how to make gallium fly. | 02:54 |
| Sarvatt | its over my head, i dont know how it changes the resultant libGL.so.1 when you compile gallium into it and if things work with non-gallium when you build gallium stuff | 02:55 |
| Sarvatt | i know it wants to use the gallium dri modules instead of the classic ones when i build it here but dont know if thats because of how i configured it | 02:57 |
| Sarvatt | the mesa build system is a nightmare :( | 02:58 |
| Sarvatt | would be super easy to add the classic mesa nouveau driver. just a patch and adding it on one line in the rules | 03:00 |
| RAOF | Yeah. | 03:01 |
| Sarvatt | they disable the gallium drivers to let the classic ones work it looks like in that branch so something tells me if you build gallium at all its gallium or nothing like I feared :( | 03:02 |
| Sarvatt | with mesa being shoved away to /usr/lib/mesa for the alternative stuff maybe it'd be easier though, just throwing it in /usr/lib/mesa-gallium and setting up the alternatives for it | 03:05 |
| RAOF | Mayhap. | 03:06 |
| RAOF | This isn't urgent, though; it'll be MM stuff at best. | 03:07 |
| Sarvatt | that actually doesnt seem *that* hard to do now that i think about it, I stopped messing with it because it seemed like they wouldnt coexist but i could reuse alot of the alternatives stuff already there that I was sketchy on. maybe if I get a day off of work someday I'll work on it :D | 03:10 |
| Sarvatt | figuring out the right configure flags to use will be the hardest part | 03:11 |
| Sarvatt | I bet I can snag that info off gentoo too | 03:13 |
| * Sarvatt tries to dig up a nv0x-nv2x nvidia card to test the classic mesa nouveau drivers | 03:16 | |
| bjsnider | Danag can do it for you in the other channel | 03:19 |
| bjsnider | he's got an old riva tnt or something | 03:19 |
| Sarvatt | nv2x is geforce 5 isnt it? or geforce4? | 03:20 |
| Sarvatt | thinking its 5 because 4 was just a speed bumped and rebranded 3 afaik | 03:20 |
| bjsnider | i dunno. naming conventions are dull | 03:20 |
| Sarvatt | woohoo, remembered i have a geforce4mx with a pci-agp adapter in my efika | 03:23 |
| Sarvatt | geforce 5 was nv4x ah | 03:24 |
| Sarvatt | err nv3x | 03:24 |
| RAOF | The geforce4mx is actually a geforce2 | 03:25 |
| Sarvatt | yepyep | 03:25 |
| bjsnider | then why is it called.. | 03:25 |
| bjsnider | never mind | 03:25 |
| RAOF | bjsnider: BECAUSE | 03:26 |
| bjsnider | there you go | 03:26 |
| RAOF | It's higher-clocked, IIRC. But it's a geforce2 core | 03:26 |
| bjsnider | nvidia still does this stuff to this day | 03:26 |
| Sarvatt | hmm libgl1-mesa-dri-gallium? libgl1-mesa-gallium-dri? | 03:33 |
| Sarvatt | libgl1-gallium-dri? I dunno | 03:34 |
| RAOF | libgs1-gallium-dri probably. | 03:35 |
| RAOF | What do we do with the other statetrackers? | 03:35 |
| Sarvatt | libgjs on the brain? :D | 03:35 |
| RAOF | I FIXED THAT, DAMNIT! | 03:36 |
| RAOF | :) | 03:36 |
| Sarvatt | yeah I saw, and thank you :) | 03:36 |
| RAOF | Do we care to split out the other state trackers? | 03:36 |
| RAOF | Maybe it's just libgl1-gallium | 03:37 |
| Sarvatt | i'm just going to start with the basics, was just using -dri as an example to try to figure out how to name it | 03:37 |
| RAOF | Yeah. I don't think we need the dri in the name; maybe libgl1-mesa-gallium? | 03:38 |
| Sarvatt | well I mean I was thinking of building the gallium dri drivers too and putting them all in the seperate package, could just install everything in one package though to start | 03:39 |
| Sarvatt | the radeong_dri.so is apparently in a usable state now | 03:40 |
| RAOF | fun! | 03:40 |
| Sarvatt | i need a complete configure flag that enables nouveau/intel/radeon gallium drivers and builds the gallium dri stuff too to make a new confflags target in the rules | 03:47 |
| bryce2 | https://wiki.ubuntu.com/X/Troubleshooting/NvidiaDriverSwitching#preview | 03:48 |
| Sarvatt | ./configure --with-state-trackers=dri --with-dri-drivers= --with-driver=dri --enable-gallium-intel --enable-gallium-radeon --enable-gallium-nouveau? | 03:48 |
| RAOF | You can drop the --with-driver=dri bit. | 03:50 |
| RAOF | I pass "glx,dri,vega" to --with-state-trackers, personally. I'm not totally sure why, though :) | 03:50 |
| Sarvatt | ah defaults to dri, I see | 03:51 |
| Sarvatt | need --disable-gallium-svga now it looks like | 03:56 |
| RAOF | I didn't think that actually built by default, did it? | 03:59 |
| RAOF | You also need newer dri2 protocol headers, don't you? | 03:59 |
| Sarvatt | they're in edgers | 04:01 |
| RAOF | Nifty. | 04:02 |
| Sarvatt | what does 101_ubuntu_hidden_glname.patch in mesa do? | 04:17 |
| Sarvatt | "Re-add debian/patches/101_ubuntu_hidden_glname.patch since we use GLX_TLS now. An explanation of the patch would be nice though.." is all i see in the history | 04:19 |
| Sarvatt | http://git.debian.org/?p=pkg-xorg/lib/mesa.git;a=blob;f=debian/patches/101_ubuntu_hidden_glname.patch;h=1d1d066c7e8b10bb594f7b3171b2bb3cb1d6ebdc;hb=0748753b1fbb808dc4a6e501a80b822dcea661ac | 04:19 |
| RAOF | Sarvatt: That's a fine question. | 04:25 |
| bjsnider | someone's not commenting a patch? unheard of | 04:26 |
| bjsnider | doesn't the code itself provide some notion of what it's doing? | 04:29 |
| RAOF | It looks like it's unhiding a function, but the source it's modifying is assembly, and it's been ages since I touched a microprocessor like that. | 04:31 |
| bjsnider | no clue about who wrote it? | 04:32 |
| bjsnider | or should it be who diffed it | 04:32 |
| bjsnider | somebody had to originally post it to a mailing list right? | 04:33 |
| RAOF | No. We don't use revision control for packaging (yet). | 04:36 |
| tjaalton | trying to trace the hidden_gl change, but it probably was split from the diff at some point | 07:28 |
| tjaalton | should also add the Old changelog entries to git | 07:28 |
| tjaalton | looks like fedora added nouveau dri to dri-drivers-experimental | 09:15 |
| RAOF | tjaalton: Where do you see these things? | 09:31 |
| tjaalton | RAOF: fedora cvs | 09:32 |
| tjaalton | http://cvs.fedoraproject.org/viewvc/devel/mesa/ | 09:32 |
| RAOF | Are you subscribed to commits, or do you just browse every now and then? | 09:32 |
| tjaalton | though it looks like they missed adding gallium/nouveau to the for-loop :) | 09:32 |
| tjaalton | browse every now and then | 09:32 |
| tjaalton | this time to see how they handle gallium | 09:32 |
| tjaalton | looks like just the way the current dri drivers are handled.. | 09:33 |
| RAOF | Spec files are wierd! | 09:36 |
| RAOF | But it does look like they don't do anything special. | 09:36 |
| tjaalton | yeah I don't like how everything is in one file.. | 09:37 |
| RAOF | I guess the one file has its advantages, but once you're familiar with the various files in debian/ I think multiple files make it easier to understand what's happening. | 09:40 |
| Cobalt | Sarvatt: I know the Intel driver Eee PC crashes have been fixed with the new Intel drivers of newer kernels, are there any plans to isolate what's causing the crashes in the newer Xorg drivers in older kernels? | 13:15 |
| libv | Cobalt: check libv.livejournal.com and answer the question at the end of the post :) | 13:20 |
| Cobalt | libv: Thank you. | 13:21 |
| libv | it has no direct solution for this, but does point at the same fundamental issue you are pointing at | 13:21 |
| Cobalt | libv: Latest post? | 13:21 |
| libv | yes, it talks about the xorg devroom and the talk i will be holding there | 13:22 |
| Cobalt | I'm sorry if I'm a bit slow with this, but I see no mention of crashes or the Intel driver... or have those issues been noted on other drivers as well? | 13:23 |
| libv | "For those using, or those who have used, the nvidia or ati closed source drivers: how would you like it if nvidia or ATI told you that you needed the very latest upstream kernel, X, and mesa to be able to run the latest catalyst or nvidia driver, especially when you might need this version for its new hardware support or for bugfixes?" | 13:25 |
| Cobalt | I see. | 13:26 |
| Cobalt | Ah well, I'll follow that, I guess, and see what comes of it. Thanks. | 13:26 |
| Cobalt | I can see a lot of people not liking the idea of upgrading their kernels. Especially if their distribution don't provide stable packages. | 13:28 |
| libv | Cobalt: about the drm, until a year/year and a half ago, you could just grab the drm tree and build kernel modules | 13:32 |
| libv | there was a small bit of compat code to level over the bumps in a few kernel versions | 13:32 |
| Cobalt | Yes, but still, it's not within everyone's grasp to do that. I'd personally shun from compiling anything kernel-related. :S | 13:32 |
| libv | Cobalt: make; make install | 13:33 |
| Cobalt | You make it sound terribly easy. | 13:33 |
| libv | it was | 13:33 |
| Cobalt | Not anymore? | 13:33 |
| libv | no, now it is assimilated in the kernel | 13:34 |
| Cobalt | See?! Terribly complex stuff. | 13:34 |
| libv | which they finally also mentioned to the BSD people a few months ago, and they were thrilled :) | 13:35 |
| Cobalt | So that's a good thing? | 13:35 |
| libv | telling the BSD folk to port their stuff directly from the linux kernel? | 13:36 |
| Cobalt | No, that the thing was integrated in the kernel now. | 13:36 |
| libv | some people say it is | 13:37 |
| Cobalt | I suppose it's going to be a lot more stable and tested. | 13:37 |
| libv | with graphics hardware? | 13:37 |
| libv | graphics hardware is hugely complex and its drivers are in constant flux | 13:37 |
| libv | part of why linus held off the boat for so long and treated the fb drivers that stepmotherly | 13:37 |
| libv | but seems that his appreciation of that has changed | 13:38 |
| Cobalt | You can hardly get anything out of the fb these days. | 13:38 |
| Cobalt | Not such a dinosaur, then. | 13:38 |
| Cobalt | Still, for him to have accepted, it's pretty big. | 13:38 |
| libv | well, go back a few years, and you could hardly get anything out of X either | 13:38 |
| libv | politics/money goes a long way | 13:39 |
| Cobalt | That has moved quite a bit, now that you mention it. Drastically too. And for a bit, without much thought to the consequences. | 13:39 |
| Cobalt | I use Ubuntu, I remember the hue and cry when Jaunty came out. | 13:39 |
| libv | yes, and it is only going to become worse | 13:39 |
| Cobalt | I thought things were evening out a bit. | 13:40 |
| libv | this is what people say will happen | 13:40 |
| libv | but there is a difference between what is stated and what is done | 13:40 |
| Cobalt | Still, I'm not much in those circles, only started getting interested in the issue because of performance and stability hits on my EeePC. | 13:40 |
| libv | next great idea is to move xorg drivers into the xserver tree again so the API "can get fixed" | 13:40 |
| libv | first week and someone will run s/xf86/xorg/ on the whole thing | 13:41 |
| Cobalt | That's the only way you'll get to debug it. | 13:42 |
| libv | err... i am talking about exchanging the string xf86 to xorg on all the symbols in the xserver | 13:43 |
| Cobalt | Oh. I'm not sure I understand what the consequences of that would be. Pretty much of a noob where all that stuff is concerned, I'm afraid. | 13:43 |
| libv | Cobalt: this means that there will be a massive API breakage for no reason except for a lingering oedipus complex | 13:44 |
| Cobalt | Well, at least, the sooner they get over that, the better, surely, even though it's going to be hell to go through the transition period? | 13:45 |
| libv | it's a pointless transition | 13:45 |
| Cobalt | Having said that, wouldn't they just stick to stability versus change? There's a lot of enterprise grade applications that depend on X. | 13:45 |
| libv | well, i used to work for suse, and i had some of those big shots on the phone with suse management and his companies management | 13:46 |
| libv | and he pretty much blatantly said that suse had to go change its business model to adapt to his way of working | 13:46 |
| Cobalt | What'd come of it? | 13:46 |
| Cobalt | Admin and bureaucracy (I think it's universal) has a way having their heads in the clouds. I have similar issues at work - at a hospital. | 13:47 |
| libv | well, in normal business you expect things like that, 5 or so years ago i never though that open source software could be just as bad or even worse. | 13:50 |
| libv | you'd expect technical stuff to be more important than politics and talking rubbish | 13:50 |
| Cobalt | Not so good when you have a megalomaniac running the show. | 13:50 |
| Cobalt | Well, that's the exact same thing with hospitals. Sometimes decisions coming form the top just does not make sense. Like painting over a whole A&E department (for only 2 hours, granted) while business is still ongoing. | 13:51 |
| jcristau | libv: it's so much better to be able to hide a few bug fixes in lots of regressions! | 16:15 |
| libv | jcristau: that's not regressions, thatt's progress :) | 16:17 |
| jcristau | ah, right | 16:17 |
| jcristau | easy to get confused.. | 16:17 |
| libv | too bad you're not there this weekend :) | 16:18 |
| libv | i'll still mention your debianised git trees in my talk though :) | 16:19 |
| jcristau | libv: do you know if any of the intel people will be at fosdem? | 16:30 |
| Sarvatt | tjaalton: wow, interesting, looks like we can build nouveau gallium at least along with the rest of the dri stuff going by what they are doing, I guess the tricky part comes when you build gallium drivers for things that have classic mesa ones as well | 16:56 |
| tjaalton | Sarvatt: I think those should be in another (libgl1-mesa-dri-experimental?) package that would provide/conflict with l-m-d, and when the gallium versions are considered stable, move them over | 17:32 |
| tjaalton | though mesa supports an alternative path now | 17:33 |
| libv | jcristau: i had to remove a talk in the wiki today | 17:33 |
| libv | jcristau: anholt inserted one at 11:00on the second of february, never said a word to me | 17:34 |
| libv | so yes, i guess so | 17:34 |
| libv | but no talk, as the morning slots are all taken by openmoko | 17:34 |
| jcristau | :/ | 17:34 |
| libv | serves him right though, it's thanks to stunts like this that we will not have a devroom next year | 17:35 |
| vish | Sarvatt: hi... the two patches you showed me , have they landed in lucid or in the -edgers ppa? [right now i have your ppa pinned and dont seem to have any trouble with it so far] | 18:20 |
| vish | the patches for the gdm flood errors* | 18:21 |
| Sarvatt | the ati patch is, i'm working on libdrm now to prevent the errors getting flooded under any circumstances also | 18:21 |
| vish | you mean they are in the edgers ppa? | 18:22 |
| Sarvatt | the ati fix is in the upstream git, the same fix i added as a patch to that -ati you used from my ppa | 18:27 |
| Sarvatt | thats been in edgers for a few days now yeah | 18:27 |
| vish | ah , cool , thanks | 18:27 |
| Sarvatt | but the libdrm one isnt yet, i'm working on that right now, taking a bit of tweaking because of the ubuntu branch in debian git being a little messed up | 18:27 |
| * vish nids | 18:29 | |
| Sarvatt | all done and it built fine, uploading now | 18:29 |
| vish | nods* | 18:29 |
| Sarvatt | are you on karmic? | 18:30 |
| * Sarvatt forgot | 18:30 | |
| vish | no.. lucid | 18:31 |
| Sarvatt | well, uploaded karmic too but that might not build right | 18:31 |
| Sarvatt | ah ok | 18:31 |
| vish | Sarvatt: would i have to watchout for Bug #436546 in the edgers ppa? last i heard was it[legacy_is_pending() or ? ] was required for some other bug | 18:34 |
| ubottu | Launchpad bug 436546 in mesa "X crashes when using compiz cube and cairo-dock" [Unknown,Confirmed] https://launchpad.net/bugs/436546 | 18:34 |
| Sarvatt | i wouldnt expect cairo-dock to work right in any circumstances, all i've heard is bad things by the mesa devs about how it tries to do things :) | 18:59 |
| vish | hehe , i can switch to different dock , but If X doesnt crash that would be sufficient for me :D | 19:02 |
| Sarvatt | i really dont have any idea though, if it doesn't work still just install ppa-purge and sudo ppa-purge xorg-edgers to go back to stock :) | 19:04 |
| vish | yeah.. i'm already installing -edgers [thats the plan] | 19:05 |
| baptistemm | * Add klingon language definition. wtf??? | 19:29 |
| jcristau | baptistemm: wtf indeed. | 19:29 |
| baptistemm | :) | 19:29 |
| baptistemm | dear X developper, are you aware of a X corruption (on Intel at least) in lucid since yesterday | 19:30 |
| seb128 | baptistemm, what do you call corruption? | 19:47 |
| bryce2 | Sarvatt, hey you suggested something the other day to get vt switching to work on nouveau but I've forgotten | 20:12 |
| bryce2 | Sarvatt, btw just removing splash from the kernel boot line wasn't sufficient for getting 3D working. but that's fine I think we're missing some more fundamental bits | 20:13 |
| tjaalton | like the dri driver?-) | 20:14 |
| bryce2 | tjaalton, indeed | 20:19 |
| Sarvatt | yeah bryce2 nouveau isn't going to have 3D support in lucid almost guaranteed, it would be easy to add nv0x-nv2x classic mesa 3D support if we go with mesa 7.8 though. removing splash was to fix the GPU hang and reset which was making the ddx use noaccel so there was no 2D acceleration happening but the fixed plymouth i uploaded there fixed that | 20:24 |
| bryce2 | heh, rotating screen upside down --> crash | 20:24 |
| bryce2 | ok | 20:25 |
| bryce2 | ideas on the vtswitching issue? | 20:25 |
| Sarvatt | what happens when you try to VT switch? | 20:25 |
| bryce2 | it leaves the X graphics on the screen | 20:25 |
| bryce2 | doesn't show the console | 20:25 |
| bryce2 | vt switching back to vt7 gets back to functioning X | 20:26 |
| bryce2 | er, vt8 (ctrl-alt-f8) actually. weird | 20:26 |
| Sarvatt | got a dmesg handy? wondering if you are having a similar problem to kklimonda's | 20:28 |
| === Sinnerman is now known as Cobalt | ||
| Sarvatt | hmm /lib/udev/rules.d/78-graphics-card.rules needs an update for lbm-nouveau too | 20:40 |
| bryce2 | apw is working on a new lbm update, should be coming in soon | 20:40 |
| bryce2 | suspend resume failed on nouveau for me | 20:41 |
| bryce2 | (at least, I couldn't get it to resume) | 20:41 |
| Sarvatt | theres going to be so many places we need to update the checks for nouveau to lbm-nouveau like this udev rule :( | 20:42 |
| Sarvatt | http://paste.ubuntu.com/369097/ | 20:45 |
| bryce2 | Sarvatt, might be useful to compile a list | 20:46 |
| Sarvatt | is there any place I should mark changes that need to be made to accomidate lbm-nouveau? i've got a plymouth and a udev patch now that need to be added | 20:46 |
| bryce2 | nothing appears in dmesg after doing the vt switch | 20:46 |
| bryce2 | yeah, we've got a wiki page for tracking these tasks | 20:46 |
| Sarvatt | dmesg | grep "GPU hang" return anything? | 20:46 |
| bryce2 | https://wiki.ubuntu.com/X/Nouveau | 20:47 |
| Sarvatt | ok I'll add a TODO section there and start putting changes on it | 20:47 |
| bryce2 | nope, no GPU hang | 20:47 |
| bryce2 | great | 20:47 |
| Sarvatt | oh should I add it to outstanding issues? | 20:48 |
| bryce2 | Implementation | 20:48 |
| Sarvatt | I was going over libdrm to see if theres anywhere else we are missing that talks to the drm module instead of lbm-drm which is where i caught the udev thing | 20:48 |
| * bryce2 nods | 20:49 | |
| Sarvatt | updated with what i have for now, the list is going to grow alot :D | 20:56 |
| Sarvatt | i'm doing it headless for the most part so i havent tried suspend or vt switching to see if they're screwed up yet :( | 20:59 |
| Sarvatt | we've got the newest nouveau in lbm in the xorg-edgers/nouveau ppa though, updated it yesterday. it's a piece of cake to update thanks to apw's scripts :D | 21:00 |
| Sarvatt | oh boy | 21:02 |
| Sarvatt | theres calls to /proc/dri all over the place that are screwed | 21:02 |
| Sarvatt | because its /proc/lbm-dri/ | 21:02 |
| Sarvatt | RAOF: should we have the /proc/dri calls in xf86drm.c also check /proc/lbm-dri ? | 21:11 |
| Sarvatt | hmm still some /proc/dri stuff in nouveau after munging, ./nouveau/drm_proc.c:DRM_ERROR("Cannot create /proc/dri/%s\n", name); ./nouveau/drm_drv.c:DRM_ERROR("Cannot create /proc/dri\n"); ./nouveau/drm_proc.c:DRM_ERROR("Cannot create /proc/dri/%s/%s\n", | 21:16 |
| Sarvatt | just the error messages though | 21:17 |
| Sarvatt | the udev rules change explains why plymouth was waiting for udev to finish at least | 21:25 |
| Sarvatt | wonder how much it would break things if we just didnt rename everything to lbm-* with this | 21:31 |
| Sarvatt | would be nice to add intel and radeon to this :D | 21:37 |
| kklimonda | huh, has something broke in the last 24 hours or so? I can't boot with nouveau.. I even managed to get a dmesg without seeing anything. http://pastebin.com/f4ae73417 | 21:41 |
| apw | kklimonda, looks like plymouth had you for lunch | 22:07 |
| apw | that has changed recently | 22:07 |
| ara | tseliot, hi! | 23:09 |
| Sarvatt | did you reboot since updating nouveau kklimonda or is that the first time? does it boot ok without splash in the kernel command line? | 23:39 |
| kklimonda | Sarvatt, I've booted with lbm ~pre3 successfully, removing splash from command line doesn't change anything | 23:44 |
| Sarvatt | could you try booting with plymouth:debug added maybe? | 23:44 |
| Sarvatt | looks like thats a new option in the most recent one | 23:44 |
| Sarvatt | just to be sure it was PAE it was working on before and PAE thats the problem now? | 23:46 |
| Sarvatt | nothing else was updated in edgers/nouveau since the nouveau update you said was working :( | 23:47 |
| tseliot | Sarvatt: shall I blacklist both nouveau and nouveau_lbm when using nvidia? | 23:48 |
| Sarvatt | its lbm-nouveau, probably best blacklisting both yeah | 23:49 |
| RAOF | That's probably a good idea. | 23:49 |
| Sarvatt | kklimonda: booting with lbm-drm.debug=6 might have useful info too | 23:50 |
| kklimonda | plymouth:debug or plymouth.debug ? | 23:52 |
| kklimonda | Sarvatt, ^ | 23:52 |
| Sarvatt | plymouth:debug i think it is, let me check | 23:53 |
| Sarvatt | ./src/main.c: || (path = strstr (state->kernel_command_line, " plymouth:debug=file:")) != NULL) | 23:54 |
| Sarvatt | =file is optional i'm pretty sure | 23:55 |
| Sarvatt | btw might want to make this change to /lib/udev/rules.d/78-graphics-card.rules | 23:57 |
| Sarvatt | http://paste.ubuntu.com/369097/ | 23:57 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
