=== chihchun_afk is now known as chihchun [06:30] RAOF, Can Xephyr be run in rootless mode? [06:30] robert_ancell: I don't believe so, but could probably be made to do so easily. [06:31] RAOF, define "easily" :) [06:31] robert_ancell: Well, you'd get most of the way there by having a root window and just making it transparent? :) [06:32] RAOF, but then the window decorations would get very complicated for the internal WM [06:32] Yeah, is true. [06:33] So, my guess is “not *terribly* difficult or invasive”. [06:33] Well, maybe a *bit* invasive. [06:34] Say, less than a month all up? [06:35] 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] 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] I mean the WM that runs inside XMir [06:36] Yeah. [06:37] 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] Needs to do a bit of translation for resizing and such. [06:38] robert_ancell: Xmir -rootless completely throws away the window manager, and implements WM itself Mir-style [06:39] duflu, ah [06:39] You could still run one, but it might conflict [06:39] So XMir on X would probably be the most working solution... [06:39] robert_ancell: On X? [06:40] Mir has an X backend right? [06:40] (I'm kidding) [06:40] robert_ancell: Yes it does exist, but that's fullscreen Mir server in an X window [06:42] 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] Umm, I mean -flatten uses XComposite [06:44] So Xmir uses Xorg to do the compositing in software with -rootless -flatten [06:44] Actually since widgets are windows, that's normal [06:53] It's not using the hardware-accelerated compositing path? [06:54] Nope. Because that's actually very buggy, and not beneficial to pursue right now either [06:55] That seems unlikely? We're using the same glamor hardware-composited path on regular X. [06:55] RAOF: armhf is set to always software anyway. Desktop is not [06:56] That's why it works [06:56] That I can see; armhf glamor is unlikely to be awesomely well tested :) [07:00] Hardware acceleration matters much more for GLX clients. However that's only really feasible with DRI (desktop hardware) [07:00] And in all fairness, even software buffers are cached in hardware for most of their life, so performance is good [07:04] Right, but GPU composition is vastly faster than CPU composition on all hardware. [07:04] If you're actually *doing* any composition... [07:06] 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] So that gets attention first [07:07] I don't think that's the case? [07:07] As evidenced by your discovery that your monitor introduces a 20ms delay that you were entirely unaware of. [07:07] It is. Proof: Software rendering completes in well under 16ms even on mobile. Our buffering lag is closer to 90ms [07:08] But that's two different types of milliseconds :) [07:08] RAOF: In user perception [07:09] But as long as rendering *is* maintaining 60Hz, lag is indeed a more interesting target. [07:09] It is. Software rendering is very fast even on a phone (with the exception of the infamous OTA-10 regression) [07:10] 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] 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] Yeah, I'm agreeing with you. [07:11] As long as we're hitting frame deadlines, we don't *really* need to increase rendering performance. [07:13] RAOF: Even still, less important than our other current performance focal points [07:14] 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] hello! does Mir software rendering work now? [07:34] zzarr: In very very limited conditions. Depends what you're trying to do [07:34] But mostly not [07:35] duflu, I'm not trying to do anything right now, it was just a general question [07:36] We are making baby steps in other tasks that will help generic software rendering in future [07:37] nice [07:48] of course I still want to try to get Ubuntu with Mir running om my chromebook [07:49] it's vital that I can turn both the touch pad and keyboard off when flipping it [07:50] (ti's an Asus Chromebook Flip) [07:50] it's* [07:51] 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] anpok, exactly [07:59] Do we need to test of integer wraparounds that will happen after the Sun engulfs the Earth? [07:59] I guess we should assume Mir is running outside the solar system [08:01] zzarr: hm we should have the necessary interfaces in mir [08:02] 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] anpok, nice [08:02] anpok, I don't know [08:03] sounds like hwdb in usc .. dmidecode.. have lots of rules for various devices.. [08:04] oh i believe we do not expose the input device registy in the mir server api... but thats the smallest problem [08:04] i thought about another interface to allow the compositor to filter out input devices.. [08:04] 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] 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] are the input filtered or are they turned off? (hw) [08:07] hm ... if you would tell an InputDevice to stop libinput would still read from evdev [08:08] 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] 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] I'm feeling I'm on thin ice... never mind you answered the question before I asked it [08:10] is it important that evdev events are not consumed? [08:10] believe me there is no ice [08:12] anpok, does evdev events trigger text on the screen? (keyboard inputs) [08:13] 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] *if no one filters it [08:20] 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] oh [08:20] I thought the screen is rotated then closed [08:26] this image shows the form factor http://liliputing.com/wp-content/uploads/2015/03/asus-chromebook-flip_02.jpg [08:38] duflu, RAOF, I figure it's about time to propose XMir upstream. Any opposition? [08:38] 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] duflu, I expect upstream is not going to test it in any detail anyway, so shouldn't be a problem. [08:39] Upstream would need Mir to complain about anything. So long as we don't break code outside our own dir [08:40] 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] Prague [09:06] Close [09:06] Closer than here [09:06] Yep [09:06] robert_ancell: What venue? [09:06] Hotel [09:07] robert_ancell: Erm, which? [09:07] 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] ah, stupid google links [09:07] http://prague.boscolohotels.com/ [11:14] 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] alan_g: hey, sorry. i got your message, but didn't have a chance to check yet [11:20] attente: np [11:45] 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] are you willing to do the work? [11:46] bregma, yep [11:47] great [11:50] bregma: looked at our xkb mapping code.. [11:51] the altGr problem could be caused by other problems [11:51] hmm, why can't I VT switch out of mir_demo_server anymore? [11:51] anpok_, problems within Mir, or elsewhere? [11:51] we seem to use the api wrong.. [11:51] yeah mir client.. i finish up the nested stuff and verify that theory [11:51] robert_ancell: it should be possible - I do it a lot [11:52] anpok_, OK, so still Mir but on the client library? [11:52] yes [11:52] k [11:52] 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] robert_ancell: minimal doesn't install the quit handler [12:01] alan_g, is there any easy way to log the keyboard events? [12:01] MIR_CLIENT_INPUT_RECEIVER_REPORT=log [12:02] oh in a server? [12:02] anpok_, yeah, the server [12:02] MIR_SERVER_INPUT_REPORT does some logging.. not sure if it contais key code [12:02] *contains key codes [12:03] hmm, doesn't seem to [12:03] I'm wondering if it doesn't work because I need to hold down 'Fn' for my F keys [12:04] If I can get a log of keycodes that might help [12:05] hm ok it does .. you should see "Received event .. type=EV_KEY code= value=0/1" === alan_g is now known as alan_g|lunch [12:06] when you set that env var to =log [12:06] I got nothing when I set MIR_SERVER_INPUT_REPORT=log [12:06] But mir_demo_server --print-input-events does something, but the output seems to overwrite so I can't read it [12:07] http://paste.ubuntu.com/16094191/ [12:08] Should the keycode always be 0? [12:10] The only scancodes seem to be alt, ctrl and backspace. i.e. nothing for Fn or the function keys [12:10] yeah.. no scan to key code translation on the server [12:11] ok thats.. odd.. [12:12] I wonder if the function keys are done with ACPI? [12:17] showkey suggests F2 is scancode 224, which is KEY_BRIGHTNESSDOWN [12:18] aeh.. hm but neither libinput nor mir filters out keys [12:22] robert_ancell: what does evtest say about the input devices that you have? [12:22] ah, KEY_F2 does work, but not in combination with alt+ctrl for some reason [12:27] ok, now with more careful testing, I am getting the event to show with --print-input-events, but still no VT switch [12:28] Seems the order in which I press 'Fn' matters [12:31] 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] I'll make a merge proposal... === alan_g|lunch is now known as alan_g === dandrader is now known as dandrader|afk === chihchun is now known as chihchun_afk === dandrader|afk is now known as dandrader === _morphis is now known as morphis [14:42] anpok, https://code.launchpad.net/~robert-ancell/mir/vt-tty0/+merge/293277 === dandrader is now known as dandrader|bbl === alan_g is now known as alan_g|EOD === dandrader is now known as dandrader|afk === dandrader|afk is now known as dandrader