| zzarr | hello! duflu, you told me a command to check if a libGLESv2 is compatible with Mir, but I don't remember what it was | 07:27 |
|---|---|---|
| duflu | zzarr: Hi, yes. That is required in theory. I think the first step though is to try and get a Mir server starting. | 07:28 |
| duflu | I suspect it will be blocked by the VT bug on Chromebooks still | 07:28 |
| zzarr | but I have a kernel with a real tty :D | 07:28 |
| duflu | That helps too | 07:29 |
| zzarr | I'll just fix an little issue (no root pass/no sudo) | 07:30 |
| zzarr | duflu, how do I start Mir? (just selecting Unity8 at login?) | 07:35 |
| zzarr | (Unity8-Mir) | 07:35 |
| duflu | zzarr: No, don't start with Unity8. Start simpler: sudo apt-get install mir-demos ; sudo mir_proving_server | 07:36 |
| zzarr | okey, thanks | 07:36 |
| duflu | It will likely fail for some reason. I would be surprised if some dev work wasn't required | 07:36 |
| zzarr | me too | 07:38 |
| zzarr | duflu, mirserver: Selected driver: mir:mesa-kms (version 0.19.1) | 07:59 |
| zzarr | is that sw or hw? | 07:59 |
| duflu | zzarr: Either. Mesa includes both, depending on what hardware drivers match your system | 08:00 |
| duflu | Although all of them will probably fail on your chromebook | 08:01 |
| zzarr | duflu, why? | 08:01 |
| duflu | zzarr: because Mesa does not include a hardware driver that matches you hardware, and Mir does not yet support software | 08:01 |
| duflu | I think.... | 08:02 |
| duflu | Maybe sw will partially work | 08:02 |
| duflu | LLVMpipe should be transparent | 08:02 |
| zzarr | duflu, okey, but I did install a libGLESv2 for the GPU | 08:02 |
| duflu | zzarr: Yeah that might help, or it might confuse Mesa. Not sure which | 08:02 |
| duflu | Mir only knows how to display buffers (windows) from the Mesa drivers. So the Mali one probably won't appear on screen, even if it loads | 08:03 |
| zzarr | I have to fix the network settings.... | 08:03 |
| zzarr | duflu, okey, but is there a way to check if the mesa driver knows about the mali one? | 08:04 |
| duflu | zzarr: You'd need to be an experienced developer to figure it out | 08:06 |
| duflu | Most likely a new driver would need to be written too | 08:06 |
| zzarr | I am an experienced developer... but not in that area | 08:06 |
| zzarr | I'm working with sensors and other stuff, like databases and applications for phones | 08:08 |
| zzarr | duflu, I hope I'm not intruding on your time to much | 08:13 |
| duflu | zzarr: I've been tinkering in graphics for approaching 20 years. And despite being on the Mir team admit I'm not familiar with most driver architectures. You need to be familiar specifically with the Mesa code and/or Android | 08:13 |
| duflu | Oh, approaching 25 years | 08:13 |
| zzarr | nice | 08:14 |
| duflu | zzarr: The key issue will be the buffer sharing approach used. Mir supports Mesa buffers or Android buffers right now. And a libGLESv2 that's specifically for Mali might not understand either. But there's a chance it might understand one of them. | 08:23 |
| duflu | You can find out by checking what OS the libGLESv2 was intended for | 08:25 |
| zzarr | duflu, I know the driver is intended for X11 | 08:28 |
| duflu | zzarr: What does 'ldd' say about it? | 08:28 |
| zzarr | I'll have a looksie | 08:29 |
| zzarr | it says: librt.so.1 libpthread.so.0 libdl.so.2 libstdc++.so.6 libm.so.6 libgcc_s.so.1 libc.so.6 with an => to the path and a /lib/ld-linux-armhf.so.3 at the end | 08:34 |
| zzarr | duflu, is that bad or good? | 08:41 |
| duflu | zzarr: Good, because there are no significant dependencies. But also inconclusive. How about libEGL? | 08:42 |
| * duflu has an interesting thought | 08:46 | |
| duflu | (only one) | 08:46 |
| duflu | If a custom driver for the chipset can be made to work with DRI then we could skip Android completely. That's interesting because Mesa is typically better behaved and performs better than Android | 08:47 |
| zzarr | duflu, the same | 08:47 |
| zzarr | libEGL.so libGLESv1_CM.so libGLESv2.so and libOpenCL.so are all symlinked to libmali.so | 08:48 |
| zzarr | duflu, I like that thought | 08:49 |
| duflu | zzarr: Interesting. I wonder if those binaries or similar are available for use on any Mali devices that mir-team has... | 08:49 |
| zzarr | it's specific for mali 76x but there are drivers for other mali GPU's too | 08:51 |
| zzarr | duflu, can we continue the discussion tomorrow, someone came ;-) | 08:52 |
| duflu | zzarr: OK, bye | 08:52 |
| zzarr | duflu, thanks, bye | 08:52 |
| popey | kgunn: is there any plan to support (in any way) clicks on x86 (desktop or some other device) any time before snappy fixes everything? | 11:12 |
| alan_g | anpok: anything to add? https://code.launchpad.net/~alan-griffiths/mir/discussion-point/+merge/284935 | 11:36 |
| anpok | alan_g: not sure whether it was anything new .. | 12:41 |
| alan_g | anpok: all part of an interesting weave of opinions. Thanks | 12:44 |
| anpok | thought about another sequence.. | 12:45 |
| alan_g | And I don't think A is true of every pair of request on every object. (E.g. submitting buffers isn't sequenced with changing cursors) | 12:46 |
| kgunn | popey: little confused by the question, support clicks on x86 before snappy?....where are clicks not supported that you are hinting at? | 12:51 |
| popey | kgunn: I am unaware of any working way to get Unity8 working on a desktop (assume x86) where one can "pkcon" or "click" install a click package | 12:52 |
| popey | kgunn: it's been broken forever, and last comment I heard was "yeah, wontfix" | 12:52 |
| popey | https://bugs.launchpad.net/ubuntu/+source/click/+bug/1396611 for example | 12:53 |
| kgunn | popey: do you know why that won't work? i mean, i don't know how u8 shell or mir would prevent that | 12:53 |
| ubot5` | Launchpad bug 1396611 in click (Ubuntu) "Cannot install click packages on ISO installs of Ubuntu" [Undecided,Confirmed] | 12:53 |
| popey | ^ is one example why | 12:53 |
| popey | but I have seen others | 12:53 |
| popey | https://bugs.launchpad.net/ubuntu/+source/unity8-lxc/+bug/1466432 | 12:53 |
| ubot5` | Launchpad bug 1466432 in unity8-lxc (Ubuntu) "Cannot install click packages on the unity 8 desktop session" [Undecided,Confirmed] | 12:53 |
| popey | My point in all this is "Should I bother putting x86 clicks in the store, when it's impossible for anyone to install them?" | 12:54 |
| ogra_ | popey, well, they would be available in the emulator, no ? | 12:55 |
| popey | True, that's one other use case I hadn't considered. | 12:55 |
| popey | Hows that working these days? :) | 12:55 |
| ogra_ | no idea | 12:55 |
| kgunn | stahp | 12:55 |
| popey | me either | 12:55 |
| kgunn | popey: i'm kinda tempted to say "that should work" and with the velocity of snap intersecting a "personal" snappy setup, i think it's probably even more so that it should work | 12:57 |
| popey | kgunn: right, but snap!=click. I'm specifically on about clicks here. For the avoidance of doubt. | 12:59 |
| ogra_ | kgunn, well, that woud mean we need to ship the same frameworks by default on desktop ... | 12:59 |
| popey | It should have worked for some time ㋛ | 12:59 |
| popey | But doesn't and hasn't, ever. | 12:59 |
| ogra_ | i'm also not sure how well click is designed for multi-user in its current state | 12:59 |
| kgunn | popey: not sure about worked forever...u8 just got usable | 12:59 |
| popey | no, I am specifically talking about installing clicks | 12:59 |
| ogra_ | (might have all bits it needs, but it was never used in that context before, bugs might be plenty) | 13:00 |
| kgunn | popey: and i know you mean click...which is why people prolly said "won't fix"...believing that snaps would save the universe | 13:00 |
| popey | indeed | 13:00 |
| popey | So I'm inferring from this, that it's not a priority for anyone to make this work as everyone believes (cargo cult style) that snappy fixes this? | 13:00 |
| * ogra_ doubts that click 9is any prio for anyone ... | 13:01 | |
| popey | I mean, no point putting devs on this if snappy does indeed fix it | 13:01 |
| popey | Exactly. | 13:01 |
| kgunn | popey: i wasn't even aware, but yeah i'd agree with you | 13:01 |
| ogra_ | snappy does ... the question is when does it :) | 13:01 |
| kgunn | ogra_: moreover...when does snappy intersect personal-desktop | 13:02 |
| * popey is keen on knowing this also. | 13:02 | |
| ogra_ | kgunn, right ... the graphical side on snappy is still totally blurry | 13:02 |
| kgunn | well, then there's the "break the world of devs" aspect to htat | 13:03 |
| ogra_ | (so its not even desktop or desktop interaction .... if we havent solved the lowest level how can we have the highest working) | 13:03 |
| kgunn | popey: let me at least talk to pat (looks from the bug, that's really his guys) | 13:05 |
| * kgunn needs coffee/toast until then.... | 13:05 | |
| === alan_g is now known as alan_g|lunch | ||
| popey | kgunn: thanks | 13:06 |
| jleen__ | popey, thanks | 13:06 |
| Saviq | hey guys, looks like my powerd or u-s-c locked up, can't get the screen to turn on | 13:41 |
| Saviq | I can ssh to the device | 13:41 |
| Saviq | and powerd-cli list takes maybe 20s to return | 13:41 |
| Saviq | anything interesting here https://paste.ubuntu.com/15001777/ from u-s-c? | 13:44 |
| Saviq | powerd looks much more tame https://paste.ubuntu.com/15001805/ | 13:50 |
| Saviq | bregma, who do you think could have a quick look ↑↑? I'd like to get my phone back :) | 13:50 |
| Saviq | huh, wonder where everything re: display config comes from, this was the phone just working (or well, might be the screen waking up?) | 13:52 |
| Saviq | dednick, greyback_ does https://paste.ubuntu.com/15001777/ look like a lockup you guys saw when reconfiguring displays? | 13:52 |
| * Saviq gets moar symbols | 13:53 | |
| dednick | Saviq: http://pastebin.ubuntu.com/15001827/ | 13:54 |
| dednick | Saviq: not so sure. i think my "lock" was more a 100% process thing. | 13:55 |
| Saviq | dednick, right, and that's unity8, where for me it's u-s-c | 13:55 |
| Saviq | afaict | 13:55 |
| dednick | Saviq: it is u8. no idea what usc was doing at the time. | 13:56 |
| === marcusto_ is now known as marcustomlinson | ||
| === alan_g|lunch is now known as alan_g | ||
| bregma | AlbertA or alf_ can you take a glance at Saviq's stacktrace above re a powerd crasher? ^^^^ | 14:13 |
| Saviq | !crasher | 14:13 |
| Saviq | lockup | 14:13 |
| bregma | *problem | 14:15 |
| alf_ | bregma: At first glance it seems like a problem that anpok may have fixed (deadlock between display and input) | 14:16 |
| alf_ | bregma: anpok ^^ Does this look like the bug you fixed? | 14:16 |
| alf_ | anpok: ^^ | 14:16 |
| greyback_ | Saviq: I've not seen lockup in that location before | 14:19 |
| Saviq | alf_, bregma, anpok, http://pad.lv/1543594 in any case (private since it's retracing) | 14:20 |
| ubot5` | Error: launchpad bug 1543594 not found | 14:20 |
| alan_g | Hmm, SystemCompositorWindowManager::add_display() grabs a lock before accessing output_map, but just above it SystemCompositorWindowManager::remove_surface() erases entries without a lock. | 14:28 |
| alan_g | Saviq: bregma alf_ - there's a failing-to-lock bug in SystemCompositorWindowManager::remove_surface() - could be related to this stack trace. | 14:35 |
| alan_g | bregma: this could be related to Saviq's failure mode. Want it backported to 0.19? https://code.launchpad.net/~alan-griffiths/mir/fix-SystemCompositorWindowManager-remove_surface/+merge/285492 | 14:58 |
| anpok | re | 15:01 |
| anpok | it looks simlar, alf. | 15:02 |
| bregma | if the problem Saviq sees is easily reproduce able, then other people will experience it too, so we want to get a solution out there... problem is is it the input fix or the surface-removal fix? | 15:03 |
| anpok | hm I can only tell with a stack trace... It requires a input dispatch attempt while a display configuration is changed | 15:05 |
| Saviq | bregma, can't say it's easily reproducible, I've had something similar a handful of times, but IIRC it recovered after some time | 15:05 |
| Saviq | anpok, http://pad.lv/1543594 has a symbolic ThreadStacktrace | 15:05 |
| ubot5` | Launchpad bug 1543594 in unity-system-compositor (Ubuntu) "unity-system-compositor locked up in __libc_do_syscall()" [Undecided,New] | 15:05 |
| anpok | only for one thread it seems.. then I cannot tell for sure, at least that stack does not look familar to the problem | 15:10 |
| anpok | still the actual problem might be caused by other threads, not shown in the Stracktrace.txt | 15:10 |
| AlbertA | Saviq: so maybe the same as https://bugs.launchpad.net/canonical-devices-system-image/+bug/1532607 ? | 15:24 |
| ubot5` | Launchpad bug 1532607 in unity-system-compositor (Ubuntu) "Phone not usable while a call comes in - followed by "restart"" [Critical,Confirmed] | 15:24 |
| AlbertA | Saviq: what were you doing before you got the screen to lock up? did you get a notification or call? | 15:24 |
| Saviq | AlbertA, incoming call, couldn't wake the screen, didn't restart by itself though - just locked up permanently | 15:26 |
| alan_g | Saviq: not plugging/unplugging outputs then? | 15:28 |
| Saviq | alan_g, no, just a phone in my pocket with an incoming call | 15:29 |
| Saviq | krillin, too, so no way to connect an external screen | 15:29 |
| AlbertA | Saviq: ok, this at least gives us a lead on the issue :) | 15:29 |
| AlbertA | ok best I Can tell from the stack trace... a message came through Dbus to turn the screen on with reason=proximity... | 15:52 |
| AlbertA | then mir failed to start the compositor for some reason, which invokes the unwind handler | 15:53 |
| AlbertA | which attempts to destroy the threads it just created | 15:53 |
| AlbertA | however, the exception is not propagated to the ThreadPool so no exception is set on the std::future so it waits indefinitely for it. | 15:53 |
| AlbertA | it's still unknown why the compositor thread failed to start however.... | 15:54 |
| * alan_g see "unwind handler" and wonders if the handler in question is safe against the uncaught_exception() bug? | 15:56 | |
| AlbertA | alan_g: which bug would that be? | 15:58 |
| alan_g | AlbertA: back in g++4.x there was a bug that meant uncaught_exception() got stuck on "true" after an exception was thrown | 15:58 |
| AlbertA | ah right | 15:58 |
| alan_g | And Saviq's phone was built with 4.9 | 15:59 |
| Saviq | yup, vivid | 15:59 |
| === alan_g is now known as alan_g|EOD | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!