[00:27] <racarr> robert_ancell: I think it just exposes less implementation detail
[00:27] <racarr> I mean it's just a lock in implementation right, but the interface to the clients
[00:28] <racarr> is "perform these operations atomically"
[00:29] <racarr> and yes, what did my emacs do?
[00:58] <robert_ancell> racarr, + // from a second thread before input focus is set.xs
[00:58] <robert_ancell> think you missed hitting ctrl there
[01:27] <racarr> True!
[01:29] <racarr> thanks :) fixed in r858
[02:59] <duflu> Woo... another morning of just fixing conflicts
[03:39] <duflu> robert_ancell: ping
[03:40] <robert_ancell> duflu, yep
[03:40] <duflu> robert_ancell: You mentioned that shortened versions was a possibility: major.minor only
[03:40] <duflu> I think I agree with that...
[03:40] <duflu> So long as no one complains that we change major a lot
[03:40] <robert_ancell> duflu, for the project?
[03:41] <duflu> Yes
[03:41] <robert_ancell> duflu, yeah, I like it too. The second number is only incremented if we branch, so for most purposes we only have one number
[03:42] <duflu> robert_ancell: Or rather the second number represents fixes that don't affect ABI
[03:42] <duflu> ... ?
[03:43] <robert_ancell> duflu, then you can't do branches. i.e. if we release Mir 94 in saucy, then we need to fix it, we need version 94.1 because in t-series we'll be on (say) 113
[03:43] <robert_ancell> So the version become <version>.<branch-version>
[03:46] <duflu> robert_ancell: I don't understand the problem. Once saucy is released as N.M, it will get updates N.(M+1). T-series is the only distro that will get (N+1)
[03:48] <duflu> Just like we do for Unity releases...
[03:48] <robert_ancell> duflu, so what do we do if we release 1.2 in saucy and 1.3 in t-series then need to make a patch to saucy?
[03:49] <robert_ancell> we can't go 1.3 because that would collide with a newer version. Then we'd have to do 1.2.1
[03:50] <duflu> robert_ancell: There's no problem if each new distro gets a major rev
[03:50] <duflu> Numbers are cheap
[03:50] <robert_ancell> yes they are
[03:51] <robert_ancell> but there's no need to unnecessarily break ABI every single release which is what this scheme would do
[03:51] <duflu> ... so it would be 1.2 in saucy (up to 1.X in updates), and 2.Y in T
[03:52] <duflu> And _eventually_ when the ABI stabilizes, we could stay on the same major and branch to 3 components
[03:53] <duflu> All the while ABI == major == a single integer
[03:53] <robert_ancell> there's no need to combine the project version and the three (for the moment) ABIs together into one number
[03:53] <robert_ancell> it just creates unnecessary work
[03:55] <duflu> robert_ancell: That's kind of true. But it does create clarity.... Alternatively, see my latest MP comments
[04:03] <robert_ancell> duflu, I have to go but I updated both MPs
[05:08] <tvoss_> good morning :)
[05:08] <tvoss_> RAOF, ping
[05:33] <duflu> Morning tvoss_
[06:18] <tvoss_> mlankhorst, RAOF  in case you are around: I noticed that SNA is not enabled by default in the XMir drivers. Is that by accident or on purpose?
[06:25] <didrocks> tvoss_: hey, ar you going to push today the disable armhf android tests?
[06:25] <didrocks> are*
[06:26] <tvoss_> didrocks, sure, I assumed you had done it already, happy to do it, though
[06:26] <tvoss_> alf_, mind if I set https://bugs.launchpad.net/mir/+bug/1102760 to in-progress?
[06:26] <ubot5> Launchpad bug 1102760 in Mir "Multi-monitor support incomplete - can't show different images on each screen" [Critical,Triaged]
[06:26] <didrocks> tvoss_: ah, sorry, I'm more trying to decipher the race right now
[06:26] <alf_> tvoss_: sure
[06:26] <didrocks> tvoss_: .1 doesn't seem enough though, just had a case where it's not enough
[06:26] <tvoss_> alf_, the correct answer is nope :)
[06:27]  * didrocks will try .5 and give several try to it
=== 65MAANWI2 is now known as tvoss
[06:30] <didrocks> tvoss: if you want, I can disable all tests, but I thought you wanted to be more fine grain and I don't know ctest
[06:30] <tvoss> didrocks, let me see what I can do :)
[07:15] <RAOF> tvoss: Um, that would be by accident.
[07:15]  * RAOF checks the packaging branches.
[07:16] <tvoss> RAOF, I have a custom /etc/X11/xorg.conf to enable sna
[07:22] <tvoss> didrocks, https://code.launchpad.net/~thomas-voss/mir/disable_acceptance_integration_tests_on_armhf/+merge/175746
[07:25] <tvoss> RAOF, alan_g|EOD you might want to have a look, too: https://code.launchpad.net/~thomas-voss/mir/disable_acceptance_integration_tests_on_armhf/+merge/175746
[07:29] <didrocks> tvoss: approved
[07:29] <didrocks> thanks!
[07:29] <didrocks> tvoss: I may need to extend the sleep to .5s FYI
[07:29] <didrocks> just ensuring that all the runs pass
[07:29] <tvoss> didrocks, not sure if that is enough, we might need to disable unit tests too
[07:29] <didrocks> (by priority to dailies to finish tests)
[07:29] <tvoss> so let's see what the builders say
[07:30] <didrocks> tvoss: ok, I'll rerun a mir build once merged, ok?
[07:30] <tvoss> didrocks, ack
[07:30] <RAOF> Hm. Why is it defaulting to UXA? The packaging branch clearly defaults to sna.
[07:37] <tvoss> RAOF, can you reproduce defaulting to UXA locally?
[07:58] <didrocks> RAOF: on ati, we have another issue in fact making unity-system-compositor segfaulting
[07:58] <didrocks> RAOF: libEGL warning: Could not open driver /usr/lib/i386-linux-gnu/egl/egl_gallium.so (libOpenVG.so.1: cannot open shared object
[07:58] <didrocks> file: No such file or directory)
[07:58] <RAOF> didrocks: Oooh, really?
[07:58] <RAOF> That's odd.
[07:58] <RAOF> I clearly had libOpenVG installed.
[07:58] <didrocks> RAOF: so, we should install libopenvg1-mesa I think
[07:58] <RAOF> Yeah.
[07:59] <didrocks> RAOF: but maybe the deps don't take it
[07:59] <didrocks> let me see
[07:59] <RAOF> Actually, that shouldn't be fatal; I think it should go on and load egl_dri2.so
[08:01] <didrocks> RAOF: so libegl1-mesa:i386                         9.2~git20130628.g6b676e6-0ubuntu0+mir4-jenkins86saucy0
[08:01] <didrocks> but libopenvg1-mesa:i386                      9.1.4-0ubuntu3
[08:01] <didrocks> RAOF: weird that shlibdeps doesn't force the latest version
[08:01] <didrocks> RAOF: we need libopenvg1-mesa from the ppa, right?
[08:02] <RAOF> We shouldn't, no.
[08:02] <RAOF> libopenvg1-mesa is installed, then?
[08:03] <didrocks> RAOF: right, but not the version from the ppa
[08:04] <didrocks> (you didn't list it in the things to upgrade)
[08:04] <didrocks> can the ABI has changed?
[08:04] <RAOF> Yeah, I didn't expect it to be necessary; libopenvg should have a fixed ABI.
[08:04] <didrocks> RAOF: as soon as the slot is free, I'll retry forcing the upgrade to latest
[08:05] <didrocks> I was thinking it was the race again, but longer timeout needed on ati
[08:05] <didrocks> but not the case :)
[08:05] <RAOF> didrocks: Yeah, thanks. I'm surprised. Looks like this might be a libegl1-mesa-drivers bug (lack of appropriate depends: on libopenvg1-mesa)
[08:05] <didrocks> RAOF: sounds likely the cause, will keep you posted (I think the slot will be free in 10 minutes
[08:05] <didrocks> )
[08:07] <RAOF> Test-building patch series to ensure they build at each commit is annoying.
[08:12] <didrocks> RAOF: ok, now we get:
[08:12] <didrocks> ERROR: /build/buildd/mir-0.0.7+13.10.20130719ubuntu.unity.next/src/server/graphics/gbm/gbm_cursor.cpp(46): Throw in function mir::graphics::gbm::GBMCursor::GBMBOWrapper::GBMBOWrapper(mir::graphics::gbm::GBMPlatform&)
[08:12] <didrocks> Dynamic exception type: boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<std::runtime_error> >
[08:12] <didrocks> std::exception::what: failed to create gbm buffer
[08:20] <RAOF> didrocks: Hm. What platform is that?
[08:20] <RAOF> didrocks: Obviously it's ATI, but what chipset?
[08:20] <didrocks> RAOF: 05:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Cedar [Radeon HD 5000/6000/7350/8350 Series]
=== alan_g|EOD is now known as alan_g
[08:20] <didrocks> RAOF: do you want a ssh access to the machine?
[08:21] <RAOF> didrocks: Sure, why not.
[08:21] <didrocks> RAOF: prefered ssh public key? ;)
[08:21] <RAOF> From launchpad?
[08:21] <didrocks> oui have 2!
[08:22] <didrocks> seems you are someone who can't decide! ;-)
[08:22] <RAOF> chris@Ed
[08:22] <didrocks> ok, grabbing that one :)
[08:58] <alf_> duflu: alan_g: @remove-graphics-viewable-area, my concern about using *Region is that "Region" has a particular meaning in graphics (an arbitrary collection of pixels) and we are not providing any related operations
[08:58] <duflu> alf_: Maybe so, but I feel it's closer. So another word... ?
[08:58]  * duflu reserves the right to not think with so little time left in the week
[08:59] <alan_g> alf_: duflu: with members "clip_to_screen" and "make_fullscreen" I have a feeling that "screens" might be part of the role/name
[09:00] <alf_> alan_g: perhaps we should not have *Boundaries/Regions, but completely different names for the too interfaces
[09:00] <alf_> s/too/two/g
[09:00] <alan_g> ScreenLayout?
[09:00] <duflu> alf_: I think Region is most accurate. Qualify it as FooRegion if you like. The word "Boundaries" makes me imagine a set of lines in space, where the line equations are most important, rather than their contents
[09:01] <alf_> duflu: that was the intention, the boundaries are important, not the contents for these interfaces
[09:01] <duflu> Desktop?
[09:02] <duflu> A "Desktop" is the set of all displays rectangles...
[09:03] <alan_g> My "desktop" is the thing that holds up tea, monitors, paper and pens...
[09:04] <duflu> desktop->clean(later)
[09:04] <alan_g> ;)
[09:06] <duflu> People generally understand "is it on the desktop", and the concept extends to multiple monitors per desktop
[09:07] <duflu> If you want to steal X/Compiz terminology then it's a "Screen", but that's confusing terminology when "Screen" encompasses multiple monitors
[09:08] <duflu> Although, arguably, the desktop could be transformed to take up less than the monitor :P
[09:09] <alan_g> Should we avoid using "screen" then and use, say, "output"
[09:09] <alf_> alan_g: duflu: I think that the Input(Coordinate?)Boundaries interface makes sense from the input subsystem's (the consumer's) perspective.
[09:10] <alf_> alan_g: duflu: I am not completely happy with SurfaceBoundaries, give the actual operations that it has, as Alan pointed out.
[09:11] <duflu> I would still hope for a name that describes the area/region, rather than just its edges
[09:11] <duflu> Area?
[09:13] <alan_g> DisplayMap ... clip_to_display()
[09:15] <duflu> Map has become an overloaded word, methinks
[09:19] <tvoss_> woot, not a single gpu hang with sna after bios upgrade on x220 while running a complete phoronix test suite
[09:20] <duflu> tvoss_: There's a new BIOS? Or you were out of date?
[09:20] <tvoss_> duflu, bios is from May 2013
[09:21] <duflu> tvoss_: All other possible variables eliminated? :)
[09:21] <tvoss_> duflu, yes, I'm staring at this for quite some time now ;)
[09:23] <duflu> tvoss_: Oh, I seem to have installed that BIOS already. No wonder mine has worked... (?)
[09:23] <tvoss_> duflu, I was actually down to inspecting individual registers of the gpu
[09:23] <duflu> Eek
[09:25] <tvoss_> duflu, but: intel_gpu_top is really an awesome tool
=== tvoss_ is now known as tvoss|benchmark_
[09:34] <alf_> alan_g: duflu: OK, so how about, InputRegion::bounding_rectangle(), InputRegion::confine(Point) and DisplayOutputLayout::clip_to_output() DisplayOutputLayout::make_fullscreen()/resize_to_output()
[09:34] <duflu> alf_: Sounds reasonable
[09:35] <duflu> Though I'm not sure what a "Layout" is. Didn't get that far
[09:35] <duflu> If you make the change soon, I will abstain on it
[09:35] <alan_g> "size_to_output()"?
[09:36] <alan_g> DisplayOutputLayout seems a bit wordy
[09:36] <alf_> alan_g: DisplayLayout?
[09:37] <alan_g> DisplayArea?
[09:37] <duflu> Oh. Yes it was so wordy I didn't understand "DisplayOutputLayout". I did understand "DisplayLayout" (or would "OutputLayout")
[09:38] <alan_g> DisplayLayout would be OK
[09:38] <alan_g> OutputRegion?
[09:39] <alan_g> If it works for input, then why not for output?
[09:42] <alf_> alan_g: I don't think that DisplayArea/OutputRegion communicate that there are multiple outputs. InputRegion doesn't care about that (yet). Which brings up another point, that these interfaces may need to change names as the needs of shell/input change. This is just a first cut.
[09:42] <alan_g> DisplayLayout would be OK
[09:46] <alf_> alan_g: duflu: ok, so it's InputRegion and DisplayLayout (although I still think *Boundaries makes sense, since all these operations are about clipping/checking against/sizing to some boundary)
[09:46] <duflu> alf_: OK. Please resubmit so I don't have to do any more reviews today :)
[09:47] <duflu> ... so that it's at least not blocked on me
[09:47] <alan_g> alf_: Something can have boundaries without being named for them
[09:47] <alf_> duflu: Feel free to pre-abstain :)
[09:50] <alf_> alan_g: Sure, but as I mentioned above, in this case the boundaries are more important than that something in terms of what the consumer needs. Anyway, I think both approaches are reasonable, so I am not fussed :)
[09:52] <didrocks> tvoss|benchmark_: that wasn't enough: https://launchpadlibrarian.net/145330493/buildlog_ubuntu-saucy-armhf.mir_0.0.7%2B13.10.20130719.1ubuntu.unity.next-0ubuntu1_FAILEDTOBUILD.txt.gz
[09:52] <didrocks> tvoss|benchmark_: at least, it doesn't hang, but unit-tests are segfaulting
[09:57] <didrocks> tvoss|benchmark_: duflu: alf_: any of you wanting to ack https://code.launchpad.net/~didrocks/mir/disable-unit-armh-tests/+merge/175786?
[09:58] <didrocks> as per discussion, we disable the tests right now, then before a week pass by, tvoss|benchmark_ promised to work on them again (with some platform-api trick)
[09:58] <duflu> didrocks: Nothing to see yet :)
[09:58] <didrocks> duflu: click on the commit :p
[09:58] <duflu> Also.. don't we usually fix failing tests?
[09:59] <didrocks> duflu: well, it's been 3 weeks they are failing and preventing us for pushing mir
[09:59] <tvoss|benchmark_> didrocks, +1
[09:59] <didrocks> duflu: so no, you don't usually fix failing tests ;)
[09:59] <didrocks> thanks tvoss|benchmark_! I'll rerun a build again once merged
[10:00] <didrocks> duflu: so the new deal is "no mir by default until this is fixed"
[10:00] <didrocks> btw, let me add that on the spreadsheet
=== tvoss|benchmark_ is now known as tvoss_
[10:01] <didrocks> tvoss_: mind approving? (not tvoss|benchmark*ed* now? ;))
[10:03] <duflu> didrocks: I will let the western hemisphere decide. I need to start winding up...
[10:03] <didrocks> duflu: enjoy your week-end!
[10:03] <tvoss_> didrocks, want a happrovie?
[10:03] <didrocks> tvoss_: I would love one! :)
[10:04] <tvoss_> didrocks, there you are
[10:05] <didrocks> thanks!
[10:08]  * duflu also means Greece and Germany even though they're not in the western hemisphere
[10:09] <duflu> Bah, details
[10:14] <tvoss_> didrocks, https://bugs.launchpad.net/platform-api/+bug/1203003
[10:14] <ubot5> Launchpad bug 1203003 in platform-api "The platform api should offer an init method that resolves all required symbols and indicates whether the platform is available or not" [Critical,New]
[10:14] <didrocks> tvoss_: sounds like the right strategy, thanks!
[10:16] <tvoss_> didrocks, https://bugs.launchpad.net/mir/+bug/1203004
[10:16] <ubot5> Launchpad bug 1203004 in Mir "Tests disabled on armhf" [Critical,New]
=== om26er is now known as om26er|away
=== om26er|away is now known as om26er
[11:46] <didrocks> tvoss_: mir built on armhf
[11:46] <tvoss_> didrocks, \o/
[11:46] <didrocks> time for unity-system-compositor ;)
[11:46] <tvoss_> didrocks, \o/
[11:46] <didrocks> heh ;)
=== alan_g is now known as alan_g|lunch
=== alan_g|lunch is now known as alan_g
[13:24] <robotfuel> kgunn: we have a saucy version of the ihv tests now http://certification-static.canonical.com/checkbox-ihv/
[13:28] <kgunn> robotfuel: hey thanks
[13:29] <robotfuel> kgunn: I'll run that on some of the systems today in the lexington lab
[13:30] <kgunn> robotfuel: good stuff & checkbox is single sign on right? so anyone could run their machine?
[13:32] <robotfuel> kgunn: I think the machine has to be added to hexr first to show up on c3, but anyone can run checkbox and view the results locally. it also produces an xls spreadsheet of the results.
[13:33] <robotfuel> kgunn: with the ihv tests there is no need for a network connection
[13:35] <robotfuel> kgunn: to run it you unpack the tarball cd in to the checkbox-ihv directory then run start_testing
[13:35] <robotfuel> kgunn: it installs all the required packages and runs checkbox's graphics tests
=== mpt_ is now known as mpt
=== alan_g is now known as alan_g|tea
=== alan_g|tea is now known as alan_g
=== om26er is now known as om26er|afk
=== bschaefer_ is now known as bschaefer
=== om26er|afk is now known as om26er
[19:03]  * kdub is tempted to just keep overriding MirEvent for sending messages to client
[19:03] <kdub> but thats probably already overridden too much
[19:16] <racarr> kdub: I think so! I wish we didn't use it at all
[19:16] <racarr> for sending messages to the client
[19:16] <racarr> kdub: The thing is, most messages to the client
[19:16] <racarr> will eventually need some sort of subscription mask
[19:17] <racarr> well maybe not :p
[19:17] <racarr> but I think a lot do, like, the client can "subscribe" to display changes
[19:17] <racarr> and this way, I think rather than use the mechanism we do now of the MirEvent, which is sort of half out of band
[19:18] <racarr> to our protobuf IRC, even though it is
[19:18] <racarr> on the same socket
[19:18] <racarr> we can model it as a call
[19:18] <racarr> with multiple responses
[19:19] <racarr> and then on the client side, I think using
[19:19] <racarr> more fine grained delegates, i.e. handle_input(MirEvent), handle_display_changed(information), handle_focus_lost
[19:19] <racarr> etc. is just good loose coupling
[19:20] <racarr> even though we don't have many events to the client so far
[19:20] <racarr> it already causes noise in some of the tests
[19:20] <racarr> where for example, a test which wants to match client input events
[19:20] <racarr> i.e. "this client gets an A key"
[19:21] <racarr> has to either mute, or expect, irrelevant events like
[19:21] <racarr> got Focus, lost focus (because it's a 3 client test)
[19:21] <racarr> or maybe later like, display changed!
[19:22] <racarr> and then, what is qtubuntu going to do?
[19:22] <racarr> qtubuntu_handle_input(Event) switch(event->type) case mouse_event: qtubuntu_handle_mouse_event, case key_event: bla bla. case surface_configuration_event: switch event->surface->attrib...
[19:23] <racarr> blablabla
[19:23] <racarr> so I think we should just have
[19:23] <racarr> seperate delegates
[19:33] <kgunn> kdub: i think i know why someone did it...but isn't there another way we could flip buffers on our mir gl rendering ?
[19:33] <kgunn> other than glreadpixels
[19:33] <kgunn> glreadpixels not good for deferred arch's....it makes you wait for the entire pipe to finish rendering
[19:34] <kgunn> when, you could run away and do more stuff
[19:34] <kgunn> also...there is some overlap in processing on the gpu that can be gained (not just the exploiting the cpu side of things)
[19:35] <kgunn> on a deferred mode arch....you can processing geometry & stuff...of the next frame, while your rendering out the previous frame
[19:35] <kgunn> thots ?
[19:35] <kgunn> tvoss_ was seeing some perf hits on galaxynexus with unity8....and i was poking around and noticed that we're doing glreadpixels
[19:36] <Stskeeps> [21:33] <kgunn> kdub: i think i know why someone did it...but isn't there another way we could flip buffers on our mir gl rendering ?
[19:36] <Stskeeps> err..
[19:36] <Stskeeps> sorry, slippage of the mouse
[19:37] <Stskeeps> (kid on my arm, ..)
[19:39] <kgunn> kdub: tvoss_ http://forum.imgtec.com/discussion/comment/7821#Comment_7821
[19:42] <racarr> Where are we doing
[19:42] <racarr> glReadPixels!
[19:42] <racarr> besides the snapshot functionality.
[19:44] <kgunn> racarr: hmmm...now you're making me wonder if i know what i'm talking about :)
[19:44] <kgunn> maybe that's where it is
[19:45] <kgunn> gl_pixel_buffer.cpp
[19:46] <racarr> kgunn: I think it's only for snapshots
[19:46] <racarr> 90% confidence index ;)
[19:46] <kgunn> racarr: thanks...i'll poke a bit more to ensure
[19:47] <racarr> I heard about some galaxy nexus performance problems though
[19:47] <racarr> so I guess something is going on
[19:47] <kgunn> racarr: it does make sense tho now that you say it....there's a bunch of copying etc going on
[19:48] <kgunn> racarr: yeah...i don't think anyone has tried demo shell on nexus4 (if you were feeling  jumpy :)
[19:48] <racarr> I did last week when it didn't really do anything
[19:48] <racarr> and it was fine
[19:48] <kgunn> racarr: and yeah...i know way too many little bastard issues on omap4460
[19:48] <racarr> I will try again soon ;)
[19:48] <kgunn> to really worry too much
[19:48] <racarr> kind of fell out of sync with gerry this week because I missed thursday morning and was distracted by the stress-test wednesday morning
[19:49] <kgunn> racarr: did you launch an app ? and if so, any perf delta appearant ?
[19:49] <kgunn> racarr: he mainly bug fixed and put quality goodness into app management
[19:49] <kgunn> so the ui perf prob wouldn't have changed much
[19:50] <racarr> It wasn't apparent on nexus 4 or desktop
[19:50] <racarr> but I also didn't really push it XD
[19:50] <racarr> at the time it was like "ok lets figure out why nothing shows up on screen..."
[19:50] <racarr> *hours of furious recompiling*
[19:50] <kgunn> greyback: ^
[19:50] <racarr> "Yay it shows up on screen! *flicks aimlessly for a minute*
[19:50] <racarr> :p
[19:50] <kgunn> wrt nexus 4
[19:52] <kgunn> greyback: in case you read scrollback...would be interesting to know...how often you're doing snapshot for apps
[19:53] <kgunn> that could be a very bad thing (glreadpixels + a copy)
[20:11] <kdub> kgunn, there is another way
[20:11] <kdub> (sorry for the delay, was eating lunch)
[20:12] <MichaelP> when Mir is shiped with the next release. How is it going to be with ati proprietary drivers ?
[20:12] <kdub> kgunn, nexus4 has similar problems with long glReadPixels performance
[20:26] <racarr> "There are only two hard things in Computer Science: cache invalidation and naming things."
[20:26] <racarr> haha, I feel like this speaks to our
[20:27] <racarr> scenegraph/synchronization data store topic *waves hands*
[20:29] <kdub> hah
[20:31] <kgunn> kdub: so that glreadpixels is your trigger for flipping ? or rather is it just for snapshot support (in which case this is ok)....and i tend to agree with racarr that's what this is
[20:32] <kgunn> enlighten if i'm wrong
[20:32] <kdub> kgunn, i'm unsure what the question means
[20:33] <kgunn> kdub: sorry...i am refering to the use of glreadpixels in the code
[20:33] <kgunn> i am thinking its only relevant to when a shell client wants a snaphot
[20:33] <kgunn> (e.g. it shouldn;t be called every frame)
[20:33] <kdub> right, of course
[20:33] <kdub> the normal render pass does not hit that function
[20:34] <kgunn> MichaelP: in 13.10 we would be delighted to see proprietary driver support appear from the various vendors
[20:34] <kgunn> but that's not ours to promise
[20:36] <MichaelP> kgunn: yeah i know.. distro's like arch you either have to downgrade xorg or use ati beta drivers...
[20:37] <MichaelP> now whats mir supose to do that xorg don't ?
[20:38] <kgunn> MichaelP: be younger :)
[20:38] <kgunn> seriously though....that's one part
[20:39] <kgunn> being a bit more focused w/o legacy of decades of special interest add-ons will help maintainability
[20:39] <MichaelP> Sometimes younger is dummer !!lol
[20:39] <kgunn> and this is all a journey
[20:39] <kgunn> if you ask what xmir will do...nothing
[20:39] <kgunn> its about a conservative step of introducing mir into distro, yet with real road miles on it
[20:40] <kgunn> its easy to keep designing, tweaking, etc...but maturity cannot be delivered like a feature
[20:41] <racarr> One thing that mir is supposed to do that X doesn't is make sense from the ground up :p
[20:41] <kgunn> like Orsen Wells said of Paul Masson wine (and if you don't know what that is...then you're the younger of us ;)
[20:41] <racarr> and shine some sense up the whole stack, as opposed to
[20:42] <racarr> pushing nonsense and hacks up the whole stack :p
[20:42] <MichaelP> from what i was reading on google about mir.. was sound like with in the next few releases of other distro's everyone eles wants to switch to wayland
[20:43] <kgunn> MichaelP: can't learn everything from reading
[20:43] <MichaelP> Im downloading 13.10 right now to check it out
[20:44] <kgunn> MichaelP: awesome!
[20:44] <MichaelP> kubuntu said kwin doesn't support mir
[20:44] <kgunn> MichaelP: i heard that too...
[20:45] <kgunn> the beauty of open source...
[20:45] <kgunn> MichaelP: another thing i think mir is bringing beyond xorg
[20:45] <MichaelP> But yet i watched a video on google.. with unity.. gnome shell.. kde xcfe useing mir
[20:46] <kgunn> is that its been built around having an answer on mobile & desktop...
[20:46] <racarr> xmir :)
[20:46] <kgunn> using android drivers and then of course mesa
[20:47] <kgunn> another big decision is server side alloc'd buffers
[20:48] <MichaelP> I have trouble with the free ati drivers... i use HP laptop... then to watch music video's i plug into my hdmi tv.. So if im in like say gnome.. i have trouble sizing the screen.. on the hdmi
[21:13] <kdub> racarr, why do input and events come back to the clients with the same callback?
[21:14] <kdub> is it driven by convenience or necessity? :)
[21:49] <racarr> kdub: That's what I was talking about earlier
[21:49] <racarr> I think it
[21:49] <racarr> 's wrong
[21:52] <racarr> kdub: If you look 2.5 hours up in scrollback
[21:52] <racarr> I wrote a bunch on it
[22:14] <kdub> racarr, ah
[23:55]  * racarr sets clock ahead 5 minutes
[23:55]  * racarr beer top flies with a *clang*