[00:38] <Sarvatt> do chroot problems on launchpad automatically give back builds? no retry button and everything tormod uploaded an hour ago failed on amd64
[04:03] <Sarvatt> 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] <Sarvatt> in /lib/modules/2.6.32-7-generic/modules.alias
[04:07] <Sarvatt> guess I should bring that up in #ubuntu-kernel instead :D
[04:12] <Sarvatt> also with the udev stuff in xserver, Amaranth is having his applesmc (accelerometer) getting recognized as a joystick and moving his mouse
[04:34] <Sarvatt> ack, that vga16fb change in 2.6.32-7 is making ALL kms stop working
[04:39] <RAOF> Sarvatt: Want to try my 2.6.32-7 kernel that builds nouveau in-tree?  _That_ works :)
[04:40] <RAOF> Amaranth: Can you now control your mouse by orienting your laptop?  Sweet!
[04:40] <Amaranth> RAOF: heck yeah
[04:41] <Sarvatt> RAOF: the bug actually is the vga16fb change making _all_ KMS stop working on 2.6.32-7
[04:41] <Amaranth> 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] <Sarvatt> radeon nouveau and intel
[04:41] <RAOF> Sarvatt: Which is strange, because my 2.6.32-7 kernel appears to work fine?
[04:41] <Amaranth> and I have to use KMS now since the intel driver doesn't support anything else
[04:41] <RAOF> Is this a newer kernel than 2.6.32-7.10?
[04:41] <Sarvatt> yeah it will if your userspace works with UMS
[04:42] <Sarvatt> xorg-edgers intel doesnt have UMS support anymore :(
[04:42] <Amaranth> right, which is alright since pommed works for my backlight
[04:43] <Sarvatt> sudo cat /sys/module/i915/parameters/modeset
[04:43] <Sarvatt> or radeon or nouveau instead of i915
[04:43] <Amaranth> Sarvatt: -1
[04:43] <Sarvatt> yep UMS :(
[04:43] <Amaranth> err, what?
[04:43] <Sarvatt> it would be 1 if you were using KMS
[04:44] <Amaranth> I can assure you I'm using KMS, my terminals look awesome
[04:44] <Amaranth> and if I boot with i915.modeset=0 I can't even get X
[04:44] <Amaranth> oh, and VT switching just crashed my fonts :/
[04:44] <Sarvatt> are you using xorg-edgers or ubuntu?
[04:44] <Amaranth> xorg-edgers
[04:45] <Sarvatt> dmesg | grep inteldrmfb
[04:45] <Sarvatt> says its loaded?
[04:45] <Amaranth> I can't tell what you said
[04:45] <Amaranth> [    2.212605] fb0: inteldrmfb frame buffer device
[04:46] <Amaranth> I can't tell what I said either
[04:46] <Amaranth> is that good?
[04:48] <Amaranth> oddly the fonts in chromium still look just fine
[04:48] <Sarvatt> yep, must be something else about it then
[04:48] <Sarvatt> i can't use 2.6.32-7, having that fb1 as a vga16fb screws things up
[04:49] <Sarvatt> oh yeah, that applesmc being a joystick thing is supposed to be a _feature_ :D
[04:49] <Sarvatt> i guess there was a hal fdi filtering it out or something before?
[04:50] <Sarvatt> googled it and people wanted to use it as a joystick for neverball
[04:50] <Amaranth> yeah, must have been a hal thing filtering it
[04:50] <Amaranth> brb, restarting X
[04:52] <Amaranth> ah, there we go
[04:52] <Amaranth> I blindly trusted what you told me to run in a terminal, couldn't read it at all :P
[04:53] <Sarvatt> inteldrmfb = a KMS framebuffer, it wouldn't say that if you didnt have KMS working
[04:54] <Amaranth> yeah
[04:55] <Amaranth> oh, fun fact, X crashes 2 or 3 times every time gdm tries to start
[04:55] <Amaranth> 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] <RAOF> Still disabled in Lucid, isn't it?
[04:59] <Amaranth> yeah, that's going to be bad
[04:59] <Amaranth> alpha 1 is going to be worthless wrt to people finding crashes
[04:59] <Amaranth> anyway, bed time for me
[05:00] <Sarvatt> 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] <Sarvatt> hyperair: got an magic fixes for a wildly unstable geany? :D
[05:57] <hyperair> Sarvatt: what's up with geany?
[06:00] <Sarvatt> 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] <Sarvatt> maybe it just needs a rebuild against the new gtk+
[06:02] <Sarvatt> building the newest svn anyway, hoping that works
[06:07] <Sarvatt> nope :(
[06:08] <hyperair> looks like a gtk issue O_o
[06:08] <hyperair> i haven't noticed anything of this sort
[11:59] <seb128> hey there
[11:59] <seb128> does anybody know what code read locale.alias? and why that's done several time?
[11:59] <seb128> oe
[12:00] <seb128> ie
[12:00] <seb128> $ strace -e open xeyes 2>&1 | grep locale.alias
[12:00] <seb128> open("/usr/share/X11/locale/locale.alias", O_RDONLY) = 4
[12:00] <seb128> open("/usr/share/X11/locale/locale.alias", O_RDONLY) = 4
[12:00] <seb128> open("/usr/share/locale/locale.alias", O_RDONLY) = 4
[12:00] <seb128> ...
[12:05] <seb128> hum, same question about .ICEauthority
[12:37] <tjaalton> seb128: the latter is gnome specific AIUI
[12:37] <tjaalton> locale.alias comes from libx11
[14:13] <seb128> tjaalton, the .ICEauthority comes from libICE
[14:16] <tjaalton> seb128: heh, ok
[18:01] <tjaalton> heh, linus demands redhat to merge nouveau drm in the kernel
[18:01] <tjaalton> on dri-devel@
[18:19] <Sarvatt> ohh i gotta check that thread out :D
[18:36] <Amaranth> heh, less flames from linus then I expected
[18:38] <Duke`> I often got freezes with recent drm when fast scrolling in firefox, is it a know issue?
[18:41] <tjaalton> Duke`: how recent? haven't heard of such
[18:42] <Duke`> well I haven't tracked this bug a lot, but if I remember it started to appear begining december
[18:42] <Duke`> I have to revert to 2009-11-25's version to get back driver stability
[18:43] <Duke`> 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] <Duke`> I can still switch to another tty to reboot properly
[18:44] <tjaalton> on lucid?
[18:57]  * Amaranth should figure out what pommed is doing to change his brightness
[18:58] <Amaranth> Need to get that to the intel guys so they can make this all work without hacks
[19:04] <Sarvatt> we might even get nouveau in 2.6.33 at this rate :D
[19:16] <tjaalton> Sarvatt: yeah, I think Linus has a point..
[19:18] <Duke`> tjaalton, no on karmic
[19:18] <Duke`> 64 bits
[19:19] <tjaalton> Duke`: so a kernel update broke it?
[19:20] <tjaalton> best to file it against linux
[19:20] <tjaalton> and mention that it's a regression
[19:20] <Sarvatt> he's using edgers, intel has been really unstable since the beginning of november, alot of speedup related things really destabalizing things
[19:20] <Sarvatt> and getting reverted
[19:23] <tjaalton> ok
[19:24] <Sarvatt> Duke`: 11-25 works for you? you dont have really bad rendering problems with it? are you on a 965+ maybe?
[19:24] <Duke`> Sarvatt, no problem with it (945), but just the libdrm2 and libdrm-intel! I have the latest xorg-video-intel
[19:25] <Sarvatt> do you see alignment errors in dmesg?
[19:26] <Sarvatt> ah 11-25 is the oldest libdrm you could even possibly use with the intel ddx from git
[19:27] <Duke`> ah
[19:27] <Sarvatt> what kernel are you using?
[19:27] <Duke`> 2.6.32
[20:36] <Sarvatt> 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] <Sarvatt> oh the irony of the patch name in #xorg-devel :D
[22:29] <Sarvatt> only 91 more places to change 185 to 195 in debian/ for a new nvidia package now, yay
[22:31] <johanbr> :)
[22:31] <johanbr> I hope you're using sed
[22:32] <Sarvatt> if i did i wouldnt see all these other dependency versions that need to be bumped in control
[22:32] <Sarvatt> Conflicts: nvidia-glx-180 (<< 185.18.32)....
[22:33] <Sarvatt> 185 is called Source: nvidia-graphics-drivers-180.. so convoluted
[22:35] <Sarvatt> tempted to just call it nvidia-graphics-drivers-180 (185.18.36+really195.22) for the PPA to make it easy :)
[22:41] <Sarvatt> 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] <johanbr> 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] <superm1> Sarvatt, i thought you just have to change it in one place, and it updates all the others?
[22:49] <superm1> at least that's how it's supposed to work...
[22:49] <superm1> I personally think that package needs some major cleanup though.
[22:49] <RAOF> johanbr: Sweet.  Is that with or without vga16fb loaded?
[22:50] <johanbr> RAOF, not sure... whatever the default is, probably
[22:51] <johanbr> I didn't mess with any frame buffer modules myself, anyway
[22:51] <RAOF> 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] <johanbr> I am using the current Lucid kernel
[22:52] <Sarvatt> 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] <johanbr> but I had nouveau working well... this was in X, after having done several suspend/resume cycles
[22:52] <RAOF> Then vga16fb probably made nouveau quite unhappy, by writing stuff to the card behind its back.
[22:52] <johanbr> ahh, okay
[22:52] <Sarvatt> 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] <johanbr> so vga16fb wouldn't necessarily interfere with X operation?
[22:53] <RAOF> No; although it appeared to sometimes cause corrupted EXA in X for me.
[22:53] <johanbr> alright... I'll try blacklisting vga16fb
[22:53] <RAOF> Some boots it would work fine, some boots all sorts of icons would be replaced by random parts of the framebuffer.
[22:53] <superm1> Sarvatt, we really should get it to the point that it doesn't need those values hardcoded in so many places
[22:54] <Sarvatt> 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] <superm1> 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] <Sarvatt> 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] <superm1> yup, i don't doubt it
[22:58] <RAOF> 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] <Sarvatt> 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] <Sarvatt> 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] <Sarvatt> if it actually supported more cards than -nv maybe..
[23:03] <Sarvatt> or we had gallium packaged :)
[23:05] <Sarvatt> is the blob packaging in git or bzr anywhere?
[23:05]  * Sarvatt doesn't understand the point of this debian.binary folder
[23:05] <RAOF> Sarvatt: My understanding is that it _does_ support more cards than nv?  Doesn't support old nvidia?  You mean pre TNT2?
[23:12] <Sarvatt> 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] <RAOF> 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] <Sarvatt> nv doesn't either in the actual driver, thats a debian packaging thing
[23:17] <RAOF> Oh, that's just so X will actually load nv?
[23:18] <Sarvatt> 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] <Sarvatt> 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] <Sarvatt> 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