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