[00:27] <bryce_> bwahahaha http://people.ubuntu.com/~brian/complete-graphs/xserver-xgl/plots/xserver-xgl-fullyear-open.png
[06:11] <pwnguin> bryce_: what's that graph about?
[06:12] <pwnguin> a lot of bugs closed apparently
[06:12] <bryce_> yeah we finally killed off xgl
[06:13] <pwnguin> ah
[06:21] <bryce_> more graphs here:  http://people.ubuntu.com/~bryce/Plots/
[07:36] <tjaalton> crevette: so the layout works now?
[07:36] <crevette> yep
[07:37] <crevette> hello :)
[07:37] <tjaalton> excellent
[07:55] <tjaalton> sigh, firefox gfx get corrupt on me both on hardy and intrepid.. I need to move the mouse to another window to refresh the contents
[07:55] <tjaalton> wonder what's going on
[09:04] <seb128> tjaalton: hi
[09:07] <seb128> tjaalton: bug #268395, bug #268384, bug #268320, something is broken in your changes
[09:07] <ubottu> Launchpad bug 268395 in gnome-control-center "gnome-keyboard-properties crashed with SIGSEGV in XkbGetNames()" [Undecided,New] https://launchpad.net/bugs/268395
[09:07] <ubottu> Launchpad bug 268384 in gnome-control-center "gnome-keyboard-properties crashed with SIGSEGV in XkbGetNames()" [Undecided,New] https://launchpad.net/bugs/268384
[09:07] <ubottu> Launchpad bug 268320 in gnome-control-center "gnome-keyboard-properties crashed with SIGSEGV in XkbGetNames()" [Undecided,New] https://launchpad.net/bugs/268320
[09:14] <tjaalton> seb128: isn't that what mvo did?
[09:15] <seb128> oh
[09:15] <seb128> tjaalton: sorry, I though that was the evdev thingy
[09:15] <seb128> mvo: ^
[09:15] <tjaalton> seb128: maybe they didn't get the xkb-data update which made them try the capplet
[09:16] <seb128> tjaalton: depends should assure they get it
[09:16] <tjaalton> seb128: yeah, well I didn't add one :/
[09:16] <tjaalton> it's a bit late for that too
[09:16] <mvo> seb128: I have a look
[09:16] <seb128> mvo: I'm fixing the retracers to get you a good stacktrace
[09:19] <mvo> hm, that is code that I haven't really touched, maybe some sort of side effect 
[09:19]  * mvo looks closer
[09:20] <seb128> one of you broke it and I'll let you discuss the details ;-)
[09:20] <seb128> it's either the evdev changes or the gnome-control-center changes
[09:21] <tjaalton> highly unlikely that the ruleset change broke this :)
[09:21] <tjaalton> but I'm all ears
[09:23] <seb128> bug #268320 has a correct stacktrace now
[09:23] <ubottu> Launchpad bug 268320 in gnome-control-center "gnome-keyboard-properties crashed with SIGSEGV in XkbGetNames()" [Medium,New] https://launchpad.net/bugs/268320
[09:27] <seb128> tjaalton: the description on bug #268395 suggests that the issue not a gnome-control-center one, the guy went to the capplet to try fixing his layout which has been broken on upgrade
[09:27] <ubottu> Launchpad bug 268395 in gnome-control-center "gnome-keyboard-properties crashed with SIGSEGV in XkbGetNames()" [Undecided,New] https://launchpad.net/bugs/268395
[09:28] <seb128> ah you already commented on this bug
[09:29] <tjaalton> yes, there were a few similar reports
[09:30] <jcristau> depending on the new xkb-data would probably fix it?
[09:30] <tjaalton> yes
[09:31] <tjaalton> but by the time it hits the archive everyone should have it installed already (or would get the right version on upgrade=
[09:31] <tjaalton> )
[13:28] <mvo> should nvidia work with 2.6.27-2 ? and if so, what do I need to do if it does not :) ?
[13:43] <tjaalton> mvo: 177 works for me
[13:45] <mvo> tjaalton: it seems like I have no kernel module, can I force dkms to build me one?
[13:46] <tjaalton> mvo: yes, there's a bug where it's all documented how to recover.. a sec
[13:48] <tjaalton> mvo: bug 261816
[13:48] <ubottu> Launchpad bug 261816 in linux-restricted-modules-envy-2.6.24 "nvidia: Multiple versions in DKMS" [Medium,In progress] https://launchpad.net/bugs/261816
[13:48] <mvo> thanks tjaalton!
[13:48]  * mvo hugs tjaalton
[13:48]  * tjaalton hugs mvo back
[13:49] <tjaalton> the package should clean up old versions, but I'm not sure where tseliot is with it
[13:51] <tseliot> tjaalton: problems?
[13:54] <tjaalton> tseliot: we discussed that nvidia-glx-177 should clean up those old dkms directories
[13:55] <tseliot> tjaalton: yes, I haven't worked on it yet
[13:55] <tseliot> I'll do it ASAP
[13:56] <tjaalton> tseliot: thanks :)
[15:13] <tjaalton> wgrant: does the mouse caplet support setting Horiz/VertEdgeScroll?
[15:24] <mvo> if bug #261816 is fix commited, why did I still see it :) or can we add some code that resolves the issue automatically instead of printing "multiple versions in DKMS" and failing to start X ?
[15:24] <ubottu> Launchpad bug 261816 in linux-restricted-modules-envy-2.6.24 "nvidia: Multiple versions in DKMS" [Medium,In progress] https://launchpad.net/bugs/261816
[15:26] <mvo> what does "nvidia: AUTONINSTALL not set in its dkms.conf" tell me ?
[15:31] <tjaalton> mvo: the package no longer leaves cruft behind, that's why it's marked as fixed. upgrades still fail though, and tseliot will fix that
[15:31] <mvo> ok
[15:32] <tseliot> yes, I will
[15:32] <tseliot> I'm working on jockey and xkit right now, though
[15:33] <mvo> great, what does  "nvidia: AUTONINSTALL not set in its dkms.conf" mean? I get this when I reinstall linux-headers-$(uname -r)
[15:35] <mvo> now that is confusing, nvidia-177.70 in /usr/src has AUTOINSTALL=true
[15:49] <mvo> hm, apt-get install nvidia-glx-173; apt-get install nvidia-glx-177 fixed it - i guess apt-get install --reinstall nvidia-177-kernel-source as well
[15:49] <mvo> I wonder if it is worth adding that to friendly recovery ...
[16:06] <tjaalton> wgrant: sorry, I meant Horiz/VertTwoFingerScroll
[16:07] <tseliot> mvo: it doesn't find autoinstall because it doesn't find any dkms.conf
[16:07] <tseliot> because some half empty directories are still in /var/lib/dkms/nvidia when they shouldn't
[16:16] <mvo> aha, ok
[16:20] <tseliot> mvo: BTW I'll give you a new release of nvidia-common soon so as to solve the bug I told you about
[16:20] <mvo> great :)
[16:20] <mvo> so its probably not woth adding code to friendly-recovery?
[16:25] <tseliot> mvo: I'm referring to the fact that some proprietary drivers don't work in Intrepid and that therefore we'll have to set a free driver during the dist-upgrade
[16:26] <mvo> oh, right
[17:21] <bryce_> tjaalton: how can I help with bug 267682?
[17:21] <ubottu> Launchpad bug 267682 in Ubuntu Intrepid "Hotkeys no longer working in Intrepid (evdev?)" [Critical,Triaged] https://launchpad.net/bugs/267682
[17:25] <johanbr> tseliot: Recent nvidia drivers give a lot of rendering bugs for me. In firefox, a lot of pages don't render properly until I click somewhere in the window. Is this a known bug?
[17:57] <bryce_> johanbr: check bugs.launchpad.net to see if it's known
[17:57] <johanbr> I did. Didn't find anything.
[18:25] <bryce_> johanbr: go ahead and file one - include your Xorg.0.log and a screenshot or photo showing the rendering problems
[18:26] <bryce_> johanbr: unfortunately since it's a proprietary driver, there may not be much we can do about it, but it may be useful info to someone
[18:28] <jcristau> reporting it to nvidia might, or might not, be more useful
[18:30] <tseliot> johanbr: hmm, sounds like a bug which affected 177.67 and was fixed in 177.68 or .70
[18:49] <tseliot> bryce_: did you have a look at my 2 new patches for the screen resolution capplet?
[18:54] <johanbr> tseliot: I see. I'll have a look if the driver is fully updated. Thanks.
[19:04] <tjaalton> tseliot: I'm seeing that same rendering bug on both hardy (169.12) and intrepid (177.70)
[19:05] <tjaalton> bryce__: well, we need to decide *how* to fix it
[19:08] <bryce__> tjaalton: I'm still trying to understand it
[19:08] <bryce__> tjaalton: unfortunately, I don't seem to have exactly the same media keys as the T61, so am not sure I'm able to reproduce it
[19:08] <bryce__> however my sleep button (Fn+F1) does nothing either (but I can't reproduce mdz's troubleshooting)
[19:09] <bryce__> unfortunately some of my media keys lock up the machine
[19:09] <tjaalton> bryce__: the thing is that evdev grabs the input device which produces those events
[19:09] <tjaalton> so the events are not passed on to g-p-m
[19:10] <tjaalton> since it appears to only listen to hal
[19:10] <tjaalton> I haven't dug beyond that
[19:10] <bryce__> (as an aside, I notice in my Xorg.0.log that evdev is setting up 1 mouse (/dev/input/event7) and three keyboards (event5, 6, 1)
[19:12] <bryce__> so, would we need to make g-p-m listen to X as well, or make evdev pass the events back to hal?
[19:12] <tjaalton> the former
[19:13] <tjaalton> the quirky way would be to use fdi-files that would make evdev not grab these devices
[19:13] <bryce__> I assume g-p-m has code to listen to -kbd; do you think it needs modified to listen to -evdev?
[19:13] <bryce__> or is there something we can do on the X side?
[19:13] <tjaalton> kdb doesn't grab those devices
[19:13] <tjaalton> kbd
[19:14] <bryce__> hm, well how did it work before?
[19:15] <tjaalton> that's a valid question which I can't answer to :)
[19:15] <bryce__> how do I see the events?  I'd like to verify that I can reproduce the problem, but catting /dev/input/event* when hitting the sleep key does nothing
[19:15] <tjaalton> gpm listened to hal or something
[19:15] <tjaalton> use evtest
[19:17] <bryce__> what package has evtest?
[19:17] <tjaalton> dvb-utils :)
[19:17] <bryce__> ok weird
[19:18] <bryce__> got a bunch of mknod/makedev errors when installing it; hope that's normal
[19:19] <tjaalton> yeah it tries to run MAKEDEV dvb
[19:19] <tjaalton> pretty useless these days
[19:23] <bryce__> okay... now how do I use it?  :-)
[19:23] <bryce__> I get the same output for event 5,6,1, and no response when I hit Fn+F1
[19:25] <bryce__> well, event1 gives different output, but also no response for this key
[19:26] <bryce__> it is showing "Event code 142 (Sleep)"
[19:26] <tjaalton> http://pastebin.ubuntu.com/45445/
[19:26] <bryce__> Event code 152 (Coffee)  heh
[19:26] <tjaalton> yeah, lock screen :)
[19:26] <tseliot> bryce__:  did you have a look at my 2 new patches for the screen resolution capplet?
[19:27] <tjaalton> so, when you first run it, it should dump the keycodes the device supports
[19:27] <tseliot> tjaalton: 169.12 won't be fixed anyway
[19:28] <bryce__> tseliot: not yet; it was on my todo list for today but this hotkey stuff got bumped to higher priority
[19:28] <tjaalton> tseliot: the thing is that I only started seeing it fairly recently, which makes it even more strange
[19:29] <bryce__> tseliot: well, I mean reviewed the patches, but I haven't packaged/uploaded them yet
[19:32] <bryce__> tseliot: since there's a good bit of cnew ode there it may require a FFe unfortunately
[19:32] <bryce__> er s/cnew ode/new code/
[19:42] <bryce__>  boy I'm not even sure where to start looking in g-p-m
[19:43] <tseliot> bryce__: ok, no problem. If you have doubts I'll be glad to answer
[19:43] <tseliot> tjaalton: it might be something else then
[19:43] <tseliot> tjaalton: that triggers the problem in the driver. Maybe firefox?
[19:44] <tjaalton> tseliot: could be, or some lib
[19:45] <bryce__> tseliot: sure, I may be able to get to it today.  If I could show you my todo list here by my computer, those uploads are literally the next thing on my todo list.  :-)
[19:58] <bryce__> ahh, Fn+F1 is hibernate, not sleep
[20:00] <bryce__> tjaalton: are we sure that the bug affects all laptops, and not just T61's?
[20:03] <tjaalton> bryce__: mine is X61, and pitti has a dell..
[20:03] <tjaalton> so it does affect more than just T61
[20:04] <bryce__> ah, I misremembered; I thought you had a T61
[20:04] <tjaalton> I also have an old T23
[20:05] <bryce__> ok well I can't see that SLEEP is mapped to any hotkeys on this dell
[20:06] <bryce__> the hibernate key doesn't work, nor does the "BATTERY" key (Fn+F3), although I don't know what BATTERY *should* do...  but all the remaining media keys are working fine
[20:06] <bryce__> unfortunately I have no non-dell laptops
[20:07] <tseliot> bryce__: don't worry, I believe you ;)
[20:07] <tjaalton> bryce__: the battery key opens a pop-up that shows how your battery is doing
[20:10] <bryce__> huh interesting; never seen that work
[21:22] <bryce_> hmm, so I've found with gnome-keybinding-properties, that Suspend was not mapped to a key, and that I could easily map it to that function by just hitting it.  hmm
[21:22] <bryce_> still doesn't trigger hibernate though
[21:55] <bryce_> tjaalton: what do you see in gnome-keybinding-properties?
[22:35] <tjaalton> bryce: nothing there
[22:37] <tjaalton> also, evtest doesn't show any output (apart from that initial blurp) when evdev has grabbed the device
[22:37] <tjaalton> forgot about that
[22:38] <bryce> tjaalton: ah okay, yeah I didn't see output from that either for any buttons
[22:39] <bryce> where does acpi stuff get logged?  mdz said he saw log messages about acpi calls, but didn't say where and I can't find those on my system
[22:40] <tjaalton> dunno
[22:40] <bryce> hrm
[22:40] <bryce> well /etc/acpi/*btn.sh don't seem to get called when hitting the corresponding buttons
[22:41] <bryce> (or at least, I haven't found evidence they're getting called)
[22:44] <bryce> I'm not sure it'd work even if it did get called though...  KEY_SUSPEND=205 however xev shows keycode 213 = (keysym 0x1008ff10, XF86Standby)
[22:44] <bryce> but maybe that doesn't matter.  
[22:46] <bryce> running /etc/acpi/sleepbtn.sh does work though... and freezes X on resume
[22:46] <bryce> but that's a separate issue
[22:46] <bryce> feh
[23:02] <tjaalton> I'll continue with it tomorrow.. night
[23:06] <wgrant> tjaalton: Not at this point. I'd be happy to work on adding those and other buttons now that it doesn't mean an awful hack in the driver.
[23:07] <wgrant> Just on/off, tap-to-click, horiz scroll, vert scroll are options at the moment.
[23:13] <bryce> night tjaalton