[02:12] <shiznix> hi all, as XMir has been broken on Intel gfx hardware for some time now on Ubuntu's latest stable offering, i was hoping to try a dev snapshot of the xmir patch for the intel gfx driver
[02:13] <shiznix> however i'm chasing my tail trying to find which project is hosting this
[02:16] <shiznix> it's not in lp:mir and it's not in lp:xserver-xorg-video-intel
[02:17] <shiznix> aah, might be in git://people.freedesktop.org/~mlankhorst/xserver
[02:22] <tmpRAOF> shiznix: Broken on Intel? I've not tested particularly recently, but I also wasn't aware of any change that might have broken it.
[02:23] <shiznix> hi tmpRAOF
[02:23] <shiznix> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1450581
[02:23] <ubot5> Ubuntu bug 1450581 in xserver-xorg-video-intel (Ubuntu) "Hardware accel causes X segfault with SNA renderer" [High,Confirmed]
[02:23] <shiznix> and related https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1420959
[02:23] <ubot5> Ubuntu bug 1420959 in xorg-server (Ubuntu) "xmir crashes when launching chromium" [Undecided,Confirmed]
=== tmpRAOF is now known as RAOF
[02:25] <shiznix> only crashes if GL is used
[02:26] <RAOF> Hm, DRI2CopyRegion.
[02:26] <RAOF> Yeah, that'd be right; if that's buggy you'd hit it whenever something tried to be accelerated.
[03:05] <duflu> shiznix: We know XMir 1.0 (the version in Ubuntu) has a number of bugs (https://bugs.launchpad.net/xmir). Although it's worth noting that 1.0 is not being maintained. An entirely new 2.0 implementation is coming soon (never before seen in any Ubuntu release)
[03:11] <robert_ancell> Does anyone know why XMir is using DRI2 and not DRI3?
[03:17] <RAOF> robert_ancell: Two reasons - (1) we don't enable DRI3 on any of our drivers, and (2) because DRI3 has a buffer model that's incompatible with Mir.
[03:17] <robert_ancell> RAOF, does that mean we can never use DRI3 with Mir?
[03:18] <RAOF> robert_ancell: No, but we lose some performance optimisations.
[03:19] <RAOF> If DRI3 support for XMir becomes a required feature then we can do that.
[03:23] <duflu> robert_ancell: You're looking at Maarten's XMir 2.0 right?
[03:23] <robert_ancell> duflu, well, there's no versioning but the stuff from the git branch. Trying to clean it up and work out what could be upstreamed easily.
[03:24] <robert_ancell> The DRI2 code is quite complex and I suspect upstream only really cares about DRI3
[03:24] <duflu> robert_ancell: Yeah I know. git means 2.0, while the one in distro is 1.0. As they're entirely different codebases we need to avoid confusing people and ourselves
[03:25] <duflu> Even within the XMir project, the code tab points to 2.0 and the bugs tab points to only 1.0 bugs :P
[03:26] <duflu> When I first raised the issue Maarten didn't think anything was confusing about that
[04:14] <shiznix> duflu: i see thanks - is the 2.0 implementation useful enough for testing yet ?
[04:14] <duflu> shiznix: It is indeed good, but hiding in a git repo you have to build it yourself :S
[04:15] <shiznix> that's ok, you got the repo link ?
[04:15] <duflu> shiznix: It will produce an "Xmir" binary as well as all the normal binaries: git://people.freedesktop.org/~mlankhorst/xserver
[04:16] <shiznix> aha thank you
[04:16] <duflu> shiznix: And this one is windowed (ie. one Xmir server per client) so you need to provide your own Mir server like those in package mir-demos
[04:17] <duflu> It's not a desktop replacement like Xmir 1.0 was
[04:17] <duflu> Just runs X apps in an existing Mir server
[04:20] <shiznix> ok i understand
=== chihchun_afk is now known as chihchun
=== chihchun is now known as chihchun_afk
=== chihchun_afk is now known as chihchun
=== chihchun is now known as chihchun_afk
=== chihchun_afk is now known as chihchun
=== alan_g is now known as alan_g|vt
[09:16] <alan_g> duflu_: the good news is that I can run the archive glmark in my locally built and installed mir_performance_tests and it all works. (The bad news is I don't yet know what happens in CI)
[09:17] <alan_g> It correctly picks up the archive libmirclient.so.8 & libmircommon.so.3
[09:17] <alan_g> greyback_: are we there yet?
[09:17] <greyback_> alan_g: building locally to make sure
[09:18] <duflu_> alan_g: Yeah it should. Probably LD_LIBRARY_PATH is in the way in CI
=== duflu_ is now known as duflu
[09:21] <alan_g> It's reassuring that the code works. It is just down to the way CI installs & runs things (or a packaging error)
[09:31] <duflu> alan_g: In fact it probably has to be LD_LIBRARY_PATH; just make sure glmark2 doesn't have that set
[09:33] <alan_g> duflu: surely LD_LIBRARY_PATH would either stop it finding any .so or let it find the right one?
[09:35] <duflu> alan_g: Wait, no. That's rubbish. There's only one libmirclient.so.8 and one libmirclient.so.9 on the system. It's not possible to confuse them :S
[09:36] <alan_g> Hold on! What's mir-0.13.0 doing here? "/tmp/buildd/mir-0.13.0bzr2570pkg0vivid2371+autopilot0/tests/performance-tests/test_glmark2-es2-mir.cpp:63: Failure"
[09:37] <alan_g> nm
[09:38] <alan_g> For a moment I thought the error was from the glmark build
=== sturmflut2 is now known as sturmflut_
[09:40] <duflu> alan_g: Exactly. The installed version has libmirclient8 and the build version libmirclient9. They should not be confused
[09:40] <greyback_> alan_g: pushed
[09:40] <alan_g> greyback_: thanks
[11:03] <alf_> alan_g: @fix-1454128-by-getting-select_active_surface-right, was calling input_targeter->clear_focus() and session_coordinator->unset_focus() when we didn't have focus causing problems, or is it a performance optimization?
[11:08] <alan_g> alf_: not causing a problem as such, but it was easier to make the expectation efficient than keep that behaviour
[11:09] <alf_> alan_g: ok
=== alan_g is now known as alan_g|lunch
=== sturmflut_ is now known as sturmflut
=== alan_g|lunch is now known as alan_g
[13:03] <alan_g> davmor2:  FYI @silo-021 - problem fixed and updated to pick up latest qtmir
[13:04] <davmor2> alan_g: yeap saw the ticket come through thanks
=== dandrader is now known as dandrader|afk
=== dandrader|afk is now known as dandrader
[13:47] <alan_g> alf_: do the end-to-end input tests need to be in separate processes? Or could we run everything in a single process?
[13:49] <greyback_> hey folks, dandrader & I have a query. We're testing mir_proving_server with simple Qt clients. If I bring up mir_proving_server as root via ssh, launch the qt app, then Ctrl+C it, mir_proving_server crashes
[13:49] <greyback_> but if I do the same in VTs, it works ok
[13:49] <greyback_> any ideas?
[13:50] <kdub> well, its still using a vt via ssh, right?
[13:50] <kdub> sounds like that shouldn't happen though
[13:51] <greyback_> yeah, it's weird, I don't know why the difference
[13:51] <alan_g> Sounds odd. For elimination purposes do ou see the same with mir_demo_server?
[13:51] <alan_g> s/ou/you/
[13:52] <alan_g> So you've detached mir_proving_server to start the client?
[13:52] <alan_g> Dunno why it would even see Ctrl-C in that case
[13:53] <alan_g> One possible difference is that the serve will be halted by switching away from the VT. So shutdown might be easier
[13:53] <greyback_> aaand now it worked fine
[13:54] <greyback_> aha
[13:54] <greyback_> I resized the application window, then Ctrl+C
[13:54] <greyback_> crash
[13:54] <greyback_> so it's unrelated to ssh vs VT
[13:55] <alan_g> Ctrl+C on the ssh session? Or on the Mir session?
[13:56] <greyback_> alan_g: neither, on the client
[13:57] <alan_g> You SIGQUIT the client and the server dies?!
[13:58] <greyback_> yeah
[13:58] <greyback_> logging bug
[13:59] <alan_g> But not if you don't resize the client window first?
[14:00] <alan_g> It seems too mad to be true
[14:00] <alan_g> is this archive or trunk or some other?
[14:01] <greyback_> archive, 0.12.1
[14:03]  * alan_g tries it
[14:04] <greyback_> alan_g: https://bugs.launchpad.net/mir/+bug/1454714
[14:04] <ubot5> Ubuntu bug 1454714 in Mir "mir_proving_server crash if resize qt client window and then quit" [Undecided,New]
[14:04] <greyback_> how do I attach a .crash file output to a bug, I keep forgetting this command
[14:05] <alan_g> Me too
[14:06] <alf_> alan_g: @end-to-end-input-tests, (I am assuming you mean the servers) We could run them in a single process, but I want to create an environment as similar to the production one as possible
[14:13] <alan_g> greyback_: I've been trying with mir_demo_client_multiwin and not seen a crash.
[14:14] <greyback_> alan_g: yeah, seems it needs to be a qt client
[14:14] <greyback_> it may be doing something "wrong"
[14:14] <greyback_> but even so, it shouldn't crash the server
[14:14] <alan_g> +1
[14:15] <alan_g> Just wanted to confirm
[14:15] <greyback_> how the heck do I attach this damn crash file to the bug!
[14:17] <alan_g> What am I missing? 'This application failed to start because it could not find or load the Qt platform plugin "ubuntumirclient".'
[14:18] <greyback_> alan_g: qtubuntu-desktop
[14:21] <alan_g> greyback_: I've not tried with ssh yet (need to unearth laptop for that) but still not seeing a crash.
[14:22] <greyback_> alan_g: seems myself & dandrader can repro quite reliably. You using mir 0.12.1 or something newer maybe?
[14:23] <tedg`> kgunn, FYI, might be worth sending someone: http://wiki.linuxplumbersconf.org/2015:graphics_modesettings_wayland
[14:26] <alan_g> greyback_: whatever's in vivid (without ppa)
[14:26] <greyback_> alan_g: ok, we on same page so
[14:27] <dandrader> greyback_, about  https://bugs.launchpad.net/mir/+bug/1454714. building mir_proving_server myself and running it under gdb made that crash go away
[14:27] <ubot5> Ubuntu bug 1454714 in Mir "mir_proving_server crash if resize qt client window and then quit" [Undecided,New]
[14:27] <greyback_> dandrader: and running without gdb?
[14:28] <dandrader> greyback_, don't know. let me reboot it. the laptop froze
[14:32] <greyback_> https://bugs.launchpad.net/ubuntu/+source/mir/+bug/1454724 should have backtrace attached soon
[14:32] <ubot5> Ubuntu bug 1454724 in mir (Ubuntu) "mir_proving_server crashed with SIGSEGV in __pthread_mutex_unlock_usercnt()" [Undecided,New]
[14:32] <dandrader> greyback_, yeah, the mir_proving_server I built myself with a debug config doens't crash also when run outside gdb
[14:32] <dandrader> greyback_, but the packaged one does
[14:32] <alan_g_> greyback_: when I ssh and try it I get "(qmlscene:25883): Gtk-WARNING **: cannot open display: " and the test exits. (the mit client is fine)
[14:33] <dandrader> alan_g_, run with sudo
[14:33] <dandrader> alan_g_, I also can't get qmlscene to run without being root :/
[14:33] <greyback_> alan_g: please remove "appmenu-qt5"
[14:34] <greyback_> that uses gtk, which tries to do X stuff
[14:34] <alan_g_> Git it
[14:34] <alan_g_> s/i/o/
[14:35] <alan_g_> and broke the server
[14:36] <greyback_> ok, glad it's not just here
[14:36] <alan_g_> And broke VT switching. :(
[14:38] <greyback_> I can recover doing "sudo X" and then killing it from another ssh session
=== chihchun is now known as chihchun_afk
=== Benno-007 is now known as Guest73908
=== sturmflut is now known as sturmflut2
=== Guest73908 is now known as help
=== help is now known as Guest89225
=== Guest89225 is now known as Benno-007
=== dandrader is now known as dandrader|afk
[15:36] <alan_g_> !ssh
[15:36] <ubot5> SSH is the Secure SHell protocol, see: https://help.ubuntu.com/community/SSH for client usage. PuTTY is an SSH client for Windows; see: http://www.chiark.greenend.org.uk/~sgtatham/putty/ for it's homepage. See also !scp (Secure CoPy) and !sshd (Secure SHell Daemon)
=== dandrader|afk is now known as dandrader
=== alan_g is now known as alan_g|EOD
=== dandrader is now known as dandrader|afk
=== dandrader|afk is now known as dandrader
[19:17] <racarr> hmm does anyone else find the wizard really difficult
[19:17] <racarr> to complete all of a sudden
[19:17] <racarr> I just failed to swipe the launcher from the left according to its heuristic like
[19:17] <racarr> well for a bout a minute straight lol
[19:17] <racarr> I mean everything visually seemed fine but the wizard wouldnt advance
[19:21] <kdub> phablet-config welcome-wizard --disable
[19:21] <kdub> s/welcome-wizard/edges-intro
[19:23] <racarr> kdub: Aha yeah I was just wondering if we broke it..
[19:24] <kdub> eh, i havent noticed, I'd guess unlikely that we did
=== Benno-007 is now known as Guest82717
=== Guest82717 is now known as Benno-007