[10:08] <tjaalton> huh, weird.. installed nvidia-glx-177 and it pulled the -rt headers and nothing else
[10:09] <tjaalton> although nvidia-177-kernel-source depends on linux-headers-generic | linux-headers
[10:11] <tseliot> tjaalton: did you have the linux-headers-generic installed?
[10:11] <tjaalton> tseliot: no
[10:12] <tjaalton> that's what it should've installed
[10:13] <tseliot> it might have been linux-headers
[10:14] <tseliot> that's the only package which can pull the rt headers
[10:14] <tjaalton> right, I was trying to point out that apt should have pulled -headers-generic instead of -rt :)
[10:16] <tseliot> could it be that linux-headers-generic had dependency problems and couldn't be installed?
[10:17] <tjaalton> I could install it manually
[10:19]  * tseliot would like to have something more reliable than depending on linux-headers
[10:22] <tseliot> making linux-image depend on its headers would solve this problem but it would also tick off some users
[10:22] <tjaalton> yep
[10:24] <tseliot> tjaalton: did you install the driver from Jockey?
[10:24] <tjaalton> tseliot: no, apt-get
[10:24] <tseliot> aah
[10:28] <tseliot> maybe we should talk about this with the kernel team at the UDS, they might have some ideas
[10:29] <tjaalton> it's just apt doing tricks
[10:30] <tjaalton> and I'm not coming to UDS
[10:30] <tjaalton> at least it's very unlikely now
[10:30] <tseliot> why? (if you don't mind me asking)
[10:31] <tseliot> is it because of sponsorship?
[10:31] <tjaalton> missed the deadline because I thought my boss would send me there like before (and I had to cancel the sponsorship then)
[10:32] <tjaalton> I've been waiting for a yes/no for a month now
[10:32] <tseliot> can't you talk to jcastro?
[10:32] <tjaalton> hm, I could
[10:32] <tseliot> I think he's the right person to ask
[10:36] <tjaalton> yep, done
[10:37] <tseliot> good, let me know how it goes
[13:29] <tseliot> bryce, mvo: this quick fix solves bug 287062: http://bazaar.launchpad.net/~albertomilone/gnome-control-center/randr-virtual/revision/32
[15:18] <mvo> superm1: thanks for your mail, please let me know when you had a chance to test the fglrx on your laptop, I think otherwise we are good for intrepid-proposed
[15:27] <tseliot> federico1: I have fixed this bug in the xrandr capplet:
[15:27] <tseliot> bug 287062
[15:27] <tseliot> with this quick hack: http://bazaar.launchpad.net/~albertomilone/gnome-control-center/randr-virtual/revision/32
[15:28] <tseliot> you might want to have a look at it
[15:34] <tjaalton> mvo: can you see why apt chooses linux-headers-2.6.27-3-rt instead of linux-headers-generic when installing nvidia-*-kernel-source
[15:34] <tjaalton> mvo: when -k-s depends on linux-headers-generic | linux-headers
[15:34] <mvo> tjaalton: that sounds odd, is this rperoduceable?
[15:34] <tjaalton> mvo: yes..
[15:34] <tjaalton> trivial to work around though, but still
[15:36] <mvo> tjaalton: give me some minutes I will see if it happens in a chroot
[15:37] <tjaalton> mvo: ubuntu-desktop recommends l-h-g, but my netboot-installation doesn't seem to pull them by default, so this should not be seen on normal installtions
[15:37] <Kano> hi, did you see the 2 new legacy beta drivers
[15:39] <Kano> at least 96.x has "Added preliminary support for X.Org server 1.5."
[15:44] <superm1> lol.  of course the day of release
[15:44] <mvo> tjaalton: it looks like it comes from dkms: Installing linux-headers-2.6.25-2-386 as dep of dkms
[15:45] <mvo> (output of  apt-get install nvidia-177-kernel-source -o Debug::pkgDepCache::AUtoInstall=true)
[15:45] <tseliot> Kano: yep, I'll update them ASAP
[15:46] <superm1> mvo, is that necessarily how they should be resolved though?  why isn't linux-headers-generic chosen to resolve?
[15:47] <tjaalton> superm1: dkms should depend on l-h-g | l-h like nvidia-k-s
[15:47] <mvo> superm1: apt is not very smart when it resolves virtual packages, it just picks the first one that provides the required dependency
[15:47] <tjaalton> mvo: thanks, I'll try to figure out how to install recommended packages first :)
[15:47] <mvo> tjaalton: --install-recommends
[15:47] <mvo> tjaalton: you can also run "sudo apt-get install --fix-policy"
[15:47] <tjaalton> mvo: I mean the netboot installer
[15:47] <mvo> aha
[15:48] <tjaalton> there doesn't seem to be a preseed value to set
[15:48] <tjaalton> I'm preseeding pkgsel/include with a _lot_ of packages :)
[15:48] <superm1> tjaalton, mvo but i mean because both nvidia-k-s and dkms are having the dependency, but nvidia-k-s has the harder dependency, shouldn't it resolve it nicer?
[15:49] <tjaalton> superm1: maybe so, but doesn't :)
[15:51] <tjaalton> phew, 546 new packages to install with --fix-policy
[15:55] <federico1> tseliot: hmm, so is check_required_...() returning a bigger size than needed if you have mirrored screens?
[15:57] <tseliot> federico1: yes and I suspect that their ->x ->y are not set to 0 if clone mode is selected
[15:58] <tseliot> therefore mine is a quick and dirty hack which works without introducing new regressions
[15:58] <tseliot> eventually we may want to fix the actual problem though
[15:59] <tseliot> what do you think?
[16:03] <tseliot> superm1: what do you suggest that I do?
[16:03] <mvo> superm1: the algorithm is pretty simple, it resolves what it find, so if dkms is first and nvidia is later it resolves dkms first
[16:03] <mvo> not smart, but simple
[16:04] <superm1> tseliot, about what?
[16:04] <tseliot> superm1: about nvidia-k-s, dkms and linux-headers
[16:04] <superm1> mvo, why is this suddenly popping up as an issues then?  shouldn't everyone that installs with jockey run into it then?
[16:06] <mvo> superm1: I think on most system linux-headers-generic is already installed, so its a non-issue
[16:06] <superm1> ah
[16:06] <tseliot> superm1: it used to happen to users of kernel flavours other than -generic (even with jockey)
[16:06] <mvo> superm1: so only people with netboot installs or pbuilder chroots see it
[16:07] <superm1> mvo, tseliot i think it's a small enough case then that we don't need to rush and say hurry up SRU a fix etc
[16:07] <superm1> but an SRU to dkms would probably be a good idea then
[16:07] <tjaalton> superm1: right, but fix it for jaunty :)
[16:07] <superm1> yeah
[16:08] <federico1> tseliot: I'd rather have the real fix in the code in SVN :)
[16:08] <tjaalton> SRU is fine, we don't use intrepid on production systems though, so no rush
[16:08] <federico1> tseliot: it shouldn't be hard to do; just check if the screens are mirrorred, inside that function
[16:08] <superm1> mvo, will you have  an update around UDS about the sticky packages idea that was brought up before, where it's at?
[16:08] <tseliot> superm1: I would like to make sure that Jockey installs the right headers for Jaunty too
[16:08] <federico1> tseliot: I think ssp fixed the "zero offsets" problem at some point, or maybe it was something related
[16:09] <tseliot> federico1: do you mean the sanitize function? If yes, no it doesn't fix this
[16:09] <federico1> tseliot: by the way, did you start the process to get a gnome svn account (or do you have one)?
[16:09] <mvo> superm1: I guess its something we need to talk about yes, its nowhere right now, its a challenge to implement and has some bits that needs thinking. but its clear that some sort of new dependencies seems to be required
[16:09] <tseliot> federico1: no, how do I do that?
[16:11] <superm1> mvo, okay, well i'm sure we'll have some discussion that will relate to all this driver installation stuff again and it would be best to bring back up and think about those bits then
[16:11] <federico1> tseliot: ah, ok - please read http://live.gnome.org/NewAccounts and follow the instructions.  You can put me as the person who vouches for your awesomeness :)
[16:11] <tseliot> federico1: ok, thanks, I'll do it :-)
[16:21] <tseliot> federico1: it says: Vouchers   For GNOME SVN and the ability to install new modules,  please select who can vouch for you:
[16:21] <tseliot> but then I can only select the gnome module
[16:22] <tseliot> shall I write your name in the Comments field?
[16:22] <tseliot> federico1: here: https://mango.gnome.org/new_account.php
[17:09] <federico1> tseliot: oh, hmm, I guess it is based on module maintainers now
[17:09] <tseliot> federico1: does my snapshot look good to you?
[17:10] <federico1> tseliot: yeah, the image you sent should be fine... put in a little more detail in the comments about what you are doing
[17:10] <tseliot> ok
[17:14] <tseliot> federico1: something like this? http://pastebin.com/d518361e1
[17:14] <federico1> tseliot: perfect
[17:16] <tseliot> federico1: ok, done
[17:19] <bryce> tseliot: rev #32 looks good to me
[17:20] <tseliot> bryce: great
[17:20] <tseliot> mvo: how about merge from my branch? http://bazaar.launchpad.net/~albertomilone/gnome-control-center/randr-virtual/revision/32
[17:22] <tseliot> s/merge/merging/
[17:44] <mvo> tseliot: is this for intrepid-prooposed?
[17:44] <mvo> or jaunty?
[17:45] <mvo> tseliot: I assume -proposed, I'm happy to sposnor it
[17:48] <bryce> mvo, yeah would be for intrepid-proposed
[17:49] <mvo> bryce, tseliot: please add TEST CASE as described in the StableReleaseUpdates wiki page to the report. I merge and sponsor now
[17:50] <bryce> I can do that
[17:51] <bryce> (the user essentially gave it in the description, but I'll clean it up)
[17:51] <mvo> yeah, the descriptions looks very good
[17:51] <mvo> it needs to be a) how to reproduce the problem b) how to verify the fix
[17:53] <tseliot> bryce: thanks
[17:53] <tseliot> mvo: we can use this report: bug 287062
[17:54] <mvo> woah, archive.ubuntu.com is not answering at all currently
[17:54] <mvo> tseliot: ok
[17:57] <bryce> mvo, okay done
[18:03] <tseliot> good
[18:03]  * tseliot > dinner
[18:19] <bdmurray> bryce: should bug 176061 really be a duplicate?  It looks like you were working on it at one point.
[19:12] <bryce> bdmurray: sorry was on conf call with amd.  lemme look
[19:12] <bdmurray> bryce: thanks, no hurry
[19:14] <bryce> bdmurray: looks like the same bug to me (issue only occurs with compiz loaded), but do you have a reason to suspect them as separate bugs?
[19:16] <bdmurray> bryce: no, you had marked one as in progress so I was wondering if that should carry over.  also they point to different upstream bugs
[19:23] <bryce> bdmurray: it looks like the upstream link for the duped bug is incorrect; it describes a performance issue when rotated, with compiz turned off
[19:26] <bryce> I don't remember why I set it to In Progress, but it's not something I'm working on currently.
[19:26] <bdmurray> alright, thanks for looking at it
[19:27] <bdmurray> its independent of the video driver correct?
[19:33] <bryce> well, it sounds like it's a bug in mesa
[19:34] <bryce> but mesa is composed of a lot of driver-specific code
[19:35] <bryce> but from looking at the bug, it does sound like it's a generic mesa problem that presumably affects more than just -intel
[20:54] <bryce> tseliot, tjaalton, mvo, superm1:  I had a productive discussion with AMD about upstreaming fglrx bugs, and I think we'll be able to tighten up the process.
[20:54] <bryce> going forward, they'll work on getting more definitive answers (even if it's Won't Fix) on bugs we send to them.  They'll take 5 per 2 weeks.
[20:55] <bryce> here's a page to document how to mark fglrx bugs to upstream, and how we'll track upstream's response:  https://wiki.ubuntu.com/X/Upstreaming
[20:56] <bryce> tseliot, tjaalton, mvo, superm1:  So if you find bugs that need to go to AMD, please follow that procedure, and I'll make sure to mention the ones marked to AMD during my calls with them.
[21:01] <tseliot> bryce: it's great news. Much better than telling users to file a bug report in AMD's bugzilla
[21:02]  * tseliot wishes that something similar could be available for NVIDIA too...
[21:15] <tjaalton> bryce: ok, nice to know
[21:17] <wgrant> It's good to know that we have useful communication channels with them
[21:21] <bryce> added some links to some handy queries of the bugs - https://wiki.ubuntu.com/X/Upstreaming
[22:00] <tseliot> bryce: what do you think about these screenshots? http://www.dummies.com/WileyCDA/DummiesArticle/Mac-OS-X-Tiger-Timesaver-Using-Multiple-Displays.id-3130.html
[22:02] <bryce> ah I see where the gui concept came from
[22:02] <tseliot> hehe right
[22:02] <bryce> having the graphical display on a separate tab from the widgets is probably a good idea - that's one way to squeeze the dialog into a tighter space
[22:03] <tseliot> and (in the future) we could have more than 2-3 displays to show there
[22:03] <bryce> tseliot: I like it a bit more than our tool, however some of the widgets are not clear to me what they do
[22:03] <bryce> right
[22:04] <tseliot> I have found this page: http://movielibrary.lynda.com/html/modPage.asp?ID=593&cid=593
[22:04] <tseliot> if you click where it says "Configuring your display with the Displays system preference"
[22:04] <tseliot> you will see a nice video of the panel in action
[22:05] <tseliot> I think there are some good ideas which we might reuse
[22:10] <bryce> yeah, I like the toolbar layout thingee; iirc we got a bug about that
[22:10] <bryce> the color management would also be pretty sweet
[22:11] <wgrant> Apart from that couple of additional features, that UI is awful.
[22:12] <tseliot> wgrant: why?
[22:13] <wgrant> tseliot: Why do I have to switch to some other tab to configure the layout of my monitors if I want to change the res as well?
[22:14] <tseliot> most users won't have to switch tab
[22:14] <wgrant> Why not?
[22:14] <tseliot> since they have 1 monitor or since the main monitor is selected by default
[22:14] <wgrant> Ah.
[22:15] <wgrant> Apart from needing a bit of prettification, I think gnome-display-properties is very good.
[22:17] <tseliot> yes, but 1) I'm not talking about gnome-display-properties and 2) I would like to have something more future-proof (try to manage more than 3 displays in that dialog)
[22:17] <tseliot> and there are other properties we have access to
[22:18] <tseliot> that are not in the mac ui either
[22:18] <wgrant> Such as?
[22:20] <wgrant> Hmm, I guess panel fitting and TV format might be useful.
[22:20] <wgrant> But I can't think of much else.
[22:20] <tseliot> I've got a list somewhere (I got it from the output of my library)
[22:21]  * tseliot looks in his laptop
[22:21] <wgrant> I see that XRandR 1.3 is getting better property support.
[22:21] <tseliot> yep
[22:25] <tseliot> panel_fitting, backlight_control, gamma and (for TVs) bottom, right, top, left, tv_format
[22:25] <wgrant> Ah, good point.
[22:26] <tseliot> putting all this stuff in a usable UI might not be easy though ;)
[22:26] <wgrant> Shouldn't backlight_control not be fiddled with by users?
[22:27] <tseliot> I haven't seen what values these properties support yet
[22:27] <tseliot> therefore I wouldn't know
[22:27] <wgrant> 	BACKLIGHT_CONTROL: combination
[22:27] <wgrant> 		supported: native       legacy       combination  kernel
[22:27] <wgrant> That looks fairly hostile and irrelevant to users.
[22:27] <tseliot> right
[22:29] <tseliot> panel fitting and tv controls can be useful though
[22:29] <wgrant> Definitely.
[22:29] <wgrant> I wasn't aware that panel fitting was controllable from outside the BIOS until I saw the property while debugging my backlight.
[22:30] <tseliot> I'm afraid we can do it only with drivers which support randr 1.2
[22:30] <wgrant> Of course.
[22:31] <tseliot> the good thing about the mac ui is that when for example 1.2 is not supported you simply don't show the "arrangement" tab
[22:32] <tseliot> currently we show a screen with an "Unknown" label
[22:32] <tseliot> ok, a small detail
[22:32] <tseliot> s/small/irrelevant/
[22:32] <tseliot> ;)
[22:32] <wgrant> Is nvidia going to get moving on 1.2 at any point?
[22:33] <tseliot> I wish I knew...
[22:33] <tseliot> I doubt it will remain the only driver which doesn't support 1.2
[22:33] <tseliot> maybe when randr supports multiple GPUs
[22:34]  * wgrant -> uni
[22:34] <tseliot> bye


[00:00] <thomi> robert_ancell: OK, cool. I'm kind of here, kind of not, depending on how long this coffee keeps me awake
[00:10] <robert_ancell> thomi, :)
[00:10] <robert_ancell> ricmm, I'm trying to manually get mir out of proposed - it seems to be in a deadlock due to some build ordering issues
[00:22] <RAOF> robert_ancell: I don't see that corruption on ati with mir from -proposed (and usc built against that mir)
[01:06] <ricmm> robert_ancell: awesome, thaks
[01:06] <ricmm> lemme know how that goes
[01:10] <robert_ancell> ricmm, packages are built, just waiting for the job that migrates them from -proposed to universe
[01:11] <ricmm> \o/
[01:23] <robert_ancell> ricmm, seems to have worked, I'm upgrading now and pulling in the new versions
[01:23] <ricmm> great!
[01:49] <robert_ancell> duflu, have you tested bypass on an ati machine?
[01:50] <duflu> robert_ancell: No, it proved impossible. Multiple kernel bugs prevent me from being able to. Alf tested it for me
[01:50] <robert_ancell> duflu, it's failing in the lab
[01:50] <robert_ancell> we've set up ppa:mir-team/qa-testing to just contain bypass, then you can run it in the lab and watch the screen there
[01:50] <robert_ancell> has lots of corruption
[01:50] <duflu> robert_ancell: Hmm. OK. I was relying on Alexandros' testing. Got kernel 3.11.0+?
[01:51] <robert_ancell> the main archive version works
[01:51] <robert_ancell> duflu, I don't think I can check until the test completes
[01:51] <robert_ancell> thomi, (if still awake) is that true?
[01:51] <duflu> robert_ancell: Because corruption is expected. You need the "DMA-buf" fix wherever that was... in kernel 3.11
[01:51] <thomi> robert_ancell: Im still awake
[01:52] <thomi> robert_ancell: you should be able to ssh in to the machine while the test is running
[01:52] <duflu> robert_ancell: To clarify... I have radeon hardware, but can't test saucy due to saucy being unbootable on my desktop (regardless of graphics)
[01:52] <thomi> robert_ancell: obviously you run the risk of affecting the result, but if all you need to do is check package versions it should be OK
[01:53] <robert_ancell> duflu, it's running saucy right now and seems to work
[01:53] <thomi> robert_ancell: oh, also, the machine may reboot under you :)
[01:53] <thomi> IP addresses are all on the wiki, in case you need them
[01:53] <robert_ancell> thomi, ta
[01:53] <robert_ancell> duflu, so the dma-buf fix is required only for bypass?
[01:54] <duflu> robert_ancell: Seems so. Because I can test raring and it fails there. alf said it worked for him on saucy+radeon.
[01:54] <robert_ancell> duflu, do you have a bug number?
[01:55] <duflu> robert_ancell: We're not also testing XMir at the same time are we? XMir adds new bugs which we would have to exclude
[01:55] <robert_ancell> duflu, yes, with xmir
[01:55] <duflu> robert_ancell: I wish I had a bug number, or a commit to point to. All anyone has been able to tell me is "you need kernel 3.11". Which seems true for nouveau too
[01:56] <robert_ancell> duflu, but saucy is kernel 3.11
[01:56] <duflu> I've also tried kernel 3.11 on raring but ran into other graphics bugs before I could test Mir
[01:57] <duflu> robert_ancell: It would be unproductive to debug XMir+radeon+bypass right now. I need someone to test just radeon+bypass
[01:57] <duflu> I'm already in the boat of having too many variables at once with another bug
[01:57] <robert_ancell> duflu, ok, to be clear. On one of the QA ATI boxes running standard saucy + xmir enabled it works fine, but standard saucy + lp:~vanvugt/mir/bypass + xmir does not
[01:57] <robert_ancell> so this is only one variable...
[01:58] <duflu> robert_ancell: Not true. We've spent the past few days finding and fixing XMir bugs only revealed by new Mir features (which themselves are bug free)
[01:59] <duflu> Maybe we have working saucy images I can boot now. Will retry today
[02:00] <robert_ancell> thomi, what is the wiki link
[02:06] <thomi> robert_ancell: https://wiki.canonical.com/UbuntuEngineering/QA/Lab
[02:43] <kgunn> robert_ancell: is the failure in the mode of the funky stripes? or black screen ?
[02:44] <robert_ancell> kgunn, looks like just the funky stripes - the test completed otherwise
[02:45] <kgunn> robert_ancell: that is strange as it keeps changing
[02:45] <robert_ancell> kgunn, I'm just running saucy without XMir for completeness so we are sure we're comparing apples with apples
[02:45] <robert_ancell> yeah
[02:45] <robert_ancell> this remote camera is awesome :)
[02:45] <kgunn> robert_ancell: so what i'm looking at right now is saucy X
[02:46] <kgunn> ?
[02:46] <kgunn> well...then...
[02:46] <robert_ancell> kgunn, you were looking at saucy + XMir+bypass
[02:46] <kgunn> oh
[02:46] <kgunn> it is awesome
[02:46] <robert_ancell> our mir packages were all out of date - there was some deadlock in the autolanding system
[02:47] <robert_ancell> They're up to date now, so running the three cases with these packages
[03:18] <kgunn> robert_ancell: i stepped away...did it run yet?
[03:19] <robert_ancell> kgunn, yes, just collecting the results
[03:22] <robert_ancell> kgunn, emailed you the results
[03:23] <robert_ancell> kgunn, what were you looking for?
[03:36] <duflu> robert_ancell: The radeon issue, looks like vertical stripes right?
[03:36] <robert_ancell> duflu, there's a link to an image in the MP
[03:36] <duflu> If that means incorrect pixel format then I have a reasonable theory as to the cause. But haven't been able to reproduce any such issue yet
[03:37] <robert_ancell> duflu, that QA machine is at your disposal :)
[03:37] <duflu> robert_ancell, OK. I was hoping to not have to invest the time setting up VPNs etc :/
[03:38] <robert_ancell> duflu, I recommend getting the QA VPN set up - it makes life easier
[03:38] <robert_ancell> thomi, asleep yet?
[03:38] <duflu> I used to... before reinstalling
[03:40] <duflu> robert_ancell: Shall I remove the prereq of bypass for timerless?
[03:40] <duflu> Just means bypass will conflict for a while
[03:40] <robert_ancell> duflu, sounds like a good idea
[03:46] <RAOF> Bypass breaks intel XMir too, even single head.
[03:47] <thomi> robert_ancell: asleep at my desk, does that count?
[03:48] <robert_ancell> RAOF, is it the mir side or the xmir side?
[03:48] <robert_ancell> duflu, do you have all the info for the VPN?
[03:48] <duflu> robert_ancell: No idea. And now I'm a couple of hours from trying :/
[03:49] <robert_ancell> thomi, can you send any links info to duflu about setting up the QA VPN
[03:49] <thomi> sure, let me see where I can find it
[03:50] <thomi> duflu: robert_ancell: https://wiki.canonical.com/InformationInfrastructure/IS/VPN
[03:50] <thomi> worth noting that it's not so much a 'QA VPN' as a 'Canonical VPN'
[03:50] <RAOF> robert_ancell: Possibly a combination of the two
[03:51] <thomi> my understanding is that almost everyone who was in the old PS dept. should have an email in their inbox with their private key
[03:52] <thomi> otherwise, IS can send you new keys, or help you get it set up
[03:53] <duflu> I may get more value sooner by trying to find a way to boot saucy on my desktop (where I have radeon). Haven't succeeded yet but it's worth another try
[03:54] <thomi> duflu: otherwise, I may be able to give you SSH access to my radeon laptop, although it will be slow
[03:54] <duflu> thomi: If that blurry screenshot is to be trusted then it looks like vertical lines? That one I might have a clue about already
[03:55] <thomi> duflu: uhh, I'm not sure what screenshot you refer to
[03:56] <duflu> http://imgur.com/1k7tQE5
[03:56] <thomi> oh
[03:56] <thomi> ok, well, let me know if you need annything
[03:56] <thomi> although for VPN-related things, IS is probably a better bet :)
[04:06] <kgunn> robert_ancell: i don't understand how those results can be like that...
[04:07] <kgunn> the thing that's supposed to be the crappiest is the best ?
[04:10] <robert_ancell> kgunn, yeah...
[04:10] <robert_ancell> kgunn, please double check the results but I *think* it was run correctly
[04:11] <robert_ancell> bob
[04:11] <robert_ancell> beLUmaya
[04:11] <robert_ancell> DISPLAY=:0 xev
[04:24] <tvoss> duflu, ping
[04:26] <tvoss> RAOF, ping
[04:26] <RAOF> tvoss: Pong.
[04:27] <duflu> tvoss, pong
[04:27] <RAOF> mlankhorst: Oooh, you're awake?
[04:27] <robert_ancell> RAOF, I notice X doesn't drop focus when you VT switch away - do you think this should be a system compositor special option?
[04:28] <RAOF> Hm, I don't know.
[04:28] <RAOF> I don't think it makes a huge amount of difference either way.
[04:28] <RAOF> But a client really isn't focused if it doesn't display or get input.
[04:38] <tvoss> robert_ancell, RAOF the benchmarking results for radeon seem to suggest that X touching the framebuffer makes things slower?
[04:38] <tvoss> duflu, kgunn ^
[04:39] <robert_ancell> I've forwarded them to duflu and RAOF
[04:39] <RAOF> Does it render correctly?
[04:39] <tvoss> robert_ancell, ?
[04:40] <robert_ancell> RAOF, not with bypass
[04:40] <RAOF> I'm not sure that we should trust the benchmark numbers then.
[04:41] <tvoss> RAOF, true
[04:42] <duflu> I know that software rendering + bypass is often slower. Which is why bypass is disabled for software surfaces
[04:52] <duflu> RAOF: If XMir does any "copies" it's really a software renderer then... ?
[04:52] <duflu> And it's lying to Mir in saying this is a hardware surface?
[04:53] <duflu> I remember a while back I said we should distinguish between "hardware" buffer residency and hardware blitting, but my suggestion was rejected :/
[04:54]  * duflu *shrugs* and goes to lunch
[04:59] <RAOF> duflu: It's does hardware blitting, from hardware-rendered other buffers.
[05:00] <RAOF> duflu: It's as much a hardware surface as any EGL app.
[05:27] <tvoss> RAOF, duflu back
[05:31] <duflu> RAOF: OK. Though this "copy" I keep hearing about, is that on the CPU? What stage is it?
[05:32] <RAOF> duflu: It's on the GPU; X is basically acting as a compositor.
[05:32] <RAOF> Except rather than going through GL, it's speaking raw GPU command streams.
[05:33] <duflu> RAOF: Sounds fast. I guess if it actually was software copying I would not see the nice reduction in mouse lag with qa-testing(bypass)
[05:33] <RAOF> As far as Mir is concerned, though, it's not different than an EGL client. The difference between X and and EGL client is an EGL client has the mesa library to produce the command streams.
[05:34] <duflu> RAOF: Oh, BTW, any idea why single-buffering desktop environments would *not* exhibit the frame ordering bug?
[05:35] <RAOF> No, and are you certain that they don't? Last time I checked I could get the frame-ordering problem on raw X + xterm.
[05:35] <RAOF> But I guess that was a while ago.
[05:37] <duflu> RAOF: Almost certain. I could not get it to happen with Compiz doing single buffering, or plain Xfce
[05:37] <tvoss> RAOF, can we disable buffer age in X?
[05:37] <RAOF> tvoss: Yes, but it doesn't help.
[05:37] <tvoss> RAOF, ah
[05:37] <duflu> But that could be timing too... single buffer damage-only updates are faster
[05:38] <duflu> I have tried making intentionally slow clients, but didn't reproduce it that way
[05:39] <tvoss> RAOF, duflu so trying to understand: somewhere the buffer order inside X gets fucked up, and n+1 is submitted before n
[05:40] <duflu> It looks like it. I still can't reproduce it with any demo client, no matter how I try to change variables
[05:40] <RAOF> I don't believe that is the case - smspillaz was seeing the same problem with his GTK implementation, and he dumped the frames to disc before submitting them and they were correct.
[05:40] <RAOF> tvoss: ^^^
[05:41] <duflu> RAOF: No, Sam reported lag only, not buffer misordering. Hence it's still a separate bug. Also that was fixed by ignoring buffer age
[05:41] <RAOF> Huh, I thought he'd tried that and it didn't work.
[05:41] <RAOF> I'm clearly not up on that bug.
[05:41] <tvoss> smspillaz, ping
[05:42] <duflu> I have other theories as to where bad ordering could come from. But I will have to learn new Mir code I've never really looked at
[05:42] <tvoss> duflu, which one? how can I help?
[05:42] <smspillaz> tvoss: pong, but I gotta go soon
[05:43] <tvoss> smspillaz, quick x-check: ignoring buffer age in your gtk port fixed the lag?
[05:43] <smspillaz> duflu: I'm not so sure if that was "fixed" by ignoring buffer age
[05:43] <smspillaz> at least - I didn't see it when I did full repaints but it appears to be a race condition
[05:43] <smspillaz> and furthermore, the symptoms I'm seeing are not consistent with incorrect buffer ages being sent
[05:44] <smspillaz> I'd suggest running the gtk demo to see if you can reproduce it on your end
[05:44] <tvoss> duflu, sounds like a simpler client than X
[05:44] <duflu> smspillaz: Yes, sorry, bad choice of words. But at least "worked around" by not using the buffer age
[05:44] <duflu> tvoss: Different bug
[05:44] <duflu> Hence not a valid test case
[05:46] <tvoss> duflu, ack
[05:46] <duflu> We have at least three lag/ordering bugs and they are all most definitely separate. It takes careful analysis to know they're different tho
[05:46] <smspillaz> duflu: like I said, I'm not sure that not using buffer age would actually fix it
[05:46] <smspillaz> it just seems that here it does not trigger that race
[05:47] <tvoss> duflu, so for the ordering bug: do we have a frame counter per surface?
[05:47] <duflu> tvoss: No, we have a unique ID you can track tho
[05:48] <tvoss> duflu, how do we know it's an ordering bug then and not an unfinished rendering?
[05:48] <duflu> tvoss: mir_debug_surface_current_buffer_id should be sufficient
[05:48] <duflu> tvoss: Unfinished rendering *usually* appears as tearing
[05:48] <duflu> But it could also be related to a missing flush/finish or equivalent
[05:49] <tvoss> duflu, true, but we are making an assumption here, and at such high frame rates, I would actually want to make sure that it is really ordering :)
[05:49] <duflu> tvoss: Well, we have tests for it already in lp:mir. You could also ask the client to check the order it's getting, with mir_debug_surface_current_buffer_id
[05:50] <duflu> Of course, tests are never foolproof
[05:50] <RAOF> That's how I tracked down the ordering problem last time; by dumping the surface ID all over the place.
[05:50] <duflu> RAOF: That was a while ago... we fixed that one right?
[05:51] <RAOF> Yeah.
[05:52] <RAOF> At least for single outputs and clients with single surfaces :)
[05:52] <RAOF> But I don't think that code cared where the buffer came from.
[05:52] <duflu> I have had more theories as to how order might be violated. However can't yet find any theoretical reason why it would be in the buffer swapper. That part is now designed to make ordering theoretically guaranteed
[05:53] <duflu> We might be racing/messing up in the protocol/threading somewhere though
[05:53] <duflu> ... but if it was that easy then you'd think some mir_demo_client could show a similar bug.
[05:54] <RAOF> Maybe?
[05:55] <RAOF> I think we might want to write a one-surface-per-output version of progressbar that uses GL rather than CPU mapping.
[05:56] <duflu> RAOF: egltriangle should be sufficient. Just need to add a parameter to populate output_id methinks
[05:57] <duflu> RAOF: I also keep thinking if your surfaces usually only map to one monitor each, then only one compositor thread should be getting each surface. It should behave like single monitor... unless we've messed up the region calculation
[05:57] <robert_ancell> RAOF, duflu, kgunn, racarr|desert, hikiko, tvoss, thomi, meeting time...
[05:58] <thomi> omw
[05:59] <tvoss> robert_ancell, not on broadband, will try to join, though
[06:00] <thomi> ugh, RAGE!
[06:00] <thomi> stupid technology
[06:00] <tvoss> duflu, do we see the ordering issue only on multi-monitor or also on single output?
[06:01] <thomi> robert_ancell: can someone link me the hangout url please? It's now showing up in my calendar
[06:01] <duflu> tvoss: Multimonitor only
[06:01] <tvoss> duflu, my understanding: it's trunk + bypass exposing it when used with XMir?
[06:02] <duflu> tvoss: No, multimonitor only. And even without bypass
[06:03] <tvoss> duflu, ah, that helps a lot
[06:03] <duflu> tvoss: It happens on qa-testing2 (no bypass)
[06:05] <tvoss> duflu, ack. So to land bypass, we need to check the weird ati numbers
[06:08] <duflu> tvoss: And corruption
[06:08] <duflu> tvoss: I will be in a better state to test and fix when I can boot saucy on my desktop. Which I cannot yet :(
[06:11] <tvoss> duflu, ack, what is blocking you from booting saucy on your desktop?
[06:12] <duflu> tvoss: Kernel/BIOS issues new in saucy. Cannot even start to boot it
[06:12] <tvoss> robert_ancell, which ppa did you use to run the openarena benchmarks? qa-testing?
[06:12] <tvoss> duflu, got a bug report?
[06:12] <robert_ancell> tvoss, ye
[06:12] <robert_ancell> s
[06:12] <duflu> tvoss: https://bugs.launchpad.net/bugs/1212977
[06:13] <tvoss> duflu, thx
[06:13] <mlankhorst> RAOF: yeah
[06:13] <mlankhorst> RAOF: did you get my message and video? :P
[06:13] <RAOF> mlankhorst: Yes
[06:14] <mlankhorst> ah good
[06:14] <RAOF> mlankhorst: I had a couple of questions. Mainly - is that pixmap the screen pixmap?
[06:14] <mlankhorst> no idea, considering the code it was from i would assume so :P
[06:22] <mlankhorst> tvoss: xorg-server is unmodified for bypass right?
[06:22] <olli> robert_ancell, mir/archive should be unblcoked
[06:23] <tvoss> mlankhorst, ack
[06:23] <robert_ancell> olli, yeah, it was another issue, fixed now
[06:23] <olli> ok
[06:24] <RAOF> mlankhorst: gdb and print out (screen->GetScreenPixmap)(screen)?
[06:25] <mlankhorst> RAOF: oh right it might be very much possible that it switches the front  buffer in fullscreen gl case
[06:25] <mlankhorst> tvoss: hm interesting noise pattern :P
[06:25] <hikiko> could anyone review this branch: https://code.launchpad.net/~hikiko/mir/mir.native-gbm-platform-class/+merge/182074 ?
[06:25] <mlankhorst> I can vaguely make out the details
[06:26] <mlankhorst> tiling or pixel format is messed up
[06:26] <RAOF> mlankhorst: And I've just noticed that nouveau *does* keep a track of what it thinks is the front buffer that is wrong as soon as xmir_resize hits...
[06:26] <mlankhorst> RAOF: hah!
[06:26] <robert_ancell> later all
[06:26] <RAOF> SetScreenPixmap hooks for everybody!
[06:26] <RAOF> robert_ancell: 'night!
[06:26] <hikiko> bye robert_ancell
[06:27] <RAOF> Also, I really really really really hate the way xf86-video-ati has an open coded "set up this radeon_surface" struct in like<PHONE_NUMBER>342342 different places.
[06:27] <RAOF> That's right. There are more copies of that code than there are lines of code.
[06:27] <mlankhorst> tvoss: actually on closer look it looks like there are vertical lines that look correct, 4 pixels? then another vertical line with garbage
[06:27] <RAOF> It's very quantum.
[06:27] <mlankhorst> so dno
[06:28]  * RAOF goes and get groceries for dinner.
[06:28] <mlankhorst> RAOF: welcome to radeon ;)
[06:28] <mlankhorst> RAOF: don't look at the kernel!
[06:28] <mlankhorst> it has  5 copies of 'is this command ring working'
[06:28] <mlankhorst> one for each ring
[06:30] <tvoss> duflu, did you see mlankhorst's findings?
[06:30] <duflu> afk
[06:30] <tvoss> duflu, ack
[06:31] <mlankhorst> nothing in dmesg this time
[06:31] <tvoss> mlankhorst, can you check with a mir demo client if the corruption shows up with that?
[06:33] <tvoss> mlankhorst, you can use lp:~thomas-voss/glmark2/mir-no-deprecated-functions and run it in fullscreen
[06:33] <mlankhorst> hm crash on eglplasma :P
[06:33] <tvoss> hah
[06:34] <mlankhorst> http://paste.debian.net/31210/
[06:34] <mlankhorst> that's the eglplasma thing crashing, i think usc went too
[06:34] <tvoss> mlankhorst, thx
[06:34] <tvoss> mlankhorst, can you verify that usc did really crash?
[06:35] <mlankhorst> Program received signal SIGABRT, Aborted.
[06:35] <mlankhorst> [Switching to Thread 0x7f165cafe700 (LWP 2149)]
[06:35] <mlankhorst> 0x00007f1669126f77 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
[06:35] <mlankhorst> 56      ../nptl/sysdeps/unix/sysv/linux/raise.c: Bestand of map bestaat niet.
[06:36] <mlankhorst> http://paste.debian.net/31211/
[06:37] <mlankhorst> lol, crashes on closing egltriangle too
[06:37] <mlankhorst> but the triangle looks fine, fwiw
[06:38] <tvoss> mlankhorst, okay, thanks for the hints
[06:38] <mlankhorst> back to the drawing board for you? :P I'm going to test for raof a bit
[06:39] <tvoss> mlankhorst, ack, calling some people to get an amd machine now
[06:41] <tvoss> mlankhorst, okay, I'm mostly interested in the corruption right now
[06:49] <mlankhorst> tvoss: oh I'm still on mesa 9.2 fwiw
[06:50] <tvoss> mlankhorst, mind switching to default saucy?
[06:51] <duflu> Sorry... had to get a quick fix for my leaky roof. Done I think
[06:52] <duflu> tvoss: What am I looking at?
[06:52] <mlankhorst> tvoss: actually I do, need to finish testing on that first :P
[06:52] <mlankhorst> but fine
[06:54] <duflu> mlankhorst: Yes I suspect the vertical lines might just be the drm fb using the wrong pixel format to the attached bo
[06:55] <duflu> Since we don't actually set it yet...
[06:56] <duflu> mlankhorst: Also, compiz _will_ switch front buffers, when it decides a fullscreen window can be "unredirected"
[06:56] <mlankhorst> that probably sounds about right :P
[06:58] <duflu> tvoss: "did you see mlankhorst's findings?" .... where?
[06:59] <mlankhorst> actually it looks like even worse garbage on 9.1.6 :P
[06:59] <mlankhorst> might just be freed memory being displayed
[07:00] <mlankhorst> hm then again it looks too much like what should be displayed, so i dont know
[07:00] <mlankhorst> but there's definitely some garbage on top of it
[07:01] <duflu> mlankhorst, sounds like what I saw with radeon doing bypass on raring. Still could never test saucy
[07:11] <tvoss> duflu, where would we need to set the pixel format?
[07:12] <duflu> tvoss: DRM calls. I will put together an attempt momentarily... which I have done before but never found a need to modify that code till now
[07:12] <duflu> I mean, it's something I've tried before but never found a system where it was necessary, yet
[07:13] <mlankhorst> $6 = {drawable = {type = 1 '\001', class = 0 '\000', depth = 24 '\030', bitsPerPixel = 32 ' ', id = 0, x = 0, y = 0, width = 2720, height = 1024, pScreen = 0x7f92f1e1b700, serialNumber = 2589},
[07:13] <mlankhorst>   devPrivates = 0x7f92f264ef38, refcnt = 1, devKind = 10880, devPrivate = {ptr = 0x0, val = 0, uval = 0, fptr = 0x0}, screen_x = 0, screen_y = 0, usage_hint = 2, master_pixmap = 0x0}
[07:13] <mlankhorst> RAOF: screen pixmap^
[07:13] <mlankhorst> but the pixmap the function is called with is this
[07:13] <mlankhorst> $7 = {drawable = {type = 1 '\001', class = 0 '\000', depth = 24 '\030', bitsPerPixel = 32 ' ', id = 0, x = 0, y = 0, width = 1280, height = 1024, pScreen = 0x7f92f1e1b700, serialNumber = 2124},
[07:13] <tvoss> duflu, ack
[07:13] <mlankhorst>   devPrivates = 0x7f92f1e8aca8, refcnt = 1, devKind = 5120, devPrivate = {ptr = 0x0, val = 0, uval = 0, fptr = 0x0}, screen_x = 0, screen_y = 0, usage_hint = 0, master_pixmap = 0x0}
[07:16] <RAOF> mlankhorst: Thanks.
[07:21] <duflu> Silly question... "DMAbuf" I've never seen explicitly mentioned. Is it part of how we use drmModeAddFB ?
[07:22] <RAOF> No.
[07:22] <RAOF> dma-buf is our buffer IPC mechanism.
[07:23] <RAOF> We go from a gem name (for use in drmModeAddFB et al) to a dma-buf fd and back.
[07:25] <duflu> RAOF: Umm, kay. So it is correct to pass in  gbm_bo_get_handle(bo).u32 (the "gem" handle?) to  AddFB?
[07:25] <duflu> Obviously it works for intel+nouveau...
[07:26] <RAOF> Yup, that would be the right thing.
[07:30] <duflu> It's really confusing when people talk about "gem" this and that, even in naming variables, but "gem" isn't mentioned in the API at all. It's just uint32_t
[07:31] <tvoss> duflu, sounds like we should have a wrapper for that then :)
[07:31]  * tvoss restarts
[07:31] <duflu> tvoss: Not Mir's fault. Just DRM... undocumented
[07:31] <tvoss> duflu, ack
[07:34] <Mirv> someone could check my two MP:s to get trunks in sync with the archive rebuilds https://code.launchpad.net/~timo-jyrinki/unity-mir/sync_to_archive/+merge/182553 + https://code.launchpad.net/~timo-jyrinki/unity-system-compositor/sync_to_archive/+merge/182554
[07:35] <mlankhorst> duflu: yeah gem predates dma-buf, fd's were too expensive at the time :P
[07:35] <Mirv> not sure why robert changed that architecture line in a 'no change' rebuild, but it seems fine
[07:37] <tvoss> duflu, is the bypass branch in sync with trunk?
[07:37] <RAOF> mlankhorst: Fun story: randr resizes don't fix up the root window pixmap.
[07:37] <duflu> tvoss: Not sure about the LP one, but there have been no conflicts or logic changes since 14 Aug
[07:37] <duflu> tvoss: I'm working on it locally
[07:38] <mlankhorst> RAOF: you don't say ;)
[07:38] <tvoss> duflu, ack
[07:43] <RAOF> mlankhorst: Would you kindly check the new xserver & nouveau? They're in qa-testing2 and also in git.
[07:44] <mlankhorst> sure
[07:47] <duflu> RAOF, mlankhorst: Is it standard to use fourcc's for pixel formats now? I can't tell when pixel_format is just uint32_t
[07:48] <mlankhorst> I guess so, just look at the source I guess
[07:48] <duflu> Ah, in place of documentation, interpret the source :)
[07:49] <duflu> mlankhorst: Is it generally considered valid to keep an alpha channel on scanout buffers? Or expected to fail?
[07:51] <RAOF> duflu: Pixel format is always just a uint32_t. Sometimes it's just a uint32_t generated by concatenating 4 bytes...
[07:52] <RAOF> dma-buf brought drm in to the magical world of fourccs, because it implies interop with v4l stuff.
[07:52] <RAOF> To the Zoë!
[07:53] <tvoss> RAOF, :)
[07:59] <tvoss> mlankhorst, what's the status of https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1214066
[07:59] <tvoss> ?
[08:00] <mlankhorst> as it says in the status, undecided, incomplete
[08:01] <mlankhorst> :P
[08:01] <tvoss> mlankhorst, have you seen similar behavior on your machine?
[08:01] <mlankhorst> not really, but I'm planning on releasing 9.2 soon
[08:01] <tvoss> mlankhorst, okay, eta?
[08:02] <tvoss> mlankhorst, is there a ppa with 9.2 such that I can test with Mir and XMir?
[08:02] <mlankhorst> ppa:canonical-x/x-staging
[08:02] <tvoss> mlankhorst, ack
[08:02] <tvoss> mlankhorst, so that has got all our mesa patches for Mir, too? just x-checking
[08:03] <duflu> mlankhorst: The bypass corruption issue... could that be because nothing is marked as dirty?
[08:03] <duflu> I just noticed the "dirty" feature
[08:03] <mlankhorst> no idea
[08:03] <mlankhorst> i think xorg only sends stuff when marked as dirty
[08:05] <duflu> The more I read, the more it sounds like bypass might /require/ it for some hardware
[08:10] <mlankhorst> I guess mir needs to be at least told a buffer is dirty :P
[08:18] <duflu> mlankhorst: I find some platforms fail to page flip with pixel_format's containing alpha. Can I tell if it's going to work before attempting the flip? Seems like I can't
[08:19] <mlankhorst> duflu: dno, I think if you can create a fb with the format flip should work
[08:20] <duflu> mlankhorst: FB creation always succeeds. But the drivers only check if the pixel_format is compatible later when the flip is attempted :(
[08:22] <hikiko> duflu, do you have some time to review a branch? (sorry I need to merge it and alf is on holidays so it's approved only by alan and jenkins) could you get a quick look? it's a very small change...
[08:22] <duflu> hikiko: Maybe. Not sure. I'm already way overloaded for the next day or two
[08:22] <mlankhorst> duflu: well strictly speaking ARGB would be compatible for flipping..
[08:22] <mlankhorst> but as XRGB
[08:23] <duflu> mlankhorst: Apparently not. intel rejects AR24, only flips XR24.
[08:23] <hikiko> duflu, only if you have some free time (here it is: https://code.launchpad.net/~hikiko/mir/mir.native-gbm-platform-class/+merge/182074) +thank you :)
[08:23] <mlankhorst> duflu: kernel or userspace?
[08:23] <duflu> mlankhorst: Userspace
[08:23] <mlankhorst> then fix userspace..
[08:32] <hikiko> hi alan_g :)
[08:32] <alan_g> hikiko: hi
[08:33] <hikiko> alan_g, I was waiting for you! :) can I merge this one: https://code.launchpad.net/~hikiko/mir/mir.native-gbm-platform-class/+merge/182074
[08:33] <hikiko> ?
[08:34] <alan_g> hikiko: Yeah, autolanding failed for "unrelated reasons". I'll top-approve again
[08:35] <hikiko> thank you alan_g :)
[08:35] <alan_g> hikiko: can you do the same for https://code.launchpad.net/~alan-griffiths/mir/spike-NestedOutput/+merge/182405?
[08:35] <hikiko> yes
[08:36] <hikiko> I thought it was merged.. done alan_g :)
[08:37] <alan_g> hikiko: there are some intermittent test failures that we see in CI. No-one has got to the bottom of them yet
[08:38] <hikiko> what is the Cl?
[08:38] <alan_g> CI == Continuous Integration
[08:39] <hikiko> I see
[08:56] <tvoss> duflu, RAOF back
[08:56] <tvoss> duflu, any more insights?
[08:57] <duflu> tvoss: I have an experimental change that might fix radeon. But lots of mocks are now broken :(
[08:57] <tvoss> duflu, okay, can you get packages over to mlankhorst? disable tests in the package build if need be
[08:58] <tvoss> just to verify that the change fixes radeon
[08:58] <duflu> tvoss: I will test it with everything I have first. Make sure nothing regressed
[08:59] <tvoss> duflu, ack
[08:59] <tvoss> duflu, I have got an amd machine now
[08:59] <tvoss> duflu, need to set it up with 13.04
[09:00] <RAOF> mlankhorst: How'd testing go?
[09:03] <mlankhorst> RAOF: oops was waiting for the build
[09:03] <RAOF> Slacker :)
[09:07] <tvoss> mlankhorst, xmir from archive working fine with mesa 9.2 on intel
[09:10] <mlankhorst> tvoss: yeah noticed the same with nouveau + radeon
[09:19] <duflu> Wow, I hate gmock more than ever now
[09:19] <duflu> Its sharing of details you shouldn't know and should be free to modify is absurd
[09:20] <tvoss> duflu, could you verify locally that things work fine on intel?
[09:20] <duflu> tvoss: Yes, about to start hardware testing. Given up trying to fix all the DRM mocks
[09:21] <duflu> brb
[09:29] <RAOF> mlankhorst: Still waiting for the build? :)
[09:36] <mlankhorst> nah was setting up my site
[09:36] <mlankhorst> with ssl.. https://mblankhorst.nl/
[09:40] <Mirv> the mir+mirslave on't publish next cu2d run if https://code.launchpad.net/~timo-jyrinki/unity-system-compositor/sync_to_archive/+merge/182554 + https://code.launchpad.net/~timo-jyrinki/unity-mir/sync_to_archive/+merge/182553 don't get merged
[09:41] <mlankhorst> RAOF: hm your build is a fail :P
[09:42] <mlankhorst> it built against the wrong mir?
[09:42] <RAOF> Both build locally!!!!!
[09:42] <mlankhorst> of course but there's a newer mir in the distro archive
[09:42] <mlankhorst> which it built against
[09:42] <RAOF> Arse
[09:43] <RAOF> Just force dependencies; mirclient ABI hasn't changed.
[09:48] <mlankhorst> boom, dead
[09:50] <mlankhorst> #0  NVSetScreenPixmap (ppix=0x7f84f7000490) at ../../src/nv_driver.c:613
[09:53] <mlankhorst> no bo attached yet, har har
[09:54] <mlankhorst> (gdb) print (struct nouveau_pixmap *)exaGetPixmapDriverPrivate(ppix)
[09:54] <mlankhorst> $6 = (struct nouveau_pixmap *) 0x0
[09:54] <mlankhorst> did you mean: nouveau_pixmap_bo ? :P
[09:56] <mlankhorst> I think you're worrying too much about scanout, tbh..
[09:57] <mlankhorst> RAOF: where do you see nouveau actually _using_ scanout?
[09:58] <mlankhorst> if you moved pScrn->displayWidth out from NVMapMem, I bet you could get rid of pNv->scanout entirely for xorgMir..
[09:58] <RAOF> A bit in nv_accel, but mostly in drmmode_display. It probably can be just wrong.
[09:58] <mlankhorst> I would think so :p
[10:00] <mlankhorst> bet it's the same for ati though
[10:00] <katie> tvoss, ping
[10:00] <tvoss> katie, pong
[10:01] <RAOF> mlankhorst: Probably, yeah.
[10:04] <RAOF> mlankhorst: Do you want to patch that out locally, or do you need me to push a patch for it?
[10:05] <mlankhorst> sec
[10:05] <mlankhorst> testing if nvmapmem can be skipped entirely
[10:06] <RAOF> Looks like it can, although fbScreenInit is probably going to want *something* moderately sane as displayWidth.
[10:10] <mlankhorst> yeah but it should
[10:10] <mlankhorst> probably unconditionally set it from earlier
[10:13] <mlankhorst> RAOF: you still failed :P
[10:13] <RAOF> Booo
[10:13] <mlankhorst> hm GetScreenPixmap is null
[10:13] <RAOF> Wat now?
[10:13] <RAOF> How is getscreenpixmap null?
[10:14] <duflu> tvoss: I have tested all the hardware I can test, and can't see any change in behaviour... but this might fix the test lab radeon issue: lp:~vanvugt/mir/bypass-drmModeAddFB2
[10:14] <RAOF> That's not my fault :)
[10:14] <mlankhorst> ok it might want some more sanity for displayWidth then.
[10:16] <tvoss> mlankhorst, can you test lp:~vanvugt/mir/bypass-drmModeAddFB2
[10:16] <tvoss> ?
[10:17] <tvoss> mlankhorst, I'm mostly done setting up my amd machine, too
[10:17] <duflu> tvoss: Still can't boot saucy with today's images either
[10:17] <duflu> Maybe I will have to try a BIOS. Somehow
[10:19] <mlankhorst> RAOF: hm the pixmap you create has no bo, and now nouveau_xmir_copy_to_mir crashes on that ;P
[10:21] <RAOF> mlankhorst: Huh. I don't immediately see why that would be the case.
[10:25] <mlankhorst> are you using createpixmap instead of createpixmap2? :p
[10:26] <tvoss> duflu, I can totally reproduce the garbled screen issue on ati with qa-testing \o/
[10:26] <tvoss> duflu, there is hope ;)
[10:26] <mlankhorst> hm seems so..
[10:26] <duflu> tvoss: Woo
[10:26] <RAOF> mlankhorst: Neither; I'm using Screen->CreatePixmap
[10:26] <duflu> tvoss: How garbled? Any lines?
[10:27] <tvoss> duflu, completely garbled, I couldn't see a thing
[10:27] <duflu> tvoss: Sounds like what I see with radeon on raring. I only assumed saucy would fix it cos alf said it worked for him
[10:28] <tvoss> duflu, not working here
[10:28] <tvoss> duflu, anyway, I can at least reproduce, compiling packages from your branch right now
[10:28] <RAOF> mlankhorst: Ah, maybe nouveau needs to migrate the pixmap in nouveau_xmir_copy_to_mir
[10:28] <RAOF> ?
[10:28] <duflu> tvoss: Excellent, thanks
[10:28] <tvoss> duflu, ack
[10:28] <mlankhorst> RAOF: probably..
[10:29] <mlankhorst> RAOF: actually nouveau shouldn't, xmir should :P
[10:29] <RAOF> mlankhorst: Why?
[10:30] <RAOF> There's no driver-independent way of doing that, at least that I know of.
[10:30] <RAOF> It's a DDX-internal (or, really, EXA internal) implementation detail.
[10:30] <mlankhorst> exa is doing it :P
[10:31] <mlankhorst> RAOF: in that case is there any way to force it to be migrated into the driver?
[10:31] <RAOF> You just need to throw an exaMoveInPixmap(src) at the top of nouveoau_xmir_copy_to_mir
[10:33] <mlankhorst> any idea why I didn't hit this before, though?
[10:37] <RAOF> mlankhorst: Because we weren't changing the screen resolution, so you got the fully-accelerated thing that nouveau creates on startup.
[10:38] <mlankhorst> also no luck..
[10:39] <RAOF> No fixy?
[10:39] <RAOF> Still no bo after exaMoveInPixmap()?
[10:39] <mlankhorst> hm seems there is simply no bo, driverprivate exists
[10:46] <mlankhorst> so width = 0 or height = 0 at time of creation, breaking on nouveau_exa_create_pixmap shows both were 0 at time of CreateScreenResources..
[10:47] <RAOF> Oh! You're not hitting this after resize, but on startup?
[10:49] <mlankhorst> yeah
[10:49] <RAOF> Oh. You're no longer creating pNv->scanout, are you?
[10:49] <mlankhorst> indeed
[10:50] <RAOF> So when NVCreateScreenResources refs pNv->scanout into GetScreenPixmap()->bo…
[10:50] <mlankhorst> well I fixed that one
[10:51] <mlankhorst> and that only happens later, it dies in createscreenresources before that point
[10:51] <mlankhorst> hm or not, let me rebuild just to be sure
[10:51] <RAOF> Yeah, but you map anything into GetScreenPixmap()->bo?
[10:52] <mlankhorst> hm no, should it?
[10:54] <RAOF> Probably; as you say, the screen pixmap is created in miCreateScreenResources with width = height = 0 and then ModifyPixmapHeader'd.
[10:54] <mlankhorst> how nasty..
[10:56] <RAOF> Yeah, I'm not entirely sure why it does that.
[10:57] <mlankhorst> setscreenpixmap is not even called though :P
[10:58] <mlankhorst> miSetScreenPixmap isn't, at least
[11:00] <mlankhorst> RAOF: does xserver always use ModifyPixmapHeader to change resolution?
[11:00] <RAOF> Hahahahahahha!
[11:00] <RAOF> Modify resolution! Surely you jest!
[11:00] <mlankhorst> ugh w/e
[11:00] <mlankhorst> s/change/during/
[11:00] <RAOF> No; xserver doesn't modify resolution. It delegates that entirely to the driver.
[11:01] <mlankhorst> ok so how does xmir handle it :P
[11:01] <RAOF> c/o randr.
[11:01] <RAOF> I use Screen->CreatePixmap(new_width, new_height, ...)
[11:01] <RAOF> Then set the screen pixmap & root window pixmap.
[11:02] <RAOF> But that code doesn't get called on startup.
[11:03] <RAOF> On startup it's just miCreateScreenResources shoving stuff directly into pScreen->devPrivate.
[11:09] <mlankhorst> hm adding exaMoveInPixmap(src) to createscreenresources probably worked
[11:09] <duflu> RAOF: tvoss showed me webcam of what looks like bypass working on radeon. But the stride is all messed up. Have you fixed any radeon stride-ness?
[11:09] <mlankhorst> something crashed though :P
[11:09] <mlankhorst> but might just be the gpu *checks*
[11:10] <RAOF> duflu: What version of radeon/xmir?
[11:10] <tvoss> RAOF, archive
[11:11] <tvoss> RAOF, or better qa-testing, which is archive
[11:11]  * RAOF tries to page that version of the driver back into my brain.
[11:12] <tvoss> RAOF, sorry for the context switch
[11:12] <RAOF> duflu: There have certainly been stride-related *changes* between there and qa-testing2
[11:12] <duflu> So... get the DDX from qa-testing2?
[11:14] <RAOF> You'd need both the DDX and xserver from qa-testing2
[11:14] <duflu> OK, same bug or not, I'm reinstalling radeon. BRB
[11:14] <tvoss> duflu, qa-testing shows the same pattern
[11:15] <tvoss> duflu, slightly more noisy though
[11:15] <duflu> tvoss: So the new branch made no difference. I recommend the old one (in qa-testing)
[11:15] <duflu> Going to put radeon back in
[11:15] <duflu> 5 min
[11:16] <tvoss> hah, egl-triangle works perfectly fine :)
[11:17] <tvoss> RAOF, would it work if I take X and radeon from qa-testing2?
[11:17] <RAOF> tvoss: Should, yes.
[11:18] <tvoss> RAOF, ack
[11:18] <RAOF> Well, obviously modulo the Mir bugs you're trying to track down :)
[11:18] <tvoss> RAOF, ;)
[11:18] <tvoss> duflu, \o/ egltriangle is working perfectly fine on qa-testing
[11:18] <tvoss> with the noise in the background ;)
[11:18] <duflu> tvoss: Umm, what?!
[11:19] <tvoss> duflu, wanna see?
[11:19] <duflu> Sure
[11:19] <tvoss> duflu, calling you on g+
[11:19] <tvoss> duflu, can you invite me to a hangout again?
[11:22] <mlankhorst> RAOF: but I think adding exaMoveInPixmap is enough..
[11:22] <mlankhorst> to NVSetScreenPixmap
[11:22] <RAOF> Oooh, yeah. That's even better!
[11:23] <tvoss> RAOF, ?
[11:23] <mlankhorst> RAOF: oh and add this to your .quiltrc
[11:23] <mlankhorst> QUILT_REFRESH_ARGS="-p ab --no-timestamps --no-index"
[11:23] <RAOF> tvoss: mlankhorst's suggestion of moving the screen pixmap into VRAM in SetScreenPixmap. Rather than in nouveau_xmir_copy_to_mir.
[11:23] <RAOF> mlankhorst: OOOOH AWESOME.
[11:24] <mlankhorst> QUILT_NO_DIFF_INDEX=1
[11:24] <mlankhorst> QUILT_NO_DIFF_TIMESTAMPS=1
[11:24] <mlankhorst> and that :P
[11:24] <hikiko> alan_g|afk, I have an idea of something that might be wrong in the mir-on-mir design but I am not sure...
[11:24] <mlankhorst> hm I guess that one is more thorough
[11:28] <tvoss> RAOF, I need xserver-xorg-common, xserver-xorg-core, xserver-xorg-xmir. Correct?
[11:28] <alan_g> hikiko: tell me
[11:28] <RAOF> tvoss: Correct.
[11:28] <RAOF> Technically you don't need xserver-xorg-common, but dpkg will complain if you don't have matching versions :)
[11:29] <tvoss> RAOF, exactly
[11:29] <duflu> Argh. Nested display stuff has broken bypass builds
[11:29] <tvoss> duflu, why is that?
[11:29] <alan_g> duflu: how?
[11:30] <duflu> Class changes...
[11:31] <duflu> Or has my system switched to gcc-4.7 by accident too?
[11:32] <tvoss> duflu, RAOF a lot better, but still not there
[11:32] <tvoss> duflu, can you invite me to a hangout?
[11:32] <duflu> What's a lot?
[11:33] <tvoss> duflu, I can log in to my session, and run glmark2
[11:33] <hikiko> alan_g, I am not sure but as we have designed it we call the create_nested_display with a parameter that is the native display constructor which means that the native display constructor is called before the nested one and we initialize the gbm/drm etc before we have a nested platform and a connection etc but I am not sure if this is bad and if this has anything to do with the bug I have
[11:34] <hikiko> still investigating
[11:34] <duflu> tvoss: Lost you... ?
[11:37] <alan_g> hikiko: *if* we need to initialize gbm after connecting to the host then that just means we shouldn't do it in the NativeDisplay constructor.
[11:37] <hikiko> yes, that's what I am checking now
[11:37] <hikiko> if moving this part
[11:37] <hikiko> will solve the issues
[11:38] <RAOF> mlankhorst: Are you able to upload to qa-testing2 / push a merge request to github?
[11:38] <tvoss__> duflu, can you call me again please?
[11:38] <tvoss__> duflu, internet connection dropped
[11:38] <RAOF> mlankhorst: 9:30 says “you're too tired to do any real work, go to sleep”
[11:41] <hikiko> alan_g, the thing is if I add the gbm code to the nested platform then it won
[11:41] <hikiko> mmm nothing :)
[11:42] <alan_g> duflu: I see - you're changing the DisplayBuffer interface and that is implemented in nested.
[11:43]  * alan_g wishes folks would let code land instead of keeping it on branches for days on end
[11:44] <alan_g> duflu: want me to MP a fix?
[11:44] <duflu> alan_g, please
[11:44] <mlankhorst> RAOF: well dno about the merge request stuff
[11:46] <alan_g> hikiko: ?
[11:47] <hikiko> nothing I fixed it :)
[11:48] <hikiko> I changed the drm.setup call and now I get an exception that mir tries to get a drm device it shouldnt but that's easier to fix :)
[11:48] <alan_g> hikiko: cool
[11:58] <alan_g> duflu: https://code.launchpad.net/~alan-griffiths/mir/prepare-nested-for-bypass/+merge/182610
[12:09] <tvoss__> mlankhorst, can you check if XMir on nouveau with qa-testing is working?
[12:18]  * duflu -> dinner
[12:21] <tvoss__> greyback, got a machine with an nvidia card?
[12:21] <greyback> tvoss__: I do, but at home (am in my office)
[12:21] <tvoss__> greyback, ack
[12:22] <tvoss__> anyone with an nvidia card around?
[12:22] <mlankhorst> tvoss__: oh seems to work btw
[12:24] <tvoss__> mlankhorst, can you try x vs. xmir vs. xmir bypass with glmark2 please?
[12:25] <mlankhorst> how? :P
[12:25] <mlankhorst> not sure if it's going to be accurate either
[12:26] <tvoss__> mlankhorst, well, it's a bit tedious, and involves installing and uninstalling
[12:26] <tvoss__> mlankhorst, got time for that right now? or are you busy with other stuff?
[12:26] <mlankhorst> not that busy, waiting for some compiles
[12:41] <tvoss__> mlankhorst, do you know your way around the xmir radeon driver?
[12:41] <mlankhorst> sort of
[12:42] <mlankhorst> raof knows the pure X stuff a lot better than me, so for any deep architectural questions ask him, small things I can probably do :P
[12:42] <tvoss__> mlankhorst, can I show you something on a hangout? I think you know how to fix it
[12:43] <kgunn> tvoss__: can i join for a status/data dump ?
[12:43] <tvoss__> kgunn, sure
[12:43] <mlankhorst> word description would be easier I think, if it's small :P
[12:43] <tvoss__> mlankhorst, well, with bypass, I'm pretty sure we have one stall frame coming from the X side
[12:43] <tvoss__> mlankhorst, easier if I can just show you what I'm seeing
[12:44] <mlankhorst> hm raof would know this kind of thing a lot more than me, I probably don't know about that ;P
[12:45] <tvoss__> mlankhorst, can you point me to the branch we are building from?
[12:45] <tvoss__> mlankhorst, will look myself then
[12:46] <mlankhorst> raof's github, xf86-video-ati
[12:46] <mlankhorst> the ones in the archive are on debian
[12:47] <mlankhorst> http://anonscm.debian.org/gitweb/?p=pkg-xorg/driver/xserver-xorg-video-ati.git;a=shortlog;h=refs/heads/ubuntu
[12:48] <kgunn> tvoss__: appears to be branch foo
[12:49] <mlankhorst> the foo branch is for mm support
[12:53] <tvoss__> mlankhorst, ack and thx
[12:53] <tvoss__> olli, kgunn wanna jump on a hangout real quick?
[12:54] <kgunn> tvoss__: good for me
[12:55] <olli> wfm, give me 2min
[12:55] <tvoss__> kgunn, sent you an invite
[12:55] <tvoss__> kgunn, can you open a hangout and invite me?
[12:56] <kgunn> tvoss__: :)) sure
[13:26] <duflu> Oh, hello USA. I must be in the wrong place
[13:28] <duflu> tvoss__, I'm finding new ways to make radeon do the same thing (noise without errors) but getting nowhere. Do you need me online?
[13:29] <duflu> kgunn^ ?
[13:29] <tvoss__> duflu, not right now
[13:42] <tvoss__> mlankhorst, do you have any idea what radeonShadowWindow is supposed to do?
[13:42] <mlankhorst> hold on let me check
[13:44] <mlankhorst> return a pointer to the window in shadowfb
[13:49] <mlankhorst> shadowfb is just a b ig slab of memory encompassing all screens :)
[13:54]  * kgunn notes... kgunn^ didn't alert me...huh
[14:07] <tvoss__> mlankhorst, in radeon_kms.c
[14:07] <tvoss__> mlankhorst, line 205: mind explaining to me the stride calculation?
[14:09] <tvoss__> mlankhorst, that should be the stride in pixels, under the assumption that every pixel has got 8 byte, correct?
[14:10] <alan_g> hikiko: any progress towards nested GBM?
[14:11] <mlankhorst> tvoss__: no, *BITS*perpixel :P
[14:11] <mlankhorst> eg / 8
[14:13] <hikiko> yes alan_g
[14:13] <hikiko> I found a bug
[14:13] <hikiko> https://code.launchpad.net/~hikiko/mir/mir.fix-drm-version/+merge/182653
[14:14] <alan_g> hikiko: \o/ I'll take a look
[14:15] <hikiko> alan_g, I don't know if it's relevant to RAOF-duflu task but since it includes drm code I added them as reviewers
[14:16] <hikiko> (alf is on holidays :/)
[14:26] <mlankhorst> hikiko: considering freeing NULL is allowed, maybe you can come up with a more compat version?
[14:28] <hikiko> true :) I'll fix it
[14:28] <mlankhorst> eg if (!(drm_version = drmGetVersion(tmp_fd)) || !(drm_version->version_major < 1) || (drm_version->version_major == 1 && drm_version->version_minor < 4)) { drmFreeVersion(drm_version); } ; etc :P
[14:29] <hikiko> oh
[14:29] <mlankhorst> but I think that would fail, did you actually test it with drm as the only user?
[14:29] <hikiko> I thought you mean I free something that is null
[14:30] <hikiko> what do you mean by drm as the only user?
[14:30] <hikiko> I tested with mir_server_basic mir_server_shell and nested mir mlankhorst
[14:31] <hikiko> I just ran it and print the version numbers with and without the change
[14:31] <hikiko> without the change nested mir couldnt allocate any device with drm 1.6
[14:32] <hikiko> do you think I have to test something more?
[14:33] <mlankhorst> I don't think they're identical, let me check..
[14:34] <hikiko> ok
[14:35] <mlankhorst> drmGetVersion gets the driver version, which is dd_major/minor
[14:35] <hikiko> so I should get the di
[14:35] <hikiko> you are right
[14:35] <mlankhorst> and is different for each driver
[14:36] <hikiko> if we want the interface version
[14:36] <hikiko> why do we do it in a loop?
[14:36] <mlankhorst> a misguided attempt..
[14:36] <mlankhorst> at fixing a race condition, but it does not work
[14:37] <hikiko> ok I'll delete the MP then and check more tomorrow because it's almost the end of my day :)
[14:37] <mlankhorst> hikiko: who passes the fd, or do you open it yourself?
[14:37] <mlankhorst> if the fd is passed to you, you could kill the check and assume the version is correct
[14:37] <mlankhorst> fixing nesting
[14:38] <hikiko> yes that's what I did but then I thought that for some reason we need that check
[14:38] <hikiko> so I tried to "fix" it
[14:38] <mlankhorst> it's only required if opening the fd yourself the first time
[14:39] <hikiko> that's what I think we do
[14:39] <hikiko>         tmp_fd = open(dev_path, O_RDWR, O_CLOEXEC);
[14:40] <hikiko> but the thing is
[14:40] <hikiko> we run this code *after* we open the device
[14:40] <hikiko> and if the version is not the desired
[14:40] <hikiko> we close the device
[14:40] <hikiko> is this correct?
[14:40] <mlankhorst> drmSetInterfaceVersion is not really required for mir, just assume it's correct or other things would have broken down sooner..
[14:42] <hikiko> ok then I ll do an MP without any check at all
[14:42] <mlankhorst> sec, I had a nice check in nouveau for it
[14:44] <mlankhorst> drmModeGetResources(fd), if it returns NULL kms is not supported :P
[14:45] <mlankhorst> freed with drmModeFreeResources
[14:49] <hikiko> mlankhorst, I think we do that check elsewhere let me see
[14:49] <mlankhorst> probably but if you do that check first it should be good enough
[14:50] <hikiko> yes we do it at the beginning
[14:50] <hikiko> so I guess there's no need to do it again
[14:52] <mlankhorst> well I think it's required for getting bus name, but meh
[14:54] <tvoss__> mlankhorst, how am I supposed to test mm from qa-testing2? Seems like xserver-xorg-xmir in there is built against trunk
[14:55] <mlankhorst> tvoss__: dpkg -i --force :P
[14:55] <mlankhorst> it's what I did anyway
[14:58] <hikiko> http://manpages.ubuntu.com/manpages/raring/man3/drmModeGetResources.3.html mlankhorst it doesnt seem to give any information on the version
[14:58] <mlankhorst> hikiko: not really, but it only works if kms is available
[14:59] <mlankhorst> if (!drm_core_check_feature(dev, DRIVER_MODESET))
[14:59] <mlankhorst> 		return -EINVAL;
[14:59] <hikiko> ok that check is done at mir initialization
[14:59] <hikiko> so we don't need to do it one more time
[14:59] <mlankhorst> yeah but I fear it might break things, so try testing at least once without plymouth
[15:00] <hikiko> I am not using plymouth as far as I know mlankhorst
[15:00] <hikiko> :s
[15:00] <hikiko> how can I check if I use plymouth?
[15:01] <mlankhorst> hikiko: it's part of the boot sequence
[15:01] <hikiko> if you run unity I guess?
[15:01] <mlankhorst> removing splash from linux cmdline options might be enough
[15:02] <mlankhorst> no, plymouth is the boot splash thing
[15:02] <hikiko> ah ok I have disabled the splash and everything the first day I installed ubuntu :D
[15:02] <hikiko> so I don't have plymouth
[17:28] <kgunn> mlankhorst: you still on ?
[18:03] <tvoss__> jibel, ping
[18:07] <jibel> tvoss__, pong
[18:12] <hoodoowoo> balloons: are you handy?  I had a conversation with you yesterday, but I don't know if you're the one I should ping now (so please redirect as appropriate).  I'm eager to respond to a question, but I need a follow up to this question: https://bugs.launchpad.net/unity-system-compositor/+bug/1217262/comments/3
[18:15] <balloons> hoodoowoo, perhaps you had a different nick yesterday? :-p
[18:16] <hoodoowoo> balloons: heh, yes, different computer
[18:16] <hoodoowoo>  /account/work rules, etc.
[18:16] <hoodoowoo> frothnicator
[18:19] <balloons> hoodoowoo, ok, I saw your thread
[18:20] <hoodoowoo> the joys of being a friendly tester but without the development background to have no questions ...
[18:20] <balloons> the ppa is frozen during testing, so you would have to build from trunk i'd guess.. or use the unstable ppa, if the team is building it and they think that is sane
[18:20] <balloons> http://unity.ubuntu.com/mir/building_source_for_pc.html
[18:21] <balloons> I'd defer to others in here on that
[18:21] <tvoss__> mlankhorst, around?
[18:32] <hoodoowoo> balloons: noted.  I'm now on the idea of automated testing.  Have y'all thought about have a script as part of the PPA that testers can execute?  I ask because though I tried to go through the test scenarios, I don't know exactly what the developers need to see.  A script could extract these automatically.
[18:35] <balloons> hoodoowoo, there was an idea for a script that olli had, but time constraints led us here ;-)
[18:35] <hoodoowoo> roger.
[18:36] <hoodoowoo> balloons: from the outside, it seems like that script could be rather useful going forward.  Otherwise, you get stupid testers like me who don't know what their doing.  ;-)
[18:36] <balloons> hoodoowoo, :-) Just testing it and giving a thumbs up or thumbs down is important
[18:38] <balloons> automated tests are useful but they don't replace your experience, your machine, etc
[18:38] <hoodoowoo> well, then, thumbs up for the work in general (was impressed by the KMS integration, and auto-detection of the VGA cable).
[18:38] <balloons> and they aren't as smart as someone look at it
[18:39] <balloons> thanks for testing :-)
[18:39] <hoodoowoo> balloons: ah, I was looking at the fact that the devs (I assume y'all?) don't have access to every machine, but do know exactly what you need to see.  On the other hand, various testers (like me), have machines and configurations that you don't have.  Hence the idea for the test script that you write, but I run.  But gotcha.  Hope I was helpful.
[18:40] <hoodoowoo> ... thumbs up for work in general ... thumbs down for ability to complete some of the test scenarios, etc.
[18:42] <kgunn> hoodoowoo: thanks for testing....yeah, would've loved to get a bit more automated....but...clock killed us :)
[18:42] <balloons> I'm not a dev, so I won't take any credit.. but I'm sure they are very happy to receive your praise.
[18:43] <hoodoowoo> kgunn: roger.  I don't know Canonical's internal time table, other than the stage freezes.  But again, I stress "going forward".  On that note, I'm out.  Time for a tester to stop wasting your time.  Thanks very much for the hard work.
[19:41] <tvoss__> okay, it becomes interesting
[22:59] <bschaefer> kgunn, hey, got around to testing the u-s-c ppa and I get a black screen on boot :(, on ati 5670
[22:59] <bschaefer> just with 1 monitor
[22:59]  * bschaefer didn't find anything to crazy about the logs
[23:00] <kgunn> bschaefer: ok...so purge that....get to a saucy only...then download & force install the xserver & x-driver from ppa:/mir-team/qa-testing2(not apt-get)
[23:01] <kgunn> it should boot to single monitor fine
[23:01] <bschaefer> kgunn, alright Ill give that a try!
[23:01] <bschaefer> yeah, thats what i was wondering about...
[23:01] <bschaefer> kgunn, but mir doesn't seem to like my ati card atm anyway
[23:01] <bschaefer> when I try to run it natively
[23:01] <kgunn> yeah...the guys updated the drivers on the problem platforms
[23:02] <bschaefer> cool, but I think my problem is a bit different, its this gbm buffer failed to create (failing on a mmap)
[23:03] <bschaefer> which I need to sill dig into the radeon.ko stuff in the kernel...
[23:03] <bschaefer> kgunn, ill give it a try any way though, possibly something fixes it :)
[23:16] <bschaefer> kgunn, well single monitor works fine on saucy with xmir soo thats good, ill attempt MM now...
[23:16] <kgunn> drum roll (don't expect much)
[23:17] <bschaefer> haha, well we shall see :)
[23:18] <RAOF> Woo!
[23:18] <RAOF> What fixed it for youL
[23:18] <RAOF> ?
[23:19] <bschaefer> RAOF, hmm well im not sure why xmir is working ... but not native mir?
[23:19] <bschaefer> RAOF, as i've only ever had a problem with native mir
[23:20] <RAOF> usc doesn't try to allocate a cursor :)
[23:20] <bschaefer> RAOF, which is just a work around then :), cause I could get around that with native mir as well, but couldn't draw to a mir region...
[23:20] <bschaefer> ill have to find sometime to do some digging into that problem
[23:33] <bschaefer> got a fun error in x-0.log: X: ../../../../include/privates.h:123: dixGetPrivateAddr: Assertion `key->initialized' failed.
[23:33] <bschaefer> and screen was black
[23:34] <bschaefer> using xserver video ati, xserver from qa-testing2
[23:34] <bschaefer> kgunn, ^
[23:35] <RAOF> bschaefer: Oooh, urgh.
[23:35] <RAOF> Why is your machine so odd :)
[23:35] <bschaefer> idk...I usually use my laptop haha
[23:35] <bschaefer> but its fired atm...
[23:35] <bschaefer> RAOF, good for testing I suppose :)
[23:36] <RAOF> kgunn: Do you happen to know the status of nouveau MM?
[23:36] <bschaefer> or bad...depending on how you look at it
[23:37] <bschaefer> grabbing these *.debs from qa-testing2... possibly I should have installed something else?
[23:37] <bschaefer> xserver-common xserver-xorg-core xserver-xorg-video-ati xserver-xorg-xmir
[23:43] <RAOF> bschaefer: Oh, you need xserver-xorg-video-radeon
[23:43] <RAOF> bschaefer: xserver-xorg-video-ati is a wrapper that just calls -radeon.
[23:45] <bschaefer> RAOF, let me try that!
[23:46]  * bschaefer should have seen that based on the size of the ati one.. 25kb
[23:47]  * bschaefer reboots
[23:53] <bschaefer> awesome! Things seem to be working
[23:53] <bschaefer> have a nice 640x480 resolution on both
[23:53] <bschaefer> but no overdraw/underdraw on my hdmi monitor which is very nice
[23:54] <RAOF> I suspect that trying to change the resolution at this point will cause sorrow.
[23:55] <bschaefer> it wont even let me :), well I could force it...but
[23:55] <bschaefer> sorrow sounds bad
[23:56]  * bschaefer tires it anyway