bryceI wonder if we should consider pulling radeonhd into main yet?01:12
ubotuNew bug: #185809 in restricted-manager "[hardy] restricted-manager break xorg when enabling fglrx (dup-of: 188409)" [Undecided,New] https://launchpad.net/bugs/18580901:36
bryceI've finished outlining -fglrx status too:  https://wiki.ubuntu.com/X/Drivers02:58
bryceplease 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
tjaaltonbryce: then radeonhd and ati would be fighting over r5xx-> cards05:23
tjaaltonI don't know how that would work out05:23
brycewell, couldn't we have it in main but not the default?05:58
brycetjaalton: wow check this new tool out:  https://edge.launchpad.net/ubuntu/+upstreamreport06:07
tjaaltonwell, if it's not installed by xserver-xorg-video-all, what's the point in having it in main :)06:10
tjaaltons/point in/point of/06:11
brycecan't it be installed by -all, but not selected as the default driver in xserver?06:11
tjaaltonboth 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 then06:12
tjaaltonmaybe the first it finds, which would be ati06:13
tjaaltonhum, new intel. I'll merge it today06:14
tjaalton*-desktop still depends on xresprobe06:57
tjaaltonbryce: still here?09:56
Q-FUNKtjaalton: that CPUID patch did something weird on amd64.  I'm not sure what to make of the build log on my PPA.09:57
brycetjaalton: yup (barely though)09:57
tjaaltonbryce: 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 -intel09:58
tjaaltonsince the server autoloads intel09:59
brycewell, I have a few bugs in on -i810 migration issues that still remain unfixed, so I generally think we have to keep i810 for now09:59
bryceI've been hopeful we can deprecate it in time for hardy though, but...09:59
tjaaltonQ-FUNK: glad that I didn't include it then ;)10:00
Q-FUNKtjaalton:  :)10:01
tjaaltonbryce: ok, do you remember which #'s?10:01
tjaaltonbryce: just to check if they should be fixed or are marked as blockers10:03
bryce114331  135093  147189  157610  16887  131972  and probably others10:04
tjaaltonhmm, that's a lot :)10:05
tjaaltonalthough 16887 seems to be invalid/fixed by now10:06
bryceplease go ahead and update; I've not had a chance to get them all updated10:07
tjaaltonok, I'll forward upstream those that aren't already10:07
bryceok, going to bed.  cya tomorrow10:08
tjaaltonbryce: night10:09
Q-FUNKdid bryce switch to .AU time?10:13
tjaaltonit's just 2AM in Portland ;)10:14
Q-FUNKI thought that he was in UK10:14
Q-FUNK...and now traveling to AU10:15
Q-FUNKthis gets confusing :)10:15
Q-FUNKhm. i really wonder why that build failed only on amd64.  could there be some 32-bit only code in bartman's patch?10:16
tjaaltonno idea10:16
jcristauQ-FUNK: have you actually read that patch?10:17
Q-FUNKjcristau: no, I just applied and tested whether it builds cleanly on all arch.10:18
jcristaumaybe you should, then10:19
Q-FUNKI notice an ifdef for amd6410:19
Q-FUNKright.  a conditional include for 64-bit build.10:20
Q-FUNKwhich apparently fails.10:20
Q-FUNKnice bit of ASM there10:21
Q-FUNKjcristau: ok.  I see your point.  any suggestion on how to fix this?10:22
tjaaltonQ-FUNK: bug the writer?10:23
jcristaui thought that was obvious, but don't build i386 asm on amd64?10:23
Q-FUNKjcristau: 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
jcristauQ-FUNK: that's the point of an emulator10:28
Q-FUNKsure, 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-FUNKit would also be a nice wat to get rid of that dependence on legacy BIOS calls for everything.10:29
jcristauthe bios is x86 code10:29
jcristauso if you're not an i386, you have to emulate that if you want to call into the bios10:30
Q-FUNKwhy should we force non-x86 architectures to play as if they were x86, though?10:30
jcristauonce again: because you're running bios calls10:31
Q-FUNKonce again: other architectures don't even have a BIOS.10:32
jcristauthey do10:34
jcristauso if you want to use it to POST the card on !x86, you need an emulator10:35
tjaaltonbryce: so apart from 147189 none of those bug reports have seen an update during hardy. I'd say it's looking good11:02
ubotuNew bug: #189579 in xorg-server (main) "xephyr should have a menu entry" [Undecided,New] https://launchpad.net/bugs/18957914:46
ubotuNew bug: #186999 in restricted-manager "Dell OEM ATI graphics chip not recognised by Restricted Drivers Manager" [Undecided,Invalid] https://launchpad.net/bugs/18699914:59
ubotuNew bug: #189599 in xorg (main) "[Hardy] Ubuntu does not remember the screen resolution" [Undecided,New] https://launchpad.net/bugs/18959915:40
tjaaltonoh crap, so the new intel just hangs16:16
pochuIs that a new feature? :-)16:21
tjaaltonI bet16:21
tjaaltonright, it's already reported on xorg@16:27
bryceerf, that's the 2.3 driver?16:35
tjaaltonwhich will become 2.2.116:36
tjaaltonI'll revert the change that broke it16:36
jcristautjaalton: jbarnes just posted a new patch16:37
tjaaltonjcristau: oh cool16:37
tjaaltonjcristau: where exactly?16:38
tjaaltoncan't see it on gitweb or on the list16:38
jcristautjaalton: list16:39
tjaaltondamn snailmail16:40
tjaaltonok got it16:42
tjaaltonnow it doesn't hang, but the output is on the wrong port16:44
bryce(hmm not boding well)16:46
tjaaltonit works after all16:58
tjaaltonI had to reboot though16:58
brycegotta be more careful with that upload button ;-)17:02
tjaaltonglad I tried it before leaving17:03
tjaaltonfix uploaded17:11
ubotuNew 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/18966618:30
ubotuNew bug: #189690 in mesa (main) "libGLw.so is not provided by a package" [Undecided,New] https://launchpad.net/bugs/18969019:43
ubotuNew bug: #189692 in xserver-xorg-video-intel (main) "problem with intel card and resolution (dup-of: 189694)" [Undecided,New] https://launchpad.net/bugs/18969220:11
brycehmm, here's a question - will we support upgrades of dual-head systems from Dapper with Xinerama to Hardy with Xrandr?20:17
tjaaltonheh, sounds like a real nightmare21:11
bryceyeah I just flashed on that after closing a dapper-era xinerama upgrade bug.  o_O21:29
tjaaltonit's just not doable21:29
bryceI'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 Hardy21:31
bryceI think we're going to need to have the upgrade process move aside their xorg.conf and generate a new one21:32
brycebut even that can lead us into problems...21:32
tjaaltonthat's one example why a robust gui configurator would be nice to have21:33
jcristaudon't people have bullet-pproof-x to[B[B[B21:41
jcristaussh lag21:44
bryceit made me laugh though ;-)21:45
sorenHow can I see which program stole my input focus?21:45
sorenHm.. No, that can't be it, now that I think about it.21:46
brycehrm, 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 with21:46
sorenX just stopped accepting keyboard input from me.21:46
bryceis this in kvm or in general?21:46
sorenIf I do the x2x trick, I can type on my laptop and it shows up, so it's not a focus problem.21:47
sorenIt's just.. Odd.21:47
brycenot sure, but there's been a few of those bugs reported21:49
sorenchvt'ing away from X and back doesn't fix it. That surprised me somewhat.21:50
brycebut the keyboard works ok when you're at a vt I take it?21:56
sorenYeah, no problems there.21:56
brycebug 184078 is the one I was thinking of21:57
ubotuLaunchpad bug 184078 in xorg "keyboard stops working until logout" [High,Confirmed] https://launchpad.net/bugs/18407821:57
brycedoes that match your issue?21:57
brycewow, searching ubuntu for "keyboard stops working" gives 100 hits21:59
brycebug 58884 sounds a bit closer to your symptoms actually22:02
ubotuLaunchpad bug 58884 in xserver-xorg-input-keyboard "Random keyboard failure in X" [Undecided,Incomplete] https://launchpad.net/bugs/5888422:02
sorenI can't even ctrl-alt-f1 to get away from X. It completely ignores me.22:03
brycehmm, nope that bug's ancient22:03
brycein fact it looks abandoned.  I'll invalidate it and shoo away the me-too'ers22:03
tjaaltonI think the issue is new with xserver 1.422:10
tjaaltonsoren: how often do you see it?22:10
sorentjaalton: This is the first time, i think.22:11
sorentjaalton: Er.. Strike the "I think" part. I would certainly have noticed it if it had happened before.22:11
tjaaltonmouse works normally, you can do stuff with it?22:11
tjaaltonok, so the server is not hung :)22:12
tjaaltoncan you ssh to the box?22:12
tjaaltonthe log might help, or not :)22:12
sorenThat's how I did the x2x thing.22:13
sorenIt 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
tjaaltonneat, haven't seen that before :)22:14
sorenOh, it's pretty nifty.22:17
sorenIt's default mode of operation is quite boring. You want the -{north,east,south,west} option.22:17
tjaaltonI need to try that at work22:18
jcristauit needs a maintainer ;)22:19
tjaaltonhehe :)22:19
bryceheh, I used x2x for a wonky 2-machine multi-head thingee I did a long time ago22:24
bryceI remember it being a bit quirky22:24
tjaaltonbryce: 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 that22:44
brycetjaalton: sounds good22:44

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!