[01:32] Karmic seems to have a bug where "Lock screen" doesn't DPMS-off monitors. Would this be likely to be an X server bug? [02:31] bryce, were you aware that the options to force VESA on the live disk don't appear to do anything anymore? [02:31] i bet ever since xorg.conf was removed that option stopped doing anything useful [03:20] superm1, no wasn't aware. bug#? [03:20] bryce, someone in another IRC channel was just raising it [03:20] i dont know that there is a bug number for it [03:21] https://bugs.edge.launchpad.net/ubuntu/+source/casper/+bug/423969 [03:21] Launchpad bug 423969 in casper "Live CD: "Safe Graphics Mode" not working" [Undecided,New] [03:22] thx [03:51] superm1, that bug is a bit ambiguous as to where things are failing exactly [03:51] I kind of hate it when people say "didn't work" - leaves too much open to interpretation ;-) [03:53] superm1, in any case the kernel doesn't pay any attention to xorg.conf, so whether it's there or not should have no bearing on whether or not the xforcevesa option works or not [03:54] bryce, well xforcevesa used to spit out a different xorg.conf [03:54] since xorg.conf is gone, nothing happens [03:55] hmm [03:55] yeah dunno on that. what exactly produces the xorg.conf? not the kernel surely...? [03:55] well originally was done by dpkg-reconfigure xserver-xorg which was called from casper [03:56] casper is just the package that gets put into the initramfs for all the live disk magic stuff [03:56] scripts/casper-bottom/20xconfig is what used to make an xorg.conf [03:58] so really it was capser that called into the xserver-xorg postinst that used to do it [03:58] *casper [04:03] but that guy has two separate issues in that bug [04:03] 1) Not working with the default config [04:03] 2) xforcevesa doesn't actually force VESA [04:06] mm [04:06] well if it is implemented by calling dpkg-reconfigure, yeah that no longer generates an xorg.conf anymore [04:06] yeah [04:06] but not sure how to work around that [04:07] I mean, it could just copy in a static xorg.conf that lists vesa as the driver, and that'd probably do just as good [04:07] i think so [04:07] in this case nothing else really needs configured [04:08] so if you just look for xforcevesa on /proc/cmdline in xserver-xorg.postinst, copy over a static file in such situations, nothing has to be changed for casper [04:08] tjaalton, I see you've dealt with breakages with this option before, do you have an opinion here? [04:12] uh, how did I walk into getting an action item on this one [04:12] :-) [04:13] I was thinking casper would copy in the xorg.conf so we didn't have to mess with any of the dpkg-reconfigure business [04:13] hehe [04:13] yeah i think ditching the dpkg-reconfigure business is the better solution and just doing it in casper [04:14] where would the static xorg.conf live though? [04:14] I'm imaging it'd be no more than half a dozen lines. It could be as trivial as an echo or print statement in some script [04:17] bryce, http://pastebin.com/f44399ec1 [04:18] if you can put a static xorg.conf somewhere on the system, that pastebin would do the trick in casper [04:19] bryce, or if you can give me the xorg conf i'll just put it in casper with a echo > /root/etc/X11/xorg.conf < EOF [04:21] ok standby [04:21] http://pastebin.com/m43aae492 [04:22] wow that's all that's necessary? :) [04:22] we might be able to trim it down further, but that's one I've actually tested [04:22] like maybe we could leave out the Monitor section, but I'm not certain [04:23] (this is the xorg.conf.failsafe that we use for the bulletproof-x mode) [04:23] what's another 60 bytes, rather know it would work [04:23] right [04:24] okay i'll commit and upload this to casper then: http://pastebin.com/f4b671042 [04:24] I really need to learn casper [04:25] ok, if that works in casper it looks good to me from an xorg pov [04:25] cool. won't be able to (easily) test until a new daily iso [04:27] it occurs to me that we could actually make xorg-server itself recognize and respect xforcevesa [04:28] but that might be madness. [04:28] not sure [04:28] LL perhaps [04:28] oh you mean for any boot, not just live media? [04:28] yeah [04:28] well hopefully xforcevesa doesn't have to be used very often in the first place anyway [04:29] yeah [07:32] boy I tell you, having a kid really sucks up your freetime [07:37] try having three ;) [07:38] two of them on my lap right now [07:40] bryce: re: vesa, the solution looks good [07:41] ok great [07:41] tjaalton, btw I reviewed all changes for xserver 1.6.5 [07:41] about a third of the patches we already have [07:42] another third I think we definitely want, even if we must cherrypick [07:42] the other third I think are lower importance, but look safe enough [07:42] yeah, great [07:42] there's just one patch that I worry about - the one that removed the DGA code and required the patch in 1.6.5 [07:43] I'm debating about whether to put in a FFe for the whole thing, or just cherrypick [07:43] what do you think? [07:43] a plus to cherrypicking is that I can do that all in git [07:43] if it merges from debian, I'm not very good at that [07:44] heh [07:44] er, "if we merge" [07:44] I'm for pulling the whole thing, as usual :) [07:44] even though it'll take a FFe? [07:44] yes, if it was generally accepted already [07:45] and probably handholding me through a git merge (or letting xorg-server escape git control *grin*) [07:45] sure :) [07:46] the former :) [07:47] http://www2.bryceharrington.org:8080/files/xserver-1.6.4-patches.ods [07:48] that's my worksheet for how the patches all fall out [07:49] I'm thinking of reverting the DGA patch entirely. AIUI it's removing dead code so is technically not a "bug fix" and seems to just introduce regression potential (evidenced by the .4 regression) [07:51] yep, that would work too [07:54] Saima (3), can already use the remote to select programs from the VDR menu.. makes my life easier :) [07:55] ..until she wants to build a puzzle [07:56] heh [07:56] Dutch and I spent the evening staring at the fish tank. Quite fascinating [07:56] he can hold his head up on his own for the most part now, which is pretty amazing (he's only 4 weeks old) [08:19] boys are stronger ;) [08:20] bryce: when were you planning to merge xserver? [08:20] do you feel like walking me through it tonight? [08:20] like 12h from now? [08:21] or your night?-) [08:21] actually I meant now [08:21] 12h from now would work to though [08:21] works better, I need to get to work first [08:21] will take 15min [08:21] ok [08:22] ping me whenever you're ready [08:56] bryce: ok, I'm here [08:56] took a bit longer :) [09:02] heya [09:02] just finishing up FFe [09:02] ok [09:02] I figure even if we end up just doing cherrypicks, we'll want git updated for LL [09:04] bug 447010 [09:04] Launchpad bug 447010 in xorg-server "FFe for updating xorg-server to 1.6.5" [Undecided,New] https://launchpad.net/bugs/447010 [09:05] alright, walk me through it [09:05] 1.6.5 isn't out yet btw, and if we revert the dga change we can just merge 1.6.4-2 [09:05] okay [09:05] since 1.6.5 has only that one change to fix the mess [09:05] anyway [09:05] first the usual stuff: git fetch [09:06] that'll update the default remote branches, in this case origin/* [09:06] then if you are in the local ubuntu branch, run git pull [09:06] it'll update the local branch to match the remote [09:07] s/1.6.5/1.6.4-2/ [09:07] yep [09:07] git fetch ; git pull done [09:08] ok, then it's just to merge the tag we want: git merge xorg-server-2_1.6.4-2 [09:08] note that zsh tab-completes it ;) [09:08] now you'll see that some files have merge conflicts [09:08] 3 conflicts [09:09] right, and to resolve them, you can either edit them directly, or use git mergetool [09:09] there are a number of frontends for it, I've used meld [09:09] but I don't know if it's still broken in karmic [09:09] I'll check [09:11] seems to be [09:11] do you have meld installed? [09:12] nope [09:12] I think it helps in visualizing what happens, so install it [09:12] and then run git mergetool [09:12] alright [09:13] huh, reminds me of clearcase [09:13] heh [09:13] ok, so it has three versions of the changelog visible (the first file with a conflict) [09:14] do I edit the middle one? [09:14] the left one is from the ubuntu branch, the right one is the remote version, and the middle one is what you edit [09:15] so, it doesn't always figure out what chunks should go where, so you'll end up editing it by hand [09:16] you can delete the markers away, and move the debian changes on top [09:16] so that the versions are in correct order [09:18] the merged part will still look red though, bad meld [09:19] if the merge-arrows would work, it would be more straightforward [09:20] once you've finished editing it, quit meld [09:20] it'll offer saving the middle version, accept that [09:21] then mergetool will show debian/control being in conflict, and open meld again [09:21] hrm, libaudit-dev is still in universe [09:22] kees: ^^ :) [09:22] ok, merged changelog, control, and series [09:22] not 100% sure on control tho [09:22] that was fast :) [09:22] if you dropped libaudit-dev from the build-deps, it's fine [09:22] ah yeah wasn't sure what to do with libaudit-dev [09:23] since it's still in universe [09:23] I left it... shoudl I drop it? [09:23] ok [09:23] there was also avr32 added to the list of archs for libselinux-dev [09:24] yup [09:24] I like how meld showed just that bit in red [09:24] you can change it after mergetool has finished, no problem [09:24] yes, and the rest of the changes in green, so you can also review the diff [09:24] ok, edited 184_virtual_devices_autodetect.patch as well (fedora-vboxvideo.diff supersedes half of it) [09:25] btw is there a way to create a "reverse patch" in git? [09:25] I've just pulled the commit, and reversed the +/-'s :) [09:25] I'd like to do something like 'git show -R 1234567' [09:26] there should be something like that though [09:26] huh, didn't think of that [09:26] that's a lot faster than the way I usually do it ;-) [09:27] now that the merge itself is done, commit the changes [09:28] the default msg is usually enough [09:28] [ubuntu ee53540] Merge commit 'xorg-server-2_1.6.4-2' from Debian into ubuntu [09:28] I've never changed that IIRC [09:28] also, it's a matter of preference to just commit the merge, and then work out the kinks in separate commits [09:29] whatever works [09:30] now you can push the branch, so I can review it :) [09:30] pushed [09:31] looks good [09:32] next... how to invert patch 507e57381fea6334f7dc8da6925e53d2c76fddcb [09:33] bet I could do a perl script to do it faster than doing it by hand... [09:33] hrm [09:33] why would you do that? [09:34] do what? [09:34] revert that patch [09:34] jcristau, it's caused one regression already, the question is why would we take it? [09:35] AIUI, it's just dropping some dead code, doesn't actually fix a bug [09:35] it's not dead code [09:36] it's removing the ability for clients to directly mmap the framebuffer [09:38] fix-dga-removal.patch has worked so far? [09:49] http://pastebin.ubuntu.com/289155/ [09:52] tjaalton: yes [09:54] uh, well I should hope it's dead code since they're deleting it all [09:55] it's dead code in the drivers once the feature is removed from the server ;) [09:55] in any case, there's no reference to a bug# or other explanation as to why it's being removed, what it did, what's wrong with it, etc. What might depend on this that could break? [09:55] tjaalton, heh ouch [09:56] clients directly mmapping the fb sounds bad [09:57] tjaalton, well then that makes me wonder, so is it a security issue? If so, there's a process for those... [09:57] <1253338095.25431.14.camel@aiko.keithp.com> has an explanation of sorts [10:05] "Removing direct graphics access from DGA" Wed, 16 Sep 2009 15:34:03 -0700 [10:06] (http://article.gmane.org/gmane.comp.freedesktop.xorg.devel/1945) [10:06] tjaalton, actually the reply from keith on the 18th is the more detailed one [10:06] (reading it now) [10:09] bryce: yeah, read it now [10:11] hmm [10:12] well, I understand this code leads to badness (I never doubted it) [10:12] but I still just have a feeling this is going to gratuitously cause regressions somewhere... old games, proprietary apps [10:13] <1253392733-sup-3653@keithp.com> refers to getting 'DGA-using games working again' [10:15] apparently it's been broken since randr-1.2 [10:15] so we would've heard about it now :) [10:16] +by [10:16] bryce: that was from before keith's patch [10:22] if it's broken anyway, it won't be doing any damage right? ;-) [10:22] ok well we still have time to decide... the FFe has not been approved yet [10:23] broken as in apps needing it would have not worked, but the feature can still be used [10:23] what else needs done to complete this merge? [10:23] the changelog entry, and removing obsolete patches [10:23] that's it [10:23] oh and testing that the remaining ones apply & build, of course [10:31] bryce, still up :) I found it fairly easy to reproduce the kwin issues by installing kwin and running kwin --replace [10:32] tormod, can you verify the fixes I posted? [10:32] yes, the crash fix worked, the other I haven't tested [10:35] will you make a combined patch for the two? you will run out of colours :) [10:45] tormod, I added more colors ;-) [10:45] hi ara, on the mesa testing wiki, you wrote "ubuntu-bug xorg", I think mesa would be the right package, right? [10:45] tormod, it's probably not necessary to do another ppa; once they're confirmed sufficiently they can just go in [10:46] tormod, it's fine for people to file against xorg [10:46] tormod, xorg apport hook will gather useful information [10:46] I think also suokko would come up with a real fix if he would be around... [10:46] ara, ok I see, we should maybe fix the mesa apport hooks if needed [10:46] tormod, I figure it's easier to just always remember 'ubuntu-bug xorg' rather than think about which package it might go to [10:47] nah the mesa apport hook is just symlinked to the xorg [10:47] so if you ubuntu-bug mesa, it's the same as if you did ubuntu-bug xorg [10:47] it's just that some of us keep a closer eye on the mesa package than the xorg bucket [10:47] the bug just ends up in a different package. but all the same info is attached [10:48] bryce, are you subscribe to the wiki page? [10:48] I move stuff out of xorg regularly [10:48] tormod, although I've not cleaned it out completely since before my leave [10:48] ara, no but I will get on it, thanks for reminding [10:49] bryce, there is a tester already reporting: https://wiki.ubuntu.com/Testing/Mesa7.6 [10:50] ara cool [10:51] bryce, also, a random crash with the new mesa was reported https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/446653 [10:51] ara, looks like he had no regressions and found that one existing bug was fixed... good! [10:51] Launchpad bug 446653 in xorg "Random crash" [Undecided,New] [10:52] ara, note that he is using nvidia... nvidia does it's own thing for 3D and doesn't actually make use of mesa [10:52] bryce, yes, I just realized :D [10:53] tjaalton, pushed some of the work [10:53] since it's 3am I'll go to bed now and finish up in the morning, thanks for the tutorial. [10:53] good night bryce! [10:54] night bryce! [10:54] oh before I go, ara here are the three confirmed mesa regressions I know of so far: [10:55] - 446425: [Radeon R250] Artifacts on kwin (patch) [10:55] - 446578: [Radeon RS690M] Crash with kwin (patch) [10:55] - 446674: [Radeon M7LW] Memory corruption / googleearth crash [10:55] * bryce --> bed [10:55] bryce, thanks!" [10:55] bryce: thanks, and night === ripps_ is now known as ripps [11:19] looks like bryce didn't git add the dga revert patch? [11:20] jcristau: the one in xorg-server 1.6.4.901 ? [11:20] no [11:20] apparently he decided to revert dga to 1.6.3 state [11:21] ah [14:23] hi [14:28] hi asac, hi ara [14:28] hmmm, it just occured to me that this might be too early for bryce [14:28] hey rickspencer3, asac [14:28] I forgot that he was West Coast as well :( [14:29] * rickspencer3 has awesome attention to detail lately [14:30] rickspencer3, these were the 3 bugs bryce could confirmed as related to the new mesa [14:30] [10:55] - 446425: [Radeon R250] Artifacts on kwin (patch) [14:30] [10:55] - 446578: [Radeon RS690M] Crash with kwin (patch) [14:30] [10:55] - 446674: [Radeon M7LW] Memory corruption / googleearth crash [14:31] bug 446425 [14:31] Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/446425/+text) [14:31] shall we start then? [14:31] ara so it seems that the mesa brought some changes to radeon that were no too good [14:32] for those first two bugs, upstream has identified the specific commits that caused them (in the radeon driver I believe) [14:32] ara, thoughts? [14:32] ok. i can come back later ;) [14:32] (too early for bryce) === marjomercado is now known as marjo [14:33] asac, before you go, what do you think? I'd like to get an update on Monday and see if patches for these issues are available for the driver [14:34] the problems seem localized and well understood [14:34] i think its still fine. i suggested in my plan to make first check today and allow fixes over weekend and check on monday tuesday [14:34] rickspencer3, https://wiki.ubuntu.com/Testing/Mesa7.6, there are some freezes as well, but they don't seem regressions [14:34] ok [14:34] and if there is indication that bugs are making good progress we can think about it then [14:34] so we are agreed, check again on Monday? [14:35] right. keep on listening and check on monday [14:35] ara? [14:35] rickspencer3, yes, I agree [14:35] did we run the test thing? [14:35] opengl? [14:35] asac, not yet, it needs someone to set it up with intel or ati, I have a nvidia [14:35] * marjo waves [14:36] hi marjo [14:36] ara: what does that setup involve? [14:36] rickspencer3, did you notice that Bryce fixed 2 of these bugs in his PPA already [14:36] sorry i'm late; was w/ mdz [14:36] ara: are you looking for specific ati hardware? [14:36] hi marjo [14:36] asac, not too much I think, just installing the dependencies [14:37] tormod, well, I noticed there were patches to try, but not sure I consider them "fixed" yet ;) [14:37] ara: are there instructions or is it just running a command after installing a package? [14:37] asac, [14:37] git://anongit.freedesktop.org/git/piglit [14:37] rickspencer3: i want to report that the rollback patch seems to work [14:37] * asac checks [14:37] they have been confirmed to work [14:38] asac, the only thing I found was that git repository. there is a readme file with instructions [14:38] k [14:38] asac, if it is useful, we should consider creating a ppa for it [14:41] yeah. let me check what happens if i build/run it ;) [16:27] could someone familiar with intel, KMS and power management please look at this: https://bugs.launchpad.net/ubuntu/+source/pm-utils/+bug/417599 [16:27] Launchpad bug 417599 in pm-utils "pm-suspend with quirks does not restore backlight anymore" [Undecided,New] === marjomercado is now known as marjo [16:56] do we expect i945 to be failing to establish DRI and thus being mind-bogglingly slow at 2d? [16:57] no. [16:59] I have two almost identical laptops upgraded jaunty->karmic, one opens DRI fine, one doesn't [17:00] * Ng hunts for the bug he just filed from the broken one [17:00] https://launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/447337 [17:00] Launchpad bug 447337 in xserver-xorg-video-intel "945 unable to initialise dri" [Undecided,New] [17:02] (I say 2d, I guess I actually mean 3d since it was probably still using compiz) [17:03] [ 20.870008] [drm:drm_fill_in_dev] *ERROR* Cannot initialize the agpgart module. [17:04] interesting, ProcModules.txt suggests that agpgart.ko and intel_agp.ko are loaded [17:04] is intel_agp missing from initramfs? [17:05] is there a quick way I can check that? [17:05] (I'm trying not to disturb the laptop's owner too much) [17:06] zcat /boot/initrd.img-$(uname -r)|cpio -i -t | grep intel-agp [17:07] hrm [17:07] actually the problem seems to be that intel-agp gets loaded too late [17:07] like, .1 second too late [17:08] wasn't there some kernel change recently to make it load sooner/properly? [17:08] no clue. [17:10] https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/430694 [17:11] Launchpad bug 430694 in linux "agpgart-intel not loaded before drm sometimes, causes KMS to fail" [Medium,Fix released] [18:15] rickspencer3, oops sorry I completely overlooked that the meeting was at 6:30am, for some reason I had it in my head that it was going to be this evening [18:15] bryce, np [18:15] next problem is that Monday is a US holiday [18:15] :) [18:15] heh [18:16] rickspencer3, well I was thinking I could swap that for a day post-release [18:16] bryce, I hear through the grapevine that your ppa'ed patches are confirmed to work? [18:16] correct [18:16] was hoping to hear from upstream on them by now, but no word so far [18:16] can we apply the patches ourselves? [18:17] certainly [18:18] and I think it's entirely reasonable for us to do so [18:20] http://www.amazon.com/Olevia-747i-47-Inch-1080p-HDTV/dp/B000OCT5GE [18:20] wow, that must be a _good_ monitor at that price! [18:22] zomg, but you get 23% off! :) [18:23] superm1, and free shippin! [18:24] rickspencer3, what I'm going to do is try to get upstream's thumbs-up on those two patches and get them in today [18:25] bryce, get them in upstream you mean? [18:25] or get them into Ubuntu? [19:22] hmm. seems i dropped the ball on checking piglit [19:51] rickspencer3, I touched base with upstream earlier - Alex is going to work up a better patch for us [19:52] bryce, nice [19:52] rickspencer3, meanwhile I've been working on the xorg-server update - lp bug #447010 [19:52] Launchpad bug 447010 in xorg-server "FFe for updating xorg-server to 1.6.4-2" [Wishlist,Confirmed] https://launchpad.net/bugs/447010 [20:46] darn, I hit the 1-click button on that 12 million dollar tv [20:48] mdeslaur, aha you've covered the cost of the patent [20:48] hehe [22:28] xorg-server 1.6.4-2 uploaded [22:28] tormod, tjaalton_: let me know if I've missed anything but I think we now have everything in we want in [22:29] oh, an -ati update might be nice, hm [22:36] bryce, yeah [22:37] I mean .. yeah! \o/ [22:37] :) [22:37] :-) [22:37] bryce, do you need me at the Monday meeting, which I haven't scheduled yet? [22:37] do you still want to do it? [22:38] guess it depends mostly on if you think it'll be useful to do [22:38] I'm fine just chatting with people through email/irc/bugz [22:39] I think your prediction that we'd get to Friday and go "what were we so worried about?" has come to pass [22:39] btw, I've received and uploaded a fix for one of those radeon kwin bugs (the cosmetic issue rather than the crash... still working on that) [22:42] bryce, my opinion on -ati: https://lists.ubuntu.com/archives/ubuntu-x/2009-September/000630.html [22:42] tormod, ah excellent, thanks === Amaranth is now known as true [22:42] * bryce adds to todo list === true is now known as Amaranth [22:43] * tormod wonders if anyone reads the ML ;) [22:44] k [22:44] * rickspencer3 will deal with Monday later [22:44] * rickspencer3 time to go [22:44] bye bye all [22:45] tormod, I do read it, just that one came in while I was on leave. :-) [23:15] bryce, I made a merge request for googleearth-package, can you please take a look (if lp recovers)? [23:15] lp#? [23:34] tormod: that was a nasty little intel libdrm breakage yesterday huh? :D [23:35] Sarvatt, \o/ [23:35] * tormod hugs sarvatt [23:35] made the mistake of updating before i went out for 12 hours of work, couldnt figure out what was broken since i updated so many things and didnt have much time [23:35] but your upload this morning fixed things up :) [23:35] hehe I got some complaints [23:38] uploading a new bunch now so cross your fingers [23:40] upgrading the ibook to karmic now to play with ati kms some more, been waiting all day for the whole chain of x11proto's to build on launchpad to build so i can start uploading libs [23:40] guessing karmic is going to stick with pixman 14.0? [23:41] heya Sarvatt! [23:42] hiyo! [23:42] long time, wassup? [23:43] not much, catching up on 2 months of open source development that I missed, crazy how much things change that fast :D [23:43] yup definitely [23:43] yeah being gone on leave 1 month myself it's been mad trying to catch up [23:44] btw I credit a lot of the reason we were able to get all the latest mesa/xserver/libdrm/intel bits updated for karmic is because they'd been getting good testing in xorg-edgers :-) [23:44] so the work you and tormod have done there has had a good payoff === asac_ is now known as asac [23:57]