| duflu | RAOF: Is this up your alley? https://bugs.launchpad.net/mir/+bug/1524161 | 02:59 |
|---|---|---|
| ubot5 | Ubuntu bug 1524161 in Mir "[ FAILED ] ClientSurfaceEvents.surface_receives_output_event_on_creation " [Undecided,New] | 02:59 |
| RAOF | duflu: Sure, let me look at it. | 04:21 |
| RAOF | Good, good. Of course I can't cause that locally... | 04:51 |
| RAOF | Oh! | 04:52 |
| RAOF | duflu: Ah, yes. This is because Alan is wrong about not needing std::future<void> there :) | 04:54 |
| duflu | You mean the thing that's about to land... :) | 04:59 |
| RAOF | Well, that isn't, because CI correctly failed the autolanding? | 04:59 |
| duflu | Oh, right | 05:02 |
| === chihchun_afk is now known as chihchun | ||
| 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:22 |
| duflu | Maybe Google did it in the kernel | 09:23 |
| duflu | Assuming we've upgraded | 09:23 |
| duflu | Still the 59Hz trick provides visibly much lower latency | 09:28 |
| anpok_ | no I havent noticed that | 09:36 |
| anpok_ | but we did switch to monotonic timestamps | 09:36 |
| 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:37 |
| duflu | So the change happened in the OS and not Mir | 09:38 |
| duflu | At least aliasing (and reprocessing) are both reduced now we're mapping 60Hz->59Hz vs the old 96Hz->59Hz | 09:39 |
| duflu | anpok_: Also the mako kernel is now from Sep 3 2015 | 09:40 |
| anpok_ | well thats the old kernel + new bluetooth stack | 09:40 |
| duflu | *shrug* | 09:41 |
| anpok_ | hm that happened in september already hmm | 09:41 |
| duflu | Yeah still 3.4.0 | 09:41 |
| duflu | anpok_: It's a xenial (devel-proposed) image so possibly not in production | 09:42 |
| anpok_ | hm mtk drivers really hated the image changes.. and caused a month full of ci problems | 09:43 |
| === greyback__ is now known as greyback | ||
| === marcusto_ is now known as marcustomlinson | ||
| jgdx | greyback, hey, who do I talk to about keyboard layouts? | 12:24 |
| greyback | jgdx: anpok_ probably to start with | 12:25 |
| jgdx | greyback, thanks | 12:25 |
| 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:27 |
| jgdx | anpok_, aah, never mind. It's xkb_mapper's XKBMapper.set_rules I assume? | 12:33 |
| anpok_ | jgdx: yes there | 12:46 |
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| jgdx | anpok_, and how do I get there from a mirconnection? /cc greyback | 14:59 |
| anpok_ | jgdx: why would you want to get there? | 15:02 |
| 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:03 |
| 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:04 |
| 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:05 |
| anpok_ | just kann surface->set_keymap(xkb_rule_names_thing); | 15:06 |
| anpok_ | *call | 15:06 |
| anpok_ | jgdx: let me guess.. the keyboard indicator is a client? | 15:07 |
| 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:08 |
| 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:09 |
| jgdx | anpok_, will setting the keymap for the shell set it for all surfaces? | 15:11 |
| greyback | anpok_: we've nothing implemented in unity8 for keymap support | 15:12 |
| 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:13 |
| 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:18 |
| 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:19 |
| greyback | jgdx: making an indicator for this is far more work than unity8 doing it internally. | 15:20 |
| 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:21 |
| kenvandine | damn | 15:22 |
| kenvandine | greyback, ok, bfiller said he'd attend it | 15:23 |
| 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:31 |
| 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:33 |
| anpok_ | greyback: the universal default keymap ... en_us .. | 15:38 |
| 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 | 15:39 |
| === tvoss is now known as tvoss|dinner | ||
| Saviq | kdub, are you aware we've qtmir in flight in silo 22 already? | 16:14 |
| 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:15 |
| 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:19 |
| ondra | kdub let me know if you need more help | 16:59 |
| kdub | ondra, i'm into the device, should be good for the first round | 17:00 |
| kdub | thanks ! | 17:00 |
| 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:01 |
| ondra | kdub if you need to reboot it:) | 17:02 |
| ondra | kdub you are in full control :) | 17:02 |
| === tvoss|dinner is now known as tvoss | ||
| === bschaefer_ is now known as bschaefer | ||
| RAOF | anpok: Indeed; any events you send to a surface *during* its construction are received immediately(ish). | 22:16 |
| anpok | hey! | 22:19 |
| anpok | always odd when I see you leave and return on the same day :) | 22:19 |
| bschaefer | i think that means its time to EOD anpok :) | 22:20 |
| RAOF | :) | 22:24 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!