RAOFvibhav: What's your intended target for python-mir? Just binding the functions in the mirclient API would work, but depending on your target you might want to do something extra.00:15
smspillazRAOF: heh, I'm just thinking about how well the multithreaded callbacks would interact with the GIL01:24
RAOFEasily! You marshal everything into a single thread!01:25
smspillazRAOF: of course. But ideally you'd probably want to do that in a separate library and then bind to that01:25
smspillazsince otherwise you'd have crazy locking overhead01:26
smspillaz(*based on a vast oversimplication of the GIL)01:26
smspillazRAOF: I remember it was quite surreal when racarr was explaining that to me while we managed to get lost on the bart01:27
smspillazRAOF: I actually kinda like the multithreaded callbacks approach, partially because it means Death to the Main Loop [tm]. The only downside is that integrating it with a main loop is a little awkward01:29
dufluRAOF: Hmm, there's no /Mir/ in any live images yet, right?01:31
duflusmspillaz: Also, if you're receiving non-input surface events, that's a different thread again :)01:32
dufluI mean :S01:33
smspillazduflu: yeah, iirc it was one thread for surface events and one thread for input events01:33
duflusmspillaz: https://bugs.launchpad.net/mir/+bug/119438401:33
ubot5Ubuntu bug 1194384 in Mir "Mir client callbacks are not thread-safe" [Medium,Triaged]01:33
smspillazduflu: I don't think the threading is a problem, rather - the whole MirEvent is just awkward01:34
smspillaz*MirEvent thing01:34
smspillazI much prefer the wayland approach -> every unique event happens in its own callback01:34
duflusmspillaz: Can you elaborate?01:35
dufluBecause technically all events have their own callbacks01:35
dufluOr you mean callback type?01:35
smspillazthat being said - wayland screws up in one area: keyboard and mouse events are reported to you in surface relative co-ordinates but you can only have one handler per mouse or keyboard01:36
smspillazduflu: callback type01:36
dufluI see01:36
smspillazduflu: unions are a kinda sucky way of representing data like this01:36
smspillazsee XEvent01:36
dufluIt is nice to be able to take shortcuts and sometimes handle different even types in a single callback01:36
dufluNot to mention, nice to avoid the user learning many callback prototypes01:37
smspillazand then you end up with a thousand-line long "Event" callback01:37
smspillazwhich is made worse by the fact that it may be called in multiple threads simultaneously01:37
smspillazand the only real way to fix that would be to dispatch the potentially giant switch statement into separate functions01:38
smspillaz... which might as well be done at the client library level01:38
smspillazsee for instance: https://github.com/smspillaz/xbmc/commit/ddab367b4928bc50f168d157b6b4939f3062402a#L2R7801:39
smspillaz(ah, my bad, wayland does actually give you the surface the event happened on)01:40
duflusmspillaz: Fair point. I would then say... use a single callback prototype demultiplexed at registration:    set_event_handler(filter, callback)01:41
smspillazduflu: eg - wl_pointer_add_listener :)01:41
smspillaz(I would show you an example, but I can't because I have to dlopen libwayland-client.so and then use the protocol directly because things like wl_pointer_add_listener are all static inline functions ....)01:43
smspillazbut eg: https://github.com/smspillaz/xbmc/commit/ddab367b4928bc50f168d157b6b4939f3062402a#L2R3601:44
duflusmspillaz: BTW pointer events are meant to be surface-relative in Mir too. It's just not implemented yet01:49
duflu-pointer +motion01:50
dufluThat's odd. My Mir performance dropped about 5% over the weekend (after updates)02:24
dufluBut it's only compositing performance that dropped. Bypass results are unchanged02:26
TheDrumsduflu: There are no *official* cdimages.ubuntu.com images, but the Xubuntu team did create one using the latest from the system-compositor-testing PPA for ease of testing.02:33
dufluTheDrums: Ah thanks. That explains the new bug reports from Xubuntu users against Mir02:33
TheDrumsYes, seems while several of the Mir devs were sent the message, you were not one of them.02:34
skellatMarking the one report about complete screen corruption as incomplete was not a good thing as the only information that was recoverable was provided.  The logs are inaccessible.02:36
skellatUnless we were running exterior serial consoles, we wouldn't have had a way to recover such.02:36
TheDrumsduflu: http://www.mail-archive.com/xubuntu-devel@lists.ubuntu.com/msg08905.html is the message.02:38
dufluskellat, I know that now. About to fix it02:41
RAOF♪ And on that farm he had a laptop ♫03:22
dufluRAOF: Awesome! (?)03:30
dufluRAOF: Quad core IPS SSD goodness?03:32
* duflu gives all builds to RAOF03:33
dufluRAOF: What's the key "depth" like?03:44
RAOFIt's pretty shallow, but typable.03:45
tvoss_good morning :)05:16
tvoss_RAOF, ping05:17
tvoss_duflu, ping05:17
RAOFtvoss_: Pong05:18
tvoss_duflu, ping05:20
duflutvoss_: pong05:43
tvoss_alf__, duflu could you guys please sync up on the multi-monitor and switch-branch integration? A summary by mail would be great!06:00
alf__tvoss_: duflu: sure06:01
duflualf__: I will try to do the timing workaround to solve non-cloned multi-output. Then "more robust solutions" are not on the critical path and blocking...06:03
alf__duflu: The BackBufferStrategy mechanism was introduced as a way to inject policy for such situations (MultiAcquisition being one such policy). I think it is the right layer to put the policy into, vs the Compositor, which should not have to care about this at all.06:06
duflualf__: I think the strategy layer is a bit hackish. It exists to match the exact semantics in which buffers will be called/used. That would be better enforced where they are called and used (hence "more robust")06:07
duflu-called +acquired06:08
duflualf__: I mean, a nicer solution would be to keep that multi-monitor logic closer to the multi-monitor compositing.06:11
dufluI was only suggesting the timing workaround as a quick solution which requires no effort on your part06:11
dufluUnless there are other "simple" ways to semi-synchronize the compositing threads without actually synchronizing them06:12
dufluAnd without breaking bypass requirements06:13
tvoss_duflu, are you loosing the z character?06:13
duflutvoss_ ?06:14
tvoss_duflu, my xchat eats away certain characters :)06:14
duflutvoss_: No, it's just you... ?06:14
tvoss_duflu, damn :)06:14
alf__duflu: how would that work in the (DisplayBuffer)Compositor?06:14
duflualf__: You mean timing workaround?06:15
alf__duflu: yes06:15
duflualf__: Actual comsumed compositor buffers get a timestamp. And new ones are not allowed to be consumed (hence get reused) for the next 10ms06:15
dufluSo multiple monitors with roughly the same refresh rates share the same compositor buffer. Or at least don't steal each other's or wake the client up any faster than one monitor would06:16
dufluIt actually feels close to the "right solution", just maybe in the wrong place06:17
dufluAnd bonus: That won't break bypass.06:18
alf__duflu: How does MultiAcquisition break bypass (I don't mind dropping it, I am just trying to undestand). In any case the ultimate benchmark for this is how much each policy affects visual fluidity. BTW, you can run mir_demo_server_shell --display-config=sidebyside (with two screens) and move clients between the outputs to test.06:20
alf__(from lp:mir)06:21
duflualf__: Cool thanks06:21
duflualf__: The issue with multiacquisition, which had be stuck for weeks, was its assumptions about the exact ordering of compositor acquire/release calls. Bypass has two acquired simultaneously most of the time, but also requires that they're always different buffers (when available)06:22
duflu-be +me06:22
duflualf__: Also, no one has pinpointed the first primary cause of the lag bug. Other than it was in the buffering code I replaced, _somewhere_ :/06:23
alf__duflu: isn't this fixed by https://code.launchpad.net/~vanvugt/mir/fix-1199450/+merge/178236 ?06:23
duflualf__: The first cause is fixed by switch (prerequisite). But switch introduces triple buffering which would cause the same problem. So the fix- branch solves that too06:24
alf__duflu: do we always use triple buffering or only for framedropping and bypass?06:26
duflualf__: It's always triple now, logically. But I defer allocating the third buffer until the client behaves in a way that uses 3 simultaneously06:27
dufluThe lazy allocation is generalized... it keeps the number of real buffers low until more are required06:28
alf__duflu: sounds good06:29
* duflu shuffles monitors06:30
alf__duflu: hmm, how do you stop a client that is (or rather wants to be) double-buffered from acquiring the third buffer?06:33
duflualf__: I just realized the primary thing keeping it at double was removed when I fixed those issues on Friday. Now it's only timing keeping it at double. If a client tries to render without using a timer (limited only by swapping) then it will expend to triple very quickly now :/06:37
duflu-expend +expand06:37
dufluThat might need revisiting. I can add dynamic resizing without much fuss06:37
duflualf__: Multi-monitor just works, nice. If only I had a GUI to set the layout :)06:50
dufluOr a language... like "DVI1 leftof VGA1"06:51
RAOFdidrocks: Have we won a Mir promotion to Main?07:22
didrocksRAOF: it was too late on Friday and risky, so we pinned to proposed. The promotion/publication is now in progress07:23
RAOFdidrocks: Cool. Sorry about that delay.07:23
didrocksRAOF: no worry ;)07:24
dholbachgood morning07:32
RAOFHm. Zoë bath time!07:43
=== hikiko is now known as hik|afk
duflualf__: Just a minor speedhump: https://bugs.launchpad.net/mir/+bug/120835408:17
ubot5Ubuntu bug 1208354 in Mir "mir_demo_server_shell crashes with --display-config=sidebyside" [Undecided,New]08:17
alf__duflu: ahh, yes this is fixed by lp:~afrantzis/mir/multimonitor-misc-fixes ⇒ lp:mir (will hopefully land soon)08:18
duflualf__: Very nice, thanks08:18
=== hik|afk is now known as hikiko
didrocksRAOF: still around?08:32
RAOFdidrocks: Yeah.08:39
didrocksRAOF: see #ubuntu-devel please :)08:40
RAOFdidrocks: Ah, I see #ubuntu-devel.08:40
didrocksheh ;)08:40
seb128can we just drop ppc? :p08:40
didrocks+1000 :p08:41
=== dholbach_ is now known as dholbach
duflualf__: I will have most of your requests resolved tonight but not all... At least multi-monitor is fixed, without breaking bypass \o/09:51
alf__duflu: great!09:52
tvoss_duflu, \o/09:58
dokoSaviq, ping10:24
Saviqdoko, pong10:26
alan_ghikiko: how's it going?11:05
hikikoalan_g, I started from create display11:18
hikikoand now I am writing a NestedDisplay class11:18
hikikodo you think I should do something else first11:19
alan_ghikiko: that sounds a sensible approach11:20
=== alan_g is now known as alan_g|lunch
=== alan_g|lunch is now known as alan_g
=== bregma_ is now known as bregma
greybackracarr: morning!14:29
=== alan_g is now known as alan_g|tea
racarrgreyback: Morning! welcome back14:30
greybackracarr: thanks :)14:30
racarrgreyback: I'm sure you are still catching up but maybe we should do a catch up soon?14:32
racarrI was kind of doing other stuff last weekly so expect for some stuff for OSK mostly not on unity14:32
greybackracarr: certainly. Whenever you're ready14:32
racarrso kind of lost track of exact status14:32
greybackYep I'd like to know where the OSK work is at14:32
racarrgreyback: Ok after the 8:00 mir stand up maybe?14:32
greybackDaniel is away, so I need to at least know what it's status is14:32
greybackracarr: perfect14:32
kgunngreyback: racarr can i lurk on your sync?14:46
greybackkgunn: sure14:46
racarrkgunn: Eh...14:50
racarrit's kind of "cool crowd only"...so I dunno14:50
racarrI am just teasing. Have a good time in IoM?14:51
kgunnracarr: consider we were the only people at that hotel under 60.... :-/14:52
kgunnracarr: we did gointo town one night...me ancell, didier & michal... food was sooo good & company was good :)14:54
=== alan_g|tea is now known as alan_g
racarrkgunn: Aha. that must have been a little strange (hotel situation)14:59
kgunndidrocks: just checking in...did RAOF overcome the alioth issue14:59
kgunnracarr: it was bizzare14:59
didrockskgunn: he did, and so we have everything uploaded14:59
didrockspromoted some components to Main14:59
didrockshowerver, multiples upload from him and I to ignore properly powerpc14:59
didrockshowever, on two components15:00
didrockswe still try to build with mir for the -ati and -nouveau driver15:00
didrocksso this one should be fixed, RAOF assume this wasn't needed (but it wasn't built) when I asked him15:00
didrockswe can:15:01
didrocks- either do a bad/ugly #ifdef15:01
didrocks- let RAOF fix it more properly (I would be more in favor of that)15:01
didrocksthe second point is that unity-system-compositor don't enable accceleration anymore on the intel or ati machine15:01
didrocksso even unity doesn't start15:01
kgunndidrocks: good ol' powerpc :)....ok, that stinks  about new prob15:02
kgunndidrocks: did you really mean intel ? or nvidia rather15:02
didrocksnvidia, sorry :)15:03
didrocksI can't even use jetlag as an excuse15:03
didrockskgunn: for powerpc, I'll be in favor of guns if this continues that road ;)15:03
didrocksI'll send an email with you/RAOF/robert15:04
racarrgreyback: Sync up?15:25
racarrkgunn: ^15:25
greybackracarr: ok15:25
kgunnracarr: gotta link ?15:26
racarrmaking one15:27
racarrkgunn: greyback: ^15:27
kgunnricmm: ^15:28
kgunnracarr: were you going to refactor down to singled method interface first ? or try chasing some approval on the current mp ?15:56
racarrkgunn: i am not sure16:05
racarrI am not throwing up my hands (actively thinking about it) but am kind of at a loss on both branches as it stands16:06
racarrThe single method variant is awkward, because like in the comment I just left16:08
racarryou end up applying the surface state changes, etc, before you actually update the member variable tracking the state16:08
racarrand there are all sorts of ways around that (i.e. the function returns the new state, and an std::function to apply it which the surface then calls after updating the member variable. Or the configuration interface gets some object/function passed in that it uses to update the surface state in between the selection and application step16:10
racarrbut both of these just mean, instead of an interface with two roles it's now a method with two roles.16:11
racarrso I am not sure this makes sense.16:12
racarrI also can't make an argument that it makes sense to split each method in to a seperate interface, i.e. AttributeDecider and AttributeApplier because16:13
racarrthey will always be passed around in a pair in the server16:13
racarrso pattern is to pass them as a composite type i.e. some AttributeStuff, which has ethods like decider() and applier()16:14
racarrbut then it's not clear why that method doesn't just have decide, and apply, like the configurator does now in the MP16:14
racarrI think it's probably somewhat more of an indication tht the way we are handling state of msh::Surface is bad16:17
racarrso I guess I am seeing if there is something I can do about that for the attribute stuff without taking more than a few days16:18
racarralan_g: A completely different proposal for surace-configuration-interface16:24
racarralan_g: msh::Surface loses the state, type, etc member variables16:24
alan_gracarr: sorry, my head is full of ~vanvugt/mir/switch/+merge/17852716:24
racarrthat's ok :)16:24
alan_gBut that sounds interesting16:25
racarralan_g: Basically the thought is if mir is only passing these values through the shell and frontend perhaps it should be a shell component that stores them and mir just passes interfaces to this component for getting back out to frontend16:26
racarrbut it's not too much hassle so maybe I will just try and implement it and you can check it out later :)16:26
racarrswitch branch scares me ;)16:26
racarralan_g: btw if you are ever bored remind me to tell you about the craziest (most interesting ;) idea I have ever heard for handling mutable state in highly threaded C++ programs XD16:29
alan_gracarr: The problem of where to store these values (and how to synchronize access to them) dates from the decision to hold them in the shell, and not in the model.16:29
racarrit needs GC though so it's not for us. it's just really interesting16:29
alan_gracarr: I'll take a raincheck16:29
racarryeah, I understand that bit sort of16:30
kgunnracarr: maybe kdub can take a peek this afternoon16:31
racarrYeah. I'll harass him ;)16:32
racarralan_g: This might be a step in that direction, i.e. rather than the surface holding this state directly it gets it through some get_attribute and set_attribute interface to this SurfaceConfiguration from the shell16:33
racarrwhich could also be implemented by16:34
racarrsuper scene graph model 2.0 :p16:34
alan_gracarr: I know I need to get back on that hobbyhorse16:34
alan_gAnd actually propose something concrete.16:34
racarralan_g: Ok. That would be good16:35
alan_gIf only folks would stop with the big complicated MPs16:35
racarrI haven't been able to get to anything concrete on that16:35
alan_g... ;)16:35
racarrand I am worried that we are16:35
racarrapproaching feature freeze16:35
racarralan_g: I.e. feature freeze is august 29th16:37
kdubracarr, peek at notify focus? or switch16:37
racarrkdub: Err, the surface-configuration-interface16:38
racarrit doesn't exactly need review, just ideas I guess16:38
kdubracarr, i'll refill my coffee and take a look now16:38
racarrkdub: Ah. excellent. Thanks :)16:39
kgunnbschaefer: are you free-ish today ?16:42
bschaeferkgunn, a bit more ibus stuff to do, but after that I should be16:42
bschaeferkgunn, still trying to get my desktop back up and working :(16:42
kgunnbschaefer: oh crap16:43
kgunnbschaefer: but ok...i'll loop you in16:43
bschaeferyeah, my HD decided to die and can no longer read/write to it...soo its toast :(, but i've to reinstall some new things to a new HD!16:43
bschaeferkgunn, sounds good!16:43
kgunnkdub: racarr ...yeah, hate to be the management ogre....but we really need to target gettting unity/mir onto touch trunk (w/ osk consideration) 10 days from now16:46
* racarr takes one of the little pills labelled "Up"16:47
racarrAnother option for client-focus-notifications16:53
racarrsurface loses surface_state_focused/unfocused. introduce an interface msh::Focus with one method Focus::give(std::shared_ptr<msh::Surface>)16:54
racarrthis obect tracks the current focus, so it can do unfocused notifications16:55
racarrit also needs to know to give the focus to the next surface if16:55
racarrthe focused surface is destroyed, so I think msh::Surface also gains a method like16:55
kdubracarr, the cloggable event sink16:55
kdubi still feel like i'm missing the big picture on the 'why'16:56
racarrwith a d'tor that knows what to do16:56
racarrkdub: Basically the idea is inbetween the call to create_surface16:56
racarrand sending a response to the client16:56
racarrwe may generate surface configuration events16:57
racarri.e. surface id 7 took focus16:57
racarrbut if we send this to the client before it's been told what surface id 7 is16:57
racarrit can't interpret it16:57
kdubah, gotcha16:58
racarrso we have to ensure the wire events are sent after the create_surface response16:58
racarrkdub: it's a little sketchy actually because it relies16:58
racarron the fact that invoking the Done callback from create_surface16:58
racarrsynchronously writes the message.16:58
kdubseems like the object with the best information to control that timing is the msh::Surface17:00
kdubperhaps the SessionManager as well17:00
racarrhmm, not as it stands now, because even after SessionManager::create_surface_for17:00
racarrthe SessionManager can't know if things have been sent over the wire yet17:00
kdubright, so it seems the shell has a false idea about when a surface is up and running17:01
kdubmaybe msh::Surface should have the same lifetime as the client surface on the other side of the ipc barrier?17:02
kdubthat way a focus event could block there until we know the client is ready17:03
kdubalternatively, we could just have more complex logic client side17:04
racarrI think you can always end up with17:04
racarrsituations where the client can't decide? Maybe not.17:04
=== alan_g is now known as alan_g|EOD
racarrif the client buffers the events and waits until the surface appears17:05
racarrthen it can't really detect events which are actually malformed/in error17:05
racarrkdub: The lifetime idea is kind of nice but I'm not sure how it would be implemented17:06
kdubi guess we have two responses now to that rpc call17:06
kdub'you are focused' or 'you are not focused'17:07
kdubthat would take care of it too :)17:07
racarri.e.  you construct all of the surface dependencies, allocate the id, make sure everything works, send the response and then allocate the msh::Surface17:07
racarrkdub: Not quite because a surface may open and not necessarily receive focus17:07
racarror maybe it opens and the shell restores it's state to maximized17:07
racarrbecause that's how it was last run17:08
racarrso there could be many responses I think17:08
kdubright, the surface opens and is not focused17:08
kdubat the time the surface is created, we should be able to know the state of the surface17:08
kdubseems that should be sent as the initial state in the return of the rpc message17:08
racarrok, so the current model is kind of like, the initial state is defaulted17:09
racarri.e. your state is restored, your surface type is normal, you do not have focus17:09
racarrand you will be notified of anything else17:09
racarrso we could extend create surface to return like17:10
racarrsurface_id, state, type, focus17:10
racarrbut then wont e still need a proxy event sink?17:10
racarrBecause we have to ensure that later when these change17:10
kdubthat seems like a separate issue17:10
racarrwe still send notification17:10
kdubthe event sink still has to be accessible to the shell surface, yes17:11
racarrbut that we don't send notification on this first call17:11
racarrbut I mean, the surface will still be created in the default state17:11
racarrso what makes the first change to 'focused' occur as part of the create_surface reply17:12
racarrand not as an event over the wire17:12
kdubthe shell decides the initial state when the surface is created17:12
kdubor :) it should be17:12
kdubthat gets sent in the reply, and afterwards, any updates to the state are sent via the event sink17:13
racarrkdub: I think it's hairy for the shell to decide that way17:14
racarrbecause now essentially any interface like17:14
racarrkdub: Ok, I was thinking17:15
kdubas opposed to deciding state after creation, and imposing synchronization across/near the ipc boundary so the client can figure out what state its in? :)17:15
racarrit had to happen before surface construction, but actually it could happen17:15
racarrkdub: Well my concern s that doing it before surface construction was difficult because then the shell will have methods like17:16
racarrdecide_state_for_surface_creation_params and decide_state_for_surface17:16
kdubright, not before17:16
racarrkdub: But actually, the surface could use the SurfaceConfigurator from the other branch (XD)17:17
racarrer welll I still cant quite figure it out but will go on17:17
racarrthen in it's constructor it calls like17:17
kdubipc request comes in, we ask the shell to create a surface, we read the created surface, and then we run done17:17
racarrstate = select_attribute_value(surface_state)17:17
racarrtype = select_attribute_value(type) focus = select_attribute_value(focused)17:17
racarrand it doesn't go over the event sink because there was no call through to msh::Surface::configure17:18
kdubsounds better17:19
racarrkdub: Ok so.I think this makes sense, but now I am having a little difficulty figuring out how the mechanism happens17:20
racarrkdub: i.e. the surface is being constructed17:21
kdubi think we need some extra fields in protobuf's Surface17:21
racarrso the shell gets select_focused(msh::Surface &)17:21
racarrand says, hey this is a new surface, so it says yes, focused17:21
racarrbut now what actually sets17:21
racarrthe input focus to17:21
racarrthat surface17:21
racarrI'm not sure if it makes sense for17:21
racarrit to be select_focused because17:22
racarrthe surface isn't even initialized at that point.17:22
kdubwe need to ban the use of the word 'surface' :)17:23
kdubit isn't initialized where?17:24
kdubclient side?17:24
racarrno, I meant, on the server, if we use some interface like17:24
racarrselect_attribute_value(focused) that is called during the constructor17:24
racarrand no one is notified of this17:24
racarrthen what actually sets the input focus17:24
kdubfrom the frontend, i see this17:27
racarrkdub: Ok.17:29
racarrkdub: trying to reword the last concern.17:29
racarrthe thing is, right now the FocusMechanism, sets the focused attribute on the surface17:29
kdubokay, yeah. i sorta detected we were talking about two different parts of code17:29
racarrafter, applying the mechanism of the focus of the surface. i.e. making sure it's on top and giving it key focus17:30
racarrso, if the surface instead takes the focused attribute itself during creation17:30
racarrthen what actually17:31
racarrdoes this giving key focus, etc step.17:31
kdubracarr, don't know where that question ended :)17:34
racarrerr, sorry17:34
racarrI mean which component, or hwere in this flow17:34
racarrdo we actually set the key focus17:34
racarrbecause there is no17:35
kdubbeen reading through a bit of the code more17:35
racarrmsh::FocusSetter::set_focus_to(msh::Surface) now17:35
racarras the only entry point for focus changing17:35
racarr(when I say now, I mean, in this select_attribute_value model)17:35
kduband really, i think in msh::SessionManager::create_surface_for, it calling set_focus_to is probably in the wrong place17:35
kdubmy head's currently exploding with 'hey, a std::future seems perfect for this sort of thing' :)17:36
racarrthe call to set_focus_to is wrong I agree17:37
racarrthat should be entirely shell policy it's just there so we could have focus before we had a shell or example servers17:37
kduba notification after SessionMediator::create_surface's done->Run() to the focus setter seems appropriate sorta17:37
racarrI was thinking about that, or even right before i.e. say17:38
kdubwith the idea, 'hey Focus stuff, time to reconsider who has focus'17:38
racarrsurface = create_surface()17:38
racarrand then like17:38
racarrthen it returns to the SessionMediator (not sure it needs to happen after done->Run())17:39
racarrbut, what does this function apply_surface_attributes look like? I mean it's not an interface because it's just...do_stuff(surface)17:39
kdubmight not be, just musing a bit17:39
racarrand is it supposed to be written like17:39
racarrswitch (surface_state): case maximized: unity_maximize_surface(), .... swtich(surface_focused): case focused...17:40
racarrkdub: Yes. thanks for the musings :) this is helpful17:44
kdubracarr, no problem :)17:47
racarrkdub: The CloggableEventSink solves another problem too17:48
racarrwhich is, say we have sorted out this focus stuff by setting it as part of construction, or even without client-focus-notifications17:49
racarrSo, the SessionMediator invokes create_surface, then before calling done->Run()17:49
racarrthe thread yields17:49
kdubright, and then the shell changes focus17:50
kdubin the time period, or something17:50
racarryeah or maximizes the surface or whatever17:50
kdubEventSink, primarily, is not an interface which has any synchronization guarantees, its purpose is to send messages17:50
kdubi think a richer synchronization17:51
kdubeven 'client ready for events' on msh::Surface, that is invoked after done->Run makes a bit more sense17:51
racarrI think the CloggableEventSink keeps it that way though, it's still not providing any synchronization guarantees to the msh::Surface, it's just sending messages17:51
racarrit's only the SessionMediator that knows about the synchronization17:52
racarrbut hmm, yeah17:52
kdubright, so why not synchronize between SessionMediator and SessionManager then17:52
kdubinstead of synchronizing between SessionMediator and EventSink, so that SessionManager can sync with Event sink too later :)17:52
racarrhmm, how17:53
racarrI guess I see two ideas, one could be maybe msh::Surface contains some attribute17:54
racarrand it buffers the configuration events itself (i.e. like the cloggable event sink does now)17:55
racarrthis was my original idea actually, but I was worried that this17:55
racarrdistributes frontend state in to shell, i.e. msh::Surface doesn't really care what state the socket is in17:56
racarrso I thought maybe the SessionMediator should be responsible for17:56
kdubwell, msh::Surface cares that a surface has been created17:56
racarrmediating the IPC synchronization requirements, with the msh::Surface interface. if that makes any sense.17:56
racarrI like the idea of17:56
racarrnot creating the msh::Surface17:57
racarruntil we have sent the response, i.e. like17:57
racarrauto params_attributes_and_id = SessionManager::create_surface_for(session, params)17:57
racarrpack_response(); done->Run()17:57
kdubright, i just considered the id as part of the parameters above :)17:58
racarror something?17:58
racarrwhich creates the actual msh::Surface17:58
kdubhaha, self_actualize(), reduce_karma(), balance_chi()17:58
kdubalan would love those names ;)17:58
racarrmir::shell::SurfaceEnlightener ;)17:59
racarrhmm ok. So I actually like this a fair amount my main concern is like17:59
racarrwhen are the other resources initialized, and such i.e.17:59
racarrin particular in error cases17:59
racarri.e. what if we fail to allocate the buffers18:00
racarrit seems strange that we have already told the client they have received a surface18:00
racarrand im not entirely sure how we report the error18:02
racarrbut that's probably sortable18:02
racarrI still don't know how to make the focus mechanism work in this model though...18:05
racarralso there is daniel's need fixing on not using attributes at all for focus :p18:05
racarrbut even if that becomes something entirely seperate from EventSink18:05
racarrwhatever this thing is will still need synchronization18:05
kdubracarr, if you take a look at the way i'm sending display info18:18
kdub(my MP up for review)18:18
kdubwe can send things via protobuf a bit easier18:18
racarrkdub: ok ill check it out after lunch18:22
racarrlunch nowww18:22
bschaeferkgunn, hey, soo I saw that email, so ati, and nvidia are having problems starting up19:13
kgunnyes...so it seems19:13
bschaeferrobotfuel, are there any machines that I would be able to ssh into?19:13
bschaeferstrange indeed...and it looks like compiz is hanging on loading opengl...19:14
robotfuelbschaefer: it looks like ps-radeon-hd6870-he is open19:17
bschaeferrobotfuel, awesome, thanks!19:17
robotfuelbschaefer: ps-nvidia-gs8400-le is also open with xmir on it19:18
bschaeferperfect, now hopefully I can figure something out :)19:18
robotfuelbschaefer: that one seem to work with xmir, the nvidia-gt640  had a black screen last week, today it's been doing a utah death test.19:21
bschaeferrobotfuel, its fine to install u-s-c on the radeon one right?19:21
* bschaefer checks if its running or not19:21
bschaeferrobotfuel, hmm the radeon machine appears to be working19:22
* bschaefer reboots just to check19:22
robotfuelbschaefer: I don't think the radeon machine has xmir on it, but it passed some phoronix tests this morning19:22
bschaeferrobotfuel, whats the utah death test do?19:22
bschaeferrobotfuel, well it had the mir serve rrunning in the background...19:23
robotfuelbschaefer: it tries to kill utah19:23
bschaeferhmm yeah:  /usr/sbin/unity-system-compositor --enable-input=false --from-dm-fd 9 --to-dm-fd 13 --vt 719:24
* bschaefer double checks the x log19:24
bschaeferyup so, the redeon machine appears to be working19:25
bschaeferand its using the u-s-c testing ppa19:25
bschaeferkgunn, ^19:25
* bschaefer looks at nvidia19:26
robotfuelbschaefer: ok, I wasn't sure because of the last test run on that radeon machine, the non-xmir job ran after it and must have failed to provision the machine. but it's on an old jenkins server with known cobbler issues. The new jenkins machine has it's own cobbler server. :)19:28
=== om26er is now known as om26
=== om26 is now known as om26er
bschaeferrobotfuel, cool :), well im also going to go and make sure things are updated as well19:29
kgunnbschaefer: ? now i wonder what didrocks might have seen....whether or not it was on these machines....or some others19:33
bschaeferkgunn, well it seems like there are some updates...19:33
kgunnbschaefer: so it healed itself ?19:34
bschaeferkgunn, well im not sure, these updates could throw it all off :)19:34
bschaeferit would be strange if it did though19:35
bschaeferkgunn, hmm well the nvidia gs8400 seems to be fine, now to go update the radeon one...19:37
bschaeferI hope they don't just heal them selfs though...as when things do that they usually break again19:37
olli__in which BP is the bypass work captured?19:38
=== olli__ is now known as olli
ollikgunn, kdub ^19:38
* kgunn digging19:39
kduboh, blueprint, not mp :)19:39
ollithx guys19:39
bschaeferkgunn, robotfuel and updated radeon is working as well...19:45
bschaeferhmm possibly didrocks was running into something that was fixed already?19:45
bschaeferyes indeed...19:47
kgunnrobotfuel: so you got the standalone X runs of phoronix across all the new platforms ?19:49
kgunnbrb guys...19:50
robotfuelkgunn: we are testing utah first to make sure it's stable. I setup all the machines on friday to do a death test on the utah and found we needed more loop devices on the new server, I want to get 100 test runs with the new server config before we move to start testing X.19:51
kgunnrobotfuel: do you mean 100 utah death test runs20:33
robotfuelkgunn: yes, we are at 28 of 100 now. so we can start the X testing tomorrow if we have utah stable.20:35
ollikgunn, robert_ancell, RAOF, what's the status of upstream acceptance? I see activity on all but nouveau and mesa, how far/close are we?20:46
olliand I admittedly only looked into the July archives ;)20:46
robert_ancellolli, otp, be back in 520:46
ollirobert_ancell, ack20:47
kdubyay, found a spare monitor in the garage20:56
robert_ancellolli, RAOF is not online yet, but I think he said good progress on the X patches. I don't think any high level "would we accept this" has been done yet, more "does this work correctly"21:04
robert_ancellolli, at least some of the patches are not complete enough for upstream to consider landing them, I think mesa was in that case21:05
ollirobert_ancell, mind following up when he is on and then either update me via mail or directly in a slide that I will ping you21:05
robert_ancellolli, yep, will ask him when he comes online21:06
ollirobert_ancell, you should have received a ggdoc mail with the doc21:07
robert_ancellolli, looking..21:07
ollirobert_ancell, thx21:08
kdubwhoohoo, display resize requests are working reasonably well... few dings to hammer out21:50
kgunnkdub: that's great....feeling better about multimon by the moment21:50
RAOFolli: Nouveau will be easy, once the Xserver patches land; we only need to satisfy mlankhorst there ☺23:21
RAOFolli: I need to give mesa a prod, but I'll do that once I can include radeon support in there - the dma-buf patch to make that work is now on the lists (*all* the lists!).23:22
robert_ancellRAOF, hey, does XMir need any updating to work with the display configuration changes in mir r925?23:30
RAOFrobert_ancell: Shouldn't, but we should now be able to actually do RANDR.23:31
kdubno, not yet :)23:32
robert_ancellRAOF, I just tried the latest mir+u-s-c combination for the system-compositor-testing PPA, but X doesn't seem to complete starting up23:32
robert_ancelli.e. black screen23:32
RAOFkdub: I think there's enough there to do the read-only bit of RANDR, at least.23:32
kdubthat just gets across the ipc barrier, still working on the server-side display configuration (focus based)23:32
kdubnot all the bits are hooked up serverside, should be soon though23:33
RAOFrobert_ancell: I'll have a look.23:34
robert_ancellI'm just recompiling X here just to double check23:34
RAOFI did fix a problem where libmirclient would segv, but you're obviously not seeing that.23:35
bschaeferrobert_ancell, what card are you on? As I tested out ati/nvidia today and both were working23:40
bschaeferthough there were some reports of black screening from didrocks...23:40
robert_ancellbschaefer, intel23:40
bschaeferhmm well hopefully rebuilding X fixes that :)23:40
* kdub tried intel today, at least the basic mir test programs seemed ok23:41

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!