/srv/irclogs.ubuntu.com/2016/02/09/#ubuntu-mir.txt

zzarrhello! duflu, you told me a command to check if a libGLESv2 is compatible with Mir, but I don't remember what it was07:27
dufluzzarr: Hi, yes. That is required in theory. I think the first step though is to try and get a Mir server starting.07:28
dufluI suspect it will be blocked by the VT bug on Chromebooks still07:28
zzarrbut I have a kernel with a real tty :D07:28
dufluThat helps too07:29
zzarrI'll just fix an little issue (no root pass/no sudo)07:30
zzarrduflu, how do I start Mir? (just selecting Unity8 at login?)07:35
zzarr(Unity8-Mir)07:35
dufluzzarr: No, don't start with Unity8. Start simpler: sudo apt-get install mir-demos ; sudo mir_proving_server07:36
zzarrokey, thanks07:36
dufluIt will likely fail for some reason. I would be surprised if some dev work wasn't required07:36
zzarrme too07:38
zzarrduflu, mirserver: Selected driver: mir:mesa-kms (version 0.19.1)07:59
zzarris that sw or hw?07:59
dufluzzarr: Either. Mesa includes both, depending on what hardware drivers match your system08:00
dufluAlthough all of them will probably fail on your chromebook08:01
zzarrduflu, why?08:01
dufluzzarr: because Mesa does not include a hardware driver that matches you hardware, and Mir does not yet support software08:01
dufluI think....08:02
dufluMaybe sw will partially work08:02
dufluLLVMpipe should be transparent08:02
zzarrduflu, okey, but I did install a libGLESv2 for the GPU08:02
dufluzzarr: Yeah that might help, or it might confuse Mesa. Not sure which08:02
dufluMir only knows how to display buffers (windows) from the Mesa drivers. So the Mali one probably won't appear on screen, even if it loads08:03
zzarrI have to fix the network settings....08:03
zzarrduflu, okey, but is there a way to check if the mesa driver knows about the mali one?08:04
dufluzzarr: You'd need to be an experienced developer to figure it out08:06
dufluMost likely a new driver would need to be written too08:06
zzarrI am an experienced developer... but not in that area08:06
zzarrI'm working with sensors and other stuff, like databases and applications for phones08:08
zzarrduflu, I hope I'm not intruding on your time to much08:13
dufluzzarr: 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 Android08:13
dufluOh, approaching 25 years08:13
zzarrnice08:14
dufluzzarr: 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
dufluYou can find out by checking what OS the libGLESv2 was intended for08:25
zzarrduflu, I know the driver is intended for X1108:28
dufluzzarr: What does 'ldd' say about it?08:28
zzarrI'll have a looksie08:29
zzarrit 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 end08:34
zzarrduflu, is that bad or good?08:41
dufluzzarr: Good, because there are no significant dependencies. But also inconclusive. How about libEGL?08:42
* duflu has an interesting thought08:46
duflu(only one)08:46
dufluIf 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 Android08:47
zzarrduflu, the same08:47
zzarrlibEGL.so libGLESv1_CM.so libGLESv2.so and libOpenCL.so are all symlinked to libmali.so08:48
zzarrduflu, I like that thought08:49
dufluzzarr: Interesting. I wonder if those binaries or similar are available for use on any Mali devices that mir-team has...08:49
zzarrit's specific for mali 76x but there are drivers for other mali GPU's too08:51
zzarrduflu, can we continue the discussion tomorrow, someone came ;-)08:52
dufluzzarr: OK, bye08:52
zzarrduflu, thanks, bye08:52
popeykgunn: 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_ganpok: anything to add? https://code.launchpad.net/~alan-griffiths/mir/discussion-point/+merge/28493511:36
anpokalan_g: not sure whether it was anything new ..12:41
alan_ganpok: all part of an interesting weave of opinions. Thanks12:44
anpokthought about another sequence..12:45
alan_gAnd 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
kgunnpopey: little confused by the question, support clicks on x86 before snappy?....where are clicks not supported that you are hinting at?12:51
popeykgunn: 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 package12:52
popeykgunn: it's been broken forever, and last comment I heard was "yeah, wontfix"12:52
popeyhttps://bugs.launchpad.net/ubuntu/+source/click/+bug/1396611 for example12:53
kgunnpopey: do you know why that won't work? i mean, i don't know how u8 shell or mir would prevent that12: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 why12:53
popeybut I have seen others12:53
popeyhttps://bugs.launchpad.net/ubuntu/+source/unity8-lxc/+bug/146643212:53
ubot5`Launchpad bug 1466432 in unity8-lxc (Ubuntu) "Cannot install click packages on the unity 8 desktop session" [Undecided,Confirmed]12:53
popeyMy 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
popeyTrue, that's one other use case I hadn't considered.12:55
popeyHows that working these days? :)12:55
ogra_no idea12:55
kgunnstahp12:55
popeyme either12:55
kgunnpopey: 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 work12:57
popeykgunn: 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
popeyIt should have worked for some time ㋛12:59
popeyBut 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 state12:59
kgunnpopey: not sure about worked forever...u8 just got usable12:59
popeyno, I am specifically talking about installing clicks12:59
ogra_(might have all bits it needs, but it was never used in that context before, bugs might be plenty)13:00
kgunnpopey: and i know you mean click...which is why people prolly said "won't fix"...believing that snaps would save the universe13:00
popeyindeed13:00
popeySo 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
popeyI mean, no point putting devs on this if snappy does indeed fix it13:01
popeyExactly.13:01
kgunnpopey: i wasn't even aware, but yeah i'd agree with you13:01
ogra_snappy does ... the question is when does it :)13:01
kgunnogra_: moreover...when does snappy intersect personal-desktop13:02
* popey is keen on knowing this also.13:02
ogra_kgunn, right ... the graphical side on snappy is still totally blurry13:02
kgunnwell, then there's the "break the world of devs" aspect to htat13: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
kgunnpopey: 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
popeykgunn: thanks13:06
jleen__popey, thanks13:06
Saviqhey guys, looks like my powerd or u-s-c locked up, can't get the screen to turn on13:41
SaviqI can ssh to the device13:41
Saviqand powerd-cli list takes maybe 20s to return13:41
Saviqanything interesting here https://paste.ubuntu.com/15001777/ from u-s-c?13:44
Saviqpowerd looks much more tame https://paste.ubuntu.com/15001805/13:50
Saviqbregma, who do you think could have a quick look ↑↑? I'd like to get my phone back :)13:50
Saviqhuh, wonder where everything re: display config comes from, this was the phone just working (or well, might be the screen waking up?)13:52
Saviqdednick, greyback_ does https://paste.ubuntu.com/15001777/ look like a lockup you guys saw when reconfiguring displays?13:52
* Saviq gets moar symbols13:53
dednickSaviq: http://pastebin.ubuntu.com/15001827/13:54
dednickSaviq: not so sure. i think my "lock" was more a 100% process thing.13:55
Saviqdednick, right, and that's unity8, where for me it's u-s-c13:55
Saviqafaict13:55
dednickSaviq: 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
bregmaAlbertA or alf_ can you take a glance at Saviq's stacktrace above re a powerd crasher? ^^^^14:13
Saviq!crasher14:13
Saviqlockup14:13
bregma*problem14: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 before14:19
Saviqalf_, bregma, anpok, http://pad.lv/1543594 in any case (private since it's retracing)14:20
ubot5`Error: launchpad bug 1543594 not found14:20
alan_gHmm, 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_gSaviq: bregma alf_ - there's a failing-to-lock bug in SystemCompositorWindowManager::remove_surface() - could be related to this stack trace.14:35
alan_gbregma: 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/28549214:58
anpokre15:01
anpokit looks simlar, alf.15:02
bregmaif 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
anpokhm I can only tell with a stack trace... It requires a input dispatch attempt while a display configuration is changed15:05
Saviqbregma, can't say it's easily reproducible, I've had something similar a handful of times, but IIRC it recovered after some time15:05
Saviqanpok, http://pad.lv/1543594 has a symbolic ThreadStacktrace15:05
ubot5`Launchpad bug 1543594 in unity-system-compositor (Ubuntu) "unity-system-compositor locked up in __libc_do_syscall()" [Undecided,New]15:05
anpokonly for one thread it seems.. then I cannot tell for sure, at least that stack does not look familar to the problem15:10
anpokstill the actual problem might be caused by other threads, not shown in the Stracktrace.txt15:10
AlbertASaviq: 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
AlbertASaviq: what were you doing before you got the screen to lock up? did you get a notification or call?15:24
SaviqAlbertA, incoming call, couldn't wake the screen, didn't restart by itself though - just locked up permanently15:26
alan_gSaviq: not plugging/unplugging outputs then?15:28
Saviqalan_g, no, just a phone in my pocket with an incoming call15:29
Saviqkrillin, too, so no way to connect an external screen15:29
AlbertASaviq: ok, this at least gives us a lead on the issue :)15:29
AlbertAok best I Can tell from the stack trace... a message came through Dbus to turn the screen on with reason=proximity...15:52
AlbertAthen mir failed to start the compositor for some reason, which invokes the unwind handler15:53
AlbertAwhich attempts to destroy the threads it just created15:53
AlbertAhowever, 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
AlbertAit'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
AlbertAalan_g: which bug would that be?15:58
alan_gAlbertA: back in g++4.x there was a bug that meant uncaught_exception() got stuck on "true" after an exception was thrown15:58
AlbertAah right15:58
alan_gAnd Saviq's phone was built with 4.915:59
Saviqyup, vivid15: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!