| 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 | 00:07 |
| racarr_ | about EOD... | 01:04 |
| racarr_ | Morning duflu :) | 01:05 |
| duflu | racarr_: Hmm, already? | 01:16 |
| duflu | racarr_: Hello! | 01:16 |
| greyback_ | duflu_: hey, since I'm up rather late hacking on multimonitor, I'll definitely miss our catchup later on | 02:15 |
| 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:16 |
| greyback_ | duflu_: ok, well we're still stuck with single surface apps just yet, so we need to fix that | 02:17 |
| === duflu_ is now known as duflu | ||
| greyback_ | and all those surface types need to be connected up in qt/gtk... | 02:17 |
| 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:18 | |
| greyback_ | loosely translates to "fair enough" | 02:19 |
| duflu | greyback_: grand so | 02:19 |
| greyback_ | :) | 02:19 |
| 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:20 |
| 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:21 |
| duflu | mikodo: Although Unity8 replaces most of that so such features would have to be requested from each shell | 02:22 |
| mikodo | duflu, Here's hoping for it ... Thanks | 02:23 |
| 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:24 |
| mikodo | duflu, When should I ask | 02:25 |
| 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. | 02:26 |
| === 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 | ||
| 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 | 07:19 |
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| duflu | alf__: Also software cursor during zoom FTW (Super+mousewheel) | 10:08 |
| === ubot5` is now known as ubot5 | ||
| 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 | 10:17 |
| === 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 | ||
| 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:45 |
| 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:46 |
| 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:48 |
| seb128 | alan_g, thanks | 15:49 |
| seb128 | alan_g, that file doesn't have a lot, it suggests that the option are mirror or side-by-side? | 15:50 |
| seb128 | I guess no way to do like in xrandr atm, define position, like one monitor on top of the other one? | 15:51 |
| 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:52 |
| alan_g | libmirserver supports mirroring. There's an example that also supports sidebyside and single display to prove other options are possible. | 15:55 |
| alan_g | We don't have any other options in our "backlog" AFAIK - but... | 15:56 |
| 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:57 |
| 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? | 15:59 |
| seb128 | kdub, ? | 16:00 |
| alan_g | kdub: isn't http://unity.ubuntu.com/mir/group__mir__toolkit.html#ga89043c48c15e7a020619fdd80e6a46dc etc session local? | 16:00 |
| 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:02 |
| alan_g | seb128: the session belongs to a client application | 16:03 |
| seb128 | like unity8? | 16:05 |
| 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:06 |
| 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:07 |
| alan_g | seb128: that's why I didn't think what kdub referred to met your need | 16:09 |
| 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:10 |
| 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:11 |
| kgunn | just a sec, on a hangout... | 16:12 |
| kgunn | camako: ^ you might read thru as well.... | 16:16 |
| 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:17 |
| 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:18 |
| 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:19 |
| 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:20 |
| 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:22 |
| === dandrader|lunch is now known as dandrader | ||
| 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:23 |
| 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:24 |
| greyback | seb128: true. | 16:25 |
| kgunn | it does make sense tho that mir would need to add "output" coordination...to render windows across screens, and mouse trajectory etc | 16:26 |
| 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:27 |
| greyback | windows/applications cannot be shared across collections | 16:28 |
| seb128 | greyback, greyback, I get from that discussion that we don't have a blueprint/bug/googledoc discussing those needs yet? | 16:30 |
| 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:31 |
| 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:32 |
| * willcooke likes being early | 16:33 | |
| willcooke | but is late to this conversation | 16:33 |
| willcooke | :)_ | 16:33 |
| seb128 | hehe | 16:33 |
| 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:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| camako | kgunn, yeah.. this is very murky though, we need arch/design input in terms of how far we want to go | 16:39 |
| 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:41 |
| 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:43 |
| camako | kgunn, sure | 16:44 |
| racarr_ | camako: Did you mean to update your review status on | 17:06 |
| racarr_ | add-more-event-getters? | 17:06 |
| 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:07 |
| camako | racarr, I was hoping to see something logged for the aborts. | 17:08 |
| racarr_ | camako: oh ok | 17:16 |
| greyback | racarr_: that's it, thanks | 17:24 |
| 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:39 |
| racarr_ | lol I guess they are ok in release builds though | 17:40 |
| * alan_g would have been happy with #undef NDEBUG | 17:45 | |
| 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:55 |
| 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 | 17:56 |
| === alan_g is now known as alan_g|EOD | ||
| 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:05 |
| 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:13 |
| racarr_ | kdub: Yeah I think that does make more sense | 18:14 |
| bschaefer | greyback, hey, any luck with those pixel formats + sdl? | 18:15 |
| greyback | bschaefer: not had chance to give it a go yet, sorry | 19:28 |
| bschaefer | greyback, no worries :), jsut wanted to double check | 19:28 |
| mibofra | hi guys | 21:15 |
| mibofra | does someone remeber me xD ? | 21:15 |
| anpok | how could we forget | 21:20 |
| mibofra | lol hi anpok | 21:41 |
| 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:44 |
| mibofra | (notice that I've /dev/mali and /dev/ump reachable) | 21:45 |
| anpok | what do you mean by another? | 21:49 |
| anpok | in parallel to an already running one? | 21:50 |
| mibofra | anpok, deteled the other one and set up another | 21:51 |
| anpok | deleted the server? | 22:00 |
| mibofra | anpok, deteled all the rootfs and unrolled the latest | 22:02 |
| mibofra | mounted in bind /dev and company | 22:02 |
| mibofra | chrooted on ubuntu touch | 22:03 |
| anpok | ah reading correctly helps | 22:04 |
| 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:12 |
| mibofra | anpok, ok | 22:13 |
| kdub | mibofra, yeah, only one hwc-owning server should run at a time | 22:17 |
| mibofra | kdub, and I've only one server in background xD | 22:18 |
| mibofra | *ad noone in foreground | 22:18 |
| kdub | for a total of 2 running servers in the system? | 22:20 |
| 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:25 |
| 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:31 |
| mibofra | ok | 22:55 |
| mibofra | kdub, the same | 23:01 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!