| robotfuel | RAOF: I'll add a apt-get install -f, this is what it's doing https://bazaar.launchpad.net/~chris.gagnon/+junk/mir-medium-test-runner-for-jenkins/view/head:/mir_install_packages.sh | 00:05 |
|---|---|---|
| RAOF | Aah. | 00:06 |
| RAOF | I think you'll be able to remove the “for DEB in ...” loop. | 00:07 |
| RAOF | That appears to be there to resolve package dependencies, yes? | 00:07 |
| robotfuel | RAOF: yes | 00:07 |
| RAOF | Yeah. Just running “apt-get -f install” after the dpkg run should do it, and will pick up newly-added dependencies to boot. | 00:08 |
| robotfuel | RAOF: testing an update now. | 00:18 |
| robotfuel | it looks like I need to use || true on the dpkg -i part, it doesn't continue to the apt-get -f install. | 00:30 |
| RAOF | Ah, yeah. That's right. | 00:35 |
| kdub | rsalveti, probably too late to get a jump on the hwc 1.2 task today, but did that 4.4 image ever become available? | 00:39 |
| RAOF | Woot. | 01:42 |
| RAOF | Rootless working, finally. | 01:42 |
| duflu_ | Woo | 01:46 |
| === duflu_ is now known as duflu | ||
| RAOF | Although for values of *working* that don't include non-origin window positioning or resizing. | 01:48 |
| RAOF | Or, really, any window management. | 01:48 |
| RAOF | Obivously. | 01:48 |
| RAOF | To the Shellinator! | 01:56 |
| === chihchun_afk is now known as chihchun | ||
| duflu | RAOF: Yeah I already knew what it can't yet do. But still, cool! | 02:04 |
| RAOF | Oh, this is why Mir has to spawn the X server... | 02:11 |
| === chihchun is now known as chihchun_afk | ||
| robotfuel | RAOF: the depends has been fixed on mako | 02:42 |
| duflu | RAOF: The non-origin input issues are filed under: https://bugs.launchpad.net/mir/+bugs?field.tag=input | 03:00 |
| RAOF | robotfuel: Thanks muchly! | 03:01 |
| === chihchun_afk is now known as chihchun | ||
| rsalveti | kdub: sorry, was having dinner while the image was being uploaded | 03:25 |
| rsalveti | got a quite slow upload channel, but got the images at http://people.canonical.com/~rsalveti/aosp/ | 03:26 |
| rsalveti | you need to flash root, system, boot into recovery, and flash http://cdimage.ubuntu.com/ubuntu-touch/daily-preinstalled/pending/trusty-preinstalled-touch-armhf.zip | 03:27 |
| DalekSec | duflu: For bug 1212753, it may be "related" to bug 1173649. Had that problem myself, but didn't change xorg.conf on the live system to test it (causes other issues as well, so did on installed system.) | 04:24 |
| ubot5 | bug 1212753 in mir (Ubuntu) "[i865] unity-system-compositor fails to start: Failed to choose ARGB EGL config" [High,Triaged] https://launchpad.net/bugs/1212753 | 04:24 |
| ubot5 | bug 1173649 in xserver-xorg-video-intel (Ubuntu) "incorrect color depth - intel graphics card" [Undecided,Opinion] https://launchpad.net/bugs/1173649 | 04:24 |
| duflu | DalekSec: When I tested an i810 (Pentium 3) system I noticed the same, Very interesting that you say being limited to 16-bit colour is a bug | 04:35 |
| duflu | It might be coming from the kernel in that case | 04:35 |
| DalekSec | While I didn't say it was a bug, it's not a good default as it causes other programs to have issues. It's not being set to 15 from the kernel, it's in the intel driver. (As stated by the dev in the report.) | 04:37 |
| DalekSec | (I have a P4 with integrated.) | 04:39 |
| duflu | DalekSec: My point was that we see common behavior between Mir and X, and their closest common factor is the kernel | 04:46 |
| duflu | (intel driver) | 04:46 |
| DalekSec | Ah, right. | 04:46 |
| duflu | Heh. ickly is being profoundly helpful as usual... https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1173649/comments/44 | 05:30 |
| ubot5 | Ubuntu bug 1173649 in xserver-xorg-video-intel (Ubuntu) "incorrect color depth - intel graphics card" [Undecided,Opinion] | 05:30 |
| duflu | *ickle | 05:31 |
| duflu | Welcome to summer :) | 06:06 |
| kgunn | duflu: so, to promote 0.1.4 dev to trusty, just need to tag the latest rev & then mp dev branch to trusty... | 07:45 |
| kgunn | noticed we slightly changed...right? now we rely on the tag | 07:46 |
| kgunn | oh...already tagged i see | 07:47 |
| duflu | kgunn: Correct. The tag is right | 07:55 |
| duflu | I thought greyback et al might be keen to get the flicker/snapshot fix | 07:57 |
| greyback | duflu: yep, we were | 07:58 |
| duflu | were? are? :) | 07:58 |
| greyback | nah, not any more :P | 07:58 |
| duflu | Oh well. 0.1.4 was plenty big enough to justify a release anyway. And we were 3.5 weeks past v0.1.3 | 07:59 |
| * greyback saw the client RPC mechanism land, was happy | 08:00 | |
| * duflu recalls willfully staying out of that discussion, so glad he ignored the MP come to think of it | 08:03 | |
| anpok | duflu: whats your opinion on having background color a part of the scene and giving it to begin vs GLRenderer having a color in the constructor | 08:06 |
| duflu | anpok: I'm not sure it fits in the mir concept of Scene. Your current design I think is cleaner | 08:06 |
| duflu | It's a good stepping stone toward "how do we do custom GL in a bespoke shell?" | 08:07 |
| anpok | when i first started the change there was no begin/end in renderer but a clear instead.. | 08:12 |
| anpok | so set_clear_color made some sense | 08:12 |
| duflu | anpok: Good point. I did intend for custom shells (like demo shell) to modify begin() in that case | 08:13 |
| duflu | Perhaps to inherit from GLRenderer and change it | 08:13 |
| anpok | so it looks a bit wierder now - and I wonder if moving to the GLRenderer constructor, and hence doing it udner the hood would be better | 08:13 |
| anpok | or that | 08:13 |
| anpok | duflu: I will change it to a struct .. but | 08:14 |
| anpok | just made a test .. the tuple emits less binary size than the struct | 08:14 |
| duflu | anpok: That's unusual, but still worth a struct | 08:14 |
| anpok | the difference is hard to notice, but the code looks of course better. | 08:15 |
| anpok | I nearly did it in the first place but felt bad about it since I had the feeling to provide more to it, to have a reason for adding a distinct structure... | 08:16 |
| duflu | typedefs can serve as documentation :) | 08:17 |
| anpok | is the opengl spec defining a default clear color? | 08:18 |
| duflu | anpok: Yes, but that includes alpha==0 (http://www.khronos.org/opengles/sdk/docs/man/) | 08:19 |
| duflu | I mean... http://www.khronos.org/opengles/sdk/docs/man/xhtml/glClearColor.xml | 08:20 |
| duflu | Whee, rotated displays minus distortion | 08:20 |
| duflu | Plus too many dependent branches | 08:21 |
| anpok | hm hardest problem is always coming up with a name | 08:22 |
| duflu | Fred | 08:22 |
| duflu | Bob | 08:22 |
| duflu | Gertrude | 08:22 |
| anpok | speeking of that, my wife came up with names for our kids | 08:27 |
| === chihchun is now known as chihchun_afk | ||
| * anpok is just listening to http://channel9.msdn.com/Events/GoingNative/2013/Inheritance-Is-The-Base-Class-of-Evil | 08:29 | |
| * duflu downloads it for later | 08:35 | |
| anpok | that person gave a longer talk on the first day, much longer | 08:36 |
| anpok | and that one contains the motivation for that one.. | 08:36 |
| anpok | .. next to other nice examples: http://channel9.msdn.com/Events/GoingNative/2013/Cpp-Seasoning | 08:37 |
| === chihchun_afk is now known as chihchun | ||
| kgunn | duflu: i feel stupid (no mgr jokes please :)...but shouldn't there be a way to propose this | 09:02 |
| kgunn | https://code.launchpad.net/~mir-team/mir/version-0.1.4/+merge/201134 | 09:02 |
| kgunn | via launchpad button to trusty | 09:02 |
| duflu | kgunn: https://code.launchpad.net/~mir-team/mir/version-0.1.4/+register-merge | 09:03 |
| duflu | kgunn: Not sure if it will work though. Usually we merge dev into a child of lp:mir and then propose that | 09:03 |
| kgunn | duflu: thanks...dammit...just one level down | 09:03 |
| kgunn | duflu: ah... | 09:03 |
| kgunn | ok will do | 09:03 |
| duflu | Well merge dev (-rv0.1.4) | 09:04 |
| kgunn | duflu: exactly... | 09:04 |
| kgunn | has to the ver you tagged | 09:04 |
| alan_g | \o/ - talk accepted! http://accu.org/index.php/conferences/accu_conference_2014/accu2014_sessions#c_best_practice_-_designing_header_files | 09:35 |
| anpok | congratulations | 09:38 |
| kgunn | duflu: fyi...https://code.launchpad.net/~mir-team/mir/promote-ver-0.1.4/+merge/201560 | 09:40 |
| duflu | kgunn: OK, but instead of reviewing I'm running off to dinner :) | 09:49 |
| kgunn | duflu: enjoy....is happy birthday in order ? | 09:50 |
| duflu | kgunn: Thanks but I'd rather avoid the thought | 09:50 |
| kgunn | heh | 09:51 |
| alf_ | alan_g: Congratulations! Is this talk related to an article of a similar name you have written (I think it was in overload?)? | 10:21 |
| alan_g | alf_: yes, that is the core | 10:22 |
| anpok | alan_g: hey, saw the TODO you had in your 2013 slides yesterday in code - when doing the other review - and thought about it.. | 10:29 |
| anpok | with the compile time trie.. | 10:30 |
| alan_g | anpok: I've been resisting that temptation a long time now. It isn't a worthwhile optimisation. | 10:30 |
| anpok | yeah it is more of an intersting riddle to solve with new c++ features than anything you notice as an improvement afterwards | 10:33 |
| anpok | apart from one TODO less. | 10:33 |
| alan_g | If you want something worthwhile, figure out why duflu added code to stop & start the compositor to unity-mir/DBusScreen::setScreenPowerMode() and do something less brutal. (c.f. https://code.launchpad.net/~kdub/mir/compositor-double-start-stop/+merge/201242) | 10:33 |
| didrocks | kgunn: hey! | 10:39 |
| didrocks | kgunn: we are about to start our "self service" release piloting by end of week, I wonder if the new Mir release will be a nice opportunity for that | 10:39 |
| anpok | alan_g: where did you see the change in unity-mir? | 10:45 |
| sil2100 | That could be a good test of the process, as there are ABI breaks to handle | 10:45 |
| alan_g | anpok: bzr blame src/unity-mir/dbusscreen.cpp | 10:46 |
| anpok | ah not a new change | 10:46 |
| anpok | thought you were referring to new branch for unity-mir | 10:47 |
| alan_g | anpok: sorry no, a bit of lp archaeology called for | 10:48 |
| didrocks | sil2100: +1 | 10:48 |
| didrocks | sil2100: and there is a client ABI break, so needs new xorg | 10:48 |
| mlankhorst | can it be hooked up to xorg 1.15? :P | 10:48 |
| didrocks | kgunn: I guess you forgot the xmir changes ^ | 10:49 |
| didrocks | mlankhorst: it can if we go with the silo approach | 10:49 |
| didrocks | and if timelines matches | 10:49 |
| mlankhorst | well expecting it in 2 weeks | 10:49 |
| didrocks | ah, I think they will want it first though | 10:49 |
| didrocks | mlankhorst: I guess it's just a rebuild anyway, but let's see with them | 10:50 |
| mlankhorst | oh in that case just rebuild | 10:54 |
| mlankhorst | RAOF: ping | 11:04 |
| anpok | alan_g: hm yes duflu considered letting the display trigger the compositor to stop and start again | 11:04 |
| mlankhorst | RAOF: are you going to release xserver-xorg-video-ati ubuntu11 at some point? :P | 11:05 |
| anpok | but according to the bug ticket comments there was no decision and the fix was to add compositor stop / start on power mode changes | 11:05 |
| anpok | https://bugs.launchpad.net/ubuntu/+source/unity-mir/+bug/1255045/comments/18 | 11:06 |
| ubot5 | Ubuntu bug 1255045 in unity-mir (Ubuntu) "screen does not turn on on maguro when pressing the power button" [High,Fix released] | 11:06 |
| alan_g | anpok: I suspect our current problem is manifested if the power mode is set but isn't changing. | 11:08 |
| anpok | yes | 11:08 |
| anpok | powerd probably sending multiple ons | 11:08 |
| anpok | or whatever also chats about power modes | 11:08 |
| anpok | but doing more state tracking on unity-mir does not feel right | 11:08 |
| anpok | hm but for display configurations it already tracks wheter it would change the configuration | 11:10 |
| alan_g | unity-mir is stateful already, so that doesn't bother me | 11:14 |
| alan_g | but It seems extreme to be stopping the compositor | 11:14 |
| alan_g | Especially as, in principle, there could be outputs powered independently | 11:15 |
| anpok | is there a compositor instance per output? | 11:17 |
| alan_g | alf_: can you think of a more elegant approach to bug 1255045 than stop/start of the compositor? ^^ | 11:17 |
| ubot5 | bug 1255045 in unity-mir (Ubuntu) "screen does not turn on on maguro when pressing the power button" [High,Fix released] https://launchpad.net/bugs/1255045 | 11:17 |
| anpok | or is there one compositor for all? | 11:17 |
| anpok | ok | 11:18 |
| alan_g | one compositor to rule all the compositing threads | 11:18 |
| alan_g | (Which are currently serialized because of a broken model) | 11:19 |
| ogra_ | note that there is also https://code.launchpad.net/~mterry/unity-system-compositor/dbus-screen-fix/+merge/201211 | 11:19 |
| ogra_ | (for nested mode, i just tested it on maguro) | 11:20 |
| alan_g | ogra_: thanks for the warning | 11:21 |
| alf_ | alan_g: At the moment configure() recreates the DisplayBuffers, so the compositor needs to be stopped and restarted to read the new ones | 11:22 |
| ogra_ | i actually think the hack from the session mir should be dropped for this, i doubt we will use it without u-s-c in the future | 11:22 |
| ogra_ | (feels like duplication to leave it in place) | 11:22 |
| alf_ | alan_g: so when changing just the power state we could retain the current displaybuffers => not start stop needed | 11:23 |
| anpok | alf_: do we need to inject some sort of screen-changed-please-redraw? | 11:24 |
| alan_g | alf_: so displayConfig->configure_output(..) => displayConfig->power_mode(newPowerMode) | 11:26 |
| alan_g | anpok: we shouldn't need it if we don't discard the buffer | 11:26 |
| anpok | which we do now because the buffers are recreated because the config change.. ok | 11:27 |
| anpok | alan_g: or more logic in configure_output to detect changes that just boil down to power changes? | 11:28 |
| alf_ | alan_g: anpok: right, the work happens in Display::configure(), the DisplayConfiguration is just a container of information | 11:29 |
| alan_g | Ah yes. | 11:30 |
| alan_g | So display->power_mode(newPowerMode) | 11:30 |
| kgunn | didrocks: thanks for the catch... | 11:31 |
| anpok | alan_g: alf_: but on android it does not seem to do more right now - it actually just checks for power mode changes | 11:32 |
| alf_ | anpok: on Mesa it doesn't though... | 11:33 |
| alf_ | alan_g: anpok: Alternatively we could continue with start/stop, but hiding it from unity-mir. For example unity-mir could use the DisplayChanger class (or similar) | 11:33 |
| alan_g | alf_: +1 for hiding it from unity-mir and USC | 11:34 |
| anpok | alan_g: you refered to as broken because it create a thread for each display that then just sits and waits of a trigger, instead of using the pool we already have from asio.. | 11:36 |
| anpok | alf_: you display conf change AND DisplayChanger? or something new? | 11:37 |
| anpok | +mean | 11:37 |
| alan_g | anpok: actually I was referring to the "lock the world, paint an output, unlock the world" bottleneck | 11:37 |
| alf_ | alan_g: anpok: so unity-mir could use an interface like PowerManager (yes, we can probably find a better name) which is implemented by injecting code to {stop() configure() start()} into our main loop | 11:38 |
| anpok | alf_: why arent we doing that also for display configuration changes? | 11:42 |
| === anpok is now known as anpok|lunch | ||
| anpok|lunch | i mean the existing DisplayConfiguration::configure_output somethig | 11:42 |
| alf_ | kgunn: On Nexus 10, glCopyTexSubImage2D is for some reason too slow when copying to a texture backed by an EGLImage. Interestingly it's fast when the texture is not backed by an EGLImage. I am looking into/measuring alternatives, like rendering to a texture (backed by the buffer we want to send to the client) first and rendering that to the screen, when we need to take a screenshot | 11:43 |
| alf_ | anpok|lunch: I don't understand what you mean | 11:44 |
| === chihchun is now known as chihchun_afk | ||
| alf_ | kgunn: ideally we would want to use multiple render targets (drawing to multiple buffers at once), but that's not supported in ES 2.0 | 11:52 |
| kgunn | alf_: right | 11:53 |
| kgunn | alf_: wonder if just a dma memcpy would be faster than farting around with glteximage calls | 11:54 |
| alf_ | kgunn: Which API allows us to do that with GPU buffer data? | 11:57 |
| alf_ | kgunn: does Android have something for this? | 11:57 |
| kgunn | alf_: if its system memory it shouldn't matter that it also happens to be mapped into for gpu use | 11:58 |
| kgunn | should it ? | 11:59 |
| alf_ | kgunn: no, but that's true only for unified memory systems | 12:00 |
| kgunn | alf_: right...i am making assumptions | 12:00 |
| kgunn | i thot everything after old n7 was unified | 12:01 |
| alf_ | kgunn: you are forgetting the desktop case ;) | 12:01 |
| alf_ | kgunn: however it's not a bad assumption to make and that's the other alternative I was considering: doing it differently on android vs mesa (i.e. not depending necessarily on GL) | 12:02 |
| kgunn | alf_:yeah...on desktop cpu is fast enough | 12:03 |
| kgunn | alf_: and i think in general glteximage khronos spec iirc has some | 12:03 |
| alf_ | kgunn: (but I need to wait for kdub to discuss what android offers us in terms of buffer copying) | 12:04 |
| kgunn | aspects to it, where it has to do some weird backstore preservation stuff | 12:04 |
| kgunn | that you're simply not interested in | 12:04 |
| kgunn | but...its part of the spec...and just slows it down | 12:05 |
| alf_ | kgunn: @preservation, that gave me an idea... | 12:12 |
| === alan_g is now known as alan_g|afk | ||
| === anpok|lunch is now known as anpok | ||
| === alan_g|afk is now known as alan_g | ||
| === dandrader is now known as dandrader|lunch | ||
| === dandrader|lunch is now known as dandrader | ||
| === alan_g is now known as alan_g|tea | ||
| === alan_g|tea is now known as alan_g | ||
| === dandrader is now known as dandrader|afk | ||
| === dandrader|afk is now known as dandrader | ||
| === tvoss is now known as tvoss|test | ||
| === tvoss is now known as tvoss|test | ||
| === tvoss|test is now known as tvoss | ||
| === alan_g is now known as alan_g|EOD | ||
| rsalveti | kdub: were you able to flash 4.4? | 20:37 |
| kdub | rsalveti, i flashed it, didnt get the wifi to work though. | 20:42 |
| kdub | is that expected? | 20:42 |
| rsalveti | kdub: did you also flash the radio? | 20:50 |
| kdub | i flashed CM11, and then flashed system, recovery, ubuntu touch, boot | 20:51 |
| kdub | i got a could-not-access on the .img's in the link you sent | 20:51 |
| rsalveti | kdub: weird, maybe an image was being uploaded when you tried | 20:54 |
| rsalveti | kdub: I don't think CM11 would flash the radio | 20:54 |
| rsalveti | kdub: flash the bootloader & radio as I said on my email, and try again | 20:54 |
| kdub | okay | 20:55 |
| rsalveti | let me check the permission again | 20:55 |
| kdub | ah, its working now | 20:55 |
| rsalveti | kdub: indeed, you should be able to access them now | 20:55 |
| kdub | okay, ill let you know how it goes shortly | 20:56 |
| rsalveti | kdub: great | 21:03 |
| kdub | rsalveti, still having radio/wifi problems, will reflash | 21:24 |
| rsalveti | kdub: weird, ok | 21:27 |
| kdub | rsalveti, i got (from clockworkmod) 'root access missing', with a yes/no to obtain root, but other than that, nothing out of the ordinary | 21:42 |
| kdub | rsalveti, worked this time flashing though | 21:43 |
| kdub | i fastboot formatted a few partitions | 21:43 |
| rsalveti | kdub: yeah, you can ignore that, need to get that fixed | 21:43 |
| rsalveti | got it | 21:43 |
| rsalveti | yeah, I flashed the 4.4.2 factory image before flashing our image | 21:43 |
| rsalveti | that also erases everything | 21:44 |
| kdub | rsalveti, at any rate, have the image working, so starting to get mir to run, thanks | 21:45 |
| rsalveti | kdub: great | 21:46 |
| RAOF | mlankhorst: That would be a reasonable plan, wouldn't it :) | 22:22 |
| RAOF | mlankhorst: Got a bug reference for it? | 22:23 |
| mlankhorst | RAOF: no, was just curious | 22:27 |
| RAOF | But you're right, I should release it now :) | 22:27 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!