[06:30] <robert_ancell> RAOF, Can Xephyr be run in rootless mode?
[06:30] <RAOF> robert_ancell: I don't believe so, but could probably be made to do so easily.
[06:31] <robert_ancell> RAOF, define "easily" :)
[06:31] <RAOF> robert_ancell: Well, you'd get most of the way there by having a root window and just making it transparent? :)
[06:32] <robert_ancell> RAOF, but then the window decorations would get very complicated for the internal WM
[06:32] <RAOF> Yeah, is true.
[06:33] <RAOF> So, my guess is “not *terribly* difficult or invasive”.
[06:33] <RAOF> Well, maybe a *bit* invasive.
[06:34] <RAOF> Say, less than a month all up?
[06:35] <robert_ancell> For who? I think it would be more than that for me given my experience. Perhaps a RAOF+duflu team would do it in a month..
[06:36] <robert_ancell> RAOF, with XMir in rootless mode, how much work does the window manager need to do? The placement should all be done by the parent WM right?
[06:36] <robert_ancell> I mean the WM that runs inside XMir
[06:36] <RAOF> Yeah.
[06:37] <RAOF> The end-state for XMir in rootless mode is that the X11-WM is basically nothing but a proxy to the external WM.
[06:37] <RAOF> Needs to do a bit of translation for resizing and such.
[06:38] <duflu> robert_ancell: Xmir -rootless completely throws away the window manager, and implements WM itself Mir-style
[06:39] <robert_ancell> duflu, ah
[06:39] <duflu> You could still run one, but it might conflict
[06:39] <robert_ancell> So XMir on X would probably be the most working solution...
[06:39] <duflu> robert_ancell: On X?
[06:40] <robert_ancell> Mir has an X backend right?
[06:40] <robert_ancell> (I'm kidding)
[06:40] <duflu> robert_ancell: Yes it does exist, but that's fullscreen Mir server in an X window
[06:42] <duflu> robert_ancell: Xmir -rootless implements its own XComposite-based window management. I know of no shell that handles it well yet, but also implemented a workaround for that too: Xmir -rootless -flatten  which only asks the Mir shell to implement one window per app (which most Mir shells can handle)
[06:43] <duflu> Umm, I mean -flatten uses XComposite
[06:44] <duflu> So Xmir uses Xorg to do the compositing in software with -rootless -flatten
[06:44] <duflu> Actually since widgets are windows, that's normal
[06:53] <RAOF> It's not using the hardware-accelerated compositing path?
[06:54] <duflu> Nope. Because that's actually very buggy, and not beneficial to pursue right now either
[06:55] <RAOF> That seems unlikely? We're using the same glamor hardware-composited path on regular X.
[06:55] <duflu> RAOF: armhf is set to always software anyway. Desktop is not
[06:56] <duflu> That's why it works
[06:56] <RAOF> That I can see; armhf glamor is unlikely to be awesomely well tested :)
[07:00] <duflu> Hardware acceleration matters much more for GLX clients. However that's only really feasible with DRI (desktop hardware)
[07:00] <duflu> And in all fairness, even software buffers are cached in hardware for most of their life, so performance is good
[07:04] <RAOF> Right, but GPU composition is vastly faster than CPU composition on all hardware.
[07:04] <RAOF> If you're actually *doing* any composition...
[07:06] <duflu> RAOF: True, but "vastly" is still completely insignificant compared to even a single frame of lag. And we have several frames of lag.
[07:06] <duflu> So that gets attention first
[07:07] <RAOF> I don't think that's the case?
[07:07] <RAOF> As evidenced by your discovery that your monitor introduces a 20ms delay that you were entirely unaware of.
[07:07] <duflu> It is. Proof: Software rendering completes in well under 16ms even on mobile. Our buffering lag is closer to 90ms
[07:08] <RAOF> But that's two different types of milliseconds :)
[07:08] <duflu> RAOF: In user perception
[07:09] <RAOF> But as long as rendering *is* maintaining 60Hz, lag is indeed a more interesting target.
[07:09] <duflu> It is. Software rendering is very fast even on a phone (with the exception of the infamous OTA-10 regression)
[07:10] <RAOF> Right. User perception is “30Hz is worse than a consistent 90ms of lag, even though frames containing my input reach the screen faster”.
[07:11] <duflu> RAOF: Agreed, but that's not an issue. Also it would be irresponsible to pursue. Do you want Xmir working in 2015 as it was, or wait till 2017/2018?
[07:11] <RAOF> Yeah, I'm agreeing with you.
[07:11] <RAOF> As long as we're hitting frame deadlines, we don't *really* need to increase rendering performance.
[07:13] <duflu> RAOF: Even still, less important than our other current performance focal points
[07:14] <duflu> No one cares if you've made Xmir faster if you had to stop working on improving the performance of all of Unity8
[07:32] <zzarr> hello! does Mir software rendering work now?
[07:34] <duflu> zzarr: In very very limited conditions. Depends what you're trying to do
[07:34] <duflu> But mostly not
[07:35] <zzarr> duflu, I'm not trying to do anything right now, it was just a general question
[07:36] <duflu> We are making baby steps in other tasks that will help generic software rendering in future
[07:37] <zzarr> nice
[07:48] <zzarr> of course I still want to try to get Ubuntu with Mir running om my chromebook
[07:49] <zzarr> it's vital that I can turn both the touch pad and keyboard off when flipping it
[07:50] <zzarr> (ti's an Asus Chromebook Flip)
[07:50] <zzarr> it's*
[07:51] <anpok> so you want them to be gone.. so that unity8 discovers that there are not more desktop input device, so it would switch to the tablet ui?
[07:52] <zzarr> anpok, exactly
[07:59] <duflu> Do we need to test of integer wraparounds that will happen after the Sun engulfs the Earth?
[07:59] <duflu> I guess we should assume Mir is running outside the solar system
[08:01] <anpok> zzarr: hm we should have the necessary interfaces in mir
[08:02] <anpok> zzarr: but you would need changes to unity-system-compositor to deal with that... detect the lid switch telling you the flip state?.. hm.
[08:02] <zzarr> anpok, nice
[08:02] <zzarr> anpok, I don't know
[08:03] <anpok> sounds like hwdb in usc .. dmidecode.. have lots of rules for various devices..
[08:04] <anpok> oh i believe we do not expose the input device registy in the mir server api... but thats the smallest problem
[08:04] <anpok> i thought about another interface to allow the compositor to filter out input devices..
[08:04] <zzarr> anpok, okey, sadly I don't know anything about that, I just have a vision that I one day can run Ubuntu/Mir on my laptop
[08:06] <zzarr> well, a script telling mir/unity that it should enter tablet mode and one that tells it to enter desktop mode would be nice
[08:07] <zzarr> are the input filtered or are they turned off? (hw)
[08:07] <anpok> hm ... if you would tell an InputDevice to stop libinput would still read from evdev
[08:08] <anpok> but thats an implementation detail.. because we use libinputs udev handling.. and turning it off and on again would require to retrigger scanning udev devices..
[08:09] <anpok> the reason for using that are also further implementation details in libinput itself .. because of historic reasons it does certain init steps only when you let it handle udev..
[08:10] <zzarr> I'm feeling I'm on thin ice... never mind you answered the question before I asked it
[08:10] <anpok> is it important that evdev events are not consumed?
[08:10] <anpok> believe me there is no ice
[08:12] <zzarr> anpok, does evdev events trigger text on the screen? (keyboard inputs)
[08:13] <anpok> well input events take a route through the system compositor down to the focused client i noone filters it along that line.. and the rendered results comes back to screen
[08:13] <anpok> *if no one filters it
[08:20] <zzarr> okey, in that case, yes it is important that it's filtered (the keyboard/mouse pad ends up on the backside when flipped)
[08:20] <anpok> oh
[08:20] <anpok> I thought the screen is rotated then closed
[08:26] <zzarr> this image shows the form factor http://liliputing.com/wp-content/uploads/2015/03/asus-chromebook-flip_02.jpg
[08:38] <robert_ancell> duflu, RAOF, I figure it's about time to propose XMir upstream. Any opposition?
[08:38] <duflu> robert_ancell: Ha. I would not have except just landed an emergency fix from Chris Townsend today. Not sure how to test it
[08:39] <robert_ancell> duflu, I expect upstream is not going to test it in any detail anyway, so shouldn't be a problem.
[08:39] <duflu> Upstream would need Mir to complain about anything. So long as we don't break code outside our own dir
[08:40] <robert_ancell> Exactly. And it seems to be in well self contained now
[09:06]  * duflu is guessing there are lots of desktoppers in London
[09:06] <robert_ancell> Prague
[09:06] <duflu> Close
[09:06] <duflu> Closer than here
[09:06] <robert_ancell> Yep
[09:06] <duflu> robert_ancell: What venue?
[09:06] <robert_ancell> Hotel
[09:07] <duflu> robert_ancell: Erm, which?
[09:07] <robert_ancell> https://www.google.cz/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0ahUKEwjHiY7S_bDMAhVqAZoKHXi5DiYQFggdMAA&url=http%3A%2F%2Fprague.boscolohotels.com%2F&usg=AFQjCNGa9EmXsm9WPTU0TKXUdwLjaNbSvQ
[09:07] <robert_ancell> ah, stupid google links
[09:07] <robert_ancell> http://prague.boscolohotels.com/
[11:14] <alan_g> attente: I'm working through the window management issues in Mir. It looks like gtk-mir might the cause of lp:1445543 - I've updated the description with a specific case that seems to show Mir passing events to the client that are ignored, can you check what happens in gtk?
[11:19] <attente> alan_g: hey, sorry. i got your message, but didn't have a chance to check yet
[11:20] <alan_g> attente: np
[11:45] <bregma> hey robert_ancell I was going to ask if there was any reason (like maybe an Intel incident) why we haven't upstreamed XMir...  I guess my question has been answered
[11:46] <bregma> are you willing to do the work?
[11:46] <robert_ancell> bregma, yep
[11:47] <bregma> great
[11:50] <anpok_> bregma: looked at our xkb mapping code..
[11:51] <anpok_> the altGr problem could be caused by other problems
[11:51] <robert_ancell> hmm, why can't I VT switch out of mir_demo_server anymore?
[11:51] <bregma> anpok_, problems within Mir, or elsewhere?
[11:51] <anpok_> we seem to use the api wrong..
[11:51] <anpok_> yeah mir client.. i finish up the nested stuff and verify that theory
[11:51] <alan_g> robert_ancell: it should be possible - I do it a lot
[11:52] <bregma> anpok_, OK, so still Mir but on the client library?
[11:52] <anpok_> yes
[11:52] <bregma> k
[11:52] <robert_ancell> alan_g, yeah, it used to work fine. But not working for me right now... alt+ctrl+backspace seems to quit it, but not mir_demo_server_minimal
[11:53] <alan_g> robert_ancell: minimal doesn't install the quit handler
[12:01] <robert_ancell> alan_g, is there any easy way to log the keyboard events?
[12:01] <anpok_> MIR_CLIENT_INPUT_RECEIVER_REPORT=log
[12:02] <anpok_> oh in a server?
[12:02] <robert_ancell> anpok_, yeah, the server
[12:02] <anpok_> MIR_SERVER_INPUT_REPORT does some logging.. not sure if it contais key code
[12:02] <anpok_> *contains key codes
[12:03] <robert_ancell> hmm, doesn't seem to
[12:03] <robert_ancell> I'm wondering if it doesn't work because I need to hold down 'Fn' for my F keys
[12:04] <robert_ancell> If I can get a log of keycodes that might help
[12:05] <anpok_> hm ok it does .. you should see "Received event .. type=EV_KEY code=<some number> value=0/1"
[12:06] <anpok_> when you set that env var to =log
[12:06] <robert_ancell> I got nothing when I set MIR_SERVER_INPUT_REPORT=log
[12:06] <robert_ancell> But mir_demo_server --print-input-events does something, but the output seems to overwrite so I can't read it
[12:07] <robert_ancell> http://paste.ubuntu.com/16094191/
[12:08] <robert_ancell> Should the keycode always be 0?
[12:10] <robert_ancell> The only scancodes seem to be alt, ctrl and backspace. i.e. nothing for Fn or the function keys
[12:10] <anpok_> yeah.. no scan to key code translation on the server
[12:11] <anpok_> ok thats.. odd..
[12:12] <robert_ancell> I wonder if the function keys are done with ACPI?
[12:17] <robert_ancell> showkey suggests F2 is scancode 224, which is KEY_BRIGHTNESSDOWN
[12:18] <anpok_> aeh.. hm but neither libinput nor mir filters out keys
[12:22] <anpok_> robert_ancell: what does evtest say about the input devices that you have?
[12:22] <robert_ancell> ah, KEY_F2 does work, but not in combination with alt+ctrl for some reason
[12:27] <robert_ancell> ok, now with more careful testing, I am getting the event to show with --print-input-events, but still no VT switch
[12:28] <robert_ancell> Seems the order in which I press 'Fn' matters
[12:31] <robert_ancell> ah. I know what this is. The VT switching is done on /dev/console which for some reason stopped working in Xenial. This affected LightDM, so I switched to using /dev/tty0 which is what other things use (GDM, logind).
[12:32] <robert_ancell> I'll make a merge proposal...
[14:42] <robert_ancell> anpok, https://code.launchpad.net/~robert-ancell/mir/vt-tty0/+merge/293277