[01:12] I wonder if we should consider pulling radeonhd into main yet? [01:36] New bug: #185809 in restricted-manager "[hardy] restricted-manager break xorg when enabling fglrx (dup-of: 188409)" [Undecided,New] https://launchpad.net/bugs/185809 [02:58] I've finished outlining -fglrx status too: https://wiki.ubuntu.com/X/Drivers [02:59] please update if anyone spots inaccuracies; I'm going off second hand reports + judgment for many of the reported issues so could easily be mistaken on some details. [05:23] bryce: then radeonhd and ati would be fighting over r5xx-> cards [05:23] I don't know how that would work out [05:57] yeah [05:58] well, couldn't we have it in main but not the default? [06:07] tjaalton: wow check this new tool out: https://edge.launchpad.net/ubuntu/+upstreamreport [06:10] well, if it's not installed by xserver-xorg-video-all, what's the point in having it in main :) [06:11] s/point in/point of/ [06:11] can't it be installed by -all, but not selected as the default driver in xserver? [06:12] both ati and radeonhd support the same pci-id's (or a subset of them in case of radeonhd), so I'm not sure how the xserver chooses the default then [06:13] maybe the first it finds, which would be ati [06:14] hmm [06:14] hum, new intel. I'll merge it today [06:57] *-desktop still depends on xresprobe [09:56] bryce: still here? [09:57] tjaalton: that CPUID patch did something weird on amd64. I'm not sure what to make of the build log on my PPA. [09:57] tjaalton: yup (barely though) [09:58] bryce: ok, now that intel 2.2.1 is close, what should we do with -i810? it's not used by default anyway, everyone is "forced" to -intel [09:59] since the server autoloads intel [09:59] well, I have a few bugs in on -i810 migration issues that still remain unfixed, so I generally think we have to keep i810 for now [09:59] I've been hopeful we can deprecate it in time for hardy though, but... [10:00] Q-FUNK: glad that I didn't include it then ;) [10:01] tjaalton: :) [10:01] bryce: ok, do you remember which #'s? [10:01] https://launchpad.net/~q-funk/+archive/+builds?build_text=&build_state=failed [10:03] bryce: just to check if they should be fixed or are marked as blockers [10:04] 114331 135093 147189 157610 16887 131972 and probably others [10:05] hmm, that's a lot :) [10:05] indeed [10:06] although 16887 seems to be invalid/fixed by now [10:07] please go ahead and update; I've not had a chance to get them all updated [10:07] ok, I'll forward upstream those that aren't already [10:08] great [10:08] ok, going to bed. cya tomorrow [10:09] bryce: night [10:13] did bryce switch to .AU time? [10:14] it's just 2AM in Portland ;) [10:14] oh [10:14] I thought that he was in UK [10:14] heh [10:15] ...and now traveling to AU [10:15] this gets confusing :) [10:16] hm. i really wonder why that build failed only on amd64. could there be some 32-bit only code in bartman's patch? [10:16] no idea [10:17] Q-FUNK: have you actually read that patch? [10:18] jcristau: no, I just applied and tested whether it builds cleanly on all arch. [10:18] sigh [10:19] maybe you should, then [10:19] I notice an ifdef for amd64 [10:20] right. a conditional include for 64-bit build. [10:20] which apparently fails. [10:21] nice bit of ASM there [10:22] jcristau: ok. I see your point. any suggestion on how to fix this? [10:23] Q-FUNK: bug the writer? [10:23] i thought that was obvious, but don't build i386 asm on amd64? [10:27] jcristau: this whole construct is an emulator to begin with. I already find it suspicious that we're trying to make every video and input hardware in the universe appear to X as x86 hardware, in the first place. [10:28] Q-FUNK: that's the point of an emulator [10:28] sure, it is. but native code for each architecture, rather than forcing the whole universe to appear as x86 hardware, would seem to be a more productive approach. [10:29] it would also be a nice wat to get rid of that dependence on legacy BIOS calls for everything. [10:29] the bios is x86 code [10:30] so if you're not an i386, you have to emulate that if you want to call into the bios [10:30] why should we force non-x86 architectures to play as if they were x86, though? [10:30] meh [10:31] once again: because you're running bios calls [10:32] once again: other architectures don't even have a BIOS. [10:34] they do [10:35] so if you want to use it to POST the card on !x86, you need an emulator [11:02] bryce: so apart from 147189 none of those bug reports have seen an update during hardy. I'd say it's looking good [14:46] New bug: #189579 in xorg-server (main) "xephyr should have a menu entry" [Undecided,New] https://launchpad.net/bugs/189579 [14:59] New bug: #186999 in restricted-manager "Dell OEM ATI graphics chip not recognised by Restricted Drivers Manager" [Undecided,Invalid] https://launchpad.net/bugs/186999 [15:40] New bug: #189599 in xorg (main) "[Hardy] Ubuntu does not remember the screen resolution" [Undecided,New] https://launchpad.net/bugs/189599 [16:16] oh crap, so the new intel just hangs [16:21] Is that a new feature? :-) [16:21] I bet [16:27] right, it's already reported on xorg@ [16:35] erf, that's the 2.3 driver? [16:35] no, 2.2.0.90 [16:36] which will become 2.2.1 [16:36] I'll revert the change that broke it [16:37] tjaalton: jbarnes just posted a new patch [16:37] jcristau: oh cool [16:38] jcristau: where exactly? [16:38] can't see it on gitweb or on the list [16:39] tjaalton: list [16:40] damn snailmail [16:42] ok got it [16:42] building [16:44] now it doesn't hang, but the output is on the wrong port [16:46] (hmm not boding well) [16:58] it works after all [16:58] I had to reboot though [16:59] phew [17:02] cool [17:02] gotta be more careful with that upload button ;-) [17:03] glad I tried it before leaving [17:11] fix uploaded [18:30] New bug: #189666 in linux-restricted-modules-2.6.24 (restricted) "Intel iwl4965 microcode not included in rt restricted modules" [Undecided,New] https://launchpad.net/bugs/189666 [19:43] New bug: #189690 in mesa (main) "libGLw.so is not provided by a package" [Undecided,New] https://launchpad.net/bugs/189690 [20:11] New bug: #189692 in xserver-xorg-video-intel (main) "problem with intel card and resolution (dup-of: 189694)" [Undecided,New] https://launchpad.net/bugs/189692 [20:17] hmm, here's a question - will we support upgrades of dual-head systems from Dapper with Xinerama to Hardy with Xrandr? [21:11] heh, sounds like a real nightmare [21:29] yeah I just flashed on that after closing a dapper-era xinerama upgrade bug. o_O [21:29] it's just not doable [21:31] I'm worried that if we're going to advertise working upgrades from Dapper->Gutsy, it's going to bite us on the butt if people expect a Dapper-era xorg.conf to be supported without issue on Hardy [21:32] I think we're going to need to have the upgrade process move aside their xorg.conf and generate a new one [21:32] but even that can lead us into problems... [21:33] that's one example why a robust gui configurator would be nice to have [21:41] don't people have bullet-pproof-x to[B[B[B [21:43] :) [21:44] :-P [21:44] sorry [21:44] ssh lag [21:45] it made me laugh though ;-) [21:45] How can I see which program stole my input focus? [21:46] uhhh [21:46] Hm.. No, that can't be it, now that I think about it. [21:46] hrm, I wrote a test code to re-steal focus and restore it, but I don't know if it's possible to determine what took it to begin with [21:46] X just stopped accepting keyboard input from me. [21:46] is this in kvm or in general? [21:46] General [21:47] If I do the x2x trick, I can type on my laptop and it shows up, so it's not a focus problem. [21:47] It's just.. Odd. [21:49] not sure, but there's been a few of those bugs reported [21:50] chvt'ing away from X and back doesn't fix it. That surprised me somewhat. [21:56] but the keyboard works ok when you're at a vt I take it? [21:56] Yeah, no problems there. [21:57] bug 184078 is the one I was thinking of [21:57] Launchpad bug 184078 in xorg "keyboard stops working until logout" [High,Confirmed] https://launchpad.net/bugs/184078 [21:57] does that match your issue? [21:59] wow, searching ubuntu for "keyboard stops working" gives 100 hits [22:02] bug 58884 sounds a bit closer to your symptoms actually [22:02] Launchpad bug 58884 in xserver-xorg-input-keyboard "Random keyboard failure in X" [Undecided,Incomplete] https://launchpad.net/bugs/58884 [22:03] I can't even ctrl-alt-f1 to get away from X. It completely ignores me. [22:03] hmm, nope that bug's ancient [22:03] in fact it looks abandoned. I'll invalidate it and shoo away the me-too'ers [22:10] I think the issue is new with xserver 1.4 [22:10] soren: how often do you see it? [22:11] tjaalton: This is the first time, i think. [22:11] ok [22:11] tjaalton: Er.. Strike the "I think" part. I would certainly have noticed it if it had happened before. [22:11] mouse works normally, you can do stuff with it? [22:11] Sure. [22:12] ok, so the server is not hung :) [22:12] damn [22:12] can you ssh to the box? [22:12] Sure. [22:12] the log might help, or not :) [22:13] That's how I did the x2x thing. [22:13] x2x? [22:13] Yes. [22:13] ah [22:14] It allows you to use one keyboard and one mouse on two different X servers. [22:14] ..it places a window on an edge of your screen and sends events to the remove X server using the XTEST extension. [22:14] neat, haven't seen that before :) [22:16] O_O [22:17] Oh, it's pretty nifty. [22:17] It's default mode of operation is quite boring. You want the -{north,east,south,west} option. [22:18] I need to try that at work [22:19] it needs a maintainer ;) [22:19] hehe :) [22:24] heh, I used x2x for a wonky 2-machine multi-head thingee I did a long time ago [22:24] I remember it being a bit quirky [22:27] wfm [22:44] bryce: I'll close the libGLw.so bug as wontfix, since it would pull lesstif into main. I believe the security team still doesn't want to support that [22:44] tjaalton: sounds good