[03:18] <duflu> RAOF: mirout is only printing half my EDID (compared to xrandr --verbose). I wonder if it's useful to have a length value without having to interpret bytes?
[03:19] <RAOF> duflu: I did think about that. The only time it's interesting is to a client that is unable to parse the EDID but, for some reason, wants to store it?
[03:19] <duflu> RAOF: Yes indeed. Or a user who wants to copy and paste into a decoder
[03:19] <RAOF> If they want to do that they can just read /sys/class/drm/$CONNECTOR/edid
[03:20] <RAOF> In a much more friendly fashion.
[03:21] <RAOF> parse-edid /sys/class/drm/$CONNECTOR/edid is going to be much easier to do than taking the output of mirout, stripping off the whitespace, converting back to binary, and dumping it into parse-edid.
[03:21] <duflu> RAOF: Is there a whole length field or is it incremental?
[03:21] <RAOF> The second-last byte is the number of extensions which follow. I'm not sure if all extensions are fixed-size, though.
[03:22] <RAOF> So there is indeed no single length field.
[03:22] <RAOF> And it's anywhere up to 32K
[03:22] <duflu> Strange also DRM can't get subpixel order from my Dell
[04:08] <RAOF> duflu: If you care, lp:~raof/mir/dump-edid-size
[04:09] <duflu> Maybe. Working on that topic right now
[04:11] <RAOF> Then maybe you'd like to review https://code.launchpad.net/~raof/mir/dump-edid-size/+merge/312223 :)
[04:13] <duflu> RAOF: I'll let yours land. I have a branch that adds text (but will improve it after lunch)...
[04:13] <duflu> Output 48: DisplayPort, connected, "DELL U2413", 1920x1200+0+0, enabled, on, 520mm x 320mm (24.0"), normal, 1.00x, unknown, monitor
[04:13] <RAOF> Ah, parsing out the name? Sure.
[04:31] <RAOF> This is the point at which I wish we had a comprehensive set of failure tests.
[05:15] <RAOF> Also a proper RPC debugger.
[05:22] <RAOF> Oh, right.
[05:33] <RAOF> This fails because we don't have any eventloop in place.
[05:52] <RAOF> And now, when you I both actually pump the eventloop *and* don't use freed data, things work better.
[06:40] <RAOF> Oh, yay! I *wrote* a bunch of failure tests in the past.
[06:40] <RAOF> Thanks, past, me!
[11:19]  * alan_g has miral-shell running on Unity8/X+O
[11:35] <romex_> oh cool, mir0.25 works fine
[11:39] <alan_g> for what?
[11:43] <romex_> for recording the screen, with 0.24.1 on 17.04 (mirscreencas | ffmpeg) although it did record, the video was showing only the first frame
[11:44] <romex_> hm.. and unity8 works, does it already use miral?
[11:46] <romex_> oh and i'm using hexchat snap on unity8 /17.04 now
[11:47] <anpok> iirc there is a test sio right now that integrates the qtmir/miral integration for unity8
[11:48] <anpok> that mp has it.. https://code.launchpad.net/~unity-team/qtmir/miral-qt-integration/+merge/310001
[11:49] <romex_> http://i.imgur.com/mkEATx8.png
[11:51] <romex_> i have #2180 installed https://bileto.ubuntu.com/#/ticket/2180
[11:52] <romex_> interesting, unity8 is becoming usable :D so i took a screen shot, launched firefox dev from the container, uploaded to imgur, copy the link, alt tab to hexchat snap, and paste the link
[11:53] <romex_> hm.. now to get the child windows working, this will make me cry
[11:54] <alan_g> greyback: can you advise? ^^
[11:57] <greyback> romex_: unity8 not quite yet using miral, we have a silo2160 with that implemented but child window support isn't in there yet
[11:57] <romex_> https://code.launchpad.net/~dandrader/unity8/miral
[11:57] <romex_> this, so.. i'll have to compile u8?
[11:57] <romex_> do i need anything else?
[11:58] <greyback> romex_: that is pre-built in silo 2160
[11:58] <romex_> oh this https://code.launchpad.net/~dandrader/unity8/miral
[11:58] <greyback> https://bileto.ubuntu.com/#/ticket/2160
[11:58] <romex_> sorry wrong c/p
[11:58] <romex_> Unity8 CI Bot: Needs Fixing (continuous-integration) 16 hours ago
[11:59] <romex_> thanks greyback
[11:59] <greyback> to be expected, as branch depends on a unity-api change
[11:59] <greyback> romex_: don't expect child windows to work with that!
[11:59] <greyback> it's a very work-in-progress silo still
[12:00] <romex_> but but daniel had it working, bu then again he knows what he's doing
[12:00] <romex_> ok then, i'll just wait to land it in a silo :D
[12:02] <romex_> for me unity8 is almost ready :D
[12:02] <romex_> i have child windows i think i'll try to move away from unity7
[12:02] <romex_> and try to report more u8 bugs
[12:10] <greyback> romex_: yep, daniel had it working, but it needs lots of polish yet before we it can be shared
[13:08] <alan_g> greyback: after QA tried testing miral under Unity8 I started wondering about how that might work. The main blocker I see is that U8 will interpret a lot of user interactions and not pass them to the "application". Is that likely to changes, or is this just an unsupported scenario?
[13:09] <greyback> alan_g: can you give me some examples of this blocker?
[13:09] <alan_g> Dragging
[13:10] <greyback> and when did QA test miral&unity8?
[13:10] <alan_g> yesterday
[13:12] <alan_g> Seems that if the test plan doesn't say "try this on a non-virtual machine running Unity7" they get inventive
[13:12] <greyback> ah, now I follow you, running miral shell in a window inside unity8
[13:12] <greyback> :D
[13:13] <greyback> dragging should just work, all the mouse events should be delivered to the client
[13:13] <greyback> but apparently not
[13:13] <greyback> I'll give it a look
[13:13] <alan_g> You'll need a MP I just put up
[13:14] <alan_g> https://code.launchpad.net/~alan-griffiths/miral/basic-Unity8-compatibility/+merge/312246
[13:15] <greyback> ok
[13:15] <alan_g> I guess I need a polite way to say "if Mir doesn't work on a configuration don't bother testing MirAL on it"
[13:16] <alan_g> /sigh
[15:02] <greyback> alan_g: for some reason, the miral makes itself fullscreen when I try it on unity8 here. Any idea why?
[15:03] <alan_g> greyback: that's Mir's "nested server" - it assumes that it takes over the outputs. Bug 1646449
[15:05] <alan_g> In the distant (and recent) past that made sense - the only nesting was inside USC
[16:10] <greyback> alan_g: sorry for delay, too many distractions. I've booted to unity8, run "miral-desktop -socket ${XDG_RUNTIME_DIR}/not_mir_socket -launcher qterminal" and I get fullscreen miral with qterminal working inside it. I can drag the window around, and drag the scroll bar inside it
[16:11] <alan_g> greyback: OK, cool. Is that the release version of the stack or development? (I was using X+O)
[16:11] <greyback> alan_g: this is zenial
[16:11] <greyback> updated just before trying
[16:11] <alan_g> zesty?
[16:12] <greyback> bleh, yes
[16:13] <greyback> darn linguistic redundancy
[16:18] <alan_g> greyback: I've got a machine on zesty, but can't log into the U8 session on it.
[16:19] <alan_g> Mostly because the greeter doesn't display and I'm typing blind
[16:19] <greyback> alan_g: maybe remove the unity8 greeter and install the old "unity-greeter" ?
[16:22] <alan_g> it is the unity-greeter
[16:22] <alan_g> Maybe I should try the unity8 one
[16:34] <alan_g> greyback: while I'm distracting you. I can't reproduce locally, but any thoughts on this? https://bugs.launchpad.net/miral/+bug/1646532
[16:38] <greyback> alan_g: worked for me on today's Zesty
[16:38] <greyback> trying my xenial box
[16:39] <greyback> yep, ok there too.
[16:39] <alan_g> thanks, I'm wondering if there's a "missing" dependency I have installed
[16:39] <greyback> alan_g: qtubuntu-desktop installed?
[16:40] <greyback> I'd expect some error output from qt at least
[16:40] <alan_g> according to the test case
[16:41] <greyback> am unsure, it all looks legit
[16:41] <greyback> he inside a VM?
[16:42] <alan_g> greyback: I was checking you didn't recognise it. Don't waste time on it
[16:42] <alan_g> Yes, in a VM
[16:42] <greyback> ok
[16:42] <greyback> if VM, qt using gl to draw stuff, might be gl issue
[16:46] <alan_g> Any quick way to vaiidate that guess? (Like one of the Mir demos?)