| === charles_ is now known as charles | ||
| === _salem is now known as salem_ | ||
| === salem_ is now known as _salem | ||
| RobbyF2 | seems those links in the topic are really outdated. | 03:10 |
|---|---|---|
| RobbyF2 | anyone happen to be maintining galaxy nexus build? | 03:13 |
| RobbyF2 | been looking around and hav't seen so i thought i would check in here as a last resort | 03:13 |
| nhaines | The links in the topic are the information we have. | 03:14 |
| nhaines | Most community ports are not active--of course, if independant developers don't maintain their port listing... | 03:14 |
| RobbyF2 | thanks nhaines | 03:16 |
| RobbyF2 | I might just have to run an emulator | 03:16 |
| nhaines | On the bright side, with luck once the phone is "out" in February, that might trigger more interest in ports. But Canonical hasn't come through with the promised updated porting guide either. | 03:16 |
| nhaines | (They're really busy getting things working for the bq phone, so hopefully post release they'll be able to finish that up--it's in progress, but just going very slowly.) | 03:17 |
| RobbyF2 | yeah. | 03:17 |
| nhaines | An emulator works pretty well and runing apps on your Ubuntu system is actually very close to device use. | 03:17 |
| RobbyF2 | tempted to buy one of those devices but I assume they will be $500+ usd | 03:17 |
| nhaines | One of which devices? | 03:18 |
| RobbyF2 | mx4 | 03:18 |
| RobbyF2 | meizu or what ever it's called | 03:18 |
| nhaines | No idae about that. the bq Aquaris is maybe going to be more like €200. | 03:19 |
| RobbyF2 | i'll have to keep my eye on that | 03:19 |
| nhaines | The Meizu MX4 is $293. | 03:19 |
| RobbyF2 | bbl | 03:20 |
| nhaines | Up to $390 for the 64GB model. | 03:20 |
| nhaines | Take care! | 03:20 |
| RobbyF2 | laptop gonna die | 03:20 |
| RobbyF2 | thanks for your help | 03:20 |
| RobbyF2 | appreciate it! | 03:20 |
| bubbasaures | nhaines, Are the OEM's going to have the plugin ubuntu desktop? | 03:28 |
| bubbasaures | plugin as an axtion bad syntax sorry | 03:29 |
| nhaines | bubbasaures: maybe once it exists. That's about two years away. | 03:31 |
| nhaines | Year and a half, maybe. 16.10. | 03:31 |
| bubbasaures | nhaines, Cool, thanks, it is nice to see it getting this far. | 03:32 |
| bzoltan_ | aquarius: The SDK is using the key from ~/.config/ubuntu-sdk | 04:11 |
| lotuspsychje | http://www.omgubuntu.co.uk/2015/01/aggregator-scopes-ubuntu-phone | 05:46 |
| lotuspsychje | new article | 05:46 |
| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| dholbach | good morning | 08:11 |
| === milli` is now known as milli | ||
| sturmflut-work | good morning | 09:12 |
| === sil2100_ is now known as sil2100 | ||
| JamesTait | Good morning all; happy Hugging Day! :-D | 09:30 |
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| === cking_ is now known as cking | ||
| === _salem is now known as salem_ | ||
| === tekojo_ is now known as tekojo | ||
| === alan_g is now known as alan_g|lunch | ||
| rickspencer3 | aquarius, what a nice way to wake up today :) | 12:14 |
| rickspencer3 | your videos are super slick | 12:15 |
| aquarius | rickspencer3, cheers | 12:16 |
| === pindonga` is now known as pindonga | ||
| davmor2 | aquarius: yes seconded, they are pretty concise, easy to follow and audio on them are great, obviously the video has your ugly mug on it so is marred by that ;) But on a serious note, Well done that man keep up the good work :) | 12:25 |
| melvster | meizu with ubuntu touch expected to on sale in february in europe, is that right? | 12:35 |
| melvster | or am i thinking of the bq? | 12:36 |
| === dandrader is now known as dandrader|afk | ||
| jgdx | melvster, seems bq comes first, ref http://www.omgubuntu.co.uk/2014/12/bq-ubuntu-phone-launches-in-europe-this-february | 12:40 |
| melvster | jgdx: woot ... ill be ordering one when it comes out ... my nexus 4 seems a bit dated now | 12:41 |
| melvster | 1GB RAM | 12:42 |
| melvster | hmmm that's tight | 12:42 |
| melvster | wow price is low | 12:43 |
| melvster | expensive NOT to buy one! | 12:43 |
| === alan_g|lunch is now known as alan_g | ||
| === dandrader|afk is now known as dandrader | ||
| * asac updtes to latest | 13:16 | |
| === MacSlow is now known as MacSlow|lunch | ||
| === marcusto_ is now known as marcustomlinson | ||
| mzanetti | sturmflut-work: hey, could you do me a favor and do a small writeup on how you got ubuntu installed on that tablet? in particular about the UEFI stuff etc | 13:50 |
| sanjeev | hi | 13:53 |
| mterry | bfiller, you were asking about bug 1413065. I agree that unity8 is probably involved if it's a focus problem. I am trying to track down what focus changes might have been made recently. Is this a regression or is it something that might have been broken for a while? | 14:20 |
| ubot5 | bug 1413065 in unity8 (Ubuntu) "[Call]The call interface sometimes disappears when making emergency call" [Critical,Confirmed] https://launchpad.net/bugs/1413065 | 14:20 |
| bfiller | mterry: think it's been broken for a while and it's a timing thing | 14:21 |
| bfiller | mterry: might have to do with the live call indicator? | 14:21 |
| mterry | bfiller, yeah you mention it doesn't always happen | 14:21 |
| bfiller | mterry: yeah | 14:22 |
| bfiller | mterry: or the fact the dialer is running fullscreen mode? | 14:22 |
| bfiller | or a combo | 14:22 |
| mterry | bfiller, I wouldn't *think* either of those components would be able to trigger an unfocus but maybe | 14:23 |
| === MacSlow|lunch is now known as MacSlow | ||
| bfiller | mterry: I remeber there was a bug where the live call indicator was quickly displayed and removed when placing a call, but that was fixed a while ago. wondering if that might be related somehow | 14:31 |
| bfiller | mterry: I'll try and find the bug as the MR might shed some hints | 14:32 |
| === zyga is now known as zyga-afk | ||
| mterry | bfiller, interesting | 14:34 |
| mterry | bfiller, looking at code, I could believe we request focus for the dialer-app when a call starts | 14:35 |
| mterry | greyback_, ^ would it make sense that ApplicationManager.requestFocusApplication() would unfocus/re-focus if an app already had focus? | 14:36 |
| greyback_ | mterry: requestFocusApplication just emits a focusRequested(appId) signal, which unity8 will act upon. | 14:39 |
| mterry | ah | 14:39 |
| greyback_ | mterry: take care, surfaces get input focus, which is what Qt.application.active reflects | 14:40 |
| mterry | greyback_, ok so that just does ApplicationManager.focusApplication it seems in PhoneStage | 14:40 |
| greyback_ | there's an annoying concept of application focus in qtmir, which is due to mir. That concept is used to manage app lifecycle, so is not the same | 14:40 |
| greyback_ | mterry: I recommend you monitor MirSurfaceItem::focus, and only explore AppMan::focus* as last resort | 14:41 |
| mterry | greyback_, OK, I'm just tracing code while I wait for my phone to finish flashing and such | 14:42 |
| greyback_ | mterry: sure. Feel free to ask anything | 14:42 |
| mterry | greyback_, does unity8 direct things from a surfaceItem perspective? I thought u8 only cared about apps? | 14:42 |
| === chihchun is now known as chihchun_afk | ||
| greyback_ | mterry: yes it does care about surfaces. It composites them, and looks after sending input events to those surfaces | 14:44 |
| greyback_ | mterry: Don't forget QML has a concept of (keyboard) focus. Only one QML item can get keyboard events - the one which has activeFocus=true. In unity8, an application surface is just another QML item (MirSurfaceItem) | 14:45 |
| greyback_ | if an app's surface has activeFocus=true, then that app have Qt.application.active==true too | 14:46 |
| greyback_ | the focus state of the surface in unity8, is passed to the application as "your surface is focused/not focused" | 14:46 |
| mterry | greyback_, where do we do that in u8? In the stage all I see is app stuff | 14:48 |
| greyback_ | mterry: see SurfaceContainer | 14:49 |
| mterry | greyback_, ok thanks, phone is flashed, I'll spend some time in a debugger and see if I can follow thread | 14:50 |
| sturmflut-work | mzanetti: I was already writing on it, but couldn't find the time to finish it. Basically I have to do a full re-install and confirm that all steps actually work, and there have been some changes in Vivid which should make things easier and which I have to test. | 15:02 |
| mzanetti | mhm. well, whenever you have time for it | 15:02 |
| mterry | bfiller, OK I see the unity8 call that starts the problem, have to figure out where in the chain the actual flaw lies, but it seems to involve trying to focus an already focused app | 15:10 |
| bfiller | mterry: nice | 15:11 |
| mardy | jdstrand: hi! My part of bug 1219644 has landed in Vivid | 15:15 |
| ubot5 | bug 1219644 in Online Accounts setup for Ubuntu Touch "Account plugins should be made confinable by apparmor" [Medium,In progress] https://launchpad.net/bugs/1219644 | 15:15 |
| mardy | jdstrand: so, when you get some time, you can start working on the apparmor side | 15:16 |
| mterry | greyback_, so I put a breakpoint at MirSurfaceItem::updateMirSurfaceFocus(), but it doesn't seem to be hit during this bug | 15:24 |
| mterry | greyback_, if I comment out the top-level requestApplicationFocus in u8 that tries to focus the already-focused dialer-app, the bug goes away | 15:24 |
| greyback_ | mterry: qtmir::MirSurfaceItem::updateMirSurfaceFocus | 15:24 |
| mterry | So somewhere in the focus-an-already-focused app, we do something wrong | 15:25 |
| greyback_ | mterry: there's a fixme in mirsurfaceitem.cpp line 311 which might interest you | 15:26 |
| mterry | greyback_, that's unfocusing on startup? This bug doesn't happen on startup though | 15:27 |
| greyback_ | mterry: start of the application. Ok, was just a thought | 15:28 |
| mterry | greyback_, well updateMirSurfaceFocus only happens on activeFocusChanged. What would you expect to happen / what is correct behavior if shell tries to re-focus an app? | 15:28 |
| pitti | uh, oh, things you don't want to see on a phone emulator (current devel-proposed): http://paste.ubuntu.com/9806535/ | 15:29 |
| pitti | (and landing in busybox) | 15:29 |
| greyback_ | mterry: frankly, "refocus" should never happen | 15:30 |
| greyback_ | but it should be a noop if it does | 15:30 |
| jgdx | Cimi, that u-s-s ci failure is not introduced by your branch. I think it's ci infra issues, but I haven't investigated yet. | 15:31 |
| mterry | greyback_, yeah I figure as much. But where in the stack do you prefer we check that and enforce a no-op? | 15:31 |
| greyback_ | mterry: why do you think it is a refocus? | 15:31 |
| mterry | greyback_, I'm also curious why it's not a no-op | 15:31 |
| greyback_ | could it instead be something stealing focus from the mir surface, and then the mir surface stealing it back again? | 15:32 |
| mterry | greyback_, because if I comment out a line in Shell.qml that does a requestApplicationFocus("dialer-app") that gets triggered when the user presses the call button in the emergency dialer, the bug goes away | 15:32 |
| mterry | greyback_, maybe u8's handling of that request is breaking it, and it's not a mir thing. Haven't determined that yet | 15:32 |
| greyback_ | mterry: qtmir & mir just pass the surface focus message from unity8 to the application | 15:33 |
| mterry | greyback_, but maybe they shouldn't if it's already focused? | 15:33 |
| ogra_ | pitti, check your USB cable :P | 15:34 |
| mterry | greyback_, is it possible Qt is taking that message on the app side and acting like an unfocus/focus then? | 15:34 |
| ogra_ | pitti, surely one of these virtual wires is loose | 15:34 |
| greyback_ | mterry: highly unlikely | 15:35 |
| pitti | ogra_: I tried another one, and also wiggled it a lot already! | 15:35 |
| ogra_ | :D | 15:35 |
| mterry | greyback_, well I can fix this bug by just guarding the Shell.qml call. But that seems like we're leaving some focus issue in place to hit someone else later. Any suggestions for another place to try a breakpoint? | 15:37 |
| pitti | sergiusens, ogra_: ok, seems to be a problem with finding the root partition; that still worked last week, are you aware of any changes there? | 15:40 |
| greyback_ | mterry: sorry no. Honestly I don't think you've got to the core of the matter. | 15:40 |
| pitti | sergiusens, ogra_: I filed it as bug 1413271, this has a log | 15:40 |
| ubot5 | bug 1413271 in android-tools (Ubuntu) "[vivid] emulator fails to find a root partition, landing in busybox" [Undecided,New] https://launchpad.net/bugs/1413271 | 15:40 |
| mterry | greyback_, I agree. That's why I'm still investigating rather than just guarding the Shell.qml call | 15:41 |
| mterry | greyback_, or are you saying that I'm going up the entirely wrong tree? | 15:41 |
| sergiusens | pitti: so this is different than xnox's problem about not being able to create | 15:42 |
| pitti | yes | 15:42 |
| pitti | I was creating an emulator just last Friday, which worked fine | 15:42 |
| greyback_ | mterry: no, you're in the rough area, QML's activeFocus is bouncing around for some reason | 15:42 |
| mterry | greyback_, but I'm reporting that it isn't -- updateMirSurfaceFocus, triggered off activeFocusChanged, isn't actually happening during the bug | 15:43 |
| mterry | Unless I screwed up that test. Can do it again | 15:43 |
| greyback_ | mterry: that method sends the IPC call to the dialer app to say is i or is not focused. There is no other way for that message to be sent | 15:44 |
| mterry | greyback_, OK, so if that method isn't hit, there's no way the app's Qt.application.active would change? | 15:44 |
| greyback_ | mterry: correct | 15:45 |
| * mterry will run that test again, maybe I accidentally queued up a 'c' in gdb | 15:45 | |
| greyback_ | mterry: qtmir.surfaces: MirSurfaceItem::updateMirSurfaceFocus false - should see those in the unity8.log | 15:45 |
| mterry | greyback_, oh that's enabled by default? swell | 15:46 |
| === dandrader is now known as dandrader|lunch | ||
| mterry | greyback_, this is what happens when Shell.qml requests focus for the already-focused dialer-app: | 15:48 |
| mterry | http://paste.ubuntu.com/9806703/ | 15:48 |
| mterry | which doesn't actually hit updateMirSurfaceFocus. But does seem to be unfocusing it | 15:49 |
| greyback_ | mterry: Application::setFocused - appId= "dialer-app" focused= false <- that looks wrong, that is something telling qtmir that the dialer-app is not being used. You see it then going into the suspended state. Then reume is called on it | 15:51 |
| mterry | yeah | 15:51 |
| greyback_ | so that's not surface focus, that's application "focus" | 15:51 |
| greyback_ | sorry I know the terminology is a nightmare, I hope to clean it up soon | 15:51 |
| mterry | greyback_, line 412 of application_manager.cpp | 15:51 |
| mterry | greyback_, should probably check if it's the same app before unfocusing | 15:52 |
| greyback_ | mterry: well is odd for unity8 to ask for an already focused app to be focused. But yes | 15:53 |
| greyback_ | mterry: I'd prefer that check being done in unity8, not for qtmir. | 15:53 |
| mterry | greyback_, sure, like I said, I could guard in Shell.qml against this as well, but seems like it would just be lying in wait for someone else | 15:53 |
| mardy | mvo: hi! Can I expect the hook program to be run in an environment where the DBus session is set, or should I assume that there's no DBus? | 15:54 |
| greyback_ | mterry: that qtmir code will go away | 15:54 |
| greyback_ | mterry: hence my preference | 15:54 |
| mterry | greyback_, I'm happy to also guard Shell.qml. If this qtmir code is short-lived fine. But if it weren't, I would really expect that qtmir wouldn't unfocus in this situation | 15:54 |
| greyback_ | mterry: sure. Only said it because it is code that has to die | 15:55 |
| mterry | ok | 15:55 |
| mterry | greyback_, thanks for your help! I'll go off and do this in unity8 | 15:55 |
| greyback_ | np | 15:55 |
| mterry | bfiller, ok MP filed. Works for me, but more testers is good too: https://code.launchpad.net/~mterry/unity8/dont-refocus-dialer/+merge/247165 | 16:21 |
| bfiller | mterry: awesome, will try, boiko and salem_ please test as well ^^^ | 16:21 |
| mterry | It's a simple one-line qml change, so you don't need to wait for the debs to be built if you're feeling adventurous | 16:22 |
| boiko | bfiller: mterry: nice! I will test it soon | 16:22 |
| salem_ | mterry, cool, thanks | 16:22 |
| mvo | mardy: I assume you mean access to DBUS_SESSION_BUS_ADDRESS via the env? I need to look at the details but I think you don't have this. https://code.launchpad.net/~mvo/click/lp1232130-kill-on-remove-2/+merge/237601 has some code to get it but its not merged and there were some concerns over it | 16:24 |
| mardy | mvo: yes, that one; I'm afraid we'll need it, sooner or later | 16:24 |
| mardy | mvo: there's the case when you remove an account plugin: we also remove the corresponding account(s), and we should notify any running app using this account that it's gone | 16:25 |
| mvo | mardy: right, we could use the approach from the MP, but that assuem the address is availalbe on /run | 16:26 |
| mardy | mvo: if it's not there, it means that there really isn't any session running, right? | 16:26 |
| === zyga-afk is now known as zyga | ||
| mvo | mardy: yeah, you can use it I think someone (ogra?) mentioned that it having the file on /run/user/$uid/dbus-address was not meant as a real interface that people should rely on, worth double checking I guess | 16:30 |
| ogra_ | yeah, please get the DBUS_ADDRESS from the environment, that file isnt meant to stay | 16:31 |
| aquarius_ | ChickenCutlass, ping | 16:59 |
| aquarius_ | ChickenCutlass, about mp4 encoding in hardware on phones and whether it's doable :) | 16:59 |
| ChickenCutlass | aquarius_: ah encode. | 17:00 |
| ChickenCutlass | aquarius_: so the camera app does this on record | 17:00 |
| aquarius_ | ChickenCutlass, yeah. I had this idea: I would like to have, basically, apple airplay on the phone. So something which pulls frames from /var/run/mir_socket and gives them to Some Chip In The Phone which gives back an mp4, and then I stream that mp4 over the network. Which, if it's possible, should involve almost no actual *CPU* time, so the phone won't bog down. | 17:01 |
| aquarius_ | but I have no idea whether the mp4 chips in phones let you encode arbitrary incoming stuff :) | 17:01 |
| ChickenCutlass | aquarius_: it might, maybe jhodapp would know that | 17:01 |
| aquarius_ | and I thought: Frey knows this stuff. ;) | 17:01 |
| aquarius_ | aha, jhodapp, ping then :) | 17:02 |
| ChickenCutlass | lol | 17:02 |
| ChickenCutlass | aquarius_: so jhodapp is the one who hocks all the bits together for multimedia | 17:02 |
| bfiller | mterry: tested your MR - works great. fixes issues and no regressions that I can see during testing. | 17:04 |
| aquarius_ | nvidia chips have the vdpau stuff which will encode arbitrary incoming things and give you an mp4 stream, but I don't know if the stuff you get in phones does. I shall ask jim :) | 17:04 |
| bfiller | mterry: thank you for the quick turnaround! | 17:04 |
| salem_ | bfiller, mterry awesome. | 17:04 |
| MoPac | Hello - I'm a bit confused at the moment about (a) natively running touch apps on desktop vs (b) docking a phone to run a full desktop enviro vs (c) docking the phone to a *running* desktop session and controlling the phone from the desktop | 17:05 |
| ChickenCutlass | aquarius_: I think you can feed a surface to the record interface and basically turn that into an mp4 | 17:05 |
| mterry | bfiller, sweet, maybe leave a comment in the MP so the unity8 folks know it's already gotten some testing and they can focus on code review side of things | 17:05 |
| MoPac | I've seen (a) and know that (b) has always been part of the project. But is (c) an initial capability? | 17:05 |
| bfiller | mterry: yup, did that | 17:06 |
| mterry | bfiller, awesome thanks! | 17:06 |
| aquarius_ | ChickenCutlass, that'd be ideal, I think; that's what I was imagining, a little thing which connects together a mir surface, the record interface, and a network port to get a streaming mp4 of the phone screen with little or no cpu impact. | 17:07 |
| ChickenCutlass | aquarius_: right take a look at qtubuntu camera | 17:07 |
| jhodapp | aquarius_, pong | 17:07 |
| aquarius_ | jhodapp, see the above conversation to get up to speed -- and then I have some questions for you :) | 17:07 |
| jhodapp | aquarius_, ok, give me 5 mins | 17:08 |
| aquarius_ | cheers :) | 17:10 |
| jhodapp | aquarius_, ok, so in theory what you want to do should be possible | 17:17 |
| aquarius_ | jhodapp, yay! although "in theory" worries me ;) | 17:18 |
| jhodapp | aquarius_, we don't have anything tied in platform-wise other than camera recording though, and that's highly specific. We are missing a gstreamer plugin that would abstract this in our pipeline that could talk to media-hub | 17:18 |
| jhodapp | aquarius_, so driver-level on down, this is possible...we are missing the integration bits that would make this easy for you to do | 17:19 |
| aquarius_ | jhodapp, this would be equally specific, though -- get the screen from mir. I'm not bothered about some generic way to expose this encoding ability to everybody :) | 17:20 |
| === dandrader|lunch is now known as dandrader | ||
| jhodapp | aquarius_, of course :) | 17:21 |
| jhodapp | aquarius_, but it would be nice to have it all generic | 17:21 |
| nhaines | MoPac: when Ubuntu desktop ships with Unity 8, that's when you can expect (c). It is not an initial capability. Maybe 16.10. | 17:22 |
| aquarius_ | jhodapp, oh, totally, but I suspect everyone capable of doing this is already really busy :) | 17:24 |
| jhodapp | aquarius_, I'll add a todo list item for myself to look into this a little more for you and point you to some Android-level code | 17:24 |
| jhodapp | aquarius_, I'll try and get back to you tomorrow some time | 17:24 |
| aquarius_ | jhodapp, what would it need? the camera uses gstreamer to send incoming video to the mp4 encoder? or does it all happen in the kernel or something? | 17:25 |
| jhodapp | aquarius_, there's an Android-level driver that reads the bits from the device...each device has its own specific driver...then there's a C++ class that abstracts it into a standard camera interface, again at the Android level. Right now for the camera recording, the video frames never leave the Android level...they get read in, sent to the encoder and output frames are sent to the MPEG4Writer class | 17:27 |
| jhodapp | aquarius_, what I did was to re-work the control interface for recording to work with hybris and our camera-app | 17:29 |
| aquarius_ | jhodapp, ah, so it does all need to get hooked up at a low level... got it. | 17:31 |
| jhodapp | aquarius_, so really the only thing you need now is to get your hands on the output of the encoder | 17:31 |
| jhodapp | aquarius_, and ideally this would be done by gstreamer | 17:31 |
| jhodapp | aquarius_, because then you could pipe it to one of the network sinks | 17:32 |
| jhodapp | aquarius_, that might be possible to send through a fifo up to a new gstreamer plugin | 17:33 |
| aquarius_ | jhodapp, that'd be totally excellent | 17:37 |
| aquarius_ | jhodapp, I create a gst pipeline which is, basically, mir-as-mp4 ! networksink host=whatever port=whatever, and that's *it* | 17:37 |
| jhodapp | aquarius_, that would be the idea yes, but most of the work is identifying the right place to attach a fifo on the android side and then creating a new Gst "encoder" plugin that receives the data and sends the data out its sink port to the right network sink element | 17:40 |
| jhodapp | aquarius_, would you want audio in there too? | 17:40 |
| aquarius_ | jhodapp, yeah. | 17:40 |
| aquarius_ | Audio... hm. Yes, ideally. | 17:41 |
| aquarius_ | the goal for this is to make screencasting really, really easy, as it is with AirPlay mirroring on iOS. | 17:41 |
| aquarius_ | except without all Apple's brain-dead drm stuff built in :) | 17:41 |
| jhodapp | aquarius_, well a little trickier then but should still be doable...you would need the same as I described above, but another element to read the audio data from pulse, then the gstreamer mp4 mux plugin, then the network sink | 17:42 |
| aquarius_ | at the moment screencasting the ubuntu phone is hard, because you can't do it at full resolution and framerate because it all happens on the cpu and so the phone bogs down. | 17:42 |
| aquarius_ | audio is a nice-to-have, not an ssential. | 17:42 |
| jhodapp | aquarius_, ok, a proof of concept would be to just do video first | 17:42 |
| nhaines | Audio's good for v1.1 | 17:42 |
| aquarius_ | the three primary use cases for this, in my mind, are: demoing the phone, live, to someone on a big screen; showing the phone's screen in a window on your desktop for hangouts, etc; streaming the video to somewhere that it can be recorded. | 17:43 |
| aquarius_ | the *real* use case for this is "use your phone to drive your TV", which is a proper user use-case rather than a techie use case, but that needs audio | 17:43 |
| aquarius_ | and a whole bunch of other standards stuff like miracast, etc. | 17:43 |
| jhodapp | aquarius_, you know what would be ideal is to get AirTame ported to Ubuntu Touch | 17:44 |
| aquarius_ | so being able to screencast by just streaming an mp4 stream to a network http server is enough to get this off the ground, and that's the bit which needs to be done inside the core OS. Everything else is niceness. | 17:44 |
| aquarius_ | jhodapp, maaaaaaaaaaaybe. AirTame is proprietary :( | 17:44 |
| jhodapp | aquarius_, their driver, because they do this already for mobile devices and they developed the tech using primarily Ubuntu | 17:44 |
| aquarius_ | because they wanna sell devices. | 17:45 |
| jhodapp | yes | 17:45 |
| aquarius_ | Apple Airplay actually is nice and open, in theory -- run an http server and advertise it on zeroconf as _airplay._tcp and an iphone will detect it and try streaming to it. That would be how we'd do it. (Airplay then doesn't owrk because you have to do a stupid drm exchange, but we wouldn't do that bit. :)) | 17:46 |
| jhodapp | aquarius_, anyway, what you want should be possible, it's hard to predict what the performance would be like | 17:46 |
| jhodapp | aquarius_, yeah, if I'm not mistaken airplay does Apple's HTTP Live Streaming, which I've worked with a bunch in the past | 17:46 |
| aquarius_ | jhodapp, oh, really? I can promise you that just taking the rawvideo output from mirscreencast and shovelling it over the network makes the phone bog down too much. I was hoping that if this were all done at a low level then there'd be hardly any cpu involvement at all; it's all just the mp4 encoder on a chip (which wasn't doing anything at all before) and the network stack | 17:47 |
| jhodapp | aquarius_, yeah, I'm just worried about feeding to GStreamer, but it's tough to say | 17:48 |
| aquarius_ | (this is why I halve the size of screencasts, and only do 6fps, which doesn't make the phone bog down but looks really not smooth in videos :( ) | 17:48 |
| aquarius_ | jhodapp, fair comment! | 17:49 |
| jhodapp | aquarius_, another option would be to modify the MPEG4Writer class to feed the output into a very tiny web server and keep it all at the Android level | 17:49 |
| aquarius_ | that would mean that you don't stream *to* a remote device (your TV), but the TV streams *from* you? | 17:50 |
| jhodapp | aquarius_, yes, or you could do a simple http client as well | 17:51 |
| jhodapp | aquarius_, just depends on what's on the receiving side | 17:51 |
| aquarius_ | ya. I'm inclined to suggest that the phone looks for zeroconf-advertised servers and streams to them, and then those servers can do what they like with the stream, but that's all handwave detail at the moment. The hard bit is getting an mp4 to stream at full resolution and framerate without the phone lagging to death :) | 17:52 |
| aquarius_ | this was an encouraging discussion! | 17:52 |
| aquarius_ | I need to work out how to have this be your priority task now ;-) Who's your boss? Do they like chocolates? :) | 17:53 |
| jhodapp | aquarius_, awesome, glad it was helpful | 17:53 |
| jhodapp | aquarius_, you were talking to him right before me :) | 17:53 |
| jhodapp | aquarius_, beer, lots of beer would be my suggestion ;) | 17:53 |
| aquarius_ | not sure my liver is up to the challenge of bribing ChickenCutlass ;) | 17:57 |
| === alan_g is now known as alan_g|EOD | ||
| === SturmFlut|AFK is now known as SturmFlut | ||
| bschaefer | SturmFlut, hey, soo just pushed some new changes to this branch: https://code.launchpad.net/~brandontschaefer/libsdl/sdl2-needs-rebuild-mir | 18:21 |
| bschaefer | which should fix your issues, if you dont mind giving it a test! | 18:21 |
| bschaefer | also the fixes are aimed at vivid, not utopic sadly | 18:22 |
| SturmFlut | bschaefer: So my phone should be running Vivid? | 18:22 |
| bschaefer | SturmFlut, if possible yes | 18:23 |
| bschaefer | i just have it on vivid sooo its pretty hard to test out, i also usually use: https://hg.libsdl.org/SDL | 18:23 |
| bschaefer | haha, soo i need to test main out more | 18:23 |
| SturmFlut | bschaefer: Oh, you fixed a lot of stuff in Revision 18. | 18:23 |
| bschaefer | yeah its stuff i've fixed upstream | 18:24 |
| bschaefer | but never ported back into main | 18:24 |
| bschaefer | i think the main things though are: 114=== modified file 'src/video/mir/SDL_mirsym.h' | 18:24 |
| bschaefer | as with out that change, dlsym fails | 18:24 |
| bschaefer | soo the mir backend is skipe | 18:24 |
| bschaefer | skipped* | 18:24 |
| SturmFlut | General question to the channel: Which version will the commercially available devices (Bq Aquaris etc.) be on? All my current apps are targeting Utopic because the mako stable channel is Utopic, and I want all my apps to run on as many devices as possible | 18:27 |
| bschaefer | SturmFlut, well, ideally the version the phone is released on? Though targeting utopic isn't a bad idea, just Im not sure if i'll be able to get an SRU in to fix these issues in Utopic | 18:31 |
| bschaefer | i could always make a ppa... | 18:31 |
| SturmFlut | bschaefer: I'll give it a try later, thanks for your work and thanks for pinging me :) | 18:33 |
| bschaefer | SturmFlut, np, thanks for testing it out! | 18:33 |
| === salem_ is now known as _salem | ||
| popey | SturmFlut: bq will ship with utopic and move to vivid via OTA sometime in March (probably) | 18:50 |
| popey | (maybe a bit later) | 18:50 |
| SturmFlut | popey: Ah, thanks. So I'll continue targeting Utopic | 18:52 |
| bschaefer | SturmFlut, if that branch works ill create a ppa to get it so you can work with utopic! | 18:53 |
| bschaefer | (it should work...) | 18:53 |
| === greyback__ is now known as greyback | ||
| === _salem is now known as salem_ | ||
| SturmFlut | mzanetti, kgunn: I just published http://sturmflut.github.io/linux/ubuntu/2015/01/21/installing-ubuntu-15.04-on-baytrail-tablets/ , it is not complete but should contain enough information to to a full installation | 19:16 |
| mzanetti | SturmFlut: nice! thanks :) | 19:16 |
| SturmFlut | mzanetti, kgunn: If not people can file bug reports against my blog on github (which might be the nerdiest thing I've ever said) | 19:17 |
| mzanetti | no, there has been worse | 19:17 |
| mzanetti | :D | 19:17 |
| SturmFlut | mzanetti: I see you know me well... | 19:18 |
| kenvandine | jgdx, your wifi-fix-cancel-test branch includes my dialog cpo work around, which won't work in rtm yet... that's why you're seeing that problem | 19:28 |
| dobey | why would 'init' be using lots of cpu? | 19:32 |
| dobey | my phone was quite hot earlier and init was constantly jumping between ~4% and ~20% cpu usage. seems to not be doing so now, after i rebooted, though | 19:33 |
| jgdx | kenvandine, wifi-fix-cancel-test was for vivid.. | 19:37 |
| jgdx | kenvandine, I fixed the test in rtm-forgetful | 19:37 |
| jgdx | *that test | 19:38 |
| kenvandine | jgdx, oh... that error about Dialog seemed to be from 14.09 though | 19:38 |
| jamie_ | Does anyone know if hostapd is working, so I can use a Nexus 4 in AP mode? | 19:42 |
| kenvandine | jamie_, i've heard that can work, with some scripts | 19:43 |
| kenvandine | jamie_, but i don't know how, just heard people have done it | 19:43 |
| ahayzen | dobey, bug 1410506 | 19:44 |
| ubot5 | bug 1410506 in mtp (Ubuntu RTM) "MTP looping between start and stopping causing constant ~10% cpu load" [Undecided,In progress] https://launchpad.net/bugs/1410506 | 19:44 |
| jamie_ | kenvandine - do you have any links that could help me? | 19:45 |
| kenvandine | jamie_, sorry, no... cyphermox ^^ | 19:46 |
| dobey | ah | 19:46 |
| kenvandine | jgdx, can you review this backport for me? | 19:47 |
| kenvandine | https://code.launchpad.net/~ken-vandine/ubuntu-system-settings/rtm-brightness_crash/+merge/244202 | 19:47 |
| jgdx | kenvandine, sure | 19:53 |
| kenvandine | jgdx, thx! | 19:54 |
| SturmFlut | jamie_: I just logged into my Nexus 4 via adb shell, made the image writeable, "apt-get install hostapd", took the example configuration, "service network-manager stop" and ran hostapd. Seconds later the new SSID appeared on my other devices. So AP mode with hostapd seems to work on the Nexus 4. | 20:00 |
| jamie_ | Brilliant - will try it. Which channel / version are you running? | 20:00 |
| popey | nice! | 20:00 |
| SturmFlut | jamie_: stable, 14.10 r14 | 20:01 |
| jgdx | kenvandine, are you looking at rtm silo 4? | 20:03 |
| kenvandine | jgdx, not yet... i was looking at what i wanted to land after silo 4, since silo 4 will need a rebuild after silo 19 lands | 20:04 |
| kenvandine | but testing silo 4 wouldn't be a waste, since the 2 silos don't touch the same plugins | 20:05 |
| mzanetti | SturmFlut: btw, https://plus.google.com/105839534016416729197/posts/ePSLDescKL3 | 20:06 |
| jgdx | kenvandine, nope. I am done testing, looks good. But would be nice to get another pair of eyes on it. | 20:06 |
| kgunn | SturmFlut: i must have posted at the exact same time as Michael :D | 20:07 |
| kgunn | https://plus.google.com/116997345010659023379/posts/RiuPtGyEY8Y | 20:07 |
| kenvandine | jgdx, can you add some more detail for testing on line 54? | 20:07 |
| kenvandine | don't want to run the entire plan there | 20:07 |
| awe_ | Wellark, was there a chance recently to PIN prompting when coming out of flight-mode? Wasn't this supposed to be an auto-prompt? | 20:08 |
| SturmFlut | mzanetti, kgunn: Haha, nice! | 20:11 |
| jgdx | kenvandine, done | 20:12 |
| kenvandine | jgdx, thx | 20:17 |
| === salem_ is now known as _salem | ||
| * Jon9012 is away: I'm busy | 20:35 | |
| === Laney is now known as Guest54456 | ||
| SturmFlut | bschaefer, popey: I built lp:~brandontschaefer/libsdl/sdl2-needs-rebuild-mir manually on my Utopic device because I am obviously too stupid to do proper cross compiling. If I omit the "--enable-mir-shared" from the standard ./configure line I actually get a libSDL2.so which loads libmirclient.so.8 and libmircommon.so.2, but then produces a segmentation fault in libprotobuf.so.8 | 21:48 |
| bschaefer | SturmFlut, hmm i just tested that branch out on the phone... and it worked | 21:49 |
| bschaefer | the libprotobuf sounds like a mir issue... | 21:49 |
| SturmFlut | bschaefer: But you are on Vivid, right | 21:49 |
| bschaefer | yeah | 21:49 |
| bschaefer | let me re-flash my phone with utopic and see what happens | 21:49 |
| bschaefer | SturmFlut, what did you test? | 21:50 |
| SturmFlut | bschaefer: https://github.com/Sturmflut/ubuntu-touch-sdl-template/blob/master/src/main.c | 21:51 |
| bschaefer | SturmFlut, im guessing it seg faults in the Init part right? | 21:51 |
| SturmFlut | bschaefer: Jep, was about to type that | 21:51 |
| bschaefer | yeeeah, something in mir is wacky... what happens when you try to run a mir demo? | 21:52 |
| bschaefer | sudo apt-get install mir-demos | 21:52 |
| bschaefer | then try mir_demo_clients_eglplamsa | 21:52 |
| bschaefer | or something (in a desktop file) | 21:52 |
| bschaefer | im wondering if somethings being strange in mir... or if its sdl doing something weird | 21:53 |
| SturmFlut | bschaefer: Got /usr/bin/mir_demo_client_eglplasma to work on the phone | 21:58 |
| SturmFlut | bschaefer: ...let me try some other things, I suspect that it is my fault... | 21:58 |
| bschaefer | shoots, thats strange, what version of libproto is it using? | 21:58 |
| bschaefer | i remember libproto being weird at some point as well...but i dont remember the cause | 21:59 |
| SturmFlut | libprotobuf.so.8 => /usr/lib/arm-linux-gnueabihf/libprotobuf.so.8 (0xb6ce5000) | 21:59 |
| bschaefer | SturmFlut, you can always try out a test in SDL/tests/ | 21:59 |
| bschaefer | theres quite a few tests in there | 22:00 |
| bschaefer | but hmm | 22:00 |
| bschaefer | im not sure why it wants to only fail through SDL | 22:00 |
| * Jon9012 is back (gone 02:10:18) | 22:46 | |
| * Jon9012 is away: I'm busy | 22:55 | |
| popey | Jon9012: you might want to disable that | 22:56 |
| SturmFlut | bschaefer: At least on my device it goes like this: MIR_Available() calls SDL_MIR_LoadSymbols(), which calls SDL_LoadObject(libmirclient.so.8) and SDL_LoadObject(libxkbcommon.so.0). Both libraries get loaded and then the functions are resolved. Everything goes well, so MIR_Available() calls SDL_MIR_UnloadSymbols() to unload the libraries again. | 23:29 |
| SturmFlut | bschaefer: In the next step MIR_CreateDevice() is called, calls SDL_MIR_LoadSymbols() again, and this time the segfault occurs *inside* SDL_LoadObject(libmirclient.so.8) | 23:29 |
| bschaefer | Hmm i wonder if its not correctly releasing them? | 23:30 |
| bschaefer | SturmFlut, what you could try, is to use --disable-mir-shared | 23:30 |
| bschaefer | in the debain/rules | 23:30 |
| bschaefer | instead of --enable-mir-shared, as if its disable it will just return 1; | 23:30 |
| bschaefer | and will not load anything | 23:31 |
| SturmFlut | bschaefer: Rebuilding... | 23:34 |
| bschaefer | SturmFlut, sorry for all of these weird issues...some times the dynamic way of loading is very fickle | 23:35 |
| SturmFlut | bschaefer: I wonder why the second call to SDL_LoadObject() fails | 23:37 |
| bschaefer | SturmFlut, yeah ... its a bit strange but the reason we load then unload is we just need to double check we should even use that backend | 23:37 |
| bschaefer | if we end up using a different backend, it would leak | 23:37 |
| bschaefer | sooo .. hmm thats really strange Ill have to re-flash my phone to check that out my self | 23:37 |
| jrg | so is there any word on a US release date for an ubuntu phone from BQ yet? | 23:42 |
| jrg | doesn't seem like those Meizu phones will be out any time soon | 23:42 |
| SturmFlut | bschaefer: rebuilt it with --disable-mir-shared, still segfaults. Let me throw in another round of debugging... | 23:43 |
| jrg | latest rumor was BQ was releasing to the EU in the first week of feb 2015 | 23:43 |
| bschaefer | SturmFlut, geez.. hmm I think theres something wrong with the libs for some reason... Ill need to also take a look... Dont want you to spend to much time on that! | 23:45 |
| sergiusens | join #ubuntu-release | 23:45 |
| SturmFlut | bschaefer: All my other app ideas are on hold because of issues I can't do much about. This SDL issue at least is something I can work on. | 23:47 |
| bschaefer | RAOF, hey, do you remember any strange issues from a crash in protobuf? | 23:48 |
| bschaefer | RAOF, on utopic? | 23:48 |
| RAOF | bschaefer: Protobuf is stupid about being loaded twice? | 23:48 |
| bschaefer | RAOF, it would seem that way... though when disabled it still seems to crash | 23:48 |
| RAOF | ie: if you load it twice into a process at the same time, it aborts. | 23:49 |
| bschaefer | RAOF, ill need to re-produce the issue... normal mir stuff works | 23:49 |
| bschaefer | RAOF, right. Though he disable shared sooo it shouldn't be loaded twice anymore | 23:49 |
| bschaefer | and it still seg faults | 23:49 |
| bschaefer | RAOF, was just curious if you've hit something like that before, i need to dig into it more | 23:49 |
| RAOF | Hm, no, that's not familiar. | 23:50 |
| bschaefer | RAOF, dang, nm then! Thanks | 23:50 |
| SturmFlut | I am quite surprised how fast the Nexus 4 is at compiling code. No match for the machines I usually work with, but for a consumer phone the performance is pretty solid. | 23:53 |
| nik90 | charles: hey, just wanted to let you know that the one-time alarm status shown in the clock app now updates correctly when i-dt disables after it has gone off :) .. You can now correct your manual test about that refresh ui bug. | 23:57 |
| nik90 | charles: oh and also I have a branch ready to fix https://bugs.launchpad.net/ubuntu-clock-app/+bug/1372545 | 23:58 |
| ubot5 | Launchpad bug 1372545 in Ubuntu Clock App "Day-of-Week picker in Alarms doesn't respect locale" [Medium,In progress] | 23:58 |
| SturmFlut | bschaefer: I was wrong, after rebuilding with --disable-mir-shared the backtrace looks different | 23:58 |
| SturmFlut | bschaefer: http://paste.ubuntu.com/9811754/ | 23:58 |
| nik90 | charles: so the alarm days-of-week picker should now respect your locale..the alarm time-picker doesn't yet, but that's due to the sdk | 23:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!