#ubuntu-mir 2013-03-25
<smspillaz> racarr: good read if you're interested http://googletesting.blogspot.com.au/2013/03/testing-on-toilet-testing-state-vs.html
<ninjaaron> is Mir going to be using libxkbcommon for keyboard input?
<tvoss> alf___, ping
 * tvoss remembers alf saying that today is a public holiday in Greece
<RAOF> Indeed he did.
<smspillaz> heh, wayland fork drama
<alan_g> smspillaz: reference?
<smspillaz> alan_g: hang on
<smspillaz> http://lists.freedesktop.org/archives/wayland-devel/2013-March/008131.html
<alan_g> smspillaz: that's a hard attitude for anyone to engage constructively with
<smspillaz> alan_g: we will see where it goes - hopefully it will drum up some interesting projects
<alan_g> mmrazik|lunch: I'm not what's up with this build. But it looks like it is getting glog while failing to get gflags (which glog needs). Can you spot the problem? https://jenkins.qa.ubuntu.com/job/mir-android-raring-i386-build/117/console
<tvoss> alan_g, you need to adjust the packaging setup in debian/control
<tvoss> alan_g, and add glog as a build dependency
<alan_g> tvoss: you mean like: 40	+ libgoogle-glog-dev
<alan_g> ?
<tvoss> alan_g, yup, but seems like you need to add gflags there, too
<alan_g> Surely the transitive dependency on gflags should be implicit?
 * alan_g guesses it can't hurt to try
<mmrazik> alan_g: I don't know. I've noticed this failure (all mir failures are going to my INBOX) but I don't know
<mmrazik> alan_g: maybe kdub can help ?
<alan_g> mmrazik: I'll ask him when he comes online.
<tvoss> lool, bschaefer, seb128 https://plus.google.com/hangouts/_/cbad7ead46ab1c85a9bc118c525d02dad37e1bc9?authuser=0&hl=en
<seb128> tvoss, is that an onair hangout?
<tvoss> seb128, yup :)
<seb128> excellent
<seb128> on my way (just grabbing something to drink)
<bschaefer> tvoss, hello, thanks
 * bschaefer has no web cam though
<tvoss> seb128, bschaefer you guys coming?
<tvoss> tmoenicke, https://plus.google.com/hangouts/_/cbad7ead46ab1c85a9bc118c525d02dad37e1bc9?authuser=0&hl=en
<tvoss> lool, https://blueprints.launchpad.net/ubuntu/+spec/client-input-methods
<tvoss> lool, https://plus.google.com/hangouts/_/cbad7ead46ab1c85a9bc118c525d02dad37e1bc9?authuser=0&hl=en
<lool> coming
<bschaefer> tvoss, yeah, had to re-install the hangout plugin....
<tvoss> bschaefer, ack :)
<tvoss> kgunn, https://plus.google.com/hangouts/_/cbad7ead46ab1c85a9bc118c525d02dad37e1bc9?authuser=0&hl=en
<kgunn> coming
<tvoss> anyone from the Ubuntu kylin project here?
<lool> seb128: do you remember who was pushing for the other input stack?
<seb128> lool, input?
<seb128> like xinput/libinput?
<seb128> or ibus/fcitx?
<lool> seb128: fcitx
<bschaefer> theres a bunch, gcin, hime, fctix, ibus etc..
<GunnarHj> If I understand it correctly, currently a bunch of IM frameworks can be used in Ubuntu. Will MIR restrict the current possibility to choose the framework of your choice?
<ogra_> why woudl it do that
<ogra_> it might restrict the UI capabilities in the beginning ... but surely not the framework
<GunnarHj> Ok.
<GunnarHj> Is any of the frameworks good enough for all the IM dependent languages?
<happyaron> GunnarHj: almostly, ibus/fcitx can fit for current situations
<happyaron> csslayer: hi
<happyaron> seb128 GunnarHj: csslayer is also upstream developer of fcitx (along with Yu)
<seb128> csslayer, hey
<seb128> happyaron, ok
<GunnarHj> Hi csslayer
<csslayer> seb128: happyaron GunnarHj: hi, I may leave for my lab meeting soon, I just login in and look around :) sorry
<seb128> csslayer, no problem, thanks for being around
<GunnarHj> So I take it that we can, if we want, disregard from all the other frameworks that currently is supported by e.g. im-config.
<seb128> csslayer, we are trying to figure out what are the main difference between ibus/fcitx
<seb128> and what we should review/consider while trying to pick one?
<csslayer> seb128: from the toolkit level there isn't much difference if you want to make a imf agnostic protocol for mir
<csslayer> seb128: and even the protocol is quite similiar
<csslayer> AFAIK ubuntu phone will go with maliit for now, so I think you might want to have some general protocol maybe ?
<seb128> on the mir/server side probably
<seb128> but there is also the question of configuration
<seb128> ui
<seb128> like what is our indicator speaking
<csslayer> that's not a problem of toolkit level, actually anyone can write any ui, there is no much difference between im and other application.
<bschaefer>  also this is a bug report that happened last time we forced IBus in 12.10 for unity: https://bugs.launchpad.net/nux/+bug/983254
<ubot5> Launchpad bug 983254 in Unity "Support input methods beside ibus" [High,Fix committed]
<csslayer> ah... sorry for my bad behavior one year ago
<bschaefer> csslayer, I was pointing out that we need to support more then 1 :)
<seb128> csslayer, what are the core difference between ibus and fcitx?
<seb128> like what would argument would give in favor of picking one instead of the other one?
<csslayer> seb128: the core difference, from my point of view (and I guess you guys might intereseted in) is the view on what should be handled by imf.
<seb128> csslayer, is fcitx handling keyboard layouts like ibus 1.5 is doing?
<csslayer> seb128: yes, that part is firstly introduced in fcitx 4.2.4
 * csslayer is checking the release date of 4.2.4
<csslayer> Jun 3 2012
<csslayer> ok let me continue my "differnce part"..
<csslayer> ibus make everything a engine, each time, every user can only use one engine.
<csslayer> fcitx also have the concept of engine, but it admits that there are some function doesn't belong to any engine.
<csslayer> for example: https://www.csslayer.info/wordpress/fcitx-dev/unicode-input-support/ something like this is obviously specific to chinese, english or any other languages.
<csslayer> and for configuration part you just talked about, fcitx also make it doesn't bind to any toolkit, but just use some file to describe the configuration.
<csslayer> and those file can be easily exploited by ui.
<csslayer> though we admits the nature that there are some complex one cannot be handled by this way, so some custom configuration ui part is also introduced in fcitx 4.2.7.
<racarr> Morning
<racarr> Got key events working all the way through a QML app over the weekend!
<alan_g> hello racarr
<racarr> Hi alan :)
<smspillaz> morning racarr !
<alan_g> racarr: that sounds good. Spike or production ready code?
<smspillaz> racarr: nice work!
<racarr> alan_g: 90% production ready
<lool> 10mn left in meeting
<seb128> csslayer, ok ... do you have any data of the number of languages/methods supported by fcitx?
<racarr> alan_g: I accumulated a few todos in the process (i.e. go back and move this class, improve this test, etc...)
<racarr> alan_g: Also, it only works with ANDROID_TYPES on
<racarr> otherwise the android::Looper used by the InputDispather
<alan_g> racarr: anything I can help with?
<racarr> never dispatches the input ready callbacks
<racarr> so it can't read the finished signals from the client
<alan_g> Hmm, I guess that is my attempted rewrite at fault.
<racarr> :) I will spend some time debugging it today though, unless you have any ideas to start
<happyaron> seb128: let me make up a list for you
<csslayer> seb128: we nearly covered everything that ibus/scim supports. (when I say "nearly" I mean I don't really know if there is some not exists in pop distro's repo)
<seb128> happyaron, thanks
<alan_g> racarr: Nothing specific - was always a risk reworking without proper tests in place
<happyaron> csslayer: actually everything in debian/ubuntu, all of them (including ibus/scim) are handled by me.
<seb128> csslayer, does that include things like cyrillic/russian?
<alan_g> racarr: I'm happy to look, but would like another hour or two first
<racarr> alan_g: Ok no hurry. I don't think I am goign to get to propose it this morning anyway
<racarr> the one thing that will take a little time, is the acceptance test doesn't yet consistently pass
<racarr> because it needs some interprocess synchronization
<alan_g> racarr: In that case, drop me some notes at your EOD and I'll look at it when I start tomorrow
<racarr> so I have to readd that IPCWaitCondition type thing I was doing a whil ago, etc
<csslayer> seb128: if you take layout part in, then yes, and fcitx's layout is not just layout, such kinds of function can also work for other language https://fcitx-im.org/wiki/File:Fcitx-Keyboard.png if correct dictionary is installed.
<racarr> alan_g: Perfect. :)
<csslayer> seb128: I'm not very sure if m17n (fcitx has m17n-lib support) also covers that part, since we also blacklist most of m17n engine since they are deprecated by layout.
 * alan_g glad he kept the ANDROID_TYPES option for this eventuality
<racarr> :) Yes
<happyaron> seb128: http://paste.ubuntu.com/5646507/ this list may not cover all fcitx supports, but should enough to give an impression.
<seb128> happyaron, thanks
<csslayer> happyaron: keyboard layout is a larger list .. though :)
<happyaron> csslayer: yes, :)
<happyaron> keyboard layouts aren't included there
<GunnarHj> happyaron: Are you aware of any languages that are not sufficiently supported by the fcitx engines?
<happyaron> GunnarHj: not yet so far, if they are already supported by ibus/scim.
<GunnarHj> Ok, thanks.
<happyaron> GunnarHj: but there's room for improvements in detailed user experience, we don't use them day to day and that needs user's feedback.
<seb128> tvoss, ^ happyaron and csslayer_ are also good people to ping if you have questions
<tvoss> seb128, yup, just reading the channel :)
<seb128> tvoss, happyaron (co)maintains fcitx (and ibus) in Debian/Ubuntu, csslayer_ is one of fcitx upstreams
<tvoss> seb128, thank you :) hey happyaron and csslayer_ :)
<seb128> yw ;-)
<happyaron> tvoss: hey, :)
<csslayer_> also thank you guys, it's my pleasure :)
<csslayer_> just  found my boss isn't here today... is the hangout ended?..
<tvoss> csslayer_, yup :)
<csslayer_> tvoss: ok then :) sorry.
<csslayer_> also welcome to #fcitx channel if you guys have further questions about fcitx
<tvoss> csslayer_, great, thank you
<Rafal_S57> Hi, quick question. How much will the Mir composer be able to re-use from an existing GPU specific Android hwc implementation? Will there be a lot of work for the GPU manufacturer to ensure that their composition GPU is utilised currectly by Mir?
<seb128> csslayer_, happyaron: tvoss updated https://blueprints.launchpad.net/ubuntu/+spec/client-input-methods with the summary of the discussions/things we need to investigate
<happyaron> seb128 tvoss thanks!
<tvoss> happyaron, yw
<alan_g> Rafal_S57: in theory mir should work with existing android implementations. But the mir code isn't yet mature enough to expect this in practice.
<tvoss> Rafal_S57, you might want to ping kdub with that question, he is working on using the hwc interface
<tvoss> kdub, you there yet?
<kdub> morning folks, status, working on that scripting branch, proposed a new type of android display, working on some hwc classes today
<alan_g> kdub: what's happening with arm/glog? I'm not what's up with this build. But it looks like it is getting glog while failing to get gflags (which glog needs). Can you spot the problem? https://jenkins.qa.ubuntu.com/job/mir-android-raring-i386-build/117/console
<tvoss> kdub, did you see Rafal_S57's question about the hwc?
<kdub> alan_g, my plan is for consolidate-crossbuild-scripts to kill ~kdub/mir/ndk-rewrite and to have your glog branch stack on top of it nicely
<Rafal_S57> thanks, I'll ping kdub specifically with my questions - Hi kdub
<kdub> Rafal_S57, yep, i'm working on that today... we do gles composition without hwc at the moment, but we should have hwc/gles composition soon
<alan_g> kdub: I'll wait patiently then. ;)
<kdub> alan_g, hopefully not too patiently :) i'll focus on that branch starting now before i hop to the hwc work for today
<Rafal_S57> kdub: so in theory, the composition GPU manufacturer will not have to do anything to support Mir, as long as they have Android hwc implemented correctly? (in time, when Mir is matured)
<kdub> Rafal_S57, yep
<Rafal_S57> kdub: ok, sounds good. Do you expect any kind of interaction with the composition GPU manufacturers, or can they "ignore" the Mir work and focus on Android support?
<racarr> [ RUN      ] BespokeDisplayServerTestFixture.clients_receive_input
<racarr> [       OK ] BespokeDisplayServerTestFixture.clients_receive_input (210 ms)
<racarr> Wheeeee
<tvoss> racarr, \o/
<kdub> Rafal_S57, can't say what they'll do, but if they ignore us, it won't hurt us
<tvoss> Rafal_S57, we are certainly happy for any kind of interaction with GPU manufacturers, however, vanilla HWC support is fine with us :)
<racarr> tvoss: I can make you a video later today :) ... atm my phone is broken and my DSLR is in a room covered in wet paint
<tvoss> racarr, \o/
<tvoss> racarr, what color?
<Rafal_S57> kdub, tvoss: I'm currently scoping a support task for a composition GPU manufacturer, as they've asked us to look into what will be required to support Mir. From what you're saying, it seems to me that there is no "must have" support work to be done. Any idea of what kind of "nice-to-have" interaction you'd like?
<racarr> tvoss: Just a boring grey...we painted the concrete floor on our whole back room :)
<racarr> it was ...a boring chipping dirty grey before
<kgunn> racarr: good stuff!!
<kgunn> racarr: the input work...but the grey paint is cool too :)
<kdub> Rafal_S57, i'll have to think about it... as far as api support, we're pretty happy with the android hal
<kgunn> Rafal_S57: my 2 cents...i concur with kdub
<kgunn> Rafal_S57: as long as you've got gles compliance, we should work
<kgunn> Rafal_S57: any "goodness" from overlay or "special sauce" should be hidden under hwc
<kgunn> Rafal_S57: so we plan to work on those interfaces as well
<racarr> :) thanks
<kgunn> Rafal_S57: sort of supposing, if you're a gpu ip guy....you've got EGL_image_external (since android sort of mandates it)
<kgunn> Rafal_S57: do you have some gles vendor extensions in mind ?
<Rafal_S57> kgunn: there are some GPU specific optimizations, but they are already hidden inside the hwc. I have to run now (gotta pick up kids) but will join tomorrow. Thanks to all for the answers so far!
<jono> boom: http://www.phoronix.com/scan.php?page=news_item&px=MTMzNDk
<racarr> jono: http://lists.freedesktop.org/archives/wayland-devel/2013-March/008131.html
<racarr> jono: Seems familiar ;)
<jono> indeed
<jono> can we bring him into Mir to help?
<ogra_> unlikely
<ogra_> he seems to be very wayland focused
<racarr> It's more than that the goals are very different
<racarr> "- A project to learn about compositors and think about new compositing concepts
<racarr> - A place for the community to openly discuss and contribute to the project
<ogra_> he actually wants to work on wayland ...
<racarr> - A place to create new and exciting desktop effects
<racarr> - An environment that encourages learning about the Linux Desktop,
<racarr> programming and wayland/northfield.
<racarr> - An environment that is less restrictive and encourages uninhibited
<racarr> i.e.
<racarr> free-flow thinking
<racarr> - A project that aims to get as many compiz effects as possible,
<racarr> not requirements driven
<racarr> working in a wayland compositor"
<ogra_> yeah
<racarr> which is kind of the opposite of what mir is doing.
<jono> makes sense
<alan_g> jono: I don't think he's a good fit
<ninjaaron> So I asked last night, but I had to go before I saw an answer: is Mir going to use libxkbcommon for keyboard input?
<racarr> ninjaaron: It's not entirely clear :)
<racarr> the bits that would be useful to us
<racarr> are largely the keymap and key character mapping
<racarr> currently we are using the android keymapper.
<tvoss> racarr, it used to be the plan :) ninjaaron, any specific reason why you are asking?
<racarr> tvoss: Yes I was ust getting ready to say
<racarr> it seems likely it will end up that way though :)
<tvoss> racarr, sorry :)
<racarr> an issue we will visit soon once the basics for keyboard input land
<racarr> tvoss: Hehe no problem.
<racarr> alan_g: At this point now that we have some stuff under an end to end test do you think it makes sense to start refactoring some interfaces in droid-input, etc...
<racarr> alan_g: i.e. it would be useful for testing if droidinput::InputChannel were mockable
<racarr> p.s. have some time to look at the looper thing?
<alan_g> racarr: assuming that it doesn't conflict with killing USE_ANDROID_TYPES
<alan_g> racarr: About half an hour - unless I get interrupted
<alan_g> (which I sort of expect tvoss to do sometime)
<racarr> ;) ok
<tvoss> alan_g, please clarify :)
<alan_g> tvoss: <tvoss> "yup, ....before pulling you onto the hangout"
<alan_g> racarr: so, can I try to help? Or shall I look in the (UK) morning?
<racarr> alan_g: well hmm it would be useful if you have time
<racarr> I am not sure that the answer isn't just to use the android implementation here
<racarr> which just uses epoll which seems like a more clear way to express what this is trying to do
<racarr> than using async_read from boost::asio
<racarr> alan_g: The problem as it presents, is the usage of looper by InputDispatcher (see around InputDispatcher.cpp l3132)
<racarr> handleReceiveCallback never fires
<racarr> that's as far as I have gotten :) because it works with the android types
<alan_g> racarr: which executable are you using?
<racarr> alan_g: acceptance-tests
<racarr> is that true
<racarr> no thats not
<racarr> the actual server binary :)
<alan_g> lp:~robertcarr/mir/send-clients-input?
<racarr> alan_g: No. that one landed just a sec.
<racarr> alan_g: lp:~robertcarr/mir/receive-input-in-client
<racarr> checking for missing files
<racarr> how surprising there were missing files ;) pushed a second time
<ninjaaron> tvoss: re: libxkbcommon: I'm a linguist, and I use a lot of custom keymaps, so I have a lot invested in xkb.
<ninjaaron> it would be nice not to have to do it over.
<tvoss> ninjaaron, sure :) I'm close to eod'ing. Would you mind if I ping you tomorrow ~13.00 UTC?
<ninjaaron> It's a date.
<tvoss> cool
<racarr> err...pushed for actual now
<racarr> I have the most problems with my ssh agent :/
<alan_g> racarr: It is building.... But I don't think I can do anything much before EOD
<racarr> alan_g: No worries :)
<alan_g> racarr: Oops: ...display_server/receive-input-in-client/examples/eglapp.c:88:49: error: unused parameter âsurfaceâ [-Werror=unused-parameter]
<racarr> it's not really blocking me
<racarr> alan_g: Yeah I just pushed another revision XD
<racarr> I committed an inprogress revision to push for you
<racarr> made the egl app demos quit when you hit q :)
<alan_g> racarr: I'll pick up in the morning - you can get things tidy first. (and tell me exactly what you run/expect in an email)
<racarr> alan_g: great thanks!
<racarr> Almost done with self review and cleanup for receive-input-in-clients. Lunch break now though!
<racarr> kdub: Shwarma at a picnic table on a grey windy day reminded me of copenhagen :)
<racarr> remember "the mathematical proof of the display server"?
<kgunn> racarr: i'm curious...."the mathematical proof of the display server"?
<kdub> racarr, hah
<racarr> kdub: Haha, it was just...on the train back to the hotel one night, we were talking...I don't remember exactly how it went, but just about how we expected
<racarr> things to roll out over the next few months
<racarr> and you were like "And after that is when we finish the mathematical proof of the display server"
<racarr> and I found it very funny at the time :)
<racarr> because I was almost thinking about that somehow aha
<kdub> racarr, yeah, might have just been the boston public transport
<racarr> really!
<racarr> ...maybe
<kdub> but we were relating how  if we were developing aerospace software, we'd have to submit a proof with our changes
<racarr> aha...yes!
<racarr> Everytime we drop a frame a plane drops from the sky :(
<racarr> though who knows I read an article about software at spacex
<racarr> and they talked about how "They don't have hard real-time requirements"
<racarr> oO
<kgunn> racarr: kdub  :))
<racarr> kgunn: Previous mir sprints involved much more getting stuck on street corners in the suburbs of boston and late nights in copenhagen
<racarr> than the relatively tame london sprint ;)
<kdub> except  for me... :/
<racarr> Mm :(
<racarr> expanded the client input acceptance test so it reproduces the failure with USE_ANDROID_TYPES=false seen in the server binary
<racarr> trying to fix it now.
<Rafal_S57> hi kgunn, do you have a minute to finish our discussion of hwc support in Mir and GPU vendor interaction?
<kgunn> Rafal_S57: busy now sorry
<Rafal_S57> kgunn: ok, np
<racarr> intermittent test failure in input acceptance test :( race with the server shutting down before the client handles all the events. difficult to solve without a timeout so going to use an unnamed IPC semaphore.
<kdub> racarr, in which branch?
<kgunn> Rafal_S57: i'll be on tomorrow morning US central time...just ping
<racarr> kdub: ~robertcarr/mir/receive-input-in-client
<racarr> not proposed yet :)
<racarr> it turns out there are at least two races...
<racarr> im currently waiting on the tea kettle, and then going to attempt to deconstruct it carefully
<racarr> kdub: If you are curious ;) the test is the single acceptance test in acceptance-tests/test_client_input.cpp
<racarr> -.- I got it to always pass but now its sometimes long running
<racarr> XD
<racarr> oh...it was a race between resetting the wait condition and the other thread posting it again XD...b ecause I didn't make reset_and_wait
<racarr> atomic
<racarr> wait_and_reset ;)
<racarr> https://code.launchpad.net/~robertcarr/mir/receive-input-in-client/+merge/155368 wheeeee
<racarr> RAOF: ping?
<RAOF> racarr: Pong.
<racarr> RAOF: Wondering what we need to do to land the mesa changes
<racarr> things are broken in trunk atm for clients that use mir_connection_get_egl_display (rather than cast MirConnection directly)
<RAOF> Ah, so. Last time I tried to build your mesa changes, they didn't work, so I didn't merge them.
<RAOF> racarr: Could you point me to the current mesa changes that you expect to work? I'll test and then merge them :)
<racarr> RAOF: let me figure out how to use git
<RAOF> Urgh :)
<racarr> RAOF: http://paste.ubuntu.com/5647997/
<racarr> just format-patched from my working branch :)
<RAOF> And that should work with mir trunk?
<racarr> RAOF: It should! let me double check I am not branch confused
<racarr> there have been a lot of branches ;)
<racarr> RAOF: Yes
<RAOF> racarr: Sweet, thanks.
#ubuntu-mir 2013-03-26
<RAOF> racarr: Your mesa fails to build against trunk; but for an obvious reason that I'll just fix up.
<racarr> RAOF: thanks...sorry I have mild
<racarr> branches inside branches schizophrenia the last 2 weeks
<racarr> *motions to chalkboard filled with diagrams*
<racarr> It's all wheels inside wheels...ive seen it....*twitch*
<RAOF> racarr: Good, that (finally) works. Thanks!
 * RAOF has a pleasing, but somewhat banded, plasma flying across his display.
 * kdub noticed the bandedness too
<RAOF> My guess is that it's not using a full 8-bit colour range, but whatever.
<racarr> RAOF: If you merge receive-input-in-client you can quit the plasma with the q key!
<racarr> its a revolution in user interaction
<racarr> ;)
<racarr> thanks for testing and fixing :)
<RAOF> Should land in the PPA next time jenkins scans the branches.
<RAOF> racarr: Got any idea how you'll handle keymaps? :)
<RAOF> racarr: Do we have to poll() every 10ms for input?
 * duflu hopes that's a joke
 * duflu afk
<racarr> RAOF: No there should be a comment there...
<racarr> maybe I didn't push everything yet
<racarr> there just needs to be a way to interrupt it so we can use a longer poll time without making shutdown slow (or the test times become huge)
<racarr> i.e. a wake fd
<racarr> it might that a droidinput::Looper should be used but
<racarr> need to sync up with Alan on that in the morning...
<RAOF> If you expected there to be a comment about the poll(), then you haven't pushed everything :)
<racarr> RAOF: As for keymaps, currently it is using the android keymap files+format
<racarr> though only Generic is available :)
<racarr> I think we will replace it
<racarr> with libxkb
<racarr> its pretty well abstracted, in that its just part of the InputReaderPolicy
<racarr> pushed more changes :) but probably just containing that comment that I just explained
<robert_ancell> RAOF, I'm thinking that that Mir on X wont be ready by 13.05. Does that sounds right to you (you have a bp item though eleni is working on it right?)?
<RAOF> robert_ancell: Correct, eleni is working on it.
<RAOF> I think it could be ready for 13.05 if it's a priority.
<robert_ancell> RAOF, I'll reassign the item then
<robert_ancell> It's a very nice to have, but not essential
<robert_ancell> RAOF, there are two items right, SDL on Mir then X on SDL on Mir right?
<RAOF> No, just Mir on SDL.
 * robert_ancell gets confused with order
<robert_ancell> yep, that sounds more like it
<robert_ancell> RAOF, so we already have SDL on X, so mir on sdl = mir on X?
<RAOF> Correct.
<robert_ancell> and that was easier than mir on X?
<RAOF> Eleni's just using SDL as the toolkit for Mir-on-X
<duflu> It should be equally easy to make Mir on native X after that. The boiler-plate for an X Window and GLX setup isn't that big.
<duflu> smspillaz: Bored with uni already?
<tvoss> RAOF, ping
<RAOF> tvoss: Yo!
<tvoss> RAOF, ninjaaron asked about libxkb yesterday, too. Will ping him today, he seemed to know a lot about it
<tvoss> RAOF, perhaps we can get some help
<RAOF> tvoss: I presume everyone's referring to libxkbcommon?
<RAOF> Which we should totally use.
<tvoss> RAOF, yup :) libxkbcommon it is
 * tvoss is too lazy to type common, no tab completion :)
<RAOF> Grr, GMock.
<tvoss> RAOF, what did you do? can I help? :)
<RAOF> Verifying that a destructor is called is unnecessarily annoying.
<RAOF> Or: verifying that a destructor is called in a couple of tests, and not caring in most of them, is unnecessarily annoying.
<tvoss> RAOF, okay
<tvoss> RAOF, an existing test?
<RAOF> tvoss: Cleaning up in https://code.launchpad.net/~raof/mir/buffer-age-misc-cleanups/+merge/155164
<tvoss> RAOF, looking
<duflu> Hmm, I hope we don't end up with XKB (extension) semantics in using libxbkcommon. That was a major problem for Compiz and not something I'd like to see happen in Mir
<tvoss> duflu, the general idea is that we reuse the existing keymapping solution without pulling in all of the atom handling
<RAOF> duflu: I don't believe it mandates xkb
 * RAOF -> baby
<duflu> tvoss: Twas only the grab behaviour that was wrong I think. And we're trying to avoid that right now AFAIK
<tvoss> duflu, yup
 * duflu wonders how many times the words "Android" and "#include <X11/" need to appear in the Mir source before it's "too much"
<duflu> tvoss: Can you point me to the design principle/reasoning/rationale for separating the protobuf from protobuf.wire?
<duflu> or /pattern
<tvoss> duflu, not sure what you mean?
<duflu> tvoss: There are two layers of protocol. There must be a good reason why it's done that way
<tvoss> duflu, from what I see on trunk, the wire protocol deals with the actual rpc, while the protobuf definition defines the actual types and services that we expose
<RAOF> duflu: AFAIK "#include <X11/" is nowhere in the Mir source?
<duflu> tvoss: Yeah I can see that. But I don't yet understand why we need to abstract an abstraction (wrap protobuf in protobuf). I need to understand more of the "why"
<duflu> RAOF: Not yet, but potentially when we use libxkbcommon :)
<duflu> -need + want
<tvoss> duflu, can you check with alan_g please? I remember there was a reason ... but I'm otp right now :)
<duflu> Kay
<RAOF> duflu: There's no X11/ in libxkbcommon :)
<duflu> Whee, small win
 * duflu thinks this looks like a hack: /usr/include/xkbcommon/xkbcommon.h
<duflu> One designed for Weston?
<tvoss> duflu, hack in what respect?
<duflu> tvoss: The name "xkb..." and yet it has no dependency on *XKB* stuff under X11/. Seems a bit backwards. Thought that could be resolved simply with better naming
<tvoss> duflu, that's a good point actually. While reading through the library I though about a name along the lines of libkeymap :)
<RAOF> Wooo!
<RAOF> I win the âwork around annoying bits of gmockâ award.
<tvoss> RAOF, \o/
<duflu> Argh. I hate it when Europe wakes up. No offence :)
<smspillaz> RAOF: the re-entrancy rule strikes again ?
<kdub> morning
<tvoss> kdub, good morning :)
<UbuPhillup> hi
<kgunn> kdub: ping
<racarr_> Morning
<tvoss> racarr_, good morning :)
<kdub> kgunn, pong
<alan_g> racarr_: Morning. Looking into the Looper thing. Is definitely a difference in behaviour, not worked out why yet.
<racarr_> alan_g: Thanks :)
<racarr_> I am wondering, how it was supposed to work as it stands, as it seems like the deadline timer is unused?
<racarr_> (Wondering if there is some bit of boost asio I do not understand)
<alan_g> racarr_: is all asio magic to me - tvoss seems to understand (or have a bit more experience of) this stuff
<tvoss> alan_g, racarr_ can you point me to the bit that is not working?
<alan_g> tvoss: the bit racarr_ is referring to is Looper::pollOnce(int timeoutMillis) with timeoutMillis > 0
<racarr_> tvoss: It works with the android::Looper implementation but not with our boost::asio based implementation :)
<racarr_> it's all described in here https://code.launchpad.net/~robertcarr/mir/receive-input-in-client/+merge/155368
<racarr_> "Currently this is failing to work with MIR_INPUT_USE_ANDROID_TYPES=false ...."
<tvoss> alan_g, racarr_ looking ...
<racarr_> three items I could take up
<tvoss> racarr_, on the Looper issue
<racarr_> 1. SW cursor (seems hard to land)/pointer input 2. Back to inprocess EGL 3. Clean up qtubuntu mir branch
<racarr_> tvoss: Oh?!
<tvoss> racarr_, at your items: I would focus on inprocess EGL
<racarr_> Ok. makes sense
<racarr_> actually depending on how it is structured that might all live in Qt ubuntu now that prepare-for-inprocess-egl has landed
<tvoss> racarr_, what's the magic cmake option to enable compiling the Looper relying on boost?
<racarr_> tvoss: MIR_INPUT_USE_ANDROID_TYPES=false
<racarr_> which is the default
<racarr_> should use the looper coming from 3rd-party/android-deps/bla/bla (with the boost implementation in header file)
<tvoss> racarr_, ack
 * alf_ is starting to get really tired of gcc ICEs
<racarr_> alf_: I know what you mean...
<tvoss> racarr_, can you give http://pastebin.ubuntu.com/5649723/
<tvoss> a spin?
<racarr_> alf_: At some point last week I wrote like 900 lines of new code...then -> ICE....I wanted to cry!
<racarr_> alf_: SOme bug report implied it may be fixed upstream I am thinking of building my own G++
<racarr_> tvoss: Trying :)
<tvoss> racarr_, cool
<racarr_> tvoss: alan_g: It's strange...changes to Looper.h wont actually trigger
<alf_> racarr_: my current methodology is to build with clang, so I can get an idea of what the problem is
<racarr_> recompile of android-input
<racarr_> always have to make clean
<racarr_> alf_: Ah...that's a better idea than crying
<alf_> racarr_: :)
<alan_g> racarr_: that's because CMake's dependency tracing doesn't track #include MACRO
<racarr_> tvoss: Still the same.
<racarr_> alan_g: ah....
<alan_g> Just delete a few files in 3rd_party/...
<tvoss> racarr_, then I need to look a bit deeper
<racarr_> tvoss: googling around people kind of implied
<racarr_> the only way to do this with asio is in the timer callback
<racarr_> you have to cancel the work.
<racarr_> then there is going about resetting the io service and
<racarr_> readding the async_read...and I dunno
<racarr_> not sure asio is the right fit here
<racarr_> tvoss: A thought..."woken" needs to be reset right
<racarr_> i.e. around l585 if (woken.load())
<alan_g> racarr_: it doesn't seem at all easy. Am proposing a fix branch
<kdub> alf_, could you give another look? https://code.launchpad.net/~mir-team/mir/consolidate-crossbuild-scripts/+merge/154762
<racarr_> it doesn't help though
<alf_> kdub: sure
<racarr_> alan_g: Yeah...it's really complex to how it should be :/
<racarr_> I think run_one should take a timeout ;)
<alan_g> racarr_: Agreed
<alan_g> racarr_: https://code.launchpad.net/~alan-griffiths/mir/receive-input-in-client-patch/+merge/155549
<alf_> kdub: @l.78, the line is not wrapped. Other than that looks good.
<racarr_> alan_g: It looks like there is some confusion in this branch? extra changes etc
<alan_g> Bugger - that has some trunc changes tpp
<alan_g> Bugger - that has some trunc changes too
<racarr_> :)
<kdub> alf_, sorry, got lost in some merges... fixed now
<alf_> kdub: also, is lp:~kdub/mir/ndk-rewrite the best place to get information from for creating a chroot, or is lp:mir enough now?
<kdub> alf_, after that branch, just lp:mir
<kdub> i'll delete that branch, and send out a mail on the mailing list
<alf_> kdub: so, we should update at l.65 ?
<kdub> alf_, yes :/ i corrected that, but that got lost in my merge mixup too
<kdub> fixed
<alan_g> racarr_: I hope that fixes it
<alan_g> (At least it looks like I intended)
<racarr_> alan_g: Oh good idea at line 310
<racarr_> (test name change)
<alan_g> racarr_: np
<alf_> kdub: thanks, approved
<racarr_> testing now
<racarr_> alan_g: All works
<racarr_> going to merge your branch in to mine and push
<racarr_> alan_g: tvoss: Thanks both :)
<racarr_> I wonder if the InputReceiverThread on the client side should be/use an android::Looper
<alan_g> racarr_: hopefully we'll soon be confident to delete the ANDROID_TYPES=on option (and the code to support it)
<racarr_> Mm
<racarr_> Currently it is using a little mini select loop but it needs optimization (diff l598)
<racarr_> *really happy to finally being close to landing an end to end test for input*
<racarr_> it's easy to move fast there now :)
<tvoss> racarr_, yup, great work :)
<racarr_> aww merge conflicts
<racarr_> tvoss: Oh while you are around i wanted to ask you...was trying to find a good input demo
<racarr_> but nothing qwidget based works on qtubuntu for me
<racarr_> expected/known?
<racarr_> (Not many QML demos that work with no cursor ;))
<tvoss> racarr_, mostly known I would say. I would think that the qml examples should work, though
<racarr_> at least precanned ones in /opt/qt5/examples
<racarr_> yeah
<racarr_> there is just only one that will accept keyboard input before mouse input
<racarr_> and it makes a pretty lame video XD (qtdeclarative/quick/keynavigation)
<tvoss> racarr_, ack, @cursor: is there a way to get a cursor rendering easily? IIRC you can provide the InputReader with a cursor handler
<racarr_> tvoss: We have a cursor handler in trunk
<tvoss> racarr_, is that one actually rendering?
<racarr_> and InputManager takes a CursorListener object, which would be the place to put a renderer
<racarr_> but the CursorListener is null atm
<racarr_> not sure how to render it
<racarr_> at least in a way that will land :)
<tvoss> racarr_, yeah, so let's postpone a cool video until we have a way to expose the hw cursor, if that's fine with you
<racarr_> Yeah :)
<racarr_> I amw ondering if I should try and work on that now...I dunno its probably not that difficult I just can't figure out the interfaces in mir...
<racarr_> the thing is the cursor listener shouldn't speak directly to the compositor or if it does
<racarr_> that's a pretty big change!
<racarr_> because it makes lines that cross surface stack where there were none
<tvoss> racarr_, hw cursor support is more likely to end up somehwere in graphics
<racarr_> but surface stack isn't really prepared to
<racarr_> represent a cursor
<tvoss> racarr_, yup
<tvoss> racarr_, so focus on in_process_egl
<racarr_> ok
<racarr_> tvoss: The way I was handling that in the iteration-1 branch was
<racarr_> using almost unmodified qtubuntu backend, and ubuntu_platform_api backed by libmirserver
<racarr_> does that still make sense? I am not sure exactly what the status of ubuntu_* API is
<racarr_> I have this thought that we don't really need "qmir" just qtubuntu, a nd ubuntu-application-api-mirclient and ubuntu-application-api-mirserver
<tvoss> racarr_, that's a difficult one. Need to give it some thought
<racarr_> tvoss: ok
<racarr_> tvoss: It's a convenient way to proceed ;) that ends with little code duplication
<racarr_> but I am not entirely sure it makes sense
<racarr_> i.e. why is the launcher an indirect consumer of ubuntu-application-api
<racarr_> seems weird.
<racarr_> ill delay it a day and at least get the inserver EGL display and a demo inprocess app proposed today :)
<tvoss> racarr, that sounds like a good idea :)
<alf_> status: working on compositing-on-demand, reviewing, fighting with gcc ICEs
<racarr> it's a shame too that its not easy to downgrade to 4.6 now because of the override use (which I quite like actually)
<racarr> its just like it's some sort of cruel joke being played on us XD
<racarr> hmm issues with the new test_client_mir_surface tests when merging trunk in to receive-input
<alf_> racarr: alan_g: Do we need SurfaceStack::raise_to_top()? No one is using it, and it has memory problems (it uses a potentially invalidated iterator).
<alan_g> alf_: dead code? Delete it!
<racarr> alf_: Apparently not!
<racarr> I think it was used in an early version of sessions/ in copenhagen ;)
<racarr> then we decided restacking the surfaces was silly when all we need is visibility
<alf_> racarr: alan_g: preparing an MP
<racarr> obviously we will need something like it one day. but lets just drop it and
<racarr> readd it working correctly when we do :)
<racarr> hmm
<racarr> where does the server MesaNativeDisplay implementation go :)
<racarr> mir::graphics::EGL::?
<kgunn> racarr: ping
<kgunn> alf_: hey, can you change https://blueprints.launchpad.net/ubuntu/+spec/client-1303-mir-glmark2 to have the drafter set to mir-team ?
<racarr> kgunn: Pongalong!
<racarr> I think I need to make
<racarr> mir::DisplayServer mockable but its not clear what the interface is
<racarr> the EGLNativeDisplay constructor (well or more likely factory function)
<racarr> wants to take mir::DisplayServer I think
<racarr> becuase the thing is, think of the code paths in unity. Unity starts up, initializes a server configuration, and then calls off to mir::run_mir(Configuration)
<racarr> at which point control goes to Mir
<racarr> but unity needs a time to start, threads
<racarr> and get some reference to the display server instance (after it is prepared)
<racarr> so I think we need some callback, the display server instance invokes inbetween starting and entering the main loop
<racarr> to give unity a time to say, start a thread which creates a surface and starts rendering.
<racarr> even simpler just imagine we are talking about a simple EGL demo app instead of unity. What does it need? It needs the display to get the platform package to initialize the egl context, and it needs a surface controller
<racarr> to create a surface.
<racarr> so it seems like maybe mir::DisplayServer should provide these
<racarr> through a...<NAME GOES HERE> interface
<racarr> first thought is mir::ServerInstance but actually this interface
<racarr> doesn't need start/stop like mir::DisplayServer does (and you would guess a ServerInstance would)
<racarr> so maybe it's more like mir::ServerComponents is the interface with (.shell_surface_controller(), .display(), etc...)
<racarr> and mir::DisplayServer implements
<racarr> or maybe mir::ServerInstance is the concrete implementation containing start/stop and the .display(), etc...
<racarr> and mir::DisplayServer becomes the interface with just
<racarr> the component access
<racarr> I think that makes sense. a mir::DisplayServer has a bunch of components that make up the interface mir::* exposes to the shell. a server instance is a display server with API for execution
<racarr> *shrug*
<racarr> Sorry sounds kind of pedantic but I think it's important to think about this interface because we need to make sure Unity and Mir are cleanly mockable from eachother.
<kgunn> kdub: quick one i think
<kgunn> what exactly did "display integration" mean ?...i mean  you already go hwc vsync working for nexus4 (not nec'lly landed...but)
<racarr> Lunch!
<kdub> kgunn, making sure that all the pieces fit together (integration test)
<kgunn> kdub: thanks...it was marked as todo...but i suppose that will hinge on some mp's to say done...
<kgunn> robert_ancell: would you mind making mir-team drafter on https://blueprints.launchpad.net/ubuntu/+spec/client-1303-mir-nexus4
<robert_ancell> kgunn, done
<kgunn> thank you!
#ubuntu-mir 2013-03-27
<racarr> namespace mgeglm = mir::graphics::egl::mesa?
<racarr> I just wanted to share how happy I was to type mgeglm
<RAOF> ???
<racarr> RAOF: I just think it's a funny combination of letters
<racarr> ignore me...
<RAOF> No, that just seems like a surprisingly nested namespace.
<smspillaz> racarr: hmm, this could get fun
<RAOF> smspillaz: What are you up to? :)
<smspillaz> namespace compiz::objects::central::keyboard
<racarr> I don't get it ;)
<RAOF> :P
<smspillaz> RAOF: me? mostly eating popcorn
<duflu> robert_ancell: We have logs if you're interested :)  https://bugs.launchpad.net/mir/+bug/1109957
<ubot5> Launchpad bug 1109957 in Mir "lightdm with type=mir causes raring to freeze on boot. plymouth stuck at 100% progress." [Critical,New]
<robert_ancell> duflu, ta
<duflu> Wow, seems Alexandros likes to finish things without any fanfare. This is now DONE(!): https://blueprints.launchpad.net/ubuntu/+spec/client-1303-mir-glmark2
<duflu> Except that we can't get any useful numbers out of it till we fix Mir's eglSwapInterval(0)
<robert_ancell> duflu, can you look out for a notification for "TEST BUG" against Mir?
<duflu> robert_ancell: Could you please update the subscription to ensure mir-team gets bug comments too?
<robert_ancell> duflu, did that before this
<robert_ancell> comments?
<robert_ancell> I think people should opt-in for comments
<duflu> robert_ancell: I disagree. Someone has to answer comments. And if the dev team has not subscribed then that will usually be no one
<robert_ancell> no, that's just spamming people. If you want to do that then subscribe yourself. Otherwise people should only subscribe to bugs that are relevant to them
<duflu> robert_ancell: Umm, Mir bugs are relevant to Mir developers. More generally developers need a kick in the pants to pay more attention to their own bugs
<robert_ancell> duflu, you are automatically subscribed to your own bugs, and you can subscribe people to bugs you think they should look at
<duflu> robert_ancell: "own bugs" means bugs you caused, not logged
<robert_ancell> duflu, then subscribe them when you read it
<robert_ancell> duflu, bugs can easily become a distraction from actual work - the goal is not to empty the bug tracker
<duflu> robert_ancell: True, but you can't release anything if you have a pile of High's and Criticals
<robert_ancell> you can
 * duflu is scared at that prospect
<robert_ancell> duflu, it depends who set them to high and critical - we have an open tracker
<duflu> robert_ancell: It's not meant to be a matter of opinion. There are clear definitions of the severities here: https://wiki.ubuntu.com/Bugs/Importance
<duflu> Though that's not to say those are followed accurately
<robert_ancell> duflu, bingo
<smspillaz> robert_ancell: I get the impression that this page is good for determining bug severity if you're a kernel
<smspillaz> it would be good to have bug guidelines per-project
<duflu> It's hard enough having one standard. I'm not sure we want multiple standards
<smspillaz> sure, its just that the examples are not very applicable to some projects
<smspillaz> "causes data corruption" <- let me know when that happens in a display server
<RAOF> We can *totally* do that.
<smspillaz> RAOF: was that a challenge accepted ?
<RAOF> We just need to set up the GPU memory maps appropriately :)
<smspillaz> RAOF: I think that's fudging with the definition of "data"
<duflu> Surely you can mmap some memory to an important file
<smspillaz> right, I just didn't think that fell within the usecase of a display server
<RAOF> Set the GPU memory maps appropriately so that they overlap with the kernel's VFS cache.
<smspillaz> RAOF: oh, heh
<duflu> Evil
<smspillaz> RAOF: does mir run as root ?
<RAOF> I don't think we know.
<smspillaz> (its a stupid question, I've not run it in months)
<smspillaz> haha
<smspillaz> yikes
<duflu> smspillaz: Not normally, but it can
<RAOF> The system-compositor probably will, but the sessions won't.
<smspillaz> you guys are going to have lots of fun
<RAOF> Of course!
<robert_ancell> duflu, you had a branch that was going to add a mircommon-dev right? What happened to that?
<duflu> robert_ancell: It landed. And I see it in the PPA already
<robert_ancell> duflu, oh right, I hadn't updated
<duflu> robert_ancell: Is it bad for lightdm that mir has no upstart config?
<robert_ancell> duflu, mir is started by lightdm so upstart is not involved
<duflu> robert_ancell: Fair enough. But there is often a small delay in the socket becoming available. Does lightdm sleep a little before looking for it?
<duflu> Or poll for it and eventually time out?
<robert_ancell> duflu, yeah, there's a hack currently but we will need the system compositor to notify lightdm when the socket is ready
<robert_ancell> poll
<duflu> Damn. No easy explanations
<duflu> You and your forethought
<robert_ancell> the way X does this is using a unix signal. We can easily pick that up, though it's a bit yuck. The cleaner way is to pass a fd to the compositor and have it write to it when ready
<duflu> robert_ancell: Signals sound might simpler. Why yuck?
<duflu> -might +much
<robert_ancell> duflu, because they're kind of hard to handle in the receiver. But we have all the work for X done so we can live with it
<robert_ancell> also potentially we want more information than a signal can provide
<duflu> I guess a signal necessitates knowing a process ID to send to :(
<robert_ancell> duflu, children can emit a signal on themselves and the parent picks it up
<RAOF> We want to pass an fd from lightdm to the system-compositor *anyway*; we might as well signal readiness on it.
<tvoss> RAOF, ping
<RAOF> tvoss: Pong.
<tvoss> RAOF, good afternoon :) quick question about hw cursors: do we have a work item for that?
<RAOF> Hm. I suspect that we might want a parallel server-side buffer age so we can optimise out sending buffers we know the client has.
<RAOF> tvoss: Heh. Yes, someone set alf_ as owning that work item today.
<RAOF> client-1303-mir-converged
<tvoss> RAOF, cool, we have the first iteration of input mostly landed, and rendering a cursor might prove helpful :)
<RAOF> We don't have keyboard input landed at all, right?
<tvoss> RAOF, an english keyboard should work :)
<tvoss> RAOF, ah, just observing your comments on receive-input-in-client
<RAOF> What about https://code.launchpad.net/~robertcarr/mir/receive-input-in-client/+merge/155368
<tvoss> RAOF, that's what I was referring to, I thought it had landed yesterday
<RAOF> :)
<tvoss> RAOF, anyway, once that lands, generic keyboard support is there. Then keymapping is the next topic
<RAOF> Cool.
<RAOF> daniels will be interested to hear where libkeymap fails to support our needs :)
<tvoss> RAOF, I guess not at all :) we just need to take a look at it
<tvoss> RAOF, got a link for me?
<RAOF> It's libxkbcommon :)
<tvoss> RAOF, I'm confused now :)
<RAOF> He was just complaining that he mis-named it, and it should really be called libkeymap.
<tvoss> RAOF, I guess I'm all in for that
<tvoss> mmrazik, I was wondering if there is any documentation on fence_cdu
<mmrazik> tvoss: do you have account on magners?
<tvoss> mmrazik, not sure :)
<mmrazik> tvoss: let me pastebin --help
<mmrazik> I don't think there is much more than that. Maybe something on wiki.canonical.com
<tvoss> mmrazik, ack
<mmrazik> tvoss: http://pastebin.ubuntu.com/5651494/
<mmrazik> tvoss: its a python script so I guess we can modify if need something
<tvoss> mmrazik, ack
<mmrazik> and I _think_ (didn't check) its using ssh to access the power strips
<tvoss> mmrazik, I was thinking about writing a google test fixture for setting up the multi-monitor setup
<RAOF> Huh. GTest really does call *0 = 1; to die in this case.
<RAOF> Grr. What the hell, gdb?
<tvoss> RAOF, what's up?
<RAOF> My changes to not leak fds in GBMClientBuffer have broken the acceptance-tests; a couple of them now segfault.
<RAOF> However, for some reason gdb doesn't seem to find DefaultDisplayServerTestFixture_client_library_accesses_and_advances_buffers::TestBody(), so I can't attach gdb at the right place.
<RAOF> Because obviously I need to be tracing the _child_, which means I need to set follow-fork-mode just before it forks.
<duflu> RAOF: gdb doesn't find it cos it's in a child process. You need to enable tracing into childten
<duflu> *children
<duflu> Yeah what you said
 * RAOF â ZoÃ« bath; back later to be annoyed at gdb further.
 * duflu reverts the day's work and starts again. Lost in class dependency spaghetti
<RAOF> Hah. Don't accidentally recurse infinitely.
<RAOF> Hm, no, that's not going to work. Looks like I really do need to make the server not uselessly send buffers the client already has.
<RAOF> kdub: Hey, you send fds for buffers out over the wire - how come android clients don't crash after not very long for exhausting their fd space?
<duflu> RAOF: I believe it's past 1am for kdub
<RAOF> Yeah, that would be right.
<RAOF> He's on in our *morning* :)
 * RAOF suspects the answer to his question is âif we had any non-trivial demo clients, they *would* crash after not very long by exhausting their fd spaceâ
<duflu> Heh
<duflu> In time
<duflu> Night all
<alf_> alan_g: @composite-on-demand, what do you think about on_change_call(...) instead of e.g. set_change_callback(...)
<alf_> alan_g: or on_changed_call()
<alan_g> alf_: this is actually a case where I tend like "set" - largely because it isn't otherwise clear that it overwrites any existing callback (as opposed to "add...")
<alan_g> alf_: but I think any of the above would be an improvement
<alf_> alan_g: ok
<alan_g> alf_: there's also "on_change_invoke()"
<smspillaz> install_change_callback () is another potential one I guess
<alf_> alan_g: smspillaz: I like how render_view.on_change_invoke(...) reads, but I will go with set_change_callback() since its semantics are clearer
<smspillaz> +1
<alf_> smspillaz: I think install_change_callback() suffers from the same problem (as discussed above)
<smspillaz> yeah I was thinking that too
<kgunn> alf_: are the gl bench #s being dumped somewhere to show a trend chart? or are they individually buried in jenkins test results?
<alf_> kgunn: I don't think there is a job for running glmark2 on mir, just on a traditional ubuntu system, but I don't know where the results end up.
<kdub> morning
<alan_g> Hello!
<kdub> status, working on integrating hwc device, hit a snag where (i think) the gpu clocks are not turned on all the way
<alan_g> status: got run_mir working properly, MP's a better MessageProcessorReport, and started wondering about glog again
<kdub> alan_g, yeah, waiting to clear that needs fixing on the scripts change :/
 * alan_g nags kdub 
<alf_> status: Amending composite-on-demand MP, started investigating mir shutdown regression (i.e. we don't return to a properly configured console sometimes)
<sturmflut> What is the status of the input subsystem? I read in the commit logs that input events are now passed down to the client, but how much of the whole system is implemented? Would it be possible to write a demo client which accepts keyboard/mouse events?
<smspillaz> sturmflut: ask racarr when he wakes up
<alan_g> sturmflut: we're getting closer - racarr is the one to ask
<sturmflut> smspillaz, alan_g: Okay
<smspillaz> racarr: wake up!
<sturmflut> haha
<smspillaz> he'll probably be around in 10 minutes :)
<smspillaz> sturmflut: if I end up moving to SFO later this year for a possible internship I'll make sure to knock on his door
<tvoss> sturmflut, once the last branch lands: yes, you could start writing a client. racarr actually planned something cool :)
<tvoss> sturmflut, but best talk to him
<sturmflut> I also noticed that my minimal client has to #include <mir/client/mir_toolkit/mir_client_library.h> but the /usr/include/mir/client/mir_toolkit/mir_client_library.h header file provided by the PPA packages tries to #include "mir_toolkit/c_types.h" which does not work. Is this because the Header files are still being shuffled around?
<tvoss> sturmflut, I'm pretty sure that is the reason, yes
<tvoss> alan_g, can you look into what sturmflut just mentioned?
<alan_g> sturmflut: I too am a bit confused about what's happening there. (It isn't what I expect.) Can you temporarily add [/usr/include/]mir/client to your project include path.
<alan_g> tvoss: I discussed it with robert_ansell yesterday and was assured it does work. But it seems I'm not the only one of a different opinion.
<tvoss> alan_g, ack. sturmflut can you file a bug please?
<sturmflut> alan_g: If i add it to my include path it works, as one would expect.
<alan_g> sturmflut: use that as a workaround. (But please raise the bug.)
<sturmflut> alan_g: Will do
<alan_g> kdub: tvoss kgunn (anyone interested) I'm creating a canonical [no pun intended] example of a useful logging reporter. I'd appreciate comments on https://code.launchpad.net/~alan-griffiths/mir/improved-MessageProcessorReport/+merge/155746
<racarr> I exist
<racarr> smspillaz: :)
<racarr> sturmflut: It's possible to write a demo client which receives keyboard events using the outstanding event ~robertcarr/mir/receive-input-in-client
<racarr> your guess of the status in trunk so far is good though, input is sent up to clients
<racarr> but not all received yet
<racarr> (and pointer input isnt finished)
<katie> hi racarr
<racarr> Hi katie
<katie> how's things? want to have a catch up?
<racarr> things are good, not sure I have anything
<katie> me neither
<racarr> katie: Ok let's skip this week then
<katie> racarr: great
<katie> i mean, i love our meetings, but good to have some time back :)
<racarr> katie: I feel the same :)
<racarr> actually right now I feel very little other than disdain for android::Looper but if I had normal feelings that would be it
<racarr> status: Iterating on receive-input-in-client...tried to port the client side input machinery to android::Looper to get rid of the short timeouts
<racarr> (plus fixing RAOF's other comments)
<racarr> got it "working" but acceptance tests fails intermittently with the looper on the client side
<kdub> drivers work better when they don't load their firmware all the time
<racarr> then back to finishing off inprocess EGL branch from yesterday
<tvoss> racarr, can you put a fixme there that notes down that we ideally want to associate it to the same event loop
<tvoss> kdub, ? :)
<racarr> kdub: Actually mythbusters did a show on that, drivers work best when loading their firmware all the time!
<racarr> :p
<racarr> tvoss: What do you mean?
<racarr> i.e. assosciate all input and everything else to the same event loop?
<kdub> tvoss, just a fun bug i caused during hwc development
<tvoss> kdub, ah :)
<tvoss> racarr, we have a looper in the client api anyway, it's an io_service. We might want to reuse that for the input channel, too
<racarr> tvoss: Boost::asio is not a good replacement for epoll I think as we saw in
<racarr> Looper.h
<racarr> well
<racarr> I dunno it can be adapted of course
<tvoss> racarr, I do disagree, I think it's a very sane replacement, it just does not fit the Looper model or we haven't looked into it deeply enough
<tvoss> racarr, just leave a note in the code :)
<kdub> RAOF, to answer the backscroll... we don't exhaust the fd space because the kernel keeps a mapping of pid's to fd's and pops the same one out on the client side on every message
<racarr> so weird...the android::Looper version of the client, sometimes it indefinitely hangs in pollOnce in the acceptance test
<racarr> if I add the fd to the looper in the first call to next_event instead of in the constructor
<racarr> it never fails (well, out of 1000 runs, whereas the other failed ~1/10)
<racarr> what is happening...-.-
<alan_g> racarr: when things don't make sense it is time to look at something else for 20min
<racarr> alan_g: You mean instead of continuing to blunder around in nonsense? Novel idea.
<alan_g> I mean that breaking focus helps see what you missed
<alan_g> racarr: ^
<racarr> alan_g|life: Hehe I know what you mean :)
<sturmflut> alan_g|life: https://bugs.launchpad.net/mir/+bug/1161064
<ubot5> Launchpad bug 1161064 in Mir "Mir client header files seem to be incorrect" [Undecided,New]
<racarr> sturmflut: Thanks! I am about to go on lunch
<racarr> but I will process that later today...I think you are right!
<sturmflut> racarr: Input processing on the server side currently concentrates on Android, am I right? Or is there a branch which handles other platforms
<racarr> so we should just land a fix asap
<racarr> sturmflut: No it works on desktop
<racarr> some of the naming is misleading because it uses
<racarr> large pieces of the android input stack :)
<sturmflut> ah
<racarr> so the mir::input::android namespace is the android-input based implementation of mir::input but not the android...platform?
<racarr> confusing...need better names :)
<racarr> sturmflut: https://code.launchpad.net/~robertcarr/mir/receive-input-in-client/+merge/155368 if you look aronud l363 you can see an example using it :)
<racarr> got distracted by finishing inprocess egl XD...just need to find the right abstraction for the display validation now and should be good to go
<racarr> but now lunch for real
<robert_ancell> tvoss, hello
<tvoss> robert_ancell, hey there :)
<tvoss> robert_ancell, wanna sync up? I have got nothing urgent on my side
<robert_ancell> tvoss, yeah, just a quick one
<tvoss> ack, gimme two :)
<kdub> meeting "mir team 2"?
<RAOF> Yeah, for those of us for whom âmir team 1â was stupid'o'clock.
<kgunn> kdub: RAOF :) happening now
<RAOF> kdub: Is that pidâfd mapping an android-specific thing? Because when *I* send fds over the pipe I get a shiny new one each time at the client.
<kdub> might be, surfaceflinger does the same thing with its binder transactions
<kdub> i can look into it, maybe its an android kernel thing
<RAOF> Eh.
<RAOF> I'm going to fix things up so we don't send needless fds, so it doesn't really matter.
<kdub> that would be better
<robert_ancell> RAOF, how are you for pkg-config/include directories?
<RAOF> robert_ancell: You mean, would I like to weigh in on the include-directory-structure thread, or do I have enough headers?
<robert_ancell> RAOF, I just need a second opinion on https://code.launchpad.net/~robert-ancell/mir/mir-common-headers/+merge/155660 - This is just standard stuff to me or is it confusing?
<sturmflut> CMake Error at cmake_install.cmake:44 (FILE):
<sturmflut>   file INSTALL cannot find "/mnt/datengrab/mir/build/doc/html".
<sturmflut> What the heck
<sturmflut> As of lately all accelerated clients segfault in XGetXCBConnection () from /usr/lib/x86_64-linux-gnu/libX11-xcb.so.1 . I tried it with the packages from the PPA and by building Mir manually. Happens with the included examples and glmark2. The unaccelerated demo client still works.
<RAOF> sturmflut: You need to have doxygen installed for make install to work.
<RAOF> sturmflut: We should probably fix that :)
<sturmflut> RAOF: doxygen is installed
<RAOF> Hm. Was it installed when you first ran cmake?
<RAOF> Oh, you might *also* have to specifically enable docs.
<sturmflut> RAOF: Yes, I even wiped the whole build/ folder and ran cmake again
<RAOF> sturmflut: Segfault in XGetXCBConnection means that Mesa hasn't detected the right EGL platform, and has uselessly defaulted to X11 which segfaults if you're not *in* X11.
<RAOF> sturmflut: We've recently gone through a transition for mesa which would have caused that, but the mesa in github (and I hope the PPA by now) should work with Mir trunk.
<sturmflut> RAOF: On the doc issue: I had to manually set BUILD_DOXYGEN to ON, then it worked
<sturmflut> Dunno why it was off in the first place
<RAOF> Because we hate you, I think :)
<sturmflut> Thank you, sir, I will remember that
<RAOF> We should really fix that.
<RAOF> To either (a) turn on the docs automatically when doxygen is installed, or (b) not fail to install when the docs haven't been built.
<RAOF> Or possibly even (c) both of the above.
<RAOF> Equally, Mesa defaulting to the X11 EGL platform is stupid and should be fixed.
<sturmflut> How do I find out if my Mesa package is on par with the github version? Seems like most of my Mesa packages are version 9.1~rc2-0ubuntu0+mir2-jenkins17
<RAOF> sturmflut: Hm. Mesa in the PPA hasn't been rebuilt since the changes landed in github, so it won't work.
<RAOF> thomi: How do we prod jenkins to build & upload a new mesa?
<thomi> RAOF: to a PPA you mean? It should happen automatically as part of the autolanding process
 * thomi investigates
<RAOF> thomi: mesa isn't autolanded.
<thomi> ahh, in that case, It's probably as simple as rebuilding a jenkins job
<thomi> RAOF: http://10.97.0.6:8080/job/mesa-egl-platform-mir-raring-dput/ was last run 20 days ago - does that sound about right?
<RAOF> That'd match the timestamp in the PPA; there are new changes in the git branch though that'll make sturmflut's mesa actually work, though.
<thomi> ahh, I see the git polling script is throwing an error, I'll rebuild it manually for now, and look in to why it's failing
<sturmflut> Now this is what I call Platinum Support
<cgoldberg> gource visualization of Mir codebase:  http://youtu.be/7grEFrTBzus
<thomi> RAOF: OK, the problem is that the git plugin we're using in jenkins is rather old, and requires a workspace on the slave (which isn't available). I'll file and RT to upgrade the plugin to a newer version, where this issue is fixed
<sturmflut> cgoldberg: Looks nice
<RAOF> Yeah, very puurdy.
<cgoldberg> sturmflut, i love making visualizations when I'm bored... just popped in to have a look at Mir :)
<kdub> cool cgoldberg
<sturmflut> thomi: Is it safe to build my own Mesa from github? Or should I wait for the packages
<thomi> sturmflut: I don't know about "safe", sorry. those packages have been dput'ed, so they shouldn't be too far away
<thomi> sturmflut: you can see the build progress here: https://launchpad.net/~mir-team/+archive/staging/+packages
#ubuntu-mir 2013-03-28
<RAOF> sturmflut: You can install the mesa packages to ~/.local and it's entirely safe (you then need to export LD_LIBRARY_PATH=$HOME/.local/lib to run things)
<sturmflut> thomi, RAOF: Okay, thanks. I think I'll go to sleep for today (it's 1 am here in europe) and if the packages are not ready for my next try I'll look into building my own Mesa
<thomi> sturmflut: unless something goes very wrong they should be there for your morning
<sturmflut> New day, new Mesa
<sturmflut> thomi: Looks like mesa-9.1~rc2-0ubuntu0+mir2-jenkins18 failed on amd64 and i386, or am I reading the results wrong?
<robert_ancell> cgoldberg, nice, thanks!
<thomi> sturmflut: yes, it seems it can't find mir_client_library.h
<thomi> I wonder if that file has moved recently
<robert_ancell> thomi, it has moved to <mir_toolkit/mir_client_library.h>
<thomi> robert_ancell: hmm, then it looks like the mesa source hasn't been updated?
<robert_ancell> thomi, probably likely
<thomi> dri/src/egl/drivers/dri2/egl_dri2.h line 69
<thomi> robert_ancell: who's the best person to fix that in mesa?
<robert_ancell> thomi, I think RAOF or alf?
 * thomi looks pointedly at RAOF
<thomi> hmmm, ok, so there's some odd setup on our jenkins machine - we don't appear to be pulling down new mesa sources at all.... unless it's hidden away in a cron job somewhere
<RAOF> thomi: I *did* test-build the mesa changes locally :)
<thomi> RAOF: yeah, there's something really funky happening here :-/
<thomi> it looks like someone had some fun getting around the fact that the jenkins server can't access freedesktop.org :)
<RAOF> It doesn't need to access freedesktop.org? Just github.
<thomi> RAOF: http://www.mesa3d.org/repository.html lists the mesa repository as git://anongit.freedesktop.org/git/mesa/mesa - is that innacurate?
<RAOF> No, that's accurate. But that's not where the branches for Mir are.
<RAOF> Because I don't have commit access there :)
<RAOF> thomi: You're looking for https://github.com/RAOF/mesa - mir-ppa and mir-ppa-quantal branches.
<thomi> RAOF: is that mirrored on launchpad at all?
<RAOF> thomi: No
<RAOF> thomi: Because it can't, because you can't import not HEAD branches.
<thomi> oh :(
<RAOF> It'd apparently be a couple of weeks work to fix bzr-git enough so that it worked, but we don't invest in bzr-git anymore :(
<thomi> yeah :(
<thomi> I'm looking at building a source package manually and dputing that to the PPA for today,a nd I'll find out what the story is here
<kdub> hey duflu, could you give https://code.launchpad.net/~mir-team/mir/consolidate-crossbuild-scripts/+merge/154762 another look?
<duflu> kdub: Will do, today
 * duflu goes to get coffee
<kdub> duflu, thanks
<sturmflut> RAOF: I'll wait until the mesa packages are updated in the PPA, I built Mesa from your github repository branch but after setting LD_LIBRARY_PATH i get "symbol lookup error: /usr/lib/x86_64-linux-gnu/libGLESv2.so.2: undefined symbol: _glapi_tls_Dispatch" upon running anything
<RAOF> sturmflut: That suggests that you either haven't installed it into the right path, or you haven't built it with the right options. Mesa has approximately 3 hojilion build options, so that's not hard. :/
<sturmflut> Hooray
<sturmflut> I foolishly thought I could get away with ./configure --prefix=/opt/mesa --with-egl-platforms=mir
<sturmflut> RAOF: Okay, I forgot --enable-gles2
<RAOF> You may wish to add --with-dri-drivers=i965 --with-gallium-drivers= (if you've got intel) or --with-dri-drivers= --with-gallium-drivers=r600 (or r300, or nouveau, if you've got one of those)
<RAOF> For reference, my most recent build:
<RAOF>  PKG_CONFIG_PATH=$HOME/.local/lib/pkgconfig ./autogen.sh --prefix=$HOME/.local/ --enable-gles1 --enable-gles2 --with-dri-drivers=i965 --with-gallium-drivers=swrast --enable-shared-glapi --enable-glx-tls --with-egl-platforms=drm,mir,x11
<sturmflut> RAOF: Thanks, it is finally working again!
<RAOF> Sorry for having it broken for so long. I'm going to break it again soon; hopefully not for as long :)
<sturmflut> At least now I can confirm that glmark2 works on Mir
<duflu> robert_ancell: Seems I'm not getting new Mir bug mail now... ?
<duflu> RAOF: Much badness :(  https://bugs.launchpad.net/mir/+bug/1161196
<ubot5> Launchpad bug 1161196 in Mir "All Mir demo clients using GL crash in eglInitialize()" [Critical,New]
<RAOF> duflu: PPA skew. The latest mesa isn't built in there. If you build from github you'll get a working GL.
<RAOF> Man, we really need eye-tracking-based focus detection.
<duflu> RAOF: Umm, kay. What are the options for not having to build Mesa from source? The old rocket-scientists PPA worked
<RAOF> The old rocket-scientists PPA won't work now; racarr's EGL changes landed, which were incompatible with the previous Mir EGL platform.
<duflu> RAOF: OK, so same question :)
<RAOF> duflu: Options include: having *me* build from source for you, or debuilding out of the mir-ppa branch on github; that'll get you packages you can install.
<duflu> RAOF: Ah, OK. debuild is less painful
<duflu> RAOF: So what do we expect the public to do if the public PPA no longer works?
<RAOF> We expect the public PPA to work.
<RAOF> The fact that it currently doesn't is (a) a bug, and (b) transitory.
<RAOF> thomi's working on restoring the mesa autobuild, which silently broke.
<duflu> RAOF: Sweet, ta. I will work around it till after Easter
<RAOF> Actually, I can help there - I'll just upload to the PPA. We don't have to wait for autolanding.
<duflu> RAOF: How goes Mesa upstreaming progress?
<RAOF> Waiting on landing the dma-buf branch.
<RAOF> Since that changes the client ABI there's little point in landing in mesa before that.
<RAOF> Oh, boo. That's right. Stupid jenkins versioning.
<duflu> RAOF: It's OK. demo_client_unaccelerated suffices for me today
<thomi> RAOF: new mesa packages are now in the PPA for i386 and amd64
<thomi> it might be a few days before the autobuild is back up and running. In the mean time, I can manually dput new mesa packages if you need them
<RAOF> duflu: Yeah, -jenkins19 in the PPA now should work, I think.
<RAOF> Care to test?_
<RAOF> GAH! Eye-tracking based focus, please!
<duflu> RAOF: Yeah will test it soon thanks
<racarr|lunch> https://code.launchpad.net/~robertcarr/mir/enable-inprocess-egl/+merge/155888 exists
<racarr|lunch> Oh wow...racarr|lunch
 * RAOF presumed racarr was just having a super-long lunch :)
<racarr> best lunch EVER
<duflu> RAOF: EGL works ta
<RAOF> Time for a last burst of SWIV:ANH-driven-development.
<racarr> ?
<RAOF> Does anyone else see the unittests sometimes failing to complete?
<RAOF> racarr: Star Wars IV: A New Hope.
<racarr> ah!
<RAOF> An excellent way to add atmospheric music to your test runs!
<racarr> "Christopher, we see you've disabled your test runs is everything alright?
<racarr> "
<RAOF> "Everything's fine" :)
<smspillaz> the next big thing:
<smspillaz> http://scottberkun.com/2007/asshole-driven-development/
<smspillaz> productivity up 200%!
<RAOF> Dear C++: I wish you didn't have to recompile all the reverse-dependencies when I change a private member.
<smspillaz> RAOF: don't expose private members in header filex kthxbye
<smspillaz> *files
<smspillaz> (even under private:)
<smspillaz> :p
<RAOF> But pimpl is such a drag!
<RAOF> It even _sounds_ bad :)
<smspillaz> I think that's why nobody uses it
<smspillaz> someone though "haha, pimpl, thats a funny name"
<smspillaz> and then the image that it puts in your head
<smspillaz> makes you not want to use it
<RAOF> Which is odd, because it's the _obvious_ implementation pattern for C.
<smspillaz> RAOF: I want to invent a language that:
<smspillaz> 1) has a very clear distinction between object and value types. Value types have public members, objects always have private members held by indirection
<smspillaz> 2) Doesn't allow for global variables or side-effects. All changes must happen throuhg interfaces provided in either the object's constructor or the function signature
<smspillaz> basically C++ the right way and no other way
<smspillaz> the problem is that the "right way" is a fluid concept
<duflu> Funnily enough, pimpl is widely used in C APIs. Except it's not called pimpl, it's just called good API design
<RAOF> Exactly my point :)
<smspillaz> also it should allow you to implement an interface and delegate that entire interface to a held object
<smspillaz> so that composition is not a total pain to write
<RAOF> smspillaz: The latter constraint sounds like you're secretly after a functional language :)
<duflu> smspillaz: You're asking for Go, right?
<smspillaz> duflu: kinda
<smspillaz> I don't really like the "you implement an interface implicitly" thing in Go
<duflu> smspillaz: Or Lisp for a purely functional language for doing your head in
 * RAOF needs to prod #debian-cli to upload F# to experimental
<smspillaz> you should be able to say "I am implementing this interface, but I want to delegate my implementation to this object"
 * RAOF isn't sure how useful that would really be
<smspillaz> RAOF: incredibly useful
<duflu> smspillaz: I've been thinking recently that maybe the problem is that an "interface" is too coarse. Maybe you should be able to delegate interface methods
<smspillaz> duflu: right, that would be the idea
<smspillaz> so if you had a Interface { public: virtual ~Interface () {} virtual void bar () = 0; virtual void baz = 0; };
<duflu> smspillaz: Which you can do in C and C++. Just not as part of the primary syntax
<smspillaz> duflu: right, you have to use function pointers to do it
<RAOF> That sounds to me like syntactic sugar for something that's already pretty sweet.
<smspillaz> and then an Object : public Interface { public: virtual void bar (); virtual void baz (); }
<smspillaz> And then a MultipleObjectsInConcept : public Interface { private Object o; }
 * duflu goes off to try do work instead of finding more bugs in Unity and Mir
<smspillaz> It would be nice to have something in the language that said - "Every function that I say I provide in Interface should be routed directly to my member Object"
<smspillaz> and then you can override the interface partially for where you needed to customize
<smspillaz> rather than having to implement every single method, then call the method from Object
<RAOF> smspillaz: But that's like three lines per method in the interface, including whitespace. I'm not sure that it's particularly onerous.
<smspillaz> RAOF: its just more typing that doesn't need to happen really
<smspillaz> and then every time you add a new method to that interface
<smspillaz> you have interface sensitivity, and all the object that were just implementing it by delegating to a member have to go implement that method
<duflu> Whoa... Maclisp existed a decade or two before the Mac ;)
<smspillaz> RAOF: my ideal language would also support templates, but reduce the amont of code generation by making it so that template members had to conform to a statically determined interface, and then for shifting points around, the entire thing was treated as void * in the underlying code
<smspillaz> so you could generate the code for std::list once (instead of per-type)
<smspillaz> and then if the template needed to call methods on the objects, you generate the code once per interface and not once per derived type
<RAOF> So, C# generics then.
<smspillaz> yes
<duflu> smspillaz: Yes I invented such an STL a few years ago. But then found prior art documented in Dr Dobbs magazine too
<smspillaz> I think what I want
<smspillaz> is Go#
<smspillaz> duflu: ah cool. Link ?
<duflu> smspillaz: Not handy
<RAOF> I'm going to work through "Statistics for programmers" in F# once everything's landed for that to actually happen. I suspect it might match many of your desires. I'll tell you how it goes. :)
<duflu> smspillaz: Though I do have a working re-implementation (not owned by IBM), I'm not willing to share that yet
<smspillaz> duflu: this is the point where you quit your job and make lots of money :p
<duflu> smspillaz: No that's a different project, which for legal and financial reasons I have not touched in ~2 years
<smspillaz> I figured it was something like that
<duflu> I know! Let's make an app for the braindead. Those make squillions!
<smspillaz> duflu: I'm always disappointed by the market
<duflu> Bah, marketing is about understanding people. Not what is arguably right...
<smspillaz> the people who come up with solutions to trap and collect plastic in the oceans get less attention than people who make apps
<smspillaz> duflu: I watched the interview on 7:30 last night
<smspillaz> I loved the bit where he was like "I had this idea ... so I hired a bunch of really smart people"
<smspillaz> and the headline is
<smspillaz> "PERSON MAKES LOTS OF MONEY"
<duflu> Heh, I'm not talking about one particular person. But the repeating theme...
<smspillaz> yeah
<smspillaz> duflu: I was tempted to go into app development after I left canonical but I couldn't bear the idea of the fact that its a seemingly-luck based get-rich-quick scheme
<duflu> Yeah, there's a lot of luck. But you'll always increase your luck with more skill too
<smspillaz> hmmm
<smspillaz> nux must kick something that the nouveau driver doesn't like
<duflu> The GPU. nouveau doesn't like those
<smspillaz> I always get a little frightened when I see them rewrite it once every few months
<duflu> smspillaz: Any more nouveau complaints, the maintainer just logged on to ubuntu-desktop ;)
<smspillaz> I'm sure they've heard enough alread :p
<smspillaz> *alrady
<smspillaz> *already
<smspillaz> me english good
<robert_ancell> hikiko, welcome!
<hikiko> hi :)
<hikiko> hi robert_ancell
<robert_ancell> alf_, are you familiar with pkg-config? (in relation to the changes for glmark2)
<alf_> robert_ancell: yes, it's already being used, but I don't think that pkg-config could help us in this case, since it's not just the base include path that changed.
<alf_> duflu: @composite-on-demand, so if I change status to Approve autolanding will fail?
<duflu> alf_: Yeah usually. But try it anyway
<alf_> duflu: ok, let's see...
<duflu> alf_: Because there are "unapproved" changes
<duflu> alf_: Frustratingly it might build the proposal and *then* tell you there are unapproved changes. Taking several hours
<robert_ancell> alf_, it was also the mir -> mir_tookit change?
<alf_> robert_ancell: right
<robert_ancell> alf_, ok, thought so. I just wanted to check the pkg-config changes weren't causing any problems
<robert_ancell> duflu, Had the /usr/include/mir-1.0 vs /usr/include/mircommon-1.0 discussion with alan_g - The main issue with the former are it makes it much harder to package (because you have to list each subset of headers per package instead of listing a directory*). Also
<robert_ancell> * = though of course clever scripting can get around this it would be nice to avoid
<duflu> robert_ancell: Not sure what the great hurdle will be but will assume you're right for now :) At least till I try and propose any changes
<robert_ancell> duflu, make sure you debuild to test them
<duflu> robert_ancell: I do. In fact, it's other people who don't debuild
<duflu> alf_: Merged! (?)
<duflu> That's not meant to happen though...
<alf_> duflu: perhaps it only blocks when you resubmit a proposal?
<duflu> robert_ancell: No one's going to answer your questions posed in bugs unless they have a bug comment subscription ;)
<duflu> So it's prolly just me
<robert_ancell> duflu, meh, I don't think there's any real supporters for it anyway - just propose a branch and see if people complain
<duflu> robert_ancell: The danger with this one is that tvoss or alan_g might have a reason for keeping it
<duflu> Ask them
<tvoss> robert_ancell, supporters for what?
<duflu> But I agree it would be nice for people to disagree with something in bug discussions before it reaches proposal
<robert_ancell> duflu, I just talked to alan_g and he's OK with it.
<duflu> tvoss: https://bugs.launchpad.net/bugs/1160741
<robert_ancell> tvoss, remove binder support since it's broken and we don't have a requirement for it
<ubot5> Launchpad bug 1160741 in Mir ""Binder" logic is redundant, unused and fails to build" [Low,New]
<tvoss> robert_ancell, fine with me, but check with Alan, please
<robert_ancell> tvoss, already done
<robert_ancell> duflu, kill it!
<duflu> robert_ancell: In other news, on-demand rendering just landed. You can finish VT switch support
<robert_ancell> duflu, yeah, I've already been talking with alf_ about this
<duflu> robert_ancell: Yeah I can probably "kill it" before finishing up this evening
<alf_> alan_g: Good morning! What do you think about the signalfd idea in reuse-run_mir? It seems it's going to be useful for proper handling of other signals too (e.g., for VT switching).
<alan_g> alf_: there's also some boost stuff tvoss used in an earlier version (IIRC that didn't work in the NDK)
<tvoss> alan_g, alf_ there is a generic signal handler in process iirc
<alf_> alan_g: tvoss: even better then
<alan_g> alf_: are you happy with https://code.launchpad.net/~alan-griffiths/mir/improved-MessageProcessorReport/+merge/155746
<alf_> alan_g: I missed the update, checking...
<alf_> alan_g: ok
<alan_g> alf_: ta
<tvoss> katie, ping
<duflu> alan_g, tvoss: How sure are we that "binder" is not required/used on Android?
<alan_g> duflu: it worked with the NDK, but we've dropped support for that
<duflu> Righto
<alan_g> We have version control if we ever want it vack
<alan_g> *back
 * alan_g doesn't want to think about libhybris support for binder
<alf_> duflu: can you still reproduce lp #1123824?
<ubot5> Launchpad bug 1123824 in Mir "The following tests FAILED: 73 - memcheck(integration-tests.BespokeDisplayServerTestFixture.*) (Failed) 75 - memcheck(integration-tests.FakeEventHubSetup.*) (OTHER_FAULT)" [High,New] https://launchpad.net/bugs/1123824
<duflu> alf_: Not sure. Twas only reliable on Nexus 7 and I haven't had time or luck with anything on Nexus recently
<duflu> Assume incomplete if you like
<alf_> duflu: I will try to reproduce locally, and mark as incomplete if I don't manage to
<katie> tvoss pong
<duflu> alf_: If you're in the mood for fixing failing tests, there are a few bugs relating to failures when built with clang :)
<alf_> duflu: I want a change of pace for today... I will focus on bug fixing, so I will probably take a look.
<duflu> OK, that's enough
 * duflu -> supermarket, Easter
<alan_g> alf_:Are you happy with this version? https://code.launchpad.net/~alan-griffiths/mir/reuse-run_mir/+merge/155196
<alf_> alan_g: Isn't there still the possibility of a deadlock? For example, if stop() is called from the signal handler (from the same thread as run()) while run() isn't yet waiting on the condition variable.
 * alan_g checks
<alan_g> alf_: AFAICS exit will be true when run tests it.
<alan_g> alf_: sorry just understood what you meant
<tvoss|lunch> mpt, katie, nothing to sync on my side
<katie> tvoss|lunch, mpt, nothing from here either
<mpt> Rheet!
<alan_g> alf_:Are you happy with this version? https://code.launchpad.net/~alan-griffiths/mir/reuse-run_mir/+merge/155196
<racarr> Morning
<alf_> alan_g: looking
<alan_g> racarr: morning
<alf_> alan_g: I am happier (although there still is a "hidden" thread that dispatches the signals). Let's see how well this way serves us for handling VT changes, and reevaluate then.
<racarr> alan_g: Did you see: https://code.launchpad.net/~robertcarr/mir/enable-inprocess-egl/+merge/155888
<alan_g> alf_: you can't avoid a self-race without using two threads
<racarr> I have a feeling the continuous part of the part of this merge is DisplayServer::surface_factory and the move of src/shell/surfaces.h to include/...
<alan_g> alf_: boost.Asio can also hook into signals - but again there's a "hidden" thread
<alan_g> racarr: I don't spend time second guessing WIP
<racarr> ok :)
<tvoss> kgunn, ping
 * alan_g wonders if "continuous" is contentious
<racarr> contentious yes
<alan_g> racarr: want me to review?
<racarr> alan_g: That would be good when you have time. I think it's "Done"
<racarr> I just don't really expect it to land on the first iteration
<racarr> because of the surface bits, etc...
<alf_> alan_g: The point of using signalfd or boost asio + signal_set (if it can manage signals without extra threads) is that everything would happen synchronously inside a thread that is already doing nothing (the main thread, currently mostly waiting on exit_cv). That is, we would move to a limited event loop structure.
<kgunn> tvoss: pong
<alan_g> alf_: That just seemed like more work (as it affects how DisplayServer::run()/stop() operate).
<alan_g> tvoss: will you have time to chat about edge-type this afternoon?
<tvoss> alan_g, in ~30 minutes for max 30 minutes
<alan_g> tvoss: I hope it won't take that long. ;)
<tvoss> alan_g, cool :)
<alan_g> alf_: are you happy to approve and revisit later?
<alf_> alan_g: yes
<alf_> alan_g: although later may be sooner than you think :)
 * alan_g thinks "after Easter"
<alf_> alan_g: No easter for me yet, so for me maybe even sooner ;)
<racarr> I heard from a homeless man that they cancelled easter.
<racarr> Not sure where he got his info.
<alan_g> alf_: I'm around tomorrow - swapped it for the following Friday
<racarr> investigating building input stack in clang so receive-input-in-clients can pass continuous integration
<alf_> alan_g: I doubt I will have reached a conclusion by tomorrow. I still need to investigate how VT switching behaves exactly, and what we need to do (pause compositor, give up). There is also the complication that VT switching exists only on GBM, so we need to handle the difference between the platforms elegantly. One idea is to make e.g. SIGUSR1 mean pause()/play() regardless of the platform, and just connect it to VT switching on GBM.
<alf_> alan_g: s/give up/give up drm permissions/
 * alan_g wishes he were clever enough to understand
<alf_> alan_g: a little background: we can tell the kernel to send us a signal when the user changes to/away from our VT. When we lose our VT we need to pause compositing, and also give up our priveleged access to the graphics device (drm) so that others can render (e.g. X11)
<alf_> alan_g: and vice versa when we regain VT "focus"
<alan_g> alf_: that helps. ;)
<alan_g> alf_: I can see why you'd then want to rethink signal handling
<racarr> alan_g: alf_: We talked yesterday in meeting (us/aus/nz) about removing MIR_DISABLE_INPUT after fixing clang build
<racarr> seem sensible?
<alan_g> racarr: my understanding is that we'll still need null input for the system compositing case
 * alan_g has been wrong before
<alf_> racarr: related question... what will it take to make the input thread not spin?
<racarr> where does lightdm get input?
<racarr> alf_: Is the input thread spinning again
<racarr> which one do you mean?
<racarr> sever or client
<alf_> racarr: did it ever stop? :)
<racarr> Yeah!
<racarr> I remember...
<racarr> *scratches head*
<racarr> sort of
 * alf_ rechecks to ensure he hasn't lost any episodes
<racarr> I dunno! Ill figure out too
<racarr> oh yay memcheck problems in receive-input too
<racarr> going to fix those first I guess
<alan_g> racarr: just wondering does the run_mir signature in https://code.launchpad.net/~alan-griffiths/mir/reuse-run_mir/+merge/155196 solve the same problem as the_ready_to_run_handler()?
<alf_> racarr: reconfirmed, InputDispatcher thread is spinning on the desktop
<racarr> alf_: Ok I will check it out soon
<racarr> thanks :)
<alf_> racarr: great :)
<racarr> alf_: ready_to_run_handler needs to run after the
<racarr> hmm
<racarr> err alan_g ^
<racarr> was going to say, after the server components are started
<racarr> but maybe not really
<alan_g> I wasn't sure either - that's why I asked
<racarr> alan_g: I will figure out, I thought that for sure it had to run after the various components are started
<racarr> but I think this is some piece of information I collected from a few months ago and forgot why
<racarr> and it might not really be true now that I look...
<racarr> shouldn't be true. just te DisplayServer:: needs to be initialized
<kdub> good morning folks, working on the android graphics integration tests today (will drive integrating the nexus4 display)
<alf_> racarr: do you want me to file a bug for the spinning thread so we can keep track of this better?
<alan_g> racarr: I've done a quick pass and highlighted my main concerns. Grab me if they don't make sense.
<alan_g> kdub: racarr  - please review https://code.launchpad.net/~alan-griffiths/mir/reuse-run_mir/+merge/155196
<kdub> alan_g, ok
<alan_g> status: getting bits of cleanup landed, reviewing and thinking about which work item to steal next
<racarr> alf_: That would be great!
<racarr> alan_g: Want to steal hardware cursor?
<racarr> its kind of cool, self contained, I can show you the drm/gbm APIs you need
<alan_g> racarr: sure. Let me grab a drink first.
<racarr> alan_g|tea: Ok sounds good :)
<alf_> racarr: lp #1161456
<ubot5> Launchpad bug 1161456 in Mir "InputDispatcher thread is spinning" [Undecided,New] https://launchpad.net/bugs/1161456
<racarr> alf_: Thanks :)
<racarr> hmm
<racarr> the input manager from the testing server configuration in test_client_input.cpp
<racarr> is leaking...
<alan_g> racarr: what's best? Hangout? email with links and chat?
<racarr> alan_g: For cursor? Either way it's pretty simple. probably easiest is just jumping on a hangout quickly and I can quickly take you through what is there/what needs to happen
<alan_g> racarr: let's do that then
<racarr> ok starting a hangout
<racarr> literally everything is leaking in this test
<racarr> somehow exit must not be clean
<alan_g> racarr: does it use the test framework?
<alan_g> racarr: does it use the mir test framework?
<alan_g> Because the server and client processes do not exit cleanly
<racarr> alan_g: Yes. It does...but why don't the other tests report leaks then?
<alan_g> racarr: the parent test process should be clean, it is the server and client process that exit abruptly
<racarr> alan_g: Parent is clean yeah. server detects the input manager and all its dependencies (i.e. the whole android input stack)
<racarr>  as definitely lost
<racarr> but this doesn't happen for any other tests
<alf_> racarr: I am not sure if/how it is related, but I currently trying to debug why the server doesn't shut down properly after a client has connected (and disconnected). The use count of our mg::Display shared_ptr<> is larger than expected at the end and thus our display it's not destroyed properly.
<alf_> racarr: I am still investigating why we lose (or rather don't lose) shared_ptr references
<racarr> alf_: Ah...strange
<racarr> no ideas from top of my head
<alf_> racarr: just mentioned it in case it's somehow related to your issues and might help you with debugging
<alf_> racarr: debugging = figuring out what's going on
<racarr> thanks
<alan_g> alf_: that sounds like a circular dependency. :(
<alf_> alan_g: Yes. An interesting clue that it only happens after at least one client has connected (and possibly disconnected, doesn't matter), never before.
<cecilpierce> /part
<alf_> alan_g: racarr: kdub: enjoy your holidays, talk to you next week (well, except Alan)!
<kdub> you too alf_ !
<racarr> Bye alf
<racarr> enjoy :)
<alan_g> alf_: see you tomorrow!
<alf_> alan_g: :)
<racarr> "Why is "MirEventDelegate const *event_handler" a separate parameter and not a member of MirSurfaceParameters?" - Alan on receive-input-in-clients
<racarr> anyone have any opinions?
<racarr> My thought is that MirSurfaceParameters are surface creation parameters, whereas the event delegate is more something attached to a created surface
<racarr> ...but thats really only kind of in terms of the server/client interaction
<racarr> not convinced that fsync works correctly under valgrind
<sturmflut> I finally got glmark2 running on Mir and took a short video: http://www.youtube.com/watch?v=Kjb8a8ISKWY
<sturmflut> Could be useful for marketing purposes
#ubuntu-mir 2013-03-29
<alan_g> alf_: not urgent, but have a look when ready... kdub's fiddling with the cross-build script is finally working on CI for https://code.launchpad.net/~alan-griffiths/mir/add-glog-logging/+merge/153568
<alf_> alan_g: great, I will take a look when I am done (or too tired to continue) chasing shared_ptr :/
<alan_g> alf_: if you get stale with it let me know and I'll take a look.
<alf_> alan_g: thanks, I will let you know
<alf_> alan_g: This is what I found is going on http://people.canonical.com/~afrantzis/mir-cyclic-dependency.dia
<alf_> alan_g: I have a solution but I need to check it a bit more (after lunch)
<alan_g> alf_: I'll try to understand and be ready to review ;)
<alf_> alan_g: in short, we need to ensure that InputManager drops its reference to ApplicationSession when the session is closed
<alf_> alan_g: but perhaps this is an indication of deeper design issue
<alan_g> alf_: That is my reaction too - but I need to think it through
 * alan_g feels there's a role (and associated class) missing, but isn't quite sure what the role is.
<kgunn> alf_: are you viewing the diagram via firefox? or some other app? (giving me fits)
<alf_> kgunn: I am using dia
<kgunn> thanks
<alf_> kgunn: in case dia crashes for you, see https://bugs.launchpad.net/ubuntu/+source/dia/+bug/1102960
<ubot5> Launchpad bug 1102960 in Dia "dia crashes on startup" [Critical,Confirmed]
<alf_> kgunn: there is a workaround in comment #11
<alan_g> alf_: I'm pretty sure that InputManager isn't an InputFocusSelector (what it needs is the current focus, not to be informed of focus changes). Also the InputFocusSelector interface is broken (I'm sure I mentioned this during review).
<alan_g> The missing role is an object that provides the InputManager with the current focus and monitors session and surface events within the shell.
<alan_g> Rephrasing: The missing role is an object that the InputManager uses to dispatch events (to the current focus) and monitors session and surface events within the shell.
<alan_g> alf_: ^ is that your thinking too?
<alf_> alan_g: So in essence reverse the Input - Shell dependency and break the cycle?
<alan_g> alf_: Well, it could be considered like that, but it is motivated by separating concerns.
<hikiko> kdub, ping :)
<kdub> hello hikiko
<alf_> alan_g: So you were thinking something like input::Shell { send_input_event(...) = 0; set_input_focus_changed_callback(...) = 0;} input::InputManager(input::Shell) ?
<alan_g> alf_: Something like shell::SessionInputFilter : input::InputFilter, shell::FocusMonitor
<alf_> alan_g: I am trying to understand how each option will help us solve the dependency problem
<alf_> alan_g: why does shell need shell::FocusMonitor?
<alan_g> alf_: Well, maybe the names is bad. But as I see it the shell needs to notify *something* about changes to the focussed session and/or surface
<alf_> alan_g: shouldn't that be expressed in terms of the "something", though?
<alan_g> I called *something* "shell::FocusMonitor" because it is an interface the shell needs
<hikiko> hello
<hikiko> one question :)
<alf_> hikiko: sure
<hikiko> gbm can be used under X?
<hikiko> I thought no but I am not sure :)
<kdub> alf_, specifically, the scenario hikiko is wondering about is
<kdub> an x server that owns the framebuffer, and mir operating as an x client (using sdl )
<kdub> and she wants to make sure that the gbm buffer 'stuff' in mir won't be affected by the presence of an x server that owns the framebuffer
<alf_> hikiko: kdub: it will be affected since in that case we don't priveleged access to the drm device (the X server has)
<hikiko> so if I want to have an sdl platform (like we already have the gbm and the android) for the emulator, I need to implement the buffer classes you have in the other 2 platforms (I can't use the gbm and just create a new display) isn't it?
<kdub> the issue sounds like its getting privilege to get at the gbm graphics buffers then
<racarr> alf_: alan_g: The current focus implementation is a shortcut
<racarr> alf_: alan_g: The way it should really work I think
<racarr> and has to for all the pointer stuff is
<racarr> the input manager maintains a session handle and window handle for all open
<racarr> sessions/windows, and removes them when appropriate
<racarr> via a listener interface
<racarr> focus is a seperate callback/interface
<racarr> that updates the property on one of the window handles
<alan_g> racarr: I really think that the input manager should delegate that tracking to something that knows about the events that change focus.
<smspillaz> racarr: morning :)
<racarr> Morning :)
<racarr> alan_g: Yeah I think once it gains this logic for managing the list of sessions handles, etc, it should become a new interface
<racarr> well a new
<racarr> object
<alf_> hikiko: kdub: although if you just want to create some buffers to render to/use as textures it may be the case that no special priveleges are required (but I haven't tried)
<alf_> hikiko: kdub: also, perhaps you can get SDL surfaces that are backed by drm buffers? (I have no idea)
<racarr> alf_: alan_g|tea: What is this about input::Shell { send_input_event}, etc...
<hikiko> I don't think that's possible... Does it have to be drm buffers? Does the client actually directly manipulate drm buffers?
<racarr> shell::SessionInputFilter?
<racarr> Don't really understand
<alan_g> racarr: it all begins with alf_ finding an ownership cycle causing memory leaks
<alan_g> http://people.canonical.com/~afrantzis/mir-cyclic-dependency.dia
<alf_> hikiko: Yes, the client part of mir (for the desktop) uses drm buffers. If the server sdl backend doesn't send drm buffers, you will also need to write a new matching client backend. And I am not sure how Mesa will work with that...
<alf_> hikiko: although the work racarr did recently should help
<hikiko> well, I guess that mesa will just provide the opengl context
<smspillaz> alf_: hikiko my understanding of working with wayland is that you should be able to allocate gbm buffers in an SDL based X11 compositor and send them to the client
<smspillaz> and then just create the textures from those
<smspillaz> shouldn't be any different than running directly on kms
<hikiko> that's cool if possible
<hikiko> I will try this first
<alf_> alan_g: racarr: Hangout?
<hikiko> thanks a lot all of you :)
<alan_g> alf_: sure
<hikiko> I have to go, my day is over! see you :)
<alf_> racarr: alan_g: https://plus.google.com/hangouts/_/77e412bddebe0d5ea06c9d92750a3dfaaa736317?authuser=0&hl=en
<smspillaz> alf_: If the mesa mir platform is anything like the wayland platform, I believe all that would be necessary is to allocate the buffers using the mir platform in mesa, and then calling into eglCreateImageKHR to bind it to a texture
<kgunn> racarr: you joining? ^
<Darxus> Anybody have an email address for sturmflut?  Or know if his changes to glmark2 to get it to run on mir are available (upstream?)?  I'm curious if they'd be a useful reference for porting it to wayland.
<Darxus> I guess he wasn't the one that ported it.
<smspillaz> Darxus: alf_ was the one who did the mir work for glmark2
<smspillaz> actually alf_ wrote it iirc :)
<smspillaz> Darxus: they're in a meeting though, give it 15 mins
<alf_> Darxus: it should be relatively straightforward to port to wayland, you will need to implement the NativeState interface for wayland (e.g. see NativeStateMir, NativeStateX11 etc)
<Darxus> smspillaz: Thanks, looks like things are pretty well documented, and upstream:  https://blueprints.launchpad.net/ubuntu/+spec/client-1303-mir-glmark2 https://code.launchpad.net/~glmark2-dev/glmark2/trunk  Looks like most of it is here:  http://bazaar.launchpad.net/~glmark2-dev/glmark2/trunk/revision/265
<Darxus> alf_: Thanks.
<kdub> hey rsalveti is lp:~rocket-scientists/aal+/trunk the latest version of hybris?
<alf_> racarr: alan_g: kgunn: Last chance for hangout today
<kgunn> alf_: you off on monday?
<alf_> kgunn: no, but I guess Alan is (and the US?)
<alan_g> alf_: kgunn I'll be off on Monday
<kgunn> alf_:  oh yeah...Alan is i think too....US works
<alf_> alan_g: kgunn: so do you want to hangout today or leave it for next week (perhaps have some more time to think about it, too)?
<kgunn> alan_g: alf_ if racarr is m.i.a. i guess leave it till Tues.
<alf_> kgunn: alan_g: fine with me
<alan_g> alf_: ok
<alf_> all: (-alan_g) Have a great weekend
<alf_> alan_g: Have a great long weekend
<alf_> :)
<kgunn> alf_: :) hope you enjoy yours also
<alan_g> alf_: I'll try (but my wife has chores planned)
<racarr> Sorry was afk
<alf_> lol
<racarr> isn't
<racarr> today off?
<racarr> :)
<racarr> we can catch up later.
<alf_> alan_g: kgunn: racarr: ok, hangout take two?
<racarr> Or that :) sure
<kgunn> ok
 * alan_g doesn't know what's happening
<alf_> alan_g: kgunn: racarr: https://plus.google.com/hangouts/_/8ca1c200997596d270738b80ee77065cc715ad1e?authuser=0&hl=en
<alf_> alan_g: racarr's perfect timing is what's happening :)
<alf_> racarr: http://paste.ubuntu.com/5658848/
<sturmflut> When will basic window management be in place? Apparently at the moment Mir doesn't even support two clients running at the same time, it just displays what the last client to be started draws onto its surface
#ubuntu-mir 2013-03-31
<cecilpierce> join #wayland
#ubuntu-mir 2014-03-24
<RAOF> Stupid bastard of an acceptance test! Last time I ran you, you worked!
<RAOF> Oh, oops.
<RAOF> Hey, cool. My touchpad really does support two-finger multitouch.
 * tvoss watches Linux Action Show
<duflu> tvoss: Good idea, till I realized how long it was :)
<tvoss> duflu, last third :)
<anpok> is there a way to batch surface changes together... i.e. move show hide..
<anpok> and have only one notification
<duflu> anpok: Not yet. But I did design in the expectation that mir events could arrive in batches. Don't think that's implemented yet
<anpok> hm I believe the shell would need an API to batch those changes together.
<duflu> anpok: It's probably a good idea for throughput. But (a) We don't yet have evidence that event throughput is a problem; and (b) It's hard to decide how long to batch events. You could easily cause all sorts of lag bugs
<duflu> In theory, any delay could be detrimental to client performance
<anpok> duflu: ah, no.. thats not what I meant..
<duflu> anpok: You mean atomic?
<anpok> in the split greeter switch between greeter and session and on boot
<anpok> for these swtiches there is now "spinner" showing a loading screen
<anpok> and it seems like if u-s-c does spinner->hide() .. check states of surfaces .. greeter or session->show() there seems to be a wrong frame in between..
<Saviq> guys, do you know the "Qt queues events when rendering blocked" bug from last week?
<Saviq> there's a reply from one of the Qt folks that we might need to argue against (or agree and implement...)
<Saviq> https://bugreports.qt-project.org/browse/QTBUG-37677?focusedCommentId=237009&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-237009
<anpok> hum
<tvoss> Saviq, I can see the need for synchronizing to swap buffers, but I'm a bit hesitant to provide all apps with information about the screen's state
<Saviq> tvoss, well, it's not about the screen's state, but about the app surface's state
<Saviq> tvoss, so there's two things... on one hand we're SIGSTOP'ing the apps soon after anyway
<Saviq> tvoss, so even if they don't care about that, we're fine
<Saviq> (that == the opaque/expose)
<anpok> so we would need to send an event when the buffer is not going to be consumed, because it is occuled, and if the screen is turned off
<Saviq> on the other, shell is affected already, but that we can control and make sure that it does honor those events
<tvoss> Saviq, just to cross-check: the whole app is effectively blocked if swap-buffers does not return, correct?
<Saviq> tvoss, yes
<anpok> only the gui/qml thread and the renderer I though?
<anpok> +t
<Saviq> anpok, yes
<Saviq> anpok, but everything in QML happens on the GUI thread effectively
<tvoss> anpok, which is by default linked to everything else in the process iiuc
<anpok> or would that also affect other QThreads created, as they do dispatch events through QApplication?
<tvoss> anpok, everything else, too, unless explicitly decoupled
<w00t> tvoss: no. if you have a thread created yourself, with no synchronisation, that's not going to magically become blocked
<w00t> the gui thread is blocked because it's waiting on the render thread to signal completion, which is actually blocked
<tvoss> w00t, sure, fair point. I'm referring to elements being implicitly tied to the gui thread
<tvoss> Saviq, so the music player app issue should be fixed with the media-hub iiuc
<Saviq> tvoss, sure, but that's just one issue
<Saviq> tvoss, shell is also affected by that - no volume buttons, no alarms working
<Saviq> and there's probably more we don't know about
<anpok> will qt clients that run animations inside their frame bisbehave with 5.2/5.1 if we dont support them with these events?
<tvoss> Saviq, yup, but I think that it would be easier for us to solve in the shell than for *all* apps
<anpok> i.e. qt games..
<tvoss> anpok, they won't be running anyway
<Saviq> anpok, yeah, when screen off they're SIGSTOP'ed, so doesn't *really* matter
<tvoss> anpok, in this particular scenario, they are sigstop'd pretty soon
<tvoss> Saviq, so the only real issue is the shell, correct?
<Saviq> tvoss, well, no, the issue is that we're disagreeing with Qt on what we do
<Saviq> tvoss, we need to either convince them to not sync (which must not have been happening in 5.0)
<tvoss> Saviq, at least making it configurable would be handy
<Saviq> or we need to implement the supported behaviour and not block the rendering thread
<tvoss> Saviq, yeah, my point was that generating the exposure/obscure event for/in the shell is certainly doable
<anpok> but the QtQuick renderer thread has to receive that occlusion event before he goes into the blocking eglSwapBuffers call..
<Saviq> tvoss, not sure why we'd special case it, though...
<Saviq> anpok, there can't be no blocking eglSwapBuffers call, that's the thing
<anpok> and that sounds like an easry race condition to run into
<anpok> ok - a failing eglSwapBuffers then?
<Saviq> or an ignored one...
<duflu> Remember anything that's not a client or a nested server is "bling". To sync that perfectly to compositing you have to render it in the compositor (i.e. don't use Surfaces)
<duflu> See the demo-shell decorations :)
<Saviq> I'm not sure on what would be the right / correct thing to do here, but obviously what they're saying is that a blocking eglSwapBuffers call is not supported
<Saviq> at least while the surface is allowed to render, I'd say
<Saviq> but yeah â that'd be racy
<duflu> SwapBuffers is designed to (and must) work asynchronously behind the scenes. If you make it synchronous like a glFinish() then performance is unacceptable
<tvoss> Saviq, hmmm, agreed, it's difficult to say, but using exposure events to encode possible reasons why a call to swap buffers might block/return an error
<tvoss> does not seem to be right to me
<Saviq> tvoss, yeah, it seems they're working under the assumption that swap buffers will always work
<duflu> tvoss, Saviq: eglSwapBuffers always blocks once you've filled the queue. That's how to throttle clients to the refresh rate :)
<Saviq> duflu, yeah, sure, but that's a "special case"
<duflu> ... which happens "all the time"
<Saviq> duflu, in our case we're telling the app effectively that the queue is filled when screen is off
<tvoss> Saviq, which actually is quite sensible :)
 * duflu goes away to try and finish his work for the evening
<Saviq> tvoss, not necessarily
<Saviq> tvoss, not if the assumption from Qt is that the app stops when that happens
<Saviq> unless we first "tell it" that there's not going to be more swaps possible (with expose/occlude)
<Saviq> but that's dangerous
<tvoss> Saviq, it is, and kind of goes against the defined of eglSwapBuffers
<tvoss> +behavior
<Saviq> indeed
<tvoss> Saviq, so Qt always assumes the "good" path when calling eglSwapBuffers unless otherwise told
<tvoss> Saviq, races and timings aside, this sounds fragile.
<Saviq> tvoss, well, not if what it does is just wait for stuff to settle again, and process everything when swapping is possible again
<Saviq> tvoss, especially when you consider the swapping to only not return when buffer is filled, and indeed you don't want to do unnecessary work until you can swap again
<tvoss> Saviq, what do you mean with "wait for stuff to settle again"?
<tvoss> Saviq, the definition of "unneccessary" becomes quite broad though, if you block the overall event processing on the rendering
<Saviq> tvoss, well, if you're a GUI app, and are expecting to be able to draw
<Saviq> tvoss, your GUI thread blocking on you not being able to draw...
<Saviq> makes sense to me
<Saviq> if you're told that you won't be able to draw (expose/occlude), that's another matter
<tvoss> Saviq, hmmm, I think both approaches are valid, i.e., block and not block, where block could be a safe default
<Saviq> tvoss, sure, we need to come up with a solution, though ;)
<Saviq> tvoss, as this is the last known 5.2 issue that we need to fix
<Saviq> tvoss, or well, we at least need guidance on whether we want to argue with Qt folk or not
<tvoss> Saviq, how about proposing making the blocking optional to the qt folks
<Saviq> tvoss, TBH I'm not convinced, so I wouldn't like to argue that point :)
<tvoss> Saviq, and I'm likewise not convinced that switching off the screen equates to an obscure event
<Saviq> tvoss, well, in our case it does, as we're unfocusing the app / putting the lock screen on
<Saviq> tvoss, btw, definition of the expose event http://qt-project.org/doc/qt-5/qwindow.html#exposeEvent
<Saviq> tvoss, I'd say that that makes sense, as exposed is a broader event than obscured
<tvoss> Saviq, okay, and we would be required to send a resize event?
<Saviq> tvoss, not sure, why?
<tvoss> Saviq, doc says so
<Saviq> tvoss, first time
<tvoss> Saviq, hmmm ...
<Saviq> tvoss, I'd say we're actually sending exposeEvent already
<Saviq> tvoss, otherwise we'd never draw
<Saviq> or qt wouldn't
<Saviq> or maybe we don't, nothing in qtubuntu apparently
<tvoss> Saviq, it's still racy to send the expose event
<Saviq> tvoss, not if we don't block swap buffers subsequently
<Saviq> tvoss, so that's the real, architectural, question - should we be ever blocking swap buffers
<Saviq> Qt seems to think we should not
<Saviq> not if we want the GUI thread to run
<Saviq> which we want, at least for the shell
<tvoss> Saviq, we should, and we have to ... it's absolutely normal behavior to throttle clients with that
<Saviq> tvoss, _throttle_
<Saviq> tvoss, we don't need to throttle if we don't want them to render at all
<Saviq> and we're SIGSTOP'ing them anyway
<Saviq> tvoss, don't get me wrong, I'm the devil's advocate here
<Saviq> tvoss, and that's why I don't want to argue with Qt folk, 'cause it's not me that made (makes) that decision
<tvoss> Saviq, sure, that's fine. I still think that an assumption on eglSwapBuffers not blocking is fragile
<Saviq> tvoss, and that's what you need to argue with them on :)
<tvoss> Saviq, I guess you are putting the focus on *you* here ;)
<Saviq> tvoss, I just don't know enough about this
<Saviq> tvoss, and it's kind of an architectural question
<tvoss> Saviq, sure, no problem. Just created an account in Jira
<Saviq> and then... you're the architect! :D
<tvoss> Saviq, yup. According to http://www.khronos.org/registry/egl/sdk/docs/man/xhtml/eglSwapBuffers.html
<tvoss> Saviq,  a way of returning early would be to return false and raise EGL_CONTEXT_LOST
<tvoss> Saviq, which is really expensive
<Saviq> tvoss, sounds so, yeah
<tvoss> Saviq, replied
<Saviq> tvoss, thanks
<Saviq> tvoss, btw, I think I found the commit https://qt.gitorious.org/qt/qtdeclarative/commit/a7f61f7
 * Saviq tries to see if reverting that helps for the time being
<Saviq> tvoss, FYI: Gunnar replied
<tvoss> Saviq, thanks
<tvoss> Saviq, is qt-project the qt channel I should go to?
<Saviq> tvoss, #qt-labs
<tvoss> Saviq, thanks
<Saviq> tvoss, or #qt-quick
<Saviq> tvoss, maybe the latter, as this seems to be a qml-specific thing
<Saviq> tvoss, FYI it's actually https://qt.gitorious.org/qt/qtdeclarative/commit/ebe8b9408cfcd953fae80514aa67e49221541bed that introduces the syncing, I doubt we can revert that with any certainty that it's gonna work
<Saviq> it does _almost_ apply -R, but I'd really rather not...
<tvoss> Saviq, that's indeed looking too complicated to just revert it
<mterry> racarr, poke!  I figure you might be starting your day soon.  I was curious if that PPA helped with testing the "screen turns back on" bug.  I tested myself with your runServerWithGreeterClient branches to see if they helped, but they didn't.  Not sure why this problem cropped up again (I thought it was already solved)
<kgunn> tvoss: Saviq ...so what's preventing us from using the expose event? seems like that is the given answer ?
<tvoss> kgunn, we certainly can, but it's still racy
<kgunn> tvoss: agreed...i think its a _terrible_ idea
<kgunn> in general
<kgunn> but just living with the "make it happy" moment
<kgunn> :)
<tvoss> kgunn, specifically when dealing with applications, we would need to wait for the apps to acknowledge the event before we can stall the pipeline
<kgunn> yeah...long halting sequence
<greyback> alf__: hey, Mir fails to start on me frequently with this error: std::exception::what: Error opening DRM device
<greyback> -22, "Unknown error -22"
<tvoss> kgunn, I think we can leverage the expose event in the shell easier, though
<greyback> alf__: it's a nouveau machine, if that's any help/hindrance
<tvoss> kgunn, and for apps: the music hub will solve the immediate issue of missing EOS
<alf__> greyback: hmm, I think we have a bug for this, let me see
<kgunn> tvoss: and iiuc, at the base qwindowsysinterface class gives you some guarantees you handling...so no misbehaved apps
<tvoss> kgunn, got difficulties parsing that sentence
<tvoss> :)
<kgunn> tvoss: just meaning @dealing with applications/waiting for ack's
<kgunn> tvoss: i'm understanding from his response that there's a guarantee for handlling
<tvoss> kgunn, mir would have to deal with that
<tvoss> kgunn, you have to synchronize that across process boundaries
<kgunn> tvoss: right...but from the app side too
<tvoss> kgunn, well, on the app side it's simple
<tvoss> kgunn, what is really challenging is getting that straight over process boundaries
<tvoss> suddenly, we would need timeouts and stuff
<kgunn> tvoss: sure...and it doesn't solve  the potential race you highlighted to them
<alf__> greyback: Hmm, I can't find a bug for this exactly (error opening DRM device + error 22 (EINVAL)), but I do remember people were discussing some issues with nouveau
<greyback> alf__: ok, I'll log a bug anyway
<alf__> greyback: "fails to start frequently", which I guess means sometimes works?
<greyback> alf__: yeah, seems to
<greyback> alf__: so I do a fresh boot, "sudo stop lightdm" and try mir_demo_server_shell
<greyback> alf__: I'm not missing anything obvious, am I?
<alf__> greyback: ok, btw you don't need to stop lightdm, you can start mir in e.g. VT1 (although if you get a strange crash you may not be able to vt away in some cases), so keep an ssh connection ready
<alf__> greyback: what happens if you don't stop lightdm, does it help?
<alf__> greyback: ok, do you run sudo mir_demo_server_shell?
<alf__> greyback: s/ok/oh/
<greyback> alf__: just rebooting to try without stopping lightdm, gimme a min. Yep always sudo
<alf__> greyback: ok, thanks
<greyback> alf__: "address already in use" - aha USC is running as mir server....
 * greyback digs into help file to find right switch to use nesting
<alf__> greyback: hmm, so you are running USC... I guess in that case you should stop lightdm, but I wonder if doing so properly stops USC.
<greyback> alf__: if I stop lightdm, USC still running. Killing bad
<alf__> greyback: killing bad, for it or for your session? :)
<greyback>  alf__ if I kill, I get the DRM error
<greyback> and general life rule
<alf__> greyback: if you leave it running can you run the demo server normally?
<greyback> alf__: nested mode should work with this, right: sudo mir_demo_server_shell --host-socket /tmp/mir_socket -f /tmp/another_mir_socket
<alf__> greyback: right, although note that nested servers live inside the context of the host server, so only visible in the host server's VT
<greyback> alf__: I didn't know that
<greyback> makes sense tho
<alf__> greyback: they work by using a surface the same way a normal application does
<alf__> greyback: but that (host) mir surface is the framebuffer for all apps connecting to the nested server
<greyback> alf__: gotcha
<alf__> greyback: but in any case, stopping USC and starting a demo server should work. In which VT are you trying to start the demo server?
<greyback> alf__: it is working as nested anyway
<greyback> alf__: so seems killing lightdm screws up the DRM state
<greyback> I want to find a clean way to stop USC
<greyback> mterry where are you...
<kgunn> greyback:  i think mterry has the worst wifi ever
<greyback> will resort to mail
<greyback> alf__: I suspect that USC is hanging on shutdown, and so not cleaning up the DRM state. Have asked mterry about it, will see what he says
<alf__> greyback: ok, ensure it's getting stopped normally (not -9)
<greyback> alf__: right, it's not. I gets a SIGTERM, but just sits there. So teardown isn't happening for some reason
#ubuntu-mir 2014-03-25
<mterry> kgunn_, poke!
<mterry> kgunn__, poke
<mterry> If anyone can test and confirm that with latest mir/devel, unity8 & keyboards have the weird reaction that keypresses "fall through" to shell behind it -- seemingly because the keyboard surface doesn't switch to the "maximized" Mir state
<mterry> Why might that be?
<racarr> mterry: Always with the good news.
<mterry> racarr, :)
<racarr> I have no clue why that would happen but can look at it when I look at the screen stuff which should be first thingtomorrow
<mterry> racarr, if you are the one that ends up looking at it -- I got as far as noting that unity-mir blocks the keypresses falling through once the surface switches to the Mir maximized state in OSKController.qml.  But I didn't see why the maximized behavior would have changed
<duflu> mterry: Could it be because the OSK was written assuming the old Mir behaviour of MirMotionEvent.x/y always being relative to the screen? That changed recently and the touch events will be relative to the top-left corner of the OSK, which if it hasn't been updated will easily be off-screen :)
<mterry> duflu, it's not about the press events themselves I don't think.  Just whether the keyboard Mir surface reports that it is "maximized" or not
 * duflu wonders if the design docs define what "maximized" means for decoration-less touch devices
<mterry> duflu, plus this is a weird keyboard surface anyway
<duflu> mterry: From a high level I can tell you that input coordinates have changed. So if the position of the OSK has changed, then that will definitely be a problem
<mterry> duflu, position of the OSK shouldn't have changed.  And it appears in the same place
<mterry> duflu, it's just that Mir never sends a "state changed to maximized" event which unity-mir listens for in order to stop key presses falling through
<duflu> mterry: It *appears* to be in the same place. But if it's been converted from a fullscreen surface (with transparency) to a smaller surface positioned at the bottom of screen then that's an issue
<mterry> duflu, I see.  And you think changes in Mir might have automatically changed it from fullscreen to smaller surface?
<duflu> mterry: No, for performance we need to (and might have already) got rid of the fullscreen approach. If that happened at the same time as global input coordinates going away (which they did) then it could get confused
<mterry> duflu, in my testing, ubuntu-keyboard/unity-mir/maliit haven't changed
<mterry> duflu, just been rebuilt against mir/devel (to my knowledge -- need kgunn to confirm which branches he pulled into the silo)
<duflu> mterry: OK. Do you know the API Unity is using to set maximized? I can check if notifications might have somehow changed
<duflu> is it surface->configure(attrib, value)?
<mterry> duflu, it's not setting maximized (I'm not sure how that's done -- probably deep in ubuntu-keyboard).  It's doing this:          onStateChanged: {
<mterry>             if (__oskSurface.state === MirSurface.Maximized) {
<duflu> mterry: OK, that's not actually Mir code so I don't know. We seem to have some confusion with identical class names between projects :)
<mterry> duflu, the enum is a unity-mir one, associated with the Mir enum that you'd expect
<mterry> duflu, I assume the event also directly corresponds with a Mir one
<duflu> Who ever thought a laptop which can't ventilate while it's on your lap is a good idea?
<duflu> Oh, right, HP
<racarr> [       OK ] TestClientCursorAPI.client_may_disable_cursor_over_surface (116 ms)
<racarr> yay
<kgunn__> mterry: its dev in silo4
<mterry> kgunn__, OK.  I assume you read some of the keyboard discussion?
<kgunn__> mterry: mmm, no
<mterry> kgunn__, one moment
<mterry> kgunn__, I was debugging a problem with (I thought) my split branches
<mterry> kgunn__, but I think it's in mir/devel now
<mterry> kgunn__, the problem is that keyboard presses "fall through" and hit the shell too (or whatever is behind keyboard)
<mterry> kgunn__, because unity-mir is waiting for a state change from the Mir surface to become maximized
<mterry> kgunn__, with mir/trusty, the keyboard surface changes state correctly
<mterry> kgunn__, with mir/devel it seems not to, so the keyboard is never finished being set up by qml
<mterry> kgunn__, just heads up to test that before releasing a mir silo
<mterry> kgunn__, it also makes it annoying to test my split silo, so I held off from sending a call for testing email
<kgunn__> mterry: ack and yeah, we should fix that
<mterry> kgunn__, also... how possible is it to do a silo just for lp:~mterry/gsettings-ubuntu-touch-schemas/volume?
<mterry> kgunn__, it was supposed to be in tedg's silo, but he forgot it
<mterry> it is needed for the indicator sound-syncing and is useful for desktop (and affects desktop)
<mterry> So I'm interested in landing it separately and as soon as possible for more testing
<mterry> it has an approved FFe
<kgunn__> mterry: lemme check if someone has gsettings-ubuntu-touch-schemas
<kgunn__> mterry: looks like we can do it right now
<mterry> kgunn__, sweet
<mterry> kgunn__, robert's uploading a new lightdm too, so soon most of the deps of this split silo can be dropped
 * mterry rubs hands together
<racarr> kgunn: RAOF: Party time?
<alan_g> duflu: update_change_notification() => on_change_call()?
<duflu> alan_g: Sounds weird like "call" is somehow the primary noun (i.e. you're expecting a "call" object).
<duflu> I like "on_change" or "set_whatever_callback"
<alan_g> duflu: as in "on change call this"
<duflu> alan_g: As in "on change do ..." in my mind. Not "call"
<alan_g> OK. I'll make it "on_change()" (unless anpok or alf__ objects)
<duflu> It's an established pattern in other projects "on_foo", so "call" sounds like the event being reacted to
<anpok> i only object on the overall concept :)
<alan_g> Which concept?
<ogra_> the one from the other channel ?
<ogra_> :)
<anpok> alan_g: that we use those callbacks to trigger a redraw immediately
<anpok> but thats maybe just an implementation detail of the scene..
<alan_g> anpok: what we do now is signal "something changed" and the compositor decides to schedule a redraw sometime in the future. What we plan to do is signal "this changed" and the compositor decides whether to schedule a redraw sometime in the future. In neither case do we redraw immediately.
<anpok> ok it does not happen synchronous..
<anpok> but it if you want to make multiple changes due to some form of event processing you do not know which changes end on screen on the next frame..
<anpok> or a i missing something that ensures that the scene is in a stable state
<anpok> *am
<alan_g> As I see it the scene should only be sending notifications when in a "stable state".
<alan_g> (When things are not stable a lock should be held - and one shouldn't be making calls or callbacks (to things one doesn't "own") when there's a lock held.
<anpok> ah that would be Scene::lock what I missed
<alan_g> anpok: not really, scene::lock() is a piece of madness kdub is about to make obsolete
<anpok> alan_g: what did it protect, and how is that solved then?
<alan_g> anpok: It allows the compositor to lock and unlock the scene. The scene should manage its own locking.
 * alan_g is tempted by his usual rant about recursive mutex
<kgunn> alf__: i have an urgent item, altho, unsure how quickly we might be able to generate something
<kgunn> alf__: here let me grab a bug report real quick...
<kgunn> alf__: https://bugreports.qt-project.org/browse/QTBUG-37677
<kgunn> ....i'll give you a moment to read
<kgunn> but the outcome is that, we'd like to return false on eglswapbuffers in the instance of screen off
<anpok> kgunn: alf is on public holidays i believe?
<kgunn> anpok: thanks!...can't believe i forgot
<kgunn> he only told me 5 times
<kgunn> anpok: if you're willing to take a look, feel free...this may be one that we need to hand off across timezones
<kgunn> e.g. AlbertA might pick it up when he comes on, then duflu and then back again :)
<kgunn> but wrt eglswapbuffers, we'd return false, but not block, but also not throw EGL_CONTEXT_LOST
<anpok> false when the surface is skipped because it got occluded
<anpok> or only false when screen is off
<anpok> probably we need both
<alan_g> kgunn: that is a major rework
<kgunn> anpok: yeah...i think both cases are valid, screen off is obvious, the other is like, when you have the lockscreen on top (but other apps are still runnig)
<kgunn> anpok: screen off is the one we're trying to solve atm
<anpok> we would need to send something back to the client that the buffer was not used
<anpok> and i think swap buffers currently only blocks when switching bundle runs out of buffers hmm
<anpok> kgunn: alan_g: i dont know the mesa/egl mir platform part and the counterpart for android egl
<alan_g> anpok: kgunn it means that instead of (as well as?) blocking in the buffer swapper that the swap buffer call fails. And a protocol update is needed for that in RPC - as well as the "internal client" code for mesa and android
<alan_g> Nothing in that path is written to handle failing to swap - the assumption is that blocking is the correct behaviour
<kgunn> alan_g: anpok ...unfortunately, tvoss did his level best to argue about this blocking assumption from Qt
<kgunn> and we're in a pickle
<kgunn> we've updates to Qt5.2....and lost the ux of music playing in background (not to mention some others)
<alan_g> ack. I'm just saying "that is a major rework"
<kgunn> alan_g: ack & thanks
<tvoss> kgunn, the music player thingy is not the most important one
<kgunn> just letting you know voss & i aren't happy about it either
<tvoss> kgunn, I think it's the shell not reacting to volume buttons
<kgunn> tvoss: ack...
<kgunn> and others...telephony signals
<kgunn> gps signals/map
 * alan_g didn't choose Qt for implementing the shell.
<kgunn> :) thank you alan_g
<alan_g> tvoss: is this needed for both out of process and in-process clients or just the lattter?
<kgunn> alan_g: ok...point taken, its major rework & i would like to prevent disturbing your work
<AlbertA> what about implementing the window hide
<AlbertA> it's that doable in unity-mir or would it have to be done on all apps?
<kgunn> AlbertA: its a 2 fold problem...there is the window expose event, but per the discussion they assume eglswap can never block
<AlbertA> kgunn: oh yeah it could be a race if it's blocked and we turn off the screen
<anpok> which would be the case for those occluded apps..
<AlbertA> kgunn: standup
<tvoss> AlbertA, kgunn, alan_g, anpok another hangout might help
<kgunn> tvoss: https://plus.google.com/hangouts/_/calendar/a2V2aW4uZ3VubkBjYW5vbmljYWwuY29t.2k4udqa2ovs931siq3b5fprgkc
#ubuntu-mir 2014-03-26
<tvoss> hmmm, taking eglSwapBuffers and eglSwapInterval strict, a turned off screen does not have vsync. With that, waiting for an eglSwapBuffers with an eglSwapInterval > 0 should never return
<duflu_> tvoss: Yep. And so all compositors and apps sleep nicely when the screen is off.
<duflu_> Unless you have the fglrx driver, which was buggy there
<tvoss> duflu, I was thinking: If an application would decouple from vsync via a call to eglSwapInterval(0) in reaction to the screen being turned off, immediately returning false from eglSwapBuffers would be valid
<duflu> tvoss: Returning false sounds correct. However I have seen drivers differ and buggy with respect to return values for an "off" screen.
<mterry> kgunn, so I think the biggest risk factor with split greeter silo is the Mir bugs.  I'm going to look into the screen on/off one today a bit.  I think racarr was looking at my bugs too?  Do you know if he got anywhere?
<kgunn> mterry: not sure...but good to know...do we have logged bugs for those ?
<kgunn> to enable me to be really annoying :)
<mterry> kgunn, um.  No, probably not.  /me is bad at paperwork
<mterry> kgunn, will file
<mterry> kgunn, will work on
<kgunn> mterry: no worries....still steamy its all so new :)
<kgunn> mterry: i do know anpok_ was poking around on the flicker
<kgunn> like first few frames being transparent from greeter
<mterry> kgunn, yeah...  That is something I was willing to live with and fix later
<mterry> Not something users will always see
<anpok_> kgunn: current status is in the review
<anpok_> approved it as it is not cause by the change..
<anpok_> i tried with a non-qt greeter (basic_server + eglplasma :)) but that is not a proper greeter..
<anpok_> so I couldnt get to that sequence of turning off and on..
<anpok_> I wanted to look at the qt side of things next..
<mterry> kgunn, bug 1297876 and bug 1297878
<ubot5> bug 1297876 in mir (Ubuntu) "Screen turns on when a new session/surface appears" [Undecided,New] https://launchpad.net/bugs/1297876
<ubot5> bug 1297878 in mir (Ubuntu) "Keyboard presses "fall through" and hit surface behind them" [Undecided,New] https://launchpad.net/bugs/1297878
<anpok_> oh 1297876 is a mir issue
<mterry> kgunn, I'll look at the first one because that seems like something I could track down (see where screen turns on and work back).  But the second one looks like it requires more knowledge of Mir than I have
<mterry> kgunn, I think racarr was looking at one or both of them
<mterry> anpok_, I *think* second one is too
<kgunn> anpok_: want to dive in to 1297876...and maybe work with racarr when he comes on....
<kgunn> let's see if we can kill these quickly
 * kgunn wants to land split greeter soon!
<anpok_> kgunn: sure - this one is very annoying, thought it was in a different part of the system.
<anpok_> brb
<AlbertA> so now that facebook will buy oculus do we still have to "pass the oculus rift test"? :)
<anpok_> there is another company with augmented reality glasses
<AlbertA> sony?
<AlbertA> :)
<anpok_> or in austria there is a vr startup
<anpok_> i think we just rename it .. or have an indirection
<ogra_> AlbertA, sure you do, we need to be prepared for when we acquire facebook as sub-devision after making billions and billions in the phone market
<anpok_> "coolest displaying tec test"
<AlbertA> I kinda like passing the "morpheus test"
<AlbertA> though probably not applicable :)
<anpok_> hmm i am sure the sony equipment will work in linux likewise..
<AlbertA> unless we get ubuntu running on the ps4 :)
<ogra_> lets start small, Ubuntu Phone on the PSP first ;)
<anpok_> vita might be simpler .. no mips ...
<alan_g> AlbertA: look at DemoPrivateProtobuf
<AlbertA> alan_g: thanks
<alan_g> yw
<alan_g> Does anyone know why ConsumingPlacementStrategy exists in the codebase?
<kdub> alan_g, I don't know
<pietro10> Quick dev-related question: does Mir use libxkbcommon? Thanks.
<kdub> its one of our dependencies
<alan_g> $ grep libxkbcommon debian/control
<alan_g>                libxkbcommon-dev,
<pietro10> thanks
<kgunn> AlbertA: trying to be better about public chat...so powerd will still contain brightness value ?
<kgunn> and u-s-c will simply be a proxy for the ui in terms of requests to change that value...?
<kgunn> i assume wrt actual screen state (on/off) that's still going to end up in u-s-c ?
<AlbertA> kgunn: yes powerd will still handle the brightness logic
<AlbertA> kgunn: I was pulling that into usc but from the conversation in the morning
<AlbertA> kgunn: that was better left in powerd
<kgunn> ok
<AlbertA> kgunn: but usc will inform powerd when to act on brightness etc
<kgunn> AlbertA: makes complete sense, any hw ctl & related hw logic should be in powerd...and usc is more about policy & req/resp on powerd
<AlbertA> kgunn: yes basically usc will do the input event timeouts and display on/off, and it will inform powerd when to to dim the screen
<AlbertA> kgunn: the settings will be obtained from the sessions possibly from a sidechannel using the same server socket mir uses
<AlbertA> kgunn: or maybe we can incorporate it into display configuration - for now I'm leaning towards side channel as far as settings
<kgunn> ack
<kgunn> mterry: out of bug 1297876 and bug 1297878
<ubot5> bug 1297876 in mir (Ubuntu) "Screen turns on when a new session/surface appears" [Undecided,New] https://launchpad.net/bugs/1297876
<ubot5> bug 1297878 in mir (Ubuntu) "Keyboard presses "fall through" and hit surface behind them" [Undecided,New] https://launchpad.net/bugs/1297878
<kgunn> you really wanted help with 78 right ?
<kgunn> just wanted to make sure i was asking racarr about the right thing
<kgunn> or...asking him to look at the right thing
<mterry> kgunn, both are blockers, but I think I can at least investigate 76 myself.  Plus 78 affects more than just split mode, so it's more critical.  I think racarr was looking more into 76 so far, but I'm not sure of his progress in either
<kgunn> agreed...78 looks like the nastier of the 2
<kgunn> in terms of ux effect
<mterry> kgunn, 76 is mad annoying bro
<mterry> but yes
<kgunn> mterry: sorry...i meant 76
<kgunn> no nvmd...
<mterry> kgunn, they are both super annoying
<kgunn> ah..my eyes o.O
<mterry> kgunn, one drains battery and is startling.  One makes keyboard useless
<kgunn> keyboard useless is worse imho
<mterry> sure
<mterry> I'm on the same page  :)  I just also hate 76
<racarr> should I just
<racarr> flip a coin/
<racarr> ok no 78
<racarr> mterry: kgunn: Anything known so far on 78 besides that is in the bug?
<mterry> racarr, no
<racarr> cool
<racarr> ill be on it in an hour or so (have to do the usual flash phone clean, build clean stack, etc...)
<kgunn> bregma: bschaefer ...meant to ask
<kgunn> oops, wait...moving
<mterry> racarr, regarding the 76 issue, your original instincts were right.  If I uncomment the "power_mode = default_power_state" bits in DefaultDisplayConfigurationPolicy::apply_to, problem goes away.  In your unity-mir branch, you say nested mode should do nothing for apply_to.  Should NestedDisplay() just not call apply_to?
<racarr> mterry: Which branch of unity-mir are you using against mir devel? trunk isnt building
<racarr> mterry: Err...let me think
<mterry> racarr, whichever ended up in silo 004
<mterry> kgunn_, which branches did you use for unity-mir in silo 004?
<racarr> mterry: Err...so I cant remember exactly what I said in my unity-mir branch
<racarr> I think it would make sense to say though, for example that
<racarr> the nested server should inherit the display configuration from the system compositor by default
<racarr> so the nested server could use a
<racarr> DisplayConfigurationPolicy (overriding the_display_configuration_policy)
<racarr> that doesnt initialize things to their default state
<racarr> re-initialie/whatever
<kdub> if they're different defaults, why not just provide an appropriate default implementation instead of overriding things
<racarr> mterry: Ok where does silo 4 come from!
<racarr> I guess maybe I can use binary packages of unity-mir
<racarr> but...I think server abi broke
<racarr> as early as like
<racarr> every day for the past week
<racarr> lol
<racarr> so im not sure how this is possible
<kgunn_> mterry: one moment
<mterry> racarr, https://launchpad.net/~ci-train-ppa-service/+archive/landing-004/+packages
<kgunn_> mterry: https://pastebin.canonical.com/107219/
<kgunn_> racarr: ^ if needed
<racarr> hmm I only see one unity-mir branch
<racarr> which doesnt have the update
<racarr> that the_session_authoried now has to implement screencast_is_allowed
<racarr> maybe I got my local branches mixed up just a sec
<racarr> mterry: Err, so I am not sure how you built mir/devel
<racarr> against these packages
<mterry> racarr, I apt-get sourced the package in the silo
<racarr>  / are there missing um branches...
<racarr> the mir package?
<mterry> racarr, and worked off that.  That way, no rebuilding
<mterry> racarr, yeah
<racarr> oh
<racarr> thats at least a week behind mir devel it seems
<racarr> maybe more? screencast has been in for forever
<mterry> racarr, well, good for fixing bugs anyway
<racarr> mm
<racarr> lemme get the PPA then
<racarr> except apt-get update wont finish lol thats good
<racarr> mterry: Just to make sure I understand how I am supposed to reproduce it
<racarr> it should just show up in this silo
<racarr> so there is nothing to isolate it to mir/mir devel in particular
<mterry> racarr, yeah
<mterry> racarr, uh.  76 needs silo.  78 should be reproducable with stock unity8 and silo
<mterry> racarr, haven't tested 78 with stock unity8 and mir/devel
<racarr> right but at this point it could be anything in the silo except unity8 right
<racarr> i.e. papi/unity-mir
<mterry> racarr, well papi/unity-mir are just rebuilds agains tmir
<racarr> er...do you have to do something besides writable-image to make
<racarr> apt work on the phones now
<racarr> I am having all sorts of issues
<mterry> racarr, no...
<racarr> :/ apt-get update will never finish even though I can access the servers it claims to stall on
<mterry> racarr, what errors?
<racarr> and dist-upgrade is complaining about no space left ond evice
<racarr> even though its a clean flash
<mterry> racarr, I've gotten the stall before, a reboot can fix that sometimes
<racarr> I dont even know space on what partition...and I check mount -v and see there are now liek
<racarr> over 20 partitions lol
<mterry> racarr, no space is an odd one after clean refresh.  two things can help:
<mterry> apt-get purge 'language-pack.*' mir-test-tools
<mterry> rm -r /var/cache/apt/archives/
<racarr> I cant even run apt-get purge
<racarr> because of no space
<racarr> but I literally
<racarr> emptied /var/cache
<racarr> hmm
<racarr> I guess I will reflash
<racarr> with bootstrap
<racarr> hopefully my flash isnt dieing
<mterry> racarr, bootstrap shouldn't be needed, but couldn't hurt
<racarr> shouldnt be right but
<racarr> dont know what to do at this point
<racarr> I mean I literally just flashed a new image without bootstrap immediately prior to this.
<mterry> racarr, :(
<mterry> racarr, did you accidentally do dd < /dev/random > /datafile?  common mistake
<racarr> mterry: Maybe, thats my password
<racarr> so maybe I entered it in the wrong prompt
<mterry> :)
<racarr> or maybe my flash is dead
<racarr> lol ok everything seems happy now.
<racarr> just going to pretend that never happened
<racarr> my usb cable is pretty flaky maybe the flashing process went wrong or maybe my flash really is failing
<racarr> maybe it was just overheating *shrug*
<mterry> :-/
<mterry> racarr, still before you re-install all the mir deps, you should probably run " apt-get purge 'language-pack.*' mir-test-tools" to help avoid in future
<racarr> mterry: good call
<racarr> woah
<racarr> that was quite
<racarr> the boot up experience
<mterry> racarr, with the PPA?
<racarr> yes
<racarr> I can see also the osk
<racarr> literally cant be dismissed lol
<mterry> :)
<racarr> I also got it stuck rotated somehow
<mterry> If you re-summon it, it can come back unrotated
<racarr> hmm ok well have to get unity-mir debug symbols now...
<racarr> MirSurfaceManager::surfaceAttributeChanged is at least being called when the OSK comes up so cant understnad why
<racarr> the surface wouldnt be getting the state
<racarr> but we shall see
<racarr> interesting
<racarr> surface manager cant find the unity-mir side
<racarr> osk surface at the time of
<racarr> attribute
<racarr> setting
#ubuntu-mir 2014-03-27
<racarr> ok I need a break for a while...left some documentation ont he bug and assigned it to me
<racarr> but should be back in an hour or so to continue
<racarr> The program is stopped at a permanent breakpoint, but GDB does not know
<racarr> how to step past a permanent breakpoint on this architecture.  Try using
<racarr> a command like `return' or `jump' to continue execution.
<racarr> what is this -.-
<racarr> MirSurfaceManager::sessionCreatedSurface (this=0xa86cce68, surface=0xabe06b68) with surface name 'MaliitOnScreenKeyboard'
<racarr> MirSurfaceManager::surfaceAttributeChanged surface = MaliitOnScreenKeyboard (this=0xa86cce68, surface=0xabe0adc4, attrib=0, value=6)
<racarr> unfortunately we have implemented a new feature where surfaces change address
<racarr> :(
<duflu_> racarr: We did?!
<duflu_> There must be a std::move or something
<racarr> maaaaybe? I am more suspiscious of memory corruption
<racarr> or something
<duflu> Cosmic rays
<racarr> lol very reproducible cosmic rays
<racarr> nvm its abi
<racarr> no it wasnt lol
<duflu> Free karma: https://code.launchpad.net/~vanvugt/mir/frontend-server/+merge/207602
<duflu> Spooky while the large planes fly low over my house to and from the southern Indian Ocean search area
<duflu> Awesome. Now I'm involved in all the code reviews, I won't be doing much coding :)
<duflu> alan_g: One of those links is invalid and the other seems to be pure Mir, no Q-anything !?
<alan_g> duflu: it has been a while since I followed them. Let me dig...
<duflu> dandrader, Saviq: Can you point me to the code of the Qt-Mir-Compositor ?
<Saviq> duflu, https://code.launchpad.net/~unity-team/+junk/qpa-mirserver
<duflu> Saviq: Cool thanks
<Saviq> cheers
<alf__> duflu: Renamed AncillaryBuffersConfig to GLConfig, if you get a chance please take look before EOD, so I can move forward with this
<duflu> alf__: Technically passed EOD ;)
<duflu> past
<anpok> alf__: AlbertA: kdub: alan_g: should setting focus to a session also mean applying the display configuration of that session?
<anpok> In the scenario I look at u-s-c sets focus to the greeter.. while display is off
<anpok> as a reaction to the focus switch the mediating display changer picks a stored display configuration which has the power state on
<anpok> and hence turns the display on
<anpok> i tend to believe that usc should be aware that the display is off and should set the focus to the greeter, or someone along the lines should check if the focused session is hidden.. (but maybe it isnst.. have to check)
<alf__> anpok: @focusing=>apply display config, yes that is the intention if the session has set a custom display config
<anpok> and we dont want to delay that if display is off - or make an exception for the power state setting ..
<anpok> in other words focus also implies - turn it on!
<alf__> anpok: what will change the focus while the display is off?
<anpok> lightdm+usc do that, in the split greeter rewor - if I understand it correctly they lightdm spawns another when display is turned off
<anpok> as soon as the greeter is done with startup and has submitted its first frame to the session usc sets the focus, so that when display is turned on it is immediately visible..
<anpok> *rework
<anpok> -they
<anpok> brb need to to get some food
<anpok> i will see if usc is somehow aware of the display state
<ice9> what are the advantages of mir over wayland or why Canonical decided to make its own display server?
<anpok> i dont want to get into a debate, but since this is digital communication I have the urge to correct wrong statements.. wayland is an ipc system. You have to ask why mir did not use wayland as an ipc backend.
<alf__> ice9: See bottom of https://wiki.ubuntu.com/Mir/Spec
<anpok> alf__: another thought on that topic - is it valid to have the power mode as a member of the display configuration?
<alf__> anpok: Go not to the elves for counsel, for the will say both yes and no :)
<anpok> hehe
<anpok> well the dwarves said I should shut up and just fix the bug and then continue digging..
<alf__> anpok: Like the brightness issue we were talking about yesterday, power mode conceptually belongs in "display configuration" but at the same time its use case differs from normal display configuration (setting up the display resolutions etc)
<anpok> yip
<anpok> but differs mostly because we like it to change more frequently / aor daptively to other events
<anpok> *"or a"
<alf__> anpok: right, so we should either introduce a new interface to do so, or reuse the same interfaces (i.e. DisplayConfiguration structs) but more intelligently (e.g. the what-changed flags we were talking about yesterday).
<alan_g> Hmm trying to build unity-mir against devel:
<alan_g> Linking CXX executable unity-mir-test-app
<alan_g> /home/alan/local/lib/x86_64-linux-gnu/libmirserver.so: undefined reference to `mir::load_library(std::string const&)
<alan_g> Where did mir::load_library go now?
<dansuf> Hi, could you look at this log http://pastebin.com/tSnra0F7 ? I'm porting my device to ubuntu-touch and I'm stuck at black screen.
<dansuf> also, in var/log/lightdm/unity-system-compositor.log
<dansuf> terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<std::runtime_error> >'
<dansuf>   what():  error binding buffer to texture
<anpok> dansuf: dont run away
<anpok> kdub: he is back ^
<dansuf> anpok: I don't understand
<anpok> dansuf: last time kdub wanted to help you but you dropped out of IRC
<kdub> the log says EGL_BAD_CONTEXT, not sure what might be going on
<kdub> i do see some errors around not being able to prod various files too
<kdub> also, why is it reporting resolution 320x480, but the build keys look to be mako?
<dansuf> kdub, it's not mako, I just used w-flo's adreno binary drivers for adreno because he wrote it solved some problems
<dansuf> kdub, w-flo was porting touch to vision
<dansuf> kdub, he made a commit in his repository where he updated the drivers and wrote which issues it solved so I copied them
<dansuf> kdub, and now i can run more tests
<dansuf> kdub, test_hwcomposer doesnt seem to fail now
<kdub> how about mir_demo_standalone_render_to_fb?
<kdub> you should get an animation
<dansuf> kdub, I don't see this program in my path
<dansuf> Maybe I have too old version
<dansuf> I think I have mir 1.6 or sth like that
<kdub> mir-demos package
<kdub> may as well try the new stuff, we're fixing it all the time :)
<dansuf> kdub, i have to leave for 10-20 minutes
<dansuf> but i'll be back..
<dansuf> I'm back
<racarr> terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<std::runtime_error> >' what():  /usr/lib/arm-linux-gnueabihf/libmirplatformgraphics.so: undefined symbol: _ZNK5boost15program_options29value_semantic_codecvt_helperIcE5parseERNS_3anyERKSt6vectorISsSaISsEEb
<racarr> mer?
<racarr> thats a great symbol name
<dansuf> kdub, mir-demos are installable through apt-get?
<kdub> yep
<dansuf> haha, and the internet isn't working on my device
<dansuf> I'll try to chroot into ubuntu on adnroid and in that way install demos, should work
<racarr> hmm if I ld_preload boost options
<racarr> (why isnt mirplatformgraphics linked against it? not sure, also not sure why this doesnt present otherwise/ust started)
<racarr>   what():  /usr/lib/arm-linux-gnueabihf/libmirplatformgraphics.so: undefined symbol: _ZN3mir7options13off_opt_valueE
<kdub> i thought i saw a review about this
<racarr> https://code.launchpad.net/~alan-griffiths/mir/add-mirplatform-to-dependencies/+merge/213077 maybe related
<dansuf> kdub, I just installed the newest daily touch and now logcat gives me more info http://pastebin.com/xwYz3BYP (I might have forgotten to make some changes I did to the previous version which could cause this more extended log)
<dansuf> I will now try to install demos (it can take some time)
<dansuf> kdub, I've installed demos and I get the animation
<kdub> excellent
<dansuf> it is moving image with a green border
<dansuf> and lots of "mdp not donfigured" in logcat because i diasbled it
<kdub> dansuf, of course, but even at that, its a good step
<kdub> the next step would be try running some of the server/client binaries together
<kdub> like mir_demo_server_shell (in one terminal) and (mir_demo_client_egltriangle) in another
<dansuf> http://pastebin.com/4awGHdir
<dansuf> kdub, after running triangles, i'll try the others now
<racarr> RAOF: Ping?
<kdub> dansuf, so it looks like the server is having trouble using the buffers that the client is sending to it
<kdub> does dmesg look suspicious?
<dansuf> kdub, nothing interesting
<kdub> hmm, getting the display going is usually the tougher part
<kdub> probably something having to do with the egl errors that were in the logcat
<dansuf> kdub, surfaceflinger also fails and gives egl bad context
<dansuf> kdub, thanks for trying to help me, I'll do more research and I'll maybe write to people developing device-specific part
<kdub> dansuf, yw, good luck!
<kdub> once you get sf past that problem, mir will probably be past that problem too
<RAOF> racarr: Yo!
<RAOF> racarr: I'm not sick today! Yay!
#ubuntu-mir 2014-03-28
<racarr> RAOF: YAy not sick welcome back
<RAOF> What can I do for you?
<racarr> I was just wondering if you had any thoughts on cursor name being a string v. an enum
<racarr> daniel suggests an enum...it seems reasonable as most toolkits suggest
<racarr> an enum
<racarr> is there any reason to make it a string? weird cursor names, etc?I just remember reading something along time ago about firefox requesting a cursor calle like hfasu8u398u32xxx7 or something
<racarr> so you had to have that in your xcursor theme
<racarr> lol
<RAOF> :)
<RAOF> So, one reason to make it a string would be so that we don't have to bake in every weird and wonderful cursor.
<RAOF> racarr: Is this in response to a particular merge request? I should probably read in context.
<racarr> RAOF: Still cursor-spike-phase-1 ;)
<racarr> The others are ready though lol (well almost...still cleaning up one test)
<racarr> that is the one reason to make it a string which is my thought too aha...I mean in the toolkit you still have
<racarr> to have a big switch on the toolkit enum types to translate it to mir types
<racarr> so might as well use a string...?
<RAOF> I think I prefer strings, yes.
<RAOF> With #defines for MIR_CURSOR_CROSSHAIR, etc.
<racarr> mm yeah defines would be good I guess
 * RAOF reviews in ernest.
<racarr> RAOF: Thank you :) ill be back in an hour or two so can iterate if you have thoughts.
<racarr> this https://www.bitwig.com/en/home/recent-news.html got released today so I am going to go play for a while...
<racarr> (Software?! For my operating system?!)
<RAOF> Funky!
<RAOF> :)
<mlankhorst> morning
<alan_g> alf__: do you have time for: https://code.launchpad.net/~alan-griffiths/mir/remove-one-of-the-redundant-surface-factories/+merge/212923?
<alf__> alan_g: looking
<alan_g> thanks
<alf__> greyback: if you want to test you will need both lp:~afrantzis/mir/android-gl-config and lp:~afrantzis/mir/nested-gl-config for nested
<alf__> greyback: otherwise wait until they reach devel :)
<greyback> alf__: noted, thank you
<jhodapp> Anybody know why running a QtTest on a target device results in it hanging trying to connect to Mir? I have this backtrace: http://pastebin.ubuntu.com/7169856/
<kgunn> bschaefer: i tried but i got a blocks-demo crash file
<kgunn> bschaefer: https://drive.google.com/a/canonical.com/file/d/0B4GvOYxwuvpFeHdsQi04Zk5nR0E/edit?usp=sharing
#ubuntu-mir 2014-03-30
<RAOF> jhodapp|afk: Looking at your backtrace, I think you'll also have a second thread that's waiting in read() or connect(); this is waiting for the response from the server, which your app isn't getting.
#ubuntu-mir 2015-03-23
<alan_g> duflu_: are the many autolanding failures over the weekend accounted for? Or is there more to fix?
<duflu_> alan_g: There are a few. Fixed one on trunk so far. More unresolved on armhf (valgrind). Working on getting logs of those and backporting the first fix to 0.12
<duflu_> So much broken
<alan_g> Do you have it in hand - or can I jump in somewhere? (Where?)
<duflu_> alan_g: I'm running out of day time. I expect I can hand this over soon. Just need to attach detailed logs: https://bugs.launchpad.net/mir/+bug/1435186
<ubot5> Ubuntu bug 1435186 in Mir "valgrind on armhf fails with with many errors" [High,New]
<duflu_> alan_g: Or is it just a mistake that we expect valgrind to work on armhf?
<alan_g> We got optimistic after alf_ generated some suppression files.
<alan_g> It *ought* to work. But seems too much work.
<duflu_> alan_g: I mean, did it ever work?
<duflu_> I don't remember
<alan_g> It did, but we had to suppress errors in libraries we don't own (IIRC  libc). That's fragile.
 * duflu checks the suppressions again
<duflu> alan_g: Yep, we just need more suppressions for system libraries.
<duflu> alan_g: Handover: https://bugs.launchpad.net/mir/+bug/1435186
<ubot5> Ubuntu bug 1435186 in Mir "valgrind on armhf fails with with many errors" [High,New]
<alan_g> ack
<alf_> duflu: alan_g: the integration tests have a lot of hopefully false memory errors
<alf_> duflu: alan_g: a single variable that valgrind thinks is uninitialized causing a cascade of memory errors?
<duflu> alf_: Don't know. The rabbit's hole is too deep for this evening
<duflu> alf_: P.S. I updated the 0.12 branch with one fix
<alf_> duflu: great, thanks
<alan_g> alf_: plausible. Got a fix?
<alf_> alan_g: no, just a theory
 * alan_g finally gets mako talking to ubuntu-device-flash again 
<alf_> alan_g: part of the problem may be https://bugs.launchpad.net/ubuntu/+source/valgrind/+bug/1284653 , but it's possible we will need to update our own custo suppression files too
<ubot5> Ubuntu bug 1284653 in valgrind (Ubuntu) "valgrind packages ouf of sync with current glibc version (2.19)" [Undecided,Fix released]
<alf_> alan_g: oops, that's the old bug, the new one is: https://bugs.launchpad.net/ubuntu/+source/valgrind/+bug/1435261
<ubot5> Ubuntu bug 1435261 in valgrind (Ubuntu) "valgrind packages ouf of sync with current glibc version (2.21)" [Undecided,New]
<alan_g> alf_: That could be
<alan_g> so it might sort itself out when that hits archive. Maybe we should just disable valgrind?
<alf_> alan_g: That's one option. Alternative, we could temporarily provide a 2.21 version of the default suppressions in Mir. I will push an MP for this, to see if it makes any difference with CI.
<alf_> *alternatively
<alan_g> alf_: OK, thanks
<alan_g> alf_: if your valgrind fix works in CI we should push it straight to trunk. Agreed?
<alf_> alan_g: sure
<alan_g> kdub: are you likely to finish off lp:~kdub/mir/demo-titlebars today? (Or shall I?)
<kdub> alan_g, I can try to today
 * alan_g is trying to get all the "polish" to CanonicalWindowManager landed before trying to move it to libmirserver
<alan_g> racarr: @lp:~kdub/mir/demo-titlebars Do you think there's a better way that's already supported? Otherwise, I think we're better to land something (in the examples) that demonstrates the pain caused by the existing API. (And use it to justify improvements to the API to clean it up.)
<racarr> alan_g: That's fine too I guess...I kind of had the thought that its not
<racarr> doing enough yet to be realistic
<kdub> have to start somewhere :)
<alan_g> What we need to get to is it being easy for users to do useful stuff. At least this demonstrates is that it is possible to do something.
<racarr> well obviously neither of those points can be argued with ;)
<racarr> I am fine with it
<racarr> I think my comment wasjust coming from
<racarr> the fact that I expect dealing with resize etc from the observer
<racarr> will be the "difficult bit"
<alan_g> who wants to do it from the observer? Just do it from the controller.
<alan_g> I.e. the WM policy knows it is resizing the window, it can easily resize the decorations.
<alan_g> The observer is just to let the "views" know a change has happened.
<racarr> yes sorry thought-typo
<racarr> thats still the difficult bit to do
<racarr> e.g. how do you make it atomic?
<alan_g> The controller is the only thing that updates the model, it already serializes updates.
<racarr> alan_g: Really?
<racarr> I am talking about hte case where say the compositor chooses to render inbetween
<racarr> updating the surface and decoration surface
<alan_g> OK, that's not been tackled
<alan_g> I intend to do some rework on scene locking though
<racarr> mm
<racarr> I dunno if its a locking rework or a
<anpok_> hm this could be resolved by some sort of batch processing of requests/events
<racarr> changeset/modifications API
<racarr> yeah
<anpok_> or yes.. explicit locks.. but this feels complicated
<anpok_> for the batch thing you would already serialize all notifications or requests that might cause changes to the scene
<alan_g> with C++14 we can have shared mutexes and only the shell grabs exclusive access
<racarr> I guess in my mind
<racarr> and we see here I have runaway with unjustified thoughts
<racarr> but
<racarr> the solution to this to avoid exposing synchronization
<racarr> primitives
<racarr> was to add
<racarr> hierarchy to
<racarr> the surface stack
<racarr> so that the decoration and surface are for example part of a window element which acts as a container
<racarr> and I guess, yeah is also a surface (though not a window...though really there are a few ways we can shove around this terminology)
<racarr> so anyway you resize or move the parent
<racarr> and the children behave appropos
<anpok_> why would adding hierachy avoid the need to expose synchronization primitives?
<racarr> Because you just call
<racarr> parent_surface->resize
<racarr> and the scene internally
<racarr> lock()
<racarr> resize1()
<racarr> resize2()
<alan_g> The window manager needs to be in charge anyway - because it can change the decorations "appropriately".
<racarr> Maybe
<alan_g> We don't need too much intelligence in the scene - it is just there for the views to observe.
<racarr> I kind of have this other idea...but am struggling to articulate it
<racarr> but for like effects...e.g. window expose and other animations
<racarr> it seems kind ofcumbersome to only have
<racarr> the decoration assosciation in the controller
<racarr> eh
<racarr> maybe just a model im mentally attached to rather than anything important
<alan_g> Rule of thumb: if you can't name two components that care about it it should not go in the scene, it should go in the component that cares.
<racarr> alan_g: Hmm thats a nice idea
<racarr> I guess Im yet to think of the shell as a single component though
<racarr> a.k.a. the thing that does the window spread animations and
<alan_g> That's because it got mixed up in scene (and is only partially extracted even now)
<racarr> the frontend window management controller
<racarr> may not really be the same component right...
<racarr> hmm
<anpok_> racarr: hm I believe not only for rendering, also for each kind of change operation on the scene.. system behavior will be harder to reason about if anything can change between micro steps..
<racarr> yeah thats a good point to think about too
<anpok_> i am all in favor of queueing the operations into batches.. i.e. at the start of processing you could define whatever is currently in the queue as you current workload
<anpok_> and when that is done, redraw may happen ..
<anpok_> every change that comes in later .. comes later..
<anpok_> as a start
<anpok_> one might want to refine that and differ between changes caused by external triggers or changes that are transitively required due to changes of the initial workload
<racarr> http://git-man-page-generator.lokaltog.net/
#ubuntu-mir 2015-03-24
<duflu> mterry: We're not tied to my CMake prototype at all. In fact I might context switch now and not get back to this task for another week or so...
<RAOF> vgdb-error is basically the best thing ever.
<RAOF> Ah, good. It's a race.
<RAOF> That'll make it easier.
<duflu> Hmm, why is upstart being added *back in* as part of a vivid update?
<RAOF> It's still session init, right?
<duflu> greyback_: Is there a way to get through the Unity8 welcome wizard with a mouse? I can't seem to do the right edge swipe
<duflu> Tried two machines
<duflu> Never mind... G'night
<greyback_> duflu: hmm, quite possibly a bug.
<duflu> Yeah seems like it
<duflu> Later...
<greyback_> duflu: o/
<alf_> Saviq: greyback_: Do any recent unity8/dash updates contain performance improvements?
<greyback_> alf_: I can see nothing performance specific in the unity8 log
<greyback_> alf_: dash looking good with double-buffering?
 * greyback_ would be surprised
<greyback_> dash often used to go over 16ms per frame
<alf_> greyback_: Yes, I am suprised too, but I will wait for some independent confirmation of my results
<greyback_> alf_: ok
<greyback_> perhaps some perf improvements landed in qt5 recently
 * greyback_ reflashes
 * alf_ checks list of updated packages in phone
<alf_> greyback_: so there was an upgrade from 5.4.0 to 5.4.1
<alf_> greyback_: But I can't see anything interesting in the Qt 5.4.1 changelog
<greyback_> alf_: nor do I
<greyback_> alf_: think there's 1 fix which has a positive impact on rendering performance, as yeah I see a definite improvement on the devel-proposed image right now
<alf_> greyback_: which fix?
<greyback_> alf_: https://code.launchpad.net/~aacid/thumbnailer/fix_dbus_blocking/+merge/251065
<alf_> greyback_: nice, thanks
<kgunn> alf_: trying to sort this one out https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1418456
<ubot5> Ubuntu bug 1418456 in unity8 (Ubuntu) "unity8 assert failure: *** Error in `unity8': double free or corruption (fasttop): 0xb20055a0 ***" [Medium,Confirmed]
<kgunn> you one comment seems pretty certain it's due to the other 2 bugs you referenced
<kgunn> but the 1414999 bug seems fixed in mesa? (so unrelated?)
<kgunn> oh nvmd...could be related, i see it's unity8 desktop
<alf_> kgunn: right, the core problem is not being able to get an EGL context, possibly because of unsupported gpu (possibly fixed by Mesa 10.5 depending on the gpu). The "double free" part of the problem was an because we didn't tear down the EGL driver correctly when the error happened (fixed).
<alf_> s/an because we/that/
<anpok> hm I wonder if this patch is still shipped with mesa: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/vivid/mesa/vivid/view/head:/debian/patches/i915-dont-default-to-2.1.patch
<anpok> alan_g: hm what do you mean by adding another level of indirection?
<anpok> https://code.launchpad.net/~andreas-pokorny/mir/stub-input-platform/+merge/252760/comments/631055
<anpok> i tried to avoid running into the symbol mangling issues caused by having an anonymous type in the signature, and do not see a way to keep the constructor private
<alan_g> anpok: well, you could define friend builder function that's called in make_module_ptr, or make the constructor protected and have a local derived class in make_module_ptr
<anpok> alan_g: brilliant!
<alf_> Saviq: camako: I have trouble running the unity8 autopilot tests on the phone. Has the way we run them changed?
<alf_> e.g. phablet-test-run -n -r 0000 -p unity8-autopilot unity8 doesn't work for me (can't find unity8-autopilot)
<alf_> greyback_: ^^ Any ideas?
<alf_> greyback_: Saviq: camako: arggh, I just had to run apt-get update :/
<greyback_> alf_: yeah that'll do it
<camako> alf: :-)
<racarr> privatizing event header
<racarr> feels good :D
<racarr> NO MORE INPUT
<racarr> I mean privatizing the old event header of course
<racarr> ;)
#ubuntu-mir 2015-03-25
<alan_g> anpok: duflu_ any last reviews? https://code.launchpad.net/~alan-griffiths/mir/make-window-management-configurable/+merge/253725
<duflu> alan_g: Adding a comment, but not blocking
<anpok> alan_g: interesting side note on clang compilation error, gcc only allows it when the constructor is a constructor template
<alan_g> Weird. I'd be very surprised if a using directive for the constructor doesn't determine the access. Almost worth posting a test case to the standards reflector.
<alan_g> I'd have to look at the wording, but I naively(?) expect it to work the same as with member functions.
<anpok> filed a bug report at llvm
<anpok> https://llvm.org/bugs/show_bug.cgi?id=23018
<ubot5> llvm.org bug 23018 in C++ "clang claims an inherited constructor protected when declared public with using" [Normal,New]
<anpok> oh what a curious bot
<anpok> alan_g: do you prefer 2014-2015 or 2015 for new files (I (inconsistently) used the former for files that I already proposed in december)
<alan_g> I think it is all silly. But it should reflect the date the intellectual property was created.
<alan_g> "silly" is these comments, not IP rights.
<anpok> :)
<alan_g> /rant=on The only reason I know of for such comments is that in the USA before 1966(ish) one had to assert the rights to be able to enforce them. And even in those days, in that jurisdiction you could put them at the bottom of the file where they are not in the way.
<tsdgeos> guys
<tsdgeos> i'm having issues with an autopilot injected keypress not being detected by the event dispatcher
<tsdgeos> any iea what may be wrong?
<tsdgeos> it's the first one
<tsdgeos> i..e it injects p a s s w o r d
<tsdgeos> and sometimes p is lost
<anpok> surface is not yet focused?
<tsdgeos> it should
<anpok> or where do you track the loss of the p?
<tsdgeos> at least the qml side says it is
<tsdgeos> at the mir level
<tsdgeos> well qtmir
<tsdgeos> i.e. on a dispatch() implementation
<anpok> hm
<tsdgeos> funny thing
<tsdgeos> is that if i add a wait in the test
<tsdgeos> then it seems to not fail
<anpok> where does that injection happen? at usc?
<tsdgeos> but i can't find what isn't yet settled
<tsdgeos> since it all seems to have been created ages ago
<tsdgeos> the surface, the event feeder, etc
<tsdgeos> anpok: it's written to uiput device
<anpok> evdev emulation?
<tsdgeos> i guess my next step would be adding some debug somewhere in mir
<tsdgeos> but recompiling mir not cool :D
<anpok> hm then you could enable input reports at usc/u8
<tsdgeos> how do i do that?
<anpok> http://unity.ubuntu.com/mir/component_reports.html
<anpok> brb
<tsdgeos> i have a feeling of having asked that question before
<anpok> :)
<tsdgeos> and having got that url and could get it to work :D
<anpok> note that u8 is both server and client
<tsdgeos> but let me see if i'm better now
<alan_g> tsdgeos: you're going through USC + U8 + app? Note that USC waits for the second posted frame before granting focus to u8 (which IIUC) waits for the first frame before giving focus to the app - that can add up to a delay.
<tsdgeos> alan_g: the app and surface have been on screw "for ages"
<tsdgeos> that's what's puzzling me
<tsdgeos> i wonder if it's even the evdev device eating the write() to it
<alan_g> Weird.
<tsdgeos> i'm using those env vars
<tsdgeos> and see nothing
<tsdgeos> where should MIR_SERVER_INPUT_REPORT=log
<tsdgeos> write that log?
<tsdgeos> stdoutput?
<alan_g> tsdgeos: yes, but I think that's redirected to a log file somewhere
<tsdgeos> you mean ~/.cache/upstart/unity8.log ?
<tsdgeos> i can't see it in there
<alan_g> greyback: you know where the logs go? ^^
<greyback> unity8's logs? yeah, tsdgeos has it
<tsdgeos> and it should end up in there if started with MIR_SERVER_INPUT_REPORT=log ?
<tsdgeos> is there anything else i need to enable?
<greyback> not that I'm aware of. But by your tone, I'm guessing it's not working ;)
<greyback> alan_g: that does work for a nested server too?
<alan_g> it always has. I can double check...
<tsdgeos> MIR_SERVER_NAME=session-0 MIR_SOCKET=/run/mir_socket QT_QPA_PLATFORM=mirserver MIR_SERVER_INPUT_REPORT=log  /usr/bin/unity8
<tsdgeos> doesn't seem to give me much
<anpok> and MIR_CLIENT_INPUT_REPORT=log
<tsdgeos> went with
<tsdgeos> MIR_SERVER_NAME=session-0 MIR_SOCKET=/run/mir_socket QT_QPA_PLATFORM=mirserver MIR_SERVER_INPUT_REPORT=log MIR_CLIENT_INPUT_REPORT=log MIR_CLIENT_INPUT_RECEIVER=log  /usr/bin/unity8
<anpok> maybe that log file is just a reopened std out? then maybe also redirect std out..
<tsdgeos> nothing either
<anpok> oops
<anpok> yes input receiver ..
<tsdgeos> that should give me touch events too, right=
<alan_g> tsdgeos: greyback - yes, reports are working from a nested server
<tsdgeos> they don't from unity8 :/
<greyback> MIR_CLIENT_INPUT_RECEIVER_REPORT is in the mir sources
<tsdgeos> ok
<tsdgeos> that gave me stuff
<tsdgeos> so yeah
<tsdgeos> according to that
<tsdgeos> doesn't get whatever prints
<tsdgeos> [1427284176.481447] <DEBUG> input-receiver: Received event:
<tsdgeos> only get the a there
<anpok> tsdgeos: so u8s surface is not yet focused/hasnt submitted buffers/been created yet...?
<tsdgeos> anpok: don't think so
<tsdgeos> usc is not getting the key event either
<anpok> oh
<anpok> but there is no client report in usc
<tsdgeos> well there is the server one
<tsdgeos> http://paste.ubuntu.com/10677149/
<tsdgeos> 14 events
<tsdgeos> which should be 16
<anpok> yeah but thats the sending part
<anpok> so there is still a lot that can go wrong (or right) within usc before this report is generated
<anpok> if you enable the MIR_SERVER_LEGACY_INPUT_REPORT=log on usc you see the part that reads the event from the evdev devices
<tsdgeos> oki
 * tsdgeos does
<tsdgeos> [1427285878.408333] android-input: [InputReader]Dropping key up from device py-evdev-uinput because the key was not down.  keyCode=44, scanCode=25
<tsdgeos> that's good
<tsdgeos> so it seems that autopilot creates device /dev/input/event8
<tsdgeos> then mir says
<tsdgeos> [1427285878.342107] android-input: [EventHub]New device: id=18, fd=66, path='/dev/input/event8', name='py-evdev-uinput', classes=0x80000063, configuration='', keyLayout='Generic.kl', keyCharacterMap='Generic.kcm', builtinKeyboard=false, usingSuspendBlockIoctl=true, usingClockIoctl=true
<tsdgeos> [1427285878.342351] android-input: [InputReader]Device added: id=18, name='py-evdev-uinput', sources=0x00000701
<tsdgeos> and i guess sometimes something goes too slow
<tsdgeos> and the first key down fails?
<tsdgeos> right
<tsdgeos> so that's what happens
<tsdgeos> mir is not seeing the new device until
<tsdgeos> [1427285878.342107
<tsdgeos> but the keypress is on
<tsdgeos> 12:17:58.305 DEBUG _uinput:60 - Pressing p (25).
<tsdgeos> that is 1427285878.305
<tsdgeos> i.e. 40 msec before
<tsdgeos> ok i kind of know what's wrong now
<tsdgeos> no idea how to fix it though :D
<tsdgeos> other than blindly adding a sleep
<greyback> tsdgeos: log a mir bug anyway
<greyback> tho it's probably a race that's hard to fix
<kdub> greyback, seems like with qt 5.5, you can split the qtgui and the renderloop thread
<greyback> kdub: yeah
<greyback> there was work to enable threaded rendering with a custom qquickrendercontrol for qt5.5
<kdub> yay, neat
<greyback> sadly that's not in 5.4
<greyback> which I expect will slow down your work a bit?
<kdub> it might, i'm having a hard time convincing the qtgui thread not to try to run
<greyback> :) the "Gui" thread does lots of other stuff too, from processing input events and managing the qml scene
<kdub> yeah, its good that it can be split in qt 5.5, although its still disconcerting how the threading works so rigidly (imo)
<greyback> kdub: "rigidly" is an interesting term, what do you mean?
<greyback> like 1 thread per qquickwindow, or 1 thread for all windows, and nothing else?
<kdub> yeah, its just strange that i have to set affinity of objects with certain threads, and mind which thread calls certain functions (just an empty complaint, really :) )
<kdub> greyback, the problem i'm running into now (with 5.4) is that the QQuickRenderControl seems to need a QQuickWindow with a fb target (QOffscreenSurface) associated with it... and trying to QQuickWindow::create() the window associated with the QQuickRenderControl seems to start the QtGui thread
<mpt> The menu bar doesnât cast a shadow on a window touching it, therefore the window is not lower than the menu bar.
<mpt> A window can slide underneath the Launcher, therefore a window is lower than the Launcher.
<mpt> A window is lower than the Launcher, but not lower than the menu bar, therefore the Launcher is higher than the menu bar.
<mpt> Therefore shell components are on multiple layers.
<mpt> Which is â¦ inconvenient.
<greyback> mpt: you're testing unity8 desktop mode I'm assuming? Yes we've plenty of work to do there yet. We've inherited those layers from the phone/tablet
<mpt> greyback, no, I was talking about shells in general. What I said was true for Unity 7 and for OS X, and probably (though I havenât tried) for Gnome Shell as well.
<greyback> mpt: ah I see, apologies
<greyback> mpt: mind if I ask what you find inconvenient about shell components on layers though? You could consider each window as being in it's own layer (except for our desired case of windows being snapped together, so in same layer)
<mpt> greyback, itâs inconvenient for defining exactly what order surfaces are in, layer-wise
<mpt> At the moment I think the answer is âthe topmost dialog/freestyle/regular/floating regular window, in the topmost window tree, should be level with the bottommost shell surfaceâ
<mpt> but that seems like a bit of a hack
<mpt> A much simpler version of the problem is: When the frontmost regular window has a dialog, and the title bars of both are flush with the bottom of the menu bar, what is the layering of the menu bar? Is it (a) above both, (b) level with the dialog, (c) level with the parent, like it would be if it didnât have a dialog, or (d) below them both?
<mpt> In Unity 7, the answer is (b)
<mpt> (i.e. as soon as the dialog opens, its parent sinks down below the menu bar)
<mpt> In OS X, the answer is (e) magically level with both, even though one is above the other
 * alan_g was just thinking about how to better manage the z-order of related surfaces in Mir.
<greyback> mpt: ok problem is clear, no obvious solution strikes me however
<greyback> thanks for elaborating
<greyback> only thing I can suggest is not having menubar part of the stack of window layers, but in a separate layer whose bottom z-order matches the top window's layer z-order
<greyback> less elegant but gives more power to choose how menubar's shadow falls
<mpt> Several subtleties about window position and size depend on knowing what is a âshell surfaceâ
<mpt> For example, if you have the Dash open, a new window can happily open with its title bar entirely covered by the Dash, but we mustnât let its title bar be entirely covered by the menu bar or the Launcher
<mpt> The menu bar and Launcher are âshell surfacesâ under this definition, while the Dash is not (and nor are indicator menus, session dialogs, Launcher tooltips, etc)
<mpt> So, itâs useful for a shell to be able to say âthis surface here is of type SHELL_SURFACEâ (a.k.a. _NET_WM_WINDOW_TYPE_DOCK) and let Mir handle the subtleties
<mpt> But, greyback, that doesnât work if the menu bar is a magical surface that layers differently from the other shell surfaces :-)
<greyback> mpt: it's not necessarily magical, we're just not confined to the laws of physics here :) It's very possible to have menubar at same z-order as the top-most window in the stack of windows
<mpt> Sure, the magical part is the detail where OS Xâs menu bar is level with all windows at the same time <http://en.wikipedia.org/wiki/Waterfall_%28M._C._Escher%29>
<racarr> *deletes 2000 lines of code from PAPI*
<racarr> delicious delicious deletion
<racarr> 3285 lines (+34/-2861) 40 files modified
<racarr> oh yeah
#ubuntu-mir 2015-03-26
<greyback> hey folks, tsdgeos got a unity8 hang: http://paste.ubuntu.com/10683891/
<greyback> if you have a look at thread 9, it's blocked waiting for another buffer from mir
<greyback> which may be normal...
<greyback> thread 23 is waiting inside a snapshotting lambda
<greyback> which is suspicious to me too
<greyback> did the double-buffering stuff land?
<greyback> AlbertA: alf_ ^^ ideas?
<alan_g> greyback: that's using Mir 12? Or 12.1?
<tsdgeos> alan_g: vivid
<alan_g> BTW alf_ is supposed to be off the rest of the week
<tsdgeos> alan_g: http://paste.ubuntu.com/10683940/
<greyback> 12.0 - so no buffer changes I suspect?
<alan_g> Well, AlbertA found (& fixed) some races in 12.0
<greyback> alan_g: that's what 12.1 is for?
<alan_g> Mostly
<greyback> alan_g: silo13 I presume?
<alan_g> Not sure exactly what we backported to 12.1 but certainly some race fixes
<greyback> tsdgeos: could you try installing silo13 and see if the problem remains?
<tsdgeos> i can give it a go i guess
<greyback> thanks, would be gret if this fixes it
<alan_g> greyback: we didn't land the switch to double buffering in 12.1
<greyback> alan_g: cool
<greyback> doesn't strike me a point-release kind of change
<tsdgeos> https://bugs.launchpad.net/ubuntu/+source/mir/+bug/1436860
<ubot5> Ubuntu bug 1436860 in unity8 (Ubuntu) "unity8 is deadlocked " [Undecided,New]
<alan_g> Nor me - but no-one listened (at first)
<tsdgeos> greyback: alan_g: anything else you guys want me to add in there before i reboot the phone?
<alan_g> not I
<greyback> tsdgeos: unity8.log pl`
<greyback> plz
<greyback> tsdgeos: and please use pastebin for the backtrace, it's hard to read as P wordwraps it
<tsdgeos> greyback: but pastebin will eventually die, no?
<tsdgeos> i can attach it into a file
<greyback> tsdgeos: I didn't think so
<tsdgeos> so you can download and read it with your favorite editor
<greyback> yeah best option
<greyback> I'd like to think pastebin.ubuntu.com will be around as long as LP is
<tsdgeos> greyback: anywya, looks better now
<greyback> tsdgeos: thanks, sorry for being pain :)
<alan_g> kdub: what do you want from "distinguish the "server_example_canonical_window_manager""?
<kdub> alan_g, I'm just not sure why there are two that seem similar I suppose
<alan_g> Because folks wanted a copy, not a move?
<alan_g> ...and copies tend to be similar.
<kdub> alan_g, fair enough, but seems to merit a name change from canonical I guess was my point
<alan_g> suggestion?
<kdub> alan_g, i keep getting distracted by the nested stuff, maybe 'default'
<alan_g> camako: should https://code.launchpad.net/~mir-team/mir/0.12/+merge/253528 still be linked to lp:1240909?
<alan_g> AIUI we reverted that change
 * alan_g wonders whether camako_ heard him
<camako_> alan_g.. I didn't... somebody ping me?
<alan_g> camako_: should https://code.launchpad.net/~mir-team/mir/0.12/+merge/253528 still be linked to lp:1240909?
<alan_g> AIUI we reverted that change
<camako_> alan_g, right it shouldn't be...
<alan_g> camako_: fixed
<camako_> thanks
<alan_g> np
<alan_g> kdub: did you notice the prerequisite? https://code.launchpad.net/~andreas-pokorny/mir/move-input-report/+merge/253207
<kdub> alan_g, no, i didn't switched back to needs review
<alan_g> And https://code.launchpad.net/~alan-griffiths/mir/unpublish-legacy-window-managment-customization/+merge/253967
#ubuntu-mir 2015-03-27
<alan_g> duflu: happy with the latest version? https://code.launchpad.net/~alan-griffiths/mir/even-NullWindowManager-configures-surface/+merge/254123
<duflu> alan_g: Still indifferent
<duflu> And it's Friday night now
<alan_g> Does "Needs Information" say indifferent now?
<alan_g> Anyway have a good weekend,
<duflu> alan_g: Make that Abstain now
<alan_g> ta
<duflu> Wow systemd makes vivid noticeably faster to start/stop
 * duflu -> weekend
<tsdgeos> guys, isn't it a bit radical to abort?
<tsdgeos> in http://paste.ubuntu.com/10689199/
<anpok> hm it throws
<anpok> the rest ist std behavior
<tsdgeos> is it documented that it throws?
<tsdgeos> because otherwise is as good as aborting
<anpok> it hits a limitation of the android touch event transport
<tsdgeos> i'm not asking you why you throw
<tsdgeos> i'm asking if it's documented so the implementators know they can need a catch not to crash
<anpok> it is not, but the person who made change in qtmir also changed added the api to mir
 * alan_g wishes that the "playground" would go somewhere
<kdub> alan_g, yeah, me too... I guess that examples and playground are about even in terms of features
<kdub> i guess playground has shadows and a background color
<alan_g> And titles, negative rendering and high-contrast rendering
<alan_g> Maybe we need a gap analysis
<alan_g> The problem is that the useful features are buried in a mess of experimental code
#ubuntu-mir 2016-03-28
<Someone_Else> â
<Someone_Else> I installed Mir and Unity 8 on a fresh 16.04 installation, alongside with the newest nVidia drivers (using KMS), but when I try to login to Unity 8, it returns to a frozen login screen
<anpok> Someone_Else: we havent integrated the nvidia support into mir.. RAOF is currently working on that. So even when nvidia does provide the necessary kms/drm interfaces egl integration will need changes in mir
<Someone_Else> anpok: I assume you are happy to see that nVidia finally released the KMS version of the driver - don't you?
<Someone_Else> anpok: What I read is that KMS is necessary for Wayland / Mir to work
<anpok> hm mir can could also use the android hwc/fb api for that purpose.. but yeah I still cannot believe that this happened..
<Someone_Else> Still, when using nVidia drivers, the boot console resolution is way to low
<Someone_Else> anpok: Are there any workarounds for that? That problem is happening as long as I can remember...
<Someone_Else> RAOF: Any ETA on when the changes are available in APT?
<RAOF> Hah!
<RAOF> nvidia support, right now?
<RAOF> No. :)
#ubuntu-mir 2016-03-29
<zzarr> hello!
<zzarr> if there is a Vulkan driver for a GPU, would that matter to MIR (could I get MIR running with the help of it in the future?)
<suebt> Hey there, I'm trying to get kivy (https://kivy.org/) running on Ubuntu Touch. The Python stuff part is working but I have issues with SDL and (maybe) MIR. It would be super cool if you could look into this whether you have an idea what's causing the error.
<suebt> So, the program is starting and segfaulting when loading sdl
<anpok_> sdl2 that is?
<suebt> yes
<anpok_> what sdl2 library are you using
<suebt> Custom builds (SDL2-2.0.4)
<anpok_> hm bschaeffer is not around
<suebt> I tried with packaged versions as well.
<suebt> Both resulting to the same error
<anpok_> he would know better.. the symptoms sound familiar
<suebt> okay, thanks, I'll just drop some links to the logs in case they're useful?
<suebt> https://drive.google.com/folderview?id=0B4EyY4wSGSyjNWwzVGo1eHBUc1k&usp=sharing Here are some stack traces. "kivy_log" is the output from python.
<greyback> suebt: hey, those are "syscall traces" - you used strace, right? That tool reports all the calls the app makes to the kernel. This doc shows how to get stacktraces: https://wiki.ubuntu.com/Backtrace which would help us more
<suebt> greyback: okay, thanks. Yes, those where strace logs. Here is a gdb log: https://drive.google.com/folderview?id=0B4EyY4wSGSyjMFhlRDh6V2NrNjg&usp=sharing
<suebt> or better http://paste.ubuntu.com/15551628/
<greyback> suebt: ok, looking, it's not a useful backtrace, as you only have 2 frames of the stack. __GI_raise indicates an exception was thrown.
<suebt> hmm, is there anything I can do to provide more useful information about this?
<greyback> suebt: suggest you install the debug packages for mir, and libc6-dbg, and then try again
<suebt> okay, libc6-dbg is installed. Will install mir debug packages
<greyback> suebt: in gdb, also do "catch throw" before running
<suebt> okay, will do, thanks!
<greyback> thank you
<suebt> greyback: can you possibly point me on which mir debug packages you mean?
<greyback> suebt: probably libmirclient9-dbgsym
<suebt> greyback okay, thanks, let's see...
<suebt> Hmm... it's not in vivid repos, is there a ppa for it?
<greyback> suebt: you probably need this: https://wiki.ubuntu.com/DebuggingProgramCrash#Non-built-in_debug_symbol_packages_.28.2A-dbgsym.29
<suebt> greyback: It throws a lot of "W: Failed to fetch ..." errors if I try this â¦
<greyback> suebt: can you pastebin me what you see and the commands you used?
<greyback> and also the contents of /etc/apt/sources.list.d/ddebs.list
<suebt> greyback: This is what I did: http://paste.ubuntu.com/15551845/ and here is my  /etc/apt/sources.list.d/ddebs.list: http://paste.ubuntu.com/15551853/
<greyback> suebt: oh, you're working on the phone
<suebt> yeah sure :)
<greyback> suebt: ok, I need to change the advice (sorry, I thought you were developing on your desktop)
<suebt> oh np :)
<suebt> I don't have mir on the desktop
<greyback> suebt: please edit the ddebs.list file to just contain this:
<greyback> deb http://ppa.launchpad.net/ci-train-ppa-service/stable-phone-overlay/ubuntu vivid main/debug
<suebt> okay
<suebt> (I'm on rc-proposed tho, not sure if that changes something)
<greyback> explanation: the phone uses a PPA to deliver software newer than vivid (which is about a year old now). So you need a special place to find debug packages for that PPA (which is what I gave you)
<greyback> suebt: nah, perfect. Best place for developing
<suebt> ah okay :)
<suebt> meh it doesn't want to write to that file oO
<greyback> I think you're nearly out of disk space too
<suebt> yep xD
<suebt> nano doesn't work properly ... Or is it normal i can't save that file?
<greyback> are you root?
<suebt> I am.
<greyback> I suspect nano and "adb shell" don't work well together
<greyback> the return key seems to disappear
<suebt> yeah, I'll move the file manually ...
<greyback> delete it and do
<greyback> echo "deb http://ppa.launchpad.net/ci-train-ppa-service/stable-phone-overlay/ubuntu vivid main/debug" | sudo tee -a /etc/apt/sources.list.d/ddebs.list
<suebt> oh that would've been faster :)
<suebt> done
<greyback> now after apt update you should be able to find the mir debug packages
<suebt> phablet@ubuntu-phablet:~/Documents$ sudo apt-cache policy libmirclient
<suebt> E: Write error - write (28: No space left on device)
<suebt> ha /0\
<greyback> sudo apt-get clean
<greyback> might help
<suebt> done, took a second to run :)
<suebt> will delete some picture
<suebt> *s
<suebt> meh, still no space left
<suebt> Think, I'd better do a clean reset, should I?
<greyback> suebt: from experience, you'll hit this again & again
<greyback> you'd be better developing in a chroot. Let me try find a link to a handy email
<suebt> greyback: Okay, that'd be super nice :)
<greyback> suebt: http://pastebin.ubuntu.com/15552039/
<greyback> oh, "sagu" should be "sudo apt update"
<greyback> oh, "sagy" should be "sudo apt install"
<suebt> greyback: really nice, thanks, I'll look into it. Just finish resetting my device up ...
<greyback> suebt: fixed: http://pastebin.ubuntu.com/15552049/
<greyback> http://pastebin.ubuntu.com/15552056/
<greyback> is better
<suebt> greyback: cool, I'm back (with a fresh ubuntu phone)!
<suebt> So this is to be setup on the phone?
<suebt> I'll try
<greyback> suebt: let's see
<suebt> hah, need to enable developer mode first :)
<suebt> whut? "E: Write error - write (28: No space left on device)"
<suebt> What does this "reset" actually do xD ... let me reflash
<camako> zzarr, hi
<camako> zzarr, do you have source access to the GPU driver you've mentioned?
<camako> zzarr, you'd need to implement the Window System Integration extensions to be able to display
<camako> WSI extensions for Mir, that is... using the Mir client library.
<camako> We have not officially published all the headers you'd need.
<camako> But they are available in our dev trunk
<suebt> greyback: had to go off for some time. "sudo apt install debootstrap" doesn't work, I assume I should add the universe repo?
<greyback> suebt: did you "apt update" first?
<suebt> greyback no, will try
<suebt> greyback: oh, it works now, thank you!
<greyback> np
<suebt> greyback: hhmm, I get "usermod -G sudo phablet" >> "usermod: user 'phablet' does not exist"
<suebt> "sudo ./ch -r vivid-chroot/" >> "logname: no login name
<suebt> logname: no login name"
<greyback> suebt: what is the user of your chroot? "echo $USER"
<suebt> "echo $USER root"
<suebt> "echo $USER" >> "root"
<greyback> suebt: if you enter the chroot as not-root, i.e. remove the "-r" switch, what is the user?
<suebt> still root ...
<suebt> without -r
<greyback> oh, you were root when creating the chroot, weren't you?
<suebt> hmm yeah, cause of sudo?
<greyback> even before?
<suebt> "echo $USER" > phablet -> outside of my chroot. At least now ...
<greyback> ok, that's good
<suebt> Does this matter?
<greyback> not hugely
<suebt> it also says "mount: mount point /home/phablet/vivid-chroot//home/phablet does not exist"
<greyback> I'm not sure what's gone wrong. debootstrap should know about the phablet user.
<suebt> can't I create it manuallyÃ
<suebt> *?
<greyback> yeah, you can
<greyback> I just never have to
<greyback> so I'm confused what is different
<suebt> maybe I did something wrong?
 * suebt double checks everything
<greyback> suebt: fyi, you can blow everything away by just deleting the $HOME/vivid-chroot directory
<suebt> ok
<suebt> but I think I did it exactly the same
<suebt> let me try again
<greyback> suebt: only difference I can think of is that usually I SSH into the device. I find adb shell sometimes causes me problems
<greyback> but the instructions I gave you are exactly those I follow
<suebt> Ah, okay, I can try to use ssh
<suebt> adb seems to be the issue indeed! No errors via ssh, yet
 * suebt needs to go off for today soon tho, thanks for all your help, will continue tomorrow.
#ubuntu-mir 2016-03-30
<duflu> RAOF: In case you didn't notice, this is yours now :)  https://bugs.launchpad.net/ubuntu/+source/unity-system-compositor/+bug/1553549
<ubot5`> Launchpad bug 1553549 in unity-system-compositor (Ubuntu) "unity-system-compositor crashed with SIGSEGV in get_adjusted_ptr(), when proprietary Nvidia drivers are installed" [High,Confirmed]
<RAOF> Indeed I noticed.
<suebt> greyback: Just got everything setup and ran gdb again. Unfortunately, there's no useful output :| (at least I think there is no): http://paste.ubuntu.com/15558754/
<greyback> suebt: libc6-dbg installed?
<greyback> but address at frame 2 does look weird
<suebt> greyback: oh no, forget I reflashed it so no... will do, sorry
<suebt> s/forget/forgot
<suebt> Do I have to run it from inside the ch thing?
<greyback> suebt: this is where you need to take care. The chroot is ideal for building code, since you can install all the dependencies without filling up your phone's root filesystem
<greyback> but running code inside chroot is less convenient, as it can get in the way. Example, you may not be able to connect to mir, which lives outside the chroot, while you are inside the chroot
<greyback> so usually I build my stuff in the chroot, then copy/install the built bits into the root filesystem. And then I test outside the chroot
<suebt> greyback: Ah, allright okay. But how does the system know that I installed the debug packages in the chroot oO Is a reboot required?
<greyback> which means, you need the dbg symbols outside the chroot too
<greyback> suebt: gdb is configured to look for dbg packages in /usr/lib/dbg. As you're inside the chroot, it will not see the dbg packages outside your chroot
<suebt> oh :| So how can I get them in the rootfs?
<suebt> or can I tell gdb that I have dbg packages in the chroot?
<greyback> suebt: the usual: apt-get install libc6-dbg
<greyback> suebt: you can, using the "dir" or directory command
<greyback> but I think you'd be safer just installing dbg packages on the rootfs
<suebt> Huh, okay â¦ but then I will be running out of space again, won't I?
<greyback> suebt: that's a danger, yes. But by not having the build packages installed too (instead having them in chroot), you've made that less likely
<greyback> usually I can manage to install about 300MB of debug packages before I hit that issue
<suebt> Okay, so I installed libc6 to the rootfs. The same with the mir debug package?
<suebt> s/libc6/libc6-dbg
<greyback> suebt: well, try gdb again, see if you get more detail in your stacktrace
<greyback> if you do, but it stops at something from the  "mirclient" library, then install the mirclient dbg package, and try again
<greyback> it's a bit iterative
<suebt> ok, thanks for your help. Let me try.
<suebt> greyback: okay, here's the lock with libc6-dbg: http://paste.ubuntu.com/15558852/
<greyback> suebt: hmm, no improvement. I would try installing the mirclient dbg, just in case.
<greyback> but frame 2 has a weird address. Hope something isn't smashing the stack
<suebt> greyback: so I'll enable the overlay ppa as I did for the chroot and install it?
<greyback> suebt: yep
<suebt> greyback ok..
<greyback> lots of work, eh? :)
<suebt> hah, I'm just bagging it won' t fill up my rootfs again xD
<suebt> greyback: http://paste.ubuntu.com/15558908/
<suebt> meh /0\
<greyback> :(
<suebt> greyback: What could be the root for this? Could it be a mir problem at all?
<suebt> or is it more likly a problem with my libraries
<greyback> suebt: it's impossible to say with this information. Something between mir & SDL
<anpok> sdl dynamically loads mirclient
<suebt> greyback: Is there anything I could do now?
<greyback> suebt: all I can recommend is ensuring you're using the most recent pull of the sdl libraries - I know the mir support was changing a lot recently
<greyback> suebt: and bschaefer would be the best guy to ask (he based on west coast US, usually online 8+ hours from now)
<suebt> Hmm â¦ okay. Actually it used to segfault because of missing/obsolete SDL libs before. But then I did the custom build and it no longer segfaulted. Instead I got the message that sdl is missing libsndio.
<suebt> Only after including this lib, this segfault we're taling about is happening.
<suebt> Not sure if that info is relevant
<suebt> okay
<greyback> yeah sorry, I'm not the expert on SDL
<suebt> me even less :D thanks for all your help anyway!
<greyback> I wish you luck. Thanks for the digging. I hope you learned something anyway
<anpok> suebt: can you point me to the source code version of libsdl that you are using?
<suebt> greyback: yes! I know now how to install debug packages, have a nice chroot where I can build stuff ... it's great! Thanks so much :)
<suebt> anpok: yeah sure
<suebt> https://github.com/Sturmflut/ubuntu-touch-sdl2-gles2-template I was using this to build my sdl libraries. This is known to work on the phone, that's why I was choosing it.
<suebt> Not sure if it would help, but I can upload the stuff I have. At least the python stuff seems to be working :)
<suebt> anpok: Or is a newer version required and I'm wrong?
<slvn_> suebt,  . ... just reading, I can help if you want to build sdl2 for ubuntu device
<slvn_> (just sum up your question again ...)
<anpok> ok
<suebt> hi slvn_, I building seems to have worked but the problem above started when I included libsndio which sdl was claiming for. Do you have an idea what could be wrong with that?
<anpok> hm the sdl archive contains code that loads mir_connection_create_surface_sync
<slvn_> not sure that sdl claims libsndio  ?!
<slvn_> is it SDL2 ? not SDL.1.2 ?
<anpok> and I believe that one only part of libmirclient8 and no longer part of libmirclient9
<anpok> SDL2
<slvn_> ok
<suebt> one moment, slvn_
<suebt> slvn_: http://paste.ubuntu.com/15558973/
<suebt> ^ that's what happens without it. FYI: it's about trying to get kivy (https://kivy.org) running.
<slvn_> yep, but kivy is not sdl2 ...   I have check SDL2 source and there is actually some part about libsndio
<suebt> okay, I thought it was sdl2 cause of the "sdl2 - ImportError" ...
<slvn_>  probably it is. since SDL2 contains some code that use libsndio
<slvn_> in "configure" there are some reference to libsndio
<slvn_> but, I have checked my partial chroot and I have no libsndio installed
<slvn_> "find . | grep libsnd"  > ./partial-armhf-chroot/usr/lib/arm-linux-gnueabihf/libsndfile.so.1
<slvn_> don't know wether libsndfile is different of libsndio ...
<suebt> I haven't seen other apps shipping libsndio as well. Dunno why kivy wants that for sdl2...
<slvn_> does kivy provides SDL2 libs for ubuntu device ? do you recompile your self ? do you actually need the libsndio ?
<suebt> No, it doesn't provide SDL libs for the phone, I compiled them myself. I want to get kivy running, I'm not sure whether libsndio is neccessary, all I know is that it claims for it when I don't have it and that I receive a segfault when I include it :/
<slvn_> SDL2 can look for various audio back-end and pick the available one. According to the "configure --help", libsndio is set as "default == yes". ...
<slvn_> from my chroot which is a few month old
<slvn_> Audio drivers   : disk dummy oss alsa(dynamic) pulse(dynamic) nas(dynamic)
<slvn_> "checking sndio.h usability... no"
<slvn_> my SDL2 on ubuntu device has no libsndio I guess
<slvn_> I think this is *kivy* which try to load libsndio
<slvn_> "ImportError: libsndio"
<slvn_> this is python, not sdl2 ?
<slvn_> maybe ask the channel #SDL2  ?
<slvn_> maybe ask the channel #SDL ?
<suebt> So, according to the kivy devs it's SDL2 xD Can you show me how you built it withoud sndio?
<slvn_> suebt, this is my configure line http://paste.ubuntu.com/15559095/
<slvn_> and the sum up http://paste.ubuntu.com/15559098/
<slvn_> I think the audio back end is pulse, because  I remember having some issue with it ...
<suebt> slvn_ hhmmm, this configuration is a bit different to what I used ...
<slvn_> suebt, for instance ?
<suebt> --enable-mir-shared --enable-video-mir instead of  --disable-mir-shared
<suebt> not sure if that makes a difference tho
<slvn_> should not matter, this is not related to libsndio
<suebt> yes...
<slvn_> I mean "configure script" won't find libsndio with the default chroot I guess
<slvn_> so SDL2 shouldn't not even try to load lib sdl2 ..
<slvn_> libsndio
<suebt> yeah ...
<slvn_> what is the output of the configure script ? "audio driver ..."
<suebt> Audio drivers   : disk dummy oss
<suebt> Video drivers   : dummy opengl_es2 mir
<suebt> Input drivers   : linuxev linuxkd
<suebt> Using libudev   : YES
<suebt> Using dbus      : YES
<suebt> Using ibus      : NO
<suebt> What I'm just wondering, kivy wants libSDL2_image, libSDL2_ttf and LibSDL2_mixer as well.
<suebt> Might it be that those require libsndio?
<slvn_> no,
<slvn_> but I have found your issue
<slvn_> you need more dependencies in your chroot
<slvn_> in your script "setup-partial-armhf-chroot.sh"
<slvn_> you need to add some dependencie :
<slvn_> builddeps+=" libfreetype6-dev libfreetype6 libpng12-dev libjpeg8-dev"
<slvn_> builddeps+=" libpulse-dev libpulse0
<slvn_> this is probably the reason for I have a different line "Audio drivers"
<suebt> slvn_: Sorry, what script are you talking about?
<slvn_> suebt,  I prepare my partial chroot to compile, with a script from mir.  Maybe you did it another way.
<slvn_> Anyway, you need to have the previous packages installed
<slvn_> so that the "configuration" of SDL2 is done correctly
<suebt> Ah ok :) Would you mind sharing your script?
<slvn_> suebt,  there was a little tutorial + files there : https://bugzilla.libsdl.org/show_bug.cgi?id=2805
<ubot5`> bugzilla.libsdl.org bug 2805 in *don't know* "resources to build SDL libs on ARM Ubuntu touch" [Normal,New]
<slvn_> I will update it
<bregma> just out of curiosity, why are you guys trying to build libSDL instead of using the pre-built binaries available in Ubuntu Touch?
<suebt> slvn_ nice, thanks
<suebt> bregma: I tried those too. There is the same problem with sndio ...
<slvn_> suebt, I have updated the previous ticket ..
<slvn_> bregma, when I was compiling SDL2 there was no pre-built binaries available for ubuntu touch .. I also have a couple of minor patches  ..
<suebt> slvn_: thanks I'll try it again with your scripts
<slvn_> the tutorial is from 2014-12-06 ...
<slvn_> you may have an issue with the "fullscreen" mode, because the status bar is still there ...
<slvn_> you need to add "MIR_mir_surface_spec_set_state(spec, mir_surface_state_fullscreen);"  after "MIR_mir_surface_spec_set_name(spec, "Mir surface");" in the file "src/video/mir/SDL_mirwindow.c"
<bregma> slvn_, ah, right, it was supposed to be available but I guess someone (me) didn't follow through -- it is available in the PPA https://launchpad.net/~mir-team/+archive/ubuntu/staging but I think bschaefer needs to update that, too
<bregma> I'll see if I can poke him to make sure it's up-to-date and available somewhere
<suebt> slvn_: hah, I'd be happy if I would get this thing running at all /0\
<bregma> he'll be online in a couple of hours
<bregma> he's the guy who maintains the Mir port
<slvn_> I found the issue .. https://bugs.launchpad.net/qtmir/+bug/1519338
<ubot5`> Launchpad bug 1519338 in QtMir "API "mir_surface_apply_spec" is not supported in qtmir/u8 " [Medium,Confirmed]
<slvn_> I have to go away, I be back in 1 hour.++
<bschaefer> suebt, hey, soo hmm not really sure why that library would cause you issue, you're trying to run a program from the command line for unity8?
<bschaefer> or do you have your own mir server running?
<bschaefer> as otherwise you'll get blocked, since you should have a *.desktop file in order to run on U8
<suebt> Hey bschaefer, I'm running on the phone!
<bschaefer> suebt, right, but you're trying to run the application from the command line for U8?
<suebt> Yes.
<bschaefer> you need a *.desktop file in order to be approved to run on unity8
<bschaefer> otherwise you'll be blocked and strange things can happen (ie. no window can be created)
<bschaefer> [CRITICAL          ] [Window      ] Unable to find any valuable Window provider at all!
<bschaefer> that seems like the main error to me
<suebt> Oh kay, that would be a very simple solution for this problem.
<bschaefer> hopefully it is the solution :)
<suebt> How can I archieve this?
<suebt> I mean how do I set the desktop file path when running it?
<bschaefer> suebt, i usually copy the webbrowser-app.desktop
<bschaefer> in /usr/share/applications
<bschaefer> and change the exec path to the path of my binary
<bschaefer> or a script file
<suebt> Okay, so I should just start it via the launcher.
<bschaefer> suebt, the other thing you might want to include is SDL_VIDEODRIVER=mir
<bschaefer> suebt, yes! Or in the dash
<bschaefer> once you get a new *.desktop file up, just search for the name you set in Name=
<suebt> Okay, I'll try both, thanks!
<bschaefer> let me know!
<suebt> sure :)
<bregma> put your custom .desktop file in ~/.local/share/applications
<bregma> use the "env" command in the Exec= line to set environment variable when running
<bschaefer> suebt, bregma knows best ^
<bregma> if you do not launch using a .desktop file, the Unity 8 Mir server will reject the connection (this prevents thinks like keylogging attacks)
<bregma> if you want to launch from the command line instead of the Dash, you will still need a .desktop file and pass it to the ubuntu-app-launch tool
<suebt> okay, thank you bregma, bschaefer, I'm trying...
<suebt> I now have the Exec line "Exec=env KIVY_WINDOW=sdl2 SDL_VIDEODRIVER=mir /home/phablet/Documents/mainv3/main".
<suebt> It hangs on the startup splash screen. How can I read command line output when starting the app from the dash?
<bschaefer> IIRC the sys log will let you know if its rejected and you can look in ~/.cache/upstart/<desktop_file_name_log> for more info
<bschaefer> suebt, check ~/.cache/upstart/ and the name of the desktop file
<bschaefer> like legacy application <desktop file name> something like that
<suebt> Ah, thanks bschaefer. Okay, hmm ... the kivy environment variable didn't work this time, was my exec line correct?
<bschaefer> suebt, i usually just make the Exec line point to a *.sh file :)
<suebt> will do :)
<bschaefer> just a simple bash script that exports the env
<bschaefer> then execs your app
<suebt> /home/phablet/Documents/mainv3/start.sh: 3: ./main: not found
<suebt> hmm, it won't find my executable from within that script oO
<bschaefer> well sounds like the path is off :)
<suebt> it doesn't work with the absolute path as well -.-
 * bschaefer isnt sure though
<bschaefer> suebt, best bet is to just do exec <full/path/to/main>
 * bschaefer internet died
<bschaefer> suebt, umm you saw the part about full path to main?
<suebt> yep, thx, one moment
<suebt> bschaefer: All right, it "works" now (the path is right now), but it crashes with the same error as before: http://paste.ubuntu.com/15560297/
<bschaefer> well : [CRITICAL          ] [Window      ] Unable to find any valuable Window provider at all!
<bschaefer> isnt a good sign :)
<suebt> yeah :/
 * bschaefer seems to keep having internet issues
 * bschaefer writes a simple SDL2 app
<bschaefer> suebt, http://paste.ubuntu.com/15560412/
<bschaefer> if you can cross compile that for ubuntu touch
<bschaefer> then test that works
<bschaefer> for Mir
<bschaefer> on U8
<suebt> Allright, will try bschaefer
<bschaefer> opps, replace ... that third error with failed to create renderer :)
<suebt> ok
<suebt> meh, my chroot seems broken, trying to install libsdl2-dev to it, "E: Unable to correct problems, you have held broken packages."
<bschaefer> :(
<suebt> let me create a new one
<suebt> need to go off now, I let the sdk create a new chroot and will try it as soon as I'm back.
<suebt> s/let/currently letting
<bschaefer> suebt, ill be around!
<suebt> great :) I'll have some pizza see you in 1-2h
<suebt> hey, I'm back, having some trouble though
<suebt> Can't I install libsdl2-dev to my click chroot? It still doesn't works ...
<bschaefer> :(
<suebt> How do you do this?
 * bschaefer isnt to good with clicks... i usually just use a pbuilder
<bschaefer> slvn_, posted this earlier: https://bugzilla.libsdl.org/show_bug.cgi?id=2805
<ubot5`> bugzilla.libsdl.org bug 2805 in *don't know* "resources to build SDL libs on ARM Ubuntu touch" [Normal,New]
<suebt> Okay, let me try with the includes from the source code-
 * bschaefer isnt 100% how helpful that is
<suebt> c++ noob question how do I tell the compiler where it finds additional includes?
<bschaefer> -I
<bschaefer> -I/path/to/includes
<suebt> ah right, thx
<slvn_> suebt,  the scripts from the SDL2 ticked should work pretty fine ... I spent hours to update them in order to make minimal user action
<bschaefer> np
<suebt> slvn_ I tried it but it failed for me :| it was missing something, I gave up in the end :/
<slvn_> well I use it, and got +10 apps published ... if you report the error I may help you ... though it should be better to use the official package ..
<suebt> let me try again.
<suebt> slvn_ it says: "gpg-error, gpg could not been executed (is it installed?)" (translated)
<suebt> *gpgv http://paste.ubuntu.com/15562381/
<slvn_> suebt,   "sudo apt-get install gpgv"  ?!
<slvn_> you need to install this tool ..
#ubuntu-mir 2016-03-31
<duflu> RAOF: Can you remember the path of the /real/ xenial Mir branch? Something like lp:ubuntu/*
<duflu> We have everything except xenial...
<duflu> https://code.launchpad.net/ubuntu/+source/mir/+all-branches
<duflu> Can anyone remember the path of the real xenial release branch?
<duflu> It's not lp:mir/ubuntu .. that's just a dummy
<RAOF> duflu: Do we *have* a real xenial Mir branch?
<duflu> RAOF: Yeah I found it a couple of months ago. Maybe I'm remembering the wily one
<duflu> alan_g: How many processes/threads implement mtf::ConnectedClientHeadlessServer ?
<duflu> (are used to implement)
<alan_g> one process
<duflu> alan_g: I mean is the server spawned from the same thread as the client (test case) runs?
<duflu> Seems like that's my problem
<alan_g> There's a async thread to control the server, plus what the server uses, plus what the client uses
<duflu> alan_g: Put another way - is it possible the server (compositor) and client in mtf are the same thread?
<duflu> That's what I'm seeing, and didn't expect
<duflu> Hmm, assert will tell me
<alan_g> I wouldn't expect it. I guess a test *could* inject client-API calls into one of the compositor threads. But that isn't sensible.
<duflu> alan_g: I'm not aiming for it, but apparently have been given it. The test server and client are the same thread ID
<alan_g> You'd have to do it deliberately
<duflu> alan_g: Never mind. I think I confused the fact that client+server are constructed from the same thread, vs called back in the same thread
<suebt> slvn_: That's the odd thing, I have it already installed oO
<slvn_> suebt, sure? gpgv is different from gpg :/
<slvn_> check if it's on the PATH.. ($> which gpgv_
<suebt> svln_: Yeah, pretty sure http://paste.ubuntu.com/15570065/ It says it is installed to /usr/bin/gpgv
<bschaefer> suebt, no luck :(
<bschaefer> ?
<suebt> No :|
<bschaefer> :(
<bschaefer> suebt, let me ... attempt to cross compile a simple SDL2 file for you
<bschaefer> or actually i have a phone i can compile on... you're on vivid+overlay?
<bschaefer> eww the sdl2 in vivid+overlay is out of date... hmm
<bschaefer> o yeah let me get a newer one pushed to a ppa
<bschaefer> suebt, also :|   * Rebuild against libsndio6.1.
<bschaefer> i see this in the changelog for
<bschaefer> libsdl2
<bschaefer> sooo i think ... the one you could be using could have an ABI break?
 * bschaefer isnt sure what version of libsndio6.1 is in vivid+overlay
<slvn_> suebt, I have retried my script for chroot, and I got the same issue "W: GPG error: http://ppa.launchpad.net vivid InRelease: Could not execute 'gpgv' to verify signature (is gpgv installed?)"
<slvn_> but it seems to compile correctly ...
<slvn_> suebt, I confirmed this works ...
<slvn_> bye+late there ..
#ubuntu-mir 2016-04-01
<zzarr> one of my least complicated questions yet, will Mir work on a computer with Intel HD 3000?
<duflu> zzarr: Yes, absolutely. That's only sandybridge/ivybridge. In fact you could argue Intel HD 3000 is close to the best tested and most mature Mir platform
<duflu> ... because that's what most Mir developers work on most of the time
<suebt> slvn_ bschaefer: Sorry, I had no time yesterday, I'm back now.
 * suebt feels like lacking a lot of knowledge
<suebt> slvn_: I think at least that it failed here, after running setup and cross-compile-chroot -u I don't have the directory ~/release ...
<suebt> slvn_: that's the log http://paste.ubuntu.com/15576073/
<slvn_> suebt, I don't speak german so I don't really understand where it fails ..
<slvn_> suebt, it seems it does not even complete the chroot ?
<suebt> slvn_: sorry, yeah, it looks like the chroot is incomplete. It says: "Package "BauabhÃ¤ngigkeiten" wasn't found. Package "Nicht" wasn't found. Package "erfÃ¼llte" konnte nicht gefunden werden. Apt-download failed. Return value: 100" Where "BauabhÃ¤ngigkeiten" means "tree dependencies", "Nicht" means "not", "erfÃ¼llte" means "match". This makes absolutely no sense as there are for sure no packages with this names /0\
<slvn_> suebt,  ... yep strange switch to english maybe ...
#ubuntu-mir 2016-04-02
<zzarr> nice
#ubuntu-mir 2017-03-27
<alan_g> greyback: I just spotted some QtMir build failures in my silo (2641), but they're not reported as failures on the front page, just in the PPA (https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/2641/+packages) is this normal? Or should I worry?
<greyback> alan_g: no need to worry, those arches are missing dependencies, qtmir hasn't built on those in some time
<alan_g> greyback: thanks. I suspected that was the case, but had to check.
<alan_g> anpok: did you ask you question against the wrong MP? (It seems to be more relevant to the follow-up.) https://code.launchpad.net/~alan-griffiths/mir/request-with-authority/+merge/320825
<anpok> alan_g: oh I did not notice that the follow up was already up for review
<alan_g> anpok: can you at least approve the first? I don't think your question matters there.
<alan_g> attente: do you have an opinion on whether GTK resize already works on Mir? Join the discussion on https://code.launchpad.net/~alan-griffiths/mir/client-initiates-user-move-and-resize/+merge/320917
 * alan_g is nagged into rebooting
#ubuntu-mir 2017-03-28
<alan_g> alf_: I'm not sure how to interpret this failure. Do you understand what's going on? https://mir-jenkins.ubuntu.com/job/device-runtests-mir-testflinger/device_type=krillin,slave_type=manager/119/console
<alf_> alan_g: looking
<alf_> alan_g: a package update (unrelated to the device-runtests-mir-testflinger) was interrupted on jenkins manager leaving the packaging system in an inconsistent state, fixed now
<alan_g> alf_: thanks. (I'll avoid asking how I could have worked that out in the hope that I'll never need to know.)
<alan_g> alf_: same MP, different error (but testflinger infrastructure again I think) - https://mir-jenkins.ubuntu.com/job/device-runtests-mir-testflinger/device_type=krillin,slave_type=manager/121/console
<alf_> alan_g: seems like a transient network glitch, job after it runs fine
<alan_g> alf_: OK, I hope it doesn't become common
<alf_> alan_g: +1
<alan_g> greyback: is your "NI" answered? https://code.launchpad.net/~alan-griffiths/mir/client-initiates-user-move-and-resize/+merge/320917
<greyback> alan_g: I've abstained, I've no objections
<alan_g> greyback: ta
<alan_g> alf_: sorry, but more CI strangeness: what is this? https://mir-jenkins.ubuntu.com/job/generic-land-mp/1309/console
<alan_g> Hmm, it actually merged at -r 4120
<alan_g> ...and then failed to land.
<alf_> alan_g: Yes, just ignore the failure. This is known issue that happens rarely. It's probably some kind of race in the jenkins-launchpad tools, but we haven't been able to track it down.
 * alan_g adopts blissful ignorance
<alf_> Zen in the art of CI
<kdub> AlbertA, good morning! would it be easy for you to do a visual spot-check on lp:~kdub/mir/split-eglstream? Checked on my nvidia card and things seem to work as before, but with no output connected, I can't see that its working correctly
<AlbertA> kdub: yeah I'll give it a spin
<kdub> thanks AlbertA
<AlbertA> kdub: mir_demo_server/mir_demo_client_fingerpaint worked fine here
<kdub> AlbertA, thanks!
#ubuntu-mir 2017-03-29
<duflu> Why is the --host-socket option implemented in the evdev-input driver?
<duflu> Oh it's just used
#ubuntu-mir 2017-03-30
<ZorroDaCat> hi guys
<ZorroDaCat> I was wondering how I can help your project. I would like to contribute either by testing some stuff
<ZorroDaCat> documentation (I speak FR...as in Frog language)
<ZorroDaCat> or even coding.
<ZorroDaCat> I'm so fucking tired of X11
<ZorroDaCat> it has been a problem in my life from day zero with Linux.... back to my slackware days with kernel 1.2.13 in the 90s...
<ZorroDaCat> I really hope that X dies forever
<ZorroDaCat> it's just stopping Linux to evolves
<ZorroDaCat> its a pain in the ass...in the early 2000s i had moved to Mac OS/X because I could finally have a bash prompt and a nice graphical (accelerated) UI......thanks Quartz...
<ZorroDaCat> I'm trying KDE5 Plasma these days...its nice and fast but it keeps on bugging when you search for an app...everything disappears and restarts...reminds me of windows 95 /NT era when you had to kill explorer.exe and restart it...same crap !
<ZorroDaCat> ok ill stop talking
<ZorroDaCat> nobody is listening anyway
<ZorroDaCat> hey
<duflu> ZorroDaCat: Agreed and welcome. But this time of day only Asia/Australia/NZ is online :)
<ZorroDaCat> ok thanks
<ZorroDaCat> np
<duflu> ZorroDaCat: You are free to dive into the code and start hacking ideas. Although we would also appreciate some work on tidying up and triaging the bug backlog bugs.launchpad.net/mir
<duflu> ZorroDaCat: http://unity.ubuntu.com/mir/index.html
<ZorroDaCat> im from Montreal...GMT-5 (NYC time) .... Thanks I'll check that out and come back
<duflu> Nice place. The team was there for a meeting last year
<ZorroDaCat> Should I use the latest 17.04 (Zesty Zapus) to get in sync with all you guys..?? Yeah cool place..but still winter here...
<duflu> ZorroDaCat: Yes the unwritten rule is Unity8/Mir development is only active on the current Ubuntu development series. So 17.04 right now
<duflu> Although lp:mir does build and run fine in 16.04 still
<duflu> And probably 16.10(?). However being neighter LTS nor the bleeding edge 16.10 gets ignored. Which some may find surprising given its the current stable release
<duflu> neither :)
<duflu> it's
 * duflu stops correcting his spelling
<ZorroDaCat> ok i need to reinstall my box anyway...was trying KDE5 on Mint 18  (16.04-based)...will switch to pure ubuntu...and follow the rules
<ZorroDaCat> do you think it's going to be a display server war with Wayland like beta/VHS back in the days ?
<duflu> I don't think it's really a war. People will choose Ubuntu or Fedora or something else. The display server they get is just a consequence of that. So nothing is really new
<ZorroDaCat> I see.. but what about nVidia/AMD supporting one or the other in proprietary drivers?
<duflu> I think we'll have 100% coverage within a year. You will be able to use any driver with any display server
<ZorroDaCat> Wow impressive....I guess both will follow Mir since the most popular distros are all based on ubuntu....
<duflu> I don't think Ubuntu actually has that much influence on Nvidia. They are a very big company. However they are slowly working toward interfaces that will allow everyone to play together
<duflu> In Mir we're lookin at supporting the proprietary Nvidia driver this year
<duflu> It's in progress
<duflu> And actually much of the code is already started. You can find it in the source tree as src/platforms/eglstream-kms/
<ZorroDaCat> okay.... im just thinking outloud :) intel seems to contribute more and more code the last few years with <intel graphics for linux> initiative
<ZorroDaCat> i mean for intel graphics of course
<duflu> Certainly Intel is a very big open source contributor. But they have to be if they want to sell hardware
<ZorroDaCat> im not a gamer but im thinking about getting a new intel cpu with integrated graphics...i only got an old amd quad core (kabini:low power APU) at the moment...with a gt710 nv card..
<ZorroDaCat> yeah
<duflu> ZorroDaCat: The nouveau driver is a problem right now for Mir/Unity8. If you can avoid using it please do.
<ZorroDaCat> ok i could use the builtin radeon from the APU....np...
<duflu> Yeah I think the open source radeon driver is much more solid
<ZorroDaCat> i also got my wifes mid-2012 macbook air with intel graphics...but I've never tried linux on it...dunno if she would be happy that I partition/dual boot her laptop , eh LOL :)
<ZorroDaCat> btw who makes the best desktop PCs right now for ubuntu...system76?
<ZorroDaCat> ok going to bed.....good morning to all of you...thanks again duflu
<duflu> ZorroDaCat: Laptops are personal choice :) Later...
<duflu> also a personal choice
<duflu> RAOF: Can I assume we stopped using connector_id because it's not unique?
<duflu> Have I asked this already? Don't remember
<RAOF> duflu: I'm not entirely sure whether it's unique or not (it probably is).
<RAOF> I stopped using connector_id because it's easier to pass in a drmModeConnectorUPtr.
 * duflu wonders where those numbers come from. Maybe dev nodes?
<RAOF> They're drm identifiers.
<RAOF> They mostly get assigned by drm core when the driver says âand I've got an outputâ.
<hikiko> hello :)
<hikiko> alan_g, and other mir people, I dist-upgraded and ran miral-shell and received a segfault, here's the bt:
<hikiko> https://pastebin.com/print/CqEL9vZT
<hikiko> any ideas if I am missing some package, or what this could be?
<hikiko> maybe it's normal to see this when I am not root?
 * alan_g looks
<alan_g> hikiko: it isn't normal. Are you using miral-shell from the archive or a local build?
<hikiko> alan_g, from the repository but when I am root it's fine
<hikiko> I am also running on a schroot
<hikiko> I don't know if that's relevant
<alan_g> what's the commandline?
<hikiko> just miral-shell
<hikiko> without parameters
<alan_g> what is the console output
<alan_g> ?
<hikiko> https://pastebin.com/raw/vmXKAwZh
<hikiko> alan_g, ^
<alan_g> hikiko: that looks like a failure to open the X socket - but I don't see how that leads to the backtrace
<hikiko> no idea either
<alan_g> But then I don't use schroot much
<hikiko> alan_g, it shouldn't be schroot
<hikiko> because I could start miral-shell before
<hikiko> with the same settings
<alan_g> Can you start a normal X11 app? Say gedit?
<hikiko> yes alan_g
<hikiko> everything else is working
<alan_g> Does mir_demo_server fail the same way?
<hikiko> let me check
<hikiko> alan_g, how can I run mir_demo_server?
<hikiko> do I need to build mir?
<hikiko> or it's somewhere installed?
<alan_g> sudo apt install mir-demos && mir_demo_server
<hikiko> yes
<hikiko> exactly the same message
<hikiko> https://pastebin.com/hBxnjgKY <- alan_g mir_demo_server message
<alan_g> thanks for confirming that.
<alan_g> I don't have a quick solution - can you log a bug (including the schroot setup)?
<alan_g> Sorry.
<alan_g> The bug should be against Mir.
<hikiko> no problem alan_g :) I ll log it in a while, thanks a lot!
<hikiko> yes, it's obviously not miral
<hikiko> here it is: https://bugs.launchpad.net/mir/+bug/1677523
<ubot5> Ubuntu bug 1677523 in Mir "mir_demo_server segfaults in schroot" [Undecided,New]
<alan_g> hikiko: thanks
<hikiko> yw
<alan_g> WTF?! I just updated zesty and miral-shell now crashes on startup
<alan_g> Server supports 2 of 10 surface pixel formats. Using format: 3
<alan_g> terminate called after throwing an instance of 'std::range_error'
<alan_g>   what():  wstring_convert::from_bytes
<alan_g> Oh, it's std::wstring_convert<std::codecvt_utf16<wchar_t>>
<hikiko> alan_g, yes
<hikiko> same here
<hikiko> and I have this error:
<hikiko> https://bugs.launchpad.net/miral/+bug/1658159
<ubot5> Ubuntu bug 1658159 in MirAL "miral-shell depends on default cursor theme being installed" [Low,Fix released]
<hikiko> although
<hikiko> dmz is installed
<alan_g> hikiko: I'm working on a fix, but miral-kiosk and 'miral-shell --window-manager tiling' will work in the meantime
<hikiko> let me try
<hikiko> mmm no
<hikiko> alan_g, miral-shell --window-manager tiling doesn't work
<hikiko> same error
<alan_g> I'm talking about the std::wstring_convert<> error
<hikiko> oh ok
<hikiko> I'll try to get a look at the other one alan_g it shouldn't happen, I have your fix here
<hikiko> maybe I can collect more info if I build mir
 * alan_g finds C++ locales and facets less confusing now than at the start of the day. (But still thinks it is too hard.)
<bregma> there's a very good reason C++ locales and their facets are rarely used in production code
<camako> tjaalton, will X+O be getting the new Mesa as well?
<tjaalton> camako: you mean X+Y? yes, but not necessarily the new mir patches
<tjaalton> https://launchpad.net/~ubuntu-x-swat/+archive/ubuntu/updates doesn't have it
<camako> tjaalton, xenial+overlay
<tjaalton> I don't know
<camako> hmm we use that in CI
<tjaalton> what's an overlay?
<tjaalton> in this context
<camako> just the overlay PPA
<tjaalton> still a mystery to me :)
<tjaalton> this will end up in xenial-updates
<camako> tjaalton, ok forget the overlay part :-)
<tjaalton> with whatever mir related you need
<camako> so it'll be in xenial, correct?
<tjaalton> right now it's still using the old patch because the new mir isn't there
<tjaalton> yes
<tjaalton> some time after zesty is released
<camako> Ah ok
<camako> thanks
<camako> tjaalton, why the dependence on zesty?
<camako> just curious
<tjaalton> I just want it to be on a release first
<tjaalton> and since it's kinda part of the backport stack, just not renamed anymore
<tjaalton> actually, there is some pressure to push mesa to -updates earlier
<camako> ok
#ubuntu-mir 2017-03-31
<hikiko> alan_g, ping :) could I ask you something for mir/miral?
<alan_g> hikiko: ?
<hikiko> hey
<hikiko> I was still having that crash and no backtrace so I ve built both mir and miral and install them both in /usr/local
<hikiko> now when I run miral-shell
<hikiko> I get this error:
<hikiko> https://paste.ubuntu.com/24287021/
<hikiko> do you know what this is about? I understand something is missing but not sure what...
<alan_g> required by /usr/lib/x86_64-linux-gnu/libmirserver.so.43 says you're not using the local one. Did you forget to run ldconfig?
<hikiko> :)
<hikiko> that was it!
<hikiko> it was trying to link with the wrong mir :)
<hikiko> thanks alan_g!
<kdub> hmm, the drm platform does not work well with rendernodes
<flohack> Hi anyone here who compiled libhybris successfully? =)
<bregma> kdub, see flohack's question^^ ?
<kdub> no, but now I do
<kdub> flohack, I have!
<kdub> at least the ubuntu side of it
<kdub> here's my autogen line
<kdub> ./autogen.sh --prefix=/usr --libexec=/usr/lib/aarch64-linux-gnu --enable-arch=arm64 --enable-mali-quirks --enable-mir --enable-debug --enable-ubuntu-linker-overrides --enable-property-cache --enable-experimental
<kdub> and I think I compiled in a dirty arm64 chroot to do an emulated cross compile
<flohack> hm
<flohack> oki let see
<flohack> thanks :)
<flohack> unfortunately autgen corrupts configure script somehow...
<flohack> on the device
<flohack> kdub, I still get:
<flohack>  /usr/bin/ld: ../.libs/mm_la-strlcpy.o: Relocations in generic ELF (EM: 40)
<flohack> ../.libs/mm_la-strlcpy.o: error adding symbols: File in wrong format
<flohack> collect2: error: ld returned 1 exit status
<flohack> so it cross-compiles but does not cross-link xD but Ok I am trying to add
<flohack> --build=x86_64 --host=arm-linux-gnueabihf
<kdub> yeah, I don't think I did a true cross compile, just an emulated one
<flohack> Kdub did you use github master branch?
<kdub> no, the ubuntu src package
<kdub> they'll be one in the same in a short while again, but we had to make some patches that are yet to have bene upstreamed
<flohack> God now automake is broken...
<flohack> Im on the device, but configure script has macro garbage inside
<flohack> cannot execute properly
<flohack> Ok disregard it works now
#ubuntu-mir 2017-04-02
<gouchi> Hi
<gouchi> It will be nice to have Mir driver context for RetroArch => https://github.com/libretro/RetroArch/tree/master/gfx/drivers_context
<gouchi> As there is already Wayland one https://github.com/libretro/RetroArch/blob/master/gfx/drivers_context/wayland_ctx.c
<ogra> file a whishlist bug (there are rarely devs around on weekends)
<gouchi> I see thank you
