#ubuntu-mir 2013-05-13
<kode54> heh, running mir as system compositor with X seems to be broken at the moment, at least with nouveau
<thomi> robert_ancell: ping?
<robert_ancell> thomi, hello
<thomi> robert_ancell: this may be a stupid question, but... in a mir (X-less) world, where is the keyboard keymap configured?
<robert_ancell> thomi, I'm not sure
<robert_ancell> thomi, racarr was looking into that I think
<thomi> I guess racarr would know, but I suppose it's still the weekend for him
<thomi> I'll grab him tomorrow, thanks
<mlankhorst> kode54: worksforme, anything in dmesg?
<RAOF> alf__: Good morning!
<alf__> RAOF: Good morning!
<alf__> RAOF: or rather, good afternoon
<RAOF> :)
<tvoss> Good morning :)
<alf__> tvoss: good morning!
<tvoss> alf__, hey, how are you?
<alf__> tvoss: great, you?
<tvoss> alf__, likewise :)
<tvoss> RAOF, ping
<RAOF> tvoss: Pong, but about to extract ZoÃ« from the bath.
<tvoss> RAOF, ack, no rush
<tvoss> RAOF, could you ping me if you find 5 minutes today?
<RAOF> tvoss: Sure. Probably after putting ZoÃ« to sleep.
<tvoss> RAOF, sure
<tvoss> greyback, ping
<greyback> tvoss: pong
<RAOF> tvoss: Yo.
<hikiko_> alf___, ping
 * alf___ wonders how he ended up with so many undescores
<alf___> hikiko_: hi
<hikiko_> hi :)
<hikiko_> I was looking at your gbm_display.cpp
<hikiko_> the configure function
<hikiko_> I didn't understand everything to be honest :)
<hikiko_> you create the display buffer isn't it? which is the gbm buffer that will fill the EGLImage later?
<alf__> hikiko_: the configure() method is an early version of what will become the mechanism to handle multiple displays in the future. Right now it just produces the same output on all displays (possibly cropped on some of them).
<hikiko_> and what are the kms outputs?
<alf__> hikiko_: (For SDL I don't think you will need any of this.)
<hikiko_> yes that's what I thought too but I guess I need the code that creates the gbm buffer?
<hikiko_> or maybe not
<hikiko_> ah I can do what kevin did in the android platform using a gbm buffer instead of an android one probably
<alf__> hikiko_: KMSOutput wraps an "output" (i.e. an attached screen) as defined by DRM/KMS, it is an internal abstraction which you don't need in SDL
<alf__> hikiko_: There is the notion of DisplayBuffer, which is a framebuffer which is meant to provide the contents for one or more outputs. On Android, which currently supports one output, the AndroidDisplay class is also a (implements the) DisplayBuffer interface
<alf__> hikiko_: gbm uses separate objects to provide DisplayBuffers
<hikiko_> so, I can implement display and display buffer in SDLDisplay as kevin did and leave the configure etc parts :)
<hikiko_> cool! :D
<hikiko_> thank you alf__ :)
<alf__> hikiko_: The display side of SDL is completely independent of GBM (and Android, of course). There is probably no code you can sanely share between these display backends.
<hikiko_> what i did so far was to use the gbm helper and gbm buffer allocator as it is
<hikiko_> initialize the context using sdl, and now I am looking what I need from the egl part (I didn't use the egl helper yet because I am looking at android impl to see if I can modify this version to use my sdl context :)
<hikiko_> but I guess it should work
<alf__> hikiko_: ok, for the display you shouldn't need to mess with GBM at all. Suggestion: as a first step create only the SDLDisplay(Buffer) and make sure that you can run examples/render_to_fb.
<alf__> hikiko_: then implement/reuse the buffer allocator and ensure that render_surfaces run
<alf__> s
<hikiko_> ok, but for the step 2, do I have to implement a buffer allocator? can't I use the gbm one as it is?
<hikiko_> ah no, it's not platform independent
<hikiko_> it has a private shared ptr to gbm platform
<hikiko_> ok
<hikiko_> I start step one :) thank you :)
<alf__> hikiko_: for step two, the dependency of GBMBufferAllocator on gbm platform is not a real one... we actually only need the gbm device pointer (which in theory the SDL platform could provide too). RAOF will need to make this change in order to split display/buffer_allocator anyway (but I am not sure how the split is progressing).
<alf__> hikiko_: but one step at a time!
<kdub> morning, today getting started on a bit of performance investigation
<alan_g> Afternoon
<kdub> hello alf__, are you back?
<alf__> kdub: Hello! Yes, I am back.
<kdub> yay, welcome back
<greyback> kdub: hey, I'm still struggling with a segv in integrating unity & mir
<greyback> kdub: mind if I borrow you for a while?
<kdub> greyback, sure (have a meeting in 30 though)
<greyback> kdub: ok, well I'll be EODing soon, so let me put instructions in a mail, and hopefully you'll be able to repro my issue
<racarr_> arsenm:/win goto 10
<racarr_> Err...wow
<racarr_> on another note
<racarr_> good morning!
<tvoss> kgunn, ping
<kgunn> pong
<kgunn> tvoss: pong
<racarr_> Someone gave me an extra monitor yesterday for my new place annnnd...
<racarr_> turning it on causes unity to segfault :(
<racarr_> greyback: Got your email...not sure of the top of my head hopefully will come up with an idea soon
<racarr_> I will be going through all this again today too...
<racarr_> took a week off so its kind of hard to remember anything :)
<greyback> racarr_: no worries, I'm just glad you're around so I can ask dumb questions :)
<racarr_> greyback: electric-fence
<racarr_> libefence.so is the preload
<kode54> mlankhorst: that depends on whether unity-system-compositor is a required package
<kode54> I had to modify the control in that package because it required an older version of libmirserver0
<mlankhorst> come again?
<mlankhorst> oh nm
<kode54>  unity-system-compositor : Depends: libmirserver0 (= 0.0.2bzr676raring0) but 0.0.2bzr678raring0 is to be installed
<mlankhorst> yeah good enough reason for nouveau not to work :)
<kode54> ahahaa
<kode54> not nouveau then
<kode54> I managed to install that package from source, but it still doesn't work
<kode54> there's also a "mir" package, don't know if I need that one
<kode54> it fails to install because it depends on libmirserver0 0.0.2bzr643raring0
<kode54> the source package for the same thing is 0.0.2bzr678raring0
<mlankhorst> well, is there anything in dmesg?
<mlankhorst> soomething like failed to validate yadda yadda
<racarr_> Thanks for chatting all :) was useful to get things loaded back in my head
<kode54> nothing about failed to validate
<kode54> there is a notice that VBIOS is valid
<kode54> and a pile of ACPI notices with Namespace lookup failure attached to them
<racarr_> If we have some data
<racarr_> that we model by some function like cpu_usage(timepoint)
<racarr_> it's interesting to see
<racarr_> integral from start of frame to end of frame
<racarr_> of the derivative of cpu_usage
<racarr_> which gives us some idea of the
<racarr_> right this number will be high if
<racarr_> we have many wakeups spread in to seperate peaks of usage
<racarr_> vs low if we have a single peak of usage in the frame
<tvoss> racarr_, we can do that post-mortem with lttng easily
<racarr_> Mm.
<racarr_> I am just saying it's a good number to look at
<racarr_> we were just talking about good numbers to measure and track on a hangout :)
<tvoss> racarr_, ah :)
<tvoss> racarr_, did you fix greyback's problems, yet?
<racarr_> not yet. we had a shell sync up, then talked about inprocess EGL then talked about performance
<racarr_> and now I am going through what greyback did to start to reproduce it
<racarr_> I have a pretty strong suspiscion
<racarr_> of what it i
<racarr_> s
<racarr_> :)
<racarr_> I think it's just API changes between android inprocess EGL and GBM inprocess EGL
<racarr_> masked by a reinterpret_cast
<racarr_> so I think the solution is really
<racarr_> get all these branches landed with an integration test
<racarr_> tvoss: Did you say riccm was looking after platform-api now?
<tvoss> racarr_, yup
<tvoss> racarr_, who is working on the integration test stuff? is that you?
<racarr_> tvoss: Not really. I'll harass thomi though and work with him
<tvoss> racarr_, thomi?
<racarr_> my immediate task is to make qt-mir-inserver and qt-mir-outofserver co installable, clean up more of the shared code, and make the platform-api and qtubuntu mergeable
<racarr_> tvoss: He is our QA friend.
<tvoss> racarr_, sounds good :)
<racarr_> tvoss: Basically what I want to get in place is some sort of automatic test that runs a Qt app against a real mir binary
<racarr_> and a mir binary with an inprocess Qt app
<tvoss> racarr_, sounds sane
<racarr_> and just verifies that it appears to work :)
<racarr_> there is a deeper and missing level of testing needed
<racarr_> i.e. the event translation from application API -> Qt
<racarr_> is quite complex.
<racarr_> and not really covered atm
<racarr_> YAY multimonitor
<racarr_> not in mir ;) I just mean on my desk.
<racarr_> ok now platform-api :)
<smag> Is anyone aware if someone is working on X11 for Ubuntu-touch?
<kdub> smag, there's xmir
<kdub> probably about the closest thing at the moment
<smag> ok, I'll check it out
<racarr_> Hmm
<racarr_> nvm :)
<racarr_>  </lunch>
<racarr_> Hit the point in merging platform-api mirserver and mirclient branches and cleaning up where I need to pick things out from input-conglomeration ;) so working on that
<kgunn> racarr_: :)
<kgunn> racarr_: did gerry ever ping back w electric fence results on the segfault?
<racarr_> kgunn: No but upon inspection I know exactly what it is
<racarr_> well
<racarr_> thought
<racarr_> reflection
<racarr_> something-ion
<racarr_> just platform-api-mirserver need to be updated to the new inprocess API
<racarr_> to use the internal client helper to get the native window type
<racarr_> rather than just cast the mir::frontend::Surface (works on GBM, not on android)
<racarr_> :)
<kgunn> racarr_: sweet
<racarr_> im merging platform-api-mirserver and platform-api-mirclient in to one great branch now and extracting the dependencies that I had left around and proposing those for merge
<racarr_> then syncing up with riccm to figure out how to land it all
<racarr_> so hopefully should unblock shell tomorrow
<kgunn> racarr_: seriously...that will be so awesome
<racarr_> Speaking of dependencies I need to land...;)
<racarr_> kdub: /+who else is alive? https://code.launchpad.net/~robertcarr/mir/enable-and-demonstrate-inprocess-input/+merge/163615
<racarr_> When you have time
<racarr_> (simple)
<kdub> racarr_, sure
<racarr_> 90% cmake ;)
<kdub> i was wondering what was happening today...
<thechef> If I had an application which wants to repeat the behaviour of Mir in order to act as a display manager for its sub applications (e.g. I want to fire up konversation in the Gordon Freemans Office in Half-Life 3). Is Mir capable of supporting this situation well, or will it fail compared to wayland, because it doesn't strictly follow the unix rules where one tool does one job, while Mir does 2 by including server side buffer allocation?
<thomi> hey racarr_
<racarr_> Hi thomi :)
<thomi> racarr_: you were looking for me earlier?
<kdub> thechef, it wouldnt be doing 2 jobs any more than any other display server does
<racarr_> thomi: Yes. I wanted to ask you about sort of cross bit integration tets for qt+mir
<racarr_> but I am getting ready to walk to a coffee shop in like 10 minutes then context switch time (from platform-api)
<racarr_> so lets sync up then?
<racarr_> thechef: The scenario you describe is rather similar to mirs primary use case ;)
<racarr_> where the session compositor mir (Unity) runs as an embedded display server
<racarr_> in the system compositor mir
<thomi> racarr_: sure
<racarr_> which has non user things like login screen, etc.
<thomi> BTW people, I have a suspicion that the packages in mir-team/staging are causing my desktop raring machine to not start Unity.
<thomi> haven't confirmed that yet though, but it's the most likely candidate
<racarr_> hmm
<racarr_> im having weird unity issues too lately but unrelated
<racarr_> just added that ppa on this system today
<racarr_> though I guess I had most of the things from it...
<racarr_> unity will fail to start because dbus is completely screwed and then I have to reboot (haven't managed to unscrew dbus so far)
<thechef> racarr_: and which instance of mir handles which buffers?
<racarr_> the system mir allocates buffers from the gpu and hands them out to the session mirs, and it's normal clients (i.e. lightdm)
<racarr_> the session mir hands out buffers from the system mir
<racarr_> i.e. the same way that mir can use gbm or android gralloc as a buffer source mir will use mir as a buffer source
<racarr_> but I mean, if half life 3 wants to let you run konversation, it links against libmirserver
<racarr_> subclasses the renderer, with something that renders to some FBO like it wants rather than the framebuffer
<racarr_> and acts like a normal mir, konversation talks to it, asks for some buffers, it asks the session mir (that the app/game is running inside of) for some buffers, so on (ignoring optimizations...lots of subcases)
<racarr_> not something we have thought about a lot (besides the session/system compositor case)
<racarr_> but it's certainly doable.
<thechef> okay, thanks. Good to know.
<racarr_> :) np
<racarr_> I think more so than buffer "allocation" it's interesting to think about buffer distribution and ownership
<racarr_> and the theory behind server side allocation is just that they are a shared centralized resource, and the display server will be in the best position to make decisions about distribution and ownership i.e. who gets what buffers when
<racarr_> as it has the most info
<racarr_> this way, rather than doing two jobs, mirs job is "Provide clients with a stream of buffers"
<racarr_> aha sorry...I seem to enjoy typing today ;) new office so im a little overexcited.
<thechef> It's seems to be some sort of a Zaunpfahl-Problem whether you choose to do server side or client side allocation. But what I find weird is the handing over of single frames, because sometimes the display server is going to know really bad WHEN an application should receive the buffer. Assume you want freshest frames. The client is better able than the server to estimate (e.g. according to the content of it's GL frustum) rendering time
<thechef> and to decide when it should start drawing.
<racarr_> greyback: Around? (This is super late for you isn't it?)
<greyback> racarr_: just about to go to bed, but go on
<racarr_> greyback: Oh no worries then. Was just going to say think the issue is fixed in ~robertcarr/platform-api/mir but haven't gotten to test it yet (still reconstructing qtubuntu and getting things out of input-conglomeration)
<racarr_> it was just, on gbm, the EGLNativeWindowType is the msh::Surface but on the new android stuff
<racarr_> you have to use this factory helper thing to contruct it
<racarr_> so ubuntu_application_ui_get_egl_native_window had to be updated
<racarr_> maybe it was another segfault but that would definitely segfault shortly after creating the surface :)
<greyback> ok cool, that's somewhere for me to start tomorrow
<greyback> racarr_: appreciated, thanks! :)
<racarr_> sleep well :)
<racarr_> will have an email for you with updated (slightly simplified so far ;)) branches
<greyback> racarr_: and good night to you too
<racarr_> kdub: Hey on the subject of mir::client::input
<racarr_> I don't want to put it in to just mir::input because it's all about receiving
<racarr_> but mir::client is misleading...
<racarr_> so what about...mir::input::receiver
<racarr_> ?
<kdub> yeah... i think we were on to something today when we said we need another word other than client
<kdub> racarr_, i think that is better
<racarr_> yes. I agree it's a hard lingual problem though XD
<racarr_> on the input side it's easier
<racarr_> because it's all about being a receiver
<racarr_> but in general its not so clear
<racarr_> Patron
<racarr_> XD
<racarr_> mir::graphics::Platform::create_internal_patron
<racarr_> ...maybe not
<racarr_> It's not a consumer
<racarr_> We could call it a customer and then we can have business logic
<kdub> hah, mir::graphics::Platform::synergize
<racarr_> of course, that just composes the Patron and the Business Logic
<racarr> I think this word has the potential to be misleading because 95% of the time in our domain it refers to a human consumer of software
<racarr> but really what we mean by client
<racarr> is user
<racarr> or maybe we want client and the problem is that we have a "client" library
<racarr> as opposed to a.......*spins hand*
<racarr> I dunno "application" library
<racarr> the root of these confusing names, is libmirclient implies that
<racarr> "Hey this is the library for mir clients"
<racarr> likewise with the mir::client:: namespace
<racarr> this is the namespace for mir client machinery
<racarr> so this inprocess client conflicts
<racarr> so mir::client::* and libmirclient might be too generally named
<racarr> so libmirapplication becomes the library toolkits link against, the exiting client library machinery moves to mir::application
<racarr> mir::client::application?
<racarr> and common stuff (like input machinery, EGL bits(??), types, etc)
<racarr> can live in mir::client::
<racarr> *shrug*
<racarr> ...
<racarr> uhoh
<racarr> namespace mir = mir::input::receiver
<kdub> heh, mirec?
<racarr> kdub: I don't know maybe this is a sign that mir is misnamed
<racarr> it needs salting to prevent collision, i.e. mirzzz773#
<racarr> :p sorry...bored renaming things and waiting for compiles
<kdub> racarr, with the "internal clients", "inprocess egl", i think the term 'client' can be reserved for the normal ipc, non priveleged client
<kdub> lots of good synonyms for client to choose from, for the 'inprocess/internal' things though
<kdub> http://thesaurus.com/browse/client
<kdub> lackey, minion, parasite, vassal,...
<kdub> ShellSidekick
<racarr> Ahahaha vassal
<racarr> mir::graphics::Vassal
<racarr> kdub: Pushed updates to enable-and-demonstrate-inprocess-input
<racarr> with the input::receiver namespace anddddddddd
<racarr> removed the reinterpret cats
<racarr> casts...
<racarr> Good morning!
<kdub> racarr, i think this one is ok without the renames (we can address that later)
<kdub> racarr, what about line 200 'todo: does this belong?'
<racarr> kdub: Mm, well at least for now it isn't using
<racarr> ::client anymore
<racarr> um
<racarr> Oh
<racarr> I put that there so we would think about exposing it because I just did it really quickly in oakland...
<racarr> tbh I'm not sure why I was concerned about it, I think it was just a general I don't want to think about this right now
<racarr> are you concerned? XD
<kdub> well, it doesn't seem 'wrong' that it would be exposed
<kdub> just trying to avoid confusing comments
<kdub> but other than that, it looks ok
<racarr> ok just removed the comment
<racarr> sorry, normally grep for TODOs...
<racarr> there are lots in all the code from oakland, haha, basically everytime a question crossed my head that didn't block running unity I was like
<racarr> ok record it in a TODO
<racarr> r654
<kdub> racarr, +1ed, once jenkins scans it
<racarr> Thanks :)
<racarr> Looking at some ot her stuff in input-conglomeration
<racarr> now that unity is so close to running in a sane way
<racarr> it doesn't seem worth landing the software cursor in demo shell
<thomi> RAOF: got a second?
<thomi> whenever I have the mir-team staging PPA enabled, unity3d won't start and spits out X errors - I wonder if you have any idea what's going on?  http://paste.ubuntu.com/5662858/
<thomi> "Error: GL_ARB_vertex_buffer_object not supported" sounds bad
<thomi> it seems like whatever is in the ppa causes the DRI driver to not load :(
#ubuntu-mir 2013-05-14
<racarr> thomi: Sorry we don't assure quality so you'll have to talk to the QA guy...
<racarr> :p
<racarr> I don't have any ideas though
<racarr> there is a mismatch between your libdri and mesa and kernel!
<racarr> that was my only idea and I think
<racarr> it's pretty unlikely
<RAOF> thomi: Oh, yeah.
<RAOF> thomi: You've got an XMir-enabled video driver (most likely xserver-xorg-video-intel) but not an XMir-enabled server.
<thomi> RAOF: that would be -nvidia in mcase
<thomi> RAOF: so... I can't run unity3d with the /staging PPA added, and I can't run mir without it. How do you guys do mir development? run KDE or something?
<RAOF> My unity3d actually works, but with software rendering.
<RAOF> But I'll upload a new xserver to the staging PPA and fix the cause.
<thomi> RAOF: thanks, can youplease ping me when the dput is done?
<RAOF> Sure.
<kdub> RAOF, could it be because of http://bazaar.launchpad.net/~mir-team/mir/trunk/view/head:/include/client/mir_toolkit/mir_client_library.h#L194
<kode54> is the correct procedure for testing mir as a compositor for X to add the staging PPA and install mir_demos?
<kode54> also dist upgrade
<RAOF> kode54: Add the staging PPA, install unity-system-compositor, set âtype=mirâ in /etc/lightdm/lightdm.conf.
<RAOF> But do this after I've unbroken X :)
<kode54> ah
<kode54> yeah, I did that last night, and X was apparently broken
<RAOF> kdub: Well, I'll need to update for that too, clearly :)
<kode54> and the docs said type=unity
<kode54> my current installation with bzr678, X starts, but only without a type= argument
<kode54> I didn't know about the type=mir
<RAOF> The docs are more likely to be right than me.
<RAOF> :)
<kode54> ah
<kode54> docs said type=unity, and that fails to start and attempts low graphics mode
<kdub> RAOF, i got it to compile: http://pastebin.ubuntu.com/5662955/
<kode54> leaving a permanent unity demo server red cursor on screen
<kdub> haven't gotten xmir to run though
<RAOF> kode54: Oooh, that probably shouldn't happen :)
<kode54> er, mir demo server
<RAOF> kode54: Just to check - you *have* installed unity-system-compositor, yes?
<kode54> yes, but I had to mess with the package
<RAOF> thomi: Oh, just to check - you're seeing this problem on Saucy, right?
<kode54> unity-system-compositor : Depends: libmirserver0 (= 0.0.2bzr676raring0) but 0.0.2bzr678raring0 is to be installed
<kode54> that was the state it was at yesterday
<kode54> and there's also a "mir" package that Depends: libmirserver0 (= 0.0.2bzr643raring0)
<kode54> but that didn't get installed, I guess it's a meta package?
<RAOF> I thought we'd dropped the âmirâ package?
<kode54> oops
<kode54> huh
<kode54> the unity-system-compositor in the repository still says it depends on that version of libmirserver0
<kode54> and then libmirserver-dev depends on libmirserver0 = 0.0.2bzr681raring0
<kode54> only straggler appears to be unity-system-compositor
<RAOF> Yeah. unity-system-compositor needs the exact version of libmirserver0 it built against, so it needs a rebuild for every Mir change.
<racarr> Off for now! Will be back this evening to write some emails
<kode54> oh I see
<kode54> the "mir" package is necessary after all
<kode54> it's the source package that is targeted for any source fetches for the subpackages it contains
<kode54> tried latest packages, including building my own unity-system-compositor against the current version of the dev packages
<kode54> the only error I get is
<kode54> init: lightdm main process (16930) terminated with status 1
<RAOF> kode54:  /var/log/lightdm/*.log should have more details.
<RAOF> But, as I said, you should wait for me to unbreak X. Because it's not going to work until I do :)
 * RAOF is test-building packages now.
<thomi> RAOF: no, raring
<RAOF> thomi: Hm. Could you pastebin your /var/log/Xorg.0.log too?
<RAOF> thomi: XMir won't work under raring (care of mir API change), but I wasn't aware raw X was broken.
<kode54> right
<kode54> it's X alright
<thomi> RAOF: http://paste.ubuntu.com/5663150/
<thomi> RAOF: hmm, Im not sure that log file is the right one any more - - how often is it rotated?
<thomi> I've purged the /staging PPA and rebooted since, so I once again have a working desktop
<RAOF> thomi: It's deleted each time you start X :)
<thomi> huh, well darn
<thomi> RAOF: no log file for you then :(
<thomi> I've already wasted most of a day trying to get a desktop  - I'll upgrade the second laptop to saucy and use that for mir development
<thomi> xmir should work on saucy?
<RAOF> Once this damn build builds, yes.
<kode54> so, how's that build going?
<RAOF> Uploading now :)
<RAOF> thomi: Enjoy a freshly dputted build.
<kode54> done now?
<RAOF> kode54: In the PPA. Won't have built yet.
<kode54> ah
<RAOF> Gah! WTF, PPA builder? This built fine in my schroot!
<RAOF> thomi: Are you aware that the saucy Mir builds are failing?
<thomi> RAOF: no, I wasn't - in launchpad, or....?
<RAOF> In Launchpad. Because of !g++-4.7
<thomi> we don't support 4.8?
<RAOF> Allow me to fix that.
<thomi> RAOF: please do
<thomi> :)
<RAOF> We explicitly override the default g++ to 4.7, which isn't installed in the saucy chroots.
<RAOF> Also we fail to build with g++ 4.8
<RAOF> You know what? I'm going to fix that, and then remove our inane GCC version lock.
<thomi> RAOF: yes, please do - packaging hacks are .... bad
<RAOF> make universe-explode-in
<RAOF> -delight
<kode54> so I suppose I shouldn't jump on this ship just yet
<RAOF> XMir in raring should work soon :)
<thomi> wooo!
<racarr> around for a while if I can be useful :)
<RAOF> racarr: Isn't it like 100 o'clock there?
<tvoss> RAOF, aka crazy'o'clock
<racarr> RAOF: 11:15!
<RAOF> racarr: You could rubber-stamp https://code.launchpad.net/~raof/mir/fix-g++-4.8-build/+merge/163635 and https://code.launchpad.net/~raof/mir/remove-gcc-version-forcing/+merge/163641 if you really wanted :)
<racarr> ahahaha
<racarr> CMP0015
<racarr> of course...
<racarr> what
<racarr> hmm...
<RAOF> thomi: WTF? https://jenkins.qa.ubuntu.com/job/mir-raring-amd64-ci/62/console
<kode54> looks like an error with the coverage report generation
<kode54> maybe gcov output syntax changed between 4.7 and 4.8?
<kode54> https://bugs.launchpad.net/gcovr/+bug/1086695
<ubot5> Launchpad bug 1086695 in gcovr "gcov parsing errors in gcovr" [Undecided,New]
<kode54> or maybe that's not the problem
<kode54> meh
<kode54> yay, now I have working xmir
<kode54> but the red cursor won't go away
<tvoss> kode54, is it an "ugly" arrow cursor?
<kode54> yes
<tvoss> kode54, that's the hw-cursor and the policy to hide it is set to "always show" :)
<kode54> is there any way to hide that?
<RAOF> unity-system-compositor should be doing that.
<RAOF> Although it might not be :)
<kode54> wtf, now plymouthd is eating 100% CPU
<RAOF> Ah, we're not shutting that down correctly then :)
<kode54> also, alt-f1 through alt-f5 toggles mouse input on and off (and also hides the hardware cursor when it's disabled)
<RAOF> That sounds like VT switching?
<kode54> should be, but no switching seems to occur
<kode54> oh weird
<kode54> when I alt-f4, it doesn't just stop watching mouse input, it also stops updating the display altogether
<RAOF> That would be you quitting unity-system-compositor, I think :)
<kode54> it stops updating display if I hit alt-f1 through alt-f5, and resumes if I hit any of those again
<RAOF> That's odd :)
<kode54> where is the latest source for unity-system-compositor?
<kode54> just the source package in the ppa?
<RAOF> bzr branch lp:unity-system-compositor, I believe
<kode54> ah, found it
<kode54> yeah
<RAOF> kdub: Is there a particular reason why your cross-compile solution doesn't build a minimal armhf chroot using debootstrap? That way you'd get all the funky dependency resolution for free.
<alan_g> RAOF: you about?
<alf__> mmrazik|afk: Hi! I noticed we are still setting -DMIR_DISABLE_INPUT=OFF in the jenkins hook scripts (H15enable_testing), but this has no effect any more. Feel free to remove it.
<RAOF> alan_g: Briefly. What's up?
<alan_g> Just wondered about proposing a fix to remove-gcc-version-forcing or rolling it into a fixed MP
<alan_g> RAOF: ^
<RAOF> Yeah; I got sidetracked into getting the android build to work on my saucy machine, and then EOD hit.
<RAOF> Feel free to roll it into a fixed MP.
<alan_g> ack
<RAOF> And now, sleep.
<alan_g> mmrazik|afk: @https://jenkins.qa.ubuntu.com/job/mir-android-raring-i386-build/686/console - can we please reconfigure Jenkins to grab g++-arm-linux-gnueabihf/raring instead of g++-4.7-arm-linux-gnueabihf/raring?
<mmrazik> alan_g|lunch: done and retriggered the ci job on that branch (seems to be working; ~53% compile ATM)
<kode54> I saw nothing in the unity-system-compositor about the hardware cursor
<kode54> so I'm not sure where that's supposed to be disabled
<kgunn> alf__: curious, i've been trying for a bit now to use prebuilt mir bins
<kgunn> problem is always the same
<kgunn> when i make set lightdm.conf type=unity
<kgunn> and i restart lightdm
<kgunn> it just gives a blank screen with cursor
<kgunn> (some thought it was a mismatch for old mirserver)
<kgunn> but its still happening
<kgunn> after a reboot i can always get back to a prompt
<kgunn> to remove the type=unity
<kgunn> and then get the ui back ok
<kgunn> alf__: ^
<kgunn> any ideas?
<kgunn> i'm on a macbook/intel integ gfx
<kgunn> side note, when i try to launch unity from command line it whines about
<kgunn> not being able to load the gl plugin in compiz
<alan_g> kgunn: I don't know if it is related, but I had problems with one of my boxes over the weekend - the compiz config had some conflicts that prevented unity loading.
<alf__> kgunn: (note: I haven't tried running unity/xmir for some time now.) Is the cursor the X cursor? Is mir definitely running?
<kgunn> alf__: ignorace is bliss...what is the "X cursor"?
<kgunn> there's no prompt, i can type characters...but they do nothing (seemingly)
<alf__> kgunn: is the mouse cursor you normally get under X? I am just trying to figure it if X starts at all, i.e. is this an xmir issue or a unity issue
<kgunn> alf__: lemme give it a shot & be more aware....i'll grab the lightdm log as well
<kgunn> alan_g: thanks...i blanked all my ccsm settings(like no more wob windows :)
<alf__> kgunn: if you can ssh to your laptop you could try launching an xterm/xcalc to see if X(Mir) is running properly
<kgunn> alan_g: now that you mention it...just did apt-get dist-upgrade....got a bunch of x/compiz updates...
<alf__> kgunn: could it be that you overwrote some XMir packages from the PPA?
<kgunn> alf__: nope...just doing that update now
<alf__> kgunn: ok
<kgunn> alf__: maybe it'll cure it :)
<kgunn> brb
<alan_g> mmrazik: thanks
<thomi> RAOF: ugh - coverage breaks with gcc 4.8
<kgunn> alf__: sneaking time from UDS :)
<kgunn> but i just retested
<kgunn> same result
<kgunn> & i know i wasn't clear
<kgunn> order of events are
<kgunn> change type=unity, restart lightdm
<kgunn> get screen with seemingly useless cursor
<kgunn> reboot machine
<alf__> cursor as in mouse cursor/pointer ?
<kgunn> get a useful prompt but still no ui
<kgunn> on useless cursor screen no mouse
<kgunn> no mouse on useful cursor screen either
<kgunn> alf__: oh, and when i try to launch unity manually after reboot with type=unity in lightdm
<kgunn> it says compiz(core) fatal: couldn't open display:0
<alf__> kgunn: is an X process running ?
<kgunn> alf__: how would i go about verifying that?
<kgunn> alf__: note, the lightdm log says WARNING: Failed to create default seat
<alf__> kgunn: ps -Af | grep X
<kode54> bwahahaha
<kode54> "clang: error: unknown warning option '-Werror=unused-local-typedefs'"
<kgunn> alf__: thanks! will steal more uds time later today to try :)
<alf__> kgunn: probably robert-ancell would be of more assistance here, since he knows lightdm and its interactions with mir and X better
<kgunn> alf__: cool
<kgunn> alf__: i had pestered a bit last week....just know he's on baby watch this week
<kode54> I thought the issue with xmir breaking was due to something wrong with the Xorg package in the mir staging ppa
<alf__> kgunn: kode54: could be, so I guess RAOF is the one to pester :)
<kode54> I thought he fixed it
<kode54> it was working here
<kode54> but the unity-system-compositor package still hasn't been rebuilt, and the current version doesn't hide the hardware cursor
<alf__> status: investigating/fixing bugs, experimenting with lttng and tools
<kdub> status, mostly starting performance work with android devices
<kdub> greyback, lp:mir should have the code needed for the shell on phone
<greyback> kdub: it does. I'm having a problem with the qpa plugin that I need to understand/ask racarr about
<alan_g> status: trying to understand the current design well enough to add composition bypass cleanly
<racarr> Morning
<kdub> hello racarr
<greyback> racarr: hey
<racarr> kdub: greyback: Did you guys see my email?
<racarr>  / did it make sense
<greyback> racarr: yep, have been working off it today
<racarr> I wrote it at like midnight right before going to sleep aha
<greyback> :)
<racarr> kdub: So what do you think about
<racarr> letting the shell get at the EGLNativeDisplay without a surface yet (i.e. like in my email)
<racarr> Qt wants to choose configurations and initialize EGL etc when QScreen is created
<racarr> so ubuntu_application_ui_get_native_display
<racarr> can't take any arguments
<kdub> racarr, makes sense to me
<racarr> kdub: p.s. do your eglconfig for qtubuntu fixes on phone exist somewhere
<racarr> greyback is trying to get mirclient on phone going
<kdub> i'll have to find them
<racarr> Ok. Thanks :)
<greyback> kdub: thanks!
<racarr> I...can't figure out how to expose this native display...
<racarr> doe it jut go back to the graphics platform?
<kdub> racarr, we could have an InternalClient that takes the surface in the creation of the eglNativeWindowType
<kdub> as a parameter to the function, as opposed to in the constructor
<racarr> kdub: Oh. That's a good idea
<kdub> greyback, this is how i got the qpa plugin to work over the sprint... http://pastebin.ubuntu.com/5664882/
<kdub> just to give some ideas :) probably not the universal solution
<greyback> kdub: thanks, will give it a go
<racarr> I think this qeglconvenience
<racarr> is copied from a qt built with EGL (which ours isn't or wasn't or something?)
<racarr> a qt5 beta from a long time ago
<racarr> or something
<racarr> I think Qt can do this for us now but will have to figure out how
<racarr> The coffee shop on my new corner has insanely caffeinated coffee oO
<alan_g> that's what has you writing at midnight?
<greyback> racarr: kdub: excellent, we have stuff on screen at last
<kdub> greyback, great :)
<racarr> Yay!
<kdub> input working too?
<racarr> alan_g: No. What has me writing at midnight is that I've actually been sleeping lately so im not tired as soon as it's 6pm haha
<racarr> which sounds kind of counterintuitive but writing emails at midnight is much less of a problem than being kept up by housemates at 2 am :p
<greyback> kdub: I'm getting the events printed in my terminal, so appears to
<greyback> kdub: bringing up something more intelligent now
<kdub> greyback, when i got it working at the sprint, i had to use qml touch events, mouse events weren't going through for some reason
<kgunn> greyback: kdub racarr aweseome!!
<greyback> kdub: interesting, will look into that
<greyback> kdub: input working
<kdub> cool
<kdub> it should be multi-touch too
<greyback> kdub: checking...
<mlankhorst> ]
<greyback> kdub: yep
<racarr> whee
<racarr> kdub: Good news, it wasn't a shared hallucination!
<kdub> great :)
<tvoss_> greyback, ping
<greyback> tvoss_: pong
<racarr> ok almost done with this native display stuff....
<racarr> we have about a half dozen duplicated instances of StubPlatform : mg::Platform ;)
<kdub> racarr, i noticed that too
<alan_g> racarr: is there something wrong with that?
<alan_g> Different tests may need different behaviour from stubs of the same interface.
<kdub> alan_g, yeah, the disadvantage is the typing :)
<racarr> alan_g: In this case they are all the same really ;)
<racarr> just null tubs
<racarr> stubs*
<racarr> I think
<racarr> I dunno
<racarr> it's cumbersome to have to update a half dozen files
<racarr> including unexpected ones
<racarr> so it becomes
<racarr> compile
<racarr> wait for error
<racarr> etc
<alan_g> racarr: kdub: if they are necessarily (as opposed to coincidentally) duplicate there are grounds to refactor
<racarr> I made a note of it in my: "Things to do when its not obvious what else to do"
<racarr> list ;)
<alan_g> But surely the motivation for a change to the interface comes from some new tests - maybe a different interfaces is a better solution?
<racarr> maybe in this case...I'm not sure
<racarr> kdub: https://code.launchpad.net/~robertcarr/mir/emancipate-egl-native-display-from-surface/+merge/163775
<racarr> When you have a chance.
<alan_g> racarr: maybe...maybe not - but I'm sure that the wrong choice has been made sometimes.
<racarr> Perhaps create_internal_client belongs on the Display
<racarr> greyback: Want to test to see if it works now while I try and get unity/phablet building?
<racarr> I think if you have: https://code.launchpad.net/~robertcarr/mir/emancipate-egl-native-display-from-surface/+merge/163775
<racarr> and revision 62 to ~robertcarr/platform-api/mir (just pushed)
<racarr> qtubuntu/mirserver should build fine now
<greyback> racarr: sure, once I do a few hacks to get shell working without the mir application module
<alan_g> Goodnight all!
<alf__> alan_g: goodnight!
<racarr> Great!
<racarr> night alan :)
<racarr> who...already left.
<racarr> im purging my qt ppas atm
<racarr> *taps foot* aha
<racarr> ugh now it finds the cmake files from qt but then they claim that nothing exists...
<racarr> why did I have to add /usr/lib/x86_linux_gnu/cmake to CMAKE_PREFIX_PATH
<racarr> ?
<tvoss_> kgunn, ping
<greyback> racarr: should/can the mir server run as phablet user, or must be root?
<racarr> Can be run as phablet user if you have input permissions
<racarr> probably ;)
<racarr> and should be
<racarr> then a system mir runs as root I guess
<kdub> racarr, greyback, i'm unsure about graphics though... i'd suggest running as root if it doesn't work :)
<greyback> racarr: kdub: it is working as root, was just curious
<racarr> ok got unity/phablet building. going to go for a walk around the block while it runs, back in a bit
<philipballew> Just saw a demo of Mir without X. Looking nice!
<racarr> :D
 * philipballew smiles back at racarr 
<racarr> hmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm now ./build -s tells me I may have held broken packages :(
<racarr> probably...
<racarr> perhaps ubuntu-unity/experimental-certified conflicting with unity-next-desktop
<racarr> ppa-purge is a real godsend
<kgunn> tvoss|dinner_lun: late pong...sorry, had to grab some grub
<olli> kgunn, tvoss|dinner_lun just told me that he might be late for the OSK session due to dinner
<kgunn> olli: ack, thanks
<racarr> That is in 30 minutes yes?
<olli> racarr, yep
<racarr> Great
<racarr>  indicator-appmenu-tools : Depends: indicator-appmenu (= 13.01.0daily13.03.28-0ubuntu1) but 13.01.0daily13.04.03-0ubuntu1 is to be installed
<racarr> greyback: Latest build -s conundrum, any ideas?
<greyback> racarr: hmmm
<racarr> trying downgrading the package
<racarr> ok its working now
<racarr> not sure if I will get the qt5 errors later aha..realized the error involved build -s failing early and me going in to build and running cmake myself ;)
<racarr> which I just thought was how build -s worked
<racarr> building lots of branches and stuff
<greyback> racarr: no idea where the duplicate packages are coming from. apt-cache showpkg helps?
<racarr> greyback: Mm. Im just going to use the downgrade for now
<racarr> need to upgrade to saucy soon anyway
<racarr> and do some housecleaning
<greyback> racarr: ok. let me know if you still have problems
<racarr> thanks :)
<racarr>  how do I get lower third set up
<racarr> I cant find out how to install it and it is not showing up in featured apps
<racarr> Ok here we go
<tskorte> Hello everyone! I've followed the "Installing pre-built packages on a PC" on unity.ubuntu.com/mir and the tried to run it natively. Problem is that I get this "failed to create GBM buffer". Has anyone encountered this or have I missed something?
<kdub> having one of those days where i was like 'this looks like a simple cleanup...' and then it cascaded into many clean ups :)
<kdub> tskorte, you installed the special mesa package?
<tskorte> kdub: Well, I installed all the pre-built packages.  That's not enough? :)
<kdub> tskorte, it /should/ be, however, i'm not up on what desktop gpus work with it... RAOF will know when he comes back
<tskorte> Great
<tskorte> In the mean time I'll try to install it from source
<kdub> it works with my intal gma-x3100
<tskorte> Should've mentioned that I have  a amd radeonhd 5750
<racarr> yay unity finished building...test time
<racarr> p.s. can someone look at https://code.launchpad.net/~robertcarr/mir/emancipate-egl-native-display-from-surface/+merge/163775
<racarr> oh just the dependency build finished :(
<hikiko_> tskorte, i had the same problem you need the special mesa pkg from the mir ppa
<racarr> greyback: Should I expect that run -m should work if qtubuntu mirserver is working?
<racarr> getting some stuff about a binding loop and hud complaints, mir starts but then a few second laters it all quits/dies
<racarr> still figuring out
<tskorte> hikiko_: Nice! What are the package names?
<greyback> racarr: you might also need the "-f" flag to work around the lack of the application API
<hikiko_> hmm :) I don't remember one second to check tskorte :)
<hikiko_> tskorte, did you try apt-get update apt-get build-dep mir after adding the mir ppa to your apt/sources.list? it should install the correct libraries I think
<tskorte> hikiko_: No, I ran update && dist-upgrade. Will try apt-get build-dep now
<greyback> racarr: I've to go afk for about 90 mins, good luck!
<racarr> greyback: Ok see you! got a stack trace so hopefully can fix it
<racarr> looks like my fault ;)
<greyback> oO
<racarr> eglplatform.h strikes again
<racarr> yay it works
<tvoss> racarr, success? :)
<kdub> racarr, when you say eglplatform.h strikes again
<kdub> you mean that we don't have a #mir_platform ifdef that defines our types?
<kdub> for the mesa platform?
<racarr> tvoss: Yep phone shell running again on g bm and 95% sure it should run on android ;)
<racarr> kdub: Yep.
<racarr> I will remember...to talk to chris about that today
<tvoss> racarr, make it running :)
<hikiko_> hey why nobody is in the hangout?
<hikiko_> :s
<kdub> i've noticed that too... on mesa, our ipc package has morphed into the native buffer type
<racarr> hmm?
<racarr> tvoss: it will be today :) greyback has a set up all ready though that just needs to plug in this fixed platform-api branch so
<tvoss> racarr, go ahead
<racarr> im going to wait for him to test it and work on other things :)
<tvoss> racarr, :)
<racarr> the video lens looks awesome on 27 inch screen haha
<racarr> excluding the big ugly cursor
<tvoss> racarr, ;)
<kdub> racarr, once RAOF logs on, lets talk eglplatform types for mesa :)
<racarr> sounds good!
<racarr> Lunch!
<tvoss> racarr|lunch, enjoy
<racarr|lunch> literally next door to a curry place now...hopefully this doesn't get out of control ;)
<racarr> back!
<FunnyLookinHat> Saw the demo w/ Unity 8 running on Mir - looks good guys!
<olli> so who of you guys did the U8 / Mir on ARM demo
<olli> that was a nice surprise
<kdub> olli, probably greyback, haven't seen it yet
<olli> https://plus.google.com/u/0/116997345010659023379/posts
<olli> can't tell from the fingertips
 * olli needs to get to know the team better
<kdub> yay, performance looks ok in the video too :)
<racarr> how
<racarr> is that working XD
<racarr> maybe out of process stuff or did someone just make it?
<kdub> racarr, i'd guess out-of-process...
<olli> racarr, how often do you and greyback sync
<kdub> greyback, your video's famous :)
<greyback> kdub: lol my finger will be recognized in public now
<kdub> yep :)
<racarr> olli: About 4 times a day ;)
<greyback> racarr: any luck with in-process mir+unity?
<racarr> greyback: Hehe was just going to say yes, its working
<greyback> racarr: nice!
<racarr> greyback: If you build ~robertcarr/platform-api/mir with https://code.launchpad.net/~robertcarr/mir/emancipate-egl-native-display-from-surface/+merge/163775
<racarr> it should work, I havent' tested on android yet
<racarr> but it's the "same code path" now so
<greyback> racarr: ok, I'll give it a go
<racarr> Awesome
<racarr> it looks great on 27 inch screen :D
<racarr> the video lens...*wide eyes*
<greyback> xD
<greyback> I hope you get a nice big value for GRID_UNIT_PX, so things scale nicely
<racarr> greyback: It all look pretty appropriate.
<racarr> Maybe I'm thinking too far ahead, but I think there will be some mir work (mostly exposing new interfaces, etc) required as well as shell work
<racarr> so I was wondering during lunch...
<greyback> write them down, do share!
<racarr> how many pieces are missing from getting the launcher to some point like "displays a list of desktop files, can launch applications, can switch between them"
<racarr> I'm just thinking about little mini milestones to try and get some basic surface management in place
<greyback> sure. We need a concrete list, prioritized, and then decide where each bit belongs
<greyback> and who does it
<racarr> What do you mean?
<greyback> racarr: just like you said, to identify the missing pieces and make work items out of them
<racarr> Haha ok, sorry I wasnt sure if you were referring
<racarr> to the work items
<racarr> or the desktop files
<racarr> and I was like...well...I dont think it really matters which desktop files...
<racarr> nvm :p
<greyback> ah, understood
<racarr> hmm.
<racarr> ill think about this more tomorrow actually :p because there is not really much useful you can do
<racarr> without the window stacking/sorting interface in mir
<racarr> So that's a missing piece that's a work item
<greyback> yep
<racarr> I guess the first missing piece ont he shell end, is mir has a SessionListener you can implement
<racarr> that is told session_appeared/vanished with the application id (desktop id I guess right now)
<racarr> so the session needs to be assosciated with the launcher icon
<racarr> so it can be switched to later
<greyback> well each session is related to a desktop file, no?
<racarr> yes (well, if qtubuntu passed this through)
<greyback> I think it did
<racarr> I just mean there needs to be an implementation of this interface in unity
<racarr> that exposes it out to qml
<racarr> the matching should be trivial
<greyback> For the launcher, I think all Mir needs to tell us is what apps are starting/open, how many windows they have (desktop-only) and things like, it is looking for attention, etc
<racarr> ok
<racarr> ill fix the desktop file pass through
<greyback> for now I think that's all we really need
<racarr> I'm really in to getting a sort of functional (if super bare bones) shell together so I can start dogfooding the input stack on myself
<racarr> I imagine between /dev/input and every application there are probably a few quirks to iron out :p
<greyback> yep, but you're right - we gotta start somewhere
<racarr> I actually dont have a whole lot planned to do for the end of the week because my highest priority stuff is blocked on the platform API refactoring
<racarr> so maybe I will try and do the start of the launcher integration in unity I think it will help me to start to get
<racarr> a mental map of the unity 8 code
<racarr> RAOF: Ping?
<racarr> thomi: Ping?
<racarr> Raof isn't around so I'm going to ask you about something different instead ;)
<RAOF> racarr: Pong.
<racarr> RAOF: Can we fix this eglplatform.h thing so I can stop telling people to edit eglplatform.h?
<kdub> racarr, RAOF we're in a pretty good position for  you to define whatever you want for the mesa/mir native types
<kdub> good position, from a mir-internals perspective
<kdub> i was wondering... could we even use the defines in __GBM__ ?
<racarr> EGLNativeDisplayType for mirclient mesa is not gbm_device * though
<racarr> its MirEGLNativeDisplayType (i.e. void* i.e. MirMesaEGLNativeDisplay)
<kdub> racarr, right, i don't really know the diff between the two
<kdub> (namely, what's in gbm_device)
<kdub> but it doesn't sound like they're close to each other
<kdub> seems like MirBufferPackage has just become the de-facto buffer type for the platform
<kdub> when, we could actively choose what we want in that struct now
<racarr> thats not exposed out through the eglplatform.h
<racarr> its just display, window, and pixmap
<kdub> well, sure
<kdub> but while we're defining our types for mesa, may as well take care of all the issues :)
<racarr> mm
<kdub> like, we have our EGLNativeDisplayType and EGLWindowType as just 'the most convenient internal types'
<kdub> which, isn't bad, but we have the opportunity to actively define what we want out of the interface :)
<racarr> I think we just want opaque pointers
<kdub> that would be ok
<kdub> racarr,  with emancipate-egl-.*, small needs fixing, otherwise looks good
<racarr> I hope to one day name a class <Noun>Emancipator
<racarr> im not sure what it does
<racarr> escalates priveleges perhaps
<racarr> kdub: Ok :) Just pushed a fix in r686
<racarr> thanks.
<racarr> RAOF: http://pastebin.ubuntu.com/5666057/ perhaps?
<racarr> kdub: ^
<kdub> racarr, i think it should be forward declared probably
<RAOF> Looks plausible.
<racarr> RAOF: Can we merge it?
 * RAOF fires up the mergeotron.
 * kdub is imagining one of those spinning carnival ride things
<racarr> RAOF: Savor the moment, likely to be the first and last EGLNativeDisplayType we will define XD
#ubuntu-mir 2013-05-15
<RAOF> Damnit, laptop. Stop thermally throttling yourself!
<mlankhorst> yeah start making burn holes on raof's lap
<RAOF> It's sitting on a table. It's welcome to try and burn that!
<robert_ancell> RAOF, bug #1102762 is fixed right?
<ubot5`> bug 1102762 in Mir "Support nouveau drivers" [Medium,In progress] https://launchpad.net/bugs/1102762
<racarr> RAOF: Does Mesa still live on github?
<racarr> I was hoping to see a shiny eglplatform revision but itsnothere
<racarr> oh I see, mir-ppa is the branch
<RAOF> racarr, robert_ancell: Correct
<racarr> are we having the weekly?
<RAOF> I presume so?
<robert_ancell> racarr, RAOF, yes
<RAOF> FIRST!
<hikiko> hi
<RAOF> Oh, thomi - could we get Saucy builds of mesa out of github, too?
<mlankhorst> is mir used on the touch image yet?
<tvoss> mlankhorst, it's not officially in the image, but working towards that goal
<tvoss> greyback, good morning :)
<greyback> tvoss: well howdy
<greyback> kdub: hey, good news: unity runs on mir in process: http://ubuntuone.com/58W4ARPX7KKPLdoHHsDrvL
<greyback> kdub: but performance isn't buttery, in fact appears a bit slower than out of process
<greyback> this is galaxy nexus
<greyback> kdub: doing some initial profiling, it appears the buffer swap is slow (often over 30ms per frame)
<hikiko> alf___, here?
<alf___> hikiko: hi, here
<hikiko> hi!
<hikiko> I have a problem when I compile, I get this error: Linking CXX shared library ../../lib/libmirserver.so ../../lib/libmirfrontend.a(session_mediator.cpp.o):(.data.rel.ro._ZTVN3mir8frontend15SessionMediatorE[_ZTVN3mir8frontend15SessionMediatorE]+0x38): undefined reference to `mir::frontend::SessionMediator::drm_auth_magic(google::protobuf::RpcController*, mir::protobuf::DRMMagic const*, mir::protobuf::DRMAuthMagicStatus*, google::protobuf::Closure*)
<hikiko> ' because I include files from the graphics/gbm, do you know how I could change the CMakeLists.txt so that the linker doesn't complain anymore? :)
<hikiko> i mean the cmakelists from the sdl platform
<hikiko> i tried to make it identical to the gbm cmakelists
<hikiko> but I still get thi serror
<alf___> hikiko: you need to create a session_mediator_sdl which is going to be basically a copy of session_mediator_android.cpp, and build with it
<hikiko> alf___, I can't use the existing gbm one?
<hikiko> what's the session mediator?
<alf___> hikiko: SessionMediator is the object that (ultimately) handles RPC requests from clients. At this point you don't need to support drm_auth_magic, since it's used by clients only. I am not sure if you can support it at all, since you will need to be the DRM master to do so.
<hikiko> I can't be the drm master, the xserver will be :S
<alf___> hikiko: perhaps you will just need to forward the request to X then
<hikiko> but I need to authenticate to the xserver
<alf___> hikiko: but anyway, for the first step (getting render_to_fb to run) it's not needed
<alf___> hikiko: ... which makes me wonder if we need mir_connection_drm_auth_magic() at all. No one seems to be using it.
<alf___> RAOF: ^^
<hikiko> I need to do the magic I guess because when I tried to create my gbm buffers in my example without authentications and inside X I didn't have permissions
<hikiko> +then you have to somehow pass the device descriptor to the xserver I guess (not sure)
<alf___> hikiko: For GBM at least, we are sending a pre-authenticated DRM fd to the client (e.g. to mesa), so I guess you will need to do the same for SDL, with the difference that you will need to ask X to authenticate it (XF86DRIAuthConnection). In any case, mir_connection_drm_auth_magic() seems to be unused right now. I will talk to RAOF to ensure he doesn't need it and remove it.
<hikiko> mmm maybe :) let me find where you do this authentication for gbm
<alf___> hikiko: gbm_display_helpers.cpp
<olli> is anybody attending the "Support for convertibles and touch screen on Ubuntu desktop ( Client )" session
<olli> Saviq, kgunn
<kgunn> checking
<Saviq> olli, I was going to go to "Touch System Settings"
<olli> Saviq, is that now?
<Saviq> olli, yes
<Saviq> no
<Saviq> in an hour
<Saviq> ok, coming to the convertibles
<kgunn> sorry, i was going to kylin images...but maybe i should go to that instead
<olli> kgunn, Saviq I think we should cover both
<olli> it would make sense to me for kgunn to go to kylin
<kgunn> ack
<olli> as this is a "customer" of ours and Saviq to go to the touch one to keep them straight/honest
<kdub> greyback, i'm working on performance stuff today, can take a look at inprocess qml going slowly
<greyback> kdub: ok cool
<kdub> greyback, that video looks ok though, is it only sometimes that it takes 30ms?
<greyback> kdub: overall frames took just a bit over 30ms when adding in the rendering time
<greyback> kdub: handy tip is to set QML_RENDER_TIMING=1 before running a qml app, you get frame info out with that
<kdub> greyback, what sort of special branches do i need?
<greyback> kdub: see racarr's email last night, he gives all the info there.
<kdub> greyback, cool, thanks
<kdub> busy morning :) status, yesterday worked on a cleanup branch, began swap interval 0 work
<mlankhorst> oh thanks for reminding me, drm needs to add support for thjat
<mlankhorst> that*
<moustafa> Hey! Is anybody else having difficulty installing mir through the PPA due to unmet dependencies?
<kdub> moustafa, what package?
<moustafa> kdub, 'mir'.  The conflict is caused by libmirserver0 being at 0.0.3bzr687raring0, where mir requires it to be at 0.0.2bzr643raring0
<mlankhorst> remove mir
<alf___> status: integrating lttng with mir reporters
<moustafa> mlankhorst, It can't even install :)
<kgunn> moustafa: i had the same issue
<kgunn> thomi: ^
<thomi> kgunn: we're fixing that today :)
<kgunn> moustafa: i was pestering folks last night, but my understanding is, you can build the libmirserver from source and it'll work
<thomi> hmmm
<kgunn> thomi: thanks ;) it helps lazy folk like me
<thomi> isn't libmirserver build by the mir source package?
<moustafa> kgunn, well, that would be the obvious way of doing it, but I like being a bit lazy (curse you, PPAs!)
<kgunn> thomi: well, based on my interaction with robert, it seemed the source didn't match the ppa (? sheepishly)
<thomi> kgunn: yeah, sorry, I assumed you were complaining about the u-s-c issue :)
<thomi> moustafa: which series are you looking at?
<moustafa> thomi, Raring
<kgunn> thomi: me also
<thomi> hmmm
<thomi> moustafa: right, as mlankhorst mentioned, 'mir' is an old package, that you should remove. If you want the demos, install mir-demos
<thomi> moustafa: the packages (listed here: https://launchpad.net/~mir-team/+archive/staging/+packages?field.name_filter=&field.status_filter=published&field.series_filter=raring) look like they've built fine
<moustafa> thomi, So, I would require mir-demos to run mir as a system compositor with X?  Or can I just go ahead with mir-demos.
<moustafa> thomi, That said, mir isn't even installed (refuses to do so anyway)
<thomi> moustafa: hmm, you said "The conflict is caused by libmirserver0 being at 0.0.3bzr687raring0, where mir requires it to be at 0.0.2bzr643raring0", which made me think you were installing the 'mir' package - maybe you could pastebin your shell session?
<moustafa> thomi, http://paste.ubuntu.com/5668074/
<mlankhorst> thomi: why is there no breaks/replaces on mir then?
<thomi> mlankhorst: there should be. I'll do tha today
<thomi> moustafa: right, don't install 'mir'
<thomi> moustafa: if you want to run the demo shell, that is now in the 'mir-demos' package
<thomi> moustafa: if you want to run on top of X... I'm not sure what you need for that. maybe someone like kdub, alf___ or kgunn can tell you
<kgunn> hikiko: ^
<hikiko> it doesn't run on top of x yet :)
<hikiko> moustafa, there's no emulator yet
<hikiko> under construction!
<moustafa> hikiko, Duly noted!
<hikiko> but moustafa I think that some examples
<hikiko> work on X
<hikiko>  alf___ L
<hikiko> ^
<kdub> greyback, ping
<greyback> kdub: pong
<kdub> i've gotten to the point where ipc qml clients are running, how to run qml-phone-shell?
<kdub> i'ts failing to run, i'd guess there's some service or something that I haven't started up
<greyback> kdub: you running phablet-integrate-mir-no-sw-cursor ?
<kdub> greyback, no, i've just jammed some hello world qml files on to test with qmlscene so far
<greyback> and they're not working?
<kdub> no, they are, its qml-phone-shell that isnt
<greyback> ok
<greyback> you compiled it with the "build" script I hope
<kdub> no, is there a wiki?
<greyback> nope, sorry
<kgunn> kdub: for building
<kgunn> http://unity.ubuntu.com/getinvolved/development/unitynext/
<kgunn> assume that's what you were looking for
<greyback> ah, news to me
<kgunn> greyback: :)
<kdub> yeah, i was just thinking 'theres some primitive unity knowledge i'm missing here...'
<kdub> thanks kgunn
<kgunn> manager== data aggregator :)
<greyback> kdub: but most of that info is desktop specific. Really all you need is "./build" and "./run"
<racarr>  -m -f ?
<kgunn> greyback: you mean ./run_on_device ?
<greyback> racarr: worked without for me on last run. "-m" only for desktop
<greyback> kdub: are you compiling on the device, or cross-compiling on your PC?
<kdub> cross compiling
<greyback> kdub: what is easiest for you to do is: "./run_on_device -s" to push code to the phone and compile it there. It will leave the qml-phone-shell executable in /home/phablet/shell/builddir/src/shell/
<greyback> kdub: but note that install compiler, etc on the phone
<greyback> s/install/installs/
<kdub> greyback, thanks, will give it a try
<racarr> Ah
<racarr> status: Met with katie, talked about surface types v. roles
<racarr> now eating a bagel and deciding what order to do things in
<kdub> so many phablet scripts to learn about
<racarr> yeah
<racarr> greyback: Wondering if there is anything I can do in particular while you are still on
<greyback> racarr: getting your platform-api and qtubuntu branches merged would be handy, so we all can get unity+mir running easily. Think it's much effort?
<racarr> greyback: Unfortunately blocked atm
<racarr> platform-api is about to (tomorrow, friday?) have a big refactoring
<greyback> racarr: :( what by?
<racarr> and we are going to land it afterwards
<greyback> aha yes, I recall taht
<greyback> ok, well best wait for that so.
<racarr> the eglplatform.h bits landed though
<tvoss> racarr, is QtMir still current or do we do things in QtUbuntu?
<greyback> cool
<racarr> tvoss: It's all qtubuntu
<kgunn> sweet
<racarr> tvoss: Though mir qtubuntu is a little different
<racarr> due to mir doing keymapping + key input wasn't really working so much in qtubuntu
<racarr> (mir client)
<racarr> Everyone likes mapping keys on the client
<racarr> but I don't understand why
<racarr> Espescially because you have to map them on the server too for the input ilter
<racarr> filter*
<tvoss> racarr, ack
<racarr> alf___: Ping?
<racarr> p.s. nice underscore
<racarr> hmm
<racarr> how do you acceptance test that pressing control+c doesn't
<racarr> kill the server
<racarr> I dont even know :/
<racarr> Too many missing pieces
<kdub> racarr, what are you trying to do :) shouldn't sigterm/sigint kill the server?
<racarr> yes but ctrl+c shouldn't generate
<racarr> any signals
<racarr> because mir should parse it like anything else and pass it on to applications
<racarr> which is easy
<racarr> tcgetattr (vtfd), cfmakeraw(attr) tcsetattr(attr)
<racarr> and it's easy enough to, well, mock out this in to a file operations bit, test that the virtual terminal uses these interfaces correctly
<racarr> test that the display calls the virtual terminals disable_control_sequences methods appropriately
<racarr> etc
<racarr> but there is no acceptance test
<racarr> you just have to mock the kernel ;)
<racarr> and with that Im giving up on acceptance testing this for now :p
<racarr> it may be possible to use a pty...I dunno
<kdub> greyback, what is "phablet-integrate-mir-no-sw-cursor"? a branch somewhere?
<greyback> kdub: lp:~robertcarr/unity/phablet-integrate-mir-no-sw-cursor
<greyback> it adds code to qml-phone-shell to create a Mir server, add cursor and other bits
<kdub> ah, i should read that email more carefully :)
<racarr> https://code.launchpad.net/~robertcarr/mir/disable-sequences-and-add-terminate-handler/+merge/164014 exists
<racarr> im not in any hurry to land it though
<kdub> greyback, http://pastebin.ubuntu.com/5668437/
<kdub> not sure what package qpa/qplatformnativeinterface.h comes from...
<greyback> kdub: qtbase5-private-dev
<greyback> I'm surprised the run_on_device script didn't install that for you
<kdub> also, i found i had to install the GL headers in addition to the gles headers, struck me as a bit strange
<greyback> kdub: that's probably wrong for phone. In src/shell/CMakeList.txt you should substitute "${OPENGL_gl_LIBRARY}" with "GLESv2"
<kdub> anyways, just built successfully, thanks greyback
<racarr> DOES IT RUN DOES IT RUN
<greyback> dramatic pause!
 * kgunn passed out from holding breath
<kdub> no, that would be too easy :)
<greyback> Here are higher-level instructions if anyone wants to run unity+mir on their phone: http://studio.sketchpad.cc/gmY0M6iqeh
<greyback> they're a bit messy still, yes. But they work
<racarr> wait so it does run?
<kdub> no, just exits
<kdub> just starting to read through the code though
<racarr> the ./run script hides the segfaults
<racarr> becaues it does openvt
<kdub> still don't know exactly what this thing is
<racarr> so I got rid of the openvt bit and ran it in GDB
<racarr> to debug in GBM
<racarr> greyback: Instructions seem to be missing building platform api + qtubuntu?
<greyback> racarr: I've them packaged
<greyback> racarr: .deb files are in my chinstrap
<racarr> greyback: Oh! I see
<racarr> So you're one of those people who does things the right way huh?!?!
<racarr> :p
<greyback> yes, very much so
<greyback> :D
<racarr> great. thanks for writing this up :)
<greyback> racarr: I'm guessing you plan to have separate platform-api-client and -server packages eventually. And same for qtubuntu?
<racarr> greyback: seperate packages yes...I think the final structure is likely to be like
<racarr> there is platform-api (which also contains bit like GPS, etc)
<racarr> that can (dynamically?) load either mirserver, mirclient, windows forms
<racarr> whatever
<kdub> do i need the 'client' or the 'server' libqubuntu.so qpa plugin?
<racarr> likewise qtubuntu should probably gain just a tiny amount of intelligence
<racarr> kdub: server
<greyback> racarr: got it. Makes sense
<racarr> to auto select loading platform-api server/client
<racarr> rather than maintain two qtubuntu
<greyback> yep, totally
<racarr> ADHD: I was wondering in the shower today. When do we need to have mir running under virtualized environments?
<racarr> kgunn: ^
<racarr> is it captured somewhere?
<kgunn> racarr: what do you mean exactly ?
<racarr> then also, I wonder if say porting xf86-video-vmware to a graphics platform is easy XD
<racarr> kgunn: I mean, Mir should be able to run under vmware/virtual box
<racarr> Has to be able to presumably
<racarr> by 14.04
<kgunn> racarr: ah, ok....
<kgunn> yes
<kgunn> and i would think that would be super easy (or am i a nut?)
<kgunn> mm
<kgunn> maybe not so...kernel stuff
<racarr> well, the basics are easy
<racarr> but like, in the X driver, they use special interrupts to map a framebuffer through the virtualization layer
<racarr> or things like that
<racarr> they have libGLs that talk to virtualbox/vmware which then use the host libgl
<racarr> things like that
<racarr> mode setting, they have special communication (I think it's weird interrupts again)
<racarr> for mode interaction between the guest video driver and the virtualization host
<racarr> etc.
<kgunn> right....i don't know how it all works but i suppose the kernel itself is the virtual bit
<kgunn> sharing hw resources like fb
<racarr> It seems like (looking at xf86-video-vmware) this is kind of abstracted away a little.
<kgunn> i would imagine so
<racarr> i.e. they have funny functions like vmware_do_bla_bla that
<racarr> handle the complex bit of
<racarr> talking to the host and back and forth and all
<racarr> but mir needs to be hooked up to it
<racarr> if it really is that simple
<kgunn> sure
<racarr> it's kind of the same sized task as porting mir to SDL
<racarr> (but made easier by that)
<racarr> but, um
<racarr> I just told you literally everything I know about this so
<racarr> I don't have the confidence to say that :p
<kgunn> :))
<kgunn> well, don't get too distracted....other things on the horizon
<kgunn> osk
<kgunn> app data sharing
<racarr> Yes of course, I am not going to work on it now
<racarr> I just want to make sure it doesn't get lost
<racarr> because I dont think we have a work item, but it's clearly expected
<kgunn> lemme check
<racarr> and I am worried it will have some secret bit like "actually there is this closed source bit that we have to convince them to modify because our semantics...."
<greyback> racarr: probably daft question, but does the phone have concept of a vt?
<greyback> "adb shell" is a proper VT?
<kdub> greyback, unsure
<kgunn> greyback: i think that's as close as it gets (adb)
<kgunn> well...i take that back....there are some who got x working on android
<kgunn> but it was really custom
<greyback> Me too. I'm just curious is there's a way to run mir from ssh so that it works. It's easy on the desktop to create a new vt and run an app in it (openvt), but it would be handy to have something similar for phone
<greyback> oh dumb-ass, I can just use "adb shell" itself from the pc
<racarr> :)
<racarr> not daft XD I was wondering the same thing
<racarr> I realized today I don't really remember how terminals/vt/pty all work
<racarr> I did in college at one point when I thought reading advanced unix programming was a fun thing to do in your spare time ;)
<tvoss> racarr, got the unix bible on my book shelf :)
<greyback> :D thanks guys, I'll expect the answer in the morning so :D
<racarr> XD
 * greyback eod
<racarr> Goodnight!
<racarr> Lunch for me, nexus 7 upgrade running as we speak so I will try unity mir android when I get back
<kdub> racarr|lunch, nex7 won't work with default hybris package
<racarr|lunch> kdub: Mm right. Do packages to fix it still exist?
<kdub> racarr|lunch, no
<racarr|lunch> kdub: Can I build them?
<hikiko> hello
<hikiko> question:
<hikiko> I get this linked error when trying to compile my sdl branch:
<hikiko> /usr/lib/libmirclient.so.0: undefined reference to `mir::protobuf::EventSequence::~EventSequence()'
<hikiko> but when I grep
<hikiko> I can't find any reference to EventSequence in the code
<bschaefer> hikiko, hmm perhaps its generated at build time?
<bschaefer> build/src/shared/protobuf/mir_protobuf.pb.h:1477:class EventSequence : public
<hikiko> !
<hikiko> I don't have that class
<bschaefer> that could be a problem!
<hikiko> wtf maybe I have to merge with a more recent version before I proceed :S
<bschaefer> possibly, im at rev 687
 * bschaefer pulled an hour or so ago
<hikiko> yes :) I have to :)
<hikiko> lol
<bschaefer> :)
<hikiko> thank you!
<bschaefer> np!
<hikiko> +see you tomorrow
<kgunn> kdub: racarr|lunch good grief....i just now made my way thru the github shennanigans & have the proper branch
<kgunn> kdub: so reading the install file....looks like the best thing to do is native compile this on the device ?
<kdub> it probably is the easiest
<kdub> it doesn't look like getting that working though is trivial though
<racarr|lunch> kgunn: You are trying the seven too?
<racarr|lunch> It didn't work for me
<racarr|lunch> But I might have done something wrong
<racarr|lunch> oh whoops
<RAOF> Late lunch? :)(
<racarr> kdub: linker.c:661| WARNING: `/system/lib/hw/gralloc.tegra3.so` is not a prelinked library
<racarr> meaningful?
<kdub> racarr, no
<racarr> :(
#ubuntu-mir 2013-05-16
<RAOF> Hurray for having next week off. This week is not my most productive ever :/
<hikiko> hello
<hikiko> alf__, ping!
<tvoss> alf__, ping
<hikiko> lol I think he has a meeting
<alf__> hikiko: pong
<alf__> tvoss: pong
<robert_ancell> tvoss, ping
<robert_ancell> (everyone else was doing it)
<alf__> ping-pong madness :)
<hikiko> lol
<tvoss> man ...
<tvoss> robert_ancell, pong
<hikiko> ok tvoss ask first if you want :D
<robert_ancell> tvoss, do you know who is maintaining LTT-ng in Ubuntu? If we take a dependency on it I'll do a MIR, but if it's another team I can leave it for them
<tvoss> robert_ancell, it should be stephane graber for Ubuntu, the kernel team makes sure that our kernels are enabled
<tvoss> robert_ancell, does that help?
<robert_ancell> tvoss, thanks, I'll ask him
<tvoss> robert_ancell, cool, let me know if I can help
<alf__> hikiko: your turn :)
<hikiko> alf__, i just merged after a longtime and I wonder what some new things are:
<hikiko> eg. the internal native display
<hikiko> and the internal client
<alf__> hikiko: The internal client is the object in-process "clients" (like e.g. the shell) use to get the EGL handles they need to render
<alf__> hikiko: The InternalNativeDisplay, is the implementation of MirMesaEGLNativeDisplay (which is what Mesa expects from us) for the in-process clients
<alf__> hikiko: (this is of course only for the GBM case, Android uses other abstractions internally)
<alf__> hikiko: (Android uses other abstractions internally = meaning not InternalNativeDisplay)
<alf__> hikiko: btw, you don't any of this for render_to_fb to work
<hikiko> cool :) so I can leave them for later
<hikiko> I just need to understand what's going on :)
<kdub> hello all, status, working on swapinterval 0 for android, was unsucessful in getting unity next to run
<hikiko> kdub, ping
<kdub> hello
<hikiko> hello :)
<hikiko> kdub, in my sdl branch I get a compile error in a header file: android_input_manager.h:26 because it is included in the src/server/default_server_configuration.cpp
<hikiko> should this file be there or I can just delete the include line?
<hikiko> I don't do an android build
<kdub> hikiko, sure ,but the input stack is called 'android' too, its probably needed somewhere in the code
<hikiko> so the input for the pc-build uses the android_input_manager.h?
<kdub> yep
<hikiko> kdub, we have an important bug in this header file
<hikiko> we use the enum Status
<hikiko> but
<hikiko> Status is defined in the Xlib headers
<hikiko> i mean #define
<hikiko> in the android build you don't use Xlib
<hikiko> so you don't get any error
<hikiko> but in the gbm/sdl
<hikiko> we have to either remove that header file from the build or use another name for Status
<hikiko> can I fill a bug report?
<alf__> hikiko: where does Status come from?
<hikiko> X11/Xlib.h
<alf__> hikiko: no I meant from our side
<hikiko> src/server/input/android/android_input_manager.h
<alf__> hikiko: found it in 3rd_party/android-input/android/frameworks/base/services/input/InputDispatcher.h
<alf__> hikiko: But why do these too conflict? Why do X headers end up in src/server/default_server_configuration.cpp?
<hikiko> because sdl includes the X headers
<hikiko> and in any case I should include them :)
<hikiko> even if I used pure Xlib
<alf__> hikiko: right, but why do the headers end up included by src/server/default_server_configuration.cpp ? DefaultServerConfiguration shouldn't know anything about the implementation of Platform, Display etc which includes X/SDL headers
<alf__> status: Continuing lttng experiments/integration, cleaning up unused code
<hikiko> no idea
<alf__> hikiko: well, that's something to look into then :)
<hikiko> but I didn't write that file :s I have no idea of its internals why wouldn't we just rename status?
<kgunn> hikiko: can you not use namespace here to solve your problem?
<hikiko> no kgunn namespaces cannot override the preprocessor definitions
<hikiko> the preprocessor substitutions happen before the compiler even sees the file
<hikiko> so Status will be an integer
<kgunn> hikiko: oh...see that now in scrollback...#define
<hikiko> I think that maybe I should fill a bug report and send an email to the mailing list, maybe someone can suggest a solution :)
<kgunn> hikiko: not really the way it works
<kgunn> hikiko: i think you need to solve the problem & _then_ propose a solution
<hikiko> I can solve the problem 2 ways but I don't know what I might break in the android build
<kgunn> hikiko: if you end up with requiring a change to the name of something in mir, create a merge proposal & let it get reviewed
<hikiko> ah ok :)
<kgunn> hikiko: ah...but that's where testing comes in :)
<kgunn> hikiko: prove it to yourself
<hikiko> should I setup an android environment to test this? I have a nexus galaxy, does mir work there?
<alf__> hikiko: yes, although I guess as a first step it would be enough to check that everything builds (which you can do without a phone)
<alf__> hikiko: I am still curious how the X11 headers end up in default_server_configuration.cpp . Where are you including SDL, X11 headers in the code?
<hikiko> alf__, you mean if that if I choose the android platform in ccmake I can build it in the pc
<hikiko> only in sdl/display.cpp, sdl/display.h
<kdub> hikiko, you can cross compile from the pc
<hikiko> kdub, are there any instructions on how to do it?
<alf__> hikiko: for building on Android check http://unity.ubuntu.com/mir/building_source_for_android.html
<hikiko> ah cool :D
<alf__> hikiko: set up the repos/get all the dependencies mentioned there, and at the last step run the ./cross-compile-chroot.sh script
<alf__> hikiko: are you including sdl/display.h somewhere?
<hikiko> where can I get this script from?
<alf__> hikiko: its in the root directory of the tree
<alf__> hikiko: (note: check the "cross compile" part of the guide)
<greyback> kdub: hey, did you succeed in running qml-phone-shell on the phone yesterday?
<hikiko> oh I see alf__ thank you!
<kdub> greyback, no, hit a corrupt stack
<greyback> kdub: strange, want me to investigate anything?
<hikiko> ok, I will try to remove the .h first and if I get a break in android I will rename the enum and propose a merge
<kdub> greyback, i still haven't ruled out that I set it up wrong somehow, so probably nothing to investigate yet
<greyback> kdub: ok, well ping me if I can help.
<kdub> sure, thanks
<kgunn> greyback: should we get one of Pat's guys to try your instructions ?
<greyback> kgunn: they're very preliminary, things will get a whole lot easier once platform-api stuff settles down. But I have no objection
<kgunn> racarr: might join #ubuntu-touch
<kgunn> rsalveti is going to give mir/unity8 build a whirl
<rsalveti> cool, will give it a try later today (after uds)
<alf__> hikiko: my suggestion is to find out if you can avoid the naming clash, by finding out why X11 headers end up in default_server_configuration.cpp (and fixing that)
<hikiko> alf__, that's a solution only if we are 100% sure that we don't want to include X11 headers and android headers together
<hikiko> the problem is not the default_server_configuration.cpp but
<hikiko> that we include that android_something.h
<hikiko> if we include it elsewhere at somepoint
<hikiko> we ll end up to have the same problem
<hikiko> what I think is a better solution
<hikiko> is to not include android header files at all in a pc build
<hikiko> :s/pc/non-android
<greyback> kdub: racarr: We plan to have Mir to run as non-root user, right? Can you quickly say why right now we must run it as root?
<kdub> greyback, because sf does it, at least on android :)
<kdub> tbh, haven't tried it non-root on android much
<greyback> kdub: oh ok then /me gives up :)
<greyback> kdub: there's so much about this layer I yet don't understand, so I'm full of questions like these.
<alf__> hikiko: but that's the android input stack which now is mir's input stack for all platforms, we can't disable it
<alf__> hikiko: for any platform
<hikiko> that's why I think that I a rename is the best solution
<hikiko> I'll just rename the enum :)
<hikiko> and then you can include the file everywhere
<alf__> hikiko: that will just hide the underlying problem, i.e., that somehow X11 headers get included where they are not supposed to be included
<alf__> hikiko: I would be all for renaming if we actually needed to include both the input and X11 headers, but that doesn't seem to be the case... we get a spurious X11 header inclusion somehow
<hikiko> I understand what you mean and it's interesting to find why it happens, my point is that the rename is necessary if we are going to use the android input stack and the X at the same time, we ll end up to have similar conflicts anyway
<alf__> hikiko: when/if we get that problem, we can fix it then :)
<hikiko> we have it now
<racarr> Unlikely but possible cause of shell crash
<racarr> perhaps qtubuntu/platform API were built against mesa EGL headers (seems like hybris is built this way in packaging for example)
<racarr> o we ran in to the same old eglplatform.h nonsense
<racarr> which doesn't matter on 32 bit machines?
<racarr> nvm
<racarr> ok speculating about this bug is getting me nowhere so im flashing my nexus 4
<racarr> google claims it backs up all my app data anyway ;)
<kdub> racarr, use clockworkmod backup
<racarr> kdub: Even better
<racarr> You can multiboot nexus 7 but no one wrote it for nexus 4
<racarr> kdub: Oh wait, but this is literally a stock device so I have to oem unlock and clear it to install clockwork right?
<racarr> that will be good the second time though
<kdub> racarr, right
<tvoss> kdub, ping
<kdub> hey tvoss
<tvoss> kdub, hey, did you have a chance to debug greyback's issue?
<kdub> no, working on other performance things though
<tvoss> kdub, okay
<racarr> tvoss: I am working on it
<tvoss> racarr, okay
<racarr> but got stuck in a 6 hour diversion of trying to get mir working on nexus 7 again
<racarr> but um...
<racarr> it didn't work :p
<racarr> so now im in the minor diversion of flashing my nexus 4
<racarr> the stacktrace is just nonsense so I will need to reproduce it
<kgunn> racarr: wow...that frightens me off
<kgunn> re: 6 hr diversion of n7
<racarr> kgunn: Well tbh I didn't get that deep but it was really time consuming
<kgunn> racarr: did you try to use the upstream or kdubs libhybris
<racarr> wait I didn't know where kdubs was anymore
<racarr> but I tried to use the upstream and tried to backport it myself
<racarr> then tried to backport it myself again better
<racarr> haha
<racarr> same segfault in  um
<racarr> pthread_mutex_lock all around
<racarr> well thats not true, the first time I tried to backport it, it segfaulted very easly in a corrupt stack
<racarr> then the upstream version, and my second backport
<racarr> print much more debug info about loading android libraries and finding the tegra 3
<racarr> and then segfault in pthread_mutex_lock
<tvoss> racarr, that's a known issue with hybris
<tvoss> racarr, at least for the nvidia driver, it comes down to the fact that nvidia's driver uses a mutex shared across processes
<racarr> tvoss: https://github.com/libhybris/libhybris/pull/49
<racarr> this is what we mean by upstream in this conversation
<racarr> but it doesn't work
<racarr> libhybris trunk is very different looking from what we are using, so I am guessing
<racarr> it needs to be backported by something more intelligent than diff and dumbly resolving conflicts
<racarr> building clang too
<racarr> currently on a phone call from ubuntu, wild
<racarr> nexus 4 seem to overheat in calls
<racarr> haha
<racarr> kdub: Any advice with wireless on nexus 4? It claims to assosciate to my network but no connection (nexus 7 worked with no intervention)
<kdub> mine worked fine from the ubuntu wireless interface
<kdub> phablet-network-setup might help too
<kdub> (just copies your laptop's wireless conf on over to the device)
<racarr> annnd it magically fixes it
<racarr> self
<racarr> :)
<racarr> I thought mir was running but really surface flinger was just bugging out :(
<racarr> kdub: ...um...have you ever seen
<racarr> ...inverted? colors
<racarr> I think this is inverted
<racarr> its not inverted
<racarr> white is white but orange is purplke
<racarr> red is blue
<racarr> ok
<kgunn> usually pink/green
<racarr> format mix up
<kgunn> is when rgb formats get screwed
<racarr> I think
<racarr> this is unity in mir
<racarr> XD
<kgunn> meaning like ubuntu purple/orange ?
<racarr> well like
<racarr> the youtube icon is blue instead of read
<racarr> the background is a deep purple
<racarr> the camera icon is perfect almost
<racarr> facebook i orange
<kgunn> oh cool....
<kdub> sounds like an rb flip
<kgunn> yep
<racarr> mm
<kgunn> bgr rgb
<racarr> wait so
<racarr> why didnt it crash
<racarr> I was expecting it to segfault XD
<racarr> like greybacks
<kgunn> if its 888 then the bit sizes are the same
<kgunn> no worries...just interpretted wrong
<kgunn> http://graphics.github.io/bltsville/
<kgunn> this is really common
<kgunn> tried solving with this open project
<kgunn> actually this one related to it http://graphics.github.io/ocd/
<racarr> kdub: So if there are things on the screen and ps aux | grep surface gives me nothing
<kgunn> lots of people get bgr/rgb swapped due to differing spec's/interpretations
<racarr> I should be pretty confident it's mir XD? I'm trying to confirm
<racarr> the right QML phone shell is running, etc.
<kgunn> can you run dumpsys SurfaceFlinger from the android shell
<kgunn> that would tell you if surface flinger is rendering
<kdub> yeah
<racarr> dumpsys command not found?
<kgunn> gotta be in the android shell
<racarr> as in
<kgunn> not an adb command
<racarr> adb shell
<kgunn> yep
<racarr> I don't have it
<kgunn> hmmm, weird....i don't either
<kgunn> on my ubuntu device
<racarr> oh
<racarr> I know how to figure out XD
<racarr> ill run a mir client :p
<racarr> I do have a tmp/mir_socket so seems pretty promising
<racarr> also the screen is blue which seems unlikely to be something that surface flinger would do
<racarr> oh cool
<racarr> it is mir
<racarr> ...um
<kgunn> so does that mean we've been looking at surfaceflinger this whole time :-/
<racarr> ?
<racarr> No.
<racarr> the ...um is because
<racarr> my whole point here was to figure out why the inproces-shell doesn't run inprocess on the nexus 4
<racarr> but then it does
<kgunn> :D
<racarr> so now I have to find out why it crashes for other people XD
<kgunn> you cured it!
<racarr> and
<racarr> figure out how to make
<racarr> blue
<racarr> orange
<racarr> red
<racarr> something
<racarr> im going to do that first XD
<kgunn> wondering if that's the Qtubuntu plugin pixel cfg format
<kdub> i'd look there first
<racarr> Yeah
<racarr> 95% sure that's what it i
<kgunn> other could be our setting on the hw for color fmt is wrong :)
<racarr> trying to find the debian source for the packages gerry poted on chintrap
<racarr> kgunn: No I would be willing to bet somewhere in
<racarr> actually somewhere in ubuntu_application_api_mirserver
<racarr> there is like
<racarr> pixel_format = argb // TODO: ~racarr lol
<kgunn> :D
<kgunn> doh!
<racarr> ah yep there it is
<racarr> *grin*
 * kgunn kinda disturbed "we" took out dumpsys....awfullly useful
<racarr> hmm
<racarr> I cant get at the pixel formats from libmirserver easily right now...
<racarr> need to pass the buffer allocator through
<racarr> computers sure are fun
<racarr> why is it magically fixed...ugh
<racarr> maybe it really was the eglplatform.h nonsense and I don't understand
<racarr> integer promotion rules
<kdub> racarr, might be, i don't think i tinkered with that eglplatform.h fiel
<racarr> kdub: It's fixed in the PPA now
<racarr> my thought is that if the qtubuntu backage was built in pbuilder
<racarr> it used the mesa headers
<kdub> i don't know that the android build draws from that ppa
<kdub> at least the scripts
<racarr> mm
<racarr> well im ust going to try and fix the colors for now and sync up with greyback tomorrow
<racarr> cross your fingers :)
<kgunn> toes as well
<racarr> hey cool the colors are right
<racarr> feels really smooth
<racarr> gesture are all easy to use :)
<racarr> it's always so anticlimatic
<kdub> great :)
<kdub> racarr, yeah
<tvoss> racarr, which device?
<kgunn> racarr: oh don't worry....crazy will arrive
<racarr> tvoss: Nexus 4
<racarr> with inprocess mir shell :)
<tvoss> racarr, epic :) video?
<racarr> tvoss: After lunch. It's not much of a video though because it will look just like the out of process stuff except applications wont work :p
<kgunn> tvoss: like mirco said...strange milestones....we want nothing to change :)
<kgunn> even tho we are changing
<racarr> tvoss: A cooler video would have been when r and b were swapped
<racarr> "Ubuntu Phone: Midnight-ice theme"
<kdub> midnight ice blur
<kdub> the next big thing i hear ;-)
<kgunn> oh man....i want that.....mightnight ice blur phone!
<racarr> maybe ill get a transfer to marketing
<tvoss> racarr, ack :)
<kgunn> :D
<racarr> Ok lunch!
<kdub> thats a good idea
<kgunn> robert_ancell: aren't you on baby duty?
<robert_ancell> kgunn, Not until Tuesday
<kgunn> robert_ancell: ok, your mail was just a pre-emptive strike
<robert_ancell> kgunn, yep
<kgunn> racarr: kdub & greyback makin' all kinds of progress
<kgunn> robert_ancell: they have the inprocess shell working on n4
<robert_ancell> kgunn, nice
<racarr> gosh the mission is charming :)
<racarr> Walking around for lunch now includes trees which is a big plus
#ubuntu-mir 2013-05-17
<kdub> good morning, got swapinterval 0 (display) to work on nex4, galaxy nexus's driver is more difficult though
<tvoss> kdub, \o/
<alf__> status: first lttng probes up for review (after a valiant fight with clang and cross-compilation rpaths), removing unneeded mir_connection_drm_auth_magic() call and all related code
<alf__> all: Have a great weekend!
<kdub> you too alf__
<greyback> kdub: I was setting swapinterval 0 on galaxy nexus, but no luck. Will be interested to see what you do
<kdub> greyback, i'll let you know when swapinterval 0 is exected to work for the shell usecase :)
<greyback> kdub: thanks. I'm more curious /how/ you do it :)
<racarr> the swapinterval(0)
<racarr> just reminds me of when we had an FPS counter in beryl
<racarr> then once we enabled vsync
<racarr> everyone posted on the forum about their FPS dropping from 4000 to 60
<kdub> racarr, yeah... trying to avoid that
<racarr> XD.
<racarr> trying to track down how we accidentally implemented sticky keys :p
<racarr> I guess we are mapping on the wrong side of
<racarr> key repeat
<racarr>  / not ignoring repeated events
<racarr> well, not mapping, but updating the key state
<racarr> so xkb common is interpreting repeated shift key down as
<racarr> ...um...I don't even know what to call it
<racarr> shift levels , additional shifts
<racarr> haha
#ubuntu-mir 2013-05-18
<bschaefer> racarr, hey, are you still around?
<racarr> benonsoftware: A little bit
<racarr> bshaefer*
<Noobuntu> hello folks
#ubuntu-mir 2013-05-19
<robert_ancell> thomi,hey, I seem to have forgotten my password for jenkins / it has locked me out. Is it easy to reset?
<thomi> robert_ancell: sure, let me take a look
<thomi> sorry for the delay - I did a dist-upgrade, and then had no usable desktop for a while :-/
<thomi> robert_ancell: BTW, do you know what the current state of mir-on-X is?
<robert_ancell> thomi, still in progress
<thomi> ok, at some point I'd like to ask you some stupid questions about the stress test stuff I'm starting
<robert_ancell> Interesting, Jenkins has colour blindness support
<robert_ancell> It would be nice to have "not sucky UI support" too
<robert_ancell> thomi, sure, I'm off from tomorrow so today is probably a good time
<thomi> haha
<thomi> robert_ancell: OK, perhaps some time this afternoon?
<robert_ancell> sure
<robert_ancell> thomi, btw, I think the CI is broken on the lightdm unity branch: https://jenkins.qa.ubuntu.com/job/mir-team-lightdm-unity-raring-amd64-ci/10/console
<robert_ancell> I put the debian dir into the branch, and it looks like it might be still trying to merge a debian branch
<thomi> robert_ancell: ahh ok, that's an easy fix, but we'll need to wait for Francis to come online before he can redeploy the config
<thomi> I'll add it to my list of things to do today.
<robert_ancell> no rush
<robert_ancell> thomi, if I push directly to a branch, will Jenkins build packages? (i.e. if I skip the broken CI for now and just push on)
 * robert_ancell starts a dist-upgrade to saucy
<thomi> robert_ancell: no
<thomi> robert_ancell: packages get built as part of the autolanding process
<robert_ancell> ok, I thought so
<thomi> robert_ancell: however, there's a generic jenkins job I can use to build & dput a package
<thomi> so we can fake it till I fix the config
<robert_ancell> thomi, what do you recommend we do for releases then? I think merges don't handle tagging right. So when I released mir 0.0.3 I didn't do it thought a MP
<robert_ancell> (note doesn't matter much in our case since we merge so often)
<thomi> robert_ancell: well, the way things are "supposed" to work is that every push to trunk is a release. If you want to do a major release, you can just update debian/changelog with the new version number you want
<robert_ancell> thomi, what about tagging that release number?
<robert_ancell> revision number I mean
<thomi> I think tags get merged with branch merges?
<thomi> surely...
<thomi> I've never tried though
<robert_ancell> yeah, I *hope* that's the case but I'm not sure.
<thomi> so I think you should be abel to tag the branch in your MP
<thomi> worth a try anyway
<robert_ancell> In my experience with bzr it tends to not always take everything from the branch, e.g. attribution
<robert_ancell> yeah, I'll try next time. Though bzr/lp is famously bad at being possible in theory but impossible in practise to move/correct tags
<thomi> robert_ancell: with the mir stress test, do we care whether the client makes accelerated calls or not? I'm not sure if there are different code paths server side?
<robert_ancell> thomi, I guess we should test both? From Mirs point of view I don't think it matters much how the buffers are filled
<thomi> I guess I can hack up an unaccelerated one, and let one of the graphics gurus add the accelerated version...
<thomi> cool
<robert_ancell> I *think* the accelerated one will be testing mesa, and the non-accelerated one will be testing without
<robert_ancell> So we can look at the difference and probably have some idea of the mesa overhead
<thomi> cool
#ubuntu-mir 2014-05-12
<duflu> RAOF: efifb would be covered by a Mir-side fbdev driver right?
<RAOF> duflu: Yes.
<duflu> Cool
<RAOF> duflu: As long as we don't want to handle resolution changes, anything providing /dev/fb0 will do.
<duflu> Everyone loves to hate fbdev. I'm not familiar with it so don't know why yet. But I'm not impressed at all by DRM either
<RAOF> Well, fbdev doesn't *do* anything.
<duflu> Just a header/API right?
<duflu> Hmm, I didn't realize we'd miss out on mode changing. That's one benefit of SimpleDRM
<RAOF> Right.
<RAOF> I mean the API doesn't do anything.
<RAOF> Other than allow you to mmap /dev/fb?, basically.
<duflu> Yep, that's the minimum
<duflu> (with stride and dimension info)
<duflu> and pixel format
<RAOF> Yeah, there are ioctls for querying those.
<RAOF> And for uploading new 256 colour palates!
<duflu> RAOF: Party like it's 1991
<RAOF> Right.
<duflu> Then again, people still use GIFs with 256-colour palettes
<duflu> How did GIFs survive? It must have been wide-scale compatibility that made them convenient
<duflu> That and the patent on LZW expired
<RAOF> And a pre-calculated, per image 256-colour palate is much less offensive than a system-wide 256 colour limit.
<duflu> I think even per image it was offensive... but became less so when we stopped measuring pixels in mm :)
<duflu> and dithering was more effective
<duflu> RAOF: Only one concern with raw fbdev I think... on some platforms (VMs) the default resolution isn't going to be the desired resolution. Are you saying fix that later?
<RAOF> Yes, because we can't reasonably fix it with fbdev.
<RAOF> The user can, however, by setting a video= kernel command line parameter.
<duflu> Sure. Just means we've all but decided to chase fbdev before chasing SimpleDRM
<duflu> ... or per-driver mode setting :P
<RAOF> I don't think that we'll need to do anything to support SimpleDRM other than making mesa handle swrast.
<RAOF> Well, and for added bonus points do a pixman-based compositor.
<duflu> RAOF: I'll be more convinced when we have a flag to enable shm on our existing platforms for GL rendering. :)
<RAOF> Well, that's roughly equivalent to having mesa handle swrast :)
<RAOF> duflu: I'm really conflicted about lp:~duflu/mir/dpi. The more I think about it, the more I think DPI is the wrong thing to be exposing.
<RAOF> duflu: Because the client wants to render on a 300DPI phone significantly different to on a 300DPI desktop display connected to that phone.
<RAOF> s/different/differently/
<duflu> RAOF: It's a metric both existing toolkits (GDK/GTK) need and also my geometry::Length requires to implement window frames. So we need DPI calculated at some point
<RAOF> GTK/GDK don't really use DPI though; they use scale-factor.
<RAOF> Or, at least, GTK apps handle DPIs significantly different to 96 extremely poorly.
<RAOF> And I think geometry::Length is the wrong measurement.
<RAOF> Measuring in cm-on-screen is easy, but isn't actually what you want.
<duflu> RAOF: *Correct* apps will call gdk-screen-get-resolution to size their widgets. That returns DPI
<duflu> RAOF: Measuring cm on screen is exactly what you want. e.g. the Unity panel is always 0.25" high
<RAOF> duflu: *GTKs* widgets handle DPI-significantly-different-to-96 really badly.
<RAOF> duflu: But you *don't* want the Unity panel to be 0.25" high on a phone.
<duflu> RAOF: More importantly for buttons and text, you're talking a fixed size
<RAOF> duflu: You want the Unity panel to appear to be the same size as if it were 0.25" on an external display.
<duflu> RAOF: Ignore phone for the moment (since it's visually different) and consider different monitors.
<duflu> Yes, if you're displaying a phone status bar, that's always smaller than 0.25"
<duflu> But ideally always the same physical size
<RAOF> Right, which is what PPD gets you.
<RAOF> At least without actual measurements of user-distance.
<duflu> RAOF: I've hardcoded the viewing distance in the screen perspective transformation. I'm sure with PPD we could still query DPI for easy consumption
<duflu> RAOF: Regardless, having a DPI value is blocking WM progress
<duflu> I need to attach a DPI value (or something) to each surface
<RAOF> Sure!
<duflu> ... something which is convertible to DPI without additional parameters :S
<RAOF> I think that is actively harmful.
<RAOF> Not very harmful, but a bit.
<duflu> RAOF: I can make perfect DPI-scalable graphics right now, with ease. Just give me a DPI number... from somewhere :)
<duflu> It's crazy I fought for years to get Unity7 to where it is in 14.04 and still it falls short of the basic requirements I described 2 years ago
<duflu> RAOF: It's not strictly blocking, however everything that requires a DPI value right now would be hardcoded (e.g. 96) until a real value is available
<RAOF> duflu: Slurp the DPI from the display, assume 64cm for external monitor and 50cm for laptop, and go :)
<duflu> RAOF: Or... calculate it precisely using basic math :)
<duflu> I'm happy to have a configurable scale too
<duflu> RAOF: But a client can't tell which display it is on, so it requires the server to tell it the physical pixel info
<RAOF> Sorry, those were viewing distances.
<RAOF> You can easily get the DPI from the EDID.
<RAOF> But the client can't render correctly using the DPI.
<duflu> RAOF: It's trivial. I've been doing it for years.
<RAOF> (Or, at least, with _just_ the DPI)
<RAOF> EG: You've got a phone plugged into an external display. Both are 300DPI. You want the output on the external display to be significantly different to the output on the phone.
<duflu> RAOF: OK I can add viewing distance as a parameter to geometry::Length::as_pixels but I don't think that blocks DPI work
<RAOF> It's the same API.
<RAOF> Or, rather, it's an API for the same purpose.
<RAOF> Unless we add in the DPI API now, then deprecate it when we put in the proper solution.
<RAOF> Which is viable, I guess. We're planning on breaking API, why not one more thing? :)
<racarr__>  how about everytime you break API you also have to opaquify an existing client struct
<RAOF> :)
<duflu> Or fix 10 bugs :)
<duflu> RAOF: If you can propose the more generic solution that would be great. In the mean time I'm not blocked and will just assume 96ish DPI where the value is required
<duflu> Hmm, or is it just a second attribute?
<duflu> mir_surface_attrib_viewing_distance
<RAOF> It's modelable as a second attribute.
<RAOF> As I wrote on the MP, I think the tuple {DPI, form_factor, PPD} expresses everything that a client might possibly want to know (but would prefer to not expose DPI, on the basis that clients are unlikely to use it well)
<duflu> Which can also be assumed as a hardcoded value for now. Its later introduction doesn't change the physical size of an inch
<duflu> RAOF: I'm also conflicted with dreams of eventually doing head tracking to update the real eye vector :)
<RAOF> duflu: Totally possible! Laptops will ship with kinect in the not-too-distant future!
<duflu> But that too does not change the definition of an inch
<RAOF> duflu: But *does* change what should be rendered.
<RAOF> It certainly doesn't change the physical DPI of the display, but the physical DPI of the display was never what you wanted in the first place; you always wanted apparent-size.
<RAOF> Or, rather, you want the DPI in order to determine how big to draw things. You want to determine how big to draw things so that they appear to be an appropriate size to the user.
<duflu> RAOF: Physical size is important. That dictates the reasonable minimum size of any touch-button on a phone or a big screen. In cases like that, viewing distance must be approximately equal to reach out to
<RAOF> We could just tell you how big to draw things so that they appear to be an appropriate size.
<RAOF> To reach out to...?
<duflu> To physically touch. That said, design requirements change too. Like how an ipad has bigger icons to an iphone
<duflu> You're still holding them at the same distance
<RAOF> I don't think that's the case, actually.
<RAOF> I think people tend to hold phones closer than tablets.
 * duflu refuses to continue that far down the hypothetical path
<duflu> Time to do other work
<RAOF> (Apple at least think people hold iPhones ~25cm from their eyes, and iPads ~38cm âº{)
<RAOF> Yeah, certainly.
<duflu> Well, if anyone's done the physical research then it would have been Apple
<duflu> I find that odd
<RAOF> Tablets are bigger :)
<duflu> 25cm is very close. Are people blind?
 * RAOF has just determined that he holds his phone between 28cm and 24cm away from his nose.
<duflu> Hah, I just measured 39cm for iPhone :)
<RAOF> Wow. That's getting pretty close to arms-length.
<duflu> No, still pretty bent in the elbow
<duflu> Arms length is about 60cm
<RAOF> Dear âbzr headsâ: please find that branch head you seem to have deleted somehow.
<RAOF> Woo!
<greyback> hey folks, quick question: for screencasting, is the intention for the screencast app to connect to the system compositor (as that is what pushes the final pixels to the screen) or to the session compositor?
<alan_g> greyback: is that for Mir to decide? Doesn't that question come down to the needs of the screencast app? (E.g. does it screencast the user session or does it want to "cast" lock screens and switching users?
<alan_g> )
<alan_g> My guess would be it should be to the session server. But I'm not designing screencast. ;)
<greyback> alan_g: fair point, I can't say what the intention was, but I can ask what he requirements for the feature were :)
<alan_g> alf_: Mir's "screencast" should support both scenarios ^^ right? (But connecting to the system compositor ought to be privileged.)
<alf_> alan_g: greyback: Right, you can connect to any mir server (nested or host) and get that server's output
<alf_> alan_g: greyback: (if you have the needed priveleges of course)
<alf_> s/priveleges/privileges/g
<greyback> alf_: yep, that's clear. I'm trying to see how QtCompositor will work with the screencasting stuff
<greyback> so was curious if I had to care at all (only system compositor would be used for screencasting) or if I did have to care
 * greyback thinks he has to care :)
<alf_> greyback: hmm, yeah, screencasting uses the DisplayBufferCompositor(Factory) interfaces currently
<greyback> alf_: to just check I understand it, for screencasting you create a new GL context, a new renderer for that context and have it render to an FBO, which then you glReadPixels back?
<alf_> greyback: right, except we don't glReadPixels in the server. We create a new hardware buffer to back the FBO, render into it, and send that back to the client. Then the client can do what it wants with it (our official screencasting client glReadPixels).
<greyback> alf_: gotcha
<greyback> alan_g: can I confirm your intention to eventually remove mir::scene::SurfaceConfigurator?
<greyback> alan_g: and is everything wired up so I could replace my use of it with mir::scene::SurfaceObserver?
<alan_g> greyback: Sorry that works's several levels down my stack - I need to review to give a good answer.
<greyback> alan_g: that's ok. I'm in absolutely no rush for an answer
 * alan_g promptly forgets about the question
<greyback> another quick question
<greyback>     geometry::Size size() const override;
<greyback>     geometry::Size client_size() const override;
<greyback> in BasicSurface
<greyback> what is the difference exactly? One the actual geometry of the surface in pixels, the other the size it should actually be rendered at (i.e. scaled)
<greyback> ah, never mind
<greyback> basic_surface.cpp:    // TODO: In future when decorated, client_size() would be smaller than size
<greyback> which troubles me, what has decoration got to do with a client's surface?
<alan_g> greyback: You're best talking to duflu  - he's got plans in this area that mean the area of a surface Mir renders can be larger than the area the client is made aware of.
<greyback> alan_g: indeed. Will have a chat with him
<kgunn> 709cardinal
<kgunn> oops wrong window
 * greyback theorizes what kgunn was writing about in that other channel
<kgunn> my address
<alan_g> alf_: do you have an opinion on https://code.launchpad.net/~alan-griffiths/mir/introduce-yet-another-interface-into-frontend/+merge/218667?
<alf_> alan_g: haven't looked yet, will do so shortly
<josharenson> kgunn, how would you like me to proceed re: glmark2 android off-screen (or the lack thereof)
<kgunn> josharenson: do you have an inkling of how to enable it ?
<kgunn> josharenson: second question, does everything hit 60 fps ?
<kgunn> on android
<kgunn> on nexus4?
<kgunn> (running on n10 & n7 pure droid might be interesting also)
<josharenson> kgunn, I'll run it an see... as for enabling it, I looked for a few ways, and there wasn't anyhting easy...
<josharenson> kgunn, you can disable vsync, but it seems to only be app side...
<josharenson> kgunn, I'll look at the code too
<kgunn> josharenson: thank...yeah, i don't want you to go down a rathole...but worth a look
<josharenson> kgunn, would the on screen numbers be of value, across devices?
<kgunn> josharenson:  i think so, it will show some relativism and effect of gpu
<kgunn> sensitivity
<josharenson> ok
<josharenson> alf_ are you aware of any way to run glmark2 off screen on android? looks like its not implemented...
<kgunn> kdub_: you back ?
<kdub_> kgunn, yep!
<kgunn> welcome back! hope it was a good time of
<kgunn> off
<kdub_> thanks!
<kdub_> looks like time to upgrade to utopic
<racarr__> http://richg42.blogspot.co.uk/2014/05/things-that-drive-me-nuts-about-opengl.html
<racarr__> from a dude at valve, its interesting
<racarr__> he has lots of bullet points ;)
<racarr__> alf_: I sa you filed a bug about the custom input dispatcher fixture failure are you orking on it?
<racarr__> I ran in to it too
<slvn_> hello, a little question :
<slvn_> I have ubuntu 14.04, I give a try and setup unity8 + mir
<slvn_> My touchscreen is not used ! only my mouse is detected
<slvn_> but I have the /dev/input/mice with receive both mouse and touchscreen information
<slvn_> do I need to configure something special?
<racarr__> slvn_:  :) Thanks for testing...you are the second person to bring this up so I guess I should take some time to look at it.
<racarr__> slvn_: I think its basically just a bug on our end...
<racarr__> for the touch devices e look for these device configuration files
<racarr__> that arent present ont he desktop
<slvn_> racarr__,  yes, my touchscreen is still under warranty :)
<racarr__> I may be able to suggest a workaround
<racarr__> if you are interested in testing
<slvn_> racarr__, is there some configuration file that patch
<racarr__> need just a minute or to to figure out
<racarr__> maybe!
<slvn_> racarr__, yes
<racarr__> this is some code we inherited from android open source project
<racarr__> so I have to remind myself...hat it does
<slvn_> racarr__, I am fine to test a workaround, because my goal is to test something more complicated afterwared
<racarr__> oh boy fun :D
<racarr__> slvn_: Ok can you run unity8 or mir_demo_server_basic for me (make sure to run demo_server as root so it can open input, otherwise you cant quit ith ctrl+Alt+backspace)
<racarr__> with MIR_SERVER_LEGACY_INPUT_REPORT=log
<racarr__> slvn_: and I guess riter stdout/stderr to a file we are looking
<racarr__> for some messages about opening input configuration files
<racarr__> to find what it is calling your touch screen
<racarr__> then we will make a conf file
<racarr__> slvn_: IF you run unity8 yourself you will also need to run it as root...from a VT like sudo QT_QPA_PLATFORM=ubuntumirserver MIR_SERVER_LEGACY_INPUT_REPORT=log unity8 > input-log.txt 2>&1
<slvn_> racarr__ of course, I need to close my X session right?
<racarr__> slvn_: No you should be able to just run it from a VT
<racarr__> and even switch back and forth
<racarr__> beteen your X VT and Mir :)
<racarr__> slvn__: Uhoh...did we kill your machine ?
<slvn__> racarr__, yes some trouble :)
<racarr__> hmm what happened?
<slvn__> I probably didnt do the command correctly ...
<racarr__> I mean ho did it break though?
<slvn__> can you copy paste the command again (my textfile hasn't been save)
<slvn__> mir is displayed
<slvn__> but could get out of it
<racarr__> oh did you forget to run as root?
<slvn__> so I rebooted ..
<racarr__> maybe missed the sudo
<racarr__> sudo QT_QPA_PLATFORM=ubuntumirserver MIR_SERVER_LEGACY_INPUT_REPORT=log unity8 > log.txt 2>&1
<racarr__> should be the stuff
<slvn__> terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<std::runtime_error> >'   what():  Error opening DRM device
<racarr__> but it worked ithout root? Hmmm
<racarr__> very strange...
<racarr__> *thinks*
<slvn__> in a terminal, doing Alt+F1
<slvn__> in root
<racarr__> slvn__: You mean a virtual terminal yes
<racarr__> not a terminal in X11
<slvn__> yes, a VT
<slvn__> I need to reboot that in a VT
<slvn__> hold on...
<slvn__> I need to redoo that in a VT
<racarr__> :)
<slvn__> ok got it
<racarr__> slvn__: Yay, can you put the log on a pastebin?
<slvn__> http://pastebin.com/nBkF7dz9
<racarr__> slvn__: Ah...hmm its actually failing earlier than I guessed
<slvn__> I have a laptop with a trackpad + a mouse (evoluent) + a usb keyboard + an external monitor with touchscreen
<racarr__> so I dont really have a workaround...sorry lol
<racarr__> this is helpful though...I can see where it fails so ill look in to it and try and get something fixed
<slvn__> racarr__, where does it fail exactly ?
<slvn__>  in /dev/input/mice ?
<racarr__> slvn__: Yeah around line 20
<racarr__> its trying to get...some sort of driver info ith some sort of IOCTL Thats not supported on the desktop
<racarr__> and apparently there is a fallback for the builtin mouse but
<racarr__> the touchscreen just fails
<slvn__> ok :(
<slvn__> it is working on ubuntu 14.04, but not with unity8. though
<racarr__> slvn__: Mm. makes sense.
<racarr__> slvn__: I think it wont be hard to fix...if you want I can try and prepare a branch for you to test later today
<racarr__> (I dont have a desktop touchscreen)
<slvn__> Yes, that would be nice :)
<slvn__> I dont know how hard this is to compile unity8
<slvn__> +mir
<racarr__> slvn__: Ok great. Will you idle around in the IRC channel so I can catch you sometime later today or tomorrow (I am us pacific time)
<racarr__> or should I send you an email?
<racarr__> or I guess we could use a launchpad bug haha
<slvn__> I am in europe
<slvn__> by email
<racarr__> slvn__: Ok. Wanna pm me your email and I ill try and work on something with instructions to test this afternoon
<slvn__> maybe we could first try the piece of could that should do the ioctl on /dev/input/*
<racarr__> and you should get them tomorro :)
<racarr__> yes I think hat is going on is the ioctl is to read
<racarr__> some like, identifier tag for the device that seems to only work on android
<racarr__> to try and load a device configuration
<racarr__> so I think we can just build in a default touchscreen configuration
<racarr__> which will work on the desktop
<anpok> ha someone looked into the clang ci failures..
<anpok> there was one error that happened on my and on alfs mp
<anpok> could reproduce locally
<anpok> *could not :)
<racarr__> I havent looke dyet happened to my MP too though
<racarr__> anpok: Hmm wait
<racarr__> looking at the tests...
<racarr__> can you run a server process without ac lient with our test fixture
<racarr__> when the last client exits
<racarr__> the server process is stopped by the fixture
<racarr__> which is why all these input tests only set client_may_exit fence after
<racarr__> all the expectations are validated
<racarr__> just a guess :)
<anpok> a failure only with clang in the bespokedisplayserver fixture based tests
#ubuntu-mir 2014-05-13
<RAOF> Today's yak shaving: gdb --args gdb --args bin/mir_unit_tests --gtest_filter=...
<duflu_> RAOF: Heh. I encountered gdb crashes ending last week too. Very frustrating
<RAOF> Prior to that was working out why my local MTA wasn't working.
<RAOF> Spoilers: nullmailer is terrible, and should not be used by anyone.
<tvoss> RAOF, have been to the nullmailer movie, too :) quite interesting how much CPU something that simple can use
<RAOF> Quite interesting how many people feel like reimplementing getopt() without features such as âoh, maybe someone will want to have a space in the inputâ :)
<duflu> Gah, gdb keeps crashing!
<RAOF> While reading debugging symbols?
<RAOF> It's pretty rad, isn't it?
<anpok_> alan_g: I need you opinion
<alan_g> anpok_: about?
<anpok_> the issue you discovered in the drop-dynamic-ptr-cast MP - I see two possible ways of cleanup to fix that kind of issue
<anpok_> not sure which path to take
<anpok_> because only the server holds the input_dispatcher_configuration and because of the order of calls the in the nested case
<anpok_> the first instance of it gets discarded after initializing the nested platform
<anpok_> i thought to fix it by removing the dispatcher_configuration entirely
<anpok_> there are only two method calls involved the rest of the initialization parameters is passed only through constructors
<anpok_> .. now I wonder if I should try to hide the droidinput::DispatcherPolicy and droidinput::InputDispatcherInterface types from the default_display_configuration
<alan_g> Hm. This is the problem with several "configuration" objects that hold state. Getting rid of them is a good idea.
<anpok_> I could do so by moving the construction and wiring into the implementation of mir::input::android::AndroidInputDispatcher
<anpok_> or should I have them as entities in the DefaultDisplayConfiguration
<anpok_> when moving them down there, testing without them will require separate construction code..
<anpok_> down == AndroidInputDispatcher
<anpok_> on the other hand I dislike leaking that namespace (android and the alias droidinput) into DefautlDisplayConfiguration
<alan_g> anpok_: I think the long term progression will be to move stuff from the "3rd_party" fork of android input into "src" - and that will eventually resolve the naming issues.
<alan_g> So I'm not too bothered by exposing the names. (Or we could just move the classes to a new namespace and have that referenced from droidinput"
<anpok_> it would be the names and CachedAndroidPtr
<anpok_> that one pulls in Ref
<anpok_> RefBase and StrongPointer
<alan_g> Not so nice.
<anpok_> which
<anpok_> might then go away one day too
<alan_g> True. Making them go away would be nice.
<anpok_> I could try to move those to <memory>
<anpok_> ok then I will go for the slightly simpler but cleaner solution
<alan_g> Yes. For just a couple of classes that might work. But it could also start an unravel.
<alan_g> How about spending an hour or so on changing those sp's as a separate prerequisite MP? If it doesn't go easy then give up for now.
<anpok_> yap
<alan_g> Has anyone else noticed that "discover_tests_in_mir_unit_tests" takes an age. WTF is it doing?
<duflu> Discovering?
<duflu> :)
<anpok_> nothing left to be found?
<duflu> alan_g: Was there any other rule to distinguishing errors from exceptions apart from recoverability?
<alan_g> duflu: that's certainly one. But with a whole range of error reporting options there's a few nuances. You have a specific example?
<duflu> alan_g: I have a rather nice framework, but am trying to avoid converting too many exceptions to errors. You will see...
<kgunn> greyback: so i'm seeing some other people talk about splash screen in mir...but to me, that doesn't make sense, shouldn't it be unity-mir that paints the 1st frame with a "unity8" splash ?
<kgunn> e.g. other shells might want to have their own splash
<greyback> kgunn: some shells may not want a splash (desktops don't usually)
<greyback> kgunn: I intended that unity-mir would supply info to the shell, so the shell could show the splash screen
<kgunn> greyback: so potentially configurable based on "form factor" ?
<greyback> kgunn: right
<kgunn> greyback: thanks, at least we both agree, not a mir thing but a shell thing
<greyback> kgunn: yep
<greyback> kgunn: there's a few outstanding questions on splash screen stuff, https://blueprints.launchpad.net/ubuntu/+spec/appdev-1311-sdk-appstartupsplash
<greyback> kgunn: I'll ping kalikiana and see where they're at
<racarr__> Morning
<seb128> rhey racarr__
<racarr__> seb128: Btw someone else ran in to touchscreen not working in unity8 and I got some logs...am going to debug it today
<racarr__> so may have a fix
<seb128> great, thanks
<racarr__> ill email you if so :)
<seb128> let me know if you need debug info from me
<racarr__> I have no touchscreen so will need testing friends at least
<seb128> sorry I didn't propose that to the other day, I though it was a "need a local config" not a "it's a bug"
<seb128> I can do that
<racarr__> np
<racarr__> I thought it was just going to be a config file thing too but the other guy gave me some logs and there is
<racarr__> some sort of small email
<racarr__> some sort of small bug*
<racarr__> ...the keys are right next to eachother?!
<seb128> (I hope that poor celeron box is good enough to build Mir, I've hear comments about Mir being yet another of those awesome c++ projects so easy to build)
<racarr__> haha itll be fine
<racarr__> alan_g: I have run in to a strange architecture issue with the scene observer and cursor and am wondering if you have any ideas...
<racarr__> the problem is...ok so my basic approach is there is a new mi::CursorListener implementation
<alan_g> racarr__: ideas me?
<racarr__> which takes mi::InputTargets and
<racarr__> when the cursor moves finds the surface under it and sets the cursor image, et
<racarr__> c
<alan_g> CursorListener is an interface or the new implementation?
<racarr__> CursorListener is an existing interface
<racarr__> right now it just takes cursor_moved_to from the input stack and calls mg::Cursor::move_to
<racarr__> so the new CursorController impl takes these cursor_moved to and calls mg::Cursor::move_to but also looks for the appropriate uh
<racarr__> unoccluded surface to get its cursor image data
<racarr__> the problem is with mi::InputTargets....
<racarr__> my idea was to promote scene::add_observer to mi::InputTargets. because this thing also needs to be an observer clearly
<racarr__> but that doesn't work
<racarr__> because scene::add_observer passes scene::Surface*
<racarr__> and in my tests I just want to stub/mock input::Surface/input::InputTargets
<alan_g> Naturally
<racarr__> so I can't think of any satisfactory solution...I mean obviously mi:CursorController shouldn't take mc::Scene
<alan_g> But why does it want to observe scene? Doesn't it really want to ask InputTargets to supply the right cursor?
<racarr__> alan_g: Oh hmm
<alan_g> input_targets->update_cursor(cursor);
<racarr__> there also needs to be some observation...maybe it can be internal to the input targets or ith another method though
<racarr__> but I mean, surface closes, you may need to update the cursor
<racarr__> So I mean one "fix" would be
<racarr__> input_targets->update_cursor_image(cursor, point) +
<alan_g> Yes, but CursorListenerImpl is only handling cursor movement events
<racarr__> input_targets->add_occlusion_change_callback
<racarr__> std::function<void()>
<alan_g> Actually...
<racarr__> but that seems like a pain too
<racarr__> alan_g: Who handles the
<racarr__> say surface destroyed and need to update the cursor "events" t hough
<alan_g> Why is CursorListener telling the cursor what to do? Surely a Listener tells other things that it has changed
<racarr__> alan_g: Android inputism
<racarr__> CursorListener should be named
<racarr__> CursorSink
<racarr__> or something
<racarr__> its just how we get the cursor pos out of the input stack
<alan_g> So CursorSink isn't the thing that monitors model changes
<racarr__> hmm
<racarr__> not necessarily no
<racarr__> but the thing that implements CursorSink...could conceivably be that.
<racarr__> because I was trying to keep it to one place that manipulates the cursor image
<racarr__> because there is some logic, i.e. if no surface is present at point use the cursor specified as default
<racarr__> if the scene change doesnt change the cursor image avoid reuploading it (significantly reduces noise ina cceptance tests in addition to being an optimization)
<racarr__> etc...
<alan_g> Sure, but I've a feeling that the "surface isn't there anymore" notification should come via compositing not the scene
<racarr__> via compositing?
<alan_g> Isn't it the compositor that maps the scene into the display? And owns the cursor?
<racarr__> no, the compositor doesnt much to do with the cursor
<racarr__> as it stands its in the gbm display buffer mostly
<racarr__> but the goal is the scene owns the cursor
<racarr__> so it will just be another type of renderable
<racarr__> because on android there is no special cursor buffer or anything
<racarr__> and also we want to support software cursors well, etc...
<alan_g> If the scene owns the cursor how do you manage spreads and other effects?
<racarr__> ? Even when you spread the cursor is still just
<racarr__> a 64x64 buffer that appears on top of
<racarr__> everything
<racarr__> that is rendered at an x,y coordinate
<alan_g> The scene isn't changed when you do a spread
<racarr__> but the cursor doesnt change when you spread unless
<racarr__> it would change anyway due to toehr things right?
<racarr__> Also in "qt compositor short term arch" certainly the scene doesnt change
<racarr__> when you spread
<racarr__> but in "qt compositor long term arch"
<racarr__> it does right, I mean spread is transformation updates, etc...
<racarr__> ah I see what you are getting at, how would you update the right
<racarr__> cursor image in case of spread, etc...
<racarr__> I dunno
<racarr__> I still feel very strongly that
<racarr__> updates to the view/what is rendered
<racarr__> that arent expressed in the model
<racarr__> will be the architectural death of us if we do it :p
<racarr__> so all this stuff like spread, zoom, decorations being int he compositor/renderer
<racarr__> worries me a lot
<alan_g> They are projections of the model onto the screen. And the cursor is tied to the screen image and not projected.
<alan_g> anyway standup time
<racarr__> I see...maybe
<racarr__> the problem is it becomes
<racarr__> "Model Model-View-Controller Controller"
<racarr__> which is a pretty hair architecture :p
<RAOF> Ok. Now that my tea has stopped trying to murder me...
#ubuntu-mir 2014-05-14
<racarr__> RAOF: Ok so I am trying to send you the xmir changes on github...the thing is I had some issue with vladmir and the intel driver and you werent around so I ended up basing them just on the packaging source
<racarr__> so now I am trying to port them to vladimir, well there isnt much to do, but anyway I think thats done
<RAOF> racarr__: Ah, cool.
<racarr__> but how ... should I build it lol
<racarr__> i.e. what are some reasonable ./configure options
<racarr__> because there is no deb dir in vladimir
<RAOF> Hm. That's dropped out of my zsh history ;)
<racarr__> oh no
<racarr__> we will have to consult the sage atop X11 mountain.
<RAOF> racarr__: But I'd just build it with --enable-xmir as a first go.
<racarr__> ahahha ok
<racarr__> I tried config.log and got ./configure --prefix=/usr --mandir=${prefix}/share/man --infodir=${prefix}/share/info --sysconfdir=/etc --localstatedir=/var --build=x86_64-linux-gnu lt_cv_prog_compiler_static_works=no lt_cv_prog_compiler_static_works=no --disable-silent-rules --disable-static --without-dtrace --disable-strict-compilation --enable-debug --enable-unit-tests --with-int10=x86emu --with-extra-module-dir=/usr/lib/x86_64-
<racarr__> but it doesnt work
<racarr__> presumably because of quotes but I havent found where to put them all yet
<racarr__> lol
<racarr__> hmm
<racarr__> RAOF: I need a new xtrans presumably I need to update
<racarr__> to utopic?
<RAOF> racarr__: Hm, dunno, seems to work for me (on utopic) :)
<racarr__> ok well enter the unicorn after meeting
<racarr__> RAOF: Ok I am making a beeline for food then will send you patch that I expect to ork on vladmir and you can try it out
<RAOF> Wickedcool.
<RAOF> TO THE COFFEEOTRON!
<RAOF> Are we going to be using EXPECT_THAT for all test expectations, rather than all of the various EXPECT_{GE,TRUE,WHATEVER} specialisations that exist?
<duflu> RAOF: I hope not. Sometimes the latter is much clearer
<duflu> Although people seem to be converting everything to the former
<RAOF> Yeah. I'm not sure why EXPECT_THAT(foo(), Eq(true)) is any clearer than EXPECT_TRUE(foo()).
<duflu> RAOF: Coming soon: Lots of EXPECT_DEATH in some of my new tests :)
<duflu> and EXPECT_EXIT
 * RAOF is a fan of EXPECT_DEATH
<duflu> lol
<anpok> hm seems like due to a change in initialization order the session manager gets an added surface before the input targeter / input registrar hence it complains that it cannot set the focs to that surface
<anpok> (on one of my cleanup branches)
<anpok> hm i think it happens in a different thread have to look again
<alan_g> anpok: the SurfaceCoordinator ought to be coordinating the surface addition. (Although I was interrupted in that doing cleanup)
<anpok> hm
<anpok> the issue is actually different again
<anpok> the moment I now register the input registrar (great names) as observer to the scene, at that moment nobody holds a strong reference to the scene yet
<anpok> oh scene is not even part of the DisplayServer::Private
<anpok> input dispatcher conf had one
<anpok> should i make a small mp for DisplayServer::Private to hold the_scene() early in the initialization?
<anpok> yes, mir::compositor::Scene seems to be wrong.. but that would be another (bigger?) change?
<anpok> i wanted to say - we should have  mir::scene::Scene and it should look different..
<alan_g> anpok: if you're writing something that needs the scene then why isn't that keeping a reference?
<alan_g> It seems wrong to rely on "someone else" holding ownership for you
<anpok> well it does not necissarily need the scene - it is something that is bridging information between the scene and what the droidinput::InputDispatcher sees
<anpok> thats true
<anpok> i find the entities that we store in DisplayServer::Private rather arbitrary
<anpok> at the moment the objects there are objects that need to be informed about stop / start / pause
<alan_g> They're the ones that the DS needs to start/pause/resume/stop
<alan_g> That's not arbitrary
<anpok> we could also make an abstraction for that .. a system state observer .. yes inverting that.. and react on state changes in the components
<alan_g> anpok: does that help your current lifetime management issue?
<anpok> no it might unveil further issue
<anpok> *issues
<anpok> i hestitated to add the scene to the registrar, because the interface of scene requires a shared ptr to register..
<anpok> so I would have to do something odd like shared_from_this or well rely on the caller to register - just like before
<anpok> with my statement above I wanted to stress that ownership (as a keep alive concept) and observation of changes should be somehow separate
<anpok> and we could redefine the role of starting and stopping as something that needs subsrcription to a state change
<anpok> and then we would have to define ownership separately and make it more explicit
<anpok> and more fine grained...
<alan_g> OK  I agree that if scene owns registrar then registrar can't also own scene
<anpok> this is not a solution (explicit ownership) - just another problem :)
<alan_g> But registrar could have a pointer to scene - as scene is guaranteed to outlive it
<anpok> pointer?
<alan_g> "SomeType*"
<alan_g> registrar-scene(this)
<alan_g> registrar->scene(this)
<alan_g> Or just passing this to the function(s) that need it
<alan_g> *"this"
<anpok> then scene needs to know registrar - which it shouldnt since it is only an impementation detail introduced for droidinput inputdispatcher
<anpok> yes, before the scene observer we had that reference to registrar inside the scene
<alan_g> "the interface of scene requires a shared ptr to register"
<anpok> to register an observer
<anpok> not to the registrar (tm)
<alan_g> Oh I misunderstood
<duflu> Anyone else notice gdb crashes a lot now
<duflu> It's really annoying
<duflu> (?)
<duflu> I just trying gdb gdb and it just shows a stack overflow (and no symbols)
<alan_g> So there's the problem: registrar shouldn't implement Observer
<alan_g> duflu: no
<anpok> duflu: no gdb worked great recently
<alan_g> It should "own" scene and register a distinct observer type
<duflu> Hmm, RAOF was reporting the same problems...
<anpok> havent updated... like at least for a week or so
<anpok> alan_g: ok that would solve it
<anpok> (just have to check who owns registrar)
<alan_g> It also keeps to the single responsibility principle
<anpok> hm ok the enumerator
<anpok> which is then owned by the droidinput InputDispatcher
<anpok> which is then owned by the mia::AndroidInputDispatcher..
<duflu> Oh, it seems to be program-specific:
<duflu>  mir_unit_tests --gtest_filter="FatalTest.*"
<duflu> Gah
<anpok> and then we are at DIsplayServer
<anpok> ok
<duflu> I mean:
<duflu> Reading symbols from bin/mir_unit_tests...Segmentation fault (core dumped)
<anpok> bbiab
 * alan_g wonders if we could generate an "ownership" DAG for Mir
<anpok> duflu: too many symbols - running out or memory? or broken memory?
<anpok> alan_g: we could trace constructor calls in CachedPtr
<anpok> with the symbol name underneath
<anpok> or maybe it can be extracted from the symbol name of the functor somehow
<duflu> alan_g: I've always thought DAG enforcement should be part of a super-shared_ptr
<duflu> mir::sp::FTW
 * alan_g was thinking build time, not runtime. And adding to the generated docs
<anpok> libclang \o/ - now i am gone
<greyback> Crazy idea, but is there a way to run mir in such a way that it doesn't connect to the hardware or composite anything, but clients could connect to it and make surface and stuff?
<greyback> would be handy for testing IMO
<anpok> greyback: there should be an offscreen option
<alan_g> greyback: it isn't crazy - it is handy for testing
<anpok> you could also disable input then the hosting server would not open any devices.. but it would also disable the dispatch of input hmm
<anpok> what was the intention of the --enable-input option?
<anpok> to not open input devices, or to not deal with input events of any source ...
<greyback> anpok: alan_g: offscreen option on my desktop still tries to twiddle the VTs
<greyback> mir_demo_server_shell --offscreen  =>  std::exception::what: Failed to find the current VT
<alan_g> alf_: you're responsible for the offsceen option aren't you? ^^
<alf_> greyback: alan_g: the offscreen support is rough still (proof of concept mostly, we were waiting from feedback from interested parties that never came)
 * alan_g thinks we have a new "interested party"
<anpok> and feedback
<greyback> alf_: yeah, I'd like to have that ability for proper integration testing of unity-mir with mir
<greyback> so in a test env, I can launch & stop apps
<greyback> not a major request mind, but would be nice to have
<alf_> greyback: ok, so what can we assume about the test environment in terms of display support (e.g. drivers with Mesa/GBM)?
<alf_> greyback: also do you want to be able to get visual output e.g. through screencasting?
<greyback> alf_: I guess my initial thought was a null display driver, so nothing gets drawn anywhere
<anpok> greyback: and do you want it to open input devices / not open any devices but allow the dispatch of synthetic input events?
<greyback> anpok: the latter option would be preferred
<alf_> greyback: perhaps offscreen is not what you are looking for, but an even leaner dumb server (like the ones we use in the mir integration/acceptance tests)?
<anpok> there is an option --enable-input that does the former, we could add one for the latter..
<greyback> alf_: ah, what dumb server is this?
<anpok> or what alf says - that one does what you want wrt to input testing
<alf_> greyback: it's not an executable, it's a server configuration with the major components stubbed which we used to instantiate our various test server instances
<alf_> greyback: tests/mir_test_framework/stubbed_server_configuration.cpp
<greyback> alf_: sounds handy. Let me play with it. If I find it useful, I might request a package containing it so unity-mir's integration/acceptance tests can use it
<greyback> alf_: anpok: thanks guys!
<alf_> greyback: yw
<anpok> greyback: or look at InputTestingServerConfiguration i believe it is the same plus a fake event hub plus the common input dispatching stuff
<greyback> anpok: ah nice, thanks
<racarr__> kdub_: Hey I replied to your comments on cursor-spike btw...fixed the style one...I think shared_ptr really is appropriate though
<racarr__> because the idea is, surfaces will share ownership of the loaded cursor images
<racarr__> so, if no one is interested in the magnifying glass image it goes away and on the other hand everyone has the same instance of the default image
<racarr__> of course the loader can also implement caching by keeping its own strong references
<kdub_> racarr__, I guess my thought was though that its strange that an observer gets ownership
<kdub_> like, having the surface have ownership makes sense to me
<racarr__> oh...for the observer! Aha maybe I misread your comment sorry...
<kdub_> right
<racarr__> Hmm.
<racarr__> ok I think you are right
<racarr__> will fix it up
<racarr__> sometimes...im not sure what to do in these situations
<racarr__> because just using shared_ptr EVERYWHERE can get costly
<racarr__> but whenever I use a reference to something managed by a shared_ptr elsewhere
<racarr__> I feel like I am laying a trap lol
<racarr__> ok brb lunch
<racarr__> ...I cant believe its 92 degrees
<kdub_> racarr__, yeah, hot down here too, 100 tomorrow
<bschaefer> racarr__, its 82 here :(, i want rain
<racarr__> Yesterday it kind of made me like woozy and tired
<racarr__> but today ive been drinking iced coffee all day
<racarr__> and really like it
<bschaefer> iced coffee....must ... get some now....
<racarr__> the error message when you only pass 8 arguments to a mock that expects 9 can be quite
<racarr__> fabulous
<racarr__> I dont understand what ipc factory is for
<racarr__> in order to add a new argument to session mediator constructor
<racarr__> you have to change literally over 10 call sites/declarations
<kgunn> anyone...i think i'm an over-user of clean (lots of scar tissue from symbian days...using reallyclean), whats kind of your rule of thumb do you make clean ?
<racarr__> basically never
<racarr__> I recenetly cleaned over 40 gigs of mir build dirs all at once though
<racarr__> :p
<racarr__> the only time I make clean is with qmake because...I have had several issues with it lol
<racarr__> kdub_: Ok passing references in cursor phase 3 now
<kdub_> racarr__, ack
<racarr__> phase 4 incoming!
<racarr__> lol
<kdub_> yknow, i should start naming my branches 'phases'
<kdub_> one less thing to name :)
<racarr__> kdub_: http://xkcd.com/1296/
<racarr__> MY HANDS ARE TYPING WORDS
<kdub_> racarr__, lol, yeah
<racarr__> kgunn: So if we were to wait on cursor API for 0.2 there is no point in waiting past phase 4 because at that point
<racarr__> clients could use it etc
<racarr__> still no themed image loaders, but they can request the images, disable the cursor, etc...it can be tested and once we add the image loader will all just work
<racarr__> again im really not sure its worth waiting though if we release again in a week or something
<racarr__> I dont think we really profit much from trying to get certain things
<racarr__> in certain releases
<racarr__> and it might be better to just have consistent fast releases
<rsalveti> kdub_: interesting bug for you: bug 1319582
<ubot5> bug 1319582 in android (Ubuntu) "'Failed to start RenderThread' after opening/closing applications" [Undecided,New] https://launchpad.net/bugs/1319582
<rsalveti> kdub_: basically, eglDestroySurface never gets called when starting/closing apps with ubuntu touch
<rsalveti> and as a side effect, the window surface never gets released when running it on the emulator
<rsalveti> as it allocates a host side gl window surface, and waits that call to happen for it to release it
<rsalveti> kdub_: we're not calling eglDestroySurface because the app is just normally killed, without any special clean-up
<kdub_> rsalveti, hmm
<rsalveti> any idea on how this could be solved on the client side?
<kdub_> make sure to clean up resources? :)
<rsalveti> right, but which component should take care of that?
<rsalveti> the system-compositor?
<kdub_> which egl context is the one that's leaking?
<rsalveti> when you open an app, it creates a surface and a color buffer
<rsalveti> the color buffer is released just fine, but the surface never gets released
<kdub_> I guess I don't know the brew of components in play well enough to reason to a solution...
<rsalveti> tvoss: maybe you have an idea ^
<kdub_> the emulator is running a mir instance, like usc+unity8, right?
<rsalveti> kdub_: yeah, exactly as we have on a nexus device
<rsalveti> but the egl/gles driver is a translator that uses your host gl
<kdub_> and there's probably some sort of pass-through driver
<kdub_> right
<kdub_> but the translator is an android window surface, right?
<rsalveti> https://code-review.phablet.ubuntu.com/gitweb?p=CyanogenMod/android_sdk.git;a=blob;f=emulator/opengl/DESIGN;hb=refs/heads/phablet-trusty
<rsalveti> right, when you ask for a surface, it sends the message to your host, via qemu pipe, that then creates the surface
<rsalveti> but for the client this is just a normal android surface
<racarr__> OHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH
<racarr__> RAOF: Email incoming in 1 minute lol
<RAOF> Wooot!
<racarr__> RAOF: ok 0001-input.patch is a completely untested integration of it in to vladimir
<racarr__> I mean not even compiled or really looked at lol, but who knows
<racarr__> and then xmir-deb
<racarr__> is the working xmir directory from my
<racarr__> ubuntu xserver patched to work with it
<racarr__> um.
<racarr__> I did have to delete my input drivers to test it
<RAOF> Bitchn'
<racarr__> als o make sure to replace your xinput driver before rebooting, it can be really disorienting
#ubuntu-mir 2014-05-15
<RAOF> :)
<bschaefer> racarr__, hey, are you still around? Weird problem im seeing with mir(sdl)/finger events
<bschaefer> racarr__, i get the first finger down, the motion events, but when i left my finger up, not finger up action?
<RAOF> Odd.
<bschaefer> yeah, i think ill have to dig into mir/android input stack... not sure where its going missing from
<bschaefer> android doesn't handle mouse up/down very well either (up is just an empty event with no state)
<bschaefer> ish
<bschaefer> RAOF, im assuming the finger events are working just fine on unity8, so im assuming im handling things incorrectly in SDL
<duflu> Speaking of which, I discovered last night that Android-input converts two-finger drags on my ThinkPad to what appears to be 3-finger events. Weird.
<bschaefer> very strange
<bschaefer> the fun part, if i do a second finger down, i get a finger up event
<duflu> Either that or there's a tool type demo-shell is supporting by accident :)
<RAOF> duflu: Yeah, the android input stack does _weird_ things to touchpads.
<duflu> RAOF: Also "click" is not button 1 :)
<RAOF> bschaefer: Huh. My input acceptance tests don't check for any finger-up events. I should probably add that.
<RAOF> duflu: It should be if you have exactly one finger down?
<RAOF> duflu: At least, it was for me.
<bschaefer> RAOF, well im assuming they are working, as with unity8 you can press icons :)
<duflu> RAOF: Yeah it varies significantly between laptops :S
<duflu> RAOF: Oh my memory failed me... it's different: https://bugs.launchpad.net/mir/+bug/1194057
<ubot5> Ubuntu bug 1194057 in Mir "mir_motion_action_move not received for thinkpad buttons (only for the clickpad)" [Low,Triaged]
<racarr__> bschaefer: Are you looking in to silvns issue?
<racarr__> I was looking in to his touchscreen issue and now he
<bschaefer> racarr__, no my own now :(
<racarr__> is on a similar issue
<racarr__> oh
<bschaefer> yeah
<racarr__> he has the same issue
<bschaefer> he poked me about it, but i swear he had up/down fine
<bschaefer> with 1 finger
<bschaefer> racarr__, also demo finger paint doesn't seem to want to work
<bschaefer> o also... im using an N7
<bschaefer> killing unity8, and using the mir server on its own (not sure what "unsupported" with the N7)
<duflu> bschaefer: https://bugs.launchpad.net/mir/+bug/1239501
<ubot5> Ubuntu bug 1239501 in Mir "Nexus 7 does not respond to touch" [High,Expired]
<bschaefer> well
<bschaefer> that could explain a few things
 * bschaefer needs to get a supported touch N<number>
<duflu> bschaefer: Reopen?
<bschaefer> duflu, well the N7 is an unsupported device
<bschaefer> duflu, but yeah i can reproduce these issues
<bschaefer> 3 finger touch isn't moving windows
<duflu> bschaefer: Sure, but Mir is open source. All real bugs are valid just lower priority if not official :)
<bschaefer> duflu, let me double check by getting trunk dev mir
<bschaefer> duflu, as im using whats in main 14.04? or 14.10
<duflu> bschaefer: Your Ubuntu release presently won't matter if you're compiling Mir from source
<duflu> Let's see how long that lasts... hopefully a while
<bschaefer> duflu, right, but i was using main mir-demos for my testing
<bschaefer> so i wanted to double check it was still happening on trunk mir
<duflu> bschaefer: trusty is only one point release behind utopic: https://launchpad.net/ubuntu/+source/mir
<bschaefer> yeah im on trusty: 0.1.8+14.04.20140411-0ubuntu1
<bschaefer> for libmirclient7
<bschaefer> duflu, that bug was closed a bit ago :), soo yeah
<duflu> bschaefer: Not closed. Only expired because it stopped happening for no apparent reason :)
<bschaefer> duflu, yeah, i mean it stopped happing for no apparent reason a bit ago, and i would have had that fix
<bschaefer> using mir-demos, soo mir trunk wont do much :(
<duflu> bschaefer: There was no fix. The bug came and went even before it expired
<duflu> So I guess it's come again
<bschaefer> duflu, hmm i wonder if its because everyone stopped using the N7?
<bschaefer> yeah
<bschaefer> duflu, o and thanks for the bug link :), i should have attempted to check bugs
<duflu> RAOF: Oh the two-finger window Alt+dragging on my touchpad looks like it might be an accidental feature. And one I might make use of :)
<RAOF> Grr. You can't actually change an interface at all and preserve ABI, can you?
<RAOF> Oh, well. EOD.
<duflu> alf_: I'm off to make dinner then back later. In the mean time, consider this problem: https://bugs.launchpad.net/mir/+bug/1317370/comments/9
<ubot5> Ubuntu bug 1317370 in Mir "[regression] [BufferQueue] BufferQueueTest.compositor_never_owns_client_buffers is very slow (up to 30 seconds) on fast machines" [High,Triaged]
<duflu> It's an interesting case. I hope I missed something.
<alan_g> dednick: AIUI a helper can only have one active trust session the session mediator? So why does it need a client side handle to a trust session? Isn't the connection a sufficient identifier?
<dednick> alan_g: when i originally wrote it, there wasn't actually that limitation, and the handle hung about. I'm not exactly sure if we want that limitation either, at the moment.
<dednick> alan_g: but anyway, i think it adds a bit of separation of "ideas".
<dednick> alan_g: i mean that i'm not sure we want the one-to-one limitation in the long run.
<alan_g> dednick: Ack
<alan_g> tvoss: opinion? ^^
<tvoss> alan_g, dednick we want one helper to be able to handle multiple trust sessions
<tvoss> for example: multiple content picking operations
<dednick> tvoss: at the same time?
<tvoss> dednick, yup, they are stateful
<dednick> tvoss: ok. phase 2?
<alan_g> tvoss: from the same connection? Or can it use a connection for each?
<tvoss> dednick, yup
<tvoss> alan_g, connection as in ordinary Mir connection?
<alan_g> tvoss: Yes. But I'm starting to wonder if it is a new type of connection and not the same thing we have to manage surfaces.
<tvoss> alan_g, that's why we introduce trusted sessions as I understand it
<alan_g> tvoss: but the proposed API implies it is owned by a connection (in the same way that surfaces are). Not that it is a different type of connection.
<tvoss> alan_g, why would it need to be owned by something different than a connection?
<alan_g> tvoss: currently we have one type of connection. It manages surfaces. The proposed API says it manages surfaces and an optional trust session. Why can't we have one connection type for surfaces and one connection type for a trust session?
<tvoss> alan_g, why would adding another type of child (surfaces and trust sessions) require a new type of parent?
<tvoss> alan_g, also: a trust helper might want to have surfaces as well
<tvoss> alan_g, which have to be added to trust sessions
<alan_g> What is the relationship between any surfaces and any trust session(s)?
<alan_g> but trust sessions don't know about surfaces - only processes
<tvoss> well, they should know about surfaces ultimately
<tvoss> alan_g, a surface belongs to a connection but can be referenced by a trust session
<alan_g> Should a trust helper surface be associated with a specific trust session or all (or some)?
<tvoss> alan_g, at most by one
<alan_g> tvoss: at one time or over the duration of the connection?
<dednick> alan_g: this is all "ultimately". not for this iteration.
<dednick> just to remind :)
<alan_g> dednick: I know - but I'd like the conceptual model to be right before we publish APIs
<tvoss> alan_g, at any point in time, a surface can be referenced by at most one trust session
<alan_g> But it can be removed from one and added to a different one?
<tvoss> alan_g, yup, that's certainly possible
<dednick> alan_g: can you take a look at: https://code.launchpad.net/~nick-dedekind/mir/test_new_fds_for_trusted_clients when you get a chance?
<dednick> Was taking a look at the problem with child sessions not stopping. The test creates a server and client. the client creates some fds, which another client connects with.
<dednick> The child that connected to the fd is crashing when shutting down, and the server is not getting a disconnect for it.
<dednick> stack for the client crash: http://pastebin.ubuntu.com/7467385/
<alan_g> dednick: ack. Was taking a first look at ~nick-dedekind/mir/trusted_sessions/+merge/218975 before getting into the issue you mentioned yesterday
<dednick> alan_g: ok. thanks
<dednick> i'm taking a guess, but i think the server may be closing the fd's which were opened by the parent client.
<dednick> when the parent client connection is released
<alan_g> dednick: Hmm. The server closes FDs once it has sent them (but they're open in the other process). I don't think it tracks them after that.
<dednick> alan_g: sent them? over to the parent client over ipc?
<alan_g> ack
<dednick> alan_g: hm. but they won't be open in the other process by then.
<alan_g> dednick: Oh yes they are. (The FDs not the connections)
<alan_g> we've been doing it for years.
<dednick> alan_g: i think i'm getting confused. but we only start the child client process after we've got the response from the server for the new_fds_for_trusted_clients.
<alan_g> Yes, but you already have the FD in your process.
 * alan_g has to go make lunch - BIAB
<dandrader> when a surface is resized ( mir::scene:surface::resize() ) should the client recreate his eglSurface or do anything at all?
<alf_> dandrader: no, unless you need to draw differently somehow (otherwise everything will just be scaled)
<dandrader> alf_, ok
<alf_> dandrader: scaled => assuming you are drawing using relative sizes (e.g. using the -1,1 coordinate system of GL)
<alan_g> dednick: @https://code.launchpad.net/~nick-dedekind/mir/test_new_fds_for_trusted_clients - I don't understand what's going on with SharedRegion. Are you using shared memory to copy the FD ids from one process to another without migrating the FDs themselves?
<dednick> alan_g: ah crap. forgot that the other clients need to be created by the parent client in order to get the FDs
<dednick> i mean the processes need to be spawed from the parent client.
<alan_g> That's certainly the easiest way.
<alan_g> Should I stop looking?
<dednick> the shared mem was just to get the fds across process. but being used incorrectly.
<alan_g> I mean is the problem you mentioned yesterday likely the same thing?
<dednick> alan_g: hm. the problem yesterday was with the child processes being created by the helper, so probably not...
<alan_g> OK. I'll start by writing a test for what should be happening.
<dednick> alan_g: thanks. easier than me stabbing in the dark about what's supposed to happen :) I don't know much about fds apparently
<alan_g> np
<dandrader> alf_, is there a significant overhead in resizing a surface?
<alf_> dandrader: we need to allocate new graphics buffers, so yes in a sense, but it all depends on your particular scenario
<dandrader> alf_, flipping the dimensions. e.g. from 768x1280 to 1280x768
<alf_> dandrader: it depends on the device and your requirements whether its ok, so I guess you need to try it out and see if it's acceptable
<alf_> dandrader: do you have alternatives to flipping the dimensions (flipping rendering instead?)
<dandrader> alf_, yes I do
<dandrader> alf_, so overall you think it's better to flip rendering than to flip the dimentions (surface resize)?
<alf_> dandrader: flipping rendering should be near cost free for the GPU (just a different transformation matrix)
<greyback> alf_: so right now there's no support for properly resizing a Qt app in Mir (and platform-api & qtubuntu)?
<alf_> greyback: mir supports resizes
<greyback> alf_: ok, so the qtubuntu just needs to support it
<greyback> which is probably doesn't right now
<alf_> greyback: (you can play with resizes using mir_demo_server_shell)
<greyback> mterry: ping
<mterry> greyback, heyo
<greyback> mterry: hey, can you explain me how unity-system-compostor starts. Lightdm starts it right? Is there a configuration applied (i.e. env vars set for USC)
<mterry> greyback, it is started by lightdm.  With some env vars it sets yeah.  And also, the configuration can change the command line used (and in fact ubuntu-touch-session does install a usc-wrapper file that sets a little more env for touch stuff)
<greyback> mterry: are any of those env vars critical for USC to start by any chance?
<mterry> greyback, probs?  What's the problem?
<greyback> mterry: http://pastebin.ubuntu.com/7468671/
<greyback> note it's with a custom build of mir
<mterry> greyback, oh yeah, you can't really start manually
<mterry> greyback, lightdm passes it a couple fd's for communicating with it
<greyback> aha
<mterry> greyback, specified on command line
<greyback> mterry: so "start lightdm" is the right way to start it?
<mterry> greyback, yeah
<mterry> greyback, lightdm loves its private fds
<greyback> how friendly
<greyback> mterry: so I get: http://pastebin.ubuntu.com/7468684/ <- I'm missing the "ubuntu" session somehow. Where should that file be?
<mterry> greyback, hm, what env are you running in?  I think you're missing ubuntu-session (or ubuntu-touch-session)
<greyback> mterry: on the phone. Some packages might have been removed (major surgery and all)
<mterry> greyback, yeah install ubuntu-touch-session
<mterry> greyback, it will change the default session to "ubuntu-touch" and install the .desktop file for it
<greyback> ack
<greyback> mterry: there we go, that fixed it, thanks
<mterry> nice
<greyback> slightly worrying how easily that broke...
<mterry> greyback, well stop removing packages!  :)
<greyback> :P
<kdub_> any more reviewers on https://code.launchpad.net/~kdub/mir/post-if-optimizable/+merge/217991
<racarr__> This is where all the fun is
<racarr__> kdub_: Ill review!
<racarr__> just saw backlog lol
<racarr__> p.s. looking for reviewers on cursor-spike-phase-3
<racarr__> ok I swear I have seen so many diffs that are exactly 1334 line
<racarr__> s
<racarr__> it seems to be a common stopping point
<racarr__> anpok: BECAUSE ON FREENODE THE PEOPLE MAY FINALLY CONTROL THE MEANS OF PRODUCTION
<racarr__> *waves flags*
<anpok> :)
<racarr__> https://code.launchpad.net/~mir-team/mir/cursor-spike-bonus-phase-correct-gbm-cursor-hide/+merge/219764
<racarr__> easy review
<racarr__> with no dependencies :)
<RAOF> racarr__: I hope there's going to be a cursor-spike-lightning-round at some point.
<racarr__> RAOF: Lol
<racarr__> ill use that for the cleanup branch at the end
#ubuntu-mir 2014-05-16
<duflu> bschaefer: Your SDL 2.0 work, that's not in archive is it?
<bschaefer> duflu, the one in archive will work for the desktop
<bschaefer> you'll need the one in mir staging for the phone
<duflu> bschaefer: Oh, trusty or just utopic?
<bschaefer> there was an issue with arm i need to get patch in archive :(
<bschaefer> duflu, utopic
<bschaefer> i dont think the trusty one built
<duflu> bschaefer: Ah. No wonder it wasn't linked to Mir :)
<bschaefer> o looks like it did
<bschaefer> duflu, it has a nice dynamic linking, so no hard depends :)
<bschaefer> but i suppose you need so to compile
<duflu> bschaefer: That's the right answer. Although it's so rare these days I always don't expect it :)
 * bschaefer wrote the debain file and has forgotten
<bschaefer> duflu, :)
<duflu> *almost
<bschaefer> duflu, i didn't know about until Rayn, one of the devs mentioned it
<bschaefer> and did that work
<bschaefer> it was pretty cool
<duflu> bschaefer: How's the input support?
<duflu> Pretty much complete (as much as Mir allows you to)?
 * RAOF hides
<bschaefer> duflu, yeah
<bschaefer> duflu, and yeah i need to re-confirm that bug
<bschaefer> duflu, o thanks for re-opening it :)
<bschaefer> also turns out mir does shaped windows server side, but allows for rect region windows
<bschaefer> sooo i need to implement that as well
<duflu> bschaefer: I've just started modifying that stuff. But if you mean windows with an alpha channel, yet that works now: mir_demo_client_egltriangle -b 0
<duflu> -yet +yeah
<bschaefer> sweet! I don't know much about shape windows them selfs
<bschaefer> just saw it in SDL and know i've to support it
<bschaefer> i think its using alpha channels
<bschaefer> as it takes a bitmap
<bschaefer> (for its example)
<duflu> bschaefer: It *just works* (tm)
<bschaefer> :)
<bschaefer> it looks cool on x11, so it would be nice to support it haha
<duflu> Although demo-shell is naive and will put a rectangular shadow around your shaped app :P
<bschaefer> thats good to know
<bschaefer> vs freaking out
<duflu> RAOF: Oh, no more inline comments check box in reviews
<RAOF> To the EOW!
<slvn_> Hello, I have an issue with MIR + a touch-screen
<slvn_> I run the app both on x86 (Desktop) and ARM (tablet)
<slvn_> In some condition I dont get the TouchEvent "UP" from my 2nd finger
<slvn_> The test-case is :  Put Finger-1 Down, F2-Down,  F2-Up, F1-Up   => it looks like Mir sends only one Up
<slvn_> I have already talk about this with some mir-developer .. (I think they are sleeping now)
<slvn_> Has anyone  an idea to debug this ?
<slvn_> (I know how to compile lp:mir, I have already put some debug trace on, and inside code ...)
<anpok> slvn_: that might be speculation, maybe you get the up events in a single event?
<anpok> slvn_: what is the result of  mir_event.motion.action & 0xff00 when you only get a single up event?
<slvn_> anpok, how could I check that ? here's some part of the *application* code -> https://hg.libsdl.org/SDL/file/3e2b3019a879/src/video/mir/SDL_mirevents.c
<anpok> alan_g: seems like my mp failed because of timing issues in the asio alarm test fixture \o/
<slvn_> anpok, I will check
<anpok> slvn_: we borrowed some ugliness from the android input stack
<anpok> and that is up and down events for pointers/finger may be encoded in a single event, and the state change is stored in the action value
<slvn_> anpok, yep I understand, I check that :)
<anpok> seems like line 167 in the file need to handle that
<anpok> k
<anpok> asio does not allow replacing the timer scheduler during runtime or as an io_service configuration.. so one way to eliminate real timing could be to not use asios deadline_timer but write a timer service that behaves exactly like it, but uses an abstract scheduler interface.
<alan_g> hmm
<anpok> somehow..
<slvn_> anpok,  ... before starting the whole compilation stuff. A question : mir_event.motion.action is defined in : /usr/include/mircommon/mir_toolkit/event.h,  and it goes from 0 to 10.  so the mir_event.motion.action & 0xff00 does not make sense ?
<anpok> well i would like agree to that..
<slvn_> if ( mir_event.motion.action & 0xff00 ) == 0, that would be a mir_motion_action_down << 8
<slvn_> but il will check
<anpok> slvn_: hm ok I was wrong you have to get two up events
<anpok> slvn_: the android input stack stores the index of the pointer that goes up /down in that part of the action variable
<anpok> I believe to stay somewhat compatible that part was kept..
<anpok> slvn_: so i guess you run in the default case when you get the second up event
<anpok> for the first up event you will get (pointer index 0 << 0xff) | mir_motion_action_up as action
<anpok> and for the second up event you will get (1 <<0xff)| mir_motion_action_up
<anpok> but it depends on the order of finger releasing
<anpok> so yeah what you observe makes sense given the mir event handling code
<slvn_>  I enter the default case with action =  0x105 and 0x106
<slvn_> anpok, yep, the order of finger releasing has also a very strange impact !
<anpok> because the value stored is not the finger id but the index in the attached pointer_coordinates array
<slvn_> 105 / 106 is   mir_motion_action_up           = 1,     mir_motion_action_pointer_down = 5,   mir_motion_action_pointer_up   = 6,
<slvn_> anpok, so basically : I should do switch ( action & 0xff)          to strip the finger id ?
<anpok> not the finger id but the pointer_coordinates index..
<anpok> and you have to read the pointer coordinate index to pass the right id to the HandleTouchPress function..
<anpok> i believe the other not mentioned index can be treated as a touch motion
<anpok> alan_g: we would need something similar to that - written against a mockable interface: http://www.boost.org/doc/libs/1_55_0/boost/asio/deadline_timer.hpp
<anpok> :)
<anpok> wrong file
<anpok> that one http://www.boost.org/doc/libs/1_55_0/boost/asio/detail/deadline_timer_service.hpp
<alan_g> anpok: I've not yet had time to look at your MP or why it failed. So I'm lacking context to make meaningful comment.
<anpok> ok the AsioMainLoopAlarmTest.main_loop_runs_unti_stop_called does wait for 10 ms for the ml thread to start and to execute a 0 ms timeout
<alan_g> tests that rely on sleep/wait are broken
<slvn_> anpok, line 228 and 231 : I could replace the "cord_index" by :   (motion.action >> 8)
<anpok> yes - but you only get meaning full values if you are handling action&0ff = mir_motion_action_pointer_{up,down}
<greyback> alf_: hey, question on the MultiThreadedCompositor: how does it manage to switch between using the DisplayBufferCompositingFunctor and the BufferConsumingFunctor during runtime?
<greyback> I don't see where the decision to use one over the other occurs
<alf_> greyback: They both run in parallel, but you shouldn't concern yourself with that, it will soon be removed and the task of consuming frames will be done at a lower level
<slvn_> anpok : yes, I also changed switch (motion.action & 0xff) line  169, and 193
<slvn_> anpok:  now it's much better for Up/Down event
<greyback> alf_: okay. Different hypothetical question: say I wrote a naughty server using Mir, which uses its own compositing loop instead of Mir's. While running as a nested server, when the display is blanked, and it tries to render, a exception is thrown inside Mir: "error during hwc prepare(). rc = ffffffff"
<anpok> sounds very hypothetical
<greyback> :)
<greyback> alf_: aside from telling to not be naughty (am working on it), what avenue would you suspect?
<alf_> greyback: hmm, strange, the nested server shouldn't touch the screen at all... Plus, for the host server, when the screen is blanked we normally don't even a expose a display buffer for that screen.
<alf_> greyback: is the exception thrown from the host mir or from your qt-compositor nested mir?
<slvn_> anpok, something is still weird, I still need a little help.  This is only 1 "motion.action" but a table of pointer_coordinates[pointer_count]
<greyback> Why I'm surprised is that it's running as nested server, so I expected it to be free to render as much as it wantede while the display was blanked, as the system server would consume those buffers
<greyback> alf_: good question, lemme see
<anpok> slvn_: i believe the other pointers do not change up/down state but are just provided because they might contain moves moves - but not really sure
<anpok> -moves
<anpok> I have to dig more into InputDispatcher to see when that happens
<slvn_> anpok. I think (not checked) there are different "motion.pointer_coordinates[cord_index].id". So If I choose cord_index==action>>8. I fix the .id
<slvn_> and then, I get only motion event from 1 finger
<slvn_> if I only do : "switch (motion.action & 0xff) {" and discard the 0xff00, all work fine
<slvn_> basically, If it would have been "motion.action & 0xff" from scratch in SDL code, I would have not noticed the bug
<alf_> duflu: Are you working on the cleanup on sigabort etc? If not, I can pick it up.
<alf_> duflu: alan_g: I am thinking of adding a mg::Platform::emergency_cleanup() method to do a best effort cleanup in fatal signal situations
<alan_g> alf_: reasonable. The alternative design is a registration facility (like atexit()).
<alf_> alan_g: Like, e.g., EmergencyCleanupRegistrar::register_cleanup(...) mg::create_platform(...,std::shared_ptr<EmergencyCleanupRegistrar> const& r) ?
<slvn_> anpok:  if (action & 0xff == cord_index) then real_action=action&0xff else real_action = motion
<alan_g> Or EmergencyCleanupRegistrar const& r
<alf_> alan_g: it depends on whether a platform needs to do clean-up for created display though... unless we also add this to Platform::create_display()
<alan_g> Hmm. It is also possible to install signal handlers in the "platform"
<slvn_> anpok : this patch is working perfectly ! http://pastebin.com/PB7FTvkk
<slvn_> anpok this is what you said first I think!
<alan_g> alf_: I don't see why it depends. The are equivalent with: r.register([this]{ emegency_cleanup(); });
<anpok> slvn_: ah that function is called for every pointer?
<anpok> then yes looks good!
<slvn_> anpok with the pointer_cound, but only one action for all !
<slvn_> I cannot use the same action for all, because otherwise I have weird up/down event that appears
<slvn_> F1 Down F2 Down F1 Up F2 Up ->  down down up up Up Down
<alf_> alan_g: I meant the comment for using a shared_ptr vs a reference to pass the registrar
<slvn_> ok ... I send this patch to bschaefer and also racarr__ because there were implicated
<slvn_> thanks anpok for the help !
<alan_g> alf_: I got that. Your original mg::Platform::emergency_cleanup() code didn't need it. And neither does  r.register([this]{ emegency_cleanup(); });
<slvn_> anpok, anyway, is there a way to see why the cord_index is encoded into the "action" and also, when there are several pointer count, why by default this should be a motion action
<alf_> alan_g: Sure, but neither handle the case where the individual displays need cleanup, *without* the platform having a mediating role in that. Anyway, at least for mesa there isn't such a need anyway.
<alf_> bbiab
<alan_g> alf_: OK. I don't (currently) see a strong reason for preferring any of the three approaches.
<alan_g> Well four if you consider rev vs sp different
<alan_g> *ref
<slvn_> anpok : curiously : fingerpaint.c has :  MirMotionAction masked_action = event->motion.action & ~0xff00;     // FIXME: https://bugs.launchpad.net/mir/+bug/1197108
<ubot5> Ubuntu bug 1197108 in Mir "Input action fields no longer maintain compatibility with surfaceflinger" [Medium,Fix released]
<anpok> slvn_: the encoding happens in InputReader of the android input code (TouchMapper is the class)
<duflu> alf_: Oops, sorry. No not working on it at all (https://bugs.launchpad.net/bugs/1320114)
<ubot5> Ubuntu bug 1320114 in Mir "[DRM/GBM] Crashing Mir (via fatal signal) often leaves the screen blank and difficult to recover" [Medium,Triaged]
<slvn_> anpok, the patch is not working. It works better, but sometime I miss a UP event  (miss== I dont detect?)
<anpok> slvn_: oh sorry did not look at the patch properly
<anpok> slvn_: http://pastebin.com/fy97wgEJ
<slvn_> anpok,  okay.... I found some stuff !  MIR is sending me : action=0x101  but only pointer_counter=1 !!!!
<slvn_> so I never do something with this event !
<slvn_> anpok, action=0x101 means the UP event should be applied to the cord_index=1, but the pointer_count==1 mean there is only 1 element in the table, only 1 cord_index (of value=0)
<slvn_> anpok, ... that's fully fix my issue now ! and it appears several time
<slvn_> if (motion.pointer_count == 1 && (motion.action >> 8) != 0)
<slvn_> motion.action &= 0xff;
<anpok> oh i assumed it only happens for pointer_up,down and not for all kinds of up and down events..
<slvn_> Everybody, does the MirMotionEvent struct makes sense to anyone  ?? MIR sends me sometimes with "motion.action=0x101" (cord_index=1 + action_up) and "pointer_counter=1"  => so the only cord_index available 0 ! Is this a Bug ?
<anpok> the code in
<anpok> wrong terminal
<anpok> slvn_: looks like a bug
<slvn_> anpok, ok, maybe I should double-check with latest version of MIR ?  (I am using lp:mir  Tree is up to date at revision 1186)
<seb128> hey there
<seb128> is Mir supposed to work on any intel hardware?
<seb128> it doesn't seem to run on the Dell mini 10v (that's an old atom based machine with an intel 950 video card)
<kdub_> seb128, I use a i965 for mir work
<seb128> I had EGL errors/assertions in the unity8-mir log
<seb128> need to boot again and share them
<seb128> I guess my current description lacks details
<racarr__> seb128: Ive heard rumors about i915 issues I think
<racarr__> the ollld ones
<racarr__> oh 950
<racarr__> who knows ;)
<seb128> racarr__, it might be i915 or 945, the 950 came from some googling, but didrocks pointed out that it was probably not right
<seb128> yeah, it's i195
<seb128> the error it gives is "ASSERT: "(eglContext_ = eglCreateContext( eglDisplay_, screen->eglConfig(), share ? share->eglContext() : EGL_NO_CONTEXT, attribus.constData())) != EGL_NO_CONTEXT" in file ../../../../src/platforms/base.context.cc, line 63
<seb128> (I hope I didn't do typos, I don't have an easy way to copy the log from the machine)
<seb128> that's in unity8-mir.log
<racarr__> seb128: Ok I think there is something
<racarr__> with i915, i.e. the mesa driver doesnt support the DRI2 apis or
<racarr__> *not entirely sure*
<racarr__> all I know for sure is that duflu knows
<seb128> ok
<seb128> "known issue" then ;-)
<seb128> let me know if I should report it
<xnox> what's the difference between libmir*-mesa & libmir*-android packages?
<racarr__> kgunn: ^ Do you remember? i915 intel mesa...doesn't work?
<racarr__> xnox: libmir-mesa uses MEsa EGL, GBM, kernel drm (direct rendering manager) modesetting, etc
<xnox> racarr__: why would i want that installed on ubuntu-touch?
<racarr__> libmir-android uses android graphics drivers, android EGL, gralloc, hardware composer
<racarr__> Id ont think you would lol
<kdub_> yeah, you wouldn't
<xnox> racarr__: lolz, we do at the moment =)
<xnox> no wonder ubuntu-touch image is 1.4 GB big with LLVM et al
<kdub_> unless you're ambitious and want the freedreno stuff? (uncharted waters)
<racarr__> xnox: Yeah...last I checked
<racarr__> I believe we end up pulling
<racarr__> significant parts of X +
<racarr__> both libegls, etc.
<racarr__> I think there are some eird dependencies in mesa
<racarr__> but ive never dug down
<kgunn> racarr__: right, as i recall from duflu, dri2  never added support for i915
<racarr__> kgunn: Ok. No bug needed from seb then :)
#ubuntu-mir 2015-05-11
<alan_g> alf_: what do you think of this now? https://code.launchpad.net/~mir-team/mir/unify-pointer-button/+merge/258322
<dholbach> hiya
<dholbach> can somebody reply to https://github.com/FreeRDP/Remmina/issues/554 (needed to fix bug 1444132)
<ubot5> bug 1444132 in remmina (Ubuntu) "Remmina crashes using the Mir GTK backend" [Undecided,In progress] https://launchpad.net/bugs/1444132
<alf_> alan_g: Still not convinced that having flags is a problem... we could even use an int64 if we feel 32 values are not enough
<davmor2> alan_g: latest landing of mir do I need to do anything special I'm trying to install it on krillin and I just get a black screen after the initial BQ loader page
<davmor2> alan_g: silo 21 frt
<alan_g> davmor2: is your krillin on vivid or rtm?
<davmor2> alan_g: vivid it's the only thing we are testing
<alan_g> Just checking
<alan_g> There's nothing special I needed for mako or manta. I know no reason for krillin to be different
<davmor2> alan_g: using ubuntu-touch/devel-proposed/krillin.en channel plus citrain device-upgrade 21 <pin code>  and installing the ppa manually as powerd in the overlay ppa were stopping package installs
<davmor2> alan_g: well all I'm getting is a black back lit screen,  do I need to install the unity8 silo with it or anything daft like that?
<alan_g> davmor2: nothing like that.
<alan_g> Mmm I used --channel ubuntu-touch/vivid
<davmor2> alan_g: that is age old and only image 2 iirc which was released about a month or so ago
<davmor2> alan_g: you would need to use at least ubuntu-touch/devel-proposed or vivid-proposed
<alan_g> davmor2: I'll have a look after lunch (which is calling). (And update the instructions I was given)
<davmor2> alan_g|lunch: thanks
<alan_g> davmor2: I can get a black back lit screen too. Investigating...
<davmor2> alan_g: yay I'm not going mad that's good to know.....okay who am I kidding going mad :D
<alan_g> davmor2: well I know what's happening (not installing updated unity-system-compositor or qtmir) but I've not figured out the why.
<davmor2> alan_g: I've rejected the initial silo ticket so once it's fixed if you trigger a rebuild we will get a new ticket and can retest
<alan_g> davmor2: thanks
<dholbach> not sure if folks saw my question earlier.....
<dholbach> can somebody reply to https://github.com/FreeRDP/Remmina/issues/554 (needed to fix bug 1444132)?
<ubot5> bug 1444132 in remmina (Ubuntu) "Remmina crashes using the Mir GTK backend" [Undecided,In progress] https://launchpad.net/bugs/1444132
<alan_g> davmor2: it isn't something I can fix as a rebuild: LP-PPA-ci-train-ppa-service-stable-phone-overlay is pinned at 1001, while the silo is 500. (Which means a silo won't ever override a package that's already in overlay!) I could workaround it by changing /etc/apt/preferences.d/extra-ppas.pref to 499 - after which everything seems fine. How do we handle this?
<davmor2> alan_g: leave it with me
<alan_g> davmor2: I've hit a problem anyway. Need to do some further testing.
<davmor2> alan_g: okay
<alan_g> But the pinning will remain a problem
<davmor2> alan_g: yeap we can keep an eye out for it now we know
<mterry> greyback__, I assume our Mir support for Qt does not extend to Qt4?
<greyback__> mterry: correct
<greyback__> will probably use xmir for those
<mterry> k
<mterry> figured  :-/
<greyback__> mterry: a particular app you're missing?
<mterry> greyback__, I'm looking at compiling RemoteDisplay, a qt4 rdp client thing
<mterry> greyback__, I may be able to just port it
<greyback> is worth a go
 * racarr almost done iterating branches up for review
<racarr> lol
<racarr> made the button states a mask again...
<racarr> + alfs suggestions on new-input-dispatcher have lead to some nice cleanups
<racarr> and some random other stuff...
<racarr> Weekly tonight proceeding as scheduled?
#ubuntu-mir 2015-05-12
<robert_ancell> RAOF, was / is there an XMir git branch (i.e. with the actual changes on git master and not with a debian/ dir like fdo:~mlankhorst/xserver
<robert_ancell> Trying to work out correct attribution for xmir.patch
<RAOF> robert_ancell: I presume Maarten has a branch somewhere, but I've only got https://github.com/raof/xserver
<RAOF> Which isn't the one that you're after.
<RAOF> robert_ancell: Some quick searching shows up http://cgit.freedesktop.org/~mlankhorst/xserver/
<robert_ancell> RAOF, that just has debian/ added and everything in the patch file
<RAOF> Yeah, dunno, sorry.
<robert_ancell> np
<RAOF> He presumably had a git tree to develop in, though.
<robert_ancell> Presumably
<duflu> robert_ancell: It's documented in the obvious place :)
<duflu> robert_ancell: https://code.launchpad.net/xmir
<duflu> But yeah we definitely need to move it
<robert_ancell> duflu, again, that's pointing at a branch containing debian/patches, i.e. not a branch based off master with the changes done inline
<robert_ancell> duflu, I am moving it now
<robert_ancell> And without the original branch we're going to lose attribution. But it's probably not a big deal.
<duflu> robert_ancell: I know it's ugly. I doubt Maarten did maintain anything inline. He was always patches
<robert_ancell> I'm going to split up the changes anyway so we can get them upstream at some point
<duflu> robert_ancell: I never did figure out how to build in manually too... Only got a successful build from debuild
<duflu> (strange compiler errors otherwise)
<duflu> Obviously the secret sauce is in debian/
 * duflu goes to get some sunlight
<duflu> Man touchscreen hardware really sucks. Even when you eliminate all the graphics lag, touchscreens are still slow. Plugging a mouse into the same device is dramatically more responsive.
<alan_g> alf_: have you had a chance to look at the power off/on/off/on/... crash?
<alf_> alan_g: yes, the crash happens in a GL call, I am trying to figure out why...
<alan_g> alf_: ack. I'll leave you to it. :)
 * alan_g goes to port glmark2-mir to contemporary API
<duflu> alan_g: You'll also want to wait till the client ABI bump before updating glmark2-mir in wily. Or else we'll have to do it twice
<alan_g> duflu: we need to decide how to work around https://code.launchpad.net/~alan-griffiths/mir/bump-client-ABI/+merge/258769/comments/646197
<alan_g> But at least I can get the code ready
<duflu> alan_g: Take it out of CI temporarily I guess. BTW that is https://bugs.launchpad.net/mir/+bug/1341490
<ubot5> Ubuntu bug 1341490 in Mir "Bumping the client ABI causes CI failures" [Medium,Triaged]
<alf_> alan_g: @glmark2, I already have an upstream branch for the update
<alan_g> alf_: ok, I'll drop mine then
<alf_> alan_g: but we will need to update the ubuntu packages
<duflu> alf_: Booo.... requires ES3 - https://www.khronos.org/opengles/sdk/docs/man3/html/glReadBuffer.xhtml
<duflu> Sigh
<duflu> And even then still not FRONT
<duflu> ES is surprisingly limited, again
 * alan_g does a clean build from trunk and gets "ClientSurfaceEvents.surface_receives_state_events...Segmentation fault (core dumped)"
 * alan_g realise he did something stupid
<alf_> alan_g: https://code.launchpad.net/~afrantzis/mir/fix-1454201-usc-crash-for-0.13/+merge/258863
<alan_g> alf_: thanks!
<alf_> alan_g: More investigation is needed to figure out why the workaround is needed (and if it's really our fault or the driver's), but this should be enough to unblock the release
<alan_g> understood
<alan_g> alf_: any ideas? https://code.launchpad.net/~afrantzis/mir/fix-1454201-usc-crash-for-0.13/+merge/258863/comments/646452
<alan_g> The test diagnostic is rather unhelpful. :(
<alf_> alan_g: I knew I was forgetting something (to check the tests!)
<alf_> alan_g: I will fix and update the branch
<alan_g> alf_: thanks. [Non-urgent: does the diagnostic need to be so far removed from the actual problem?]
<davmor2> alan_g: the issue you spotted yesterday in silo21 did you resolve it at all?
<alan_g> davmor2: we're (well alf_) closing on it. I expect to rebuild and test after lunch.
 * alan_g goes to lunch while alf_  does the work.
<davmor2> alan_g: that's great just remembered about it so thought I'd ask while it was in my head :)
<dandrader> I've mir_proving_server running on my laptop as root. Is it possible to run mir clients without being root?
<dandrader> I did "sudo chmod a+rwx mir_socket" but trying mir_demo_client_egltriangle without root still gives me "Can't get connection"
<dandrader> ok, manually pointing out the location of the mir_socket did the trick: "/tmp$ mir_demo_client_egltriangle -m mir_socket"
<dandrader> wonder why I don't have to do so when I run the client as root
<alan_g> dandrader: the socket location depends on some environment variables that are set differently
<dandrader> alan_g, where/how can I find a list of env vars that mir looks for?
<alan_g> mir_proving_server --help ... "Socket filename [string:default=$XDG_RUNTIME_DIR/mir_socket or  /tmp/mir_socket]"
<dandrader> alan_g, so this translates to having a MIR_SERVER_HOST_SOCKET in the environment of the client app?
<greyback_> dandrader: I usually set MIR_SOCKET=/tmp/mir_socket
<alan_g> If you run as root then $XDG_RUNTIME_DIR isn't set so server and client look at /tmp/mir_socket
<alan_g> If you run as non-root then it is usually set
<dandrader> alan_g, I got it from the help text. but what's the name of the env var I should use for the client?
<dandrader> alan_g, it says nothing aboutn the existence of the MIR_SOCKET env var
<dandrader> greyback_, thanks!
<racarr> So...autolanding is down I guess?
<greyback_> alan_g: fyi, qtmir had some landings. I'm working on fixing up qtmir/devel-mir-next to suit
<alan_g> greyback_: Oh. I'll need to roll that into silo 021
<greyback_> alan_g: yep, exactly why I'm doing it
<alan_g> Thanks. Is it a long job?
<greyback_> alan_g: nah, almost there, just 2 new tests I'm being careful with
<alan_g> Excellent (rebuild of mir will be finished shortly)
<greyback_> alan_g: in the CI Dashboard, your silo21 is for "vivid primary" - I didn't think we could land there any more
<greyback_> tho I see plenty of other silos with the same
<greyback_> my qtmir landing was in vivid+stable-overlay
<alan_g> I don't know why not. So long as we don't break ABI
<greyback_> things are unclear
<alan_g> They certainly are
<alan_g> I thought "overlay" was a temporary substitute until wily was usable. But it got hijacked
<racarr> Planning to rework the event representation today (mostly to line up to input_event.cpp/the C API)
<racarr> starting to realize there may  be some advantage to
<racarr> deunionizing the event...
<racarr> I was thinking about the playground shell and the big if statement for handling
<racarr> keybindings there and realized what you want is probably some sort of
<kdub> I feel like I've never had the genuine thought 'awesome, its a union'
<racarr> kdub: not since I was 12 or so here :p
<racarr> haha uh but you want
<racarr> some sort of Keybinder interface
<racarr> but then I realized keybinding description is
<racarr> the same signature as "MirKeyboardEvent" - "MirInputEvent"
<racarr> (Minus MirInputEvent that is)
<racarr> so if you could construct a MirKeyboardEvent without constructing the enclosing
<racarr> MirInputEvent
<racarr> MirKeyboardEvent could be the
<racarr> authorative uh
<racarr> key type
<racarr> lol
<racarr> and avoid this android input mess of
<racarr> MotionEvent v. NotifyMotionArgs (partially constructed MOtionEvent basically)
<racarr> in other news I literally forgot to drink coffee
<racarr> this morning
<racarr> this is unprecedented
<racarr> Hmm
<racarr> I've been thinking of promoting (Keyboard/Touch/Pointer)Event::Modifiers to InputEvent
<racarr> but the above thought suggests otherwise
<anpok_> and then do things like comparing events..
<anpok_> but does it matter that there is a union?
<racarr> anpok_: Well the thing is if
<racarr> its a union then they all need to contain
<racarr> timestamp
<racarr> which ISNT part
<racarr> of a keybinding
<racarr> description
<racarr> and
<racarr> device_id
<racarr> which...could be
<racarr> lol
<racarr> ugh
<racarr> I guess thats suggesting the time is the unique member
<racarr> yeah because its like
<racarr> a Keyboard state
<racarr>  + a time
<racarr>  = an event
<anpok_> or + occurence
<racarr> what do you mean?
<anpok_> if you leave the device id out of the keyboard stae
<anpok_> *state
<racarr> ah, yes.
<anpok_> where and when
<racarr> hmm
<racarr> so if not a union...C++ inheritance?
<racarr> Rust traits + FFI
<racarr> ...focus focus
<kdub> how did we end up with so much 'required' in protobuf :/
<camako> kdub, standup
<kdub> ah, coming
<dandrader> I run mir_proving_server on my laptop. run a client in from another ssh terminal. then in the client's terminal I do ctrl+c. mir_proving_server frezes for good, getting defunct and impossible to kill. is that a know issue?
<alan_g> dandrader: I'm not aware of that happening.
<alan_g> alf_: silo 021 has your fix and is working for me on mako. Wanna try it?
<alan_g> greyback_: are we there yet?
<dandrader> some how building mir_proving_server myself, with debug config, and running it under gdb made it behave....
<alf_> alan_g: all good on krillin
<alan_g> \o/
<racarr> Does anyone know how to GDB mir_unit_tests/
<racarr> if I run gdb on mir_unit_tests GDB silently detaches
<racarr> (no kidding...)
<racarr> if I run it on .uninstalled
<racarr> Bus error
<racarr> its been happening for about 2 weeks now...
<racarr> also has anyone experienced problems with system headers getting mixed in to local compilation...
<anpok_> hm that did not happen for me
<racarr> anpok_: Ok I guess ill just quit programming and get a job in the farm.
<racarr> ...printf debugging and dist upgrade it s
<racarr> is
<racarr> ahaha
<racarr> I mismatched an int32_t and an int64_t in a union
<racarr> making it look as if another enum value (preceeeding it in the union)
<racarr> was overwritten with the value which it would have had if
<racarr> parts were compiled with system headers instead of the modified local headers
<racarr> WHEEEE
 * kdub has gotten that gdb error
<kdub> on the unit tests
<SturmFlut> Mir and Unity8 on BayTrail: http://sturmflut.github.io/ubuntu/baytrail/2015/05/12/ubuntu-15-10-and-desktop-next-on-a-baytrail-tablet/
<SturmFlut> The external HDMI port even works in theory
<greyback_> kdub: I have a question on android multimonitor. I know how there is a DisplaySyncGroup, which is a collection of DisplayBuffers which are all swapped at once
<kdub> greyback_, right
<greyback_> kdub: say only 1 DisplayBuffer needs a redraw. Does the android MM stuff require the other one to also be redrawn too?
<greyback_> i.e. we get fresh DisplayBuffers back for all displays after a swap
<kdub> greyback_, so, the updated DisplayBuffer will get a swap, and the not-updated one won't
<kdub> and both will be 'reposted'
<greyback_> ahh
<greyback_> swap != post
<kdub> right, I had to tease that out because hwc doesn't give me a way to just update one
<kdub> so the DisplayBuffer is back to the original idea of just being the content on screen (2d stuff or overlays), and the DisplaySyncGroup does the posting
<greyback_> kdub: that's ok. The above scenario had me confused, but as swap != post, it's ok
#ubuntu-mir 2015-05-13
<shiznix> hi all, as XMir has been broken on Intel gfx hardware for some time now on Ubuntu's latest stable offering, i was hoping to try a dev snapshot of the xmir patch for the intel gfx driver
<shiznix> however i'm chasing my tail trying to find which project is hosting this
<shiznix> it's not in lp:mir and it's not in lp:xserver-xorg-video-intel
<shiznix> aah, might be in git://people.freedesktop.org/~mlankhorst/xserver
<tmpRAOF> shiznix: Broken on Intel? I've not tested particularly recently, but I also wasn't aware of any change that might have broken it.
<shiznix> hi tmpRAOF
<shiznix> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1450581
<ubot5> Ubuntu bug 1450581 in xserver-xorg-video-intel (Ubuntu) "Hardware accel causes X segfault with SNA renderer" [High,Confirmed]
<shiznix> and related https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1420959
<ubot5> Ubuntu bug 1420959 in xorg-server (Ubuntu) "xmir crashes when launching chromium" [Undecided,Confirmed]
<shiznix> only crashes if GL is used
<RAOF> Hm, DRI2CopyRegion.
<RAOF> Yeah, that'd be right; if that's buggy you'd hit it whenever something tried to be accelerated.
<duflu> shiznix: We know XMir 1.0 (the version in Ubuntu) has a number of bugs (https://bugs.launchpad.net/xmir). Although it's worth noting that 1.0 is not being maintained. An entirely new 2.0 implementation is coming soon (never before seen in any Ubuntu release)
<robert_ancell> Does anyone know why XMir is using DRI2 and not DRI3?
<RAOF> robert_ancell: Two reasons - (1) we don't enable DRI3 on any of our drivers, and (2) because DRI3 has a buffer model that's incompatible with Mir.
<robert_ancell> RAOF, does that mean we can never use DRI3 with Mir?
<RAOF> robert_ancell: No, but we lose some performance optimisations.
<RAOF> If DRI3 support for XMir becomes a required feature then we can do that.
<duflu> robert_ancell: You're looking at Maarten's XMir 2.0 right?
<robert_ancell> duflu, well, there's no versioning but the stuff from the git branch. Trying to clean it up and work out what could be upstreamed easily.
<robert_ancell> The DRI2 code is quite complex and I suspect upstream only really cares about DRI3
<duflu> robert_ancell: Yeah I know. git means 2.0, while the one in distro is 1.0. As they're entirely different codebases we need to avoid confusing people and ourselves
<duflu> Even within the XMir project, the code tab points to 2.0 and the bugs tab points to only 1.0 bugs :P
<duflu> When I first raised the issue Maarten didn't think anything was confusing about that
<shiznix> duflu: i see thanks - is the 2.0 implementation useful enough for testing yet ?
<duflu> shiznix: It is indeed good, but hiding in a git repo you have to build it yourself :S
<shiznix> that's ok, you got the repo link ?
<duflu> shiznix: It will produce an "Xmir" binary as well as all the normal binaries: git://people.freedesktop.org/~mlankhorst/xserver
<shiznix> aha thank you
<duflu> shiznix: And this one is windowed (ie. one Xmir server per client) so you need to provide your own Mir server like those in package mir-demos
<duflu> It's not a desktop replacement like Xmir 1.0 was
<duflu> Just runs X apps in an existing Mir server
<shiznix> ok i understand
<alan_g> duflu_: the good news is that I can run the archive glmark in my locally built and installed mir_performance_tests and it all works. (The bad news is I don't yet know what happens in CI)
<alan_g> It correctly picks up the archive libmirclient.so.8 & libmircommon.so.3
<alan_g> greyback_: are we there yet?
<greyback_> alan_g: building locally to make sure
<duflu_> alan_g: Yeah it should. Probably LD_LIBRARY_PATH is in the way in CI
<alan_g> It's reassuring that the code works. It is just down to the way CI installs & runs things (or a packaging error)
<duflu> alan_g: In fact it probably has to be LD_LIBRARY_PATH; just make sure glmark2 doesn't have that set
<alan_g> duflu: surely LD_LIBRARY_PATH would either stop it finding any .so or let it find the right one?
<duflu> alan_g: Wait, no. That's rubbish. There's only one libmirclient.so.8 and one libmirclient.so.9 on the system. It's not possible to confuse them :S
<alan_g> Hold on! What's mir-0.13.0 doing here? "/tmp/buildd/mir-0.13.0bzr2570pkg0vivid2371+autopilot0/tests/performance-tests/test_glmark2-es2-mir.cpp:63: Failure"
<alan_g> nm
<alan_g> For a moment I thought the error was from the glmark build
<duflu> alan_g: Exactly. The installed version has libmirclient8 and the build version libmirclient9. They should not be confused
<greyback_> alan_g: pushed
<alan_g> greyback_: thanks
<alf_> alan_g: @fix-1454128-by-getting-select_active_surface-right, was calling input_targeter->clear_focus() and session_coordinator->unset_focus() when we didn't have focus causing problems, or is it a performance optimization?
<alan_g> alf_: not causing a problem as such, but it was easier to make the expectation efficient than keep that behaviour
<alf_> alan_g: ok
<alan_g> davmor2:  FYI @silo-021 - problem fixed and updated to pick up latest qtmir
<davmor2> alan_g: yeap saw the ticket come through thanks
<alan_g> alf_: do the end-to-end input tests need to be in separate processes? Or could we run everything in a single process?
<greyback_> hey folks, dandrader & I have a query. We're testing mir_proving_server with simple Qt clients. If I bring up mir_proving_server as root via ssh, launch the qt app, then Ctrl+C it, mir_proving_server crashes
<greyback_> but if I do the same in VTs, it works ok
<greyback_> any ideas?
<kdub> well, its still using a vt via ssh, right?
<kdub> sounds like that shouldn't happen though
<greyback_> yeah, it's weird, I don't know why the difference
<alan_g> Sounds odd. For elimination purposes do ou see the same with mir_demo_server?
<alan_g> s/ou/you/
<alan_g> So you've detached mir_proving_server to start the client?
<alan_g> Dunno why it would even see Ctrl-C in that case
<alan_g> One possible difference is that the serve will be halted by switching away from the VT. So shutdown might be easier
<greyback_> aaand now it worked fine
<greyback_> aha
<greyback_> I resized the application window, then Ctrl+C
<greyback_> crash
<greyback_> so it's unrelated to ssh vs VT
<alan_g> Ctrl+C on the ssh session? Or on the Mir session?
<greyback_> alan_g: neither, on the client
<alan_g> You SIGQUIT the client and the server dies?!
<greyback_> yeah
<greyback_> logging bug
<alan_g> But not if you don't resize the client window first?
<alan_g> It seems too mad to be true
<alan_g> is this archive or trunk or some other?
<greyback_> archive, 0.12.1
 * alan_g tries it
<greyback_> alan_g: https://bugs.launchpad.net/mir/+bug/1454714
<ubot5> Ubuntu bug 1454714 in Mir "mir_proving_server crash if resize qt client window and then quit" [Undecided,New]
<greyback_> how do I attach a .crash file output to a bug, I keep forgetting this command
<alan_g> Me too
<alf_> alan_g: @end-to-end-input-tests, (I am assuming you mean the servers) We could run them in a single process, but I want to create an environment as similar to the production one as possible
<alan_g> greyback_: I've been trying with mir_demo_client_multiwin and not seen a crash.
<greyback_> alan_g: yeah, seems it needs to be a qt client
<greyback_> it may be doing something "wrong"
<greyback_> but even so, it shouldn't crash the server
<alan_g> +1
<alan_g> Just wanted to confirm
<greyback_> how the heck do I attach this damn crash file to the bug!
<alan_g> What am I missing? 'This application failed to start because it could not find or load the Qt platform plugin "ubuntumirclient".'
<greyback_> alan_g: qtubuntu-desktop
<alan_g> greyback_: I've not tried with ssh yet (need to unearth laptop for that) but still not seeing a crash.
<greyback_> alan_g: seems myself & dandrader can repro quite reliably. You using mir 0.12.1 or something newer maybe?
<tedg`> kgunn, FYI, might be worth sending someone: http://wiki.linuxplumbersconf.org/2015:graphics_modesettings_wayland
<alan_g> greyback_: whatever's in vivid (without ppa)
<greyback_> alan_g: ok, we on same page so
<dandrader> greyback_, about  https://bugs.launchpad.net/mir/+bug/1454714. building mir_proving_server myself and running it under gdb made that crash go away
<ubot5> Ubuntu bug 1454714 in Mir "mir_proving_server crash if resize qt client window and then quit" [Undecided,New]
<greyback_> dandrader: and running without gdb?
<dandrader> greyback_, don't know. let me reboot it. the laptop froze
<greyback_> https://bugs.launchpad.net/ubuntu/+source/mir/+bug/1454724 should have backtrace attached soon
<ubot5> Ubuntu bug 1454724 in mir (Ubuntu) "mir_proving_server crashed with SIGSEGV in __pthread_mutex_unlock_usercnt()" [Undecided,New]
<dandrader> greyback_, yeah, the mir_proving_server I built myself with a debug config doens't crash also when run outside gdb
<dandrader> greyback_, but the packaged one does
<alan_g_> greyback_: when I ssh and try it I get "(qmlscene:25883): Gtk-WARNING **: cannot open display: " and the test exits. (the mit client is fine)
<dandrader> alan_g_, run with sudo
<dandrader> alan_g_, I also can't get qmlscene to run without being root :/
<greyback_> alan_g: please remove "appmenu-qt5"
<greyback_> that uses gtk, which tries to do X stuff
<alan_g_> Git it
<alan_g_> s/i/o/
<alan_g_> and broke the server
<greyback_> ok, glad it's not just here
<alan_g_> And broke VT switching. :(
<greyback_> I can recover doing "sudo X" and then killing it from another ssh session
<alan_g_> !ssh
<ubot5> SSH is the Secure SHell protocol, see: https://help.ubuntu.com/community/SSH for client usage. PuTTY is an SSH client for Windows; see: http://www.chiark.greenend.org.uk/~sgtatham/putty/ for it's homepage. See also !scp (Secure CoPy) and !sshd (Secure SHell Daemon)
<racarr> hmm does anyone else find the wizard really difficult
<racarr> to complete all of a sudden
<racarr> I just failed to swipe the launcher from the left according to its heuristic like
<racarr> well for a bout a minute straight lol
<racarr> I mean everything visually seemed fine but the wizard wouldnt advance
<kdub> phablet-config welcome-wizard --disable
<kdub> s/welcome-wizard/edges-intro
<racarr> kdub: Aha yeah I was just wondering if we broke it..
<kdub> eh, i havent noticed, I'd guess unlikely that we did
#ubuntu-mir 2015-05-14
<racarr> omg...I think I just witnessed the acceptance tests running against
<racarr> system libraries
<racarr> lol...spent most of the morning
<racarr> lalala
<racarr> hmm
<racarr> how to understand this...
<racarr> It's looking like https://bugs.launchpad.net/mir/+bug/1437357 may be fixed in trunk and or/prefer-event-builders
<ubot5> Ubuntu bug 1437357 in Canonical System Image "Crash because uncaught exception in mir::events::add_touch" [Critical,In progress]
<racarr> maybe the messed up action mapping
<racarr> was causing the events to get malformed in the
<racarr> nested dispatcher?
<racarr> I dunno
<racarr> but I ran now
<racarr> mir server -> nested -> client
<racarr> (havnet built u8 yet)
<racarr> and uh
<racarr> I didn't validate the whole event stream but the crash doesnt occur and now the client is using mir::events::add_touch
<racarr> so either 1. The bug is fixed.
<racarr> 2. Qtmirs attempt to fix an invalid touch stream is making it more invalid causing the crash
<racarr> going to write a touch validating client now
#ubuntu-mir 2015-05-15
<alan_g> alf__: IIRC the mesa support did/does some unusual stuff with loading symbols?
<anpok> i think the interesting part is that the mesa egl library does not link against mirclient
<anpok> (while it links against wayland c/s and libX*)
<anpok> alan_g: mesa does lib = dlopen(null) dlsym(.. "mir_egl_mesa_display_is_valid") ..
<alan_g> anpok: Ah. That's probably what I'm seeing.
<alf__> alan_g: anpok: yes, it assumes that libmirclient/server is linked by the executable, and searches for that function at runtime
<alan_g> I tried removing the ensure_loaded_with_rtld_global() hack and mesa "blew up"
<anpok> then it knows that the surface is of a specific type and uses function pointers there to advance buffers..
<anpok> ah
<alan_g> alf__: @1455109 - so we change status to confirmed? And push to the kernel team?
<alf__> alan_g: that's one way to go, although I still haven't verified that the commit really fixes the problem.
<alan_g> alf__: OK, then just update the status for now?
<alf__> alan_g: yes
 * alan_g is glad that all the cleanup of linkage to static libraries allows us to remove the ensure_loaded_with_rtld_global() hack from libmirclient and libmirplatform
<alf__> alan_g: I will mark confirmed in Mir for now, although the kernel crash is of course the kernel's fault.
<alf__> alan_g: Not sure what's so special about "sudo mir_demo_server --vt 2 --test-timeout 1 --test-client mir_demo_client_basic"
<alf__> alan_g: the command also fails on radeon too (but doesn't crash the kernel)
<alan_g> Indeed, especially as I couldn't get the error with the non-installed build (even with use_debflags)
<alan_g> davmor2: not nagging, but what timeframe are we expecting for mir-0.13.0?
<davmor2> alan_g: I have been blocked for 2 days and the fubar images in the channels so it should be by end of day today hopefully
<davmor2> s/and/with
<alan_g> Thanks. :)
<davmor2> now that we finally have vivid images all round
<alan_g> alf__: FYI it is now "vivid all round" ^^
#ubuntu-mir 2015-05-17
<sturmflut_> Hmmmm, does Mir support Miracast or is support for Miracast planned?
#ubuntu-mir 2016-05-16
<alan_g> kdub: are you happy with these test & SessionMediator changes? I know you have designs on mir_connection.cpp but, as mentioned in comments, your version is compatible with this behavior. https://code.launchpad.net/~alan-griffiths/mir/BufferStreamArrangement.can_be_specified_when_creating_surface/+merge/294407
<kdub> alan_g, will review, not sure how it meshes with https://code.launchpad.net/~kdub/mir/fix-1577967/+merge/294283 yet
<alan_g> kdub: https://code.launchpad.net/~alan-griffiths/mir/BufferStreamArrangement.can_be_specified_when_creating_surface/+merge/294407/comments/756082
<kdub> alan_g, will review shortly, heads all full of adding error callbacks for MirBuffers at the moment
<alan_g> np
<kdub> Saviq, the failure in silo 68 needs silo 31 to land to unblokc
 * kdub hit a similar issue in silo 69
<Saviq> kdub, orly
<kdub> yeah, hybris started aborting when probing on non-android platforms, which broke the mesa stack, and 31 changes the behavior to returning an error code
#ubuntu-mir 2016-05-17
<zzarr> hello!
<zzarr> this is just a "what if" question, if I have a Vulkan driver for a graphics card, when Mir have support for Vulkan, would that mean that I could use Mir with that driver, or does it not work that way?
<alan_g> zzarr: essentially, yes. Although there might be some caveats. camako ^?
<kdub> zzarr, I think if its vulkan supported via mesa, you'll probably be alright (because mir has a mesa platform)
<kdub> if its supported via <a blob>, support will come when <a blob> is a supported mir platform
<zzarr> okey
<zzarr> so, I'll have to wait and see
<zzarr> there's a Vulkan driver comming to Mali GPU's but I don't know how/if it will be open/closed source
<kdub> well, thats an android platform
<kdub> and android is supported
<kdub> what we would need there is hybris support for vulkan
<kdub> which afaik, is not present
<zzarr> well kdub, I have an ASUS Chromebook Flip, which Ubuntu would be lovely on ;)
<camako> zzarr, answering your original question, mir support needs to be added to every Vulkan driver separately
<camako> zzarr, there is no such thing as Mir support for Vulkan in Mir
<camako> zzarr, Mir support must be in the individual drivers themselves
<camako> We have a prototype for the Mesa Vulkan Intel driver - we were able to do this ourselves since Mesa is open source
<camako> We'll upstream it when everything is ready
<camako> We also have a prototype for the LunarG Intel Vulkan driver - not sure if that one is worth upstreaming (or even if that's possible... maybe)
<zzarr> camako: I thought that it was that way
<zzarr> I have to wait and see what they release
<camako> zzarr, when is this expected to come out?
<zzarr> camako: I don't know, it says comming soon
<zzarr> is this something useful? http://malideveloper.arm.com/resources/drivers/open-source-mali-gpus-ump-user-space-drivers-source-code/
<camako> not to me :-)
<zzarr> okey
<zzarr> some day, I will read about how ump and all the other parts of a gpu driver (I only know about kernel-driver and user-space driver yet)
<zzarr> is there an ongoing porting of openjdk to mir?
<sil2100> Hello! Could anyone review an mir MP? I mean the one in the following silo: https://requests.ci-train.ubuntu.com/#/ticket/1421
#ubuntu-mir 2016-05-18
<alan_g> Does anyone feel like some MirAL reviews? https://code.launchpad.net/miral/+activereviews
#ubuntu-mir 2016-05-19
<alan_g> kdub: are you planning a 23.1 release? (I'd find it really convenient if we could cherry-pick lp:~alan-griffiths/mir/fix-1583536 if it lands in time.)
<kdub> alan_g, sure
#ubuntu-mir 2016-05-20
<duflu> greyback: I think I love you right now. INTEL_DEBUG=perf was a great suggestion
<duflu> (love you more than usual)
<greyback> :)
<greyback> duflu: I bestow http://mesa3d.org/envvars.html upon you, use it with care!
<duflu> greyback: I know. Still never used that variable before
<greyback> I had to read through the i915 mesa code to figure out what env vars actually returned some debugging info
<duflu> Arguably perf issues are errors to us... but if you ask only for errors you'd never see it
<greyback> what did you learn?
<duflu> greyback: Old and new(!) Intel GPUs fall back to software rendering regularly
<duflu> But Atoms moreso
<duflu> Possibly caused by ES/non-ES confusion
<duflu> The Atom issue seems to be that our shaders are 18% longer than the hardware limit
<greyback> that's interesting
<duflu> It's a big deal
<duflu> And exciting to imagine after we fix it
<greyback> indeed
<duflu> greyback: The offending function seems to only be in qtubuntu and qtquick but maybe I missed more
<greyback> qtubuntu is just a glue between mirclient/platform-api and Qt - aside from setting up GL context, it has no other impact on GL
<greyback> qtquick most likely
<duflu> I logged bugs. You will find them...
<greyback> nice
<greyback> duflu: fyi, here are the shaders QtQuick has: http://code.qt.io/cgit/qt/qtdeclarative.git/tree/src/quick/scenegraph/shaders
<greyback> that is trunk (5.7 pre-release), we're using 5.5, but I don't see the shaders changing in some time
<duflu> greyback: One thing at a time. The first issue seems to be bad format args to glCopyTexSubImage
<greyback> ah, that was what you were referring to
<greyback> yes
<greyback> I had hoped a proper OpenGL context would have resolved that
<duflu> Which I found one instance of that switches behaviour for ES
<duflu> Yep
<greyback> http://pastebin.ubuntu.com/16518134/ <- qt only uses it for the font distance field
<greyback> uitk doesn't
<alan_g> kdub: you're probably not looking at it yet. But you had an MP that got the titlebars wrong. I've just seen a similar behavior in code I'm working on and it looks like a deeper issue that may also have caused the problem on your branch. Will update if I figure it out.
<kdub> alan_g, ack, yeah got stuck on that one because i couldnt get the terminal to start
<alan_g> kdub: I bottomed my problem - unfortunately, it was new code so it fix yours.
<kdub> *it doesnt fix?
<alan_g> yes doesn't
<alan_g> /sigh
<alan_g> Oh well, 20min of week left and code is in a stable intermediate form. Might as well MP it and start looking forward to xp2016
#ubuntu-mir 2016-05-21
<Ashkooz> Hi everyone, I've installed unity8-mir through ppa stable-phone-overlay on my laptop, it looks promising but libertine doesn't work (when I want to setup a container, it auto-removed)
#ubuntu-mir 2017-05-15
<alan_g> anpok_: I just looked at lp:mir-android-platform - it doesn't seem to be picking up Mir package configs, linking against gtest, etc. Is there a branch I should checkout? Or am I looking too soon?
<anpok_> I tested that with install lp:mir into an alternative destination directory..
<anpok_> then setting the pkg config path to pull from there
<anpok_> or $there/lib/pkgconfig/
<anpok_> I had no problems with gtest
<alan_g> Weird. I have Mir in /usr/local. The first thing I hit was gtest:
<alan_g> $ git diff
<alan_g> diff --git a/tests/unit-tests/platforms/android/CMakeLists.txt b/tests/unit-tests/platforms/android/CMakeLists.txt
<alan_g> index 78ef6e6..a8cabda 100644
<alan_g> --- a/tests/unit-tests/platforms/android/CMakeLists.txt
<alan_g> +++ b/tests/unit-tests/platforms/android/CMakeLists.txt
<alan_g> @@ -35,6 +35,9 @@ target_link_libraries(
<alan_g>  
<alan_g>    client_platform_common
<alan_g>    server_platform_common
<alan_g> +  ${GTEST_BOTH_LIBRARIES}
<alan_g> +  ${GMOCK_LIBRARY}
<alan_g> +  ${GMOCK_MAIN_LIBRARY}
<alan_g>    dl
<alan_g>  )
<alan_g> Then I found that it was picking up the wrong libmirserver.so
<alan_g> so I asked
<alan_g> But I see things like "mirserver" mentioned, not ${MIRSERVER_LDFLAGS} which is what I'd expect
<anpok_> ok there is something wrong
<anpok_> I just cleared by cmake cache
<anpok_> and it fails to find gmock
<anpok_> and gtest
<alan_g> Your cmake cache came from a copy of lp:mir?
<anpok_> alan_g: I dont think that would have been possible - but I did iterate untill it worked, and did not make a clear run after that.
<anpok_> Can you try again?
<anpok_> should be fine now..
<alan_g> anpok_: better but still seeing it pick the wrong libmirserver.so:
<alan_g> /usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libmirserver.so: undefined reference to `mir::protobuf::RaiseRequest::RaiseRequest()@MIR_PROTOBUF_3'
<alan_g> I can investigate a bit later, just needed to know if it's worthwhile
<alan_g> Actually, why would it be linking to libmirserver.so at all?!
<anpok_> there are diagnostic utils that would.. but those are disabled at the moment
<anpok_> test assist?
<alan_g> That would be it
<anpok_> ah and the wrapper need to changed
<anpok_> or actually I should not need that..
<anpok_> alan_g: ok I think I found something..
<alan_g> There are a number of things: MIRSERVER_LDFLAGS, MIRCOMMON_LDFLAGS etc are used but never set
<alan_g> MIRSERVER_LDFLAGS in particular shouldn't ever be needed
<alan_g> Something somewhere is searching for libmirserver.so without going through a Mir .pc file.
<alan_g> anpok_: Here's a fix - https://paste.ubuntu.com/24581832/
#ubuntu-mir 2017-05-16
<alan_g> RAOF: ping
<RAOF> yo!
<alan_g> did you see my email about the Mir SRU?
<RAOF> alan_g: I did. Sorry for not replying today. It looked like you got some support for it here last week?
<alan_g> RAOF: some, but I'm still trying to figure out who I need to progress it further
<RAOF> Ok.
<tjaalton> alan_g: I was about to ask about that too, because it affects the hwe stack backports :) with mir backported I could re-enable support for the new stuff
<RAOF> alan_g: it's current waiting in a silo? Or are you going to avoid the bileto bang?
<alan_g> RAOF: it's in silo 2736
<alan_g> tjaalton: that sounds like another benefit.
<tjaalton> yep
<RAOF> alan_g: I think I know how to push that to the archive. I'll test that hypothesis first thing tomorrow.
<alan_g> RAOF: thanks
<alan_g> RAOF: have a good evening!
<alan_g> anpok: @{the patch I pasted yesterday} - this fixes the Mir bug: https://code.launchpad.net/~alan-griffiths/mir/fix-mirtest.pc/+merge/324097
<anpok> oh nice .. i also stumbled over a mirprotobuf problem
<anpok> if you look at the patch I added yesterday to the android platform - I took your change and still had to add mirprotobuf
 * alan_g just has to find someone left that can review MPs
<anpok> yeah hire someone!
<anpok> ok me continues fencing..
<alan_g> anpok: https://launchpad.net/mir-android-platform/+activereviews
<blaze> Finished 1 minute ago (took 2 minutes, 12.8 seconds)
<blaze> woops, sorry
<anpok_> hi
<bschaefer> anpok_, ill need to poke you at some point about the libinput patches ... such as... do we want to upstream that umm specific phone patch one?
<bschaefer> i.e 0003-Fix-premature-flushing-of-evdev-event-on-mx4-touchsc.patch
<bschaefer> that one
<anpok_> that was not really mx4 specific
<anpok_> that patch changed the treatment of specfic button events
<bschaefer> anpok_, looks like you correctly handled a none type
<bschaefer> for fallback?
<anpok_> hm I think mx4 emits a button event on touch.. and libinput than thinks it is a key
<bschaefer> +   if (type == EVDEV_KEY_TYPE_NONE) { then check if we are a touch then fall back
<bschaefer> anpok_, o that makes sense
<anpok_> as a result it would flush the touch contact state
<anpok_> and generate an incomplete update..
<anpok_> I think libinput upstream has reworked that code and they have fixed that already in a different way
<bschaefer> o yeah i should attempt to double check the code here to see if its already been fixed
<bschaefer> anpok_, i think the main would be 0001-libinput-add-orientation-and-size-of-touch-point-and.patch
<bschaefer> ?
<bschaefer> (thats a pretty large patch)
<anpok_> yup
<anpok_> and you have to change a few chunks there because the naming of the evdev internals changed
<bschaefer> o dangs well shouldnt be to bad
<anpok_> what is lacking here is an udev property to somehow scale the touch contact sizes
 * bschaefer still side tracked by other work but needs to get on getting these patches working
<bschaefer> anpok_, i see, well ive never had to do much digging into libinput (just minorly) hopefully its not to bad
#ubuntu-mir 2017-05-17
<alan_g> tjaalton: RAOF has put the Mir SRU into https://launchpad.net/ubuntu/xenial/+queue?queue_state=1, but someone else needs to approve. I see you named on https://launchpad.net/~ubuntu-sru/+members#active - does that mean you can help?
<tjaalton> alan_g: sure
<tjaalton> while it's not my sru day today but can have a look
<tjaalton> because I need this too :)
<alan_g> That was exactly my thought. 8^)
<alan_g> anpok: I know you talked to bschaefer about the libinput patch. That's all that's happened right?
<tjaalton> I hope those get either dropped or upstreamed
<alan_g> I know, it is one of the embarrassments I need to get cleaned up.
<tjaalton> i'm updating it to 1.7.2 for debian experimental
<tjaalton> and then merge for artful
<tjaalton> alan_g: I see the mir backport adds new packages, does it need a transition?
<alan_g> tjaalton: I don't think so. It installs alongside just fine
<tjaalton> one thing I noticed is that all the bugs that this SRU references have the upstream tasks as "fix committed" and not fix released
<alan_g> tjaalton: yeah...
<alan_g> We were in the middle of a 0.27 release when things happened
<alan_g> That will get picked up again, but I've fewer hands than before
<tjaalton> okay
<alan_g> They are all low risk changes, and we're the only real consumers of that stuff
<tjaalton> alright
<ogra_> alan_g, mind taking a look at https://forum.snapcraft.io/t/bug-in-core-running-on-rpi3/657 ? (was mir-kiosk/mir-libs recently updated ?)
<alan_g> ogra_: sure. I'm not aware of any recent updates. (Near future however...)
<ogra_> we didnt really change anything in core either, the drivers should still be the saem as always ...
<ogra_> snaps are built and linked against the debs though ...
<ogra_> so if the archive has something that doesnt work with mir-libs or mir-kiosk, that might have some impact
<tjaalton> could the libinput patch to keep compatibility with old mir servers be dropped from artful?
<alan_g> tjaalton: I know that would be nice, but I think that would likely break the mir source currently in archive.
<alan_g> ogra_: I got the same symptoms on dragonboard after a "snap refresh". Looked like the interfaces were screwed up (they'd been frigged manually in the past). Uninstalling and reinstalling libs, kiosk and apps seemed to resolve whatever went wrong. Hopefully, will work for rIl3 too.
<alan_g> rPi3
<ogra_> alan_g, ah, cool, thanks for researching that!
<AdamH_> It is my post if I can help with debugging it?
<alan_g> AlbertA: you've a rPi3 haven't you? Could you have a look into https://forum.snapcraft.io/t/bug-in-core-running-on-rpi3/657/11
<AlbertA> alan_g: I do
<AlbertA> umm "Loading module: 'libubuntu_application_api_test.so.3.0.0'" seems wrong
<ogra_> ogra@pi3:~$ find /snap/mir-kiosk-apps/16/ -name '*libubuntu_application_api_test*'
<ogra_> oops
<ogra_> /snap/mir-kiosk-apps/16/usr/lib/arm-linux-gnueabihf/libubuntu_application_api_test.so.3
<ogra_> /snap/mir-kiosk-apps/16/usr/lib/arm-linux-gnueabihf/libubuntu_application_api_test.so.3.0.0
<ogra_> definitely existing though
<AlbertA> ogra_: right but it's just a stub used for testing
<ogra_> ah
<AlbertA> ogra_: interesting part, I booted my rpi3 with some old core version I suppose...
<AlbertA> mir-kiosk-apps started fine....
<AlbertA> then auto-updated...
<ogra_> weird
<AlbertA> and I see the issue
<ogra_> well, mir-kiosk itself starts for me just fine
<ogra_> just not the apps
<AlbertA> ogra_: yeah
<AlbertA> same here
<ogra_> so i wonder how a system update could relate to the breakage here
<ogra_> was this an old core with no mir snaps installed ?
<ogra_> (initially)
<AlbertA> ogra_: no the snaps were installed already
<ogra_> ah
<AlbertA> ogra_: ummm I'm not getting anything in syslog... is there a command to enable output now? or did logging change?
<ogra_> AlbertA, sudo journalctl --no-pager
<ogra_> we dropped rsyslog
<AlbertA> ogra_: ahh thanks!
<ogra_> (kills SD cards ... journalctl uses a ringbuffer)
<ogra_> s/journalctl/journald/
<AlbertA> ogra_: so yeah seeing the same thing "Unable to load selected module, using dummy." a bit useless...
<ogra_> well
<ogra_> looks like it falls over in the inotifywait call of /snap/mir-kiosk-apps/16/bin/mir-kiosk-app-daemon
<AlbertA> but it all originates from papi not being able to load the module
<ogra_> which ... if i read that right ... is supposed to wait til a config file has been created
<AlbertA> ogra_: yeah it
<AlbertA> it's used to wait for changes to the confif file
<AlbertA> but the main issue is that papi fails to load the module (so dlopen failed on it) for some reason
<AlbertA> but since nothing changed about the snaps... only core (at least here) probably a new security related feature?
<ogra_> or a snapd change ...
<AlbertA> ogra_: right...
<AlbertA> ogra_: yeah just a dlopen: http://bazaar.launchpad.net/~phablet-team/platform-api/trunk/view/head:/src/ubuntu/application/base_module.h#L113
<ogra_> mind noting that in the thread ?
<AlbertA> ogra_: done
<ogra_> AlbertA, thanks!
<AlbertA> ogra_: happens on VM with an amd64 core image so should make it easier to debug
<ogra_> yeah
<AlbertA> ogra_: so turns out newer core snap revisions do not have libjson-c.so.2 anymore, which libubuntu_application_api_desktop_mirclient.so.3.0.0 depended on.
<AlbertA> IIRC snapcraft has some smarts to not include "known" system libraries or some such... perhaps that's why it was not included in the mir-kiosk-apps snap originally...
<alan_g> AlbertA: thanks for tracking that down
<AlbertA> alan_g: no prob
<chatter29> hey guys
<chatter29> allah is doing
<chatter29> sun is not doing allah is doing
<chatter29> to accept Islam say that i bear witness that there is no deity worthy of worship except Allah and Muhammad peace be upon him is his slave and messenger
#ubuntu-mir 2017-05-18
<RAOF> I wish that so many of our tests didn't make blatantly invalid calls, relying on the internal implement to silently ignore them...
<anpok> thats fake news!
<RAOF> In related news, virtually all of our buffer tests try to either (a) release a buffer they haven't allocated, or (b) submit a buffer they haven't allocated.
<RAOF> Also, we have code to check whether a buffer allocation request has a BufferStreamId set, but all client codepaths set that value.
<alan_g> tjaalton: We've checked Mir from proposed. Is it now just a matter of waiting?
<tjaalton> alan_g: yep
<bschaefer> fritsch, hey, sooo i assume (for when compiling xbmc with mir) -- VAAPI enabled: Yes -- VDPAU enabled: No
<bschaefer> will cause these build issues: http://paste.ubuntu.com/24600082/
<bschaefer> i can dig into a bit more this weekend ... just trying to grok the current vaapi/vdpau talk + that raspi branch
<bschaefer> was pretty much reading the codec depends on both vaapi and vdpau being enabled
#ubuntu-mir 2017-05-19
<RAOF> Success!
<RAOF> Now to rebase into submittable form.
<xnox> Saviq, alan_g: so neither qtmir-desktop nor qtubuntu-desktop is needed?
<xnox> then in my mini supported-kiosk i will only have content-hub and libmiral-dev
<Saviq> xnox, correct, qtmir was only used by unity8
<xnox> yeah \o/
<Saviq> we'll need to update content-hub to not use the interfaces qtmir exposed, though
<xnox> sure
<Saviq> not sure if that dep is expressed in debian/control, but the result will only be that you can't copy/paste... which you can't anyway unless you're using unity8
<xnox> development goes on as needed.
<alan_g> @libmiral-dev - surely miral-kiosk needs miral-examples
<alan_g> Saviq: that always puzzled me - why cut & paste started working in miral (but I never investigated)
<Saviq> alan_g, maybe content-hub was smart about running under unity8 (or not) - in which case things should continue working :)
 * alan_g hopes
<alan_g> https://books.google.co.uk/books?id=sS7aPtrUuw4C&pg=PA58&lpg=PA58&dq=97+things+every+programmer+griffiths+magic&source=bl&ots=-hi1PW6dwN&sig=zikGKTPhISbGiovEuigGWVD647c&hl=en&sa=X&ved=0ahUKEwjx--Ld2vvTAhVoLMAKHdM-BycQ6AEIJzAA#v=onepage&q=97%20things%20every%20programmer%20griffiths%20magic&f=false
<alan_g> Oops! that's a long URL
#ubuntu-mir 2017-05-20
<fritsch> bschaefer: yeah - currently broken and much noise :-)
