#ubuntu-mir 2014-02-03
 * duflu wonders if the Atom will finish building Mir today
<duflu> Awesome. Mir on an old Intel Atom is super-responsive, compositing at 60FPS. If only it wasn't also suffering a bug; https://bugs.launchpad.net/mir/+bug/1275398
<alan_g> fast, works - chose any one. :(
<duflu> alan_g: Well, moving sofrware surfaces around is faster and smoother than anything I've ever seen on a old netbook. It's kind of exciting
<duflu> software too
<alan_g> Any clue about the GL clients failing?
<duflu> alan_g: Possibly missing GL extenions (the ones used to load GL images into textures)
<duflu> Ah. And Mir is just as fast as LXDE, without the ugly tearing of LXDE :)
<alan_g> So failing to check result codes is the first thing
<duflu> alan_g: Yep
<duflu> But another day
<alan_g> Sure. Nice it works so well otherwise
<alan_g> slangasek: you were raising a protobuf issue yesterday?
<duflu> alan_g: He logged it as https://bugs.launchpad.net/mir/+bug/1275372
<anpok> i have one of those - currently only runnig lxde because all other environments are two slow
<rsalveti> alf_: hey, remember we discussed a way to dynamically load a mir backend instead of making that decision in build-time? this was part of the emulator discussion https://blueprints.launchpad.net/ubuntu/+spec/core-1311-ubuntu-touch-for-x86
<rsalveti> basically we now need mir to work with the android backend on x86 as well
<dandrader> alan_g|lunch, so to add my own messages on top of the regular ones in the mir socket I've to extend ProtobufSessionCreator and ProtobufMessageProcessor?
<slangasek> alan_g: hi there - yes, I've inadvertently started a Mir-affecting protobuf transition in trusty; and mir doesn't pass its test suite with the new one (bug #1275372). Is this something you could help with fixing, so we can go forward instead of backwards with the protobuf transition?
<ubot5> bug 1275372 in Mir "mir: FTBFS in trusty-proposed, tests fail against libprotobuf8" [Critical,Triaged] https://launchpad.net/bugs/1275372
<slangasek> alan_g: (if not, then the right thing to do is to back out the protobuf transition so it doesn't block mir landings)
<alan_g> slangasek: yes. I'll help. Been wondering what the easiest way to grab the protobuf update to test without breaking other work (the error just looks unrelated)
<slangasek> alan_g: well, you can grab the new protobuf from trusty-proposed; as for it looking unrelated, I did a test build with protobuf as the only difference, and it passed with the old one and fails with the new
<alan_g> slangasek: I believe you. (Just makes it hard to guess what's wrong)
<racarr> Morning
<kgunn> racarr: your alarm clock is still broken :)
<racarr> wait no now it's 7:33 right
<racarr> yes
<kgunn> alan_g: just sitting here thinking about your discussion with slangasek...
<kgunn> alan_g: so since we're already in a build pickle with platform-api blocking us...
<kgunn> alan_g: ok...nvmd...i thot it thru, we just have to merge that back into dev
<kgunn> actually the whole trunk back into dev
<kgunn> not as bad as i originally thot
<alan_g> kgunn: Just think of "dev" as the trunk and "trunk" as a release branch and it feels more normal
<alan_g> slangasek: How are you running the tests? https://bugs.launchpad.net/ubuntu/+source/mir/+bug/1275372/comments/1
<ubot5> Launchpad bug 1275372 in Mir "mir: FTBFS in trusty-proposed, tests fail against libprotobuf8" [Critical,Triaged]
<slangasek> alan_g: as part of the package build
<slangasek> alan_g: reproducible with a native build on x86
<alan_g> slangasek: I've tried on x86 - still CNR - we are doing something differently
<slangasek> alan_g: output of "dpkg -l '*protobuf*' | grep ^ii" in your build environment?
<slangasek> alan_g: you aren't passing 'DEB_BUILD_OPTIONS=nocheck' in your environment (because of cross-builds), are you?
<alan_g> $ dpkg -l '*protobuf*' | grep ^ii
<alan_g> ii  libmirprotobuf-dev:i386                               0.1.3+14.04.20140108-0ubuntu1          i386         Display server for Ubuntu - protocol definition
<alan_g> ii  libmirprotobuf0:i386                                  0.1.3+14.04.20140108-0ubuntu1          i386         Display server for Ubuntu - protocol implementation
<alan_g> ii  libprotobuf-dev:i386                                  2.5.0-5ubuntu1                         i386         protocol buffers C++ library (development files)
<alan_g> ii  libprotobuf-lite8:i386                                2.5.0-5ubuntu1                         i386         protocol buffers C++ library (lite version)
<alan_g> ii  libprotobuf7:i386                                     2.4.1-3ubuntu4                         i386         protocol buffers C++ library
<alan_g> ii  libprotobuf8:i386                                     2.5.0-5ubuntu1                         i386         protocol buffers C++ library
<alan_g> ii  protobuf-compiler                                     2.5.0-5ubuntu1                         i386         compiler for protocol buffer definition files
<alan_g> ii  python-protobuf                                       2.5.0-5ubuntu1                         all          Python bindings for protocol buffers
<alan_g> slangasek: I'm just doing "make -j4 && ctest"
<slangasek> alan_g: please use debian/rules build
<alan_g> slangasek: ok
<slangasek> alan_g: correction: 'fakeroot debian/rules binary'
<alan_g> slangasek: running (but that takes a while to run)
<slangasek> alan_g: yep, understood
<slangasek> alan_g: fwiw, the relevant test call in debian/rules is this: GTEST_OUTPUT=xml:./ dh_auto_test --max-parallel=1
<slangasek> (once the package build has run through once, you should be able to call that directly to iterate)
<slangasek> alan_g: any luck?
<alan_g> buiid at 97%
<slangasek> ok
 * slangasek sits on his hands ;)
<alan_g> slangasek: it finished successfully. But I don't see any test run in backscroll
<alan_g> The unit test binary passes (with LD_PRELOAD)
<alan_g> And so does "GTEST_OUTPUT=xml:./ dh_auto_test --max-parallel=1"
<slangasek> alan_g: ok, so 'GTEST_OUTPUT=xml:./ dh_auto_test --max-parallel=1' passes without any LD_PRELOAD?
<slangasek> alan_g: I noticed that you were on i386... I was testing on amd64.  Could be that has an effect here
<slangasek> let me try to reproduce on i386; can you try to reproduce on amd64?
<alan_g> slangasek: I can try - but EOD for me is 18min away
<slangasek> mmk
 * alan_g still thinks this would be a very strange effect of protobuf changes
<alan_g> slangasek: left it building - will check back when I get a minute (after supper)
<alan_g|EOD> slangasek: works on amd64
<slangasek> curious
<slangasek> my i386 build is still running, let's see what happens
<racarr> Is freenode acting weird?
<racarr> No
<ogra_> racarr, it was for most of the day
<ogra_> they had a DDOS
<popey> hello mir people.
<popey> how far away is screencasting mir?
<anpok> currently being worked on, i.e. there is a mp https://code.launchpad.net/~afrantzis/mir/mir-screencast-server-frontend/+merge/203809 in progress, another one for the client api has been merged alreadn, then there will probably be one or two more for platform support
<anpok> correct details when alf_ is back online :)
<slangasek> what the what
<slangasek> https://launchpad.net/ubuntu/+source/mir/0.1.3+14.04.20140108-0ubuntu2
<slangasek> why is cmake now broken?
<slangasek> hmm
<slangasek> because I uploaded from a dirty tree, sigh
<anpok> popey: I am the wrong one to ask
<popey> k
<anpok> maybe someone on -unity knows whether thats planned or in progress..
<Guest438> popey: it will be a raw vid stream of what's happening on screen, no plan to show where you touched or swiped
#ubuntu-mir 2014-02-04
<alan_g> alf_: is this right? https://code.launchpad.net/~alan-griffiths/mir/suppress-tests-for-armhf/+merge/204620
<alf_> alan_g: looks good
<alan_g> alf_: thanks
<alf_> alan_g: perhaps, though, we should apply this to devel first and merge that?
<alf_> alan_g: too late, doesn't matter :)
<alan_g> alf_: I'd rather do a reverse merge after the trunk gets tagged
<alf_> alan_g: ok
 * alan_g thinks we should not be landing two months changes in one lump (but who listens?)
<alan_g> didrocks: I trust your changelog concerns are addressed? https://code.launchpad.net/~mir-team/mir/trunk-0.1.4/+merge/201707
<didrocks> alan_g: swimming over the diff, it looks good to me
<alan_g> didrocks: surely a 32k diff is no cause for concern. ;^/
<didrocks> alan_g: well, that's your process, if things can't land, we are going to revert your 32k of diff
<didrocks> you pick your risk
<alan_g> didrocks: kgunn already made that decision.
<didrocks> yeah, so no need to argue on that more :)
<alan_g> Is it ok to top-approve now? (Or are there other steps needed in the latest process?)
<didrocks> alan_g: kgunn is the lander, he will handle that, so no top-approve (well, top-approve won't do anything anyway)
 * alan_g washes hands
<alf_> alan_g: have you tried cross compiling recently?
<alan_g> alf_: can you suggest a cleaner approach to https://code.launchpad.net/~alan-griffiths/mir/refactoring-so-SwitchingBundle-can-control-completion-of-client_acquire/+merge/204244
<alan_g> alf_: no - can to though
<alan_g> *do
<alan_g> (Was probably friday I did it last)
<alf_> alan_g: I am getting http://paste.ubuntu.com/6872683/
<alan_g> Tried zapping the "partial chroot"?
<alf_> alan_g: no, just the build dir (while updating the chroot), will try from scratch
<alan_g> Hmm " #error This file was generated by an older version of protoc which is"...
<alf_> alan_g: you need to update the host protobuf libraries and protobuf-compiler package
<alan_g> alf_: ack
<alf_> alan_g: @switching bundle, I like the proposed approach, perhaps with the change that Kevin proposed to swap_client_buffers()
<alf_> alan_g: i.e., returning the buffer in the callback
<alan_g> thanks. Was thinking along those lines - but not feeling convinced it was the best of all possible solutions
 * alan_g isn't convinced by the name "submit_produced_buffer_and_notify_on_available_buffer" though
<alf_> alan_g: the other approach is to move to a push model for surface buffers, but that's more radical and needs further discussion
<alan_g> alf_: quite
<alan_g> BBL
<alf_> alan_g: cross-build ok from scratch, thanks
<dandrader> alan_g, trying to make unity8 do custom RPC over mir_socket, following test_protobuf.cpp example
<alan_g> dandrader: yes?
<dandrader> alan_g, I need to include mir/frontend/template_protobuf_message_processor.h
<dandrader> alan_g, but that header, on its part, includes mir_protobuf_wire.pb.h
<dandrader> alan_g, which is not exported by mir
<alan_g> dandrader: you're right. That needs to be fixed.
<alan_g> Want to log a bug? I'll get to it today
<dandrader> alan_g, sure
<alan_g> thanks
<dandrader> alan_g, https://bugs.launchpad.net/mir/+bug/1276162
<ubot5> Launchpad bug 1276162 in Mir "libmirserver user is unable to #include <mir/frontend/template_protobuf_message_processor.h>" [Undecided,New]
<alf_> mlankhorst: Hi! I think I have found a bug in Mesa, could you take a look?
<mlankhorst> I guess
<alf_> mlankhorst: So, the problem is that when unbinding a context, the driver unbind function is not called when there are no bound surfaces, but this break when we have a surfaceless context
<mlankhorst> is this a bug in gallium only or is i915 affected?
<alf_> mlankhorst: it's in dri_utils, a tentative fix is http://paste.ubuntu.com/6873664/ . Just that look plausible?
<alf_> s/Just/Does/
<mlankhorst> I really can't say
<alf_> mlankhorst: np, thanks
<mlankhorst> it seems like it's not called on purpose there
<mlankhorst> so I don't know, put it on the mesa-dev list I guess
<mlankhorst> or write a test
<alf_> mlankhorst: will do thanks
<Saviq> kdub, hey, could you maybe answer asac's question in "Landing team 31.01.2014" on ubuntu-phone ("How can we ensure that display is ready before trying to start?")?
<kdub> Saviq, i'll take a look
<Saviq> kdub, thanks
<dandrader> alan_g, so mir wire protocol has no concept of services. only functions, right?
<alan_g> dandrader: correct
<dandrader> alan_g, meaning that you can map a wire protocol function to any protobuf service you like, right?
<alan_g> dandrader: correct
<dandrader> ok
<kdub> was there a problem with protobuf?
<alan_g> kdub: bug 1276162
<ubot5> bug 1276162 in Mir "libmirserver user is unable to #include <mir/frontend/template_protobuf_message_processor.h>" [High,In progress] https://launchpad.net/bugs/1276162
<kdub> alan_g, what i'm seeing looks more like a version mismatch of protobuf on my setup
<kdub> upgrading everything and hopefully that works
<alan_g> kdub: yeah, theny just pushed protobuf8 in
<alan_g> &they
<alan_g> Sorry, thought you were joining the conversation, not starting a new one
<kdub> alan_g, np, upgrading things seemed to fix what i was seeing
<alan_g> kdub: is this to your liking now? https://code.launchpad.net/~alan-griffiths/mir/refactoring-so-SwitchingBundle-can-control-completion-of-client_acquire/+merge/204244
<kdub> looking
<alan_g> kdub: thanks
<ali1234> i just read about SDL Mir backend
<ali1234> don't most 3D games use GLX? how does that work then?
<bschaefer> ali1234, when it comes to a game that uses GLX, the mir video backend returns an opengl context (through egl) which allows most games to work
<ali1234> i'm a game developer... how will i know if my game can work this way?
<bschaefer> i've tested this out in SDL 1.2 (which I have a branch for)
<ali1234> i use SDL2 and ogre3d
<bschaefer> then things should just work :)
<bschaefer> to test, you would have to set up the mir server
<ali1234> i compile my own version of ogre and sdl...
<bschaefer> and run it on it directly
<bschaefer> i've not tested ogre out but if it depends on X11 it will not work
<bschaefer> depends on it directly
<ali1234> well it depends on it for building
<ali1234> but i use SDL to open a window and get a GL context
<bschaefer> the GL context you get from SDL (if you are running it through mir) will be opengl
<bschaefer> ali1234, ive gotten games such as extremetuxracer
<bschaefer> working through mir
<bschaefer> (only in sdl 1.2, which is not patched for mir, but my own branch)
<bschaefer> which depends on  |Depends: libgl1-mesa-glx
<bschaefer> so I would assume any games written in SDL2, should work with the same dependencies
<ali1234> i literally just open a window with SDL2 and then tell ogre to render into it... there is zero X11 specific code in my stuff, which also runs on windows
<bschaefer> the problem i see though, is ogre has a hard depend on :   Depends: libx11-6
<ali1234> yes
<bschaefer> at lease im seeing that here: apt-cache depends libogre-1.8.0
<ali1234> ogre has it's own window management functions, but i do not use them
<bschaefer> which will not allow it to work :(
<bschaefer> o
<bschaefer> well
<ali1234> so it should work as long as the libraries are around and it just won't use them... i guess?
<ali1234> also i could patch the X11 stuff out of ogre, maybe
<bschaefer> well if they are around, and there are functions calls that attempt to connect with the XServer it'll fail
<ali1234> wondering if it's worth it...
<ali1234> luckily all this stuff is BSD licensed :)
<ali1234> or was it MIT, i forget
<bschaefer> well the lease you could do is run down where ogre calls any x11 functions
<bschaefer> you would hope that if you are using SDL2 to get the context (and set up the native handling) that ogre would leave all that alone
<bschaefer> and let SDL2 handle that
<bschaefer> if thats the case it'll work just fine
<ali1234> CMake/Packages/FindOpenGLES.cmake:    # On Unix OpenGL most certainly always requires X11.
<ali1234> :(
<bschaefer> :(, thats one assumption that has caused a lot of pain
<ali1234> on a related note, the oculus rift devkit relies on X11 and Xinerama as well
<bschaefer> to bad they just don't all build a layer ontop of SDL2 and leave all the native window handling to it...
<ali1234> well ogre is a lot older than SDL2... SDL1 has no windowing support
<bschaefer> right
<bschaefer> i forgot how new SDL2 really is :)
#ubuntu-mir 2014-02-05
<anpok> alan_g: regarding the include "../lttng/*_report.h" - i could move the code from logging/default_configuration.cpp to src/server/default_server_configuration.cpp
<alan_g> anpok: it would still  be a cross-component include
<alan_g> I've not had a serious think about what the dependencies should be - but I'm tempted by the idea of putting all the reporting options together (that needs a few renames)
<anpok> as in putting lttng and logging together?
<anpok> or moving them into a report/lttng report/logging structure?
<anpok> the only reason we need that is that because whe have to provide a the_..._report() method
<anpok> if we could split that one up, we would never have to care about it
<anpok> I thought about reigstering the different types somewhere
<alan_g> anpok: True - there could be lttng and log report factories
<anpok> or we could use something generic like: http://code.google.com/p/hypodermic
<alan_g> alf_: opinion? ^^
<anpok> that would dissolve most of default_configuration
<anpok> we could wire the program_options with that one - or something like that - havent looked on what it needs and how it is done
<alan_g> I'm not sure we need anything that generic
<alf_> alan_g: looking
<alan_g> Just "return LttngReportBuilder(...).foo_report();"
<anpok> it would be the_foo_report() { return container.create<FooReport>() } and inside lttng/default_configuration.cpp ::register_types() { if (get_option("foo-report" == "lttng") { container.register<Foo,LttngFoo>() }
<anpok> +Report two times
<alf_> alan_g: anpok: (I am not sure if this is what Alan meant) how about the_foo_report() { if (lttng) the_lttng_builder().foo_report(); else the_logging_builder().foo_report(); }
<alan_g> alf_: I meant the_foo_report() { if (lttng) LttngBuilder().foo_report(); else LoggingBuilder(the_log()).foo_report(); }
<alf_> alan_g: anpok: that being said, lttng and logging are kind of reports so I would be ok with a report/lttng,report/logging structure
<alan_g> Agreed
<anpok> the generic approach above could also make our live simpler in other cases... i.e. image adding a constructor parameter somewhere, because we factor out functionality. with types registered like above, and compile time information on constructor signature, the change might not have cause further changes in test cases..
<alan_g> I've used IOC containers in other languages and understand the attraction (and the problems). And I do realize that that we're on that road with DefaultServerConfiguration. I just don't think it is quite that simple to drop it in.
<anpok> yes.
<alan_g> Hmm. Why can't I find "google::protobuf::GoogleOnceInitImpl(int*, google::protobuf::Closure*)" on the N10 today?
<anpok> .. so what would be a good intermediate solution.
<anpok> reshuffling into another container - would that also add a namespace?
<anpok> s/container/folder
<alan_g> What I suggested above? a public class lttng::ReportFactory { shared_ptr<FooReport> foo_report() const; } in the lttng namespace that can be used by any component.
<anpok> ok then agreed
<alan_g> alf_: ?
<alf_> alan_g: anpok: Why not hide that behind and interface and expose it through the_lttng_report_factory?
<alan_g> It doesn't introduce another factory function into DefaultServerConfiguration - just gets used in the implementation.
 * alan_g powers up N4 to see if that works any better
<alf_> alan_g: anpok: But it does introduce a potential "hidden" dependency between lttng and other components
<alf_> alan_g: anpok: I think that for our current purposes the report/lttng,report/logging structure would be more straightforward
<alan_g> alf_: isn't that orthogonal?
<alan_g> I mean something needs to provide assess to private report implementations in report/lttng and report/logging
<alan_g> *access
<alf_> alan_g: anpok: If it's available only for internal (subcomponent) access, I am OK, but we could just use the internal subcomponent classes directly. However, I got the feeling that lttng::ReportFactory was going to be public for *all* components to use.
<alf_> (not that they would have much reason too)
<alf_> s/too/to
<alan_g> alf_: we only have "public" and "component private" so yes, it was going to be public
<alan_g> alf_: @"but we could just use the internal subcomponent classes directly." that isn't how I've understood our rules
<alan_g> Otherwise default_server_configuration.cpp could just access everyone's privates
<alf_> alan_g: then perhaps subcomponent is not the right word. In my mind the lttng and logging are implementation details of report in this case, placed in separate internal directories.
<alan_g> whereas I would give the classes prefixes and put them all in report
<alf_> alan_g: That's an implementation detail ;)
<alan_g> anpok: have you decided we're mad yet?
<alan_g> alf_: did you get stuff working on android? Today I find that I've got an unresolved protobuf symbol when I try to run things
<alf_> alan_g: haven't tried today, but it was working yesterday
<alan_g> alf_: thanks
<alan_g> \o/ zapping everything in sight and starting over worked
<dandrader> alan_g, so mirclient doesn't install include/client/mir/*, just include/client/mir_toolkit/*. Because if that a libmirclient user cannot #include <mir/client/private.h> which is needed for the "custom RPC over mir socket" story
<dandrader> s/if that/of that
<alan_g> dandrader: I understand the problem. Not sure of the best solution - thinking...
<alan_g> dandrader: yes. Adding that directory to include/mirclient seems to be the best answer. Want to log a bug for me to fix?
<dandrader> alan_g, sure
<dandrader> alan_g, https://bugs.launchpad.net/mir/+bug/1276565
<ubot5> Launchpad bug 1276565 in Mir "libmirclient user cannot "#include <mir/client/private.h>"" [Undecided,New]
<alan_g> dandrader: thanks. Am on it
<anpok> alan_g: was preparing lunch
<anpok> alan_g: let me check on madness
<anpok> ..processing..
<anpok> i think yes
<alan_g> dandrader: https://code.launchpad.net/~alan-griffiths/mir/fix-1276565/+merge/204899
<kgunn> sil2100: i see "problems with unit test" on mir landing...what's up ?
<sil2100> kgunn: where?
<sil2100> kgunn: are you sure you're looking at the right landing?
<kgunn> sil2100: ooo i better look again
<kgunn> sorry :) sil2100
 * kgunn should really wait for coffee before trying to read stuff
<sil2100> kgunn: no problem ;) We need to wait until we are unblocked from the location-service bug before proceeding thouhj
<sil2100> *though
<mlankhorst> and xorg-server testing was broken anyway due to protobuf abi break :P
<dandrader> alan_g|lunch, solve the problem! I would approve it but launchpad seems to be down at the moment.
<dandrader> solves
<rsalveti> kgunn: alf_: bug 1276621 needs to be fixed as well to enable the android backend by default
<ubot5> bug 1276621 in Mir "Android backend unit-tests FTBS on amd64" [Undecided,New] https://launchpad.net/bugs/1276621
<rsalveti> atm I'm just trying to push a custom mir package that defaults to the android backend
<anpok> alf_: alan_g whats the idea behind the separation of ServerConfiguration and DefaultServerConfiguration?
<anpok> i.e. the_logger is introduced at DSC
<alf_> anpok: ServerConfiguration is the interface used by DisplayServer
<alan_g> ServerConfiguration is what DisplayServer needs. DefaultServerConfiguration is a default implementation
<dandrader> alan_g, protobuf question: do I have to keep my service stub alive until I get a reply from the service?
<alan_g> dandrader: yes
<dandrader> alan_g, hmm, looks like they're just thin wrappers around the given rpc_channel....
<dandrader> eg: http://paste.ubuntu.com/6879913/
<alan_g> yeah, they are mostly a level of indirection
<dandrader> the thing is that by default they delete the channel when you delete the stub
<kdub> do we have to ping someone about that protobuf mismatch problem with CI?
<alan_g> kdub: no it sorted itself out.
<kdub> alan_g, okay, cool
<alan_g> Depending what's in your partial chroot and the image you use you may see the same thing (I did).
<alan_g> But the latest versions are OK
<alan_g> dandrader: they certainly don't separate concerns in a way that feels natural to me.
<anpok> whats the legacy of legacy input report?
<alan_g> IIRC that's the intercept of the original logging in the android input code
<anpok> ok so it is not legacy in itself
<alan_g> Well the idea was (is?) that we'd replace it with something better integrated into our reporting
<anpok> hm I first thought it was legacy and hence did not do anything about it
<anpok> i would first incorporate it into my current rework to not violate component boundaries
<anpok> and then in a further step I would turn the log() interface into something more report-like?
<alan_g> anpok: I'm not sure that's the best use of time
<anpok> further .. as in .. further down the road
<anpok> ... not this week
<anpok> just stumbled across it since I was able to remove input_report from the public interface entirely
<alan_g> :)
<greyback> hey folks, I really need a reliable way of getting the PID of a Session
<anpok> alan_g: i meant not with this mp
<alan_g> greyback: I don't think it is kept after passing to connection_is_allowed() - I guess that's a feature request.
<greyback> alan_g: I've logged it anyway, how could I push for it https://bugs.launchpad.net/mir/+bug/1276704
<ubot5> Launchpad bug 1276704 in Mir "Need way of getting PID of Session" [Undecided,New]
<greyback> kgunn: could I push for that feature request? The workaround in unity-mir fails in some scenarios and I can't see any way to make it solid without that feature request
<alan_g> greyback: that's the way. ;)
<greyback> :D
<kgunn> alan_g: are you volunteering by speaking :)
 * alan_g shats up
<alan_g> *shuts
<kgunn> lol
<kgunn> well..you could shat too...but well
<alan_g> kgunn: I won't get to it today. But if you want I can look tomorrow.
<kgunn> alan_g: thanks...was just looking to see if we had captured that on a bp as well...is it a specific of "cleanly abstract out application logic from the session mediator"
<kgunn> greyback: is this for the sidestage flicker ? or some other ?
<greyback> kgunn: other problem: rapid launching of apps confuses unity-mir - ppl do that to test mzanetti's work
<alan_g> greyback: is it actually the PID you want? Or would it be better to allow you to attach an object to the session when it is authorised? (I'm thinking shared_ptr<void>)
<greyback> alan_g: well PID would be easiest. With the latter suggestion, I would create object with PID and probably app_id to attach. It's much of a muchness to me
<greyback> (I need PID to verify with upstart the process' app_id)
<alan_g> greyback: PID is fine for us - but as I didn't know what you wanted it for I thought you might want something more generic
<greyback> alan_g: gotcha. For now, PID is plenty enough. It is so that when a Session starts, I can take the PID and using upstart, match the app_id.
#ubuntu-mir 2014-02-06
<sennn> i hope mir not blackscreen on my APU soon...
<sennn> issue
<sennn> anyone?
<sennn> fine...
<dandrader> alan_g, finally got custom messages between qt apps and unity8 through mir_socket working :)
<alan_g> dandrader: Great!
<alan_g> alf_: I've had to update to track changes on devel - could you recheck before I top-approve? https://code.launchpad.net/~alan-griffiths/mir/refactoring-so-SwitchingBundle-can-control-completion-of-client_acquire/+merge/204244
<alf_> alan_g: looking
<anpok> ricmm: ping
<anpok> alan_g: alf_: it got larger than I thought ~3k loc
<alan_g> anpok: what is "it"?
<anpok> avoiding includes between subcomponents
<anpok> for reports
<alan_g> I imagine a lot of that is moves and renames?
<alf_> alan_g: looks good
<anpok> yes moved header files around..
<alf_> anpok: alan_g: I still think that moving everything into a report(ing) component is the cleanest way to deal with this...
<alan_g> "everything"?! Surely just the reports?
<alan_g> 8^)
<alf_> alan_g: :)
<anpok> alf_: i dont disagree, but just moving lttng/ and logging/ was not enough
<anpok> we had a lot of report related stuff cluttered in other places too
<anpok> == should be simpler now
<alan_g> I wouldn't expect "a lot of report related stuff cluttered in other places too" - what's that?
<anpok> alan_g|lunch: hm probably not a lot of .. just a few report logging implementations being provided within the components itself, and accessing component internals..
<xnox> Yo =) !
<xnox> i've installed mirout on my device
<xnox> and when i do "mirout" via adb shell I get
<xnox> "Could not connect to a display server."
<ricmm> anpok: hi
<anpok> ricmm: hi -> look at #mir
<sil2100> om26er: hi!
<om26er> sil2100, hello
<chrisccoulson> kgunn, so, I ran this in gdb, and ua_ui_display_get_native_type seems to return NULL (which I verified by setting a breakpoint on eglGetDisplay)
<chrisccoulson> i'm just a bit unsure whether this is actually expected, seeing as apps seem to work
<kgunn> chrisccoulson: sorry...got interrupted...
<kgunn> you were saying "remember what we talked about yesterday? (me wanting to get a valid display handle in oxide that I can pass to chromium for creating EGL contexts)"
<kgunn> and "so, this is what I implemented: http://paste.ubuntu.com/6885671/"
<chrisccoulson> kgunn, sorry, xchat crashed there
<chrisccoulson> ok, so i still get a null display handle, but now i'm not sure if this is actually the expected behaviour, seeing as things seem to work
<chrisccoulson> kgunn, i just ran qmlscene in gdb, and set breakpoints on eglGetDisplay and eglCreateContext, both of which seem to succeed, and this is what I see: http://paste.ubuntu.com/6885692/
<kgunn> chrisccoulson: i'll admit i'm not as familiar with the upper stack...but do i read it right that the display id in the qmlscene is null as well?
<chrisccoulson> kgunn, that's right. we get a null handle from ua_ui_display_get_native_type(), which gets passed to eglGetDisplay and somehow magically works
<kgunn> chrisccoulson: so...wondering...shouldn't papi be taking care of all this egl shennanigans ?
<kgunn> (which is maybe why it works)
<kgunn> again i'm not as familiar...
<chrisccoulson> kgunn, papi?
<kgunn> chrisccoulson: platform api...which in turn is talking to mir
<chrisccoulson> aha :)
<kgunn> chrisccoulson: so i'm just spit-balling...but wondering if maybe, you can ask for egldpy id, but in the end it kind of ignores you and just takes care of some of the binding under the hood ?
 * kgunn starts to root around in platform-api
<kgunn> chrisccoulson: ...right, cause ua_ui_display_get_native_type() is actually from the platform-api i/f
<kgunn> ricmm: is it normal for an app that might query ua_ui_display_get_native_type() to get null back ?? but still operate ?
<chrisccoulson> kgunn, the other thing - even with a valid display handle, libhybris seems to actually ignore it - http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/trusty/libhybris/trusty/view/head:/hybris/egl/egl.c#L173
<chrisccoulson> (it passes EGL_DEFAULT_DISPLAY rather than the actual handle)
<kgunn> chrisccoulson: true...(altho you could get a egl no display return if hybris ws considers it invalid...)
<ricmm> kgunn: so that call is pretty transparent, it translates directly to mir_connection_get_egl_native_display()
<ricmm> so whatever is coming from there, you get
<ricmm> which ultimately will wrap hybris' EGL
<chrisccoulson> ok, so it seems like what I'm seeing is actually pretty normal
<chrisccoulson> so this could be a red herring wrt my original problem
<chrisccoulson> kgunn, ricmm, so, IIUC, MirConnection::egl_native_display() will always return EGL_DEFAULT_DISPLAY on the device?
<kgunn> certainly appears so
<chrisccoulson> kgunn, ok, thanks. so i have another issue then
<chrisccoulson> there are some android specific egl bits in chromium, i wonder whether we should actually be turning these on
<kgunn> chrisccoulson: it would depend, but quite possibly that may be required...
<kgunn> this is on n4 right ?
<kdub_> alan_g, with this failure: http://jenkins.qa.ubuntu.com/job/mir-mediumtests-builder-trusty-armhf/402/console
<kdub_> for CI on ~alan-griffiths/mir/fix-1276565
 * alan_g looks...
<kdub_> did you figure out what was happening on the builder? i see something similar on one of my branches
<alan_g> kdub: no. But I got the impression that everything was very slow yesterday
<kdub_> alan_g, okay, thanks
<mhall119> kgunn: are there any docs for the mir screencasting feature?
<kgunn> mhall119: nope
<mhall119> :(
<mhall119> is there a way to start/stop it from the commandline?
<mhall119> like phablet-screenshot?
<kgunn> its not even in archive yet
<kgunn> right now its just an api on mir for a server to hook into
<kgunn> its not intended to be something used arbitrarily
<kgunn> or i guess i should say "server side aware obj:
<kgunn> so like...shell will do something for AP testing...
<kgunn> and if you wanted apps to be able to utilize this...we'd have to talk to ricmm about how to expose that out to app world in a trusted manner
<mhall119> kgunn: I've been tasked with automating the creation of walk-thru videos with autopilot and screen recording, would it be possible for me to use whatever you're using to accomplish that?
<mhall119> this doesn't need to be in an app, it can be something I launch from the terminal via adb, or however else
<kgunn> mhall119: ah...yeah...likely
<kgunn> so, if you're wanting to do something quicker than later....you could use unity8 on desktop that would rely on mir
<kgunn> as you'd have a mouse
<kgunn> otherwise...not sure what visual queue you'd have for pointer
<kgunn> unless AP has some toggle to turn on a visual?
<kgunn> also...we've got one bug on desktop in mesa we think we've solve...whereas on android we're running into a driver issue
<kgunn> for which we don't have code yadda yadda
<mhall119> kgunn: what do you mean I'd have a mouse?
<mhall119> I thought unity8+mir on desktop didn't have non-touch input devices working yet
<kgunn> mhall119: oh no...i think its _some_
<mhall119> my plan was to have Autopilot dump a log of events and x,y coordinate for them, then programatically over-lay some visual on the video in post-production
<kgunn> like some specific hw bewteen certain years
<kgunn> mhall119: oh ok...sounds cool
<mhall119> bregma: kgunn: so will the Unity8+Mir desktop session preview still happen for 14.04, with enough input device support to actually use it?
<bregma> mhall119, that's the aim...  I already have enough devices :)
<bregma> it really just needs cursor-relative device support and improved out-of-box touchscreen device recognition
<bregma> keyboard works OK at the Mir level, but there are no keyboard shortcuts in the shell
<bregma> mouse and trackpad are a problem because there's no cursor, could be a configuration problem?
<anpok> greyback: any clue why we would permanently recomposit everything when the launcher is displayed?
<greyback> anpok: not off hand, lemme see what unity8 is doing..
<greyback> anpok: well I checked in case unity8 was continually rendering with the launcher open, but no. As a result, I've no idea why compositing hasn't stopped
<greyback> anpok: I used "QML_RENDER_TIMING=1" to find out by the way, it prints frame stats for each frame
<anpok> ah so it does not render
<anpok> how is the fading of the phone shell implemented?
<anpok> hm alpha value?
<greyback> yeah,  t draws black rectangle with alpha on top of app surface
<bregma> so, I grabbed the latest Mir 0.1.4 source package from Ubuntu and built it in a clean pbuilder (OK), then pushed it to a PPA where it failed on every single udev test ... has anyone else seen that, and is there a workaround?
<anpok> bregma: did you run make test?
<bregma> I ran dput -- it's a PPA and it's a source package from Ubuntu
<anpok> greyback: hm worst case is now three blended buffers, i.e. if you launched camera, then some app .. then it will render Cam|APP|Phone Shell
<anpok> because camera has larger buffer..
<anpok> bregma: it sounds like tests being run without libumockdev
<bregma> anpok, that would mean the package is broken
<bregma> nope mir-0.1.4 build-depends on lubumockdev-dev, and it _did_ pass the tests in a pbuilder chroot, it only fails in a PPA sbuilder
<anpok> is a libumockdev-preload.so accessible there? maybe there is an error message comaplaining about not being able to preload the library?
<bregma> every unit test fails with "libudev: udev_monitor_new_from_netlink_fd: error getting socket: Invalid argument"
<greyback> anpok: sounds good to me!
#ubuntu-mir 2014-02-07
<RAOF> Hm. When I'm blowing up code in 3rd_party I should probably move it under src/ shouldn't I.
<kdub_> RAOF, tough call
<RAOF> Oh, *that's* why you don't move anything from 3rd_party to src/
<RAOF> It doesn't compile, because it generates hundreds of warning from ten or more different constructs. Hurray!
<RAOF> âI killed him, cha cha chaâ
<RAOF> Alright. That's EOW for me. See yall Tuesday!
<anpok_> alf_: would moving null, logging and lttng into report also imply that as another namespace level
<anpok_> alf_: good morning
<alf_> anpok_: good morning :) I would imagine something like mir::report in which null,logging,lttng implementation are all implementation details
<alf_> anpok_: but not necessarily
<anpok_> hi alan_g
<alan_g> anpok_: ho
<anpok_> alf_: implementation details - as there are no public headers? or no further namespaces?
<alan_g> as in not needed by users of the class
<anpok_> sure we will get there..
<anpok_> just wanted to be sure about the details
<alf_> anpok_: primarily the first, but also the second i.e., mir/report/default_configuration.cpp would implement all the_*_report() methods using class internal to the reporting component (logging, lttng)
<anpok_> ah ok, I can see why, so all dependencies are in one direction..
<alan_g> alf_: anpok_ any opinions?  https://code.launchpad.net/~alan-griffiths/mir/SwitchingBundle-controls-completion-of-client_acquire-without-blocking/+merge/204294
<alf_> alan_g: looking
<anpok_> i am a bit puzzled by having multiple compositors
<anpok_> what would happen if we turn one screen off
<anpok_> i mean we have one compositor per output?
<greyback> alan_g: will you have a chance to look at bug 1276704 any time soon?
<ubot5> bug 1276704 in Mir "Need way of getting PID of Session" [Undecided,New] https://launchpad.net/bugs/1276704
<alan_g> greyback: I've just put it on today's list
<greyback> alan_g: thanks
<alf_> anpok_: we have multiple compositors (running in different threads) because 1. each output is backed by a different framebuffer that we need to draw to (exception: clone mode) 2. outputs have different vsync rates and vsync start offsets
<anpok_> but when one compositor is stopped it will release all buffers?
<anpok_> btw will you kill me for having mrn and mrl (mir::report::logging?
<alf_> anpok_: we have one MultiThreadedCompositor that coordinates composition on all outputs, and each output is then handled by a (Default)DisplayBufferCompositor instance
<alf_> anpok_: so which compositor are you referring to? :)
<anpok_> alf_: ok puzzle solved
<anpok_> it happens through the temporary compositor buffer being consumed as a shared ptr for the short time during composition
<alf_> anpok_: @mrn,mrl, I don't mind as long as they are internal to report (although Alan may not share this preference?)
<alan_g> Does "internal to report" mean in the same src directory?
<anpok_> no in another directory underneath
<anpok_> i just moved everthing below report
<anpok_> yeah this time everything
<anpok_> only lttng logging and null_*
<alf_> rsalveti: Hi! I was thinking, for the dynamic backends, do you need runtime selection or package time selection (e.g., have a libmirplatformandroid and libmirplatformmesa that both provide libmirplatform)?
<alf_> rsalveti: (runtime selection = being able to install both libmirplatformandroid and libmirplatformmesa at the same time and select the actual library at runtime)
<rsalveti> alf_: any would do for now (as we have different seeds for desktop and touch), but later on it might be good to do that in runtime
<rsalveti> in case someone installs the android one, and ends up breaking his desktop
<alf_> rsalveti: the difference in mir code is minimal (since we will load server/clients backends at runtime), it's more of a packaging decision
<rsalveti> ogra_: what do you think^?
<alan_g> alf_: in case you've not noticed - there's still a little android/mesa code in frontend (chosen at build time).
<rsalveti> ogra_: I don't think we have an official way yet to decide if we're in desktop or touch during runtime
<alf_> alan_g: thanks, there is also a lot of code on the client that is chosen at build time :) (I am fixing both)
<alan_g> :)
 * ogra_ reads
<ogra_> no, we dont have such a way *yet* but we will need one in the future ... for the time being selection via seeds will be fine
<ogra_> as long as we dont tie us in with that for the future (i.e. if it still stays an easy switch i guess it is fine to re-visit in 15.04 or 15.10, whatever will have the merged seeds)
<kgunn> rsalveti: atm isn't there at least some android version/value that can be interrogated ?
<kgunn> e.g. we have hwc1.0, 1.1 as well...and if no android present you're on desktop...couldn't that be the logic ?
<kgunn> alf_: ^
<alf_> kgunn: probably
<alan_g> greyback: https://code.launchpad.net/~alan-griffiths/mir/fix-1276704/+merge/205357
<greyback> alan_g: nice, thank you
<alf_> rsalveti: is the fix for bug 127662 enough to unblock you until we get dynamic backends?
<ubot5> bug 127662 in x11-xserver-utils (Ubuntu) "Removing insecure xhost package removes entire X server" [Medium,Expired] https://launchpad.net/bugs/127662
<alf_> rsalveti: hmm, bug 1276621
<ubot5> bug 1276621 in mir (Ubuntu) "Android backend unit-tests FTBS on amd64" [Undecided,New] https://launchpad.net/bugs/1276621
<anpok|lunch> alf_: alan_g: I need a name - a factory that creates reports based on the program options / server options ..
<rsalveti> alf_: yeah, trying that today
<rsalveti> alf_: ogra_: but it should just be easier for now to have a separated package
<rsalveti> and we can land it faster as well
<alf_> rsalveti: sure
<alf_> anpok|lunch: ReportFactory ?
<alan_g> I understand the reluctance to use "Factory" - if there's something less generic than a pattern name it should be preferred
<alan_g> is this an function, a class interface, an implementation, ...?
<alan_g> *a function
<ogra_> yeah, shiny is for later :)
<anpok|lunch> alf_: thats the interface
<anpok|lunch> alan_g: it is just an aggregation of three of those implementations .. for null reports logging and lttng..
<anpok|lunch> it just delegates to the real ones ..
<alan_g> Then surely the interface is AbstractFactory?
 * alan_g winces
<alan_g> ReportSelector?
<anpok> yes that would be fine for me, but thats like the generic version of the "er"-rule for turning verbs into nouns
<anpok> but since you proposed it, the rule cannot be applied by yourself
<anpok> oh... thank you!
<anpok> that thing does not need to implement the factory interface.
<alf_> kdub: Is mga::FBTargetLayerList::reset_composition_layers() going to be generally useful in the future? It's only used in the tests right now.
<alan_g> kgunn: looks like you're getting ready to land stuff. I think greyback would like this included if it gets reviewed: https://code.launchpad.net/~alan-griffiths/mir/fix-1276704/+merge/205357
<greyback> kgunn: that I would, but landing it will demand a unity-mir rebuild since it changes server API
<anpok> alan_g: still there?
<bregma> hey guys, I'm trying to run Unity8 on the desktop and I don't have any kind of cursor anywhere ... is there something I need to do in Mir or is it the shell layer that's expected to handle that in software now?
#ubuntu-mir 2015-02-02
 * alan_g wonders if it is safe to let clang update today
<racarr_> alan_g: Hey. I am trying to round up branches for a release...what do you think the status of unity-system-compositor/port-to-Msh-shell branch is
<racarr_> Just noticing it is still WIP and not proposed
<racarr_> I guess you'd like to land https://code.launchpad.net/~alan-griffiths/mir/MVC-refactor-msh-Shell-hierarchy/+merge/248030 first
<racarr_> ?
<alan_g> racarr_: that's because I want to land some Mir changes to simplify that and the qtmir equivalent.
<alan_g> Specifically https://code.launchpad.net/~alan-griffiths/mir/MVC-refactor-msh-Shell-hierarchy/+merge/248030
<alan_g> Doh! you spotted that
<racarr_> :) I see
<racarr_> alan_g: If I can round up some reviews for that branch for you (I'll do one too) do you basically have the qtmir/usc
<racarr_> branches ready?
<racarr_> Trying to make release ASAP to get various
<racarr_> event business out to downstreams
<alan_g> racarr_: I've spiked them. But not managed to test them. (Not figured out how to get USC running on desktop - and got distracted by lp:1416482)
<alan_g> the qtmir especially branch will be much nicer with the above MP - but I've not made the changes yet
<racarr_> mm
<racarr_> alan_g: I guess my real question is do you think they could be ready tomorrow tomorrow or so (assuming there are no problems landing Mir branch)
<racarr_> or should release continue and we grab them in next release...
<racarr_> I can help with most of the testing as part of testing the silo
<alan_g> racarr_: you can't build qtmir or USC against current Mir
<alan_g> But the branches are relatively safe "mechanical" reworks.
<racarr_> alan_g: Right, what I mean was should we land port-to-Msh-shell as they stand now
<racarr_> with mir-devel
<racarr_> s/land/release/
<racarr_> or do you think the new versions can be ready in a day or two
<racarr_> or is port-to-Msh-shell already out of date...? It was working friday :p
<alan_g> If I stop looking at lp:1416482 I can updated the branches in half an hour
<alan_g> But I'd really like to get MVC-refactor-msh-Shell-hierarchy in
<alan_g> When you say "working", you mean compiling?
<racarr_> alan_g: Lol...yeah thats the first step at least...then we can start the silo process
<racarr_> alan_g: I guess I will get reivews for refactor-msh-Shell-hierarchy
<racarr_> and you can continue working on 1416482
<racarr_> and either you, or I tomorrow can find time to update the downstream branches
<alan_g> racarr_: works for me
<racarr_> alan_g: Ok thanks :) talk to you soon
<kgunn> alf_: this will actually be solved with your u-s-c cursor work that's on vivid already right?
<kgunn> https://bugs.launchpad.net/bugs/1416642
<ubot5> Launchpad bug 1416642 in unity8 (Ubuntu) "No mouse cursor shown when connecting a BT mouse to the phone" [High,Triaged]
<greyback> duflu: http://rt.com/news/228559-eu-parliament-bomb-threat/
<alan_g> racarr: I've updated both branches to compile with MVC-refactor-msh-Shell-hierarchy (the USC one works with development trunk)
<racarr> alan_g: :) Thanks
<alf_> kgunn: the cursor support is there, but 1. u-s-c turns it off by default 2. unity8, as a nested server, doesn't use a cursor 3. In order to enable/disable the cursor dynamically we need support from the input subsystem (Anpok is working on this I think)
<alf_> kgunn: that being said, if you run a demo server you should see a cursor
<kgunn> right, on android
<alf_> kgunn: yes, on Mesa we have the hardware cursor, plus I think on desktop usc is invoked with a switch that enables the cursor
<alf_> kgunn: also on Android, with some drivers, there are problems with overlays with the cursor
<alan_g> alf_: @bfi-fix-1416482 - thanks, updated
<alf_> alan_g: approved
<alan_g> :)
<alan_g> alf_: is clang 3.6 behaving itself yet?
<alf_> alan_g: Haven't updated since Friday, let me give it a try
<alf_> alan_g: Clang still having problems for me. Note, however, that a clean installations seems to work (judging from the CI runs), so it may be a problem with my setup.
<alan_g> alf_: thanks
<kgunn> alf_: hey, iirc sometime back you did a sw framebuffer for headless setups
<kgunn> are there some instructions how to use?
<alf_> kgunn: --offscreen when invoking a server. Note that in this context headless == without a monitor, but it needs a working and supported GPU
<kgunn> bschaefer: ^
<bschaefer> alf_, awesome, thank you! bregma ^
<greyback> duflu: https://bugs.launchpad.net/mir/+bug/1417170
<ubot5> Launchpad bug 1417170 in Mir "qtcreator with mir_proving_shell breaks surface move" [Undecided,New]
<alf_> kgunn: bschaefer: bregma: It is just a prototype, though, meant for early feedback which we never got. So it may or may not fit your needs. Why do you need to use it?
<racarr_> I don't think im the person to do it but maybe its worth prioritizing https://bugs.launchpad.net/mir/+bugs?field.tag=gtk-mir
<racarr_> as most are still marked
<racarr_> wishlist
<racarr_> but I dont think thats how we really feel about them
<bschaefer> alf_, looking at getting automated tests for sdl2 using mir using an offscreen buffer
<alf_> bschaefer: ok, note that for this to work you need to be in a non-X VT currently
<kdub> could anyone around to review that 2nd-db branch of mine? :)
#ubuntu-mir 2015-02-03
<kgunn> racarr: so which branch is for mirevent2.0 against papi ? i thot i was looking for "port-to-event-2.0"
<kgunn> but only found this recent branch
<kgunn> https://code.launchpad.net/~mir-team/platform-api/expose-mir-connection
<kgunn> doesn't seem to have any event related changes...
<alan_g> alf_: FWIW I've now updated to clang 3.6. It works (even with use_debflags=on)
<racarr> kgunn: Remembering too qtubuntu branch is named port-to-mirclient not port-to-mirevent :)
<alf_> alan_g: ack. I am still having problems, so it's probably something in my setup.
<kgunn> racarr: :) yep, it was more obvious...as it had changes regarding events
<kgunn> thanks
<alan_g> Anyone know what's happening in CI? (I can't get to s-jenkins.ubuntu-ci via the VPN) Autolandings don't seem to be happening, Jenkins reviews don't always happen, ...
<alf_> racarr: Have the branches that will go into 0.11 been finalized? I would like to get my MPed branches in.
<alf_> alan_g: I see that autolanding and CI jobs are in progress
<racarr> alf_: No they haven't. will try and get your branches in too
<racarr> alf_: All your currently mped branches?
<alf_> racarr: Yes, if possible. Thanks :)
<racarr> alf_:  OK :)  shoud be possible...will evaluate in a few minutes
<racarr> alf_: Ok the TAed ones + https://code.launchpad.net/~afrantzis/mir/platform-operation-client-api-remove-opcode/+merge/248338 ?
<anpok> kgunn: lp:~mir-team/unity-system-compositor/toggle-cursor lp:~mir-team/mir/expose-cursor
<alan_g> racarr: it would be nice to sneak this through (it only touches examples) https://code.launchpad.net/~alan-griffiths/mir/MVC-rework-WindowManager-examples-using-msh-Shell/+merge/248138
<alf_> racarr: Sounds good. Ideally lp:~afrantzis/mir/remove-set-gbm-device-nested also, but let's see if it gets enough approvals in time.
<alan_g> alf_: that was next on my list
<anpok> alf_: do you see any reason why having a show() without a cursor image might be a bad idea?
<anpok> in mir::graphics::Cursor
<alf_> anpok: What will the behavior be? Show the last image? What if there is no last image?
<anpok> show the last image, and do nothing if there is none
<anpok> which means in case of the software cursor to keep the last image alive..
<alf_> alan_g|lunch: Fix potentially unaligned memory accesses in lp:~afrantzis/mir/remove-set-gbm-device-nested
<alf_> alan_g|lunch: s/Fix/Fixed/
<alan_g> alf_: approved
<kgunn> anpok: yo, seems abi changed
<kgunn> https://launchpadlibrarian.net/196466500/buildlog_ubuntu-vivid-amd64.mir_0.11.0-0~2285~ubuntu15.04.1_FAILEDTOBUILD.txt.gz
<kgunn> for building the cursor branch in the ppa
<anpok> kgunn: yes pushed a fixed
<kgunn> ta
<anpok> -ed
<kgunn> :)
<kgunn> greyback: so is there mir aspect to this one ?
<kgunn> https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1410457
<ubot5> Launchpad bug 1410457 in QtMir "DisplayWindow::makeCurrent crash with xmir apps" [High,Confirmed]
<kgunn> e.g. do we need to make sure someone is working it ?
<greyback> kgunn: I can't repro it with mir_proving_server, but am rather confused by it. I'd appreciate a hand
<kgunn> duflu: ^ can you assist?
<duflu> kgunn: Comment added
<kgunn> ta
<kgunn> duflu: http://en.wikipedia.org/wiki/Cabbage_patch_dance
<racarr> kgunn: lp:~mir-team/qtubuntu/shellRotation-mirclient
<racarr> kgunn: I guess it needs a proposal in order to go in your silo?
#ubuntu-mir 2015-02-04
<alan_g> alf_: FYI I discovered that my problems accessing the VPN were not what I thought. There's something broken in the networking stack - e.g. if I connect both wired and wireless or activate any VPN then DNS just hangs.
<alf_> alan_g: ack
<tmpRAOF> alan_g: Ah. You don't have something between you and the VPN dropping UDP packets that are 1500 bytes or larger? :)
<alan_g> tmpRAOF: not intentionally. Why?
<tmpRAOF> alan_g: That's why people at the sprint couldn't access anything through the VPN.
<alan_g> tmpRAOF: AFAIK the only change was updating to the latest vivid yesterday
<racarr> alan_g: duflu: You guys have qtmir conflicts in port-to-Msh-shell and fix-buffers_ready_for_compositor
<racarr> just the update to mock_surface
<racarr> both have to land in release so one of you should merge the others branch in and mark as a prereq
<racarr> or something similar
<alan_g> racarr: qtmir?
<alan_g> racarr: duflu already has mine as a pre-requisite
<racarr> alan_g: :) Ok looks like duflu is sorting it
<duflu> Yes and no. I have lots of things to rebuild and a little laptop. Please come back later
<racarr> :)
<alan_g> let me know if I can help
<duflu> alan_g: I'll have to propose to your branch. But that will be ~1hr away
<alf_> tmpRAOF: does github.com/RAOF/mesa contain the latest version of the code (i.e. does it correspond to the patch in the latest ubuntu package)?
<tmpRAOF> alf_: I... no longer know. I think so, but it's probably safer to take it from the latest ubuntu package.
<alf_> tmpRAOF: Thanks. I will check and try to bring the two in sync.
<tmpRAOF> bregma: You're after AddClientOnOpenFd, and it's in xserver core.
<anpok> alan_g|lunch: https://code.launchpad.net/~andreas-pokorny/mir/flags-utility/+merge/247565/comments/615275
<racarr> IRC standup! Working on keymap change support, buffer stream continuation, assorted silliness
 * kdub writes "//we're nested, so the posts are driven by the swaps"
<kdub> and its amusing because its one of those sentences that's unintelligible outside of the graphics world
#ubuntu-mir 2015-02-05
<willcooke> kgunn, imported:  https://code.launchpad.net/~mlankhorst/xmir/xmir
<mlankhorst> goodie
<kgunn_> \o/
<kgunn_> @vogons ^
<kgunn_> @unity ^
<kgunn_> bregma: bschaefer ^
<mlankhorst> but please use the git repo :P
<willcooke> mlankhorst, looks like it failed actually:  http://launchpadlibrarian.net/196684280/mlankhorst-xmir-xmir.log
<mlankhorst> .. :/
<mlankhorst> bug in bzr import it seems, looks like it can't handle GPG signed releases..
<mlankhorst> just use raw git :P
<willcooke> kgunn_, can we do that in the short term?
<kgunn_> willcooke: what's that ? sorry...in case i disconnected
<willcooke> kgunn_, there seems to be an issue with LP pulling in the Git repo.
<kgunn_> sure
<willcooke> kgunn_, can we work with it in Git for now?
<kgunn_> we'll just have to get the packages uploaded manually using the trainguards
<willcooke> Or we could some kind of manual push in to LP
<kgunn_> which is simple
<willcooke> ok!
<willcooke> nice
<kgunn_> yeah...so mlankhorst if you have a new set of packages that you'd say is ready to be put into a ppa & part of our demo lemme know
<mlankhorst> oke
<mlankhorst> when can I expect mir 0.11? :P
<mlankhorst> or is there a ppa somewhere with the cursor changes?
<kgunn> mlankhorst: so the ppa i shared, will have all those changes
<mlankhorst> oke
<kgunn> mlankhorst: but i think that mirevent2 landed as part of mir0.11
<kgunn> however
<kgunn> the qtmir utilization of it is in lag
<kgunn> e.g. we'll test and land that next
<mlankhorst> oke I'll build 0.11 myself then..
<dandrader> kgunn, the fix for the silo 0 https://code.launchpad.net/~alan-griffiths/qtmir/port-to-msh-Shell/+merge/247844/comments/615755
<kgunn> mlankhorst: oh...actually, there is a ppa for testing that has just mir0.11
<kgunn> not trunk (i think)
<dandrader> kgunn, gotta apply this patch to this MP http://paste.ubuntu.com/10069953/
<kgunn> one sec
<kgunn> dandrader: ack
<kgunn> mlankhorst: ah yeah...so this silo/ppa
<kgunn> http://people.canonical.com/~platform/citrain_dashboard/#?distro=ubuntu&q=landing-012
<kgunn> is the testing silo/ppa for mir0.11
<mlankhorst> oke
<mlankhorst> and if I use that with unity-system-compositor I get the mouse events?
<kgunn> mlankhorst: mmm....on desktop yeah i thikn you just get it....on andrdoid devices, you have to use the u-s-c that's in the ppa for the demo (vivid silo 0)
<kgunn> anpok: ^ right ?
<kgunn> mlankhorst: difference being that hw cursor is used on desktop, and android doesn't suport hw cursor
<alf_> mlankhorst: Hi! If I have a patch for the mesa mir egl backend, what's the best way to propose? Diff against ubuntu branch on debian git, debdiff, some other way?
<mlankhorst> alf_: ask raof..
<alf_> mlankhorst: OK, forget I mentioned the mesa mir egl detail :) I mean in general, how would do you prefer me to propose a package update for mesa.
<mlankhorst> feel free to upload and I'll merge the changes back to the packaging
<alf_> mlankhorst: upload where?
<mlankhorst> archive?
<mlankhorst> or do you want a review :P
<alf_> mlankhorst: I don't have ubuntu archive access, if that's what you mean. I could push to a PPA though.
<mlankhorst> oke then just send me a diff ..
<alf_> mlankhorst: ok, thanks. I will do so after some wider testing (probably will push to PPA first anyway).
<alf_> mlankhorst: (after 0.11 is released)
<kgunn> alan_g: hey mornin' would you mind updating your qtmir branch based on dandrader's feedback ?
<kgunn> https://code.launchpad.net/~alan-griffiths/qtmir/port-to-msh-Shell/+merge/247844/comments/615755
<kgunn> ....we _think_ it's the last thing to change in order to test/rel mir0.11
<alan_g> kgunn: just compiling it before pushing
<kgunn> thank you sir
 * alan_g wishes there were automated acceptance tests that pick this up.
<alan_g> kgunn: dandrader - done
<kgunn> cool
<mlankhorst> alf_: hm do I need a even newer version of mir to kill of the thread mir creates?
<kgunn> thank you
<dandrader> alan_g, thanks
<mlankhorst> I want to kill the thread proxy in Xmir
<mlankhorst> makes input handling slightly easier for me..
<alf_> mlankhorst: It's now my turn to tell you 'ask RAOF' :) But assuming what you want is an event fd, that didn't make it into 0.11 AFAICT.
<mlankhorst> aw..
<mlankhorst> yeah probably not
<alf_> mlankhorst: https://code.launchpad.net/~raof/mir/provide-event-fd/+merge/247794 , in case you want to check if this is good enough for your use cases
<mlankhorst> it probably is
<mlankhorst> the main thing I worry about is if my hack that copies the full event will hold until mir advanced enough for that one..
<mlankhorst> it's a lot easier to rework events after that provide-event-fd code is merged
<Saviq> hey guys, does that crash ring a bell for you bug #1418456? mardy can't get unity8 to start on an Atom netbook
<ubot5> bug 1418456 in unity8 (Ubuntu) "unity8 assert failure: *** Error in `unity8': double free or corruption (fasttop): 0xb20055a0 ***" [Medium,New] https://launchpad.net/bugs/1418456
<ogra_> its not only free sowftware but even double free software :P
<alan_g> alf_: you were looking at a heap corruption recently ^
<alf_> alan_g: doesn't look familiar, it seems that an exception(?) happens and we are unwinding the stack when we get the memory error
<alan_g> alf_: ack
<mardy> alan_g, alf_: I've that machine running, if you want feel free to ask me more questions for debugging, I can give you the results right away
<alf_> mardy: could you run unity8 under gdb?
<mardy> alf_: sure; any specific parameters or env variables to set?
<alf_> mardy: no params, but type 'catch throw' in gdb before running
<alf_> mardy: (so it will stop when an exception is thrown)
<mlankhorst> so why is my touchpad in unity-session-compositor seen as a touch event? :s
<mardy> alf_: but I should export QT_QPA_PLATFORM=ubuntumirclient, right? Otherwise it seems it's trying to talk to X
<mlankhorst>  
<mardy> alf_: or maybe export QT_QPA_PLATFORM=mirserver?
<alf_> mardy: I haven't tried in a while but unity8 env. variables I used for manual invocation are: MIR_SERVER_NAME=session-0 MIR_SOCKET=/run/mir_socket QT_QPA_PLATFORM=mirserver
<mardy> alf_: anyway, looks like it's quitting immediately, no crashes (but I see a "Gtk-WARNING **: cannot open display:" message (Gtk??)
<mardy> alf_: ok, let me try with those
<alf_> mardy: perhaps MIR_SOCKET is different now
<mardy> alf_: even with those variables, it exits immediately, with that Gtk warning
<alf_> mardy: oh, are you running USC?
<mardy> alf_: so, I've been running this commands from a text terminal, after doing a "sudo service lightdm stop"
<alf_> mardy: so USC has stopped too
<alf_> mardy: let's go back a step and try with the demo servers only
<alf_> mardy: Install the mir-demos package (if you don't have it already)
<mardy> alf_: done
<mardy> alf_: I even tried the mir_demo_server before, but it took control of the terminal and I didn't know how to quit or switch to another terminal
<alan_g> mardy: the mir servers will exit on Ctrl+Alt+BkSp
<alan_g> Or SIGTERM etc
<alan_g> It is easiest if you can get a terminal session from another device - e.g. ssh
<greyback_> mardy: this is my command to start unity8 on desktop: http://pastebin.ubuntu.com/10072333/
<alf_> mardy: be careful to run *sudo* mir_demo_server
<willcooke> mlankhorst, so still issues with the pointer in xmir?
<mardy> greyback_: it still quits immediately, with that Gtk warning
<mardy> alf_: ah, let me try
<mlankhorst> seems to right now, but I don't know if a fix has made it in to qtmir yet..
<alf_> mardy: do you have ssh access to the machine?
<mardy> alf_: yep
<greyback_> mardy: that command depends on USC running
<mardy> alf_: so, with the demo server I get a black screen and a working mouse pointer
<mardy> greyback_: ok, I'll try that later as soon as we confirm with alf_ that the mir things are working
<alf_> mardy: ok keep that running and ssh to the machine
<mardy> alf_: yep, done
<alf_> mardy: as first test run in ssh "sudo mir_demo_client_egltriangle"
<alf_> mardy: you should see a rotating triangle on screen
<mardy> alf_: yes, it works
<alf_> mardy: ok, stop it (ctrl-c), and run 'sudo mir_demo_server --host /tmp/mir_socket -f /tmp/mir_nested'
<mardy> alf_: ok, no changes on screen, but the thing is running
<alf_> mardy: ok, new ssh and run 'sudo mir_demo_client_egltriangle -m /tmp/mir_nested'
<mardy> alf_: works fine, too
<alf_> mardy: ok, good, so base mir is working
<alf_> mardy: now kill every mir related process
<alf_> mardy: and 'sudo start lightdm'
<alf_> mardy: that should start usc, and try to run unity8 and fail
<alf_> mardy: but usc should stay running
<willcooke> anpok, were you working on the input stuff in qtmir for pointer events etc?
<alf_> mardy: then ssh and use e.g. greyback's invocation to start unity
<mardy> alf_: so, I should login using the unity8 session, right?
<alf_> mardy: actually before you log in do a 'ps -Af | grep unity', does it show anything?
<mardy> alf_: ops, too late, I already logged in. It shows USC, unity8-dash and a couple of processes related to unity-scopes
<alf_> mardy: no problem, just wanted to make sure USC wasn't already running
<mardy> alf_, greyback_: always the same: http://pastebin.ubuntu.com/10072557/
<alf_> mardy: hmm, let's see where the mir_socket is created at, try 'find /var /tmp /run -name mir_socket'
<greyback_> mardy: could you put 'import QtQuick 2.2; Rectangle{ color: "blue" }' into a test.qml file, and do the above command, but replacing /usr/bin/unity8 with "qmlscene test.qml"
<mardy> alf_: not found
<mardy> greyback_: same output as above; so I guess this is due to the missing mir socket
<greyback_> mardy: yeah, tho am surprised it's not printing an error
<alf_> mardy: try 'cat /proc/$(pidof unity-system-compositor)/cmdline'
<alf_> mardy: and 'cat /proc/$(pidof unity-system-compositor)/environ'
<alf_> mardy: perhaps they will give us a clue
<alf_> greyback_: The invocation you pasted is for a nested unity8, right?
<greyback_> alf_: correct
<mardy> alf_: the first says /usr/sbin/unity-system-compositor--disable-inactivity-policy=true--on-fatal-error-abort--file/run/lightdm-mir-0--from-dm-fd12--to-dm-fd21--vt8--enable-hardware-cursor=true
<mardy> alf_: the second is XDG_SEAT=seat0XDG_VTNR=8PWD=/
<greyback_> alf_: to test qtmir is working, stop unity-system-compositor, run "DESKTOP_SESSION=unity8-mir QT_QPA_PLATFORM=mirserver qmlscene test.qml"
<alf_> mardy: ok, so the file you are looking for is
<alf_> mardy: '/run/lightdm-mir-0'
<mardy> alf_: yes, it's there, it's a socked owned by root  with 777 permissions
<alf_> mardy: hmm, but that was already correct in greyback's invocation...
<mardy> greyback_: should I run your command as root?
<greyback_> mardy: yes
<mardy> ahh
<greyback_> sorry, I always forget that
<greyback_> and yeah, you need ssh access to stop it
<mardy> greyback_: nope, nothing changed, same output
<greyback_> mardy: ok that's not expected
<greyback_> mardy: it crashes right?
<greyback_> could you grab a backtrace?
<mlankhorst> I'm not a mir-dev.. but shouldn't input_event_type_to_string handle type_pointer ?
<mardy> greyback_: no, it looks like a clean exit "[Inferior 1 (process 12590) exited with code 01]"
<mardy> greyback_: and it's even claiming that your process is inferior ;-)
<greyback_> :)
<mardy> greyback_: is that Gtk warning expected?
<greyback_> mardy: no
<alf_> greyback_: can we (try) to connect one of the mir demos to usc, to check if at least that part is OK?
<greyback_> alf_: go for it
<mardy> greyback_, alf_: do you think that a strace can help?
<greyback_> mardy: I'm extremely confused, so yeah, give me anything you think of
<alf_> greyback_: Well, it was mostly a question of how to make USC accept it? What environment should we set? MIR_SERVER_NAME=session-0 DESKTOP_SESSION=unity8-mir ?
<greyback_> alf_: MIR_SOCKET=$XDG_RUNTIME_DIR/mir_socket \
<greyback_> MIR_SERVER_PROMPT_FILE=1 \
<greyback_> MIR_SERVER_HOST_SOCKET=/run/lightdm-mir-0 \
<greyback_> MIR_SERVER_FILE=$XDG_RUNTIME_DIR/mir_socket \
<greyback_> MIR_SERVER_NAME=session-0 \
<greyback_> those should do the trick
<mlankhorst> willcooke: https://bugs.launchpad.net/qtmir/+bug/1417650 seems this bug is related?
<ubot5> Launchpad bug 1417650 in QtMir "Pointer motion and crossing events are missing" [Undecided,In progress]
<alf_> mardy: when you are done strace-ing, you could try 'mir_demo_client_egltriangle' with the environment greyback pasted above to see if at least the demo client can connect to usc
<mardy> greyback_, alf_: https://launchpadlibrarian.net/196699566/unity8-strace.log
<willcooke> mlankhorst, aha!  So it's being worked on already, right?
<willcooke> I will speak to kgunn and the guys here shortly....
<mlankhorst> I'm not sure if it's worked on specifically..
<mlankhorst> but lets hope so
<mardy> alf_: nope: "Can't get connection"
<alf_> mardy: sudo?
<alf_> mardy: I noticed in strace that you are running 32-bits (i386), perhaps that could be significant (or not)
<mardy> alf_: yes, I started it from within a "sudo -i" environment
<greyback_> mardy: could you run the qmlscene line in gdb, break on gdk_init and backtrace it please
<mardy> alf_: if I add the "-m /run/lightdm-mir-0" option to the egltriangle test, then it connects and apparently runs, though nothing is visible on screen
<alf_> mardy: ah, right, this is a client -m is the correct switch
<willcooke> mlankhorst, if we need it looking at I can ask
<alf_> mardy: ok, that's expected, usc doesn't bring it to the foreground
<alf_> mardy: so the socket works fine
<mardy> greyback_: so, it doesn't hit gdk_init
<greyback_> mardy: how about gdk_display_open
<mardy> greyback_: gtk_init() is hit, instead
<greyback_> ah
<alf_> mardy: I leave you in greyback_'s capable hands for now (he is more familiar with the qt/unity8 side of things anyway), got to get some lunch, be back in a bit
<mardy> alf_: ok, thanks a lot
<mardy> greyback_: http://paste.ubuntu.com/10072964/
<mlankhorst> willcooke: well it looks from the diff like it's useful..
<mardy> greyback_: I hope there is not a switch based on the CPU architecture in there...
<greyback_> mardy: there isn't in my code anyway
<greyback_> mardy: could you muck with /usr/lib/i386-linux-gnu/qt5/plugins/platformthemes/libappmenu-qt5.so to prevent it being loaded?
<greyback_> tho oddly it is loaded here and unity8 comes up just fine
<mardy> greyback_: ok, now I get the "double free or corruption"
<mardy> greyback_: wait, let me try with qmlscene first
<mardy> greyback_: yep, I get the memory corruption with qmlscene as well
<greyback_> mardy: backtrace again please
<mardy> greyback_: http://paste.ubuntu.com/10073018/
<mardy> greyback_: as you can see I typed "catch throw", but it seems like there was no exception
<mlankhorst> willcooke: hm it's probably necessary but not sufficient
<mlankhorst> afaict
<greyback_> mardy: could you add the missing symbols?
<greyback_> that code is more mir's
<willcooke> mlankhorst, just spoke to kgunn and greyback_, someone will get on to this asap.  greyback_ will probably work on it
<mlankhorst> oke
<mlankhorst> just tested and nested mir works as intended
<mlankhorst> just unity8 is borked
<greyback_> mlankhorst: borked how?
<willcooke> mlankhorst, side question:  how's your xmir ppa looking atm?  Good to try on our devices here?
<mlankhorst> ought to?
<mlankhorst> greyback_: I don't get pointer events..
<mlankhorst> my pointer events get converted to touch events
<greyback_> mlankhorst: that issue, ok, yeah I'm on it
<willcooke> thanks guys
<mlankhorst> willcooke: ppa works fine afaik, I was working on moving to new touch events but it can wait
<mardy> greyback_, alf_: http://paste.ubuntu.com/10073198/
<willcooke> mlankhorst, ack
<greyback_> mardy: frame 11 could be very useful, libmirserver28-dbgsym is missing?
<mardy> greyback_, alf_: http://paste.ubuntu.com/10073557/
<anpok> willcooke: input stuff in unity-system-compositor and mir
<willcooke> anpok, no worries, I think greyback_ is looking at the issue
<greyback_> mardy: thanks for the paste, I need alf_ to help you with that
<alf_> greyback_: mardy: back, looking
<alf_> mardy: could you run qmlscene with valgrind please?
<mardy> alf_: ah! I anticipated you :-) I just did it, let me collect the logs :-)
<mardy> alf_: http://paste.ubuntu.com/10073830/
<mardy> alf_: see the error at the end of the logs: "std::exception::what: Failed to create shared EGL context"
<alf_> mardy: ah, this is much more helpful, thanks!
<alf_> mardy: could you please attach this to the bug so it doesn't get lost?
<mardy> alf_: ok
<kgunn> racarr: i owe you a beer....disabling n seems to be working
<kgunn> like life chaning
<kgunn> changing event
<mardy> alf_: done
<alf_> mardy: thanks
<alf_> mardy: greyback_: So, the root cause of the bug is the exception "std::exception::what: Failed to create shared EGL context". This causes the stack to unwind and releases objects in a way that causes memory errors, but that's secondary, only a side effect. I will work on fixing the effect, probably the problem is in our Mesa code.
<alf_> mardy: still we need to find out why the context creation fails...
<alf_> mardy: could you run qmlscene under gdb and additional environment variables MESA_DEBUG=1 and EGL_LOG_LEVEL=debug
<mardy> alf_: sure
<alf_> mardy: then in gdb break on _mesa_error()
<alf_> mardy: before running
<racarr> alan_g: Hey...testing release and running in to some issues I think may originate with the SurfaceConfigurator changes...
<alan_g> racarr: ok?
<racarr> aha sorry got distracted mid sentence loud room
<racarr> alan_g: OSK hiding got broken somewhere between
<racarr> the OSK and the QML the minimized state isn't
<racarr> successfully applying or being pushed through or some such
<racarr> just wondering if you have any ideas :)
<duflu_> alf_, mardy: Sounds like bug 1408910 :)
<ubot5> bug 1408910 in unity8 (Ubuntu) "Ubuntu Desktop Next fails to start; just black screen and mouse pointer (unity8.log: std::exception::what: Failed to create shared EGL context)" [Critical,Confirmed] https://launchpad.net/bugs/1408910
 * alan_g goes to look at the Q_EMIT surfaceAttributeChanged changes...
<racarr> alan_g: I haven't verified it entirely because Im still getting debug symbols...but we added some print in the QML side on the input method element and
<racarr> the first time it does show that state changed to showed...and
<racarr> set_surface_attribute continues being called but
<racarr> state never changes again...so it may be uh
<racarr> the value of "result" is incorrect or being mangled or some such
<dandrader> anpok, the env var is GRID_UNIT_PX
<alf_> duflu_: mardy: ah, indeed
<mardy> alf_: this is what I get, the _mesa_error() was not hit: http://paste.ubuntu.com/10074123/
<alf_> mardy: ok, please try setting the breakpoint after you have run the program once in gdb and then re-run, sometimes BPs don't work correctly if the symbols is not loaded
<alan_g> racarr: nothing leaps out at me. Is there an image I can try?
<alf_> duflu_: bug 1418486, I will re-add mir, because although it's strictly not code in the Mir codebase, it's still the "Mir project" and I want it to show in the bug list for Mir. I will remove it when done.
<ubot5> bug 1418486 in mesa (Ubuntu) "Mir Mesa EGL platform leaks memory with every frame" [High,In progress] https://launchpad.net/bugs/1418486
<duflu_> alf_: Yep, OK, standard behaviour
<alf_> duflu_: I wonder if there is a better way to express the relationship of the two projects in LP... Perhaps have a "Mir project" meta-project? Anyway...
<racarr> alan_g: Yeah its showing up in the release PPA http://people.canonical.com/~platform/citrain_dashboard/#?distro=ubuntu&q=landing-012
<racarr> alan_g: The whole issue I guess is...the way the osk hides is it does this animation
<duflu_> alf_: Yeah, not without LP enhancements, which take decades :) Just using "Mir" is OK
<racarr> and then it sets the minimize state
<racarr> and qtmir hides it.
<racarr> so there is an existing bug where sometimes the animation does not finish
<racarr> (it mostly seems to show up on n7...)
<racarr> and hten you will see
<racarr> a little bit of the OSK left over at the bottom
<racarr> because the
<racarr> well, the hiding doesnt work
<racarr> alan_g: We are seeing it may actually just be the wrong version
<racarr> of the package in the silo....so
<racarr> maybe don't spend any time on it now lol...sorry
<alan_g> racarr: OK. Keep me informed.
<racarr> alan_g: Thanks :)
<racarr> alan_g: Ah its still broken even with the correct packages :( (featuring the metatype registration)
<alan_g> racarr: :(
<greyback_> mlankhorst: lp:~mir-team/qtmir/port-to-event-2.0/ should enable mouse hover - it needs mir 0.11 though
<alan_g> racarr: I'm still not sure what your saying is going wrong. Is the server is getting the state change notification at set_surface_attribute() but not publishing the surfaceAttributeChanged event? Or is the there something not happening client side?
<mlankhorst> greyback_: oke, last I tried it was borked, is it fixed now?
<mlankhorst> greyback_: I was getting touch events rather than pointer events even with that branch :/
#ubuntu-mir 2015-02-06
<alan_g> racarr: I think I know what I missed. Working on a quick fix. (But it opens up a whole load of simplifications to qtmir that I'm trying to resist for now.)
<alan_g> racarr: I've not had time to test and have a hospital appointment - but I've pushed what I think is a fix to port-to-msh-Shell
<alf_> racarr: How is the 0.11 release going? Asking because I need 0.11 to be released so I can release some Mesa fixes/changes.
<alf_> racarr: (Good morning!)
<alf_> racarr: duflu: @mir abi broken, we knew about this and since mir_connection_platform_operation was not (and couldn't have been) in use, we chose to ignore it. What changed?
<duflu> alf_: I lost track... ask racarr
<racarr> alf_: It was a series of confusions because we had a crash moving a client from .10 to .11 so it was like
<racarr> oh ABI must be broken
<racarr> so then we ran compliance checker and its like
<racarr> ok yeah ABI broken
<racarr> then at the end of the day we realized it wasn't in use ( I was mistakingly imaginging the mesa EGL platform using it forgetting the fds were preauthed)
<alf_> racarr: yes, all external code (i.e. XMir) still uses the mesa_connection_drm_* functions
<alf_> racarr: and mesa doesn't use mir public client functions at all directly
#ubuntu-mir 2015-02-07
<mlankhorst> XMir-standalone doesn't use mir at all :P
<mlankhorst> I'm not sure XMir really needs to use mir for EGL, since it does its own flipping can't it use gbm?
<mlankhorst> oh it probably doesn't use egl either :p
#ubuntu-mir 2016-02-08
<duflu> alf_, alan_g : Should it be possible for a client with the default swap interval to submit frames that never make it to composition? That's what I'm seeing in our test framework. If the client starts too quickly then the test server never sees that frame.
<duflu> ... which is a problem our acceptance tests don't cope with and they they measure latency wrong
<duflu> they then
<alf_> duflu: I don't think we should allow that
<alf_> duflu: (I mean a frame never making it to composition)
<duflu> alf_: yeah losing a frame and only seeing the second and subsequent ones is a problem. I'll have an acceptance test for it soon, but not a fix
<coretex__> no frame left behind
<duflu> Heh
<alan_g> duflu: in a bit of synchronicity I've been puzzling over StaleFrames.are_dropped_when_restarting_compositor which seems to test for that behaviour.
<duflu> alan_g: Sounds related, although mine is on startup
<duflu> What is a stale frame?
<duflu> I forget
<alan_g> AFAICS so is the test (despite its name)
<duflu> Dropping frames except in the confines of well-planned triple buffers with at least 2 frames ready is usually unsafe
<duflu> Because you can drop the newest frame
<duflu> With no guarantee anything comes after it
<alf_> duflu: when restarting the compositor we want to show only the latest submitted frame, instead of all queued frames (don't forget that even when the compositor is off we allow clients to render at a low rate 10FPS or so). Older frames that we don't want to render, are called 'stale'.
<duflu> alf_: Oh, yes. But I'm not restarting :)
<alan_g> How is the "re" in restarting significant to that argument?
<duflu> alf_: Do we delete stale frames even when there's only one? That would be a problem...
<alan_g> By that definition the latest one can't be stale
<duflu> Because it might be a slow or simply well-behaved client, and the latest frame could be from before it went to sleep. Not displaying that is a serious problem
<duflu> alan_g: Fair point. But we could still mess it up infinite ways...
<alf_> alan_g: in theory at least, we can't have a stale frames when first starting the server, since we start the compositor before the client connector
<alf_> alan_g: but perhaps we are messing this somehow?
<alan_g> alf_: Like I said, I was puzzled by this test at EOW. Maybe it will make sense today.
<duflu> Sounds relevant. Maybe skipping a stale frame on start-up is right...
<duflu> Gah, I read that backwards. Must be approaching EOD
 * duflu continues with the test, regardless of what the bug or fix is...
<zzarr> hello duflu :-)
<duflu> zzarr: Hi
<zzarr> I found a libGLESv2 for my mail 764 GPU, I haven't tested it yet (my package system got broke when installing ofono and urfkill)
<zzarr> is there a way I can check if the lib I have is the one needed by Mir?
<alan_g> alf_: are your concerns addressed? https://code.launchpad.net/~kdub/mir/refix-1517205/+merge/283861
<anpok> vogons: I am thinking about moving MirClientConnection.. from graphics::nested .. to .. hum not sure yet
 * alan_g wonders
<anpok> *MirClientHostConnection
<anpok> I need to forward input device events
<anpok> register for changes .. in nested setup
<anpok> it currently does graphicse and life cycle events.. so it alreday feels slightly misplaced
<anpok> hm or I will just leave it there and wait for complains and suggestions..
 * alan_g thinks "nested" is already more than graphics - and is unlikely to complain.
<anpok> ah .. I mean it is inside graphics right now..
<anpok> mir::nested would make more  sense to me
<alan_g> I know that. ;)
<anpok> and mir::nested::graphics for related stuff..
<anpok> ok
<alan_g> anpok: we should revisit nested, the platform ABI (and especially, if we really need create_guest_platform()) after NBS has solidified. It ought to be possible to do things a lot more cleanly.
<anpok> aye.. i was close to implementing what I need as a platform.. but turned out that the input subsystem behaves quite different when nested..
<anpok> it does not nees any of the interesting state tracking parts to begin with.
<anpok> s/nees/need
<alan_g> alf_: do you know what this failure is? https://code.launchpad.net/~alan-griffiths/mir/fix-1535894-alt/+merge/285223/comments/725800
<alf_> alan_g: yeah, just mentioned that in #mir
<alf_> alan_g: it seems to be a package problem
<alf_> alan_g: in libuuid1
<alan_g> I suspected that, or a the test system configured "incorrectly"
<alf_> alan_g: I will try to work around that by updating the chroot (so that we don't need to upgrade the package for each package build). Not sure it will help but let's see...
<alan_g> alf_: thanks. (I was mostly concerned that nothing you'd done was causing unexpected failure.)
<alf_> alan_g: hmm, not working, same error
#ubuntu-mir 2016-02-09
<zzarr> hello! duflu, you told me a command to check if a libGLESv2 is compatible with Mir, but I don't remember what it was
<duflu> zzarr: Hi, yes. That is required in theory. I think the first step though is to try and get a Mir server starting.
<duflu> I suspect it will be blocked by the VT bug on Chromebooks still
<zzarr> but I have a kernel with a real tty :D
<duflu> That helps too
<zzarr> I'll just fix an little issue (no root pass/no sudo)
<zzarr> duflu, how do I start Mir? (just selecting Unity8 at login?)
<zzarr> (Unity8-Mir)
<duflu> zzarr: No, don't start with Unity8. Start simpler: sudo apt-get install mir-demos ; sudo mir_proving_server
<zzarr> okey, thanks
<duflu> It will likely fail for some reason. I would be surprised if some dev work wasn't required
<zzarr> me too
<zzarr> duflu, mirserver: Selected driver: mir:mesa-kms (version 0.19.1)
<zzarr> is that sw or hw?
<duflu> zzarr: Either. Mesa includes both, depending on what hardware drivers match your system
<duflu> Although all of them will probably fail on your chromebook
<zzarr> duflu, why?
<duflu> zzarr: because Mesa does not include a hardware driver that matches you hardware, and Mir does not yet support software
<duflu> I think....
<duflu> Maybe sw will partially work
<duflu> LLVMpipe should be transparent
<zzarr> duflu, okey, but I did install a libGLESv2 for the GPU
<duflu> zzarr: Yeah that might help, or it might confuse Mesa. Not sure which
<duflu> Mir only knows how to display buffers (windows) from the Mesa drivers. So the Mali one probably won't appear on screen, even if it loads
<zzarr> I have to fix the network settings....
<zzarr> duflu, okey, but is there a way to check if the mesa driver knows about the mali one?
<duflu> zzarr: You'd need to be an experienced developer to figure it out
<duflu> Most likely a new driver would need to be written too
<zzarr> I am an experienced developer... but not in that area
<zzarr> I'm working with sensors and other stuff, like databases and applications for phones
<zzarr> duflu, I hope I'm not intruding on your time to much
<duflu> zzarr: I've been tinkering in graphics for approaching 20 years. And despite being on the Mir team admit I'm not familiar with most driver architectures. You need to be familiar specifically with the Mesa code and/or Android
<duflu> Oh, approaching 25 years
<zzarr> nice
<duflu> zzarr: The key issue will be the buffer sharing approach used. Mir supports Mesa buffers or Android buffers right now. And a libGLESv2 that's specifically for Mali might not understand either. But there's a chance it might understand one of them.
<duflu> You can find out by checking what OS the libGLESv2 was intended for
<zzarr> duflu, I know the driver is intended for X11
<duflu> zzarr: What does 'ldd' say about it?
<zzarr> I'll have a looksie
<zzarr> it says: librt.so.1 libpthread.so.0 libdl.so.2 libstdc++.so.6 libm.so.6 libgcc_s.so.1 libc.so.6 with an => to the path and a /lib/ld-linux-armhf.so.3 at the end
<zzarr> duflu, is that bad or good?
<duflu> zzarr: Good, because there are no significant dependencies. But also inconclusive. How about libEGL?
 * duflu has an interesting thought
<duflu> (only one)
<duflu> If a custom driver for the chipset can be made to work with DRI then we could skip Android completely. That's interesting because Mesa is typically better behaved and performs better than Android
<zzarr> duflu, the same
<zzarr> libEGL.so libGLESv1_CM.so libGLESv2.so and libOpenCL.so are all symlinked to libmali.so
<zzarr> duflu, I like that thought
<duflu> zzarr: Interesting. I wonder if those binaries or similar are available for use on any Mali devices that mir-team has...
<zzarr> it's specific for mali 76x but there are drivers for other mali GPU's too
<zzarr> duflu, can we continue the discussion tomorrow, someone came ;-)
<duflu> zzarr: OK, bye
<zzarr> duflu, thanks, bye
<popey> kgunn: is there any plan to support (in any way) clicks on x86 (desktop or some other device) any time before snappy fixes everything?
<alan_g> anpok: anything to add? https://code.launchpad.net/~alan-griffiths/mir/discussion-point/+merge/284935
<anpok> alan_g: not sure whether it was anything new ..
<alan_g> anpok: all part of an interesting weave of opinions. Thanks
<anpok> thought about another sequence..
<alan_g> And I don't think A is true of every pair of request on every object. (E.g. submitting buffers isn't sequenced with changing cursors)
<kgunn> popey: little confused by the question, support clicks on x86 before snappy?....where are clicks not supported that you are hinting at?
<popey> kgunn: I am unaware of any working way to get Unity8 working on a desktop (assume x86) where one can "pkcon" or "click" install a click package
<popey> kgunn: it's been broken forever, and last comment I heard was "yeah, wontfix"
<popey> https://bugs.launchpad.net/ubuntu/+source/click/+bug/1396611 for example
<kgunn> popey: do you know why that won't work? i mean, i don't know how u8 shell or mir would prevent that
<ubot5`> Launchpad bug 1396611 in click (Ubuntu) "Cannot install click packages on ISO installs of Ubuntu" [Undecided,Confirmed]
<popey> ^ is one example why
<popey> but I have seen others
<popey> https://bugs.launchpad.net/ubuntu/+source/unity8-lxc/+bug/1466432
<ubot5`> Launchpad bug 1466432 in unity8-lxc (Ubuntu) "Cannot install click packages on the unity 8 desktop session" [Undecided,Confirmed]
<popey> My point in all this is "Should I bother putting x86 clicks in the store, when it's impossible for anyone to install them?"
<ogra_> popey, well, they would be available in the emulator, no ?
<popey> True, that's one other use case I hadn't considered.
<popey> Hows that working these days? :)
<ogra_> no idea
<kgunn> stahp
<popey> me either
<kgunn> popey: i'm kinda tempted to say "that should work" and with the velocity of snap intersecting a "personal" snappy setup, i think it's probably even more so that it should work
<popey> kgunn: right, but snap!=click. I'm specifically on about clicks here. For the avoidance of doubt.
<ogra_> kgunn, well, that woud mean we need to ship the same frameworks by default on desktop ...
<popey> It should have worked for some time ã
<popey> But doesn't and hasn't, ever.
<ogra_> i'm also not sure how well click is designed for multi-user in its current state
<kgunn> popey: not sure about worked forever...u8 just got usable
<popey> no, I am specifically talking about installing clicks
<ogra_> (might have all bits it needs, but it was never used in that context before, bugs might be plenty)
<kgunn> popey: and i know you mean click...which is why people prolly said "won't fix"...believing that snaps would save the universe
<popey> indeed
<popey> So I'm inferring from this, that it's not a priority for anyone to make this work as everyone believes (cargo cult style) that snappy fixes this?
 * ogra_ doubts that click 9is any prio for anyone ... 
<popey> I mean, no point putting devs on this if snappy does indeed fix it
<popey> Exactly.
<kgunn> popey: i wasn't even aware, but yeah i'd agree with you
<ogra_> snappy does ... the question is when does it :)
<kgunn> ogra_: moreover...when does snappy intersect personal-desktop
 * popey is keen on knowing this also.
<ogra_> kgunn, right ... the graphical side on snappy is still totally blurry
<kgunn> well, then there's the "break the world of devs" aspect to htat
<ogra_> (so its not even desktop or desktop interaction .... if we havent solved the lowest level how can we have the highest working)
<kgunn> popey: let me at least talk to pat (looks from the bug, that's really his guys)
 * kgunn needs coffee/toast until then....
<popey> kgunn: thanks
<jleen__> popey, thanks
<Saviq> hey guys, looks like my powerd or u-s-c locked up, can't get the screen to turn on
<Saviq> I can ssh to the device
<Saviq> and powerd-cli list takes maybe 20s to return
<Saviq> anything interesting here https://paste.ubuntu.com/15001777/ from u-s-c?
<Saviq> powerd looks much more tame https://paste.ubuntu.com/15001805/
<Saviq> bregma, who do you think could have a quick look ââ? I'd like to get my phone back :)
<Saviq> huh, wonder where everything re: display config comes from, this was the phone just working (or well, might be the screen waking up?)
<Saviq> dednick, greyback_ does https://paste.ubuntu.com/15001777/ look like a lockup you guys saw when reconfiguring displays?
 * Saviq gets moar symbols
<dednick> Saviq: http://pastebin.ubuntu.com/15001827/
<dednick> Saviq: not so sure. i think my "lock" was more a 100% process thing.
<Saviq> dednick, right, and that's unity8, where for me it's u-s-c
<Saviq> afaict
<dednick> Saviq: it is u8. no idea what usc was doing at the time.
<bregma> AlbertA or alf_ can you take a glance at Saviq's stacktrace above re a powerd crasher? ^^^^
<Saviq> !crasher
<Saviq> lockup
<bregma> *problem
<alf_> bregma: At first glance it seems like a problem that anpok may have fixed (deadlock between display and input)
<alf_> bregma: anpok ^^ Does this look like the bug you fixed?
<alf_> anpok: ^^
<greyback_> Saviq: I've not seen lockup in that location before
<Saviq> alf_, bregma, anpok, http://pad.lv/1543594 in any case (private since it's retracing)
<ubot5`> Error: launchpad bug 1543594 not found
<alan_g> Hmm, SystemCompositorWindowManager::add_display() grabs a lock before accessing output_map, but just above it SystemCompositorWindowManager::remove_surface() erases entries without a lock.
<alan_g> Saviq: bregma alf_ - there's a failing-to-lock bug in SystemCompositorWindowManager::remove_surface() - could be related to this stack trace.
<alan_g> bregma: this could be related to Saviq's failure mode. Want it backported to 0.19? https://code.launchpad.net/~alan-griffiths/mir/fix-SystemCompositorWindowManager-remove_surface/+merge/285492
<anpok> re
<anpok> it looks simlar, alf.
<bregma> if the problem Saviq sees is easily reproduce able, then other people will experience it too, so we want to get a solution out there...  problem is is it the input fix or the surface-removal fix?
<anpok> hm I can only tell with a stack trace... It requires a input dispatch attempt while a display configuration is changed
<Saviq> bregma, can't say it's easily reproducible, I've had something similar a handful of times, but IIRC it recovered after some time
<Saviq> anpok, http://pad.lv/1543594 has a symbolic ThreadStacktrace
<ubot5`> Launchpad bug 1543594 in unity-system-compositor (Ubuntu) "unity-system-compositor locked up in __libc_do_syscall()" [Undecided,New]
<anpok> only for one thread it seems.. then I cannot tell for sure, at least that stack does not look familar to the problem
<anpok> still the actual problem might be caused by other threads, not shown in the Stracktrace.txt
<AlbertA> Saviq: so maybe the same as https://bugs.launchpad.net/canonical-devices-system-image/+bug/1532607 ?
<ubot5`> Launchpad bug 1532607 in unity-system-compositor (Ubuntu) "Phone not usable while a call comes in - followed by "restart"" [Critical,Confirmed]
<AlbertA> Saviq: what were you doing before you got the screen to lock up? did you get a notification or call?
<Saviq> AlbertA, incoming call, couldn't wake the screen, didn't restart by itself though - just locked up permanently
<alan_g> Saviq: not plugging/unplugging outputs then?
<Saviq> alan_g, no, just a phone in my pocket with an incoming call
<Saviq> krillin, too, so no way to connect an external screen
<AlbertA> Saviq: ok, this at least gives us a lead on the issue :)
<AlbertA> ok best I Can tell from the stack trace... a message came through Dbus to turn the screen on with reason=proximity...
<AlbertA> then mir failed to start the compositor for some reason, which invokes the unwind handler
<AlbertA> which attempts to destroy the threads it just created
<AlbertA> however, the exception is not propagated to the ThreadPool so no exception is set on the std::future so it waits indefinitely for it.
<AlbertA> it's still unknown why the compositor thread failed to start however....
 * alan_g see "unwind handler" and wonders if the handler in question is safe against the uncaught_exception() bug?
<AlbertA> alan_g: which bug would that be?
<alan_g> AlbertA: back in g++4.x there was a bug that meant uncaught_exception() got stuck on "true" after an exception was thrown
<AlbertA> ah right
<alan_g> And Saviq's phone was built with 4.9
<Saviq> yup, vivid
#ubuntu-mir 2016-02-10
<zzarr> hello duflu :-) I'm back
<duflu> zzar: Hello
<duflu> zzarr: What happened when you started Mir? You only mentioned one log message yesterday. Was that the end?
<zzarr> duflu, how do I start Mir? is it the sudo mir_proving_server you mean?
<duflu> zzarr: Yes that
<zzarr> duflu, if it is that command, I just ran it again, and it says that "gbm: failed to open any driver (search paths /usr/lib/arm-linux-gnueabihf/dri:${ORIGIN}/dri:/usr/lib/dri)"
<zzarr> gbm also complains about not being able to open /usr/lib/dri/rockchip_dri.so
<duflu> zzarr: Yeah that's the failure I expected all along. You either need some Mali driver for Mesa, or some new Mir driver for Mali.
<duflu> Ooh, maybe rockchip_dri.so exists somewhere
<zzarr> duflu, I'm scanning the internet
<zzarr> duflu, is that driver a kernel driver or user driver?
<duflu> zzarr: It's the user driver Mesa needs for hardware acceleration
<duflu> zzarr: You might get around it with env LIBGL_ALWAYS_SOFTWARE=1
<zzarr> duflu, ohh... in that case there might be way to find it (I think others have done it)
<duflu> I can't see any evidence that rockchip_dri.so exists yet. But environment variable LIBGL_ALWAYS_SOFTWARE=1 should skip the need for it
<zzarr> duflu, okey, I know that people have gotten 3D acceleration to work with X, are the rockchip_dri.so they used specific for X?
<duflu> zzarr: That's just a file Mesa needs to implement OpenGL. If they got X working it might have been without any OpenGL
<zzarr> duflu, okey, I tried sudo mir_proving_server after setting LIBGL_ALWAYS_SOFTWARE to 1, butI got the same error messages
<zzarr> (from gbm)
<duflu> zzarr: Yeah I just tested it and Mir weirdly ignores that common variable, still tries hardware acceleration or nothing. Sounds like a bug
<zzarr> duflu, I agree
<zzarr> duflu, a little off topic, do I need to add netdev to the lightdm user in order to login to a WiFi from lightdm?
<duflu> zzarr: No idea. You will have to ask in ubuntu-desktop or some other channel
<zzarr> duflu, I'll do
<duflu> zzarr: You can follow this: https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1543952
<ubot5`> Launchpad bug 1543952 in mesa (Ubuntu) "Mir binaries ignore Mesa setting LIBGL_ALWAYS_SOFTWARE=1 and only ever try hardware acceleration" [Undecided,New]
<zzarr> duflu, there it is
<duflu> It is now anyway
<zzarr> yea
<anpok_> duflu: if there is no drm driver there is nothing to post buffers to
<duflu> anpok_: I know. But there is one or two (sw) and Mesa won't let us use them
<duflu> Which is odd. In regular Ubuntu, Unity7 relies on LIBGL_ALWAYS_SOFTWARE as a failsafe fallback
<duflu> And it works
<duflu> Maybe egl-platform-mir is forcefully choosing hardware drivers only...
<anpok_> mir doesnt care what driver mesa uses. we just dont build mesa with the fbdev platform... so mesa may only work on top of x11, wl, mir and drm
<anpok_> so if the kernel does not include drm-next patches it will be missing the rockchip drm driver that is currently being integrated
<duflu> anpok_: Also doesn't matter. He has working DRM with the mali/rockchip GPU
<duflu> anpok_: Also he built his own kernel with the required DRM.
<anpok_> oh so then things should work just like within
<anpok_> kvm
<anpok_> where we use the software backend of mesa
<duflu> Yeah but Mesa insists looking for rockchip_dri.so which may not even exist
<duflu> And Mesa still insists even if you try to force it to use the software driver
<duflu> When I do so on desktop it still gets Intel DRI
<anpok_> hm is there a kms_swrast_dri.so?
<duflu> anpok_: On my machine yes
<anpok_> hm there is a good chance the respective env variable inside gbm/egl is different
<anpok_> thats the one it should fall back to,,
<zzarr> interesting
<zzarr> duflu, would a fbdev user driver help?
<duflu> zzarr: No, that would probably be worse. Looks like you're waiting on a Mesa/Mir fix
<zzarr> duflu, do you mean for sw acceleration?
<duflu> Yes (which is much easier than hw)
<zzarr> duflu, would I be able to use an X11 hw driver with XMir?
<duflu> You're probably making it more complicated and harder again
<zzarr> duflu, sorry, it's a bad habit ;-)
<zzarr> duflu, what about the android driver?
<duflu> zzarr: Again, that's worse
<zzarr> duflu, if I got my hands on the fbdev or X11 drivers source, how much work and is there a guide to write my own Mir driver? (please, it's not your monitors fault, it my fault the text is in front of you)
<duflu> zzarr: alf_ is already working on fbdev (or some alternative) in theory. I suggest your best bet is to figure out the bug with the env var
<duflu> Which would help us too
<zzarr> duflu, okey
<zzarr> duflu, at the moment I will try the X11 drivers
<zzarr> duflu, but I will try to figure out what's up with the SW variable, where's the code that's related to the variable?
<duflu> zzarr: Mesa :)
<zzarr> duflu, okey, thanks alot for your help :-)
<duflu> zzarr: No problem
<zzarr> duflu, another OT question, how do I find out why Unity(7) don't appear for me even with the drivers in place?
<zzarr> (the X11 drivers)
<duflu> zzarr: #ubuntu-unity I think
<duflu> could be wrong
<zzarr> okey, thanks duflu
<zzarr> alf_, hello! I have to ask out of curiosity, how far along with the frame buffer support for Mir are you?
<zzarr> alf_, I mean the fb driver support
<alf_> zzarr: Hi! Just a proof of concept (and only for software buffers). I haven't touched the code in a long time now.
<alf_> zzarr: (which isn't published anywhere at the moment)
<zzarr> alf_, okey, will there be hw fb support in the future?
<alf_> zzarr: What do you mean by hw fb support? The PoC code used the fbdev interface, by "software buffers" I mean the buffers posted by the client need to be software buffers (i.e. their pixels need to be directly accessible, contrast to accelerated/hw buffers used e.g. for GL rendering on the GPU)
<zzarr> alf_, I'll tell the hole story, I have a Chromebook with a mali GPU and wish to get Mir running on it
<zzarr> alf_, I only have a fbdev driver and a X11 driver
<zzarr> alf_, I have the ASUS Chromebook Flip you see, and the way Unity8/Mir handles touch it's perfect :-)
<mcphail> alan_g: Do you mind if I ask if that gcc bug is looking to be the culprit for the screen crashing on calls on the phone? I've be holding off updating my phone because of this, and it would be good to know if there has been a lead
<alan_g> mcphail: maybe. In any case it is something we need to eliminate. Last I heard we've still not been able to reproduce the problem under controlled conditions but have stack traces pointing to that area.
<mcphail> alan_g: thanks. I think it is fascinating that this could be the cause. Amazing detective work you're doing
<alf_> alan_g: mcphail: FYI, our current understanding of that crash is that input and compositor threads deadlock during compositor startup, causing the compositor to throw an exception because it times out waiting for its threads to start, leading to a crash. We we will ship a fix for this in 0.19.2.
<pete-woods> greyback: hey, did your MR to libqtdbustest help at all?
<greyback> pete-woods: not got around to checking tbh
<greyback> was gonna land it, and then see. I can't emulate what the jenkaas instance is doing
<pete-woods> greyback: okay, no worries, was just wondering if it needed putting in a silo
<greyback> pete-woods: it does. I was going to do that for next unity8 landing, but that might be a while away yet
<pete-woods> greyback: sure, wasn't pressing you to do it now or anything, was more an offer to land it for you, but I'll hold off if you don't know it helps
<greyback> pete-woods: fair. We'll stick it in our silo and see if it helps. No point landing if it doesn't
<mcphail> alf_: brilliant. thanks for the info and teh hard work :)
#ubuntu-mir 2016-02-11
<zzarr> alf_ how much work is it to make Mir talk to fbdev?
<anpok_> zzarr: is that really the right problem to solve?
<anpok_> i mean .. if you have a drm capable kernel driver.. you already have the right mechanism to efficiently post to screen, and to pass buffers from clients to server
<anpok_> the only missing piece in your case seems to be a mali driver that works with drm
<anpok_> or as a temporary solution kms-swrast
<anpok_> oh of course your drm kernel driver could mis some features
<anpok_> then we would have to add those.. what mir needs there can be easily enabled via various drm-helpers..
<anpok_> zzarr: you could ask the lima driver developers..
 * alan_g thinks it really is about time we cleaned up support for 3rd party "platform" modules
<anpok_> zzarr: i did look at that situation with mali recently
<anpok_> zzarr: the mali drivers user ump to manage memory... in theory ump is capable to grant other processes access to buffers. But I havent seen any way to get egl/glev2 render to such a handle, their fbdev-egl drivers do not over an entry point with a native ump handle to render to..
<anpok_> the x11-egl drivers require an x11 connection, and also allocation happens underneath..
<anpok_> so the only arm-mali solution that might work - is the android drivers..
<anpok_> s/not over/not offer/
<anpok_> so if you can build an android kernel for your board.. you should be able to get mir working with hybris and the arm drivers that you can download from arm.com..
<anpok_> the only other options are: build and select kms-swrast as dri driver, or look into lima.. http://limadriver.org/
<zzarr> okey anpok_
<zzarr> what changes needs to be done to the kernel to run hybris?
<zzarr> anpok_, or is there a tutorial how to rewrite the X driver to become a Mir one?
<zzarr> anpok_, is there a Mir driver I can have a look at (so I can compare the mali X driver to it?)
<zzarr> I'll read this later, I'll leave the chat open, have to go
<anpok_> zzarr: hm not sure what hybris actually needs.. but the mali driver for android will require a mali kernel module.. I am not sure how to integrate that one. I once looked how it was done for an Allwinner SOC, and it didnt look easy..
<zzarr> anpok_, okey, you don't think it's possible to "just install" the user space driver?
<anpok_> as in I tried to migrate that one to a newer kernel version, and got lost in the integration code that needs to access clocks and interrupts
<zzarr> ohh.... I see
<anpok_> so the easier path here would be to get an android kernel for rockchip
<anpok_> and port ubuntu-touch to it
<anpok_> but I cannot help with that
<zzarr> I thought it was a matter of kernel configuration
<anpok_> well .. of configuring the right kernel
<zzarr> the thing is, everything except the graphics and closing the lid/flipping are working
<anpok_> someone did that for rk2918 http://forum.xda-developers.com/showthread.php?t=2318728
<zzarr> I have seen that there are android specific configuration options in the kernel, but... I'll have a look
<zzarr> If I manage to make an Android version of the kernel (or get one from some RK3288 based device) will the other drivers (/lib/modules... /lib/firmware...) stop working so I need a WiFi driver and so forth too?
<anpok_> which kernel did you use?
<zzarr> I used one for Kali linux for my device
<zzarr> (it actually uses both KERN-A and KERN-B)
<anpok_> so .. you would need one that has drivers/gpu/mali
<zzarr> anpok_, the kernel(s) are basically the default one(s) but with console activated
<zzarr> and as it have GPU acceleration when Chrome OS is booted it have some driver
<zzarr> but it's drm
<zzarr> anpok_, I hope that I'm not too tiresome, but as many devices are based on the RK3288 SoC I think it would be very nice to get Mir support for it :-)
<anpok_> hm yeah it would be interesting to see how the mali driver that they probably use interact with the drm module
<anpok_> chrome os has the advantage that they only have a single rendering process in the system, and the different browser rendering process communicate the command streams to that process..
<zzarr> anpok_, yea, but I think that's only the user space driver
<zzarr> and freon
<zzarr> I'll download the code for the mali X driver
<anpok_> oh the x11 user space parts are open source?
<zzarr> I think they are, if I don't remember wrong
<zzarr> here http://malideveloper.arm.com/resources/drivers/open-source-mali-gpus-ump-user-space-drivers-source-code-2/
<zzarr> I have to go now, I'll check the chat later (I'll leave it open)
<zzarr> thanks so much anpok_
<zzarr> I'll figure it out some how ;-)
<anpok_> ok
<zzarr> anpok_, now I'm here again for a little while
<zzarr> I'm sitting on a bus
<zzarr> I'm remote controlling a computer at home with the chat
<zzarr> anpok_, I got the ump driver, is that enough to write a Mir driver? (I don't see anything interesting yet)
<zzarr> I'm soon to get off the bus
<anpok_> enough to write a server i guess. but not enough to get a client to render with glesv2 as far as i understood it
<zzarr> are you looking at the code?
<anpok_> i was looking at the glesv2 sdk examples from arm ... looking for a way to initialize egl with an ump handle..
<anpok_> but maybe i was missing something
<zzarr> I have to close the connecton now
<zzarr> okey
<zzarr> bbl
<zzarr> I'm back... for now, I was going to a postal office, but the guy who tried to deliver the package to my door wrote the wrong office on the paper he put in my mailbox
<zzarr> so I have to go to another office....
<zzarr> anpok_, the code I downloaded have a ump_arch.c, ump_frontend.c and ump_ref_drv.c are they useful?
<zzarr> anpok_, there are other ump* files as well
<zzarr> I have to go to the other postal office now
<zzarr> bbl (again)
#ubuntu-mir 2016-02-12
<zzarr> hello anpok
<anpok> hi
<zzarr> anpok, here are the ump libs http://malideveloper.arm.com/resources/drivers/open-source-mali-gpus-ump-user-space-drivers-source-code-2/
<zzarr> (or lib/code)
<zzarr> anpok, are there sufficient code to write a Mir driver?
<zzarr> anpok, other whys it looks like it's possible to use the android driver (I think that the kernel driver may be the same for both X and Android drivers, if I haven't misunderstood )
<anpok> yes kernel side is the same, I did look into UMP User Space Drivers r4p0-00rel1
<anpok> and there was no mentioning on how to get egl/glesv2 to render to an ump handle
<anpok> zzar: that would be the problem to be solves
<anpok> *solved
<anpok> the other stuff is helpful.. as it tells you how to transfer handles been processes which is an important piece
<anpok> s/been/between
<anpok> they might have an extension to setup egl with that.. i dont now.. an alternative native window handle.. maybe
<zzarr> anpok, as I'm still new to GPU drivers, I think that the android driver is the easiest way for me
<zzarr> anpok, is there a tutorial how to install and configure the android lxc?
<alan_g> kgunn: I'm going through the bugs targeting 0.20 and came across bug 1528384 - what is the latest status of that? Is it fixed in 0,19,2?
<ubot5`> bug 1528384 in Unity System Compositor "unity-system-compositor crashed with std::runtime_error in mir::compositor::CompositingFunctor::wait_until_started() from usc::MirScreen::set_screen_power_mode (mir_power_mode_on)" [Critical,In progress] https://launchpad.net/bugs/1528384
<anpok> zzarr: look for ubunte touch porting guide.. and ask in #ubuntu-touch .. e.g. people like ogra_  or morph or ...
<anpok> *ubuntu
 * kgunn checks
<zzarr> I have asked in #ubuntu-touch
<ogra_> well, rather ondra and morphis :) ... i'm not very familiar with the GPU driver setup on the android side
<zzarr> okey ogra_, well, I'll read the text on the internet before asking
<zzarr> if I get stuck I'll ask
<kgunn> alan_g: ah yeah, that landed...the reporting....and AlbertA_ has branches up for 19.2 for that nasty bug
<kgunn> alan_g: so we're going on the hope that there's not a seperate subtle bug lurking there
<kgunn> for the case of 0.20 you can consider it ok
<kgunn> done
 * alan_g wonders how to convince LP it was committed in 0.19.2
<alan_g> alf_: You have a USC release in the pipe? (I was about create a "no-change" release for Mir-0.20.0, but does this impact?)
<alan_g> greyback__: Saviq - in doing a Mir release do I need to do anything for qtmir-gles? (Saviq left a note that one of the steps isn't needed, but there are other I suspect it applies to.)
<greyback__> alan_g: usually, if you're not incrementing the qtmir version number, just proposing an empty MP against lp:qtmir/gles , and adding to train, is enough
<Saviq> alan_g, nothing in changelog needed, but you should bump the dep in debian/control
<Saviq> alan_g, basically, anything you change in debian/ for the non-gles MP, should be changed in the -gles one
<Saviq> it's no longer necessary to mangle debian/changelog or debian/watch
<alan_g> OK, so as (in this case) I've just an empty MP for qtmir that covers it.
<alan_g> Or, I need an empty one for lp:qtmir/gles too?
#ubuntu-mir 2016-02-14
<Saviq> RAOF, hey, since you'll be the first to work among, can I abuse you to please click â» near the Regression on https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-051/excuses.html? much obliged :)
<RAOF> Saviq: Sure.
<Saviq> that worked fast :)
<Saviq> thanks a bunch!
<RAOF> You're reasonably sure that retrying will actually result in success? :)
<Saviq> RAOF, yeah, bug #1532358
<ubot5`> bug 1532358 in unity-scopes-shell (Ubuntu) "flaky autopkgtests cause migration issues" [High,Triaged] https://launchpad.net/bugs/1532358
<RAOF> Maybe you should run them three times and pass if any of them pass :P
<RAOF> Retry requested.
<RAOF> Have a nice Sunday!
<Saviq> not much of it left, was nice, thanks :)
<Saviq> RAOF, gah, it's more persistent than I had hoped, can we have another try, please https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-051/excuses.html - last time, I promise ;)
<RAOF> Ok.
<RAOF> Now go to sleep!
<Saviq> yes mom
<RAOF> :P
#ubuntu-mir 2017-02-06
<duflu> RAOF: I don't encourage you to hang around late but care to rethink this? https://code.launchpad.net/~vanvugt/mir/fix-hide-then-show/+merge/316089
<alan_g> duflu: is this OK with you? https://code.launchpad.net/~alan-griffiths/mir/fix-0.26-mirclient-ABI/+merge/316428
<duflu> alan_g: Yes, but I keep getting into trouble for fixing branches during the build/test/release cycle. Not sure if we want to fix it...?
<alan_g> duflu: QA have not got to the ticket yet. It's low risk as it just reintroduces a couple of symbols - I can rebuild the silo and test on desktop before camako wakes up.
<duflu> alan_g: Sure, please do. I'm off in a moment
#ubuntu-mir 2017-02-07
<superextra_> mir 0.26.1 from silo seems to work great on xenial
<superextra_> that's all. bye
<alan_g> vogons ^ FYI
<camako> awesome
<alan_g> greyback: it isn't quite finished, but there's a first cut at miral workspace support: https://code.launchpad.net/~alan-griffiths/miral/workspaces/+merge/316584
<greyback> alan_g: ack!
#ubuntu-mir 2017-02-08
<hikiko> hello
 * alan_g waves
<hikiko> do you know if I need proposed or some other repos to have the latest miral/mirclient?
<alan_g> hikiko: Mir 0.26.0 is in X+O and Z, as is Miral 1.1. There's a Mir 0.26.1 in a silo, but I don't see that you'd need it.
<hikiko> alan_g, when I include mir_toolkit header files in chromium I get this error:
<hikiko> In file included from /usr/include/mirclient/mir_toolkit/events/event.h:90:
<hikiko> #include "mir_toolkit/mir_input_device_types.h"
<hikiko> and apt-file search doesn't return anything
<hikiko> I wonder what I am missing
<hikiko> is this a bug or there's a lib I should have installed?
<hikiko> locate also cant find this file
<alan_g> that's in libmircore-dev.  What do you get from $ pkg-config --cflags mirclient
<hikiko> $ pkg-config --cflags mirclient
<hikiko> -pthread -I/usr/include/mirclient -I/usr/include/mircookie -I/usr/include/mircore
<hikiko> that lib was missing :)
<alan_g> Then /usr/include/mircore/mir_toolkit/mir_input_device_types.h ought to be there
<hikiko> :s
<hikiko> ok installing mircore-dev fixed that
<hikiko> apt-file should return it though :/
<alan_g> Hmm. $ apt depends libmirclient-dev doesn't list libmircore-dev - sounds like a bug
<hikiko> yes, when I ran apt-get build-dep libmirclient-dev mircore-dev was not installed
<alan_g> greyback_: up for review: https://code.launchpad.net/~alan-griffiths/miral/workspaces/+merge/316584
<greyback_> alan_g: ack
#ubuntu-mir 2017-02-09
<duflu> RAOF: Can we kill max_simultaneous_outputs, or does it have a future?
<RAOF> I believe I've already answered this :)
 * duflu looks
<RAOF> It's a *shrug*
<RAOF> It's information that's easy to provide, but it's not easy for a client to use.
<duflu> RAOF: I mean https://code.launchpad.net/~mir-team/mir/fix-1661163/+merge/316307
<RAOF> Hm.
<RAOF> The deprecation message is incorrect, but I'm not aghast at the function being deprecated.
<duflu> I know, was just a suggestion
<duflu> We could declare it deprecated and then decide to keep it
<duflu> RAOF: OK then, a simpler question: Are 'cards' a dead concept?
<RAOF> Yes
<duflu> I thought so, but max_simultaneous_outputs depends on them
<RAOF> In our current implementation, yes.
<duflu> Then again, so does everything loosely
<RAOF> Again, yes :)
<RAOF> It's possible that cards will be exposed again in the client interface, but we've never ever exposed more than one.
<RAOF> Which is why they're not useful.
<RAOF> That said, prime support will suddenly mean that sometimes we *do* have more than one card.
<RAOF> But the first go at that will not really expose that.
<duflu> RAOF: Hmm.... seems my best option is to just improve that deprecation comment
<duflu> Since the logic to implement it was deleted
<RAOF> It'd be pretty easy to re-add that logic, but *shrug*.
<duflu> RAOF: It was part of a larger code deletion (I just bisected it). Too hard
<duflu> for now
<RAOF> Oh, I mean you could easily re-add logic that would support it.
<RAOF> But, again, shrug.
<RAOF> Also, EOD!
<duflu> Kay, bye
<dandrader> AlbertA, around?
<dandrader> alan_g, using the new "mir_window_spec_set_cursor_name() && mir_window_apply_spec()" API doesn't trigger mir::scene::SurfaceObserver::cursor_image_set_to as the deprecated API "mir_cursor_configuration_from_name() && mir_window_configure_cursor" does
<dandrader> alan_g, What should I be listenting to on the server side now?
<alan_g> dandrader: I would expect that to work. Possibly a Mir bug.
<dandrader> alan_g, ok, will report then
<dandrader> alan_g, https://bugs.launchpad.net/mir/+bug/1663197
<ubot5> Ubuntu bug 1663197 in Mir "mir_window_spec_set_cursor_name() doesn't trigger mir::scene::SurfaceObserver::cursor_image_set_to" [Undecided,New]
<alan_g> dandrader: ack
<alan_g> A question to ponder: https://code.launchpad.net/~alan-griffiths/miral/miral-toolkit-dev/+merge/316827/comments/825816
<elopio> kgunn_: AlbertA: hey, can you please check for my email in your inbox? I think you are sending me to the spam :'(
<AlbertA> dandrader: here.. let me check the frontend
<AlbertA> elopio: oh I was just waiting for kgunn to answer sorry :)
<elopio> AlbertA: he seems to be missing in action. But anyway, the ideal was to have you both to talk about the work you have been doing.
<elopio> AlbertA: can you join us on Friday next week?
<AlbertA> elopio: I can , I believe kgunn_ is on vacation today
<kgunn_> elopio: i'm here...busy
<kgunn_> otp
<kgunn_> ah...demos, thank you AlbertA
<dandrader> AlbertA, turns out to be a bug in miral
<dandrader> AlbertA, will try out your qtubuntu branch again once the fix is available
<AlbertA> dandrader: cool thanks
<elopio> AlbertA: awesome! I'll send you the invite, and more details next week.
<alan_g> dandrader: confirmed a Mir bug - aiming to get fix into 26.1
<dandrader> alan_g, ok
