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