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