[01:04] <kdub> hey duflu, I wanted to sync with you on adding overlay support to the compositor
[01:05] <kdub> pretty much, my plan is to have the platform provide a 'filter' for the scene that will skip GL composition on a surface if the hardware can handle composing that surface
[01:07] <kdub> so, if the platform can bypass or overlay-composite any given buffer, it simply tells the compositor to skip rendering that surface with GL
[01:07] <duflu> kdub: Sounds about right. Although all the "filter" code will be replaced by Q*
[01:07] <kdub> right, i pinged greyback about it, he seemed optimistic that it can be worked into the qt scenegraph
[01:09] <duflu> kdub: Could be a generalization of BypassFilter, in a way. We just have to remember that if/when Q* take over the scene graph to ensure there's a working Qt replacement
[01:11] <kdub> right, just like a 'hardware optimization filter'
[01:12] <kdub> greyback said it wouldn't be too hard to integrate a 'skip rendering these layers' into his work, so hopefully the bypass filter and this overlay work will mesh nicely with that
[01:16] <duflu> kdub: Before we add yet more filters, I had planned on tidying up and getting back to only having a single surface class passed around filters/renderers.
[01:16] <kdub> duflu, yeah, part of the work that will need to be done is cleaning up the filter/operators on the SurfaceStack
[01:16] <kdub> i don't know that the model we have makes sense anymore, with the way we're using it these days
[01:17] <duflu> kdub: I'm not committing to a particular class or name. Just that it became obvious to me there's so much coupling on the filter/operators that it would make more sense to refer to just something::Surfacelike instead. A single interface
[01:19] <kdub> perhaps, i haven't really felt out what I like best yet... just that it is pretty coupled
[01:23] <duflu> kdub: I think it could be dangerous to be specific about the interface. It needs to be a general Surface-like interface to encompass CompositingCriteria, Renderable (buffer acquisition), flagging for overlay/bypass/etc
[01:23] <duflu> That all fits into some kind of Surface interface I think. If we're lucky, an existing one
[01:24] <duflu> Hmm, maybe it would be the reintroduction of a "Renderable"
[01:25] <kdub> got a bit lost
[01:27] <kdub> we'll probably hash all that out next week though :)
[01:30] <duflu> Yes. Oh look; final confirmation.
[01:41] <kdub> yeah, should be a fun long flight
[01:50] <duflu> Actually, significantly shorter than Boston :)
[01:53] <truebattleaxe> i've lost my volume control and ability to vol + and - with the keyboard. is there a fix for this
[01:54] <truebattleaxe> this happened when i installed mir
[01:58] <duflu_> truebattleaxe: Not sure. That's odd because XMir does not affect input or sound. Those are unchanged to regular X
[01:58] <duflu_> truebattleaxe: Try uninstalling Mir and make sure the problem goes away. Otherwise it's somewhere else :)
[01:59] <truebattleaxe> hmm maybe its just how i installed kde
[01:59] <truebattleaxe> is there any way to update mir? or see if there are updates
[02:00] <duflu_> truebattleaxe: it's just in normal Ubuntu updates
=== duflu_ is now known as duflu
[02:01] <truebattleaxe> gotcha. i did uninstall ubuntu software manager and center. i have noticed its probably just muon but for some reason it doesn't get root access
[02:03] <duflu> truebattleaxe: sudo apt-get update ; sudo apt-get upgrade
[02:04] <duflu> Will do a regular update (including Mir)
[02:04] <truebattleaxe> doing that now. just wondering if thats normal with muon. to get the error of no root access
[02:05] <truebattleaxe> how often is mir getting updated right now?
[02:06] <duflu> truebattleaxe: On 14.04 every couple of weeks. On 13.10, not at all. (https://launchpad.net/ubuntu/+source/mir)
[02:06] <truebattleaxe> gotcha. im on 14.04 so that is definitely good to hear
[02:07] <duflu> truebattleaxe: But XMir does not use Mir input. And Mir has nothing to do with sound. So you should probably search for other causes/solutions
[02:10] <truebattleaxe> i think i may have uninstalled the sound manager some how.
[02:11] <truebattleaxe> thanks duflu
[02:11] <truebattleaxe> so far i've had no problems with mir. It actually seems like my system is faster
[02:13] <duflu> truebattleaxe: Probably not faster, but very likely smoother. There's extra buffering and page flipping is enforced. So it could really make a visual difference if the existing X driver is below-par
[02:14] <duflu> Umm, "above" par??
[02:15] <truebattleaxe> yes i would say above par :P
[02:15] <truebattleaxe> way smoother
[02:18] <truebattleaxe> thanks duflu for the info. definitely makes me a bit easier knowing there are updates every few weeks
[02:18] <duflu> truebattleaxe: No problem. In fact we're trying to get 0.1.2 into trusty this week
[02:18] <truebattleaxe> a stable release?
[02:20] <duflu> truebattleaxe: They're all *stable* but it's a snapshot of the latest development
[02:20] <truebattleaxe> gotcha
[02:22] <truebattleaxe> once that update comes out i'll compile my desktop setup so i can pass it to my dad. He wants to use linux but he's iffy switching from windows because of ease to use.  So i made something that has all the apps he would use and ease and taking out that "edgyness" of linux to give him the experience he needs
=== chihchun is now known as chihchun_afk
=== philipballew is now known as philip
=== chihchun_afk is now known as chihchun
[07:05] <didrocks> hey duflu, how are you?
[07:06] <duflu> didrocks: Hello. Good. You?
[07:06] <didrocks> duflu: I'm fine, even if latest image we promoted isn't that nice, so we'll have to race again today :)
[07:06] <duflu> didrocks: Well, I didn't land it this time :)
[07:06] <didrocks> duflu: I was coming to news, I think you heard about Mir making unity8 crashing?
[07:06] <duflu> But happy to help
[07:06] <didrocks> duflu: it's the previous Mir release
[07:07] <duflu> didrocks: I haven't seen any evidence of Mir making Unity8 crash... ?
[07:07] <didrocks> urgh, the info wasn't sent?
[07:07] <didrocks> I guess it was https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1253685
[07:07] <ubot5> Ubuntu bug 1253685 in unity8 (Ubuntu) "unity8 crashed with SIGSEGV in QMetaObject::activate()" [Critical,Confirmed]
[07:07] <duflu> didrocks: Ah, right. See comment #11
[07:07] <didrocks> so it's unity-mir (still associated with Mir in my head)
[07:07] <didrocks> yeah, just reading :)
=== chihchun is now known as chihchun_afk
[07:08] <duflu> It's very confusing that unity-mir has classes that sound like they're in Mir
[07:09] <didrocks> yep
[07:09] <didrocks> so, I guess I have to wait for greyback
[07:28] <duflu> RAOF: How evil is it to limit width/height of a surface to 65535?
[07:29] <RAOF> Not very evil?
[07:29] <RAOF> I guess it depends on what the units are.
[07:30] <duflu> RAOF: Pixels... so that's 4-gigapixels
[07:30] <RAOF> Well, not necessarily. It could be a thin strip of a window.
[07:30] <RAOF> But that's not at all evil.
[07:30] <duflu> RAOF: Yeah I know. But is it foreseeable for Mir to support multi-gigabyte surfaces?
[07:31] <RAOF> It's forseeable for GPUs to act on multi-gigabyte *buffers*, but I don't think they're likely to be displayed.
[07:32] <duflu> I'm conflicted because the most elegant solution to resizing seems to be to make size a MirSurfaceAttribute. Therefore int value = (width << 16) | height;
[07:33] <duflu> Although if it was beyond 65535 you could just use zero and ask the client to query the buffer properties, as they already do
[07:34] <RAOF> That (width << 16) | height would be entirely hidden in mir_client_library, right?
[07:34] <Mirv> filed bug #1254986 and bug #1254987 against unity-mir and unity-system-compositor respectively
[07:34] <ubot5> bug 1254986 in unity-mir "unity-mir FTBFS against libmirserver11" [Critical,New] https://launchpad.net/bugs/1254986
[07:34] <ubot5> bug 1254987 in Unity System Compositor "unity-system-compositor FTBFS against libmirserver11" [Critical,New] https://launchpad.net/bugs/1254987
[07:34] <duflu> RAOF: Yes, behind mir_surface_get_size
[07:35] <duflu> Although a client could observe events and see the odd value if it wants
[07:35] <RAOF> It shouldn't be able to do that.
[07:35] <RAOF> If it's monitoring for size events it should receive a synthesised event, not the raw protocol value.
[08:18]  * duflu discovers yet another redundant Surface class and is now much more sad
=== chihchun_afk is now known as chihchun
[09:39]  * alan_g enjoyed their Java and Python IDEs: http://www.jetbrains.com/objc/features/cpp.html
[09:43] <alf_> alan_g: looks interesting, but mac os x only :/
[09:44] <alan_g> alf_: that's just the current xcode plugin. They're working on a cross platform C++ IDE
[09:46]  * alf_ is pretty happy with vim + YouCompleteMe + Syntastic
[09:47]  * duflu thinks IDE == heresy. Pure code should be pure, accessible, readable and buildable with a text editor and shell :)
[09:49] <duflu> Although I do now accept syntax highlighting. And feel slightly dirty.
[09:50]  * alan_g thinks e.g. selecting a block of text and saying "make that a member function" is less disruptive to thinking about the code than doing the steps by hand.
[09:54] <duflu> alan_g: Pick the odd one out:
[09:54] <duflu>     std::shared_ptr<graphics::Buffer> snapshot_buffer() const;
[09:54] <duflu>     void swap_buffers(std::shared_ptr<graphics::Buffer>& buffer);
[09:55] <duflu> I think we need some kind of consistency, somehow
[09:56] <alan_g> duflu: they are different use-cases (note the const) but I do agree
[09:56] <alan_g> We'll get there
[10:24] <mlankhorst> ok, mesa 10 test build in ppa:canonical-x/x-staging soon
[10:24] <mlankhorst> might need some mir testing :P
[10:28] <ogra_> did anything with the input layer change recently ? i cant wake up my maguro anymore without tapping the screen
=== chihchun is now known as chihchun_afk
[12:45] <didrocks> ogra_: seems you are not popular here :)
[12:45] <didrocks> kgunn: so, we confirmed that ogra's bug started in the previous Mir release: https://bugs.launchpad.net/mir/+bug/1255045
[12:45] <ubot5> Ubuntu bug 1255045 in mir (Ubuntu) "screen does not turn on on maguro when pressing the power button" [High,Confirmed]
[12:45] <ogra_> heh
[12:46] <didrocks> kgunn: so, putting the current Mir release on hold until this one is fixed
[12:46] <didrocks> mind having some people from your team looking at it? (and answering on IRC in the future ;))
[12:49] <ogra_> well, i didnt ping anyone specifically and didnt expect an answer :)
[12:49] <didrocks> ogra_: still, would be nice if upstream in working hours was reading IRC :)
[12:50] <alan_g> didrocks: I only answer when I have something to say
[12:51] <didrocks> alan_g: would be still nice if downstream doesn't have to play catching up to proove/search for which component regressed (this happens a lot) and that can be done with a little bit more communication
[12:51] <alan_g> I don't have a Galaxy Nexus and don't see the problem
[12:51] <didrocks> still, I guess you have an idea on what enters Mir trunk
[12:51] <didrocks> more than us anyway
[12:54] <alan_g> didrocks: I rarely touch the input stuff. I think dandrader was making changes there a few weeks ago.
[12:55] <alan_g> Those changes might be (finally) on trunk
[12:55] <didrocks> alan_g: yeah, so at least, sharing this information would have been a start :)
[12:57] <alan_g> ogra_: which version of Mir are you looking at?
[12:58] <ogra_> alan_g, well, the changeset with which it started is http://people.canonical.com/~ogra/touch-image-stats/20131120.2.changes
[12:58] <ogra_> so somewhere between misetver 9 and 10
[12:58] <ogra_> *mirserver
[13:02] <alan_g> ogra_: Ok, that would be from "a few weeks ago". :(
[13:03] <ogra_> well, it entered th distro on the 20th
[13:05] <alan_g> ogra_: there's a long and painful story about how stuff gets to Mir trunk. I don't like to think about it.
[13:06] <didrocks> this is due to a long a painful story to be able to release Mir as well, but we already discussed it
[13:10] <alan_g> I can't see anything immediately suspicious. The stuff dandrader did in -c 1150 lp:~mir-team/mir/development-branch/ is only test code.
[13:11] <dandrader> alan_g, there's 1160.1.33 "android-input - Assign more unique touch ids"
[13:12] <dandrader> alan_g, that needs a recent qtubuntu which finally got a release only yesterday. but it's easy to tell if there's a mismatch there as there would be a crash after you tap on the screen 16 times :)
[13:13] <dandrader> but that's all about touch events. nothing to do with buttons/keys.
[13:14]  * alan_g has to go. (If someone can lend him a Galaxy...)
=== alan_g is now known as alan_g|lunch
=== ara is now known as Guest1754
=== ara_ is now known as ara
=== ara is now known as Guest55288
=== dandrader is now known as dandrader|afk
=== Guest55288 is now known as ara_
[13:53] <Kaleo> shouldn't https://bugs.launchpad.net/mir/+bug/1255045 be marked as Critical?
[13:53] <ubot5> Ubuntu bug 1255045 in mir (Ubuntu) "screen does not turn on on maguro when pressing the power button" [High,Confirmed]
=== dandrader|afk is now known as dandrader
=== alan_g|lunch is now known as alan_g
=== ara_ is now known as ara
=== dandrader is now known as dandrader|lunch
[15:55] <greyback> didrocks: there's no kgunn for the rest of this week I believe
[15:55] <kgunn> greyback: whats up ? (on a hangout....)
[15:55] <greyback> kgunn: oh, I thought you were on hols. Sorry!
[15:55] <didrocks> greyback: ok, ah no :)
[15:55] <didrocks> kgunn: you probably missed my pings
[15:55] <kgunn> very soon ....like minutes...not hours
[15:55]  * greyback goes back under his rock
[15:58] <kgunn> didrocks: something wrong ?
[15:58] <didrocks> kgunn: yeah, basically we have https://bugs.launchpad.net/mir/+bug/1255045
[15:58] <ubot5> Ubuntu bug 1255045 in mir (Ubuntu) "screen does not turn on on maguro when pressing the power button" [Critical,Confirmed]
[15:58] <didrocks> kgunn: this is on previous mir release
[15:59] <didrocks> (and it's promoted in the current image now)
[15:59] <didrocks> kgunn: I think I'll have to hold any Mir release on it
[15:59] <didrocks> kgunn: not, it can be on qtubuntu (which had to be upgraded due to the ABI breakage), you have the package version on the description
[16:00] <didrocks> would be nice if you can assign someone to it
[16:00] <kgunn> racarr: ricmm ^ can you guys please take a look into this bug ?
[16:00] <didrocks> thanks
[16:00] <kgunn> didrocks: so, if flashing dev-proposed will it be in that image ?
[16:01] <didrocks> kgunn: just flash trusty
[16:01] <kgunn> ack...thanks
[16:01] <didrocks> no need for -proposed
[16:01] <didrocks> kgunn: maguro
[16:01] <kgunn> didrocks: ah...maguro
[16:02] <didrocks> yeah maguro (*sigh*)
[16:03] <kgunn> didrocks: maguro only good for sushi these days...right ?
[16:23] <alf_> kdub: so in KMS A plane respresents an image source that can be blended with or overlayed on top of a CRTC during the scanout process
[16:23] <kdub> so similar to android overlays
[16:24] <kdub> alf_, for what its worth, I think (to the compositor) we can model the hardware cursor as an overlay as well
[16:24] <kdub> so for gbm, it would be a kms plane or a hardware cursor, and for android, it would be a hwc surfcae
[16:24] <alf_> kdub: In KMS since this happens during scanout, the result is not really saved anywhere (not in user accessible buffer at least)
[16:25] <kdub> in android, i think its composited to a buffer, but we don't know exactly when that buffer is ready to see
[16:27] <ogra_> kgunn, well, maguro uses a PVR chipset ... we will soon have to support intel/android HW too ... that mostly comes with PVR (often enough even the same driver) ... so it makes sens to take care for it
=== chihchun_afk is now known as chihchun
=== RoddieKieley1 is now known as RoddieKieley
=== chihchun is now known as chihchun_afk
[16:32] <alan_g> kgunn: the only team member that I think might have a maguro/Galaxy Nexus is kdub
[16:33] <kgunn> alan_g: ...i thot racarr had one, but surely any help welcome
[16:33] <alan_g> kgunn: you may be right
[16:34] <alf_> kdub: @hardware cursor as overlay, probably as long as there is some kind of attribute that tells us that this is the cursor, since, at least with kms, there is a dedicated API for it so we need a special overlay implementation
[16:34] <kdub> alf_, right, but thats something the gbm platform can sort out so the compositor doesn't have to think about it
[16:43] <kdub> ricmm, does maguro count on mir to turn the screen on and off? or is handled somehow with sysfs and powerd?
[17:07] <greyback> kdub: any way I could help you determine that? I've a gnexus here
[17:10] <greyback> kdub: powerd sets display state by talking to (unity-)mir over dbus.
[17:12] <greyback> which is setting the MirPowerMode on the display
[17:12] <kdub> greyback, ok, i have an idea then
[17:18] <ricmm> kdub: it relies on mir, but afaik robert never plugged that path
[17:19] <ricmm> something might have changed that prevemts the hwc from restartong unledd there is a toich
=== dandrader|lunch is now known as dandrader
[17:19] <ricmm> powerd does hpwever brong the system.down
[17:19] <ricmm> which results in the screen going off
[17:19] <ricmm> having lunch, can help in a bit
[17:19] <kdub> ricmm, sure, should have something to try by then
[17:20] <ricmm> ok
[17:20] <ricmm> typing on phone is hard
=== greyback is now known as greyback|away
[17:57]  * kdub sees the power button working intermittently on maguro
[17:57] <kdub> was that the bug? that it doesn't work sometimes?
=== alan_g is now known as alan_g|EOD
=== dandrader is now known as dandrader|afk
=== dandrader|afk is now known as dandrader
=== thomi_ is now known as thomi