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