[00:15] <racarr> 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] <RAOF> Ah, right.
[00:15] <racarr> that doesn't sound quite right to me though
[00:15] <racarr> What in frontend wants to call send_event on a surface?
[00:16] <racarr> I would think for example the input dispatcher would be calling it (as it does now)
[00:16] <racarr> which would work on mi::Surface
[00:16] <RAOF> Nothing in frontend, but frontend needs to *provide* send_event.
[00:16] <racarr> yes. I guess it needs to provide
[00:16] <racarr> the_input_sender
[00:16] <racarr> which
[00:16] <racarr> Surface::consume
[00:17] <racarr> uses
[00:17] <RAOF> Which is what I'm doing. Ish.
[00:17] <RAOF> Because there isn't actually a single input_sender.
[00:18] <RAOF> (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] <RAOF> Which is why trying to make it do something different is annoying :)
[02:16] <RAOF> Damn. I should have left this branch not-compiling.
[02:24] <kenvandine> racarr, weird... i had the tests pass once... but not again :/
[03:15] <racarr> kenvandine: ONce it fails it fails until u8 restarts yeah...and...yes I think it just became more resilient but not totally
[03:15] <racarr> Once mir 0.14 ppa finishes building
[03:15] <racarr> well maybe thats done
[03:15] <racarr> once its tomorrow
[03:15] <racarr> ill be in a good position to verify my theory about
[03:15] <racarr> mirscreencast confusing
[03:15] <racarr> USC window management....
[06:09] <RAOF> Have I mentioned before how much I hate the way nothing in Mir ever has an owner? :/
[06:11] <anpok_> owner?
[06:12] <anpok_> like mir::DisplayServer::Privae?
[06:13] <RAOF> Everything we ever create is a shared_ptr; nothing is owned by anything.
[06:19] <anpok_> but shared_ptr describes ownership.. shared but still .. ownership
[06:20] <anpok_> hmm
[06:20] <anpok_> i guess for a lot of stuff unique_ptr and passing around references would be enough
[06:21] <RAOF> Yeah. shared_ptr describes “eh, working out who owns this is hard. Let's go shopping!”
[06:22] <anpok_> hehe
[06:23] <RAOF> Lots of our things are ‘this thing is owned by the compositor; it's basically a singleton’.
[06:24] <RAOF> 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] <RAOF> You are in a maze of classes, all called Shell.
[06:36] <RAOF> It doesn't help that Qt Creator gets confused about the type hierarchy.
[06:45] <anpok_> hm is passing argv=nullptr and argc=0 a user error
[08:18] <dandrader> duflu_, ping
[08:18] <duflu_> dandrader: Hello!
[08:18] <dandrader> duflu_, hi
[08:20] <dandrader> 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] <dandrader> duflu, or should I use a single compositor user id
[08:21] <duflu> 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] <duflu> -library +logic
[08:22] <duflu> 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] <duflu> dandrader: You doing multi-display?
[08:23] <dandrader> duflu, no. I'm doing "having multiple items showing the same mir surface in a qml scene"
[08:24] <dandrader> 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] <dandrader> duflu, but wondering if that's a wrong approach
[08:25] <duflu> 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] <dandrader> 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] <duflu> 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] <dandrader> or work independently
[08:27] <dandrader> duflu, so, would that be a valid use of this compositor user id API or would that be a hack?
[08:27] <dandrader> s/valid/correct
[08:28] <duflu> 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] <duflu> 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] <dandrader> duflu, right.
[08:31] <dandrader> 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] <duflu> 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] <duflu> dandrader: Yeah the switcher or workspace previews is where I'd expect to see the same texture used multiple times on the same screen
[10:47] <greyback> Mir API quiz: If I am a nested server, and my surface is resized by the system compositor - how do I know?
[11:11] <omg_run> hi. i'm trying to record something with mir but i don't know what's mir's server socket file?
[11:12] <omg_run> /run/lightdm-mir-o doesn't work
[11:12] <anpok_> there is one for the unity-system-compositor and another one for the user session
[11:12] <omg_run> something changed lately?
[11:12] <anpok_> greyback: hum iirc you do not notice
[11:13] <greyback> 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] <anpok_> omg_run: iirc /run/mir_socket and /run/user/<USER_ID>/mir_socket
[11:15] <omg_run> anpok_: thanks :D let's see
[11:15] <anpok_> greyback: I believe back then we assumed that it was not necessary..
[11:15] <anpok_> hm I think I even had a fix branch that dispatches that too
[11:15] <greyback> anpok_: bad assumption :)
[11:16] <anpok_> I thought you get a display configuration change callback?
[11:17] <greyback> sure I do, but the display config has only a bit to do with how USC wants to draw its scene
[11:18] <greyback> 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] <greyback> so USC is calling resize() on unity8's surface
[11:19] <greyback> but unity8 has no idea
[11:20] <omg_run> doesn't work.. /run/lightdm-mir-0 worked fine until the last update.. hm.. let's see what changed
[11:24] <greyback> anpok_: I see you noticed it a while ago: https://bugs.launchpad.net/mir/+bug/1294574 ;)
[11:34] <anpok_> greyback: hm so how do you want that fixed.. i believe just getting the resize event somewhere isnt enough?
[11:34] <greyback> anpok_: I can work around it
[11:35] <greyback> but it's definitely something I'll want in future
[16:12] <racarr> Good morning!
[16:18] <racarr> working on verifying some theories related to USC window management about the autopilot tex tbug
[16:49] <kenvandine> racarr, cool
[16:49] <kenvandine> racarr, when do we expect to see 0.14 in wily?
[16:50] <kenvandine> assuming that has the fix :)
[16:54] <racarr> kenvandine: Quite soon I think but I'm really not sure it does
[16:54] <racarr> I will be soon
[16:54] <racarr> I get very slow connections to the image server lately :(
[17:20] <racarr> anpok_: Is the mir 0.14 silo expected working now?
[17:28] <racarr> seems to work
[18:03] <racarr> kenvandine: Ok...so theres a lot to suggest its fixed in .14 but there is a new problem in that
[18:03] <racarr> autopilot is triggering lots of key repeats now...
[18:04] <racarr> We changed the way key repeat was implemented/disabled so
[18:04] <racarr> thats not so unexpected
[18:04] <kenvandine> ugh
[18:04] <racarr> it seems like key repeat must have just been off before...I unno
[18:05] <anpok_> racarr: nearly
[18:05] <racarr> anpok_: Oh its working for me
[18:05] <anpok_> i misconfigured qtubuntu-gles
[18:06] <racarr> hmm
[18:07] <racarr> How was key repeat working before
[18:07] <racarr> as far as I remember we didn't provide a runtime way to
[18:07] <racarr> disable key repeat until now and it was
[18:07] <racarr> on by default and qtmir doesn't disable it
[18:07] <racarr> so...is it just the new key repeat timeout is way too low
[18:07] <racarr> and
[18:07] <racarr> ....
[18:07] <anpok_> nah not quite
[18:07] <racarr> but seems unlikely that this would have never come up before but ive never heard of it
[18:07] <anpok_> unity8 had its own input dispatcher so it bypassed the repeat
[18:08] <anpok_> handling
[18:08] <racarr> anpok_: But from USC
[18:08] <anpok_> so usc was repeating.. yes
[18:08] <anpok_> and qtmir event feeder might have ignored the repeats?
[18:08] <anpok_> not sure
[18:08] <racarr> thats an idea!
[18:09] <racarr> hmm it seems to interpret autorep correctly
[18:17] <racarr> Hmm I dont get it how were there no key repeats before
[18:18] <racarr> oh
[18:18] <racarr> The initial key repeat timeout may actually be
[18:18] <racarr> much lower than before...
[18:19] <racarr> yep
[18:19] <racarr> ok hmm
[18:19] <racarr> kenvandine: So yeah...I can't trigger the text failing bug anymore but there is definitely this issue with key repeat
[18:20] <racarr> 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] <racarr> OR
[18:20] <racarr> autopilot can restart usc with MIR_SERVER_ENABLE_KEY_REPEAT=false :p
[18:20] <racarr> kgunn: ^
[18:21] <kgunn> awesome racarr thanks for chasing it so hard
[18:21] <kenvandine> great news!
[18:23] <racarr> I think autopilot with specific
[18:23] <racarr> mir options has been shot down in the past right
[18:23] <racarr> so....uh....
[18:24] <racarr> should we try and get something in 0.14 or just
[18:24] <racarr> let 0.14 go and do a point release
[18:24] <racarr> No ABI break...
[18:24] <racarr>  / API
[18:29] <racarr> lunch!
[18:31] <racarr> lol this would have showed up in manual testing
[18:31] <racarr> for the silo too
[18:31] <racarr> it makes the volume control so hard to use
[18:31] <racarr> (tried to turn on music on the way to lunch)
[19:17] <bschaefer> mir demos needs to depend on mir-platform-graphics-mesa2
[19:17] <bschaefer> otherwise the demo server wont run
[19:23] <attente> hello, does/will mir support any kind of clipboard/selection api?
[19:26] <racarr> Back
[19:26] <racarr> anyone have any opinions on 0.14/point release
[19:26] <racarr> attente:  I think in the end we decided not to support it
[19:26] <racarr> in favor of the content hub supporting it
[19:27] <attente> racarr: yeah, that's what i thought too, but it's not clear to me if this is implemented there yet
[19:28] <kenvandine> attente, it isn't
[19:29] <kenvandine> the spec is still being written up
[19:29]  * kenvandine is looking forward to working on that :)
[19:30] <attente> kenvandine: ok, thanks :)
[19:30] <kenvandine> np
[21:38] <racarr> kenvandine: Are there workarounds now for this issue? e.g.
[21:39] <racarr> we have a fix for the key repeat thing now so with that + 0.14 everything should work again
[21:39] <racarr> and trying to sort out urgencies/what to do with it
[21:57] <kgunn> reboot brb