[08:22] <duflu> That's confusing. Linking a bug to a branch changes the branch's last modified date
[09:52] <alan_g> duflu: how do you envisage getting a scale factor from "Alt+middle_button"?
[09:56] <duflu> alan_g: Pythagoreoan distance from the point of clicking to current cursor pos
[09:57] <duflu> alan_g: Kind of like the way we scale on touch in the demo shell
[09:57]  * duflu -> dinner
[09:58] <alan_g> I'm still missing something: isn't the point of clicking the current cursor position?
[09:59]  * alan_g sees duflu has gone
[09:59] <alan_g> Ah! middle click & drag
[11:59] <greyback_> stupid question, but I don't see it anywhere in the code: is the DPI of a monitor calculated anywhere?
[11:59] <greyback_> alf: ^
[12:00] <alf> greyback_: not at the moment (but all the info is there)
[12:01] <greyback_> alf: ok, was just checking
[12:01] <greyback_> thanks
[12:12] <greyback_> alf: Ive another stupid question, does DPI depend on the resolution you've chosen for your monitor? Or it depends on the actual number of pixels it has?
[12:18] <alf> greyback_: resolution, since even though the monitor may have a finer grain than the current resolution it's not really available to us
[12:19] <greyback_> alf: ok, is what I guessed, thanks! Is it worth doing that sum though, if you get weird fractional values? Should there be a small set (72, 96..) we choose from?
[12:19] <greyback_> not sure how toolkits deal with weird values for DPI
[12:25] <alf> greyback_: Not sure either, but if toolkits want to support real sizes properly they need to handle all possible values.
[12:26] <greyback_> alf: indeed. Think will be truthful for now, and then see which toolkits give trouble. Thanks
[15:40] <anpok_> hm shoold key modifiers work globally for all attached input devices
[15:40] <anpok_> *should
[15:41] <anpok_> X behaves that way.. the android input stack does that too
[18:28] <racarr> anpok_: Seems like ok behavior...I guess we will eventually have to support both and let shell decide
[18:59] <anpok_> racarr: somethig odd i noticed becayse modifier state is currently unified by eventhub.. as it queries all devices it knows.. but it has no clue about devices added with libinput
[19:00] <anpok_> which is probably no problem since i would use the android code for everything not a touchpad
[22:41] <racarr> BufferStream 2.0 aka "gently introduce buffer stream" seemingly done...requires a round of review from myself though.
[22:42] <racarr> This just factors our the common MirScreencast and MirSurface code
[22:42] <racarr> and tests, etc...in toa  client internal
[22:42] <racarr> MirBufferStream
[22:42] <racarr> then I should be able to rebase intro-buffer-stream on it and
[22:42] <racarr> well, the lack of code duplication should make it a lot more compelling :)
[22:53] <mhall119> kdub: FYI,had the graphics issue again and restarting lightdm fixed it
[22:53] <mhall119> http://paste.ubuntu.com/9752519/ shows RAM usage before and after
[22:53] <mhall119> not sure if that helps or not
[23:55] <greyback__> mhall119: please update https://bugs.launchpad.net/mir/+bug/1383745 with your finding, it implies either the userland driver or Mir has an issue