| RAOF | Well, it certainly needs to be notified when the display configuration changes, yes. | 00:00 |
|---|---|---|
| RAOF | It does not expect to immediately reply to that notification, though. | 00:02 |
| kdub | right | 00:02 |
| kdub | the message could be ignored if nothing in the x-world cares about the display change | 00:03 |
| RAOF | X *might* want to keep a copy of the display configuration internally, and update it on that signal. | 00:04 |
| RAOF | But it might just be easier to forward configuration state probes all the way down to Mir. | 00:05 |
| kdub | so if mir can notify x of changes to the physical displays (along with the info associated with the change) | 00:06 |
| kdub | and mir can service a configuration request at any time | 00:07 |
| kdub | sounds like that would be good enough | 00:07 |
| 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:08 |
| 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 | 00:09 |
| 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. | 01:49 |
| RAOF | TheDrums: Oooh, that's a shiny new error. | 02:33 |
| RAOF | That would be a ‘Your GPU is too old to support Mir’ type error, though. | 02:34 |
| 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:39 |
| 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:40 |
| RAOF | How would you work around a lack of alpha channel? | 02:41 |
| 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:43 |
| 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:44 |
| RAOF | Fair enough. | 02:45 |
| duflu | RAOF: Laptop? :) | 02:45 |
| * duflu is excited for new hardware | 02:46 | |
| RAOF | Not yet shipped. | 02:46 |
| duflu | Boo | 02:47 |
| RAOF | Indeed. | 02:47 |
| RAOF | Soon! | 02:47 |
| 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:50 |
| 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:58 |
| 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 | 02:59 |
| 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:00 |
| TheDrums | Heh, wow. So the answer isn't "Switch distros." after all, interesting. | 03:25 |
| 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:27 |
| TheDrums | Indeed, so I've noticed. | 03:28 |
| * RAOF has Zoë for an hour or so. | 04:32 | |
| tvoss_ | good morning :) | 05:06 |
| tvoss_ | duflu, good morning :) | 05:15 |
| 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:16 |
| duflu | tvoss_: Shrug, approve. | 05:17 |
| 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:18 |
| 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:21 |
| * duflu wonders about the evils of std::shared_ptr<T> a(p), b(p) | 05:29 | |
| tvoss_ | RAOF, ping for later when you have time | 05:31 |
| RAOF | tvoss_: Pong. | 05:34 |
| thomi | tvoss_: hey | 05:35 |
| 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:47 |
| tvoss_ | thomi, okay, no problem :) | 05:48 |
| thomi | of course, having said that, they appear to be late... | 06:09 |
| tvoss_ | thomi, of course | 06:09 |
| duflu | alf__: I think I have a clearer explanation of my buffer problems... | 06:33 |
| duflu | TemporaryCompositorBuffer is unsafe to put in a shared_ptr because it maintains its own use_count in back_buffer_strategy | 06:34 |
| duflu | So even after the last shared_ptr is destroyed, the strategy has a refcount of 1 and fails to compositor_release() | 06:35 |
| dholbach | good morning | 06:43 |
| alf__ | dholbach: Good morning! | 06:43 |
| dholbach | hi alf__ | 06:44 |
| 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:47 |
| duflu | alf__: https://bugs.launchpad.net/mir/+bug/1200504 | 06:49 |
| ubot5 | Ubuntu bug 1200504 in Mir "surfaces::Surface::compositor_buffer() will leak and cause hangs if used more than once" [Undecided,New] | 06:49 |
| alf__ | duflu: what I don't get is how 'a' and 'b' are the same shared_ptr? mc::BufferStreamSurfaces::lock_back_buffer() | 07:04 |
| alf__ | duflu: returns a new shared_ptr<TemporaryCompositorBuffer> every time | 07:05 |
| duflu | alf__: It's the same from mc::MultiAcquisitionBackBufferStrategy::acquire | 07:05 |
| 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:07 | |
| duflu | alf__: You make a good point. Bug incomplete for now | 07:10 |
| alf__ | duflu: ok, let me now if I can help you investigate this further | 07:11 |
| 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:14 |
| duflu | Ugg. How many internal compiler errors can I hit in one day? | 07:26 |
| RAOF | All the clangs | 07:27 |
| RAOF | Builds faster, too ;) | 07:28 |
| * duflu goes clang | 07:29 | |
| * duflu was sure gcc never sucked so much before | 07:30 | |
| hikiko | hi | 08:15 |
| hikiko | could you please give me a hand with cmake? | 08:18 |
| 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:19 |
| 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:20 |
| 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:21 |
| hikiko | 2- add the source files | 08:22 |
| hikiko | 3- maybe(?) build mirplatformgraphics (?) <- not sure at all this is necessary | 08:22 |
| hikiko | and I have no idea what I am doing so wrong | 08:23 |
| 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:24 |
| 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:25 |
| 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:26 |
| hikiko | alan_g, http://paste.ubuntu.com/5867495/ that's what I have now (I removed include_directories etc to keep it simple) | 08:29 |
| alan_g | hikiko: the first parameter to those commands is the library you want to build | 08:30 |
| 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:31 |
| alan_g | add_library(mirnestedgraphics STATIC ... | 08:33 |
| alan_g | target_link_libraries(mirnestedgraphics mirclient | 08:33 |
| 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:36 |
| 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:38 |
| 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:39 |
| alan_g | hikiko: you're welcome | 08:40 |
| * duflu gives up; goes to dinner | 09:39 | |
| * alf__ is attempting a reboot after 600MB worth of saucy updates... | 09:44 | |
| 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:14 |
| 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:15 |
| 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:16 |
| 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:17 |
| FernandoMiguel | I had two mouse pointers too | 10:18 |
| FernandoMiguel | https://bugs.launchpad.net/ubuntu/+source/ubuntu-ui-toolkit/+bug/1200553 | 10:18 |
| ubot5 | Ubuntu bug 1200553 in ubuntu-ui-toolkit (Ubuntu) "two mouse pointers" [Undecided,New] | 10:18 |
| FernandoMiguel | guess we can close that one... probably the new X | 10:18 |
| FernandoMiguel | PPA purged successfully using aptitude fallback | 10:18 |
| 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:19 |
| 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:20 |
| 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:21 |
| FernandoMiguel | FYI it's working | 10:23 |
| FernandoMiguel | :) | 10:23 |
| FernandoMiguel | any time table for MIR to hit 13.10 repos? | 10:24 |
| tvoss_ | FernandoMiguel, bugs preventing us from entering universe https://bugs.launchpad.net/mir/+bugs?field.tag=entering-saucy | 10:26 |
| tvoss_ | FernandoMiguel, so yeah, hopefully really soon | 10:38 |
| FernandoMiguel | cool | 10:39 |
| 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:43 |
| 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:44 |
| 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:45 |
| 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:46 |
| tvoss_ | RAOF, okay | 10:47 |
| tvoss_ | RAOF, can you trigger the respective copies? | 10:48 |
| tvoss_ | RAOF, I will watch it building then | 10:48 |
| mirtestuser | Hi All! I am running Mir (Ubuntu 13.10 + enabled Mir according to Olli's blog post). | 10:56 |
| tvoss_ | mirtestuser, cool :) | 10:57 |
| mirtestuser | I get the two mouse pointers (hardware and software pointers). | 10:57 |
| mirtestuser | Typing text feels a big laggish (takes a few moments for the text to appear). Is this a known behaviour? | 10:58 |
| tvoss_ | mirtestuser, yes, that's a known bug: https://bugs.launchpad.net/mir/+bug/1199450 | 11:01 |
| ubot5 | Ubuntu bug 1199450 in XMir "[xmir] Inputs slowing, last event of a stream of events greatly delayed" [Critical,Triaged] | 11:01 |
| tvoss_ | mirtestuser, it turned up after the last update of the ppa and we are working on the fix | 11:01 |
| 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:03 |
| mirtestuser | tvoss_: thanks. It's AMD/ATI Radeon HD 6320 ( Evergreen). | 11:04 |
| tvoss_ | mirtestuser, cool, I'm running Intel myself | 11:05 |
| mirtestuser | What Mir examples, etc are available to try out? | 11:09 |
| 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:10 |
| mirtestuser | I am going through those available at mir/build-linux-x86/bin/ | 11:11 |
| === tjaalton_ is now known as tjaalton | ||
| mirtestuser | The mir_demo_client* do not run. I get some errors. | 11:12 |
| RAOF | What errors. | 11:12 |
| RAOF | ? | 11:12 |
| 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:13 |
| 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:17 |
| 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:18 |
| RAOF | They should get a connection to the running Mir server. | 11:19 |
| 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:20 |
| 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:24 |
| mirtestuser | RAOF: Yes, I am running them from gnome-terminal/XMir. | 11:25 |
| RAOF | Funky :) | 11:25 |
| mirtestuser | If a process is spawned from gnome-terminal (XMir), then it is limited to XMir then? | 11:26 |
| tvoss_ | RAOF, yeah, it's actually quite cool, the demos are overlayed on top | 11:29 |
| 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:31 |
| RAOF | I don't know. If the qtplatform was in the PPA you could just use a random Qt app. | 11:42 |
| * alan_g starts to hate clang | 11:49 | |
| === asac` is now known as asac | ||
| === alan_g is now known as alan_g|lunch | ||
| === alan_g|lunch is now known as alan_g | ||
| kgunn | alf__: alan_g hikiko any of you running xmir...like dogfooding/using it regularly ? | 13:51 |
| kgunn | i have pinned ppa, but this morning i did a dist-upgrade...and it uninstalled my lightdm & u-s-c | 13:53 |
| 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:54 |
| 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:55 |
| 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:56 |
| hikiko | I ran ubuntu only in my laptop | 13:57 |
| 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:58 |
| bregma | I'll check | 13:59 |
| alan_g | kgunn: Some of us want one of the machines to work (and keep it on raring) | 13:59 |
| kgunn | alan_g: stability...its so overrated :) | 14:00 |
| 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:01 |
| 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:02 |
| bregma | people like to watch cursor races just to see a pointer crash | 14:03 |
| tvoss_ | alf__, ping | 14:04 |
| alf__ | tvoss_: pong | 14:04 |
| tvoss_ | alf__, the testing ppa is broken, do you know how to trigger a rebuild of unity-system compositor? | 14:05 |
| alf__ | tvoss_: no :/ | 14:08 |
| 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:09 |
| tvoss_ | alf__, we need a non-binary copy | 14:10 |
| 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:11 |
| alan_g | olli_: kgunn bregma - is that the hanging input tests? (tentative fix in -c 847) | 14:14 |
| tvoss_ | kgunn, ack | 14:15 |
| kgunn | tvoss_: so we need to copy both u-s-c & mir right ? | 14:16 |
| tvoss_ | kgunn, mir should already be current | 14:16 |
| kgunn | tvoss_: ok | 14:17 |
| kgunn | tvoss_: yeah....makes sense...duh | 14:17 |
| === Guest98373 is now known as Debolaz | ||
| greyback | kgunn: hmm, something may be wrong somewhere. I just distupgraded, now xmir fails to start. X is failing with "unrecognised option -mir" | 14:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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:42 | |
| 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:45 |
| 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:46 |
| 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:47 |
| didrocks | https://launchpad.net/~mir-team/+archive/system-compositor-testing/+delete-packages | 14:48 |
| kgunn | didrocks: got it thnaks | 14:48 |
| didrocks | yw ;) | 14:48 |
| tvoss_ | kgunn, propagated | 14:50 |
| tvoss_ | dist-upgrading right now | 14:51 |
| kgunn | tvoss_: moi aussi | 14:52 |
| 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:40 |
| 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:42 |
| kgunn | are now updated to include all the other bits | 15:43 |
| kgunn | hth | 15:43 |
| mhall119 | thanks kgunn | 15:43 |
| mhall119 | kgunn: have the xorg-server changes been submitted upstream? | 15:47 |
| 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:48 |
| kdub | mi::InputCriteria, mg::CompositorCriteria, ms::SurfaceCriteria (for the readonly information) | 15:49 |
| kdub | and for the interface to change that information | 15:50 |
| 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:51 |
| kdub | mi::SurfaceConfiguration | 15:52 |
| kdub | ms::SurfaceState | 15:52 |
| * alan_g tries to remember what those interfaces have in them | 15:53 | |
| mhall119 | RAOF: /w 116 | 15:54 |
| mhall119 | ignore | 15:54 |
| 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:57 |
| alan_g | mi::Surface? | 15:58 |
| kdub | i think that works | 15:59 |
| kdub | with ms:: though, there already is a ms::Surface, so ms::SurfaceState sounds better (containing transform, size, name) | 16:02 |
| alan_g | alf__: what do you think of these names? ^^ | 16:03 |
| alan_g | kdub: does ms need the transform? Or just the pre- and post-transform properties | 16:05 |
| 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:06 |
| kdub | so that should just be name, size_and_position | 16:07 |
| kdub | so, to summarize, mg::CompositorCriteria ( the read-only interface the compositor uses), mi::Surface, the read-only interface the input stack uses | 16:08 |
| 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:09 |
| 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:10 |
| 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:11 |
| 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:12 |
| * kdub goes about changes | 16:16 | |
| * alan_g escapes to the weekend before kdub pushes changes for review | 16:52 | |
| === alan_g is now known as alan_g|EOW | ||
| kdub | haha :) | 16:52 |
| bregma | gosh dang I made one small typo and now I have to restart my arm build.... another hour-and-a-half delay | 17:10 |
| * tvoss notes that the testing ppa has got a very snappy version of mir/xmir | 17:44 | |
| * ogra_ still waits for XMir on his chromebook | 17:45 | |
| kdub | renaming is a pain, but worth it in the long run | 18:34 |
| renato | sil2100, we are waiting for the final designs before start to writing autopilot | 18:50 |
| renato | sil2100, does not make sense implement autopilot tests with the current UI since this will change | 18:51 |
| kgunn | bregma: dang it!!...success yet? | 19:09 |
| bregma | kgunn, https://code.launchpad.net/~bregma/mir/lp-1195265/+merge/174478 ... I finally get a build on my machine | 19:11 |
| bregma | won;t know if it fixes on the builders until they've done their bit | 19:12 |
| sil2100 | renato: ok, thanks | 19:16 |
| 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:41 |
| bregma | is jenkins actually cross-building on i386 and failing because it tries to run just-built executables? | 19:42 |
| wilee-nilee | So in what release does mir become the default? | 19:45 |
| gotwig | howdy :D | 20:03 |
| gotwig | mhall119: any idea when QT apps can run on Mir? | 20:04 |
| 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:26 |
| mhall119 | gotwig: the bigger question is when we'll be running Unity 8 on mir (on desktops and devices) | 20:27 |
| kdub | hmm, looks like the builder's trying to exec the arm executable, i'd guess | 20:28 |
| kgunn | bregma when you say "passes fine on your hw"....are you native compiling on arm? or cross compiling ? | 20:32 |
| kdub | right, it looks like a cross-arch execution attempt is being made | 20:35 |
| 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:39 |
| kdub | right, but it touches ctest (which i beleive we make) | 20:45 |
| === ricmm_ is now known as ricmm | ||
| olli_ | quick question (stupid question too;) | 20:58 |
| 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? | 20:59 |
| * 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:00 |
| 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:01 |
| 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:02 |
| 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:03 |
| 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:05 |
| 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:06 |
| kdub | right, its of course common in the mobile world too | 21:07 |
| 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:08 |
| kdub | it is sort of whatever they want to do though of course | 21:09 |
| kgunn | bregma: do you need help ? | 22:10 |
| kdub | bregma, the problem is in MirCommon.cmake | 22:18 |
| bschaefer | kgunn, kdub bregma is EOD | 22:20 |
| 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:21 |
| kgunn | kdub: excellent | 22:22 |
| kgunn | put bregma as reviewer | 22:22 |
| kgunn | too | 22:22 |
| === renato is now known as renato_away | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!