[06:40] <duflu> RAOF: Did you notice bug 1660017 ?
[06:40] <ubot5> bug 1660017 in Mir "EDID does not change when hotplugging a monitor" [Medium,New] https://launchpad.net/bugs/1660017
[06:40] <duflu> I know it's almost EOD
[06:42] <RAOF> Huh.
[06:42] <RAOF> I did not.
[06:46] <duflu> (assuming hotplugging does not crash the server, which still happens but I have not clearly described in any recent bug)
[06:53] <RAOF> I am confused.
[06:54] <RAOF> We're using the functions documented as doing a full hardware probe.
[07:04] <RAOF> ????
[07:04] <RAOF> EOD
[09:43] <alan_g> duflu: as you've poked around Xmir, maybe you know the answer... I'm trying to use it in a snap, (where nothing is ever on the default path) and it can't find sxkbcomp. I can see it holds the format string "%s%sxkbcomp" -w %d %s -xkm "%s" -em1 %s -emp %s -eml %s "%s%s.xkm", but is there a way to set the first %s field? (A quick look at the code suggests it's a build-time constant, but I'm hoping I missed something.)
[09:45] <duflu> alan_g: Did you build Xmir or copy from archive?
[09:46] <alan_g> from archive
[09:46] <duflu> (The trick to avoid similar issues when building Xmir is to configure with --prefix=/usr)
[09:48] <alan_g> duflu: it needs to be (at runtime) %SNAP/usr
[09:48] <duflu> alan_g: No idea then sorry
[09:48] <duflu> Oh
[09:48] <alan_g> But I guess you've confirmed that it's set at build time
[09:48] <alan_g> thanks
[09:48] <duflu> alan_g: Maybe this is the same problem in reverse. You need to build Xmir with --prefix=<replacement for /usr>
[09:49] <alan_g> At build time we don't know %SNAP
[09:49] <duflu> Yep. Xorg code is a bit older than that
[09:51]  * duflu looks at the source
[09:53] <duflu> alan_g: Looks easily configurable. The first %s is the bin dir and the second is forward or backslash
[09:53] <duflu> I could do that.
[09:55] <alan_g> ack, But it isn't a priority (ATM), and likely not the last blocker.
[09:56] <duflu> alan_g: Are you suggesting the first %s is empty or non-empty and wrong?
[09:57] <duflu> Looks like building with empty should work (and default to $PATH)
[09:57] <alan_g> No, the first % is /usr and is wrong in a snap
[09:57] <alan_g> it needs to be (at runtime) %SNAP/usr
[09:57] <duflu> alan_g: Yeah looks like the source is written to nicely handle NULL and search the path, but our builds are hardcoded
[09:59] <alan_g> I was hoping that I'd missed an env variable or similar (windows has winFixupPaths()).
[09:59] <duflu> alan_g: Sounds easy to test and fix. I'll just stop using the --prefix workaround and see what works then. Sadly there is no environment. It's popen'd with an optional hardcoded bin path
[10:00] <alan_g> that's what I thought. :(
[10:01] <duflu> It stumped me too. When I first looked at Xmir it didn't work because the default build uses /usr/local for it which is wrong on Ubuntu
[10:01] <duflu> I never changed any release build parms, just have a technique for building it in development.
[10:02] <duflu> alan_g: Tomorrow. Now; dinner
[10:02] <alan_g> duflu: Have a good one!
[10:02] <duflu> o/
=== hikiko is now known as hikiko|ln
[11:51] <alan_g> greyback: starting to think about D&D support. Where are the "drag start, drag move & drop events" initiated (a toolkit API mir_window... call?) handled (a server interface?) and delivered (a toolkit MirWindowEventCallback event?)
[11:56] <greyback> alan_g: to begin, have you seen this doc? https://docs.google.com/document/d/1IztlvbrJHmvLe3im1xe5WIKHkh4-SlBguokBCgXMgLo/edit#
[11:57] <alan_g> greyback: was skimming docs but lacking overview. That's the starting point?
[11:58] <greyback> alan_g: IMO yeah. It was roughly what we agreed on at the sprint in Montreal
[11:59] <alan_g> greyback: thanks, will read before bugging you again
[11:59] <greyback> alan_g: np
[12:06]  * alan_g wonders how to represent "list of drag surfaces + origins"
=== hikiko|ln is now known as hikiko
[12:53] <dandrader> alan_g, does a mir_buffer_stream_swap_buffers_sync ever time out? I'm debbuging a situation where I have an internal client (mirclient run in a thread) gets stuck in mir_buffer_stream_swap_buffers_sync() forever while because server is unable to drop buffers from it. that all happens when I'm trying to close that client.
[12:55] <alan_g> dandrader: no timeout AFAIK
=== dandrader is now known as dandrader|afk
=== dandrader|afk is now known as dandrader
[14:23] <alan_g> greyback: quick one I see "A list of drag surfaces + origins" in one of the diagrams. Is this buffer stream(s) + hotspot(s)? Why is there a list?
[14:24] <greyback> alan_g: list because multiple items may be selected, and we thought it made sense to allow shell to decide how those items can be laid out
[14:25] <greyback> we've not had much design input until recently
[14:25] <greyback> alan_g: this is all I know: https://docs.google.com/presentation/d/1NEcPwodymSAjvsUGWlDx7ocDLhs41edkPGq_MsA_BdM/edit#slide=id.g19dd5d1a07_2_23
[14:26] <greyback> alan_g: also note there is a process diagram in there, which differs to the one in the doc I gave you. The differences have yet to be figured out and clarified
[14:26] <greyback> I'm doing that right now actually
[14:28] <alan_g> ack
=== dandrader is now known as dandrader|afk
=== dandrader|afk is now known as dandrader
=== dandrader is now known as dandrader|afk
=== dandrader|afk is now known as dandrader