[00:42] interesting; daniels has switched Zap off by default upstream [00:55] Ooh. [00:55] I was watching that argument, but gave up eventually. [01:23] I wish I had the time to follow all the upstream discussions [01:24] * bryce kicks launchpad aka timesucker [06:31] 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] 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] 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] Good day to all. [07:16] tjaalton: filed 279999 on it [07:16] wow, I got a good lp# [07:39] bryce: dunno, I'll have a look [07:40] 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] 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] ah, a shame [07:41] and the sponsorship-dl was two weeks ago.. [07:43] well, next one is in spain in feb [07:44] so soon? [07:48] well, I think the uds in december is just later than it probably normally should be (dunno why) [07:48] that too, but feb is a bit too soon for jaunty+1 :) [08:16] 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] no need to set SendCoreEvents btw [08:21] ok [08:21] what should info.capabilities be set to? [08:21] it should be set by the device, or some other part of the system.. not the fdi [08:22] hrm [08:22] current rules match input.mouse or input.keys [08:22] oh, same applies to info.product.. [08:25] I don't know where those are normally coming from [08:28] kernel maybe? hmm [08:28] well, I'll bounce it back to henrik I guess [08:44] tjaalton: do you happen to know in which package I can find XInput.c? [08:45] tjaalton: not the compiled binary, just the source [08:47] tseliot: there isn't one [08:48] tjaalton: but I have /usr/include/X11/extensions/XInput.h [08:48] that doesn't imply there's XInput.c [08:49] what should I look for then? [08:49] I don't know [08:49] the source of the command line app xinput would be fine [08:50] well, XInput.h is not from xinput [08:50] but x11proto-input-dev.. [08:50] apt-get source xinput? [08:50] what are you trying to do? [08:51] I would like to see how xinput works and if I can interface to it with Python [08:52] well there you go [08:52] get the sources for xinput [08:53] 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] wgrant: yes, but I would like to get the device properties from Xinput and write fdi files [09:00] how's that going to work? [09:00] properties don't map into driver options [09:01] I have yet to see if that's possible [09:01] well I can tell you it's not :) [09:01] I would rather not hardcode options [09:02] do you know where options for fdis can be found for different devices? [09:02] man foo [09:02] where foo==evdev [09:02] hmm, or synaptics, joystick.. [09:03] aah, nice, that's actually easier [09:03] since I can parse the man page with my options data store [09:04] and those options are persistent. properties are not [09:04] yes, right [09:11] bryce: the new g-c-c works well [09:12] What's new with g-c-c? [09:13] 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] Ah. [09:13] I see. [09:13] tjaalton: .... even with the different API and ABI? [09:13] That hints that xinput is broken. [09:13] wgrant: well, those should be updated yes [09:13] wgrant: https://bugs.launchpad.net/ubuntu/intrepid/+source/gnome-control-center/+bug/275977 [09:13] speaking about new g-c-c could whoever did the changes or upload commit the bzr? [09:13] Launchpad bug 275977 in gnome-control-center "Setting the Virtual resolution should be easier" [Wishlist,Fix released] [09:14] wgrant: hmm, right.. it doesn't use a patch system so that could be it [09:14] tjaalton: So the patch was never applied? [09:14] It still shouldn't crash my X server, but that would explain why it wasn't working. [09:15] seb128: yes, I can do it [09:15] seb128: lp:~ubuntu-core-dev/gnome-control-center/ubuntu , right? [09:15] tseliot: thanks ;-) otherwise it's likely that next upload see the change dropped [09:15] tseliot: correct [09:15] ok [09:16] More likely that the next upload will be rejected... I've had that happen a few too many times. [09:16] I'll start doing my mvo and complaining about people not pushing their changes to bzr when uploading ;-) [09:16] wgrant: next upload is likely to be a new upstream version for GNOME 2.24.1 [09:16] wgrant: well looks like it wasn't applied, yes [09:16] duh [09:17] tjaalton: Well, that was an easy fix. [09:17] seb128: Ah. Even better. [09:17] wgrant: I bet it doesn't fix my mouse buttons though [09:18] which are broken with the updated server [09:18] tjaalton: True. [09:18] wgrant: did you see that? events only on buttonrelease [09:18] seb128: do you maintain gnome-desktop in bazaar too? [09:18] tjaalton: I use a touchpad normally, so it's not really noticable. [09:19] tseliot: no [09:19] tseliot: apt-get source tell you usually ;-) [09:19] right [09:19] 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] ok [09:21] seb128: I guess I'll have to create my own branch and ask mvo to merge from it right? [09:21] wgrant: um, sorry.. xinput is fine [09:21] after all [09:22] tjaalton: Damn. [09:22] mvo: bzr question for you there ;-) [09:22] tseliot: right, create your own branch and any core-dev can merge [09:22] mvo: ok [09:22] tseliot: you can also just sent me the debdiff and I merge this one (but the next one is for you ;) [09:23] ideally whoever upload should do the commit too because who has upload rights has commit rights too [09:23] mvo: I'll do it myself. You can use the time I'm saving you to read my email :-P [09:23] right [09:23] oh, right [09:23] damm [09:23] ETOOMUCH [09:24] * seb128 hugs mvo [09:24] sorry tseliot, please keep nagging me, I'm just busy with $STUFF, but it should be straightforward to merge your changes [09:25] mvo: no problem [09:40] 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] tjaalton: Heh, that might do it. [09:45] mvo: can you merge from lp:~albertomilone/gnome-control-center/randr-virtual when you have the time? [09:53] thanks tseliot, merged [09:54] mvo: thanks [10:04] wgrant: at least my mouse works now, but props still don't [10:19] tjaalton: BadRequest or similar? [10:21] wgrant: yep, and still shows the minor opcode as 41, when that shouldn't exist anymore [10:21] inputproto, libxi checked and verified to be ok [10:23] Huh. [11:41] tjaalton: can upload the new NVIDIA driver to Intrepid, please? https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-177/+bug/275098 [11:41] Launchpad bug 275098 in nvidia-graphics-drivers-177 "Packaging request, please upgrade to ver 177.80" [Wishlist,In progress] === crevette_ is now known as crevette [13:59] tjaalton: never mind [14:06] tseliot: I was on it, but got other stuff to do first [14:07] tjaalton: no problem, pitti is doing the upload for me. Thanks anyway [14:14] tseliot: ok, good [14:16] 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] :-/ [14:30] tseliot: 173 will probably get there [14:31] tjaalton: the problem is that 173 doesn't support some new nvidia cards [14:33] if only nvidia hadn't dropped the support for geforce 5xxx in 177... [14:38] that's what you get with proprietary blobs [18:21] 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] For instance, I had to restart X. [18:23] you shouldn't need to restart x [18:24] what driver are you using? [18:24] as for the 'not ideal' part, you'd have to be more precise [18:24] The free -ati driver. [18:25] Having to restart X was the worst glitch. [18:25] running 'xrandr --auto' should do the right thing there [18:25] can you put the output of "xrandr" on pastebin after you plug in the projector? [18:25] I used gnome-display-properties. It messed a bit with my xorg.conf and told me to restart X. [18:26] Maybe that's where the blame should be assigned. [18:26] I don't have the projector handy right now, but will try later. [18:26] johanbr: aah, you're not trying to use clone mode [18:26] you tried to set up the screens separately [18:27] What came up after the restart was cloned. [18:27] e.g. your projector to the right of your screen [18:27] that's normal [18:27] you have to log in [18:27] did you update the system today? [18:28] 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] tjaalton: would you like to have clone mode set by default? [18:28] yes [18:29] I believe that's the most common case [18:29] xorg.conf after gnome-display-properties had messed with it: http://pastebin.ca/1222902 [18:29] Well, gotta go. Back in about 1h. [18:30] yes, the virtual resolution was set [18:30] tjaalton: if bryce and/or seb128 agree we can change that [18:30] * tseliot > dinner [18:33] 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] 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] also left-of kills acceleration in quite some setups [19:06] 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] 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] 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] tjaalton: do you think we should put the "mirror screens" label in bold? [19:42] or do something else to highlight it? [19:45] tseliot: dunno, can't test it now [19:49] 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] wgrant, did your investigations of the brightness keys ever end up anywhere useful? [22:20] superm1: I know why my two issues happen, yes. [22:21] 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] wgrant, is the root cause solveable in a timely fashion? [22:22] 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] The many thousands of key events... well, I need to track down the source of the problem. [22:22] I don't think it happened in Hardy, but it might have just been that g-p-m was smarter. [22:23] well I've compared hardy side by side with two of the same system here, and things are much better in hardy [22:23] I'll likely find time to debug it properly tomorrow night... but it's unfortunate release timing given the coming exams... [22:23] superm1: What are your symptoms, again? [22:23] I lose focus for an extended period of time [22:23] roughly 40 seconds or so [22:23] whenever I change brightness [22:24] switching VTs restores focus [22:24] or killing GPM [22:25] If you run xev, give it focus, and hit a brightness key, do you see far too many events? [22:25] And do that stop when you hit another key? [22:25] s/that/they/ [22:25] `xrandr --prop | grep -i light` is also useful output. [22:26] should I kill gpm when i hit this brightness key? [22:26] Probably a good idea. [22:26] wgrant: that might be a kernel bug. i think some people already reported some keys not sending keyrelease. [22:26] jcristau: Would that cause tens of thousands of events? [22:27] Anyway, I need to leave for uni now... I won't be around for a few hours, [22:27] wgrant, oh yeah that's wayyy too many events [22:27] wgrant: probably, with key repeat [22:27] its like the key is stuck [22:27] Aha. [22:27] I thought it was too many for that, but I guess it's possible. [22:28] wgrant, regarding xrandr --prop, this machine uses nvidia-glx-177. dont' expect any swanky xrandr features [22:28] wgrant: you can change the autorepeat settings with xset, see if that affects what you're seeing? [22:36] 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] gvaroquaux: what bug? [23:22] bryce: any ideas about bug 210340? should it work? [23:22] Launchpad bug 210340 in xorg "install failure if 2 both monitors are active" [Undecided,Confirmed] https://launchpad.net/bugs/210340 [23:23] * bryce looks [23:26] 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] 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] bdmurray: re 210340 - I guess it should work, but obviously we're missing some important info [23:49] and without that, there's no proof that the me-tooer in comment #3 is seeing the same as the original reporter [23:50] okay, I wasn't sure if dual monitors on a Live CD should work [23:51] well, the issue is that they had two monitors plugged in [23:51] 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] worst case would be that output only appears on one monitor - that'd be acceptable [23:51] best case would be that they show up cloned [23:52] can you reverse the dupe, so 277724 is the primary? It has the more complete info and will be easier to upstream [23:52] also the reporter seems more actively engaged [23:52] yep, I think he posted to u-d-something [23:53] also, that bug can be filed against xserver-xorg-video-nv rather than xorg [23:53] mark it high/triaged, and I'll upstream it either today or tomorrow [23:55] bryce: cool, done [23:59] jcristau: Um, the brightness keys don't seem to generate any X events at all if key repeating is turned off.