[02:36] <duflu> Hmm, lots of internal compilers errors these past few days on vivid
[02:36] <duflu> And no sign of disk errors
[02:37] <duflu> -s
[03:02] <desrt> duflu: good morning
[03:03] <duflu> desrt: Hello
[03:03] <duflu> desrt: Happy Sunday night?
[03:03] <desrt> yup!
[03:06] <duflu> Made great Mir progress on Sunday myself. Prototyped an exciting approach to reducing our buffer lag dynamically
[03:09]  * desrt has been playing around with bluetooth and gvariant<->kdbus serialisation this weekend
[03:10] <desrt> turns out NetworkManager currently lacks a good mechanism for marking a PAN-capable paired bluetooth device in such a way as to say "i never want to connect to the internet with this"
[03:11] <RAOF> Yeah, that's moderately annoying.
[03:11] <desrt> it does have -a- mechanism
[03:12] <desrt> you can find the Device object corresponding to the mac address in question, enumerate its connection objects and call 'Delete' on them
[03:12] <desrt> and then the device will go away
[03:12] <desrt> but it'll be back again once you restart networkmanager
[03:25] <RAOF> That doesn't sound like a solution to “I never want that phone I paired with to appear to be an internet connection, ever”
[03:26] <RAOF> :)
[03:39] <duflu> RAOF: I'm still staying out of two-stage surface creation, but have a requirement request: Make surface width/height optional attributes (if not now then in future). Because in some cases they're unknown by the client who is (for example) requesting an initial state of "full screen"
[03:39] <duflu> Maybe we need to allow an initial size of 0x0
[03:41] <RAOF> No, I don't think we need to do that :)
[03:41] <RAOF> But, indeed, clients requesting fullscreen will get full screen (shell policy allowing).
[03:41] <duflu> RAOF: I've tried not having it and it's ugly and misleading to require a width and height that is never used
[03:41] <RAOF> We can't guarantee that it's never used.
[03:41] <RAOF> Or, rather, we *can*
[03:42] <duflu> RAOF: It must never be used if you want full screen
[03:42] <duflu> Or else it's just wasted buffer creation and deletion
[03:42] <RAOF> Our choices are: require width/height, if the shell disallows fullscreen then terminate the app.
[03:42] <RAOF> duflu: two-stage-surface-create (follow-on-branch) sends fullscreen attribute at surface creation time.
[03:42] <RAOF> There's no wasted buffer creation.
[03:43] <duflu> RAOF: Yeah deferring all buffer creation is easy
[03:43] <duflu> RAOF: I think it's fine if you can get the dimensions from the initial state or fail creation if the shell refuses full screen
[03:44] <duflu> And this is why I'm not participating in that discussion. If something is broken after it lands, I'll let you know :)
[03:44] <RAOF> duflu: So far the only attribute mismatches I say will fail creation are buffer_usage and pixel_format.
[03:45] <duflu> RAOF: Do we need pixel format for hardware or let GL choose?
[03:45] <RAOF> Given that we can't let GL choose, yes.
[03:45] <RAOF> There is literally no way of letting GL choose for us.
[03:46] <RAOF> (And where people have been proposing such ways, they've been along the lines of ‘tell GL to use the format that we've already specified for the native window’)
[03:47] <duflu> RAOF: Yes, I mean you can partially infer one from the other, but I guess that only gets you a subset and not a specific singular choice
[03:48] <RAOF> Right.
[03:48] <RAOF> And also - your surface creation completes before you do any GL calls.
[03:49] <duflu> RAOF: Hmm, actually if your buffer creation is deferred then pixel format and buffer usage are also not immediately required -- just needed before the surface ever gets realized
[03:49] <duflu> Oh, but you have GL wanting things
[03:49] <duflu> Great
[10:14] <alf> greyback: Hi! We were discussing implementing the item 'Add a polite "client close your window" request', which I think was requested by you. Could you elaborate what the use case / requirements are for it?
[10:15] <greyback> alf: it's a desktop feature primarily - to implement the red X in the window decoration
[10:16] <greyback> which I presume (never checked) is a message to the client to say, please close that window
[10:16] <greyback> I doubt X just deletes that window on the client
[10:17] <alf> greyback: ok, so this is per surface (window) not the whole app
[10:17] <greyback> alf: right
[10:17] <alf> greyback: (unless they coincide of course)
[10:18] <greyback> alf: well that's not for Mir to enforce IMO
[10:18] <greyback> if client has only 1 surface, and user closes it, it's up to the app to decide to close itself or not, no?
[10:18] <greyback> "close itself" = quit the whole process
[10:21] <alf> greyback: I wonder... there may be a security risk here I think... imagine a user closing an app, the (only) window disappears, but the process is still there doing its thing in the background
[10:23] <greyback> alf: isn't it alsp possible to start an app which creates a mir connection, but doesn't create a surface?
[10:23] <alf> greyback: then again, I am not sure how IM indicators work, do they spawn a different process when showing the contacts window when clicking on the indicator (e.g. skype)?
[10:23] <greyback> unlikely
[10:23] <alf> greyback: fair point
[10:24] <alf> greyback: perhaps I am being overly paranoid :)
[10:25] <greyback> alf: I expect shell would still have the application marked as running in the launcher, so user will be able to see it
[10:33] <alf> greyback: ok, so we basically want the same semantics as an X11 close event (a request that the client is free to ignore/handle as they wish).
[10:33] <greyback> alf: I think that's reasonable. You?
[10:37] <alf> greyback: I think so too (in general), but since I am not closely involved with window management work, I can't say how it fits with the WM grand plan.
[11:44]  * alan_g wishes for the mir-nested-on-X "platform" once more
[12:29] <alan_g> alf: how are you testing MirSurfaceVisibilityEvent? I've not yet been able to reproduce your faulure
[12:29] <alan_g> *failure
[12:30]  * alan_g reproduces failure
[12:30] <alan_g> :)
[12:33] <alf> alan_g: I just found that we have an fd leak that affects most repeated runs of acceptance test. It may be involved in these failures too, so I suggest we fix this first (looking into it now).
[12:35] <alan_g> alf: I won't look at this any further until I hear from you. But let me know if I can help.
[12:35] <alf> alan_g: thanks
[14:53] <alf> alan_g: the failure in migrate-MirSurfaceVisibilityEvent doesn't seem to be related to the fd leak
[14:54] <alan_g> alf: yeah. It was related to the NullFocusSetter
[14:54] <alan_g> Any progress with the fd?
[14:55] <alf> alan_g: Yes, our stub implementations of ClientBuffer(Factory) didn't release the fds passed to it through the MirBufferPackage, will have a fix soon
[14:55] <alan_g> nice