[06:59]  * duflu vomits on the boost docs
[07:59] <alf_> RAOF: After the latest saucy updates, any program that uses libglx crashes. Unfortunately this includes firefox, too, so I can't really do a proper search for this problem... Have you seen this?
[08:00] <alf_> mlankhorst: ^^?
[08:02] <alf_> mlankhorst: (btw, this is plain X not XMir)
[08:06] <mlankhorst> no?
[08:06] <mlankhorst> lets see..
[08:06] <mlankhorst> alf_: what card? open or closed d rivers?
[08:07] <alf_> mlankhorst: 5750, r600g, Xorg log: http://paste.ubuntu.com/6174634/
[08:08] <alf_> mlankhorst: EGL works fine (e.g. glmark2 crashes X, glmark2-es2 works fine)
[08:08] <mlankhorst> ok
[08:10] <mlankhorst> wouldn't compiz crash too, then?
[08:12] <alf_> mlankhorst: I am not running compiz
[08:13] <alf_> mlankhorst: my WM doesn't use GL
[08:17] <mlankhorst> alf_: starts for me(TM)
[08:18] <mlankhorst> oh glamor
[08:18]  * mlankhorst installs
[08:21] <mlankhorst> still no issue with glamoregl installed :P
[08:22] <mlankhorst> alf_: can you install xserver.*dbg and xserver-xorg-glamoregl-dbgsym?
[08:22] <alf_> mlankhorst: sure
[08:24] <alf_> mlankhorst: does glamoregl-dbgsym need a special repository?
[08:25] <mlankhorst> yeah ddebs.ubuntu.com
[08:25] <alf_> mlankhorst: thanks
[08:26] <mlankhorst> hm doesn't exist i think, grr
[08:30] <alf_> mlankhorst: the backtrace using xserver.*dbg is not more helpful...
[08:30] <mlankhorst> meh, valgrind? :P
[08:34] <alf_> nick alf|debugging_x
[08:41] <alf|debugging_x> mlankhorst: http://paste.ubuntu.com/6174709/
[08:43] <mlankhorst> string = (const char *) CALL_GetString(GET_DISPATCH(), (name));
[08:44] <mlankhorst> can you try with valgrind? :P
[08:45] <mlankhorst> oh missed a bunch of updates
[08:49] <mlankhorst> hold on updating first then retrying
[08:52] <alf|debugging_x> mlankhorst: the interesting part of the valgrind log: http://paste.ubuntu.com/6174744/
[08:53] <mlankhorst> nope interesting part is the whole log :P
[08:56] <alf|debugging_x> mlankhorst: whole log: http://paste.ubuntu.com/6174771/
[08:58] <alf|debugging_x> mlankhorst: (all of these are produced by starting X and then glmark2)
[08:59] <mlankhorst> hmz, works for me :S
[08:59] <mlankhorst> do you have libgl1-mesa-dri/glx installed correctly?
[09:00] <alf|debugging_x> mlankhorst: I think so, let me --reinstall them
[09:01] <mlankhorst> same with whole of xserver-xorg-core and xserver-xorg-video-radeon to be sure
[09:04] <duflu> alf|debugging_x, mlankhorst, Confirmed -- I get the same valgrind error/crash
[09:04] <duflu> That's relatively new... only must have crept in past couple of weeks
[09:04] <mlankhorst> but I don't :/
[09:04] <mlankhorst> is that with usc?
[09:05] <alf|debugging_x> mlankhorst: not in my case, just plain X
[09:05] <duflu> mlankhorst: Using mir_demo_server_basic and connecting a Xorg to it manually
[09:05] <mlankhorst> hm..
[09:05] <alf|debugging_x> mlankhorst: reinstalled packages, no difference
[09:05] <mlankhorst> something like Xorg :0 & DISPLAY=:0 glmark2 right?
[09:06]  * duflu tries without Mir
[09:06] <alf|debugging_x> mlankhorst: right, here are my package versions http://paste.ubuntu.com/6174795/
[09:06] <mlankhorst> alf|debugging_x: can you remove glamoregl ?
[09:07] <mlankhorst> and meh, same versions here
[09:08] <alf|debugging_x> mlankhorst: removing glamoregl removes video-ati...
[09:08] <mlankhorst> hm indeed
[09:11] <duflu> I don't remember X being this bad in valgrind. Now I get a huge stream of uninitialized jumps from libpixman and the intel DDX
[09:11] <mlankhorst> duflu: oh ignore that
[09:12] <mlankhorst> intel ddx needs valgrind enabled, and it might not have been
[09:12] <duflu> Dear ickle, that's slightly silly
[09:13] <mlankhorst> I mean for valgrind warnings
[09:13] <mlankhorst> but it should work with the most recent versions afaict
[09:14] <mlankhorst> anyway I have no idea what you 2 have in common that glx fails, my system works :/
[09:17] <mlankhorst> even with mir_demo_server_basic, although it has the same bug that cursor has in multimonitor, afaict..
[09:17] <mlankhorst> frames that jump backwards
[09:19] <mlankhorst> it happens when i only run glmark2 in the nested xorg..
[09:23] <duflu> mlankhorst: The jumpy frames fix landed upstream today. Should hit the archive soon enough
[09:23] <mlankhorst> ah k
[09:24] <mlankhorst> anyway running only the versions in the archive doesn't seem to trigger it for me..
[09:31] <alf|debugging_x> duflu: do you get the crash with plain X?
[09:32] <duflu> alf|debugging_x: No. Although my system is all over the place now. Not reliably doing the same thing
[09:41] <mlankhorst> meh could it be from some residual mir stuff?
[11:11] <alf|debugging_x> mlankhorst: @residual mir stuff, I don't think its very likely
[11:11] <mlankhorst> alf|debugging_x: meh I have no idea what's different then :/
[11:11] <mlankhorst> you're on amd64 right?
[11:14] <mlankhorst> alf|debugging_x: oh btw this is for your egl image branch http://paste.debian.net/47487/
[11:14] <alf|debugging_x> mlankhorst: yes
[11:15] <alf|debugging_x> amd64
[11:15] <mlankhorst> afaict that should be the correct paths here, it still doesn't work but it looks like it's because garbage gets copied or something
[11:18] <alf|debugging_x> mlankhorst: thanks
[11:19] <mlankhorst> so I would try without bypass first :P
[11:21] <alf|debugging_x> mlankhorst: I need to fix my development environment first :)
[11:22] <mlankhorst> ok then bypass second, I guess
[11:22] <mlankhorst> O:-)
[12:02] <alf|debugging_x> mlankhorst: it seems that I am getting a NULL struct gl_api table..., i.e. _glapi_tls_Dispatch is NULL
[12:06] <mlankhorst> hm
[12:06] <mlankhorst> that's in fact possible
[12:07] <alf|debugging_x> mlankhorst: arghh... for some reason glx is looking in /usr/lib/dri/... to find drivers, but the drivers are in fact in /usr/lib/x86_64/dri, creating a symlink fixes the problem...
[12:08] <mlankhorst> now THAT is weird :P
[12:08] <mlankhorst> I have no /usr/lib/dri either, but glx works
[12:09] <mlankhorst> dpkg-shlibdeps: warning: debian/libgl1-mesa-dri/usr/lib/x86_64-linux-gnu/dri/radeon_dri.so contains an unresolvable reference to symbol _glapi_tls_Context: it's probably a plugin
[12:09] <mlankhorst> I should probably link radeon_dri against libglapi now
[12:09] <mlankhorst> and the other *_dri.so too
[12:11] <mlankhorst> but that would only affect classic drivers
[12:13] <alf|debugging_x> mlankhorst: before symlinking http://paste.ubuntu.com/6175350/
[12:14] <mlankhorst> hm just why..
[12:15] <mlankhorst> alf|debugging_x: somewhere something is seriously messed up, mesa is built debian/rules:   --with-dri-driverdir=/usr/lib/$(DEB_HOST_MULTIARCH)/dri \
[12:15] <mlankhorst> debian/rules:   --with-dri-searchpath='/usr/lib/$(DEB_HOST_MULTIARCH)/dri:\$$$${ORIGIN}/dri:/usr/lib/dri' \
[12:16] <mlankhorst> do you have anything in your environment?
[12:16] <mlankhorst> env |grep usr.lib
[12:17] <mlankhorst> and ldd /usr/bin/glxgears to make sure the right libgl is used
[12:19] <mlankhorst> In fact you probably have a different libGL, built with static glapi. It's the easiest way to explain why _glapi_tls_Dispatch is NULL..
[12:21] <mlankhorst> same for duflu I guess :P
[12:24] <alf|debugging_x> mlankhorst: you are right, it seems there were /usr/lib/libGL.so* files, but I have no idea where the came from... perhaps some upgrade path is not working correctly?
[12:25] <alf|debugging_x> mlankhorst: thanks for the hint!
[12:26] <mlankhorst> more like ancient mir leftovers, or compiled yourself..
[12:26] <mlankhorst> even precise didn't stuff libGL in /usr/lib any more
[12:27] <alf|debugging_x> mlankhorst: could be, although I had been using this setup without issues before the upgrade
[12:33] <mlankhorst> shrug, maybe during updates it disabled the alternative and added it again, causing it to find the old libgl or something because it was cached?
[12:35] <alf_> mlankhorst: we will probably never know, I am just happy that I have a working system again...
[12:36] <mlankhorst> I'm guessing leftover from egl-image testing:P
[12:41] <mlankhorst> plus a bug in xorg, it seems
[12:42] <mlankhorst> https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1232000
[12:43] <mlankhorst> yep, crashes here too, ok lets fixup that fail..
[12:49] <mlankhorst> alf_: but it looks like the glapi_tls_Dispatch thing is a separate issue :P
[12:50] <mlankhorst> DISPLAY=:0 LIBGL_ALWAYS_INDIRECT=1 glxinfo
[12:53] <alf_> mlankhorst: confirming that glapi_tls_Dispatch is still a problem
[12:53] <alf_> mlankhorst: (confirmed)
[12:53] <mlankhorst> yeah easy to reproduce like that
[12:55] <mlankhorst> normally glapi is pulled in, I guess xorg-server doesn't because it doesn't use libGL
[12:56] <mlankhorst> hm what does it use, though..
[12:59] <mlankhorst> oh no it loads /dri/* directly
[13:13] <mlankhorst> ok one line patch made
[13:20] <mlankhorst> nope, weird stuff :/
[13:32] <mlankhorst> afaict the dri libs deliberately do not link against shared libglapi, and xserver provides its own
[13:55] <mlankhorst> meh :/
[14:01] <davmor2> kgunn: Video of sf vs mir done, uploading to u1 currently will paste the link once complete.  https://pastebin.canonical.com/98152/  stop unity line here throws up the following stop: Unknown job: unity is the command correct and do I just carry on?
[14:02] <kgunn> davmor2: crap...i told you wrong...stop unity8
[14:02] <kgunn> davmor2: also i learned from some chatting on fri
[14:02] <davmor2> kgunn: http://ubuntuone.com/78ciDgDqX8zEZfFAWs5KmW here is the video link it might take a while to download it and it's mov format so it works for me on raring no idea about saucy yet :)
[14:02] <mlankhorst> alf_: wow it looks nasty
[14:04] <davmor2> kgunn:   or not phablet@ubuntu-phablet:/$ stop unity8           stop: Unknown job: unity8
[14:04] <kgunn> davmor2: i learned that for su phablet you want to do....sudo -u phablet -i (instead of just su phablet)
[14:04] <mlankhorst> oh god it's exactly what I thought it was.. damn
[14:04] <davmor2> kgunn: ah right will do
[14:04] <kgunn> davmor2: sorry...should've pinged you when i learned  it :)
[14:05] <kgunn> davmor2: also...i had to totally reboot...to get the state right
[14:05] <alf_> mlankhorst: what did you think it was? :)
[14:05] <kgunn> davmor2: if you've been su phablet'ing
[14:05] <davmor2> kgunn: I wrote down the steps that I've done anyway so I'll just replicate it again with the timings now :)
[14:05] <mlankhorst> alf_: interaction with glamor-egl..
[14:05] <mlankhorst> rm /usr/lib/xorg/modules/libglamoregl.so is a workaround
[14:06] <alf_> mlankhorst: :/
[14:09] <davmor2> kgunn: overall I think mir is a good 20 seconds slower that sf on this fairly simple set of tests.  The biggest ones being app launch, indicator pull down (it's much smoother but slower because of it by the look of things) app switch is slower, rotate is slow on both but worse on mir and I'll retry the commands once the phone is back up
[14:10] <kgunn> davmor2: what  image are you on? (i tried late friday afternoon...and it looked really good)
[14:11] <kgunn> davmor2: but i had seen pretty awful rotation prior to that
[14:11] <davmor2> kgunn: todays
[14:11] <kgunn> w/ mir
[14:11] <kgunn> ah...ok
[14:11] <kgunn> still downloading video...
[14:11] <kgunn> i should watch that first
[14:11] <davmor2> kgunn: rotate is crappy on sf and mir
[14:12] <kgunn> davmor2: oh yeah...and you're on maguro/galaxynexus right ?
[14:12] <davmor2> kgunn: 2 vids first is mir second is sf.  I'm on maguro yes and I'm on image 70
[14:13] <kgunn> i keep forgetting that
[14:14] <kgunn> davmor2: galaxynexus has an omap4460 in it
[14:14] <kgunn> davmor2: i managed the gfx team at ti for 5 yrs
[14:14] <kgunn> davmor2: let's just say...omap4470 was a truly awesome chip...and  i would totally work on a program that used the chip
[14:15] <kgunn> davmor2: omap4460....mmm....well.....
[14:15] <davmor2> kgunn: I have to admit mir is a hell of a lot better just a little slower.  It's still a little jerky on app switch but everything else is really smooth
[14:15] <davmor2> kgunn: haha
[14:15] <kgunn> davmor2: there are some things that really effect gfx/ux there...
[14:16] <kgunn> davmor2: and some secret sauce we don't have access to using binaries
[14:18] <davmor2> kgunn: You can stop with the excuses already, man are you a race driver in your spare time? ;)  No I get there are issues between all the layers that need to be overcome.  There are issues on sf that don't seem to be present on mir and visa versa
[14:19] <kgunn> davmor2: just lots of scar tissue (years of it) listening to people talk/complain about gfx performance that have no clue :)
[14:20] <kgunn> davmor2: so thank you for understanding :) most people just throw rocks instead
[14:25] <davmor2> kgunn: I'm amazed at how stable it has become and how quickly mir has been put together to be honest.   But more import for me is it's this |   | short of being a daily driver :)  rather than this much  |                                             | a couple of weeks back :)
[14:25] <davmor2> typical line breaks in the wrong place but you get the idea ;)
[14:25] <greyback> alf_: alan_g: question for you guys. I need to get the display geometry when a mir server isn't running. You think there's some way to fetch that information without actually running the mir server?
[14:25] <kgunn> davmor2: lol....gonna use ascii art on my progress tracking
[14:26] <alan_g> greyback: what counts as "running"?
[14:26] <greyback> alan_g: I've not started any compositor or event handler - I've not called "run_mir"
[14:29] <alan_g> You can create a configuration object and init part of the system by getting the objects you need. That doesn't start the compositor
[14:29] <alf_> greyback: you could call the_display() to get the display and then get the current configuration, but keep in mind that if you release it the next the_display() call would be a different object
[14:30] <greyback> alf_: that'll probably be enough. Will try
[14:31] <hikiko> hey:)
[14:31] <hikiko> question
[14:31] <hikiko> is the include/share/mir
[14:32] <hikiko> the right place to add an fd wrapper clasS?
[14:32] <alf_> greyback: also note that getting the_display() brings up the display, and releasing it tears it down (i.e. there will probable be visual effects of doing so)
[14:33] <greyback> alf_: this is for autopilot tests to get screen geometry before it starts running the shell. Visual flicker should be ok
[14:33] <alf_> greyback: ok then
[14:34] <greyback> alf_: can you think of any other way I could fetch that information?
[14:34] <alf_> greyback: not really in a platform independent manner
[14:34] <greyback> alf_: ok, I'll try this idea and will see
[14:39] <kgunn> greyback: so that flicker will really only be associated with AP tests...not 100% of boot times
[14:39] <kgunn> ?
[14:39] <greyback> kgunn: only for AP
[14:39] <kgunn> coolio
[14:40] <davmor2> kgunn: https://pastebin.canonical.com/98223/ posted to to phablet by accident, my phone is hating your commands you know :(
[14:41] <kgunn> davmor2: are you cdimage or system ?
[14:41] <davmor2> kgunn: system
[14:41] <kgunn> wonder if writability is an issue...
[14:41] <kgunn> just a thot
[14:42] <davmor2> kgunn: I'll make it rw and try again
[14:42] <kgunn> davmor2: cool....just a guess
[14:45] <alf_> greyback: you could probably avoid any effects by holding the_display() until mir is finished (i.e. after run_mir returns). Mir will reuse the same instance internally in that case.
[14:47] <davmor2> kgunn: No it just hates me https://pastebin.canonical.com/98225/  no the touch command at the end to ensure RW was in play :)
[14:48] <davmor2> s/no/note
[14:48] <kgunn> davmor2: lol...crap
[14:49] <kgunn> davmor2: i admittedly have seen what you see every now and then...i usually suspect myself...and reboot/reflash...and 99% it corrects
[14:49] <kgunn> but wonder if something else is going on there
[14:50]  * kgunn imagines the phone silently hating davmor2  while the screen is off...waiting for him to just hit the power button
[14:52] <davmor2> kgunn: No hit the power button sends it into rage mode I mean it's got power then and everything :)  It quietly hates me while it is turned off :)
[15:02] <mhall119_> kgunn: I'll be a couple minutes late
[15:02] <kgunn> mhall119_: np
[15:04] <davmor2> kgunn: no just hates me https://pastebin.canonical.com/98226/  that's all the commands so you can confirm I'm not missing something
[15:07] <davmor2> kgunn: /me needs to stop playing with this now as I need my phone and I got loads to do, feel free to give me a ping if you figure something out :)
[15:08] <kgunn> davmor2: will do
[15:08] <kgunn> davmor2: i'll try to pester someone else on my team with a galaxy nexus...wonder if we broke something somehow
[15:17] <FunnyLookinHat> I know this isn't the right place to ask about it - but maybe you guys know where it would be?  Wondering about feature-set of Multitouch on Ubuntu w/ touchscreens - specifically, a lack of two-finger scrolling ?
[15:17] <FunnyLookinHat> Wow - I've never typed less of a grammatically correct sentence in my life.
[15:25] <kdub> mir supports multigesture, its up to the shell and the applications to use them
[15:26] <FunnyLookinHat> Ah ok - I'll take my question to #ubuntu-unity :)
[15:49] <racarr> Good morning team mir
[15:53] <davmor2> kgunn: looking at it another good test is to get your contacts on the phone and then scroll through them.
[16:26] <davmor2> kgunn: mir might of introduced an old bug,  open 2 apps, close the one on the left, the one on the right should now replace it.  What is happening for me is it is opening the second app instead
[16:27] <davmor2> kgunn: In fact you know what.  Tomorrow I might try and spend the entire day on mir and see what bugs I hit :)
[16:43] <kgunn> davmor2: all good
[16:43] <kgunn> appreciate it
[16:43] <kgunn> racarr: mornin'
[16:46] <racarr> kgunn: Morning :)
[16:48] <kgunn> ok, gonna take a break and go run...
[16:48] <kgunn> bbiab
[16:53] <racarr> Enjoy :D
[17:03] <kgunn> ok bbiab for real
[17:46] <greyback> racarr: quick question, in case you know it on top of your head: you have 2 apps open. You unfocus. Then one app closes. Does Mir keep the unfocus state, or give focus to the remaining app?
[19:02] <kdub> stupid darn hwc implementations
[19:16] <kdub> exynos5 hwc checks that a garbage value is set in a deprecated field (and fails without error code if not set) just because surfaceflinger sets the field
[19:16] <kdub> -_-
[19:29] <ChickenCutlass> kdub, wow
[19:33] <kgunn> kdub: good old semico software :)
[19:35] <kdub> yeah... grumble grumble
[19:41] <kgunn> racarr: hey, would you mind reviewing https://code.launchpad.net/~gerboland/unity-mir/whitelist-musicplayer/+merge/188387
[19:41] <kgunn> ricmm: or you could ^
[19:42] <kgunn> hot one...of course
[19:42] <kgunn> looks simple tho
[19:42] <kgunn> dandrader: ^ or you could
[19:43] <kgunn> just someone holler as to who's gonna take it
[19:43] <ricmm> looks fie
[19:43] <ricmm> fine*
[19:49] <ricmm> kgunn: I'll do some testing later and I'll get it in trunk before EOD
[19:49]  * ricmm takes it
[20:01] <FunnyLookinHat> Yo guys - it looks like Mir / Unity System Compositor still are only in universe ( not default ) - any idea on when  that's getting tightened up?
[20:10] <FunnyLookinHat> brb
[20:18] <kgunn> racarr: ping
[20:40] <robert_ancell> thomi, are you working on bug 1232054 at the moment?
[20:42] <kgunn> robert_ancell: thomi is runing errand/appt right now afaik
[20:43] <robert_ancell> k
[20:43] <robert_ancell> kgunn, there were no problems with that other change yesterday?
[20:44] <kgunn> robert_ancell: none that i'm aware of
[20:46] <robert_ancell> kgunn, regarding duflu's email about the merging to lp:mir making it harder to bisect. I guess he's right there, the other option is just to bzr push the dev branch to lp:mir periodically. Any thoughts on that?
[20:46] <robert_ancell> If we did switch to that we'd have to do a bzr push --overwrite the first time which would change the history but not the contents
[20:47] <robert_ancell> Or the other option is to perhaps cherry pick each commit over and manually push them. Seems like a lot of work though
[20:49] <racarr> kgunn: Ponnng sorry, IRC session was hung
[21:20] <kgunn> racarr: hey was wondering if you were working on the api/support that zanetti needs to make the hud spyglass work (i think there was something else requiring that...nbut can't remember)
[21:20] <racarr> kgunn: https://bugs.launchpad.net/mir/+bug/1233378 :)
[21:21] <racarr> halfway done
[21:21] <racarr> :)
[21:21] <kgunn> racarr: awesome! thanks...i don't mind it not being there for a day or so....kind of want to avoid an api break while we're turning on mir by default :)
[21:22] <kgunn> robert_ancell: it is true...about what duflu says...
[21:22] <racarr> ok
[21:22] <kgunn> robert_ancell: but on the other hand...there's also no mystery where those changes are coming from :)
[21:22] <racarr> I just want to get it out of the way so I can get back to API
[21:22] <kgunn> so, one could easily go look at the dev branch
[21:23] <robert_ancell> kgunn, yeah, and I guess it's possible to bisect inside a merge perhaps?
[21:23] <kgunn> racarr: ack...no worries...you get it on dev branch and robertA and i will manage the api break
[21:23] <kgunn> robert_ancell: i think this would actually be worthwhile to have a session on at the management sprint
[21:24] <kgunn> e.g. why are we on sacred lp:mir/trunk
[21:24] <kgunn> we should be on lp:mir/sacred
[21:24] <robert_ancell> kgunn, i.e. reverse it?
[21:24] <kgunn> and see if we can effect some change that way
[21:24] <kgunn> robert_ancell: well...i think most engineers are bothered that "trunk" is considered sacred
[21:25] <racarr> kgunn: ill come in my ripped jeans, tell the story of a poor developer forced out on to the streets through branching practices
[21:25] <racarr> it will be a real sob piece.
[21:25] <kgunn> :))
[21:25] <robert_ancell> racarr, ha!
[21:25] <kgunn> robert_ancell: i'm actually not suggesting to change anything at the moment - we should stay the course for the moment
[21:26] <kgunn> just because we're finaly landing things without issue (other than duflu upset about having to dig a litte :)
[21:26] <robert_ancell> kgunn, yeah, we've had enough change to confuse everyone. The current system is not great but it works for now and it's ultimately temporary
[21:26] <kgunn> rigth
[21:26] <kgunn> right even
[21:26] <kgunn> robert_ancell: more like just a session with asac & didrocks on a proper pulling system
[21:27] <robert_ancell> kgunn, yep
[21:27] <kgunn> that would in effect help us in the upstream branch managemewnt
[21:27] <kgunn> or management even
[21:27] <kgunn> racarr: have you ever run autopilot on the phone?
[21:36] <racarr> No.
[21:51] <racarr> having to implement the inverse of mia::Lexicon
[21:51] <racarr> ><
[21:53] <kdub> at least you can have some interesting class names as a result
[21:54] <kdub> mir::input::ReverseLexicon
[21:57] <racarr> haha no just new methods on the lexicon
[21:57] <racarr> alternatively mir::input::Leximonicon
[22:02] <kdub> mir::input::Lexicant
[22:02] <racarr> kdub: Which is of course the concrete implementation.
[23:06] <racarr> had a misconfusion about the input dispatcher API...there is still a missing piece of machinery for the input injection
[23:06] <racarr> trying to sort out which path to take...but it will take a little longer any way.
[23:08] <racarr> The input dispatcher injection goes through the normal targetting interface, rather than taking a target at injection time
[23:09] <racarr> adding a direct injection interface, isn't trivial, and requires mucking around with InputDispatcher a bunch
[23:09] <racarr> it would be pretty easy to add like
[23:09] <racarr> input_injection_mode_skip_shell_surfaces
[23:09] <racarr> which works well
[23:09] <racarr> but then we need, something internal to ms::Surface which indicates
[23:09] <racarr> a 'shell' surface
[23:24] <kdub> seems not very generic
[23:24] <kdub> i guess this goes back to the central model problem
[23:26] <kdub> racarr, the problem is you need to dish out input to certain clients, but we iterate over the ms::Surfaces
[23:26] <kdub> ?
[23:29] <racarr> kdub: Yes.
[23:29] <racarr> or the alternate problem is modify the input dispatcher to support injection in a particular clients queue
[23:29] <racarr> I think that may be the harder/riskier approach though
[23:34] <kdub> yeah
[23:37] <kdub> hmm, maybe there should be a bitmask (of sorts) that filters the input to the surfacestack
[23:37] <kdub> (just musing, might be a dumb idea :) )