#ubuntu-mir 2013-12-16
<duflu> Eeek, brown-out
<RAOF> Win!
<RAOF> The mediumtests-trusty-touch and mediumtests-runner-mako CI jobs are just failing at the moment, aren't they? That's not an issue with my code?
<duflu> RAOF: They are indeed just failing :/
<duflu> in 80-90% of cases...
<duflu> So you can retry :)
<duflu> RAOF: Could you kindly give the changelog and version proposals an honorary approval?
<RAOF> There you go.
<duflu> RAOF: Ta
<RAOF> I know *why* we have debian/ in the repository, I just continue to think it's a bad idea ;)
<duflu> RAOF: If we continue with the two separate branches then I agree. But while the goal is to ideally have one, then I disagree
<duflu> Hmm, we *could* hide debian/ in dev and just quietly maintain it in lp:mir :)
<RAOF> Yes, we could.
<duflu> Although that makes code reviews of packaging changes impossible
<duflu> Umm, less convenient
<RAOF> Not really? We just review on lp:mir
<RAOF> I don't think it's a bad idea to have packaging changes reviewed in a different place to code changes; our developer skill sets are almost entirely disjoint, too.
<duflu> Surely debian/ as a subdirectory is designed that way so you can keep it with your code without stepping on any toes
<RAOF> Historically it has not been; we're being an unhelpful upstream by including it.
<RAOF> (This is mostly fixed with deb src 3.0, though)
<duflu> RAOF: I hate to say it, but code reviews are even more scarce on lp:mir than dev.
<RAOF> Are there any reviews to *do* on lp:mir?
<duflu> I mean, if you rely on the subset of developers with the skills to review packaging changes, then you don't have enough reviewers
<RAOF> Ah, but we can get potentially get didrocks and other distro people to review those changes.
<duflu> Because he loves us so much already
<duflu> And rightly so
<duflu> I mean that both ways
<RAOF> No one from distro is going to regularly check merges that are almost all code changes unrelated to distro work; if we separate out those quite-infrequent changes it's more likely we can shanghai people to do them.
<RAOF> duflu: What's the typo?
<duflu> RAOF: construtor ?
<RAOF> AHA!
<duflu> Or is it copy-construe-er?
<duflu> If all else fails, copy and paste into an edit field with spell-checking
<RAOF> Hm. I do appear to have dropped into my native braces style a bit there, don't I?
<RAOF> Also, I'm pretty sure our style guide suggests 120 characters ;)
<duflu> RAOF: On the theme of readability, not style compliance :)
<duflu> Though I've already spent enough of my life trying to explain to people why a limit of 80 cols is important. I won't waste my breathe (much) more
<duflu> breath too
 * RAOF wonders if we should set up clang-format as a precommit hook.
<duflu> RAOF: I suspect we have too many exceptions we'd like to keep :)
<duflu> Including 3rd party, which we wish to not touch where possible
<tvoss> RAOF, +1 on clang-format
<anpok> is there a rule for curly braces placement .. egyptian vs on the same column?
<RAOF> Is egyptian
<RAOF> if (foo)
<RAOF> {
<RAOF>    hello();
<RAOF> }
<RAOF> ?
<RAOF> If so, yes, we use Egyptian :)
<anpok> nope
<anpok> if (foo) {
<anpok>    hello();
<anpok> }
<anpok> http://www.codinghorror.com/blog/2012/07/new-programming-jargon.html
<alf_> anpok: http://unity.ubuntu.com/mir/cppguide/index.html
<tvoss> olli, ping
<anpok> alf_: yes, but it only states it for function definitions.. and some examples use { on the same line..
<alf_> anpok: they are wrong :)
<anpok> obviously
<duflu> Awesome. Now I can code like an Egyptian and party like it's 1986 simultaneously
<RAOF> alf_: I'd like a second opinion on GLContext { void make_current() const; }; duflu has suggested that having it be const is an artefact of using non-C++ types, and I can see that, but I vacillated when writing the commit message for unconstifying it.
<RAOF> alf_: cf: https://code.launchpad.net/~raof/mir/check-for-surfaceless/+merge/198510
<duflu> RAOF: I'm happy to keep const. Just expect it to be non-const if the implementation changes
<RAOF> duflu: Ok then. I think conceptually const makes more sense, and it's an implementation detail if it isn't.
<duflu> Yeah const is always a maintenance risk in that way
<duflu> There's a reasonable argument for not having const in the language :)
<duflu> Although I think having const with clearly defined policy is better
<anpok> it is always simpler to explain the usage of const_cast / mutable if it is to fulfill a const in the problem domain, than because of a possible trivial implementation
<anpok> duflu: any suggestions on the pixel format encoding? should I only take RGB based formats into account now..
<anpok> or look for something that also adresses yuv ..
<duflu> anpok: I suggest sticking with what you have (don't change MirPixelFormat for now). It's nice and forward compatible to just define query functions like you have
<duflu> Fitting all the info we need into 32-bits is quite difficult actually
<anpok> SDL2 does something similar .. but they dont encode shift values directly
<duflu> anpok: The panacea is an accurate set of instructions for interpreting/encoding any pixel :)
<duflu> Without switch/case
<RAOF> We should probably look at gallium's format descriptor infrastructure.
<RAOF> anpok: That's what your merge proposal triggered for me.
<anpok> the one in gbm.h
<anpok> ?
<duflu> I think fourcc is kind of OK, but fails to resolve the bug really. You have to switch on all known fourcc's. It's ugly
<RAOF> anpok: No... let me hunt it down.
<duflu> Hmm SDL_pixels.h is interesting
<RAOF> https://github.com/RAOF/mesa/tree/egl-platform-mir/src/gallium/auxiliary/util - u_format.{c,h,csv}
<RAOF> A bunch of that is driver-implementation-specific, but the general gist could be useful.
<anpok> hm there are also compressed formats
<anpok> hm those would not be needed ...
<RAOF> Right. There are a huge number of formats there, most of which we wouldn't need.
<RAOF> Also, we (probably?) don't need all that description; block width and height, channel swizzle, layouts that aren't âplainâ
<anpok> that reminds me of https://github.com/laanwj/etna_viv/blob/master/doc/hardware.md
<anpok> if I am not mistaken the device can render to super tiled frame buffers.. and the optional composition gpu can do scanouts on those
<anpok> that might be relevant again with hwc on android
<anpok> different topic in some code parts DisplayConfigurationPolicy is named "initial" conf.. why only initial?
<anpok> i initially assumed that.. if changes to the available displays happen the policy would querried again
<RAOF> anpok: No; that's only used for initial configuration, and something else is assumed to handle configuration on hotplug events.
 * RAOF EODs
 * duflu too. Overdue for cooking a healthy meal
<mlankhorst> RAOF: grrr! fix your trailing whitespace
<mlankhorst> RAOF: anway xorg-server for saucy-proposed, pixman and libdrm for all supported releases in the release queue:)
<anpok> i am a bit concerned about the conversion operator usage
<anpok> in EGLDisplayHandle and similar... not widely used. it seems odd to have conversion operators for typedefs of void*
<kgunn> bregma: did RAOF get you the mesa you needed for nested mir on desktop ?
<kgunn> never saw a follow up
<anpok> kgunn: iirc nested mir on desktop also needs a small change in mesa platform which is currently in review
<kgunn> anpok: exactly, this is what i was asking about
<kgunn> anpok: i looked at raof's github but didn't see any reference
<kgunn> but maybe i don't know where to look exactly ?
<kgunn> can you share if you do ?
<anpok> sorry my wording was ambigiuous ..
<anpok> mir/mesa needed another change
<anpok> there is some utility class that needs surfaceless context, but creates a pbuffer surface which is not supported by mesa.
<anpok> https://code.launchpad.net/~raof/mir/check-for-surfaceless/+merge/198510 thats the change
<xnox> Does mir at all can export / has api to query detected screen resolution and the DPI setting?
<anpok> you can querry that through the mir client api - take a look at demo_client_display_config.c in the examples folder
<kdub> yay https://lists.ubuntu.com/archives/ubuntu-devel/2013-December/037904.html
<xnox_> =)
<kdub> i was just looking up who to +1... i'll see  if  i can drop my amateur cmake cross compile file from mir
<kgunn> kdub: so did you say if you put in some logic to "ignore" the second "on"...display turns on but then hangs ?
<kdub> kgunn, right
<kdub> like, the problem is
<kgunn> kdub: damn...that's just weird...so not only does powerd send it...it meant to send it :)
<kdub> right
<kdub> i'm still poking around powerd trying to understand
<kdub> ricmm, ping
<greyback> kdub: anything I could do to help?
<kdub> greyback, don't know of anything at the moment
<greyback> kdub: ok
<kdub> unity-mir's role seems to be pretty straightforward
 * mterry pokes ricmm about libhybris
<kdub> mterry, what about hybris?
<mterry> kdub, that libhybris fix that ricmm identified during the sprint, to allow two different users (root and phablet) to access hw on maguro
<mterry> It's the last fix needed for nested mode to land
<kdub> ah, okay
<kdub> mterry, is screen on/off with nested working okay? i have some concerns about that
<kdub> eh, actually, i'd expect it to work
<kdub> its just funny that we make the power request to a nested client who asks the host server
<kdub> too many hops
<mterry> kdub, no, UCS is actually the one that will host the dbus interface
<mterry> kdub, the unity-mir code to do it is still there, but will gracefully fail once UCS already owns it
<mterry> kdub, and then we can remove that codee
<kdub> mterry, great, sounds good
<kgunn> kdub: so i was just trying your instructions...i'm on N4 with todays devel-proposed image...after i install mir-test-tools
<kgunn> the only mir test i see is mir_stress
<kgunn> any ideas?
<kgunn> https://docs.google.com/a/canonical.com/document/d/1oxXDxehRQ35rYRwkuBCy1ZNmB_IBpg5UhE3jvNHEk_0/edit
 * kdub looks
<kdub> they were added in rev 1256
<kdub> and it looks like 1248 was the last merge to lp:mir
<kdub> kgunn^^
<kgunn> kdub: heh
<kgunn> fell victim
#ubuntu-mir 2013-12-17
<RAOF> You know what I *really* want to do while dog tired? Start writing an X window manager.
<RAOF> That'll be awesome.
<RAOF> duflu: Oh, is client initiated window resize implemented?
<duflu> RAOF: No. That depended on the attribute thing, which half the team disliked
<RAOF> Ah, ok. So worrying about how to handle resize in xmir-rootless is somewhat premature :)
<duflu> RAOF: There's still time. Technically we haven't released 0.1.3 which is the first release with MirResizeEvent
<RAOF> Well, it doesn't particularly matter to me if it's not available in 0.1.3
<duflu> RAOF: I mean I told Gerry the resize event design might change in 0.1.3/0.1.4. And having not released 0.1.3 yet we have lots of freedom still
<RAOF> Ah, cool.
<RAOF> Well, I don't particularly care about the events as such; I can pull that data from the buffer.
<RAOF> I care about the ability to resize from the client, though.
<anpok_> is that something the shell still could deny?
<RAOF> Yes
<duflu> ... in theory. Not implemented yet because nothing beyond the shell /can/ resize surfaces yet :)
<duflu> It's just a virtual function the shell could override I think
<RAOF> Well, ye.
<duflu> Hmm, didn't expect that. I just noticed clients only get input events iff the gesture started inside the client surface
<duflu> I guess that's correct
<duflu> Hmm, and only if it starts inside the client's creation size. That's wrong.
<duflu> alf_: Shall I merge the fix manually?
<alf_> duflu: I was about to do it (almost done)
<duflu> alf_: OK, thanks. I shall vanish then
<alf_> duflu: Enjoy!
<alan_g> alf_: does that resolve the remaining CI issues?
<alf_> alan_g: duflu's fix?
<alan_g> alf_: I'm still catching up - it looked as though it was related to your fix failing
<alf_> alan_g: No, duflu's MP updates our cross compilation tools for a change in upstream packaging
<alan_g> alf_: OK, I'd noticed that you MP had failed for "E: Couldn't find these debs: android-platform-headers" and wondered if we were nearly there yet.
<alan_g> *your
<ogra_> alan_g, alf_, the package was renamed (upstream) to "android-headers"
<ogra_> (update your build deps)
<alan_g> ogra_: ogra_ that's what alf_ is merging (above)
<ogra_> oh
<alf_> ogra_: alan_g: Actually the fix was to remove the dependency completely from our cross tools, since it turned out we didn't actually need it
<alan_g> alf_: Yeah, that's the best sort of "update". ;)
<ogra_> :)
<alf_> alan_g: @test-framework-wait-for-server-startup, it resolves some of our CI problems (and improves our pass rate), but it seems there are still other issues not addressed by the MP. I would like to get this MP merged (even manually if needed), so that when we get failure we at least know it's some other problem
<alan_g> alf_: I'm happy with that approach. (I guess you want me to change my vote?)
<alf_> alan_g: Only if you are happy with the handling of the shutdown tests
<alan_g> alf_: that's what I'm looking at. ;)
<alf_> alan_g: http://paste.ubuntu.com/6588244/ is a minimal example to exercise the valgrind behavior which was worked around in the last commit
<alf_> alan_g: wait_for_server_process_to_finish() ?
<alan_g> alf_: terminate_server_and_wait_for_shutdown()?
<alf_> alan_g: so, shutdown_server_process => terminate_server_and_wait_for_shutdown , wait_for_shutdown_server_process => wait_for_server_shutdown ?
<alf_> alan_g: anyway, as you said, this is for later...
<alan_g> alf_: I can't think of anything better. But I don't quite feel convinced. :(
<tvoss> greyback, ping
<greyback> tvoss: pong
<xnox> hello again.
<xnox> what's equivalent to figuring out screen size / resolution under mir?
<xnox> are there mir API docs?
<RAOF> xnox: There are; http://unity.ubuntu.com/mir/
<xnox> RAOF: excellent. and are there any command-line utility that exposes/prints MirDisplayInfo width & height?
<RAOF> xnox: http://unity.ubuntu.com/mir/mir__client__library_8h.html is the client API
<RAOF> xnox: mir_demo_client_display_config is a demo client that'll do that.
<alan_g> alf_: @http://paste.ubuntu.com/6588244/ - the lack of a join() is likely a licence for inconsistent behaviour.
<nic-doffay> Hey everyone, I'm looking to get an FPS count from mir, can anyone give me any tips?
<alan_g> nic-doffay: some of the demo apps outout an fps count to the console. Is that what you need?
<nic-doffay> alan_g, I'd like to output the frames somewhere in unity8.
<alan_g> nic-doffay: I'm not sure where unity8 calls mir_surface_swap_buffers() (I assume it is in platform-api) - but those are the calls you'd need to count.
<anpok_> and then maybe extrapolating the frame delay would be also of interest
<nic-doffay> alan_g, should I just grep that call?
<alan_g> nic-doffay: I guess you could also detect the unity8 client server-side and intercept the calls there. C.f. http://bazaar.launchpad.net/~mir-team/unity-mir/trunk/view/head:/src/unity-mir/surfacefactory.cpp (although that just identifies the unity8 surface, it doesn't intercept the call you want to count)
<nic-doffay> alan_g, I'll the first approach I think.
<alf_> alan_g: sure in a normal situation, but it shouldn't matter in the case since the process aborts (join() wouldn't be called anyway in this scenario)
<alan_g> alf_: rephrasing: I'm not sure how well the C++ memory model copes with posix signals - there could well be dragons around here.
<alf_> alan_g: ok
<nic-doffay> greyback, ^
<nic-doffay> Saviq, is qt client FPS enough for our purposes?
<Saviq> nic-doffay, probably, yeah
<nic-doffay> Saviq, could this just be done from Qt?
<Saviq> nic-doffay, yeah of course
<Saviq> nic-doffay, only place it can be done, really, if we want it cross-display-server
<nic-doffay> Saviq, I mean look for something in the scenegraph. I was pointed towards QML_RENDERER_TIMING
<Saviq> nic-doffay, yes
<xnox> So i've pushed mir_demo_client_display_config to the phone, yet all it says "Can't get connection" whilst unity8 is running.
<xnox> how can I get display size from the running unity8/mir ?
<anpok_> xnox: how do you start it?
<alf_> xnox: You need to connect to the server that unity8 connects to (or to the system compositor)
<xnox> anpok_: ./mir_demo_client_display_config from adb shell.
<xnox> alf_: how do I do that?
<xnox> hm, is mir socket a well-known value?
<alf_> xnox: you can pass -f
<kgunn> xnox: also...can you retarget your mp from lp:mir to lp:mir/devel ?
<xnox> kgunn: why is lp:mir the default merge proposal target then on the lp-project?
<xnox> kgunn: how would I know that you are using custom series for development....?
<xnox> kgunn: shouldn't there instead be stable series and lp:mir the devel one?
<alf_> xnox: @mir socket, are you running as root?
<alf_> xnox: if os try as phablet
<xnox> kgunn: I followed http://unity.ubuntu.com/mir/md__h_a_c_k_i_n_g.html
<xnox> alf_: fails with both phablet & sudo user. let me try -f
<alf_> xnox: -f requires the path
<xnox> ..
<alf_> xnox: try /var/run/user/[userid]/mir_socket
<xnox> i am running android emulator, and i want to find out the current screen resolution & DPI.
<xnox> /var/run is  a symlink to /run/ ;-)
<xnox> using mir_socket as root or as phablet user still gives me Can't get connection.
<alf_> xnox: I don't know if you need special permissions (e.g. given by starting to upstart) to be able to connect to unity8
<alf_> xnox: ...given by starting through upstart...
<xnox> ... i have root & have apparmor disabled.
<xnox> is only one client at the time supported?
<alf_> xnox: not that I know of
<xnox> alf_: I installed fbset and it gets the the framebuffer resolution and i'm happy with that for now =)
<alf_> xnox: ok
<xnox> alf_: but i would want to get the screen size & dpi from mir/unity, such that i know what mir/unity8 thinks it is.
<xnox> either by connecting to unity8's mir_socket or somehow talking to unity8 asking it to export that information.
<xnox> e.g. in the unity8 logs I see "creating surface at (0, 0) with size (480, 800) with title 'Qml Phone Shell'"
<greyback> xnox: client will be denied connection unless it called with "--desktop_file_hint=dialer-app"
<xnox> but i really do not want to get that via API of a sorts, instead of parsing logs which might not be there.
<xnox> greyback: (a) that's a .desktop file lauching hack of the qmlscene apps (b) i'm launching mir_demo_client_display_config from command-line (c) i'm not use upstart-app-launch (d) mir_demo_client_display_config obviously does not have such a flag
<xnox> greyback: so how do I hint / get the connection to the running instance of unity8/mir?
<greyback> xnox: for (a) it's for /any/ app that connects to mir/unity8, not just qmlscene apps
<xnox> hm, ok.
<xnox> greyback: i don't actually want to run anything =/ only print / retrieve resolution & dpi. Maybe mir_demo_client_display_config is too much for that task?
<greyback> xnox: flag is not actually for the client application, it should be ignored by the client. unity8 is the thing that cares about that flag
<greyback> xnox: unity8 does have a basic dbus interface to get screen size right now (not dpi though)
<xnox> greyback: ah, that's better =) let me check it out.
<greyback> xnox: check out com.canonical.Unity.Screen
<xnox> greyback: excellent!
<xnox> greyback: thanks a lot =)
<greyback> xnox: oh no, it was actually removed
<greyback> xnox: it could be restored. Why do you need it?
<xnox> greyback: at the moment autopilot hard-codes the screen resolution based on device codenames, emulator can run with any resolution / dpi therefore we actually need to query it at runtime to figure out the right resolution/dpi and it must match what mir/unity8 will think it is.
<xnox> greyback: i'm actually not sure if unity8/mir is running when autopilot starts up, if it doesn't we can surely start mir/unity8 just to query that.
<xnox> greyback: here is the current "resolution" detection http://bazaar.launchpad.net/~autopilot/autopilot/trunk/view/head:/autopilot/display/_upa.py
<alf_> kgunn: alan_g|lunch: the latest errors at https://jenkins.qa.ubuntu.com/job/mir-mediumtests-runner-mako/100/console , especially the failure of Process.a_successful_exit_function_succeeds, looks very suspicious. It makes me think that there is a problem (race?) in our test process handling code...
<xnox> greyback: autopilot simulates the touch events based on resolution hence it needs to know the geometry.
<alf_> kgunn: alan_g|lunch: that is causing all the remaining issues we are seeing
<greyback> xnox: gotcha. What solution would you prefer? dbus interface? Or a simple Mir client that can read the display info itself?
<xnox> greyback: not sure. i think a simple mir client would be useful beyond just autopilot, and easy enough to itegrate.
<xnox> greyback: i'll ping thoami to see if he'll prefer a dbus api as well / in addition / or just that.
<greyback> xnox: ok
<xnox> greyback: e.g. at the moment autopilot cannot change the resolution at runtime, but clearly unity8/mir can and so can the android emulator.
<xnox> greyback: in the perfect world that mir client would query running instance if there is one, otherwise start-dummy-mir and query that and exit/clean-up. such that one can query "current or the probably would be" resolution.
<greyback> alf_ any ideas on how that could be done?
<alf_> greyback: xnox: mir clients/servers don't have any knowledge of existing servers, that should be handled externally in a script tailored for the specific scenario (e.g., check if unity8 is running and connect a client to its socket, otherwise start a mini server)
<xnox> alf_: that should be ok. so it's just the mir client that needs to connect to an  existing server and query info from it.
<kgunn> xnox: fair....i'll followup to change that
<alan_g> alf_: It is possible. I remember we had some problems in the shutdown code that I never really dug into.
<racarr> bregma: https://code.launchpad.net/~robertcarr/mir/nested-internal-egl-on-mesa-with-caveat/+merge/199329
<racarr> this should work for you with no multimonitor
<racarr> if you have a second monitor you probably needtoliterally unplug it
<bregma> racarr, sweet, multimonitor is not (yet) a requirement
<racarr> it shouldbe fixed sooner than later anyway just some sort of bug
<bregma> I'll play with it today, when my test rig gets freed up again
<racarr> I haven't tested unity8/usc yet...
<racarr> ok great!lemme know
<racarr> all the appropriate demos work now so it should work but I reinstalled my machine and don't feel like rebuilding the entire unity8stack at this exaaaaccct
<racarr> moment
<racarr> but will soon haha
<bregma> racarr, that seemed to do the trick: now U8 crashes trying to connect to the phone sensors (because the desktop is not a phone and does not have sensors) ... which means your fix worked, all you need to do is get it committed
<bregma> now the question is, can Mir be tuned so it doesn't try to connect to the Android accelerometer when it's not running on an Android kernel, or at least not crash?
<bregma> at least this problem is not in Mir itself, so not your problem
<racarr> bregma: problem is in platform APII guess
<racarr> need stub sensors build on desktop?
<bregma> racarr, my current problem is in libqubuntumirserver.so, there are a lot of confusingly named libraries involved, I think every combination of 'ubuntu' 'mir' and 'server' is used by every project involved in the Unity8 stack
<racarr> bregma: That'sbecause that's the qt platform integration plugin
<bregma> yep
<racarr> there is qtubuntumirserver (for unity8) and qubuntumirclient/qubuntusurfaceflinger (just called qubuntu)
<racarr> but they get sensors from platform API
<racarr> so it should be fixed at that level,
<tvoss> bregma, can you file a bug against the platform api to fallback gracefully if sensors are not available?
<bregma> tvoss, should it be the platform_api or the qtubuntu_sensors that falls back gracefully?
<tvoss> bregma, hmmm, I think it really should be platform api
<bregma> OK, I'll file the bug against it
<tvoss> bregma, thanks
#ubuntu-mir 2013-12-18
<kdub> another fun day of powerd for me... see yall tommorrow
<duflu> Later kdub
<RAOF> racarr: Oh, Kevin mentioned that you were fighting with nested?
<duflu> RAOF: Silly question: In the nested world, a greeter is a shell too, right?
<RAOF> duflu: There will certainly be a greeter shell, yes.
<duflu> Good. Just checking I understood that much
<RAOF> Whether or not the greeter is built into that shell or is a separate client is neither here nor there, really.
<duflu> RAOF: Interesting point. If the greeter is just a client then the efforts to support translucent nested servers won't be used (anpok!)
<RAOF> No, they will.
<RAOF> There will still be a nested shell that the greeter runs in.
<duflu> Sounds weird. We'd have to have a good reason for that...
<RAOF> The greeter needs to have a bit of session logic, as it folds in multiple processes.
<RAOF> See the current greeter - the indicators need to be folded in, and they can pop up windows, etc.
<duflu> So put another way... in the nested case you can choose which server a client connects to. Why wouldn't the greeter just be a client to the system compositor?
<duflu> Oh, right, popups in greeters. OK
<RAOF> Because then everything it spawns will be clients of the system compositor, and we would need nontrivial window management in the system compositor.
<RAOF> Right, you've got it :)
<duflu> You could just say don't make greeters with windows :)
<duflu> I think Ubuntu is unique in that area
<RAOF> I'm pretty sure we'll continue to want non-trivial greeters; the ability to enable wifi before logging in remotely requires some windowish.
<duflu> Wow, framerate (thoughput) is indeed higher when nesting. What's that all about?!
<duflu> Perhaps nesting allows the extra N-buffering we don't really do properly with a single server?
<RAOF> Perhaps.
<anpok> hmm
<anpok> rfkill block / unblock seems to fix the issue
<anpok> RAOF: do you experience strange behavior on the ac7260 wifi chip
<RAOF> anpok: I don't have one of those; I've got Qualcomm Atheros AR9462
<duflu> That's odd. Intel wifi is usually the best. And ac7260 I think is the newest ... http://ark.intel.com/products/75439/Intel-Dual-Band-Wireless-AC-7260
<anpok> it works very well for like a day usually
<anpok> but then connection attempts seem to take ages.. lots of packet loss
<anpok> maybe caused by some upgrade.. I had no issue in london
<RAOF> I've seen complaints that Intel wifi has been going backwards, quality-wise.
<anpok> and the time before
<duflu> Hmm, and now nested is slower, which sounds more sane
<anpok> duflu: I hoped that RAOF branch gets merged sooner.. what do you mean by resubmit? wait untill checks-for-urfaceless is in devel?
<duflu> anpok: No, you can resubmit now and RAOF's diff will be hidden if it's listed as a prereq of yours
<duflu> Just fill in the Prerequisite Branch field
<duflu> anpok: Thanks. That's smaller :)
<anpok> yeah.. I didnt expect such a feature would exist
<anpok> regarding tests.. I think I need to do some more behavior changes
<anpok> so far it only allows selecting pixel formats
<anpok> which is ignored by offscreen and android  .. and it would fail for mesa
<anpok> at least now it would fail
<anpok> hm i think inside gbm.. if somebody tries to create an ARGB buffer with the scan out flag it would fail
<anpok> shall I filter such an attempt.. and pick a similar pixel format without alpha - or throw?
<anpok> ah ok display class in mesa also does not take that setting into account
<duflu> anpok: I've noticed it's very confusing trying to tell the difference between nested and non-nested servers on screen. Could you by any chance add an option to select the glClear background colour for each? :)
<duflu> ... I noticed after realizing I was moving and resizing the nested server and _not_ the client within it :P
<anpok> yeah
<anpok> we could also draw borders
<anpok> clear is simpler
<duflu> anpok: The glClear call already exists. Just change glClearColor
<duflu> Although when I changed the default colour, that upset Unity8 people
<anpok> oh there is clear call in mesa platform
<anpok> i thought only in the example shell
<anpok> would we see garbage on screen otherwise - if there was no initial clear&swap?
<duflu> anpok: src/server/compositor/gl_renderer.cpp:    glClear(GL_COLOR_BUFFER_BIT);
<alan_g> CI and Autolanding are failing android-trusty-i386 with "W: GPG error: http://ppa.launchpad.net trusty Release" - I've put a general query on #ubuntu-ci-eng, but no-one I know is awake there.
<alf_> kgunn: alan_g: https://code.launchpad.net/~afrantzis/mir/fix-mako-ci-use-steady-clock/+merge/199469
<alan_g> alf_: looking...
<alf_> alan_g: resubmitted against mir-devel: https://code.launchpad.net/~afrantzis/mir/fix-mako-ci-use-steady-clock/+merge/199472
<alan_g> alf_: can you try a cross-build (including running tools/setup-partial-armhf-chroot.sh)? Do you see something like "/usr/arm-linux-gnueabihf/include/bits/byteswap.h:74:17: error: â__uint64_tâ does not name a type"?
<alf_> alan_g: trying
<kgunn> alan_g: alf_ sorry...was in with ui guys...
 * kgunn waits for cross build results
<alan_g> kgunn: ?
<kgunn> alan_g: just checking back in...
<kgunn> seems the 32bit stuff was a red herring
<alf_> alan_g: problem confirmed here too, I will try again after an apt-get update
<alan_g> alf_: thanks
<alf_> alan_g: FWIW, no change after ensuring I have an up-to-date system
<alan_g> alf_: agreed. Something changed upstream - not yet tracked down what. (I hope I've an old copy of the relevant files on my laptop...)
<alf_> kgunn: @fix-mako-ci-use-steady-clock, it's blocked by cross-compilation issues so we might want to merge manually to get it in ASAP
<kgunn> alf_: please do....
<alf_> kgunn: cross-compilation issues == the ones Alan is investigating
<kgunn> alf_: yes...i realized it right after i saw it fail & tried to approve again :P
<alan_g> Hmm, this must be related - a load of "#  if __GLIBC_HAVE_LONG_LONG" conditions have become unconditional in the gnu headers.
#ubuntu-mir 2013-12-19
<RAOF> duflu: Do you have any suggestions for shorter test names?
<RAOF> They're that long because I think they need to be that long to describe what they're testing :)
<duflu> RAOF: Not sure. I'm happy to ignore it if the other minor issues are fixed
<RAOF> duflu: They are now.
<RAOF> (I think)
<RAOF> Or, at least, have been thrashed out here (const-ness of make_current, etc)
<duflu> Woo, Jenkins is landing things!
<RAOF> Oh, wow. Do we really put the { on the next line in *assignments*? Yes, yes we do.
<RAOF> That's really silly.
<alan_g> anpok_: thanks for fixing cross-compilation!
<anpok_> no problem
<RAOF> duflu: Those names any better? :/
<duflu> RAOF: I will assume yes. They don't stand out as obviously crazy any more. So I closed my eyes and hit Approve
<alan_g> duflu: why don't you want to publish the demo_standalone examples?
<duflu> alan_g: Because they contain very bad practices of mixing client and server code in undesirable ways
<duflu> Hence bad examples
<anpok_> why do we have those examples then?
<anpok_> if the source is there, people will see and copy from it
<duflu> anpok_: Because they pre-date having a rich and functional client+server architecture
<alan_g> duflu: http://unity.ubuntu.com/mir/render_surfaces-example.html
<duflu> They were necessary to test things earlier in Mir's life
<duflu> alan_g: I'm not sure that's a helpful example. Though it does make me think we need better demo-server examples/docs
<alan_g> There's nothing wrong with using the server APIs to put stuff on the screen. If we want to set a better example we should improve the code, not hide the executables.
<duflu> alan_g: Functionality used by render_surfaces such as setting rotation and using a buffer initializer and examples of things I expect to be eliminated eventually. We shouldn't encourage people to copy that
<duflu> Although, if we all agree demos may be removed from the mir-demos package at any time, then I guess it doesn't matter what goes in it
<alan_g> duflu: it's inconsistent to have the code and publish it to the website but not put it in the package.
<duflu> alan_g: Well doxygen's automagical publishing is something less controllable than packaging :)
<alan_g> duflu: I do agree that the code in several examples is less than exemplary.
<alan_g> duflu: only because you know the incantations for one and not the other. ;)
<duflu> alan_g: True
<duflu> And now I have to go sit in traffic. Hurray.
<alan_g> Have a good evening!
<alan_g> RAOF: you about?
<alan_g> kgunn: you've just approved "build-options-for-tests"? Have you co-ordinated putting the changed options into jenkins?
<kgunn> uh-oh, alan_g maybe i misunderstood
<kgunn> alan_g: got it...i missed alf's comment above duflu's
<kgunn> makes sense now
<kgunn> thanks for the catch
<alan_g> np
<alan_g> BTW we're able to land stuff today
<kgunn> alan_g: it does seem like we are now passing ci reliably
<kgunn> yep
<kgunn> alan_g: so...thinking we might be able to promote lp:mir/dev to lp:mir....can i ask for some advice
<kgunn> seems our deb change is back about 2 revs
<kgunn> http://bazaar.launchpad.net/~mir-team/mir/development-branch/revision/1292
<kgunn> should i revert and then reapply ?
<kgunn> or just bump again ?
<kgunn> thots
 * kgunn knows debian has black magic involved sometimes
<alan_g> kgunn: it is about time. Anything outstanding you'd like to land?
<kgunn> let me skim again
 * alan_g leaves debian foo to others. Is there any reason to do either?
<kgunn> alan_g: ok...there's 2 branches up for merging...may as well wait for those to get in
<alan_g> kgunn: one just failed
<kgunn> besides that..there's "ping" and then the "build opts for test" (that requires coord)
<kgunn> dang it
<kgunn> alan_g: sorry...which one are you referring to that just failed ?
<alan_g> kgunn: https://code.launchpad.net/~raof/mir/check-for-surfaceless/+merge/198510
 * alan_g feels guilty as he just wrote the test that failed: DemoInProcessServer.client_can_connect
<alan_g> kgunn: Looks like we just landed a flaky test.
<kgunn> alan_g: hopefully that'll make it simple to fix :)
<kgunn> looking for the bright side
<alan_g> kgunn: There's some useful looking test output. But so far I can't reproduce (but only run it n0000 times)
<alan_g> \o/ running under valgrind I can reproduce after on iteration 20521
<alan_g> s/after //
<kgunn> goodness
<kgunn> how much luck must it take to have hit that
<alan_g> kgunn: I think it is an unforseen interaction between alf_'s work to sync across processes and my test that runs in a single process.
<anpok> hm I have a crash in mesa
<anpok> in platform_drm.c
<alan_g> kgunn: want a quick and dirty fix to unblock things? (With a cleanup fix a few hours later)
<kgunn> alan_g: nah...go for the cleanup fix if its truly just few hours...
<kgunn> alan_g: i'll work my afternoon to queue up the merge to lp:mir once it lands
<alan_g> kgunn: It truly is - it just means we need a new class in the testing configuration hierarchy. (I've a working POC that extends the hierarchy to disable alf_'s sync stuff)
<kgunn> alan_g|tea: sounds good...i'd rather just do it right and avoid sinking your time into band-aids
<anpok> need a break..
<anpok> is the mesa inside the trusty archives (10.0.0-1ubuntu4) working for you?
<alan_g> I assume that's what I'm running.
<alan_g> kgunn: as promised (less than 2 hours later) - https://code.launchpad.net/~alan-griffiths/mir/fix-1262754/+merge/199688
<alan_g> There must be a better way to represent moved code than large swatches of red and green
<kgunn> alan_g: thank you
<kgunn> ...i quite like the red/green representation
<alan_g> But moving code doesn't entail the same risks as deleting old and writing new
<kgunn> mmm true
 * alan_g wishes once more for a VCS that understands refactoring
<anpok> alan_g: there is a vcs project that does that ..it parses the source code and is able to detect certain patterns, like renaming a method, moving it up or down in the inheritance hierachy
<anpok> or detects similar fixes on different levels of the hierachy and presents logical merge conflicts..
<anpok> cannot remember its name
<alan_g> anpok: once upon a time I was told bzr would do that.
<anpok> stories with a happy ending that way
<alan_g> if I rename something and someone else adds a use of it the VCS should sort be able to it out.
<anpok> ok it was my error my self built mesa version was interfering ..
<anpok> now with current mesa from trusty i get an unsuported platform warning in the nested case
<fishscene> How are Mir milestones reached? Are they reached by tasks accomplished? or is it by date/time? Relevant link: https://launchpad.net/mirÂ 
<kgunn> fishscene: you might have noticed we're working on a dev branch which gets promoted to our "sacred trunk" which feeds the archive/touch images...
<kgunn> we're promoting approximately fortnightly
<kgunn> although...every now and then
<kgunn> like...the last 2 weeks :)
<kgunn> we've been wrestling with our ci infrastructure (our automated testing)
<kgunn> which we need to be fully passing to promote
<kgunn> at any rate that's the rough correlation...so schedule based more than task based
<kgunn> driven mostly by the fact we don't want the dev to get too diverged from whats in archive
<kgunn> hth
<fishscene> kgunn: Gotchya. Thanks for taking the time to fill me in. :)
#ubuntu-mir 2013-12-20
<ricmm> duflu: ping
<duflu> ricmm: pong
<ricmm> duflu: hey daniel, msh::Surface::resize() is meant to do something?
<ricmm> or is it just stubbed
<duflu> ricmm: It does work, providing...
<duflu> (1) Desktop; you have the latest Mesa
<duflu> (2) You don't expect events to be sent about it (they're in Mir 0.1.3)
<duflu> Functionally it should work in Mir 0.1.2
<duflu> ricmm: Also (3) In a nested server, I'm not sure. Nesting still has too many bugs to test it properly
<ricmm> hmm
<ricmm> tested on phone?
<duflu> ricmm: Yes, for quite some time now
<duflu> ricmm: You can pinch/zoom with demo_shell
<ricmm> ah great
<duflu> ricmm: I sent a "feature complete" email to Gerry. I'mm find it for you
<duflu> I'll find it...
<ricmm> oh nvm this surface was drawing weirdly
<ricmm> led me to think it was in a different placement
<ricmm> need to move it to 0,0 too
<duflu> ricmm: Oh, yes, we don't have support for localized input coordinates yet
<duflu> ricmm: 3 fingers to pinch/zoom in demo_shell. It's not a nice perfect 2-fingers because we're reserving 1-2 finger gestures for apps
<duflu> Or Alt+middlebuttondrag on desktop
<ricmm> ah perfect now :)
<duflu> ricmm: Fun, right?
<ricmm> well I wouldnt go that far
<ricmm> but at least gallery seems to be correctly placed when it changes from maximized to fullscreen
<ricmm> ;)
<duflu> ricmm: That reminds me... we do have mir_surface_set_state(s, mir_surface_state_maximized), but it's not wired up to *do* anything with resizing. At last discussion the rest of mir-team thought it was appropriate to make that the shell's responsibility. I'm still not sure
<ricmm> thats what im doing right now
<ricmm> state_fullscreen triggers a set of actions
<duflu> Good, I think
<ricmm> that end up in a move/resize operation if policy allows
<ricmm> well, that was the original intention of that message passing
<ricmm> just that back then there was no resize support
<duflu> ricmm: In that case beware of: https://bugs.launchpad.net/mir/+bug/1261647
<ubot5> Ubuntu bug 1261647 in Mir "Clients don't receive motion events inside their own rectangle if they have been moved/resized" [High,Triaged]
<ricmm> oh nice :)
<ricmm> lol
<duflu> ricmm: Don't shoot the messenger. I just found it this week
<ricmm> thats probably very obvious in server_shell
<ricmm> not as bad here as the original geometry only changes by about 60 pixels on the top
<ricmm> which is usually useless
<ricmm> but yea, big bug :)
<anpok_> ok strange.. the mesa issues from yesterday are just gone
<duflu> anpok_: Happy Friday then
<anpok_> hi
<alan_g> duflu: in the past we've merged development-branch directly to lp:mir - any reason for using lp:~vanvugt/mir/version-0.1.3 this time?
<duflu> alan_g: We stopped doing that a few releases ago
<duflu> alan_g: The head of dev is no longer the 0.1.3 release, that's why. See the tags :)
<alan_g> I guess this is the first time I'm awake since then.
<duflu> If the merge happens before the upstream releases, then certainly just merge from dev. But that's not how it's happened lately. And ideally not how it should
<anpok_> hm is mir_image.h a nice drawing of the space station?
<alan_g> anpok_: I had to be told what it is
 * alan_g wonders why jenkins hasn't reviewed ~andreas-pokorny/mir/allow-transparent-server-buffers
<RAOF> alan_g: Oh, you wanted me yesterday? I happen to be around now.
<alan_g> RAOF: yeah, I wondered if you knew anything about alf_'s MP fiddling with linkage
<alan_g> https://code.launchpad.net/~afrantzis/mir/mir-client-ensure-global-symbol-resolution/+merge/196110
<duflu> alan_g: I believe Jenkins checks if the author is in some certain group (engineering teams or an employee) and only kicks in if so
<duflu> anpok_: Yes it is a nice drawing (the artist is on mir-team I think) :)
<alan_g> duflu: but it reviewed ~andreas-pokorny/mir/fix-missing-system-path
 * duflu shrugs
<anpok_> but only after somebody added jenkins to it
<anpok_> i think kevin did
<anpok_> before that it ignored the branch
<duflu> The CI elves will know
<anpok_> duflu: since I am all into transparency and glasnost. I thought about adding some non-255 alpha values to it
<duflu> Indeed Glasnost is about transparency... (?)  http://en.wikipedia.org/wiki/Glasnost
 * anpok_ nods 
<anpok_> at least some weirdness of yesterday still exists
<duflu> Sorry, have to run. Expecting company any second...
<anpok_> see you .. next year?
<duflu> anpok_: No, Monday. I'm around almost every day
<anpok_> is the order of supported buffer formats passed to the client random?
<RAOF> I don't think we have any semantics defined there.
<RAOF> alan_g: Commented on that MP.
<alan_g> RAOF: thanks for looking at that MP - I'm still unclear as to whether the right problem is being solved
<RAOF> At a high level the right problem is being solved - libEGL.so.1 can't resolve Mir symbols when libmir* are loaded by something else with RTLD_LOCAL.
<RAOF> I think the *most* correct solution would be to have something that's actually linked with libmirclient and libmirserver, but that's also the least trivial solution.
<RAOF> alan_g: Actually, now that you mention it - why isn't EGL linked against libmirclient and libmirserver? Is it only because we suck at libmirserver ABI?
<alan_g> RAOF: I don't know. I assume it is so that it runs on the mir-less stack
<anpok_> because you dont have to update libEGL for each mirclient/server update?
<alan_g> RAOF: I assume only a small part of the API is used? We could write a stable wrapper
 * alan_g goes to talk to the CI elves
<alan_g> anpok_: did you track down the problem with nesting render_surfaces on android?
<anpok_> alan_g: not yet i will do that after lunch got.. trying to reproduce the weirdness i had this morning with mesa.. but it works now..
<alan_g> ok. It occurred to me that I'd only used it on N4. N10 might be different. (Haven't tried yet)
<alan_g> anpok_: Over on #ubuntu-ci-eng (where the CI elves hang out) fginther has promised to fix it so that Jenkins reviews your MPs. (He's a useful chap while our timezones meet.)
<kgunn> alan_g: distracted helping out with some ui testing this morning...but later was going to do the promotion of dev branch....is everything ok?
<kgunn> or any mp's that need to be waited on?
<alan_g> kgunn: all good.
<anpok_> that weirdness from this morning on mesa was that in some occasions the render_surfaces example was unable to find a matching egl config
<anpok_> error was between chair and keyboard..
<tvoss|lunch> anpok_, lol
#ubuntu-mir 2014-12-15
<attente_> dandrader: hi. is clipboard support only available through u8 and not mir?
<dandrader> attente_, yes
<attente_> dandrader: that means toolkit support for clipboard then depends on u8, isn't that a problem?
<dandrader> attente_, current clipboard architecture is not the final one
<attente_> dandrader: oh ok, so there is some plan to move it back down to the mir level?
<dandrader> attente_, I don't think so. if I'm not mistaken the plan is to move it to content hub
<dandrader> attente_, consensus seems to be that system clipboard  != display server
<dandrader> attente_, tvoss knows the details
<attente_> dandrader: ok, thanks
<mardy> bschaefer: hi! I'm trying to run a SDL2.0 game on the nexus 4
<bschaefer> mardy, awesome, hows that going?
<mardy> bschaefer: SDL_CreateWindow fails:
<bschaefer> :(
<bschaefer> mardy, are you trying to run this on unity8?
<mardy> Could not create window: Failed to created a window surface 0x1
<bschaefer> or on a standalone mir server?
<mardy> bschaefer: looks like the message comes from here: http://hg.libsdl.org/SDL/file/2b2cfda26085/src/video/mir/SDL_mirwindow.c#l133
<mardy> bschaefer: unity8
<bschaefer> oooo ... haha yeah i think thats my fault
<bschaefer> for not patching SDL2 yet...
<bschaefer> i think sdl2 still has opengl compiled with it on the phone
<bschaefer> mardy, sooo you'll need to recompile SDL2 with --disable-video-opengl
<bschaefer> IIRC
<mardy> bschaefer: I had to rebuild libsdl2 myself, because of https://bugs.launchpad.net/bugs/1402753
<ubot5> Launchpad bug 1402753 in libsdl2 (Ubuntu) "Mir backend doesn't work, rebuild needed" [Undecided,New]
<bschaefer> eeek, i've not seen that yet!
<mardy> bschaefer: ok, I'll try
<bschaefer> mardy, thanks! let me know if that works
<mardy> bschaefer: after rebuild with --disable-video-opengl, the window is created and the app runs, but nothing is visible on the screen
<mardy> bschaefer: it's not just black, it's completely transparent
<bschaefer> mardy, what app are you testing?
<mardy> bschaefer: https://github.com/mardy/trg2/tree/sdl2.0
<mardy> bschaefer: the SDL code is in src/main-sdl2.cpp
<bschaefer> mardy, o haha yeah i was about to say looks like 1.2
<mardy> bschaefer: what happens if the window size does not match the screen? could this be the problem?
<bschaefer> mardy, try to confirm its getting the correct window size
<bschaefer> yeah
<bschaefer> if its 0,0
<bschaefer> that would be an issue :), you can also try to force a size to confirm is an issue on my end
<mardy> bschaefer: SDL_GetWindowSize() returns the same size I used to create it: 854x480
<mardy> bschaefer: I didn't understand: should I specify 0,0 as size?
<bschaefer> mardy, no, i was thinking if it get 0,0
<bschaefer> it would be an issue but mir doesn't support resize :)
<bschaefer> mardy, is it still ... working besides no image?
<mardy> bschaefer: yes, the music plays
<bschaefer> mardy, alright...whats the res on the n4?
<bschaefer> also, if you want to you can get some errors
<bschaefer> printf("ERROR:\n%s", SDL_GetError());
<bschaefer> IIRC
<bschaefer> mardy, let me get a phone running for me to attempt to run the game!
<bschaefer> mardy, also you made a desktop file to launch the app right?
 * bschaefer waits for phone to not be dead
<mardy> bschaefer: sure, I have a click dir, let me push it somewhere
<bschaefer> click dir? you've made a click package?
<bschaefer> man i need to learn how to make one of those haha
<mardy> bschaefer: https://github.com/mardy/trg2/tree/click
<mardy> bschaefer: so, to build the app:
<mardy> bschaefer: mkdir build && cd build && cmake .. && make
<mardy> bschaefer: then, once the executable is build: cd ../click && cp ../build/trg2 . && click build .
<bschaefer> cool, and do you get any errors after you init
<bschaefer> or after you create the window?
<mardy> bschaefer: nope
<bschaefer> ie. after you do an SDL_Init do a print on SDL_GetError()
<bschaefer> o, dang
<bschaefer> hmm
<mardy> bschaefer: If I print SDL_GetError() I can see some error, but it varies; I think that I shouldn't call SDL_GetError() if the functions return success
<mardy> bschaefer: anyway, I added a SDL_WINDOW_FULLSCREEN flag, and if I specify a size of 768x1222 (like other QML apps), I see that the returned size is 768x1280, which is really fullscreen
<bschaefer> mardy, yeah just call it anytime
<mardy> bschaefer: I get this: Failed loading eglChooseConfig: /usr/lib/arm-linux-gnueabihf/libSDL2-2.0.so.0: undefined symbol: _eglChooseConfig
<bschaefer> if theres no error, its empty
<bschaefer> hmm IIRC thats not really an error but still happens
<mardy> bschaefer: or maybe they forget to clear it?
<bschaefer> possibly that
<bschaefer> mardy, i also have an sdl1.2 branch as well
<bschaefer> https://github.com/BrandonSchaefer/SDL1.2-Mir
<bschaefer> mardy, and you app works fine on X11?
<bschaefer> your*
<mardy> bschaefer: yep
<bschaefer> cool, just want to double check :)
<bschaefer> mardy, another thing you could test
<bschaefer> in SDL/tests/
<mardy> bschaefer: now I added a probably useless SDL_GL_MakeCurrent, and it returns 0 (no error)
<bschaefer> theres a few tests that are a good to check things are working
<bschaefer> hmm
<bschaefer> mardy, no you do need that
<bschaefer> well...
<bschaefer> mardy, you should also store the SDL_GLContext
<bschaefer> so you can do
<bschaefer>   SDL_GL_DeleteContext(context);
<mardy> bschaefer: that shouldn't have an impact, right?
<bschaefer> nope
<mardy> bschaefer: ops, I have to leave now
<bschaefer> none at all :)
<bschaefer> alright, do you have an email?
<bschaefer> err
<mardy> bschaefer: if you can find some time to play with it, I'd be grateful
<bschaefer> yup
<mardy> bschaefer: alberto.mardegan@canonical.com
<bschaefer> mardy, cool, ill take a look. Thanks!
#ubuntu-mir 2014-12-16
<duflu> Hmm, has Jenkins approved anything yet?
<dandrader> I'm going through Alf's "Mir in VMware quick-start guide"
<dandrader> "6. If you are using Mesa drivers, stop the virtual machine"
<dandrader> how do I know if I'm using such drivers?
<greyback> dandrader: what GPU have you?
<dandrader> onboard intel
<dandrader> greyback, ^
<greyback> dandrader: you're using MESA then
<dandrader> ok, thanks
<dandrader> greyback,  "7. sudo apt-get install glmark2 and run 'glmark2' to ensure that it runs and
<dandrader>    shows SVGA as the renderer (not llvmpipe!)"
<dandrader> greyback, that's from inside the vm, right?
<greyback> dandrader: yep
<greyback> just to confirm you're using the host's GPU, instead of emulating GL using CPU inside the vm
<dandrader> greyback, it's using llvmpipe. how do I fix that?
<greyback> dandrader: hmm go back over the steps and double-check. It just worked for me
#ubuntu-mir 2014-12-17
<anpok_> kdub, alan_g: can I have your opinion on the LoggingSharedLibraryProberReport here:
<anpok_> https://code.launchpad.net/~mir-team/mir/server-platform-probing/+merge/244982
<anpok_> line 1122 in the MP currently defined anonymously inside the graphics part of the server configuration
<kdub> sure
<anpok_> I was wondering whetyer MIR_SERVER_*_REPORT=log should use ml::log instead of logger?
<alan_g> ok
<alan_g> no
<anpok_> i was about to move that class somewhere else since I would use the same impl for input platform loading
<anpok_> ok then this wont be the =log report..
<anpok_> so right now this code will always report which libraries have been tested and loadded independent of any log setting
<alan_g> anpok_: I think you have misunderstood something. The reason reports (like LoggingSharedLibraryReport) should have a dependency on ml::Logger is so that they can be tested - and we can ensure the output is correct and meaningful
<alan_g> ml::log() provides a way for unimportant messages to be written to the logger (which is the same one).
<kdub> its also so we can plug different loggers in (like glog in the examples), or we could have a file-writer logger one day
<alan_g> kdub: of we plug in glog that also affects ml::log()
<alan_g> *if
<anpok_> hm so the LoggingSharedLibraryReport part needs fixing
<kdub> alan_g, ah, I was unaware
<alan_g> The last thing mir::Server::apply_settings() does is ml::set_logger() - so by the time the system starts initialization the logger has been changed
<alan_g> camako: here is the extension to mir_demo_server we talked about yesterday. Can you check it can supersede  mir-demo-tester? https://code.launchpad.net/~alan-griffiths/mir/enable-running-tests-in-mir_demo_server/+merge/245021
<alan_g> AlbertA: I think this is OK now? https://code.launchpad.net/~nick-dedekind/mir/1355173.trust-prompt-suspend/+merge/241588
<AlbertA> alan_g: oh yeah I forgot to flip it yesterday...
<AlbertA> racarr: so I'm trying to understand the need for buffer stream...like why not just add additional methods to fill in a buffer obtained from a MirSurface?
<AlbertA> racarr: I mean at the client level why do I care that it's MirSurface vs MirBufferStream?
<racarr> AlbertA: You can't make WM requests on a buffer stream, it can't receive input, etc
<racarr> so the question is it better to pull out the buffer stream abstraction or
<racarr> make a highly special cased surface
<AlbertA> racarr: couldn't we do a MirSurfaceType cursor or such?
<racarr> I mean we could, and it would work for this despite adding a lot of extra semantics...
<racarr> e.g. now it probably requires documentation, setting cursor on MirSurfaceType cursor always fails, setting orientation, etc.
<racarr> but then, the intention is that its not just cursor...
<racarr> e.g. perhaps the auxillary decoration surfaces
<racarr> the other example is from RAOF and that's a client attaching multiple buffer streams to a single surface.
<anpok_> hmm
<anpok_> like a nested shell?
<racarr> essentially
<racarr> except say
<racarr> I mean chromium is the only app I can think of that may do something like that
<racarr> I think maybe RAOF has another example
<AlbertA> racarr: well I do think it goes nicely with screencasting
<AlbertA> so we don't have to do the egl dance and glREadPixels
<racarr> that too
<racarr> eventually mir_screencast.cpp and
<AlbertA> lends itself for easier integration with h/w encoders
<racarr> mir_surface/surfaceless_buffer_stream.cpp
<racarr> parts of it can
<racarr> be shared
<racarr> as the client machinery
<racarr> but...
<racarr> i.e. in terms of code duplication
<racarr> but the diff is already kind of painful
<racarr> and I was scared to touch any more critical path code lol
<racarr> but it should eventually reduce some code duplication
<racarr> AlbertA: p.s. thanks for reviewing buffer stream :)
<racarr> I know its kind of a long review for the tagline of...upload pixels to the cursor
<racarr> lol
<AlbertA> racarr: add-more-event-getters is a pre-requisite of port-examples-off-mir-event-access right?
<racarr> AlbertA: Yeah, because of the new
<racarr> header structure
<racarr> that doesn't require including each event header individually
<racarr> AlbertA: I realized a lot of my concerns about protocol validation in your branch (don't feel you have to do this though because it already exists too...)
<racarr> could be solved by using a different way of structuring the protobox requests
<racarr> e.g. message MenuRequest { required int top; required int left} message SurfaceRequest {optional int MenuRequest}
<racarr> err
<racarr> optional MenuRequest
<AlbertA> racarr: yeah I asked about that, but it was preferred
<AlbertA> to add optional fields to SurfaceParameters
<racarr> really weird
<AlbertA> and required is probably not something we want to use now...as it would be a pain in the ass to retire it if we need to right?
<racarr> nah. as long as the top level requests only feature optional membership of things that have required members
<racarr> then you can always keep appending, MenuRequest2 MenuRequest3, etc...
<AlbertA> racarr: ah I see...
<AlbertA> still have it as part of SurfaceParameters
<racarr> mm
<AlbertA> but group them accordingly
<AlbertA> ?
<racarr> yes
<racarr> you end up repeating the shared parameters
<racarr> in the nested messages
<racarr> I think? But that's not really
<racarr> a problem
<racarr> I mean some component has to contain these message groupings
<racarr> in the current architecture its drifting towards a combination of SurfaceParameters and session
<racarr> so I think it would be cool to just encode it in the protobuf layer.
<racarr> actually the version of alan_g in my dream last night (100% serious lol) thought it would be cool but I agree.
<AlbertA> racarr: :)
<racarr> Maybe ill take a peek at it the next time I get some time for a cleanup branch
<anpok_> hmm
<anpok_> those to probing branches..
<anpok_> *two
<anpok_> they are a bit inconsistent.. the output dir for the loadable client and server libraries is {client,server}-modules but for the dpkg those paths get changed to {client,server}-platform
<anpok_> ah ok thats just install vs output..
<racarr> mp list is giant lets top approve https://code.launchpad.net/~albaguirre/mir/pref-orientation-at-create-time/+merge/244602
<racarr> ?
<racarr> err grr I forgot
<racarr> the dep
<racarr> https://code.launchpad.net/~alan-griffiths/mir/mir-server-version-macros/+merge/244577 may be a TA candidate
<AlbertA> racarr: yeah just waiting to discuss with daniel
<AlbertA> on the dep branch
<racarr> camako: lol you sure you dont want to block on the cow?!
<racarr> :p
<camako> racarr... It's not a longhorn so I thought about it, but naah :-)
<racarr> https://code.launchpad.net/~mir-team/platform-api/expose-mir-connection/+merge/245054 is a thing
<racarr> lol im concerned if I submit any more MPs or become involved ina ny more reviews my head may explode
<racarr> THERES ONLY ONE WAY TO FIND OU...*POP*
<racarr> https://code.launchpad.net/~mir-team/mir/add-more-event-getters/+merge/243579 this is the branch I'd most like to land
<racarr> I guess qtubuntu port is done but the dependency chain is
<racarr> add-more-event-getters -> event-ref/unref + port-examples-off-mir-event -> release mir
<racarr> papi/expose-mir-connection
<racarr> then qtubuntu can land
<racarr> seems unlikely to happen by holidays ;(
#ubuntu-mir 2014-12-18
<RAOF> racarr: Hey, I'm about to do a whole lot of commenting on introduce-bufferstream.
<RAOF> racarr: Would you prefer an IRC discussion? :)
<racarr> RAOF: Yeah IRC sounds better :)
<RAOF> Ok.
<RAOF> racarr: So, first off - why create_surfaceless_buffer_stream, rather than just create_buffer_stream?
<racarr> RAOF: I guess because I'm thinking of BufferStream as analagous to an interafce implemented by
<racarr> Surface and Screencast
<racarr> so create_buffer_stream is
<racarr> mildly incorrect?
<RAOF> That brings up point 2 - why does MirScreencast still exist? :)
<RAOF> So, my feeling is that mir_connection_create_surfaceless_buffer_stream is mildly incorrect; among other things, a screencast is *also* a surfaceless bufferstream.
<racarr> hmm
<racarr> I guess the Screencast C'Tor could just return BufferStream
<racarr> except for ABI break
<RAOF> Yeah, that's what I was thinking.
<racarr> which this otherwise avoids iirc
<RAOF> Yeah, this is true.
<racarr> I guess, right so the other thing is
<racarr> then you would need mir_buffer_stream_release
<racarr> and have to document the behavior when called on a buffer stream obtained
<racarr> from a surface
<RAOF> Yeah. Which is my point 3 :)
<RAOF> My preference would be for *all* buffer streams to need to be released.
<racarr> oO?
<racarr> What is the use case for releasing a surface but not the buffer stream?
<RAOF> Consistency in API, mostly :)
<RAOF> But it's also vaguely sensible, if you just care about output.
<racarr> Hmm I dont know it seems to require a lot more error states, e.g. what happens if you use surface in when buffer stream is released, etc...
<racarr> ?
<RAOF> Neither the surface nor the buffer stream are destroyed until both are.
<racarr> What do you mean by its vaguely sensible
<racarr> if you just care about output?
<RAOF> Well, if you're doing something like a video output window you could happily release the surface and just swap the buffer stream.
<RAOF> But I agree that's not particularly compelling, which is why I said vaguely sensible :)
<racarr> I guess I'd be more inclined to have mir_buffer_stream_release be an error
<racarr> if the buffer stream is owned by a surface
<racarr> or something...not sure of the exact language
<RAOF> Well, *that* could actually be a sensible usage.
<racarr> ?
<RAOF> If you're just doing say a static splash screen - create the surface, get the buffer stream, do your one and only swap, then release the buffer stream and now Mir can free some memory :)
<RAOF> But eh.
<RAOF> Mostly I want it for API consistency, and for when we want to associate multiple buffer streams with a single surface.
<racarr> I am not sure I would quite see it
<racarr> anything that requires every currently existing call call to mir_surface_release
<racarr> literally without fail
<racarr> to be prefixed with a call to mir_buffer_stream_release
<racarr> has to be incorrect right?
<racarr> anyone looking would say the surface should own the buffer stream and take care of releasing it....
<RAOF> Well, I thought the same thing for MirSurfaceSpec; mir_surface_create() should eat the SurfaceSpec passed in.
<racarr> ugh
<racarr> lol
<RAOF> But I don't think it's so unreasonable now :)
<racarr> This is a little different though because the surface creates the buffer stream...
<racarr> and I do think its unreasonable lol
<racarr> floating references provide a better solution
<racarr> but yes I guess that landed
<duflu> racarr: a buffer stream allocator for clients might be what we need to make nested clients bypass/overlayable too
<duflu> ... as the nested server can then allocate buffers from the system compositor for nested clients
<RAOF> Also, you still have the problem of error states multiplying - you still have to specify what happens when you use buffer stream you got from a released surface.
<racarr> lol
<racarr> nah, it becomes invalid
<racarr> I guess there should be
<racarr> mir_buffer_stream_is_valid
<RAOF> Yeah, that's necessary.
<RAOF> duflu: Oooh, exactly right!
<RAOF> duflu: That's âmultiple buffer streams per surfaceâ.
<duflu> RAOF: Nah, just the nested server needs a way of allocating system-compositor buffers for nested clients
<RAOF> Also, hello from Perth.
<duflu> RAOF: Oh good morning
<racarr> Hmm ok I am convinced mir screencast ctor should return MirBufferStream
<racarr> I am convinced...surfaceless_buffer_stream could have a better name
<duflu> racarr: minus "surfaceless" because that's kind of implied
<duflu> Bugger. We're too efficient and landed the branch I was about to fix
<racarr> I mean not necessarily some buffer streams are associated with surfaces
<duflu> Another branch then
<racarr> some aren't
<racarr> but RAOF points out that screencast isnt associated with a surface
<racarr> but isnt what I call a SurfacelessBufferSTream
<duflu> racarr: Yeah there's a reason why it's called a stream in video encoding/decoding
<racarr> RAOF: The part that I can't wrap my head around is why you should have to release a buffer stream seperately from the surface....
<racarr> duflu: ?
<duflu> racarr: The reason is just that nobody has thought of a better abstraction/noun than "stream"
<racarr> oh lol
<duflu> And maybe there isn't one
<RAOF> racarr: You don't have to, but I feel it's a bit cleaner and consistent.
<racarr> RAOF: Hmm
<racarr> I guess I will mull over that one my thought is that
<racarr> the consistency is "all streams which you allocat ehave to be released" and in this case it
<racarr> s said that the surface allocates the stream
<racarr> likewise I would say that in the case of attaching multiple buffer streams to surfaces, etc...
<racarr> I guess I would expect the surface to take ownership of the stream
<RAOF> I'm happy with that, but I'm not sure it's consistent with our current API.
<racarr> im not sure either lol
<racarr> wrt surface spec its different because you allocate the spec...
<racarr> hmmm
<RAOF> But then with your multiple-buffer-streams case you *also* allocate the buffer stream :)
<racarr> and are we sure there really is no MirScreencast
<racarr> I can almost imagine things like
<racarr> mir_screencast_set_capture_rate, or mir_screencast_set_scale
<RAOF> Maybe?
<racarr> What if we add MObject and then MirScreencast can MIR_IMPLEMENT_INTER....
<racarr> err....
<RAOF> :)
<RAOF> All nontrivial C programs are guaranteed to implement a half-arsed object system? :)
<racarr> mm
<racarr> it does kind of seem like set_rate could be a thing...-.-
<RAOF> That would seem to be mir_buffer_stream_set_swap_interval?
<racarr> hmm probably
<racarr> Seems Screencast can probably go
<racarr> RAOF: Ok so my plan is to change the surfaceless_buffer_stream names, drop MirScreencast, add buffer_stream_is_valid
<racarr> do something about buffer_stream_release
<racarr> (took notes)
<RAOF> Hm.
<RAOF> Does MirCursorConfiguration want to own the buffer_stream?
<racarr> hmm
<racarr> I dont think so at least from the client perspective
<racarr> and thats consistent with surface spec
<racarr> on the server side though, if the buffer stream was used as the
<racarr> active cursor request from a surface
<racarr> even if you release the buffer stream
<racarr> the surface will keep around shared_ptr buffer stream and the last buffer will persist until
<racarr> you make a new cursor request for the surface
<racarr> which I thought was good semantics
<racarr> it would be more obvious with unref vs release
<RAOF> Maybe we want unref?
<RAOF> I agree that's good semantics.
<racarr> I kind of think we want unref, because...well I dunno, that semantic might not be entirely obvious to me as I see _release
<racarr> right. I mean I guess its explicitly non obvious
<racarr> because release typically means release
<racarr> however if I saw unref
<racarr> I would assume
<racarr> the cursor configuration and or surface took references to the buffer stream
<RAOF> Right.
<RAOF> (Relatedly, Ryan is correct in saying that we need a destroy notify on our delegates)
<racarr> indeed.
<racarr> I'm making event ref counted in another mp...
<RAOF> Which would happily remove the need for all our _release_sync()s.
<racarr> maybe connection and surface should be ref counted too...
<racarr> RAOF: ?
<racarr> Oh I see
<racarr> wow this reminds me of an ancient problem that _create_sync is unsafe because oyu dont have time to set delegates before
<racarr> events can be received
<racarr> and that delegates need to be in surface spec
<racarr> <tangent>
<racarr> well its unsafe in that you could miss events
<racarr> and will miss your first focus event
<racarr> Total tangent lol
<racarr> ok hopefully I should get to all this tomorrow assuming I dont wake up to some sort of perfect storm of merge conflicts
<racarr> im kind of assuming I will wake up to a perfect storm of merge conflicts but who knows
<RAOF> Heh.
<racarr> Ok. Off to go play some piano before dinnnnner
<racarr> RAOF: Thanks :)
<duflu_> RAOF: Can you check this out some time soon? ... https://code.launchpad.net/~vanvugt/mir/revert-r2165/+merge/245063
<RAOF> Sure. I'm doing a big review sweep anyway. :)
<racarr> whee merging sha1sums causes cascading jenkins failures again!
<racarr> duflu: I wonder how evil MirEvent* mir_event_ref(MirEvent const*) is :p
<racarr> I think its ok if you believe in logical constness
<racarr> you mark the ref count mutable the compiler is happy
<racarr> all calls mir_event_foo* return the same value
<racarr> after mir_event_ref that they did before mir_event_ref
<duflu> racarr: I think I abstained on that?
<racarr> so its 'logically const' right
 * duflu checks
<RAOF> Uuuh, you mean MirEvent const* mir_event_ref(MirEvent const*), right?
<racarr> duflu:  Mm :) I am just saying maybe there wont be an ABI break
<RAOF> I'd be fine with that; you're not changing the contents of the MirEvent.
<racarr> RAOF: Even better!
<racarr> lol
<racarr> hmm
<racarr> no
<duflu> racarr: Mutable or not, it would be poor C design to go changing things insider a const object
<racarr> RAOF: But then mir_event_unref would have to accept a const
<racarr> MirEvent
<racarr> which...is less
<racarr> more questionable
<racarr> I dont think youc an say its logically const
<racarr> if you destroy the object
<racarr> lol
<RAOF> Why does MirEvent want to be refcounted, by the way?
<duflu> racarr: Non-const always, but just work to make the return value optional later?
<duflu> Then no ABI break
<racarr> duflu: Unfortunately clients only ever get MirEvent const*
<duflu> Although this is mircommon, which we break regularly. Possibly a non-issue
<RAOF> I don't know. I think it *is* logically const if mir_event_unref() only ever destroys an object that's no longer referenced anywhere.
<racarr> oh
<racarr> thats true
<racarr> haha
<racarr> well
<racarr> thats an argument at least!
<racarr> hmm
<racarr> effectively it wants to be refcounted because it wants to be copied
<RAOF> Because the client code wants to preserve it outside the event callback?
<duflu> racarr: This is kind of why I was saying ABI breaks are inherited though. e.g. some changes in mircommon would break the client ABI
<racarr> RAOF: Basically, and because
<racarr> the client library code isnt going to access it after that
<racarr> I dont think you gain any sort of avoid synchronization benefit from a copy
<racarr> and ref will be most efficient
<racarr> RAOF: Then the double controversy is because I can't add ref_count to MirEvent yet mir_event_ref currently copies the event
<racarr> :p
<RAOF> Well, if you only ever use it inside the event callback then you can just pass the const*.
<RAOF> What code wants to use the event outside the callback?
<duflu> racarr: Surely while it's not opaque the user can just copy it? :) a = *b
<racarr> RAOF: Qt queues it up as a task on the main loop
<racarr> duflu: That's what qtubuntu does now
<racarr> and im trying to
<racarr> port it
<racarr> :)
<RAOF> Ah, fair enough.
<RAOF> Then I'm for mir_event_ref and mir_event_unref, both working on const*
<racarr> mm I think so too
<racarr> will update in morning
<RAOF> duflu: std::atomic_bool _still_ isn't equivalent to std::atomic<bool> :)
<anpok> RAOF: hmm it cannot find the graphics-dummy platform
 * RAOF looks.
<RAOF> Oh, on the mako?
<anpok> hm there we install the packages and do not run from build location
<anpok> RAOF: oh you meant it should =log on the client and server by default?
<RAOF> anpok: Yes.
<RAOF> anpok: But more; I don't think that it should be a report at all. It was just - when all you have is a ReportPattern, everything seems to be a report.
<anpok> :)
<RAOF> Because why would you _ever_ want to use SHARED_LIBRARY_PROBER_REPORT=lttng
<RAOF> ?
<anpok> RAOF: if all your reports report to lttng.. all your reports report to lttng
<anpok> to be honest I only made that change, because I needed it for the input side
<RAOF> Yeah.
<RAOF> I think that short-term defaulting to log is fine.
<RAOF> And then, longer term, we just need to drop the SharedLibraryProberReport interface entirely, move mir::logging into mircommon, and then have libraries_for_path log directly, rather than take a SharedLibraryProberReport.
<RAOF> anpok: Oh, of course!
<RAOF> anpok: You're missing a path separator in the as-installed probe.
<RAOF> anpok: Would you like to fix it, or shall I?
<RAOF> anpok: Specifically:
<RAOF> +         {library_path() + "/server-modules/", library_path() + "/server-platform/", std::string(MIR_SERVER_PLATFORM_PATH)})
<RAOF> should be
<RAOF> +         {library_path() + "/server-modules/", library_path() + "/server-platform/", std::string(MIR_SERVER_PLATFORM_PATH) + "/"})
<RAOF> Because MIR_SERVER_PLATFORM_PATH=/usr/lib/linux-armhf-gnueabi/server-platform
<duflu> RAOF: Not equivalent, but more efficient and sufficient possibly
<duflu> Although atomic anything is open to races. I think we're turning a blind eye to that most of the time
<duflu> Hmm, the sensible thing to do would be to find ways to tie up loose ends by tomorrow
<duflu> Not sure how to achieve that more than we already are :P
<RAOF> duflu: Actually, now that I've looked a bit more, I take that back.
<RAOF> std::atomic_bool is a typedef to std::atomic<bool>.
<RAOF> So we're both wrong :)
<duflu> RAOF: Regardless if you know enough about the arch it could also be typedef bool :)
<duflu> sigactomic_t
<duflu> sigactomic_t
<duflu> or sig_atomic_t
<duflu> one of them
<RAOF> I don't think sig_atomic_t is guaranteed to be thread-atomic.
<RAOF> And it can't be typedef bool, because there's memory barriers involved.
<duflu> RAOF: It's a pretty safe bet if the type is within the word size
<duflu> RAOF: Barriers?!
<RAOF> Yes, barriers?
<duflu> Oh I see. std::atomic is quite featured.
<duflu> Too many features for some uses
<duflu> RAOF: I guess not if is_lock_free()
<RAOF> Barriers != locks.
<RAOF> Barriers are âdear CPU+compiler, please actually read this memoryâ
<duflu> RAOF: ??
<racarr> e.g. cache invalidation
<RAOF> Compilers are free to reorder or entirely elide reads; likewise CPUs (and, indeed, multiple levels of the memory heirarchy)
<duflu> Interesting. I always use spinlock as my lowest level primitives but seems like barriers might also be useful
<RAOF> duflu: Feel like a quick and easy top-approve?
<RAOF> duflu: https://code.launchpad.net/~mir-team/mir/more-inconsistent-overrides/+merge/245068
<RAOF> racarr: :P
<RAOF> duflu: http://en.wikipedia.org/wiki/Memory_barrier if you're interested. In particular, memory barriers are required to correctly implement any synchronisation primitive. :)
<duflu> RAOF: Right. Back on the original topic. If you can avoid a template instantiating type then it's obviously preferable. Some compilers at least will extern the std::atomic_foo methods
<duflu> Or extern the instantiation
<RAOF> The instantiation is in libstdc++, though.
<duflu> RAOF: Yes, in some implementations. What's important is that it might be typedef'd to something that's not an instantiation, hence more efficient
<RAOF> I'm not entirely sure how that follows?
<duflu> RAOF: Not mentioning '<>' in the code ensures you don't slow down the compiler to check for or create instantiations
<duflu> Unfortunately not an advantage if the library typedefs to one
<duflu> But other C++ implementations would benefit
<duflu> I don't remember the end of any year ever being this busy
<racarr> The year jenkins stole christmas
<duflu> racarr: To be fair to Jenkins, it didn't slow us down. We had already landed everything we could. It just sucked up my time landing things
<racarr> I dunno not to give anyone a hard time because I did the same thing to some branches but I assume introduce-buffer-stream etc wouldnt have gone a full week
<racarr> without review
<racarr> if they had a +1 from jenkins
<racarr> or maybe europe just doesnt like me anymore because I sleep through standup and there are only two of you guys
<racarr> who knows
<duflu> racarr: I know how it feels. Safe to say everyone's waiting for things of theirs to lang
<duflu> land
<racarr> :)
<duflu> And I'm now involved in more code reviews than I can feasibly keep up with. So staying out of others
<racarr> Thats how I felt towards EOD today toooo
<racarr> Ok daily show -> bed
<duflu> racarr: As a matter of psychological trickery, developers tend toward reviewing smaller things first
<duflu> Not that that's a "trick" but helpful to know
<anpok> RAOF: uh!
<RAOF> Boo.
<RAOF> Fewer random hard shutdowns please laptop.
<mlankhorst> RAOF: hey did you take a look at standalone xmir yet? :P
<RAOF> mlankhorst: What did you want me to look at again?
<RAOF> I've been off for the last 3 days, so may have lost some state :)
<mlankhorst> no just in general if you have looked at it or not
<RAOF> mlankhorst: Oh, no, I've not.
<RAOF> mlankhorst: Is there anything you'd like me to do about it?
<mlankhorst> not in particularly, just if you could look it over
<Mark__> hello, anyone here?
<racarr> can I TA add-more-event-getters?
<racarr> Happy to lose the dependency on my branches...
<racarr> *removes MirScreencast from public API*
<racarr> Chris pointed out last night MirBufferStream* mir_connection_create_screencast can be enough
#ubuntu-mir 2014-12-19
<alan_g> kdub: happy with this one yet? https://code.launchpad.net/~mir-team/mir/add-more-event-getters/+merge/243579
<kdub> alan_g, reviewing
<kdub> alan_g, +1 from me, although... I wasn't privy to the goals of MirEvent 2.0
<alan_g> kdub: nor I
#ubuntu-mir 2015-12-14
<robjh> hi RAOF. theres no error message. though i didnt try starting my own mir server. The actual output of the program is this http://codetidy.com/7590/
<RAOF> robjh: Hah. You're running it on lightdm's system-compositor, not unity8.
<RAOF> robjh: Since you can see the phone UI that's not going to work :)
<robjh> ooh :p
<RAOF> robjh: the MIR_SOCKET environment variable has Unity8's value in it.
<duflu> Unless you logged in remotely?...
<RAOF> You'll then need to pass -- --desktop_file_hint=gedit.desktop (or something like that) in order to defeat Unity8's âsecurityâ.
<robjh> i can get the enviroment vatiable from the terminal app i bet
<RAOF> Yup.e
<RAOF> It'll be /run/user/$SOMETHING/mir_socket
<robjh> run/user/32011/mir_socket
<robjh> so, yep
<robjh> It's working! :D
<robjh> thanks for the help :)
<RAOF> No problem!
<RAOF> ThreadSanitizer: reported 356 warnings
<RAOF> Yeah, this'll just take a moment...
<sturmflut> Looks like our armhf repositories for xenial contain a libmircookie1 package, but its dependency libnettle4 is missing. Who do I ping about this?
<zzarr> hello! Is there a way to try unity8 on a computer with a nVidia card?
<duflu> zzarr: Yes in theory, however Unity8 on desktop is a bit hit and miss right now. It doesn't seem to be working properly with the latest xenial today
<duflu> So I wouldn't go to the trouble of trying it until the recent basic issues are fixed
<corn_field> duflu, yeah... unity8 loads but the wallpaper is black and it doesn't load apps :/ i can see the apps opened in the launcher but not on the desktop o_O weird
<duflu> It might (should) work better in wily than xenial, but development continues in xenial only.
<corn_field> xenial should start beeing not brake from now on :)))
<corn_field> broken
<zzarr> okey duflu, but will xenial have support?
<duflu> zzarr: Yes, xenial is the bleeding edge. wily is frozen, but likely to be frozen at a less broken stage in the past, at a guess
<duflu> Then again, it's early for xenial and Ubuntu usually has lots of teething issues like this every cycle
<zzarr> okey, duflu thanks for the heads up :)
#ubuntu-mir 2015-12-15
<duflu> Oh, nested servers/clients all hang and/or exit silently. I wonder when that started
<duflu> alan_g, anpok: Umm, good night. But for kicks, check out bug 1526209
<ubot5> bug 1526209 in mir (Ubuntu) "[regression] Clients of nested Mir servers silently crash/exit instantly" [Critical,Triaged] https://launchpad.net/bugs/1526209
<maikeul> hello folks, i'm getting these errors when running any X application with Xmir: http://pastie.org/private/evaqzjyuvhwtudi4li5yhw i know there is no support for this, but maybe you might have an idea what could be the problem, or where to start looking  at ? thanks in advance
<greyback_> kdub: any idea^ ?
<kdub> maikeul, the gralloc (android hal) mapping on the client side seems to fail
<kdub> you might want to try mir_demo_server + mir_demo_client_fingerpaint (another software-rendered client) to boil the problem down a bit more
<maikeul> thanks i'll have a try
<maikeul> both work perfectly
<kdub> maikeul, interesting... i guess the good news is that means your driver isn't insane
<maikeul> am i sure i have the latest Xmir version ?
<maikeul> i'm getting a bit lost with the doc i find online
<maikeul> i was hoping i don't have to build from source :)
<alan_g> kdub: FYI I've fixed a second bug in https://code.launchpad.net/~alan-griffiths/mir/fix-1526248/+merge/280578. (And I'm not sure what your comment implies for landing my MP.)
<kdub> alan_g, no need to block, lgtm... was just pointing out an additional problem with this code bit
<kdub> that I spent friday afternoon re-sorting
<kdub> :D
<alan_g> thanks
<mcinitreevan> Hi, Im trying to build mir from source on xenial and when I run mk-build-deps it doesn't install all the missing dependencies, it just fails. I saw there was a bug on launchpad about this, but it said the fix was committed and I am using the latest repo as far as I can tell
<camako> mcinitreevan, as a workaround, just look in the debian/control file and install all the packages on the list.
#ubuntu-mir 2015-12-16
<mcinitreevan> Thanks, camako
<mcinitreevan> Hi again, Im trying to build everything from source, but there are issues with building the modified mesa, not sure if they're known or not http://pastebin.ubuntu.com/14045761/
<RAOF> mcinitreevan: That's not our code; that must be a mesa bug.
<alan_g> anpok_: duflu - anyone want to review this before I TA? https://code.launchpad.net/~alan-griffiths/mir/fix-1526248/+merge/280578
<duflu> alan_g: Come to think of it, maybe yes
<Mirv> RAOF: you're probably not around anymore but https://requests.ci-train.ubuntu.com/#/ticket/725 would be publish button pressable by a core dev (including acking packaging changes)
<Mirv> as it was approved 6h ago by QA
<anpok_> oh it takes the wrong client library it seems..
<sil2100> Hello mir team!
<sil2100> I would need this merge approved by someone https://code.launchpad.net/~mir-team/mir/0.18/+merge/279111
<sil2100> (otherwise landing from silo 21 won't get published)
<alan_g> sil2100: I'm not sure of the current status, kdub (who's been managing this) should be up soon...
 * kdub is up now
<kdub> sil2100, we're still working through a bug found in testing
<sil2100> kdub: wait, so it's not ready for release then?
<sil2100> kdub: the status is QA Granted so I was about to publish it
<kdub> sil2100, hmm, just waking up, let me see what's going on in there
<sil2100> kdub: if it's not ready, please change it to 'Needs QA' so that no one publishes it by accident
<kdub> will do, have to work out with vvruiz why it qa_signoff was toggled
<kdub> sil2100, sorry for the confusion
<kdub> actually, what probably happened was
<kdub> we toggled to "QA needed" and shortly thereafter, found the bug
<kdub> so we toggled back to "QA required"
<kdub> and that probably generated some confusion
<sil2100> kdub: ACK
<sil2100> Ok, if you could bring that up with QA so they're aware
#ubuntu-mir 2015-12-17
<duflu> RAOF: Now happening in simple unrelated MPs?.... https://bugs.launchpad.net/mir/+bug/1524161
<ubot5> Ubuntu bug 1524161 in Mir "[ FAILED ] ClientSurfaceEvents.surface_receives_output_event_on_creation " [Medium,New]
<RAOF> Hm.
<duflu> RAOF: Although the offending branch now landed.
<duflu> Maybe not fixed fixed
<RAOF> Hm.
<RAOF> Maybe alan's ordering fix is insufficient?
 * RAOF looks briefly, before EOD.
<RAOF> Nope, nothing obvious.
<RAOF> duflu: Alan's attempt to enforce ordering in that test is clearly insufficient, but I can't see why.
 * RAOF â EOD.
<duflu> EOD OK RAOF CU
<anpok_> duflu: got a configureable high dpi mouse now..
<duflu> anpok_: Cool. I found my cheap one that emits faulty clicks does 1000Hz OK. Surprisingly I bought a new Microsoft and that does not do 1000Hz (although it was advertised higher)
<duflu> Oh, high DPI. I mean high event rate
<anpok_> duflu: kind of both
<anpok_> at least it claims so
<anpok_> it can be configured via a hardware switch at the bottom.. and yeah only one of the low settings are useful in x11
<anpok_> now i wonder if that change in resolution is advertised somewhere..
<anpok_> oh there are three evdev devices...
<Saviq> hey guys, any idea on ETA of Mir 18? just wondering if I shall wait or skip a qtmir landing for now
<anpok_> i thought it was ready for qa yesterday
<Saviq> is "QA Required" today, kdub mentioned there was a last-minute issue found
<kdub> Saviq, I'm about to start testing for landing, issue is found
<kdub> and fixed
<Saviq> kdub, ack
<kdub> so I'm hoping today, but I'll let you know if there are any additional delays
<Saviq> kdub, ack, thanks
 * camako is wondering what happened to irc.canonical.com
<tvoss> camako, it's down
<camako> tvoss, ok thanks..
<kdub> i hope the irc outage doesnt affect the train
<kdub> for some reason this song is stuck in my head ;) https://www.youtube.com/watch?v=Wg60Az10A_E#t=1m06s
<kdub> is prodstack still down for everyone else?
#ubuntu-mir 2015-12-18
<anpok_> hum what is the purpose of clients only use client symbols test
<anpok_> as in it reports only missing client symbols but still fails
<anpok_> ah .. ok
<anpok_> gold..
<duflu> anpok_: The history behind that was about a year ago we had clients accidentally bound to particular libmircommon symbols. And libmircommon's ABI breaks too often. So test that clients only ever talk to libmirclient
<duflu> and it's "more stable" ABI
<anpok_> yeah.. it just failed for me after switching to gold
<anpok_> and just saw raofs mp
<anpok_> which btw eleminates the slow linking problem..
<alan_g> anpok_: any thoughts on this? https://code.launchpad.net/~alan-griffiths/mir/fix-1526779/+merge/280880/comments/712083
<anpok_> alan_g: whats happening there?
<alan_g> Read the bug discussion?
<alan_g> s//Have you /
<anpok_> not yet
<anpok_> oh
<alan_g> So, something is screwed up in drm (or below) - and I suspect other kit could be affected.
<anpok_> aye..gbm and drm are screwed ..
<anpok_> there seems to be no attempt to ever behave as a device abstraction
<alan_g> anpok_: Still OK with the testable, tested version?
<anpok_> yes
<alan_g> kdub: it's an old bug, but I think you landed some stuff that may be relevant. Could you take a look when you have an idle moment? https://bugs.launchpad.net/mir/+bug/1383745
<ubot5> Ubuntu bug 1383745 in Mir "[mako] screen corruption/tearing after using the device for medium durations" [Medium,New]
<kdub> alan_g, alright
#ubuntu-mir 2016-12-19
<tsdgeos> guys, did #include <mir_toolkit/debug/surface.h> disappear?
<tsdgeos> ah, it moved
<duflu> tsdgeos: You were using debug/debug/ ?
<duflu> https://bugs.launchpad.net/mir/+bug/1639153
<ubot5`> Ubuntu bug 1639153 in Mir "libmirclient-debug-extension-dev installs debug/surface.h twice" [Low,Fix released]
<tsdgeos> duflu: nah
<tsdgeos> moved as in moved to a different deb file
<tsdgeos> at some point, maybe not now, i had not built qtubuntu in quite some time
<duflu> tsdgeos: Oh right yes the more distant past. I just checked and zesty has it still (in the newer location and no longer twice)
<duflu> (zesty has Mir 0.25 now I forgot to announce)
<tsdgeos> yeah
<tsdgeos> it broke qtubuntu
<tsdgeos> :D
<duflu> Yay more work
<tsdgeos> would be nice to figure out why it wasn't caught before the landing happened
<tsdgeos> broke = doesn't compile
<duflu> tsdgeos: Let bschaefer know as that should have been in his checklist
<tsdgeos> i thought bileto or some stuff would take care of this
<tsdgeos> btu i guess they don't :D
<duflu> Clearly we have awesome build-deps that don't necessitate rebuilds of *everything*
<duflu> Probably since libmirclient9 has been unbroken a while
<alan_g> anpok: should we discuss the MirInputConfig etc. rename idea here instead of comments?
<anpok> agreed
<alan_g> why are you reluctant to export global namespace symbols from mircommon?
<anpok> alan_g: well thats more of a side effect.. I am reluctant to use a global name when we already have a namespaced name ..
<anpok> alan_g: well thats more of a side effect.. I am reluctant to use a global name when we already have a namespaced name ..
<anpok> the only advantage is that we have direct type name mapping in the mir client implementation
<alan_g> We already have names in the global namespace mir_* and Mir[A-Z]*
<anpok> oh we did that for events
<alan_g> I guess a couple more vogons should chime in to ensure folks are happy with the idea
<anpok> hm alan_g and then MirInputConfig -> MirInputConfiguration at some point
<alan_g> anpok: I guess so. Before/when it moves to mircore?
<anpok> alan_g: I thought because of the deprecation and rename of MirDisplayConfig{uration}
 * alan_g thinks XXXConfig would be easier to achieve. (But the team has voted)
<anpok> alan_g: I thought you very all in against abbreviating things?
<alan_g> In the general case I am. But "config" is widely used and unlikely to confuse
<anpok> s/very/were
<alan_g> that was my reading
<_javier4_> I get this error trying to launch Ubuntu Touch, and the screen remains on the boot animation
<_javier4_> ERROR: QMirServer - Mir failed to start
<_javier4_> is there a way to obtain a better debug message?
<anpok> _javier4_: the /var/log/lightdm/unity-system-compositor.log are the first log to look at..
<_javier4_> anpok_, I know. But to me that don't say anything. http://pastebin.com/gAHgsxUn
<anpok_> _javier4_: this looks ok..
<anpok_> so it seems something else prevents unity8 to start up and connect to unity-system-compositor
<anpok_> what else was inside the unity8 log?
<_javier4_> anpok_, this is the whole log http://pastebin.com/3fA2sUKW
<anpok_> _javier4_: hm could you look into what logcat gives you?
<_javier4_> unfortunately logcat resulted empty. But let me try again
<anpok_> it is weird that you see usc and the egl spinner of usc starting up .. which already shows that egl eith GLEX works..
<anpok_> with GLES
<_javier4_> anpok_, empty again
<_javier4_> root@ubuntu-phablet:~# /android/system/bin/logcat
<_javier4_> root@ubuntu-phablet:~#
#ubuntu-mir 2016-12-20
<alan_g> greyback: congratulations! miral integration has passed QA
<greyback> alan_g: hurray!
<davmor2> alan_g, greyback: now don't make it sound like it is a fluke or we might go back and look at it again ;)
<greyback> :D
<alan_g> so true!
<greyback> alan_g: fyi https://bugs.launchpad.net/ubuntu/+source/miral/+bug/1651384
<ubot5`> Ubuntu bug 1651384 in miral (Ubuntu) "[MIR] miral" [Critical,New]
<greyback> need miral to be in main before unity8 can use it
<alan_g> Oh yeah, I'd forgotten we'd need that.
<alan_g> greyback: can I help? Or is it just another wait for the wheels to turn?
<greyback> alan_g: the later, I think that's all the paperwork needed
<dandrader> alan_g, hi, did you read my mail about the double-lock issue?
<alan_g> dandrader: sorry, I forgot about it
<alan_g> dandrader: I see. Yes, force_close() shouldn't be calling a function from shell::WindowManager.
 * alan_g wonders why he's not hit that
<dandrader> alan_g, should I file a bug?
<alan_g> please - I'll get to it real soon
<dandrader> alan_g, https://bugs.launchpad.net/miral/+bug/1651422
<ubot5`> Ubuntu bug 1651422 in MirAL "Double lock in force_close()" [Undecided,New]
<alan_g> dandrader: thank you. Do you need the fix released? Or just committed for the time being?
<dandrader> first option is best, of course. but it's not blocking me. worst case I add a work around in qtmir (ie, no lock that call)
<dandrader> alan_g, ^
<alan_g> dandrader: if you do a workaround I suggest using "#if MIRAL_VERSION <= MIR_VERSION_NUMBER(1, 0, 0)"
<dandrader> alan_g, right, good point
<dandrader> alan_g, so the next miral release is gonna be 1.0?
<alan_g> dandrader: the last one was
<dandrader> oh
<dandrader> alan_g, is it in zesty?
<alan_g> yes
<alan_g> http://voices.canonical.com/alan.griffiths/2016/12/19/miral-1-0/
<dandrader> landed today, right. because it wasn't there yesterday
 * dandrader upgrades
<alan_g> landed yesterday, my afternoon
<alan_g> dandrader: https://code.launchpad.net/~alan-griffiths/miral/fix-1651422/+merge/313609
<alan_g> camako: the discussion comment I promised you yesterday: https://code.launchpad.net/~cemil-azizoglu/mir/mirsurfacespec-deprecation-2/+merge/313451/comments/814567
<camako> Thanks. I was just reading it.
<alan_g> 8-)
<_javier4_> Hi guys, I'm porting a device and now I'm stuck at the ubuntu animation boot logo (ubuntu text with dots moving). compositor log doesn't help, and now I'm seeing this messages in dmesg
<_javier4_> (1)[2353:VSyncThread_0][DISP][mtk_disp_mgr_ioctl #1956]ERROR:[session]ioctl not supported, 0x40104fd5
<_javier4_> (1)[2361:Mir/Comp][DISPCHECK]primary_display_switch_mode require sess_mode DIRECT_LINK
<_javier4_> repeated many times. Are they meaningful for my problem?
<greyback> _javier4_: sounds possible yes. Can you share the output of "/system/bin/logcat" and "$HOME/.cache/upstart/unity8.log" please
<greyback> /var/log/lightdm/unity-system-compositor.log too
<_javier4_> greyback, unfortunately logcat returns nothing, these are the logs you asked for
<_javier4_> http://pastebin.com/50CmQMTz
<_javier4_> http://pastebin.com/atis2u9q
<greyback> _javier4_: hmm unity-system-compositor does bring up GL ok (lots of warnings, but it appears to work since you see the splash)
<greyback> but something is wrong with unity8
<greyback> it is a mir server, which connects to unity-system-compositor (as a nested mir server)
<greyback> seems to fail to connect/start
<greyback> am unsure why
<_javier4_> is there something I can do to supply more debug messages?
#ubuntu-mir 2016-12-21
<duflu> Mesa 13 has landed. And my Unity8 no longer works. Related?
<duflu> Nope. Not related
<RAOF> WHY ARE ALL MY COMPUTERS EXPLODING?
<tsdgeos> who's the miral resident expert?
<duflu> tsdgeos: alan_g is on it
<alan_g> what's "it"?
<duflu> alan_g: MIR miral
<alan_g> Actually, greyback is running that
<duflu> anpok_: Did you/we change input event accumulation in the recent past? Clients of nested servers are seeing really erratic jagged motion I think...
<duflu> Oh nevermind. Just that sudo doesn't import exported environment settings from the parent shell
<alan_g> duflu: sudo --preserve-env
<duflu> Cool
<duflu> Joy to the world..... Mir will soon be rid of all input resampling
<duflu> Which gives me a feel for how much nicer Unity8 will feel in future
<_javier4_> Hi guys, I'm porting a device and now I'm stuck at the ubuntu animation boot logo (ubuntu text with dots moving). compositor log doesn't help, and now I'm seeing this messages in dmesg
<_javier4_> (1)[2353:VSyncThread_0][DISP][mtk_disp_mgr_ioctl #1956]ERROR:[session]ioctl not supported, 0x40104fd5
<_javier4_> (1)[2361:Mir/Comp][DISPCHECK]primary_display_switch_mode require sess_mode DIRECT_LINK
<_javier4_> repeated many times. Are they meaningful for my problem?
<_javier4_> this is unity8.log
<_javier4_> http://pastebin.com/50CmQMTz
<_javier4_> and this is unity-system-compositor.log
<_javier4_> http://pastebin.com/atis2u9q
<alan_g> _javier4_: I'm not the best one to help at this stage, but what the logs tell me is that the unity-system-compositor Mir server does start (which is why you see the animation) but that the Unity8 one fails. But I don't see any indication why that is.
<alan_g> greyback: ^^
<greyback> alan_g: qtmir reports that the mir server failed to start
<greyback> I don't really know how to suggest how to debug that
<alan_g> I'm surprised there's no logging from Mir after "[2010-01-05 20:47:21.436870] mirserver: Starting"
<alan_g> _javier4_: this is probably in the graphics driver support. The guy that knows that best for android drivers is not currently around (too early in his day and he's on vacation until the new year).
<_javier4_> ouch. Thanks for your help guys. But if the problem is in the android part, the system compositor shouldn't fail too?
<alan_g> _javier4_: if it failed completely, yes. But I suspect that some specific operation is working "differently" on your kit and only affects the nested U8 server. The place in the Mir code that collates the "known" differences is src/platforms/android/server/device_quirks.cpp
<alan_g> It likely needs debugging through to find out exactly what is failing (and why there is no helpful log message).
<alan_g> I'd go for using instances of the mir_demo_server (as system and session servers) in place of USC and U8 and trying to reproduce the problem.
<alan_g> That's an easier set-up (for me) to debug.
<_javier4_> alan_g, could you link a guide to set up mir demo server?
<alan_g> It is in mir-demos
<alan_g> Hmm. I don't have a guide for this scenario to hand. Let me search.
<alan_g> With mir-demos installed you need to shut down USC: sudo stop lightdm
<alan_g> You need to keep the screen on: mirbacklight
<alan_g> To start as a host: sudo mir_demo_server
<alan_g> (In a separate terminal) you can then run "nested" (with a demo client): mir_demo_server --host /tmp/mir_socket --launch mir_demo_client_egltriangle
<alan_g> Actually, a better command for the host would be: sudo mir_demo_server --window-manager system-compositor
<alan_g> But, with the way things are failing you probably won't get far enough for it to matter (yet).
<_javier4_> alan_g, the problem is that I still didn't complete the port. i didn't apply apparmor patch to my kernel, but just applied the ones needed to complete a boot. I don't know if I'm able to install packages.
<alan_g> _javier4_: ack. I don't have the knowledge to help with that.
<_javier4_> alan_g, do you know if mir-demos has dependencies other than a plain install? If I can avoid to setup a net connection, i would try to install it downloading it manually.
<alan_g> _javier4_: any dependencies should be met by the existing support for USC and U8
<_javier4_> ok. thanks.
<_javier4_> Sorry for my ignorance: should I search it as a click package or a snap one? I don't use Ubuntu since years, now...
<greyback> _javier4_: debian package
<_javier4_> greyback, this one?
<_javier4_> http://launchpadlibrarian.net/201141411/mir-demos_0.12.1+15.04.20150324-0ubuntu1_armhf.deb
<greyback> _javier4_: no, that's too old
<greyback> _javier4_: https://launchpad.net/%7Eci-train-ppa-service/+archive/ubuntu/stable-phone-overlay/+packages?batch=75&direction=backwards&memo=300&start=225 <- find the mir version for vivid
<_javier4_> but my Ubuntu touch rootfs is vivid.
<_javier4_> oh, ok.
<greyback> yes, Ubuntu Touch is vivid, plus a PPA supplying newer stuff (the PPA I linked to above)
<greyback> note to take care if you're mixing an older touch image with that PPA, PPA can have never stuff than your image. So match package versions carefully
<_javier4_> in that ppa I can't find mir-demos package.
<greyback> _javier4_: look for just "mir - 0.24.1+15.04.20160928-0ubuntu1" with vivid, then click the arrow to expand it
<greyback> inside is a big list of the deb packages, one of which is "mir-demos_0.24.1+15.04.20160928-0ubuntu1_armhf.deb"
<_javier4_> found. thanks a lot.
<_javier4_> greyback, just out of curiosity: that strange "nesting" of the package inside the repo, is due to mir being a metapackage or what?
<greyback> _javier4_: good question. In that listing, you see "source packages" which contain the source code for the project. Then that package is taken and built for each distro and each architecture, which is nested inside in that listing
<_javier4_> greyback, Now I understand. Launchpad store the whole "projects", then shows you the various packages in which they have been split into. Thanks again.
<greyback> no prob!
<_javier4_> and now, this is the situation:
<_javier4_> system compositor start fine, while nested one fail with this (finally meaningful) error
<_javier4_> [2010-01-06 15:36:43.228679] mirplatform: Found graphics driver: mir:android (version 0.24.1)
<_javier4_> [2010-01-06 15:36:43.232091] mirserver: Starting
<_javier4_> ERROR: /build/mir-coQbl3/mir-0.24.1+15.04.20160928/src/server/graphics/default_configuration.cpp(132): Throw in function mir::DefaultServerConfiguration::the_graphics_platform()::<lambda()>
<_javier4_> Dynamic exception type: N5boost16exception_detail10clone_implINS0_19error_info_injectorISt13runtime_errorEEEE
<_javier4_> std::exception::what: Exception while creating graphics platform
<_javier4_> ERROR: /build/mir-coQbl3/mir-0.24.1+15.04.20160928/src/server/graphics/nested/mir_client_host_connection.cpp(245): Throw in function mir::graphics::nested::MirClientHostConnection::MirClientHostConnection(const string&, const string&, const std::shared_ptr<mir::shell::HostLifecycleEventListener>&)
<_javier4_> Dynamic exception type: N5boost16exception_detail10clone_implINS0_19error_info_injectorISt13runtime_errorEEEE
<_javier4_> std::exception::what: Nested Mir Platform Connection Error: Failed to connect to server socket: No such file or directory
<_javier4_> Sorry, I should have used pastebin.
<greyback> _javier4_: "Failed to connect to server socket: No such file or directory" have you set MIR_SOCKET correctly? And do take care with permissions of the socket
<_javier4_> greyback, I followed strictly alan_g suggestions, and launched nested compositor passing --host /tmp/mir_socket
<greyback> _javier4_: well let's trouble-shoot: please check that /tmp/mir_socket exists, and see what permissions it has
<_javier4_> actually, it doesn't exists at all.
<greyback> ok, so it should have been created by the first mir_demo_server
<greyback> is /tmp writable?
<_javier4_> yes
<_javier4_> drwxrwxrwt    4 root   root      80 Jan  6 15:17 tmp
<greyback> _javier4_: ok, well please stop all mir servers, and do "sudo mir_demo_server -f /tmp/mir_socket" to ensure mir creates that file
<greyback> and verify socket file is created
<_javier4_> srwxr-xr-x 1 root root 0 Jan  6 15:49 mir_socket
<_javier4_> try to launch the nested one?
<_javier4_> greyback,
<_javier4_> [2010-01-06 15:52:31.331620] mirserver: Using nested cursor
<_javier4_> [2010-01-06 15:52:31.341012] mirserver: Initial display configuration:
<_javier4_> [2010-01-06 15:52:31.347749] mirserver:   0.1: LVDS 5" 57x101mm
<_javier4_> [2010-01-06 15:52:31.348514] mirserver:        Current mode 1080x1920 53Hz
<_javier4_> [2010-01-06 15:52:31.349704] mirserver:        Preferred mode 1080x1920 53Hz
<_javier4_> [2010-01-06 15:52:31.350017] mirserver:        Logical position +0+0
<_javier4_> [2010-01-06 15:52:31.350111] mirserver:   0.2: unused DisplayPort
<_javier4_> [2010-01-06 15:52:31.350362] mirserver:   0.3: unused (null)
<_javier4_> *** Error in `mir_demo_server': free(): invalid pointer: 0x001bf9c8 ***
<_javier4_> Aborted (core dumped)
<greyback> _javier4_: well we need to find the host server's socket
<greyback> hmm, I don't like that error
<greyback> _javier4_: can you pastebin the output of "dpkg -l | grep mir"
<_javier4_> greyback, http://pastebin.com/MX5QLdRF
<greyback> ok good, package versions are matching
<greyback> right, so please kill the root mir server, and launch again with "sudo mir_demo_server -f /tmp/mir_socket"
<greyback> oh hang on
<greyback> sorry, I mis-read your output above
<greyback> so you have a /tmp/mir_socket?
<_javier4_> yes
<greyback> ok, let's connect a client to it, just to check it works, run mir_demo_client_egltriangle
<_javier4_> that's what fail with the pointer error
<greyback> the demo client?
<_javier4_> root@ubuntu-phablet:~# mir_demo_server --host /tmp/mir_socket --launch mir_demo
<greyback> too soon, I don't want to test nested server just yet
<greyback> I just want to check that any client can connect to your host server
<_javier4_> oh, ok. Sorry. I'm new to all this stuff.
<greyback> no worries :)
<_javier4_> Should I kill system server?
<greyback> nope, that's good, keep it running
<_javier4_> no error, but black screen. Let me kill the server and try from scratch.
<greyback> _javier4_: ok. You should see a spinning triangle
<greyback> also good to try mir_demo_client_flicker
<alan_g> _javier4_: I forgot an option (to make the socket file accessible) for the "host": sudo mir_demo_server --window-manager system-compositor --arw-file
<_javier4_> wait. A found a bunch of mir process hanging around on my system. I killed them all. Correct me if I'm wrong:
<_javier4_> mirbacklight, to get backlight;
<alan_g> Yes, that keeps the screen on
<_javier4_> mir_demo_server --window-manager system-compositor --arw-file, to start system compositor
<alan_g> yes. now /tmp/mir_socket should be globally rw
<_javier4_> it isn't. I think it's still the one we specifically created before.
<_javier4_> *explicitly
<_javier4_> ls -l /tmp
<_javier4_> total 0
<_javier4_> srwxr-xr-x 1 root root 0 Jan  6 15:49 mir_socket
 * alan_g reads scollback because that sounds wierd
<_javier4_> I can delete it, kill server and relaunch it. I think it will not be created.
<alan_g> _javier4_: do that
<_javier4_> ok. Just wait.
<_javier4_> As suspected: launched system comp with mir_demo_server --window-manager system-compositor --arw-file, but the file has not been created. Should I pass it -f flag?
<_javier4_> I suspect $MIR_SOCKET is not set
<alan_g> _javier4_: $MIR_SOCKET should not be set
<alan_g> have you lost "sudo" from the commandline?
<_javier4_> no, I'm from root
<_javier4_> I'm root user.
<alan_g> The server is running?
<alan_g> I.e. didn't exit/crash
<_javier4_> yes http://pastebin.com/SxXmzAT4
<alan_g> is $XDG_RUNTIME_DIR set?
<_javier4_> echo $XDG_RUNTIME_DIR
<_javier4_> "/run/user/0"
<_javier4_> quotes needed for irc
<alan_g> Ah, then the mir_socket will be there
<alan_g> ls -l $XDG_RUNTIME_DIR/mir_socket
<_javier4_> yes it is
<_javier4_> ls -l /run/user/0
<_javier4_> total 0
<_javier4_> srw-rw-rw- 1 root root 0 Jan  6 16:13 mir_socket
<alan_g> Cool
<alan_g> So now: mir_demo_client_egltriangle -f /run/user/0/mir_socket
<alan_g> So now: mir_demo_client_egltriangle -f -m /run/user/0/mir_socket
<alan_g> Oops!
<_javier4_> which one?
<alan_g> the latter
<alan_g> Use this: mir_demo_client_egltriangle -f -m /run/user/0/mir_socket
<_javier4_> Mir chose pixel format 1.
<_javier4_> Using pixel format 2.
<_javier4_> Current active output is 1080x1920 +0+0
<_javier4_> Can't create a surface
<alan_g> Try: mir_demo_client_egltriangle -f -m /run/user/0/mir_socket -o 1
 * alan_g is guessing the output ID
<_javier4_> Mir chose pixel format 1.
<_javier4_> Using pixel format 2.
<_javier4_> Current active output is 1080x1920 +0+0
<_javier4_> WARNING: linker /android/system/vendor/lib/libPVROCL.so: is missing DT_SONAME will use basename as a replacement: "libPVROCL.so"
<_javier4_> library "libPVRDebugger.so" not found
<_javier4_> Surface 0 DPI
<_javier4_> Surface exposed
<_javier4_> but still black screen. :-/
<alan_g> mirbacklight?
<_javier4_> first time I set it, I rememeber I've seen the backlight turning on. Now I'm not sure.
<alan_g> try it now
<_javier4_> Already done. But sincerely I can't say if ther was already on, or if they're staying black.
<_javier4_> reboot the phone and start from scratch?
<alan_g> First try replacing mir_demo_client_egltriangle with mir_demo_client_muitlwin (which doesn't use EGL)
<alan_g> *mir_demo_client_multiwin
<_javier4_> mir_demo_client_multiwin
<_javier4_> Segmentation fault (core dumped)
<alan_g> Although the animation does use EGL, so that *shouldn't* be the problem
<alan_g> I guess a reboot can't hurt
<_javier4_> ok. Be back soon
<_javier4_> stop lightdm
<_javier4_> whoops, wrong window. :D
<_javier4_> I now know what's wrong: after stopping lightdm, backlight turn off. Issuing mirbacklight they turn on for a second, then they turn off and don't resume even with following mirbacklight.
<_javier4_> they result still set
<_javier4_> cat /sys/class/leds/lcd-backlight/brightness
<_javier4_> 255
<alan_g> That's odd. try: mirbacklight 95
<alan_g> I've a vague memory of a driver that didn't like to use max_brightness
<alan_g> greyback: IIRC you mentioned some backlight issues in the past. Does the above sound familiar?
<_javier4_> nothing.
<_javier4_> let me reboot, and check the values of lcd-backlight before stopping server.
<greyback> alan_g: actually yes, mirbacklight only works for some devices
<greyback> on one phone the lcd backlight wasn't in the standard location
<_javier4_> sysfs is right. It starts from 102, then goes to 10, then to 0. If I try to set it again on 102, it stays black.
<_javier4_> greyback, alan_g : I'm trying to debug my backlight problem. I noticed this thing:
<_javier4_> If I echo 0 to the brightness, screen goes off, and if I echo 102 it turns back on. But if I turn it off by power button, my following echo 102 doesn't work.
<greyback> yeah that is odd
<_javier4_> It's like if the power button (and the stopping lightdm) does not seto brightness to 0, but changed also somebody else.
<_javier4_> i tried to monitoring by udev, but I just discovered the real sysfs for my driver. nothing else.
<_javier4_> perhaps power button issue also some kind of suspend mode for lcd?
<fritsch> RAOF: does mir support higher precision than 888 RGB visuals=?
<RAOF> fritsch: Not at the moment; we don't expose any 101010 pixel formats.
<fritsch> RAOF: isn't it a display driver thingy, too?
<fritsch> i only see 8 8 8 visuals for my intel gpu anyways
<RAOF> It'll do 101010
<RAOF> (Probably âº)
<fritsch> how can one force that mode from userspace?
<RAOF> You can't.
<RAOF> You need whatever's providing the display buffers to be providing 101010 display buffers.
<RAOF> (Which means either X, GNOME Shell, Plasma, or Mir)
<fritsch> that won't help if you cannot open a corresponding visual
<RAOF> Indeed.
<fritsch> ah, that's what you mean
<fritsch> yeah
<RAOF> So, *mesa* is perfectly happy to render to 101010 textures.
<fritsch> internally even 16 bit and more precision
<RAOF> AFAIK, all the desktop cards are happy to scan out of 101010 buffers.
<RAOF> Oh, yeah. You can render to full-float buffers if it tickles your fancy!
 * RAOF doesn't know about double precision.
<fritsch> https://github.com/xbmc/xbmc/blob/8d4a5bba55638dfd0bdc5e7de34f3e5293f99933/xbmc/windowing/X11/WinSystemX11GLContext.cpp#L176
<RAOF> The missing bit is hooking them all together.
<fritsch> I searched a solution for kodi
<fritsch> now since we can decode hevc10 bit and share it lossless via R16, G16 extension
<fritsch> to get it on the display
<fritsch> https://lists.freedesktop.org/archives/mesa-dev/2016-December/138472.html <- btw. you don't have a say there? Seems no one cared for now
<RAOF> I don't have commit access or anything.
<fritsch> no need to commit, but not a comment since 5 days is quite uncommon
<RAOF> I can comment, but I'm not sure how useful it'll be. I'm not very involved in mesa development.
<RAOF> (And the patches I've submitted have also tended to languish, sometimes until somebody independently reimplements them)
<fritsch> if you find that patch useful it would be nice
<fritsch> your MIR kodi port / vaapi will also directly be able to use that
<fritsch> for decoding 10 bit content
<RAOF> vaapi spits out two planes when decoding 10 bit content?
 * RAOF would naively expect it to spit out a packed XRGB 2101010 plane. But whatever!
<fritsch> RAOF: nope
<fritsch> and we certainly don't want RGB
<fritsch> as that's doulbe as big as NV12
<RAOF> Oh, of coures.
<fritsch> we want as minimal as possible and use a yuv2rgb shader at the end
<RAOF> It's 10bit, encoded in a different colourspace.
<fritsch> to get it displayed
<fritsch> it's just yuv420p10 with more precision
<RAOF> I'm a bit confused about the R16/GB16 extension, then. Where does that come in?
<fritsch> RAOF: https://github.com/FernetMenta/kodi-agile/blob/master/xbmc/cores/VideoPlayer/DVDCodecs/Video/VAAPI.cpp#L1298
<fritsch> https://github.com/FernetMenta/kodi-agile/blob/master/xbmc/cores/VideoPlayer/DVDCodecs/Video/VAAPI.cpp#L1376 <- sorry
<fritsch> here of cours
<fritsch> we use it for eglCreateImage extension
<fritsch> to create Y and UV plane
<RAOF> Oh, right. You're not actually using them as RGB channels, just as storage.
<fritsch> jep
<fritsch> we avoid converting anything until display
<fritsch> (not entirely true, we did not invest time to make your lanczos scaler work on yuv ...)
<fritsch> so it runs after rgb conversation
<fritsch> I got to go - already late here. will read the backlog tomorrow
<RAOF> 5oo/
#ubuntu-mir 2016-12-22
<_javier4_> alan_g, I'm here again. Is there a way to stop automatic backlight dim-down? I would try if the first mirbacklight can be made persistent.
<alan_g> _javier4_: AFAICT it is a problem with the drivers on your system. It isn't something I see on the devices I test with.
<alan_g> _javier4_: Here's another approach. (I can't test if it works.) https://wiki.ubuntu.com/powerd
<_javier4_> alan_g, it seems to work. :D
<_javier4_> starting the nested compositor this way
<_javier4_> mir_demo_server --window-manager system-compositor
<_javier4_> exit with this error
<_javier4_> ERROR: Throw location unknown (consider using BOOST_THROW_EXCEPTION)
<_javier4_> Dynamic exception type: N5boost16exception_detail10clone_implINS0_19error_info_injectorINS_6system12system_errorEEEEE
<_javier4_> std::exception::what: bind: Address already in use
<_javier4_> I see the triangle!
<_javier4_> even a grey bar on the first lines of pixels.
<_javier4_> and a mouse pointer on oxo position. :-/
<_javier4_> 0x0
<_javier4_> alan_g, once I've got system mir running, and triangle test succeded, how should I launch the nested server?
<alan_g> where does your host server put the mir_socket endpoint?
<alan_g> mir_demo_server --host <host endpoint> --file <somewhere else>
<alan_g> _javier4_: I'll have to leave you to check scrollback. (I have to take my wife to dinner.)
<_javier4_> Priorities. :D
<_javier4_> are you sure the flag is --host and not --host-socket?
<alan_g> It can be abbreviated
<alan_g> [I think]
<_javier4_> ok. Then I have to connect to main socket and create a different one for the nested,right?
<_javier4_> Thanks, and have a good dinner.
#ubuntu-mir 2016-12-23
<_javier4_> I tried various mir_democs_client_, and they work if I launch the nested mir server specifying a socket different from the system's one. I suspect this is the same problem that blocks my normal server to start. I'm trying to understand the graphical boot chain of unity8 to test it, any hints?
#ubuntu-mir 2016-12-24
 * javier4 Hi all. Is there a way to make Lightdm set a specific socket file for nested server in a unity8 session?
#ubuntu-mir 2016-12-25
<javier4> do you think this message from lightdm upstart service log can be the cause of my ubuntu touch screen keep showing loading animation?
<javier4> ** (lightdm:2284): WARNING **: Error updating user /org/freedesktop/Accounts/User32011: GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: No such interface 'org.freedesktop.DBus.Properties' on object at path /org/freedesktop/Accounts/User32011
