=== chihchun_afk is now known as chihchun | ||
=== LockeAnarchist- is now known as LockeAnarchist | ||
=== chihchun is now known as chihchun_afk | ||
=== chihchun_afk is now known as chihchun | ||
=== LockeAnarchist- is now known as LockeAnarchist | ||
duflu | Hmm, lots of internal compilers errors these past few days on vivid | 02:36 |
---|---|---|
duflu | And no sign of disk errors | 02:36 |
duflu | -s | 02:37 |
=== chihchun is now known as chihchun_afk | ||
=== chihchun_afk is now known as chihchun | ||
desrt | duflu: good morning | 03:02 |
duflu | desrt: Hello | 03:03 |
duflu | desrt: Happy Sunday night? | 03:03 |
desrt | yup! | 03:03 |
duflu | Made great Mir progress on Sunday myself. Prototyped an exciting approach to reducing our buffer lag dynamically | 03:06 |
* desrt has been playing around with bluetooth and gvariant<->kdbus serialisation this weekend | 03:09 | |
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:10 |
RAOF | Yeah, that's moderately annoying. | 03:11 |
desrt | it does have -a- mechanism | 03:11 |
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:12 |
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:25 |
RAOF | :) | 03:26 |
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:39 |
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:41 |
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:42 |
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:43 |
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:44 |
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:45 |
=== chihchun is now known as chihchun_afk | ||
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:46 |
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:47 |
RAOF | Right. | 03:48 |
RAOF | And also - your surface creation completes before you do any GL calls. | 03:48 |
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 | 03:49 |
=== LockeAnarchist- is now known as LockeAnarchist | ||
=== LockeAnarchist- is now known as LockeAnarchist | ||
=== LockeAnarchist- is now known as LockeAnarchist | ||
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:14 |
greyback | alf: it's a desktop feature primarily - to implement the red X in the window decoration | 10:15 |
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:16 |
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:17 |
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:18 |
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:21 |
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:23 |
alf | greyback: perhaps I am being overly paranoid :) | 10:24 |
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:25 |
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:33 |
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. | 10:37 |
* alan_g wishes for the mir-nested-on-X "platform" once more | 11:44 | |
alan_g | alf: how are you testing MirSurfaceVisibilityEvent? I've not yet been able to reproduce your faulure | 12:29 |
alan_g | *failure | 12:29 |
* alan_g reproduces failure | 12:30 | |
alan_g | :) | 12:30 |
=== dandrader is now known as dandrader|afk | ||
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:33 |
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 | 12:35 |
=== dandrader|afk is now known as dandrader | ||
alf | alan_g: the failure in migrate-MirSurfaceVisibilityEvent doesn't seem to be related to the fd leak | 14:53 |
alan_g | alf: yeah. It was related to the NullFocusSetter | 14:54 |
alan_g | Any progress with the fd? | 14:54 |
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 | 14:55 |
=== chihchun_afk is now known as chihchun | ||
=== dandrader is now known as dandrader|lunch | ||
=== chihchun is now known as chihchun_afk | ||
=== chihchun_afk is now known as chihchun | ||
=== dandrader|lunch is now known as dandrader | ||
=== alan_g is now known as alan_g|EOD | ||
=== chihchun is now known as chihchun_afk | ||
=== LockeAnarchist- is now known as LockeAnarchist | ||
=== greyback__ is now known as greyback | ||
=== LockeAnarchist- is now known as LockeAnarchist |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!