#ubuntu-mir 2013-04-22
<duflu> robert_ancell: Did you notice I had a go at the strings-on-the-protocol issue? https://code.launchpad.net/~vanvugt/mir/method-index/+merge/159782
<robert_ancell> duflu, yeah, I've got a branch where I converted it to an enum
<robert_ancell> duflu, the RPC code is yuck though and we could probably get away without it
<duflu> robert_ancell: Yeah I think we would need to avoid strings... if we were to go to a more efficient transport in future. But not yet
<robert_ancell> I am so sick of seeing "Internal compiler error: Error reporting routines re-entered.
<robert_ancell> "
 * duflu has never seen it
 * RAOF wonders if he should try defaulting to gcc 4.8, which doesn't suffer that.
<robert_ancell> RAOF, yes, we should if 4.8 is available and not broken
<RAOF> 4.8 is available in raring, will be default in S, and isn't broken (in that way âº)
<robert_ancell> RAOF, are you sure it is in raring - it's not showing for me
<RAOF> It's packaged as gcc-snapshot
<robert_ancell> hmm, that doesn't sound like something we should depend on. We can shift when we go to S I guess
<robert_ancell> RAOF, btw, is XMir working? I tried it on Friday and was getting the "no screens" error
<RAOF> I wasn't suggesting that we default to it in the build, but locally you could easily install and use it, and not get stupid ICEs.
<RAOF> XMir worked last time I tried.
<RAOF> Oh, no it didn't; I need to fold in a new package. You probably don't have an xmir server installed.
<robert_ancell> RAOF, I did downgrade to the latest XMir package but it wasn't connecting
<RAOF> Hm. *That* did work on my machine. Let me check...
<RAOF> Bah! I wish launchpad was updated to something more recent than Hardy.
<RAOF> Then I could use a bzr builder recipe version 0.4, which means I could use {debver:packaging} in the version, which means I wouldn't have to change the recipe each time someone uploads xserver-xorg-video-intel to Ubuntu!
<kdub> good morning, status, friday worked on hwc1.0 for galaxy nexus, will continue with that today. going pretty well
<kgunn> kdub: mornin'
<alan_g> Good morning
<alf_> status: some performance investigations, but mostly getting laptop ready for sprint
<alan_g> status: having a look through our generated documentation (and learning a bit more about doxygen)
<alan_g> BTW does anyone know how frequently http://unity.ubuntu.com/mir/index.html is updated? It seems to be some days behind the trunk.
<racarr_> Morning
<racarr_> Working on touch/pointer input
<racarr> alf_: I am workingon a software cursor and need some APIs to
<racarr> damage the compositor
<racarr> seperate through the renderables
<racarr> to trigger rendering
<racarr> any ideas?
<alan_g> racarr: I think alf_ was the last one to rework that area.
<alf_> racarr: alan_g: so basically two options: 1. Pass an object to the compositor and register a notification internally (like we do for renderables currently) 2. Expose e.g. Compositor::damage() and call it when the cursor moves (that is make the cursor depend on the compositor)
<racarr> Compositor::damage seems more appropriate for me because in this case
<racarr> the shell is rendering the software cursor
<racarr> via overriding the compositing strategy
<racarr> Fixed gmock warnings on reflow-input-focus-selection
<racarr> alan_g: So the crash in demo shell
<racarr> is the shared_ptr to the Eventfilter which is returned via initializer_list from the server configuration
<racarr> is released in the process of being passed from DefaultServerConfiguration to InputConfiguration
<racarr> I can't understand it to the point where I think it might be a G++ bug
<racarr> :/
<alan_g> racarr: That sounds wrong. Give me 10 and I'll have a look.
<racarr> thanks :)
<racarr> I think it's actually lost in the constructor of eventfilter chain (when passingfrom DefaultInputConfiguration to EventFilterChain)
<racarr> but either way it makes no sense :(
<kdub> alan_g, maybe thomi would know about how often the doc site is updated, i'll ask when he signs on later
<alan_g> racarr: you're saying the shared_ptr to the initializer list is OK, but the one *in* the initializer list gets reset?
<racarr> alan_g: Err there is a shared_ptr to the initializer list?
<racarr> isn't it passed by value
<racarr> what I mean is, the_input_configuration calls the_event_filters and in gdb you can observe the_event_filters returns an initializer list
<racarr> with a shared_ptr as it's first member
<racarr> and m_ptr as non zer0
<alan_g> racarr: sorry, misreading the code
<racarr> then it gets passed to the input configuration constructor
<racarr> and it also non zero
<racarr> when it's passed to the EventFilterChain constructor
<racarr> the initializer list is empty
<racarr> and the EventFilterChain later attempts to call a method on the event filter (0x0)
<racarr> well, it's not empty
<racarr> it contains one member, a shared_ptr with m_ptr = 0
<racarr> alan_g: Just pushed a revision (604) which you can see fixes it by moving ownership to main
<racarr> but why?
<alan_g> racarr: It still doesn't make sense
<racarr> alan_g: I think it has to be a GCC bug :/ I du nno
<racarr> I went through with valgrind etc...
<alan_g> racarr: the initializer list captures by reference, but and the reference is to a temporary std::shared_ptr<mi::EventFilter> created in the function call. Because app_switcher is a std::shared_ptr<me::ApplicationSwitcher> and needs conversion to std::shared_ptr<mi::EventFilter>.
<racarr> but the initializer list
<racarr> should own that reference
<racarr> until it passes it to the vector of std::shared_ptr<EventFilter in EventFilterChain right?
<alan_g> racarr: temporaries don't exist after you leave the enclosing scope
<alan_g> I.e. return from the_event_filters()
<racarr> alan_g: Then why doesn't it work if I make
<racarr> the_event_filters a const member of DemoServerConfiguration
<racarr> err
<racarr> make std::initializer_list event_filters
<racarr> a const member
<racarr> and initialize it at construction time
<alan_g> Because, when you exit the constructor the temporary it references goes out of scope
<racarr> (not as in r604 where the list is created in main)
<racarr> Hmm
<alan_g> If you had a  std::shared_ptr<EventFilter> member you could pass a reference to that around in the initializer list
<racarr> that's what I was just going to say
<racarr> do you think its better to keep it like r604
<racarr> or to keep the app_switcher in the config like it was in 603 and just use
<racarr> shared_ptr EventFilter
<alan_g> Using initializer lists like this might be a bad idea. ;)  (I don't have the experience of them to be sure yet)
<racarr> that's what I was wondering...
<racarr> so I just tried
<racarr> constructing the app_switcher from main
<racarr> passing itto the demo server configuration (as mi::EventFilter
<racarr> saving it as a shared_ptr on the demo server configuratino and returning { event_filter }
<racarr> same problem
<racarr> I think r604 is the way to go :p
<alan_g> saving it as a shared_ptr on the demo server configuration ought to work - you didn't save a reference by mistake did you?
<racarr> no, const value
<bschaefer> Right now for KeyEvents I don't see a define/const saying if the key event is pressed or released for the event...besides checking if the event.action is true/false, have I missed something?
<bschaefer> err, event.action 1 or 0
<bschaefer> all I see is: test/mir_test/event_factory.h:29:enum class EventAction
<bschaefer> which isn't exposed to the C apis :(
<racarr> bschaefer: For now you can see them in
<racarr>  3rd_party/android-input/android_pristine/frameworks/native/include/android/input.h
<racarr> AKEY_EVENT_ACTION
<racarr> will try and get them added to a header in trunk
<racarr> I tried once but people argued about if they were needed yet until I gave up :p
<bschaefer> racarr, cool, yeah I had to print them out to figure out what was down/up so I can hold up and actually using a name fo ir
<racarr> :)
<bschaefer> racarr, yeah, well the action is an int32_t which...you can't do a nice enum with that :(
<bschaefer> racarr, thanks! Also one more question while you're around :)
<racarr> Sure
<bschaefer> racarr, soo for the cursor, how is mir going to be handling the 'themeing' of the cursor?
<bschaefer> or will that be left up to the client I suppose
<racarr> I don't entirely know ;)
<racarr> I guess the shell will eb responsible for the general themeing of the cursor
<racarr> but there are times where the clients need to request stuff, etc. or i.e. needs to change from cursor to text cursor...
<racarr> ill get back to you :p thanks for bringing that up
<bschaefer> yeah, I was just digging through what Ill have to do for the mouse, and saw that SDL was making the own theme based on the video :)
<racarr> bschaefer: I have a branch with a software cursor in mir but it's not uite ready to propose
<bschaefer> yeah, X11 does it a bit different where you just request the cursor? (I think) and wayland was doing it a bit differently
<racarr> and you need this branch to
<racarr> https://code.launchpad.net/~robertcarr/mir/enable-pointer-touch-input/+merge/160153
<bschaefer> racarr, sweet, I can give it run!
<racarr> receive motion events/pointer events
<bschaefer> nice, I should able to mock a cursor for now and get events working :)
<bschaefer> racarr, thanks!
<racarr> Cool! Let me know if it works :)
<bschaefer> racarr, will do! So far key events work well :)
<racarr> hurrah
<bschaefer> using scan codes from the events there was already a mapping of the xfree86_scancode_table2
<bschaefer> which was nice
<racarr> Hmm
<racarr> but then how are you getting things like
<racarr> $
<racarr> as shift + 4
<racarr> or does SDL do its own mapping
<bschaefer> SDL has its own mapping, but yeah I want to write some tests where it'll make sure all are working
 * bschaefer checks mod events
<bschaefer> racarr, you're right, not working :)
<racarr> I don't know how SDL expects it to work but my guess would be you need the keycodes -> SDL keycodes
<racarr> unless SDL can listen to shift down or modifiers or whatever itself
<racarr> and do the mapping
<racarr> but seems best to use the mapping from mir
<R__> you guys ported SDL to mir then?
<R__> or in the process?
<bschaefer> right, I need to use xkb and set the modifier, im thinking something like: xkb_state_update_mask
<bschaefer> R__, in the process
<R__> I hear SDL 2.0 is getting the final blessing in May
<bschaefer> racarr, theres a mapping form Mir already? Or are you talking about the xkb state from Mir?
<R__> think you'll get it merged?
<bschaefer> R__, that would be nice :), well...lets hope!
<bschaefer> racarr, and right, the SDL keycodes Ill have to do my own mapping now for the '$' stuff, but as along as I can get the correct keysym I should be fine
 * bschaefer looks into it
<racarr> bschaefer: Well I mean the mir key"code"
<bschaefer> thanks for pointing that out!
<racarr> is a keysym
<bschaefer> right
<racarr> so if shift was down and 4 is hit the key code
<racarr> will be XKB_KEY_dollar
<bschaefer> oo alright, so ill have to make my own mapping of the special mod + <key> symbols
<bschaefer> unless they are around somewhere
<racarr> ?
<racarr> the values for MirEvent::keycode are all in
<racarr> xkbcommon/xkbcommon-keysyms.h
<racarr> so I am guessing you can translate from like
<racarr> XKB_KEY_dollar to SDL_KEY_dollar and thats all that is needed
<racarr> unless that was what you meant by your own mapping :)
<bschaefer> racarr, well I was just saying Ill have to do my own mapping of that stuff
<bschaefer> yup
<racarr> should see how the wayland backend works
<bschaefer> racarr, unless theres like a magic -48 :)
<racarr> they are probably doing xkb in the client
<racarr> but there must be a translation somewhere
<racarr> bschaefer: Not normally, though almost all xkb keysyms are unicode characters
<racarr> so maybe SDL is the same way
<bschaefer> right, well whats strange is they only use the scan codes for input
<bschaefer> and then SDL_SendKeyboardText(text);
<bschaefer> for everything else
<bschaefer> soo, from what I see wayland doesn't handle sending: SDL_SendKeyboardKey of mod + <key>
<bschaefer> racarr, but I need to do some more digging, im fairly new to xkb as well :)
<racarr> you can use xkb_keysym_to_utf8
<racarr> to send text
<racarr> it wont always return a value
<racarr> i.e. KEY_left
<bschaefer> yup, thats what I was planning
<bschaefer> but im getting curious to why SDL_SendKeyboardKey seems to only be used w/o modifiers. From what I see they all use something similar  to the scan code mapping
<bschaefer> interesting...
<racarr> well maybe you send shift down to SDL and then send 4 to sdl and it maps itself
<racarr> I dunno
<racarr> would be a little weird but not the weirdest!
<racarr> but then who knows why its not working
<bschaefer> that would weird, but nice ;)
<bschaefer> but im not setting the mod in sdl, soo thats what im looking for
<bschaefer> hmm: SDL_SetModState(SDL_Keymod modstate);
 * bschaefer tires to use that
<racarr> bschaefer: You can find themodifier states in...qtubuntu/src/platforms/base/input.cc lol
<racarr> I'm not sure where else oO
<bschaefer> mir/include/shared/mir_toolkit/events.h is what im more or less stuck with :)
<bschaefer> SDL is in C
<bschaefer> and lol, a .cc file
 * bschaefer looks
<racarr> bschaefer: No but I mean you can
<racarr> copy them for now
<racarr> and they will end up in events.h soon
<bschaefer> yeah, i thought you were pointing to a header at first
<bschaefer> cool, I can look at doing some of that work as well
<racarr> nope just a hipster C++ file
<bschaefer> haha
<racarr> awesome yes :) propose away
<bschaefer> racarr, thanks for all the info! That'll give me a bunch to do today :), ill also test out your cursor branch later!
<racarr> Great :) np I am happy someone else is testing input
<thomi> hi kdub
<thomi> kdub: the docs should be uypdated daily - are they not?
<thomi> kdub: more specifically, they should get updated every time something gets merged into trunk
<racarr> Back from lunch :)
<racarr> thomi: https://jenkins.qa.ubuntu.com/job/mir-quantal-amd64-ci/474/console halp
<racarr> 404?
<thomi> racarr: how long ago did the build fail?
<racarr> uh within an hour
<thomi> racarr: it takes a few minutes to publish
<racarr> but I had the same problem on the first build that failed earlier
<thomi> should work, let me see
<thomi> racarr: got the MP link handy?
<racarr> https://code.launchpad.net/~robertcarr/mir/enable-pointer-touch-input/+merge/160153
<racarr> thomi: ^
<racarr> Had just run off to get it then I got distracted by firefox
<thomi> heh
<thomi> that's really odd
<thomi> neither the private nor the public jenkins have got to job 474
<racarr> what about their sentient jenkins love child?
<racarr> hmm
<racarr> I dunno.
<racarr> I could resubmit the branch
<thomi> racarr: do you have VPN access?
<racarr> probably resets some state
<racarr> yeah
<thomi> racarr: the job ran
<thomi> look here: http://10.97.2.10:8080/job/mir-quantal-amd64-ci/474/console
<thomi> there's your problem ^^ a failed test
<thomi>  93/112 Test  #93: memcheck(integration-tests.AndroidInputManagerAndEventFilterDispatcherSetup.*) ...***Failed    3.98 sec
<thomi> *sad trombone*
<racarr> Ahhh
<racarr> that isn't much of an Ahh because who knows why the test fails ;)
<racarr> lets look
<racarr> hmm
<racarr> gtest-repeat=100 is ok locally but
<racarr> that would be too easy if it were reproducable ;)
<racarr> I can't reproduce the memory errors either
<racarr> wish it had --track-origins=yes
<racarr> (though that is slow :()
<kgunn> racarr: hey, so i was chatting with dandrader
<kgunn> about possibly working on input filtering from the shell
<kgunn> e.g. filter edge events, pass the rest to whatever qt app is "beneath" the shell
<thomi> racarr: there seems to be an issue with publishing job data from the private jenkins, we're looking into it. Until we fix it, you can just look at the private jenkins server instead
<kgunn> in order to minimize any throw away & work on real integration issues
<kgunn> can't we run mir w/ ubuntu touch on top ?
<kgunn> we're not too early to try are we?
<kgunn> racarr: kdub ^
<racarr> kgunn: Just 3 minutes :) 5 things at once
<kgunn> ;)
<racarr> need to write down what I am doing or I will forget something
<racarr> Ok hi!
<racarr> hi dandrader :)
<racarr> I am going to go backwards
<dandrader> racarr, hi
<racarr> we can run mir w/ ubuntu touch on top, with the stuff kdub has set up (and this is continually tried) but this setup is using
 * kgunn dandrader in for some racarr entertainment :)
<racarr> surface flinger with input only windows shadowing the mir surfaces
<racarr> and mir input shut down
<racarr> err..
<racarr> well basically? Kevin can correct me
<racarr> but mir input is shut down so that configuration isn't ready for event filtering stuff
<racarr> I do not think we are too early to start trying to run ubuntu touch on mir
<racarr> I mean it is possible to take a Launcher.qml today and write a few hundred lines of C++ to run it in process and get it events
<racarr> an event filter can be plugged in for edge events, etc for the gestures
<racarr> normal events (i.e. clicked on a button)
<racarr> can just go over the normal input dispatch
<racarr> even though it's inprocess, it will be kind of wasteful it gets something going
<racarr> There is one blocker of some sort
<racarr> no in process EGL support on android
<racarr> not sure how much work that is
<racarr> kdub: ^ ?
<kgunn> racarr: mmm, so we'd be better off just to create some event filtering scheme in absence of mir
<racarr> But I mean, we can get things going on GBM
<racarr> kgunn: Hmm I'm not sure I mean I think this week/next week
<kdub> should have put the lunch nick on!
<racarr> is the time to really get this off the ground
<racarr> I'm trying to tie up a lot of loose ends now in demo shell + touch/crsor input stuff, and the basically what Mir can offer the shell for event filtering is
<kgunn> racarr: right...timing...so we're kind of close enough we might need to sus up mir input w/ touch on top first
<kdub> thomi, unity.ubuntu.com/mir seems to be out of sync with the doc folder
<racarr> a global event filter, where it sees the raw stream and can alter/filter it/whatever
<dandrader> one thing is that I would like an event canceling mechanism.
<racarr> and for shell surface clients (i.e. launcher dash, etc)
<racarr> they can receive events much like a regular client would (through Qt) and
<racarr> handle them or not
<dandrader> e.g. both shell and client application get touch events and once (if) shell recognizes a gesture it wants (out of the current touches) if would grab the gesture and the client app would be a event/gesture/touches canceled event
<kgunn> dandrader: mmm, are  you sure? have you considered shell _being_ the filter for both ?...i know you said replay touches expensive but shouldn't it be "gestures" not touches by then?
<racarr> hmm. sounds tricky
<thomi> kdub: ok, thanks - will investigate today.
<racarr> what if the client has already processed the event? It can't
<racarr> necessarily rewind what it has done
<racarr> so there are lots of situations there where
<racarr> the right thing happening is left open to a race of whomever recognizes the gesture first
<racarr> there are a few cases events can be cancelled
<racarr> i.e. removed by the event filter, cancelled before dispatch (by a sort of dispatch filter)...but this could allow events to go through to certain surfaces or certain shell surfaces while not allowing dispatch to
<racarr> occur.
<racarr> Then when events are unhandled
<racarr> they can be cancelled or retargeted
<racarr> I think...hmm. I think in the future if we want to get in to this sort of give client and shell event and let gesture recognizing decide who gets it
<racarr> we can extend the idea of event handling with some sort of score.
<dandrader> what I mean is the rationale explained here: http://lwn.net/Articles/485484/
<racarr> dandrader: This is describing sequential delivery though right? like the shell has a chance to see it and back up the stream
<dandrader> although it requires an application have logic to undo whatever it has done with the events of a touch point that got cancelled (because the shell grabbed it)
<racarr> then unflood them
<racarr> Yes. if we could count on applications
<racarr> to have that logic it would be a very cool solution
<racarr> but I'm not sure it's possible.
<dandrader> it's all about removing the latency involved in replaying a bunch of touch events to an application after gesture recognition is done by the shell and shell decides it does not want this touch point
<kgunn> dandrader: dumb question...so is there something on the qt i/f where an app says "handled" wrt touch events/gestures?
<kgunn> kgunn: it would seem you either make the shell the master, filter & replay...or you have some other detached monitoring object you can have shell & app
<kgunn> dandrader: both indicate to...."i've got it"
<kgunn> and avoid the replay
<kgunn> while at the same time avoiding having both shell
<kgunn> & app operate on the same event stream
<dandrader> a similar (but simpler) situation happens when you flick a list of buttons in a touchscreen. you press over a button and it goes to pressed state, but once you start dragging your finger vertically the flickable component takes over the touch point and the button receives a cancellation event. so the button gets "unpressed" instead of released (and therefore clicked) and the list scrolls
<dandrader> kgunn, no qt doesn't have that. if I understood you correctly
<dandrader> but, well, gotta go. let's continue the discussion tomorrow
<racarr> We can allow qt in the shell to have it perhaps though
<bschaefer> racarr, sweet, receiving mouse events :)
<bschaefer> racarr, also, it looks like you don't have to do the modifiers, as you are suppose to do that on the user side i guess...
<bschaefer> check if the event.mod & LSHIFT && SDLK_4 works for me for '$'...strange though...
<bschaefer> as how I was checking the "$" before was even failing in X11
<kdub> from the android side, if the first edition of ubuntu touch with mir underneath doesn't rely on qt, then we're ok from the graphics side
<kdub> android 'in process egl' is slated in the blueprints for ubuntu-13.07:
<thomi> kdub: docs uploading fixed - they should be up to date now (well, once the web cache times out anyway) - let me know if you see anything else amiss
<kdub> thomi, cool, thanks!
<racarr> test was failing due to uninitialize memory accidentally enabling
<racarr> pointer acceleration
<racarr> haha!
<racarr> Comment on https://code.launchpad.net/~robertcarr/platform-api/mirclient/+merge/160217 would be really appreciated
<racarr> if it seems confusing, please harass me and ask questions because a qt backend supporting input is something we need to move forward on quickly if we want to get the most out of next week :)
<racarr> Also does anyone have time to check https://code.launchpad.net/~robertcarr/mir/demo-shell/+merge/159253 out? alf is on vacation so it needs another review
<kdub> racarr, i'll review
<racarr> kdub:  thanks :)
<racarr> kdub: The crash in demo shell
<racarr> was due to initializer_list secretly capturing by reference
<racarr> so we had an me::ApplicationSwitcher
<racarr> and a temporary mi::EventFilter shared_ptr was created
<racarr> for the initializer_list
<racarr> then it was destroyed when the scope exited and
<racarr> initializer list has a bogus reference
<racarr> initializer_list is weird :p
<racarr> it's fixed now due to owning the list in main
<racarr> Anyone have any problem with me switching this to approved: https://code.launchpad.net/~robertcarr/mir/reflow-input-focus-selection/+merge/159225
<racarr> approve from alan + an old (addressed) needs fixing from alf
<kdub> racarr, looking it over... one min
#ubuntu-mir 2013-04-23
<robert_ancell> RAOF, did you have any luck with xmir working?
<RAOF> robert_ancell: I believe it should now; let me check again.
<RAOF> Unless launchpad has *once again* foiled me.
<robert_ancell> RAOF, the package did update for me, but still fails to connect to mir
<RAOF> Ok launchpad. Let's see what you've got for me...
<duflu> One _million_ bugs (pinky to mouth)
<robert_ancell> thomi, was CI supposed to work for lp:lightdm/1.6?
<robert_ancell> (two MPs, no checking done)
<racarr> I think
<racarr> I might try and port kmscon
<racarr> it seems surprisingly hard
<thomi> robert_ancell: no, I thought we decided that it wasn't worth it - but I can add it to the "things to do in Oakland for mir people" list, if you like :)
<robert_ancell> thomi, it's nice to have, but not a high priority
<thomi> yeah that's what I figured
<racarr> I just want to point out https://code.launchpad.net/~robertcarr/platform-api/mirclient/+merge/160217 to the southern hemisphere :)
<RAOF> racarr: Port kmscon? Why?
<duflu> Why not port anything you can? :)
<racarr> RAOF: I just want a working terminal emulator
<racarr> kterm isn't qt5
<racarr> this qml terminal emulator seems quirky
<RAOF> Does kmscon have all the various affordances we expect in a decent terminal emulator? Unicode? Colour?
 * RAOF goes to see why the new new build of xf86-video-intel doesn't XMir properly
<racarr> it seems to
<RAOF> Grr. Who changed the libmirclient API? :)
<racarr> who didn't!
<RAOF> Me~!
<robert_ancell> RAOF, any idea on XMir? So you also don't have XMir working on -intel?
<RAOF> robert_ancell: So, cascade of failures.
<RAOF> robert_ancell: The autobuilt xf86-video-intel defaulted to the SNA acceleration architecture, which I haven't yet patched for XMir.
<RAOF> Once I'd fought launchpad to get a build that defaults to UXA, someone had gone and remove mir_surface_create() from libmirclient, so XMir now doesn't work.
<RAOF> Both of these should now be fixed, and you're waiting for 1.13.3-0ubuntu6+xmir2 to appear in the PPA.
<RAOF> URGH
<robert_ancell> RAOF, ok, cool
<RAOF> thomi: Hey, while you're at it, could you get the tests to spin up an XMir server? :)
<thomi> RAOF: send me an email with the details and I'll look into it at oakland... or bug me about it in oakland :)
<RAOF> Most assuredly!
<robert_ancell> thomi, is there a convention for raising QA issues? Should we open bugs on LP projects and assign them to you?
<thomi> robert_ancell: it rather depends on the issue. There's no project that deals with infrastructure issues, for example
<thomi> and (thankfully) I'm not having to teach you guys how to write unit tests, so I've not had to actually touch the mir codebase yet
<thomi> I guess if we think we need a process to stop things getting forgotten about we should figure out what the best approach is
<thomi> my problem right now is that my time is split between mir and autopilot, and autopilot is consuming close to 90% of my waking hours
<robert_ancell> thomi, you can we awake for 190% of the time right?
<thomi> I tried that once, it did not go well
<robert_ancell> :)
<RAOF> Ok ladies and gentlemen: A brief bit of client architecture handwaving.
<RAOF> I'd like to implement n-buffering so that I can implement eglSwapInterval(0) so that the benchmarks we run can be minimally useful.
<RAOF> There are two broad approaches here - the client always has exactly one buffer, or the compositor always has exactly one buffer.
<RAOF> In the former you give out multiple buffers to the client library, and the client library is responsible for handling "do I block" and "what is the next buffer to draw to".
<RAOF> In the latter the server only ever hands out one buffer to the client library at a time, the client library always blocks on IPC, and the server is responsible for "what is the next buffer to draw to"
<RAOF> The former will have less IPC overhead, and will result in higher benchmark numbers, but the IPC overhead won't be significant for non-benchmark clients anyway.
<RAOF> You know what? email.
<robert_ancell> RAOF, yeah, email works for big stuff :)
<tvoss> RAOF, ping
<RAOF> tvoss: Pongity pong.
<robert_ancell> RAOF, well, X doesn't quit anymore. But it does sit at 100% CPU and never generates a ready signal
<robert_ancell> RAOF, short ML post from you...
<RAOF> The rest is coming soon.
<RAOF> robert_ancell: That's odd. Mine got all the way to showing the root weave and not responding to input because I didn't run it as root.
<RAOF> robert_ancell: To be clear - you get as far as the root weave, yes?
<robert_ancell> RAOF, no, black screen
<robert_ancell> RAOF, doesn't appear to be anything exciting in the X log http://paste.ubuntu.com/5594738/
<robert_ancell> RAOF, lightdm log, though also shows nothing except for it waiting for the ready signal http://paste.ubuntu.com/5594740/
<robert_ancell> but perhaps the command line flags passed to it might indicate something
<RAOF> Hm.
<RAOF> Let me see about this locally.
<RAOF> robert_ancell: Everything works fine here.
<robert_ancell> RAOF, :(
<robert_ancell> How are you launching it?
<RAOF> Xorg :7 -mir 5 -retro -verbose 7
<RAOF> Oooh! *That's* why VT switching sometimes takes minutes!
<RAOF> xf86-video-ati is totally freaked out that I've turned off the radeon on this laptop.
<mlankhorst> oooh I'm freaked outttt where is my card? where is my card?
<RAOF> Actually, it looks like it's also confusing radeon.ko, which is being amazed that it can't execute the ATOM BIOS.
<mlankhorst> how does it even find a valid bios, then?
<RAOF> Presumably it's cached the bios from boot?
<RAOF> The card was on at boot, and got switcheroo'd off.
<mlankhorst> ah
<robert_ancell> RAOF, ok, will look into that tomorrow
<robert_ancell> bye all
<mlankhorst> bb
<RAOF> robert_ancell: 'night!
<kdub> hello, status, mp-ed hwc 1.0 support, working on display logging today
<alan_g> hello, status, getting laptop in sync with current dev environment
<kdub> quiet day on the channel
<alan_g> kdub:I'm here if you need to talk
<kdub> lol
<racarr> morning
<alan_g> afternoon
<racarr> alan_g: Do you have any idea with demo-shell?
<racarr> I dont have any besides using a weak_ptr somewhere but I don'tknow where is appropriate
<alan_g> racarr: I've not been thinking about it today (got distracted elsewhere)
<racarr> Maybe EventFilterChain holds weak references
<racarr> to each EventFilter
<alan_g> racarr: since demo-shell tends to kill leave me with a blank screen I can't get out of I've been disinclined to play
<racarr> compared to regular mir binary?
<racarr> vince vt changes things are weird
<racarr> I have to kill it, then switch to X
<racarr> to get a screen back
<alan_g> racarr: I can do that with mir, but not with demo-shell
<racarr> uhoh
<racarr> oh
<racarr> well I just fixed the crash properly
<racarr> yesterday
<alan_g> racarr: I gather you agree about the "owner loop"? Or have I missed something?
<racarr> yes
<racarr> im just anxious to push things a long
<racarr> but I don't know how to fix it
<racarr> besides with a weak_ptr
<racarr> We are going to have these everywhere
<racarr> unless we introduce a new pattern
<alan_g> racarr: weak (or dumb) pointers can certainly break the loop
<racarr> i.e. the compositing strategy draws a software cursor so it becomes the cursor listener and needs to notify the compositor ofdamage
<racarr> alan_g: Yeahhh everything still goes in a circle though ;)
<racarr> I wish there were something better
<alan_g> there are solutions - e.g. a "RegisterMe" member variable that registers a callback in the constructor and deregisters in the destructor.
<alan_g> (The registered back-pointer can be a raw pointer, as its guaranteed to point to a live object)
<alan_g> The thing is that smart_ptr is being used in places where ownership isn't involved.
<alan_g> But my head isn't yet clear on where the fixes are needed
<racarr> Most ui frameworks would use
<racarr> a signalling pattern to break this
<racarr> i.e. rather than ApplicationSwitcher becoming the EventFilter, application switcher
<racarr> is allowed to see the KeybindingEventFilter
<racarr> and registers a callback or whatever
<racarr> the EventFilter keeps with weak reference, or the signal is expected to be disconnected on shutdown
<alan_g> If it's blocking you then using weak pointers in EventFilters ought to be enough for now
<racarr> alan_g: I will propose I think. the thing is it's blocking software cursor
<racarr> which has the same problem
<racarr> and over andover
<racarr> (propose with weak ptrs that is)
<racarr> you all are in for some excellent weather next week if things continue :)
<alan_g> Where we are working? Or out of the window?
<racarr> alan_g: ...hmm good point
<racarr> though when the day ends at 6
<racarr> still an hour and a half of time to have a beer in the sunshine!
<alan_g> We'll need to find a good beer location
<racarr> Hehe one night you should come to city beer, which is a store/pub type thing in  San Francisco (close to a bart though, about 25 minute travel from hotel)
<racarr> that is all local beers from the bay area
<racarr> nearly 100 I would say
<racarr> *embarassingly excited to be the local at conference for once*
<racarr> hehe
<alan_g> You'll be writing the guidebook then?
<alan_g> Anyway, I've had enough for the day. I'll start looking into managing back pointers tomorrow. (And finish getting laptop to behave.)
<racarr> alan_g|sun: I'm working on it, it's called "The Great American Novel: A software engineers guide to life in San Francisco" ;)
<racarr> not really i'd read that though
<racarr> enjoy :) tty tomorrow
<bschaefer> racarr, hello! Is this what you had in mind when moving some enums over to the mir_toolkit/event.h?
<bschaefer> http://paste.ubuntu.com/5596121/
<bschaefer> which then makes this easier: http://paste.ubuntu.com/5596127/
<racarr> bschaefer: https://code.launchpad.net/~robertcarr/mir/add-event-action-defines/+merge/160224
<racarr> ;)
<racarr> so yes!
<bschaefer> haha
<bschaefer> well awesome, beat me to it!
<bschaefer> racarr, did you want to type def them? Though it shouldn't be needed...
<bschaefer> racarr, nevermind, I see you've commented on that part :)
<racarr> bschaefer: We also need the modifiers
<racarr> but in adding them would like to add something using them
<racarr> so either demo shell after it lands (alt tab instead of tab) or
<racarr> maybe just tests that
<racarr> KEY_SHIFT comes out as mir_meta_flag_shift or hwatever its called
<bschaefer> right, tests for thest shouldn't be to bad if you can mock motion events and tests they line up with the correct enum (for a unit test)
<bschaefer> racarr, also, what about button state?
 * bschaefer also wonders if the input platform is subject to change from android
<racarr> bschaefer: button state too I guess
<racarr> hypothetically
<racarr> but
<bschaefer> racarr, well I suppose a lot of this can be talked about next week, but im more concerned about a changing input platform :(
<racarr> more likely is the increasingly forked
<racarr> droidinput loses the android name
<racarr> well
<racarr> its unlikely right! The abstraction exists
<racarr> but more as a consequence of writing testable well isolated object oriented code
<racarr> than an intention to replace the input backend
<racarr> but eventually once all the flags are in place, etc. and everything is defined ina  mir_ namespace
<racarr> that hides all the ANDROID* and android* and integer guessing stuff
<racarr> you could swap it out!
<bschaefer> oo yeah, I was just wonder about the enum ordering if the input is different as we can't control how they order their actions :)
<bschaefer> or I suppose if its forked we can :)
<bschaefer> right, and changing the enums (onces they are in place) will make that easy
<racarr> well if you are integrating any input stack you control in to the mir server you can have it emit events over the wire that look like MirEvent in terms of enums, etc
<racarr> and the worst case is some kind of marshalling, i.e. conversion
<bschaefer> right, I was thinking of sort of mapping to ensure a mir_motion_action_down is always 0
<bschaefer> for the action, but that can be done under the hood for the event.action I suppose (if it ever gets to that point)
<racarr> Yeah
<bschaefer> well that answers my question thanks :)
<racarr> Too much sun?
<racarr> I think the EventFilterChain holding each filter by weak reference is satisfactory in that case and actually
<racarr> the software cursor case I was giving was something entirely different
<racarr> it's already strange that the software cursor renderer has to subclass the compositing strategy
<racarr> i.e. reimplement all the drawing
<racarr> just to draw an overlay
<racarr> so there should be like
<racarr> the_overlay_renderer() which is passed a change_callback like
<racarr> the_renderables()
<racarr> are
<racarr> *babbles*
<racarr> kdub: https://code.launchpad.net/~robertcarr/mir/weakify-event-filters/+merge/160497 is aimed at the circular dependency
<racarr> indemo shell
<kdub> cool, will look it over soon
<racarr> Thanks :)
<racarr> now to untangle the software cursor one. I think I can do something more satisfactory than just a weak_ptr here with some work on the rendering interfaces
<racarr> Morning robert_ancell  :)
<bschaefer> racarr, an interesting bug im getting up a mouse released events. That button state is == 0 :(, no matter which key is being released
<bschaefer> a log: http://paste.ubuntu.com/5596683/
<bschaefer> racarr, if you can point me close to some of the mir code I can dig through it :)
<robert_ancell> racarr, hello
<racarr> Hi :)
<racarr> bschaefer: Hmm
<racarr> I'm not sure exactly where the culprit is! I mean one way to start is to write
<racarr> a failing integration test with the fixtures in tests/integration-tests/input/android/test_android_input_manager
<racarr> using the event_filter, rather than an actual server with clients
<bschaefer> racarr, cool, Ill look into getting a failing test
<racarr> you use the fake event hub to
<racarr> synthesize events
<bschaefer> yeah, I saw some fake MouseDown tests, but none for Up
<racarr> TEST_F(AndroidInputManagerAndEventFilterDispatcherSetup, manager_dispatches_button_events_to_filter)
<racarr> does the kind of thing you need
<bschaefer> sweet, thanks!
<racarr> but maybe write a new test rather than just expand it :)
<racarr> feel free to bug me about the APIs, etc :)
<bschaefer> alright :)
<bschaefer> racarr, I might have done the test a bit wrong, but it shows the button state always being zero:http://paste.ubuntu.com/5596922/
<bschaefer> http://paste.ubuntu.com/5596922/
<racarr> bschaefer: Yay! tests. Ok. Give me just 20-30 minutes to wrap something up and I will
<racarr> investigate
<bschaefer> racarr, alright, thanks!
<racarr> robert_ancell: The overlay renderer is for the software cursor.
<racarr> it could be a surface but I think it is less conceptually clear as it introduces a lot of
<racarr> other stuff, i.e. it has to be kept on top (double triple on top)
<racarr> and the way surfaces are rendered has to change
<robert_ancell> racarr, yeah, was just wondering if there were strong reasons like the hardware needs to know the difference
 * kdub has thought about overlays too
<robert_ancell> Also wasn't sure if you might need more than one overlay and then it becomes better to use surfaces with an overlay flag
<racarr> Hmm no no strong reasons like hardware in this case.
<racarr> I think if you want more than one "overlay"
<racarr> you implement that in your overlay renderer
<racarr> the idea is just this is a point for a shell to render, after mir has finished rendering the entire surface stack
<racarr> I think this is almost definitely how you want to do things like debugging visualizations
<racarr> with software cursor I considered another approach too...
<racarr> the shell could implement the_renderables, to contain a surfacestack, andfor_each first does for_each on the surfacestack then emits a renderable for the cursor
<racarr> but the renderable interface
<racarr> isn't really prepared to draw anything besides
<racarr> a surface...
<racarr> mostly due to the way textures are managed.
<kdub> racarr, with the overlay manager
<kdub> how do we coordinate the overlay with the surface stack?
<kdub> i guess i'm thinking in the more complex world of using the hwc with multiple layers to do overlays
<racarr> kdub: I don't know yet
<racarr> I would guess those are in the surface stack and maybe not "overlays" in this sense ovf overlay
<racarr> right like, a video overlay isnt an overlay in this sense of overlay
<kdub> yes, and that's sort of what i'm thinking about
#ubuntu-mir 2013-04-24
<racarr> mm
<kdub> like,  its common  for the software buttons on the nexus4 to be an overlay layer
<kdub> i guess we don't have to solve the problem now
<racarr> no it's interesting though
<racarr> I'minterested in starting to rework the rendering
<racarr> to explore the shell rendering effects, etc.
<racarr> might be related.
<kdub> yeah... its hard to abstract that
<kdub> 'this layer is quicker, but... you can't use a shader on it'
<racarr> Mm
<racarr> there are sort of two approaches to the shell and how it interacts with rendering and effects
<racarr> 1. Is the shell replaces the compositor, renderer, etc, does what it wants
<racarr> and 2. is the surface stack functions more as a scene graph and the shell is declarative about what it wants
<racarr> I think this functions as an argument for 2, where the shell would create an "overlay" layer inside the scenegraph (beefed up surface stack)
<racarr> and insert say, the software button surface in it
<kdub> well, we could do a mix somehow
<racarr> then the graphics backend is free to figure out
<racarr> Hey, can overlay this with HWC
<racarr> then all of a sudden it has a blur shader
<racarr> and the graphics backend can render it however
<kdub> right
<kdub> i think that dynamism is what we should aim for
<kdub> plus if the behavior is abstracted well
<kdub> thats a big win too
<kdub> like, thats actually how composition on the nexus4 works
<kdub> within the hwc
<racarr> mm
<racarr> We should have layers in the surface stack
<racarr> lets introduce them for stacking
<racarr> and add fancy rendering later
<racarr> (maybe try and make a demo shell that implements the unity blur between two layers)
<racarr> Hehe that's tricky to express
<kdub> racarr, i mean, the quick way is just override the default gl_renderer.cpp
<kdub> but expressing a good model for all the different effects is tricky
<racarr> one possible way to express blur is like
<racarr> there are two layers, say the app layer and the shell layer and we want to render the shell layer with a blur effect of the app layer
<racarr> so the shell, does something like shell_layer->add_texture_sampler((Renderable)appLayer, "textureSamplerName")
<racarr> then shell_layer->add_fragment_shader(shader source)
<racarr> highly idealized of course ;)
<racarr> the renderer
<racarr> does a prepass on the graph, to resolve dependencies, i.e. it sees the shell layer references the app layer as a texture so we need to render it to an fbo
<racarr> or maybe there are only 4 renderables in total and we have a bunch of texture units so we render it all with one massive multitexture
<racarr> *hand wavy*
<racarr> thats my idealized extreme of number 2
<RAOF> I hate all technology
<RAOF> robert_ancell: Any better luck with XMir today?
<robert_ancell> RAOF, just about to try
<robert_ancell> brb
<robert_ancell> RAOF, http://paste.ubuntu.com/5597212/ - is that it getting confused with nouveau?
<robert_ancell> And if I remove the nouveau driver Mir wont even start
<RAOF> Wha?
<robert_ancell> RAOF, drmOpen seems to give "Operation not permitted"
<RAOF> Well, it's not meant to be drmOpening at all.
<RAOF> robert_ancell: Could you change lightdm so that it passes "-verbose 7" to X, and then give me the lightdm log? That should also catch things that X's backtrace handler doesn't, like missing symbols.
<robert_ancell> RAOF, that should have been -vebose 7
<RAOF> robert_ancell: Ah, ok. Yes, the problem is that nouveau getting loaded.
<RAOF> I can reproduce on my hybrid system when I've got the ATI card powered up.
<RAOF> Urgh.
<RAOF> robert_ancell: And, as before, you can't turn off your nvidia card, can you. Bah!
<RAOF> I'm heading out to lunch soon. I'll see what I can wrangle when I get back.
<robert_ancell> RAOF, nope
<racarr> If anyone still around wants to review
<racarr> demo-shell again, alans needs fixing was covered by weakify-event-filters (and Alan agreed that was good in the morning)
<racarr> and alf is on vacation so it just need one more +1
<RAOF> robert_ancell: I think I've fixed your nouveau problem in the daily build that's happening now.
<robert_ancell> RAOF, yay!
<racarr> anyway if we can land it or iterate in the next 2 hours or so before I go to sleep
<racarr> I can propose software cursor :)
<racarr> Also happy afternoon :)
<robert_ancell> racarr, if you think you've fixed the issues raised by Alan/Alexandros just land it
<racarr> robert_ancell: Cheers :) will land and propose software cursor soon
<robert_ancell> racarr, regarding https://code.launchpad.net/~vanvugt/mir/clarify-c-types/+merge/160294. Is c_types supposed  to refer to "C language types"?
<RAOF> Hah! And now that we've fixed the drivers to not load we run into xserver bugs.
<racarr> robert_ancell: It's supposed to refer to C language types
<racarr> it is used in the server by the native display but this merge seems to work because mesa/native_display.h is included
<racarr> includes it
<racarr> even if the src/server/* file removed it
<duflu> racarr: Yeah there's still some conflict there with common.h. We need to resolve the differences between the two more clearly, somehow
<duflu> I think mentioning "c_" is pointless, because all the toolkit headers are C-compatible
<racarr> types.h :)
<racarr> it was introduced just right before mir_toolkit so it was weird
<racarr> oh god reminder email
<racarr> I forgot the difference between tuesday and wednesday
<duflu> racarr: Right, but common.h is also just for C-types. But wider-used simple types like enums
<tvoss> racarr, robert_ancell duflu do we do the weekly?
<duflu> The tricky part is that some types like callbacks are too client-specific to go in common.h (visible to the server)
<robert_ancell> tvoss, sure. I'm looking after my daughter so I'll have to see how it goes but I'll attempt it
<tvoss> robert_ancell, cool
<tvoss> robert_ancell, grabbing headset then
<robert_ancell> RAOF, ^
<RAOF> robert_ancell: Yeah, just hunting for the link.
<robert_ancell> racarr, ping?
<robert_ancell> hikiko, connection problems?
<racarr> Joining!
<hikiko> yes robert_ancell
<hikiko> trying to fix it
<robert_ancell> hikiko, ok, we're mostly saying we'll just meet in Oakland
<duflu> No one wants to talk much this week
<hikiko> :)
<hikiko> I entered!! but the hangout is done I guess
<hikiko> I am the only one there :)
<hikiko> fail!!
<duflu> hikiko: Sorry. Not having any problems to discuss is good I guess.
<hikiko> haha, true :D
<duflu> Oh dear. I failed to read the docs correctly on our pixel format semantics. Time to rewrite :P
<RAOF> Man, I wonder if this xserver code has ever actually been executed?
<RAOF> mlankhorst: xf86DeleteDriver just doesn't really work, does it? :)
 * mlankhorst has no idea
<RAOF> Spoilers: it doesn't.
<RAOF> Well, it does unless you're using it in a situation when you'd want to use it.
 * mlankhorst busy rebasing the kernel patches
<RAOF> Does one of them allow me to get the size of a dma-buf out of its fd? :)
<mlankhorst> oh I forgot
<RAOF> I'm happy to get some more kernel experience if you don't want to write that patch.
<mlankhorst> hehe I want to write it, it was just that I had to rework some other patches and I was resenting it so much I postponed all my kernel work a bit
 * RAOF goes to bathe ZoÃ«
 * duflu wonders if RAOF named ZoÃ« before, after, or because of his discovery of key composition ;)
<duflu> Aaa Mir, why can't you tell red from blue? :(
<RAOF> Wellllll after :P
<alan_g> Good morning!
<duflu> Good afternoon- almost end of the week
<alan_g> ;)
<duflu> I'm panicking about lack of prep and need to run off in a while
<duflu> Happy Raring Eve too
<tvoss> duflu, Happy Raring Eve
 * alan_g checks he has the t-shirt
 * RAOF wins the battle against Xorg
<tvoss> RAOF, \o/
 * mlankhorst checks RAOF for scars
<kdub> hello! status, bugs, worked on display logging
<alan_g> afternoon, got laptop up to date, reviewing and updating MP. Thinking about ownership issues.
<kgunn> kdub: hwc1.0...awesome!
<tvoss> kdub, \o/
<kdub> yay
<racarr> /win goto 10
<racarr> ...:)
<alan_g> Hello there
<racarr> Hello :)
<alan_g> Goodbye!
<racarr> I thought I broke the Qt mapping of the tab character
<racarr> but really I forgot I was in demo shell
<racarr> and it eats tab events
<racarr> ...
<racarr> Got lots of little quirks in Qt key input worked out
<bschaefer> racarr, cool :)
<bschaefer> racarr, soo, i added some more event defines in a branch here:
<bschaefer> https://code.launchpad.net/~brandontschaefer/mir/more-event-defines/+merge/160756
<bschaefer> I saw your comment about waiting till next week, but I needed the MirMotionButton and MirKeyMeta for some SDL stuff so I went ahead and did that
<racarr> bschaefer: Haha! I was just getting ready to add the mir key meta after lunch
<racarr> so perfect!
<racarr> now lunch though, will review after
<bschaefer> haha nice :), im just about to go on lunch
<racarr> back
<bschaefer> soo, i just started looking into this missing button state for a mouse release...and whats weird is the mir_motion_action_hover_exit
<bschaefer> has the correct button state
<bschaefer> another thing thats weird is clicking in general generates a hover exit/enter event as well
<bschaefer> so the events go like this when you press: HoverExit (correct button state), MousePressed (correct button state), Mouse Released (incorrect button state)
<bschaefer> so im thinking that hover exit steals it
<bschaefer> also thanks for the review
<racarr> hmm
<racarr> well click/release does enter/exit hovering
<racarr> kind of weird though
<bschaefer> indeed, i need to track down where the conversion from an android event -> mir event happens...possibly something in there?
<bschaefer> err, that seems to be done in the lexicon, but that would mean android is giving odd states? interesting..
<racarr> bschaefer: I guess this is just how the android input works perhaps
<racarr> it does make sense somehow, when the button is released the button state is 0 ;)
<bschaefer> racarr, hmm perhaps, the problem is theres no look ahead when receiving events
<bschaefer> ie, press button 1 down, press button 2 down, release button 1, which button was released?
<bschaefer> I also don't know why you would need to know the button state on a hover exit :)
<racarr> bschaefer: So...it seems to be as intended
<bschaefer> racarr, whooo, umm I just got something weird...um
<bschaefer> racarr, is the lexicon function thread safe?
<racarr> if you look in InputReader.cpp around l2400
<racarr> is whre it begins sort of
<racarr> It should be right! It doesn't access any
<racarr> data or anything besides its arguments
<bschaefer> racarr, so heres a sample of my log:
<bschaefer> http://paste.ubuntu.com/5599532/
<bschaefer> and the print statement im using in void mia::Lexicon::translate(const droidinput::InputEvent *android_event, MirEvent &mir_event)
<bschaefer> it does a static cast but the umm, android event seems to be off, as it should align up
<bschaefer> racarr, ignore that...
 * bschaefer put the print statement in the wrong place
<bschaefer> :)
<racarr> story of my life haha :)
<bschaefer> haha, I put it before the mir_event was getting assigned so it had the last values it had in it hahaha
<bschaefer> :)
<racarr> I think this is as intended by android, and the idea is just, you receive an event and see the new button state and do what is appropriate
<bschaefer> right, SDL being old doens't do things like this
<racarr> but if SDL apps aren't happy with that (i.e. need an event this button was released)
<racarr> I think you should just maintain
<racarr> a simple mapping
<racarr> for now
<bschaefer> well, yeah Ill have to do a map
<bschaefer> yeah
<racarr> Im not sure if the android way is good or not but
 * bschaefer was trying to avoid ambiguous events
<bschaefer> well to me it makes for an ambiguous event, which means we have to do more book keeping :)
<bschaefer> but android is more a of touch environment, so maybe thats a reason
 * bschaefer makes a workaroud
<racarr> bschaefer: You should propose the test anyway, just with the passing semantics
<racarr> so we at least have something that says how it works
<bschaefer> alright, I still need to fix a mocking problem, complaining about something
<bschaefer> even if I remove the check if state ==0
<bschaefer> racarr, Ill try and get that out today
<racarr> great
<racarr> ok the one thing keeping me from using mir as a terminal multiplexor now
<racarr> is input goes through to the VT :p
<racarr> so ctrl+c
<bschaefer> haha
<bschaefer> racarr, also, turns out if you do MouseDown 1, then try MouseDown 2 its blocked by the mouse Down 1
<bschaefer> sooo I suppose thats no longer a problem, so I just have to save the last used button state...still annoying :)
<racarr>   struct termios terminal_attributes;
<racarr>     tcgetattr(vt_fd, &terminal_attributes);
<racarr>     cfmakeraw(&terminal_attributes);
<racarr>     terminal_attributes.c_oflag |= OPOST | OCRNL;
<racarr>     tcsetattr(vt_fd, TCSANOW, &terminal_attributes);
<racarr> lol...
<racarr> its like all the worst names in 5 lines
<bschaefer> haha, are you really stealing the fd from the vt haha?
<bschaefer> well that works
<racarr> well I mean in the server
<racarr> setting up the VT
<racarr> the problem is I need the server not to respond to control sequences anymore :)
<bschaefer> oo, I was thinking the tty for some reason
<bschaefer> right, you don't want the server to die on a crtl+c :)
<bschaefer> also for you enable input branch, with my change to trunk you'll need to change these: http://paste.ubuntu.com/5599384/
<bschaefer> (very simple...)
#ubuntu-mir 2013-04-25
<hikiko> hello
<mlankhorst> g'day
<hikiko> did you have any problems with the libgbm recently? I upgraded to have the latest mir libraries and I noticed that an example program I write using gbm doesn't work anymore (runtime errors), i switched to debian where I have an old libgbm version and it works fine
<tvoss> RAOF, ping
<smspillaz> tvoss: its a public holiday in Australia today
<tvoss> smspillaz, ah, thanks
<smspillaz> np
<alan_g> tvoss: ping
<tvoss> alan_g, pong
<alan_g> do you know anything about "hardware cursor"?
<tvoss> alan_g, no intimate details, but I have a high-level understanding of its purpose and idea
<alan_g> tvoss: all I have are a few notes I made talking to racarr - which are a bit low level, sparse, and confusing now I look again
<alan_g> I was going to talk to alf, but between one delay and another...
<tvoss> alan_g, yeah, so how can I help?
<alan_g> Maybe you can't - I was just hoping
<alan_g> Sigh!  Why doesn't mir run from a remote terminal any more?
<kdub> morning folks, status, hunting bugs
<alan_g> afternoon kdub, status trying to understand how some of the code works
<kdub> anything i can help with?
<alan_g> It's the gbm code, I think I just have to keep going until I get the right idea. :(
<alan_g> What I'd really like to do is run mir from a debugger in a remote terminal so I can step through it, but it doesn't seem to like not being in a VT.
<racarr> Morning
<alan_g> Afternoon
<alan_g> racarr: what's the weather going to be like? Do I need shorts? Rain gear? ...
<alan_g> Is the forecast accurate?
<racarr> alan_g: Who knows if the forecast is accurate
<racarr> the weather should be really good though today is our first overcast day in weeks
<racarr> it would be pretty weird if it rained more than once
<alan_g> especially in the office
<alan_g> ;)
<kgunn> racarr: kdub ....i think i forgot to tell you guys, i'm going to EOD early & i'm out tomorrow
<kgunn> i have to drive to alabama to fetch my daughter/stuff from dorm
<kgunn> see you in oakland
<racarr> See you!
<racarr> have a good drive
<racarr> I am going to be out from about 10 minutes from now for about 2 hours to look at an apartment :)
<racarr> /win goto 39
<racarr> whoops
<tvoss> kgunn, see you in Oakland
<alan_g|life> kgunn: see you there
<racarr> Wheeee oakland
<tvoss> racarr, ping
<racarr> tvoss: Pong
<racarr> about to leave (need to within 5-10 minutes for an apartment showing)
<racarr> but what's up?
<tvoss> racarr, nothing special
<tvoss> good luck for the appartement though
<racarr> Thanks :)
<racarr> I am hoping to make a video today :) I fixed up all the quirks in the terminal
<racarr> so emacs is usable now...haha
<racarr> but then when I tab more than a few times there is a crash
<racarr> so I have to fix that...then video!
<racarr> Gotta run. cheers :)
<tvoss> racarr, cheers :)
<arsson> i know this is mir channel, but could anyone tell me how to get nvidia official drivers to work in ubuntu 13.04? after installation desktop disappears.
<arsson> or DE
<robert_ancell> RAOF, Did you have any complaints about https://code.launchpad.net/~alan-griffiths/mir/surface-states-simplification/+merge/160583?
<robert_ancell> kdub, is there a reason not to do ensure_no_live_buffers_bound in the destructor? I guess because the destructor may not have a GL context?
<kdub> in the destructor of what? glRenderer?
<robert_ancell> yeah
<kdub> glRenderer's lifetime is the same as the compositor, so on every draw, we don't construct/destruct the glRenderer
<kdub> the object that is in charge of securing and freeing texture resources for glRenderer is the (perhaps poorly named) RenderingOperator
<robert_ancell> kdub, ah, cheers
<robert_ancell> thomi, still busy? Can I get you to enable CI for unity-greeter?
<robert_ancell> or tell me where to file bugs to request that
<thomi> robert_ancell: CI and autolanding? for lp:unity-greeter?
<robert_ancell> yep
<robert_ancell> actually I'm not sure if someone else has done it - any way to check?
<kdub> thomi, do you know if we're generating mir armhf packages anywhere?
<thomi> robert_ancell: the easiest way is to look either in the jenkins server, or in the cupstream2distro-config source
<thomi> let me check the jenkins server quickly...
<thomi> robert_ancell: looks like it's already enabled
<robert_ancell> thomi, ah, cheers - what is the URL for the jenkins server?
<thomi> the public interface is jenkins.qa.ubuntu.com
#ubuntu-mir 2013-04-26
<RAOF> Filtering systems, oh my!
<RAOF> robert_ancell: You've found that XMir now works, I trust?
<RAOF> It does here, even if I have all my GPUs powered up.
<robert_ancell> RAOF, yes, been getting it working. I can do user switching now :)
<RAOF> Woot!
<robert_ancell> still input pass through issues though :(
<robert_ancell> And I'm really struggling to get the appropriate information from Mir. I feel some patches coming on :)
<RAOF> :)
<robert_ancell> thomi, can you set up CI and autolanding (into mir-team staging PPA) for lp:unity-system-compositor?
<thomi> robert_ancell: sure, but before it gets deployed Francis need to review it, and I won't see him now till oakland :-/
<robert_ancell> thomi, ok, np. Just put it into the queue
<robert_ancell> I'll do some manual uploads until then
<thomi> ok
<thomi> robert_ancell: what packaging branch are you using?
<robert_ancell> thomi, it has packaging checked in
<robert_ancell> thomi, also, we set up lp:~mir-team/lightdm/mir to autoland right? Can we switch that to lp:~mir-team/lightdm/unity instead?
<thomi> robert_ancell: sure.
<thomi> I wish you could file bugs against a person in LP
<thomi> would make for a handy TODO list tracker for me
<robert_ancell> thomi, you guys need to make a project for this :)
<robert_ancell> the bug-thomi-for-stuff project
<thomi> hmmmm, why not...
<duflu> Hah. That's asking for trouble. Bug: "This person smells"
<thomi> meh - started doing it, got bored
<tvoss> RAOF, ping
<RAOF> tvoss: Yo!
<tvoss> alan_g|life, ping
<tvoss> michi, ping
<michi> tvoss: pong
<alan_g> tvoss: pong (sorry for the delay)
<hikiko> hello
<hikiko> question :) when i initialize the gbm I need to connect to a drm device and then create a context etc
<hikiko> but when I am inside X i have already a connection to the device and glx context
<hikiko> is there any way to give the existing content to the gbm?
<hikiko> (i couldn't find something)
<RAOF> hikiko: No.
<hikiko> RAOF,
<hikiko> :D i was about to email you
<hikiko> then
<hikiko> the only way to have an X backend for mir
<hikiko> is by implementing another buffer mechanism isn't it?
<hikiko> :s
<RAOF> hikiko: What you need to do (and what Mesa does) is open a connection to the drm device, call drmGetMagic on that fd, send the magic value to the X server via DRI2Authenticate, which will authenticate your fd, *then* pass that fd to gbm.
<hikiko> http://www.x.org/releases/current/doc/dri2proto/dri2proto.txt this extension?
<hikiko> ah I got it :)
<hikiko> thank you R__
<hikiko> RAOF*
<RAOF> Correct!
<hikiko> so then i can open a win get the current context
<RAOF> Hm. Now that I think of it, there's still the problem of how to get your buffers *out* of gbm.
<hikiko> there's no function to get the user data?
<hikiko> ah you mean that then you have to pass through drm again
<hikiko> ?
<RAOF> Meaning you'll have a gbm bo with the rendering you want to display, but you need to get that into the X window somehow.
<RAOF> Hah! The EGL_DRM_BUFFER_MESA target of eglCreateImageKHR will do what you want.
<RAOF> Although you've got a GLX context, not an EGL context, right?
<hikiko> I have a glx but I called the eglGetCurrentContext and then attempted to create a khr image :p
<hikiko> but i used the native pixmap target
<hikiko> which is wrong
<RAOF> Hm. Actually we want to go the other way, don't we - you want to create an EGL image, then gbm_bo_import() that EGL image to get the gbm_bo that you hand off to the rest of the buffer machinery.
<RAOF> So, I think you've got two options - create an EGL image and gbm_bo_import() that to feed to the gbm bits, or pull a gbm_bo out of the gbm bits, get the handle with gbm_bo_get_handle(), and eglCreateImageKHR() that handle with type EGL_DRM_BUFFER_MESA.
<hikiko> the first seems easier but I think that the second is similar to what we already do isn't it?
<RAOF> I think we actually do the first.
<RAOF> :)
<hikiko> :D
<RAOF> Oh, no. We do the latter.
<RAOF> Because we sometimes want to be all software rendering.
<hikiko> why can't you do the first with software rendering?
<RAOF> Because you may (and, in practise, do) need to allocate the buffer differently if you're going to write from the CPU to it.
<RAOF> Unless you use something like TexImage2D, of course.
<RAOF> But that was apparently too slow.
<hikiko> so better to follow the 2nd way too? or we ll have software rendering only outside X (eg when we render to the framebuffer device)?
<RAOF> Yeah, I think you'll need to go the second path.
<hikiko> ok
<hikiko> and RAOF I had a problem with libgbm
<RAOF> Or, rather, gbm_buffer_allocator.cpp already goes the second path, and I think with the possible exception of using EGL_DRM_BUFFER_MESA rather than EGL_NATIVE_PIXMAP_KHR you'll be able to copy it wholesale.
<RAOF> (This is why I need to refactor the platforms to separate display from buffer allocation)
<hikiko> I see, I am trying to do all these outside mir first because if I start the changes on a mir branch I won't be able to debug easily
<RAOF> That sounds sensible.
<RAOF> Or, at least, a stinging indictment of our current architecture which makes what should be a reasonably simple task difficult :/l
<hikiko> but I had a problem with libgbm: i upgraded and after that I couldn't run a very simple example that just creates a drm device and then a gbm buffer and was working fine. I switched to debian where I have the old versions and it was working :s
<hikiko> but i can't continue on debian because I don't have half of the functions
<alan_g> RAOF: we should be looking at fixing whatever makes simple tasks difficult
<RAOF> alan_g: In this case, it's because display and buffer allocation are needlessly conflated.
<RAOF> alan_g: It's on TODO.
<alan_g> RAOF: I'll let you own it then. ;)
<RAOF> hikiko: Hm, urgh. I'd ask for the sample code, but it's time for bed here.
<RAOF> hikiko: We can sort it out in Oakland, I guess!
<hikiko> sorry RAOF :) I forgot the time difference :)
<hikiko> thank you very very much
<RAOF> s'ok. I'm the one who'se silly enough to be on IRC at this point :)
<hikiko> thanks :D
<alan_g> mmrazik|afk: can you see what's wrong here? http://jenkins.qa.ubuntu.com/job/mir-quantal-amd64-ci/507/console
<racarr> Hi :)
<alan_g> Afternoon
<mmrazik|afk> alan_g: mising xsltproc as build dependency? http://pastebin.ubuntu.com/5605060/
<mmrazik|afk> just guessing
<mmrazik|afk> but weird as its not something new
<alan_g> mmrazik|afk: that makes sense - thanks, I couldn't find a signal in all the noise.
 * kdub should get his laptop up to snuff before monday
<olli> racarr, around?
<racarr> olli: Yep!
<olli> racarr, I am looking at BP https://blueprints.launchpad.net/ubuntu/+spec/client-1303-mir-phone-iteration-0
<racarr> Ok
<olli> trying to see if we achieved Acceptance criteria for April
<olli> do you have some insight into that
<racarr> Almost
<racarr> my outstanding workitems exist in local branches or
<olli> almost got insight or almost achieved it ;)
<racarr> sometimes branches with other people
<racarr> it's just review is backed up
<racarr> so hopefully can land the remainders monday and say we made it for april :)
<olli> racarr, ok ;)
<racarr> olli: Err...I had a brain error
<racarr> and was reading the criteria for may ;)
<olli> whot? impossible ;)
<racarr> we are even
<racarr> closer
<racarr> to april :)
<olli> for may?
<olli> it says tbd
<olli> don't get confused by the month-X suffic
<racarr> Oh I was just seeing if the workitems were finished
<olli> suffix even
<olli> gotcha
<racarr> the acceptance criteria
<racarr> are great :)
<racarr> what is the conceptual difference between
<racarr> acceptance criteria  and all the work items being finished
<racarr> I didn't really understand when those were added
<alan_g|bbs> racarr: the blueprints are far from clear to me, glad you don't understand them either.
<bschaefer> racarr, hello! I've a question about scroll events
<bschaefer> or rather that its hard to get vscroll hscroll info without having to do this: http://paste.ubuntu.com/5605289/
<olli> racarr, alan_g|bbs the Acceptance Criteria should be a description of the sum of work items, i.e. something I can understand ;)
<alan_g|bbs> olli: ;)
<tvoss> racarr, ping
<racarr> Sorry have to run out again for apartment hunting nonsense :)
<racarr> back in the afternoon...
<bschaefer> good luck hunting!
<racarr> back!
<racarr> working on a bug where things seem to go wrong (fds get closed) when
<racarr> focus cycles multiple times
<racarr> whoops. forgot to press enter :)
#ubuntu-mir 2013-04-27
<racarr> ARE YOU HERE YET
#ubuntu-mir 2013-04-28
<JoseeAntonioR> hey guys, I'm trying to get mir running natively as explained on http://unity.ubuntu.com/mir/using_mir_on_pc.html but it only displays a black screen. just did the install and everything, haven't rebooted or so
<JoseeAntonioR> also, it removed the ubuntu-desktop meta-package, is this normal?
<racarr> Hi alan_g :)
<alan_g> hi racarr - was just reading your email
<racarr> Cool. Are you/people around the hotel?
<racarr> Was going to head over soon...one last errand to run and should get there around 3:15-3:30
<alan_g> I am, didn't see anyone else on my way in
<racarr> Ok well I will come say hello and im sure people will really be around
<racarr> will be around*
<alan_g> I'll look for you around 3:30 then. ;)
<racarr> my concern is hotels seem to not like long haired youth who are not hotel guests
<racarr> hanging around :p
<racarr> probably
<racarr> Anyway! See you in a bit.
 * alan_g doesn't see a problem with long hair
#ubuntu-mir 2014-04-21
<ice9> how efficient is Mir currently?
<ogra_> ice9, efficient eough to be the default on all tablet and phone images
<ice9> ogra_: I mean the desktop sorry
<ogra_> yeah, no idea about that ...
<ogra_> (since there is no desktop that could use Mir yet)(
<mterry> What's the best way for USC to tell a session to "freeze" -- i.e. don't render any frames.  I thought it was hide(), but it seems that doesn't stop it from swapping buffers.  In 0.1.9, I'm guessing I use lifecycle events.  But what about 0.1.8?
<kgunn> mterry: do you want everyone to freeze ? i would assume yes
<mterry> kgunn, in this particular instance I want to be able to freeze a whole session -- all its surfaces.  So not quite everyone (not all sessions)
 * mterry goes afk real quick
<kgunn> mterry: i would have thought hide as well....is it really about the rendering ? or you just want a still frame ? e.g. the analogy  hear would be unity-mir using snapshots i think
<kgunn> mterry: so out of curiosity i started to poke, wonder if set_lifecycle_state on session is what you'd want to use...altho, good news bad news, the i/f kinda sounds right, but not sure if anything acts on it
<kgunn> AlbertA: camako ...am i reading the code correct ? ^ do the states of set_lifecycle_state not really get acted on?
<camako> kgunn: checking
<kgunn> i see where it makes it to protobuf_life_event and the state gets set, but then i don't really see any action taken on it...
<camako> kgunn: I don't see set_lifecycle_state being called from anywhere
<kgunn> camako: right, well...i was thinking it might server mterry's purpose (he's shell like in a sense with the greeter sitting on top of u-s-c)
<kgunn> u-s-c==unity-system-compositor
<kgunn> he wanted to halt apps (sessions) from rendering...
<kgunn> not completely sure why yet...but seemed a sensible thing to want to do as a shell-like-thing
<kgunn> camako: mterry ...so it's actually called in unity-mir, wonder if its an opaque msg (e.g. mir not acting on it but passed to platform-api)
<mterry> kgunn, heyo, back.  So in 0.1.8, lifecycles don't seem to do much.  That might change in 0.1.9?
<mterry> kgunn, the reason I want this is for split greeter boot animation -- on boot, we don't show the greeter session until both the greeter and user session are ready to go (i.e. we don't want to show the greeter without the user session behind it ready to go) but...
<mterry> kgunn, the greeter also has a "fade in animation" that we want to have happen when the user sees it -- so ideally when the greeter is ready, I could "freeze" it until the user session is also ready so the user sees the full fade in animation -- as is today, the user may miss the animation because the greeter was running through it while waiting for the user session.  Make sense?
<mterry> kgunn, this may be yet another blocker for split mode from the design side
<mterry> kgunn, sometimes the user session is ready before the greeter, so there's no problem.  But not always.  So it's a bit of a race and design prefers the animation always happen, naturally
<kgunn> mterry: afaik, w 0.1.9, only additional mgmt atm is coming with qtubuntu where the exposeEvent is triggered
<mterry> kgunn, I really did think hide() did that though.  I'd like to hear if it's intended to do that and I'm making some mistake or if that's just not the API I want
<kgunn> mterry: yeah...makes sense....basically, when the greeter is ready "well before" the user session, there's no fade, and it just looks like a hard switch/hard transition animation (
<mterry> Yeah.  "well before" can be on the order of just a second though.  Fade in animation isn't super long
<kgunn> mterry: my only fear there, is hide won't "halt renders" in 0.1.9
<kgunn> this is the whole point of the non-block swap
<kgunn> mterry: all this being said....sounds like a sensible control for a shell-like thing to have
<mterry> kgunn, right.  But lifecycle would replace that, eh?
<mterry> kgunn, or yeah, maybe we need to add a tiny bit of API
<mterry> kgunn, this seems like a reasonable use case
<mterry> kgunn, I'll file a feature bug, not sure who can work on it though
<kgunn> mterry: my worry on life cycle even with 0.1.9...is that, the side channel is racy also... so, you end up getting some "renders you don't see"
<mterry> kgunn, I see
<kgunn> mterry: actually...when was the last time you dealt with lifecycle events ?....i do see some handling of it in platform-api as well...ubuntu_application_api_mirclient.cpp
<mterry> kgunn, I tried to use them for this purpose last Friday
<mterry> kgunn, didn't seem to do anything that I could see (I still saw swap_buffers being called for the client after I used lifecycle calls)
<kgunn> hmmm....
<mterry> kgunn, bug 1310637 is the feature request, which might just get closed with a "this can already be done" comment
<kgunn> mterry: wonder if this is a failing of nested ?
<ubot5> bug 1310637 in mir (Ubuntu) "Allow a server to halt rendering in a client session" [Undecided,New] https://launchpad.net/bugs/1310637
<AlbertA> kgunn: well it's a feature of non-blocking
<AlbertA> "feature"
<kgunn> AlbertA: yes yes...
<kgunn> AlbertA: i wouldn't drive yourself too crazy optimizing that 2% out before putting up MP's for the switching bundle change
<kgunn> e.g. propose 1 set...then you can always propose a subsequent optimizATION SET
<kgunn> oops...sorry cap lock strike
<AlbertA> kgunn: o
<AlbertA> kgunn: ok
<kgunn> dang it... camako, could you share that acceptance test hit-list you, alan, kdub created ?
<kgunn> or share the name i can search...
<racarr__> Nah. thanks though.
<racarr__> err kgunn ^
<racarr__> went in to wrong channel
<kgunn> i forgot to save the link
<racarr__> lol
<kgunn> racarr__: :)
<AlbertA> kgunn: should be in e-mail
<kgunn> duh...
<camako> kgunn :https://docs.google.com/document/d/17T4H5IhbfIPK3hErFz7VCmXReOywrHQnWwt_dTxe0kI/edit?usp=sharing
<racarr__> https://www.youtube.com/watch?v=16EYejUic_0 - Great Code Review music.
<AlbertA> racarr__: :(
<AlbertA> racarr__: I mean :)
<AlbertA> mterry: kgunn: the greeter has to listen to lifecycle events and stop its own rendering loop
<AlbertA> mterry: kgunn: mir won't do anything to prevent that
<AlbertA> mterry: kgunn: with the non-block swap behavior
<kgunn> camako: as and when people start to free up and ask for things todo... i think items #1, #3, #4, #10 in your acceptance test doc make the most sense...
<kdub> 6 is more of a sub-bullet for 3
<mterry> AlbertA, OK...  Does 0.1.8 already have the ability for it to do that?
<AlbertA> mterry: non-blocking?
<AlbertA> mterry: that will be coming in 0.1.9
<mterry> AlbertA, for the greeter to listen to lifecycle events
<AlbertA> mterry: you could do that now, that's what gerry is using for qtubuntu
<racarr__> The QPA is handling that for clients at least. Is it different because greeter is using qtubuntu-mirserver?
<camako> kgunn: I'll keep that in mind
<mterry> racarr__, greeter is using unity-mir/mirserver.  I guess that makes it different?
<AlbertA> racarr__: oh it's in-process?
<racarr__> Ci
<racarr__> But using qtubuntu
<racarr__> so the logic should be there, so maybe its just flipped off for in process? not sure hwo the shell
<racarr__> is handling render stop
<AlbertA> mterry: greeter is qml?
<AlbertA> mterry: the new version?
<AlbertA> mterry: I mean the new split version of the greeter?
<mterry> AlbertA, yeah, it basically runs same code as unity8, just different plugins/qml
<AlbertA> mterry: you probably want to ping greyback then on how he uses the lifecyle to stop rendering
<AlbertA> https://code.launchpad.net/~gerboland/qtubuntu/surface-visible-hidden-side-channel/+merge/215884
<AlbertA> mterry: ^
<racarr__> https://code.launchpad.net/~josharenson/mir/install_glmark2/+merge/216504
<racarr__> jenkins was ignoring
<racarr__> this branch...wonder why
<racarr__> (I just manually requested a CI review)
<racarr__> but there was none pending
<mterry> AlbertA, thanks, will poke around
<mterry> AlbertA, oh right.  But I remember talking about the side channel for lifecycles and it is too slow -- can't rely on when it stops rendering
<AlbertA> mterry: oh the 3 sec delay?
<mterry> AlbertA, greyback's comments greyback's indicate that hide() *should* do what I want.  but it doesn't seem to
<mterry> maybe he's talking about Qt's hide
<AlbertA> mterry: yeah beginning with 0.1.9 hide means don't show in screen
<AlbertA> mterry: but apps can still render
<mterry> AlbertA, 3 seconds?  I dunno.  I remember hearing it was "racy" in the sense that some frames might be rendered before the client handles lifecycle event
<mterry> AlbertA, right.  So I think I need a new API added -- stop_rendering() or some such that a server can tell a client session
<mterry> AlbertA, I filed bug 1310637
<ubot5> bug 1310637 in mir (Ubuntu) "Allow a server to halt rendering in a client session" [Undecided,New] https://launchpad.net/bugs/1310637
<AlbertA> mterry: and this is for in-process clients right?
<mterry> AlbertA, i'm not sure about that term.  It's USC talking to the greeter.  So separate processes?
<AlbertA> mterry: oh...
<racarr__> Yes, greeter is its own
<racarr__> mirsrever instance though correct?
<racarr__>  /it was
<mterry> racarr__, yes
<racarr__> :)
<mterry> racarr__, but from USC perspective, it doesn't care what the session is, it just wants to stop it from doing anything
<mterry> maybe I should just send a SIGSTOP...
<mterry> That actually doesn't sound so dumb...
<AlbertA> mterry: but that would introduce the same issues we are trying to resolve
<mterry> Still a bit racy I guess
<AlbertA> mterry: with non-blocking
<mterry> AlbertA, this is a specific use case, not a general thing that USC always wants to do
<mterry> AlbertA, I'm specifically trying to synchronize rendering between two sessions
<racarr__> mm...which is making me kind of think there
<racarr__> I mean if its literally just a fade
<racarr__> then the fade could be done
<racarr__> server side
<racarr__> with set_alpha
<AlbertA> mterry: but the problem is the animation will be already over
<mterry> Not just a fade.  Different elements grow and become more opaque, each on their own timer
<mterry> racarr__, ^
<AlbertA> mterry: in the greeter
<racarr__> Mm -.-
<mterry> AlbertA, sorry, how do you mean?
<AlbertA> mterry: is it just a fade? or some other cutesy stuff?
<mterry> AlbertA, I mean, that's the problem I have today that I'm trying to solve yeah
<AlbertA> mterry: I'm thinking more in general terms
<AlbertA> mterry: that may change in the future
<mterry> AlbertA, cutesy stuff.  Panel drops down from top, clock time grows from 0.8 to 1.0 size and goes from 0 to 1 opacity
<mterry> clock fades in similarly
<AlbertA> mterry: yeah that's what I mean, you couldn't do that at the mir server side
<AlbertA> mterry: qt controls all that
<AlbertA> mterry: but is it possible for the greeter to start in hide mode (hide in qt sense)
<mterry> AlbertA, right.  But I just want to have USC send a message to the session that says "don't handle any buffers" so that Qt will stop until we unfreeze it
<AlbertA> mterry: right - but that kinda goes agains the non-blocking decision
<mterry> AlbertA, I agree as a general thing.  But I'm saying there is a specific use case where we do actually want the ability to block
<racarr__> this is only in the specific case though, triggered by shell code in USC
<racarr__> mm
<mterry> AlbertA, this isn't about app lifecycle
<AlbertA> kgunn: mterry: where it was decided that mir would not enforce at all rendering loop behavior implicitly by blocking
<AlbertA> mterry: I guess if its short lived it should be ok
<AlbertA> mterry: so you can't tell QT to not render at all when creating the greeter stuff? it always starts rendering no matter what?
<AlbertA> mterry: just curious
<mterry> AlbertA, well.  I could have the greeter start in frozen mode.  But then I'd need a signal to unfreeze it.  Which is this same problem, just much more app-specific
<AlbertA> mterry: plus in any case, it would be hard to do frame level synch transitions to screen
<mterry> And the problem is really a compositor specific one.  Not really greeter-specific.  I feel like the abstraction for this belongs in mir compositor code
<AlbertA> mterry: you most likely would get some black frames at the beginning
<AlbertA> mterry: maybe if we send transition events to each of the sessions that are transitioning from each other
<AlbertA> mterry: and we wait until the transition event is acked
<AlbertA> mterry: like one for being transitioned to
<AlbertA> mterry: and one for being transitioned out of
<mterry> AlbertA, it would be useful if a mir client knew it was being transitioned away from (we will eventually want to know this for the tiny boot animation app so it can fade out too)
<AlbertA> mterry: so we send transition out of - wait until ack - the client receives it
<mterry> client fades out, acks back
<AlbertA> mterry: does its cutesy shutdown transition animation, finishes and acks the message
<mterry> yeah, that would be ideal
<AlbertA> mterry: and the other client receives transition to
<AlbertA> mterry: and same deal
<mterry> AlbertA, except...  I'm not sure what we do there.
<mterry> AlbertA, that seems like a separate problem from being able to freeze it until ready?
<mterry> AlbertA, the greeter appears before we're ready to transition to it
<AlbertA> mterry: well maybe we could block until a first ack is received
<AlbertA> mterry: or something....
<AlbertA> mterry: maybe begin transition into
<AlbertA> mterry: server blocks until begin transition into acks
<mterry> AlbertA, yeah, we could add a special message for 'freeze' that is part of this set of messages
<AlbertA> mterry: and only for sessions that have registered for transition notifications
<tvoss> AlbertA, mterry seems like waiting for the first swap buffers call after the transition has been initiated is the trigger you are looking for here
<AlbertA> tvoss: yeah that would be more sensible, because waiting for an ack would be "dangerous" for misbehaving clients
<tvoss> AlbertA, yup, exactly.
<mterry> tvoss, AlbertA: I do hook into swap_buffers calls.  That's how I know a client is ready to display to the screen.  But how do I stop the client from doing anything after that point?
<tvoss> mterry, that would require an occlusion event
<tvoss> mterry, AlbertA something we would need to add anyway
<AlbertA> tvoss: yep
<mterry> tvoss, meaning we don't have that yet, OK
<tvoss> mterry, yup
<mterry> tvoss, occlusion being a way to tell a client it isn't actually visible on screen?  That sounds exactly the semantics of my situation indded
 * kdub makes an argument the scene would be the best one to compute occlusion
<tvoss> kdub, +1
<kdub> i guess though, for max flexibility, the compositor should submit an occlusion scanner or something like that
<tvoss> mterry, yup, I think we should implement such a fundamental feature "the right way" (tm) :) Out of curiosity: why isn't the usc process lifecycled and thus stopped by usc?
<mterry> tvoss, you mean why isn't the greeter process lifecycled?
<mterry> tvoss, I tried using lifecycle events for this, but they didn't do what I wanted.  Maybe because I'm still testing with mir 0.1.8
<mterry> tvoss, but even if they did do what I wanted, I hear that the sidechannel is 'racy' in the sense that the client may still render some frames before being lifecycled
<mterry> tvoss, and ideally this would be frame-perfect
<tvoss> mterry, that is surely the case, but then: we expect clients receiving a lifecycle event to prepare a "final" good rendering
<mterry> tvoss, but in this case, I'm not sure that makes sense.  That would mean having the greeter 'reset' itself to frame zero if it gets a suspend event near the beginning of its lifespan?  Seems finicky
<mterry> or maybe just any suspend event.  I suppose we could redo the animation on screen wake too...
<tvoss> mterry, so is that a viable option for you?
<mterry> tvoss, I think so...?  Let me look into it
<tvoss> mterry, ack, drop me a mail with your ideas/thoughts, so we can pick up the discussion tomorrow
<anpok> kdub: +1 - for flexibility you could add an optional - filterfilter that resurrects false negatives..
<kdub> i'm always very pleased when I get to do matrix stuff
<kdub> 'all that math was worth it!' :P
<racarr__> You mean like dodging bullets, etc?
<racarr__> :p
<kdub> lol
<kgunn> interesting...i've been testing xmir w/ non-blocking swap all day...and comparing to good ol' x
<kgunn> i don't think  x today works the way duflu says...
<kgunn> i find plenty that still renders when occluded and screen blank even in x
<racarr__> I agree re: occlusion
<racarr__> thought screen off would block swap buffers in composited GLX/compiz but who knows
<anpok> hmm .oO(X11 terrible times .. years ago when I once messed with xlib - I never managed to properly treat the expose and damage events)
<racarr__> lol
<RAOF> racarr__: Yo!
<RAOF> racarr__, kgunn_: Whether or not screen off blocks GLX_swap_buffers is driver dependent!
<RAOF> Yay!
<racarr__> RAOF: Morning!
<RAOF> racarr__: And a fine Easter Monday to you!
#ubuntu-mir 2014-04-22
<RAOF> racarr__: You wanted to discuss 1Hz-rendering
<RAOF> ?
<kdub> racarr__,  quick side question :) is this one ready to go? https://code.launchpad.net/~mir-team/mir/cursor-spike-phase-2.5-rework-of-the-input-targets/+merge/213742
<racarr__> kdub: Yeah!
<racarr__> RAOF: Um...in a bit (around meeting or something?) getting ready to make dinner
<RAOF> racarr__: Sure!
<kgunn> searching for a headset...
<RAOF> In Which I Gain A New Appreciation Of How Slow Nexus 4 Hardware Is.
<anpok_> RAOF: hm?
<RAOF> anpok_: Oh, running into a race I thought couldn't happen.
<RAOF> But does on N4.
<RAOF> Under valgrind, admittedly.
<RAOF> Turns out a thread sleeping for 1ms is not long enough for another thread to get unblocked and take the lock.
<mlankhorst> RAOF: that's really really the wrong approach to locking ;P
<RAOF> Well, I'm doing this in a test designed to expose a different race, so I can't really go into the code and lock at exactly the right point :)
<mlankhorst> hah :p
<mlankhorst> while (pthread_mutex_trylock()) unlock() sleep ? :D
<RAOF> I'll just (a) bump it to 2ms and (b) move the locking closer.
<duflu> RAOF: Script up a test which runs helgrind ;)
<duflu> That will fail reliably
<RAOF> duflu: Hush!
 * duflu bows head and backs into hole
<RAOF> Anyway, EOD for me.
<alf_> duflu: Is https://bugs.launchpad.net/mir/+bug/1308843 about the buffer consuming thread running faster than the real compositor?
<ubot5> Launchpad bug 1308843 in Mir "[regression] Client judders, skipping frames periodically" [High,In progress]
<duflu> alf_: Kind of yes. But unconditionally running both it seems, still results in the same problem. You get periodic aliasing/beating. The only real solution is to make the consumer conditional, which is fairly easy. I'm just stuck writing good test cases right now
<alf_> duflu: "to make the consumer conditional" ?
<duflu> It's exactly the same as multi-monitor with 59.9Hz vs 60.0Hz. With physical displays we accept the beating, but with the virtual one we shouldn't
<alf_> duflu: there's also RAOFs approach which shouldn't have this issue
<alf_> duflu: have you tried it?
<duflu> alf_: No I was trying to solve regressions before doing more code reviews
<duflu> Argh, we're all tangled
<duflu> Anyway, the fix(es) are easy. I'll continue improving the regression tests regardless
<duflu> Wow, that's huge
<duflu> I think we can do better
<alf_> duflu: what's huge?
<duflu> alf_: The diff
<alf_> duflu: diff of what?
<duflu> alf_: 1Hz branch
<duflu> I think I can solve multiple regressions with much less change
<anpok_> hm the timer functionality adds a lot
<duflu> A lot of risk, definitely
<duflu> And maintenance burden
<kgunn> alf_: just want to say...non-block swap buffers on mir-devel seems to be rockin'
<kgunn> i tested all day y'day on xmir...did a lot of suspends
<kgunn> and comparing to regular X....didn't see any difference
<kgunn> in fact, i see a bug sometimes on X suspend :)
<kgunn> also, i put through the wringer on nexus 10...no new bugs
<kgunn> any bugs around sidestage are the same/already present
<alf_> kgunn: Great. I have put up https://code.launchpad.net/~afrantzis/mir/consume-only-not-rendered-buffers/+merge/216725 for review, trying to combine the best of both worlds, but if everything is working fine at the moment, let's go with what we have and revisit in a few days when things have stabilized.
<anpok> so we wont integrate RAOFs MP?
<anpok> I am asking because I would have a need for the Timer functionality that comes with that MP..
<alf_> anpok: We haven't decided anything yet... just more alternatives for evaluation
<AlbertA> anpok: that's up to the panel to decide :)
<anpok> hehe
<anpok> the elder?
<anpok> *s
<anpok> hmm
<anpok> I was thinking about shamlessly ripping that part out and providing it as is in a separate MP
<AlbertA> anpok: let's merge both and see what happens.... ;)
<AlbertA> anpok: that's the spirit of open source
<AlbertA> anpok: :)
<anpok> alan_g: https://code.launchpad.net/~andreas-pokorny/mir/custom_input_dispatcher/+merge/215174/comments/514940
<anpok> alan_g: would you prefer a huge change that does everything in one MP - or several normal sized changes?
<anpok> hmm it is already beyond 3k...
<alan_g> anpok: I don't mind promises that "this is only like this until the next MP"
<anpok> can I reuse that promises since it will take a few more MPs untill that thing evaporates
<alan_g> ack
<anpok> and at some point I need to add (or understand that those events can be ignored) something to MirEvent
<anpok> to store device reset events..
<anpok> which I expect leads to further discussions...
<racarr__> I just noticed my desk is not only on a slanted part of my floor
<racarr__> but is bowing at the middle
<racarr__> and my keyboard is at quite an angle lol
<racarr__> Ive had this muscular thing that I thought was from playing piano...and now I think I know the culprit ;)
<kdub> hah, all those earthquakes
<kdub> any more takers on this: https://code.launchpad.net/~kdub/mir/gl-program-creation-factory/+merge/216218 ?
<kdub> thanks AlbertA
<kgunn> AlbertA: anpok on the topic of occlusion detection & alpha detection
<kgunn> we still would allow the occluded app to render
<kgunn> but the compositor would just ignore right ?
<AlbertA> kgunn: right
<AlbertA> kgunn: there's an MP that wants to delete the occlusion logic
<AlbertA> kgunn: but I think since anpok has already done the work to switch to opaque surfaces in unity
<AlbertA> kgunn: that is still worth keeping
<kgunn> AlbertA: i agree with you...that's still so obviously valuable we shouldn't remove it
<kgunn> AlbertA: do i need to reject?
<racarr__> Eh I was going to reject it later too so
<kgunn> racarr__: AlbertA ...i don't mind being the team punching bag :)
<AlbertA> kdub: ^
<AlbertA> kgunn: I disapproved
<kgunn> anpok: while you're here :)....in your mind are we "done" satisfying greyback and dandrader's requirements
<kgunn> sorry i fell out of touch on the android input wrapper
<anpok> AlbertA: hm I think we could go with really opaque by default, and change osk and popups to enforce transparency
<anpok> best in one go..
<anpok> kgunn: I pushed a branch for dandrader that is enough to unblock
<anpok> but not complete
<anpok> i.e. all in all it allows a custom dispatcher and provides a working API to send input events to mir clients through mir::input::Surface
<kgunn> anpok: thanks...so i suppose your in polishing mode on that until its MP worthy ?
<anpok> but .. still missing is .. proper cleanup when surfaces leave scene.. detection of non responding client
<dandrader> anpok, btw, is input_sender.cpp all-new code or did you copy-pasted-and-modified code from andoird::InputDispatcher?
<anpok> s
<anpok> kgunn: yes
<anpok> dandrader: all new
<dandrader> anpok, brave man! :)
<anpok> dandrader: considered c&p but feared the review
<kgunn> heh
<kgunn> hehe
<anpok> kgunn: so yes... several branches in the queue .. based on https://code.launchpad.net/~andreas-pokorny/mir/custom_input_dispatcher/+merge/215174 .. and hopefully someday the mess I caused is cleaned up
<racarr__> I will review that again today....havent caught up on your last few adys of work
<anpok> racarr__: no real change on that one. just some smaller findings ..
<racarr__> I know I just want to review the whole um
<racarr__> sort of stack
<racarr__> Right now though I am deep in meditation seeking the true nature of mir::graphics::CursorImage
<racarr__> ;)
<anpok> AlbertA: kgunn: I would like to push opaque surfaces - but do not see it happen before input singularity
<anpok> so if urgent someone else should take over *wink*
<kgunn> anpok: agreed...rightly so, i see that as a nice optimization
<kgunn> actually...i'd probably ask for some acceptance test love first :)
<anpok> oh dear
<AlbertA> anpok: I don't think it's urgent :)
<racarr__> Sigh...I really dont want to remove cursor_theme from the client API over a debate of the name of the class that supplies cursor images
<racarr__> so that we can come add it again later
<kgunn> AlbertA: can i say powerd, display state stuff is "done"
<kgunn> cleaning up blueprints
<kgunn> if you think there is still some churn there we'll leave it open
<AlbertA> tvoss: ^
<AlbertA> kgunn: I believe tvoss had an re-architecture plan for powerd?
<AlbertA> tvoss__:^
<AlbertA> kgunn: so I haven't seen myself any activity in powerd so it's up in the air right now...
<AlbertA> kgunn: the last discussion I had, it seemed like the MP I have pending in USC would be sufficient
<AlbertA> kgunn: but tvoss mentioned yesterday he had some plans for rearchitecture I think I don't know what things will change
<racarr__> so I am considering cursor_name->cursor_spec, which can take the form like "rightarrow" "default/rightarrow" "gamecursors/rightarrow"
<racarr__> but then that requires a whole description of what a cursor spec is and limits cursor names and
<racarr__> all in all seems kind of silly
<AlbertA> racarr__: more naming wars?
<AlbertA> :)
<kgunn> AlbertA: what's holding up landing the mp pending in usc ?.....is it me landing it ?
<AlbertA> kgunn: no pending on powerd rework
<kgunn> AlbertA: is that seth ?
<AlbertA> kgunn: I dunno if anybody got assigned to that work - rsalveti: ^
<rsalveti> AlbertA: kgunn: which MR?
<AlbertA> rsalveti: the one about removing the display state changes from powerd
<AlbertA> rsalveti: and the input parsing
<rsalveti> I think tvoss__ will indeed change powerd's architecture, but not for now
<rsalveti> AlbertA: have the links in hands?
<AlbertA> rsalveti: no, last time I asked you were going to submit the mr so I don't have a link
<rsalveti> sure, for powerd I still need to create them :-)
<rsalveti> just saying where can I find the other MRs, for usc
<AlbertA> the MP for USC is here:
<AlbertA> https://code.launchpad.net/~albaguirre/unity-system-compositor/screen-power-state-handling/+merge/213957
<rsalveti> I remember I had 2 pending changes to do:
<rsalveti> 1 - export the dim value via dbus
<rsalveti> 2 - remove the display state changes
<AlbertA> rsalveti: right and also no input parsing is needed since the inactivity timers would move to usc
<rsalveti> right
<kgunn> AlbertA: rsalveti ...so is this something we can do before the next "re-architecture" ?
<rsalveti> cool, let me try to get something today still and will ping you back
<rsalveti> kgunn: for sure
<kgunn> cool
<kgunn> (also a question of do we want to...sounds like we do)
<rsalveti> yup
<racarr__> run -> lunch -> back in a bit
<kgunn> kdub: wrt android driver compliance test suite, do you consider our integration tests actually providing that function ?...or is more needed ?
<kdub> kgunn, they provide a test that integrates the drivers with mir
<kdub> I don't know if we should produce a test suite for one of our dependencies though
<kdub> an example... gralloc should be able to open and close cleanly, but it seems strange to make a test that just checks that without any mir code involved
<kgunn> mmm
<kgunn> camako: ^ interesting task kdub has been pushing for a long time now...
<kgunn> e.g. if you're an oem, how do you know you've got all the required bits to run mir
<kgunn> kdub: at any rate i'll reword the task in the bp
<camako> kgunn: yes since android itself is evolving
<kdub> kgunn, okay
<kdub> if the integration tests run, there's a pretty good chance the server/client will run okay
<kdub> the one coverage gap that I can think of is hitting the driver with our screenshotting code
<camako> kgunn, kdub: especially important if oem ever does mir before android :-)
<kdub> sure :)
<anpok> racarr__: ping when you are back..
<racarr__> anpok: Poonng
<anpok> playing with InputRegistrar ..
<anpok> cleaned some of my mess
<anpok> but now that I look at it -> why not introduce something like a SceneObserver?
<anpok> that gets surface_added .. surface_removed..
<AlbertA> anpok: you mean like racarr__ mp: https://code.launchpad.net/~mir-team/mir/introduce-scene-observer/+merge/215969
<racarr__> Indeed
<racarr__> that is getting reproposed today
<racarr__> with some modifications
<racarr__> tried the observer ownership thing...but I guess its not really the best either
<anpok> ah I remember
<anpok> I changed InputRegistrar into something similar
<anpok> but with an awkward name
<anpok> racarr__: will the new version still hold a lock while calling the observers?
<racarr__> another way of conversational standstill on cursor images yay
<racarr__> sorry got distracted from IRC
<racarr__> anpok: Um. Yes so far
<racarr__> its possible to copy the observers...its also possible
<racarr__> in the case of the dispatcher, well
<racarr__> signal in to a dispatcher thread or something
<racarr__> err wait
<racarr__> why does it matter?
<AlbertA> racarr__: last time I tested it one of the tests deadlocked
<racarr__> yeah...I fixed that in the rebased off of rework
<racarr__> surface-observer
<racarr__> version
<racarr__> but now have to unrebase
<anpok> racarr__: because of possible deadlocks.. yeah copy observers .. or remember changes and apply after the loop..
<anpok> or .. something fancy in between..
<racarr__> why is InputRegistrar/Dispatcher changing anything
<racarr__> maybe it should get const mi::Surface
<anpok> just a general thing..
<racarr__> anpok: There are lots of solutions...copy the observers is one but I am inclined to think its kind of costly for something that happens so frequently
<racarr__> other approaches include, recursive mutex, using try_lock on the mutex (And simply mute recursive observations))
<racarr__> remembering changes, something fancy inbetween that remembers changes, or maybe something fancy inbetween that just remembers to emit the notifications
<racarr__> ...so I dont know how to pick one
<racarr__> but I think for now, input can deal with const mi::Surface mostly? and
<racarr__> the compositor jumps the problem with the multiple threads
<racarr__> and ther eis a test in place for that
<racarr__> so I think we can just delay picking something until we are forced and
<racarr__> then we will be able to choose better
#ubuntu-mir 2014-04-23
<kgunn> duflu: wrt "keeping mir working with trusty"... at first, i felt like "yes we should"...but the more i thot about it, there will always be a mir version in trusty, and people can get that code....
<kgunn> granted choosing that route, we would feature starve those on trusty...but this is how most projects in my experience work
<kgunn> if you want new features, move fwd
<duflu> kgunn: I actually meant keep the HEAD buildable with trusty. But RAOF's libinput plans might make that impossible in the end
<RAOF> Not really.
<kgunn> duflu: yeah, i guess i am thinking....its "not that bad"
<duflu> which is fine... there's a lot in flux
<RAOF> Although you won't be able to build the libinput driver on trusty, of course :)
<duflu> I mean if you want people to get involved in your project it has to be usable on a stable platform. That's obviously the LTS
<duflu> But maybe we can't quite guarantee that this cycle
<duflu> Getting input improved is more important that retaining trusty support, IMHO
<kgunn> i think that's too strong a statement...if people want to get involved, they're welcome to be on the latest with us
<kgunn> granted, this might be inconvenient for some...
<kgunn> and it would be nice to do so of course
<duflu> You're asking the typical user to replace what is possibly their only PC with a pre-release OS. I don't think that's ideal but it's nothing new either
<kgunn> mir dev....typical user ? :)
<duflu> Then again, we may have build-from-source instructions to keep trusty going
<duflu> I'm sure libinput is buildable
<kgunn> duflu: last one before i disappear...i can tag at will for 0.1.9 right ?
<kgunn> btw, landing is at a stand still...no such thing as "U" yet
<kgunn> :)
<duflu> kgunn: I highly recommend against it. The regressions are now visible and have fixes on the way
<kgunn> duflu: ok, no problem...
<duflu> On the plus side, 0.1.8 was tagged at a perfect time and has no regressions :)
<kgunn> com' on...we planned it :P
<kgunn> duflu: hey, besides this one...
<kgunn> https://bugs.launchpad.net/mir/+bug/1308941
<ubot5> Launchpad bug 1308941 in Mir "[regression] mir_demo_server_shell crashes on display resume [what(): Invalid or inconsistent display configuration]" [High,Triaged]
<kgunn> what else are you thinking is a must fix regression ? ( i reviewed the bugs..but nothing jumped out)
<duflu> kgunn: Nope. 0.1.8 predates the regression :)
<duflu> They're all bug-never-released, which is good
<duflu> kgunn: Mostly bug 1308843, but there's a list in https://launchpad.net/mir/+milestone/0.1.9
<ubot5> bug 1308843 in Mir "[regression] Client judders, skipping frames periodically" [High,In progress] https://launchpad.net/bugs/1308843
<kgunn> duflu: nice!..thanks for the hygiene, easy to see
<kgunn> ok...night guys...
<kgunn> duflu: i'll keep an eye on those bugs and won't tag until then...
<racarr__> RAOF: So how do I stop x from opening the real input devices
<racarr__> either I already did and the keyboard is working perfectly
<racarr__> or I didnt (seems pretty likely)
<racarr__> and my events are dissapearing into QueueKeyboardEvent because of some strange device configuration error (totally plausible)
<RAOF> racarr__: I'd do it by removing xf86-input-evdev and xf86-input-synaptics from the search paths of your fancy new Xserver.
<RAOF> racarr__: That'll do it for sure; we should, however, patch out the input detection logic in the XMir case.
<RAOF> But we don't yet.
<mlankhorst> ooh fancyyy
<duflu> ?
<mlankhorst> inputless xserver :)
<duflu> Oh that
<duflu> I hate it when Europe wakes up
<duflu> Oh, hi Europe!
<duflu> :)
<mlankhorst> I don't think canonical would approve of me sleeping all day :P
<mlankhorst> during work time
<RAOF> I think they'd be fine with it, as long as you worked all night!
<duflu> Bah it's fine. I have a plan to finish at a sane hour tonight
<RAOF> Speaking of sane hours, 6pm says EOD!
 * duflu waves to RAOF
<mlankhorst> lies :P
<duflu> alf_: You changed the meaning of conf_output.used to sometimes be false even for a display in use (but off). Is that a good idea/required?
<alf_> duflu: where did I do that?
<duflu> alf_: r1546... but maybe I got it backwards?
<duflu> alf_: Oh, that's not it. The issue is just setting current_mode_index=<invalid> on resume
<duflu> That's more straightforward
<alf_> duflu: hmm, yeah, so because of the change to not have a DisplayBuffer (and the underlying framebuffer object) for displays that are off, the mode is cleared
<alf_> duflu: not sure how to best handle that, we update the configuration information using the information given by the hardware
<duflu> alf_: I think it needs to remember the current mode. Because guessing on resume with preferred_mode could easily be wrong
<alf_> duflu: What about the case that you power off the screen, then unplug it and plug in a new one? That is, how can we differentiate when to remember and when to not remember?
<duflu> alf_: I'm testing with simple pause and resume. How should demo-shell remember the mode between Alt+P's
<duflu> ?
<duflu> Previously it was just remembered in the display structure
<alf_> duflu: the point is that when we request the configuration, we shouldn't make any assumptions about it, because it can change because of events external to mir (like someone pluging things in or out)
<duflu> alf_: Yeah I know, but more common is a simple suspend/resume... And it makes no sense to move responsibility for saving just one attribute outside of the structure
<duflu> Never mind, I'll either find a way or cook dinner early
<alf_> duflu: I would be OK with that as long as it is safe to do so (e.g. the set mir_power_mode_off, unplug screen, plug a new one scenario)
<alan_g> alf_: duflu can we just hash some display attributes to detect changes vs on/off?
<duflu> alan_g: The field that stores the current_mode is presently invalid. All we need to do is not set it to invalid and keep its old value
<duflu> So a dumb shell can set outputs off/on/off/on blindly
<alan_g> duflu: I think alf_ is worried that the old value could be wrong if the device changed.
<duflu> alan_g: Which is still validated, and better than what we have now (invalid --> crash)
<alan_g> ack
<alan_g> duflu: any thoughts about this approach: https://code.launchpad.net/~alan-griffiths/mir/spike-shell-namespace/+merge/216332
<duflu> alan_g: None at all. I'm involved in too many reviews again so won't get involved
<alan_g> duflu: np
<alf_> duflu: The same would happen with the new scheme too, if we don't do things properly... an invalid value in the configuration (e.g. mode 4 out of the 3 modes of the new monitor) will cause the same crash. Anyway, it may not be a problem really, because when a screen is unplugged we handle the event internally and update the configurations. So, to be safe we need to serialize all display conf changes (incl. power on/off) with our main loop, so probably an Disp
<duflu> alf_: It's actually an easy fix it seems. The off display still has a persistent structure and ID. Only challenge to do a regression test
<mterry> Is greyback on vacation?
<alan_g> I was wondering that too
<ogra_> lying in the sun and turnuing into brownback :)
<racarr__> Morning
<anpok> maybe for some people :P
<racarr__> anpok: Wait are you implying the other things on IRC are also people?!?!
<racarr__> seems I owe some apologies
<racarr__> :p
<anpok> hm yah proving that gets harder every day
<racarr__> haha thats what
<racarr__> sprints are for
<RAOF> Mornin all.
<RAOF> racarr__: What up, dude!
<racarr__> Morning!
<racarr__> Nothing much...just getting back to xmir soon....new scene observer...maybe cursor part 1 can land now then I will rebase the rest.
<racarr__> xmir is still where it is yesterday...things getting as far as QueueKeyboardEvents...but as im not unloading the default drivers and
<racarr__> not getting duplicate key events I assume its not working lol
<racarr__> presumably some field of one of the device configuration structs needs to be set to 9 instead
<racarr__> of 7
<racarr__> yeah its definitely not working
<RAOF> Heh.
<RAOF> Are you running your XMir as root?
<RAOF> Because if you're not then the other input devices wouldn't actually be getting opened due to permissions.
<racarr__> I am so it can write to the log file aha um
<racarr__> I tried adding 11 to keycode though
<racarr__> and everything is still good
<racarr__> so its certainly not my keyboard events
<racarr__> going anywhere
<racarr__> QueueKeyboardEvents is being called, xf86PostKeyboardEvent, etc...
<racarr__> just need to read some code...
<RAOF> Heh.
<RAOF> --prefix=$HOME/.local. It's the way of the future!
<racarr__> o maybe
<racarr__> I actually built debs this time lol
#ubuntu-mir 2014-04-24
<RAOF> :)
<bschaefer> hello, getting a fun failed to mmap a buffer, only when running it through SDL: http://paste.ubuntu.com/7317028/. demo multiwin works fine :(
<bschaefer> the mir surface is created, and is valid
<duflu> bschaefer: Weird buffer dimensions/attributes? Tested other software buffer demos like "progress" or "fingerpaint"?
<bschaefer> duflu, i tested outt he pixel formate, which was fine
<bschaefer> duflu, alright
<bschaefer> duflu, hmm they appear to be working, i check what other info in the surface creation bit i could be messing up
<duflu> bschaefer: Either that or a buffer/structure overrun could be corrupting some critical field
<duflu> (valgrind)
<bschaefer> duflu, good idea!
<duflu> bschaefer: Please also update this :)  https://bugs.launchpad.net/mir/+bug/1247943
<ubot5> Launchpad bug 1247943 in Mir "Mir server failing to start when compiled for 32bit" [High,New]
<duflu> bschaefer: Oh, which driver?
<bschaefer> duflu, that was me a bit ago, on intel
 * bschaefer updates
<bschaefer> duflu, hows all else going?
<duflu> bschaefer: Busy. And this week is book-ended by two public holidays in Oz
<duflu> bschaefer: How's your end?
<duflu> sunny Seattle :)
<bschaefer> duflu, raining atm :)
<bschaefer> duflu, Oz, sounds like fun!
<duflu> Follow the yellow... lawn?
<bschaefer> haha
<bschaefer> duflu, summer coming to a nice warm end?
 * bschaefer is just now starting to hit some summer days
<bschaefer> duflu, valgrid, i've not dug through it yet.... lots of info.. http://paste.ubuntu.com/7319558/
<bschaefer> did mir move to using ShmMemory?
 * bschaefer doesn't remember that being around a while ago
<duflu> bschaefer: Just search for your own code to narrow it down. Then again, a simple overrun clobbering just Mir structures would not be detected as an overrun within the context of the client process :P
<duflu> bschaefer: Yeah Mir's software buffers implementation changed some months ago
<bschaefer> duflu, ill check it out :)
<bschaefer> it has to be my issue haha
<bschaefer> duflu, thats for the help!
<bschaefer> thanks*
<duflu> bschaefer: No problem
<duflu> Whee, new Ubuntu release, new flood of teething bug reports
<racarr__> UTOPIC UNICORN
<RAOF> uTopic unicorn :)
<duflu> Whoa. Utopic Unicorn
 * duflu wonders what this means for Ubuntu and its relevance to reality
<anpok> RAOF: ping
<RAOF> anpok: Pong
<anpok> two days ago it was unsure wether your 1hz branh would make it in so I too the timer parts
<anpok> and proposed them as a separate branch
<anpok> now it seems like the 1hz branch would make it after 0.1.9
<anpok> or I am not sure..
<anpok> I need the functionality for the input stuff
<RAOF> Heh.
<anpok> and did not want to duplicate anything
<RAOF> I can rebase on your branch if you like.
<anpok> ok - since i would adress findings as far as possible that come up in https://code.launchpad.net/~andreas-pokorny/mir/add-timer-to-main-loop/+merge/216881
<anpok> that would be cool
<RAOF> anpok: Yeah. Go for your life; address Alan's concerns, and I'll merge on top.
 * RAOF -> EOD
<duflu> Hmm, my monitor exposes 50Hz modes on DisplayPort but not DVI?
<duflu> ?
<dandrader> anpok, got the qt compositor working with lp:~andreas-pokorny/mir/input-sender-split
<dandrader> anpok, good work!
<anpok> great news!
<kgunn> dandrader: anpok ....that is really nice work!
<kgunn> anpok: think we could try to get that landed onto dev branch in the next few days ?....it'd be really great if we could bring that along with our 0.1.9 tag
<kgunn> note: i'm not going to tag until we address a couple of regressions
<anpok> ah ok - i thought we would wait for after 0.1.9. I will try to clean things up
<kgunn> anpok: i'll take your lead, i would like it in 0.1.9 but if you think it injects too much risk that's worth considering...
<anpok> the way it is built right now, makes it work kind of in parallel to the existing dispatcher code. hence the risk is low..
<anpok> of course at some point i will remove the old send path..
<kgunn> anpok: thanks...that's good to hear, since we're at the beginning of cycle i'd like to get it into 0.1.9, risks are easier to swallow :)
<kgunn> so its worth waiting on for a day or 2 for sure
<alf_> kgunn: which regressions do we need fixes for before 0.1.9?
<kgunn> alf_: we have this list...
<kgunn> https://launchpad.net/mir/+milestone/0.1.9
<kgunn> but in reality there are 2 that i'd consider musts
<kgunn> 1308843
<kgunn> 1308941
<kgunn> ....and this one kinda troubles me 1294510
<alf_> kgunn: 1308843 is not as bad as it sounds, and doesn't seem to affect the phone... I would propose ignoring it for 0.1.9, because it is going to be fixed by the "1Hz" branch, but we can't land the 1Hz branch for 0.1.9 because we will need to become more confident in it.
<alf_> kgunn: unless we say that we postpone 0.1.9 for some time until 1Hz has been tested properly
<kgunn> alf_: hmmm, i understand now...it does stink b/c we definitely want to land this sooner than later
<kgunn> alf_: how come it doesn't manifest on the phone ? nested ?
<alf_> kgunn: I can't see it on any of my computers, so I don't have first hand experience, but my understanding is that the effect this has depends on the vsync timings of the outputs (in this case the real output and the fake 60Hz one)
<kgunn> alf_: right, i was kind of assuming that the fake 60 hz will never be perfect for any display, timing will always be off somewhere
<kgunn> i guess, if the fake is a bit slower than the screen you're  ok?
<alf_> kgunn: Right. So one thing we could potentially do for 0.1.9 and should be relatively safe is reduce the fake output rate to something sufficiently small e.g. 10Hz.
<racarr__> Guten morgen
<alf_> kgunn: oops, that won't work
<anpok> racarr__: Guten Tag
<racarr__> :)
<racarr__> *races breakfast with standup*
<josharenson> kgunn, current graphics dashboard is broken down by resolution and GPU manufacturer. Keep that format, or categorize by device?
<kgunn> josharenson: mmm, can we expand ?...to include formfactor {phone, tablet, desktop}
<kgunn> we should keep screen res
<kgunn> and gpu
<kgunn> for sure
<kgunn> or... if not formfactor, device name.... mako, manta, macbook, dell###
<josharenson> kgunn, I can probably add that... the website looks like it was originally written to show desktop performance
<josharenson> its organized only by resolution and gpu, but can probably add anything
<josharenson> kgunn, I'll work on resolution and gpu for now (cause thats what there) and add other criteria later. I'll let you know if there are issues with that...
<kdub> alf_, once I fix https://code.launchpad.net/~kdub/mir/plumb-android-shader-creation/+merge/216779/comments/515830, would you be okay with a top-approve?
<racarr__> A moment of silence for null cursor *bows head*
<josharenson> robotfuel, I'm working on extending the qa-dashboard/graphics page and was wondering what the significance of the "ps" prefix to the names of all gpus?
<robotfuel> josharenson:  it's product-strategy the name of the group that owned the machines.
<kgunn> alf_: hey, so looks like i can tag the tip of devel...
<kgunn> anything else outstanding that needs to merge ?
<kgunn> anyone ^
<josharenson> robotfuel, ah thanks... any reason to preserve that convention? even if other machines?
<kgunn> otherwise i'll do it this afternoon....and apologize to duflu at the same time :)
<robotfuel> josharenson: no it was the name of the machine, that's all. ps was absorbed in to ubuntu engineering.
<josharenson> robotfuel, ack
<kdub> kgunn, I'm okay to merge
<racarr__> +1
<racarr__> mieqEnqueue
<racarr__> for some reason that breaks my brain
<racarr__> (random x server function lol)
<kdub> they just mis-spelled meek... see meekEnqueue
<kdub> like a polite equeuement, obviously
<racarr__> hahaha
<racarr__> common locking pattern, reader, writer, and meek writer.
<AlbertA> kgunn: https://code.launchpad.net/~vanvugt/mir/fix-1308941/+merge/217021
<AlbertA> kgunn: that should probably land so 1308941 is taken care of
<kgunn> AlbertA: thanks...i'll keep an eye on it
<racarr__> yay shift key now outputs
<racarr__> m6 hwich must mean
<racarr__> xmir input is close to working
<racarr__> ;)
<racarr__> as in now just mapping is off
<racarr__> very off apparently
<racarr__> but besides that getting close lol
<anpok> racarr__: mapping as in mapping of different keyboard types?
<racarr__> well just somewhere int he mapping of scan code to key code
<racarr__> something has gone wrong
<racarr__> as usual the answer was add or subtract 8 from scan code
<racarr__> :p
<racarr__> in this case its add 8 when going from mir scan code to x scan code
<AlbertA> racarr__: can I add that comment on all bugs? "Did you try adding 8?" ;)
<AlbertA> or 42 could work too...
<racarr__> AlbertA: on all input related bugs I think its a fair comment lol
<racarr__> </lunch>
<racarr__> probably top 10 lunches of the year so far.
<josharenson> robotfuel, just wanted your opinion... after looking at all the code, it seems creating a standalone 'performance test' category, rather than nesting under 'graphics' seems like a good idea... thoughts?
<racarr__> hahaha watching the xmir cursor follow
<racarr__> the mir cursor
<racarr__> is my new hobby
<racarr__> in other news increasming amounts of xmir input
<racarr__> work
<kgunn> josharenson: camako and i were talking about comparing mir & SF
<josharenson> kgunn ok
<kgunn> question is, do you know if Qt on the QPA for SF just renders as if the Qt engine were a full screen app on SF ?
<racarr__> Everything (including the shell) is in fact a full screen app on SF right?
<racarr__> no in process shell or any such..suchness
<josharenson> kgunn, are you trying to determine something about bypass?
<josharenson> kgunn, cause I'm not sure, but if you dump layer contents, it should be obvious
<kgunn> josharenson: not really about bypass...more like trying to satisfy the question of is mir on par with sf
<josharenson> kgunn which I'm not sure how to do in ubuntu.... only android
<kgunn> kdub: would know
<kgunn> racarr__: true...no in process shell
<kgunn> racarr__: also true...no nested
<kgunn> hmmm
<kgunn> makes comparing more difficult me thinks
<kdub> kgunn, I know the stuff we have to improve, yes
<robotfuel> josharenson: there are already people working on performance tests, ping cgoldburg or nuclearbob
<kdub> kgunn, or did you mean something else?
<kgunn> kdub: something else...but i think racarr__ negated it
<kdub> right, at the end of the day, its tough to get an apples-to-apples of the whole stack
<kgunn> robotfuel: do you know what kind of performance tests ? are they to compare sf & mir ?
<kdub> and some of the key differences are in driver details that are abstracted from us
<robotfuel> kgunn: no all kinds of performance tests.
<kdub> so its tricky to negate the goodness or badness of the particular driver
<kgunn> kdub: camako josharenson ...i'm starting to wonder, would a simple native gl test written specifically native to sf and then native to mir be the only wya ?
<kgunn> way
<robotfuel> kgunn: not sf vs mir
<camako> kgunn: So we are measuring graphics perf?
<kdub> kgunn, even at that, there's some serious headaches
<kdub> like if you have "setprop debug.mdpcomp.maxlayer" set to two vs four on mako, you might get different results that take a while to figure out
<kdub> or if you happen to run on tegra3, the hybris pthread issue might bite
<camako> kdub: what is mdpcomp.maxlayer switch for?
<camako> hw overlays?
<josharenson> what exactly are you trying to measure? just general performance?
<kdub> its just a mako switch for if the hwc happens to select the mdp core, to limit the number of layers it will accept :)
<kdub> just making the point that there are sorts of little gotchas there that a quagmires to sort out
<camako> kgunn: any non-trivial graphics apps should produce the same result (fps?) on mature platforms
<camako> emphasis on "should" and "mature"
<kdub> camako, right, agree
<kdub> but also, the result is fps+power
<camako> kdub: yes, cpu bw, mem bw, etc...
<kdub> right
<camako> I guess without messing w any switches, comp at gl level would make sense to answer "is mir up to par with Android?"
<camako> Assuming we don't already know the answe :-)
<racarr__> We dont know the answer wrt power.
<racarr__> But of course both are capable of rendering rectangles at 60hz in isolated conditions
<kdub> right
<camako> I see
<racarr__> interesting sort of questions to me are like
<kdub> like, and the other side is, are we capable of explaining any deltas?
<racarr__> say same EGL app rendering at vsync on mir and SF and measure power
<racarr__> hmm? You mean deltas over time or deltas
<racarr__> v. surface flinger
<kdub> vs surfaceflinger
<camako> then I guess gl perf would make sense
<camako> gl perf comp*
<camako> josharenson: kgunn mentioned you were (or would) work on this, have you started this comp effort bw sf and mir?
<kdub> but like, do we have control over the gl drivers? we're just comparing (switching logic + ipc roundtrip) then
<josharenson> I have a test that runs glmark2....
<josharenson> camako, but if we just need a simple gl app...
<camako> kdub, correct... Do we care to have control over the gl drivers since what we develop is outside those
<racarr__> ok if you ignore everything that isnt a 3button+2axis mouse or a us english keyboard
<racarr__> and dont click on buttons at the same time
<racarr__> xmir input is workin perfectly :D
<camako> kdub, like a stock system-level comparison.. what an avg user would experience...
<racarr__> as part of the overall process of ubuntu
<racarr__> its good to have gl performance benchmarks
<kdub> like, we can plumb mir/unity8 to get that information, and its good for analyzing, but to compare to surfaceflinger
<racarr__> in terms of comparing mir to other compositors
<racarr__> I dont think its useful
<kdub> we have to plumb surfaceflinger at the same points
<camako> fps, cpu %, power consumption don't require mir/unity specific plumbing, do they
<kdub> well, not to measure those, but if we investigate, and figure out the ipc is slow or something, we do
<camako> kdub, I agree that comp at that granularity is not useful.
<camako> kdub: I don't know what info kgunn wanted to get out of it, but I think it'd be useful to get those readings for a simple app on mir vs SF for comps
<camako> Or may be not... :-)
<camako> those readings being fps, cpu%, power
<kdub> sure, but we're already in the ballpark though
<camako> kdub, someone measured already?
<kdub> camako, measured what? :)
#ubuntu-mir 2014-04-25
<josharenson> re: glmark2, currently the test is failing on jenkins as the environment setup does not start a mir server. Is there a reliable way to kick off a server automatically? I would prefer not to use popen if possible
<racarr__> josharenson: You can link against libmirserver and call mir::run_mir with an instance of DefaultServerConfiguration I suppose
<racarr__> see examples/basic_server.cpp
<racarr__> um
<racarr__> running mir_demo_server_basic or mir_demo_server_shell may be better though...
<bschaefer> racarr__, is there much of a difference between the two? I've always just used the shell
 * bschaefer just sees config changes 
<racarr__> bschaefer: demo server shell has some keybindings some window shadows a background
<racarr__> etc
<bschaefer> oo i see, thats where all thats coming from
<bschaefer> cool
<slvn_> Hello
<slvn_> SDL has support for MIR. Any Idea how I could get the SDL crossed compiled for UbuntuPhone ?
<alan_g> slvn_: I've not looked at SDL but would you be able to do something similar to the Mir cross-compile-chroot.sh script?
<tvoss> slvn_, you should ping bschaefer later on, he wrote the SDL mir backend
<slvn_> this is the cross-compile-chroot.sh : https://github.com/eMir-server/eMir/blob/master/cross-compile-chroot.sh  right ?
<slvn_> I will give a try
<slvn_> and try to contact also bschaefer
<slvn_> thanks!
<alan_g> slvn_: http://bazaar.launchpad.net/~mir-team/mir/utopic/view/head:/cross-compile-chroot.sh
<slvn_> alan_g|errands, thanks for the link!
<kdub> yay overlay client on the screen
<kdub> some kinks to work out though
<josharenson> racarr__ My test case starts a mir server internally a la the examples... However, since the server takes a non trivial amount of time to come up, is there a callback that is fired when initialization of the server is complete?
#ubuntu-mir 2014-04-27
<slvn_> Hello
<slvn_> I have a Nexus 10, where I put UbuntuTouch (#303)
<slvn_> I have cross compiled the lib SDL, using a chroot armhf, and I am trying to run an application SDL on this device
<slvn_> I have changed the call "mir_connect_sync(NULL, ...)" to "mir_connect_sync("/tmp/mir_socket")
<slvn_> so that is connect correctl (call to connection_is_valid returns true)
<slvn_> and I have switch the internal configuration of SDL to use openg es 2.0  ... to avoid the lib crashing
<slvn_> my test programm executes correctly, but nothing is displayed on the screen !
<slvn_> Any Idea ?
#ubuntu-mir 2015-04-20
<robert_ancell> Has anyone tried Mir with the open VC4 driver (i.e. on a Raspberry Pi)?
<kdub> groan, I rewrote geom::Displacement
<kdub> robert_ancell, i havent tried, but there seems to be an android driver around for it, so it stands a good chance of working
<kdub> robert_ancell, but, you probably meant, http://dri.freedesktop.org/wiki/VC4/, which also stands a good chance of working with the mesa platform
<robert_ancell> kdub, yeah that.
#ubuntu-mir 2015-04-21
<mpt> So, hereâs a puzzle
<mpt> Letâs say Mir is responsible for docking windows (like docking Inkscapeâs palettes inside its document windows)
<mpt> So that the window decorations can be consistent regardless of whether a window is docked or not
<mpt> What if the app puts the dockable windows inside a scrolling pane in its window (as in Inkscape)? How would the app represent the scrolling pane to Mir?
<greyback> mpt: is there an app that does that already?
<mpt> greyback, you mean, besides Inkscape?
<greyback> mpt: ah, I misread you, sorry.
<greyback> I'd need to check, but I suspect in that case, the actual dockable window is destroyed, and everyting it contained was reparented inside the scrollable pane of the main window
<mpt> Yes, LibreOffice
<greyback> I don't see how else it would work, say if you scroll that pane so part of the "dockable window" is occluded - it would be horribly complex to try telling the compositor to only draw the bottom bit of that dockable window
<mpt> I think one pleasant side-effect of handling docking in Mir is supposed to be that the app doesnât have to destroy and recreate everything
<greyback> mpt: if it wants to integrate the contents of that dockable window into the main UI, it's probably easier just to reparent, than trying to reposition a child window
<mpt> That makes sense to me â especially if the docked window has to (for example) get wider
<mpt> But Mir would still need to handle the clipping case so that it can render the docked windowâs window controls
<mpt> If it isnât doing *that*, then thereâs no point in Mir handling docked windows at all, that I can see.
<mpt> The original problem to be solved is that the title bars of docked palettes in (for example) LibreOffice vs. Inkscape are gratuitously inconsistent.
<greyback> mpt: to solve that issue, could have the app use freestyle surfaces for palettes and draw their own decoration, so it matches
<greyback> just an idea
<mpt> greyback, yes, that would make LibreOfficeâs docked vs. undocked palette consistent. But it wouldnât make LibreOfficeâs undocked palette consistent with Inkscapeâs or any other appâs.
<greyback> mpt: true, but while docked, they are not windows any more, they are widgets drawn as part of the main window. In that situation, how they draw a "decoration" is up to them, not mir. So only way to make them consistent is to patch those apps
<mpt> greyback, I think âhow they draw a âdecorationâ is up to themâ is the problem to be solved. Because if it is up to the app, I canât see how they could possibly do it in a way that wonât get out of date as soon as the OS theme changes.
<greyback> mpt: yeah. We could offer a widget to app devs for decorations, one that we can theme as we wish. Could also be used by apps which want to draw their own decoration too, but then will customize it (e.g. chromium).
<mpt> That might work better, yes
<mpt> It seems to me that docked windows have custom controls in their âtitle barsâ much more often than undocked windows do, too
<mpt> (which is why Inkscapeâs undocked windows have two title bars each, for example)
<seb128> hum, bug #1445542 ... is mir/unity8 handling multiple surfaces now?
<ubot5> bug 1445542 in gtk+3.0 (Ubuntu) "Using the Mir backend, secondary windows of GTK apps open behind the primary window" [Undecided,New] https://launchpad.net/bugs/1445542
<seb128> greyback, ^
<greyback> seb128: mir/unity8 not handling separate surfaces still
<seb128> greyback, can you comment on that bug? means the gtk part is invalid?
<greyback> seb128: hmm duflu marked gtk as affected, he's testing with stock mir, not qtmir/unity8
<seb128> greyback, oh ok, so maybe different issues
<greyback> yeah, I suspect so
#ubuntu-mir 2015-04-22
<seb128> is anyone looking at https://errors.ubuntu.com/problem/009ff218f16e78b57614e9a3a0e4ddae9cb0750a / https://bugs.launchpad.net/ubuntu/+source/unity-system-compositor/+bug/1442508
<ubot5> Ubuntu bug 1442508 in unity-system-compositor (Ubuntu) "/usr/sbin/unity-system-compositor:11:Add:add_surface_pixel_format:mir::frontend::SessionMediator::connect:mir::frontend::detail::invoke:mir::frontend::detail::ProtobufMessageProcessor::dispatch" [High,Confirmed]
<seb128> it's one of the most reported vivid issues on e.u.c this week
<seb128> seems it started with u-s-c 0.0.5+15.04.20150227-0ubuntu1 (the most recent version)
<mterry> Is there a convenient way to get mir-next on my machine?
<mterry> I see the staging ppa
<mterry> But that only has mir
<mterry> Not usc, qtmir, and unity8 rebuilt
<kdub> mterry, not in general
<kdub> but, there should be a coherent silo being put together this week
#ubuntu-mir 2015-04-23
<duflu> racarr: Still around?
<racarr> duflu: Si
<racarr> whats up?
<duflu> racarr: Heh, you shouldn't be still around :) ... I'm about to revert r2505 to fix tests crashing unless you can fix it directly?...
<racarr> duflu: Go for it...I am playing Go -.-
<duflu> racarr: Kay
<racarr> Sorry :(
<duflu> racarr: It's OK. You should be offline by now :)
<sgx1> it seems that the wiki page https://wiki.ubuntu.com/Mir/Spec is outdated. what are the current gaps for mir? any roadmap?
<tvoss> sgx1, good point, taking an action to update it
<tvoss> sgx1, in the meantime, what are you specifically interested in?
<sgx1> window management, input method, security stuff and the current status of  toolkit(qt, gtk, etc) support.
<gQuigs> trying to parse this bug (https://bugzilla.mozilla.org/show_bug.cgi?id=694570) ,  current suggestion would be to add a dependency to libsm/libice,  is there a better way to do this going forward?
<ubot5> Mozilla bug 694570 in Startup and Profile System "Stop using libgnome and libgnomeui on Linux" [Normal,New]
<gQuigs> or is desktop environment specific dbus sessions the answer?
#ubuntu-mir 2015-04-24
<RAOF> gQuigs: There's currently no cross-desktop solution for !X11\
#ubuntu-mir 2016-04-25
<robert_ancell> kgunn, hey, remember when you asked me how to install the archive version of a package? You can do this easily, i.e. returning gnome-calculator to the archive version can be done with 'apt install gnome-calculator/xenial'
<robert_ancell> i.e. this is equivalent to 'apt install gnome-calculator=(version in xenial)'
<kgunn> robert_ancell: cool trick thanks
<kgunn> why are you awake?
<robert_ancell> kgunn, in Prague
<kgunn> ah right
#ubuntu-mir 2016-04-26
<robert_ancell> RAOF, with nested X, can acceleration easily pass through now?
<robert_ancell> And is the double IPC overhead not a major issue?
<RAOF> I'd be astounded if it was.
<RAOF> I mean, it'll be an overhead, but anything that's actually doing appreciable IPC with X is already a lost cause.
<RAOF> And, yes; Xephyr is glamor-accelerated now and I believe supports GLX, too.
<robert_ancell> Nice
<robert_ancell> RAOF, how about window management? Do you need a special WM in the child X to have the correct behaviour?
<RAOF> Yes, we'd need that.
<robert_ancell> That is the hard problem I guess :(
<RAOF> Indeed.
<RAOF> One we've committed to solve, though.
<robert_ancell> For U8, but not U7
<RAOF> The solution for U8 could *be* the solution for U7
<robert_ancell> RAOF, do we have a dedicated WM project now?
<RAOF> No idea.
<duflu> greyback_: I haven't (successfully) set up a test of U8 with this fix yet, but do you think QtMir might need fixing similarly? https://code.launchpad.net/~mir-team/mir/fix-1528109/+merge/291984
<duflu> Unity8 is definitely broken in the same way. I'm just wondering if it needs a separate fix
<greyback_> checking
<greyback_> duflu: I don't think it is the same issue. From a cursory glance (pun intended) our cursor code doesn't assume integer movements
<duflu> greyback_: Cool. Fingers crossed then Mir 0.23 is all it needs
<duflu> Mir 0.22 I mean
<greyback_> ack, thanks
<duflu> greyback_: On that note, does U8 have its own acceleration curve now? Seems like we should not have two because that's resampling the resampled
<greyback_> duflu: it does not
<duflu> greyback_: If you want, I would prefer U8 did it and Mir just dealt with raw unmodified input coords
<duflu> That would solve some more libinput regressions
<duflu> Or Mir could just set a more sane default (off) then libinput's default (on)
<greyback_> duflu: I don't see why we'd not use libinput's accel stuff.
<duflu> libinput's acceleration curve is ugly and still causes bugs
<greyback_> but it's customizable IIRC
<duflu> Yeah, Mir could just set it to 'off'
<greyback_> sure, but why reinvent if we can get libinput to do what we want
<duflu> Its first derivative is not continuous.
<duflu> which I think is a big part of the problem
<duflu> Turning it off would return us to perfect and accurate mouse movement (Unity7 style)
<greyback_> or we could work with upstream so that everybody gets that
<duflu> More difficult to convince people their design sucks than just of some bug
<greyback_> more work for us to take on entire burden of input processing
<duflu> We actually don't need any any more. Since the resampling bug (recently fixed) was just a bug... that fix remains and "acceleration" of any sort is no longer required
<greyback_> I don't understand. Why isn't pointer accel needed? It will be a user-configurable setting eventually
<duflu> greyback_: Absolutely user configurable. I'm just suggesting make the default "none" instead of some weird curve. So it's exactly like Unity7
<duflu> Which really is a discussion for mir-team
<greyback_> duflu: I'm ok if you want to disable it in libinput. I'm not ok with reimplementing it in unity8, if libinput would do the job with some tweaking
<duflu> greyback_: That's OK, I just feared U8 already did some
<greyback_> nope
<duflu> There are sliders
<duflu> which do nothing
<greyback_> duflu: sliders in the settings app? I believe they'll talk to USC which will configure libinput
<duflu> Cool
<greyback_> (not the final solution ofc)
<duflu> Better than expected
<duflu> greyback_: Why two? They're not labelled
<greyback_> duflu: I honestly don't know, you'd need to ask settings app guys
<n1md4> hi.  i have a gtx980m and nvidi-364 driver.  when i attempt to login to mir / unity 8 it somewhat hangs at the login screen.  does this type of problem sound familiar to anyone?
<n1md4> worth reporting a bug?  is so where.
<n1md4> if so, where* even
<ogra_> since when does Mir work with proprietary drivers ?
<n1md4> hah
 * ogra_ thought it only works with nouveau
<n1md4> http://phoronix.com/scan.php?page=news_item&px=NVIDIA-364.12-Linux
<n1md4> :)
<n1md4> i suppose, just because something is 'supported' doesn't yet mean it works.
<ogra_> ah
<ogra_> well, but how would they test the support then ? :)
<alan_g> n1md4: there's work in progress, but not there yet
<n1md4> ogra_: no idea :)
<ogra_> there you have your answer though
<n1md4> alan_g: thanks, i did check in here the other day, may have been you i spoke with then.  what's the best way to keep up to date with this?  would it be enough to check for ubuntu updates and catch when mir is in that list?  or is there a more efficient way.
<alan_g> n1md4: Mir releases are announced on Mir-devel@lists.ubuntu.com (if you don't mind the traffic)
<n1md4> thanks, alan_g, i'll check it out
#ubuntu-mir 2016-04-27
<Saviq> guys, https://requests.ci-train.ubuntu.com/#/ticket/1303 was already QA: Ready yesterday, https://bazaar.launchpad.net/~mir-team/mir/0.22/revision/3482 got pushed, though, so silo says it needs rebuild again
 * alan_g wonders why bin/mir_demo_server is a script for running "Mir Performance Tests"
<anpok> ahh
<anpok> me already stared confused on the output of ptest
<duflu> alan_g: Resizing crashes, I found are easier to reproduce under valgrind
<duflu> Just enough racing to break our buffering logic
<duflu> Saviq: I don't mind if we revert the changelog correction. Would that be better?
<duflu> Although we're append-only, so that would just create a new revision
<Saviq> duflu, IMO yes, otherwise we need to rebuild and retest
<alan_g> anpok: bzr merge -r3477..3476. fixes it
<Saviq> bzr uncommit
<Saviq> bzr push --overwrite ;P
<duflu> Saviq: It's protected against those. I'll need to unprotect
<Saviq> only way to make train happy again
<anpok> alan_g: yeah.. but I dont see why that change would cause
<anpok> it
 * alan_g doesn't care why. Is going to MO a revert
<anpok> ack
<anpok> ah
<duflu> alan_g, anpok: I don't know how to reproduce that binary mixup..?
<anpok> cp cp ${CMAKE_CURRENT_SOURCE_DIR}/performance_tests.sh ${CMAKE_RUNTIME_OUTPUT_DIRECTORY}/mir_performance_tests overwrittes the wrapper script binary links to it
<anpok> that probably only happens on an incremental build
<duflu> anpok: Your tree is unclean. User error :)
<duflu> cp -f perhaps?
<alan_g> Doing an incremental build isn't a user error
<duflu> alan_g: OK, that explains why CI and myself never saw it. I'll fix it
<duflu> Although you really should be testing fresh builds daily
<duflu> Dear train: I hate you. Love duflu
<duflu> Saviq: Done
<Saviq> duflu, thanks
<alan_g> duflu: irrelevant, Incremental builds should work.
<duflu> alan_g: OK, fixing it now
#ubuntu-mir 2016-04-28
<robert_ancell> RAOF, Can Xephyr be run in rootless mode?
<RAOF> robert_ancell: I don't believe so, but could probably be made to do so easily.
<robert_ancell> RAOF, define "easily" :)
<RAOF> robert_ancell: Well, you'd get most of the way there by having a root window and just making it transparent? :)
<robert_ancell> RAOF, but then the window decorations would get very complicated for the internal WM
<RAOF> Yeah, is true.
<RAOF> So, my guess is ânot *terribly* difficult or invasiveâ.
<RAOF> Well, maybe a *bit* invasive.
<RAOF> Say, less than a month all up?
<robert_ancell> For who? I think it would be more than that for me given my experience. Perhaps a RAOF+duflu team would do it in a month..
<robert_ancell> RAOF, with XMir in rootless mode, how much work does the window manager need to do? The placement should all be done by the parent WM right?
<robert_ancell> I mean the WM that runs inside XMir
<RAOF> Yeah.
<RAOF> The end-state for XMir in rootless mode is that the X11-WM is basically nothing but a proxy to the external WM.
<RAOF> Needs to do a bit of translation for resizing and such.
<duflu> robert_ancell: Xmir -rootless completely throws away the window manager, and implements WM itself Mir-style
<robert_ancell> duflu, ah
<duflu> You could still run one, but it might conflict
<robert_ancell> So XMir on X would probably be the most working solution...
<duflu> robert_ancell: On X?
<robert_ancell> Mir has an X backend right?
<robert_ancell> (I'm kidding)
<duflu> robert_ancell: Yes it does exist, but that's fullscreen Mir server in an X window
<duflu> robert_ancell: Xmir -rootless implements its own XComposite-based window management. I know of no shell that handles it well yet, but also implemented a workaround for that too: Xmir -rootless -flatten  which only asks the Mir shell to implement one window per app (which most Mir shells can handle)
<duflu> Umm, I mean -flatten uses XComposite
<duflu> So Xmir uses Xorg to do the compositing in software with -rootless -flatten
<duflu> Actually since widgets are windows, that's normal
<RAOF> It's not using the hardware-accelerated compositing path?
<duflu> Nope. Because that's actually very buggy, and not beneficial to pursue right now either
<RAOF> That seems unlikely? We're using the same glamor hardware-composited path on regular X.
<duflu> RAOF: armhf is set to always software anyway. Desktop is not
<duflu> That's why it works
<RAOF> That I can see; armhf glamor is unlikely to be awesomely well tested :)
<duflu> Hardware acceleration matters much more for GLX clients. However that's only really feasible with DRI (desktop hardware)
<duflu> And in all fairness, even software buffers are cached in hardware for most of their life, so performance is good
<RAOF> Right, but GPU composition is vastly faster than CPU composition on all hardware.
<RAOF> If you're actually *doing* any composition...
<duflu> RAOF: True, but "vastly" is still completely insignificant compared to even a single frame of lag. And we have several frames of lag.
<duflu> So that gets attention first
<RAOF> I don't think that's the case?
<RAOF> As evidenced by your discovery that your monitor introduces a 20ms delay that you were entirely unaware of.
<duflu> It is. Proof: Software rendering completes in well under 16ms even on mobile. Our buffering lag is closer to 90ms
<RAOF> But that's two different types of milliseconds :)
<duflu> RAOF: In user perception
<RAOF> But as long as rendering *is* maintaining 60Hz, lag is indeed a more interesting target.
<duflu> It is. Software rendering is very fast even on a phone (with the exception of the infamous OTA-10 regression)
<RAOF> Right. User perception is â30Hz is worse than a consistent 90ms of lag, even though frames containing my input reach the screen fasterâ.
<duflu> RAOF: Agreed, but that's not an issue. Also it would be irresponsible to pursue. Do you want Xmir working in 2015 as it was, or wait till 2017/2018?
<RAOF> Yeah, I'm agreeing with you.
<RAOF> As long as we're hitting frame deadlines, we don't *really* need to increase rendering performance.
<duflu> RAOF: Even still, less important than our other current performance focal points
<duflu> No one cares if you've made Xmir faster if you had to stop working on improving the performance of all of Unity8
<zzarr> hello! does Mir software rendering work now?
<duflu> zzarr: In very very limited conditions. Depends what you're trying to do
<duflu> But mostly not
<zzarr> duflu, I'm not trying to do anything right now, it was just a general question
<duflu> We are making baby steps in other tasks that will help generic software rendering in future
<zzarr> nice
<zzarr> of course I still want to try to get Ubuntu with Mir running om my chromebook
<zzarr> it's vital that I can turn both the touch pad and keyboard off when flipping it
<zzarr> (ti's an Asus Chromebook Flip)
<zzarr> it's*
<anpok> so you want them to be gone.. so that unity8 discovers that there are not more desktop input device, so it would switch to the tablet ui?
<zzarr> anpok, exactly
<duflu> Do we need to test of integer wraparounds that will happen after the Sun engulfs the Earth?
<duflu> I guess we should assume Mir is running outside the solar system
<anpok> zzarr: hm we should have the necessary interfaces in mir
<anpok> zzarr: but you would need changes to unity-system-compositor to deal with that... detect the lid switch telling you the flip state?.. hm.
<zzarr> anpok, nice
<zzarr> anpok, I don't know
<anpok> sounds like hwdb in usc .. dmidecode.. have lots of rules for various devices..
<anpok> oh i believe we do not expose the input device registy in the mir server api... but thats the smallest problem
<anpok> i thought about another interface to allow the compositor to filter out input devices..
<zzarr> anpok, okey, sadly I don't know anything about that, I just have a vision that I one day can run Ubuntu/Mir on my laptop
<zzarr> well, a script telling mir/unity that it should enter tablet mode and one that tells it to enter desktop mode would be nice
<zzarr> are the input filtered or are they turned off? (hw)
<anpok> hm ... if you would tell an InputDevice to stop libinput would still read from evdev
<anpok> but thats an implementation detail.. because we use libinputs udev handling.. and turning it off and on again would require to retrigger scanning udev devices..
<anpok> the reason for using that are also further implementation details in libinput itself .. because of historic reasons it does certain init steps only when you let it handle udev..
<zzarr> I'm feeling I'm on thin ice... never mind you answered the question before I asked it
<anpok> is it important that evdev events are not consumed?
<anpok> believe me there is no ice
<zzarr> anpok, does evdev events trigger text on the screen? (keyboard inputs)
<anpok> well input events take a route through the system compositor down to the focused client i noone filters it along that line.. and the rendered results comes back to screen
<anpok> *if no one filters it
<zzarr> okey, in that case, yes it is important that it's filtered (the keyboard/mouse pad ends up on the backside when flipped)
<anpok> oh
<anpok> I thought the screen is rotated then closed
<zzarr> this image shows the form factor http://liliputing.com/wp-content/uploads/2015/03/asus-chromebook-flip_02.jpg
<robert_ancell> duflu, RAOF, I figure it's about time to propose XMir upstream. Any opposition?
<duflu> robert_ancell: Ha. I would not have except just landed an emergency fix from Chris Townsend today. Not sure how to test it
<robert_ancell> duflu, I expect upstream is not going to test it in any detail anyway, so shouldn't be a problem.
<duflu> Upstream would need Mir to complain about anything. So long as we don't break code outside our own dir
<robert_ancell> Exactly. And it seems to be in well self contained now
 * duflu is guessing there are lots of desktoppers in London
<robert_ancell> Prague
<duflu> Close
<duflu> Closer than here
<robert_ancell> Yep
<duflu> robert_ancell: What venue?
<robert_ancell> Hotel
<duflu> robert_ancell: Erm, which?
<robert_ancell> https://www.google.cz/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0ahUKEwjHiY7S_bDMAhVqAZoKHXi5DiYQFggdMAA&url=http%3A%2F%2Fprague.boscolohotels.com%2F&usg=AFQjCNGa9EmXsm9WPTU0TKXUdwLjaNbSvQ
<robert_ancell> ah, stupid google links
<robert_ancell> http://prague.boscolohotels.com/
<alan_g> attente: I'm working through the window management issues in Mir. It looks like gtk-mir might the cause of lp:1445543 - I've updated the description with a specific case that seems to show Mir passing events to the client that are ignored, can you check what happens in gtk?
<attente> alan_g: hey, sorry. i got your message, but didn't have a chance to check yet
<alan_g> attente: np
<bregma> hey robert_ancell I was going to ask if there was any reason (like maybe an Intel incident) why we haven't upstreamed XMir...  I guess my question has been answered
<bregma> are you willing to do the work?
<robert_ancell> bregma, yep
<bregma> great
<anpok_> bregma: looked at our xkb mapping code..
<anpok_> the altGr problem could be caused by other problems
<robert_ancell> hmm, why can't I VT switch out of mir_demo_server anymore?
<bregma> anpok_, problems within Mir, or elsewhere?
<anpok_> we seem to use the api wrong..
<anpok_> yeah mir client.. i finish up the nested stuff and verify that theory
<alan_g> robert_ancell: it should be possible - I do it a lot
<bregma> anpok_, OK, so still Mir but on the client library?
<anpok_> yes
<bregma> k
<robert_ancell> alan_g, yeah, it used to work fine. But not working for me right now... alt+ctrl+backspace seems to quit it, but not mir_demo_server_minimal
<alan_g> robert_ancell: minimal doesn't install the quit handler
<robert_ancell> alan_g, is there any easy way to log the keyboard events?
<anpok_> MIR_CLIENT_INPUT_RECEIVER_REPORT=log
<anpok_> oh in a server?
<robert_ancell> anpok_, yeah, the server
<anpok_> MIR_SERVER_INPUT_REPORT does some logging.. not sure if it contais key code
<anpok_> *contains key codes
<robert_ancell> hmm, doesn't seem to
<robert_ancell> I'm wondering if it doesn't work because I need to hold down 'Fn' for my F keys
<robert_ancell> If I can get a log of keycodes that might help
<anpok_> hm ok it does .. you should see "Received event .. type=EV_KEY code=<some number> value=0/1"
<anpok_> when you set that env var to =log
<robert_ancell> I got nothing when I set MIR_SERVER_INPUT_REPORT=log
<robert_ancell> But mir_demo_server --print-input-events does something, but the output seems to overwrite so I can't read it
<robert_ancell> http://paste.ubuntu.com/16094191/
<robert_ancell> Should the keycode always be 0?
<robert_ancell> The only scancodes seem to be alt, ctrl and backspace. i.e. nothing for Fn or the function keys
<anpok_> yeah.. no scan to key code translation on the server
<anpok_> ok thats.. odd..
<robert_ancell> I wonder if the function keys are done with ACPI?
<robert_ancell> showkey suggests F2 is scancode 224, which is KEY_BRIGHTNESSDOWN
<anpok_> aeh.. hm but neither libinput nor mir filters out keys
<anpok_> robert_ancell: what does evtest say about the input devices that you have?
<robert_ancell> ah, KEY_F2 does work, but not in combination with alt+ctrl for some reason
<robert_ancell> ok, now with more careful testing, I am getting the event to show with --print-input-events, but still no VT switch
<robert_ancell> Seems the order in which I press 'Fn' matters
<robert_ancell> ah. I know what this is. The VT switching is done on /dev/console which for some reason stopped working in Xenial. This affected LightDM, so I switched to using /dev/tty0 which is what other things use (GDM, logind).
<robert_ancell> I'll make a merge proposal...
<robert_ancell> anpok, https://code.launchpad.net/~robert-ancell/mir/vt-tty0/+merge/293277
#ubuntu-mir 2016-04-29
<robert_ancell> RAOF, duflu, I was thinking we could hack out the DRI2 and window management stuff from XMir and propose that upstream as a starting point. That seem fair?
<RAOF> Ah, DRI2 was not *quite* an exact copy of xfree86/dri2? Sadness. (I had forgotten about that).
<RAOF> That would remove the bits that I see as likely to be contentious.
<robert_ancell> RAOF, I spent some time trying to directly link but it was very hard to make the code happy
<RAOF> Fair chop.
<duflu> robert_ancell: Any *hacking* and the code would lose my trust. Hence should not be upstreamed in that form
<duflu> It has matured, which says a lot
<robert_ancell> duflu, hacking as in chopping out that stuff (you said we only recommend sw anyway). We would then propose DRI support and window management as a second step
<robert_ancell> They might take more work to be upstream acceptable
<duflu> robert_ancell: The window management is core (and fragile if touched)
<RAOF> Which is one of the reasons why it's likely to be contentious upstream.
<duflu> Also not really broken
<RAOF> It need not be core.
<duflu> If you changed it, I would thoroughly recommend not upstreaming then. It no longer qualifies as mature
<RAOF> Maturity is roughly irrelevant for upstreaming.
<RAOF> Indeed, upstream is often *happier* if it's not mature.
<duflu> OK. *shrug*
<RAOF> Because it means that possibly contentious design decisions aren't baked in as hard.
<duflu> Can we keep a stable branch somewhere then?
<RAOF> Absolutely.
<RAOF> We wouldn't be shipping what's upstream until it's functionally equivalent.
<duflu> This is sounding silly actually. Why propose something neither the sender not receiver likes?
<duflu> nor receiver
<RAOF> Because it allows us to work it into a state that both sender and receiver likes.
<duflu> If we could not endorse what we're proposing to upstream (and I would not) then why bother?
<robert_ancell> It's a starting point
<RAOF> Because having a base upstream and iterating in upstream is much more likely to happen than us perfecting it and then upstream taking it entirely as-is.
<duflu> Some of the most important bits are the window management. We need those (just as soon as Unity8 catches up on features)
<RAOF> Those bits should really be in an actual window manager component?
<duflu> I don't think so. They need to speak native Mir
<RAOF> That's an entirely solvable problem.
<duflu> It works, it's mature. Please don't break it
<RAOF> Witness, for example, the instructive case of AMD's new GPU driver. They submitted a working, fairly polished driver, and are rewriting it basically from scratch to make it acceptable for upstream.
<duflu> We are the only users of Xmir. There's no point proposing something that's only appropriate for some other user base that does not exist
<RAOF> Except Xmir is intimately bound with other parts of Xorg, and having it upstream means that it needs to be considered when someone wants to make a change that might break it.
<duflu> I don't mind the ripping out of DRI2. That needs months/years of work yet anyway. But the WM work represents a lot of effort and maturing already
<RAOF> Then wouldn't it be a great idea to propose it upstream and see if it's acceptable, so you don't have to rip it out later?
<duflu> Essentially I don't mind what anyone does, unless they break what already works for us. So long as the codebase we use does not get broken, it's OK
<duflu> Also modified in any way kind of counts as breaking the level of maturity at least :P
<duflu> robert_ancell: Also worth noting the WM stuff should not be contentious at all. There is prior art for the same approach to rootless in hw/xwin/
<duflu> Which I often referred to
<Tak> is this entry from the wiki still accurate? "Make sure your hardware is supported. That means you're using a Mesa driver"
<Tak> (ref: https://unity.ubuntu.com/mir/using_mir_on_pc.html )
 * duflu looks
<duflu> Tak: Yes Mir on desktop still only supports intel/nouveau/radeon right now. Also VMs have some limited support: https://unity.ubuntu.com/mir/setup_kvm_for_mir.html
<duflu> Tak: The docs fail to properly explain that Ubuntu already contains the right Mesa code
<Tak> :-/
<duflu> Tak: Would love to add more hardware support. What do you need?
<Tak> well, I'd be looking for desktop nvidia driver
<duflu> Tak: Good news. RAOF is working on that with Nvidia right now
<Tak> that is good news
<duflu> Also, he just logged off for the week
<anpok> hm and the doxygen docs on unity.ubunty.com/mir are still very outdated
<Tak> kvm could be an option though
<duflu> Tak: Then anpok is your expert
<anpok> Tak: just enable qxl/spice in your kvm starup.. or even simpler use the checkboxes in virt-manager
<duflu> anpok: Having the host running Nvidia binary driver, will it still work?
<anpok> yes
<duflu> And the crowd goes wild
<Tak> yeah, I'll give it a try following the wiki page duflu posted
<Tak> (I hope they release linux 3.18 soon! ;-) )
<anpok> but it will torture your cpu instead .. a bit..
<anpok> yeah .. it is about time..
<duflu> Tak: You laugh, but Android isn't that current yet
<duflu> Or ChromeOS
<duflu> Sometimes
<Tak> btw, what about vmware?
<duflu> Tak: http://bazaar.launchpad.net/~mir-team/mir/development-branch/view/head:/doc/setup_vmware_for_mir.md
<Tak> ah, nice
<anpok> virtualbox not yet
<Tak> hm, no dice with vmware, time to try kvm
#ubuntu-mir 2017-04-24
<alan_g> duflu: any thoughts on the right way to handle the libmirclient deprecations for 16.04? Reworking all the downstreams to use the new APIs seems like risky behaviour.
<duflu> alan_g: No immediate thoughts :P
<duflu> :/  I mean
<alan_g> :)
<xnox> hi, is there anybody who could advise me on qtmir and qtmir-gles
<xnox> are they going to be supported, developed and needed in artful and going forward?
<xnox> e.g. does kiosk use it?
<alan_g> xnox: the kiosk doesn't use it
<xnox> alan_g, thanks. what about maintainance and supporting qtmir in artful? no idea?
<alan_g> I can't give a definitive answer to that yet. But it isn't needed for IoT, so I don't forsee any active development
<alan_g> xnox: what usecase interest you?
<xnox> alan_g, i am interested to drop src:upstart, src:cgmanger, src:libnih from artful. And currently src:qtmir[-gles] depend on cgmanager libraries. I'm pondering if i need to touch/fix that
<xnox> or src:qtmir can simply be removed from artful
<alan_g> Saviq: can you give a better answer? ^^
<Saviq> xnox, remove it, if we find that we need it, we'll revisit
<xnox> hm, that would mean removing src:unity8 and e.g. src:ubuntu-push
<xnox> but i thought ubuntu-push will be in snappy, no?
<xnox> or was ubuntu-push phone/touchy stuff?
<xnox> alan_g, Saviq - so ubuntu-app-launch has moved onto systemd, yet qtmir is using cgmanager/upstart cgroup paths to determine related app pids
<xnox> so my understanding is that fetchAssociatedPids is now broken.
<xnox> and effectively always returns "which is not app-specific"
<xnox> (e.g. does not find any related pids)
<Saviq> that might very well be, greyback â ?
<alan_g> greyback: ^^
<xnox> QSet<pid_t> DBusFocusInfo::fetchAssociatedPids(pid_t pid) always goes down the else path, as no things in zesty+ have 'upstart' in their cgroup
<greyback> xnox: I think you're right yes. However that code is only used to expose a pid list via dbus of focused apps, which is used only by autopilot I think.
<xnox> aha
<greyback> it is not important code, and we didn't notice this bug in the systemd transition
<greyback> because almost nobody uses that dbus api
<xnox> greyback, i think i will make the code to go down the else path, without changing any api/abi
<xnox> and drop build-dep and runtime dep on the cgmanager.
<xnox> meaning i'm not making things any worse.
<xnox> it is possible that autopilot uses ubuntu-app-launch apis directly for the systemd code path =/
<greyback> xnox: I think that change won't hurt anyone that we care about
<xnox> running tests now, fingers crossed
<xnox> horay!
<xnox> onto gles variant
<xnox> greyback, i've asked tedg if there is anyway to get all the pids from ubuntu-app-launch and here is his response
<xnox> <tedg> xnox: Yup, you can grab it from the instance object, pids() returns a vector.
<xnox> <tedg> xnox: You can also call ubuntu-app-launch-pids
<xnox> <xnox> nice.
<xnox> <tedg> xnox: But those will only really work on U8...
<xnox> so either autopilot should use that, or qtmir should re-expose that over db
<greyback> xnox: right. UAL does make that possible, we just kept neglecting that particular bit of code
<xnox> ah, ok.
<xnox> i shall open a bug report.
<xnox> at least
#ubuntu-mir 2017-04-26
<tjaalton> any idea if xmir will be upstreamed now, or the vulkan/mesa bits?
<tjaalton> and if no, how long those should be maintained in ubuntu..
<duflu> tjaalton, not sure. Although I was the main person working on Xmir, it (1) was not upstreamable with the DRI2 bits (robert_ancell was working to cut it down a while ago; and (2) not fully ported to the Mir 0.26 API yet. So if anyone wants Xmir in future and if Mir 0.27+ gets released then more work is required
<duflu> I feel it will become "too hard" to maintain soon
<tjaalton> duflu: it's ported to 0.26 at least
<duflu> tjaalton: No it's not. It compiles with warnings about using things declared deprecated :)
<tjaalton> oh right
<duflu> And the person who loosely owned that problem (created that problem) no longer works for Canonical
<tjaalton> yeah..
<duflu> I let it slip in on the condition that he fixed it
<duflu> Might only be one afternoon of work though, assuming the alternative APIs work
<tjaalton> ok, so let's revisit this around artful FF or so
#ubuntu-mir 2017-04-27
<tjaalton> oh well, mir vulkan support in mesa is causing pain when rebasing to new upstream..
<tjaalton> since this was added in zesty, is not self-contained and probably won't be upstreamed, I'll disable it in artful
 * alan_g thinks that's unfortunate. (But pragmatic.)
<Son_Goku> alan_g, have you heard anything on the patch upstreaming efforts for libinput and mesa?
<alan_g> Son_Goku: bschaefer has the libinput work on his list (I think anpok has been helping). The mesa work hasn't been dropped, but is not yet owned by anyone.
<anpok> I started yesteday to make the intermediate solution
<anpok> so yes.. still on my list..
