| duflu | RAOF: https://launchpad.net/ubuntu/+source/libinput ? | 01:31 |
|---|---|---|
| duflu | Sounds official | 01:31 |
| RAOF | Indeed. | 01:31 |
| * RAOF upgrades to utopic | 01:32 | |
| RAOF | But first: coffee! | 01:32 |
| josharenson | kdub, re: way earlier, I am following the same method as the acceptance tests to launch server/client combo... but it isn't working, likely due to the fact that popen forks | 01:48 |
| bschaefer | anyone know why mesa-common-dev is installing GL headers on arm? | 02:29 |
| duflu | RAOF: I just noticed this happening on my system: | 02:37 |
| duflu | [ 1.345960] fb: conflicting fb hw usage inteldrmfb vs EFI VGA - removing generic driver | 02:37 |
| duflu | which sounds logical | 02:37 |
| duflu | but doesn't that mean we can never have a seamless boot screen? | 02:37 |
| duflu | Because any modern system will start with efifb (or other) and then switch to the GPU-specific driver | 02:38 |
| RAOF | bschaefer: Because you can totally build GL applications against mesa on arm? | 02:58 |
| RAOF | duflu: No; intel, for example, has code to seamlessly take over from the EFI bootsplash. | 02:59 |
| duflu | RAOF: I suspected as much. Cool | 02:59 |
| duflu | RAOF: By default? | 03:00 |
| RAOF | I'm not sure if they've enabled it yet. | 03:00 |
| duflu | Trusty's boot screens seem quite broken for many possible reasons. Grub is often one | 03:01 |
| duflu | As usual, most of the boot experience is a black screen. Sometimes a purple border. And then the login screen | 03:01 |
| duflu | Plymouth doesn't really play a part any more | 03:01 |
| RAOF | It's because we boot too fast. | 03:04 |
| duflu | Yeah. I wonder what purpose the black screen with purple border is intended for though | 03:04 |
| duflu | It just looks confusing | 03:04 |
| RAOF | That would probably be grubish. | 03:04 |
| bschaefer | RAOF, with glx? | 03:07 |
| RAOF | bschaefer: Sure, why not! | 03:07 |
| bschaefer | RAOF, hmm then either SDL2 is confused or i am :) | 03:08 |
| RAOF | There would be some adrino GPUs where you could do GLX :) | 03:08 |
| bschaefer | as SDL2 assumes if GL/gl.h and GL/glx.h then opengl is supported, and attempts to render in opengl on arm | 03:08 |
| bschaefer | which fails | 03:08 |
| RAOF | And this is at compile-time, obviously. | 03:15 |
| RAOF | There's no way of explicitly asking for EGL? | 03:15 |
| bschaefer | there is, and it compiles fine, its at run time when a renderer is picked | 03:15 |
| bschaefer | which usually if opengl is around, opengl is picked first | 03:15 |
| bschaefer | RAOF, i can get around this by --disable-video-opengl in the deb for arm builds | 03:16 |
| bschaefer | RAOF, i just thought that opengl stayed away from arm, and it was just es 1/2 | 03:16 |
| RAOF | It's technically possible to do on arm hardware (although I haven't followed up if Rob has actually implemented it for any of the reverse-engineered drivers), and (for example) the new nvidia arm stuff supports OpenGL 4.4. | 03:17 |
| RAOF | bschaefer: How does it pick a renderer? It can't pick a GLX one for Mir, because it can't get an X connection :) | 03:19 |
| bschaefer | RAOF, thats awesome! I didn't even know that was close to being supported on arm | 03:19 |
| bschaefer | RAOF, well, SDL2 just does 2 checks | 03:20 |
| bschaefer | if GL/gl.h and GL/glx.h exists, then flip the define VIDEO_OPENGL = 1 | 03:20 |
| bschaefer | if VIDEO_OPENGL = 1, then we assume opengl is supported, and we attempt to return an opengl context for the renderer in the mir backend | 03:20 |
| RAOF | Ah. | 03:22 |
| bschaefer | actually its changed a bit in mir since then, but we get flags that'll hand that to us (in the mir back end) | 03:22 |
| RAOF | Well, it should be checking whether the EGL implementation supports OpenGL. | 03:22 |
| bschaefer | The check is just for OpenGLX11(), which flips that flag :( | 03:23 |
| bschaefer | i should add a check if x11 is even around at that point though? | 03:23 |
| bschaefer | Ill have to dig more into its criteria for picking opengl, as i think its a bit to loose | 03:24 |
| bschaefer | RAOF, thanks! | 03:24 |
| RAOF | NP :) | 03:25 |
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| duflu | RAOF: Here you go. It works at near light speed :) https://code.launchpad.net/~vanvugt/mir/single-buffer/+merge/217555 | 08:01 |
| RAOF | duflu: I notice you assume that reading and writing to that buffer simultaneously won't crash :) | 08:04 |
| duflu | RAOF: Correct for all memory types I know of...? | 08:04 |
| RAOF | I'm pretty sure doing so on some graphics hardware invokes undefined behaviour. | 08:08 |
| RAOF | But that's ok, because you can't hardware-accelerate single-buffered clients anyway! | 08:08 |
| duflu | RAOF: I doubt it. Traditionally most GL implementation support single buffering | 08:08 |
| RAOF | Not to window surfaces? | 08:09 |
| RAOF | And only GL; that's one of the things removed in GLES | 08:09 |
| duflu | RAOF: Yeah "traditionally" in the good old GL days | 08:10 |
| anpok_ | RAOF: duflu: you could have the other buffer in the display control unit that does the scan out.. and only block gl during scanout.. so the gles driver would really see only one buffer | 08:36 |
| anpok_ | greyback: duflu is out for short, but comes back soon | 08:37 |
| duflu | greyback: Not sure there was any WM news this week... ? | 08:54 |
| greyback | duflu: not from me, I was out last week | 08:55 |
| greyback | duflu: have you anything? | 08:55 |
| duflu | I have grand plans for making a start on defining "Window" (maybe) and the multi-surface support stuff | 08:55 |
| duflu | greyback: But nothing official yet. I got delayed last week trying to fix some regressions. | 08:57 |
| duflu | And it happened to be a 3-day week in Australia :) | 08:57 |
| greyback | duflu: fair enough. This week I hope to sort out the QtCompositor multi-monitor story | 08:59 |
| duflu | anpok_: Yeah I was thinking you could block single buffered clients "only during scanout". But not a pressing issue | 08:59 |
| duflu | greyback: Fun. Let us know if anything needs fixing/improving | 08:59 |
| greyback | duflu: once anpok's custom-input-dispatcher branch lands, I'll be a happy bunny | 09:01 |
| * duflu doesn't even know what that means | 09:01 | |
| greyback | anpok_: note https://code.launchpad.net/~andreas-pokorny/mir/custom_input_dispatcher/+merge/215174 has conflicts with trunk, could you update please | 09:03 |
| anpok_ | greyback: ok | 09:09 |
| === ondra- is now known as ondra | ||
| anpok_ | hm i seem to be using a different compiler than our ci - the new 4.8 or 4.9 does not include string.h.. | 09:31 |
| anpok_ | hmm or that caused by a change in boost exception | 09:31 |
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| === alan_g is now known as alan_g|lunch | ||
| === alan_g|lunch is now known as alan_g | ||
| greyback | fginther: ping | 13:21 |
| === pete-woods1 is now known as pete-woods-lunch | ||
| === jono is now known as Guest72975 | ||
| === dandrader is now known as dandrader|afk | ||
| === alan_g is now known as alan_g|tea | ||
| === alan_g|tea is now known as alan_g | ||
| === dandrader|afk is now known as dandrader | ||
| === pete-woods-lunch is now known as pete-woods | ||
| === chihchun is now known as chihchun_afk | ||
| === alan_g is now known as alan_g|EOD | ||
| greyback | anpok_: hey, do you think lp:~andreas-pokorny/mir/input-sender-split is close to MR? | 16:57 |
| greyback | (fyi it has conflicts with mir-devel right now) | 16:58 |
| anpok_ | i know | 16:59 |
| anpok_ | i am untangling things that I added during custom_input_dispatcher | 16:59 |
| greyback | anpok_: ok | 17:01 |
| anpok_ | it is closeish .. but not done | 17:01 |
| greyback | I'll be working off it for now anyway | 17:02 |
| anpok_ | thanks | 17:02 |
| kdub | yay, figured out my resizing problem, lets see if there's any other way to break this overlay stuff | 17:15 |
| josharenson | So I still cannot figure out how to launch a mir client (via popen) and have it attach to a mir server that was started from a different thread (at least that isn't some kind of hack)... Has anyone done this? I think the issues is popen forks | 17:22 |
| kdub | josharenson, what sort of problem? | 17:24 |
| josharenson | kdub its either not working at all (client cannot connect to mir), or the performance is terrible (.5 frames / sec) | 17:25 |
| kdub | generally, I'd fork first, then have the processes do their things | 17:25 |
| josharenson | kdub I've tried using the test framework (launch_client_process) which does exactly that... no dice | 17:26 |
| kdub | josharenson, what is like the overarching goal? | 17:26 |
| kdub | like, launch glmark or something automatically? | 17:27 |
| josharenson | kdub, start server, run benchmark, stop server | 17:27 |
| kdub | right, just making sure | 17:27 |
| josharenson | if i call run_mir in a separate thread, sleep the main thread while server inits, and then call popen, it works | 17:27 |
| josharenson | kdub, but that uses a sleep call, and there is no way to gracefully stop the server | 17:28 |
| kdub | use a condition_variable to wake it up when the client has stopped | 17:28 |
| josharenson | kdub, it blocks at the run_mir call though | 17:29 |
| kdub | well, run_mir will just stop on the signals iirc | 17:30 |
| josharenson | kdub, so just raise(sigint)? | 17:30 |
| kdub | well, I dunno if that's the preferable way | 17:30 |
| kdub | if you're using the test framework directly (eg, like writing a new acceptance test) | 17:30 |
| kdub | then the drivers might not be being hit I think the default with those is to stub out the drivers | 17:31 |
| kdub | like, this new executable that does this should be more of 'in the spirit of the acceptance tests' than an acceptance test itself I guess | 17:31 |
| kdub | just my two cents though :) | 17:31 |
| josharenson | kdub, nod... however when I tried everything acceptance test related, up to and including dropping the popen into an existing acceptance test, the benchmark still couldn't connect to mir... I'll keep trying things... | 17:32 |
| alan_g|EOD | josharenson: kdub how about using InProcessServer with the default configuration? You can launch glmark in the test body. | 17:33 |
| * alan_g|EOD hasn't tried it but it should be possible | 17:33 | |
| kdub | josharenson, yeah, thats another idea | 17:33 |
| kdub | like, check out the demo_inprocess_egl example | 17:33 |
| kdub | alan_g|EOD, but if the purpose is benchmarking, I'd rather not cut out the IPC stuff | 17:33 |
| * josharenson looking at that function | 17:33 | |
| josharenson | kdub, alan_g|EOD certainly looks like what I'm trying to do.. I'll give it a try. Thanks | 17:35 |
| alan_g|EOD | kdub: If you launch a child process you'll be doing IPC | 17:36 |
| kdub | alan_g|EOD, yeah, good point | 17:36 |
| kdub | no process context switches though | 17:36 |
| alan_g|EOD | kdub: If you launch glmark as a child process it will be a different process | 17:37 |
| kdub | well, I thought we were talking about inprocess egl clients | 17:38 |
| alan_g|EOD | InProcessServer creates a server in the test process. But the client can be another process - provided you ship the connection FD across. | 17:39 |
| * alan_g|EOD wanders away again | 17:39 | |
| kdub | have a nice wander :D | 17:40 |
| * kdub has to reacquaint myself with InProcessServer | 17:40 | |
| === dandrader is now known as dandrader|lunch | ||
| === dandrader|lunch is now known as dandrader | ||
| stgraber | hey there | 19:37 |
| stgraber | so asac asked me to get a Unity8 + Mir desktop session running inside a LXC container (as a way to run 14.10's unity8+mir on 14.04) | 19:37 |
| stgraber | so far I'm trying to run unity8 with mir on vt8 from within a container. I've got access to /dev/tty8 and to /dev/dri but things are still failing a bit | 19:38 |
| stgraber | http://paste.ubuntu.com/7361449/ any idea? | 19:38 |
| stgraber | that's basically a clean container with just unity8-desktop-session-mir installed in there | 19:38 |
| stgraber | asac: http://paste.ubuntu.com/7361648/ | 20:07 |
| asac | greyback: ^^ | 20:07 |
| asac | greyback: who could help? | 20:08 |
| asac | kdub: ^ ? | 20:09 |
| asac | racarr__: ^ :) (that was last ping i'll try) | 20:10 |
| racarr__ | Hola! | 20:10 |
| asac | yay! | 20:10 |
| racarr__ | asac: stgraber: It's not familiar off the top of my head...lemme think/try something | 20:10 |
| asac | nice one... thanks! | 20:11 |
| racarr__ | hmm experiment uninformative lol, lsof on a running mir_demo_server_shell | 20:11 |
| racarr__ | is all libraries, /dev/tty /dev/dri and /dev/input (which wouldnt give this error...I think opening input still just fails with a log message) | 20:12 |
| kdub | stgraber, lxc container on the desktop? | 20:12 |
| stgraber | kdub: yep | 20:12 |
| racarr__ | stgraber: Ok looking at gbm source its definitely the DRM fd | 20:14 |
| racarr__ | *thinks* | 20:14 |
| racarr__ | stgraber: Hmm if you aren't running USC | 20:17 |
| racarr__ | then EGL_PLATFORM="mir" shouldnt be set | 20:17 |
| racarr__ | because mir clients (incl nested mir server )use the mir egl platform | 20:17 |
| racarr__ | but a host mir server uses the | 20:17 |
| racarr__ | drm egl platform | 20:17 |
| racarr__ | it shouldnt be necessary to set EGL_PLATFORM="mir" | 20:18 |
| racarr__ | that could be it. | 20:18 |
| racarr__ | if not, backtrace would be next step to see if its the server context or unity8 failing to initialize | 20:19 |
| racarr__ | seems like the server...but *shrug* | 20:19 |
| asac | racarr__: stgraber: no luck? | 20:40 |
| stgraber | asac: sorry, had a meeting, back now | 20:52 |
| asac | heh | 20:52 |
| asac | dont worry | 20:52 |
| asac | i just wanted to check before i drop off :) | 20:52 |
| stgraber | racarr__: ok, so things should work if I only set QT_QPA_PLATFORM=ubuntumirserver in the environment and call unity8? | 20:53 |
| asac | allright, i am off, cu around tomorrow | 20:53 |
| racarr__ | stgraber: Should! | 20:57 |
| === dandrader is now known as dandrader|afk | ||
| AlbertA | kdub: ping | 21:21 |
| kdub | AlbertA, pong | 21:21 |
| AlbertA | kdub: so on the fallback path | 21:21 |
| kdub | sure | 21:21 |
| AlbertA | kdub: let's say you are using demo shell | 21:21 |
| AlbertA | kdub: and lets' say evertying is hooked up to hwc as envisioned | 21:22 |
| kdub | right | 21:22 |
| AlbertA | kdub: how does the extended | 21:22 |
| AlbertA | renderer get to render the shadows? | 21:22 |
| AlbertA | I'm not clear how the fallback and the compositor render interplay | 21:22 |
| kdub | well, in that case, the user of mg::DisplayBuffer (eg, the demo shell writer) would know they're doing something advanced, so they wouldn't try the optimization function | 21:23 |
| kdub | like, if the compositor writer can fit what they want to appear on the screen into a RenderableList, then they have the shot at optimization | 21:23 |
| kdub | otherwise, they have OpenGL to do what they want | 21:24 |
| AlbertA | ah I see | 21:24 |
| kdub | now, a clever compositor writer with this scenario could make a Renderable that is black, and insert it into the list | 21:24 |
| kdub | but not all ideas behind effects can be captured in the RenderableList | 21:25 |
| kdub | like from a compositor writer's perspective, they don't know about the android fallback GL code | 21:25 |
| kdub | and this is a cool abstraction (i'm biased :) ) because it works for like | 21:26 |
| kdub | hardware cursor + bypass buffer too | 21:26 |
| kdub | on mesa | 21:26 |
| AlbertA | I see you could render the shadows just once (until window size changes) and keep inserting into the list | 21:28 |
| kdub | right, but take like the 'magic lamp' animation (like a macos minimize) | 21:31 |
| kdub | during the animation, the compositor writer wants to do GL, so they have the flexibility | 21:31 |
| kdub | but once the window has become steady, then the compositor writer knows its simple, and can try submitting to the optimized function to get the optimized render the platform provides | 21:32 |
| === dandrader|afk is now known as dandrader | ||
| racarr__ | living on the edge and having a second coffee today :D | 23:41 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!