[00:42] <bryce> interesting; daniels has switched Zap off by default upstream
[00:55] <wgrant> Ooh.
[00:55] <wgrant> I was watching that argument, but gave up eventually.
[01:23] <bryce> I wish I had the time to follow all the upstream discussions
[01:24]  * bryce kicks launchpad aka timesucker
[06:31] <gvaroquaux> Hi, I am trying to check if a specific hardware rendering bug is fixed under Intrepid. I am upstream for mayavi2, and a user (and Debian developer) has just signaled that the bug was fixed in Debian, I can't find a corresponding bug report on Launchpad, and intrepid has a slightly older version of xserver-xorg-video-intel. I would be quite happy if someone with an intel card (something like an i810) could quickly perform a few t
[06:42] <bryce> tjaalton: should all mouse-like devices be using evdev?  I was lent a hands-free mouse device which hal sees but isn't associating a driver to, and setting it to evdev doesn't seem to do the trick.
[06:47] <gvaroquaux> No answers... I guess everybody is sleeping. I got to run to work, but if anyone with a laptop with an intel graphics running Intrepid is willing to help, it would be great. I cannot do this test in a VM :). Just send me an e-mail at gael dot varoquaux at normalesup dot org. The experiment is actually quite simple: apt-get install mayavi2, and go through the steps describe on http://code.enthought.com/projects/mayavi/docs/develo
[06:47] <gvaroquaux> Good day to all.
[07:16] <bryce> tjaalton: filed 279999 on it
[07:16] <bryce> wow, I got a good lp#
[07:39] <tjaalton> bryce: dunno, I'll have a look
[07:40] <tjaalton> btw, looks like I won't make it to UDS this time.. my boss still hasn't decided after two weeks if they'll send me there, ffs
[07:41] <tjaalton> bryce: Zap: yes, turning it off by default was looking like the best option, no reason to over-engineer something to go around it :)
[07:41] <bryce> ah, a shame
[07:41] <tjaalton> and the sponsorship-dl was two weeks ago..
[07:43] <bryce> well, next one is in spain in feb
[07:44] <tjaalton> so soon?
[07:48] <bryce> well, I think the uds in december is just later than it probably normally should be (dunno why)
[07:48] <tjaalton> that too, but feb is a bit too soon for jaunty+1 :)
[08:16] <tjaalton> bryce: the problem with that device is that it doesn't have any info.capabilities set, so the current rules won't match it
[08:17] <tjaalton> no need to set SendCoreEvents btw
[08:21] <bryce> ok
[08:21] <bryce> what should info.capabilities be set to?
[08:21] <tjaalton> it should be set by the device, or some other part of the system.. not the fdi
[08:22] <bryce> hrm
[08:22] <tjaalton> current rules match input.mouse or input.keys
[08:22] <tjaalton> oh, same applies to info.product..
[08:25] <tjaalton> I don't know where those are normally coming from
[08:28] <bryce> kernel maybe?  hmm
[08:28] <bryce> well, I'll bounce it back to henrik I guess
[08:44] <tseliot> tjaalton: do you happen to know in which package I can find XInput.c?
[08:45] <tseliot> tjaalton: not the compiled binary, just the source
[08:47] <tjaalton> tseliot: there isn't one
[08:48] <tseliot> tjaalton: but I have /usr/include/X11/extensions/XInput.h
[08:48] <tjaalton> that doesn't imply there's XInput.c
[08:49] <tseliot> what should I look for then?
[08:49] <tjaalton> I don't know
[08:49] <tseliot> the source of the command line app xinput would be fine
[08:50] <tjaalton> well, XInput.h is not from xinput
[08:50] <tjaalton> but x11proto-input-dev..
[08:50] <tjaalton> apt-get source xinput?
[08:50] <tjaalton> what are you trying to do?
[08:51] <tseliot> I would like to see how xinput works and if I can interface to it with Python
[08:52] <tjaalton> well there you go
[08:52] <tjaalton> get the sources for xinput
[08:53] <tseliot> yes, that worked well and should be enough. Thanks
[08:57]  * wgrant used xinput as a reference for the g-c-c stuff.
[08:58] <tseliot> wgrant: yes, but I would like to get the device properties from Xinput and write fdi files
[09:00] <tjaalton> how's that going to work?
[09:00] <tjaalton> properties don't map into driver options
[09:01] <tseliot> I have yet to see if that's possible
[09:01] <tjaalton> well I can tell you it's not :)
[09:01] <tseliot> I would rather not hardcode options
[09:02] <tseliot> do you know where options for fdis can be found for different devices?
[09:02] <tjaalton> man foo
[09:02] <tjaalton> where foo==evdev
[09:02] <tjaalton> hmm, or synaptics, joystick..
[09:03] <tseliot> aah, nice, that's actually easier
[09:03] <tseliot> since I can parse the man page with my options data store
[09:04] <tjaalton> and those options are persistent. properties are not
[09:04] <tseliot> yes, right
[09:11] <tseliot> bryce: the new g-c-c works well
[09:12] <wgrant> What's new with g-c-c?
[09:13] <tjaalton> wgrant: this is.. interesting, or confusing; I've got all the properties bits updated on my machine, apart from xorg-server, and 'xinput list-props foo' works just fine
[09:13] <wgrant> Ah.
[09:13] <wgrant> I see.
[09:13] <wgrant> tjaalton: .... even with the different API and ABI?
[09:13] <wgrant> That hints that xinput is broken.
[09:13] <tjaalton> wgrant: well, those should be updated yes
[09:13] <tseliot> wgrant: https://bugs.launchpad.net/ubuntu/intrepid/+source/gnome-control-center/+bug/275977
[09:13] <seb128> speaking about new g-c-c could whoever did the changes or upload commit the bzr?
[09:14] <tjaalton> wgrant: hmm, right.. it doesn't use a patch system so that could be it
[09:14] <wgrant> tjaalton: So the patch was never applied?
[09:14] <wgrant> It still shouldn't crash my X server, but that would explain why it wasn't working.
[09:15] <tseliot> seb128: yes, I can do it
[09:15] <tseliot> seb128: lp:~ubuntu-core-dev/gnome-control-center/ubuntu , right?
[09:15] <seb128> tseliot: thanks ;-) otherwise it's likely that next upload see the change dropped
[09:15] <seb128> tseliot: correct
[09:15] <tseliot> ok
[09:16] <wgrant> More likely that the next upload will be rejected... I've had that happen a few too many times.
[09:16] <seb128> I'll start doing my mvo and complaining about people not pushing their changes to bzr when uploading ;-)
[09:16] <seb128> wgrant: next upload is likely to be a new upstream version for GNOME 2.24.1
[09:16] <tjaalton> wgrant: well looks like it wasn't applied, yes
[09:16] <tjaalton> duh
[09:17] <wgrant> tjaalton: Well, that was an easy fix.
[09:17] <wgrant> seb128: Ah. Even better.
[09:17] <tjaalton> wgrant: I bet it doesn't fix my mouse buttons though
[09:18] <tjaalton> which are broken with the updated server
[09:18] <wgrant> tjaalton: True.
[09:18] <tjaalton> wgrant: did you see that? events only on buttonrelease
[09:18] <tseliot> seb128: do you maintain gnome-desktop in bazaar too?
[09:18] <wgrant> tjaalton: I use a touchpad normally, so it's not really noticable.
[09:19] <seb128> tseliot: no
[09:19] <seb128> tseliot: apt-get source tell you usually ;-)
[09:19] <tseliot> right
[09:19] <seb128> tseliot: gnome-control-center is in bzr because mvo is working on it too in fact, we don't have many bzr packages yet
[09:19] <tseliot> ok
[09:21] <tseliot> seb128: I guess I'll have to create my own branch and ask mvo to merge from it right?
[09:21] <tjaalton> wgrant: um, sorry.. xinput is fine
[09:21] <tjaalton> after all
[09:22] <wgrant> tjaalton: Damn.
[09:22] <seb128> mvo: bzr question for you there ;-)
[09:22] <mvo> tseliot: right, create your own branch and any core-dev can merge
[09:22] <tseliot> mvo: ok
[09:22] <mvo> tseliot: you can also just sent me the debdiff and I merge this one (but the next one is for you ;)
[09:23] <seb128> ideally whoever upload should do the commit too because who has upload rights has commit rights too
[09:23] <tseliot> mvo: I'll do it myself. You can use the time I'm saving you to read my email :-P
[09:23] <mvo> right
[09:23] <mvo> oh, right
[09:23] <mvo> damm
[09:23] <mvo> ETOOMUCH
[09:24]  * seb128 hugs mvo
[09:24] <mvo> sorry tseliot, please keep nagging me, I'm just busy with $STUFF, but it should be straightforward to merge your changes
[09:25] <tseliot> mvo: no problem
[09:40] <tjaalton> wgrant: hmm, I'm wondering if it's about the drivers after all.. Noticed that my evdev was newer than the one on my ppa, for instance
[09:43] <wgrant> tjaalton: Heh, that might do it.
[09:45] <tseliot> mvo: can you merge from lp:~albertomilone/gnome-control-center/randr-virtual when you have the time?
[09:53] <mvo> thanks tseliot, merged
[09:54] <tseliot> mvo: thanks
[10:04] <tjaalton> wgrant: at least my mouse works now, but props still don't
[10:19] <wgrant> tjaalton: BadRequest or similar?
[10:21] <tjaalton> wgrant: yep, and still shows the minor opcode as 41, when that shouldn't exist anymore
[10:21] <tjaalton> inputproto, libxi checked and verified to be ok
[10:23] <wgrant> Huh.
[11:41] <tseliot> tjaalton: can upload the new NVIDIA driver to Intrepid, please? https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-177/+bug/275098
[13:59] <tseliot> tjaalton: never mind
[14:06] <tjaalton> tseliot: I was on it, but got other stuff to do first
[14:07] <tseliot> tjaalton: no problem, pitti is doing the upload for me. Thanks anyway
[14:14] <tjaalton> tseliot: ok, good
[14:16] <tseliot> tjaalton: a lot of people is asking me to put that driver in Hardy too but that would screw up users of Geforce 5xxx
[14:17] <tseliot> :-/
[14:30] <tjaalton> tseliot: 173 will probably get there
[14:31] <tseliot> tjaalton: the problem is that 173 doesn't support some new nvidia cards
[14:33] <tseliot> if only nvidia hadn't dropped the support for geforce 5xxx in 177...
[14:38] <tjaalton> that's what you get with proprietary blobs
[18:21] <johanbr> Is monitor hotplug supposed to work by now? I just tried plugging in a projector and the experience in Intrepid is still not ideal.
[18:21] <johanbr> For instance, I had to restart X.
[18:23] <jcristau> you shouldn't need to restart x
[18:24] <tseliot> what driver are you using?
[18:24] <jcristau> as for the 'not ideal' part, you'd have to be more precise
[18:24] <johanbr> The free -ati driver.
[18:25] <johanbr> Having to restart X was the worst glitch.
[18:25] <jcristau> running 'xrandr --auto' should do the right thing there
[18:25] <tseliot> can you put the output of "xrandr" on pastebin after you plug in the projector?
[18:25] <johanbr> I used gnome-display-properties. It messed a bit with my xorg.conf and told me to restart X.
[18:26] <johanbr> Maybe that's where the blame should be assigned.
[18:26] <johanbr> I don't have the projector handy right now, but will try later.
[18:26] <tseliot> johanbr: aah, you're not trying to use clone mode
[18:26] <tseliot> you tried to set up the screens separately
[18:27] <johanbr> What came up after the restart was cloned.
[18:27] <tseliot> e.g. your projector to the right of your screen
[18:27] <tseliot> that's normal
[18:27] <tseliot> you have to log in
[18:27] <tseliot> did you update the system today?
[18:28] <tjaalton> actually, separate screens is what it seems to offer by default, since the same happened on my laptop yesterday when I tried multihead for fun
[18:28] <tseliot> tjaalton: would you like to have clone mode set by default?
[18:28] <tjaalton> yes
[18:29] <tjaalton> I believe that's the most common case
[18:29] <johanbr> xorg.conf after gnome-display-properties had messed with it: http://pastebin.ca/1222902
[18:29] <johanbr> Well, gotta go. Back in about 1h.
[18:30] <tseliot> yes, the virtual resolution was set
[18:30] <tseliot> tjaalton: if bryce and/or seb128 agree we can change that
[18:30]  * tseliot > dinner
[18:33] <bryce> perhaps the ideal would be to detect if the monitors are identical, in which case default to left/right multihead, but if they're different, default to cloned
[18:36] <tjaalton> the only case where I see left/right better than clone is fixed setups, but there's no way to detect that, and even if there was, it would be confusing
[18:37] <jcristau> also left-of kills acceleration in quite some setups
[19:06] <bryce> well, we've had some complaints by people expecting multi-screen layouts, not being able to figure out that they need to drag one of the cloned monitors to the side
[19:07] <bryce> I don't know who changed it to show left/right by default, but I thought it was an improvement in that regard
[19:09] <bryce> although I suppose I could see the reverse as well - if it defaulted to left/right but they were expecting cloned, they'd be equally confused about needing to drag one monitor on top of the other
[19:09]  * bryce shrugs
[19:41] <tseliot> tjaalton: do you think we should put the "mirror screens" label in bold?
[19:42] <tseliot> or do something else to highlight it?
[19:45] <tjaalton> tseliot: dunno, can't test it now
[19:49] <tseliot> there's no hurry
[22:00]  * wgrant looks at porting syndaemon to input properties in order to remove the final need for SHMConfig and placate various users.
[22:20] <superm1> wgrant, did your investigations of the brightness keys ever end up anywhere useful?
[22:20] <wgrant> superm1: I know why my two issues happen, yes.
[22:21] <wgrant> One of them might be an X bug, and the other one might be an X bug but is probably a hardware bug and a g-p-m-is-far-too-trusting bug.
[22:21] <superm1> wgrant, is the root cause solveable in a timely fashion?
[22:22] <wgrant> The hang can be worked around fairly easily in g-p-m, but we need to decide on a maximum sane number of increments for screen brightness.
[22:22] <wgrant> The many thousands of key events... well, I need to track down the source of the problem.
[22:22] <wgrant> I don't think it happened in Hardy, but it might have just been that g-p-m was smarter.
[22:23] <superm1> well I've compared hardy side by side with two of the same system here, and things are much better in hardy
[22:23] <wgrant> I'll likely find time to debug it properly tomorrow night... but it's unfortunate release timing given the coming exams...
[22:23] <wgrant> superm1: What are your symptoms, again?
[22:23] <superm1> I lose focus for an extended period of time
[22:23] <superm1> roughly 40 seconds or so
[22:23] <superm1> whenever I change brightness
[22:24] <superm1> switching VTs restores focus 
[22:24] <superm1> or killing GPM
[22:25] <wgrant> If you run xev, give it focus, and hit a brightness key, do you see far too many events?
[22:25] <wgrant> And do that stop when you hit another key?
[22:25] <wgrant> s/that/they/
[22:25] <wgrant> `xrandr --prop | grep -i light` is also useful output.
[22:26] <superm1> should I kill gpm when i hit this brightness key?
[22:26] <wgrant> Probably a good idea.
[22:26] <jcristau> wgrant: that might be a kernel bug. i think some people already reported some keys not sending keyrelease.
[22:26] <wgrant> jcristau: Would that cause tens of thousands of events?
[22:27] <wgrant> Anyway, I need to leave for uni now... I won't be around for a few hours,
[22:27] <superm1> wgrant, oh yeah that's wayyy too many events 
[22:27] <jcristau> wgrant: probably, with key repeat
[22:27] <superm1> its like the key is stuck 
[22:27] <wgrant> Aha.
[22:27] <wgrant> I thought it was too many for that, but I guess it's possible.
[22:28] <superm1> wgrant, regarding xrandr --prop, this machine uses nvidia-glx-177.  dont' expect any swanky xrandr features
[22:28] <jcristau> wgrant: you can change the autorepeat settings with xset, see if that affects what you're seeing?
[22:36] <gvaroquaux> Anybody running intrepid with an intel graphics card willing to check that a bug is gone in intrepid for me? I asked about this this morning, but had to run to work.
[23:21] <bdmurray> gvaroquaux: what bug?
[23:22] <bdmurray> bryce: any ideas about bug 210340? should it work?
[23:23]  * bryce looks
[23:26] <gvaroquaux> bmurray: it is a z-ordering bug that appears running the program mayavi2. It is probably a duplicate of an existing bug, but I am not sure which one. All I know is that many users complain about this bug. I can show how to reproduce it. The reason I ask about this today is that a Debian user reported it was fixed in Debian, and the version numbers of debian are ever so slightly higher than ubuntu (actually only the lib-mesa-dri 
[23:31] <gvaroquaux> I am going to be off to bed soon (sorry, I have long days at work), but if anybody wants to give me a hand (it should be fairly straight forward), I am available on gael dot varoquaux at normalesup dot org (I am the fealing this is not going anywhere :>)
[23:49] <bryce> bdmurray: re 210340 - I guess it should work, but obviously we're missing some important info
[23:49] <bryce> and without that, there's no proof that the me-tooer in comment #3 is seeing the same as the original reporter
[23:50] <bdmurray> okay, I wasn't sure if dual monitors on a Live CD should work
[23:51] <bryce> well, the issue is that they had two monitors plugged in
[23:51] <bryce> regardless of whether dual monitor functionality should work in a livecd, you shouldn't see corruption if two monitors are just plugged in
[23:51] <bryce> worst case would be that output only appears on one monitor - that'd be acceptable
[23:51] <bryce> best case would be that they show up cloned
[23:52] <bryce> can you reverse the dupe, so 277724 is the primary?  It has the more complete info and will be easier to upstream
[23:52] <bryce> also the reporter seems more actively engaged
[23:52] <bdmurray> yep, I think he posted to u-d-something
[23:53] <bryce> also, that bug can be filed against xserver-xorg-video-nv rather than xorg
[23:53] <bryce> mark it high/triaged, and I'll upstream it either today or tomorrow
[23:55] <bdmurray> bryce: cool, done
[23:59] <wgrant> jcristau: Um, the brightness keys don't seem to generate any X events at all if key repeating is turned off.