[04:20] <RAOF> For those playing at home, lp:~raof/mir/mesa-hybrid-support should light up any and all outputs connected to any and all GPUs. Probably; it needs serious cleanup.
[04:55] <duflu> RAOF: What's the expected behaviour if I put a graphics card in an intel desktop and try using both GPUs?
[04:58] <RAOF> duflu: Assuming your bios doesn't disable the intel GPU, you should be able to light up outputs on both GPUs.
[04:59] <duflu> Fancy
[04:59] <RAOF> This was tested on my Intel/AMD/Nvidia desktop :)
[04:59] <duflu> RAOF: Did you get tri-GPU going?
[04:59] <RAOF> (Which has the Intel GPU disabled by the firmware)
[04:59] <duflu> Oh
[04:59] <RAOF> I should see if I can turn it on.
[05:00] <RAOF> I don't have a third monitor though.
[05:00] <RAOF> Hm. Could try a projector.
[05:00] <RAOF> Hm. I actually don't need a third monitor...
[05:01] <duflu> Conveniently I have two Nvidia cards on the desk, for lack of better storage choices
[05:01] <RAOF> If I can convince the Intel to be the primary device, even though it's got no displays connected, then I'd be rendering on the Intel and displaying on the radeon and nvidia cards...
[09:55] <alan_g> Saviq: @bug 1665123 is Unity8 running on the h/w or using a host USC(?) server?
[10:00] <duflu> alan_g: Have you heard any news on 0.26.1 making it out of proposed any time soon? Today is feature freeze
[10:01] <alan_g> duflu: MirAL 1.2 (a no-change rebuild failed) just passed QA. Have poked ci-eng.
[10:01] <duflu> alan_g: Thanks. I shall soon EOD with confidence
[10:06] <Saviq> alan_g, there is USC in there, yes
[10:07] <Saviq> and that one's ran from /
[10:07] <Saviq> not from the snap
[10:10] <duflu> Saviq: Another thought on text rendering... if it's being rendered with float glyph offsets then we/Qt may need to ensure the glyph cache contents are at least double the resolution of the rendering (https://en.wikipedia.org/wiki/Nyquist%E2%80%93Shannon_sampling_theorem)
[10:11] <Saviq> duflu, I think what greyback wants to do is the first thing, we're not telling Qt to align properly atm
[10:11] <duflu> Fair enough. More efficient and less work
[10:11] <duflu> Good night
[10:13] <alan_g> Saviq: then that mixing of servers is what breaks the snap.
[10:13] <alan_g> /sigh this brave new snap world has a lot of traps for the architecture we adopted.
[10:24] <Saviq> alan_g, aha, that sounds like something we've missed when designing this...
[10:25]  * alan_g wishes once again that snaps had an overlay-like filesystem
[10:27] <alan_g> Saviq: if we hacked a symlink in for the renamed platform .so it would (I predict) magically start working
[10:27] <Saviq> alan_g, that would make them tied to the host system, which we don't want :)
[10:28] <Saviq> I suppose the "nested" platform is the way to go...
[10:28] <alan_g> No, in the snap link the new name to the old
[10:29] <alan_g> That way the host driver can resolve the .so when loaded in the snap
[10:30] <Saviq> well, sure, but we'd have to maintain a list of symlinks like that ;)
[10:30] <Saviq> maybe that's what we need for now
[10:30] <alan_g> Only until you rebuild the snap with 26.1
[10:31] <Saviq> did that already
[10:32] <Saviq> now we've the opposite problem until 0.26.1 migrates to zesty ;)
[10:33] <Saviq> but this will happen every time we have a SONAME bump in the platform, so we really need to solve this proper
[10:34] <alan_g> It works fine in a .deb world. (And RPM could be fine too.)
[10:35] <alan_g> It's just we're doing stuff that snaps (and AFAICS flatpak) is designed against.
[10:39] <alan_g> Saviq: miral 1.2 is publishing. Did we need anything else to unblock Mir 26.1 on zesty?
[10:42] <alan_g> hikiko: if you've been using the miral::toolkit classes, then you should be aware they're moving to mir::client (in a new libmirclientcpp-dev package)
[10:42] <alan_g> Landing in archive real soon now (I hope).
[10:43] <Saviq> alan_g, no, that's all, thanks
[10:57] <hikiko> thanks alan_g :)
[11:06] <hikiko> alan_g, sorry had to reboot, I am running miral as a server (miral-shell) but I am using libmirclient-dev
[11:06] <hikiko> will I have a problem?
[11:06] <alan_g> nope
[11:06] <hikiko> ok :) thanks a lot!
[13:12] <dandrader> alan_g, have you just released a new miral?
[13:12] <dandrader> alan_g, CI just failed with this: "fatal error: miral/toolkit/connection.h: No such file or directory"
[13:39] <dandrader> alan_g, oh yeah, must be due to https://bileto.ubuntu.com/#/ticket/2476
[13:41] <alan_g> dandrader: yes. New package libmirclientcpp-dev, new names mir/client/connection.h, new namespace mir::client.
[13:41] <dandrader> alan_g, wan't miral supposed to ease the pain of constant api changes...
[13:42] <alan_g> Nope. The pain of constant ABI changes.
[13:45] <dandrader> alan_g, the funny thing is that I wouldn't have this problem is I were using mir directly for those bits
[13:46] <alan_g> dandrader: sorry, I thought ou were in the loop about this change.
[13:46] <alan_g> *you
[13:47] <dandrader> alan_g, I did see the message the other day but was expecting a smoother transition. and not so soo :)
[13:47] <dandrader> *soon
[13:47] <dandrader> miral releases fast!
[13:48] <alan_g> Ack. 1.2 got moved up because Mir cocked up binaries.
[13:48] <alan_g> Se we needed a miral release to unblock Mir 26.1
[15:46] <dandrader> alan_g, where's miral/toolkit/persistent_id.h now?
[15:47] <bschaefer> ./client/mir_toolkit/mir_persistent_id.h
[15:47] <bschaefer> o miral
[15:47] <dandrader> alan_g, ok. bzr told me "RM  include/miral/toolkit/persistent_id.h => include/mir/client/window_id.h"
[15:49] <dandrader> error: ‘for_normal_surface’ is not a member of ‘mir::client::WindowSpec’
[15:50] <alan_g> s/surface/window/g
[15:52] <dandrader> thanks
[16:11] <dandrader> alan_g, with new mir and miral my internal mir client code stopped working
[16:12] <alan_g> dandrader: odd. mine didn't
[16:12] <dandrader> alan_g, the connection returned by mir::client::Connection{mir_connect_sync(...))
[16:12] <dandrader> returns false here: mir_connection_is_valid(m_connection)
[16:13] <dandrader> alan_g, has anything changed there. like the connection string format
[16:13] <dandrader> ?
[16:14] <alan_g> AFAIK
[16:15] <alan_g> *not* AFAIK
[16:19] <alan_g> dandrader: does mir_demo_server work with mir_demo_client...?
[16:22] <dandrader> alan_g, no. http://pastebin.ubuntu.com/24007981/
[16:22] <dandrader> alan_g, I'm missing something it seems
[16:23] <alan_g> mir-graphics-drivers-desktop?
[16:23] <dandrader> alan_g, I have that
[16:24] <alan_g> updated?
[16:24] <dandrader> ohhhhhhh. mir-client-platform-mesa5 is still 0.26.0 for some reason
[16:26]  * alan_g thinks changing a .soname in the middle of a series doubled the problems
[16:26] <dandrader> alan_g, now it works. thanks!
[16:26] <alan_g> yw
[17:29] <alan_g> bschaefer: if you have time and motivation it would be good for someone other than me to try out: https://code.launchpad.net/~alan-griffiths/miral/workspaces-example/+merge/316975
[17:29] <bschaefer> alan_g, yeah i can test it out!
[17:30] <alan_g> thanks!!