[03:28]  * wgrant cries at the state of X docs on help.u.c/community.
[03:28] <wgrant> Some of them reference XF86Config-4, and others reference a proprietary Intel video driver, which I don't think existed...
[03:45] <superm1> psb?
[08:58] <jcristau> wgrant: it did exist, some years ago, afaik
[08:58] <wgrant> jcristau: Oh. Hmmm.
[09:06] <jcristau> might be this: http://www.intel.com/design/intarch/swsup/graphics_drivers.htm
[09:16] <wgrant> bryce: We should probably move wiki.u.c/X/Config to help.u.c/community soon.
[09:17] <wgrant> I'm currently attacking help.u.c/community and removing an enormous amount of old stuff, and it'd be nice to be able to remove pages and redirect to X/Config.
[12:50] <laga> so, hey guys. 
[12:50] <laga> i can't use DISPLAY=:0 over a ssh session to start apps on a remote computer. is that intentional?
[12:51] <laga> it worked in 8.04 and i'm not the only one with that problem
[12:57] <wgrant> laga: "can't use" isn't very descriptive.
[12:58] <laga> wgrant: i yelled at a friend of mine for using "doesn't work" just a few minutes ago :)
[12:58] <laga> i can't connect to the X server.
[12:58] <laga> eg ssh 192.18.0.137; DISPLAY=:0 xeyes -> Error: Can't open display: :0
[12:59] <wgrant> There is an xserver on .137?
[12:59] <wgrant> Running as your user?
[12:59] <laga> yes.
[13:00] <laga> this is a mythbuntu box. maybe we're doing something special. i haven't tried on vanilla ubuntu
[13:00] <wgrant> Probably.
[13:00] <wgrant> Because it works fine for me.
[13:01] <laga> interesting. thanks.
[13:02] <laga> X is using evdev by default now, right? said friend of mine had trouble getting her arrow keys to work because gnome settings didn't get updated :(
[13:03] <tjaalton> laga: enable x11-forwarding on both the client and server
[13:04] <laga> tjaalton: forwarding? do i need forwarding if i want to display something on the *remote* display
[13:04] <tjaalton> laga: ah. don't know
[13:04] <wgrant> laga: No, you don't.
[13:04] <laga> i wonder if consolekit is to blame.
[13:05] <wgrant> I've seen a few complaints about cursor keys getting borked, but not enough to suggest that it was broken in an upgrade of the default configuration.
[13:05]  * wgrant celebrates the inclusion of his fix for bug #280148 upstream.
[13:05] <ubottu> Launchpad bug 280148 in gnome-settings-daemon "g-s-d needs to set mouse properties when a new device appears" [Medium,In progress] https://launchpad.net/bugs/280148
[13:11] <laga> okay.
[13:32] <superm1> laga, i can't think of anything we're explicitly doing unless its a mistake that we keyed something wrong in gdm-cdd.conf
[13:33] <laga> i will investigate tonight
[13:44] <Q-FUNK> wgrant: thanks for the followup on g-s-d
[13:44] <Q-FUNK> wgrant: I have your PPA in my sources.list, so it will be tested as soon as the buildd has dinstall'ed it.
[13:45] <Q-FUNK> ah.  it seems that it's published now
[13:48] <Q-FUNK> reloading.
[13:57] <Q-FUNK> wgrant: it doesn't fix it either.  the problem seems to be that my laptop's touchpad+buttons are not considered as removed/reinsterted upon restoring from sleep/hibernate.  rather, g-s-d would need to know when *it* has been resumed and then rescan all hardware.
[14:17] <ScottK> bryce: Looks like we got an additional hit on Bug 290156, so it's not just the one monitor.
[14:17] <ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/290156/+text)