[00:38] do chroot problems on launchpad automatically give back builds? no retry button and everything tormod uploaded an hour ago failed on amd64 [04:03] looks like nouveau isn't working on 2.6.32-7 because a modalias for vga16fb was added to match all gpus just after gpu modules get checked, but nouveau builds later and is at the end of the list [04:04] in /lib/modules/2.6.32-7-generic/modules.alias [04:07] guess I should bring that up in #ubuntu-kernel instead :D [04:12] also with the udev stuff in xserver, Amaranth is having his applesmc (accelerometer) getting recognized as a joystick and moving his mouse [04:34] ack, that vga16fb change in 2.6.32-7 is making ALL kms stop working [04:39] Sarvatt: Want to try my 2.6.32-7 kernel that builds nouveau in-tree? _That_ works :) [04:40] Amaranth: Can you now control your mouse by orienting your laptop? Sweet! [04:40] RAOF: heck yeah [04:41] RAOF: the bug actually is the vga16fb change making _all_ KMS stop working on 2.6.32-7 [04:41] oh, and pommed can control my backlight when using KMS so I guess whatever it does needs to be ported to the kernel to provide backlight support [04:41] radeon nouveau and intel [04:41] Sarvatt: Which is strange, because my 2.6.32-7 kernel appears to work fine? [04:41] and I have to use KMS now since the intel driver doesn't support anything else [04:41] Is this a newer kernel than 2.6.32-7.10? [04:41] yeah it will if your userspace works with UMS [04:42] xorg-edgers intel doesnt have UMS support anymore :( [04:42] right, which is alright since pommed works for my backlight [04:43] sudo cat /sys/module/i915/parameters/modeset [04:43] or radeon or nouveau instead of i915 [04:43] Sarvatt: -1 [04:43] yep UMS :( [04:43] err, what? === _stink__ is now known as _stink_ [04:43] it would be 1 if you were using KMS [04:44] I can assure you I'm using KMS, my terminals look awesome [04:44] and if I boot with i915.modeset=0 I can't even get X [04:44] oh, and VT switching just crashed my fonts :/ [04:44] are you using xorg-edgers or ubuntu? [04:44] xorg-edgers [04:45] dmesg | grep inteldrmfb [04:45] says its loaded? [04:45] I can't tell what you said [04:45] [ 2.212605] fb0: inteldrmfb frame buffer device [04:46] I can't tell what I said either [04:46] is that good? [04:48] oddly the fonts in chromium still look just fine [04:48] yep, must be something else about it then [04:48] i can't use 2.6.32-7, having that fb1 as a vga16fb screws things up [04:49] oh yeah, that applesmc being a joystick thing is supposed to be a _feature_ :D [04:49] i guess there was a hal fdi filtering it out or something before? [04:50] googled it and people wanted to use it as a joystick for neverball [04:50] yeah, must have been a hal thing filtering it [04:50] brb, restarting X [04:52] ah, there we go [04:52] I blindly trusted what you told me to run in a terminal, couldn't read it at all :P [04:53] inteldrmfb = a KMS framebuffer, it wouldn't say that if you didnt have KMS working [04:54] yeah [04:55] oh, fun fact, X crashes 2 or 3 times every time gdm tries to start [04:55] then it loads but if I type my password incorrectly it crashes a couple more times [04:55] * Amaranth wonders where apport is [04:58] Still disabled in Lucid, isn't it? [04:59] yeah, that's going to be bad [04:59] alpha 1 is going to be worthless wrt to people finding crashes [04:59] anyway, bed time for me [05:00] RAOF: i think its something specific to that guys hardware he's using nouveau on, the vga16fb doesn't interfere with nouveau KMS here, just checked it [05:53] hyperair: got an magic fixes for a wildly unstable geany? :D [05:57] Sarvatt: what's up with geany? [06:00] crashing when i build 1/10 times or so, getting Gtk:ERROR:/build/buildd/gtk+2.0-2.19.1/gtk/gtkfilesystemmodel.c:295:emit_row_changed_for_node: assertion failed: (id < (model)->files->len) [06:01] maybe it just needs a rebuild against the new gtk+ [06:02] building the newest svn anyway, hoping that works [06:07] nope :( [06:08] looks like a gtk issue O_o [06:08] i haven't noticed anything of this sort [11:59] hey there [11:59] does anybody know what code read locale.alias? and why that's done several time? [11:59] oe [12:00] ie [12:00] $ strace -e open xeyes 2>&1 | grep locale.alias [12:00] open("/usr/share/X11/locale/locale.alias", O_RDONLY) = 4 [12:00] open("/usr/share/X11/locale/locale.alias", O_RDONLY) = 4 [12:00] open("/usr/share/locale/locale.alias", O_RDONLY) = 4 [12:00] ... [12:05] hum, same question about .ICEauthority [12:37] seb128: the latter is gnome specific AIUI [12:37] locale.alias comes from libx11 [14:13] tjaalton, the .ICEauthority comes from libICE [14:16] seb128: heh, ok === mac_v_ is now known as mac_v [18:01] heh, linus demands redhat to merge nouveau drm in the kernel [18:01] on dri-devel@ [18:19] ohh i gotta check that thread out :D [18:36] heh, less flames from linus then I expected [18:38] I often got freezes with recent drm when fast scrolling in firefox, is it a know issue? [18:41] Duke`: how recent? haven't heard of such [18:42] well I haven't tracked this bug a lot, but if I remember it started to appear begining december [18:42] I have to revert to 2009-11-25's version to get back driver stability [18:43] when the problem happens, there's a ton of error messages in dmesg in relation with drm and gem, and the GPU is screwed [18:43] I can still switch to another tty to reboot properly [18:44] on lucid? [18:57] * Amaranth should figure out what pommed is doing to change his brightness [18:58] Need to get that to the intel guys so they can make this all work without hacks [19:04] we might even get nouveau in 2.6.33 at this rate :D [19:16] Sarvatt: yeah, I think Linus has a point.. [19:18] tjaalton, no on karmic [19:18] 64 bits [19:19] Duke`: so a kernel update broke it? [19:20] best to file it against linux [19:20] and mention that it's a regression [19:20] he's using edgers, intel has been really unstable since the beginning of november, alot of speedup related things really destabalizing things [19:20] and getting reverted [19:23] ok [19:24] Duke`: 11-25 works for you? you dont have really bad rendering problems with it? are you on a 965+ maybe? [19:24] Sarvatt, no problem with it (945), but just the libdrm2 and libdrm-intel! I have the latest xorg-video-intel [19:25] do you see alignment errors in dmesg? [19:26] ah 11-25 is the oldest libdrm you could even possibly use with the intel ddx from git [19:27] ah [19:27] what kernel are you using? [19:27] 2.6.32 [20:36] tormod: if you read the ubuntu-x log before you push some updates I updated the xserver hooks to grab the patches from people.ubuntu.com instead of my server, not sure if i'm going to renew the vps this year and it went down for a bit today [21:06] oh the irony of the patch name in #xorg-devel :D [22:29] only 91 more places to change 185 to 195 in debian/ for a new nvidia package now, yay [22:31] :) [22:31] I hope you're using sed [22:32] if i did i wouldnt see all these other dependency versions that need to be bumped in control [22:32] Conflicts: nvidia-glx-180 (<< 185.18.32).... [22:33] 185 is called Source: nvidia-graphics-drivers-180.. so convoluted [22:35] tempted to just call it nvidia-graphics-drivers-180 (185.18.36+really195.22) for the PPA to make it easy :) [22:41] oh dang, nvidia-settings never even got bumped in karmic even though the xv values changed and it was screwing it up huh [22:46] yikes... when I tried to switch to a tty, nouveau wedged the card hard enough that I had to install the blob to get back to a working state [22:49] Sarvatt, i thought you just have to change it in one place, and it updates all the others? [22:49] at least that's how it's supposed to work... [22:49] I personally think that package needs some major cleanup though. [22:49] johanbr: Sweet. Is that with or without vga16fb loaded? [22:50] RAOF, not sure... whatever the default is, probably [22:51] I didn't mess with any frame buffer modules myself, anyway [22:51] johanbr: If you're using Lucid's current kernel, then it's loading vga16fb, and if that gets loaded first it makes nouveau quite unhappy. [22:51] I am using the current Lucid kernel [22:52] if i'm not misunderstanding how it builds that only works right for the same major version? (like 185.xx to 185.yy) [22:52] but I had nouveau working well... this was in X, after having done several suspend/resume cycles [22:52] Then vga16fb probably made nouveau quite unhappy, by writing stuff to the card behind its back. [22:52] ahh, okay [22:52] i mean its got stuff to update the dependencies in the .in's but nothing changes the names of the actual packages or anything in all these files that i can see [22:52] so vga16fb wouldn't necessarily interfere with X operation? [22:53] No; although it appeared to sometimes cause corrupted EXA in X for me. [22:53] alright... I'll try blacklisting vga16fb [22:53] Some boots it would work fine, some boots all sorts of icons would be replaced by random parts of the framebuffer. [22:53] Sarvatt, we really should get it to the point that it doesn't need those values hardcoded in so many places [22:54] someone in #ubuntu+1 last night couldn't even boot unless he disabled vga16fb on his machine.. it works ok on mine but i havent tried to vt switch yet actually [22:54] i think it's ridiculous to have to update so much for simply a newer version [22:54] * RAOF just deleted the module. [22:57] its screwing up alot of people using sketchy PPA packages (because its so hard to update) then upgrading their ubuntu version and having it mess up too, seen a ton of bugs where thats happened and people blame ubuntu for it [22:57] yup, i don't doubt it [22:58] I should ask apw whether there's anything more I can usefully do to help get nouveau in lucid's kernel. Then, make nouveau magically as good a 3d driver as nvidia, then we drop the blob, and have cake! [23:00] nouveau is going to cause 100x more problems than there already are, I think its crazy to switch to the headache that is nouveau just for people to install the blob personally lol [23:01] only works with KMS on some generations but not others, doesnt support old nvidia, if it was me I'd rather just use vesa for the initial install until I could install the blob [23:03] if it actually supported more cards than -nv maybe.. [23:03] or we had gallium packaged :) [23:05] is the blob packaging in git or bzr anywhere? [23:05] * Sarvatt doesn't understand the point of this debian.binary folder [23:05] Sarvatt: My understanding is that it _does_ support more cards than nv? Doesn't support old nvidia? You mean pre TNT2? [23:12] i haven't compared the detection to nv's in 6 months or so but it didnt before, and yeah i mean those old cards and IGP's we have patched into and working -nv [23:16] Nouveau doesn't have the same detection code; it doesn't rely on a list of PCIIDs like nv does. It's entirely possible that nouveau is significantly worse on IGPs, though; I've not had experience there, but they seem more problematic. [23:16] nv doesn't either in the actual driver, thats a debian packaging thing [23:17] Oh, that's just so X will actually load nv? [23:18] yeah it has a big list of pci ids that debian/ubuntu pull the pci.ids out of but theres a further section that has entire ranges of pci ids that can be used generically based on generation and another section that looks behind an agp/pci-e bridge chip pci id that gets reported to see the actual chips id [23:24] i have no idea what everythings like now though, been a long time since i looked at it. fedora has a xserver patch with all the special pci id range exceptions they do for nouveau though, would dig it up if it didnt take a year to load their cvs on an atom cpu :D [23:29] hmm, guess nouveau did have some problems with vga16fb.. [ 24.304799] [drm:drm_mode_getfb] *ERROR* invalid framebuffer id and in the xorg log [ 1.476598] (WW) NOUVEAU(0): Failed to retrieve fbcon fb: id 0