[00:15] <Fighter19> Are porting questions also to be asked in this room. If yes. Does Ubuntu Touch also use init.rc?
[00:17] <RAOF> Ubuntu Touch uses upstart (at the moment - switching to systemd is a work in progress, IIUC)
[00:19] <RAOF> So you *can* stick things in /etc/rc.* and the right thing will happen, but you're probably better off dealing with native upstart.
[00:20] <Fighter19> So if I have to load / insert  a kernel module at an early stage?
[00:22] <RAOF> It doesn't get autoloaded?
[00:22] <RAOF> But you can certainly write an upstart job for that.
[00:22] <RAOF> (Or in init.d script, of course)
[00:23] <Fighter19> Well, I have a kernel module which creates block devices so I can mount my NAND filesystem.
[00:23] <RAOF> Ah, so you'll need it to be in the initramfs.
[00:23] <RAOF> Which I *believe* we use on Touch.
[00:24] <Fighter19> Is it possible to output kernel log to the screen if that's the case?
[00:25] <RAOF> Hm. This must actually be in the android half of Touch, because that's where the kernel is loaded from.
[00:26] <Fighter19> Well, should be also fine.
[00:26] <RAOF> I'm not familiar with the details of porting, but the kernel comes from Android...
[00:29] <Fighter19> I have a working Android Kernel built for my device. I tried to port CM. But init.rc (for the main system) seems to cause problems, which is why I consider porting to Ubuntu Touch first.
[00:31] <Fighter19> If I have adb at an early stage of the boot sequence I'm more than satisfied.
[00:32] <RAOF> You've presumably seen https://developer.ubuntu.com/en/phone/devices/porting-new-device/ ?
[00:32] <Fighter19> Yes I've seen it.
[00:33] <RAOF> Under the Debugging header: “This will open an adb shell and pause execution of the initrd,”
[00:34] <RAOF> So, yes - you'll need to ensure your kernel module ends up in the initrd and you should be able to use a script in hooks/modules to load it.
[00:34] <Fighter19> Sounds great!
[00:36] <Fighter19> Thank you. I'll definetly try to hopefully get something to run tomorrow!
[00:39] <dobey> Fighter19: why is that driver not just built into the kernel?
[00:43]  * RAOF expects some totally appalling reason, like it's a binary blob.
[01:05] <Fighter19> dobey, because it's a propietary blob.
[01:08]  * Fighter19 overlooked the "me" line my RAOF .
[01:08] <RAOF> HAH! Called it.
[01:09] <RAOF> What manufacturer should we be pointing and laughing at?
[01:11] <Fighter19> At Rockchip ;)
[01:13] <Fighter19> Same goes for the mali modules.
[01:13] <RAOF> Those at least you don't need in order to mount your root filesysem.
[01:13] <RAOF> And GPUs are *somewhat* more complex than NAND interfaces.
[01:14] <Fighter19> That's true.
[01:17] <Fighter19> I remember some strange stuff had to be done to get Mali chips running under Linux. I hope it doesn't get too complicated again. And I hope they're powerful enough
[01:18] <RAOF> Fortunately you don't need to get the Mali chips running under Ubuntu userspace; you only need to get them running under Android userspace :)
[01:19] <Fighter19> Does ubuntu access the framebuffer? :O
[01:20] <RAOF> Only though the Android HAL.
[01:21] <RAOF> (This is the point of mir-graphics-platform-android - given an Android graphics stack, provide an Ubuntu one on top of it)
[01:21] <Fighter19> Wait, if no OpenGLES and no FB, how is it supposed to  show something? Am I missing something? xD
[01:21] <RAOF> The magic of libhybris - Mir accesses the usual Android graphics stack to do this.
[01:21] <RAOF> So you need working Android drivers, but once you've got them it's done*.
[01:22] <Fighter19> Nice.
[01:22] <Fighter19> So it should automatically work
[01:22] <RAOF> *: Modulo the fact that graphics drivers are terrible and you might need to quirk things.
[01:22] <Fighter19> I'd still like to activate GLES if possible at some time.
[01:22] <Fighter19> I think Ubuntu Touch supports it?
[01:23] <RAOF> You'll get it for free.
[01:23] <RAOF> If you can bring Mir up on your android drivers, any client connecting to that Mir server will get GLES support.
[01:24] <RAOF> Again, modulo the fact that graphics drivers are terrible.
[01:25] <Fighter19> I guess I'll just have to read through some documents first :D
[01:28] <Fighter19> I'm kinda surprised. Because normally the libMali.so contains the symbols for GLES. So it can be linked with the normal GLES headers. But in the end effect it accesses /dev/mali which again is created by the kernel module.
[01:29] <RAOF> That's how the userspace component of graphics drivers generally works.
[01:30] <RAOF> Provide the GL/GLES/whatever ABI at one end, talk to the kernel module at the other.
[01:38] <Fighter19> When you think that your Linux knowledge helps you to understand Android xD. The HAL thing was new to me, but as I understand it, it's inside the kernel and provides a unified way to access devices of the same type. Sounds easy enough, de facto. So my kernel will know what to do once the modules are loaded.
[01:45] <Fighter19> Ah no, that was BS what I just said.
[01:50] <Fighter19> Your device has a piece of code which provides the interface for the communication with the hardware (often through device nodes) for HAL. I think THIS is right. (sorry to spam the chat, sometimes I have to say out thinks "loud" :D )
[01:51] <Fighter19> Just wondered why there was no config (putting the so inside the proper directory is enough :O )
[01:54] <Fighter19> Thank you! Have a good night / or day, wherever you are :)
[03:56] <JasonD> @duflu - There is a video on OMGUbuntu from April showing a Nexus 4 and a Nexdock with correct resolution - http://www.omgubuntu.co.uk/2016/04/ubuntu-touch-nexdock-video
[03:58] <duflu> JasonD: Cool, thanks. Maybe I/we/mir-team will end up having to order one.
[03:58] <duflu> Because I don't have any other way to test the problem right now
[03:59] <JasonD> Hi, yeah I thought I had seen it working properly somewhere, could it be a regression or my slimport cable?
[03:59] <JasonD> Happy to help if I can
[03:59] <duflu> JasonD: More likely a regression. Faulty cables will result in no image (which is VERY common). Do you get any image?
[03:59] <duflu> I've found 50% of Slimport cables are unusably faulty....
[04:00] <JasonD> Yes, just very difficult to read as the font is so small/fuzzy
[04:00] <duflu> Cool, that's something at least
[04:00] <JasonD> This is my second one, they are not very well made it seems
[04:01] <duflu> If the Nexdock does advertise other resolutions I don't think mir's Android backend will report them. Maybe it's just Mir defaulting to the wrong resolution
[04:04] <JasonD> Dunno, but if you watch the video the resolution looks correct, on mine the icons and address bar in the web browser are way smaller
[06:08] <sebsebseb> hi
[06:09] <JasonD> Hi
[06:10] <sebsebseb> JasonD: hi
[06:10] <sebsebseb> how you get on with your nexux 4 and  the nexdock
[06:10] <sebsebseb> etc
[06:11] <JasonD> Still wrong resolution atm, tried it with RPi2 ok
[06:11] <sebsebseb> JasonD: it's just a tv screen tough or kind of
[06:12] <sebsebseb> I thik meant to adust  resolutions on the devices that are dconnected to it reallhy ?
[06:12] <sebsebseb> JasonD: or like with a desktop. you adjust the reesolutino in windows :d,  and then  it goes on the screen
[06:13] <JasonD> A bug has been raised, I did find a video from earlier in the year showing a N4 working correctly so may be a regression
[06:13] <sebsebseb> JasonD: or you have a kid across the roadcoming to your house,  since was sort of freindly with your sons at the time so me and my brother
[06:13] <JasonD> It looks like the N4 is outputting FHD regardless
[06:13] <sebsebseb> JasonD: the id changes the resolutiohn  to something my Dad doesn't like
[06:13] <sebsebseb> and he gets all uh about it etc
[06:14] <sebsebseb> all annoyed about it,  and  I think may have even gone across the road to get cahngedback  cn't remeber
[06:14] <sebsebseb> oh 90's with Windows h eh
[06:14] <sebsebseb> 1990 's
[06:14] <sebsebseb> good times?
[06:14] <sebsebseb> h eh
[06:14] <JasonD> Should work like this: http://www.omgubuntu.co.uk/2016/04/ubuntu-touch-nexdock-video
[06:15] <sebsebseb> JasonD: the Nexus 4 isn't FHD though I think ?
[06:15] <JasonD> Rebooting after every change? lol
[06:15] <sebsebseb> what in Windows?
[06:15] <JasonD> It outputs FHD via the slimport
[06:15] <JasonD> yes
[06:15] <sebsebseb> yes inded re booting after lots of things that' Windws
[06:16] <JasonD> brb, of to lunch
[06:16] <sebsebseb> JasonD: ok
[08:28] <javier4>  First of all, my original aosp tree builds and runs. My ubuntu tree instead, fails with CAPEWrapper.cpp:16: error: undefined reference to '__xlog_buf_printf'
[08:28] <javier4> that function is declared inside cutils/xlog.h, but the only file where it could be defined is a binary inside vendor/$something/libs/*
[08:28] <javier4> I added vendor/$something/libs to main.mk, but my build still complains about that definition missing
[10:01] <popey> dobey: did you ask about phablet-tools yesterday because it broke during update?
[10:01] <popey> (it did here)
[11:21] <jgdx> popey, seems he's off this whole week
[11:36] <popey> jgdx: ta
[11:50] <davmor2> popey: what broke?
[11:52] <popey> davmor2: nvm :)
[13:03] <mpt> “Device krillin not found on server https://system-image.ubuntu.com channel ubuntu-touch/stable”
[13:09] <mpt> Should I be using bq-aquaris.en instead?
[13:10] <mpt> But that was last updated in July…
[13:12] <davmor2> mpt: that sounds about right you are looking at stable
[13:12] <davmor2> mpt: ubuntu-touch/rc/bq-aquaris.en contains the ota we are looking to release if that is what you are after
[13:14] <mpt> thanks davmor2
[14:34] <Fighter19> Can I use a CM tree as reference to initialize the phablet tree?
[14:34] <Fighter19> Or does this only work with an AOSP tree?
[14:41] <Fighter19> Which branch is considered stable? :O
[14:41] <Fighter19> phablet-5.1.1?
[15:34] <saidinesh5> Fighter19: ubports tree is based on CM
[17:01] <Fighter19> Got an error building the recovery executable. Inside roots.cpp cryptfs has not been found
[17:03] <Fighter19> (I'm on the phablet-5.1.1_r36 branch)
[19:23] <Fighter19> My system partition is only 100 MB big, can this be right? :O
[19:23] <Fighter19> Regarding what has been built.
[19:33] <jonathan___> hello. Is it safe, (easy?) to buy a meizu mx4 with flyme os and install ubuntu touch myself ? thank
[19:39] <NotKit> jonathan___, it's possible to install it the same way as on ported devices
[19:54] <Fighter19> Does any one here have an idea how I debug the startup on a new device. I can boot the created recovery partition without problems, but if the same kernel tries to boot the ramdisk from boot it fails.
[19:55] <Fighter19> I even tried to set break=top in the CMDLINE. It even shows up in the recovery so that can't be the problem.
[23:06] <Fighter19> Looks like my device only likes binary inits.....