[00:25] /away [00:25] uh [09:38] tjaalton: thinking about it, we could only do the xhost trick for local sessions (otherwise you're telling the x server to trust some random user). not sure it's worth it... [09:39] as in, you need to detect those somewhat reliably [09:40] jcristau: running 'id -un' isn't enough? [09:42] jcristau: that's what fedora does, allows only the session user to connect [09:48] in xinit it's ok, since that creates a local session anyway [09:48] but, if you put that in Xsession.d, you have to handle remote sessions, where `id -un` on the client may not have anything to do with uids on the server [09:49] hmm, ok [11:28] wgrant: I've now installed the packages from my PPA, and xinput list-props $id just gives me a BadRequest [11:29] so something is broken in the backport [11:32] what's the request id? [11:32] tjaalton: Ergh. [11:33] jcristau: Major 146, minor 41 [11:33] (XInputExtension) [11:34] hrm [11:34] #define X_WarpDevicePointer 41 [11:34] that's XI2 [11:34] Those were just renumbered in XI2... [11:35] But. [11:35] Hmm. [11:35] Hmmm. [11:35] did you update inputproto, then libxi, then xinput? [11:36] I should have, but maybe some build-dep was broken so xinput was built against the old packages [11:36] will check [11:36] 41 used to be GetDeviceProperty [11:36] Sounds like xinput was built before publishing. [11:36] yeah [11:36] grr [11:38] hmm no, it was built against my versions [11:38] It's a bit odd that it hardlocks my laptop. [11:38] and libxi was built against the right inputproto? [11:38] just listing the props? [11:39] tjaalton: Correct. [11:39] jcristau: yes.. [11:39] I need to go through them once more.. [11:39] Well, it did last night, but I've not changed anything since and daren't try again right now. === Ng_ is now known as Ng [13:57] tseliot: hi, are you around? I have a system with quite an old nvidia card and jockey doesn't suggest that I may want to install a different driver for it. How can I debug this? [14:00] james_w: what does jockey do, exactly? [14:01] "No proprietary drivers are in use on this system" [14:01] and nothing listed in the UI at all [14:02] it's correct, but I thought it would show the chance to turn nvidia on [14:02] james_w: if it's an old card, then that may not be an option? [14:03] it used to be nvidia, were some dropped in Intrepid? [14:03] james_w: can you put the output of "sudo aptitude search nvidia" in pastebin? [14:03] maybe some modalias packages are not available [14:03] sure [14:03] james_w: how did you upgrade? [14:04] I don't remember now, it was very early [14:04] I wonder if its driver -71 or -96 were we have no xserver 1.5 support ? [14:04] james_w: aha, ok :) I'm looking for testing feedback of the current upgrader for people with nvidia hardware/drivers [14:05] mvo: it's my second machine, so I'll consider reinstalling hardy and upgrading [14:06] http://paste.ubuntu.com/52840/ [14:06] james_w: nvidia-common wasn't installed during the dist-upgrade [14:07] james_w: aha, ok. that system looks like a good test candidate [14:07] try installing nvidia-common and then launch jockey again [14:07] NOTE: don't try to install -71 or 96 (they don't work) [14:09] haven't we blacklisted those yet? [14:09] mvo: no, not yet [14:09] aha, ok [14:09] I have worked on the gnome-control-center [14:09] nothing [14:10] the same as before [14:10] james_w: can I see the output of this command? lspci -n | grep 300 [14:11] 02:00.0 0300: 10de:0201 (rev a3) [14:12] james_w: this is weird. Your card is supported: :/usr/share/jockey/modaliases$ grep 0201 * [14:12] nvidia-71:alias pci:v000010DEd00000201sv*sd*bc03sc*i* nvidia nvidia-glx-71 [14:12] nvidia-96:alias pci:v000010DEd00000201sv*sd*bc03sc*i* nvidia nvidia-glx-96 [14:12] did nvidia-common install other packages? [14:13] nvidia-{71,96,173,177}-modaliases [14:13] e.g. nvidia-96-modaliases, nvidia-71-modaliases [14:14] ok, try killing jockey-backend [14:14] and start jockey again [14:14] ps aux should show jockey-backend [14:15] aha! [14:15] thanks [14:15] but you say don't install 71 or 96? [14:15] ok, now don't install those drivers [14:15] they are not compatible with the new Xorg ABI [14:15] are they likely to be fixed by the release? [14:16] therefore I didn't bother patching them to make them compatible with kernel 2.6.27 [14:16] I have no idea... [14:16] ok, thanks for your help [14:17] you're welcom [14:17] e [17:33] whoa, jim gettys reported bug 276782 to launchpda [17:33] Launchpad bug 276782 in xserver-xorg-video-ati "X server crashes on rotation in xf86ResizeOffscreenLinear+0x3b" [Undecided,New] https://launchpad.net/bugs/276782 [17:39] heh, shouldn't he be fixing it too? ;) [17:52] ;-) [18:16] hey bryce. [18:17] would you have a moment to look at bug 276680? [18:17] Launchpad bug 276680 in gnome-control-center "gnome-display-properties: "Detect Displays" does not work" [Undecided,New] https://launchpad.net/bugs/276680 [18:17] I'm not really sure which component is at fault here [18:17] heya james_w, one sec, looking at a bug for heno atm [18:17] sure, no rush [18:20] james_w: if he starts X with vga disconnected, the server doesn't allocate a framebuffer big enough for the vga monitor's native resolution [18:21] jcristau: the "Virtual" setting? [18:21] yeah [18:22] his first xrandr output says 'maximum 1024 x 1024'; 1280x1024 doesn't fix [18:22] fit, even [18:22] so the framebuffer allocated depends on what's plugged in when X starts? [18:22] yes [18:23] if there's no Virtual directive, anyway [18:27] ok, so close the bug as Invalid and ask him to set a Virtual [18:29] well, it's still a bug that we can't resize the framebuffer [18:29] just not one that'll be fixed tomorrow [18:31] thanks [18:33] james_w: yeah if it's the virtual directive stuff, we surely have a bug open on that already; in any case it's an upstream issue === mvo_ is now known as mvo [20:50] tjaalton: btw, I've been cherrypicking some -ati patches from current git [20:50] tjaalton: maybe it'd be better to just grab a new snapshot, but release team probably would prefer cherrypicks [20:50] bryce: good.. upstream should learn how to release though ;) [20:52] yeah... [20:52] of course then I think I probably should volunteer to help with that... [20:53] I'll be happy if they just apply one or two of my patches ;-) [20:53] http://www.bryceharrington.org/ubuntu/Ati/ === Adri2000_ is now known as Adri2000 [22:16] bryce: it seems upstream leaves it all up to the distros to make a stable driver, which of course makes for duplicated work. [22:17] one could say that upstream here is redhat though :) [22:18] :-/ [22:18] maybe some people from a couple of distros should make a stable branch and cherry-pick things to it. it doesn't have to be Alex doing that. [22:18] tormod: well in fairness the git tree for -ati currently looks mainly like bug fixes so far [22:18] (although some of the changes in recent weeks are what's caused the bugs) [22:19] hmm, you know, establishing a stable branch might not be a bad idea. [22:19] currently yes, the problem is that you never know before afterwards :) [22:20] if Alex likes the idea, he might be helpful in saying "this should go in stable", or "now the tree is stable, time to branch" [22:21] he likes to think that master is always stable, but it's hard to convince release managers about that. [22:21] yes, he's given that kind of advice for me previously (gutsy iirc) [22:22] Btw, i was under the impression the reason for the ABI change that made some versions of fglrx incompatible with X in intrepid was because of MPX. Since intrepid doesn’t have MPX, what caused the ABI change? [22:22] just having a parallel branch almost like master would help to get things past the RM :) [22:24] 6.9.0.1 looks much better than 6.9.0+git20080925 :) [22:25] agreed [22:25] hmm, well too late really for intrepid in any case [22:26] (probably...) [22:26] likely a good practice for jaunty tho [22:26] esp if we run into trouble with -fglrx again [22:27] Probably, if the ABI change caused by MPX is yet to come. :-) [22:29] ion_: I heard the X changes that broke -fglrx was the devprivates rework. Dunno if that involves MPX or not [22:29] afaik the MPX changes still lay in the future [22:30] mpx changes came past 1.5 I think [22:30] Alright, thanks [22:34] tjaalton: do the brightness hotkeys on your thinkpad work? [22:40] They do on mine, if that’s relevant. [23:42] ion_: most important abi changes from 1.4 to 1.5 are devprivates rework, which was part of the selinux work, and also pci-rework [23:42] iirc