| bryce | interesting; daniels has switched Zap off by default upstream | 00:42 |
|---|---|---|
| wgrant | Ooh. | 00:55 |
| wgrant | I was watching that argument, but gave up eventually. | 00:55 |
| bryce | I wish I had the time to follow all the upstream discussions | 01:23 |
| * bryce kicks launchpad aka timesucker | 01:24 | |
| 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:31 |
| 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:42 |
| 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. | 06:47 |
| bryce | tjaalton: filed 279999 on it | 07:16 |
| bryce | wow, I got a good lp# | 07:16 |
| tjaalton | bryce: dunno, I'll have a look | 07:39 |
| 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:40 |
| 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:41 |
| bryce | well, next one is in spain in feb | 07:43 |
| tjaalton | so soon? | 07:44 |
| 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 :) | 07:48 |
| 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:16 |
| tjaalton | no need to set SendCoreEvents btw | 08:17 |
| 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:21 |
| bryce | hrm | 08:22 |
| tjaalton | current rules match input.mouse or input.keys | 08:22 |
| tjaalton | oh, same applies to info.product.. | 08:22 |
| tjaalton | I don't know where those are normally coming from | 08:25 |
| bryce | kernel maybe? hmm | 08:28 |
| bryce | well, I'll bounce it back to henrik I guess | 08:28 |
| tseliot | tjaalton: do you happen to know in which package I can find XInput.c? | 08:44 |
| tseliot | tjaalton: not the compiled binary, just the source | 08:45 |
| tjaalton | tseliot: there isn't one | 08:47 |
| tseliot | tjaalton: but I have /usr/include/X11/extensions/XInput.h | 08:48 |
| tjaalton | that doesn't imply there's XInput.c | 08:48 |
| 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:49 |
| 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:50 |
| tseliot | I would like to see how xinput works and if I can interface to it with Python | 08:51 |
| tjaalton | well there you go | 08:52 |
| tjaalton | get the sources for xinput | 08:52 |
| tseliot | yes, that worked well and should be enough. Thanks | 08:53 |
| * wgrant used xinput as a reference for the g-c-c stuff. | 08:57 | |
| tseliot | wgrant: yes, but I would like to get the device properties from Xinput and write fdi files | 08:58 |
| tjaalton | how's that going to work? | 09:00 |
| tjaalton | properties don't map into driver options | 09:00 |
| 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:01 |
| 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:02 |
| tseliot | aah, nice, that's actually easier | 09:03 |
| tseliot | since I can parse the man page with my options data store | 09:03 |
| tjaalton | and those options are persistent. properties are not | 09:04 |
| tseliot | yes, right | 09:04 |
| tseliot | bryce: the new g-c-c works well | 09:11 |
| wgrant | What's new with g-c-c? | 09:12 |
| 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:13 |
| ubottu | Launchpad bug 275977 in gnome-control-center "Setting the Virtual resolution should be easier" [Wishlist,Fix released] | 09:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| 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:17 |
| 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:18 |
| 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:19 |
| 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:21 |
| 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:22 |
| 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:23 |
| * 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:24 |
| tseliot | mvo: no problem | 09:25 |
| 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:40 |
| wgrant | tjaalton: Heh, that might do it. | 09:43 |
| tseliot | mvo: can you merge from lp:~albertomilone/gnome-control-center/randr-virtual when you have the time? | 09:45 |
| mvo | thanks tseliot, merged | 09:53 |
| tseliot | mvo: thanks | 09:54 |
| tjaalton | wgrant: at least my mouse works now, but props still don't | 10:04 |
| wgrant | tjaalton: BadRequest or similar? | 10:19 |
| 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:21 |
| wgrant | Huh. | 10:23 |
| tseliot | tjaalton: can upload the new NVIDIA driver to Intrepid, please? https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-177/+bug/275098 | 11:41 |
| ubottu | Launchpad bug 275098 in nvidia-graphics-drivers-177 "Packaging request, please upgrade to ver 177.80" [Wishlist,In progress] | 11:41 |
| === crevette_ is now known as crevette | ||
| tseliot | tjaalton: never mind | 13:59 |
| tjaalton | tseliot: I was on it, but got other stuff to do first | 14:06 |
| tseliot | tjaalton: no problem, pitti is doing the upload for me. Thanks anyway | 14:07 |
| tjaalton | tseliot: ok, good | 14:14 |
| 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:16 |
| tseliot | :-/ | 14:17 |
| tjaalton | tseliot: 173 will probably get there | 14:30 |
| tseliot | tjaalton: the problem is that 173 doesn't support some new nvidia cards | 14:31 |
| tseliot | if only nvidia hadn't dropped the support for geforce 5xxx in 177... | 14:33 |
| tjaalton | that's what you get with proprietary blobs | 14:38 |
| 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:21 |
| jcristau | you shouldn't need to restart x | 18:23 |
| 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:24 |
| 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:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| 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:29 |
| 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:30 | |
| 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:33 |
| 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:36 |
| jcristau | also left-of kills acceleration in quite some setups | 18:37 |
| 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:06 |
| 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:07 |
| 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:09 | |
| tseliot | tjaalton: do you think we should put the "mirror screens" label in bold? | 19:41 |
| tseliot | or do something else to highlight it? | 19:42 |
| tjaalton | tseliot: dunno, can't test it now | 19:45 |
| tseliot | there's no hurry | 19:49 |
| * wgrant looks at porting syndaemon to input properties in order to remove the final need for SHMConfig and placate various users. | 22:00 | |
| 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:20 |
| 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:21 |
| 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:22 |
| 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:23 |
| superm1 | switching VTs restores focus | 22:24 |
| superm1 | or killing GPM | 22:24 |
| 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:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| 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. | 22:36 |
| bdmurray | gvaroquaux: what bug? | 23:21 |
| bdmurray | bryce: any ideas about bug 210340? should it work? | 23:22 |
| ubottu | Launchpad bug 210340 in xorg "install failure if 2 both monitors are active" [Undecided,Confirmed] https://launchpad.net/bugs/210340 | 23:22 |
| * bryce looks | 23:23 | |
| 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:26 |
| 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:31 |
| 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:49 |
| bdmurray | okay, I wasn't sure if dual monitors on a Live CD should work | 23:50 |
| 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:51 |
| 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:52 |
| 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:53 |
| bdmurray | bryce: cool, done | 23:55 |
| wgrant | jcristau: Um, the brightness keys don't seem to generate any X events at all if key repeating is turned off. | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!