[03:29] <bryce> wgrant: you might want to take a peek at bug 282730 when you get a chance
[06:06] <wgrant> bryce: That looks like the device's fault... but g-s-d should be smart enough to reset things.
[06:09] <wgrant> I've known about this sort of thing for a couple of weeks, but thought it only occurred with some strange touchpads.
[06:09] <wgrant> And it was too late to work out how to add event detection support into g-s-d at that stage.
[06:22] <bryce> wgrant: ok, if it's a device-specific that lessens the severity
[06:25] <wgrant> bryce: As you can see, it fails to find the device.
[06:25] <wgrant> That probably means it decides to go to sleep.
[06:27] <wgrant> The solution is to have g-s-d watch for input device changes, and possibly suspend/resume as well (depending on how braindead some devices are).
[06:31] <bryce> yep - do you know if this issue has been communicated upstream to gnome?
[06:33] <wgrant> I've not heard anything about it, and I've not established any lines of communication with them yet.
[06:33] <wgrant> I need to soon, but exams loom...
[06:34] <bryce> no prob, we've plenty of time before jaunty
[06:51] <wgrant> I think I'll be doing an awful lot of g-s-d and g-c-c hacking after UDS.
[07:26] <wgrant> bryce: What new stuff are we looking at in X land for Jaunty, other than GEM and MPX?
[07:28] <tjaalton> my wishlist includes a working nouveau driver, but upstream should wrap up a release first
[07:28] <bryce> hopefully more stability ;-)
[07:29] <bryce> we need to do a test package for MPX
[07:29] <tjaalton> MPX is not necessarily in xserver 1.6
[07:29] <wgrant> Oh, I thought it had been merged already...
[07:29] <tjaalton> in master yes
[07:29] <tjaalton> but XI2 might not end up in 1.6
[07:29] <wgrant> Ah, 1.6 is already branched?
[07:29] <wgrant> Oh dear.
[07:29] <tjaalton> not yet AFAIK
[07:30] <bryce> I think with MPX what we need to do is provide it as an experimental package for at least one full release, before putting it in
[07:30] <wgrant> I suspect so.
[07:30] <wgrant> It is a bit of a change.
[07:30] <tjaalton> bryce: but it's in the server, no?
[07:30] <bryce> it could end up uncovering bugs in a variety of client apps, so would be nice to give folks a chance to experiment with it before we switch it on by default
[07:31] <wgrant> Can we run it until say 
[07:31] <wgrant> Er.
[07:31] <wgrant> ... until say beta, and then switch it off if it proves bad?
[07:31] <tjaalton> gtk/qt should support it first
[07:32] <tjaalton> don't know if there still are some problems
[07:32] <wgrant> I wasn't necessary meaning Jaunty beta, but $CONVENIENT_RELEASE beta.
[07:32] <bryce> wgrant: that's not a bad idea
[07:33]  * tjaalton goes hunting some breakfast
[07:33] <bryce> I think a lot of issues are going to show up as application crashes, in apps that make assumptions that they'll only be accessed by a single pointer device
[07:34] <bryce> which could be extraordinarily irritating for developers of those apps
[07:34] <bryce> so I'm thinking rather than force it on them, instead give them some time to opt-in and play with it on non-development systems
[07:35] <wgrant> Or we could be nasty and force it on them, thus making them fix it *really* quickly.
[07:37] <bryce> maybe
[07:37] <bryce> there's going to be a LOT of corner cases that won't get fixed quickly
[07:37] <bryce> like perhaps fullscreen games
[07:38] <wgrant> Yes...
[07:39] <wgrant> I suppose that any device config UI in g-c-c is going to need to be designed with MPX config in mind.
[07:39] <bryce> yep
[07:42] <bryce> clearly I need to pay better attention to which machine I'm logged into when I restart gdm
[07:43] <wgrant> Haha.
[07:45] <wgrant> That is the main problem with deving X stuff.
[07:45] <bryce> yep
[07:46] <bryce> otoh you learn about .xprofile ;-)
[07:46]  * wgrant knows not of that.
[07:47] <bryce> create a ~/.xprofile, which is sourced during start up of a graphical session.  Put the cmds for any client apps to start up in there
[07:48] <wgrant> Ah.
[07:54] <bryce> create a ~/.xprofile, which is sourced during start up of a graphical session.  Put the cmds for any client apps to start up in there
[07:54] <bryce> dah
[07:54] <bryce> night
[07:57] <wgrant> Night.
[08:17] <tjaalton> how embarrassing, a guy with hardy on his laptop (intel gfx) can't get the picture to the projector
[08:17] <wgrant> And now the complaints roll in about us breaking touchpads :(
[08:17] <wgrant> Hmm.
[08:17] <wgrant> That always works fine for me; what's it breaking on?
[08:17] <tjaalton> just no picture, xrandr shows both outputs though
[08:17] <tjaalton> --auto does nothing
[08:17] <wgrant> Nice.
[08:18] <tjaalton> nothing visible at least
[08:18] <wgrant> Which chipset?
[08:18] <tjaalton> 965GM I think
[08:19] <tjaalton> wgrant: where are the complaints, the forum?
[08:19] <wgrant> tjaalton: Yeah
[08:19]  * wgrant is dealing with them.
[08:20] <wgrant> I hate to imagine the response we'll get once we update it to master...
[08:21] <wgrant> Lots of defaults have been changed.
[08:21] <wgrant> But we'll have a config GUI then, so it shouldn't be toooo bad.
[08:21] <wgrant> Maybe a more thorough release note should be added about the InputDevice section commenting-out?
[08:24] <tjaalton> synaptics master?
[08:24] <wgrant> Yes.
[08:25] <tjaalton> the inputdevice sections shouldn
[08:25] <tjaalton> bah
[08:25] <tjaalton> 't matter when the device is handled via hal
[08:25] <wgrant> They manage to break things if they're uncommented.
[08:25] <wgrant> But if they're commented, they lose their non-gconf settings.
[08:26] <tjaalton> hum, ok
[08:26] <wgrant> The majority of touchpad complaints early on were fixed by removing the InputDevice section. I'm not sure why
[08:30] <tjaalton> hmm, or is it evdev for which they are irrelevant
[08:32] <wgrant> I wonder if it's a good idea to move the Hardy stuff out of https://help.ubuntu.com/community/SynapticsTouchpad and into https://help.ubuntu.com/community/SynapticsTouchpad/Hardy and link to it where relevant... that page is fairly inconveniently unreadable...
[08:33] <tjaalton> yeah
[08:33] <wgrant> It also needs more stuff added to it tonight.
[08:33]  * wgrant copies it elsewhere for hitting.
[08:40] <wgrant> Oh good, it looks like they've finished my passport.
[08:53] <tjaalton> going somewhere?-)
[08:55] <wgrant> tjaalton: UDS?
[08:55] <tjaalton> wgrant: ahh, of course
[08:56] <tjaalton> I renewed mine a couple of weeks ago..
[08:56] <wgrant> Child passports can unfortunately not be renewed here :(
[08:57] <tjaalton> well, you always get a new one when renewing, right?-)
[08:58] <wgrant> Yes, but it's a lot more work.
[08:58] <wgrant> Yay, nice short page at https://wiki.ubuntu.com/WilliamGrant/SynapticsTouchpad
[08:58] <tjaalton> my old one was a ten-year passport, but with the biometric crap the five years is max
[08:59] <wgrant> They're still 10 years for adults here.
[08:59] <tjaalton> EU ftl in this case
[08:59] <wgrant> But not for me.
[11:02] <Ng> hrm what happened to bryce's domain
[11:02] <Ng> I wanted to see http://www.bryceharrington.org/X/PkgList/versions_current.html
[11:03] <Ng> also, are the 71 and 96 versions of nvidia not compatible with the current X server?
[11:03] <wgrant> Ng: Correct.
[11:04] <Ng> wgrant: how come they're still in the archive?
[11:04] <wgrant> Ng: And drop the 'www.' from bryce's domain.
[11:05] <wgrant> Ng: Because they might get fixed eventually, I suppose.
[11:06] <Ng> if people have a card which isn't supported by 177 and they upgrade, aren't they basically screwed?
[11:06] <wgrant> If their card isn't supported by 173 or 177, they will be migrated to nv.
[11:07] <wgrant> Unless they don't use update-manager, in which case they deserve to be screwed.
[11:07] <Ng> they will be migrated to nv, but they will then be offered the nvidia drivers
[11:07] <wgrant> Will they?
[11:07] <wgrant> Why?
[11:08] <Ng> the restricted thingy
[11:08] <Ng> jockey?
[11:08] <wgrant> That was fixed months ago.
[11:08] <wgrant> It won't offer broken drivers.
[11:08] <Ng> not according to a guy who did an upgrade about 6 hours ago
[11:09] <wgrant> Hmmm.
[11:09] <wgrant> tseliot: ^^
[11:10] <tseliot> Ng: I fixed this in Jockey
[11:11] <tseliot> wait, no, it doesn't work
[11:11]  * tseliot scratches head
[11:12]  * tseliot checks if the fix is in trunk
[11:13] <tseliot> this line should have solved the problem:
[11:13] <tseliot> assert int(version) >= 173, "NVIDIA legacy driver not yet supported"
[11:14] <Ng> I have no suitable hardware to test this, but if the report is true it's quite a serious bug I think
[11:15] <tseliot> I'll talk to pitti about this
[11:15] <Ng> ideally jockey would say "sorry, nvidia are not currently supporting your hardware, os you lose 3D"
[11:15] <wgrant> s/quite/very/
[11:16] <tseliot> the dist-upgrade should migrate users to "nv" therefore they won't be screwed up
[11:16] <tseliot> but yes, we have to fix this in Jockey too or see why my fix doesn't prevent Jockey from showing 96 and 71
[11:17] <Ng> yeah the guy confirms that he was migrated to nv, which is fine
[11:17] <Ng> but the little hardware applet would have been there telling him he could upgrade to nvidia, which he did, and that obviously broke
[11:18] <Ng> is there any chance though that jockey could explicitly say that the hardware is unsupported? upgraders might be confused as to why their experience has regressed
[11:18] <wgrant> It's probably a bit late for that.
[11:19] <tseliot> no, if the hardware is not supported then it shouldn't show up in Jockey
[11:19] <Ng> I'll settle for that ;)
[11:19] <Ng> it's less than ideal, but I guess there's no good way to notify them that nvidia have screwed them, atm
[11:20] <Ng> and miles better than offering a broken driver
[11:20] <tseliot> yep
[11:20]  * Ng hunts for a bug report about this
[11:22] <Ng> wow it's hard to find nvidia bugs
[11:23] <Ng> "1  → 75  of 5421 results " if I just search for "nvidia" in bugs.lp.net/ubuntu/
[11:26] <tseliot> yes, I know...
[11:29] <Ng> hmm, I don't think there is a bug for this, at least I can't find it searching for "nvidia intrepid"
[11:31] <Ng> just asking him to file one
[11:32] <tseliot> ok, thanks
[11:32] <Ng> np :)
[11:56] <Ng> tseliot: https://bugs.launchpad.net/ubuntu/+bug/288662
[11:56] <tseliot> Ng: thanks a lot
[11:56] <Ng> np
[11:57] <Ng> fwiw the reporter is in an eastern chinese timezone, but I'm subscribed and will poke him if info is required and he's awake ;)
[11:57] <Ng> (since it's obviously getting quite tight on timelines now)
[11:58] <tseliot> ok
[14:14] <tseliot> Ng: the problem should be solved now
[15:11] <superm1> bryce, wgrant i'm not sure if this should be pointed at evdev or the gnome package that handles settings: https://bugs.edge.launchpad.net/ubuntu/+source/bluez/+bug/287801 
[15:12] <superm1> but i feel like it shouldn't be kept at bluez, since once it is paired it just shows up as a normal mouse
[15:20] <Ng> tseliot: great, thanks :)
[15:29] <superm1> and this is sounding like probably the same type of problem: http://ubuntuforums.org/showthread.php?t=953489
[15:44] <Ng> does the touchpad stuff use xinput properties? it's my general observation that on a suspend we lose all xinput property settings
[15:44] <Ng> something needs to learn to recognise the devices and store the settings. gnome-settings-daemon springs to mind
[17:38] <bryce> morning
[17:39] <bryce> superm1: probably g-s-d
[17:39] <bryce> superm1: but wgrant would know for certain
[22:59] <wgrant> superm1, Ng: That's g-s-d's fault. Some devices disappear on suspend, and g-s-d doesn't know to look for new ones.
[22:59] <wgrant> The same problem plagues the upstream right/left-handedness setting now.
[23:00] <superm1> where do the settings get stored in general though?
[23:00] <superm1> so that they persist from reboot to reboot etc
[23:00] <wgrant> gconf
[23:00] <superm1> okay, and are they tied to a kernel inputX device then?
[23:01] <wgrant> No, they're global, and have been for a couple of releases.
[23:01] <wgrant> This will change for Jaunty.
[23:01] <superm1> well that will be troublesome most certainly for bluetooth keyboards and mice then.  there is a bug out there that whenever the device goes into low power mode, it's old inputX dissappears, and we get inputX+1
[23:01] <wgrant> The problem is that devices now appear and disappear while X is running.
[23:01] <wgrant> And the new device doesn't have the settings applied.
[23:01] <superm1> ah
[23:02] <wgrant> I wonder how hard it will be to get g-s-d to notice.
[23:02] <wgrant> I'll look at that after breakfast.
[23:02] <superm1> hopefully X emits some kind of event whenever devices show up or similar
[23:03] <wgrant> Probably the devicepresencenotify event.
[23:06] <wgrant> Not all hardware disappears across suspend (my touchpad being the important one), and I don't use custom settings for my USB mouse, so I never noticed that this had become a problem :(
[23:11] <wgrant> I wonder if any other distros have a fix for this.
[23:11] <wgrant> Or are we the only people using input-hotplug for *everything*?
[23:12] <bryce> fedora and debian are
[23:12] <bryce> mandriva is stuck in the past
[23:12] <bryce> not sure what opensuse is doing
[23:12] <bryce> wgrant: but yeah I've wondered the same a bit myself
[23:13] <wgrant> AFAICT, Mandriva barely exists any more.
[23:15] <bryce> wgrant: from my experience, we seem to be a bit ahead of the pack in terms of dealing with unusual hardware
[23:17] <jcristau> bryce: debian isn't yet.
[23:17] <bryce> jcristau: really?  thought you were.
[23:18] <jcristau> it was too late to get this in for lenny
[23:26]  * wgrant grumbles about having to learn about X events now.
[23:44] <tjaalton> ho ho ho
[23:47] <wgrant> Why is tjaalton laughing so evily?
[23:48] <tjaalton> wgrant: haha, you've got mail. a shitload of it. welcome to ubuntu-x! :)
[23:48] <tjaalton> wgrant: that should suffice :)
[23:48] <wgrant> Heh.
[23:48] <wgrant> Thanks.
[23:49]  * wgrant fixes procmail.
[23:51] <tjaalton> wgrant: btw, you think santa is evil? like in in futurama perhaps..
[23:52] <wgrant> I do.
[23:54] <tjaalton> "ho ho ho, your mistletoe is no match to my tow-missile!"
[23:55] <tjaalton> hope i got that right
[23:56]  * wgrant has never seen Futurama.
[23:57] <tjaalton> awwww...