[05:44] <mlankhorst> g'morning
[06:15] <tjaalton> boo, mesa 9.1 crashes nouveau on suspend
[06:16] <mlankhorst> I'm not sure that's mesa's fault..
[06:17] <mlankhorst> what exactly is the error?
[06:18] <mlankhorst> you could try [PATCH] drm/nouveau: idle all channels before suspending -- it's a hack but meh
[06:19] <tjaalton> bug 1168900
[06:19] <ubottu> bug 1168900 in mesa (Ubuntu) "Xorg crashes after suspension with Mesa 9.1.1-0ubunt0.3" [Undecided,Incomplete] https://launchpad.net/bugs/1168900
[06:19] <tjaalton> i should be able to repro it
[06:26] <tjaalton> crashes with old mesa too
[06:26] <tjaalton> so not due to _this_ update, phew
[06:26] <tjaalton> :)
[06:26] <tjaalton> looks exa related here as well
[06:29] <tjaalton> hmm, I'll try with current kernel
[06:30] <mlankhorst> I had the same issue regardless of mesa
[06:31] <tjaalton> same thing with 3.9rc6
[06:31] <mlankhorst> tjaalton: yeah maintainer nacked my patch
[06:31] <mlankhorst> you could try with it
[06:31] <tjaalton> you have a kernel built with it?-)
[06:31] <mlankhorst> not really
[06:32] <mlankhorst> but you only need to rebuild nouveau, make drivers/gpu/drm/nouveau/nouveau.ko
[06:38] <tjaalton> alright, seems to build
[06:43] <tjaalton> but doesn't load
[06:43] <tjaalton> I'll just build the whole kernel
[06:49] <mlankhorst> I saw some suspend failures on mailing list that indicated the channels were not halted correctly, and that it was a cause of failure
[06:58] <mlankhorst> or at least I was guessing based o nevidence :-)
=== schmidtm_ is now known as schmidtm
[07:11] <tjaalton> mlankhorst: nope, still crashes
[07:11] <mlankhorst> booo
[07:12] <tjaalton> there seem to be several such reports against raring
[07:15] <mlankhorst> unsurprisingly, linux 3.7 and later had a drm kernel module rewrite for nouveau
[07:15] <tjaalton> I'll try 3.6
[07:25] <tjaalton> still broken
[07:31] <tjaalton> duped some with bug #1084960
[07:31] <ubottu> bug 1084960 in xserver-xorg-video-nouveau (Ubuntu) "Resume from Standby mode doesn't work with Nouveau on Geforce GT430" [High,Triaged] https://launchpad.net/bugs/1084960
[07:32] <mlankhorst> I can actually suspend on my 480
[07:32] <mlankhorst> but prolonged suspend dies
[07:33] <tjaalton> suspend works, resume doesn't :)
[07:35] <mlankhorst> resume works for me on short suspends
[07:56] <tjaalton> sigh, we still have nvidia-experimental on raring..
[07:56] <tjaalton> -*
[08:01] <mlankhorst> :>
[08:01] <mlankhorst> weird, my config says one thing, but vmlinux indicated another
[08:08] <mlankhorst> oh make clean doesn't clean everything, grr
=== Prf_Jako1 is now known as Prf_Jakob
=== seb128_ is now known as seb128
[12:37] <mlankhorst> tjaalton: I may have a fix for the tegra now
[12:38] <mlankhorst> oops, still missing some part :P
[12:59] <tjaalton> ok..
[13:04] <mlankhorst> caused the event queue to overflow
[13:09] <mlankhorst> blergh dno what the right solution would be, the things related to touch are way too complicated >:(
[13:12] <mlankhorst> seems the easiest way to reproduce it is to hit the icon in top left, then immediately start a dragging movement, with valgrind enabled it will crash
[13:18] <seb128> tjaalton, hey, want to get the patch from https://bugs.launchpad.net/ubuntu/+source/libwacom/+bug/1167504 in Debian and then sync the package over so we stay in sync ?
[13:18] <ubottu> Launchpad bug 1167504 in libwacom (Ubuntu) "screen rotation for finger input fails on x230t" [Undecided,New]
[13:22] <tjaalton> seb128: yeah, sounds like a plan
[13:23] <seb128> tjaalton, thanks
[13:25] <tjaalton> there was a patch upstream already
[13:25] <tjaalton> not in git yet though but I'll steal it
[13:26] <mlankhorst> push it upstream? :P
[13:26] <tjaalton> it's on git.gnome.or
[13:26] <tjaalton> g
[13:27] <tjaalton> seb128: I'll upload it later today or early tomorrow so we can still sync it for raring
[13:28] <seb128> tjaalton, thanks
[13:28] <seb128> tjaalton, I will assign to you/unsubscribe sponsors
[13:28] <tjaalton> assigned already
[13:28] <tjaalton> and poof sponsors gone
[13:29] <seb128> ;-)
[13:29] <mlankhorst> ah right, I only have access to fd.org
[14:18] <mlankhorst> oh wow..
[14:28] <mlankhorst> *motion_event = *event; I suddenly get why that line was wrong ._.
[18:28] <sarnold> my thinkpad's brightness keys don't work well in raring; another lenovo and an acer user reported the same thing on my bug report. I might have mis-filed it in the first place, and recently heard that gnome-settings-daemon might be the proper target -- but got other advice to come here and ask :)
[18:29] <sarnold> so, should this bug be re-assigned somwhere else? https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/1156477
[18:29] <ubottu> Launchpad bug 1156477 in gnome-settings-daemon (Ubuntu) "laptop brightness keys regression" [Undecided,Confirmed]
[18:38] <jwi> sarnold: it's a firmware issue actually (at least the thinkpad one) - duplicate of bug 1098216
[18:38] <ubottu> bug 1098216 in linux (Ubuntu) "Regression in brightness control on Lenovo Thinkpad X230 and X1 Carbon" [Medium,Triaged] https://launchpad.net/bugs/1098216
[18:40] <jwi> try pressing the brightness keys ten times in a row, just for giggles?
[18:40] <sarnold> jwi: wow, thanks!
[18:42] <sarnold> jwi: the results depends upon the brightness setting I set with /usr/lib/gnome-settings-daemon/gsd-backlight-helper --set-brightness -- if I set it to '90', no amount of key banging changes the brightness again.
[18:43] <sarnold> jwi: if I set it to '70', the brightness changes quite a lot, but I can't get it to maximum brightness, even with my best key-banging
[18:46] <jwi> sarnold: so it's even weirder than I thought it was. thanks lenovo.
[18:47] <sarnold> jwi: no kidding. I bought a lenovo 'cause I figured they wouldn't do anything stupid. like this. heh. :)