[00:00] <RAOF> Well, it certainly needs to be notified when the display configuration changes, yes.
[00:02] <RAOF> It does not expect to immediately reply to that notification, though.
[00:02] <kdub> right
[00:03] <kdub> the message could be ignored if nothing in the x-world cares about the display change
[00:04] <RAOF> X *might* want to keep a copy of the display configuration internally, and update it on that signal.
[00:05] <RAOF> But it might just be easier to forward configuration state probes all the way down to Mir.
[00:06] <kdub> so if mir can notify x of changes to the physical displays (along with the info associated with the change)
[00:07] <kdub> and mir can service a configuration request at any time
[00:07] <kdub> sounds like that would be good enough
[00:08] <RAOF> X also wants to be notified of non-physical display changes. Basically, any time the display configuration changes - either because the hardware has changed, or because the resolution has changed, or whatnot - X wants to be notified.
[00:09] <RAOF> But yeah. Notification when the configuration changes plus the ability to get the current configuration at any time is enough for X.
[00:09] <kdub> well, i guess by 'physical' i meant 'the displays, and all properties associated, like resolution'
[00:09] <kdub> right
[01:49] <TheDrums> There was an email sent with results of people testing XMir, and one that came in late with an Intel card (Intel Corporation 82845G/GL[Brookdale-G]/GE) came up with http://paste.openstack.org/show/40176 still.
[02:33] <RAOF> TheDrums: Oooh, that's a shiny new error.
[02:34] <RAOF> That would be a ‘Your GPU is too old to support Mir’ type error, though.
[02:39] <duflu> TheDrums, RAOF: I was thinking about this only a few hours ago. It should be perfectly possible to enhance gl_renderer to switch to a more compatible compositing method (i.e. no GLSL). That's what Compiz and Unity do today. I'm not aware of any significant technical hurdles
[02:39] <duflu> Do we have a bug yet?
[02:39] <duflu> :)
[02:39] <RAOF> duflu: That's not a “I failed to get GLSL” style thing, that's an “I can't create ARGB EGL surfaces” type thing.
[02:40] <duflu> RAOF: Sure, but they're both solvable problems
[02:40] <RAOF> Failure to create ARGB surfaces will be pretty hard to solve.
[02:40] <duflu> And both likely to occur on similar systems
[02:41] <RAOF> How would you work around a lack of alpha channel?
[02:43] <duflu> RAOF: Either ignore alpha as a fallback ugly mode, or change the surface type, or enhance Mesa
[02:43] <duflu> It's all solvable.
[02:43] <duflu> Some more easily than other parts
[02:44] <duflu> I don't accept we have to impose tougher restrictions on hardware support in Mir than Ubuntu has today.
[02:44] <duflu> It's just "not implemented yet"
[02:45] <RAOF> Fair enough.
[02:45] <duflu> RAOF: Laptop? :)
[02:46]  * duflu is excited for new hardware
[02:46] <RAOF> Not yet shipped.
[02:47] <duflu> Boo
[02:47] <RAOF> Indeed.
[02:47] <RAOF> Soon!
[02:50] <duflu> Has anyone else noticed a second or two delay in mir_demo_server[_shell] starting?
[02:50] <duflu> Any idea why it's not immediate?
[02:58] <RAOF> I don't _think_ I've noticed that?
[02:58] <RAOF> Woo!
[02:58] <RAOF> That *almost* works.
[02:58] <RAOF> Modulo Unity crashing.
[02:58] <RAOF> And unredirected rendering always being done in the top-left corner.
[02:59] <duflu> RAOF: Isn't top-left correct? (unless you have multiple outputs)
[02:59] <RAOF> Not if you're a popup that's meant to go at 1200,230
[03:00] <duflu> RAOF: Oh. That's not unredirected, usually. Unless you're playing with XComposite clients
[03:00] <RAOF> Or don't have a compositor running.
[03:00] <duflu> Oh, of course
[03:00] <RAOF> Which is easy to do, if Unity crashes :)
[03:25] <TheDrums> Heh, wow.  So the answer isn't "Switch distros." after all, interesting.
[03:27] <duflu> TheDrums: Even if support for older hardware is not implemented by 13.10, Ubuntu will still fall back to legacy X where Mir can't start. So long as X works for you now...
[03:28] <TheDrums> Indeed, so I've noticed.
[04:32]  * RAOF has Zoë for an hour or so.
[05:06] <tvoss_> good morning :)
[05:15] <tvoss_> duflu, good morning :)
[05:16] <duflu> tvoss_: Good afternoon
[05:16] <tvoss_> duflu, hello, mind giving https://code.launchpad.net/~thomas-voss/mir/get-rid-of-disable-epoll-flag/+merge/174180 a quick review?
[05:17] <duflu> tvoss_: Shrug, approve.
[05:18] <tvoss_> duflu, the change might reduce spurious wakeups in the frontend threads
[05:18] <duflu> OK. I wasn't aware we had "spurious" wakeups
[05:18] <duflu> But I've never looked too hard
[05:21] <tvoss_> duflu, we introduced the flag to support the ancient kernel in the buildds
[05:21] <tvoss_> duflu, ignoring some of the warnings present in the code :)
[05:21] <tvoss_> thomi, ping
[05:29]  * duflu wonders about the evils of std::shared_ptr<T> a(p), b(p)
[05:31] <tvoss_> RAOF, ping for later when you have time
[05:34] <RAOF> tvoss_: Pong.
[05:35] <thomi> tvoss_: hey
[05:47] <tvoss_> thomi, sorry, might have lost some of your messages
[05:47] <thomi> tvoss_: I just said "hi" :)
[05:47] <thomi> I have the in-laws arriving for dinner any second though, so I can't stick around I'm afraid :-/
[05:48] <tvoss_> thomi, okay, no problem :)
[06:09] <thomi> of course, having said that, they appear to be late...
[06:09] <tvoss_> thomi, of course
[06:33] <duflu> alf__: I think I have a clearer explanation of my buffer problems...
[06:34] <duflu> TemporaryCompositorBuffer is unsafe to put in a shared_ptr because it maintains its own use_count in back_buffer_strategy
[06:35] <duflu> So even after the last shared_ptr is destroyed, the strategy has a refcount of 1 and fails to compositor_release()
[06:43] <dholbach> good morning
[06:43] <alf__> dholbach: Good morning!
[06:44] <dholbach> hi alf__
[06:47] <alf__> duflu: I am not sure I got what you mean... when the shared_ptr holding a TemporaryCompositorBuffer is destroyed, it calls BackBufferStrategy::release() which either releases the buffer or not, depending on whether someone else has acquired the same buffer in the meantime.
[06:47] <duflu> alf__: I'm writing a better explanation...
[06:49] <duflu> alf__: https://bugs.launchpad.net/mir/+bug/1200504
[07:04] <alf__> duflu: what I don't get is how 'a' and 'b' are the same shared_ptr?  mc::BufferStreamSurfaces::lock_back_buffer()
[07:05] <alf__> duflu: returns a new shared_ptr<TemporaryCompositorBuffer> every time
[07:05] <duflu> alf__: It's the same from mc::MultiAcquisitionBackBufferStrategy::acquire
[07:07] <alf__> duflu: it's the same real buffer but wrapped by different TemporaryCompositorBuffer object, so I would expect ~TemporaryCompositorBuffer() to be called when b goes out of scope.
[07:07]  * duflu checks again
[07:10] <duflu> alf__: You make a good point. Bug incomplete for now
[07:11] <alf__> duflu: ok, let me now if I can help you investigate this further
[07:14] <duflu> Ooh. I think I'm alternating shared_ptr's. But because there are always at least one in existence, the underlying buffer is never released properly. And actually that's kind of what I need.
[07:14] <duflu> So maybe I need a special scanout_buffer()
[07:26] <duflu> Ugg. How many internal compiler errors can I hit in one day?
[07:27] <RAOF> All the clangs
[07:28] <RAOF> Builds faster, too ;)
[07:29]  * duflu goes clang
[07:30]  * duflu was sure gcc never sucked so much before
[08:15] <hikiko> hi
[08:18] <hikiko> could you please give me a hand with cmake?
[08:19] <alan_g> tvoss: https://code.launchpad.net/~alan-griffiths/mir/workaround-1200236/+merge/174201
[08:19] <alan_g> hi hikiko, what do you need?
[08:20] <hikiko> I just realized alan_g that what I did yesterday doesn't give any errors because it doesn't compile anything :\
[08:20] <hikiko> I have a directory nested
[08:20] <hikiko> inside src/server/graphics
[08:21] <hikiko> I did add_subdirectory(nested/) in graphics/CMakeLists.txt
[08:21] <hikiko> and in nested/CMakeLists.txt
[08:21] <hikiko> I want to:
[08:21] <hikiko> 1- link with mirclient
[08:22] <hikiko> 2- add the source files
[08:22] <hikiko> 3- maybe(?) build mirplatformgraphics (?) <- not sure at all this is necessary
[08:23] <hikiko> and I have no idea what I am doing so wrong
[08:24] <hikiko> if I add target_link_libraries( mirclient )
[08:24] <hikiko> I get:
[08:24] <hikiko> This typically indicates a problem with your CMakeLists.txt file
[08:24] <hikiko> CMake Warning (dev) at src/server/graphics/nested/CMakeLists.txt:10 (target_link_libraries):
[08:24] <hikiko>   Cannot specify link libraries for target "mirclient" which is not built by
[08:24] <hikiko>   this project.
[08:24] <hikiko> then make shows no errors and doesn't build my source files
[08:25] <tvoss> hikiko, how is your target called?
[08:25] <alan_g> hikiko: you're leaving me to guess where you get a problem. graphics/nested/CMakeLists.txt should be similar to src/server/frontend/CMakeLists.txt with appropriate name changes
[08:26] <alan_g> maybe you can pastebin your graphics/nested/CMakeLists.txt?
[08:26] <hikiko> oh I did something completely different :) I thought target_link_libraries are the libraries you want to link with
[08:26] <hikiko> sure alan_g
[08:26] <hikiko> 1 sec
[08:29] <hikiko> alan_g, http://paste.ubuntu.com/5867495/ that's what I have now (I removed include_directories etc to keep it simple)
[08:30] <alan_g> hikiko: the first parameter to those commands is the library you want to build
[08:31] <hikiko> so I have to add mirplatformgraphics SHARED?
[08:31] <hikiko> or a new one?
[08:31] <alan_g> http://www.cmake.org/cmake/help/cmake_tutorial.html
[08:31] <alan_g> hikiko: you want a new static library that will be linked info mirserver
[08:33] <alan_g> add_library(mirnestedgraphics STATIC ...
[08:33] <alan_g> target_link_libraries(mirnestedgraphics mirclient
[08:36] <hikiko> no :) I did this yesterday, but then I thought what alexandros meant was that I have to remove it and use mirplatformgraphics and since I was getting errors with mirplatformgraphics I totally removed it... :p I can't make myself clear :\ that worked :DD +I got the compile errors back!!! thanks a lot... :)
[08:38] <alan_g> hikiko: that wasn't clear. If you still have a problem, push a branch to ~mir-team (where I can see and fix the problem)
[08:39] <alan_g> hikiko: if you don't have a problem, that's even better
[08:39] <hikiko> no I haven't :) it works :D I just misunderstood something yesterday :) thank you alan_g! :)
[08:40] <alan_g> hikiko: you're welcome
[09:39]  * duflu gives up; goes to dinner
[09:44]  * alf__ is attempting a reboot after 600MB worth of saucy updates...
[10:14] <FernandoMiguel> morning
[10:14] <FernandoMiguel> I assume todays update of ppa on ubuntu 13.10 is broken?
[10:14] <FernandoMiguel> got to boot in safemode
[10:14] <FernandoMiguel> xserver -mir is not a valid option, according to the logs
[10:15] <RAOF> Ah. You've not pinned the PPA as suggested.
[10:15] <RAOF> And someone's uploaded a new Xserver  :)
[10:15] <FernandoMiguel> RAOF: ehe
[10:15] <FernandoMiguel> trying to purge it now
[10:16] <tvoss> FernandoMiguel, pinning the ppa is really a good idea right now :)
[10:16]  * tvoss is doing a reboot, too
[10:16] <RAOF> You should get a shiny new -ati that works on resolutions that aren't 1366x768 and a bonus -intel that uses sna.
[10:17] <FernandoMiguel> good luck tvoss :p
[10:17] <FernandoMiguel> RAOF: all intel DELL here
[10:17] <FernandoMiguel> The following packages will be DOWNGRADED:
[10:17] <FernandoMiguel>   libdrm-intel1 libdrm-nouveau2 libdrm-radeon1 libdrm2 libegl1-mesa libegl1-mesa-drivers libgbm1 libgl1-mesa-dri libgl1-mesa-glx
[10:17] <FernandoMiguel>   libglapi-mesa libgles2-mesa libkms1 liblightdm-gobject-1-0 libopenvg1-mesa libsdl1.2debian libxatracker1 lightdm unity-greeter
[10:17] <FernandoMiguel>   xserver-xorg-video-ati xserver-xorg-video-intel xserver-xorg-video-nouveau xserver-xorg-video-radeon
[10:18] <FernandoMiguel> I had two mouse pointers too
[10:18] <FernandoMiguel> https://bugs.launchpad.net/ubuntu/+source/ubuntu-ui-toolkit/+bug/1200553
[10:18] <FernandoMiguel> guess we can close that one... probably the new X
[10:18] <FernandoMiguel> PPA purged successfully using aptitude fallback
[10:19] <FernandoMiguel> RAOF: that should be enough, no?
[10:19] <RAOF> FernandoMiguel: That should get you back to stock Ubuntu, which should get rid of the second mouse pointer and allow you to start, yes ;)
[10:19] <FernandoMiguel> ok
[10:20] <FernandoMiguel> guess I'll wait for MIR to hit the repos
[10:20] <FernandoMiguel> that was a fun trial
[10:20] <FernandoMiguel> I must say, it is faster
[10:20] <FernandoMiguel> brb
[10:20] <RAOF> People do say that.
[10:20] <FernandoMiguel> reboot
[10:20] <RAOF> I don't really know why!
[10:20] <FernandoMiguel> ofc it could also be from other upgrades
[10:20] <RAOF> Some thing we do must make us feel faster.
[10:20] <FernandoMiguel> but the last version of unity/X before I upgraded to MIR was actually slower than the earlier ones
[10:21] <FernandoMiguel> hence a person notices more the speed bump
[10:21] <RAOF> That could be it :)
[10:21] <FernandoMiguel> I did notice while jumping windows
[10:21] <FernandoMiguel> and expose
[10:21] <FernandoMiguel> multi screen with a 37" 1080p tv also behaved much better than X
[10:21] <FernandoMiguel> brb
[10:23] <FernandoMiguel> FYI it's working
[10:23] <FernandoMiguel> :)
[10:24] <FernandoMiguel> any time table for MIR to hit 13.10 repos?
[10:26] <tvoss_> FernandoMiguel, bugs preventing us from entering universe https://bugs.launchpad.net/mir/+bugs?field.tag=entering-saucy
[10:38] <tvoss_> FernandoMiguel, so yeah, hopefully really soon
[10:39] <FernandoMiguel> cool
[10:43] <RAOF> tvoss_: I'm pretty sure the input delay we're seeing is a missing-damage issue. It's possible that the signal unmunging MP might fix that (fingers crossed!). Failing that, I'll investigate next week.
[10:44] <tvoss_> RAOF, ack ... that's mostly my conclusion, too
[10:44] <tvoss_> RAOF, can we get an updated version into the system-testing ppa today?
[10:45] <RAOF> tvoss_: Sure. Do you want to babysit the copies? All you need to do is copy-with-binaries Mir, and then copy-with-rebuild unity-system-compositor.
[10:45] <tvoss_> RAOF, okay, what about the xserver?
[10:45] <tvoss_> RAOF, or do we just need a new mirclient library?
[10:45] <RAOF> Just a new mirclient library
[10:45] <tvoss_> RAOF, no versioning conflicts, then?
[10:46] <RAOF> There *shouldn't* be.
[10:46]  * tvoss_ wonders if we should break the ppa over the weekend
[10:46] <RAOF> The xserver depends on a (too strict) >= version, so a newer mir won't break that.
[10:47] <tvoss_> RAOF, okay
[10:48] <tvoss_> RAOF, can you trigger the respective copies?
[10:48] <tvoss_> RAOF,  I will watch it building then
[10:56] <mirtestuser> Hi All! I am running Mir (Ubuntu 13.10 + enabled Mir according to Olli's blog post).
[10:57] <tvoss_> mirtestuser, cool :)
[10:57] <mirtestuser> I get the two mouse pointers (hardware and software pointers).
[10:58] <mirtestuser> Typing text feels a big laggish (takes a few moments for the text to appear). Is this a known behaviour?
[11:01] <tvoss_> mirtestuser, yes, that's a known bug: https://bugs.launchpad.net/mir/+bug/1199450
[11:01] <tvoss_> mirtestuser, it turned up after the last update of the ppa and we are working on the fix
[11:03] <tvoss_> mirtestuser, what gpu are you running on?
[11:03] <mirtestuser> (also compiled from the 'mir' repository in order to get the examples, etc)
[11:04] <mirtestuser> tvoss_: thanks. It's AMD/ATI Radeon HD 6320 ( Evergreen).
[11:05] <tvoss_> mirtestuser, cool, I'm running Intel myself
[11:09] <mirtestuser> What Mir examples, etc are available to try out?
[11:10] <tvoss_> mirtestuser, there is not a documented list right now, but if you have built from source, you can find the examples in bin of your build dir
[11:11] <mirtestuser> I am going through those available at mir/build-linux-x86/bin/
[11:12] <mirtestuser> The mir_demo_client* do not run. I get some errors.
[11:12] <RAOF> What errors.
[11:12] <RAOF> ?
[11:13] <mirtestuser> ./mir_demo_client_eglflash Can't get connection user@laptop:~/Downloads/mir/build-linux-x86/bin$ ./mir_demo_client Starting Connected mir_demo_client: /home/user/Downloads/mir/examples/demo_client.c:109: demo_client: Assertion `mir_connection_is_valid(mcd.connection)' failed. Aborted (core dumped)
[11:17] <RAOF> Have you started a mir server? mir_demo_server_shell is most likely the one you want.
[11:17] <mirtestuser> Those mir_demo_client* apps do not seem to get a valid connection to the running Mir server.
[11:18] <mirtestuser> RAOF: I see. I am trying to run them from within the GUI (Ubuntu) assuming that they will connect to the running Mir server. That is not the case?
[11:19] <RAOF> They should get a connection to the running Mir server.
[11:20] <RAOF> If you started mir_demo_server_shell as root and the clients as non-root though you'll need to chmod the /tmp/mir_socket so that they can connect to it.
[11:24] <mirtestuser> RAOF: that's right, the running Mir server on Ubuntu probably runs are root. By changing the permissions I manage to run the demos.
[11:24] <RAOF> mirtestuser: Oh, you're running these from XMir?
[11:25] <mirtestuser> RAOF: Yes, I am running them from gnome-terminal/XMir.
[11:25] <RAOF> Funky :)
[11:26] <mirtestuser> If a process is spawned from gnome-terminal (XMir), then it is limited to XMir then?
[11:29] <tvoss_> RAOF, yeah, it's actually quite cool, the demos are overlayed on top
[11:31] <mirtestuser> Is there an app that is pure Mir (like simple text editor) so that it is possible to compare the behaviour between Mir / XMir? (for example, the lag during typing).
[11:42] <RAOF> I don't know. If the qtplatform was in the PPA you could just use a random Qt app.
[11:49]  * alan_g starts to hate clang
[13:51] <kgunn> alf__: alan_g hikiko any of you running xmir...like dogfooding/using it regularly ?
[13:53] <kgunn> i have pinned ppa, but this morning i did a dist-upgrade...and it uninstalled my lightdm & u-s-c
[13:54] <alan_g> kgunn: never - until I can test the mir I build with a session mir it would just prevent any work being done.
[13:54] <kgunn> ...so i think packages might be busted again....
[13:55] <hikiko> kgunn, I removed it
[13:55] <alf__> kgunn: +1 alan_g
[13:55] <hikiko> I have an intel and I was getting a black screen so I removed it
[13:56] <hikiko> but if you want me to test it
[13:56] <hikiko> I can use it again
[13:56] <kgunn> well i'm not going to force anyone...but it is nice to have a second sane opinion (esp if you have multiple machines)
[13:57] <hikiko> I ran ubuntu only in my laptop
[13:58] <kgunn> bregma: ^
[13:58] <kgunn> you having any trouble?
[13:58] <hikiko> but ok I can try (not atm because I have to finish something)
[13:58] <kgunn> hikiko: np
[13:58] <kgunn> i know bregma is a user
[13:59] <bregma> I'll check
[13:59] <alan_g> kgunn: Some of us want one of the machines to work (and keep it on raring)
[14:00] <kgunn> alan_g: stability...its so overrated :)
[14:01] <bregma> I have a test machine running mir because that's what I do
[14:01] <bregma> besides, it's fun to watch people try to control two pointers
[14:01] <alan_g> kgunn: Until I worked here I kept my "stable" machine on the LTS
[14:02] <kgunn> bregma: ....you need a hobby if you like watching pointers race across the screen
[14:02] <kgunn> btw...the x pointer always loses
[14:03] <bregma> people like to watch cursor races just to see a pointer crash
[14:04] <tvoss_> alf__, ping
[14:04] <alf__> tvoss_: pong
[14:05] <tvoss_> alf__, the testing ppa is broken, do you know how to trigger a rebuild of unity-system compositor?
[14:08] <alf__> tvoss_: no :/
[14:09] <kgunn> tvoss_: checking to see if ancell told me last time...
[14:09] <olli_> kgunn, bregma... who is on the armhf build issue?
[14:09] <olli_> do we have an eta
[14:09] <alf__> tvoss_: packages for the testing ppa are copied from the staging ppa. Does the staging ppa have what you need?
[14:09] <bregma> olli_, I'm still working on it, expect something today
[14:10] <tvoss_> alf__, we need a non-binary copy
[14:11] <kgunn> tvoss_: seems u-s-c is building now
[14:11] <alf__> tvoss_: you can have non-binary copies from one ppa to another
[14:11] <alf__> tvoss_: (i.e. rebuilt the package in the target ppa)
[14:14] <alan_g> olli_: kgunn bregma - is that the hanging input tests? (tentative fix in -c 847)
[14:15] <tvoss_> kgunn, ack
[14:16] <kgunn> tvoss_: so we need to copy both u-s-c & mir right ?
[14:16] <tvoss_> kgunn, mir should already be current
[14:17] <kgunn> tvoss_: ok
[14:17] <kgunn> tvoss_: yeah....makes sense...duh
[14:35] <greyback> kgunn: hmm, something may be wrong somewhere. I just distupgraded, now xmir fails to start. X is failing with "unrecognised option -mir"
[14:36] <tvoss_> greyback, did you pin the ppa?
[14:36] <kgunn> greyback: working on it
[14:36] <greyback> tvoss_: yes
[14:36] <tvoss_> kgunn, you sure that usc is building in the testing ppa?
[14:36] <kgunn> tvoss_: i was about to copy u-s-c over
[14:36] <tvoss_> kgunn, do so
[14:36] <greyback> Huh, my xserver-xorg is from saucy main repo. That can't be right
[14:37] <greyback> but no other version exists in apt-cache policy
[14:37] <kgunn> tvoss_: copying
[14:37] <tvoss_> kgunn, but source, not binary, right?
[14:38] <kgunn> tvoss_: binary per ancell's instructions
[14:38] <kgunn> that he sent in case this happened again
[14:38] <tvoss_> kgunn, the system compositor needs to rebuild against mir in the ppa
[14:39] <kgunn> tvoss_: it did technically....in staging...it was building against 848...which is the same that was in the -testing
[14:39] <tvoss_> kgunn, okay
[14:42] <bregma> just managed to get my apt updates done, and yes, it kindly wants to remove lightdm and unity-system-compositor for me
[14:42] <bregma> and also unity
[14:42]  * bregma looks for his trusty hammer.....
[14:45] <kgunn> didrocks: confused/looking for help....so i copied over u-s-c to
[14:45] <kgunn> https://launchpad.net/~mir-team/+archive/system-compositor-testing/+packages
[14:45] <kgunn> 2 things...#1...i accidently copied raring & saucy ( just meant to copy saucy)
[14:45] <tvoss_> kgunn, unity-system-compositor - 0.0.1bzr33saucy0.161 is pending and not yet propagated
[14:46] <kgunn> tvoss_: thanks...where did you see that / how does one tell ? (i must have missed it)
[14:46] <tvoss_> https://launchpad.net/~mir-team/+archive/system-compositor-testing/+packages
[14:46] <didrocks> kgunn: what's the question? ;)
[14:47] <kgunn> didrocks: well...my #1 is still valid....if i accidently copied in a package that shouldn't be in a ppa...how to expunge ?
[14:47] <didrocks> kgunn: you have this "delete package link"
[14:48] <didrocks> https://launchpad.net/~mir-team/+archive/system-compositor-testing/+delete-packages
[14:48] <kgunn> didrocks: got it thnaks
[14:48] <didrocks> yw ;)
[14:50] <tvoss_> kgunn, propagated
[14:51] <tvoss_> dist-upgrading right now
[14:52] <kgunn> tvoss_: moi aussi
[15:40] <sil2100> renato: ping
[15:40] <sil2100> renato: is there any work being done related to adding more autopilot integration tests to address-book-app?
[15:42] <mhall119> kgunn: where is the XMir code and the modified Xorg server code that is needs?
[15:42] <kgunn> mhall119: uno momento
[15:42] <kgunn> mhall119: instructions here http://unity.ubuntu.com/mir/building_source_for_pc.html
[15:43] <kgunn> are now updated to include all the other bits
[15:43] <kgunn> hth
[15:43] <mhall119> thanks kgunn
[15:47] <mhall119> kgunn: have the xorg-server changes been submitted upstream?
[15:48] <kgunn> mhall119: i have to punt on that one...
[15:48] <kgunn> its on the todo list...and
[15:48] <kgunn> raof is listed as inprogress (i just looked at it yesterday)
[15:48] <kgunn> so the full intention is to do so....
[15:48] <kdub> ok, so for names for the surface-state-related stuff...
[15:49] <kdub> mi::InputCriteria, mg::CompositorCriteria, ms::SurfaceCriteria (for the readonly information)
[15:50] <kdub> and for the interface to change that information
[15:51] <kdub> i think we can group that all into ms::MutableSurfaceState (containing alpha, input regions, position)
[15:51] <kdub> just because at the moment, there's no need to split that all up
[15:51] <alan_g> CompositorCriteria makes sense as it sets out the way that compositing should be done. I'm not so convinced by the others...
[15:52] <kdub> mi::SurfaceConfiguration
[15:52] <kdub> ms::SurfaceState
[15:53]  * alan_g tries to remember what those interfaces have in them
[15:54] <mhall119> RAOF: /w 116
[15:54] <mhall119> ignore
[15:57] <alan_g> kdub: mi::SurfaceConfiguration is your rework of InputChannel?
[15:57] <kdub> well, no mi::InputChannel hasn't changed
[15:57] <kdub> mi::SurfaceConfiguration has the size, position, and input regions
[15:58] <alan_g> mi::Surface?
[15:59] <kdub> i think that works
[16:02] <kdub> with ms:: though, there already is a ms::Surface, so ms::SurfaceState sounds better (containing transform, size, name)
[16:03] <alan_g> alf__: what do you think of these names? ^^
[16:05] <alan_g> kdub: does ms need the transform? Or just the pre- and post-transform properties
[16:06] <kdub> alan_g, i'll have to check
[16:06] <kdub> alan_g, no, transform will go away when I consolidate the implementation class
[16:07] <kdub> so that should just be name, size_and_position
[16:08] <kdub> so, to summarize, mg::CompositorCriteria ( the read-only interface the compositor uses), mi::Surface, the read-only interface the input stack uses
[16:09] <kdub> ms::SurfaceState (the basic generic info the shell needs) and ms::MutableSurfaceState (the way the shell can change the surface state how it needs)
[16:09] <alan_g> Wasn't it mg::CompositingCriteria?
[16:10] <kdub> ah, ok :) mg::CompositingCriteria
[16:10] <alf__> alan_g: kdub: they seem ok. I wonder if at some poin ms::Surface should be renamed to ms::SurfaceImpl (or perhaps hidden somewhere), and free ms::Surface to be used for an interface name
[16:11] <kdub> alf__, i'd expect something like that in the future, not in the MP
[16:11] <alan_g> alf__: ms::Surface should never have been public - it was forced there by some early example code
[16:11] <kdub> right
[16:12] <alf__> kdub: ok
[16:12] <kdub> but after this mp, ms::Surface : public mg::Renderable is broken, so we can put a sensible  public interface around it
[16:12] <kdub> and what is now ms::Surface will just become an implementation class
[16:16]  * kdub goes about changes
[16:52]  * alan_g escapes to the weekend before kdub pushes changes for review
[16:52] <kdub> haha :)
[17:10] <bregma> gosh dang I made one small typo and now I have to restart my arm build.... another hour-and-a-half delay
[17:44]  * tvoss notes that the testing ppa has got a very snappy version of mir/xmir
[17:45]  * ogra_ still waits for XMir on his chromebook 
[18:34] <kdub> renaming is a pain, but worth it in the long run
[18:50] <renato> sil2100, we are waiting for the final designs before start to writing autopilot
[18:51] <renato> sil2100, does not make sense implement autopilot tests with the current UI since this will change
[19:09] <kgunn> bregma: dang it!!...success yet?
[19:11] <bregma> kgunn, https://code.launchpad.net/~bregma/mir/lp-1195265/+merge/174478 ...  I finally get a build on my machine
[19:12] <bregma> won;t know if it fixes on the builders until they've done their bit
[19:16] <sil2100> renato: ok, thanks
[19:41] <bregma> gah, my branch fails in the builders https://jenkins.qa.ubuntu.com/job/mir-android-saucy-i386-build/1299/console but passes fine on my hardware...  anyone have any ideas?
[19:42] <bregma> is jenkins actually cross-building on i386 and failing because it tries to run just-built executables?
[19:45] <wilee-nilee> So in what release does mir become the default?
[20:03] <gotwig> howdy :D
[20:04] <gotwig> mhall119: any idea when QT apps can run on Mir?
[20:26] <kgunn> gotwig: its happening already...https://wiki.ubuntu.com/Touch/Testing/Mir
[20:26] <kgunn> kdub: ^ can you take a look at bregma err's
[20:27] <mhall119> gotwig: the bigger question is when we'll be running Unity 8 on mir (on desktops and devices)
[20:28] <kdub> hmm, looks like the builder's trying to exec the arm executable, i'd guess
[20:32] <kgunn> bregma when you say "passes fine on your hw"....are you native compiling on arm? or cross compiling ?
[20:35] <kdub> right, it looks like a cross-arch execution attempt is being made
[20:39] <kgunn> but if you go look at that check_discover_tests_in_acceptance-tests it just looks like a bunch of make calls to verify directories are populated....
[20:45] <kdub> right, but it touches ctest (which i beleive we make)
[20:58] <olli_> quick question (stupid question too;)
[20:59] <olli_> GPUs using UMA doesn't tell whether it's using a binary/free driver
[20:59] <olli_> i.e. any GPU can be using UMA
[20:59] <olli_> is that correct?
[21:00]  * olli_ tries to parse a statement from sales
[21:00] <olli_> and it doesn't quite make sense
[21:00] <olli_> racarr, kdub, kgunn ^
[21:01] <kdub> olli_, uma == unified memory architecture?
[21:01] <olli_> yep
[21:01] <olli_> well
[21:01] <olli_> that's how I read it
[21:01] <olli_> not sure what Mr. SalesPerson had in mind
[21:01] <olli_> ;)
[21:02] <kdub> the question is sort of a 'does not compute'
[21:02] <kgunn> olli_: or if it was wrt graphics....did he mean to say UXA ?
[21:02] <kgunn> the evolution of EXA
[21:02] <kgunn> which is now subsumed by SNA
[21:03] <kgunn> so chronologically it went EXA -> UXA -> SNA
[21:03] <olli_> kdub, UMA is not an attribute of a GPU which would say anything about vendor or driver
[21:05] <kgunn> olli_: after a quick googling...yeah, its using system mem instead of dedicated video/gfx mem i think
[21:05] <kgunn> it seems to be kind of associated with intel....but i know for a fact of other architectures that use system mem
[21:05] <kgunn> gpu archs that is
[21:06] <kgunn> so conceptually....yeah....any gpu could do it
[21:06] <olli_> kgunn, nv & ati do UMA as well
[21:06] <olli_> according to uncle google
[21:07] <kdub> right, its of course common in the mobile world too
[21:08] <mlankhorst> kdub: ^citation needed
[21:08] <mlankhorst> it's a mess :P
[21:08] <kdub> https://developer.qualcomm.com/forum/qdevnet-forums/mobile-gaming-graphics-optimization-adreno/1286
[21:09] <kdub> it is sort of whatever they want to do though of course
[22:10] <kgunn> bregma: do you need help ?
[22:18] <kdub> bregma, the problem is in MirCommon.cmake
[22:20] <bschaefer> kgunn, kdub bregma is EOD
[22:21] <kgunn> kdub: do you know a sensible solution ?
[22:21] <kdub> ah, ok, well, i'll MP how I got his fix to work
[22:21] <kdub> as like, a merge to a merge
[22:22] <kgunn> kdub: excellent
[22:22] <kgunn> put bregma as reviewer
[22:22] <kgunn> too