#ubuntu-mir 2013-09-02
<RAOF> You know what would be really awesome?
<RAOF> Documentation of the ownership semantics of pointers we pass into mirclient.
<duflu> RAOF: What is the ID in "X -mir ID" ?
<RAOF> It's the name that XMir uses to identify its connection.
<RAOF> duflu: It's a string that usc uses to distinguish between different xservers.
<duflu> RAOF: Oh, my mistake for assuming it was always an int
<RAOF> It's passed verbatim through to mir_connect
<RAOF> usc just happens to pass integer strings for it :)
<duflu> RAOF: Ah, kay. I know the connect string is harmless. Didn't know that's what -mir ID was
 * RAOF should possibly document it better
<oiaohm> RAOF: sometimes is great when a team has a techical writer for some of these items that need documentation.  They don't get destracted by needing to code.
<duflu> oiaohm: That's true, you do get better results with dedicated technical writers. However in this case we're talking about a very small section of code, not part of any docs
 * duflu is impressed that --display-config sidebyside figures out where the monitors are in space and gets them *backwards* every time ;)
<duflu> RAOF: Is there a reason why XMir changes the monitor layout immediately on startup, even with zero X clients?
<RAOF> duflu: Because that's X's default behaviour, and I haven't yet overridden it.
<duflu> RAOF: Kind of?... X without Mir doesn't change the resolution or start mirroring. Whereas XMir does both (bug 1216224)
<ubot5> bug 1216224 in XMir "[multimonitor] XMir defaults to wrong resolution 1152x864 instead of 1920x1200." [Undecided,Confirmed] https://launchpad.net/bugs/1216224
<RAOF> duflu: xf86-video-intel overrides X's default behaviour.
<duflu_> Whee, i915 hangcheck
<oiaohm> There are a lot of horible x11 features killed by drivers.
<tvoss> good morning :)
<RAOF> Aloha!
<smartboyhw> tvoss, hello:)
<tvoss> smartboyhw, hey there :) how is it going?
<smartboyhw> tvoss, quite good:) How's XMir?
<tvoss> smartboyhw, alive and we made feature freeze, now some issue to fix
<smartboyhw> tvoss, \o/
 * duflu goes to find lunch, and the store
<duflu> tvoss: BTW if there are still radeon corruption issues without bugs, please log another bug. We only have one right now... bug 1218815
<ubot5> bug 1218815 in xorg-server (Ubuntu) "[radeon] Graphic glitches and screen corruption since the latest update" [Undecided,Incomplete] https://launchpad.net/bugs/1218815
<RAOF> Harumph.
<RAOF> Why am I receiving unpared focus/unfocus events?
<RAOF> Oh, of course!
<RAOF> mir_surface_release doesn't implicitly trigger a focus lost event.
<duflu> RAOF: Wonder if it should....
<RAOF> It would make my life easier.
<RAOF> And I don't think that my use case is *that* peculiar.
<RAOF> And given that I need to add at least *some* code to make this work...
<duflu> RAOF: Though that's another reason why the even should be on the connection rather than on the surface...
<RAOF> Well, possibly multi-layered?
<duflu> Don't know
<duflu> RAOF: Is there a way to make X not ignore the LD_LIBRARY_PATH?
<RAOF> It doesn't ignore LD_LIBRARY_PATH
<duflu> Hmm, mine is
<RAOF> Are you trying to pass LD_LIBRARY_PATH througgh sudo again?
<duflu> RAOF: No
<RAOF> Hm. Should work. I've used it in the past.
<duflu> RAOF: Sanity check: Does the frame ordering issue occur on nouveau/radeon?
<RAOF> duflu: I don't know; I don't have dual-head nouveau/radeon set up.
<duflu> RAOF: Sanity check (2): What branch/URL contains the latest XMir?
<RAOF> duflu: The Ubuntu archive.
<dholbach> good morning
<duflu> Oh, I'm cloning that just now
<duflu> Morning dholbach
<dholbach> hi duflu
<RAOF> Aha! unity-system-compositor needs to handle this. Maybe.
<duflu> RAOF: So... maintaining in archive means maintained as a patch? That sounds painful
<duflu> Possibly less painful than not being in archive though
<RAOF> duflu: Ah, no. I maintainish on vladmir-upstreaming branch of github, then dump the diff of that against vladmir-upstream-base to generate the patch.
<RAOF> duflu: If you want to do upstreamish hacking on xmir that's where you should hack, but if you want to do printf debugging you want to start with the archive.
<duflu> Yep
<RAOF> We appear to have three subtly different focus mechanism classes in Shell :/
<duflu> Awesome. More the merrier
<duflu> Or is that backwards?
<duflu> Argh. How can building the archive version have missing symbols when my machine is up to date?
<RAOF> *Fails* with missing symbols?
<RAOF> (Also, what do you mean by missing symbols?)
<duflu> RAOF: X: symbol lookup error: /usr/lib/xorg/modules/drivers/intel_drv.so: undefined symbol: xmir_window_to_windowptr
<RAOF> Hrm. Odd.
 * duflu rebuilds the intel driver
<RAOF> Is xmir successfully loading/?
<RAOF> Because that woud happen in the past when xmir failed to find mir, and then would unload itself.
<RAOF> But I thought I made those errors fatal.
<duflu> RAOF: Yes, now. But my packages are kind of screwed now. Trying to fix
<duflu> RAOF: Oh. Someone has been dputting without updating the lp:ubuntu/....
<RAOF> lp:ubuntu/ is automatically maintained. When it works.
<duflu> Yeah it's quite behind right now
<duflu> A few weeks
<duflu> Maybe apt-get source will give me the actual correct code...
<RAOF> It shall.
 * mlankhorst pokes tvoss with a glmark2 deb
<tvoss> mlankhorst, yeah :)
<tvoss> mlankhorst, sent
<tvoss> mlankhorst, sent you armhf, too
<tvoss> mlankhorst, not sure you need them, though
<duflu> RAOF: Unexpectedly I appear to have fixed the artifact'd cursor
<tvoss> duflu, how so? :)
<duflu> tvoss: Maybe I just hid it by going slower. Added more mir_wait_for in xmir
<duflu> I'm still concerned by XMir's apparent lack of synchronization though
<RAOF> duflu: What were you mir_wait_foring?
<duflu> RAOF: The swap buffers
<RAOF> Oh, yeah. That'd be adding significant wait.
<duflu> RAOF: Cos there doesn't seem to be any guarantee otherwise that mir_surface_get_current_buffer is getting for the correct frame
<RAOF> Nothing should call that until has_free_buffer is true, which is set in the buffer_received callback.
<RAOF> And we should only ever have one swap_buffers in flight at any one time.
<RAOF> (per surface)
<duflu> RAOF: OK, will have a closer look next time I'm in XMir
<duflu> Ping alan_g
<alan_g> duflu: good morning
<duflu> alan_g: Hi. Something that's tripped me up a few times... the display server test fixture hangs if you try to swap buffers more than once. Any idea why?
<alan_g> duflu: yes
<duflu> Umm, good.
<alan_g> duflu: It uses a stubbed graphics component that never consumes buffers
<duflu> alan_g: I keep getting lost in the whole "this test is now three processes" :( Do you think you can propose a way to consume them?
<RAOF> Why does C++11 not contain features in C99? :(
<alan_g> duflu: I can add it to the list. (I'll probably need a fuller test graphics implementation for nested mir at some point)
<alan_g> RAOF: because they're bad ideas?
<duflu> RAOF: Because the ideas are *too good*
<alan_g> Does anyone implement all C99 anyway?
<duflu> RAOF: Consider it a fork with no recent common ancestor :/
<RAOF> alan_g: I don't think designated structure initialisers are a bad idea ;)
<tvoss> RAOF, now that's a good idea, indeed. Have stumbled over that multiple times, too
<alan_g> RAOF: as best as I can tell the only reason is that no-one proposed adding them
 * duflu also votes for dynamically sized arrays in the local stack frame
<duflu> I think people raised that as a security risk though
<duflu> alan_g: Strangely, multiple swaps started working recently (with the switch branch??) and we added a test case that depends on it. But now I'm working on new buffering changes, the new test case hangs (expectedly)
<alan_g> duflu: in that case I have no idea
<duflu> alan_g: OK, I *think* I found a fix. Will propose it soon
<greyback> Hi folks, I've an 26" Apple display in front of me that I want to use as second monitor with my macbook pro. When I plug it in, I get black screens, except for on my laptop where the cursor remains. If I try to move the cursor, it takes 2-5 seconds for the display to update. Ideas?
<duflu> greyback: radeon by any chance?
<greyback> duflu: nope, intel sandybridge
<duflu> greyback: Anything chewing CPU while the cursor is slow?
<greyback> duflu: any way I can tell, without needing a second device to SSH in?
<greyback> note unplugging made everything ok again
<duflu> greyback: With Mir you will often need a second device for ssh :(
<duflu> greyback: It's only OK _while_ unplugged?
<greyback> duflu: yes. Plugged in, laptop display black screen with cursor, Apple display unchanged, as if not plugged in at all. If I unplug, laptop display returns to normal
<duflu> greyback: Normal X session you mean?
<duflu> greyback: X will auto-enable remembered multi-monitor layouts when new monitors become available AFAIK. Maybe you should start fresh by removing ~/.config/monitors.xml
<greyback> duflu: yes, I'm using XMir. Ok will try that.
 * greyback just pulled updates, will reboot for safety
<duflu> greyback: You're not the only one reporting a black screen. So it would be helpful to get to the bottom of
<greyback> duflu: ok. Will let you know once I reboot. Also have my tablet here with terminal app, so should be able to ssh into my laptop
<duflu> greyback: Is that soon? I am off in a minute...
<greyback> duflu: I'll probably be 5 minutes. No worries if it's your EOD
<duflu> greyback: OK, I can easily track the issue if you log a bug :)
<greyback> duflu: ack
<mlankhorst> tvoss: hm sent me where?
<tvoss> maarten.lankhorst@canonical.com
<mlankhorst> odd, didn't arrive then
<mlankhorst> oh nm i see it now
<mlankhorst> derp
<alan_g> hikiko: have you time to review https://code.launchpad.net/~alan-griffiths/mir/tidy-up-nested-class-responsibilities/+merge/183233?
<hikiko> yes alan_g
<hikiko> in a sec to finish something
<mlankhorst> tvoss: hm seems most likely that nouveau is syncing glmark2 to vblank :P
<tvoss> mlankhorst, oops :)
<tvoss> mlankhorst, however, having something like 60fps would already be better than last week, both for X and XMir
<mlankhorst> try glmark2 --off-screen
<tvoss> RAOF, ping
<penghuan> hi, i build mir locally, i got an error, "undefined symbol: eglCreateImageKHR", how can i resolve this
<alan_g> penghuan: I can only guess that you've not got the right dependencies installed in your build environment. You've followed these instructions? http://unity.ubuntu.com/mir/building_source_for_pc.html
<smartboyhw> tvoss, (and the Mir team), I can't seem to load lightdm using XMir
<tvoss> penghuan, do you have libhybris or libhybris-dev installed?
<tvoss> smartboyhw, not sure what you mean? what are the symptoms you see?
<smartboyhw> tvoss, after Plymouth, it went black
<smartboyhw> Well, seems like that I have to report a bug:(
<tvoss> smartboyhw, that's fine :) please make sure to attach the relevant logs including dmesg
<smartboyhw> tvoss, for dmesg, how can I find PAST logs?
<smartboyhw> Since I've now booted in using Xorg
<tvoss> smartboyhw, you cannot really resurrect it, sorry
<tvoss> smartboyhw, what kind of setup are you testing?
<smartboyhw> tvoss, so unfortunately, I can't include it then
<smartboyhw> tvoss, Ubuntu 13.10
<tvoss> smartboyhw, in terms of hw?
<smartboyhw> tvoss, laptop (amd)
<smartboyhw> I mean, amd card
<smartboyhw> tvoss, Bug 1219847
<ubot5> bug 1219847 in mir (Ubuntu) "XMir can not start LightDM" [Undecided,New] https://launchpad.net/bugs/1219847
<tvoss> smartboyhw, thanks
<smartboyhw> But, I can't attach anything (in Firefox or Chromium) weird
<jibel> I get bug 1218456 with xserver-xorg-video-ati
<ubot5> bug 1218456 in xorg-server (Ubuntu) "Xorg assert failure: X: ../../../../include/privates.h:123: dixGetPrivateAddr: Assertion `key->initialized' failed." [Critical,Confirmed] https://launchpad.net/bugs/1218456
<tvoss> jibel, I assume you upvoted it?
<jibel> tvoss, yes
<tvoss> jibel, thanks for reporting :)
<jibel> tvoss, yw, let me know if you need more info, this is my main work machine :)
<tvoss> jibel, ;)
<tvoss> kdub, ping
<kdub> hello tvoss
<tvoss> kdub, unping, it's labor day, isn't it?
<kdub> it is, but i thought I'd quickly update myself and check our status after my time off :)
<tvoss> kdub, ff is passed, we do see some performance issues on the galaxy nexus
<tvoss> kdub, first of all: welcome back :)
<kdub> thanks :)
#ubuntu-mir 2013-09-03
<racarr> Hello!
<RAOF> No longer eating delicious desert?
<racarr> Back home :D it will probably take a few days for the dust to fully leave my lungs though.
<RAOF> Ooh. I *can* slot in a MockSurface. Yay!
<RAOF> Oh, no.
<RAOF> That's a lie.
<smspillaz> racarr: !!
<robert_ancell> RAOF, did you get anywhere with XMir+focus switching?
<RAOF> robert_ancell: Yeah, I'm just preparing to propose a Mir branch to fix an annoyance there.
<robert_ancell> RAOF, cool
<robert_ancell> RAOF, also, do you think there's any version dependency that could help bug 1218932?
<ubot5> bug 1218932 in Unity System Compositor "unity-system-compositor should depend on >= version of xserver-xorg-video-<driver> (intel|nouveau|radeon) that works with it." [Undecided,Confirmed] https://launchpad.net/bugs/1218932
<robert_ancell> The depends of u-s-c on xmir is a bit suspect already, not sure if there's any minimum version that makes sense
<robert_ancell> actually, I guess that should be mir with a minimum version on a driver, though it should be a recommends I guess
<RAOF> Yeah, I need to think about that a bit more.
<racarr> smspillaz: !!?!!
<RAOF> robert_ancell: https://code.launchpad.net/~raof/mir/unfocus-on-surface-destroy/+merge/183563 is available for your pleasure.
<robert_ancell> RAOF, the name sounds like a useful feature :)
<robert_ancell> RAOF, does the destroy event not get to the client?
<RAOF> robert_ancell: It does, but you don't know whether the surface was focused or not.
<robert_ancell> RAOF, would it be better just to add a mir_surface_get_has_focus()? This isn't like X - Mir will always notify if you get focus
<robert_ancell> I'm just thinking that unfocus due to deletion is a slightly separate case to being unfocussed for a particular reason
<RAOF> It is, yes. I could add has_focus(), but it would be a bit racy - you'd need to check it in the surface deletion callback to avoid possibble races (and that's non-obvious).
<robert_ancell> RAOF, you say "We probably need to rethink focus entirely, but this is an incremental improvement that I need" - can't XMir track the focus itself?
<RAOF> I could, yes.
<RAOF> robert_ancell: Actually, I'm not sure whether I *could* do focus tracking in XMir. Aside from the locking being a huge pain in the arse, I'm not clear on what our message ordering guarantees are.
<RAOF> I could do it with a mir_surface_get_has_focus(), though.
<robert_ancell> RAOF, for input it doesn't matter about ordering right? You grab input devices when getting a focus event, and drop them when getting an unfocus or destroy
<robert_ancell> RAOF, but with duflu's second opinion, I'm happy to approve the MP anyway
<duflu> I think it's OK to say "we're not really sure what's focussed when" for now. The API is too racy (by design) to be sure.
<RAOF> That branch guarantees that a released surface always ends up unfocused from the client API's perspective.
<robert_ancell> RAOF, btw, I was thinking - do you think XMir will drop the input devices fast enough when switching to the second XMir? Could both XMirs get duplicate events during the changeover?
<RAOF> Fair question; that's entirely possible.
<duflu> robert_ancell: Even if you guaranteed ordering in the protocol, you can never guarantee when each XMir will be scheduled by the kernel and process the messages.
<robert_ancell> duflu, correct
<robert_ancell> duflu, but if XMir is being driven by the events, then the ordering isn't really relevant to it in this case
<robert_ancell> RAOF, btw, did you see https://dvdhrm.wordpress.com/2013/08/25/sane-session-switching/
<RAOF> robert_ancell: Yeah.
<RAOF> I think I commented on that one?
<RAOF> Yes :)
<robert_ancell> ah, I didn't read the comments. Due to blog comments almost always being crap. I guess planet.freedesktop probably has more credibility here
<RAOF> Heh.
<RAOF> robert_ancell: So, probably the *correct* way to do this is a synchronous âplease switch nowâ client API for xmir.
<robert_ancell> RAOF, I was wondering if we are forced to do it the correct way or continue with our hack
<RAOF> It depends on how fixed you want the bug.
<robert_ancell> RAOF, fixed enought that it doesn't bite us in the arse later
<RAOF> Without a request/ack style API there *will* be periods where both X servers are consuming events.
<robert_ancell> RAOF, yeah, I think we just have to bite the bullet and do it properly via u-s-c. I don't really want to add it into the Mir protocol, but that would be the easiest and most reliable place to put it
<RAOF> We don't have anywhere else to put it :/
<robert_ancell> RAOF, well, if XMir could contact u-s-c via a different socket we could do something custom and temporary. But XMir doesn't really know u-s-c exists
<RAOF> We could teach it.
<RAOF> It'd not be super hard.
<robert_ancell> RAOF, I suppose we could open a pipe and give you the fd in an env variable
<RAOF> Or as another commandline option.
<RAOF> Note: we are discussing the most terrible thing ever. âº
<robert_ancell> Yes, I feel dirty
 * duflu goes to play in the rain, erm lunch
<duflu> RAOF: Any idea why X is always slightly clumsy at changing modes? I always see flickering and sometimes briefly misplaced outputs while it reconfigures. This happens without X too. Plain Mir doesn't.
<duflu> This happens *without* Mir too
<duflu> Ugh. I mean the issue with X pre-dates Mir. A pure Mir environment seems to switch layouts much more cleanly. But I guess I haven't seen pure Mir switch modes yet
<RAOF> duflu: I think XMir exposes a case where Mir does some unnecessary modesetting.
<duflu> RAOF: No I mean X has always done this... without Mir
<RAOF> But the X issue is bound up in X's "one framebuffer to rule them all"
<RAOF> ie: you *can't* turn on a new monitor without touching the existing monitors.
<duflu> Oh. Yes.
<RAOF> Various drivers can do better and worse at mitigating that; Intel seems to make a fair amount of trouble to mitigate that (copying the contents of the previous framebuffer, etc)
<duflu> RAOF: On an unrelated note, would intel's double/triple buffering in the DDX affect the generic logic of the xmir module?
<RAOF> I don't believe so, no; from memory, those codepaths are in the drmmode bits, which we bypass.
<RAOF> Bah! How do I get Jenkins to retry the flaky test?
<duflu> RAOF: Click on the link. Or shout at it.
<RAOF> What's the IP of s-jenkins?
<RAOF> That's behind the VPN, right?
<duflu> Think so
<duflu> RAOF: Any tips for explorers wishing to dive into XMir's damage tracking?
<RAOF> duflu: The main business is in xmir-window.c, where xmir_window_get_dirty maintains a circular list of damage regions in struct xmir_window.
<duflu> RAOF: And xmir_window is effectively one Mir output?
<RAOF> Right. We have one xmir_window per output (strictly speaking, one per CRTC)
<RAOF> They're sitting in xmir_screen->root_window_fragments
<hikiko> RAOF, should the multimonitor work in the lightdm screen?
<hikiko> (before we start unity)
<RAOF> hikiko: Yes, but you'll have mirrored displays because unity-greeter doesn't set anything different.
<hikiko> mmm is there any setting in lightdm I should have or the defaults are fine?
<RAOF> The defaults are fine.
<hikiko> in an Intel 4000 I have multimonitor working on unity but not in lightdm
<hikiko> which is very strange
<RAOF> As in: your second display doesn't show anything?
<hikiko> it shows a vertical purple line
<hikiko> I ll upload a screenshot in a while
<hikiko> RAOF: http://i.imgur.com/ulUN09l.jpg
<hikiko> but as soon as I login everything is working fine
<RAOF> Huh.
<RAOF> Interesting.
<RAOF> I wonder what it's doing?
<hikiko> maybe there's something wrong in my system
<hikiko> how can I check that lightdm uses xmir for sure?
<RAOF> grep -i xmir /var/log/Xorg.${DISPLAY#:}.log
<hikiko> also this occurs when I have the 2nd monitor plugged from the begining, I will check what happens if I start without the 2nd monitor plugged
<hikiko> in Xorg.2.log I have this line:
<hikiko> [  2356.280] xorg-server 2:1.13.3-0ubuntu6+xmir3 (For technical support please see http://www.ubuntu.com/support)
<hikiko> am I using xmir?
<dholbach> good morning
<hikiko> good morning dholbach
<hikiko> RAOF, ^ I think I use xmir... shall I fill a bug report?
<RAOF> hikiko: That would suggest that you're *not* using mir
<RAOF> Also, that you've got an old Xserver :)
<hikiko> haha
<hikiko> great
<dholbach> hi hikiko
<hikiko> so RAOF
<hikiko> there must be a conf?
<RAOF> hikiko: Do you have unity-system-compositor installed? It installs /etc/lightdm/lightdm.conf.d/10-unity-system-compositor, which enables usc and hence XMir.
<hikiko> or installing xserver-xorg-mir is enough
<hikiko> RAOF, if I run apt-get install there are extra packages :) it should be that
<hikiko> (I mean apt-get install unity-system-compositor)
<RAOF> Yeah, apt-get install unity-system-compositor should do it.
<hikiko> ok I found what it was: when you upgrade unity-system-compositor with apt-get install there's a question
<hikiko> install the package maintainer's version / keep your current etc and default == keep current
<hikiko> let me try again
<hikiko> fixed :D
<hikiko> RAOF, now unity wallpaper
<hikiko> has the size of the small monitor
<RAOF> Yup, that sounds right.
<hikiko> and the dash
<RAOF> We clone by default.
<hikiko> ok so I leave it like that?
<RAOF> Oh, you probably want to set up a spanned desktop; the Displays capplet will let you do that.
<RAOF> You can set it up just like you want.
<hikiko> cool :)
<hikiko> and RAOF another question (final)
<hikiko> I want to test xmir for the first time
<hikiko> I build and run ./mir_demo_server... --enable-xmir and that's all?
<hikiko> what should I expect to see?
<RAOF> hikiko: Once you've installed unity-system-compositor you'll be using xmir all the time.
<hikiko> I mean the xmir I will build
<hikiko> not the system's xmir
<RAOF> Ah. In that case, run mir_demo_server_shell, and then on a different VT run âXorg :33 -mir 1 -retro -verbose 7â
<RAOF> (The :33 and 1 are just placeholder values; you can use whatever you want there)
<RAOF> When you switch back to mir_demo_server_shell you'll see the delightful X root weave, which is the black and white crosshatch thingy.
<hikiko> and then how do you stop it? just killing mir_demo_server_Shell?
<RAOF> Ctrl-C works fine :)
<duflu> hikiko: Ctrl+Alt+Backspace is how you get out of mir_demo_server_*
<duflu> Ctrl+C was disabled a while back
<hikiko> yes that's what I noticed :)
<hikiko> thanks duflu and RAOF :D
<RAOF> Oh, yeah. But Ctrl+C will kill Xorg.
<RAOF> When you VT switch back to your Xorg-running VT.
<hikiko> oh, I see
<hikiko> and one more question to setup a spanned desktop do I need to do something on mir or I do it from unity settings?
<hikiko> found
<duflu> RAOF: Woo, no time-travelling frames any more
<tvoss_> duflu \o/
<duflu> Just need to *repeat* and verify. It's not a fix. Just a hack right now
<tvoss_> duflu, what is the idea?
<duflu> tvoss_: XMir seems to be reporting incorrect damage regions
<tvoss_> duflu, ah
<duflu> tvoss_: Still, somehow, affected by XMir's multimonitor logic
<tvoss_> duflu, hmmm ... interesting
<tvoss_> duflu, go ahead then ;)
<hikiko> is there any way to temporarily disable xmir?
<smspillaz> tvoss_: ^ interesting comment by duflu - do apps need to provide a damage region or is it just assumed to be sizeof(surface) on swap_buffers?
<smspillaz> I didn't see anything in the mir api about it
<tvoss_> smspillaz, no damage region, yet
<smspillaz> tvoss_: ah okay. What was duflu's comment about damage regions about then?
<tvoss_> smspillaz, duflu was talking about the xmir world, so mostly the x <-> mir integration parts over there
<smspillaz> tvoss_: ah you mean xmir reporting incorrect damage regions to x clients?
 * smspillaz thought that xdamage didn't live in the ddx
<tvoss_> smspillaz, I would think vice-versa
<tvoss_> smspillaz, let me check
<sil2100> Hi everyone!
<sil2100> Do you know if we still need to enable the Mir PPA for daily-releasing Mir?
<sil2100> i.e. D09add_ppa~mir-team~staging ?
<sil2100> Since I would prefer not to use non-standard PPAs when releasing stuff
<sil2100> kgunn: ^ do you know?
 * alan_g wishes he didn't need to learn so much about [E]GL
<kgunn> sil2100: mir is in archive...no ppa needed
<sil2100> Awesome
<kgunn> at most, for those not already running xmir...just apt-get install unity-system-compositor
<racarr> Morning!
<kgunn> racarr: welcome back
<kdub> good morning!
 * kdub is back
<racarr> kgunn: Thanks :)
<alan_g> racarr: welcome back
<racarr> alan_g: Thanks :)
<kgunn> kdub: welcome back!!
<kdub> thanks!
<racarr> I keep on looking for some email titled like
<racarr> Mirpocalypse
<racarr> but havent found it yet. Seems like things are going pretty well?
<alan_g> racarr: no dramatic failures
<alan_g> but we've not been able to address the lack of a coherent data model and there are plenty of bugs and missing features
<racarr> alan_g: :) Thanks.
<racarr> Yay, email finished
<racarr> I think I replied to all emails last week (except bugs + MRs) that warrant a response from me
<racarr> so if you sent me an email last week and are waiting to hear back
<racarr> please resend / ping me.
<racarr> kgunn: Hey. I think I am keeping myself busy until lunch catching up on commit logs then bugs but can we schedule a sync for this afternoon maybe
<racarr> So I can prioritize some tasks?
<kgunn> racarr: sounds good
<kgunn> i've got thing around 4pm my time...other than that i'm pretty open
<racarr> kgunn: Ok how about in 2.5 hours (3 your time?)
<kgunn> sounds good
<racarr> Ok. Thanks :)
<racarr|lunch> Back soon!
<racarr> updating my phone image now
<racarr> excited to see last weeks progress :)
<kdub> racarr, once you've updated, could you try the acceptance tests? seeing some failures there on the phone
<racarr> kdub: ok
<racarr> updating my phone image earlier really meant charging my ultra dead neuxs 4 so it will be a bit stil
<kdub> yeah, mine died a few times mid-update because it ran out of battery
<racarr> its so obvious that comcast has been throttling me and is now rewarding me for not using any internet for a week -.-
<racarr> Been getting like 3MBs all day
<racarr> Phone looks pretty great :)
<kgunn> racarr: on the phone...you notice the flicker yet ?...i'm wondering if that's z-order fighting
<kgunn> kdub: ping
<kdub> kgunn, pong
<ricmm> racarr: ping
<kgunn> kdub: hey...so i was trying to do mir logging on android...so i did stop unity8, then exported
<kgunn> MIR_SERVER_MSG_PROCESSOR_REPORT=log
<kgunn> MIR_SERVER_DISPLAY_REPORT
<kgunn> =log
<kgunn> MIR_SERVER_GLOG=1
<kgunn> and MIR_SERVER_GLOG_LOG=/tmp/
<kgunn> but...no luck
<kgunn> did i miss something
<kgunn> (obviously i restarted unity8 after all that)
<kdub> hmm, seems like that should work
<kgunn> kdub: is the log file names something funny (like j1jk2k3.something) or something obvious like (mir_glog.log)
<kdub> MIR_SERVER_GLOG_LOG_DIR=/tmp
<kdub> kgunn^^
<kdub> the name should be... mir.hostname.user.loglevel.timestamp
<racarr> ricmm: Pong!
<racarr> kgunn: Yes! I saw it twice pretty quickly but then not again yet
<racarr> kgunn: I dont think its that but would have to dig deeper
<ricmm> kgunn: it doesnt inherit the environment from where you are restarting the job
<ricmm> kgunn: you'd need to add that to the unity8.conf job
<kgunn> ricmm: thanks for solving that mystery for me!
#ubuntu-mir 2013-09-04
 * robert_ancell -> lunch
<RAOF> robert_ancell: When you get back we need to discuss how to proceed with Operation: Worst Thing Ever (ie: sideband pipe between usc and Xmir)
<RAOF> duflu: You tracked down damage problems?
<duflu> RAOF: Kind of, not really. I need to devote more hours to better learning XMir
<duflu> kdub: You're back? Congratulations by the way
<smspillaz> racarr: long shot, but still around ?
<duflu> RAOF: ickle says he "pushed a patch" for the intel cache/lines issue with bypass. But I can't tell which commit(s) it was. Do you think... http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=47e718bf321f6fe80dc5f797f433b00bc8de91c7 ?
<robert_ancell> RAOF, yes. I was also wondering how far from working the focus thing is - that would at least reduce the pressure for a less hacky solution
<RAOF> duflu: It's all folded up into the single monolithic xmir commit, but yeah.
<RAOF> duflu: It's a bit ugly; we should either work out how to unuglify it - probably by telling the DDX when bypass is in effect, rather than having it guess it.
<duflu> RAOF: If you can get the bo flags then it's easy :/
<RAOF> The bo-flags are userspace only
<duflu> RAOF: Oh, actually that wouldn't help. Most large surfaces are now SCANOUT even when not bypassed
<duflu> RAOF: A surface attribute? Still ugly
<RAOF> A buffer attribute.
<RAOF> As it has to be :)
<RAOF> Because SCANOUT is already a possible pessimisation in the non-bypass case.
<RAOF> robert_ancell: Oh, the focus thing is mostly ok. It works for single-head; I just need to work out what I do wrong in the multihead case.
<duflu> RAOF: Sanity-check vladmir-upstreaming FTW?
<RAOF> duflu: Yes.
<RAOF> Although you'll want to pull the changes back to the ubuntu branch.
<RAOF> Because vladmir-upstreaming is based on master, which is an ABI bump ahead of us.
<duflu> RAOF: Argh. Maybe I'll just keep working with apt-get source on saucy to minimize impact on the system...
<RAOF> duflu: vladmir-upstream-base is the tag you want; it's easy to reproduce xmir.patch
<RAOF> duflu: git diff vladmir-upstream-base..vladmir-upstreaming > debian/patches/xmir.patch
<duflu> RAOF: When will that be upstreamed? Post 13.10?
<RAOF> Once it's broadly feature-complete.
<RAOF> I think glx-bypass is the final piece of that.
<duflu> RAOF: I can't see any guarantees about which portion of damage actually makes it to the swap_buffers. How can we be sure about the exact damage region that *really* got swapped?
<duflu> ... without waiting
<duflu> Oh, actually, maybe the answer is in the DDX...
<RAOF> What do you mean? The drivers are responsible for passing a correct region into submit_rendering.
<RAOF> And they're responsible for doing enough flushing that the fd submitted to Mir actually contains the rendering expected.
<duflu> RAOF: Yes! OK so the answer is the region parameter to the submit. Ta.
<RAOF> As a practical matter, the DDXen all pass the region that they get passed in.
 * duflu -> lunch
<RAOF> Ah, good. Now with significantly less password-leakage-across-VT-switch!
<RAOF> robert_ancell: So, the XMir side of focus-thing works. The Mir side (drop focus on VT switch) hasn't landed yet as far as I can tell.
<robert_ancell> RAOF, cool
<tvoss_> robert_ancell, ping
<tvoss_> robert_ancell, don't have broadband in the new house, yet
<robert_ancell> tvoss_, ok, so not coming to meeting?
<tvoss_> robert_ancell, trying, but don't know if it works, only 3G here :/
<robert_ancell> hikiko, duflu, racarr, kdub, meeting
<robert_ancell> duflu, should we close bug 1217262 invalid?
<ubot5> bug 1217262 in Unity System Compositor ""sudo restart lightdm" always hangs/fails when using unity-system-compositor" [Undecided,Incomplete] https://launchpad.net/bugs/1217262
<duflu> tvoss_: How did you go with Mir-native-OpenArena ?
<robert_ancell> duflu, you may have been hitting the problem where u-s-c was left running due to the way it was launched with a shell script
<duflu> robert_ancell: I think it might still be valid. We have something occasionally keeping DRM open and triggering bug 1206633
<ubot5> bug 1206633 in Mir "Mir/unity-system-compositor fails to start: Error opening DRM device" [Critical,Triaged] https://launchpad.net/bugs/1206633
<duflu> ... but it's racy. If you stop, pause, start, then it's OK
<mlankhorst> yeah of course it's racy..
<duflu> As mlankhorst keeps pointing out
<robert_ancell> duflu, then is it better covered by that specific bug? The bug you filed is a bit vague and likely to attract random me toos
<mlankhorst> unity-system-compositor needs to be completely dead before starting lightdm again :P
<duflu> mlankhorst: That should surely be solvable in upstart
<robert_ancell> mlankhorst, right, and lightdm does wait for that. But there was a bug where it was launched by a shell script without exec and lightdm was killing the shell script and not realizing u-s-c was still running
<mlankhorst> or we should start usc WAY early.. and make plymouth a client to usc..
<duflu> robert_ancell: Incomplete bugs should be left to expire naturally due to inactivity I say
<duflu> "Expire of natural causes"
<robert_ancell> duflu, well, you filed this bug... why not just close and re-open if you see it again?
<duflu> robert_ancell: I will retest for it now...
<duflu> robert_ancell: Reproduced. Now a duplicate of bug 1206633 :)
<ubot5> bug 1206633 in Mir "Mir/unity-system-compositor fails to start: Error opening DRM device" [Critical,Triaged] https://launchpad.net/bugs/1206633
<robert_ancell> duflu, awesome
<robert_ancell> duflu, is bug 1216245 still applicable? afaik the demo shells don't need any special code for multi-monitor
<ubot5> bug 1216245 in Mir "mir_demo_server_shell doesn't respond to hotplugging monitors" [Undecided,New] https://launchpad.net/bugs/1216245
<duflu> robert_ancell: Yes it's an issue and nice to have for testing. Just set Wishlist
<hikiko> duflu, are you working on the bug: #1216522?
<ubot5> bug 1216522 in XMir "XMir hung in xf86CrtcSetModeTransform()" [Critical,New] https://launchpad.net/bugs/1216522
<duflu> robert_ancell: I'm not sure having a completely broken display is only Medium... bug 1218815
<ubot5> bug 1218815 in xserver-xorg-video-ati (Ubuntu) "[radeon] Graphic glitches and screen corruption (vertical lines) on XMir surfaces only" [Medium,Triaged] https://launchpad.net/bugs/1218815
<robert_ancell> duflu, change it :)
<robert_ancell> I'm just doing a first cut for triaging, I'll re-look over high-med-critical and do them next
<hikiko> question: I startx to have a 2nd window manager apart from unity and the events (like double click on desktop) are send to unity (wrong vt?) is this a bug or something expected?
<duflu> hikiko: Yes, RAOF is working on that
<hikiko> plus programs like synergy dont work (but ok that's expected I guess)
<duflu> robert_ancell: The hang bug is incomplete. I haven't stress-tested MM recently to retry
<hikiko> duflu, and there's no way I use X without mir for the 2nd wm so that I can debug more easily the xmir? (eg attach a gdb etc)
<duflu> hikiko: I don't think you can right now due to the input focus problems. RAOF will have it fixed soon. Meanwhile you probably need a second machine
<hikiko> ouch :)
<RAOF> hikiko: Yeah, you can; but until https://bugs.launchpad.net/ubuntu/+source/unity-system-compositor/+bug/1192843 is fixed all keyboard input will always go to XMir.
<ubot5> Launchpad bug 1192843 in XMir "XMir receives input from other VTs" [Critical,In progress]
<duflu> Alternatively, go old-school and move your desktop to a text VT :/
<tvoss_> duflu, not sure what you mean?
<duflu> tvoss_: You were going to benchmark OpenArena with the Mir-native-SDL ?
<duflu> Or something
<hikiko> and could you guys suggest me a bug that is important to fix and none of you is working on it atm?
<duflu> hikiko: I think generally anything Critical in the mir or xmir projects
<hikiko> because most of our critical bugs are either GPU specific (need ATI for example) or assigned from what I see
<duflu> Hmm, maybe we should unassign those not in progress
<hikiko> kevin suggested one that is a test failure (but it's a bug that only appears some times) that ^ you said is incomplete
<hikiko> 3 others are ATI Specific
<duflu> hikiko: Bug 1206633 is a killer. And close to code you have seen recently...
<ubot5> bug 1206633 in Mir "Mir/unity-system-compositor fails to start: Error opening DRM device" [Critical,Triaged] https://launchpad.net/bugs/1206633
<hikiko> cool :D
<duflu> Though that might just be upstart scripting. I guess I should test
<hikiko> I'll pick this one then!!
<tvoss_> duflu, yup, got the numbers, need to post-process them
<duflu> hikiko: It might not be a bug. Maybe just our upstart scripts need better dependency rules
<hikiko> yes I saw your comment
<hikiko> I'll give it a try though
<duflu> hikiko: I also recall that exception wasn't clear which function it came from. Can also happen with errno==0. So maybe you should make the exception clearer first... and mention which function failed
<hikiko> yes, I did that when I was testing for the nested mir: it was permission denied not success
<hikiko> and my guess is
<duflu> hikiko: I mean, it would be good to propose a branch with better exception details first
<hikiko> that the problem is that we have that test (what interface version is used?) before we set the drm master
<hikiko> oh :)
<hikiko> true!
<hikiko> will do!
<hikiko> ok, cool!I'll start with this bug :D thank you duflu!
<hikiko> final question: for as long as I only have my laptop for development
<hikiko> is there any way to disable and enable xmir?
<hikiko> +if I start xserver without -mir and then I start my compiled version of xmir (the branch I work) will I get a crash?
<duflu> hikiko: Yes, comment out type=unity from /etc/lightdm/lightdm.conf.d/*
<hikiko> duflu, if I do so, and compile/start xmir I wont have any issues isnt it?
<hikiko> or I have to remember to enable it before I test?
<hikiko> (enable the system's xmir)
<robert_ancell> bye all
<duflu> hikiko: That only affects the default system logon. You can still run any server manually
<duflu> Bye robert_ancell
<hikiko> cool that was my guess :)
<hikiko> thanks duflu :)
<dholbach> good morning
<duflu> Morning dholbach
<dholbach> hi duflu
<duflu> RAOF: All root fragments share the same Drawable right?
<RAOF> Correct.
<RAOF> They're all associated with the root window, as seen by pScreen->root
<duflu> RAOF: Looks like we don't filter damage reports to check if they overlap the fragment in question. Any damage effectively damages all fragments
<RAOF> This is correct. *but* we take the intersection of the damage with the fragment's region before updating the damage regions.
<duflu> RAOF: Still, that explains why on the Mir side I was seeing all outputs redraw even when only one should... ?
<RAOF> No, I don't think so?
<duflu> OK, forget I said that. It's tangental
<RAOF> We *should* only be calling the driver's copyproc when xmir_window_is_dirty() returns true, which is iff RegionNotEmpty(xmir_window_get_dirty(xmir_win)) returns true.
<hikiko> duflu, still here?
<duflu> hikiko: Yes, but about to vanish for a brief while... ?
<hikiko> :)
<hikiko> I have a question but ok, I'll find out! good evening :)
<duflu> hikiko: I'll be back soon. What is the Q?
<hikiko> well, I wonder how and when xmir starts working with the xserver (because I remember that when I was implementing the mir display for X I had to do a trick to tell the xserver not to handle the drm device that mir is using and I want to see if this is necessary in xmir as well)
<hikiko> it might be related to the 1206633 bug
<hikiko> bug #120633
<ubot5> bug 120633 in telepathy-mission-control (Ubuntu) "Sync telepathy-mission-control 4.26-1 from debian unstable" [Wishlist,Fix released] https://launchpad.net/bugs/120633
<hikiko> sorry
<hikiko> bug #1206633
<ubot5> bug 1206633 in Mir "Mir/unity-system-compositor fails to start: Error opening DRM device" [Critical,In progress] https://launchpad.net/bugs/1206633
<duflu> hikiko: I don't think there would be any remaining races for DRM devices in the X server. Because it is single threaded. More likely other processes racing, like maybe plymouth has not finished deactivating yet
<hikiko> the only reason I suspect xserver is because I get the bug when I start a 2nd instance of lightdm which starts a second instance of xserver
<hikiko> when it's only lightdm and plymouth I dont get the freeze
<hikiko> but ok, I'll test a few other things first :)
<duflu> hikiko: Try adding a sleep and retry. That will give you an idea of whether the race just lasts a split second
<hikiko> I will :)
<duflu> RAOF: That's fun. Each frame XMir is looping through my *unused* outputs as well as used
<duflu> ... or something.... because I have 6 XMir wins to loop through
<duflu> Hmm, sometimes 8. This is quite strange
<davmor2> hey guys, I think I found an odd issue, if you hit the power button at any time in saucy the machine shutsdown with no prompts, this includes if the machine is in lock/sleep mode,  meaning someone could leave their machine and it sleeps and locks and someone else hit the power button, all their work is then lost
<tvoss_> davmor2, did you try it without Mir?
<tvoss_> davmor2, that is, without unity-system-compositor?
<davmor2> tvoss_: nope but I can
<duflu> davmor2: Yeah I thought it was a new feature. I like it. Has nothing to do with Mir though
<davmor2> duflu: I'd of said it was a critical regression it should switch off in locked mode it should just popup the user password dialogue box
<davmor2> shouldn't switch off even
<duflu> davmor2: I suggest you raise it in #ubuntu-desktop. It's really unrelated to this channel
<davmor2> duflu: will do thanks
<duflu> davmor2: Though it's not a security issue. Anyone with physical access to the power button always has the ability to kill a machine. There's no change there
<davmor2> tvoss_: so yeah happens with with mir removed too
<tvoss_> davmor2, then it's not a an xmir issue
<davmor2> duflu: indeed that is the case for a hard press but if someone though the machine was hibernating and taps the power button to wake it like they do on windows instant shutdown may not be the desired result :)
<duflu> I like it. I always hated having to click on a dialog after I've already pressed the power button.
<duflu> And it's better than Windows' annoying behaviour of always suspending, IMHO
<davmor2> duflu: I have no issue with it in an unlocked system, but if I lock my system I'd rather be forced to open the system and ensure there is nothing unsaved before my system shutsdown on me :)
<duflu> davmor2: Fair point. And Ubuntu design often makes contentious decisions. You should probably start by raising it in #ubuntu-desktop
<davmor2> duflu: I am now :)
<Mirv> I filed bug #1220652 now for my problem. the attachments may not be very useful since I'm running normal X again, but just in case someone would have an force-rebootable desktop at some point and could try to reproduce my problem
<ubot5> bug 1220652 in unity-system-compositor (Ubuntu) "Input devices gone in xmir after forcefully killing unity-system-compositor" [Undecided,New] https://launchpad.net/bugs/1220652
<Mirv> and input devices disappearing might be a bit weird anyhow, not shown in the normal logs.
<Mirv> oh, added the tidbit that writing in VT1 also has the text in VT7, but in lightdm itself I can't type or move mouse
<tvoss_> Mirv, what would be the expected behavior from your pov when forcefully killing usc?
<Mirv> tvoss_: to that matter, it restarting itself gracefully like unity does
<tvoss_> Mirv, that would be an upstart task, wouldn't it?
<Mirv> tvoss_: yes, I think
<tvoss_> Mirv, might be good to mention that in the bug report, too
<Mirv> added ", even after reboot" to the bug title to make it more clear that the killing is not the main issue
<Mirv> behavior in kill situation might be worth feature request in another bug, but that bug's intend is that I can't use xmir at the moment anymore, for some mysterious reason X
<Mirv> I'll file another bug for the request to gracefully restart itself
<Mirv> and that is bug #1220656
<ubot5> bug 1220656 in unity-system-compositor (Ubuntu) "Feature request: gracefully restart after being killed (or crashed)" [Undecided,New] https://launchpad.net/bugs/1220656
<tkamppeter> I have serious multi-screen problems with the XMIR as of saucy release (not -proposed) should I report a bug or are there already fixes in the queue for which I should wait?
<kgunn> tkamppeter: one minute while i dig
<kgunn> we've tagged multimonitor here https://bugs.launchpad.net/xmir/+bugs?field.tag=multimonitor
<kgunn> curious are you on intel? or ati/nvidia?
<tkamppeter> kgunn, I am on Intel, Lenovo Thinkpad Twist with Core i& with its built-in GPU.
<kgunn> tkamppeter: yeah, i'd skim thru the multimonitor tagged bugs...if you don't find a match/similar bug...please file
<tkamppeter> kgunn, it seems to be bug 1216472, workaround (1) of this bug solves the problem.
<ubot5> bug 1216472 in XMir "[xmir] [multimonitor] Frames eventually get slightly out of order, look like glitches or typing will feel slow" [Critical,In progress] https://launchpad.net/bugs/1216472
<kgunn> cool
<tkamppeter> kgunn, I have marked the "Me too" now and subscribed to the bug.
<hikiko> bye!
<kdub> we need a way to change the client-side connection configuration in integration/acceptance tests
<alan_g> kdub: which parts of the configuration can't you change?
<kdub> if we use mir_connect, we can't put in a stub client-side graphics platform
<kdub> was thinking of changing it a bit to use some test connection functions
<kdub> but its just nice that the client's exec() in our test framework just uses our public api
<alan_g> kdub: yes, we should have made the client API mockable
<kdub> alan_g, would you be opposed to having integration and acceptance tests connect with something like mtd::mir_connect()?
<kdub> (which allows us to put different client connection configurations in, depending on whether we want real graphics or not)
<alan_g> kdub: If I were not starting from here I'd add a level of indirection so that all the API calls could be intercepted by test doubles.
<kdub> with 'here' being 'lots of acceptance/integration tests already written' ?
<alan_g> "here" being introducing function pointers breaking the ABI
<kdub> ah, understood
<alan_g> kdub: I think the better way is for mir_connect() to call through a function pointer  that defaults to the current implementation, but can be replaced for a test.
<kdub> yeah
<kdub> or even, maybe put that function into mir_client_library_debug.h
<kdub> probably worth doing, two critical bugs about the tests have popped up related to this
<alan_g> kdub: "that function" being the existing implementation and the function pointer?
<kdub> well, i'm currently thinking the path of least resistance will be a mtf::test_client_connect() function that returns a MirConnection*
<kdub> as opposed to adding a mir_connect(<current args>, MirClientFnPtrStruct*)
<kdub> no touching the API, just a small inconvenience for tests
<alan_g> kdub: I was thinking of a global pointer variable, not an extra parameter
<alan_g> mir_connect() calls through (*mir_connect_impl)() which defaults to mir_connect_default_impl()
<kdub> and that global pointer can be overwritten via a debug function?
<kdub> rather, a function in mir_client_library_debug.h
<alan_g> Or just declare it in mir_client_library_debug.h and allow it to be assigned to
<kdub> yeah, i'll see which is nicer (i'll try to keep the struct containing the function pointers hidden)
<racarr> Morning...!
<racarr> Zzzz. im not sure its worth it for me to go to the late night weekly
<alan_g> Afternoon...!
<racarr> because I try but this ends up happening every week
<racarr> Hey alan_g ! How have you been?
<alan_g> ;)
<alan_g> racarr: I've been good.
<alan_g> How was your vacation?
<racarr> alan_g: It was great!
<racarr> Left a significant portion of my stress in the desert :)
<alan_g> Excellent. (Now let's see if we can fix that...)
<alan_g> racarr: kdub: I've left a couple of MPs for you to review.
<kdub> will look
 * alan_g sneaks off 3 minutes early to mother-in-law's birthday...
<kdub> fun gcc error: "The bug is not reproducible, so it is likely a hardware or OS problem."
<racarr> kdub: Lol beautiful
<ricmm> olli_: kgunn sorry guys chrome crashed
<robert_ancell> racarr, "Renamed toggle_dpms to toggle_dpms_between_on_and_off" - love it :)
<racarr> robert_ancell: :D I felt pretty happy about that too
<racarr> ricmm: Can you tell me more about the screen blanking stuff in upowerd and the small hack you mentioned? I think our DPMS support API is pretty ready to land, so if the mechanism is simple
<racarr> maybe I can just do the android impl...like right now!
<kgunn> rsalveti: ^
<rsalveti> cool
<kgunn> rsalveti: also...did i see you mention it was easy to crash (or freeze) mir on N4 today ?
<rsalveti> kgunn: yup
<rsalveti> just installed today's mir image, and could easily crash mir when opening the browse-app, getting back to the shell and then killing the app
<kgunn> rsalveti: any particular sequence? ( ive been testing regularly....but admit, i hadn't updated today)
<kgunn> eeewww
<rsalveti> let me reboot and give it another try
<kgunn> rsalveti: one more....what are "input_tests" ?
<kgunn> e.g. how to replicate what you see in terms of failed input handling
<rsalveti> oh, it's just that currently powerd is listening for the input events directly
<rsalveti> to support the power button
<rsalveti> that's not the desired way when mir is in place, but it was the way we did this with SF
<racarr> Howshould powerd get the power button
<racarr> without a window, it doesnt seem it should get it from mir
<rsalveti> what I tried to check is if we were able to get the input events via hal, which wasn't the case
<racarr> so it needs to communicate with unity somehow
<rsalveti> seems Mir was getting all the events somehow
<rsalveti> well, powerd is not the right one to handle the power button
<ricmm> racarr: not really, just exploring a simple interface via the HAL
<ricmm> racarr: I can take a look at it
<ricmm> the shell needs to implement policy, powerd execute it
<rsalveti> as we discussed during that previous call, we need someone that is already handling the input events to handle that power button
<ricmm> thats the decision we had made
<rsalveti> and communicate with the system to let it suspend/resume
<rsalveti> yeah
<ricmm> or in this case, the other way around... powerd executes the policy by asking the shell (Mir) to blank the screen
<ricmm> out via the android impl for DPMS, but all we really need is a screen on/off toggle
<ricmm> no more
<racarr> I don't understand where powerd helps us here, because
<ricmm> rsalveti: do you know if a basic HAL interface for this?
 * ricmm looks
<rsalveti> right, but powerd is not the one listening for the power input events
<racarr> the shell, needs to make the policy decision (no one else should see all the input events)
<rsalveti> at least it shouldn't be
<racarr> but, then if the shell uses powerd for the mechanism
<racarr> mir in turn needs to respond to the screen turning off (explicitly, or through error conditions I guess)
<ricmm> powerd will work the idle timeout
<racarr> i.e. stop the compositor, stop handing out buffers
<racarr> etc
<ricmm> the shell will work the power button and ask powerd if it should suspend
<racarr> so why not just have mir turn off the screen
<racarr> For powerd to work the idle timeout
<kgunn> racarr: i think they are saying the shell should own that policy
<racarr> how will that work? i.e. it sees the stream of all input events?
<racarr> Or does unity send it an event like "idle"
<kgunn> for making decisions about whether or not to actually blank the screeen
<rsalveti> who is handling all the input, mir, right?
<ricmm> want to jump in a hangout?
<racarr> Yes
<rsalveti> one thing ins handling the power button input
<ricmm> https://plus.google.com/hangouts/_/f4a766e9a7fc27ef894ab5ac8235856049fc75ab
<rsalveti> the other is the timeout
<racarr> kgunn: I am interpreting the opposite XD
<racarr> Thanks :) will give screen blanking a shot in 10-15 min
<robert_ancell> racarr, in src/server/shell/default_focus_mechanism.cpp, there is a reference held to the currently focussed surface that is never cleared until another surface has focus. Do you see any issues there if the surface is destroyed?
<racarr> robert_ancell: Yes. That's the second part of the stress test race
<racarr> robert_ancell: I tried to fix it with session-transactions but need to come up with another solution I guess
<robert_ancell> racarr, do you have a branch that fixes that specific part of the code? Because I'm modifying that code to support dropping focus on vt switch
<robert_ancell> ah
<racarr> I think it may be resolvable with a weak reference
<racarr> plus the appropriate logic when lock fails
<racarr> or the other idea I had was a different approach to session transactions hwere consumers of the surfacers in the shell store
<racarr> mf::SurfaceId and there is an api like
<racarr> session->with_surface_do(SurfaceId, [&](msh::Surface& surface) { stuff })
<racarr> I think it is the cause of some of the phone crashes gerry is seeing so I am taking it on after DPMS
<racarr> Screen blanking is blocking mir on phone though, so I am taking a minor diversion from GBM DPMS to hopefully quite quickly implement android screen blanking XD
<racarr> robert_ancell: the thing is the surface will still be destroyed or whatever but exceptions may throw when you try to use it because the underlying surface is gone
<robert_ancell> right
<racarr> there is another race in the same section of code
<racarr>     auto surface = focus_session->default_surface();
<robert_ancell> racarr, is there an easy way to detect that without just ignoring exceptions when accessing it?
<racarr> Then a few lines later:         surface->raise(surface_controller);
<racarr> but the underlying surface could be destroyed
<racarr> robert_ancell: Not really because without some sort of lock it can always happen inbetween
<racarr> your detection and operations
<racarr> so you need some way to do things atomically.
<racarr> I guess a weak_ptr is not enough.
<racarr> I like with_surface_do sort of. but im not sure it will land
<racarr> let me figure out why session-transactions was rejected I dont remember
<racarr> ok the recursive mutex.
<racarr> hmm
<racarr> the problem is, the idea is with_surface_do or do_transaction or whatever is that it holds a lock on the session that prevents destroy_surface, etc from running during the body of your function
<racarr> but then certainly the body of the function should be able to call these methods
<racarr> so you need a recursive mutex.
<racarr> robert_ancell: Ok I have an idea
<racarr> the focus mechanism needs to track the last surface, so it can unfocus it when a new surface takes focus
<racarr> so...um...
<racarr> another way to do that? XD not sure what the pattern is
<racarr> err, nvm I thought myself in a circle
<racarr> I was thinking about, passing out token objects to the surfaces
<racarr> that know how to generate unfocus events when they are destroyed
<racarr> but it doesnt seem to make sense
<racarr> Maybe the transaction API, but just don't use a recursive mutex
<racarr> and make it clear that calling session functions in the body of this is a deadlock
<racarr> with some API like
<racarr> session->do_with_surface_while_freezing_requests(mf::SurfaceId, std::function)...
<robert_ancell> racarr, but what do we do when the last surface is removed and then we try and access it afterwards?
<racarr> Mm
<racarr> Ok maybe remove the SurfaceId from the API and the session tracks
<racarr> its last focused surface (as the default_surface I guess)
<racarr> and there is API like
<racarr> session->with_default_surface_do
<racarr> std::function
<racarr> I need to run some errands. Back in ~1 hour
#ubuntu-mir 2013-09-05
 * robert_ancell -> lunch
<racarr> back
<racarr> traffic was destroyed by the bridge ><
<RAOF> Did the bridge transform in to a huge humanoid robot and crush cars underfoot?
<duflu> A dyslexic German deceptacon bridge?... "Die Autos"
 * duflu clearly needs more coffee
<duflu> Woo, I have an N4 again. Apparently the battery "was faulty" and eventually just stopped charging
<kgunn> racarr: curious...did the hwcomposer blank call work  ?
<racarr> kgunn: Havent tried yet needed to make an interface then got distracted by other things then went out for a bit
<racarr> will be trying very soon
 * RAOF lunches
<duflu> Ah, source control. Finally I can hack and run XMir within the safety of git
<robert_ancell> duflu, how?
<duflu> robert_ancell: Just build it the traditional way, and drop the resulting libxmir.so into my saucy filesystem
<duflu> Also, not having to re(de)build each time will be awesome
<duflu> robert_ancell: Hangout? Or something?
<robert_ancell> duflu, yep, in 5
<Mirv> hah, finally it makes sense, retitled bug #1220652
<ubot5> bug 1220652 in unity-system-compositor (Ubuntu) "Input devices unusable if booting with two monitors attached" [Undecided,New] https://launchpad.net/bugs/1220652
<Mirv> so it was just that I killed unity-system-compositor because I had just upgraded to the multi-monitor supporting mir last week, and I thought the problem was because of the forceful killing, and not because of the upgrade..
 * Mirv now back at using XMir
 * duflu -> lunch
<tvoss_> good morning :)
<alf_> tvoss_: good morning :)
<robert_ancell> bbl
<dholbach> good morning
<duflu> RAOF: This is driving me nuts... The frame misordering thing only happens on frames where we have decided that the damage doesn't touch all outputs. Skipping sna_xmir_copy_to_mir for any output on any frame causes the problem. I still don't know why...
<RAOF> duflu: That's... hm.
<RAOF> duflu: I wonder if we're clearing incorrect damage areas, then.
<duflu> Which leads me to another idea... hmm
<duflu> RAOF: It suggests that the intel DDX multibuffers for each output are not allowed to get out of sync... or that there is only one... ?
<mlankhorst> duflu: oh oh maybe because of EGL lifetime ? :P
<mlankhorst> they would get out of sync
<duflu> mlankhorst: There is no GL-anything here
<mlankhorst> buffer age
<duflu> mlankhorst: I have ripped out and removed all aging logic AFAIK. Still same problem
<mlankhorst> duflu: interesting, do you have a testcase?
<duflu> mlankhorst: bug 1216472
<ubot5> bug 1216472 in XMir "[xmir] [multimonitor] Frames eventually get slightly out of order, look like glitches or typing will feel slow" [Critical,In progress] https://launchpad.net/bugs/1216472
<RAOF> ...ooh! Semi-overlapping outputs might be broken like that, though...
<mlankhorst> RAOF: :P
<RAOF> But who has semi-overlapping outputs :P
<mlankhorst> <<
<RAOF> Just to be different, or for noble purpose?
<mlankhorst> for perfectionism
<mlankhorst> and it's the default case if you have multimonitor in ubuntu with different resolutions
<mlankhorst> RAOF: my simple testcase is attaching my 2 monitors, one is 1280x1024, other is 1440x900, they both have a big shared area only visible on 1 screen, and a small band that is only shown on 1 screen in the default setup. :P
<RAOF> I thought we should be actually cloning in that case.
<RAOF> But indeed, I think that's a bit broken.
<mlankhorst> RAOF: yeah, but with some xrandr forcing it can be changed :)
<tvoss_> RAOF, ping
<duflu> RAOF: Testing the bleeding edge git xf86-video-intel, I just get a black screen. Can you confirm?
<duflu> .. that's with XMir of course
 * duflu gives up
<alan_g> alf_: are you happy with the latest version of https://code.launchpad.net/~alan-griffiths/mir/init-native-gbm/+merge/183441?
<alf_> alan_g: yes, approved
<alan_g> alf_: thanks
<katie> tvoss_, mpt is there anythign we need to discuss today?
<mpt> I'm hungry
<mpt> But other than that, no
<tvoss_> mpt, katie nope, not from my side
<kgunn> alf_: welcome back
<alf_> kgunn: hi
<alf_> kgunn: thanks@
<alf_> kgunn: s/@/!/
<racarr> Morning
<alan_g> racarr: Afternoon
<alan_g> racarr: I was wondering if you'd have time to help me get the nested input stack wired up?
<racarr> alan_g: I think so
<racarr> alan_g: I am in a meeting right now, so want to sync on it after that?
<alan_g> racarr: sure
<racarr> alan_g: Ok will ping you :)
<racarr> alan_g: Hey meetinged+breakfasted
<racarr> want to explain nested input to me?
<kgunn> racarr: can i be a complete manager and ask...did blanking work via hwc after all ? (knowing this'll get hot tomorrow or monday)
<alan_g> racarr: The theory is really simple - we get input events from the host Mir (as seen in p:~alan-griffiths/mir/spike-nested-input)
<alan_g> But there's a whole load of setup needed in NestedInputConfiguration to hook it up
<alan_g> And I don't have a good grasp on all the roles there
<pete-woods> tvoss: hi! I have a dbus security problem I thought you might have ideas on. If you have any free time at some point to talk about it, it would be very much appreciated.
<racarr> kgunn: No XD sorry. I realized it was 7:30 pm last night and decided to stop working ill get to it before lunch today
<pete-woods> tvoss_: ^
<kgunn> racarr: np
<racarr> alan_g: Ok, starting to think out loud
<racarr> How much of the android input stack do we use in the nested mir? It seems like we need to reuuse a lot of our input infrastructure because for example the nested mir might be using a different keymapping, or have different pointer acceleration configuration
<racarr> or such
<racarr> so its not enough to just modify and forward the events.
<alan_g> racarr: Hmm
<racarr> so I think instead, we should extract the raw events out of the events (By raw I event I specifically mean, android::RawEvent that EventHub deals with)
<racarr> then we use a pretty normal input stack in the nested mir, but don't probe devices, and instead inject events from the host mir in to the nested event hub
<alan_g> racarr: that's more complex than my initial thoughts (but more correct)
 * alan_g wonders how to disentangle the bits we want to reuse from the spaghetti
<racarr> alan_g: There is a series of issues with it too though in that
<racarr> the eventhub needs to be told about input device added, removed, etc, which we don't send over IPC now
<racarr> that can be quickly worked around by using the built in cursor/mouse but has to be fixed quickly
<racarr> alan_g: Perhaps even, the nested mir implements
<racarr> the EventHub
<racarr> eh its hard to do without inheritance of implementation
<racarr> EventHub has two roles biw (calling it only two is generous...). One is to read the raw events from the kernel and track device info in the case of device appearing/dissapearing.
<racarr> the second part, is stateful on top of that, i.e...is scan code 7 pressed
<alan_g> I saw an "and" in that. Don't be sneaky!
<racarr> Yes I thought of splitting it in to three there XD
<racarr> it probably is, but for the purpose of this idea
<racarr> if those first two responsibilities were held in one interface, and the second moved to a common implementation
<racarr> the first interface is good for nested mir to replace
<racarr> alan_g: I think this is likely too involved to finish within the week, but perhaps not. I have an easier idea though
<alan_g> the refactoring? I guess there are inadequate tests around here?
<racarr> nested mir, uses null impls/disabled objects/whatever for everything below the InputDispatcher (i.e. the EventHub and InputReader)
<alan_g> ack
<racarr> and injects the events with InputDispatcher::injectEvent
<racarr> this expects droidinput::InputEvent which lines up to MirEvent
<racarr> it wont work properly with device configuration, etc
<racarr> but it can get things going
<racarr> and yeah, inadequate tests around the pure android code...also just the interfaces are difficult.
<racarr> There are like 30-40 member methods of EventHub
<alan_g> racarr: I can remember that from when I hacked out stuff we didn't need
<alan_g> It also doesn't sound like much wasted work. The reconfig work could fit in if the MirEvent -> InputEvent "mapping" took place in the stubbed EventHub
<racarr> No. Not wasted work.
<racarr> Not sure I understand that last bit though
<alan_g> Maybe I'm not making sense
<racarr> (also, I guess you mean RawEvent?)
<alan_g> "InputDispatcher::injectEvent expects droidinput::InputEvent which lines up to MirEvent"
<racarr> Oh! ok I see, inject in to the InputDspatcher from the stubbed event hub
<racarr> like you said :p
<racarr> I replaced stubbed with reimplemented in my mind
<alan_g> racarr: it will then grow from a little stub to handle device configuration, etc
<racarr> yeah.
<alan_g> And we have a stable intermediate form that might work
<racarr> perhaps though instead of using InputDispatcher::injectEvent
<racarr> well maybe we should be stubbing out and doing this in the InputReader
 * alan_g wishes he understood the roles of these classes
<racarr> or, not have an input reader, and use the InputListenerInterface from the INputDispatcher as the reader does
<racarr> where you have like, notifyConfigurationChanged, notifyKey, notifyMotion, notifySwitch, notifyDeviceReset
<racarr> basically, I am thinking, stub out the input reader, ignore the event hub (don't need it if we aren't constructing the real input reader)
<alan_g> That sounds like we don't need a hub
<racarr> yep no hub
<alan_g> duh, you jsut said it
<racarr> then just make some object like uh
<racarr> NestedInputReaderWithABetterNameThanInputReader
<racarr> that takes the InputListenerInterface (implemented by dispatcher)
<alan_g> NestedInputRelay
<racarr> receives events and calls notifyKey, Motion, etc
<racarr> yes relay is good
<racarr> alan_g: If you look in fake_event_hub.cpp there is some stuff about synthesize_builtin_keyboard_added and synthesize_builtin_cursor_added
<racarr> To get started, I think we will have to replicate that at the notifyConfigurationChanged level
<racarr> and then force all device ids to builtin keyboard or cursor in the relay
<racarr> then we have to start sending input configuration info over the wire
<racarr> before we can get any further
<alan_g> But we should be able to route some input without the config messages as a POC.
<racarr> yes by
<racarr> forcing them all on to synthetic devices
<racarr> but if we just route them straight away I think the InputDispatcher will be like
<racarr> device Id 7? You just made that up, stop it.
 * alan_g hates code that knows too much
<racarr> that might not be true the input reader will definitely choke
<racarr> the InputDispatcher might not.
<racarr> a quick grep through for "Device" in InputDispatcher is more promising than I expected
<racarr> it may just be happy to pass it through
 * alan_g hears demands for tea
<alan_g> I think I have some ideas to work with
<alan_g> BRB
<racarr> Ok
<hikiko> hey :) I am alone at the hangout
<racarr> hikiko: Oh! I forgot I was awake
<racarr> :p
<racarr> whats the sane way to stop unity8-mir on the phone now so I can run mir
<racarr> without it restarting itself :p
<racarr> just compiling a build now where I expect screen blanking to work
<racarr> kgunn: ok it basically works I think but I need to stop the compositor from continuing to try and post to the fb (or make that blocking or something)
<kgunn> racarr: cool...that makes sense
<kgunn> in fact the DSS has probably cut the clocks...and might get pissed if you try to send data
<kgunn> see dss2 kernel code
<racarr> oi
<racarr> ok lunch!
<bschaefer> kgunn, thanks for that email! Ill poke one of them when ever I get a chance to look back at this radeon problem...
<kgunn> you bet...thanks bschaefer !
<bschaefer> kgunn, did all that packaging stuff get sorted with the xserver radeon stuff?
<greyback> racarr: "stop unity8"
<greyback> just shout out. nice and loud. It'll get the hint.
<greyback> :D
<olli_> this is probably old news for you guys
<olli_> but AWESOME!
<olli_> http://www.phoronix.com/scan.php?page=news_item&px=MTQ1MzU
<racarr> greyback: Aha thanks.
<racarr> greyback: mv /usr/bin/unity8.lol /usr/bin/unity8
<racarr> I ended up using the insane way
<greyback> racarr: insane, but works :)
<tvoss_> bschaefer, ping
<bschaefer> tvoss_, pong
<racarr> Whee
<racarr> screen blanking works on nexus 4 :)
<tvoss_> racarr, \o/
<racarr> ok I am going to be late for the dentist brb
<kdub> racarr, yay
<racarr> kdub: There are some complications about pausing things
<kdub> yeah, although
<racarr> noticeably the most naieve method doesnt work because then you can stall the client that wants to unblank the screen
<kdub> we do that already, don't we?
<racarr> in buffer hand out
<racarr> and it will never be able
<racarr> to send the message to unblank the screen
<racarr> well it will send it but the server side machinery will be locked up (we do one message at a time)
<racarr> so there is a bit of a dance to do
<racarr> ill tell you about it when I get back XD
<kdub> are clients able to request a blank? o.O i thought the shell would be the one that would do that
<kdub> anyways, have fun at the dentist :P
<racarr> xmir needs to
<racarr> as usual XD
<kgunn> robotfuel: so is the latest radeon build still an issue ? (stripes?)
<kgunn> and if so, is it stripes only on xmir and not X
<robotfuel> kgunn: yes on the latest xmir in main
<robotfuel> kgunn: I'll double check x
<robotfuel> kgunn: I just kicked off a test run on, we will know in 7 minutes
<kgunn> robert_ancell: something to watch ^
<robert_ancell> yep
<robotfuel> robert_ancell: are there any changes in xmir in proposed that you know about? (should I test proposed today?)
<robert_ancell> robotfuel, not that I know of specifically, will have to ask RAOF
<robert_ancell> robotfuel, which pacakge? xorg-server doesn't seem to be in proposed
<robotfuel> robert_ancell: I didn't know if there were any packages
<robert_ancell> robotfuel, ok, there don't seem to be any xmir changes
<robert_ancell> racarr, hey
<racarr> robert_ancell: Hey
<robert_ancell> racarr, I thought our meeting was an hour later - free now?
<racarr> robert_ancell: Can we delay 1 hour? or at least 30 min or so
<robert_ancell> sure
<racarr> face is too numb to talk right now really
<robert_ancell> more dental work!!
<racarr> Yes. It's not actually that much its just the root canal took 4 visits
<racarr> I got 1 half cleaned, then a root canal, then now I just finally got the other half cleaned
<racarr> it was inclusive of inside of the gums though, and kind of involved an intense about of local anaesthetic XD
<rsalveti> racarr: have the blank/unblank patch in hands so we can test with maguro as well?
<robotfuel> kgunn: regular x does not have black bars
<kdub> rsalveti, from what I've heard, i think its a pretty preliminary patch at the moment
<robert_ancell> RAOF, can you have a look at https://code.launchpad.net/~robert-ancell/unity-system-compositor/reboot-on-install/+merge/184204 when you are here
<robert_ancell> out with an errand for ~1hr
<rsalveti> kdub: yeah, but just wanted to know if it'd work with the hwcomposer used with maguro
<rsalveti> guess I'll have to wait :-)
<kdub> it should
<racarr> rsalveti: There is a not yet proposable (build will fail on tests :p) branch you can try out
<racarr> but its pretty preliminary :p
<racarr> lp:~robertcarr/mir/test-android-screen-blanking
<racarr> you can run mir-demo-server-shell then mir-demo-client-display-config
<racarr> and press any hardware key to toggle the screen on and off
<racarr> poatch should be finished soon
<racarr> Had to run out for the afternoon
<rsalveti> cool
<kgunn> RAOF: ^ robotfuel's comment on radeon xmir has black stripes and regular x doesn't....wasn't sure if you were aware
<RAOF> kgunn: Yeah, I sees it.
<RAOF> Not the bug, just the comment â¹
<robert_ancell> thomi, hey, do we have coverity and CI integration?
<racarr> Ok so the hardware part of DPMS android is working and It hink I can clear it up pretty quickly. I think also the IPC issue I found was my real issue with GBM
<racarr> essentially, imagine a dumb client like demo-client-display-config
<racarr> which turns off the display then tries to advance its buffer
<racarr> which blocks on the server side waiting for the display to turn back on (hey the display is off! Stop swapping buffers)
<racarr> but because we process messages in-order
<robert_ancell> racarr, anesthetic worn off?
<racarr> you can't send a message ot turn the screen back on
<racarr> robert_ancell: Yes!
<TheDrums> I'd assume http://paste.progval.net/show/530/ hasn't been fixed?  Last tested in 0.0.6, though.
<kdub> what device?
<TheDrums> Pad says intel 82845G/GL[Brookdale-G]/GE
<kdub> TheDrums, not sure if it would work now... intel cards should work though
<TheDrums> It was a different error than they were used to, because it didn't handle alpha.
#ubuntu-mir 2013-09-06
<racarr> One option is that advance_buffer becomes an error instead of blocking while display is off
<racarr> but this is really just shoving the problem to the client
<kdub> racarr, we say that the advance buffer could block
<kdub> so if the client wants to blank/unblank then, it seems the client is the only one that can sort that out
<racarr> kdub: Yes. its generally ok, but here is the specific problem
<racarr> its the blocking on the server side,
<racarr> i.e. you call, display off, then call advance buffer
<racarr> your server side socket session is blocked there
<racarr> so you can never turn display back on
<racarr> because all messages are processed in order
<racarr> one solution would be to seperate messages in to channels, and read them as fast as we can and ensure messages are executed in order per channel
<racarr> i.e. the surface channel, and so you can't execute a resize message while you are executing a swap buffers message
<racarr> but the display channel, you can turn off the display while your surface is being resized
<kdub> seems complicated
<racarr> that's kind of invasive though
<racarr> yeah
<kdub> why not just have an error be returned
<kdub> if the client tries to swapbuffers while they've paused?
<kdub> well, actually, i take that back
<racarr> thats what I was saying, is one option
<racarr> but ideally I think, swap buffers really would just block
<racarr> but assuming you are doing it asynchronously you should be able to go on to do
<racarr> other things like reconfigure the displays
<robert_ancell> RAOF, hey, been thinking we can abuse the application lifecycle API for XMir input dropping instead of focus - it will probably work better. racarr confirmed the API is there (mir_connection_set_lifecycle_event_callback)
<robert_ancell> RAOF, since it's per connection it should be more clear than focus
<racarr> kdub: toyds would never have this problem
<kdub> i was just thinking about toyds yesterday
<racarr> :D
<robert_ancell> thomi, also, is Jenkins locked up? https://code.launchpad.net/~robert-ancell/lightdm/coverity-fixes/+merge/184043
<racarr> maybe the different message channels aren't that hard
<racarr> instead of waiting for the session mediator to process messages before starting the next async read
<racarr> you read them as fast as you can
<racarr> then the session mediator has locks i.e.
<racarr> surface_channel_mutex, display_channel_mutex
<racarr> to ensure you only process one message from each channel
<racarr> except it doesnt work because how do you know that in between reading a message from the socket and invoking the session mediator that your thread wont yield to another thread which will process a message ahead of you that should have been behind
<RAOF> robert_ancell: Oooh, yes!
<robert_ancell> RAOF, at the moment it doesn't handshake, but I suspect that will have to come at some time
<RAOF> We might as well get the handshake in sooner rather than later.
<duflu> RAOF: Can you please sanity check these comments?... https://bugs.freedesktop.org/show_bug.cgi?id=68969
<ubot5> Freedesktop bug 68969 in Driver/intel "xf86-video-intel 2.99.901 + XMir + multimonitors = all displays black" [Normal,Resolved: notourbug]
<RAOF> duflu: Hm.
<duflu> robert_ancell: I just noticed why so many bug reports lack logs...
<duflu> UnitySystemCompositorLog: Error: [Errno 13] Permission denied: '/var/log/lightdm/unity-system-compositor.log'
<duflu> LightDMLog: Error: [Errno 13] Permission denied: '/var/log/lightdm/lightdm.log'
<robert_ancell> duflu, huh, I thought apport collected them as root
<robert_ancell> duflu, do you have an example bug report with that error?
<duflu> robert_ancell: https://bugs.launchpad.net/bugs/1215053
<ubot5> Launchpad bug 1208250 in Mir "duplicate for #1215053 Graphic corruption on Intel Mobile Corp Mobile 4 chipsets" [Critical,Incomplete]
<robert_ancell> duflu, https://code.launchpad.net/~robert-ancell/unity-system-compositor/apport-root-files/+merge/184224
<tvoss_> good morning :)
<alf_> RAOF: I have been trying to add eglCreateImageKHR support for gbm_bo to platform_mir, but I get some erratic behavior with this failing either during image creation or rendering in intel_do_flush_locked. It seems there may be some race/timing related issue going on... any ideas or known caveats about CreateImage implementations?
<RAOF> alf_: Sorry, I've got no ideas.
<alf_> RAOF: np, thanks
<RAOF> Although most drivers are not themselves threaded, so if gbm_bo import happens on a Mir callback that might be wrong.
<duflu> RAOF: Some trivial patches for you: https://bugs.launchpad.net/xmir/+patches
<RAOF> Ta.
<duflu> I wish, less trivial fixes :{
<RAOF> ...oh.
<RAOF> Is *that* it?
<RAOF> Hm, no, that *shouldn't be itâ¦
<RAOF> Oh, yes it is.
<RAOF> duflu: We really need to tell clients when they're bypassed.
<duflu> RAOF: That's quite counter-intuitive for me, but yeah, sure.
<duflu> RAOF: More reasons why? Other than intel DDX internal reasons?
<RAOF> Radeon DDX internal reasons, too.
<duflu> Joy
<RAOF> I'm pretty sure that's why radeon is corrupting with bypass (for some people)
<RAOF> And the (for some people) is really (for some resolutions), because scanout buffers are aligned differently.
<mlankhorst> ;p
<mlankhorst> <<<
<duflu> RAOF: In that case we need to flag scanout buffers, and not necessarily when they're also bypassed
<RAOF> mlankhorst: nvidia always seems to have the most forgiving hardware, but does nouveau lay out scanout buffers subtly differently in ways the kernel doesn't necessarily expose?
<RAOF> duflu: Yes
<mlankhorst> erm not at all, just needs to be allocated contiguously
<mlankhorst> but I've even added kernel checks for that recently
<duflu> RAOF: Can you please make sure the bug carries the conversation?... bug 1218815
<ubot5> bug 1218815 in xserver-xorg-video-ati (Ubuntu) "[radeon] Graphic glitches and screen corruption (vertical lines) on XMir surfaces only" [Critical,Triaged] https://launchpad.net/bugs/1218815
<mlankhorst> failing to allocate contiguously will only result in some very obvious scanout corruption though ;P
<duflu> RAOF: Umm, actually, no. We don't need a scanout flag. We just need to report stride/pitch/whatever *accurately* :)
<mlankhorst> duflu: but you can abuse the fact that if you know the dimensions, radeon calculates everything in libdrm so you will get the same answer
<duflu> Argh, intel why can't you treat NullRegion as empty? :P
<RAOF> mlankhorst: Actually, you won't; the RADEON_SURF_SCANOUT flag looks like it'll change the surface layout.
<RAOF> mlankhorst: Although in ways that I've not fully traced.
<alf_> mlankhorst: I have been trying to add eglCreateImageKHR support for gbm_bo to platform_mir, but I get some erratic behavior with this failing either during image creation or rendering in intel_do_flush_locked. It seems there may be some race/timing related issue going on... any ideas or known caveats about CreateImage implementations? It seems like the gem object created by gbm somehow gets lost and can't be found (e.g. I sometimes get ENOENT e
<alf_> mlankhorst: could this be related to how gbm creates the gem object, loading the dri driver on its own?
<mlankhorst> alf_: you might want to try against drm-next kernel, it has a bunch of fixes, and your wall of text got truncated at ENOENT
<alf_> mlankhorst: ...ENOENT errors from IOCTL_DRM_GEM_FLINK, or later when trying to render)
<alf_> mlankhorst: is there an easy way (e.g. a package) to get the kernel?
<mlankhorst> we have a bunch of pre-built ones
<mlankhorst> tjaalton: ^
<RAOF> In the kernel "PPA", right?
<mlankhorst> no idea, i only know we do :P
<RAOF> alf_: http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-next/
<alf_> RAOF: great, thanks!
 * RAOF really needs to fix it so that we don't flink buffers for no good reason
<tjaalton> yes, mainline builds rock
<tjaalton> what doesn't is the amount of work needed to get fixes backported
<dholbach> good morning
<alf_> RAOF: well, the flink I am referring to is just part of an experiment to figure out why gbm object get lost, do we still have flinks elsewhere?
<RAOF> alf_: I think we might do, yes.
<duflu> RAOF: What is this exactly?... xmir->driver->BufferAvailableForWindow
<RAOF> duflu: A callback we call when swap_buffers has returned, so there's a new buffer available.
<duflu> RAOF: Yeah I figured that out. But am confused because it means we only schedule new redraws if one happened recently. How do you go from idle to redraw then?
<RAOF> duflu: Due to my mismemory of the X main loop, it's kinda superfluous, because we only get our events processed when going idle anyway, and the DDX calls xmir_for_each_dirty_window()
<duflu> Cool.
<RAOF> duflu: Ah; the BlockHandler gets called before the X main loop goes into select()
<duflu> ???
<duflu> What _is_ the BlockHandler? Looks important :)
<RAOF> It's the server's âI'm about to go into select(), anything you need to do before I block for an indeterminate period?â
<RAOF> callback.
<RAOF> (One of the things you can do is tell it not to block for an indeterminate period âº)
<duflu> RAOF: Right. So that could go deep sleep and not be woken till damage arrives?
 * duflu checks the intel code again
<RAOF> Nothing in the X server does anything between the block handlers being called and select() returning because some external event has happened.
<RAOF> Whereupon the X server will call any of the WakeUpHandlers associated with fds that select says have had something interesting happen to them.
<RAOF> Then X will handle any client requests on its socket.
<RAOF> Then X will call the BlockHandlers again, then X will sleep in select() untilâ¦
<duflu> RAOF: X is all very clever with its single threaded design, but not always intuitive. I usually end up appreciating the approach... eventually
<RAOF> duflu: It's not totally dissimilar to glib's main loop handling, either.
<RAOF> But much, much less visible.
<duflu> RAOF: OK, so do we really still need and want all of sna_accel_block_handler when XMir is running? I'm not convinced it's additional, but likely should replace some of that
<RAOF> I don't think we need all of it, but I don't think it does anything that will actually *break* anything.
<RAOF> Some of what it does would appear to be mandatory, like actually submitting rendering commands for everything but the XMirâMir copy.
<duflu> I thought we did that in XMir.
 * duflu hacks the DDX to be convinced
<duflu> If only the upstream branch *worked* I would be working with that.
<RAOF> Time for me to see why it doesn't.
<duflu> RAOF: It works if you have only one output...
<RAOF> Then it's time to see what xmir_resize does that ickle hates!
<duflu> RAOF: FYI, commenting out sna_accel_block_handler, XMir still works :)
<RAOF> Colour me surprised.
<duflu> RAOF: So unless there's something important there, maybe we should try to skip as much as possible?
<RAOF> It looks to me like there's important stuff there.
 * RAOF wonders where else calls kgem_retire and _kgem_submit.
<duflu> RAOF: The submit is in +sna_xmir_copy_to_mir
<RAOF> No, that's kgem_submit_bo, which is different.
<RAOF> ... no it isn't?
<RAOF> Ah. _kgem_submit vs kgem_submit. Of course!
<RAOF> duflu: I suspect that you'll find that XMir will eventually fail to work when you comment out sna_accel_block_handler
<duflu> RAOF: Fair point
<Mirv> I just experienced what apport tracked to bug #1220073 after 4h usage. it resulted in Xmir seemingly non-functional but VT1 functional
<ubot5> bug 1220073 in xserver-xorg-video-intel (Ubuntu) "[snb mesa] GPU lockup IPEHR: 0x79050005 IPEHR: 0x0b140001" [Undecided,Confirmed] https://launchpad.net/bugs/1220073
<duflu> Mirv: Well, the maintainer clearly knows about the bug already. Not sure what you can do
<duflu> Mirv: BTW, when logging bugs, please remember to set a task for the Mir project. Most of the team doesn't monitor the Ubuntu tasks
<Mirv> duflu: yeah I noted that you want those in the upstream project
<Mirv> let's see if that gpu hang happens again, it's been a bit of time since the last one
<Mirv> generally it's nice now, the only real workaround I currently need is to boot without the external monitor attached
<MKCoin> Will editing the keyboard be substantially different in Mir, or will it be similar to/the same as Xmodmap?
<duflu> MKCoin: It's pure X, unchanged. X is still handling all input even under XMir for now
<duflu> alf_: Have you worked with xf86-video-intel before?
<MKCoin> I see, thanks.
<MKCoin> First thing after I do after an install is customize my keyboard, glad to know that will be unchanged :D
<kgunn> alf_: got your feet on the ground again yet ?
<alf_> kgunn: I actually have my feet deep in the mud... trying to implement eglCreateImageKHR for EGL platform mir (needed by nested mir), but I am getting strange issues
<kgunn> alf_: mmm....like ?....i vaguely remember some weirdness around the gl binding call to the egl surface
<kgunn> alf_: gotta branch ?
<alf_> kgunn: it's a combo of the platform_mir eglCreateImageKHR implementation in mesa, and a hacked version of Alan's nested-mir spike. I will push my versions, along with an explanatory email later today.
<kgunn> alf_: cool...
<pete-woods> ssweeny: hi, sorry for the delayed response
<pete-woods> whoops, wrong channel
<tehrain> in case anyone didn't know, the latest daily build is a real bitch to install on VMware due to graphical corruption
<xtriz> from the next release ubuntu will start shipping with Mir, so will that create probs with some applications ?
<tehrain> it's creating huge problems for me right now
<xtriz> that's sad to hear :(
<tehrain> and this is with just the stock software
<xtriz> Mir would be default with the next release ?
<tehrain> yes
<tehrain> it doesn't seem to like changing screen resolution
<tehrain> the installation is also really fucked up on VMware at least
<tehrain> I had to alt+drag the window
<xtriz> i tried but i terribly failed too.
<xtriz> on the next release can't we use the  xorg server instead of Mir ?
<tehrain> nope
<tehrain> not unless you install binary nvidia or amd drivers
<tehrain> and in 14.04 there will be no option to use X
<tehrain> of course, you could also go upstream and use debian instead... ;p
<xtriz> then most of the applications also must not work properly on it correct ?
<tehrain> at this point they're running inside of an X server that runs on top of Mir
<tehrain> so most applications should work similarly
<xtriz> tehrain, and what about xfce and other DE will they work ? because i am using xfce side by side with unity.
<tehrain> I haven't tried, but in theory it should work
<tehrain> but expect serious problems
<xtriz> is their any special advantage of using Mir ?
<tehrain> not really ;p
<xtriz> yeah i suspect that , there must be a whole lot of probs :(
<xtriz> than why are they taking up Mir...!! :P bad decision .
<tehrain> obviously they smoke some really good weed
<tehrain> I mean.. at least wait until the software is ready to make it default!
<tehrain> I have to support this professionally
<xtriz> support ?
<tehrain> we use Ubuntu at this company
<xtriz> like it's difficult for all the open source software to make Mir compatible.
<xtriz> ok :)
<tehrain> yeah, and as an open source developer I'm not going to jump through hoops to make stuff work for a single distro
<xtriz> correct :D
<tehrain> it should be up to the Ubuntu devs to make Mir work with the existing software and adhere to existing standards, imo
<xtriz> absolutely otherwise all will leave ubuntu ...
<tehrain> on my VM I'm seeing stars right now ;p
<tehrain> they change color if anything else on the screen moves
<xtriz> tehrain, what should i do if i don't want mir to be default on my system from the next release ?
<tehrain> if you have an nvidia or amd graphics card, install the proprietary drivers
<tehrain> then you'll go back to using straight X
<xtriz> that's that simple ?
<xtriz> nothing else i need to do ?
<xtriz> \as mir will introduced that other DE like cinnamon and xfce will not work right ?
<kdub> xmir supports other x-based environments
<xtriz> kdub, that's great if it supports and everything works well.
<xtriz> xmir is a compatible layer right ?
<kdub> no
<xtriz> ok
<xtriz> where i can learn more about mir ?
<kdub> its the xserver that the desktop environment uses
<xtriz> kdub, is their any special advantage of using mir ?
<kdub> xtriz, sure!
<xtriz> like what are they ? i am getting more interested in Mir now...after reading couple of articles.
<kdub> xtriz, for one, you can have smooth transitions between opengl clients
<xtriz> but can't get exact benefits of using Mir.
<xtriz> kdub, ok
<xtriz> kdub, are you a mir developer ?
<kdub> xtriz, another one is that the state of the desktop is centralized and can be better tracked
<kdub> yep
<xtriz> great :)
<kdub> xtriz, so for instance, if we want to have a client, and map it to a sphere shape, and have the clicks follow the client's mapping to the sphere, we could do something like that
<kdub> there's no plans to do that at the moment :) but thats the sort of flexibility we're shooting for
<xtriz> that's interesting.. so this sounds something more better.
<xtriz> kdub, for example i am using any open source application will that work fine ? or they have to be made compatible to work with Mir.
<xtriz> kdub, if i want to get involve into Mir from where should i start.
<kdub> most applications that rely on qt or gtk won't notice a difference
<kdub> because we just rewrite some of the backend for qt/gtk/etc and the applications won't have to change
<xtriz> ok
<kdub> xtriz, if you want to help out, that would be great! a good start is to just get it running
<xtriz> ok , so downloading the beta build of 13.10
<kdub> xtriz, how are you interested in helping? really, once you get it going, the 'most fun' would just be to play with our example programs probably
<tehrain> kdub, are you aware of any issues with Mir specific to VMware?
<xtriz> ok :)
<xtriz> i would help to fix some bugs or recompile app with GTK / QT necessary flag support.
<kdub> tehrain, no, unaware... we could note in a bug report I suppose
<kdub> tehrain, might get better results if you use software rendering in vmware
<tehrain> the largest issue I've seen is during the installation phase of the latest daily Ubuntu snapshots, where a black/grey menubar repeats itself for half of the screen
<tehrain> that might be VMware specific though, not sure if it happens on other video drivers
<tehrain> and if you change resolution, there is a lot of graphical corruption
<tehrain> and I am using software rendering
<bschaefer> tehrain, I got that the other day...its not a VM problem
<xtriz> right now i am using cinnamon 1.8 so after the upgrade to 13.10 i can successfully use it ?
<xtriz> or some changes are necessary to be made ?
<xtriz> like compiling packages with mir support ?
<tehrain> only the toolkit needs to have support for Mir I believe
<xtriz> ok
<xtriz> all the packages would need to recompiled to support mir correct ? if this happens then those distro which depends on ubuntu will be in prob ?
<xtriz> am i correct ?
<xtriz> any expert opinion
<kdub>   no, just the toolkit packages
<xtriz> kdub, can i pm you ?
<xtriz> would all the packages made in ubuntu will be compatible to those distro which do not support mir ? or they will package stuff specifically optimized for mir ?
<kdub> xtriz, a gui application linked to a toolkit will need no repackaging
<xtriz> kdub, ok :)
<kdub> xtriz, really, the goal is so most people don't have to worry about it
<xtriz> kdub, thats great
<xtriz> if everything integrates well with Mir then Mir will be really successfully across the board.
<racarr> cd
<racarr> ok I think I decided how to do the focus refactoring to get rid of the race
<racarr> DefaultFocusMechanism::set_focus_to changes its argument from session->surface
<racarr> and rather than like, session manager calls focus_mechanism->set_focus_to(session)
<racarr> then the focus_mechanism queries the default_surface
<racarr> instead, the session manager calls like
<racarr> session->take_focus(focus_mechanism)
<racarr> and the session gets its own default surface while holding its internal lock
<kdub> whats the race?
<racarr> kdub: You call session->default_surface and get std::shared_ptr<msh::Surface>, and or you were holding std::weak_ptr<msh::Surface> to the last focused surface and just locked it (so you can send it unfocused)
<racarr> but then you yield, the surface is destroyed from another thread (say the client disconnects)
<racarr> and you call surface->anything throwing an exception
<racarr> because you aren't actually keeping the underlying surface alive
<racarr> of course, everything could be modified to handle the exceptions properly but that seems dangerously like using exceptions for synchronization XD
<racarr> It's what session-transactions was aimed to fix but that required a recursive mutex.
<racarr> perhaps even just msh::Session should be std::lockable
<racarr> eh
<racarr> needs a recurisve mutex
<racarr> or a verbose API
<racarr> bler myt focus mechanism inverting solution makes it difficult to deliver unfocused notifications
<racarr> its possible to make it like DefaultFocusMechanism::set_focus_to(std::shared_ptr<shell::Surface> const& new_Focus, std::function<void()> callback_to_be_invoked_when_surface_is_unfocused_that_has_reponsibility_for_delivering_the_unfocus_configure_event)
<racarr> but you still need a recursive mutex because the lambda comes from the session and needs to lock the surfaces, but set_focus_to is called by the session as well
<racarr> its recursive all the way down
<racarr> A whole new tree of ideas!
<racarr> maybe the session doesnt call surface->destroy and just relys on the ~msh::Surface to do that so then
<racarr> keeping around a shared_ptr to a surface becomes safe
<racarr> this may be a useful property in general, i.e. just bnecause the client closed the surface doesn't mean the shell is totally done (perhaps we want to do an animation(
<racarr> lol so in the end the solution is three lines
<racarr> ok im pretty happy about that :)
<bschaefer> if anyone can reproduce, seems pretty bad (though it only happens when existing from an egl app): https://bugs.launchpad.net/mir/+bug/1221974
<ubot5> Launchpad bug 1221974 in Mir "eglTerminate double free or corruption using mir" [Undecided,New]
#ubuntu-mir 2013-09-07
<kdub> racarr, sorry, got embroiled in fighting the nexus10
<kdub> racarr, i like the sound of the last idea, although, it might be better done as a deleter than a destructor?
<racarr> kdub: Hmm y eah a deleter is probably better
#ubuntu-mir 2014-09-01
<duflu> camako: Welcome to... Sunday?
<duflu> RAOF: Are we really waiting to upstream the latest Mesa patch before putting it in distro?
<camako> thanks duflu...
<camako> duflu, have you tried running the 0.7.0 silo on the desktop?
<duflu> camako: No. Still doing the morning bug triage and refresh of code reviews... And will be into the afternoon
<duflu> camako: Hey I notice butter made it in. That's exciting
<camako> duflu, yes it did... I wanted to get the privatise-headers too, but not gonna happen in this release
<duflu> camako: Well, it got bloated out as I caved into pressure to republish the headers used in examples.
<duflu> There's very little risk to landing it though. I have been testing with qtmir and usc
<camako> We already did a bunch of testing... finishing it up as we speak.. be greenlighting it unless I find smth majorly wrong
<duflu> I was a bit disappointed to find examples/ increased the size of the public SDK so much. But it's given me ideas for slowly trimming it back into the future
<duflu> It's just getting harder as time goes by... and complexity increases
<duflu> I did spot one potential major chunk of work that might be dead code now. Not sure, will have to investigate
<camako> yeah it'd be good to trim it down
<RAOF> duflu: No? Why do you think that?
<duflu> RAOF: Ah good. Anpok suggested that in a bug
<RAOF> Ah.
<RAOF> I *have* been somewhat remiss in reviewing and pushing that patch, though :)
<duflu> RAOF: Or it seems I misunderstood: https://bugs.launchpad.net/mir/+bug/1275398
<ubot5> Ubuntu bug 1275398 in mesa (Ubuntu) "i915 driver/i945 hardware: Mir GL clients are rendered as black or transparent windows when using i945 graphics" [High,In progress]
 * RAOF is confused by helgrind reporting tons of âunlocked not-locked mutexâ errors in ~unique_lock on armhf. 
<duflu> RAOF: It does seem valgrind's ARM support is a bit immature
<RAOF> â==9897== Thread #38: Bug in libpthread: write lock granted on mutex/rwlock which is currently wr-held by a different threadâ
<RAOF> Yeah, this might be valgrind being terrible.
<duflu> RAOF: Well valgrind is mostly good for armhf, except for the occasional unimplemented instruction. Seems the helgrind plugin needs some attention to be taught what the locking primitives are for ARM
<camako> My N7 won't boot!
<RAOF> Program received signal SIGILL, Illegal instruction.
<RAOF> 0x0044a538 in std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string()@plt ()
<RAOF> GrrrrrrrrrrrARGH.
<duflu> RAOF: Oh valgrind+armhf? :)
<RAOF> No; gdb + armhf.
<RAOF> So, the thing I like most of all is having weird armhf failures because our test harness does something wrong in ways that are never tested on !android.
<memeka> hi .... does Mir run on top of libhybris hwcomposer ?
<duflu> memeka: Yes it does on Android
<memeka> duflu: how about on Linux ?
<duflu> memeka: Both are Linux :) On desktop it uses Mesa/DRM
<memeka> duflu: can it work with this: https://github.com/mbrasser-jolla/qt5-qpa-hwcomposer-plugin ?
<memeka> duflu: I have the min amount of android services working (pvrsrvkm for GPU, android-media-server and android-service-manager) and libhybris - test_hwcomposer works. sound and everything else is all linux non-android (ALSA/pulseaudio, etc...)
<memeka> will Mir start on my system?
<duflu> memeka: I don't think so. I'm no Android/HWC expert but the intention with Mir is to make Mir the layer between the tookit (Qt) and the hardware (via libhybris). So we don't actually expose HWC for anyone to use. You have to write for Mir
<memeka> duflu: I could install qtwayland + the qpa-hwcomposer plugin and then run qml-compositor - under there start a nested weston instance, run qt5 apps etc
<memeka> libhybris exposes several EGL_PLATFORM ... does Mir works with all of them
<memeka> ?
<duflu> memeka: I think you're asking deeper Android questions than I can answer. Maybe try kdub when he comes online.
<memeka> duflu: thanks ... I am not sure what I am asking but the main idea is to see if I can run Mir :)
<RAOF> You'll be using the qtmir plugin, anyway.
<memeka> and Unity8
<RAOF> (Qt5 platform plugin, that is)
<RAOF> I _think_ the answer is âyes it should, modulo driver weirdness - and there's always driver weirdnessâ âº
<memeka> RAOF: so I can then install qtwayland + qt5-hwcomposer qpa + qtmir + mir + ... ?
<anpok> -qtwayland -qt4-hwcomposer
<anpok> then yes..
<RAOF> Well, you wouldn't want qtwayland or qt5-hwcomposer.
<memeka> RAOF: so, given a libhybris install, and test_hwcomposer running (and showing the pattern on the screen) ... what's next for me to get Mir displaying stuff on screen?
<RAOF> memeka: What happens if you try running one of the demo servers? :)
<memeka> I haven't any demo server ....
<memeka> didn't know what to install :D
<RAOF> You want a build of lp:mir/devel on there :)
<RAOF> If you've got Ubuntu running then mir-test-tools and mir-demos are the relevant packages.
<RAOF> Well, or you could just install the ubuntu-touch metapackage and see if unity8 just works :)
<memeka> RAOF: can i just checkout http://bazaar.launchpad.net/~mir-team/mir/development-branch/files and do a dpkg-buildpackage -b ?
<RAOF> Yup.
<memeka> how old are the ubuntu-touch components in the utopic repo? should i just try that first ?
<memeka> RAOF: also is there any X dependency? since X11 won't display anything on my system - since the GPU is android - libhybris ....
<RAOF> No X dependency..
<memeka> RAOF: oh, the ubuntu-touch meta is only in that ppa
<RAOF> Well, no runtime dependency.
<memeka> RAOF: still cannot find the ubuntu-touch metapackage ... where is it ?
<RAOF> ubuntu-touch:
<memeka> RAOF: also, do I need any xf86-video-xxx ? cause there isnt any for my GPU (I don't care about xmir)
<RAOF>   Installed: (none)
<RAOF>   Candidate: 1.181
<RAOF>   Version table:
<RAOF>      1.181 0
<RAOF>         500 http://mirror.internode.on.net/pub/ubuntu/ubuntu/ utopic/universe amd64 Packages
<RAOF>         500 http://archive.ubuntu.com/ubuntu/ utopic/universe amd64 Packages
<RAOF> Nope, no X runtime dependencies.
<memeka> thanks RAOF ... I will report back after I have finished trying :D
<memeka> RAOF: there are no ARM packages. .. looks like i will have to build everything :D
<RAOF> http://ports.ubuntu.com/dists/utopic/
<RAOF>  http://ports.ubuntu.com/dists/utopic/
<RAOF> memeka: You're looking for ports.ubuntu.com
<RAOF> Hm. Laaaaaaag.
<memeka> RAOF: awesome, thanks! (ther mirror did not have them but they are there)
<memeka> cheers
<RAOF> Woot! One branch (hopefully) fixed on CI!
<RAOF> ...mutter mutter stupid android tests mutter mutter...
<duflu> Oh fun. I'm getting conflicts from a non-existent file
<duflu> Wow. Wacky bzr conflicts. This is very strange
<camako> Mir 0.7.0 is now in the archive
#ubuntu-mir 2014-09-02
<duflu> Oh, utopic got 0.7.0 already. Nice.
<duflu> camako: !
<RAOF> SIGHUP? Really?
<duflu> RAOF: Well, it was better than SIGTERM (which we had previously). Next step: Someone propose some nice error returns instead
<duflu> Although that's possibly a client API change
<RAOF> Clients can already handle that.
 * RAOF actually quite liked SIGTERM
<RAOF> I don't think it _is_ better than SIGTERM, although SIGPIPE is probably the best choice of a bad bunch.
<duflu> RAOF: Yeah I tried SIGPIPE, and for weird reasons it interacted with the socket code causing strange unreproducible test failures
<duflu> But feel free to continue to improve/change it
<RAOF> What was wrong with sigterm, anyway?
<RAOF> SIGHUP _means_ something.
 * RAOF lunches.
<duflu> RAOF: Per the description: http://bazaar.launchpad.net/~mir-team/mir/development-branch/revision/1881
<duflu> Apps need to distinguish between expected/desired and unscheduled/unexpected shutdowns
<RAOF> Then they can hook up a lifecycle callback and get disconnected results.
<duflu> RAOF: OK. I'm not familiar with "lifecycle" stuff. It must have crept in when I wasn't looking. Although you still need a default behaviour too...
<duflu> Which is at least now not spinning or crashing. That's an improvement :)
<RAOF> Right; the default behaviour we had was SIGTERM, which seems reasonable to me; if not that, then SIGPIPE because that's what you get from everyone else (X11 & Wayland, particularly).
<duflu> RAOF: During the code review I think we all preferred SIGPIPE. If you can change it and figure out why it was causing weird CI failures then go ahead
<RAOF> alf_: UsingStubClientPlatform *doesn't* stub out the client platform, though.
<alf_> RAOF: how so?
 * alf_ reads code again
<RAOF> alf_: I've expounded on the MP.
<RAOF> But basically, prev_api->connect() is not going to call StubMirConnectionAPI's configuration().
<RAOF> It's going to call DefaultMirConnectionAPI's configuration()
<alf_> RAOF: oh, you are right... completely inheritance fail there :)
<RAOF> Well, that's a nice change of pace.
<RAOF> The non-android CI bits fail. :(
<anpok_> i need an opinion on checking for egl extensions
<alf_> anpok_: ?
<anpok_> currently we throw when mesa_drm_image is not available
<anpok_> but we do not use the API provided by that extension
<anpok_> i came across a driver that does not suppor the api of that extension.. yet mir works
<anpok_> so I changed that to egl_khr_image_pixmap
<anpok_> but on some configurations that extension is not advertised either..
<anpok_> while it works..
<anpok_> in theory mesa_drm_image is a good indication since it requires the image loader dri extension to be available
<anpok_> which we need internally inside the mesa mir platform..
<anpok_> i kind of alternate between checking for those extension above but warning only vs dropping the extension check entirely
<anpok_> oh i could also find and fix all driver setup combinations that might falsly claim that the extensions do not work
<alf_> anpok_: well, ideally we should fix the drivers and remove the mesa_drm_image check from mir
<alf_> anpok_: which drivers have such an issue?
<anpok_> missing mesa_drm_image is with kms-swrast
<anpok_> the other extension - I have not investigated it happens with intel drivers but never looked exactly when and how
<alf_> anpok_: I would say we drop the mesa_drm_image extension check, keep the egl_khr_image_pixmap check
<alf_> anpok_: and look at what's wrong (if anything) with the intel drivers
<Saviq> guys, is it possible that new Mir played bad with keyboard input on the device (as in evdev, not vkb)
<alf_> Saviq: everything is possible (not sure how likely, though), what problem are you seeing?
<Saviq> alf_, verifying now, but no autopilot key strokes reach the text entry
<Saviq> alf_, flashed 217 now so will know in a moment
<Saviq> that worked, /me upgrades
<alf_> Saviq: worked => no keyboard problem?
<Saviq> alf_, yeah
<alf_> Saviq: ok, good :)
<Saviq> alf_, well, not good, yet, upgrading to new Mir now ;)
 * alf_ can't recreate any of the non-android CI failures we are seeing, going to update system to see if that helps
<alf_> RAOF: ^^ any luck with these?
<Saviq> alf_, ok, you guys are off the hook, something weird's happening on our packages
<alf_> Saviq: ack
<racarr> Morning!
<kdub> hello racarr welcome back
<racarr> kdub: Thanks! ... feels a little strange to be at a computer! Reading email is kind of comforting though. How goes settling in michigan?
<racarr> How goes Mir? Is it done yet...;)
<kdub> pretty good, moved in and all
<racarr> Yay
<racarr> </catches up on email>
#ubuntu-mir 2014-09-03
<rsalveti> robert_ancell: getting bug 1364725 on krillin
<ubot5> bug 1364725 in lightdm (Ubuntu) "Krillin fails to display spinner/unity8 after upgrade to 1.11.7-0ubuntu1" [Undecided,New] https://launchpad.net/bugs/1364725
<rsalveti> krillin + ubuntu-touch from proposed
<robert_ancell> rsalveti, got the lightdm.log after it occurs?
<rsalveti> can easily get that for you, 1 sec
<rsalveti> robert_ancell: https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1364725/comments/1
<ubot5> Ubuntu bug 1364725 in lightdm (Ubuntu) "Krillin fails to display spinner/unity8 after upgrade to 1.11.7-0ubuntu1" [High,New]
<robert_ancell> hmm, that looks normal to me
<rsalveti> the main difference when comparing with the older one is:
<rsalveti> [+2.00s] DEBUG: Seat: Switching to Mir session session-0
<rsalveti> [+2.00s] DEBUG: Activating login1 session /org/freedesktop/login1/session/c2
<rsalveti> I don't get such lines
<rsalveti> but unity8 is running fine
<rsalveti> let me try getting a screenshot
<rsalveti> no, screenshot is also all black
<robert_ancell> Right. So it's like LightDM hasn't told u-s-c that that session is ready
<rsalveti> also added the log diff to the bug
<robert_ancell> rsalveti, could you attach both logs as files? The diff is a bit confusing due to the timing
<rsalveti> sure
<robert_ancell> the diff shows more information from the log than you pasted
<rsalveti> all attached
<robert_ancell> rsalveti, could you also run lightdm --show-config on the device and paste that?
<rsalveti> robert_ancell: from 1.11.6 or 1.11.7?
<robert_ancell> 1.11.7
<rsalveti> or doesn't make any difference
<rsalveti> sure
<robert_ancell> it was only introduced then
<rsalveti> robert_ancell: https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1364725/comments/7
<ubot5> Ubuntu bug 1364725 in lightdm (Ubuntu) "Krillin fails to display spinner/unity8 after upgrade to 1.11.7-0ubuntu1" [High,New]
<rsalveti> robert_ancell: this doesn't happen all the time though, sometimes unity8 shows up just fine
<robert_ancell> oh, ok
<rsalveti> maybe a race
<rsalveti> let me try to get into a working state (harder than actually reproducing the bug)
<rsalveti> robert_ancell: https://launchpadlibrarian.net/183907934/lightdm.log with 1.11.7 from a working boot
<rsalveti> so yeah, didn't switch to mir session
<robert_ancell> definitely a race of some sort then
<robert_ancell> rsalveti, could you try lp:~robert-ancell/lightdm/unity-activate and see if that makes a difference?
<robert_ancell> rsalveti, Also, looking at ~/.xsession-errors might give some clies
<robert_ancell> clues
<rsalveti> robert_ancell: sure
<rsalveti> nothing useful in ~/.xsession-errors
<rsalveti> building from your branch
<rsalveti> robert_ancell: rebooted more than 10 times, worked fine at every time
<robert_ancell> rsalveti, cool
<robert_ancell> rsalveti, do you have a log from a successful boot with that change? It was just a hunch that suggested that code might have broken but it really shouldn't work...
<rsalveti> robert_ancell: http://paste.ubuntu.com/8220528/
<robert_ancell> ah, so I was right. It's actually failed to find the logind session id which is a very bad thing (TM). That was exposing a bug that my branch fixed
<robert_ancell> I'm working on a proper fix now
<rsalveti> awesome
<robert_ancell> rsalveti, could you try lp:~robert-ancell/lightdm/logind-session-id-env-var and see if that works
<robert_ancell> This is the good fix
<rsalveti> robert_ancell: sure
 * robert_ancell hates the feeling when you'd seen some flaky code at some point in the past and not bothered to fix it then it comes to bite you in the butt later on...
<rsalveti> robert_ancell: yeah, seems fine as well
<rsalveti> unable to reproduce the issue
<robert_ancell> rsalveti, ok, cool. I'll ship that then
<rsalveti> robert_ancell: awesome, thanks
<robert_ancell> Have you got a log so I can double check?
<rsalveti> robert_ancell: http://paste.ubuntu.com/8220784/
<robert_ancell> that looks better
<robert_ancell> rsalveti, brb, just smoke testing
<robert_ancell> rsalveti, ok, all good. Uploaded as 1.11.8-0ubuntu1
 * robert_ancell -> dinner
<rsalveti> robert_ancell: awesome, thanks!
<duflu> RAOF: Oh, the problem with SIGPIPE happens with SIGHUP too. It's just some pre-existing unreliability in the test framework - https://bugs.launchpad.net/mir/+bug/1364772
<ubot5> Ubuntu bug 1364772 in Mir "[regression] acceptance tests fails in ServerDisconnect.causes_client_to_terminate_by_default" [Medium,Triaged]
<duflu> So we could have used SIGPIPE. Need to fix the test infrastructure tho
<RAOF> Well, sigPIIIIIIIIIIIPE is up for review :)
<duflu> RAOF: I know. Haven't got around to it yet
<RAOF> That's fine; it's got a prerequisite branch anyway :)
<Saviq> hmm guys how do you think would that be possible:
<Saviq> unity-system-compositor: symbol lookup error: /usr/lib/arm-linux-gnueabihf/libmirserver.so.24: undefined symbol:
<Saviq> _ZTIN7android7RefBaseE
<Saviq> seems libmircommon1:armhf got upgraded as I was installing unity8-autopilot
<Saviq> (that's RTM btw)
<Saviq> but that must've not pulled in new mirserver or so
<ogra_> new mir isnt in rtm yet
<ogra_> it landed in 218 in devel-proposed but didnt migrate over yet
<Saviq> http://pastebin.ubuntu.com/8222494/
<Saviq> ogra_, well, yeah, but package deps should not have allowed me to get into that state
<Saviq> ogra_, should force upgrades where required
<ogra_> then you need a versioned dep
<Saviq> ogra_, as now I ended up with a mix of mir 0.6.1 and 0.7.0
<ogra_> defining a minimal version in unity
<Saviq> ogra_, it's not that, unity doesn't even depend on mir directly
<ogra_> well, it also seems like the new packages migrated but arent in the image
<ogra_> (new rtm image is currently building, so i guess that will have it)
<Saviq> ogra_, sure, still ;)
<Saviq> ogra_, http://pastebin.ubuntu.com/8222504/
<ogra_> right, there is some dependency screw up somewhere
<Saviq> I only asked apt to install unity8-autopilot - that pulled in libmircommon1 0.7.0, that should've pulled others with it, as there seems to have been an ABI break
<Saviq> because u-s-c doesn't start
<Saviq> complaining about missing symbols
<ogra_> right
<Saviq> *something* should've forced upgrades of the whole of mir I'd say
<ogra_> file a bug so a dep gets added
<Saviq> yeah, will do, just wanted some feedback from the guys here
<anpok> hmm
<anpok> why does qtmir-plugin only depend on mircommon?
<anpok> i would have thought anything of qtmir needs mirserver
<anpok> is qtmir dloading mir?
<anpok> hm ok qtdeclarative5-qtmir-plugin only pulls in mircommon while qtmir-android adds mirserver..
<Saviq> bug #1364890
<ubot5> bug 1364890 in mir (Ubuntu) "Some dependency or missed SONAME bump causes missing symbols" [Undecided,New] https://launchpad.net/bugs/1364890
<greyback> anpok: qtmir-{android,desktop} needs mirserver, as that is the code which creates a mir server. qtdeclarative5-qtmir-plugin just allows Qt/QML to interact with the mir server, so needs some of the common mir stuff (mostly enums I think)
<racarr> Good morning!
<alf_> racarr: Hi!
<racarr> alf_: :) How goes?
<anpok> hm I was curious what was happening there: https://code.launchpad.net/~raof/mir/dont-kill-the-poor-clients/+merge/232971/comments/568627 but I cannot reproduce locally
<anpok> has anybody else looked at that yet?
<racarr> not yet
#ubuntu-mir 2014-09-04
<duflu> RAOF, anyone: Please review this ASAP: https://code.launchpad.net/~mir-team/mir/fix-1364772/+merge/233298
<RAOF> Hm. Why doesn't this work?
<RAOF> ...checks...
<RAOF> return std::shared_ptr<PlatformProbeReport>{};
<RAOF> Oh. Yeah. Need to actually implement that :)
<duflu> RAOF: Trivial needs fixing ... then we can land it: https://code.launchpad.net/~raof/mir/from-the-neglected-branches-files/+merge/233150
<RAOF> Ta, done.
<duflu> Saviq: Just starting on your symbol bug now. Is it actually a problem that needs fixing in 0.7 or is a clean ABI bump later in 0.8 enough?
<duflu> Because the latter can't be backported to 0.7
<Saviq> duflu, I don't think it's a huge problem, as long as it gets resolved, it's rare that people would just install one package (as opposed to a dist-upgrade)
<Saviq> duflu, so I think it's fine to do in devel
<duflu> Saviq: OK, so long as you don't need a backported fix then it's just an ABI bump. If you do need a backported fix then I need to hunt down symbols and add them into 0.7
<Saviq> duflu, no, is fine, it's a corner case, just wanted to make sure it gets addressed
<duflu> Saviq: Also, we only introduce the reduced symbol map for each library once. Such bugs can't happen again
<Saviq> duflu, kk
<duflu> I'm not a fan of symbols.map, but trying to work with it
<anpok_> i believe in qtmir we initialize an egl context with gles and only later switch to gl
<anpok_> while in qtubuntu we initialize an egl context with eglBindAPI(EGL_OPENGL_API)
<anpok_> (on desktop)
<anpok_> the interesting part is that mesa on i915 (depending on the gpu) either exposes (es 2.0, GL 2.1) capability
<anpok_> or (es 2.0, gl 1.4)
<anpok_> and that is actually a workaround introduced for unity7 to make it not use certain effect on i915 systems..
<anpok_> *effects
<duflu> Sounds likely. I know Unity<=7 always had different code paths in Nux for i915
<anpok_> duflu: did unity7 use occulusion query somewhere?
<duflu> anpok_: What's that?
<anpok_> with that you can query the amount of samples drawn from a primitive
<duflu> No idea
<anpok_> because thats used somewhere in the logic in mesa..
<anpok_> to decide if it is 1.4 or 2.1
<anpok_> maybe thats just an awkward check to differ between generations of the gpu and not related to usage..
<anpok_> hm I think we could enable unity8 by adding a fallback .. trying to create an 1.4 context and checking that the vertex and fragment program extensions are there..
<duflu> Well anything is better than trying to use LLVM on an i945 system :)
<duflu> Except of course the third option (a black screen) we have right now
<anpok_> well the i915 driver falls back to swrast
<anpok_> to implement shaders..
<anpok_> afaik
<duflu> Yeah. And it works well, last I checked
<duflu> Just not in Mir yet
<anpok_> maybe my enthusiasm is slightly damped because I always used debuf versions of mesa
<anpok_> s/f/g
<anpok_> so if we bump mircommon we will run into the rpath linker issues again?
<robotfuel> kgunn: ping, can you have someone look at this stacktrace on this crash and see if it's usable? https://bugs.launchpad.net/ubuntu/+source/qtdeclarative-opensource-src/+bug/1365673  maybe it's a client that can't connect? I didn't get video :(
<ubot5> Ubuntu bug 1365673 in qtdeclarative-opensource-src (Ubuntu) "/usr/lib/arm-linux-gnueabihf/qt5/bin/qmlscene:6:qt_message_fatal:QMessageLogger::fatal:UbuntuClientIntegration::UbuntuClientIntegration:UbuntuMirClientIntegrationPlugin::create:loadIntegration" [Undecided,New]
<racarr> ah...right...sbuild on armhf fails because of the explicit G++ dependency somehow
<racarr> it seems like...
<racarr> mir build dependecies pull in
<racarr> g++4.9:armhf
<racarr> but what the sbuild needs is a
<racarr> x86 armhf crosscompiler right?not the armhf binary
<racarr>  g++-4.9:armhf : Depends: gcc-4.9:armhf (= 4.9.1-10ubuntu2) but it is not going to be installed
<racarr> E: Build-dependencies for sbuild-build-depends-mir-dummy could not be satisfied.
<racarr> I wonder if I can do anything about it
<racarr> all I see in
<racarr> debian/control is g++-4.9...no architecture mention...
<racarr> does anyone know someone to be particularly knowledgeable about cross compiling, e.g. maybe they have seen this sort of thing before
<racarr> I wonder what other packages explicitly depend on a G++ version
<racarr> https://wiki.debian.org/CrossToolchains suggests depending on g++-4.9-for-host
<racarr> https://wiki.debian.org/CrossTranslatableBuildDeps
<racarr> suggests something else...
<racarr> *investigates revision dates*
<racarr> oh I see the second one is a proposal
<racarr> it kind of seems like its all proposals, aha
<racarr> It looks like I could use build profiles but its not clear ubuntu has that?
#ubuntu-mir 2014-09-05
<racarr> !! I think I fixed it
<ubot5> racarr: I am only a bot, please don't think I'm intelligent :)
<racarr> :( fine
<racarr> I think maybe I got it
<racarr> but I may just be mis understanding...actually
<racarr> tried build dependency as g++-4.9:native
<racarr> hmm colinwatson suggests against using g++-4.9:native but doesnt say why in the reference I found
<racarr> hahahahahaha
<racarr> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=760158
<ubot5> Debian bug 760158 in dpkg "dpkg: please implement the new build profiles syntax" [Wishlist,Open]
<racarr> no wonder build profiles aren't working
<racarr> the patch was posted 4 days ago
<racarr> lol ok it seems there really is no fix here but debian is on top of it. I'm going to make a script to modify debian/control to depend on g++-4.9-arm-linux-gnueabihf  instead of g++-4.9, build a source package, restore debian control
<racarr> and call it "create-cross-compile-source" or some such...maybe useful enough to check in ill think about it
<racarr> if nothing up will write an email with findings
<racarr>  / comment on https://bugs.launchpad.net/ubuntu/+source/mir/+bug/1353855
<ubot5> Ubuntu bug 1353855 in unity8 (Ubuntu) "Explicit g++ 4.9 dependency breaks cross-building" [Undecided,Confirmed]
<duflu> RAOF: Can you comment on correct procedure for updating symbols.map here? https://code.launchpad.net/~vanvugt/mir/mircommon2/+merge/233310
<RAOF> duflu: Done
<duflu> RAOF: So if only adding new symbols then add a new block for SONAME+1 but don't bump SONAME?
<duflu> Sounds futuristic
<RAOF> New block for new version; SONAMEs reset the blocks ;)
<duflu> RAOF: OK so what's the block named in the case of no new SONAME?
<RAOF> The new Mir version would be an obvious candidate.
<RAOF> But it actually doesn't matter at all as long as the string is unique across all versions.
<duflu> RAOF: Hmm kinda makes sense but we presently use SONAMEs (kinda) in the symbols.map
<RAOF> Right. Because when I first proposed it I used the Mir version and everyone was all âthat'll be confusingâ :P
<duflu> All options are confusing in their own little way
<RAOF> We could actually just use the output of uuidgen. It would be equivalent :)(
<duflu> RAOF: OK, so for the simple case (and common case) where we've broken the ABI anyway, just continue bumping the SONAME in the symbols.map?
<duflu> I say "continue" should be "start"
<RAOF> Yes.
<duflu> RAOF: Oh of course. Because there won't be users of the old version (already enforced by SONAME in dynamic loading)
<RAOF> Well, there actually might be - in the case that something links against libmirfoo.so.X and additionally links against libbaz which links against libmirfoo.so.X-1.
<RAOF> Which fails appalingly in the absence of symbol versioning, but can work with appropriate versioning (in this case, meaning things in mirfoo.so.X need different versions to mirfoo.so.X-1, which is satisfied by âbump the version to the new SOVERâ).
<RAOF> Of course, with our magical protobuf singleton that fails _anyway_, but it's a really useful property to have if we can fix the protobufing.
<duflu> RAOF: I'm not convinced we're disciplined enough for symbol versioning to work out properly, but will continue supporting the effort :)
<RAOF> Oh, for the immediate and mid-term future our versioning is just going to be âbump the SOVER, change the versionâ.
<RAOF> But even that is useful, because when we _do_ get into a position to be more stable than that we can take advantage of âload multiple different SOVERs in the same processâ, which you can only get if everything's always been versioned.
<duflu> RAOF: So SONAME bump means bump symbols.map. But symbols.map should be bumpable more often than SONAME?
<RAOF> Correct.
<RAOF> Anytime you add something to symbols.map it should technically go in a new version section.
<duflu> RAOF: Might be a good idea for new functions to just go in SONAME+1. Then assuming they don't change, that will remain true when we do finally break the ABI
<RAOF> Oh, when we break the ABI then everything coalesces into a single new version.
<duflu> RAOF: Exactly
<duflu> And the new functionality added during SONAME-1 was already linked as symbol version SONAME
<RAOF> Ah, but how do you distinguish between two different additions *before* the new SONAME?
<duflu> RAOF: Crap
<RAOF> eg: We release 0.7. In 0.8 we add some symbols, adding them to a new version bit. In 0.9 we add some more new symbols. Where do they go?
<RAOF> Then in 0.10 we break ABI and everything gets folded into a single new version stanza, and that's ok.
<duflu> RAOF: Ah, but if you break a new addition then by your own rules you would bump and coalesce everything anyway
<duflu> Kind of
<duflu> It wasn't part of SONAME-1 really
<RAOF> duflu: Right, but what if you add things in too successive releases without breaking.
<RAOF> I know this is largely theoretical, as it's predicated on us making two whole releases without breaking ABI, but longer term that won't be a joke :)
<duflu> Versions then
<RAOF> Of course, we at Canonical don't believe in versions and just continuously release from trunk :P
<RAOF> But that's a swamp we can drain when we get to it :)
<duflu> RAOF: Found somewhere we need to decide on the syntax of naming new blocks: https://code.launchpad.net/~kdub/mir/protobuf-exchange-buffer/+merge/232728
<RAOF> To the rebuild button!
<duflu> Yes please
<RAOF> A symbol versioning guide?
<duflu> RAOF: Just docs with sections titled "I have added new functionality" and "I have changed or removed existing functionality"
<duflu> RAOF: I meant yes to the rebuild. It will help land things faster
<duflu> https://code.launchpad.net/~raof/mir/remove-old-clang-workaround/+merge/233448
<RAOF> I've pressed rebuild on everything of mine that should build.
<RAOF> Including that one :)
<duflu> RAOF: OK then. Bon weekend
<duflu> anpok: Got a shiny new mesa coming to utopic soon?
<anpok> i think a 10.3 based version is close to be released
<anpok> I will have to talk marteen to include my patches. only one of them have been reviewed yet
<anpok> there were some llvm related issues.. and lately ppc build issues to resolve
<anpok> duflu: do you have a i915 system?
<duflu> anpok: Yes, but they're way out of date. Needs reinstalling.
<anpok> are those 945 and similar gpus still included in current intel processors?
<duflu> anpok: No, a few years old
<duflu> anpok: A few years old but still required to be supported by Ubuntu of course
<duflu> (e.g. original Netbooks)
<anpok> so also current atoms are now also served through i965?
<duflu> anpok: I think so(?)
<duflu> anpok: If you remind me, I'll have my i945 machines updated by next week
<anpok> i have a intel atom netbook.. now trying an optimized build
<duflu> Otherwise they gather dust
<duflu> I usually do hardware support experiments on weekends, but not very often. Not for a long time now
<anpok> yeah just i need to test the unity8-dash test with a non hacked mesa - hopefully the last iteration now
<anpok> s/test/change
<duflu> anpok: So after I do reinstall a machine or two you want me to also install nonstandard Mesa? :)
<robotfuel> kgunn:  do you know who the right person to assign this crasher to? https://bugs.launchpad.net/ubuntu/+source/qtdeclarative-opensource-src/+bug/1271879 we had more crashes for this yesterday on errors.ubuntu.com  from the long running tests.
<ubot5> Ubuntu bug 1271879 in qtubuntu (Ubuntu) "qmlscene crashed with SIGABRT in qt_message_fatal()" [Undecided,Confirmed]
<kgunn> robotfuel: sorry, i got lost in bug world y'day....didn't mean to ignore you
<kgunn> robotfuel: sorry, i got lost in bug world y'day....didn't mean to ignore you
<robotfuel> kgunn: heh that's okay I can always bug you again ;)
<kgunn> robotfuel: so that's ancient ?
<kgunn> is that right ?
<kgunn> ...so the signature is the same ?
<robotfuel> yes it is still crashing in yesterdays image
<robotfuel> kgunn: https://bugs.launchpad.net/ubuntu/+source/qtubuntu/+bug/1365673 has the latest errors.u.c link
<ubot5> Ubuntu bug 1271879 in qtubuntu (Ubuntu) "duplicate for #1365673 qmlscene crashed with SIGABRT in qt_message_fatal()" [Undecided,Confirmed]
<kgunn> robotfuel: any hints on when/what exactly makes it happen ?
<robotfuel> kgunn: no I connected a camera to try to catch the crash, but it hasn't happened again today.
<kgunn> robotfuel: so spoke to some guys....sounds like the original fix is still in place (e.g. unity-mir replaced by qtmir..but the change is there)
<kgunn> they said that the unity8 log would be really helpful
<kgunn> can you grab that if it happens ??
<kgunn> robotfuel: ^
<robotfuel> kgunn: I have the unity8 log, I just need to dig it out of jenkins
<kgunn> sweet, thanks, just attach to the bug
<kgunn> robotfuel: think we can dedup 1271879....and close out 1365673 ?
<robotfuel> kgunn: if that works better for you sure
<kgunn> yes please
<robotfuel> kgunn: I've added the crash files to 1365673
<kgunn> tahnks
<Tassadar> Hi, I have a problem with some code in unity-system-compositor, namely the part which takes care of screen power off/on during suspend/resume after pressing the power button - http://bazaar.launchpad.net/~unity-system-compositor-team/unity-system-compositor/trunk/view/head:/src/screen_state_handler.cpp#L162
<Tassadar> the sequence of operations is "turn the screen of with blank call (under display->configure())" and _then_ set brightness to 0
<Tassadar> android does it the other way around - it sets the brightness first
<Tassadar> that's the reason why backlight on nexus 5 stays on all the time, the kernel driver refuses to set the brightness after the panel is powered down
<Tassadar> is there anybody who knows if there's a specific reason why the screen panel is turned off before the brightness is set, or would it be okay to change the order to the one Android has?
<kdub> AlbertA,^
<kdub> I don't know of a reason
<Tassadar> I'd try out if it works when I change the order, but setting up the build would probably take ages
<racarr> Oh! I never said good morning hi everyone
<racarr> sorry I slept through standup:). Standup:
<racarr> Distracted from USC touchspot configuration by perfecting cross compile work flow
<racarr> I think i've made a lot of progress though and will be writing up something good soon...
<racarr> actually right now im using my new cross compile set up to test my USC changes
<racarr> and then will submit those, then send some emails about cross compiling
<AlbertA> kdub: Tassadar: yeah no particular reason
<Tassadar> okay, so can I submit a merge request which changes the order?
<AlbertA> Tassadar: yeah go ahead
<Tassadar> hm, actually, I'd really like to test it out frist
<Tassadar> what about "compositor->start();", does it matter if it is after or before display->configure()?
<AlbertA> that one has to be after configure
<Tassadar> okay
<Tassadar> I'll try to build that package so I can see if it works or not and then submit the merge request
<racarr> Shouldn't USC also have an explicit g++-4.9 dependency?
<racarr> (went to apply my hack and failed)
<AlbertA> Tassadar: for a quick test you can use these scripts
<AlbertA> https://github.com/albaguirre/unity-dev-scripts
<AlbertA> and do ./cross-compile.sh <usc directory>
<AlbertA> and ./adb-push.sh usc
<Tassadar> thanks
<racarr> https://code.launchpad.net/~mir-team/unity-system-compositor/explicit-g++-dependency/+merge/233564
<racarr> hmm having trouble getting sbuild top use my local apt repository for deps
<kdub> racarr, i'm having sbuild problems too
<kdub> although, mine might just be bad setup
<racarr> kdub: There are a few problems along the way...it doesn't really work at the moment
<racarr> I've got Mir to cross-build with a few hacks though just sturggling now to crossbuild USC against those packages
<racarr> where is it giving up for you?
<kdub> i'm still a few steps back
<racarr> if its the g++-4.9 dependency, you just have to remove it, change it to g++-4.9:native, change it to g++-4.9-arm-blablabla, etc.
<racarr> there's no actual fix atm...
<racarr> debian upstream is working on some tooling changes to fix it as late as...last week I found
<racarr> aha...
<kdub> hmm, i'll probably run into that
<kdub> every time i try sbuild its like spinning my wheels trying to find the magic key to get things going :/
<racarr> aha :(
<racarr> kdub: Do you know about https://wiki.ubuntu.com/SimpleSbuild
<racarr> this has been the best set of directions for me
<kdub> i'll try it out
<kdub> 'simple sbuild' would be
<kdub> ./go.sh
<kdub> :D
<racarr> lol
<racarr> ok so the short story is
<racarr> mk-sbuild --target armhf utopic
<racarr> then, prepare the mir source (replace g++-4.9 in debian/control with g++-4.9:native)
<racarr> build a source package
<racarr> bzr bd -S --native -- -uc -us
<racarr> -S for build source package, --native for build from working tree rather than try and download the upstream tarball
<racarr>  -uc and -us are options for debbuild to skip signing
<racarr> so you dont have to mess around with bumping the changelog
<racarr> then you will have the .dsc in the directory one up
<racarr> which you should now be able to build
<racarr> DEB_BUILD_OPTIONS=nocheck sbuild --build amd64 --host armhf -d utopic <PATH-TO-DSC-FILE>
<racarr> It's still going to be really slow though
<racarr> big optimizations: pre-populated chroot (discussed on simplesbuild, prepopulate with buidl deps)
<kdub> even at that though, still slow because its running through qemu
<racarr> wait really.
<racarr> I know pbuilder can use qemu but I thought sbuild was using a real cross chain
<kdub> eh, i might be wrong, but I saw it fetching the qemu emulator
<racarr> maybe it can use qemu!
<racarr> I am pretty sure if you use --build amd64 and --host armhf
<racarr> it should be a real cross chain though, the build I have running right now is using
<racarr> well, I see cc1plus in my top outside of the chroot so.
<racarr> its so confusing the "armhf" is called the "host" though
<racarr> anyway with prepopulated chroots, and ccache
<racarr> its actually quite fast...
<Tassadar> kdub: AlbertA https://code.launchpad.net/~vbocek/unity-system-compositor/fix-hammerhead-backlight/+merge/233572
<Tassadar> tested in on hammerhead and it works there, I hope it won't break anything else
<kdub> racarr, okay, you're right, seems to be using the cross compiler
<kdub> had to use that gcc 4.9:native thing
<kdub> Tassadar, cool, thanks
<Tassadar> that issue took way to long to track down)
<racarr> Back in a few, off to doctor
<racarr> kdub: :D Cool, hope you can get it working
<racarr> my EOD task for today is I hope to write up
<racarr> everything ive gathered, + the set of working instructions for the various
<racarr> optimizations, etc
<kdub> yeah, its going better than my previous attempts
<racarr> and post it to warthogs/phone list or something in which case
<racarr> someone who actually understands the tools will fill in the gaps
<racarr> and maybe we will finally have a nice workflow for it :D
<racarr> DOCTTOOOOOR TIME
<fginther> kgunn, camako, can either of you recommend someone to look at the new jenkins mir-mediumtests results? https://jenkins.qa.ubuntu.com/job/mir-mediumtests-runner-mako/2671/console
<fginther> this contains the modifications for the adb user changes
<fginther> The results look similar to the last job which passed.
<camako> fginther, RAOF is your guy... I'll ask him to look over..
<kdub> camako, have you gotten qtmir to build under sbuild?
<camako> kdub, no that's the only one because I think it uses some weird qml build files
<kdub> camako, hmm, okay
<camako> kdub, looking at the build logs... I guess I got over the qml build failures then I got this :
<camako> The following packages have unmet dependencies:
<camako>  sbuild-build-depends-qtmir-dummy : Depends: libubuntu-application-api-dev (>= 2.1.0) but it is not going to be installe
<camako> d
<camako> E: Unable to correct problems, you have held broken packages.
<camako> kdub, is this what you're seeing?
<kdub> i'm seeing
<kdub> qmake: could not find a Qt installation of ''
<kdub> and then qmake failes
<camako> kdub, let me check earlier build files
<camako> kdub, I take that back.. I did successfully built qtmir by itself.. What was failing for me is when I built qtmir with Mir packages coming from a local repo (also built with sbuild)
<camako> I got that conflict and I haven't had a chance to investigate it yet
<camako> I mean the 'unmet dep'
<kdub> well, thats encouraging
<kdub> camako, did you run into what I was seeing?
<camako> kdub, no
<kdub> okay, will keep poking at it
<racarr> Back
#ubuntu-mir 2014-09-07
<mibofra> hi guys :)
<mibofra> (may I ask a suggestion :)) ? )
#ubuntu-mir 2015-08-31
<duflu> RAOF: Your ANR branch is probably the next one that might be landable, but it sounds like it might be broken?..
<RAOF> I'll look after lunch. It might be.
<duflu> Argh. The diff to qtmir is now so large I have to start again. Thanks dandrader.
<duflu> Fark. vivid is ahead of wily? I didn't see that coming
<dhbiker> hello.
<dhbiker> is Mir independently developed
<dhbiker> or some sorts related to Wayland ?
<duflu> dhbiker: Completely independent
<anpok_> but you could claim that we are about to adopt an orphaned child that grew up in weston
<anpok_> hmm not really orphaned..
<anpok_> duflu: i believe the ci issues with mir-mediumtests-runner-mako are limited to mako-08
<duflu> anpok_: That's fine. I don't care about CI for the rest of today
<anpok_> duflu: is #ubuntu-ci-eng / cihelp the right channel to complain about that?
<duflu> anpok_: Can't remember
<anpok_> k will find out
<duflu> Find one with people in it :)
<guest42315> uuu mir 0.15.1
<guest42315> and black screen in wily :| and no .log files in .cache o_O
<guest42315> WHY DO YOU PEOPLE HATE WILY??
#ubuntu-mir 2015-09-01
<duflu> RAOF: Hmm X things as well as the console fail a lot in this DP 1.2 mode. Is that well known?
<RAOF> What sort of things? Is that MST mode?
<duflu> RAOF: Yeah MST (although only one monitor plugged in)
<RAOF> Ah, yah.
<RAOF> Yeah, that's in-progress-ish, from memory.
<duflu> The console is never native resolution and X randomly fails to start.
<duflu> Mir is fine though
<RAOF> airlied has done a bunch of work on it, but I'm not sure if any of the X drivers do the fiddling required to make it appear as a single monitor.
<duflu> That's fine. Mir works perfectly with it. Better hurry up and replace X
<RAOF> I'm a bit surprised that Mir works. What do we do with the two distinct outputs?
<duflu> RAOF: I only have one monitor on each physical output. And each monitor provides a second DP but I don't use those yet
<duflu> Still one monitor per stream
<duflu> RAOF: Mir just reports (when the two monitors are plugged in) that I now have 4 DPs and 2 are used
<duflu> which sounds correct
<duflu> Although there's still the old i915 bug of reporting my DVI converter as HDMI
<duflu> Last I checked that was a kernel bug
<RAOF> Ah, right.
<RAOF> DP 1.2 has enough bandwidth to drive your 4K monitor as a single panel.
<RAOF> 4K@60Hz
<duflu> RAOF: Not 4K just FHD
<duflu> or 1920x1200
<RAOF> Oh. I thought we were talking about monitors that need to appear as 2 distinct outputs in order to drive all the pixels.
<RAOF> I've got no idea why that wouldn't work with X at the moment.
<duflu> RAOF: No, just a standard monitor that provides a DisplayPort "hub"
<duflu> 4K would be fun. But my choice of monitors was motivated by cost (and that they still provide deep colour)
<duflu> Although I suspect deep colour just means true colour plus temporal dithering
<duflu> That's an improvement for me anyway
<duflu> Not that Linux can output deep colour to them right now.
<duflu> RAOF: Actually you do need to store the scaling factor. Because during resizing you need to know if the client wants to stretch, or is just lagging (and so should be clamped instead). Accidentally scaling during resize would be an ugly regression. We've been there before
<duflu> RAOF: Actually I posed an algorithm for that yesterday... https://code.launchpad.net/~vanvugt/qtmir/unstretch/+merge/268724
<RAOF> Our whole resizing logic is pretty bad, yeah.
<RAOF> But that's actually pretty easy - when we resize, we proportionately resize the attached buffer stream.
<duflu> RAOF: I mean we still need clamping logic, a hybrid with scaling as in the above branch
<RAOF> Oh, right. Yeah, I see your point.
<RAOF> That's an issue because we do resizing in roughly the worst possible way, though.
<duflu> RAOF: Actually it's the best. And the same way all other desktop OS's do it
<duflu> Just the event delivery needs work
<RAOF> And the âwhen has the client actually resizedâ bit.
<duflu> RAOF: Yeah that's a bug. It's well documented now
<duflu> As of Friday
<RAOF> So ignoring all the ways that resizing is terrible, it's the best possible :)
<duflu> RAOF: There are two open bugs. But the theory of doing it asynchronously is ideal
<duflu> Unity8 resizing was pretty terrible last I checked. But it's catching up
<RAOF> I think synchronous resizing would be better in most cases, but that's a matter of tradeoffs.
<duflu> RAOF: Definitely not. Even if it's working well, you'd have the window edge lagging behind the mouse. Which is much worse than the window contents lagging behind the edge
<RAOF> That is a value judgement, not an objective truth.
<RAOF> As I say, tradeoffs.
<duflu> RAOF: Try it by all means. And you will find out why no OS does it that way. The user experience is better when the thing you're moving keeps up with the mouse pointer (moreso)
<RAOF> By âno OSâ you mean âno OS but Ubuntuâ, right?
<duflu> Also keep in mind most of our resize lag is triple buffers. The problem is halved with double. And eliminated with swap interval zero.
<duflu> RAOF: Including Ubuntu they all do it the same
<duflu> Although you can try to drop frames, that also looks ugly. Anything that animates on the swap interval will jump during resizing
<duflu> Sadly I think that's where QtMir is right now. Haven't checked
<duflu> No, QtMir can't drop. That's OK then
<RAOF> step
<duflu> bt
<duflu> greyback: So when do you expect to start landing the large change to lp:qtmir?
<greyback> duflu: next couple of days, this is the culprit: https://code.launchpad.net/~gerboland/qtmir/multimonitor-spike/+merge/263602
<duflu> greyback: OK. I expect flux but if you guys are using big hammers I'll avoid the project for a while.
<duflu> Mir has similar problems... you can't just *fix* a bug because the code in question is always about to be rewritten by somebody
<greyback> duflu: I'll let you know when it lands then
<duflu> greyback: Still got a couple of trivial MPs to qtmir up in the mean time
<greyback> go for it
 * duflu wishes for mildly stable code that doesn't get rewritten so often
<duflu> stable meaning unchanging
<alan_g> You mean hardware?
<mcphail> RAOF: Is your "Mir-on-X" project the appropriate thing to use if I'm developing an app (for the phone, using libmirclient) but building and testing on a standard Unity7 Ubuntu desktop?
<duflu> mcphail: Mir runs on the Ubuntu Phone Emulator so you could use that.
<mcphail> duflu: I'll try it, but I've found graphics things very slow on the emulator (even non-arm emulators)
<guest42315> the emulator experience is really really really bad
<duflu> mcphail: Yeah, although running phone code on a desktop you can't easily test touch, unless you have a touchscreen laptop
<mcphail> duflu: True
 * mcphail will have another look at the emulator later
<mcphail> Cheers
<duflu> mcphail: You can install mir-demos, in which there are three demo servers. All of them understand "--vt 1" to run on a separate VT and you can switch back and forth with X using Ctrl+Alt+Fn
<mcphail> duflu: I'm running proprietary drivers, though. Will they work?
<duflu> mcphail: Oh, no it won't
<mcphail> duflu: I'd tried Unity8 with open source drivers but just got a black screen/flashing cursor so went back to the dark side
<duflu> mcphail: Yeah I'm not talking about Unity8. Just the mir_* demos in the mir-demos package
<guest42315> wily is currently broken on nvidia, i get a black screen
<guest42315> with nouveau
<duflu> Hmm, I wonder if any of ~mir-team has tested the latest wily nouveau
<mcphail> This is why "Mir-on-X" sounds like an exciting project! :)
<guest42315> nobody cares about nvidia :)) they all have intel
<duflu> mcphail: It has some conditions still. Like only works with some X drivers (not intel yet). And also lag is higher
<duflu> Hmm, I should check that too
<duflu> mcphail: Correction it works with intel now
<mcphail> duflu: does mir-on-x work with proprietary nvidia?
<duflu> mcphail: Not sure, but you can try easily:    sudo env DISPLAY=:0 bin/mir_proving_server
<duflu> I mean:    sudo env DISPLAY=:0 mir_proving_server
<mcphail> duflu: OK, I'll try this when I get home
<alan_g> duflu: you shouldn't need sudo to connect to X
<duflu> True
<duflu> It works inside X
<duflu> alan_g: Actually you do. Otherwise no mouse access
<alan_g> --platform-input-lib=lib/server-modules/server-mesa-x11.so.4
<duflu> It's so obvious
<alan_g> camako: is working on automatically selecting the right input stack
<mcphail> That gives me something to work with. Cheers guys
<duflu> Oh dear. Even --vt doesn't work like it used to
<duflu> I need to relearn the options
<alan_g> Yep, there is either too much or too little intelligence in the platform selection - but not the right amount.
<alan_g> yet.
<alf_> alan_g: ^^ Tue Sep 01 2015, the day mir platform selection turns into skynet :)
<alan_g> /sigh I nearly missed it
<alan_g> BTW alf_  thanks for sorting lp:1489806, I was looking it totally the wrong place.
<alf_> alan_g: yw
 * duflu wonders what changed from intel not working at all to suddenly working without effort
<duflu> Must have been a kernel change they were waiting on
<alan_g> duflu: Mir-on-X?
<duflu> alan_g: Yeah
<alan_g> an extension that camako was using landed in the driver
<duflu> alan_g: Any ETA on the double cursor issue?
<duflu> Or no discussion yet?
<alan_g> I've not heard anything
<duflu> Bah, it's a simple matter of X function calls
<alan_g> Sure, there's a whole lot "X function calls" needed for it to work right and camako is MPing each thing he get working. But I don't know the order or timescale.
#ubuntu-mir 2015-09-02
<Hawk_> trying to port ubuntu touch
<Hawk_> the system reboot if I use gralloc from CM but work well if using xperia gralloc binary
<Hawk_> any help is appreciated
<Hawk_> this url seem to be dead : http://unity.ubuntu.com/mir/md__h_a_c_k_i_n_g.html
<duflu> Hawk_: That site is unfortunately not updated very often. To access the latest (source) docs you can browse: http://bazaar.launchpad.net/~mir-team/mir/development-branch/files/head:/doc/
<duflu> Or access them in the doc/ directory of the Mir source code
<duflu> Hawk_: Also  http://bazaar.launchpad.net/~mir-team/mir/development-branch/view/head:/HACKING.md
<Hawk_> ok, thanks
<Hawk_> duflu, any tip on where to start looking? :)
<duflu> Hawk_: It can only be src/platforms/android/ really
<Hawk_> ok
<Hawk_> can the vivid arm source work without mir?
<Hawk_> for touch
<duflu> Hawk_: In theory yes. ubuntu-device-flash touch --developer-mode should give you an image that you can "adb shell" into without graphics. Although I've never tried myself
<Hawk_> mir is required to boot into graphic mode?
<duflu> Hawk_: Yes, every single pixel is Mir
<Hawk_> perhaps i should try out wily first
<Hawk_> maybe the mir has been patched somehow
<RAOF> You know, this would be much easier if I could just send an event to the client on surface creation.
<duflu> Oh fun. My kernel decided it can't VT switch any more. Either by keyboard or by other.
<duflu> Had to reboot
<RAOF> Yeah, VT_ACK is problematic :)
<duflu> RAOF: At least after receiving SIGTERM Mir tells me what it was waiting for
<duflu> RAOF: So does that mean it might have been X refusing to reply/give it up?
<duflu> That would be better than a kernel bug
<RAOF> Could have been.
<duflu> Good news. My MHL adapter has finally shipped
<duflu> :P
<anpok_> duflu: now only a mhl capable device is missing!
<duflu> anpok_: Oh?
<anpok_> yes..
<duflu> anpok_: Yes
<duflu> What?
<anpok_> it is a pitty..
<anpok_> n4 n7 are slimport..
<duflu> anpok_: Do our devices have fake MHL?
<duflu> anpok_: Yay. Another purchase
<anpok_> and the others might have mhl enoder chips as part of the soc.. but they might not be wired.. or be deactivated
<anpok_> at least noone managed to get the mtk kernel with mhl to boot
<anpok_> and looking at the code you probably dont want to have that do something on your device .. i found hard coded resolutions and display timings in there..
<duflu> Also yay. I can't buy Slimport adapters locally
<duflu> This will take more time
<duflu> Can't find Slimport things locally, but can find: http://www.jaycar.com.au/General-Consumer/Toys-%26-Games/15%2Byrs/Useless-Box-/p/GT3706
<anpok_> great!
<pixel> hi
<Guest86043> i have mir demo server on vt1 but i can't switch the vt (alt fn doesn't work)
<Guest86043> is it normal?
<Guest86043> on wily
<anpok_> on intel?
<Guest86043> anpok_: nvidia
<anpok_> i think we dont have a bug yet..
<Guest86043> anpok_: from unity8.log failed to load module server-mesa-x11.so.4 and QMirServer - mir failed to start
<Guest86043> so.. blame mesa?
<anpok_> it depends ..
<anpok_> but file a bug report..
<Guest86043> ok
<anpok_> i mean older nvidia cards lack gl-2.0 or gles-2.0 support, which will make qt initialization fail..
<anpok_> which mir version do you have installed?
<Guest86043> 0.15.0
<Guest86043> nvidia 8600
<Guest86043> mir worked before with mir 0.14.x
<Guest86043> with a diff mesa?
<Guest86043> anpok_: uh... i can change VTs if i sudo mir_demo_server
<Guest86043> anpok_: and mir works just fine
<Guest86043> anpok_: opengl gallion 0.4 v84 opengl es gles 3.0
<Guest86043> mesa 10.6.3
<Guest86043> anpok_: i'm playing with gedit on mir demo server
<guest42315> anpok_, oh :)) maybe i'm not on 0.15.0 :/ https://bugs.launchpad.net/mir/+bug/1490367
<ubot5> Ubuntu bug 1490367 in Mir 0.15 "Mir 0.15.1 reports itself as "0.15.0"" [Medium,Fix committed]
<guest42315> ok.. so  0.15.1+15.10.20150825-0ubuntu1
<guest42315> not 0.15.0
<guest42315> anpok_, https://bugs.launchpad.net/mir/+bug/1491372
<ubot5> Ubuntu bug 1491372 in Mir " mircommon: Failed to load module" [Undecided,New]
<anpok_> guest42315: please attach the full logs
<guest42315> anpok_, done
<guest42315> anpok_, if you need other logs i can upload them
<anpok_> hm
<anpok_> the complaint about mesa-x11 is ok.. unless of course you intended to run usc/unity8 from within X11
<anpok_> did unity8 manage to start?
<anpok_> guest42315: which nv generation do you use, and could you also attach unity8-dash.log?
<guest42315> anpok_, GeForce 8600 GT, and i've uploaded unity8-dash.log
<guest42315> after the lightdm.. screen i get a black screen but i can see the mouse cursor
<guest42315> thanks alan_g :>> i'll try to uninstall mir-platform-graphics-mesa
<Guest55614> same :( still doesn't load
<Guest55614> anpok_: in kern.log o_O MirServerThread and ibus-ui-gtk3 segfaults
<Guest55614> what is libX11-xcb
<mcphail> http://unity.ubuntu.com/mir/ is giving me a "not found" error. Is something broken?
<kdub> mcphail, it appears so
<mcphail> kdub: do you know who looks after the API docs? Was hoping to do a bit of hacking this evening
<kdub> mcphail, that site is generated from mir's doc/ folder
<kdub> make doc i think
<kdub> but in the meantime, i can figure out how to get it back
<mcphail> kdub: many thanks
<kdub> mcphail, out of curiousity, planning on working on something?
<mcphail> kdub: just trying to get a game engine running on the phone
<mcphail> kdub: feeling out of my depth :)
<kdub> mcphail, ah, cool, examples/ should have some examples of how to get a gl context going
<mcphail> kdub: Yes - they look really helpful
<kdub> good luck!
<mcphail> cheers!
#ubuntu-mir 2015-09-03
<RAOF> Oh, of course!
<RAOF> mir_surface_spec_set_event_handler!
 * RAOF always gets confused navigating our Shell hierarchy.
<RAOF> For example: why do we have two independent ShellWapper hierarchies, mf::ShellWrapper and ms::ShellWrapper, each with an identical (but not derived) interface?
<RAOF> I think adding an extra argument to session::create_surface is going to be a thousand-line diff.
<anpok> havent you thought about using variant to simplify that?
<anpok> or was that a different proble
<anpok> +m
<RAOF> anpok: I don't understand?
<RAOF> Specifically - I want to pass the EventSink for the surface in from SessionMediator, rather than inheriting the ApplicationSession's event sink.
<anpok> ok, i believe i understood - my suggestion was nonsense
<RAOF> This will let me (a) send surface events during surface construction, which I want to do, (b) close a race where we might send an event for a surface before we've sent the creation completion, and (c) be useful in an unrelated thing.
<RAOF> Why isn't there a C++ type for âshared pointer, but guaranteed non-nullâ?
<RAOF> Likewise: unique_ptr.
<RAOF> Well, that's a strange indictment of our test coverage.
<RAOF> Replace the scene::Surface's event sink with nullptr and no tests (other than the ones this branch adds) fail.
 * RAOF does some ZoÃ« time for an hour before my 6pm meeting...
<mcphail> http://unity.ubuntu.com/mir/ is still not working. Can someone give it a kick please?
<duflu> mcphail: It's automagical. I can't remember who updated it. alan_g?
<alan_g> Me neither. :(
<duflu> alan_g: My email history says it's a Jenkins job. So maybe just down temporarily with the rest of Jenkins
<duflu> Paul Larson fixed it last time (December)
 * mcphail loves things which work automagically :)
<alan_g> duflu: the Jenkins job pushes updates...doesn't explain why the page has gone.
<duflu> mcphail: Yeah it's managed by the Jenkins service, and that's been down for all projects since last weekend. So I guess wait till Jenkins is back and maybe the website will be too
<duflu> alan_g: True. Maybe null got pushed
<mcphail> duflu: Is it possible to push a placeholder for the time being? Dare I say, it doesn't look vry professional just now...
<duflu> mcphail: Completely agree. We'd have to wait for USA to wake up it appears
<mcphail> duflu: OK, cheers :)
<popey> on nexus 7 with silo 0, should I expect the external display to be oriented correctly? (I get half a display, rotated incorrectly) http://i.imgur.com/S5WckVx.jpg & http://i.imgur.com/xQRZtRS.jpg
<greyback_> popey: it won't install correctly on a newish image any more. we're not maintaining it any more
<greyback_> are trying to land all the code instead
<pixelr0> popey, do you mind if i use your pics for karma?
<alan_g> greyback_: does this (unimplemented) API work for you? https://code.launchpad.net/~alan-griffiths/mir/MirBlob/+merge/269949
<pixelr0> popey, this one is nice! http://i.imgur.com/xQRZtRS.jpg
<greyback_> alan_g: it allows saves/restores a single DispConf. I presume I can have multiples of these saves, yes? (so save different configs with different monitors)
<alan_g> As many as you like
<greyback_> then it should do the job nicely
<alan_g> But not per monitor, per configuration
<popey> greyback_: ah, okay
<popey> pixelr0: sure
<pixelr0> popey, thanks ;D
<alan_g> And, of course, if the hardware has changed the configuration may no longer make sense,
<greyback_> alan_g: yeah, which is why I need to save a configuration per hardware config
<greyback_> to do that, I need unique identifier for each display hardware (EDID maybe)
 * alan_g senses scope creep. ;)
<greyback_> and then save something like: ((EDID1, EDID2), MirBlob1), (EDID1, MirBlob2)...
<greyback_> sure, but there's no point making something which will be thrown away when the scope increases
<alan_g> Sure, but we can deliver some value with the blob slice and consider hardware IDs as the next "user story".
<alan_g> greyback_: do you really want to identify specific hardware? If an alternative monitor can support the same mode does the user care?
<greyback_> alan_g: if Ishare my laptop with 2 different external monitors, and configure each one differently, I'd like those configurations to be saved
<greyback_> but this is solving future problems we've not decided we have yet
<greyback_> dunno if this relevant, but when I see Blob in a linux context, I immediately think of binary blobs and proprietary stuff
<alan_g> If I plug in a projector wherever I'm visiting I'd like my "usual" projector config to be chosen. Not the hardware defaults.
<alan_g> Got a better name?
<greyback_> alan_g: not really, and it is used in database context a lot
<greyback_> will do, ignore me & carry on
<alan_g> MirSerializedData
<greyback_> alf_: hey, I've query about DisplayBuffers and the nested platform. On android, for a nested server, when I plug in external monitor, I get notification displayconfig has changed, but I don't appear to be getting a new DisplayBuffer for that external display.
<greyback_> should I definitely be getting a displaybuffer for newly added displays, or do I need to do something?
<greyback_> if I start the server with the external monitor connected, I get display buffer for both, which is correct
 * alan_g spies a missing acceptance test
<greyback_> it might be more a kdub question, since it's an android thing
<kdub> so the nested server doesnt get another display buffer?
<kdub> from the above description, i'd guess this would happen on mesa too
<greyback_> kdub: that's how it appears to me. The new display doesn't get a new displaybuffer.
<greyback_> will check mesa
<alf_> greyback_: Does the configuration policy enable that second monitor?
<greyback_> alf_: I think so: http://bazaar.launchpad.net/~gerboland/qtmir/multimonitor/view/head:/src/platforms/mirserver/tileddisplayconfigurationpolicy.cpp
<greyback_> I'm just tweaking the default display config to have displays side-by-side
<greyback_> works if I start nested server with both displays connected anyway
<greyback_> only if I start without external display, then plug it in, do I get this issue
<alf_> greyback_: Can you verify that output.used is set for both displays when your tiled config runs?
<greyback_> alf_: ack
<alf_> greyback_: (I mean after the wrapped policy is applied)
<greyback_> yep
<greyback_> kdub: alf_: yeah I can repro on mesa also
<greyback_> alf_: I'm not seeing my display config policy being consulted at all as a nested server after startup
<greyback_> it is if I run as host server tho
<alf_> greyback_: that's a problem :)
<greyback_> alf_: could this happen: plug in external monitor: client gets displayConfigChange with output: *not* used. Then after host server gets ready, another displayConfigChange event with output: used
<greyback_> because host server needs time to prepare the new display. So 2 separate events
<greyback_> nope, just checked, that's not happening
<alf_> greyback_: right, so in this setup the host server will wait for the nested server to tell it what to do when a configuration change happens (since it is focused and has set per-session/custom configuration)
<greyback_> alf_: so I suppose it should consult the nested server's display config policy
<alf_> greyback_: I am going through the nested code, but everything seems in order, not sure why the policy is not used in your case
<greyback_> alf_: I logged bug https://bugs.launchpad.net/mir/+bug/1491816
<ubot5> Ubuntu bug 1491816 in Mir "[nested server] plug in monitor, display config change fires, but no DisplayBuffer ready for that new display" [Undecided,New]
<greyback_> alf_: perhaps I've forgot to do something in my code?
<alf_> greyback_: your code looks fine too
<alf_> greyback_: Let me try to reproduce locally with Mesa and demo servers and I will get back to you
<greyback_> thanks
<greyback_> alf_: dunno if relevant, but I was testing with host mir server with --display-config=sidebyside set
<alf_> greyback_: With the exception of some mouse cursor issues, demo servers work as expected (using mir_demo_server from lp:mir though, not mir_proving_server from ??)
<greyback_> alf_: hmm, lemme try that
<greyback_> alf_: no change here
<alf_> greyback_: at which point do you expect a display buffer to exist?
<greyback_> alf_: in the callback fired when the DisplayConfiguration changes
<alf_> greyback_: which callback is that?
<greyback_> Display::register_configuration_change_handler
<alf_> greyback_: you shouldn't touch that :)
<alf_> greyback_: that's a notification that the hardware configuration has changed
<alf_> greyback_: and the default handler is what takes that new configuration and applies policy etc in a safe way
<greyback_> alf_: it doesn't support registering multiple change handlers??
<greyback_> come on
<alf_> greyback_: no, but that's not the point. "This is not the callback you are looking for" (probably)
<alf_> greyback_: I say probably because I am not sure what's needed for qt integration...
<alf_> greyback_: quick hangout so I can understand the architecture?
<greyback_> alf_: sure, 1 sec
<alan_g> greyback_: WindowManager::add_display()?
<greyback_> alan_g: possibly
<greyback_> alf_: ok, removing that fixes my problem
<alf_> greyback_: great
<alf_> greyback_: are you able to use compositor start/stop?
<greyback_> yeah
 * alan_g finds another bug in the configure_display() logic: the server replies with the "active configuration" without having waited for changes to take effect (on another thread),
<bregma> Saviq, do you know what is the status of the branch-synch problem kgunn was working on yesterday?
<Saviq> bregma, in silo
<Saviq> silo 14
<Saviq> bregma, so mir an usc needs to be there as well, or can they get there later/
<Saviq> ?
<Saviq> (there - in a silo)
<bregma> should be OK to put no-change rebuilds in there now, but I'll ask at the Mir standup in a few minutes to make sure
<Saviq> kk
<bregma> Saviq, can we add https://code.launchpad.net/~mir-team/mir/released-rebuild-for-vivid-overlay/+merge/269918 to landing-014 for a start?
<Saviq> bregma, any word?
<bregma> Saviq, I think we need to add https://code.launchpad.net/~mir-team/mir/released-rebuild-for-vivid-overlay/+merge/269918 to landing-014 for a start, and another MP for u-s-c
<bregma> https://code.launchpad.net/~mir-team/unity-system-compositor/no-change-rebuild-mir-0.15.1/+merge/269102
<bregma> just put them in silo 14 and rebuild -- shall I do it?
<Saviq> bregma, please do
<Saviq> bregma, note the silo is dual
<Saviq> but your MPs look fine for that
#ubuntu-mir 2015-09-04
<Saviq> hey all, have there been any changes to u-s-c recently that you think could cause bug #1491566 ?
<ubot5> bug 1491566 in unity8 (Ubuntu) "Greeter and edges not responsive after an incoming SMS" [Critical,Confirmed] https://launchpad.net/bugs/1491566
<Saviq> it's as if unity8 stopped getting input altogether, but is not stuck
<Saviq> hmm folks, resyncing vivid+overlay and wily for mir means upgrading overlay to mir 0.15.1, is that desired?
<RAOF> I believe that's the poison we've chosen, yes.
<Saviq> ok so Mir's test plan added
<alan_g> duflu: alf_ are there enough eyes on the CI failures yet? Or should I take a look?
<duflu> alan_g: I've got the ClientLatency issues under control. No idea about clang
<alf_> alan_g: I haven't made any progress on the clang threadsanitizer job, can't reproduce. I am very tempted to just disable the job.
<alan_g> alf_: I'll take a look (in half an hour or so). If I can't find anything quickly let's disable it to unblock CI.
<alf_> alan_g: ack
<Saviq> hey guys, can you please help me get silo 14 into a valid state, now that it includes a mir 0.15.1 upgrade into vivid/overlay, we need to rebuild a few bits in there, too, I imagine?
<Saviq> like qtubuntu, maybe gtk since we missed its upgrade to 0.14
<Saviq> seems mirclient didn't change, just mirserver and mirplatform got a bump
<Saviq> anpok, seeing as you released 0.15 into wily originally, can you comment â?
<alan_g> Saviq: mirclient in 0.15 is ABI compatible to 0.14, so it should only be servers that need rebuilding. Not sure what your gtk comment is about - I thought it was updated with 0.14.
<anpok> Saviq: 0.14 ..
<Saviq> alan_g, yeah, that's the problem, it got "lost" somewhere, and gtk in vivid overlay depends on mirclient8 still
<anpok> alan_g: it wasnt copied for some reason to the ppa
<alan_g> alf_: having trouble building TS (on my vivid+some of overlay laptop) - sorry for the delay
<alan_g> anpok: you OK to sort this?
<alf_> alan_g: np, can I help in some way?
<alan_g> alf_: dunno, somehow I'm getting multiple pthreads definitions... gonna nuke some directories
<anpok> Saviq, alan_g: lunch - will look for the 3.14 branch with the neessary patches..
<Saviq> anpok, kk, I'm rebuilding qtmir in the mean time, will you be able to help with testing vivid+overlay with the new mir?
<Saviq> we'll test the unity8 part for both vivid and wily
<dandrader> alf_, how do I change the environment where u-s-c is run?
<alf_> dandrader: On the phone?
<dandrader> alf_, yes
<alan_g> alf_: built OK - but I'm seeing failure in UnresponsiveClient.does_not_hang_server :(
<alf_> alan_g: could that be because of a timeout being too short for running under ThreadSanitizer?
<alf_> alan_g: (just a wild guess)
<alan_g> They are all wild at the moment. :(
<alan_g> alf_: nm that test is excluded in CMake
<dandrader> alf_, so..? :)
<alf_> dandrader: looking, but things seem to have changed from last time I looked (which was long ago)
<dandrader> :(
<alf_> dandrader: ok, I think what you are looking for is /usr/share/ubuntu-touch-session/usc-wrapper
<alf_> dandrader: edit that to export any env. variables you want
<alf_> dandrader: (or add args to usc invocation)
<dandrader> alf_, excellent! thanks!
<alf_> dandrader: np, let me know if it works :)
<dandrader> it should. I recall having played with this file for this same purpose ages ago :)
<dandrader> I mean, now I recall
<Saviq> anpok, hey, any news?
<anpok> Saviq: looking now..
<anpok> silo-014 is a dual landing silo
<anpok> ok so no source package iirc
<Saviq> anpok, I believe we can do it with a source package no problem
<Saviq> still the train staff will have to upload it for us
<Saviq> and since gtk is not a train-driven package, likely the only way?
<anpok> iirc dual landing silos dont mix with source package silos..
<anpok> at least thats what added another level of fun to the 0.14 release
<Saviq> anpok, ah hmm, that might be, maybe we can land gtk separately, after, then?
<alan_g> alf: kdub I think we should go ahead, disable the test (and add a card for re-enabling it).
 * kdub is inclined to agree
<kdub> I havent had much luck getting it to fail in the same way
<alf_> alan_g: I agree, should I notify the CI team?
<alan_g> alf_: please do
 * alan_g gets segfault to happen in the debugger
 * alf_ managed to confuse the CI team and they disabled mir-ci/autolanding instead of only the clang-ts job
<alan_g> LOL
<anpok> Saviq: a silo for gtk-3-14 to vivid with the package from back then is available.. but also a new upstream version with the updated mir backend is on vivid-proposed
<anpok> yeah that will silence all the noise
<Saviq> anpok, ok, I saw you sorting it out with Mirv in #ubuntu-ci-eng, so we can go ahead and start testing silo 14 if I'm not mistaken/
<Saviq> ?
<anpok> yes gtk will be solved by the other silo 021 or by itself if the updated one makes it into vivid itself
<Saviq> bregma, mzanetti, so AFAICT silo 14 is good for testing now
<Saviq> can we split the effort? /me not up for testing a Mir release yet
 * mzanetti neither
<mzanetti> can do unity stuff
 * Saviq for wily
<mzanetti> ack, vivid here
<bregma> I'm a little concerned about unity-system-compositor; there may be issues, we'll see how that works out
<Saviq> bregma, wily is a no-change rebuild for mir, so mir@vivid is the important bit
<bregma> I'll set up to test on each serially, but it may take a while I'm new to testing Mir
<Saviq> bregma, u-s-c is a no-change rebuild into both, so should be fine in theoruy
<Saviq> -u
<bregma> well, it's gone complicated because it looks like theyve forked between wily and the overlay, I need an explanation
<Saviq> bregma, u-s-c? not AFAICT?
<Saviq> bregma, here's a merge of lp:u-s-c/wily into lp:u-s-c https://code.launchpad.net/~mir-team/unity-system-compositor/no-change-rebuild-mir-0.15.1/+merge/269102
<Saviq> bregma, just changelog diffs
<bregma> Saviq, did you rebuild the silo after updating that MP?
<Saviq> bregma, it wouldn't build otherwise
<bregma> exactly
<Saviq> bregma, but that's just because of the missing changelog version
<mzanetti> Saviq, confirming that yday's issue is gone. doing more testing now
<bregma> yeah, I didn;t follow up after the build failed because my attention got diverted elsewhere, thanks for updating
<Saviq> bregma, so I now updated the changelogs and it's built in the silo for both vivid and wily, but both are no-change rebuilds afaict
<Saviq> yeah, it must be so, because that diff is merging into lp:u-s-c/ubuntu
<kdub> anpok, is it sane to set all the mac's to zero for qtcompatibility thusly? : https://code.launchpad.net/~kdub/qtmir/mir-mac-compatibility/+merge/270185
<anpok> for now - yes since attestable-timestamps is still in review
<kdub> anpok, alright, should be good enough for testing then, thanks
<alan_g> alf_: I think that the tsan problem is just the process overloading the poor little VM in CI. Running it a while on my laptop started chewing up memory - it go so I could only run terminal tasks.
<fginther> kdub, https://code.launchpad.net/~alan-griffiths/mir/configurable-DisplayConfigurationReport/+merge/269786 and https://code.launchpad.net/~kdub/mir/plumb-resizing/+merge/269093 failed (or will fail soon) to merge because one of the jenkins slaves ran out of space. May I re-approve them?
<kdub> fginther, sure
<kdub> thanks!
#ubuntu-mir 2016-09-05
<duflu> alan_g: Hey I only just discovered DisplayReport, which I had partially duplicated. Would anyone complain if I changed the default to be for every vsync instead of summarised per second?
<RAOF> duflu: I'm +1 on that.
<duflu> I'm guessing not. No one other than us would be using it
<alan_g> duflu: I doubt anyone else uses it. An alternative is to add multiple reporting options.
<alan_g> RAOF: do you want me to split this into two MPs? https://code.launchpad.net/~alan-griffiths/miral/hide-streams-from-Window-Management-API/+merge/304626
<RAOF> alan_g: Commented on MP.
<alan_g> RAOF: thanks. I'll split it to separate the discussion. (Not just here, but we really need to get some clarity around the distinction between "WM", "Shell" and "Compositor")
<alan_g> I'm just going with "adding later doesn't break ABI"
<alan_g> duflu: do you remember when/how we could remove this hack? https://code.launchpad.net/~vanvugt/mir/fix-1391976/+merge/262678?
<duflu> alan_g: bzr blame will tell you where it got removed
<duflu> If you specify a source file and look at the relevant lines
<duflu> Which means I don't remember
<duflu> It might have been Alberto's switch to protobuf-lite
<alan_g> duflu: yes. I don't remember either.
<alan_g> I don't think it was that - the problem comes back with protobuf3 - so I was wondering if we patched protobuf. I'll have to dig it over.
 * alan_g thinks alf_  went looking at the protobuf code. But he's "away".
<alan_g> And "blame" isn't so good at when lines were deleted.
<duflu> alan_g: Yes r2798
<duflu> bzr blame is broken but I found it anyway
<duflu> bzr log <specific source file> sometimes works and did in this case
<alan_g> thanks
 * duflu is still in the school of "if you need it to keep working into the future write it yourself and don't rely on 3rd party code"
<duflu> Because in the worst case you have no blocker to fixing any issues
<alan_g> So, write everything from scratch?
<duflu> Well not "everything" :)
<duflu> But protocol code I would have
#ubuntu-mir 2016-09-06
<alan_g> RAOF: I guess you've an opinion on this: https://code.launchpad.net/~alan-griffiths/miral/remove-properties-WM-ignores/+merge/304906
<RAOF> alan_g: Eh, it doesn't break ABI to add it in later.
<alan_g> True
<alan_g> So you're OK with it.
<RAOF> Yup.
<alan_g> thanks
#ubuntu-mir 2016-09-07
<duflu> anpok_: I'm inspired now. Going to try attacking the cursor freezes with some real-time profiling
<duflu> anpok_: Umm... the bug isn't happening for me any more (!?)
<alan_g> bugs that bite and run away live to bite another day
<anpok_> duflu: I do see pauses in traces .. combined with batching those pauses get larger..
<anpok_> it seems as if the multiplexing dispatchable driving the input thread is not woken up..
<duflu> anpok_: Sure yes in traces. But I can't "see" it any more
<zzarr> just a quick question does Mir work with any MESA driver?
<anpok_> zzarr: there are two groups of mesa drivers
<anpok_> those that are gallium based and the original mesa drivers
<anpok_> from the second set .. I only have seen people use the intel mesa drivers..
<anpok_> this is relevant because we rely on the capability to import dmabuf fds
<anpok_> intel originally hat bugs in that area.. because mir was more or less the main user of that feature
<zzarr> so it would not work with a MESA driver for an ARM based SoC?
<alan_g> zzarr: no. there's some Mir support patches needed. So you need the Ubuntu version or to pick up the patches another way.
<anpok_> all mesa drivers for arm socs are gallium based
<zzarr> okey
<anpok_> so it should work.. with ubuntu patches for mesa.
<alan_g> There's a link in my latest "voices" post
<zzarr> will Mir support Gallium based MESA drivers in the future?
<zzarr> ohh, it could work now with patches?
<alan_g> The intention is to rework and upstream the patches. But we can't promise a timeline.
<anpok_> zzarr: gallium based drivers work fine..
<anpok_> no patches requires in the gallium drivers iirc .. we only have to add code to integrate with egl
<alan_g> http://voices.canonical.com/alan.griffiths/ - look for "enabling Mir EGL"
<zzarr> If I understood correctly... Mir works with the Gallium based MESA driver if patched
<anpok_> yes
<anpok_> zzarr: based on your original question I extrapolated a more exotic hardware
<zzarr> thanks, that's great
<greyback> alan_g: hey, I'm in a situation where for every miral::Window, I need to associate a PersistentId from StubPersistentSurfaceStore - do you think the persistentId makes sense to add to miral::WindowInfo?
<greyback> it might be handy for a window manager to use it to identify a surface to give it special behaviour
<alan_g> greyback: what is it needed for? The usecase that we knew about is covered by WindowManagerTools::info_for_window_id
<alan_g> Nobody had a usecase where the WM wanted to get an ID from a surface
<greyback> alan_g: use-case is dbus-menus, and is more shell-specific. https://code.launchpad.net/~unity-team/qtmir/persistent_surface_id/+merge/303580 is giving each surface a persistentId, that it uses as unique identifier to find its dbus-menus
<greyback> this is my implementation so far: lp:~gerboland/miral/qtmir-555
<greyback> which is neater, it associates a persistentId to the surface as soon as possible, and passes it along with the other WindowInfo
<greyback> see "qtmir::NewWindowInfo"
<alan_g> I'm reluctant to impose "every surface has an ID" because one user finds it convenient.
 * alan_g wishes for more downstreams that will fight each other over features
<greyback> :)
<greyback> I don't have a strong opinion on it
<greyback> I just made my implementation, and noticed the proposal might clean it up a little more
<alan_g> I still wonder if this is a problem persistent IDs are meant to solve. I mean, no-one has created a *persistent* store of them, and this seems like an unintended usage.
<greyback> alan_g: I agree it is incorrect usage if the classes was indeed persistent, but it's not, in which case it is doing what is needed
<alan_g> greyback: do you think dbus menus should be directly supported in miral?
<greyback> alan_g: nope
<alan_g> Wouldn't other shells also want them?
<greyback> they might, and they might not. I cannot predict that
<greyback> as you say, having a single downstream doesn't make it easy to identify features miral should support
<alan_g> I just think runner.run_with(DbusMenus{}) would make exposing "persistent" IDs irrelevent.
<kdub> hmm, we could fix http://bazaar.launchpad.net/~mir-team/mir/development-branch/view/head:/include/common/mir_toolkit/mir_native_buffer.h#L51 with the mir_buffer.h api
<greyback> alan_g: dbus menus are the only reason 'persistent'IDs are being used. But I am not familar enough with dbus menus to know what features they provide, so I don't know how complex that task would be
<greyback> dednick would be the man to ask, but he's on holidays for 1.5 weeks
<alan_g> For the moment I think WindowManagerTools::id_for_window() is less intrusive
<greyback> agreed
<alan_g> miral::DbusMenus only needs to support an abstraction over what you're wiring up
<alan_g> And previous discussions have all said its the only "de-facto standard" around
<RAOF> FWIW, I think PersistentSurfaceIDs are perfectly fine to use as our default cross-process-capable surface identifiers.
#ubuntu-mir 2016-09-08
<duflu> robert_ancell: Only coding style? :)
<robert_ancell> duflu, that was the easy changes..
<duflu> I expect more complaints. So many more that I would not recommend upstreaming right now
<robert_ancell> duflu, I have a simplified branch that I'm trying to propose. It removes as much as possible to get a first step
<duflu> robert_ancell: If you mean removing dri2 I would like to do that but it's critical to keep on desktop
<robert_ancell> duflu, yeah, it's just software support
<duflu> robert_ancell: Yeah please don't bother. Real desktops need the dri2 backend
<robert_ancell> duflu, it's worth us having a smaller delta
<duflu> robert_ancell: Well, if you're working in a separate branch then sure. Don't want to cripple the main one is all
<robert_ancell> duflu, it's a separate branch
<duflu> Ugh, same problems with Mesa. We really don't want to upstream egl-platform-mir with the open bugs we know about
<duflu> Although that's less severe. Not really blocking I guess
<RAOF> No, we don't want to upstream egl-platform-mir because we're about to completely rewrite it.
<RAOF> From the interface up.
<RAOF> Bugs are fine when submitting upstream; knowing that you're about to change the whole platform is not.
<duflu> RAOF: That's worse. At least now it's stable and mature-ish. If we rewrite it we won't have the same confidence and definitely can't upstream any time soon
<RAOF> We don't want to upstream mature code.
<duflu> But maybe soon is not a requirement
<RAOF> We want to upstream code that we *want* to mature.
<RAOF> Ideally we should be upstreaming code *well* before its mature.
<duflu> Fair point. Trunk isn't a place for maturation
<RAOF> Also, upstreaming is highly likely to involve changes.
<RAOF> Possibly significant ones.
<RAOF> âUpstreamingâ is almost never âhere is this perfectly fine code ready to just drop without changes into your projectâ. Although, because we're awesome, that totally applies to the Mir EGL platform :)
<duflu> RAOF: Can you add any more bugs detailing what's missing to: https://bugs.launchpad.net/ubuntu/+source/mesa/+bugs?field.tag=egl-platform-mir
<RAOF> Huh. Why do you want EGL_SWAP_BEHAVIOUR_PRESERVED?
<RAOF> That's guaranteed to be slow.
<duflu> RAOF: I know... but Xmir. Either that or single buffering
<duflu> Xmir dri/glx copy sub-buffer stuff
<RAOF> Why do you need it?
<RAOF> Ah.
<RAOF> That stupid idea :)
<duflu> Yep. And the apps already exist
<RAOF> You can implement it just as efficiently in Xmir, you know.
<duflu> RAOF: I know and I tried. Failed so far for reasons... not entirely clear
<duflu> Probably the same reasons why our src/dest FBOs are wrong (the stuttering)
<duflu> At a guess
<duflu> Single buffering would actually be most appropriate and have no performance penalty either
<RAOF> Well, you can do that with MirPresentationChain.
<RAOF> Indeed, that solves all your problems.
<RAOF> Mostly.
<duflu> It's not a massive issue right now as offenders are (confusingly) copying sub-buffers that are the whole window
<TheKit> is Intel GPU currently not supported by Mir?
<duflu> TheKit: Intel GPUs are better supported than any other :)
<duflu> Have been for several years
<TheKit> ah, ok, thanks
<duflu> Hmm, actually that might be another Xmir bug
<RAOF> MirPresentationChain would make it very nearly easy to implement DRI3.
<RAOF> And then you could ignore all the DRI2 madness.
<duflu> OK, sounds good.
<RAOF> (We'd need to add a MirBuffer constructor that took an fd, but that's easy)
<RAOF> *
<alan_g> greyback: just to alert you, the miral-qt stuff needs some tweaks for yakkety (unity-shell-application) and for mir trunk (new DisplayConfiguration fields).
#ubuntu-mir 2016-09-09
<alan_g> greyback: did you overlook this? It should be easy: https://code.launchpad.net/~gerboland/miral/qtmir-556/+merge/305113/comments/789043
<greyback> alan_g: yes I did, will fix
<alan_g> kdub: you've been shuffling GL stuff about? Any thoughts on what this might be? https://bugs.launchpad.net/miral/+bug/1621917
<ubot5> Ubuntu bug 1621917 in MirAL "tests fail when built against lp:mir" [High,Triaged]
<kdub> alan_g, that bit of code did change recently, but iirc, the stubdisplaybuffer should be a gl render target
<alan_g> Well, it isn't. Thanks.
#ubuntu-mir 2016-09-11
<Elleo> does anyone know what controls an app's ability to go fullscreen under confinement? I have an SDL app that goes fullscreen fine when run unconfined from the command line, but doesn't when installed as a click package
<Elleo> and there's no apparmor denials or anything
<Elleo> using mir_surface_set_state to go fullscreen
<RAOF> Elleo: That's very curious.
<RAOF> Elleo: I didn't think any Mir API interacted with confinement at all.
<Elleo> RAOF: yeah, I wasn't expecting any difference; but as soon as I run it from inside a click package it stops going to fullscreen :/
<Elleo> RAOF: I know that some other SDL based apps are managing it fine though (like neverball), so there must be something simple I'm missing
<RAOF> They might be doing it on surface creation, rather than creating a surface and then calling mir_surface_set_state?
<RAOF> Also: plausibly using mir_surface_spec_set_fullscreen_on_output?
<RAOF> Oh!
<RAOF> Or just asking SDL to set fullscreen state? :)
<Elleo> RAOF: nope, turns out I'm an idiot :P
<Elleo> RAOF: I'd forgotten to update the launch lines in the desktop files to include the fullscreen switch
<RAOF> Heh
#ubuntu-mir 2017-09-07
<alan_g> xnox: did you ever find an example of changing binary package versions? My attempt at the incantation isn't quite working: https://code.launchpad.net/~alan-griffiths/mir/move-miral-to-mir-no-more-miral-packages/+merge/329993
<xnox> alan_g, ah, yes. i'm so sorry totally slipped my plate. Something like: include /usr/share/dpkg/default.mk; override_dh_gencontrol: dh_gencontrol -p libmiral2 -- -v1.5$(DEB_VERSION); dh_gencontrol -> should do it. But let me try it on your branch and provide a usable debdiff.
<xnox> alan_g, fixing your code, almost right.
<xnox> alan_g, it FTBFS for me =/ but things to change are like this http://paste.ubuntu.com/25483395/
<xnox> basically by default dh_* commands act on all packages. If one wants something special to be done, one can call a dh_* -ppackage to do things for a given package specially, and then subsequent naked dh_* call will process all remaining / other packages.
<xnox> alan_g, is there some ppa or release i need to build this in? seems to fail to build from source on artful for me.
<xnox> and i think we will need to tweak libmiral2's shlibs thing too.
 * xnox tries to build in zesty
<alan_g> xnox: there shouldn't be
<alan_g> Was working for me yesterday (apart from the packaging)
<xnox> ack maybe new toolchain in artful-proposed is breaking things.
<alan_g> xnox: OK, I'll check latest artful and try your changes
<xnox> alan_g, well the zesty build is going further. And I will get to see if these blind changes are right or not =) plus i do think one more thing will be needed to tweak shlibs.
<xnox> ah, should have done a no-check build
<alan_g> Build on artful seems fine
<xnox> alan_g, but my code is still wrong =)
<alan_g> xnox: nm, just give me the right code. 8^)
<xnox> yeah fixing.
<xnox> and triggering a clean rebuild to retest.
<alan_g> xnox: no luck?
<xnox> alan_g, i think i'm getting as far as you did - it build, but produces the wrong version number.
<xnox> but also getting interrupted with other more urgent things.
<alan_g> :)
#ubuntu-mir 2017-09-08
<xnox> huh, looks like i am very wrong about the order of gencontrol stuff.
 * xnox is confused, let's see if this works.
<alan_g> xnox: I got some help from RAOF and I think I figured out the last bit. Just checking locally and with updated MP in CI.
<Saviq> alan_g: where do miral-{app,desktop} live in the new packages? should I be able to get them from the staging ppa without installing miral-examples?
<alan_g> they went to mir-demos
<alan_g> At least, that's what I'm trying to land
<Saviq> ack, so not in staging yet
<alan_g> Saviq: staging hasn't updated successfully for a while.
<xnox> dpkg-deb: building package 'libmiral2' in '../libmiral2_1.5.0.1.0.0-0ubuntu1_amd64.deb'. -> ah i'm happy now =)
<alan_g> I *think* its broken by introducing the epoch, but haven't checked yet
<xnox> alan_g, i'm going non-epoch route, still.
<xnox> alan_g, quick question you have @MIRAL_1.5.0 symbols, yet they declare that a minimum version of miral that is required is '1.0.0' is that true?
<xnox> alan_g, my understanding is taht if something uses for example "miral::pre_init(miral::CommandLineOption const&)@MIRAL_1.5.0" it needs 1.5.0 minimum version, not 1.0.0?
<xnox> alan_g, here is my final diff that builds fine and has everything correct http://paste.ubuntu.com/25489348/
<xnox> reduced number of variables by using standard variables from /usr/share/dpkg/default.mk
<xnox> the libmiral2 version is now the (MIRAL triplet).(full debian/changelog version)
<alan_g> xnox: Agreed. I think I've now got the incantations I need to make that happen.
<xnox> and that is used to create libmiral2 package, and generate the dependency on the libmirserver-dev
<xnox> -rw-r--r--    1 root root     47650 Sep  8 11:58 libmirclient-dev_1.0.0-0ubuntu1_amd64.deb
<xnox> -rw-r--r--    1 root root    119050 Sep  8 11:58 libmiral2_1.5.0.1.0.0-0ubuntu1_amd64.deb
<xnox> note the version numbers
<alan_g> You want libmiral2_1.5.0.1.0.0-0ubuntu1_amd64, not libmiral2_1.5.0-0ubuntu1_amd64?
<xnox> yes.
<xnox> alan_g, because all package builds must be unique. one is not allowed to produce 1.5.0-0ubuntu1 twice.
<xnox> which is possible when src:mir debian/changelog version number is 1.0.1-0ubuntu1
<alan_g> Got it
<xnox> and i do think the .symbols files are a bit odd. the bit after the space should indicate when the symbol got introduced and thus set the minimum library version requirement. E.g. such that if something only uses 1.0 symbols the minimum dep is >= 1.0; but if something uses one 1.3 symbol, the dep should become >= 1.3; etc.
<xnox> however, i guess this is not high-priority to fix, given there is nothing in the artful archive left that links against libmiral2 =)
<xnox> alan_g, does my diff make sense to you? and i'm _not_ using epoch in the debian/changelog.
<alan_g> xnox: I got the symbols stuff sorted out too: https://code.launchpad.net/~alan-griffiths/mir/move-miral-to-mir-no-more-miral-packages/+merge/329993
<xnox> ooooh, i'm missing loads of commits from your branch.
<xnox> i should review that.
<xnox> yeah ths makeshlibs looks nice.
<alan_g> xnox: the MP has the version wrong as discussed above.
<xnox> do you want me to retweak it?
<xnox> everything looks really good though.
<alan_g> xnox: No, I know how to fix that. But RAOF has a point about not killing libmiral-dev
<xnox> it is true that you either need to keep libmiral-dev or you should provide the "dummy transitional package" that is called libmiral-dev and simply depends on the libmirserver-dev
<xnox> under normal packaging cercumstances.
<xnox> under normal packaging circumstances.
<xnox> however the breaks/replaces/provides should be good enough too.
<alan_g> AIUI its good for packaging, but for maintaining downstreams it is better to keep separate.
<alan_g> AIUI it's good for packaging, but for maintaining downstreams it is better to keep separate.
<alan_g> Anyway, I'll tweak it after lunch.
<alan_g> xnox: RAOF thanks a lot for the help! You're better informed than the manpages.
<xnox> alan_g,  e.g. something like http://paste.ubuntu.com/25489403/
<alan_g> xnox: are you content with this version? https://code.launchpad.net/~alan-griffiths/mir/move-miral-to-mir-no-more-miral-packages/+merge/330433
<xnox> amlost
<xnox> i do not see in the diff changes in debian/control which should make libmiral-dev depend on libmiral2 (= ${libmiral2:Version}) or some such
<xnox> hmmmm.
<xnox> let me check things, i think binary:Version may expand to something funky, hopefully not.
<alan_g> xnox: weird, I seem to have lost the changes to control while arguing with bzr/lp. Let me check.
<alan_g> xnox: I've pushed what I think the changes were. Sadly bzr seems confused about them.
<xnox> alan_g, i'm not sure if you would still need something like this - http://paste.ubuntu.com/25491262/
<xnox> will do a build of just what's in your branch; and with that patch; and will check if that makes any difference or not
<alan_g> xnox: well, what I have now doesn't work, and that looks right...
 * alan_g has to go...
