[00:07] <racarr_> Hmm if I was smart I would have first ported MirSurface and MirScreencast to MirBufferStream in an independent MP before adding the surfaceless buffer stream type....
[00:07] <racarr_> and if I was really smart I would probably do that now even though it involves repeating some work
[00:07] <racarr_> :(
[00:07] <racarr_> lol
[01:04] <racarr_> about EOD...
[01:05] <racarr_> Morning duflu :)
[01:16] <duflu> racarr_: Hmm, already?
[01:16] <duflu> racarr_: Hello!
[02:15] <greyback_> duflu_: hey, since I'm up rather late hacking on multimonitor, I'll definitely miss our catchup later on
[02:16] <duflu_> greyback_: Fair enough. I do have a fun WM branch that is usable but it's not pretty enough to propose yet
[02:16] <duflu_> Started down the slippery slope of "hey it's easy to implement all WM at once" without breaking it up
[02:17] <greyback_> duflu_: ok, well we're still stuck with single surface apps just yet, so we need to fix that
[02:17] <greyback_> and all those surface types need to be connected up in qt/gtk...
[02:18] <duflu> greyback_: I'm working on surface states right now. The types work (parenting?) I have deferred to the rest of the team since my proposals were voted down
[02:18] <greyback_> grand so
[02:18]  * duflu looks up Irish vernacular
[02:19] <greyback_> loosely translates to "fair enough"
[02:19] <duflu> greyback_: grand so
[02:19] <greyback_> :)
[02:20] <duflu> greyback_: There's our catchup done. Go sleep
[02:20] <mikodo> I would like to see Mir be developed with it's own feature of inversing the display.(Independant of X or Xmir with "Xcalib" or by using compositors like Compiz and Kwin).
[02:20] <greyback_> duflu: brain still buzzing
[02:21] <duflu> mikodo: That's actually trivial to do in a fragment shader. Only a little messy right now for Mir to switch shaders on the fly. But we'll improve that
[02:21] <duflu> red = 1 - red; green = 1 - green ...
[02:21] <mikodo> duflu, Thanks. I remain hopefull for iths
[02:22] <duflu> mikodo: Although Unity8 replaces most of that so such features would have to be requested from each shell
[02:23] <mikodo> duflu, Here's hoping for it ... Thanks
[02:24] <duflu> mikodo: When and if I get to implementing dynamic shader switching I'll make that the first test case, for the Mir demo shell at least. You'd have to request it from Unity8 separately
[02:24] <mikodo> duflu, hmm, where
[02:24] <duflu> mikodo: https://bugs.launchpad.net/ubuntu/+source/unity8/+filebug
[02:25] <mikodo> duflu, When should I ask
[02:26] <greyback_> mikodo: right now, so we can keep it in mind, with other a11y features like zoom, high contrast, etc
[02:26] <duflu> mikodo: Whenever you like. Worst case is they will say "never". But ideally it will get logged as an enhancement for future
[02:26] <duflu> mikodo: greyback_ is the Unity8 man
[02:26] <duflu> And needs sleep
[02:26] <mikodo> duflu, Thank you. Alright.
[07:19] <duflu> That's annoying. The only Nvidia low-profile fanless cards that fit in my system are still the old 210's
[07:19] <duflu> Although a 610 with a fan will fit
[10:08] <duflu> alf__: Also software cursor during zoom FTW (Super+mousewheel)
[10:17] <alf__> duflu: indeed
[10:17] <duflu> alf__: Between zoom and rotation it's easy to see the renderer/compositor needs to speak up when software cursors are needed
[15:45] <seb128> hey there
[15:45] <seb128> question for you ;-)
[15:45] <seb128> how work does Mir support multimonitor atm, is there work planned for that already/if so where are the specs/details?
[15:46] <seb128> things like geometry of the monitor, their respective position, having a primary monitor concept, etc
[15:46] <seb128> equivalent to xrandr apis to change those
[15:48] <alan_g> seb128: there is some basic support. See examples/example_display_configuration_policy.h but it is currently left to the shell to implement any logic around it
[15:49] <seb128> alan_g, thanks
[15:50] <seb128> alan_g, that file doesn't have a lot, it suggests that the option are mirror or side-by-side?
[15:51] <seb128> I guess no way to do like in xrandr atm, define position, like one monitor on top of the other one?
[15:52] <kdub> there is... "mirout"
[15:52] <alan_g> seb128: something would have to implement a cleverer policy that the proof-of-concept examples there
[15:52] <seb128> kdub, alan_g, are what is currently supported and what is planned documented somewhere?
[15:52] <seb128> the cleverer policy is mir work? or shell/unity8 one?
[15:55] <alan_g> libmirserver supports mirroring. There's an example that also supports sidebyside and single display to prove other options are possible.
[15:56] <alan_g> We don't have any other options in our "backlog" AFAIK - but...
[15:57] <anpok> alan_g: hm i think seb128 means free placement of outputs and resolution changes per output..
[15:57] <anpok> during runtime ..
[15:57] <kdub> we can do that
[15:57] <kdub> on mesa
[15:59] <seb128> it means that it should be working/we could write a configuration UI for unity8-desktop-next?
[15:59] <seb128> like do the same current desktop do
[15:59] <seb128> allow to move monitors on the left/right/top/bottom, change their resolution, define which one is primary, etc?
[15:59] <seb128> mir supports it and client apis are there?
[16:00] <seb128> kdub, ?
[16:00] <alan_g> kdub: isn't http://unity.ubuntu.com/mir/group__mir__toolkit.html#ga89043c48c15e7a020619fdd80e6a46dc etc session local?
[16:02] <alan_g> I mean  mir_connection_apply_display_config() applies to the current session, not to the desktop env
[16:02] <kdub> alan_g, yes, iirc, it applies to the current session
[16:02] <seb128> what's the difference between current session and desktop env?
[16:03] <alan_g> seb128: the session belongs to a client application
[16:05] <seb128> like unity8?
[16:06] <alan_g> seb128: like camera
[16:06] <seb128> hum, how that works?
[16:06] <seb128> usually you configure your monitor setup as you wish your config to be and stay
[16:07] <seb128> like external 24" on the left, laptop on the right
[16:07] <seb128> and something apply that config on start
[16:07] <seb128> and it stays until something change it
[16:07] <seb128> what would be the client application in that case?
[16:09] <alan_g> seb128: that's why I didn't think what kdub referred to met your need
[16:10] <seb128> k, thanks
[16:10] <seb128> where should I open a bug if I register one about my usecase
[16:10] <kdub> right, I don't think it would either, now that I understand better, although we do have a lot of the plumbing, more modifying the policy
[16:11] <seb128> mir? unity8? something else?
[16:11] <seb128> kdub, willcooke asked me to register bugs for things we need from mir to have a full desktop, trying to do that ;-)
[16:11] <alan_g> kgunn: where does this belong? ^^
[16:12] <kgunn> just a sec, on a hangout...
[16:16] <kgunn> camako: ^ you might read thru as well....
[16:17] <camako> kgunn, I was
[16:17] <kgunn> so i can see on desktop where there may be fixed physical screens with relative position, this makes sense, but with say phone/monitor it doesn't
[16:18] <kgunn> surely we want the feature, question is...where does the logic/tracking reside & where does the policy decide
[16:18] <kgunn> sort of feels like mir should prolly keep track of the positions for any sort of optimizatino or shared FB or some such could happen
[16:19] <kgunn> but then shell would determine policy, e.g. i'm on a desktop or i'm on phone , a-la hypothesis generator from
[16:19] <kgunn> https://docs.google.com/a/canonical.com/presentation/d/1K1oV4vMc-FduKUNYYO62zPUCU5WMb74zjer8KzYzhLg/edit#slide=id.p
[16:20] <kgunn> greyback: mzanetti ^
[16:20] <kgunn> in short, to support relative monitor placements in a converged world...
[16:20] <greyback> sounds like htere's no one answer for all our convergence cases
[16:22] <greyback> I guess some displays could be isolated from others, i.e. phone UI probably should not be part of the entire "virtual desktop", as it doesn't make a huge amount of sense to drag an app to the phone screen with a mouse
[16:22] <kgunn> seb128: so is system-settings a client of mir in any way today ?
[16:23] <seb128> kgunn, well, system settings is a standard app, I expect it to write some configuration on disk but it's not a service so it's not going to apply it, unity8 should probably be the one doing that
[16:23] <greyback> perhaps Mir could tag some displays as being configurable, and some as not - shell could decide which display is and isn't configurable
[16:23] <kgunn> seb128: yep...
[16:24] <kgunn> greyback: when you say "configurable" you mean...can have a relative position to the other display ?
[16:24] <seb128> greyback, well, on "docked phone" it could make sense to be able to turn the screen of the phone on or off, the same way you do it today for a docked laptop
[16:24] <greyback> kgunn: yeah
[16:25] <greyback> seb128: true.
[16:26] <kgunn> it does make sense tho that mir would need to add "output" coordination...to render windows across screens, and mouse trajectory etc
[16:27] <greyback> sounds like we want Mir to support multiple display collections. phone display would be set as member of a single collection, on it's own. Then multiple monitors could all belong to another collection. Displays in a collection can be configured relatively to eachother
[16:27] <greyback> only a single collection can capture a mouse
[16:28] <greyback> windows/applications cannot be shared across collections
[16:30] <seb128> greyback, greyback, I get from that discussion that we don't have a blueprint/bug/googledoc discussing those needs yet?
[16:31] <greyback> seb128: I'm not aware of any docs on the topic
[16:31] <seb128> where should we start? with a bug report against mir?
[16:31] <greyback> bug to start, but really we need to determine what is actually wanted
[16:32] <greyback> scope is kinda big
[16:32] <kgunn> seb128: yeah...and you're early :)
[16:32] <seb128> yeah
[16:32] <seb128> kgunn, well, willcooke asked us to register bugs for things that "desktop is going to need from mir"
[16:32] <seb128> that's one of those
[16:32] <seb128> we need to know what is missing to get a full desktop
[16:32] <seb128> so we need to start listing those
[16:32] <seb128> even if it's early to work on them
[16:32] <kgunn> seb128: absolutely, no worries
[16:33]  * willcooke likes being early
[16:33] <willcooke> but is late to this conversation
[16:33] <willcooke> :)_
[16:33] <seb128> hehe
[16:34] <kgunn> seb128: likely would need a bug on design as well...like, what do we want to do on phone/tablet....
[16:34] <kgunn> e.g. android made a real concrete decision to just mirror
[16:34] <seb128> kgunn, bug on ubuntu-ux/mir/unity8 I guess
[16:34] <kgunn> yeah
[16:35] <seb128> well, android doesn't claim to support developer desktops yet
[16:35] <kgunn> i think we should collectively design a phase 1 tho...
[16:35] <seb128> they might revisit if/when they try to reach there
[16:35] <kgunn> e.g. desktop we want parity, phone should at least mirror
[16:35] <seb128> right
[16:35] <kgunn> i could totally see on phone
[16:35] <kgunn> having a glowing-edge or something where you can flick apps or some such
[16:36] <kgunn> to magically appear on monitor
[16:36] <kgunn> kind of special desktop extend mode...
[16:36] <kgunn> or phone becomes a remote or vcr-button mode
[16:37] <camako> ... yeah a lot more can be done on a phone, though... depending on how much we wanna do
[16:37] <kgunn> camako: yeah...i heard a rumor you once had to work on such stuff :-P
[16:38] <camako> heh.. I heard that rumor too.
[16:38] <kgunn> camako: so i think we just found something for alf and alan to work on in the new year ;)
[16:39] <camako> kgunn, yeah.. this is very murky though, we need arch/design input in terms of how far we want to go
[16:41] <camako> do we want apps to be aware of these displays and change their behaviour, etc.. (the "remote control" use-case requires that)
[16:41] <camako> anyways, let's start with a bug
[16:41] <camako> :-)
[16:43] <kgunn> camako: agree with murky statement, hence i'll take it on me to draft a spec for something like a phase1(desktop parity & reasonable expectations for phone), we can include ideas for future under a phase2
[16:44] <camako> kgunn, sure
[17:06] <racarr_> camako: Did you mean to update your review status on
[17:06] <racarr_> add-more-event-getters?
[17:07] <greyback> can anyone tell me how/where Mir decides to use clone mode for multimonitors?
[17:07] <racarr_> greyback: I think you are looking for the DefaultDisplayConfigurationPolicy
[17:08] <camako> racarr, I was hoping to see something logged for the aborts.
[17:16] <racarr_> camako: oh ok
[17:24] <greyback> racarr_: that's it, thanks
[17:39] <racarr_> hmm wait
[17:39] <racarr_> why have I
[17:39] <racarr_> lol these statements were originally assert
[17:39] <racarr_> and now they are aborts
[17:39] <racarr_> preceded by log strings
[17:39] <racarr_> that contain
[17:39] <racarr_> assertions
[17:39] <racarr_> :/
[17:40] <racarr_> lol I guess they are ok in release builds though
[17:45]  * alan_g would have been happy with #undef NDEBUG
[17:55] <alan_g> camako: could you find time to review this today? https://code.launchpad.net/~alan-griffiths/mir/publish-server-examples-and-docs/+merge/244026
[17:56] <camako> alan_g, yep I was working on it right now as a matter of fact
[17:56] <alan_g> camako: then note that I've just updated it
[17:56] <camako> alan_g, ok, I'll refresh
[18:05] <racarr_> camako: What do you think the log messages should say? I can't think of anything useful
[18:05] <racarr_> the only thing interesting afaics is the calling frame which we obviously dont have
[18:13] <kdub> racarr_, would BlankingHwcControl be a better name?
[18:13]  * kdub agrees that it could be better
[18:13] <kdub> and the 1.4 impl would be PowerModeHwcControl
[18:14] <racarr_> kdub: Yeah I think that does make more sense
[18:15] <bschaefer> greyback, hey, any luck with those pixel formats + sdl?
[19:28] <greyback> bschaefer: not had chance to give it a go yet, sorry
[19:28] <bschaefer> greyback, no worries :), jsut wanted to double check
[21:15] <mibofra> hi guys
[21:15] <mibofra> does someone remeber me xD ?
[21:20] <anpok> how could we forget
[21:41] <mibofra> lol hi anpok
[21:44] <mibofra> anyway, I'm again with utouch in chroot, another setup, on the latest rootfs. Now everything seems to not prompt errors, egl demos too (anyway only render_to_fb continue displays something )
[21:44] <mibofra> but I've started another mir demo server and mir_stress
[21:44] <mibofra> with mir_stress I get this: UMP: ump_arch_open() failed to open UMP device driver
[21:45] <mibofra> (notice that I've /dev/mali and /dev/ump reachable)
[21:49] <anpok> what do you mean by another?
[21:50] <anpok> in parallel to an already running one?
[21:51] <mibofra> anpok, deteled the other one and set up another
[22:00] <anpok> deleted the server?
[22:02] <mibofra> anpok, deteled all the rootfs and unrolled the latest
[22:02] <mibofra> mounted in bind /dev and company
[22:03] <mibofra> chrooted on ubuntu touch
[22:04] <anpok> ah reading correctly helps
[22:12] <anpok> mibofra: i can only guess (and I would start by looking at which operation failed through strace) AlbertA isnt here and kdub might have better ideas
[22:13] <mibofra> anpok, ok
[22:17] <kdub> mibofra, yeah, only one hwc-owning server should run at a time
[22:18] <mibofra> kdub, and I've only one server in background xD
[22:18] <mibofra> *ad noone in foreground
[22:20] <kdub> for a total of 2 running servers in the system?
[22:25] <kdub> also mibofra, does the server and basic clients work?
[22:25] <kdub> if it does, perhaps the stress test is just covering a corner case that we have a problem with (and most usecases would still work)
[22:31] <mibofra> kdub the matter is that now clients and demos run fine, but without displaying something, except form the standalone_render_to_fb
[22:31] <kdub> try running the server with "--disable-overlays true"
[22:55] <mibofra> ok
[23:01] <mibofra> kdub, the same