bryce | I wonder if we should consider pulling radeonhd into main yet? | 01:12 |
---|---|---|
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 | 01:36 |
bryce | I've finished outlining -fglrx status too: https://wiki.ubuntu.com/X/Drivers | 02:58 |
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. | 02:59 |
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:23 |
bryce | yeah | 05:57 |
bryce | well, couldn't we have it in main but not the default? | 05:58 |
bryce | tjaalton: wow check this new tool out: https://edge.launchpad.net/ubuntu/+upstreamreport | 06:07 |
tjaalton | well, if it's not installed by xserver-xorg-video-all, what's the point in having it in main :) | 06:10 |
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:11 |
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:12 |
tjaalton | maybe the first it finds, which would be ati | 06:13 |
bryce | hmm | 06:14 |
tjaalton | hum, new intel. I'll merge it today | 06:14 |
tjaalton | *-desktop still depends on xresprobe | 06:57 |
tjaalton | bryce: still here? | 09:56 |
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:57 |
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:58 |
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... | 09:59 |
tjaalton | Q-FUNK: glad that I didn't include it then ;) | 10:00 |
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:01 |
tjaalton | bryce: just to check if they should be fixed or are marked as blockers | 10:03 |
bryce | 114331 135093 147189 157610 16887 131972 and probably others | 10:04 |
tjaalton | hmm, that's a lot :) | 10:05 |
bryce | indeed | 10:05 |
tjaalton | although 16887 seems to be invalid/fixed by now | 10:06 |
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:07 |
bryce | great | 10:08 |
bryce | ok, going to bed. cya tomorrow | 10:08 |
tjaalton | bryce: night | 10:09 |
Q-FUNK | did bryce switch to .AU time? | 10:13 |
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:14 |
Q-FUNK | ...and now traveling to AU | 10:15 |
Q-FUNK | this gets confusing :) | 10:15 |
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:16 |
jcristau | Q-FUNK: have you actually read that patch? | 10:17 |
Q-FUNK | jcristau: no, I just applied and tested whether it builds cleanly on all arch. | 10:18 |
jcristau | sigh | 10:18 |
jcristau | maybe you should, then | 10:19 |
Q-FUNK | I notice an ifdef for amd64 | 10:19 |
Q-FUNK | right. a conditional include for 64-bit build. | 10:20 |
Q-FUNK | which apparently fails. | 10:20 |
Q-FUNK | nice bit of ASM there | 10:21 |
Q-FUNK | jcristau: ok. I see your point. any suggestion on how to fix this? | 10:22 |
tjaalton | Q-FUNK: bug the writer? | 10:23 |
jcristau | i thought that was obvious, but don't build i386 asm on amd64? | 10:23 |
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:27 |
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:28 |
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:29 |
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:30 |
jcristau | once again: because you're running bios calls | 10:31 |
Q-FUNK | once again: other architectures don't even have a BIOS. | 10:32 |
jcristau | they do | 10:34 |
jcristau | so if you want to use it to POST the card on !x86, you need an emulator | 10:35 |
tjaalton | bryce: so apart from 147189 none of those bug reports have seen an update during hardy. I'd say it's looking good | 11:02 |
ubotu | New bug: #189579 in xorg-server (main) "xephyr should have a menu entry" [Undecided,New] https://launchpad.net/bugs/189579 | 14:46 |
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 | 14:59 |
ubotu | New bug: #189599 in xorg (main) "[Hardy] Ubuntu does not remember the screen resolution" [Undecided,New] https://launchpad.net/bugs/189599 | 15:40 |
tjaalton | oh crap, so the new intel just hangs | 16:16 |
pochu | Is that a new feature? :-) | 16:21 |
tjaalton | I bet | 16:21 |
tjaalton | right, it's already reported on xorg@ | 16:27 |
bryce | erf, that's the 2.3 driver? | 16:35 |
tjaalton | no, 2.2.0.90 | 16:35 |
tjaalton | which will become 2.2.1 | 16:36 |
tjaalton | I'll revert the change that broke it | 16:36 |
jcristau | tjaalton: jbarnes just posted a new patch | 16:37 |
tjaalton | jcristau: oh cool | 16:37 |
tjaalton | jcristau: where exactly? | 16:38 |
tjaalton | can't see it on gitweb or on the list | 16:38 |
jcristau | tjaalton: list | 16:39 |
tjaalton | damn snailmail | 16:40 |
tjaalton | ok got it | 16:42 |
tjaalton | building | 16:42 |
tjaalton | now it doesn't hang, but the output is on the wrong port | 16:44 |
bryce | (hmm not boding well) | 16:46 |
tjaalton | it works after all | 16:58 |
tjaalton | I had to reboot though | 16:58 |
tjaalton | phew | 16:59 |
bryce | cool | 17:02 |
bryce | gotta be more careful with that upload button ;-) | 17:02 |
tjaalton | glad I tried it before leaving | 17:03 |
tjaalton | fix uploaded | 17:11 |
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 | 18:30 |
ubotu | New bug: #189690 in mesa (main) "libGLw.so is not provided by a package" [Undecided,New] https://launchpad.net/bugs/189690 | 19:43 |
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:11 |
bryce | hmm, here's a question - will we support upgrades of dual-head systems from Dapper with Xinerama to Hardy with Xrandr? | 20:17 |
tjaalton | heh, sounds like a real nightmare | 21:11 |
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:29 |
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:31 |
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:32 |
tjaalton | that's one example why a robust gui configurator would be nice to have | 21:33 |
jcristau | don't people have bullet-pproof-x to[B[B[B | 21:41 |
tjaalton | :) | 21:43 |
bryce | :-P | 21:44 |
jcristau | sorry | 21:44 |
jcristau | ssh lag | 21:44 |
bryce | it made me laugh though ;-) | 21:45 |
soren | How can I see which program stole my input focus? | 21:45 |
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:46 |
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:47 |
bryce | not sure, but there's been a few of those bugs reported | 21:49 |
soren | chvt'ing away from X and back doesn't fix it. That surprised me somewhat. | 21:50 |
bryce | but the keyboard works ok when you're at a vt I take it? | 21:56 |
soren | Yeah, no problems there. | 21:56 |
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:57 |
bryce | wow, searching ubuntu for "keyboard stops working" gives 100 hits | 21:59 |
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:02 |
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:03 |
tjaalton | I think the issue is new with xserver 1.4 | 22:10 |
tjaalton | soren: how often do you see it? | 22:10 |
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:11 |
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:12 |
soren | That's how I did the x2x thing. | 22:13 |
tjaalton | x2x? | 22:13 |
soren | Yes. | 22:13 |
tjaalton | ah | 22:13 |
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:14 |
soren | O_O | 22:16 |
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:17 |
tjaalton | I need to try that at work | 22:18 |
jcristau | it needs a maintainer ;) | 22:19 |
tjaalton | hehe :) | 22:19 |
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:24 |
soren | wfm | 22:27 |
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 | 22:44 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!