[02:59] RAOF: Is this up your alley? https://bugs.launchpad.net/mir/+bug/1524161 [02:59] Ubuntu bug 1524161 in Mir "[ FAILED ] ClientSurfaceEvents.surface_receives_output_event_on_creation " [Undecided,New] [04:21] duflu: Sure, let me look at it. [04:51] Good, good. Of course I can't cause that locally... [04:52] Oh! [04:54] duflu: Ah, yes. This is because Alan is wrong about not needing std::future there :) [04:59] You mean the thing that's about to land... :) [04:59] Well, that isn't, because CI correctly failed the autolanding? [05:02] Oh, right === chihchun_afk is now known as chihchun [09:22] anpok_: Did you notice (or did I imagine) that the touchscreen event rate on mako dropped from 96Hz to 60Hz in xenial (devel-proposed)? [09:22] It's not a bad thing though. Keeps latency down. [09:23] Maybe Google did it in the kernel [09:23] Assuming we've upgraded [09:28] Still the 59Hz trick provides visibly much lower latency [09:36] no I havent noticed that [09:36] but we did switch to monotonic timestamps [09:37] which means we are accounting touch events with the time stamp they occured on.. [09:37] this removes the time the server takes to catch up with the device.. [09:37] anpok_: No I sanity checked and tried Mir 0.17 too. It also runs at 60Hz on xenial instead of the old 96Hz [09:38] So the change happened in the OS and not Mir [09:39] At least aliasing (and reprocessing) are both reduced now we're mapping 60Hz->59Hz vs the old 96Hz->59Hz [09:40] anpok_: Also the mako kernel is now from Sep 3 2015 [09:40] well thats the old kernel + new bluetooth stack [09:41] *shrug* [09:41] hm that happened in september already hmm [09:41] Yeah still 3.4.0 [09:42] anpok_: It's a xenial (devel-proposed) image so possibly not in production [09:43] hm mtk drivers really hated the image changes.. and caused a month full of ci problems === greyback__ is now known as greyback === marcusto_ is now known as marcustomlinson [12:24] greyback, hey, who do I talk to about keyboard layouts? [12:25] jgdx: anpok_ probably to start with [12:25] greyback, thanks [12:27] anpok_, let me know when you're back? I have some questions re: layout managing, specifically how to configure layouts, if it's through mir or with xkbcommon directly? [12:27] and if mir, then I can't really find the api bits for it [12:33] anpok_, aah, never mind. It's xkb_mapper's XKBMapper.set_rules I assume? [12:46] jgdx: yes there === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [14:59] anpok_, and how do I get there from a mirconnection? /cc greyback [15:02] jgdx: why would you want to get there? [15:03] it is part of the input event processing [15:03] ah [15:03] you want to configure it yourself [15:03] sorry did not read the backlog entirely [15:04] jgdx: do you want to configure a clients keymap within the shell. or the shells own keymap from within the shell.. or the clients own keymap as a regular client? [15:04] s/clients/client [15:04] anpok_, yes [15:04] :p [15:05] whatever the keyboard indicator does today, I want to replicate [15:05] then you just have to send a keymap event with the xkb_rules to the focused client [15:06] just kann surface->set_keymap(xkb_rule_names_thing); [15:06] *call [15:07] jgdx: let me guess.. the keyboard indicator is a client? [15:08] greyback: or is it part of unity8? [15:08] anpok_, it's not [15:08] … a part of unity8, but it may be a client? Not sure of the definitions in the x world [15:09] jgdx: ok, then you need to find a way to access the currently focused session and the focused surface.. and just set the keymap.. [15:09] or set the keymap for each surface of session.. not sure what behvior is preferred.. [15:11] anpok_, will setting the keymap for the shell set it for all surfaces? [15:12] anpok_: we've nothing implemented in unity8 for keymap support [15:13] I don't even know who is responsible for mapping the actual keys [15:13] afaict, all shell can do is send event to app telling it what keymapping it should perform [15:18] jgdx, greyback: the current keymap is stored client side per surface, we only gurantee that we forward proper scancodes and alreayd interpreted modifier states.. so to control which keymap a client uses a shell just has to set the keymap through the Surface interface [15:19] greyback, could you communicate that ^ to your meeting tomorrow? :) [15:19] greyback: all the indicator would need is access to the currently focused surface or session.. [15:19] if not, I will [15:19] jgdx: ack [15:19] anpok_, configuration will be done via System Settings for now, the indicator hasn't been considered yet [15:19] oh [15:20] jgdx: making an indicator for this is far more work than unity8 doing it internally. [15:21] greyback, is the stake holders meeting you mentioned thursday the 17th? [15:21] greyback, right, I think an indicator is future, not for pd1 [15:21] if the work isn't even prioritized by then, there's really no chance any of it will land for ota9 [15:21] kenvandine: am afraid so [15:22] damn [15:23] greyback, ok, bfiller said he'd attend it [15:31] anpok_, the indicator does pr window but also global keymap configuration, btw [15:31] I think the default is global, which is what we want to do [15:33] anpok_: when an app creates a surface, what is the default keymap? [15:33] anpok_: the API only has a setter, no getter [15:38] greyback: the universal default keymap ... en_us .. [15:39] greyback: sounds like feature request? set the keymap on creation.. [15:39] hm I believe RAOF made an MP to allow that to work before any user input would be received === tvoss is now known as tvoss|dinner [16:14] kdub, are you aware we've qtmir in flight in silo 22 already? [16:15] kdub, also, according to https://requests.ci-train.ubuntu.com/#/ticket/725 qtmir-gles needs a rebuild in your silo, there's a new commit in lp:qtmir/gles that has to deal with new Qt [16:19] kdub, it also says mir needs a rebuild, you can see in https://ci-train.ubuntu.com/job/ubuntu-landing-021-0-status/lastBuild/console why it thinks you need the rebuild [16:19] Saviq, will investigate shortly [16:19] thanks for the heads up [16:59] kdub let me know if you need more help [17:00] ondra, i'm into the device, should be good for the first round [17:00] thanks ! [17:01] kdub ok, you need to reboot it, and reboot, you are on computer connected to it, so should give you more freedom [17:01] ondra, I need to reboot it now? or if i need to reboot it? [17:02] kdub if you need to reboot it:) [17:02] kdub you are in full control :) === tvoss|dinner is now known as tvoss === bschaefer_ is now known as bschaefer [22:16] anpok: Indeed; any events you send to a surface *during* its construction are received immediately(ish). [22:19] hey! [22:19] always odd when I see you leave and return on the same day :) [22:20] i think that means its time to EOD anpok :) [22:24] :)