[00:03] <thomi> RAOF: maybe. Unity has binary deps on lots of other things though, so you often can't release libdee (for example), unless you release the rest of the stack at the same time
[00:03] <RAOF> Oh, that totally makes sense.
[01:48] <robert_ancell> RAOF, do you know who I can talk to about lightdm still being in proposed? The one in main has a serious bug
[01:49] <RAOF> robert_ancell: Probably most people in #ubuntu-release?
[01:49] <robert_ancell> RAOF, ta
[01:49] <RAOF> I'd expect a random archive admin to know.
[01:52] <mlankhorst> RAOF: oh btw can lts-raring and mesa in raring be promoted to -updates? :P
[02:12] <duflu> robert_ancell: Could you do me a favour?
[02:13] <robert_ancell> duflu, sure
[02:13] <duflu> robert_ancell: Change the "development focus" to 0.9.11 on https://launchpad.net/compiz
[02:13] <duflu> ?
[02:13] <robert_ancell> duflu, done
[02:14] <duflu> robert_ancell: Thanks
[02:17] <Sarvatt> mlankhorst: that was extra annoying, finding out it was in -proposed after recommending it to people instead of edgers :)
[02:18] <Sarvatt> mlankhorst: but infinity was talking about making daily builds work so "any day now"
[04:32] <olli> RAOF, hey
[04:32] <RAOF> olli: Yo!
[04:32] <olli> just wanted to say thanks for proposing all the patches over the weekend
[04:32] <olli> :)
[04:33] <olli> seems like the intel one got the most traction so far
[04:34] <RAOF> Well, the most reaction at least :)
[04:37] <olli> RAOF, true
[04:38] <olli> so, it seems like we have missed all major upstream releases (at least Mesa and X iirc)
[04:38] <olli> not sure if "missed" is the right term
[04:39]  * duflu wanders off to lunch
[04:39] <olli> enjoy duflu
[04:39] <olli> RAOF, how will we ship these in 13.10 then?
[04:39] <RAOF> By patching?
[04:39] <RAOF> Same way we did XI2-multitouch?
[04:41] <olli> heh, the amount of "?" indicates I was asking a stupid question ;)
[04:41] <olli> will you have to maintain 2 versions of the patches then, one for Mesa/X/... at 13.10 and one for the respective latest version
[04:41] <olli> will that be a big delta, if at all?
[04:48] <RAOF> Depends on how things change underneath.
[04:49] <RAOF> The patch as-of 13.10 though probably won't need _too_ much support that isn't simple backporting.
[05:22] <tvoss> RAOF, ping
[05:22] <RAOF> tvoss: Yo.
[05:22] <tvoss> RAOF, good morning :) got some time in your voip lair?
[05:22] <RAOF> Sure.
[05:23] <RAOF> My new, improved, VoIP lair!
[05:25] <tvoss> RAOF, \o/ let me grab coffee
[05:27] <tvoss> RAOF, can you open a hangout and add me to it, would like to join on the ipad
[05:43] <didrocks> kgunn: just to reash, I'm not thrilled to drop 50% of our testing, and just having one machine with "a workaround" to get Mir starting
[05:43] <didrocks> rehash
[05:44] <didrocks> RAOF: hey, you confirm that the ati issue isn't due to lxc, but a real issue, right?
[05:45] <RAOF> didrocks: Yeah, looked like it.
[05:45] <didrocks> RAOF: if you need access to the machine, we can provide you that
[05:46]  * didrocks is seeing that we diminish more and more on Mir quality side "just" to ship in universe
[06:49] <tvoss_> didrocks, how many machines can we provision in the lab to start mir?
[06:50] <didrocks> tvoss_: 2 right now
[06:50] <tvoss_> didrocks, why not more? it is my understanding that we have 2 ati, 2 intel and 2 nvidia machines
[06:50] <didrocks> tvoss_: we have that since yesterday
[06:50] <tvoss_> didrocks, what gpu is running in the two machines?
[06:50] <didrocks> tvoss_: we just need to provision the nvidia
[06:50] <didrocks> one intel, one ati
[06:51] <didrocks> tvoss_: the 3 others are for raring
[06:51] <tvoss_> didrocks, why do we need them for raring?
[06:51] <didrocks> tvoss_: because we support our users?
[06:51] <didrocks> so we do have SRUs everyday
[06:51] <tvoss_> didrocks, sure, but I thought we could just reprovision them with a different Ubuntu version?
[06:51] <didrocks> tvoss_: no, we need kernel == container
[06:52] <didrocks> tvoss_: the machines are the same anyway, between the ati, intel and nvidia FYI
[06:52] <tvoss_> didrocks, okay, I was told some time back that we have he/le ati, he/le nvidia, he/le intel
[06:52] <didrocks> maybe you are not mentionning the same machines then
[06:52] <didrocks> because the 3 others arrived this week
[06:53] <didrocks> and we only have 3 until then
[06:53] <tvoss_> didrocks, that might well be
[06:53] <tvoss_> didrocks, so which machine is causing issues? the ati one?
[06:53] <didrocks> yep
[06:53] <tvoss_> didrocks, intel and nvidia come up cleanly?
[06:53] <didrocks> tvoss_: well, nvidia is on raring (one of the 3 we had)
[06:53] <didrocks> we need to wire up the other one
[06:53] <didrocks> on intel, it was failing as well
[06:53] <didrocks> and we needed my workaround
[06:53] <didrocks> the sleep :/
[06:54] <didrocks> I got a "we never see it"
[06:54] <didrocks> then, when I gave the description, starting to see devs telling they saw it
[06:54] <didrocks> and "just" reboot :/
[06:54] <didrocks> we need to change that behavior
[06:54] <tvoss_> didrocks, as far as I know we do not see those issues in the cert lab
[06:55] <didrocks> tvoss_: so, we are inventing the issues?
[06:55] <didrocks> "not seen here" -> then, when opening "oh btw, I saw it some times"
[06:55] <didrocks> regular rules
[06:55] <tvoss_> didrocks, of course not, I'm just trying to track down the issue
[06:55] <tvoss_> didrocks, can I get access to the ati machine?
[06:56] <didrocks> tvoss_: see the bug report, RAOF already dived to it
[06:56] <didrocks> tvoss_: yeah, once daily are finished, I can give you access
[06:56] <tvoss_> didrocks, ack, can you paste the bugreport again?
[06:56] <tvoss_> didrocks, my backlog is a bit fucked up after numerous reboots
[06:56] <didrocks> tvoss_: bug #1203070
[06:57] <didrocks> Chris told: "it's failed to create the hw cursor buffer, and I don't believe that there are any more relevant logs
[06:57] <didrocks> available."
[07:00] <tvoss_> mlankhorst, ping
[07:04] <mlankhorst> pong!
[07:08] <tvoss_> mlankhorst, hey there :) we are trying to solve an issue with Mir failing to create a hardware cursor buffer on ati.
[07:08] <tvoss_> mlankhorst, I wonder if you are aware of any known ati issue in that area?
[07:09] <mlankhorst> erm cursor usually has special requirements for buffer
[07:30] <tvoss_> mlankhorst, okay, the call succeeds in general, we only have an issue on one specific card. Is there any way to get something like a last error from gbm?
[07:31] <mlankhorst> use the debugger(TM)
[07:32] <tvoss_> mlankhorst, woot, thanks for the enlightenment ;)
[07:32] <mlankhorst> it's what it's for :P
[08:05] <duflu> alf__: How do you guarantee that only one compositor buffer is consumed per 16ms in the multimonitor stuff? Is it still partial releases?
[08:07] <duflu> ... or yet to be figured out?
[08:09] <alf__> duflu: there is no guarantee for that atm
[08:10] <duflu> alf__: OK, I thought I might be too early. When you have an idea, please let me know
[08:10] <alf__> duflu: hmm, sorry, there is a partial guarantee
[08:11] <duflu> alf__: Saved resources?
[08:13] <duflu> alf__: I would suggest enforcing that compositor_acquire only happens for real on one monitor (which must also have the highest refresh rate of all monitors)
[08:13] <duflu> Probably #0. And recycle till that monitor refreshes again
[08:15] <alf__> duflu: about partial release... essentially the first release of a buffer marks its end as a preferred buffer for next acquisitions. Since under normal operation this happens once per ~16ms, the consumed once per 16ms is enforced.
[08:15] <alf__> duflu: (more or less)
[08:15] <duflu> alf__: I know but that won't be true under bypass, so I'm hunting for a more robust guarantee
[08:16] <duflu> Under bypass, two compositors are held and one consumed, per 16ms
[08:19] <alf__> duflu: Couldn't we just have a differently constructed BufferStream for bypass, that doesn't enforce the MultiAcquisition policies?
[08:21] <duflu> alf__: Yes. However I suspect that will cause the client to get buffers at Nmonitors*60Hz
[08:21] <duflu> Which is fine for me with one monitor right now. Not fine for working with multimonitor
[08:23] <RAOF> Dear POSIX: signals are hateful, and
[08:23] <RAOF> I hate you.
[08:24] <hikiko> hi
[08:24] <hikiko> question
[08:25] <duflu> alf__... So before it becomes a problem I would like to see some more explicit distinction between buffer recycling and guaranteed buffer advancement
[08:25] <alf__> duflu: I haven't really thought about this yet, but perhaps using a combination of a different back buffer strategy in BufferStream plus a different CompositingStrategy (note, renamed to DisplayBufferCompositor in proposed MP), which we need anyway, perhaps we could reach the needed behavior. Hopefully we won't need to have a single behavior that works for both normal and bypass, if that means making compromises for both.
[08:25] <hikiko> alf__, I tried to use the mir buffers as you said but I am not sure if you can fill the ipc package using those buffers
[08:28] <alf__> hikiko: what method are you referring to?
[08:28] <hikiko> fill_ipc_package in platform alf__
[08:29] <alf__> hikiko: well, the plan is to relay this request to the native platform to do this for you
[08:32] <RAOF> Who thought that having read() able to return EINTR at any point and *partially* consume the buffer was a good idea? >:(
[08:32] <duflu> RAOF: Before threads were invented/common...
[08:33] <duflu> Though arguably, retrying I/O is less error prone than expecting programmers to do threads reliably
[08:33] <RAOF> And who didn't want to make libc go to the effort to *not* consume the buffer in that case?
[08:33] <RAOF> Yeah, but you can't retry IO. You need to keep track of how much was actually read, and then try to read the rest.
[08:34] <RAOF> Because *that's* totally not going to be done badly, and couldn't be sensibly implemented in the goddamned system library.
[08:34] <hikiko> I don't create a native and a nested platform at the same time alf__ either native or nested
[08:38] <RAOF> Not that this is *necessarily* the cause of output delay, just that I hate noticing things that are going to explode when a SIGIO comes in at an inopportune time.
[08:38] <alf__> hikiko: the nested platform should create and use an instance of a specially configured native platform, see second paragraph of mir-on-mir mir-devel email reply
[08:39] <hikiko> ok
[08:40] <hikiko> I forgot to re-add this :p
[08:40] <hikiko> sorry :)
[08:40] <deathcrawler> Current Ubuntu Phone images uses Mir directly?
[08:44] <mlankhorst> RAOF: sigh
[08:44] <mlankhorst> I'm getting reports about mir now..
[08:44] <mlankhorst> https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1201028
[08:45] <RAOF> mlankhorst: I don't know what you're talking about officer. Mir couldn't cause *any* problems at all. See, we've corraled him in a PPA where he's kept safe from the masses!
[08:46] <mlankhorst> the bugs get filed against xorg-server though, what should I do with them?
[08:47] <mlankhorst> I just want them not be against xorg-server for now, i don't care if I close it as invalid or reassign to mir :P
[08:47] <duflu> That's odd. There should be no automatic reports when users (like that one) are using a PPA
[08:48] <RAOF> mlankhorst: Feel to reassign to the xmir project. duflu set that one up :)
[08:49] <mlankhorst> link?
[08:49]  * duflu assigned it
[08:49] <duflu> mlankhorst: Launchpad project "xmir"
[08:49] <mlankhorst> https://bugs.launchpad.net/ubuntu/+source/xorg-server?field.searchtext=mir&search=Search&field.status%3Alist=NEW&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.assignee=&field.bug_reporter=&field.omit_dupes=on&field.has_patch=&field.has_no_package=
[08:51] <mlankhorst> but I'll reassign all then
[08:54] <duflu> Oh, I was reassigning. But OK
[09:02] <alf__> deathcrawler: not yet (it still uses surfaceflinger) but we are getting close to switching
[09:20] <tvoss_> RAOF, disabling sigio event reporting in X is great, works fine here ;)
[09:47] <deathcrawler> alf__: Thanks
[10:42] <duflu> Oh dear. My diff is now over 4kloc to trunk. This is a worry
[10:57] <RAOF> tvoss_: Oh, disabling sigio events avoids the bug?
[10:57] <tvoss_> RAOF, nope
[12:17] <tvoss_> didrocks, alf__ https://code.launchpad.net/~thomas-voss/mir/fix_process_waitpid_approach_to_correctly_setup_tracing/+merge/176367
[12:18] <alf__> tvoss_: looking
[12:27] <alf__> tvoss_: what does the waitpid (pid, NULL, 0) call do after PTRACE_ATTACH?
[12:28] <tvoss_> alf__, it waits for the child process to be stopped as a result to the parent attaching. that should help us avoid a lot of races
[12:33] <ogra_> LOL
[12:33] <ogra_> http://www.indiegogo.com/projects/support-ubuntu-edge-enthusiast
[12:33] <ogra_> awesome
[12:34] <ogra_> oops, i'm not in -touch, sorry
[12:34] <tvoss_> ogra_, still great :)
[12:36] <alf__> tvoss_: is this because of  WUNTRACED   also  return  if  a  child has stopped (but not traced via ptrace(2)).  Status for
[12:36] <alf__>                    traced children which have stopped is provided even if this option is  not  speci‐
[12:36] <alf__>                    fied.
[12:37] <tvoss_> alf__, yes, partly and PTRACE_ATTACH really is what we want to do here
[12:40] <alf__> tvoss_: I guess my question is what guarantees that we have that waitpid(..., 0) is notified about the stopped child (normally waitpid() only gets termination events).
[12:41] <tvoss_> alf__, that's the usual flow of ptrace_attach and then waitpid
[12:42] <alf__> tvoss_: ok, I am not familiar with it, and the manpages are not very clear, but if it works then great :)
[12:42] <tvoss_> alf__, tests pass and I haven't seen any flakyness locally
[13:54] <mlankhorst> oh darn, I had the mir ppa enabled still..
[13:57] <mlankhorst> might have been why my nv50 was still not working after fixing all the card bugs :>
[14:10] <kgunn> mlankhorst: are you free to help with ati debug wrt this "unable to provision hw cursor" ?...we have a QA machine on which this is consistently failing 100%, didrocks can help provide access
[14:10] <kgunn> its blocking mir entering universe
[14:11] <kgunn> robotfuel: ^ let's see if mlankhorst can help
[14:15] <mlankhorst> kgunn: sure ;P
[14:15] <mlankhorst> what kind of hw btw
[14:16] <hikiko> question: do we have an env variable for the platform already? I'd like to see if my native platform is gbm or android at runtime without ifdef and maybe getenv is an option..
[14:17] <kgunn> mlankhorst: https://bugs.launchpad.net/mir/+bug/1203070
[14:17] <kgunn> "cedar"
[14:19] <kgunn> tvoss_: ^
[14:19] <tvoss_> kgunn, yup
[14:28] <mlankhorst> mmm lets see
[14:30] <mlankhorst> kgunn: that's only starting with unity-system-compositor from ppa:mir-team/unity-system-compositor right?
[14:32] <kgunn> mlankhorst: well, this may be a didrocks build, via his daily ppa (not necessarily exactly system-compositor-testing)
[14:32] <mlankhorst> mm lets try anyway..
[14:32] <didrocks> kgunn: mlankhorst: to ensure to run the same version, use those from ppa:ubuntu-unity/daily-build-next
[14:34] <mlankhorst> ok, upgrading
[14:35] <tvoss_> mzanetti, ping
[14:35] <mzanetti> tvoss_: pong
[14:35] <tvoss_> mzanetti, soemthing weird going on here: https://jenkins.qa.ubuntu.com/job/mir-android-saucy-i386-build/1415/console
[14:36] <mzanetti> tvoss_: hmm... seems to be the same as last time
[14:36] <mzanetti> tvoss_: I wonder why this is build on ps-android-sandybridge. That seems wrong
[14:36] <mzanetti> tvoss_: as that's the machine where the devices for testing are attached
[14:40] <mzanetti> tvoss_: yeah. this definitely seems wrong to me. who sets up Mir jobs usually?
[14:41] <kgunn> hikiko: should be easy to add...i would think you could check if gralloc is present
[14:42] <tvoss_> mzanetti, same happens for clang: https://jenkins.qa.ubuntu.com/job/mir-clang-saucy-amd64-build/1300/console
[14:43] <tvoss_> mzanetti, not sure, thomi perhaps?
[14:43] <tvoss_> alf__, ^ can you help here?
[14:43] <mzanetti> tvoss_: hmm... not sure why the one on kinnara fails. that should work.
[14:44] <mzanetti> tvoss_: I contacted fginther. he's in a phone call right now. when he's free again we'll try to resolve it asap
[14:44] <hikiko> yes I've added kgunn I just wonder if we already used one because I couldn't find any
[14:44] <alf__> hikiko: why do you need to get the native platform type?
[14:44] <hikiko> because my nested platform has a pointer to the native platform in order to call native functions when necessary
[14:45] <hikiko> and I have to initialize that pointer to a new GBM or a new Android platform
[14:45] <hikiko> (the pointer is mg::Platform)
[14:45] <tvoss_> hikiko, I thought the idea is that the nested platform does not need to know those details?
[14:46] <hikiko> it won't know
[14:46] <hikiko> then it will use the mg::Platform functions
[14:47] <hikiko> but at some point I have to initialize the mg::Platform
[14:47] <tvoss_> hikiko, isn't it like auto platform = mg::NestedPlatform()?
[14:47] <alf__> hikiko: you can do it that the same way we get the platform currently, by exposing a symbol in the native platform library (e.g. create_native_platform_nested(...))
[14:48] <hikiko> I call create_platform_nested() :s
[14:48] <hikiko> but even the current create_platform
[14:48] <hikiko> returns a GBMPlatform in GBM case
[14:48] <hikiko> and an Android in case of android
[14:49] <hikiko>     return std::make_shared<mgg::GBMPlatform>(report, vt);
[14:49] <hikiko> you specify that your pointer is mgg::GBMPlatform
[14:50] <mlankhorst> kgunn: hm tons of fun spam in dmesg......
[14:50] <alf__> hikiko: Isn't that what you need? The native platform knows what to do when you call create_native_platform_*(...). It creates an appropriate mg::Platform pointer and sends it back to you.
[14:50] <mlankhorst> kgunn: http://paste.debian.net/18047/
[14:50] <mlankhorst> though no idea why....
[14:51] <hikiko> yes but in create_platform* you specify what type of platform this is
[14:51] <hikiko> you can't have a mg::Platform pointer without initialize it with new GBM or new Android
[14:51] <kgunn> mlankhorst: do we need to contact radeon guys?
[14:51] <mlankhorst> but I guess that's what causes your issue here
[14:51] <hikiko> you either have to do ifdef "GBM"...
[14:51] <mlankhorst> kgunn: I think so..
[14:51] <hikiko> or get the platform at runtime
[14:51] <hikiko> using getenv for example
[14:52] <kgunn> mlankhorst: do you have a contact ? (i'm supposing you already have :)
[14:52] <mlankhorst> kgunn: that was with drm-next + drm-fixes of today :P
[14:52] <hikiko> create_platform returns a different pointer in gbm and in android case
[14:52] <mlankhorst> I guess #radeon would work, brb buying some food
[14:52] <kgunn> ta
[14:53] <alf__> hikiko: that's what create_native_platform_nested() will do also, no difference in the mechanism, just in the way the native platform is set up internally
[14:53] <mlankhorst> that was a merge of drm-next + drm-fixes, dno how representive that is :P
[14:53] <mlankhorst> hm i should probably try with a cleaner kernel later just in case
[14:53] <hikiko> alf__, I am talking about the create_platform_nested implementation
[14:53] <hikiko> mmm
[14:54] <hikiko> I mean that
[14:54] <hikiko> even if create_native_platform_mnested
[14:54] <hikiko> lives in GBMPlatform
[14:54] <hikiko> it has to return a GBMPlatform pointer
[14:54] <hikiko> ah :) sec
[14:56] <hikiko> lol ok :) mg::Platform lala = create_native... yeah... got it... :P
[14:56] <hikiko> <-tired :p ok, ignore :)
[14:57] <hikiko> thanx!
[14:57] <hikiko> I wrote the func and forgot to use it 2 times today :p
[15:05] <tvoss_> greyback, ping
[15:05] <greyback> tvoss_: pong
[15:27] <mlankhorst> kgunn: ugh, was lacking pm firmware
[15:28] <kgunn> mlankhorst: pm == power management ?? (e.g. pmic )
[15:28] <mlankhorst> yeah
[15:28] <kgunn> mlankhorst: oh...yeah...so hw mouse would be like one of the first hw accelerators i suppose
[15:28] <kgunn> in terms of sw trying to use it
[15:29] <mlankhorst> indeed
[15:29] <mlankhorst> so I guess you should check dmesg, just in case
[15:30] <kgunn> mlankhorst: so, where does that lie in the field of responsibility ?....is that a ubuntu saucy foundational problem ?...or?
[15:30] <mlankhorst> kgunn: heck check dmesg on that machine, then you know for sure
[15:30] <kgunn> mlankhorst: mmm, but X worked ?
[15:31] <kgunn> gotta run
[15:31] <mlankhorst> x can fallback to unaccelerated
[15:31] <kgunn> brb
[15:52] <kgunn> mlankhorst: ok...back, so "we" mir team need to add in fallback for sw cursor for xmir/radeon ?
[16:00] <kgunn> bschaefer is this something you could look pre-australian time ? ^
[16:00] <kgunn> didrocks can give bschaefer access to machine if needed
[16:01] <bschaefer> kgunn, whats going on? The sw cursor thing?
[16:01] <kgunn> bschaefer: yeah
[16:01] <kgunn> https://bugs.launchpad.net/mir/+bug/1203070
[16:01] <kgunn> basically we know the problem....we need to create a solution & test it
[16:03] <bschaefer> kgunn, possibly, i've a few other things ive to work on :)
[16:03] <didrocks> kgunn: sure, tell me once you need the access so that I can prepare
[16:03] <kgunn> bschaefer: no prob...if you're helping robotfuel keep doing that
[16:03] <kgunn> no pointing in switching just for the sake of it
[16:03] <bschaefer> kgunn, no, i do unity-maintenance under bregma and i've some new ibus changes I need to get landed
[16:03] <kgunn> greyback: curious...you said unity8 now (w/ some caveats/bugs) runs on mir....do the instructions on the wiki need to change ?
[16:04] <kgunn> or does it all just magically stay relevant ?
[16:04] <bschaefer> kgunn, if I can finish that up quickly I could possibly take a look :)
[16:04] <greyback> kgunn: which instructions? Let me check through them
[16:04] <kgunn> bschaefer: ah...ibus...yeah...kinda critical :)
[16:04] <kgunn> greyback: https://wiki.ubuntu.com/Touch/Testing/Mir
[16:05] <bschaefer> kgunn, yeah, as some would like the new version landed, but that SW fallback cursor is also critcal!
[16:05] <greyback> kgunn: hmm, so that URL to s-jenkins is an internal url only, so no community people will be able to use it.
[16:06]  * bschaefer goes to work fast
[16:06] <greyback> kgunn: other bits could be updated, yes. I'll add it to my list
[16:06] <kgunn> greyback: doh...good point
[16:06] <kgunn> np...in due time
[16:06] <greyback> kgunn: ack
[16:08] <kgunn> greyback: crap...can you shoot me the link to your sketchpad of "todo's" closed it before saving link
[16:09] <greyback> kgunn: sure: http://studio.sketchpad.cc/UFFAX8fxc2
[16:10] <kgunn> greyback: one more interrupt, does "Use actual surfaces instead of screenshots for window management" actually address my "cut corners" blueprint ?
[16:12] <greyback> kgunn: I don't think so. That proposal is for shell to animate the actual application surface, not a screenshot of the application (as we're doing right now)
[16:12] <greyback> kgunn: nothing to do with single-surfac shell
[16:14] <kgunn> greyback: got it...texture source for the single surf...not actual compositing...
[16:29] <kgunn> didrocks: can you paste the dmesg output from the ati-trouble machine into the bug ? https://bugs.launchpad.net/mir/+bug/1203070
[16:31] <tvoss_> mlankhorst, ping
[16:38] <didrocks> kgunn: I just pasted the relevant time log: https://bugs.launchpad.net/mir/+bug/1203070/comments/5
[16:38] <didrocks> (the lightdm segfault)
[16:40] <kgunn> didrocks: ??....lankhorst indicated the pm firmware not being installed as the reason for hw mouse failing....this is somewhere after that
[16:41] <mlankhorst> kgunn: pong, might be related, maybe not
[16:41] <didrocks> kgunn: I don't see any logs for it, does he know what we should install? (even on the image by default)
[16:41] <mlankhorst> can i start unity-system-compoistor alone
[16:41] <didrocks> mlankhorst: it seems lightdm is setting up an environment for it
[16:41] <didrocks> so stopping/start lightdm
[16:42] <mlankhorst> without lightdmm...
[16:42] <didrocks> would be a question for kgunn and robert_ancell I guess :)
[16:42] <kgunn> mlankhorst: sure.. (in xmir config i assume you mean)
[16:43] <kgunn> which should just kick of mir
[16:43] <kgunn> tvoss_: ^ sanity
[16:43] <kgunn> but obvioulsy...no mir clients (as xmir has failed by that point)
[16:44] <tvoss_> kgunn, ENOCONTEXT
[16:46] <kgunn> tvoss_: could one, after a failure to boot in xmir, kick off the u-s-c process manually
[16:46] <tvoss_> kgunn, hmmm, no, you need lightdm and the env for that ...
[16:48] <kgunn> tvoss_: is the need for lightdm because we cannot have a "clientless" mir ?
[16:48]  * didrocks wasn't on crack then :)
[16:48] <tvoss_> kgunn, of course not, it's because the usc needs t obe passed some file descriptors
[16:48] <tvoss_> kgunn, and a vt to operate upon
[16:49] <kgunn> tvoss_: ack
[16:49]  * kgunn was insane...
[16:52] <mlankhorst> gone
[18:15] <bschaefer> kgunn, ping
[18:21] <kgunn> bschaefer: yo
[18:21] <bschaefer> kgunn, hey, so ive some time now, but I don't have an ATI card :(
[18:21] <bschaefer> i've a large desktop I can install ubuntu on but it'll take a bit of time
[18:22] <kgunn> bschaefer: yeah....it'd be best to get access to didrocks machine
[18:22] <kgunn> but he's not on
[18:22] <kgunn> at least for the moment
[18:22] <bschaefer> dang and now hes gone...
[18:22] <bschaefer> kgunn, well I should have mentioned this acouple hours ago :)
[18:22] <kgunn> he might show back up
[18:23] <bschaefer> yeah, Ill try poking some QA people in the meantime
[18:23] <kgunn> cool
[18:24] <kgunn> tvoss_: robotfuel: do you know if there is someone else who might be able to provide us access besides didrocks to the ati machine failing to boot ??
[18:25] <tvoss_> kgunn, not sure, sil2100 might be able to help
[18:25] <robotfuel> I don't have access to the ati machine yet, jibel might?
[18:25] <robotfuel> kgunn: ^
[18:29] <kgunn> jibel: could you help us ?
[18:30] <bschaefer> kgunn, I think I found one
[18:31] <kgunn> sweet!
[18:31] <kgunn> bschaefer: i'm gonna break for lunch...
[18:31] <bschaefer> kgunn, cool, enjoy your lunch!
[18:50] <tvoss_> xjunior, hey there :)
[18:50] <tvoss_> xjunior, still busy debugging
[18:51] <xjunior> tvoss_: nice man :) good luck with that!!
[18:51] <xjunior> I believe it's a hard piece of code to debug
[18:51] <bschaefer> kgunn, yup, got access to a ati machine, thanks for the suggestion :)
[18:51] <tvoss_> xjunior, it is, raof is looking into it, too
[18:51] <xjunior> fortunately it's not Xorg :P
[18:52] <xjunior> I still can't get into Xorg, btw. I believe it's a intel driver issue. It's crashing and I remember it was updated a few days ago
[18:52] <tvoss_> xjunior, did you pin the ppa?
[18:53] <xjunior> yeap
[18:54] <bschaefer> xjunior, something like this: https://bugs.launchpad.net/xmir/+bug/1203776
[18:54] <tvoss_> xjunior, just to make sure: you have got the system-compositor-testing ppa?
[18:54]  * bschaefer was getting an intel crash on normal X as well this morning
[19:05] <racarr> I am trying to process the scene graph discussion email
[19:05] <xjunior> tvoss_: yea yeah, absolutely
[19:05] <xjunior> I guess that's what's happening to me :)
[19:06] <racarr> and I think what Alan is describing, and what I've started to see we need through some of the pain in resolving races like in session-transactions
[19:06] <racarr> is not actually a scene graph in...any particular sense
[19:07] <racarr> one of it's responsibilities (it's interface to the compositor) coincides with some of the responsibility of a scene graph
[19:07] <xjunior> That's exactly the situation I have here, tvoss_. I +1'd that bug
[19:07] <tvoss_> xjunior, thx
[19:08] <racarr> but it contains assosciations like session->surface, etc, which aren't actually 'scene' assosciations
[19:08] <racarr> I guess I feel like the problem we are trying to solve, is that we have dataa and state distributed over the system so we want to integrate it in to a single multi index store
[19:09] <racarr> and not
[19:09] <racarr> we need a "scene graph"
[19:10] <racarr> *trails off in to mumbling*
[19:10] <racarr> I am just thinking outloud :)
[19:14] <bschaefer> racarr, so your trying to come up with a data structure that can store all of the session/surfaces while having random access while having some sort of graph structure?
[19:14]  * bschaefer could have read that wrong
[19:16]  * bschaefer looks up scene graph...
[19:16] <bschaefer> which looks just like a B-Tree
[19:18] <bschaefer> but a bit crazier...
[19:19] <racarr> bschaefer: Hmm, thats probably part of the data structure. but I think finding a data structure once we know exactly what we need wont be so bad
[19:20] <racarr> I guess to me the thing is, state is distributed all over the system
[19:20] <racarr> i.e. the input state is held in some data structure that basically builds an input view of the surface stack
[19:20] <bschaefer> right, reading scene graph wiki was kind of funny: The definition of a scene graph is fuzzy
[19:21] <racarr> the shell bit with the session assosciation, and shell state lives in the shell, and acts as sort of another view/controller to the surface stack
[19:21] <bschaefer> isn't input in a different thread as well?
[19:21] <racarr> likewise, the compositor gets a view of the surface stack, and treats it like a scene graph
[19:21] <racarr> Right
[19:21] <racarr> so with all the state in different bits
[19:21] <racarr> synchronization gets
[19:21] <racarr> increasingly difficult
[19:21] <bschaefer> geez, thats going to be hard to get that all sync...
[19:21] <bschaefer> yeah
[19:21] <racarr> and, another thing is pretty much all state
[19:21] <racarr> changing in mir
[19:22] <racarr> needs to support some pattern like
[19:22] <racarr> notify the shell of this and potentially allow it to interfere, etc.
[19:22] <racarr> and without one authoratative source of...what is what when
[19:22] <racarr> this becomes kind of difficult and we've ended up with this weird pattern where the shell will do things like subclass one of our factory objects
[19:22] <bschaefer> you'll get lost...and out of order :(
[19:22] <racarr> and interfere and then call up to the base class
[19:23] <racarr> yeah
[19:24] <racarr> so that's what I am thinking about :p
[19:24] <bschaefer> that is an interesting problem to solve...
[19:24] <racarr> and we have always called this a scene graph, because at a very high level
[19:25] <racarr> a bunch of components manipulate it, then the compositor visits it to render the scene
[19:25] <racarr> well, at one very high level XD
[19:25] <bschaefer> yeah, that sounds like a fun problem that almost seems like it needs to be broken down a bit haha
[19:25] <racarr> but I think, "scene graph" doesn't actually capture the problem we are trying to solve
[19:25] <racarr> yeah
[19:26] <tvoss_> racarr, what you are describing is the mvc, isn't it?
[19:26] <bschaefer> well, i don't a single data structure can capture that...scene graph is pretty high level thats just a bunch of other graphs/trees
[19:27] <bschaefer> s/dont/dont think
[19:27] <racarr> tvoss_: Well...it's some kind of MVC right! But it has a very particular structure
[19:27] <racarr> and has to provide a few seperate views
[19:27] <racarr> and I think part of what it needs to do is
[19:27] <tvoss_> racarr, right, but mvc can account for that ;)
[19:28] <tvoss_> racarr, gerry is merely pointing out that we can leverage an existing implementatoin quite easily. and I do strongly agree with that
[19:28] <racarr> support some system of
[19:28] <tvoss_> most likely, the glue layer I'm mentioning in the mail will allow for querying the views (compositor, input, focus) that you have in mind
[19:28] <racarr> transactional/atomic operations
[19:29] <racarr> mm
[19:29] <racarr> but I guess I am saying that is the real problem at hand
[19:30] <racarr> and if we knew these interfaces
[19:30] <racarr> the data structure is entirely trivial
[19:31] <racarr> maybe Qt through OpenSceneGraph can help us on the rendering end
[19:31] <racarr> but that's closer to a view on this structure in the compositor not the structure itself I think
[19:32] <racarr> right I mean this is our central data store, not our "rendering pass optimizer"
[19:35] <racarr> I honestly still dont understand what it would mean though, using the qt scene graph
[19:35] <racarr> does it mean ms::Surface implements QSceneGraphItem?
[19:38] <racarr> Are we talking about just reusing their data structure? or using the renderer too?
[19:38] <racarr> I don't think it understands that each display element has its own opengl context that its children are drawn in
[19:39] <racarr> so I don't understand how that can be integrated with the compositor exactly
[19:40] <racarr>  / at all.
[19:40] <racarr> Sorry :) I don't mean to be negative
[19:40] <racarr> but I literally don't know what the first step towards doing this would be
[19:47] <kgunn> racarr: what is the first "it's" in "one of it's responsibilities (it's interface to the compositor) coincides with some of the responsibility of a scene graph"
[19:47] <kgunn> i/f to compositor ?
[19:49] <bschaefer> kgunn, hey, been rebooting this machine for a while now and xmir starts up each time :(
[19:49] <bschaefer> using : 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Caicos PRO [Radeon HD 7450]
[19:49]  * bschaefer keeps rebooting
[19:51] <kgunn> bschaefer: hmmm....didrock's was a Cedar series...which i think is Radeon HD 5000 series of gpu
[19:52] <bschaefer> kgunn, right, i should go check my desktop really quick...as if its a cedar series it might be worth getting xmir installed on it
[19:52] <kgunn> bschaefer: also..
[19:52] <kgunn> just thinking
[19:52] <kgunn> it wasn't so much the fact it was cedar series....
[19:52] <kgunn> the current theory of suscpicion was that
[19:53] <bschaefer> the power management?
[19:53] <kgunn> didrock's machine didn't have pm firmware installed
[19:53] <kgunn> right
[19:53] <bschaefer> yeah, hmm I wonder if I can uninstall that...
[19:53] <kgunn> so when the gfx driver tried to use hw cursor it couldn't
[19:53] <kgunn> ...and then got pissed
[19:53] <bschaefer> but you would think things would fail softly...
[19:53] <bschaefer> instead of bringing everything down
[19:53] <kgunn>  (that's U.S. pissed not U.K. pissed)
[19:53]  * bschaefer is from U.S
[19:53]  * bschaefer just learned there was a difference
[19:54] <bschaefer> kgunn, would you happen to know how to remove pm firmware?
[19:54] <kgunn> oh...thot you were in canada...and you never know which they favor with speech :) z==zee vs zed
[19:54] <kgunn> bschaefer: no ide
[19:54] <kgunn> idea
[19:54] <bschaefer> kgunn, haha yeah, from Seattle :)
[19:54] <bschaefer> close
[19:55] <bschaefer> kgunn, alright, well ill look into if thats even possible to remove, and if removing it should yield a working desktop or not
[19:56] <kgunn> bschaefer: kernel folk might know....
[19:56] <bschaefer> kgunn, would you happen to know a channel for that? When/if i get stuck at lease...
[19:57] <racarr> kgunn: This data structure that we are debating in the email thread
[19:57] <racarr> if I understood your question
[19:58] <racarr> that point was just supposed to say that while it mimicks a scene graph in one scenario
[19:58] <kgunn> bschaefer: took a guess...lots of people in #ubuntu-kernel
[19:58] <racarr> I dont think that's the right way to come at it
[19:58] <bschaefer> kgunn, great guess :), thanks!
[19:58] <kgunn> racarr: ack
[19:58] <kgunn> bschaefer: high five!
[19:58] <racarr> I mean in the most literal sense
[19:58]  * bschaefer high fives back
[19:59] <racarr> it could be called a graph of the scene
[19:59] <racarr> but it could also be called a list haha
[20:00] <racarr> so I am trying to find the right direction to zoom in on it from
[20:01] <kgunn> bschaefer: hmm, could it disabling the "APM" option referred to here be the trick http://how-to.wikia.com/wiki/How_to_configure_the_Linux_kernel/Power_management_options_(ACPI,_APM)
[20:02]  * bschaefer takes a look
[20:02] <bschaefer> possibly, I was thinking I could move the firmware/driver out of its dir in the kernel somewhere
[20:03] <kgunn> bschaefer: maybe...something easier first...
[20:03] <kgunn> duh
[20:03] <kgunn> why not change the xorg conf to just rely on sw cursor
[20:03] <bschaefer> hmm so right now its relying on the hw cursor?
[20:04]  * bschaefer looks at the xorg conf
[20:10] <kgunn> bschaefer: so i guess any xorg driver actually reads the xorg conf file....
[20:10] <kgunn> http://linux.die.net/man/4/radeon
[20:11] <kgunn> ?
[20:11]  * kgunn realizes how little he knows
[20:12] <bschaefer> kgunn, as do I :), im looking at turning some things off in the BIOS at first possibly that'll cause the firmware to not load?
[20:12] <bschaefer> kgunn, also the machine im on doesn't even have an xorg conf file
[20:13] <bschaefer> but I did fine a bunch of binary in the kernel that looked like it was dealing with power...but I have a feeling moving those will cause other problem s:)
[20:13] <bschaefer> kgunn, how did we come to the conclusion the we were missing pm firmware?
[20:14] <kgunn> mlankhorst saw dmesg's go by saying so
[20:14] <kgunn> bschaefer, but i think you should be able to simply add a xorg conf file with over-riding values for options
[20:15] <bschaefer> right, i need to look at those man pages :)
[20:15] <bschaefer> lots of things to read :)
[20:15] <kgunn> i only think this because of sna wiki (https://wiki.ubuntu.com/X/Testing/IntelSNA) where it talks about downloading their pre-formed version for sna
[20:19] <bschaefer> yeah you can add an xorg conf file... im just wondering why there wasnt one...
[20:20] <bschaefer> im also trying to wrap my head around why not having a pm firmware loaded would cause the hw cursor to not work
[20:24] <kgunn> on the pm part...hw cursor is actually a seperate piece of silicon, that requires to be "powered" up at some point, so something probably inside the hw mouse driver
[20:24] <kgunn> queried pm, it failed, so he failed..."sorry i ain't got no power"
[20:25] <bschaefer> that does make more sense, im waiting on this machine to do something
[20:38] <bschaefer> kgunn, sorry, seem to have broken to machine, hopefully I can get it up soon :)
[20:38] <kgunn> bschaefer: thanks for the effort
[20:38] <bschaefer> the machine*
[20:38] <kgunn> and the update
[20:38] <kgunn> :D
[20:38] <bschaefer> np, I guess you can't just disable all PM  and expect it to turn on :)
[20:44] <bschaefer> also forcing a SW wont help much atm, as im trying to reproduce the problem atm :)
[21:11] <bschaefer> alright, have the machine back...
[21:12] <xjunior> tvoss_: hey man, did have success
[21:12] <tvoss_> xjunior, how?
[21:13] <xjunior> any news on debugging the slowness on XMir
[21:14] <tvoss_> xjunior, ah, that was a question?
[21:14] <xjunior> yeah :) sorry
[21:15] <xjunior> I ate some words apparently
[21:15] <tvoss_> xjunior, no worries :) know the symptoms
[21:15] <tvoss_> so I have an instrumented build of X now, will give that a spin tomorrow. Its 11pm here :)
[21:18] <xjunior> oh, gotcha :) Europe?
[21:18] <tvoss_> xjunior, yup, Germany
[21:20] <xjunior> nice :) have friends there
[21:20] <kgunn> robert_ancell: so looks like the ati bug is the last hurdle (at least for universe)
[21:20] <xjunior> Alright, good luck tomorrow. Hope you solve it.
[21:20] <kgunn> robert_ancell: so some debug mlankhorst did that didrocks machine didn't have pm firmware installed...
[21:21] <mterry> robert_ancell, you asked about u8-greeter and running as mir server?
[21:21] <kgunn> so when hw cursor tried to init...it failed....and xmir didn't fall back to sw cursor
[21:21] <mterry> robert_ancell, I was thinking we wouldn't need to run as mir server anymore
[21:21] <kgunn> whereas standalone x does (or that is the assumption)
[21:22] <kgunn> robert_ancell: so bschaefer is in the midst of trying to "simulate" that problem...since didrocks is sleeping :) and we can't get to the machine
[21:23] <bschaefer> yeah, and so far xmir is working, sooo trying to remove pm firmware...but just got the broken machine back...
[21:23] <robert_ancell> mterry, I'm just getting LightDM to support Mir sessions/greeter with VT switching since we don't have nested Mir support yet. Just wondering if I can run the u8 greeter for now like that or support has been dropped
[21:23] <kgunn> robert_ancell: so i'm hoping this is either a bug or missing feature we have to fall back to sw cursor
[21:24] <robert_ancell> kgunn, who let didrocks go to sleep? ;)
[21:24] <kgunn> i know... right ?
[21:24] <robert_ancell> kgunn, yeah, wonder if it's just never been noticed because everything does the fallback
[21:24] <robert_ancell> seems like it should be fixed in the driver depending on how widespread it is
[21:25] <kgunn> robert_ancell: yeah...its one of those bugs that might have been lurking...also, just in case...didrock card was  a Cedar (5000 series)
[21:26] <kgunn> just in case....as in bschaefer is toying around on a 7000 series
[21:26] <bschaefer> it would be strange that a specific ATI card was doing this vs PM ... but what do i know haha
[21:27] <kgunn> robert_ancell: if you, duflu or RAOF have a 5000 series it might be worth it just to enable swcursor in xorg.conf and test it
[21:27] <bschaefer> they are under different classes though...
[21:27] <robert_ancell> kgunn, I just have the one intel/nvidia card
[21:27] <kgunn> it would at least help in confirm/deny
[21:27] <mterry> robert_ancell, my branch is still using an internal mir-server
[21:27] <bschaefer> im on a Caicos PRO
[21:27] <kgunn> that this whole issue is related to swcursor
[21:27] <mterry> robert_ancell, i.e. I haven't made it a pure client yet
[21:28] <robert_ancell> mterry, cool, can you keep it like that for testing purposes until we have the whole stack ready?
[21:28] <robert_ancell> or support both?
[21:28] <kgunn> mterry: now has 3 optional configs he needs to support :))
[21:29] <mterry> :)
[21:30] <mterry> robert_ancell, uh, I can keep my current split as is, yeah.  Let me know when you don't care about mir-server mode anymore
[21:30] <robert_ancell> mterry, will do :)
[21:37] <kgunn> robert_ancell: also...would you mind dispositioning the MIR feedback ? i think your best to speak to it
[21:37] <kgunn> robert_ancell: one note...for all the "need to assign a bug owner"
[21:38]  * robert_ancell looks up dispositioning
[21:38] <kgunn> olli chose mir-team for the moment :)
[21:38] <robert_ancell> kgunn, that works for now
[21:38] <kgunn> yeah...he promised to seek another victim...oops i mean owner
[21:39] <robert_ancell> wiktionary says "Present participle of disposition.". Now I have to remember what a present participle is :)
[21:39] <kdub> EventSink hitch-hikes through a lot of constructors
[21:40] <kgunn> :)
[21:40] <kgunn> robert_ancell: whenever RAOF or duflu come on, just check if they've got a cedar/5000 series ati card to try (w sw cursor).....since that bugs our #1 right now
[21:41] <robert_ancell> kgunn, ok
[21:47] <robert_ancell> mterry, oh, how did you remove the u-s-c task from the mir MIR?
[21:55] <mterry> robert_ancell, there's a little red minus symbol next to the tasks
[21:55] <robert_ancell> mterry, huh, I totally missed that
[21:57] <mterry> robert_ancell, way nicer than marking invalid in terms of bug spam
[21:57] <robert_ancell> yes
[22:08] <robert_ancell> mterry, in the MIRs you refer to needing a dev team subscribed to bug reports. Is that the "bug supervisor" in https://bugs.launchpad.net/mir?
[22:14] <mterry> robert_ancell, yeah, but for the ubuntu package side, not the upstream one
[22:15] <mterry> so ubuntu/+source/mir
[22:15] <robert_ancell> mterry, k
[22:15] <mterry> I guess that's mir-team
[22:16] <robert_ancell> mterry, so, Unity doesn't seem to have a subscriber https://bugs.launchpad.net/ubuntu/+source/unity
[22:22] <mterry> robert_ancell, that would be good to add too
[22:23] <mterry> robert_ancell, we didn't use to *require* it, only strongly suggest it
[22:23] <mterry> robert_ancell, but no one did it, so we are bumping up our language
[22:23] <robert_ancell> mterry, yeah, I'm trying to find *any* project that has a team subscribed to bug email
[22:24] <racarr> kdub: It's not strong coupling, all the classes are just really good friends and having a party.
[22:24] <racarr> :p
[22:25] <mterry> robert_ancell, most of the gnome desktop ones have a team subscribed
[22:25] <robert_ancell> the dialog for this is really bad. The list of teams is not sorted alphabetically
[22:28] <robert_ancell> and you can't seem to tell who is subscribed by looking at the project page
[22:42] <kdub> racarr, haha
[22:47] <robert_ancell> RAOF, did you see the traceback about cedar/5000 series ATI cards
[22:47] <RAOF> robert_ancell: I did, yes.
[22:47] <robert_ancell> RAOF, got any?
[22:47] <RAOF> I do not.
[22:48] <RAOF> I've got a 4535 or somesuch, and a 7870 that I don't have a desktop box to put into.
[22:48] <bschaefer> RAOF, i've been trying to reproduce it as well, on a 7450
[22:49] <bschaefer> but xmir is working perfectly
[22:50] <bschaefer> RAOF, it was mentioned that this could be due to the power management firmware missing, but it doesn't seem to be easy to just remove that to test if thats the problem...
[22:52] <RAOF> bschaefer: I don't know about that - on 3.11 kernels you need more firmware than we've got in linux-firmware to *load* radeon.ko, but (a) we're running a 3.10 kernel, and (b) Mir would fail in a different way if that were the case.
[22:54] <bschaefer> yeah... hmm I wonder if its the radeon family (as the 5000 is in the evergreen series) drivers then...
[22:54] <bschaefer> RAOF, shouldn't mir attempt to play nice when it can't load the HW cursor?
[22:54] <RAOF> Maybe? It currently doesn't, though.
[22:55] <bschaefer> well you would assume if this happens: std::exception::what: failed to create gbm buffer
[22:55] <bschaefer> no other gbm buffers are going to work...
[22:56] <RAOF> You know what? I should look in the xf86-video-ati source and see whether they have any specific hacks for that card & the hw cursor.
[22:56] <RAOF> Unfortunately, not. The hw cursor bo is super-specific - failing to allocate it doesn't mean that you'll fail to allocate anything else.
[22:57] <bschaefer> o hmm thats interesting
[22:57] <bschaefer> well im sure you've seen the list family for the ATI cards but: http://xorg.freedesktop.org/wiki/RadeonFeature/
[22:58] <bschaefer> as the card im using is under Nothern Islands...idk if that even matters though vs the driver is self for each card
[23:14] <RAOF> Isn't a 7450 SI? Stupid damned marketing department.
[23:16] <bschaefer> it should be, looking at the number but the machine im on gives me:
[23:16] <bschaefer> 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Caicos PRO [Radeon HD 7450]
[23:16] <bschaefer> which Caicos is a NI card...possibly the  PRO is throwing it off...
[23:17] <bschaefer> but looking here as well: http://wiki.gentoo.org/wiki/Radeon#Feature_support
[23:17] <bschaefer> and it  has the 7450 under NI
[23:18] <RAOF> Yeah, it the radeon page is probably right.
[23:18] <bschaefer> hmm my desktop that i've not used in a while had an evergreen card
[23:18] <RAOF> I just hate that the card marketing generation is not the same as the card chip generation.
[23:18] <bschaefer> a redwood one
[23:19]  * bschaefer starts downloading13.10
[23:19] <RAOF> I've got an evergreen (although I can't quite remember the specific model) too, but that worked fine last time I tried it.
[23:19]  * RAOF will be slow for the next hour or so, as he's minding Zoë.
[23:20] <bschaefer> well it'll take  a bit for me to get my desktop up with xmir.. 1-2 hours...
[23:20] <bschaefer> it'll be strange if its just specific to CEDAR
[23:21] <bschaefer> but then again this could be normal, as I haven't done video card stuff much before :)
[23:22] <bschaefer> hopefully duflu will come on a reproduce the problem
[23:22] <bschaefer> and*
[23:44] <RAOF> Hey, is there any way to get a buffer ID that crosses the IPC boundary? I want to check that the buffer I most recently submitted from XMir is *really* the buffer that Mir's displaying.
[23:48] <olli_> bregma, can you pls ping the relevant armhf issues to slangasek?
[23:48] <olli_> or robert_ancell ^
[23:52] <kgunn> RAOF: ok....any guesses on why robotfuel might see openarena values higher on Xmir vs X ?
[23:52] <kgunn> kgunn: the results are still strange with the monitor attached x is 44.47  frames per second average and xmir is 136.97
[23:53] <kgunn> is it because there's no governing ?
[23:53] <kgunn> e.g. no more vsync on the bottom of x (moved to the bottom of mir)
[23:53] <kgunn> robotfuel might take a trained eye....but do you see any tearing ?
[23:54] <RAOF> vsync would be my immediate guess
[23:54] <robert_ancell> kdub, around?
[23:54] <kdub> yep
[23:54] <RAOF> XMir clients are *not* throttled to vsync
[23:55] <robert_ancell> kdub, I've just forwarded you an email regarding armhf tests and android. Perhaps you can help understand what lp:mir expects and what is happening
[23:56] <kdub> sure
[23:56] <kgunn> robotfuel: does it also provide time to complete ?....and is that different on x vs xmir ? (ignoring the fps for moment)
[23:56] <kgunn> RAOF: right...so clients can go nuts and swap buffers as they like...which means, the truly displayed frames is much less than that
[23:57] <kgunn> or "allegedly" is much less than that :)