#ubuntu-mir 2013-09-01 <oiaohm> http://dvdhrm.wordpress.com/2013/09/01/splitting-drm-and-kms-device-nodes/ I really do wonder badly this is going to effect mir idea of server side control. <RAOF> oiaohm: rhonda96@example.net. <oiaohm> RAOF using device nodes could nicely under mine buffer controls. Client side allocation in GPU memory spaces. <RAOF> They can't allocate the front or back buffers, which is all Mir controls anyway. <RAOF> We weren't planning to, and don't, allocate *all* client buffers. That would entail much annoyance - we'd need to have server-side changes any time a GPU driver wanted a differently laid out buffer for internal purposes. <RAOF> Clients allocate all their textures themselves. <oiaohm> RAOF: the back buffer one is something I do wonder about. dma-buf that is used to pass from device nodes back to servers can have a back buffer applied. <oiaohm> basically the change might effect you a little. RAOF <RAOF> You're using "back buffer" in a way I don't recognise. <RAOF> dma-bufs are a buffer passing mechanism, yes. <RAOF> There's no way for a client to *display* anything except through Mir; only what they render to the buffers sent out from the server (as dma-bufs) will ever make it to the screen. <RAOF> (Barring hilarious client bugs) #ubuntu-mir 2013-09-02 <RAOF> You know what would be really awesome? <RAOF> Documentation of the ownership semantics of pointers we pass into mirclient. <duflu> RAOF: What is the ID in "X -mir ID" ? <RAOF> It's the name that XMir uses to identify its connection. <RAOF> duflu: It's a string that usc uses to distinguish between different xservers. <duflu> RAOF: Oh, my mistake for assuming it was always an int <RAOF> It's passed verbatim through to mir_connect <RAOF> usc just happens to pass integer strings for it :) <duflu> RAOF: Ah, kay. I know the connect string is harmless. Didn't know that's what -mir ID was * RAOF should possibly document it better <oiaohm> RAOF: sometimes is great when a team has a techical writer for some of these items that need documentation. They don't get destracted by needing to code. <duflu> oiaohm: That's true, you do get better results with dedicated technical writers. However in this case we're talking about a very small section of code, not part of any docs * duflu is impressed that --display-config sidebyside figures out where the monitors are in space and gets them *backwards* every time ;) <duflu> RAOF: Is there a reason why XMir changes the monitor layout immediately on startup, even with zero X clients? <RAOF> duflu: Because that's X's default behaviour, and I haven't yet overridden it. <duflu> RAOF: Kind of?... X without Mir doesn't change the resolution or start mirroring. Whereas XMir does both (bug 1216224) <ubot5> bug 1216224 in XMir "[multimonitor] XMir defaults to wrong resolution 1152x864 instead of 1920x1200." [Undecided,Confirmed] https://launchpad.net/bugs/1216224 <RAOF> duflu: xf86-video-intel overrides X's default behaviour. <duflu_> Whee, i915 hangcheck <oiaohm> There are a lot of horible x11 features killed by drivers. <tvoss> good morning :) <RAOF> Aloha! <smartboyhw> tvoss, hello:) <tvoss> smartboyhw, hey there :) how is it going? <smartboyhw> tvoss, quite good:) How's XMir? <tvoss> smartboyhw, alive and we made feature freeze, now some issue to fix <smartboyhw> tvoss, \o/ * duflu goes to find lunch, and the store <duflu> tvoss: BTW if there are still radeon corruption issues without bugs, please log another bug. We only have one right now... bug 1218815 <ubot5> bug 1218815 in xorg-server (Ubuntu) "[radeon] Graphic glitches and screen corruption since the latest update" [Undecided,Incomplete] https://launchpad.net/bugs/1218815 <RAOF> Harumph. <RAOF> Why am I receiving unpared focus/unfocus events? <RAOF> Oh, of course! <RAOF> mir_surface_release doesn't implicitly trigger a focus lost event. <duflu> RAOF: Wonder if it should.... <RAOF> It would make my life easier. <RAOF> And I don't think that my use case is *that* peculiar. <RAOF> And given that I need to add at least *some* code to make this work... <duflu> RAOF: Though that's another reason why the even should be on the connection rather than on the surface... <RAOF> Well, possibly multi-layered? <duflu> Don't know <duflu> RAOF: Is there a way to make X not ignore the LD_LIBRARY_PATH? <RAOF> It doesn't ignore LD_LIBRARY_PATH <duflu> Hmm, mine is <RAOF> Are you trying to pass LD_LIBRARY_PATH througgh sudo again? <duflu> RAOF: No <RAOF> Hm. Should work. I've used it in the past. <duflu> RAOF: Sanity check: Does the frame ordering issue occur on nouveau/radeon? <RAOF> duflu: I don't know; I don't have dual-head nouveau/radeon set up. <duflu> RAOF: Sanity check (2): What branch/URL contains the latest XMir? <RAOF> duflu: The Ubuntu archive. <dholbach> good morning <duflu> Oh, I'm cloning that just now <duflu> Morning dholbach <dholbach> hi duflu <RAOF> Aha! unity-system-compositor needs to handle this. Maybe. <duflu> RAOF: So... maintaining in archive means maintained as a patch? That sounds painful <duflu> Possibly less painful than not being in archive though <RAOF> duflu: Ah, no. I maintainish on vladmir-upstreaming branch of github, then dump the diff of that against vladmir-upstream-base to generate the patch. <RAOF> duflu: If you want to do upstreamish hacking on xmir that's where you should hack, but if you want to do printf debugging you want to start with the archive. <duflu> Yep <RAOF> We appear to have three subtly different focus mechanism classes in Shell :/ <duflu> Awesome. More the merrier <duflu> Or is that backwards? <duflu> Argh. How can building the archive version have missing symbols when my machine is up to date? <RAOF> *Fails* with missing symbols? <RAOF> (Also, what do you mean by missing symbols?) <duflu> RAOF: X: symbol lookup error: /usr/lib/xorg/modules/drivers/intel_drv.so: undefined symbol: xmir_window_to_windowptr <RAOF> Hrm. Odd. * duflu rebuilds the intel driver <RAOF> Is xmir successfully loading/? <RAOF> Because that woud happen in the past when xmir failed to find mir, and then would unload itself. <RAOF> But I thought I made those errors fatal. <duflu> RAOF: Yes, now. But my packages are kind of screwed now. Trying to fix <duflu> RAOF: Oh. Someone has been dputting without updating the lp:ubuntu/.... <RAOF> lp:ubuntu/ is automatically maintained. When it works. <duflu> Yeah it's quite behind right now <duflu> A few weeks <duflu> Maybe apt-get source will give me the actual correct code... <RAOF> It shall. * mlankhorst pokes tvoss with a glmark2 deb <tvoss> mlankhorst, yeah :) <tvoss> mlankhorst, sent <tvoss> mlankhorst, sent you armhf, too <tvoss> mlankhorst, not sure you need them, though <duflu> RAOF: Unexpectedly I appear to have fixed the artifact'd cursor <tvoss> duflu, how so? :) <duflu> tvoss: Maybe I just hid it by going slower. Added more mir_wait_for in xmir <duflu> I'm still concerned by XMir's apparent lack of synchronization though <RAOF> duflu: What were you mir_wait_foring? <duflu> RAOF: The swap buffers <RAOF> Oh, yeah. That'd be adding significant wait. <duflu> RAOF: Cos there doesn't seem to be any guarantee otherwise that mir_surface_get_current_buffer is getting for the correct frame <RAOF> Nothing should call that until has_free_buffer is true, which is set in the buffer_received callback. <RAOF> And we should only ever have one swap_buffers in flight at any one time. <RAOF> (per surface) <duflu> RAOF: OK, will have a closer look next time I'm in XMir <duflu> Ping alan_g <alan_g> duflu: good morning <duflu> alan_g: Hi. Something that's tripped me up a few times... the display server test fixture hangs if you try to swap buffers more than once. Any idea why? <alan_g> duflu: yes <duflu> Umm, good. <alan_g> duflu: It uses a stubbed graphics component that never consumes buffers <duflu> alan_g: I keep getting lost in the whole "this test is now three processes" :( Do you think you can propose a way to consume them? <RAOF> Why does C++11 not contain features in C99? :( <alan_g> duflu: I can add it to the list. (I'll probably need a fuller test graphics implementation for nested mir at some point) <alan_g> RAOF: because they're bad ideas? <duflu> RAOF: Because the ideas are *too good* <alan_g> Does anyone implement all C99 anyway? <duflu> RAOF: Consider it a fork with no recent common ancestor :/ <RAOF> alan_g: I don't think designated structure initialisers are a bad idea ;) <tvoss> RAOF, now that's a good idea, indeed. Have stumbled over that multiple times, too <alan_g> RAOF: as best as I can tell the only reason is that no-one proposed adding them * duflu also votes for dynamically sized arrays in the local stack frame <duflu> I think people raised that as a security risk though <duflu> alan_g: Strangely, multiple swaps started working recently (with the switch branch??) and we added a test case that depends on it. But now I'm working on new buffering changes, the new test case hangs (expectedly) <alan_g> duflu: in that case I have no idea <duflu> alan_g: OK, I *think* I found a fix. Will propose it soon <greyback> Hi folks, I've an 26" Apple display in front of me that I want to use as second monitor with my macbook pro. When I plug it in, I get black screens, except for on my laptop where the cursor remains. If I try to move the cursor, it takes 2-5 seconds for the display to update. Ideas? <duflu> greyback: radeon by any chance? <greyback> duflu: nope, intel sandybridge <duflu> greyback: Anything chewing CPU while the cursor is slow? <greyback> duflu: any way I can tell, without needing a second device to SSH in? <greyback> note unplugging made everything ok again <duflu> greyback: With Mir you will often need a second device for ssh :( <duflu> greyback: It's only OK _while_ unplugged? <greyback> duflu: yes. Plugged in, laptop display black screen with cursor, Apple display unchanged, as if not plugged rhonda96@example.net. If I unplug, laptop display returns to normal <duflu> greyback: Normal X session you mean? <duflu> greyback: X will auto-enable remembered multi-monitor layouts when new monitors become available AFAIK. Maybe you should start fresh by removing ~/.config/monitors.xml <greyback> duflu: yes, I'm using XMir. Ok will try that. * greyback just pulled updates, will reboot for safety <duflu> greyback: You're not the only one reporting a black screen. So it would be helpful to get to the bottom of <greyback> duflu: ok. Will let you know once I reboot. Also have my tablet here with terminal app, so should be able to ssh into my laptop <duflu> greyback: Is that soon? I am off in a minute... <greyback> duflu: I'll probably be 5 minutes. No worries if it's your EOD <duflu> greyback: OK, I can easily track the issue if you log a bug :) <greyback> duflu: ack <mlankhorst> tvoss: hm sent me where? <tvoss> rhonda96@example.net <mlankhorst> odd, didn't arrive then <mlankhorst> oh nm i see it now <mlankhorst> derp <alan_g> hikiko: have you time to review https://code.launchpad.net/~alan-griffiths/mir/tidy-up-nested-class-responsibilities/+merge/183233? <hikiko> yes alan_g <hikiko> in a sec to finish something <mlankhorst> tvoss: hm seems most likely that nouveau is syncing glmark2 to vblank :P <tvoss> mlankhorst, oops :) <tvoss> mlankhorst, however, having something like 60fps would already be better than last week, both for X and XMir <mlankhorst> try glmark2 --off-screen <tvoss> RAOF, ping <penghuan> hi, i build mir locally, i got an error, "undefined symbol: eglCreateImageKHR", how can i resolve this <alan_g> penghuan: I can only guess that you've not got the right dependencies installed in your build environment. You've followed these instructions? http://unity.ubuntu.com/mir/building_source_for_pc.html <smartboyhw> tvoss, (and the Mir team), I can't seem to load lightdm using XMir <tvoss> penghuan, do you have libhybris or libhybris-dev installed? <tvoss> smartboyhw, not sure what you mean? what are the symptoms you see? <smartboyhw> tvoss, after Plymouth, it went black <smartboyhw> Well, seems like that I have to report a bug:( <tvoss> smartboyhw, that's fine :) please make sure to attach the relevant logs including dmesg <smartboyhw> tvoss, for dmesg, how can I find PAST logs? <smartboyhw> Since I've now booted in using Xorg <tvoss> smartboyhw, you cannot really resurrect it, sorry <tvoss> smartboyhw, what kind of setup are you testing? <smartboyhw> tvoss, so unfortunately, I can't include it then <smartboyhw> tvoss, Ubuntu 13.10 <tvoss> smartboyhw, in terms of hw? <smartboyhw> tvoss, laptop (amd) <smartboyhw> I mean, amd card <smartboyhw> tvoss, Bug 1219847 <ubot5> bug 1219847 in mir (Ubuntu) "XMir can not start LightDM" [Undecided,New] https://launchpad.net/bugs/1219847 <tvoss> smartboyhw, thanks <smartboyhw> But, I can't attach anything (in Firefox or Chromium) weird <jibel> I get bug 1218456 with xserver-xorg-video-ati <ubot5> bug 1218456 in xorg-server (Ubuntu) "Xorg assert failure: X: ../../../../include/privates.h:123: dixGetPrivateAddr: Assertion `key->initialized' failed." [Critical,Confirmed] https://launchpad.net/bugs/1218456 <tvoss> jibel, I assume you upvoted it? <jibel> tvoss, yes <tvoss> jibel, thanks for reporting :) <jibel> tvoss, yw, let me know if you need more info, this is my main work machine :) <tvoss> jibel, ;) <tvoss> kdub, ping <kdub> hello tvoss <tvoss> kdub, unping, it's labor day, isn't it? <kdub> it is, but i thought I'd quickly update myself and check our status after my time off :) <tvoss> kdub, ff is passed, we do see some performance issues on the galaxy nexus <tvoss> kdub, first of all: welcome back :) <kdub> thanks :) #ubuntu-mir 2013-09-03 <racarr> Hello! <RAOF> No longer eating delicious desert? <racarr> Back home :D it will probably take a few days for the dust to fully leave my lungs though. <RAOF> Ooh. I *can* slot in a MockSurface. Yay! <RAOF> Oh, no. <RAOF> That's a lie. <smspillaz> racarr: !! <robert_ancell> RAOF, did you get anywhere with XMir+focus switching? <RAOF> robert_ancell: Yeah, I'm just preparing to propose a Mir branch to fix an annoyance there. <robert_ancell> RAOF, cool <robert_ancell> RAOF, also, do you think there's any version dependency that could help bug 1218932? <ubot5> bug 1218932 in Unity System Compositor "unity-system-compositor should depend on >= version of xserver-xorg-video-<driver> (intel|nouveau|radeon) that works with it." [Undecided,Confirmed] https://launchpad.net/bugs/1218932 <robert_ancell> The depends of u-s-c on xmir is a bit suspect already, not sure if there's any minimum version that makes sense <robert_ancell> actually, I guess that should be mir with a minimum version on a driver, though it should be a recommends I guess <RAOF> Yeah, I need to think about that a bit more. <racarr> smspillaz: !!?!! <RAOF> robert_ancell: https://code.launchpad.net/~raof/mir/unfocus-on-surface-destroy/+merge/183563 is available for your pleasure. <robert_ancell> RAOF, the name sounds like a useful feature :) <robert_ancell> RAOF, does the destroy event not get to the client? <RAOF> robert_ancell: It does, but you don't know whether the surface was focused or not. <robert_ancell> RAOF, would it be better just to add a mir_surface_get_has_focus()? This isn't like X - Mir will always notify if you get focus <robert_ancell> I'm just thinking that unfocus due to deletion is a slightly separate case to being unfocussed for a particular reason <RAOF> It is, yes. I could add has_focus(), but it would be a bit racy - you'd need to check it in the surface deletion callback to avoid possibble races (and that's non-obvious). <robert_ancell> RAOF, you say "We probably need to rethink focus entirely, but this is an incremental improvement that I need" - can't XMir track the focus itself? <RAOF> I could, yes. <RAOF> robert_ancell: Actually, I'm not sure whether I *could* do focus tracking in XMir. Aside from the locking being a huge pain in the arse, I'm not clear on what our message ordering guarantees are. <RAOF> I could do it with a mir_surface_get_has_focus(), though. <robert_ancell> RAOF, for input it doesn't matter about ordering right? You grab input devices when getting a focus event, and drop them when getting an unfocus or destroy <robert_ancell> RAOF, but with duflu's second opinion, I'm happy to approve the MP anyway <duflu> I think it's OK to say "we're not really sure what's focussed when" for now. The API is too racy (by design) to be sure. <RAOF> That branch guarantees that a released surface always ends up unfocused from the client API's perspective. <robert_ancell> RAOF, btw, I was thinking - do you think XMir will drop the input devices fast enough when switching to the second XMir? Could both XMirs get duplicate events during the changeover? <RAOF> Fair question; that's entirely possible. <duflu> robert_ancell: Even if you guaranteed ordering in the protocol, you can never guarantee when each XMir will be scheduled by the kernel and process the messages. <robert_ancell> duflu, correct <robert_ancell> duflu, but if XMir is being driven by the events, then the ordering isn't really relevant to it in this case <robert_ancell> RAOF, btw, did you see https://dvdhrm.wordpress.com/2013/08/25/sane-session-switching/ <RAOF> robert_ancell: Yeah. <RAOF> I think I commented on that one? <RAOF> Yes :) <robert_ancell> ah, I didn't read the comments. Due to blog comments almost always being crap. I guess planet.freedesktop probably has more credibility here <RAOF> Heh. <RAOF> robert_ancell: So, probably the *correct* way to do this is a synchronous âplease switch nowâ client API for xmir. <robert_ancell> RAOF, I was wondering if we are forced to do it the correct way or continue with our hack <RAOF> It depends on how fixed you want the bug. <robert_ancell> RAOF, fixed enought that it doesn't bite us in the arse later <RAOF> Without a request/ack style API there *will* be periods where both X servers are consuming events. <robert_ancell> RAOF, yeah, I think we just have to bite the bullet and do it properly via u-s-c. I don't really want to add it into the Mir protocol, but that would be the easiest and most reliable place to put it <RAOF> We don't have anywhere else to put it :/ <robert_ancell> RAOF, well, if XMir could contact u-s-c via a different socket we could do something custom and temporary. But XMir doesn't really know u-s-c exists <RAOF> We could teach it. <RAOF> It'd not be super hard. <robert_ancell> RAOF, I suppose we could open a pipe and give you the fd in an env variable <RAOF> Or as another commandline option. <RAOF> Note: we are discussing the most terrible thing ever. âº <robert_ancell> Yes, I feel dirty * duflu goes to play in the rain, erm lunch <duflu> RAOF: Any idea why X is always slightly clumsy at changing modes? I always see flickering and sometimes briefly misplaced outputs while it reconfigures. This happens without X too. Plain Mir doesn't. <duflu> This happens *without* Mir too <duflu> Ugh. I mean the issue with X pre-dates Mir. A pure Mir environment seems to switch layouts much more cleanly. But I guess I haven't seen pure Mir switch modes yet <RAOF> duflu: I think XMir exposes a case where Mir does some unnecessary modesetting. <duflu> RAOF: No I mean X has always done this... without Mir <RAOF> But the X issue is bound up in X's "one framebuffer to rule them all" <RAOF> ie: you *can't* turn on a new monitor without touching the existing monitors. <duflu> Oh. Yes. <RAOF> Various drivers can do better and worse at mitigating that; Intel seems to make a fair amount of trouble to mitigate that (copying the contents of the previous framebuffer, etc) <duflu> RAOF: On an unrelated note, would intel's double/triple buffering in the DDX affect the generic logic of the xmir module? <RAOF> I don't believe so, no; from memory, those codepaths are in the drmmode bits, which we bypass. <RAOF> Bah! How do I get Jenkins to retry the flaky test? <duflu> RAOF: Click on the link. Or rhonda96@example.net. <RAOF> What's the IP of s-jenkins? <RAOF> That's behind the VPN, right? <duflu> Think so <duflu> RAOF: Any tips for explorers wishing to dive into XMir's damage tracking? <RAOF> duflu: The main business is in xmir-window.c, where xmir_window_get_dirty maintains a circular list of damage regions in struct xmir_window. <duflu> RAOF: And xmir_window is effectively one Mir output? <RAOF> Right. We have one xmir_window per output (strictly speaking, one per CRTC) <RAOF> They're sitting in xmir_screen->root_window_fragments <hikiko> RAOF, should the multimonitor work in the lightdm screen? <hikiko> (before we start unity) <RAOF> hikiko: Yes, but you'll have mirrored displays because unity-greeter doesn't set anything different. <hikiko> mmm is there any setting in lightdm I should have or the defaults are fine? <RAOF> The defaults are fine. <hikiko> in an Intel 4000 I have multimonitor working on unity but not in lightdm <hikiko> which is very strange <RAOF> As in: your second display doesn't show anything? <hikiko> it shows a vertical purple line <hikiko> I ll upload a screenshot in a while <hikiko> RAOF: http://i.imgur.com/ulUN09l.jpg <hikiko> but as soon as I login everything is working fine <RAOF> Huh. <RAOF> Interesting. <RAOF> I wonder what it's doing? <hikiko> maybe there's something wrong in my system <hikiko> how can I check that lightdm uses xmir for sure? <RAOF> grep -i xmir /var/log/Xorg.${DISPLAY#:}.log <hikiko> also this occurs when I have the 2nd monitor plugged from the begining, I will check what happens if I start without the 2nd monitor plugged <hikiko> in Xorg.2.log I have this line: <hikiko> [ 2356.280] xorg-server 2:1.13.3-0ubuntu6+xmir3 (For technical support please see http://www.ubuntu.com/support) <hikiko> am I using xmir? <dholbach> good morning <hikiko> good morning dholbach <hikiko> RAOF, ^ I think I use xmir... shall I fill a bug report? <RAOF> hikiko: That would suggest that you're *not* using mir <RAOF> Also, that you've got an old Xserver :) <hikiko> haha <hikiko> great <dholbach> hi hikiko <hikiko> so RAOF <hikiko> there must be a conf? <RAOF> hikiko: Do you have unity-system-compositor installed? It installs /etc/lightdm/lightdm.conf.d/10-unity-system-compositor, which enables usc and hence XMir. <hikiko> or installing xserver-xorg-mir is enough <hikiko> RAOF, if I run apt-get install there are extra packages :) it should be that <hikiko> (I mean apt-get install unity-system-compositor) <RAOF> Yeah, apt-get install unity-system-compositor should do it. <hikiko> ok I found what it was: when you upgrade unity-system-compositor with apt-get install there's a question <hikiko> install the package maintainer's version / keep your current etc and default == keep current <hikiko> let me try again <hikiko> fixed :D <hikiko> RAOF, now unity wallpaper <hikiko> has the size of the small monitor <RAOF> Yup, that sounds right. <hikiko> and the dash <RAOF> We clone by default. <hikiko> ok so I leave it like that? <RAOF> Oh, you probably want to set up a spanned desktop; the Displays capplet will let you do that. <RAOF> You can set it up just like you want. <hikiko> cool :) <hikiko> and RAOF another question (final) <hikiko> I want to test xmir for the first time <hikiko> I build and run ./mir_demo_server... --enable-xmir and that's all? <hikiko> what should I expect to see? <RAOF> hikiko: Once you've installed unity-system-compositor you'll be using xmir all the time. <hikiko> I mean the xmir I will build <hikiko> not the system's xmir <RAOF> Ah. In that case, run mir_demo_server_shell, and then on a different VT run âXorg :33 -mir 1 -retro -verbose 7â <RAOF> (The :33 and 1 are just placeholder values; you can use whatever you want there) <RAOF> When you switch back to mir_demo_server_shell you'll see the delightful X root weave, which is the black and white crosshatch thingy. <hikiko> and then how do you stop it? just killing mir_demo_server_Shell? <RAOF> Ctrl-C works fine :) <duflu> hikiko: Ctrl+Alt+Backspace is how you get out of mir_demo_server_* <duflu> Ctrl+C was disabled a while back <hikiko> yes that's what I noticed :) <hikiko> thanks duflu and RAOF :D <RAOF> Oh, yeah. But Ctrl+C will kill Xorg. <RAOF> When you VT switch back to your Xorg-running VT. <hikiko> oh, I see <hikiko> and one more question to setup a spanned desktop do I need to do something on mir or I do it from unity settings? <hikiko> found <duflu> RAOF: Woo, no time-travelling frames any more <tvoss_> duflu \o/ <duflu> Just need to *repeat* and verify. It's not a fix. Just a hack right now <tvoss_> duflu, what is the idea? <duflu> tvoss_: XMir seems to be reporting incorrect damage regions <tvoss_> duflu, ah <duflu> tvoss_: Still, somehow, affected by XMir's multimonitor logic <tvoss_> duflu, hmmm ... interesting <tvoss_> duflu, go ahead then ;) <hikiko> is there any way to temporarily disable xmir? <smspillaz> tvoss_: ^ interesting comment by duflu - do apps need to provide a damage region or is it just assumed to be sizeof(surface) on swap_buffers? <smspillaz> I didn't see anything in the mir api about it <tvoss_> smspillaz, no damage region, yet <smspillaz> tvoss_: ah okay. What was duflu's comment about damage regions about then? <tvoss_> smspillaz, duflu was talking about the xmir world, so mostly the x <-> mir integration parts over there <smspillaz> tvoss_: ah you mean xmir reporting incorrect damage regions to x clients? * smspillaz thought that xdamage didn't live in the ddx <tvoss_> smspillaz, I would think vice-versa <tvoss_> smspillaz, let me check <sil2100> Hi everyone! <sil2100> Do you know if we still need to enable the Mir PPA for daily-releasing Mir? <sil2100> i.e. D09add_ppa~mir-team~staging ? <sil2100> Since I would prefer not to use non-standard PPAs when releasing stuff <sil2100> kgunn: ^ do you know? * alan_g wishes he didn't need to learn so much about [E]GL <kgunn> sil2100: mir is in archive...no ppa needed <sil2100> Awesome <kgunn> at most, for those not already running xmir...just apt-get install unity-system-compositor <racarr> Morning! <kgunn> racarr: welcome back <kdub> good morning! * kdub is back <racarr> kgunn: Thanks :) <alan_g> racarr: welcome back <racarr> alan_g: Thanks :) <kgunn> kdub: welcome back!! <kdub> thanks! <racarr> I keep on looking for some email titled like <racarr> Mirpocalypse <racarr> but havent found it yet. Seems like things are going pretty well? <alan_g> racarr: no dramatic failures <alan_g> but we've not been able to address the lack of a coherent data model and there are plenty of bugs and missing features <racarr> alan_g: :) Thanks. <racarr> Yay, email finished <racarr> I think I replied to all emails last week (except bugs + MRs) that warrant a response from me <racarr> so if you sent me an email last week and are waiting to hear back <racarr> please resend / ping me. <racarr> kgunn: Hey. I think I am keeping myself busy until lunch catching up on commit logs then bugs but can we schedule a sync for this afternoon maybe <racarr> So I can prioritize some tasks? <kgunn> racarr: sounds good <kgunn> i've got thing around 4pm my time...other than that i'm pretty open <racarr> kgunn: Ok how about in 2.5 hours (3 your time?) <kgunn> sounds good <racarr> Ok. Thanks :) <racarr|lunch> Back soon! <racarr> updating my phone image now <racarr> excited to see last weeks progress :) <kdub> racarr, once you've updated, could you try the acceptance tests? seeing some failures there on the phone <racarr> kdub: ok <racarr> updating my phone image earlier really meant charging my ultra dead neuxs 4 so it will be a bit stil <kdub> yeah, mine died a few times mid-update because it ran out of battery <racarr> its so obvious that comcast has been throttling me and is now rewarding me for not using any internet for a week -.- <racarr> Been getting like 3MBs all day <racarr> Phone looks pretty great :) <kgunn> racarr: on the phone...you notice the flicker yet ?...i'm wondering if that's z-order fighting <kgunn> kdub: ping <kdub> kgunn, pong <ricmm> racarr: ping <kgunn> kdub: hey...so i was trying to do mir logging on android...so i did stop unity8, then exported <kgunn> MIR_SERVER_MSG_PROCESSOR_REPORT=log <kgunn> MIR_SERVER_DISPLAY_REPORT <kgunn> =log <kgunn> MIR_SERVER_GLOG=1 <kgunn> and MIR_SERVER_GLOG_LOG=/tmp/ <kgunn> but...no luck <kgunn> did i miss something <kgunn> (obviously i restarted unity8 after all that) <kdub> hmm, seems like that should work <kgunn> kdub: is the log file names something funny (like j1jk2k3.something) or something obvious like (mir_glog.log) <kdub> MIR_SERVER_GLOG_LOG_DIR=/tmp <kdub> kgunn^^ <kdub> the name should be... mir.hostname.user.loglevel.timestamp <racarr> ricmm: Pong! <racarr> kgunn: Yes! I saw it twice pretty quickly but then not again yet <racarr> kgunn: I dont think its that but would have to dig deeper <ricmm> kgunn: it doesnt inherit the environment from where you are restarting the job <ricmm> kgunn: you'd need to add that to the unity8.conf job <kgunn> ricmm: thanks for solving that mystery for me! #ubuntu-mir 2013-09-04 * robert_ancell -> lunch <RAOF> robert_ancell: When you get back we need to discuss how to proceed with Operation: Worst Thing Ever (ie: sideband pipe between usc and Xmir) <RAOF> duflu: You tracked down damage problems? <duflu> RAOF: Kind of, not really. I need to devote more hours to better learning XMir <duflu> kdub: You're back? Congratulations by the way <smspillaz> racarr: long shot, but still around ? <duflu> RAOF: ickle says he "pushed a patch" for the intel cache/lines issue with bypass. But I can't tell which commit(s) it was. Do you think... http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=47e718bf321f6fe80dc5f797f433b00bc8de91c7 ? <robert_ancell> RAOF, yes. I was also wondering how far from working the focus thing is - that would at least reduce the pressure for a less hacky solution <RAOF> duflu: It's all folded up into the single monolithic xmir commit, but yeah. <RAOF> duflu: It's a bit ugly; we should either work out how to unuglify it - probably by telling the DDX when bypass is in effect, rather than having it guess it. <duflu> RAOF: If you can get the bo flags then it's easy :/ <RAOF> The bo-flags are userspace only <duflu> RAOF: Oh, actually that wouldn't help. Most large surfaces are now SCANOUT even when not bypassed <duflu> RAOF: A surface attribute? Still ugly <RAOF> A buffer attribute. <RAOF> As it has to be :) <RAOF> Because SCANOUT is already a possible pessimisation in the non-bypass case. <RAOF> robert_ancell: Oh, the focus thing is mostly ok. It works for single-head; I just need to work out what I do wrong in the multihead case. <duflu> RAOF: Sanity-check vladmir-upstreaming FTW? <RAOF> duflu: Yes. <RAOF> Although you'll want to pull the changes back to the ubuntu branch. <RAOF> Because vladmir-upstreaming is based on master, which is an ABI bump ahead of us. <duflu> RAOF: Argh. Maybe I'll just keep working with apt-get source on saucy to minimize impact on the system... <RAOF> duflu: vladmir-upstream-base is the tag you want; it's easy to reproduce xmir.patch <RAOF> duflu: git diff vladmir-upstream-base..vladmir-upstreaming > debian/patches/xmir.patch <duflu> RAOF: When will that be upstreamed? Post 13.10? <RAOF> Once it's broadly feature-complete. <RAOF> I think glx-bypass is the final piece of that. <duflu> RAOF: I can't see any guarantees about which portion of damage actually makes it to the swap_buffers. How can we be sure about the exact damage region that *really* got swapped? <duflu> ... without waiting <duflu> Oh, actually, maybe the answer is in the DDX... <RAOF> What do you mean? The drivers are responsible for passing a correct region into submit_rendering. <RAOF> And they're responsible for doing enough flushing that the fd submitted to Mir actually contains the rendering expected. <duflu> RAOF: Yes! OK so the answer is the region parameter to the submit. Ta. <RAOF> As a practical matter, the DDXen all pass the region that they get passed in. * duflu -> lunch <RAOF> Ah, good. Now with significantly less password-leakage-across-VT-switch! <RAOF> robert_ancell: So, the XMir side of focus-thing works. The Mir side (drop focus on VT switch) hasn't landed yet as far as I can tell. <robert_ancell> RAOF, cool <tvoss_> robert_ancell, ping <tvoss_> robert_ancell, don't have broadband in the new house, yet <robert_ancell> tvoss_, ok, so not coming to meeting? <tvoss_> robert_ancell, trying, but don't know if it works, only 3G here :/ <robert_ancell> hikiko, duflu, racarr, kdub, meeting <robert_ancell> duflu, should we close bug 1217262 invalid? <ubot5> bug 1217262 in Unity System Compositor ""sudo restart lightdm" always hangs/fails when using unity-system-compositor" [Undecided,Incomplete] https://launchpad.net/bugs/1217262 <duflu> tvoss_: How did you go with Mir-native-OpenArena ? <robert_ancell> duflu, you may have been hitting the problem where u-s-c was left running due to the way it was launched with a shell script <duflu> robert_ancell: I think it might still be valid. We have something occasionally keeping DRM open and triggering bug 1206633 <ubot5> bug 1206633 in Mir "Mir/unity-system-compositor fails to start: Error opening DRM device" [Critical,Triaged] https://launchpad.net/bugs/1206633 <duflu> ... but it's racy. If you stop, pause, start, then it's OK <mlankhorst> yeah of course it's racy.. <duflu> As mlankhorst keeps pointing out <robert_ancell> duflu, then is it better covered by that specific bug? The bug you filed is a bit vague and likely to attract random me toos <mlankhorst> unity-system-compositor needs to be completely dead before starting lightdm again :P <duflu> mlankhorst: That should surely be solvable in upstart <robert_ancell> mlankhorst, right, and lightdm does wait for that. But there was a bug where it was launched by a shell script without exec and lightdm was killing the shell script and not realizing u-s-c was still running <mlankhorst> or we should start usc WAY early.. and make plymouth a client to usc.. <duflu> robert_ancell: Incomplete bugs should be left to expire naturally due to inactivity I say <duflu> "Expire of natural causes" <robert_ancell> duflu, well, you filed this bug... why not just close and re-open if you see it again? <duflu> robert_ancell: I will retest for it now... <duflu> robert_ancell: Reproduced. Now a duplicate of bug 1206633 :) <ubot5> bug 1206633 in Mir "Mir/unity-system-compositor fails to start: Error opening DRM device" [Critical,Triaged] https://launchpad.net/bugs/1206633 <robert_ancell> duflu, awesome <robert_ancell> duflu, is bug 1216245 still applicable? afaik the demo shells don't need any special code for multi-monitor <ubot5> bug 1216245 in Mir "mir_demo_server_shell doesn't respond to hotplugging monitors" [Undecided,New] https://launchpad.net/bugs/1216245 <duflu> robert_ancell: Yes it's an issue and nice to have for testing. Just set Wishlist <hikiko> duflu, are you working on the bug: #1216522? <ubot5> bug 1216522 in XMir "XMir hung in xf86CrtcSetModeTransform()" [Critical,New] https://launchpad.net/bugs/1216522 <duflu> robert_ancell: I'm not sure having a completely broken display is only Medium... bug 1218815 <ubot5> bug 1218815 in xserver-xorg-video-ati (Ubuntu) "[radeon] Graphic glitches and screen corruption (vertical lines) on XMir surfaces only" [Medium,Triaged] https://launchpad.net/bugs/1218815 <robert_ancell> duflu, change it :) <robert_ancell> I'm just doing a first cut for triaging, I'll re-look over high-med-critical and do them next <hikiko> question: I startx to have a 2nd window manager apart from unity and the events (like double click on desktop) are send to unity (wrong vt?) is this a bug or something expected? <duflu> hikiko: Yes, RAOF is working on that <hikiko> plus programs like synergy dont work (but ok that's expected I guess) <duflu> robert_ancell: The hang bug is incomplete. I haven't stress-tested MM recently to retry <hikiko> duflu, and there's no way I use X without mir for the 2nd wm so that I can debug more easily the xmir? (eg attach a gdb etc) <duflu> hikiko: I don't think you can right now due to the input focus problems. RAOF will have it fixed soon. Meanwhile you probably need a second machine <hikiko> ouch :) <RAOF> hikiko: Yeah, you can; but until https://bugs.launchpad.net/ubuntu/+source/unity-system-compositor/+bug/1192843 is fixed all keyboard input will always go to XMir. <ubot5> Launchpad bug 1192843 in XMir "XMir receives input from other VTs" [Critical,In progress] <duflu> Alternatively, go old-school and move your desktop to a text VT :/ <tvoss_> duflu, not sure what you mean? <duflu> tvoss_: You were going to benchmark OpenArena with the Mir-native-SDL ? <duflu> Or something <hikiko> and could you guys suggest me a bug that is important to fix and none of you is working on it atm? <duflu> hikiko: I think generally anything Critical in the mir or xmir projects <hikiko> because most of our critical bugs are either GPU specific (need ATI for example) or assigned from what I see <duflu> Hmm, maybe we should unassign those not in progress <hikiko> kevin suggested one that is a test failure (but it's a bug that only appears some times) that ^ you said is incomplete <hikiko> 3 others are ATI Specific <duflu> hikiko: Bug 1206633 is a killer. And close to code you have seen recently... <ubot5> bug 1206633 in Mir "Mir/unity-system-compositor fails to start: Error opening DRM device" [Critical,Triaged] https://launchpad.net/bugs/1206633 <hikiko> cool :D <duflu> Though that might just be upstart scripting. I guess I should test <hikiko> I'll pick this one then!! <tvoss_> duflu, yup, got the numbers, need to post-process them <duflu> hikiko: It might not be a bug. Maybe just our upstart scripts need better dependency rules <hikiko> yes I saw your comment <hikiko> I'll give it a try though <duflu> hikiko: I also recall that exception wasn't clear which function it came from. Can also happen with errno==0. So maybe you should make the exception clearer first... and mention which function failed <hikiko> yes, I did that when I was testing for the nested mir: it was permission denied not success <hikiko> and my guess is <duflu> hikiko: I mean, it would be good to propose a branch with better exception details first <hikiko> that the problem is that we have that test (what interface version is used?) before we set the drm master <hikiko> oh :) <hikiko> true! <hikiko> will do! <hikiko> ok, cool!I'll start with this bug :D thank you duflu! <hikiko> final question: for as long as I only have my laptop for development <hikiko> is there any way to disable and enable xmir? <hikiko> +if I start xserver without -mir and then I start my compiled version of xmir (the branch I work) will I get a crash? <duflu> hikiko: Yes, comment out type=unity from /etc/lightdm/lightdm.conf.d/* <hikiko> duflu, if I do so, and compile/start xmir I wont have any issues isnt it? <hikiko> or I have to remember to enable it before I test? <hikiko> (enable the system's xmir) <robert_ancell> bye all <duflu> hikiko: That only affects the default system logon. You can still run any server manually <duflu> Bye robert_ancell <hikiko> cool that was my guess :) <hikiko> thanks duflu :) <dholbach> good morning <duflu> Morning dholbach <dholbach> hi duflu <duflu> RAOF: All root fragments share the same Drawable right? <RAOF> Correct. <RAOF> They're all associated with the root window, as seen by pScreen->root <duflu> RAOF: Looks like we don't filter damage reports to check if they overlap the fragment in question. Any damage effectively damages all fragments <RAOF> This is correct. *but* we take the intersection of the damage with the fragment's region before updating the damage regions. <duflu> RAOF: Still, that explains why on the Mir side I was seeing all outputs redraw even when only one should... ? <RAOF> No, I don't think so? <duflu> OK, forget I said that. It's tangental <RAOF> We *should* only be calling the driver's copyproc when xmir_window_is_dirty() returns true, which is iff RegionNotEmpty(xmir_window_get_dirty(xmir_win)) returns true. <hikiko> duflu, still here? <duflu> hikiko: Yes, but about to vanish for a brief while... ? <hikiko> :) <hikiko> I have a question but ok, I'll find out! good evening :) <duflu> hikiko: I'll be back soon. What is the Q? <hikiko> well, I wonder how and when xmir starts working with the xserver (because I remember that when I was implementing the mir display for X I had to do a trick to tell the xserver not to handle the drm device that mir is using and I want to see if this is necessary in xmir as well) <hikiko> it might be related to the 1206633 bug <hikiko> bug #120633 <ubot5> bug 120633 in telepathy-mission-control (Ubuntu) "Sync telepathy-mission-control 4.26-1 from debian unstable" [Wishlist,Fix released] https://launchpad.net/bugs/120633 <hikiko> sorry <hikiko> bug #1206633 <ubot5> bug 1206633 in Mir "Mir/unity-system-compositor fails to start: Error opening DRM device" [Critical,In progress] https://launchpad.net/bugs/1206633 <duflu> hikiko: I don't think there would be any remaining races for DRM devices in the X server. Because it is single threaded. More likely other processes racing, like maybe plymouth has not finished deactivating yet <hikiko> the only reason I suspect xserver is because I get the bug when I start a 2nd instance of lightdm which starts a second instance of xserver <hikiko> when it's only lightdm and plymouth I dont get the freeze <hikiko> but ok, I'll test a few other things first :) <duflu> hikiko: Try adding a sleep and retry. That will give you an idea of whether the race just lasts a split second <hikiko> I will :) <duflu> RAOF: That's fun. Each frame XMir is looping through my *unused* outputs as well as used <duflu> ... or something.... because I have 6 XMir wins to loop through <duflu> Hmm, sometimes 8. This is quite strange <davmor2> hey guys, I think I found an odd issue, if you hit the power button at any time in saucy the machine shutsdown with no prompts, this includes if the machine is in lock/sleep mode, meaning someone could leave their machine and it sleeps and locks and someone else hit the power button, all their work is then lost <tvoss_> davmor2, did you try it without Mir? <tvoss_> davmor2, that is, without unity-system-compositor? <davmor2> tvoss_: nope but I can <duflu> davmor2: Yeah I thought it was a new feature. I like it. Has nothing to do with Mir though <davmor2> duflu: I'd of said it was a critical regression it should switch off in locked mode it should just popup the user password dialogue box <davmor2> shouldn't switch off even <duflu> davmor2: I suggest you raise it in #ubuntu-desktop. It's really unrelated to this channel <davmor2> duflu: will do thanks <duflu> davmor2: Though it's not a security issue. Anyone with physical access to the power button always has the ability to kill a machine. There's no change there <davmor2> tvoss_: so yeah happens with with mir removed too <tvoss_> davmor2, then it's not a an xmir issue <davmor2> duflu: indeed that is the case for a hard press but if someone though the machine was hibernating and taps the power button to wake it like they do on windows instant shutdown may not be the desired result :) <duflu> I like it. I always hated having to click on a dialog after I've already pressed the power button. <duflu> And it's better than Windows' annoying behaviour of always suspending, IMHO <davmor2> duflu: I have no issue with it in an unlocked system, but if I lock my system I'd rather be forced to open the system and ensure there is nothing unsaved before my system shutsdown on me :) <duflu> davmor2: Fair point. And Ubuntu design often makes contentious decisions. You should probably start by raising it in #ubuntu-desktop <davmor2> duflu: I am now :) <Mirv> I filed bug #1220652 now for my problem. the attachments may not be very useful since I'm running normal X again, but just in case someone would have an force-rebootable desktop at some point and could try to reproduce my problem <ubot5> bug 1220652 in unity-system-compositor (Ubuntu) "Input devices gone in xmir after forcefully killing unity-system-compositor" [Undecided,New] https://launchpad.net/bugs/1220652 <Mirv> and input devices disappearing might be a bit weird anyhow, not shown in the normal logs. <Mirv> oh, added the tidbit that writing in VT1 also has the text in VT7, but in lightdm itself I can't type or move mouse <tvoss_> Mirv, what would be the expected behavior from your pov when forcefully killing usc? <Mirv> tvoss_: to that matter, it restarting itself gracefully like unity does <tvoss_> Mirv, that would be an upstart task, wouldn't it? <Mirv> tvoss_: yes, I think <tvoss_> Mirv, might be good to mention that in the bug report, too <Mirv> added ", even after reboot" to the bug title to make it more clear that the killing is not the main issue <Mirv> behavior in kill situation might be worth feature request in another bug, but that bug's intend is that I can't use xmir at the moment anymore, for some mysterious reason X <Mirv> I'll file another bug for the request to gracefully restart itself <Mirv> and that is bug #1220656 <ubot5> bug 1220656 in unity-system-compositor (Ubuntu) "Feature request: gracefully restart after being killed (or crashed)" [Undecided,New] https://launchpad.net/bugs/1220656 <tkamppeter> I have serious multi-screen problems with the XMIR as of saucy release (not -proposed) should I report a bug or are there already fixes in the queue for which I should wait? <kgunn> tkamppeter: one minute while i dig <kgunn> we've tagged multimonitor here https://bugs.launchpad.net/xmir/+bugs?field.tag=multimonitor <kgunn> curious are you on intel? or ati/nvidia? <tkamppeter> kgunn, I am on Intel, Lenovo Thinkpad Twist with Core i& with its built-in GPU. <kgunn> tkamppeter: yeah, i'd skim thru the multimonitor tagged bugs...if you don't find a match/similar bug...please file <tkamppeter> kgunn, it seems to be bug 1216472, workaround (1) of this bug solves the problem. <ubot5> bug 1216472 in XMir "[xmir] [multimonitor] Frames eventually get slightly out of order, look like glitches or typing will feel slow" [Critical,In progress] https://launchpad.net/bugs/1216472 <kgunn> cool <tkamppeter> kgunn, I have marked the "Me too" now and subscribed to the bug. <hikiko> bye! <kdub> we need a way to change the client-side connection configuration in integration/acceptance tests <alan_g> kdub: which parts of the configuration can't you change? <kdub> if we use mir_connect, we can't put in a stub client-side graphics platform <kdub> was thinking of changing it a bit to use some test connection functions <kdub> but its just nice that the client's exec() in our test framework just uses our public api <alan_g> kdub: yes, we should have made the client API mockable <kdub> alan_g, would you be opposed to having integration and acceptance tests connect with something like mt33ec:265c:71fe:e26d:2682:4ec2:aaa1:99abmir_connect()? <kdub> (which allows us to put different client connection configurations in, depending on whether we want real graphics or not) <alan_g> kdub: If I were not starting from here I'd add a level of indirection so that all the API calls could be intercepted by test doubles. <kdub> with 'here' being 'lots of acceptance/integration tests already written' ? <alan_g> "here" being introducing function pointers breaking the ABI <kdub> ah, understood <alan_g> kdub: I think the better way is for mir_connect() to call through a function pointer that defaults to the current implementation, but can be replaced for a test. <kdub> yeah <kdub> or even, maybe put that function into mir_client_library_debug.h <kdub> probably worth doing, two critical bugs about the tests have popped up related to this <alan_g> kdub: "that function" being the existing implementation and the function pointer? <kdub> well, i'm currently thinking the path of least resistance will be a mt33ec:265c:71fe:e26d:2682:4ec2:aaa1:99abtest_client_connect() function that returns a MirConnection* <kdub> as opposed to adding a mir_connect(<current args>, MirClientFnPtrStruct*) <kdub> no touching the API, just a small inconvenience for tests <alan_g> kdub: I was thinking of a global pointer variable, not an extra parameter <alan_g> mir_connect() calls through (*mir_connect_impl)() which defaults to mir_connect_default_impl() <kdub> and that global pointer can be overwritten via a debug function? <kdub> rather, a function in mir_client_library_debug.h <alan_g> Or just declare it in mir_client_library_debug.h and allow it to be assigned to <kdub> yeah, i'll see which is nicer (i'll try to keep the struct containing the function pointers hidden) <racarr> Morning...! <racarr> Zzzz. im not sure its worth it for me to go to the late night weekly <alan_g> Afternoon...! <racarr> because I try but this ends up happening every week <racarr> Hey alan_g ! How have you been? <alan_g> ;) <alan_g> racarr: I've been good. <alan_g> How was your vacation? <racarr> alan_g: It was great! <racarr> Left a significant portion of my stress in the desert :) <alan_g> Excellent. (Now let's see if we can fix that...) <alan_g> racarr: kdub: I've left a couple of MPs for you to review. <kdub> will look * alan_g sneaks off 3 minutes early to mother-in-law's birthday... <kdub> fun gcc error: "The bug is not reproducible, so it is likely a hardware or OS problem." <racarr> kdub: Lol beautiful <ricmm> olli_: kgunn sorry guys chrome crashed <robert_ancell> racarr, "Renamed toggle_dpms to toggle_dpms_between_on_and_off" - love it :) <racarr> robert_ancell: :D I felt pretty happy about that too <racarr> ricmm: Can you tell me more about the screen blanking stuff in upowerd and the small hack you mentioned? I think our DPMS support API is pretty ready to land, so if the mechanism is simple <racarr> maybe I can just do the android impl...like right now! <kgunn> rsalveti: ^ <rsalveti> cool <kgunn> rsalveti: also...did i see you mention it was easy to crash (or freeze) mir on N4 today ? <rsalveti> kgunn: yup <rsalveti> just installed today's mir image, and could easily crash mir when opening the browse-app, getting back to the shell and then killing the app <kgunn> rsalveti: any particular sequence? ( ive been testing regularly....but admit, i hadn't updated today) <kgunn> eeewww <rsalveti> let me reboot and give it another try <kgunn> rsalveti: one more....what are "input_tests" ? <kgunn> e.g. how to replicate what you see in terms of failed input handling <rsalveti> oh, it's just that currently powerd is listening for the input events directly <rsalveti> to support the power button <rsalveti> that's not the desired way when mir is in place, but it was the way we did this with SF <racarr> Howshould powerd get the power button <racarr> without a window, it doesnt seem it should get it from mir <rsalveti> what I tried to check is if we were able to get the input events via hal, which wasn't the case <racarr> so it needs to communicate with unity somehow <rsalveti> seems Mir was getting all the events somehow <rsalveti> well, powerd is not the right one to handle the power button <ricmm> racarr: not really, just exploring a simple interface via the HAL <ricmm> racarr: I can take a look at it <ricmm> the shell needs to implement policy, powerd execute it <rsalveti> as we discussed during that previous call, we need someone that is already handling the input events
{'channel': 'ubuntu-mir', 'month': 9}