[00:15] RAOF: I'm not sure...I hadn't really gotten that far yet so much as digesting/rewriting/importing the existing InputTransport code [00:15] Ah, right. [00:15] that doesn't sound quite right to me though [00:15] What in frontend wants to call send_event on a surface? [00:16] I would think for example the input dispatcher would be calling it (as it does now) [00:16] which would work on mi::Surface [00:16] Nothing in frontend, but frontend needs to *provide* send_event. [00:16] yes. I guess it needs to provide [00:16] the_input_sender [00:16] which [00:16] Surface::consume [00:17] uses [00:17] Which is what I'm doing. Ish. [00:17] Because there isn't actually a single input_sender. [00:18] (There isn't *currently* a single input_sender, really; it's just that we've split the input sending code into multiple pieces, owned by different things) [00:19] Which is why trying to make it do something different is annoying :) [02:16] Damn. I should have left this branch not-compiling. [02:24] racarr, weird... i had the tests pass once... but not again :/ [03:15] kenvandine: ONce it fails it fails until u8 restarts yeah...and...yes I think it just became more resilient but not totally [03:15] Once mir 0.14 ppa finishes building [03:15] well maybe thats done [03:15] once its tomorrow [03:15] ill be in a good position to verify my theory about [03:15] mirscreencast confusing [03:15] USC window management.... === chihchun_afk is now known as chihchun [06:09] Have I mentioned before how much I hate the way nothing in Mir ever has an owner? :/ [06:11] owner? [06:12] like mir::DisplayServer::Privae? [06:13] Everything we ever create is a shared_ptr; nothing is owned by anything. [06:19] but shared_ptr describes ownership.. shared but still .. ownership [06:20] hmm [06:20] i guess for a lot of stuff unique_ptr and passing around references would be enough [06:21] Yeah. shared_ptr describes “eh, working out who owns this is hard. Let's go shopping!” [06:22] hehe [06:23] Lots of our things are ‘this thing is owned by the compositor; it's basically a singleton’. [06:24] A bunch of others are ‘this thing exists for as long as a client has connected. And then for an indeterminate time afterwards, even though that doesn't make sense’. [06:33] You are in a maze of classes, all called Shell. [06:36] It doesn't help that Qt Creator gets confused about the type hierarchy. [06:45] hm is passing argv=nullptr and argc=0 a user error [08:18] duflu_, ping [08:18] dandrader: Hello! [08:18] duflu_, hi === duflu_ is now known as duflu [08:20] duflu_, If I draw a surface twice in my qml scene. Should each item there have a different compositor "user id" when fetching buffers? [08:21] duflu, or should I use a single compositor user id [08:21] dandrader: That's the multi-monitor frame sync library. Technically you should get one user ID per frame for a single monitor display. [08:21] -library +logic [08:22] dandrader: It's really an opaque "monitor ID". If two monitors with different IDs ask for a frame around the same time they will get the same frame. But if any ID asks for a frame twice it will get different (the next) frame [08:23] dandrader: You doing multi-display? [08:23] duflu, no. I'm doing "having multiple items showing the same mir surface in a qml scene" [08:24] duflu, and I'm finding it may be easier to implement if each qml item did its own buffer fecthing using separate ids... [08:25] duflu, but wondering if that's a wrong approach [08:25] dandrader: Hmm, still with a single display and a single ID I imagine you will get messed up by that. The right answer is to only ask each surface for a buffer once per frame (and use it any number of times). I you want a kludge, use different user IDs to force each call to get the same frame. [08:26] duflu, yeah, that was my intent. using a unique id per qml item (eg "(void*)this") so that they get the same frame [08:26] dandrader: If you imagine "user ID" actually means "view ID" it makes sense. You're free to make up new IDs. And different views using different IDs will see the same frame [08:26] or work independently [08:27] duflu, so, would that be a valid use of this compositor user id API or would that be a hack? [08:27] s/valid/correct [08:28] dandrader: It might feel like a hack, but the model is very abstract. If your two views with different IDs are on the same screen it should always work. I don't expect it would be a problem [08:29] dandrader: But frankly for the sake of OpenGL performance you should be binding the surface to a texture once and then reusing the texture multiple times in the frame [08:29] duflu, right. [08:31] although I don't see a mir surface being rendered more than twice in a scene (say, its may view/window and a thumbnail in the tab switcher) [08:31] dandrader: So it's a bit unexpected what you're doing but I don't expect it will ever break. It will work but it's not optimal. Also keep in mind for multi-monitor, each display needs a separate ID (or IDs) [08:32] dandrader: Yeah the switcher or workspace previews is where I'd expect to see the same texture used multiple times on the same screen === dandrader is now known as dandrader|afk === greyback__ is now known as greyback [10:47] Mir API quiz: If I am a nested server, and my surface is resized by the system compositor - how do I know? [11:11] hi. i'm trying to record something with mir but i don't know what's mir's server socket file? [11:12] /run/lightdm-mir-o doesn't work [11:12] there is one for the unity-system-compositor and another one for the user session [11:12] something changed lately? [11:12] greyback: hum iirc you do not notice [11:13] anpok_: yeah I'm reading the code and am seeing the mirclient resize event being swallowed in mgn::detail::DisplayBuffer::mir_event(MirEvent const& event) [11:14] omg_run: iirc /run/mir_socket and /run/user//mir_socket [11:15] anpok_: thanks :D let's see [11:15] greyback: I believe back then we assumed that it was not necessary.. [11:15] hm I think I even had a fix branch that dispatches that too [11:15] anpok_: bad assumption :) [11:16] I thought you get a display configuration change callback? [11:17] sure I do, but the display config has only a bit to do with how USC wants to draw its scene [11:18] my current approach: on display config, configure displays to clone (rotate if necessary), calculate the subrectangle which fits on both displays, resize scene to fit in that subrectangle [11:19] so USC is calling resize() on unity8's surface [11:19] but unity8 has no idea [11:20] doesn't work.. /run/lightdm-mir-0 worked fine until the last update.. hm.. let's see what changed === omg_run is now known as omg_run|AW [11:24] anpok_: I see you noticed it a while ago: https://bugs.launchpad.net/mir/+bug/1294574 ;) [11:24] Launchpad bug 1294574 in Mir "Resize of nested server surfaces never reaches mir::graphics::NestedOutput - nested server always renders with original size" [Medium,Triaged] [11:34] greyback: hm so how do you want that fixed.. i believe just getting the resize event somewhere isnt enough? [11:34] anpok_: I can work around it [11:35] but it's definitely something I'll want in future === dandrader|afk is now known as dandrader === dandrader is now known as dandrader|afk === dandrader|afk is now known as dandrader === chihchun is now known as chihchun_afk === dandrader is now known as dandrader|afk [16:12] Good morning! [16:18] working on verifying some theories related to USC window management about the autopilot tex tbug === dandrader|afk is now known as dandrader [16:49] racarr, cool [16:49] racarr, when do we expect to see 0.14 in wily? [16:50] assuming that has the fix :) [16:54] kenvandine: Quite soon I think but I'm really not sure it does [16:54] I will be soon [16:54] I get very slow connections to the image server lately :( [17:20] anpok_: Is the mir 0.14 silo expected working now? === dandrader is now known as dandrader|bbl [17:28] seems to work [18:03] kenvandine: Ok...so theres a lot to suggest its fixed in .14 but there is a new problem in that [18:03] autopilot is triggering lots of key repeats now... [18:04] We changed the way key repeat was implemented/disabled so [18:04] thats not so unexpected [18:04] ugh [18:04] it seems like key repeat must have just been off before...I unno [18:05] racarr: nearly [18:05] anpok_: Oh its working for me [18:05] i misconfigured qtubuntu-gles [18:06] hmm [18:07] How was key repeat working before [18:07] as far as I remember we didn't provide a runtime way to [18:07] disable key repeat until now and it was [18:07] on by default and qtmir doesn't disable it [18:07] so...is it just the new key repeat timeout is way too low [18:07] and [18:07] .... [18:07] nah not quite [18:07] but seems unlikely that this would have never come up before but ive never heard of it [18:07] unity8 had its own input dispatcher so it bypassed the repeat [18:08] handling [18:08] anpok_: But from USC [18:08] so usc was repeating.. yes [18:08] and qtmir event feeder might have ignored the repeats? [18:08] not sure [18:08] thats an idea! [18:09] hmm it seems to interpret autorep correctly [18:17] Hmm I dont get it how were there no key repeats before [18:18] oh [18:18] The initial key repeat timeout may actually be [18:18] much lower than before... [18:19] yep [18:19] ok hmm [18:19] kenvandine: So yeah...I can't trigger the text failing bug anymore but there is definitely this issue with key repeat [18:20] we either need to get a mir patch in (which I should be able to cook up today...shouhld be roughly 20 lines of diff) [18:20] OR [18:20] autopilot can restart usc with MIR_SERVER_ENABLE_KEY_REPEAT=false :p [18:20] kgunn: ^ [18:21] awesome racarr thanks for chasing it so hard [18:21] great news! [18:23] I think autopilot with specific [18:23] mir options has been shot down in the past right [18:23] so....uh.... [18:24] should we try and get something in 0.14 or just [18:24] let 0.14 go and do a point release [18:24] No ABI break... [18:24] / API [18:29] lunch! [18:31] lol this would have showed up in manual testing [18:31] for the silo too [18:31] it makes the volume control so hard to use [18:31] (tried to turn on music on the way to lunch) [19:17] mir demos needs to depend on mir-platform-graphics-mesa2 [19:17] otherwise the demo server wont run [19:23] hello, does/will mir support any kind of clipboard/selection api? [19:26] Back [19:26] anyone have any opinions on 0.14/point release [19:26] attente: I think in the end we decided not to support it [19:26] in favor of the content hub supporting it [19:27] racarr: yeah, that's what i thought too, but it's not clear to me if this is implemented there yet [19:28] attente, it isn't [19:29] the spec is still being written up [19:29] * kenvandine is looking forward to working on that :) [19:30] kenvandine: ok, thanks :) [19:30] np === dandrader|bbl is now known as dandrader [21:38] kenvandine: Are there workarounds now for this issue? e.g. [21:39] we have a fix for the key repeat thing now so with that + 0.14 everything should work again [21:39] and trying to sort out urgencies/what to do with it [21:57] reboot brb