| hikiko | hey | 08:52 |
|---|---|---|
| hikiko | duflu, are you around? | 08:52 |
| duflu | hikiko: Yes | 08:53 |
| hikiko | hello :) | 08:53 |
| hikiko | do you know anything about miral? | 08:53 |
| === dandrader is now known as dandrader|afk | ||
| hikiko | I run it and it crashes with this error: | 08:54 |
| hikiko | http://pastebin.com/wzCNkedA | 08:54 |
| hikiko | and I am almost sure, I didn't install some mir or miral dependency | 08:54 |
| duflu | hikiko: Don't know. Try alan_g (who starts in 5 minutes?) | 08:55 |
| hikiko | ok :) thanks! | 08:56 |
| hikiko | lol here he is! | 08:56 |
| hikiko | hi alan_g | 08:56 |
| hikiko | I have questions for you!! | 08:56 |
| hikiko | good morning :) | 08:56 |
| hikiko | mmm duflu do you use any ppa for mir? | 08:57 |
| duflu | hikiko: No. Just zesty, or compile lp:mir. But I only use Unity8 with the official zesty packages | 08:58 |
| hikiko | I can't compile mir for some reason either... I get some compile errors | 08:59 |
| hikiko | can I show you? | 08:59 |
| duflu | hikiko: That's interesting. Yes please show the error | 08:59 |
| hikiko | might be just my configuration :p 1 sec | 08:59 |
| hikiko | duflu, linker* errors | 09:01 |
| hikiko | https://paste.ubuntu.com/24136976/ | 09:02 |
| hikiko | I am pretty sure I didn't install something properly | 09:02 |
| hikiko | I am building that inside a chroot | 09:02 |
| hikiko | so I might miss some package | 09:02 |
| hikiko | I have installed mir common, platform, client, server, mesa-x12 etc | 09:03 |
| alan_g | hikiko: are you following https://unity.ubuntu.com/mir/0.26/building_source_for_pc.html? | 09:06 |
| hikiko | alan_g, yes | 09:06 |
| hikiko | also miral-shell gives me a segfault because some cpp is missing give me a sec | 09:07 |
| hikiko | [10:54:00] <hikiko> I run it and it crashes with this error: | 09:07 |
| hikiko | [10:54:20] <hikiko> http://pastebin.com/wzCNkedA | 09:07 |
| hikiko | alan_g, I am sure there's something on my system missing because I could run miral | 09:07 |
| hikiko | but I can't figure out what | 09:07 |
| alan_g | hikiko: I don't see how those instructions would try to lonk with //usr/lib/x86_64-linux-gnu/libmirclient.so.9 | 09:08 |
| alan_g | *kink | 09:08 |
| alan_g | **link | 09:08 |
| hikiko | alan_g, I don't know either | 09:08 |
| hikiko | I just copy pasted all the commands | 09:08 |
| hikiko | oh I don't know if it's relevant | 09:08 |
| hikiko | I am using also this ppa: | 09:08 |
| alan_g | hikiko: "./miral-shell/decoration_provider.cpp:196" is trying to load a font | 09:09 |
| hikiko | cemil-azizoglu-ubuntu-mesa-rs-zesty.list | 09:09 |
| hikiko | I am apt-file searching it | 09:10 |
| hikiko | ttf-ubuntu-font-family: /usr/share/fonts/truetype/ubuntu-font-family/Ubuntu-B.ttf | 09:10 |
| hikiko | alan_g, it seems that the font is there | 09:10 |
| duflu | hikiko: It appears you have an old version of the libmirclient package installed (0.25) but a new libmirclient (0.26). Try updating to ensure they are all version 0.26.1 | 09:11 |
| duflu | hikiko: It appears you have an old version of the libmirclient package installed (0.25) but a new libmircommon (0.26). Try updating to ensure they are all version 0.26.1 | 09:11 |
| duflu | hikiko: zesty right? | 09:11 |
| hikiko | duflu, yes | 09:12 |
| hikiko | but apt-get update/dist-upgrade | 09:12 |
| hikiko | doesn't propose anything for mir | 09:12 |
| duflu | Hmm | 09:12 |
| duflu | hikiko: dpkg -l | grep libmir | 09:12 |
| hikiko | duflu, http://pastebin.com/UWBS4hHx | 09:13 |
| hikiko | it seems that everything is 0.26 :s | 09:13 |
| duflu | Oh, maybe I should not expect the symbol versions to change. Hang on | 09:13 |
| * alan_g wonders why loading the font failed at L196, not L96 (which gives a clear message) | 09:20 | |
| hikiko | alan_g, do you want a backtrace> | 09:20 |
| hikiko | ? | 09:20 |
| duflu | hikiko: That PPA won't cause the problem either. I guess you have either leftovers from some old PPA or custom environment finding libmircommon in a strange place | 09:21 |
| alan_g | hikiko: does "$ miral-app -kiosk" run? | 09:21 |
| duflu | I really wish we didn't have launcher commands | 09:21 |
| duflu | But now count at least four | 09:22 |
| hikiko | alan_g, it gives the same error | 09:22 |
| hikiko | but then: | 09:22 |
| hikiko | waiting for /run/user/1000/mir_socket | 09:22 |
| hikiko | waiting for /run/user/1000/mir_socket | 09:22 |
| hikiko | oh | 09:22 |
| hikiko | sec | 09:22 |
| hikiko | maybe it's the chroot | 09:22 |
| * alan_g wonders how it can give an error from code that isn't running | 09:23 | |
| alan_g | or even in the executable | 09:23 |
| hikiko | [2017-03-08 09:23:40.909694] mirserver: Using software cursor | 09:23 |
| hikiko | ERROR: Throw location unknown (consider using BOOST_THROW_EXCEPTION) | 09:23 |
| hikiko | Dynamic exception type: boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::system::system_error> > | 09:23 |
| hikiko | std::exception::what: bind: No such file or directory | 09:23 |
| hikiko | Segmentation fault | 09:23 |
| hikiko | waiting for /run/user/1000/mir_socket | 09:23 |
| hikiko | waiting for /run/user/1000/mir_socket | 09:23 |
| hikiko | then it prints the message forever | 09:24 |
| alan_g | If the server crashes /run/user/1000/mir_socket will take a long time to appear | 09:24 |
| alan_g | Just kill it with ^C | 09:24 |
| hikiko | yep, I killed it already | 09:25 |
| alan_g | Do you have anything Mir in /usr/local/lib? | 09:25 |
| hikiko | let me check | 09:25 |
| hikiko | no | 09:26 |
| hikiko | just python | 09:26 |
| alan_g | $ ldd `which miral-shell` | 09:26 |
| duflu | Morning alf_ ... Perhaps interesting reading: https://lists.freedesktop.org/archives/mesa-dev/2014-July/063977.html | 09:27 |
| hikiko | alan_g, http://pastebin.com/zAVKL89W | 09:27 |
| duflu | (which I only found when searching for the new function he added in the header but failed to implement) | 09:28 |
| alan_g | That all looks sane | 09:30 |
| hikiko | then why it segfaults? | 09:31 |
| alan_g | Not obvious. | 09:33 |
| alf_ | duflu: thanks | 09:35 |
| alan_g | It's annoying to debug too - (mir-on-X grabs input). Can you ssh from a different machine? | 09:36 |
| hikiko | alan_g, it's a chroot I guess if I open it from another terminal it's fine | 09:36 |
| hikiko | it doesnt grub input btw if you roll the window :) | 09:37 |
| alan_g | hikiko: for differential diagnosis - do Mir & MirAL work outside the chroot? | 09:41 |
| hikiko | mmm miral-shell seems to work | 09:41 |
| === dandrader|afk is now known as dandrader | ||
| hikiko | I don't know about mir I don't want to install its dependencies on desktop | 09:42 |
| alan_g | Sure | 09:43 |
| hikiko | so, it's probably what I suspect | 09:43 |
| hikiko | something missing from chroot | 09:43 |
| alan_g | Yeah | 09:43 |
| hikiko | that is installed on desktop | 09:43 |
| alan_g | A stacktrace from miral-kiosk might give a clue | 09:45 |
| alan_g | There's clearly also a problem with the font | 09:45 |
| duflu | It may not be relevant now, but when I first did font support I found I could not use the Ubuntu font because it was missing in Core | 09:47 |
| hikiko | interesting: miral-kiosk without params can run (it shows a red screen that fades out) when I mount /run/user/1000 | 09:47 |
| hikiko | but miral-shell cant | 09:47 |
| hikiko | alan_g, the font is just a warning | 09:48 |
| hikiko | I think the real error is that: | 09:48 |
| hikiko | (anonymous namespace)::Printer::printhelp ( | 09:48 |
| hikiko | this=0x55555583a080 <(anonymous namespace)::render_pattern(MirGraphicsRegion*, unsigned char const*)::printer>, region=...) | 09:48 |
| hikiko | at ./miral-shell/decoration_provider.cpp:196 | 09:48 |
| hikiko | 196 ./miral-shell/decoration_provider.cpp: No such file or directory. | 09:48 |
| hikiko | $ apt-file search decoration_provider.cpp returns nothing | 09:50 |
| hikiko | that's why I was wondering if my mir version is outdated and I need a ppa | 09:50 |
| alan_g | hikiko: ./miral-shell/decoration_provider.cpp:196 is trying to use the font. Are you sure it exists with sane access permissions in the chroot? | 09:51 |
| duflu | If you're using Core/snappy then it's possible the Ubuntu font doesn't exist still. That's why I used LiberationSans-Bold.ttf. Confusingly Ubuntu Core did contain RedHat's font | 09:52 |
| duflu | hikiko: Are you running full desktop zesty? | 09:53 |
| duflu | Might have a similar problem with Ubuntu Server | 09:54 |
| alan_g | OK, if miral-kiosk runs then the only problem seems to be the font | 09:55 |
| alan_g | Are there any fonts in the chroot? | 09:55 |
| hikiko | I reinstalled the font | 09:55 |
| hikiko | and worked :) | 09:55 |
| hikiko | now I have to find out why mir doesn't build, I guess something similar :p | 09:55 |
| hikiko | alan_g, yes | 09:55 |
| hikiko | there were | 09:56 |
| duflu | hikiko: What ISO did you install from? | 09:56 |
| duflu | If any | 09:56 |
| hikiko | duflu, no iso I used debootstrap | 09:56 |
| hikiko | on zesty | 09:56 |
| alan_g | You can choose the font with --shell-titlebar-font | 09:56 |
| duflu | I guess a more elegant fallback than crashing is required for missing fonts | 09:57 |
| hikiko | yeah :) | 09:57 |
| hikiko | anyway, thanks duflu alan_g :) | 09:58 |
| alan_g | duflu: it's odd - it exits with an error if opening the font fails. This is something new. | 09:58 |
| duflu | Oh | 09:58 |
| duflu | Anyone found PosixRWMutex unit tests hang/fail? | 09:58 |
| duflu | I'm only seeing it today | 09:58 |
| alan_g | Hmm. I was wrong... | 09:59 |
| alan_g | WARNING: failed to load titlebar font: "rubbish" | 09:59 |
| alan_g | Segmentation fault (core dumped) | 09:59 |
| duflu | That's not this one is it? https://errors.ubuntu.com/problem/c4a91485a9e7bf2774806d21e8c6c71f8ef79f08 | 10:02 |
| alan_g | hikiko: do you see a "WARNING: failed to load titlebar font" message before the segfault? | 10:02 |
| hikiko | yes alan_g | 10:05 |
| * alan_g goes to log a bug | 10:05 | |
| hikiko | but as I said, after re-installing ubuntu fonts I don't see the segfault, it works great | 10:06 |
| alan_g | Sure, but it shouldn't segfault if the font isn't there. | 10:06 |
| alan_g | duflu: I can't tell what that is | 10:07 |
| alan_g | greyback: HTH https://bugs.launchpad.net/miral/+bug/1670741/comments/1 | 10:33 |
| ubot5 | Ubuntu bug 1670741 in MirAL "Have a MIRAL_WINDOW_MANAGEMENT_TRACE env var" [Undecided,Invalid] | 10:33 |
| greyback | alan_g: oh so that already works? Great | 10:34 |
| alan_g | You just had the spellign wrong | 10:34 |
| greyback | *nod* understood | 10:35 |
| * alan_g can't type this morning | 10:35 | |
| greyback | alan_g: https://bugs.launchpad.net/miral/+bug/1670876 <- ack, I couldn't see any real miral code that would impact it, but logged it against miral as miral-shell has the same bug | 11:45 |
| ubot5 | Ubuntu bug 1670876 in Mir "Setting cursor causes window's input_region to be reset" [Undecided,New] | 11:45 |
| alan_g | Sure, it's either the new APIs or misuse of the new APIs | 11:46 |
| === dandrader is now known as dandrader|afk | ||
| === dandrader|afk is now known as dandrader | ||
| attente | is gtk supposed to be receiving a resize event when the window appears? or should gtk be querying this manually? | 15:50 |
| alan_g | attente: the resize events are mostly useless as they are not synced with the size of the buffer. The buffer has a size which is accurate. | 15:55 |
| attente | alan_g: but the resize events are still useful for checking when the buffer size changes, no? | 15:57 |
| alan_g | attente: well, if the size doesn't match the buffer, then there is a possibility that you'll get a buffer of a different size after a few swaps. (Unless there's another resize first) | 15:58 |
| alan_g | Not sure how useful that is though. | 15:58 |
| attente | alan_g: ok, so the buffer size is authoritative basically... | 15:59 |
| attente | alan_g: thanks | 15:59 |
| attente | this is a bit annoying that we have to keep track of the size and synthesize the gdk event when it changes, but should be manageable | 16:02 |
| alan_g | kdub: ^^ anything to add for NBS? | 16:05 |
| === dandrader is now known as dandrader|afk | ||
| greyback | attente: I can say from the Qt side, we totally ignore the mir resize event. It arrives at an arbitrary time. It would be far more useful if it arrived, and then you were guaranteed the next buffer you swap has that size. | 16:49 |
| greyback | we go by the buffer size instead | 16:49 |
| greyback | which is not ideal | 16:49 |
| attente | greyback: ok, thanks for the info. in the end i don't see it being too much of a problem | 16:50 |
| * alan_g thinks we should never have provided resize events. Then people wouldn't try to use them. | 16:51 | |
| * attente shrugs | 17:00 | |
| greyback | I see value in resize events, but only if they arrive at the right time | 17:01 |
| attente | if this is the concern, why not deprecate them? | 17:01 |
| kdub | oh, resize events make sense now | 17:02 |
| kdub | they're a notification that the shell has redesignated the size, and the client is in control of the physical size of the buffers | 17:03 |
| kdub | and lets the client figure out how its subscene should get resized | 17:03 |
| attente | kdub: what if the client decides to set the buffer size to something different from the resize event's size? | 17:05 |
| greyback | kdub: what if client creates buffers of sizes that the shell didn't decide on? | 17:05 |
| greyback | heh, same question, different epxression | 17:05 |
| attente | :) | 17:05 |
| greyback | only real buffer management qtubuntu is doing is via egl swap buffers | 17:06 |
| kdub | a different physical buffer size isn't a problem, the client arranges its scene via mir_window_spec_set_streams | 17:07 |
| kdub | and the difference is accommodated by the renderer, usually scaling, but guess a renderer could also do clamping or whatever if it wanted | 17:07 |
| kdub | greyback, the new system, when the resize event comes along, its only an indication that the shell has resized the on-screen size | 17:08 |
| attente | but that kind of invalidates the approach we were talking about earlier where we would check the buffer size to reliably determine the window size | 17:09 |
| kdub | and the client calls mir_render_surface_set_physical_size() (soon to be mir_surface_set_physical_size()), and at that point, then the next buffer out of eglSwapBuffers will be the right size | 17:09 |
| greyback | so it is up to shell to confine any client buffers that "mis-behave" | 17:09 |
| kdub | well, the shell is already painting at the size it wants | 17:09 |
| attente | i'm really just looking for a reliable way to know the size we should render at to get no scaling | 17:10 |
| greyback | sure. But as I understood it, clients got a buffer of size whose size the shell decided ultimately | 17:10 |
| kdub | in the new system, the clients are in charge of buffers | 17:10 |
| attente | this is what i thought too, greyback | 17:10 |
| attente | based on what alan_g was saying | 17:11 |
| kdub | so, in the case where there are no sub-surfaces (one surface to one bufferstream) | 17:11 |
| greyback | kdub: ok, new system behaves differently, that's ok. I just wanted to be consider the diffference from the shell's PoV | 17:11 |
| attente | kdub: so does that mean this bug should theoretically fix itself once the new system is in place? https://bugs.launchpad.net/ubuntu/+source/gtk+3.0/+bug/1670390 | 17:11 |
| ubot5 | Ubuntu bug 1670390 in unity8 (Ubuntu) "Desktop applications don't get properly resized when launched in staged mode" [High,In progress] | 17:12 |
| attente | (speaking from a gtk perspective) | 17:12 |
| greyback | attente: that's unity8 only, right? | 17:12 |
| attente | greyback: i'm not sure. but i haven't seen this bug in miral-shell | 17:13 |
| greyback | attente: if not in miral-shell, then probably unity8's fault | 17:13 |
| kdub | re the bug, not sure without thinking harder | 17:13 |
| attente | greyback: i'm just confused about how to reliably get the window size | 17:13 |
| greyback | attente: I'd go with buffer size for now | 17:13 |
| kdub | attente, which window size? :) | 17:13 |
| attente | kdub: the mir window size :) | 17:14 |
| greyback | attente: there is a general problem with unity8 and window resizing, which I think is mainly qtmir's fault (for which I've ideas) | 17:14 |
| attente | kdub: like, should i be expecting it to come from a resize event? or do i have to query it? | 17:14 |
| kdub | sure, the size of the window that the shell designates is comes from the resize callback | 17:14 |
| kdub | right, resize event, no querying | 17:14 |
| attente | kdub: ok, then there's definitely an issue with unity8 not sending the proper resize event when the window appears | 17:15 |
| attente | or in stage mode for that matter | 17:15 |
| kdub | attente, iirc, there's no resize event sent at startup | 17:15 |
| greyback | attente: here is how we're doing it in Qt: http://bazaar.launchpad.net/~phablet-team/qtubuntu/trunk/view/head:/src/ubuntumirclient/qmirclientwindow.cpp#L641 | 17:16 |
| attente | kdub: what's the right thing to do here? query on window creation? or should u8 send a resize event? | 17:16 |
| greyback | attente: look for "handleGeometryChange" <- that is how we notify Qt of the window size change | 17:17 |
| attente | greyback: is it worth doing this if the new system is supposed to send resize events reliably at some point? | 17:18 |
| greyback | attente: I can't answer that, sorry. I can only tell you what works for us now | 17:18 |
| attente | greyback: fair enough, thanks for the pointers. i think i'll eventually just copy what you've already done | 17:19 |
| kdub | i think mir_window_get_parameters at startup to get the initial size the shell said, and after that the callback or you can requery via that function | 17:20 |
| greyback | yep, we do that in qtubuntu, works ok | 17:21 |
| === dandrader|afk is now known as dandrader | ||
| kdub | right, in the old system, server/shell controlled both window size and physical size, in the new system, the server controls window size, and the client controls/owns the physical buffers (and their sizes) | 17:24 |
| greyback | gotcha | 17:24 |
| greyback | kdub: will old system hang around? Or eventually deprecated? | 17:24 |
| greyback | kdub: and roughly on the topic, what about pixel format. If every buffer can have different pixel format, why would Window have that property (ref: https://bugs.launchpad.net/mir/+bug/1666533/comments/9) | 17:25 |
| ubot5 | Ubuntu bug 1666533 in MirAL "Shell wants api to listen for window pixel_format changes" [Medium,Incomplete] | 17:25 |
| kdub | greyback, the old system really only exists in the client api that's being deprecated (internally, things are already plumbed with client-controlled physical sizes) | 17:27 |
| kdub | greyback, windows no longer have pixel format | 17:28 |
| kdub | hmm, might be a missed deprecation there | 17:28 |
| kdub | i guess it says 'to be deprecated soon' in the comments | 17:28 |
| greyback | ok | 17:28 |
| greyback | kdub: from unity8's perspective, something that we be really useful is a notification that a client swapped a buffer with the new size & pixel format, as soon as the client swapped it | 17:31 |
| greyback | s/we/would/ | 17:31 |
| greyback | welll | 17:32 |
| greyback | actually, ignore hat | 17:32 |
| kdub | sure :) | 17:32 |
| greyback | I need to test an idea first. But if that idea fails, I'll be back to you | 17:32 |
| kdub | looking at qmirclientwindow.cpp, mir_buffer_stream_get_egl_native_window is going away soon | 17:33 |
| greyback | kdub: I presume it will get a replacement of similar functionality? | 17:33 |
| kdub | greyback, right, so in the mir-1.0 world, you just plug a MirSurface (formerly MirRenderSurface) into eglCreateWindowSurface | 17:34 |
| kdub | the MirSurface->MirWindow and MirRenderSurface->MirSurface rename in 1.0 makes for confusion when talking about it :) | 17:35 |
| kdub | basically, we've gone from being a server that supports 2 different EGL systems, to being one that has a mir egl platform | 17:36 |
| greyback | yep, the transition made all my old terminology confused | 17:37 |
| kdub | yeah, we also need a grand mir-server-internal rename for it :/ | 17:39 |
| === JanC_ is now known as JanC | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!