[00:04] persia: Where are you getting this x11-common? I see “debconf (>= 0.5) | debconf-2.0, upstart-job, debianutils (>= 1.13), lsb-base (>= 1.3-9ubuntu2)” as the full list of depends for x11-common=1:7.5+1ubuntu3 [00:05] persia, there haven't been any recent changes to x11-common which would change that [00:05] (at least, not in git) [00:06] Ugh. I can't replicate for some reason. [00:06] I really just saw this with a lucid upgrade (which I didn't perform). [00:06] * persia goes hunting, and apologises for the noise [00:06] no prob [00:26] In case anyone else complains, blame onboard. === virtuald_ is now known as virtuald [02:05] So, we need to put the update-initramfs hook for nouveau in a package somewhere. lbm-nouveau-2.6.whatever would be the obvious choice, but that needs to be parallel-installable, so that'd be awkward. [02:05] The linux-backports-modules-nouveau-lucid-{generic,generic-pae} metapackages from linux-meta would be another option, but they're not set up to actually ship files at all. [02:06] Finally, xserver-xorg-video-nouveau would be possibly the easiest option, but feels a bit wrong because it's not really the same package as the kernel module. [02:15] Does anyone have any firm opinions one way or the other? [02:32] RAOF, no firm opinion [02:32] * bryceh ponders [02:33] don't we run update-initramfs with -nvidia? [02:33] We might, if we now try to blacklist nouveau when we install -nvidia. [02:34] But before then, why would we? nvidia.ko doesn't want to be in the initramfs. [02:34] I think it was being done for removing nouveau [02:34] tseliot would probably be the one to solicit an opinion from [02:35] That would probably be right. We'd need to blacklist nouveau good and early, lest it be in the initramfs and grab the hardware before nvidia. [02:35] right [02:36] * RAOF heads off to send *another* offer to the real estate agent. [02:36] RAOF, i thought you didn't want nouveau to be the default in lucid [02:37] RAOF, aha debian/nvidia-96.postinst.in [02:38] bjsnider, ? [02:39] because nouveau depends on an experimental libdrm [03:18] heh, you're all wasting your time. People will fight anything that means changing any of their current mindset or working practices. Reasons like "we are trying to run a business and making the linux desktop work" are deemed completely irrelevant upstream. All that matters to some people upstream is their own fun and big statements proclaiming how great they are. There is no point discussing, just do the work, and prove things _hard_ an === ubott2 is now known as ubottu [05:40] hmm , something in today's -edgers update makes high Xorg CPU usage if xchat is opened :( [05:40] it turns out that if the progress meter graph is displayed it burns CPU on and ATI [05:42] similar to Bug #355355 [05:42] Launchpad bug 355355 in update-manager "Update Manager causes high Xorg CPU usage when checking for updates" [Medium,New] https://launchpad.net/bugs/355355 [05:43] xorg (1:7.5+1ubuntu2) to 1:7.5+1ubuntu3 [05:43] xserver-xorg (1:7.5+1ubuntu2) to 1:7.5+1ubuntu3 [05:43] xserver-xorg-input-all (1:7.5+1ubuntu2) to 1:7.5+1ubuntu3 [05:43] xserver-xorg-video-all (1:7.5+1ubuntu2) to 1:7.5+1ubuntu3 [05:43] xserver-xorg-video-ati (1:6.12.99+git20100215.47136fa3-0ubuntu0sarvatt) to 1:6.12.99+git20100218.a3b730ec-0ubuntu0sarvatt [05:43] xserver-xorg-video-radeon (1:6.12.99+git20100215.47136fa3-0ubuntu0sarvatt) to 1:6.12.99+git20100218.a3b730ec-0ubuntu0sarvatt [05:43] those were the updates ^ [05:47] oh , not xchat alone .... it happens with _any_ progress bar , if i activate widget factory [which previews themes] Xorg starts to use high CPU [05:53] and only when the progressbar is using the _murrine_ engine [06:11] bryceh: isn't nv needed for the fallback, and for those devices where the server automatically chooses it and not nouveau? [06:12] There are a couple of cards that fall into that category; the rivas at least won't be driven by -nouveau and should be driven by -nv, yeah. [07:56] ah ok [07:58] I think I'll put the kms hook in x-x-v-nouveau for now. Are we aiming for libdrm 2.4.18 for alpha 3, or shall I pass on updating the DDX until after A3? [07:59] I think we should at least do 2.4.18 sans the API bump patch for a3 [08:06] Ok. So I'll look at pulling a newer DDX, changing the dependency to the lbm metapackage (already in git), and putting in the kms hook this evening. [08:16] RAOF, oh, I just changed the dependency to the lbm metapackage [08:17] sorry, didn't realize you'd already done that [08:18] we needed it to get the cd's buildable [08:22] That's fair enough. [08:41] $ git push origin ubuntu [08:41] fatal: The remote end hung up unexpectedly [08:41] ^ that's from trying to push the aforementioned change to the nouveau git tree [08:42] I'll merge it in to my tree locally, if you like [08:42] thanks [10:24] hiya [10:24] so I just had the nouveau driver installed, I rebooted and I just get a black screen [10:26] after a while I get the drum sound of the gdm login, but the monitor doesn't seem to get any signal [10:26] what if you boot without splash? [10:27] could be a plymouth bug [10:30] Why must git-buildpackage mock me? [10:31] Any ideas what's happening here? http://pastebin.ca/1802514 [10:31] tjaalton: same :/ [10:32] RAOF: never used it.. [10:32] dholbach: Do you have a dmesg? Particularly: is vga16fb loaded? [10:32] aniel@bert:~$ dmesg | grep -i vga16fb [10:32] [ 2.211558] vga16fb: initializing [10:32] [ 2.211563] vga16fb: mapped to 0xffff8800000a0000 [10:32] daniel@bert:~$ [10:33] Ding. [10:33] We need to add lbm_nouveau to the initramfs so that it'll take over before vga16fb gets loaded. [10:34] so people upgrading now will "hose" their systems? [10:34] Possibly. [10:35] what do I do now? :-D [10:35] unload the module and load lbm_nouveau instead [10:35] then start gdm [10:36] You could also check that adding this: http://pastebin.com/d7755dc1b to /usr/share/initramfs-tools/hooks/nouveau_kms and make it executable, and run update-initramfs. [10:37] There was a hook in the linux-backports-modules-nouveau package; that seems to have been lost along the way. [10:38] hum, seems I can't rmmod vga16db easily [10:38] how do I find out what "uses it" [10:38] The VTs, I think. [10:38] man, I'm so glad I don't have to do this very often [10:38] dholbach: stop gdm first [10:38] tjaalton: did that already [10:38] ok [10:39] tjaalton: Will that work? His VTs are useing vga16fb, aren't they? [10:39] daniel@bert:~$ sudo rmmod -f vgastate vga16fb [10:39] ERROR: Removing 'vgastate': Resource temporarily unavailable [10:39] ERROR: Removing 'vga16fb': Resource temporarily unavailable [10:39] daniel@bert:~$ [10:40] need to unbind first, i think [10:44] RAOF: [10:44] daniel@bert:~$ sudo update-initramfs -u [10:44] update-initramfs: Generating /boot/initrd.img-2.6.32-13-generic [10:44] woozy: Possible missing firmware /lib/firmware/nouveau/nvac.ctxvals for module lbm_nouveau [10:44] woozy: Possible missing firmware /lib/firmware/nouveau/nvac.ctxprog for module lbm_nouveau [10:44] ... [10:44] ... [10:44] ... [10:45] dholbach: That's ok. That'll mean if you've got a geforce 8 or higher you won't get accel, but it should at least bring up X. [10:45] alright, I'll take the plunge [10:46] Oh! And nothing depends or recommends nouveau-firmware. [10:46] That got lost from linux-backports-modules-nouveau, too. [10:46] grub, a lot of flickering back and forth, "No signal detected", gdm's drum sound, no screen [10:46] * dholbach installs firmware [10:47] grub, less flickering back and forth, "No signal detected", gdm's drum sound, no screen [10:47] daniel@bert:~$ dmesg | grep vga16fb [10:47] [ 2.216952] vga16fb: initializing [10:47] [ 2.216957] vga16fb: mapped to 0xffff8800000a0000 [10:47] daniel@bert:~$ [10:48] RAOF: ^ [10:48] :( [10:49] http://paste.ubuntu.com/379657/ [10:49] detected a tv connector - wow - i didn't even know I had one [10:50] RAOF: does the pastebin tell you anything? [10:53] tjaalton: are you going to update radeon soon? I would like to add this quirk: http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=e68d3a3890fc81c51f2006b5548da1e8756ad2fd81c51fi [10:55] tseliot: Bad object id: e68d3a3890fc81c51f2006b5548da1e8756ad2fd81c51fi [10:56] http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=e68d3a3890fc81c51f2006b5548da1e8756ad2fd [10:56] :) [10:56] tseliot: nah, you can add it on top of the current one as a patch :) [10:56] tjaalton, dholbach: something must have messed with my clipboard [10:57] bryce has handled it so far [10:57] tjaalton: yes, I just wanted to avoid uploading this patch if you had already planned to update the driver [10:57] ok [10:57] I'll do libdrm and mesa [10:57] good [10:58] xserver would probably need a FFe by now :/ [10:58] RAOF, tjaalton: shall I just deinstall those nouveau packages or is there anything I can test? [10:58] actually so does libdrm [10:58] meh [10:58] dholbach: tbh I haven't played with nouveau yet [10:58] tjaalton: the xserver? Why? [10:58] tseliot: 1.7.5 [10:59] dholbach: Final check - was the initramfs you built for the kernel you booted into? [10:59] oh, I missed another release [10:59] tjaalton: if it's only bug fixes I don't think we need a FFE [11:00] tseliot: but will they get stuck in a queue? [11:00] RAOF: let me retry to make sure [11:00] sudo update-initramfs -u -k all [11:00] That should make it happen. [11:01] tjaalton: no, I don't think so [11:01] tseliot: ok cool, I'll upload that as well then [11:01] good [11:02] daniel@bert:~$ ls -l /usr/share/initramfs-tools/hooks/nouveau_kms [11:02] -rwx--x--x 1 root root 242 2010-02-19 11:43 /usr/share/initramfs-tools/hooks/nouveau_kms [11:02] daniel@bert:~$ dmesg | grep vgs16fb [11:02] [ 2.197797] vga16fb: initializing [11:02] [ 2.197801] vga16fb: mapped to 0xffff8800000a0000 [11:02] daniel@bert:~$ [11:02] RAOF: ^ no dice [11:02] why does nouveau conflict with that anyway? [11:02] intel is working ok with it [11:04] And why does booting into recovery mode suddenly make it work, even with vga16fb? [11:04] anything else I could test? [11:04] RAOF: at least plymouth is not used then [11:04] tjaalton: Yeah. [11:04] dholbach: Test without splash? [11:05] I did that [11:05] didn't help either [11:06] does recovery mode work for you, too? [11:07] dholbach: what does this command say? grep nouveau /etc/modprobe.d/* [11:08] tseliot: nothing [11:08] RAOF: let me try [11:08] ok [11:10] RAOF: no dice either [11:10] RAOF: even worse - I can't ssh into it [11:14] tjaalton, RAOF, tseliot: anything else I can try before I remove those packages again? [11:14] to me it sounds like this should at least be in #ubuntu-devel's topic or something [11:14] dholbach: I'm out of ideas.. [11:14] it's going to screw a bunch of people [11:14] I'm out, too. [11:15] if they can't ssh into it from another machine or have a live cd handy they're screwed [11:15] I'll try it on the desktop I have [11:16] dholbach: do you have an X log and the output of dmesg we can have a look at? [11:16] Has the patch to make X autoload nouveau not yet made it into the main packages? [11:17] tseliot: http://people.canonical.com/~dholbach/dmesg http://people.canonical.com/~dholbach/Xorg.0.log [11:17] RAOF: hah, good point [11:18] RAOF: can I try that patch somewhere? [11:18] there we go [11:18] it loads nv [11:18] tjaalton: we don't have an ubuntu branch for radeon, do we? (I bet I asked you the same thing last time I uploaded radeon)? [11:18] I'll upload 1.7.5 merge asap [11:18] tseliot: no [11:18] ok [11:19] if you have the patch, I'm happy to build packages locally to try it out [11:19] dholbach: http://git.debian.org/?p=pkg-xorg/xserver/xorg-server.git;a=commitdiff;h=cfdca8e85ca73f18edaeff1a411e356afac2bc4c [11:19] ..selectively [11:19] dholbach: it looks like you loaded nouveau (the kernel module) but you're using the "nv" X driver [11:20] I've just booted up my laptop; it's booted fine, and is using nv successfully with the nouveau kernel module loaded. [11:20] dholbach: maybe try creating this xorg.conf? http://pastebin.ubuntu.com/379673/ [11:21] hmm... [11:21] Oh, whoops. I think because I've got the initramfs hook. [11:23] RAOF: the hook that I have? [11:23] tseliot: I'll try tjaalton's patch first (just building), if that fails, I try that xorg.conf [11:24] dholbach: The hook that you have, yes. [11:24] dholbach: oh, I missed that patch. That should work [11:25] tseliot: I haven't lost hope yet :) [11:25] that's the spirit ;) [11:26] Rebuilding the initramfs with that hook made it work for me. [11:28] And, again, booting without “quiet splash” works, ish for me. [11:34] new xserver installed [11:34] let's see what happens [11:34] yeeeeeeeeehaw [11:34] Win? [11:34] yep [11:34] let's get all those changes uploaded asap [11:35] the firmware change, the added initramfs hook and the xserver patch [11:35] Why does vga16fb get loaded anyway? [11:35] xorg-xserver [11:35] I dunno, but right now people who upgrade and restart will get bitten [11:36] xorg-server uploaded [11:41] thanks guys for fixing this [11:47] tjaalton: I've got a nouveau with the initramfs hook and updated to build against libdrm 2.4.18. I'm just test-building it. [11:47] RAOF: so I should basically drop all the patches you added, and revert the two commits? [11:47] Yes. [11:48] right [11:48] I can extract out the update requiring 2.4.18 if libdrm will take a while. [11:49] no I'm on it [11:50] hmm, what's the best way to generate a reverse patch? [11:50] git show foo > ... [11:51] git revert, git format-patch, git reset --hard? [11:51] That'd work. git revert foo; git show foo'scommit [11:56] maybe I'm not doing it hard enough, stops right away [11:56] hmm, patch -R could be useful [11:57] then git diff [12:04] radeon uploaded [12:05] one hunk failed, otherwise it worked [12:10] right, needed to revert the smaller commit first [12:21] RAOF: libdrm pushed and uploaded [12:21] tjaalton: xserver-xorg-video-nouveau in alioth git should be ready to go, too. [12:22] But I can't upload it, 'cause it's in main. [12:23] RAOF: ok, I'll upload it too [12:23] Thanks. It's getting late here - you might want to give it a quick sanity check first. [12:24] sure [12:24] "if it builds, ship it" [12:24] :P [12:24] Well, it certainly builds, I can check that mechanically :) [12:24] And with that, I bid goodnight. Thanks! [12:25] thank you [12:32] oh bah, forgot to build-check libdrm. missing symbols [12:34] well, symbol [13:54] RAOF: what is going to depend on nouveau-firmware? [13:54] and where is usr/share/initramfs-tools/hooks/nouveau_kms going to live? [13:57] the hook comes with xserver-xorg-video-nouveau [13:58] I think the lbm package should depend on the firmware, not sure though [13:59] isn't that ... like ... very important stuff? :) [13:59] yes [14:00] ask on #ubuntu-kernel :) [14:00] naah, who wants a working graphics driver these days :-P [14:00] totally overrated [14:00] absolutely [14:00] I'll have my terminal kthxbye [14:03] tjaalton: does it make sense for the hook to come in the xorg driver package? is nouveaufb unusable without xorg driver for some reason? [14:14] kklimonda: that's where RAOF put it, probably because he could touch the package more easily [14:14] ach, I see [15:14] tjaalton, the x userspace for i915 will that cope with a .33 kernel? [15:41] yes [15:56] apw: right [15:58] apw: aiui there should be no abi breaks anymore, at least planned ones, apart from the nouveau one we talked about [15:58] tjaalton, we need to understand the scope of the patches this nouveu stuff is going to drop on us [16:01] apw: it only touches nouveau [16:02] and the upstream ddx needs it [16:02] yes. but i need to understnad the maintenance issues it will cause for us if we have that on top of the other backports we are contemplating [16:02] who would be able to point me at what is needed [16:03] so backporting fixes will be tough without it [16:03] sorry being slow, baby on lap, [16:03] duh [16:03] and cant type on my e71 [16:04] apw: RAOF is the one on top of things [16:04] and tracking any stable upstream branches will be hard with it, so i need to know what it looks like to try and figure out how much pain it represents [16:06] there was no nouveau in .32, so the stable branch will be a non-issue :) [16:07] tjaalton, and there will be in the .33 stable branch [16:07] which is why it matters [16:11] maybe airlied could answer that [16:12] if there will be nouveau fixes in .33.x [16:16] since there is no released ddx/libdrm with the .33 abi [16:17] so it would feel pointless to add nouveau fixes on the stable branch === yofel_ is now known as yofel [18:15] RAOF: any ideas about this? http://launchpadlibrarian.net/39392763/buildlog_ubuntu-lucid-i386.linux-backports-modules-2.6.32_2.6.32-13.999~git20100218~xorgedgers_FAILEDTOBUILD.txt.gz [18:15] not having any luck building nouveau with the new api [18:15] argh gotta disappear again, so busy the past few days [18:18] if anyone is still getting the sigquit and gdm restart after pressing enter the first boot issue, can you try compiling this kernel module and loading it before reproducing it? I can't make it happen anymore http://sarvatt.com/downloads/trace-signal.c [18:19] compile instructions at the top of the source [18:34] hey all if I remove the nvidia driver in lucid does x automagicly fall back to nouveau? [18:34] I want to test it im just wondering if its as easy as removing the other driver [19:07] Sarvatt, looks like lbm_list_sort was defined once and then redefined again as something different [19:07] that's bizarre [19:18] there is no list sort in the nouveau tree, i had to grab that stuff from linux-2.6 in the update-nouveau script [19:19] fagan: if you have xserver 1.7.5-1ubuntu1 thats all you need, if not you need nouveau in xorg.conf [19:27] one of the deaders you're loading has list sort. two, actually [19:27] headers [19:37] window redraws are so darn slow with this newest gtk+ that has client side decorations enabled [20:01] Sarvatt, RAOF, apw put together another backports module for testing: http://people.canonical.com/~apw/drm-backport-lucid/ [20:02] i have some reports of it working ok, even with the nouveau bits if you blacklist the lbm-nouveau [20:02] er, actually that's a backport of drm .33 to the .32 kernel not an lbm [20:02] thats what i mean, if you have lucid with the lbm, if you blacklist that, then the kernel one seems to work [20:02] Sarvatt, RAOF, so I think to incorporate this for Lucid, we'd merely need to remove some of the lbm_ hacks we'd put in earlier [20:03] i think the lbm hacks must have been 'try both' style hacks so we might not need to remove them even [20:03] I'm thinking we might wait until right after alpha-3 to upload this stuff, since getting it into a3 would be kind of a rush [20:04] bryceh, yeah the kernel is done for a-3 [20:05] apw, think we need a FFe for this stuff? [20:05] we should get together on monday, and go over the testing we have by then and make a final go/no-go decision on this one [20:05] ok, that sounds good [20:05] i don't think we get any new features do we, just working things which didn't [20:06] but we can ask on monday once we've deciced where we are going [20:06] * bryceh nods [20:06] dunno if we can get a test matrix filled or something, i have some of my boys testing [20:06] just to get a feel ... i'd like to have at least all of us tested on everything we have [20:07] we can continue using https://wiki.ubuntu.com/X/Testing/NouveauEvaluation for the test matrix [20:07] I stuck in a date column exactly because I anticipated we'd be making changes as we go [20:08] yeah in the meantime we might want to collect the ones with my kernel in a new table at the bottom and integrate them once we 'go' [20:08] apw, ok [20:09] so we can see what has been tested easy to help decision makeing [21:08] '(12:55:21 PM) mwk: DanaG: upgrade libdrm, recompile DDX (12:56:44 PM) DanaG: libdrm2 version is 2.4.18+git20100217.2d9990c7 (12:57:35 PM) DanaG: ddx is 0.0.15+git20100219+9b4118d (12:58:31 PM) DanaG: What's new since then? [21:08] is xorg-edgers ppa not new enough? [21:09] xorg log: http://pastebin.com/d7f22c765 [21:18] apw: airlied said that there probably will be nouveau updates in .33.x, since F12 has that [21:45] * bryceh sends email to ubuntu-x@ about -nouveau and begins the count for how long until it appears on phoronix [21:46] tjaalton, yeah, I think apw has some skepticism. Guess we'll see [21:46] tjaalton, btw how did the libdrm merge go? [21:47] hmm, for nouveau help on lucid, is this channel okay? Nobody's answered in #ubuntu+1. [21:48] bryceh: it wasn't that hard, just had to make sure the revert patch was flawless [21:48] DanaG, this is more of a developer/integrator channel, but feel free to ask about nouveau and if someone knows they'll chip in with an answer [21:49] DanaG: nouveau in edgers is broken due to the abi change [21:49] aah. So it'll be fixed eventually? [21:50] yes [21:50] though lucid has most of it [21:50] already [21:50] and is working I hear [21:50] only most? [21:50] apart from the abi change [21:50] ah right, only the non-broken parts ;-) [21:51] yep, and what's on top of that [21:51] I did think it odd that it said it opened it successfully (got "10"), and then said it failed to open. [22:16] heh, already on phoronix - http://www.phoronix.com/scan.php?page=news_item&px=ODAwMg [22:17] night [22:17] guys need your help [22:18] after the last batch of updates to X and nouvoue the upgrade complains of no firmware [22:18] and i cant start GDM/X [22:19] Sarvatt: RAOF: ^^^^^^ [22:24] $ pastebinit Xorg.0.log http://paste.ubuntu.com/379998/ [22:24] $ pastebinit Xorg.0.log.old http://paste.ubuntu.com/379999/ [22:24] $ pastebinit Xorg.1.log http://paste.ubuntu.com/380000/ [22:33] using Sarvatt ppa-purge [22:33] Errors were encountered while processing: nvidia-current nvidia-glx-185 E: Sub-process /usr/bin/dpkg returned an error code (1) [23:21] i'm back [23:21] no X [23:22] not even recovery console [23:25] BUGabundo, try installing the nouveau-firmare package [23:25] fmarl: will do [23:26] shouldnt it be pulled as a depency ? [23:27] I dunno.. [23:36] the firmware it's optional depending on the video card [23:37] ok [23:37] still upgrading to PPA, again [23:37] lets see if that saves me [23:38] BUGabundo: xorg-edgers is broken for nouveau right now until I can get the linux-backports-modules-nouveau built with the api changes [23:39] BAHABAAB [23:39] i just upgraded :( [23:39] Sarvatt: alternatives? [23:39] the stuff already in lucid [23:40] didnt work [23:40] i just tried that [23:40] compile from source :) [23:40] vesa only, once i tried jockey all hell broke lose [23:40] you installed the nouveau-firmware package? [23:40] not yet [23:40] i have all the logs here [23:40] its just not a depends yet like it needs to be [23:40] if u wnat to take a pic [23:40] *peak [23:41] so purge PPAs (again), initram the kernel, boot vesa, install fw, then jokey? [23:41] sorry man, I really dont have much time to debug it at the moment :( [23:41] np [23:41] purge ppa, install nouveau-firmware and you're good to go [23:42] just give me an working X at full resolution [23:42] thanks [23:42] can purge-ppa do both at the same time? [23:42] maybe remove "quiet splash" from the kernel command line if that doesnt work [23:42] do both what? [23:42] already dod that [23:43] Sarvatt: ppa-purge both nouveua and xedgers [23:43] oh you have both PPAs? afraid not, the script is broken at the moment and only works for whatever/ppa [23:43] but everything in xorg-edgers/nouveau should be supersceded by stuff in lucid already [23:44] ok [23:44] yep it is [23:44] # ppa-purge xorg-edgers, it is [23:45] The following packages will be DOWNGRADED: libdrm-intel1 libdrm-nouveau1 libdrm-radeon1 libdrm2 libgl1-mesa-dri libgl1-mesa-glx libglu1-mesa mesa-utils xserver-xorg-input-evdev xserver-xorg-input-synaptics xserver-xorg-video-ati xserver-xorg-video-fbdev xserver-xorg-video-intel xserver-xorg-video-radeon xserver-xorg-video-sis [23:46] no xorg-server-core and such? [23:46] xserver-xorg-core i mean [23:47] The following extra packages will be installed: intel-gpu-tools libdrm-intel1 libdrm-nouveau1 libdrm-radeon1 libdrm2 libgl1-mesa-dri libgl1-mesa-glx libglu1-mesa mesa-utils xserver-xorg-input-evdev xserver-xorg-input-synaptics xserver-xorg-video-ati xserver-xorg-video-fbdev xserver-xorg-video-intel xserver-xorg-video-radeon xserver-xorg-video-sis Suggested packages: libglide3 gpointing-device-settings touchfreeze firmware-linux [23:47] i did notice i had no Xorg last time [23:47] oh xserver in lucid is a higher version already [23:48] nouveau-firmware next [23:48] The following packages will be REMOVED: libx11-xcb1{u} libxcb-dri2-0{u} [23:48] but nothing installed [23:50] nouveau-firmware: Installed: 20091212-0ubuntu1 [23:50] xserver-xorg-video-intel in edgers had those as depends for XvMC support, no biggie [23:50] seems i already had it [23:50] # dpkg -l | grep xorg | pastebinit http://pastebin.com/d2631efb4 [23:51] # dpkg -l | grep nvid ii nvidia-current-modaliases 195.36.03-0ubuntu1 [23:51] ok it looks like the libdrm in lucid now doesnt have the lbm-nouveau patch to it [23:52] going for another reboot [23:52] sorry BUGabundo, it probably wont work [23:52] hope to be rigt back [23:52] what?! [23:52] why !? [23:53]