| 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:15 |
| 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:16 |
| 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:17 |
| 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:18 |
| RAOF | Which is why trying to make it do something different is annoying :) | 00:19 |
| RAOF | Damn. I should have left this branch not-compiling. | 02:16 |
| kenvandine | racarr, weird... i had the tests pass once... but not again :/ | 02:24 |
| 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.... | 03:15 |
| === chihchun_afk is now known as chihchun | ||
| RAOF | Have I mentioned before how much I hate the way nothing in Mir ever has an owner? :/ | 06:09 |
| anpok_ | owner? | 06:11 |
| anpok_ | like mir::DisplayServer::Privae? | 06:12 |
| RAOF | Everything we ever create is a shared_ptr; nothing is owned by anything. | 06:13 |
| anpok_ | but shared_ptr describes ownership.. shared but still .. ownership | 06:19 |
| anpok_ | hmm | 06:20 |
| anpok_ | i guess for a lot of stuff unique_ptr and passing around references would be enough | 06:20 |
| RAOF | Yeah. shared_ptr describes “eh, working out who owns this is hard. Let's go shopping!” | 06:21 |
| anpok_ | hehe | 06:22 |
| RAOF | Lots of our things are ‘this thing is owned by the compositor; it's basically a singleton’. | 06:23 |
| 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:24 |
| RAOF | You are in a maze of classes, all called Shell. | 06:33 |
| RAOF | It doesn't help that Qt Creator gets confused about the type hierarchy. | 06:36 |
| anpok_ | hm is passing argv=nullptr and argc=0 a user error | 06:45 |
| dandrader | duflu_, ping | 08:18 |
| duflu_ | dandrader: Hello! | 08:18 |
| dandrader | duflu_, hi | 08:18 |
| === duflu_ is now known as duflu | ||
| 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:20 |
| 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:21 |
| 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:22 |
| 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:23 |
| 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:24 |
| 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:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| 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:29 |
| 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:31 |
| 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 | 08:32 |
| === dandrader is now known as dandrader|afk | ||
| === greyback__ is now known as greyback | ||
| greyback | Mir API quiz: If I am a nested server, and my surface is resized by the system compositor - how do I know? | 10:47 |
| omg_run | hi. i'm trying to record something with mir but i don't know what's mir's server socket file? | 11:11 |
| 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:12 |
| 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:13 |
| anpok_ | omg_run: iirc /run/mir_socket and /run/user/<USER_ID>/mir_socket | 11:14 |
| 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:15 |
| anpok_ | I thought you get a display configuration change callback? | 11:16 |
| greyback | sure I do, but the display config has only a bit to do with how USC wants to draw its scene | 11:17 |
| 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:18 |
| greyback | so USC is calling resize() on unity8's surface | 11:19 |
| greyback | but unity8 has no idea | 11:19 |
| omg_run | doesn't work.. /run/lightdm-mir-0 worked fine until the last update.. hm.. let's see what changed | 11:20 |
| === omg_run is now known as omg_run|AW | ||
| greyback | anpok_: I see you noticed it a while ago: https://bugs.launchpad.net/mir/+bug/1294574 ;) | 11:24 |
| ubot5 | 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:24 |
| 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:34 |
| greyback | but it's definitely something I'll want in future | 11:35 |
| === 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 | ||
| racarr | Good morning! | 16:12 |
| racarr | working on verifying some theories related to USC window management about the autopilot tex tbug | 16:18 |
| === dandrader|afk is now known as dandrader | ||
| kenvandine | racarr, cool | 16:49 |
| kenvandine | racarr, when do we expect to see 0.14 in wily? | 16:49 |
| kenvandine | assuming that has the fix :) | 16:50 |
| 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 :( | 16:54 |
| racarr | anpok_: Is the mir 0.14 silo expected working now? | 17:20 |
| === dandrader is now known as dandrader|bbl | ||
| racarr | seems to work | 17:28 |
| 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:03 |
| 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:04 |
| anpok_ | racarr: nearly | 18:05 |
| racarr | anpok_: Oh its working for me | 18:05 |
| anpok_ | i misconfigured qtubuntu-gles | 18:05 |
| racarr | hmm | 18:06 |
| 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:07 |
| 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:08 |
| racarr | hmm it seems to interpret autorep correctly | 18:09 |
| racarr | Hmm I dont get it how were there no key repeats before | 18:17 |
| racarr | oh | 18:18 |
| racarr | The initial key repeat timeout may actually be | 18:18 |
| racarr | much lower than before... | 18:18 |
| 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:19 |
| 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:20 |
| kgunn | awesome racarr thanks for chasing it so hard | 18:21 |
| kenvandine | great news! | 18:21 |
| 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:23 |
| 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:24 |
| racarr | lunch! | 18:29 |
| 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) | 18:31 |
| bschaefer | mir demos needs to depend on mir-platform-graphics-mesa2 | 19:17 |
| bschaefer | otherwise the demo server wont run | 19:17 |
| attente | hello, does/will mir support any kind of clipboard/selection api? | 19:23 |
| 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:26 |
| attente | racarr: yeah, that's what i thought too, but it's not clear to me if this is implemented there yet | 19:27 |
| kenvandine | attente, it isn't | 19:28 |
| kenvandine | the spec is still being written up | 19:29 |
| * kenvandine is looking forward to working on that :) | 19:29 | |
| attente | kenvandine: ok, thanks :) | 19:30 |
| kenvandine | np | 19:30 |
| === dandrader|bbl is now known as dandrader | ||
| racarr | kenvandine: Are there workarounds now for this issue? e.g. | 21:38 |
| 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:39 |
| kgunn | reboot brb | 21:57 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!