| kdub | another fun day of powerd for me... see yall tommorrow | 01:58 |
|---|---|---|
| duflu | Later kdub | 02:11 |
| RAOF | racarr: Oh, Kevin mentioned that you were fighting with nested? | 02:44 |
| === chihchun_afk is now known as chihchun | ||
| === tvoss is now known as tvoss|test | ||
| === tvoss|test is now known as tvoss | ||
| duflu | RAOF: Silly question: In the nested world, a greeter is a shell too, right? | 07:25 |
| RAOF | duflu: There will certainly be a greeter shell, yes. | 07:25 |
| duflu | Good. Just checking I understood that much | 07:25 |
| RAOF | Whether or not the greeter is built into that shell or is a separate client is neither here nor there, really. | 07:25 |
| duflu | RAOF: Interesting point. If the greeter is just a client then the efforts to support translucent nested servers won't be used (anpok!) | 07:38 |
| RAOF | No, they will. | 07:39 |
| RAOF | There will still be a nested shell that the greeter runs in. | 07:39 |
| duflu | Sounds weird. We'd have to have a good reason for that... | 07:39 |
| RAOF | The greeter needs to have a bit of session logic, as it folds in multiple processes. | 07:40 |
| RAOF | See the current greeter - the indicators need to be folded in, and they can pop up windows, etc. | 07:40 |
| duflu | So put another way... in the nested case you can choose which server a client connects to. Why wouldn't the greeter just be a client to the system compositor? | 07:41 |
| duflu | Oh, right, popups in greeters. OK | 07:41 |
| RAOF | Because then everything it spawns will be clients of the system compositor, and we would need nontrivial window management in the system compositor. | 07:41 |
| RAOF | Right, you've got it :) | 07:41 |
| duflu | You could just say don't make greeters with windows :) | 07:42 |
| duflu | I think Ubuntu is unique in that area | 07:42 |
| RAOF | I'm pretty sure we'll continue to want non-trivial greeters; the ability to enable wifi before logging in remotely requires some windowish. | 07:47 |
| duflu | Wow, framerate (thoughput) is indeed higher when nesting. What's that all about?! | 08:07 |
| duflu | Perhaps nesting allows the extra N-buffering we don't really do properly with a single server? | 08:07 |
| RAOF | Perhaps. | 08:16 |
| anpok | hmm | 08:22 |
| anpok | rfkill block / unblock seems to fix the issue | 08:23 |
| anpok | RAOF: do you experience strange behavior on the ac7260 wifi chip | 08:23 |
| RAOF | anpok: I don't have one of those; I've got Qualcomm Atheros AR9462 | 08:24 |
| duflu | That's odd. Intel wifi is usually the best. And ac7260 I think is the newest ... http://ark.intel.com/products/75439/Intel-Dual-Band-Wireless-AC-7260 | 08:25 |
| anpok | it works very well for like a day usually | 08:25 |
| anpok | but then connection attempts seem to take ages.. lots of packet loss | 08:26 |
| anpok | maybe caused by some upgrade.. I had no issue in london | 08:28 |
| RAOF | I've seen complaints that Intel wifi has been going backwards, quality-wise. | 08:28 |
| anpok | and the time before | 08:28 |
| duflu | Hmm, and now nested is slower, which sounds more sane | 08:29 |
| anpok | duflu: I hoped that RAOF branch gets merged sooner.. what do you mean by resubmit? wait untill checks-for-urfaceless is in devel? | 08:31 |
| duflu | anpok: No, you can resubmit now and RAOF's diff will be hidden if it's listed as a prereq of yours | 08:32 |
| duflu | Just fill in the Prerequisite Branch field | 08:32 |
| duflu | anpok: Thanks. That's smaller :) | 08:48 |
| anpok | yeah.. I didnt expect such a feature would exist | 08:49 |
| anpok | regarding tests.. I think I need to do some more behavior changes | 08:50 |
| anpok | so far it only allows selecting pixel formats | 08:50 |
| anpok | which is ignored by offscreen and android .. and it would fail for mesa | 08:51 |
| anpok | at least now it would fail | 08:52 |
| anpok | hm i think inside gbm.. if somebody tries to create an ARGB buffer with the scan out flag it would fail | 08:52 |
| anpok | shall I filter such an attempt.. and pick a similar pixel format without alpha - or throw? | 08:54 |
| anpok | ah ok display class in mesa also does not take that setting into account | 09:30 |
| duflu | anpok: I've noticed it's very confusing trying to tell the difference between nested and non-nested servers on screen. Could you by any chance add an option to select the glClear background colour for each? :) | 09:33 |
| duflu | ... I noticed after realizing I was moving and resizing the nested server and _not_ the client within it :P | 09:34 |
| anpok | yeah | 09:34 |
| anpok | we could also draw borders | 09:34 |
| anpok | clear is simpler | 09:34 |
| duflu | anpok: The glClear call already exists. Just change glClearColor | 09:40 |
| duflu | Although when I changed the default colour, that upset Unity8 people | 09:40 |
| anpok | oh there is clear call in mesa platform | 09:44 |
| anpok | i thought only in the example shell | 09:44 |
| anpok | would we see garbage on screen otherwise - if there was no initial clear&swap? | 09:45 |
| duflu | anpok: src/server/compositor/gl_renderer.cpp: glClear(GL_COLOR_BUFFER_BIT); | 09:52 |
| === dandrader is now known as dandrader|afk | ||
| === dandrader|afk is now known as dandrader | ||
| alan_g | CI and Autolanding are failing android-trusty-i386 with "W: GPG error: http://ppa.launchpad.net trusty Release" - I've put a general query on #ubuntu-ci-eng, but no-one I know is awake there. | 11:32 |
| === alan_g is now known as alan_g|afk | ||
| === alan_g|afk is now known as alan_g | ||
| === alan_g is now known as alan_g|lunch | ||
| === alan_g|lunch is now known as alan_g | ||
| alf_ | kgunn: alan_g: https://code.launchpad.net/~afrantzis/mir/fix-mako-ci-use-steady-clock/+merge/199469 | 14:41 |
| alan_g | alf_: looking... | 14:43 |
| alf_ | alan_g: resubmitted against mir-devel: https://code.launchpad.net/~afrantzis/mir/fix-mako-ci-use-steady-clock/+merge/199472 | 14:44 |
| alan_g | alf_: can you try a cross-build (including running tools/setup-partial-armhf-chroot.sh)? Do you see something like "/usr/arm-linux-gnueabihf/include/bits/byteswap.h:74:17: error: â__uint64_tâ does not name a type"? | 15:01 |
| alf_ | alan_g: trying | 15:05 |
| kgunn | alan_g: alf_ sorry...was in with ui guys... | 15:10 |
| * kgunn waits for cross build results | 15:10 | |
| alan_g | kgunn: ? | 15:10 |
| kgunn | alan_g: just checking back in... | 15:11 |
| kgunn | seems the 32bit stuff was a red herring | 15:11 |
| alf_ | alan_g: problem confirmed here too, I will try again after an apt-get update | 15:12 |
| === dandrader is now known as dandrader|lunch | ||
| alan_g | alf_: thanks | 15:24 |
| alf_ | alan_g: FWIW, no change after ensuring I have an up-to-date system | 15:32 |
| alan_g | alf_: agreed. Something changed upstream - not yet tracked down what. (I hope I've an old copy of the relevant files on my laptop...) | 15:33 |
| === chihchun is now known as chihchun_afk | ||
| alf_ | kgunn: @fix-mako-ci-use-steady-clock, it's blocked by cross-compilation issues so we might want to merge manually to get it in ASAP | 16:36 |
| kgunn | alf_: please do.... | 16:36 |
| alf_ | kgunn: cross-compilation issues == the ones Alan is investigating | 16:36 |
| kgunn | alf_: yes...i realized it right after i saw it fail & tried to approve again :P | 16:37 |
| alan_g | Hmm, this must be related - a load of "# if __GLIBC_HAVE_LONG_LONG" conditions have become unconditional in the gnu headers. | 16:45 |
| === dandrader|lunch is now known as dandrader | ||
| === dandrader is now known as dandrader|afk | ||
| === dandrader|afk is now known as dandrader | ||
| === chihchun_afk is now known as chihchun | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!