Re: [Ubuntu-phone] obexd-{client,server}: replaced by bluez-obexd?
On 20.08.2015 23:20, Steve Langasek wrote:
Hi all,
I've been taking care of a backlog of packages that have been removed in
Debian but not removed in Ubuntu. One of the packages that's shown up on
the list as having reverse-dependencies in Ubuntu is obexd, whose packages
(obexd-client and obexd-server) don't merely have reverse-dependencies, they
have the ubuntu-touch metapackage as a reverse-dependency.
According to the Debian bug report (http://bugs.debian.org/772094), these
packages are obsolete and superseded by bluez-obexd. bluez-obexd is
available in Ubuntu, and does show itself as replacing obexd-client and
obexd-server. Should the touch seed be changed to use bluez-obexd in place
of obexd-{client,server} going forward from wily? Do we have test cases for
obex support on the phone?
Bluetooth support on Touch in wily is currently broken with bluez 5.33
being included. All touch components still expect the old 4.x DBus API.
The conversion will happen soon once we get bluez 5.x running on Touch.
I am not sure that there are explicit test case for OBEX but I at least
remember some which included address book syncing with car kits.
However running them on Touch will be not possible in wily so I am fine
with just dropping obexd-{client,server} from the Touch seeds in wily
and use bluez-obexd instead.
regards,
Simon
--
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] Bluetooth API for 3rd party developers
On 23.08.2015 04:44, XiaoGuo Liu wrote: Hi, I am now trying to help a developer to get Bluetooth API. On our phone platform, do we have any open API for the purpose? I cannot find any such info at: http://developer.ubuntu.com/api/apps/qml/sdk-15.04/. From what I know we currently don't expose any bluetooth specific APIs. Qt itself offers some (see http://doc.qt.io/qt-5/qtbluetooth-index.html) but I never tried to use them in Ubuntu Touch applications. The package (qml-module-qtbluetooth) responsible for it also isn't installed on our current images. This is really something we need to get up on our list of things we have to provide as part of our application usable API sets. regards, Simon -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] Preparing for larger images
On 27.08.2015 13:17, Thomas A. Moulton wrote: From watching the various updates my Tablet (flo) has received, aren't the OTA updates deltas? If so, then would it be expected to have >500MB of changes between updates often? In the most recent update I think I saw about 148MB downloaded. Think about the case where we upgrade the second rootfs from 14.04 to 16.04 or similar cases. Could this be a temporary problem, because aren't we going to migrate to a Snappy based system at some point? Then with the System-ab partitions some of the rules may change, such as writing updates to System-B while we're running in A, not requiring a single download to have everything. That would still imply a change to the partitioning which is quite critical on production devices. For a fresh made device this might work but would still be depending on the size of our partitions we setup. regards, Simon -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] Preparing for larger images
On 27.08.2015 13:56, Sergio Schvezov wrote: On Thu, Aug 27, 2015 at 7:14 AM, John McAleely wrote: As we begin to prepare for new features associated with converged devices, it seems likely that some image configurations will be *much* larger than our current phone images on system-image.ubuntu.com As an example, I've been anecdotally informed that if an OEM wanted to bundle libreoffice (a likely scenario) that may add around 500M to the image size. Currently, we download images three ways: - Via system updates to the phone, where the download is pulled to the cache partition - Via a host desktop and then via ubuntu-device-flash to the phone. Again, this writes the (compressed) images to the cache partition as a staging step - Via various factory flashing tools, which simply write whole partitions as-is (similar to how dd might work) Typically, the cache partition on android devices seems to be in the range 500-700M, and it it certain that some desirable converged device configurations will have images that (in compressed form) are much larger than this. The first two flashing methods will clearly break. A simple solution to this problem is to increase the size of the cache partition on devices where large applications might be installed. Fine for those devices where we control the partition table, but impossible on those devices where we co-exist with android and don't change that table. Those devices where the partition table can't be modified includes Mako, Flo, etc. For those devices, we clearly need to make changes to how images can be downloaded, if we wish to support these devices for convergence images. One choice would simply be to reserve a sufficiently large amount of space in the userdata area of the android partition table, and ask our image flashing tools to use that. We would then ignore the cache partition entirely for the flashing process on these phones. Is it just the download/updater (including recovery) that is impacted, or are other actors involved in preparing system updates? This could be solved with having an entry in channels.ini (if it is not there already) with the preferred storage location for updates and have all clients respect that. I just say channels.ini because it is common to all, there may be a better location. The recovery script may not need to know about this, but the client generating the update script would and it would generate an update script with the right commands. I haven't checked if this would be supported out of the box, I'm just saying that when in recovery we shouldn't need any special flag if the update commands are done right. The system-image-upgrader script currently expects a update file to be placed on /cache/recovery so we would have to change this. regards, Simon -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] obexd-{client,server}: replaced by bluez-obexd?
On 29.08.2015 16:26, Ricardo Salveti de Araujo wrote:
On Aug 28, 2015 20:20, "Steve Langasek"
wrote:
On Fri, Aug 28, 2015 at 08:06:24PM -0300, Ricardo Salveti de Araujo wrote:
On Aug 21, 2015 14:17, "Tony Espy" wrote:
On 08/20/2015 05:20 PM, Steve Langasek wrote:
I've been taking care of a backlog of packages that have been removed
in Debian but not removed in Ubuntu. One of the packages that's
shown
up on the list as having reverse-dependencies in Ubuntu is obexd,
whose
packages (obexd-client and obexd-server) don't merely have
reverse-dependencies, they have the ubuntu-touch metapackage as a
reverse-dependency.
According to the Debian bug report (http://bugs.debian.org/772094),
these packages are obsolete and superseded by bluez-obexd.
bluez-obexd
is available in Ubuntu, and does show itself as replacing
obexd-client
and obexd-server. Should the touch seed be changed to use
bluez-obexd
in place of obexd-{client,server} going forward from wily? Do we
have
test cases for obex support on the phone?
We do, the main use case here is contact sync with cars and so on, which
uses obex.
The API from the obex provided by bluez is quite different, so please
only
drop this once we migrate completely to bluez5.
Unfortunately, I already removed the packages when Tony gave the go-ahead.
Does this change need to be reverted? If so, I think it would be best if
the phone team explicitly took ownership of the obexd-* packages by
preparing a new upload (which could then be sponsored in).
Otherwise, as far as bluez5 is concerned, looking at the archive I believe
this migration is already done. So perhaps there's no need to revert?
I'm not following the bluez5 work, so not sure if it is already completed,
maybe Simon can provide more details.
For wily this can stay as it is as already stated before. BlueZ 5.x has
landed in wily and is therefore also included in the Touch images and we
consider bluetooth as broken in wily for now. That is one of the
downsides of the transition but doesn't really matter as nobody really
uses wily at all.
For vivid we have to do the same change but coordinated with the BlueZ
5.x landing which doesn't has any date set yet as we still have quite
some userland porting work for this ahead.
@Steve: Can you point me to the change you did for wily to unseed those
packages?
regards,
Simon
--
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] Using 64bit Android BSPs with Ubuntu
On 07.09.2015 17:21, Oliver Grawert wrote: Am Montag, den 07.09.2015, 14:57 +0100 schrieb John McAleely: Are these the two options we have? What pros and cons are there for each? do you actually know (did anyone test) if hybris would get along with running in 32bit on the ubuntu side while the container is 64bit ? i suspect there needs to be some syscall translation between the two hybris sides ... I doubt that will work. At least not for libGLES, libEGL, .. as they don't use proper length-defined types like uint16_t. Also from what I've seen we can't promise which HAL libraries we get in 32 / 64 bit and which only in 32 bit and which only in 64 bit. The Android CDT defines a small subset of Android libraries which must be available in both variants but that isn't enough for our purpose. Also I am not entirely sure if the HAL API is reliable in terms of well defined types. otherwise yes, it would be a good interim if we could use a 32bit rootfs with 64bit container ... apps wouldnt be able to address the full ram though (afaik thats limited to 3GB with armhf) so it wouldnt be a permanent solution. long term someone needs to make arm64 images work anyway indeed. For the near term we need a solution to handle both as we will have to support applications having different types at the moment. We need to find a way to ensure that all future applications in the store will get a 64 bit variant as well to prevent us from having to support 32 bit apps forever and can easily switch to 64 bit only later once we don't offer any other devices anymore. regards, Simon -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] Using 64bit Android BSPs with Ubuntu
On 07.09.2015 15:57, John McAleely wrote: Folks, More and more Android devices are shipping in 64bit form. As such, I think Ubuntu needs a plan to use the drivers from such a system sooner rather than later. We have a choice, I think. We can either attempt to build a 64bit Ubuntu image for phones (broadly, an arm64 version of what we have, for example), or attempt to use the 64bit Android in a way that is restricted to only the container which hosts it. In such a system, the rest of the Ubuntu image need not change at all, and would exist as a collection of armhf binaries. I think the safest way is to adapt a bit to what Android does for this today as they have a similar problem (but also a bigger app store which quite more 32bit-only apps than we do). The Android Compatibility Definition (see [1]) defines pretty well what devices must support. Chapter 3.3 Native API Compatibility describes the current situation on Android: Each devices which is 64 bit MUST provide a set of well defined libraries also in 32 bit. Those are mainly all libs which are used by apps build with the Android NDK. That is what we can expect for any Android BSP at the moment if it want to pass the Android CDT. With this in mind a multiarch system might one of the candidate options if we don't end up with a dependency chain of one of our apps in the store which requires a 64 bit only Android library at the other end. Similar to what we have on Ubuntu multiarch systems in Ubuntu Android separates 32 and 64 bit binaries into different locations. As libhybris provides a set of wrapper libraries which loads their Android equivalent we need this set of wrappers + libhybris in 32 and 64 bit in our system when doing a multiarch system which would then satisfy our needs. regards, Simon [1]: https://static.googleusercontent.com/media/source.android.com/de//compatibility/android-cdd.pdf -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] Using 64bit Android BSPs with Ubuntu
On 08.09.2015 09:14, Vicamo Yang wrote:
On Tue, Sep 8, 2015 at 12:54 PM, Simon Fels
wrote:
On 07.09.2015 17:21, Oliver Grawert wrote:
Am Montag, den 07.09.2015, 14:57 +0100 schrieb John McAleely:
Are these the two options we have? What pros and cons are there for
each?
do you actually know (did anyone test) if hybris would get along with
running in 32bit on the ubuntu side while the container is 64bit ? i
suspect there needs to be some syscall translation between the two
hybris sides ...
I doubt that will work. At least not for libGLES, libEGL, .. as they don't
use proper length-defined types like uint16_t. Also from what I've seen we
can't promise which HAL libraries we get in 32 / 64 bit and which only in
32 bit and which only in 64 bit. The Android CDT defines a small subset of
Android libraries which must be available in both variants but that isn't
enough for our purpose. Also I am not entirely sure if the HAL API is
reliable in terms of well defined types.
Most of the Android BSP libraries has both 32 and 64 bit builds on aarch64
if LOCAL_32_BIT_ONLY is not specified. libmediaplayerservice [1] is one of
the exceptions. HAL modules usually come with both versions, too. But
sometimes there is no 32 bit NFC module, and sometimes no 64 bit bluetooth
and camera modules. libGLES, libEGL and all the libs that are required by
app_process{32,64} must have both 32 and 64 bit versions because you need
app_process32 to exist in 64 bit android to launch 32 bit apps.
My point was just that we can rely on anything other than what the CDD
defines. If we have a 64 bit only -> ubuntu lib -> 32 bit app dependency
somewhere in our system than we need to rework that on our side. However
this might end up very complex if we have to deal with multiple devices
where one has a 32 bit NFC HAL module where the other one has a 64 bit one.
For the bluetooth HAL it looks like this comes down to problems with
Bluedroid which in turn requires the the whole JNI layer to be 32 bit
only [1]. We need to identify all those flows in our system and see
where we end up with problems.
regards,
Simon
[1]:
https://android.googlesource.com/platform/packages/apps/Bluetooth/+/master/jni/Android.mk
--
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] Using 64bit Android BSPs with Ubuntu
On 08.09.2015 09:14, Vicamo Yang wrote:
On Tue, Sep 8, 2015 at 12:54 PM, Simon Fels
wrote:
On 07.09.2015 17:21, Oliver Grawert wrote:
Am Montag, den 07.09.2015, 14:57 +0100 schrieb John McAleely:
Are these the two options we have? What pros and cons are there for
each?
do you actually know (did anyone test) if hybris would get along with
running in 32bit on the ubuntu side while the container is 64bit ? i
suspect there needs to be some syscall translation between the two
hybris sides ...
I doubt that will work. At least not for libGLES, libEGL, .. as they don't
use proper length-defined types like uint16_t. Also from what I've seen we
can't promise which HAL libraries we get in 32 / 64 bit and which only in
32 bit and which only in 64 bit. The Android CDT defines a small subset of
Android libraries which must be available in both variants but that isn't
enough for our purpose. Also I am not entirely sure if the HAL API is
reliable in terms of well defined types.
Most of the Android BSP libraries has both 32 and 64 bit builds on aarch64
if LOCAL_32_BIT_ONLY is not specified. libmediaplayerservice [1] is one of
the exceptions. HAL modules usually come with both versions, too. But
sometimes there is no 32 bit NFC module, and sometimes no 64 bit bluetooth
and camera modules. libGLES, libEGL and all the libs that are required by
app_process{32,64} must have both 32 and 64 bit versions because you need
app_process32 to exist in 64 bit android to launch 32 bit apps.
I just did a quick check on this. As libmediaplayerservice is 32 bit
only we would end up with a 32 bit only unity8 and media-hub-server in
our system as both seem to use the library.
regards,
Simon
--
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help : https://help.launchpad.net/ListHelp
[Ubuntu-phone] Phase 1 of landing BlueZ 5.x has started
Hey everyone, as some might know we're currently in the transition period to BlueZ 5.x on Ubuntu Touch. Until now we're still using version 4.101 which dates back to 2012. BlueZ 5 is a rework of the former version with a changed DBus API and a lot of improvements/refactorings across the whole stack. Overall this will bring us a more stable and reliable bluetooth stack and also some new features like Low Energy support. The reason why we never did the switch until now (desktop waited for us a long time but did the switch finally with wily) was that we have pretty dated kernels on all our supported Touch devices (mako 3.4, flo 3.4, krillin 3.4, arale 3.10). Those ship with an older variant of the kernel side bluetooth stack which lacks features, bug fixes, improvements, etc. Upstream says we should use at least 3.13. We tried different approaches but now found a way which works for all devices the same way with just a minimal amount of work. Basically we will use the kernel backports project (see [1]) to bring a newer version of the kernel side bluetooth stack in. With this we just have one patch we apply to all our kernel trees plus some small tree specific changes and get all features and bug fixes from a latest kernel release which is 4.2 at the moment. However this was just the first step of the journey to BlueZ 5. The next step is to update all userland components which is what we work on at the moment. To get some first feedback of the kernel side work we uploaded new kernels for the Nexus 4 (mako) and Nexus 7 2013 (flo) which includes the new kernel side bluetooth stack. They should come to your devices if you're using the rc-proposed channels. Basically there should be no regressions as BlueZ 4.x still works with the newer stack too. However if you discover anything which looks like a regression or see any crashes on the kernel please don't hesitate to report those! If someone is interested in the kernel patches, you will find them on [2] for mako and [3] for flo. As soon as there is a silo ready to be tested with the userland rework I will send another update this way. regards, Simon [1]: https://backports.wiki.kernel.org/index.php/Main_Page [2]: http://kernel.ubuntu.com/git/ubuntu/ubuntu-vivid.git/log/?h=mako [3]: http://kernel.ubuntu.com/git/ubuntu/ubuntu-vivid.git/log/?h=flo -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] Using 64bit Android BSPs with Ubuntu
On 14.09.2015 13:12, John McAleely wrote: I like the sound of multiarch for two reasons: - It trivially guarantees compatibility for all the apps in the store today - It allows us to make use of 64 bit whenever it is useful If we forgo the second advantage, we could just boot the kernel & android container in 64 bit, and continue booting Ubuntu as a 32bit system. I've documented this in a diagram here: https://wiki.ubuntu.com/Touch/ContainerArchitecture in the section: "mixed-containers, 32bit Ubuntu, 64bit Android". It seems this would enable us to start using 64bit Android BSPs as a device specific feature of the device tarball, and then we can migrate Ubuntu to 64bit or multiarch at a time of our own choosing (ie, we're not dictated to by the availability of android BSPs). Unless there's any reason this scheme shouldn't work, I would like to propose it as the initial way we use 64bit android BSPs. That is fine for me. However as soon as we can't provide something we have to load through hybris and don't provide as a binder-accessible service on the container side we need a 64-bit version of libhybris and also 64 bit versions of those services on the Ubuntu side which are using those bits. Small example (not very likely to happen but to highlight what we might end up with): Android has a HAL lights module which is loaded by our powerd through libhybris. Means once the lights module is only available as 64 bit only (we only get a binary from the vendor, ...) we have to load it as 64 bit through hybris into powerd which brings us to the multiarch system with a 64 bit powerd. I am not sure if we have those intersection points with the Android container documented but if not we should really do that to have an better overview for further decisions and possible requirements we put out for compatible Android BSPs. regards, Simon -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] Using 64bit Android BSPs with Ubuntu
On 14.09.2015 14:26, Alfonso Sanchez-Beato wrote: On Mon, Sep 14, 2015 at 1:55 PM, Simon Fels wrote: On 14.09.2015 13:12, John McAleely wrote: I like the sound of multiarch for two reasons: - It trivially guarantees compatibility for all the apps in the store today - It allows us to make use of 64 bit whenever it is useful If we forgo the second advantage, we could just boot the kernel & android container in 64 bit, and continue booting Ubuntu as a 32bit system. I've documented this in a diagram here: https://wiki.ubuntu.com/Touch/ContainerArchitecture in the section: "mixed-containers, 32bit Ubuntu, 64bit Android". It seems this would enable us to start using 64bit Android BSPs as a device specific feature of the device tarball, and then we can migrate Ubuntu to 64bit or multiarch at a time of our own choosing (ie, we're not dictated to by the availability of android BSPs). Unless there's any reason this scheme shouldn't work, I would like to propose it as the initial way we use 64bit android BSPs. That is fine for me. However as soon as we can't provide something we have to load through hybris and don't provide as a binder-accessible service on the container side we need a 64-bit version of libhybris and also 64 bit versions of those services on the Ubuntu side which are using those bits. Small example (not very likely to happen but to highlight what we might end up with): Android has a HAL lights module which is loaded by our powerd through libhybris. Means once the lights module is only available as 64 bit only (we only get a binary from the vendor, ...) we have to load it as 64 bit through hybris into powerd which brings us to the multiarch system with a 64 bit powerd. One option we have in case we are very unlucky and one end *really* needs to be 64 bits and the other end *really* needs to be 32 bits is to have a daemon that would act as a proxy and that would communicate via DBus or other IPC with the Ubuntu end (and would link with libhybris). Yeah, that would be really what we have to do then. In fact most of the libhybris users are system daemons that use DBus as communication mean, so we could install a 64 bit version of, say, powerd, without affecting the rest of the system. The only downside of this would be that we then have to build multiple ubuntu rootfs images rather than just one we can share on all devices and also have to double our QA efforts (which we would have to do anyway as soon as we have a 32bit-only and a 64bit-only image). It might be better to cut those dependencies via an IPC mechanism already on the container border so that the Ubuntu system isn't affected by this at all and we can either provide a pure 32bit or 64bit image (leaving app support aside). regards, Simon -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] App working in background
On 30.08.2015 20:21, Gran PC wrote: media-hub wouldn't work for Spotify because that'd require them to put a non-encrypted version of the music somewhere on the disk. There's a third-party Spotify app on the store right now called CuteSpotify which demonstrates the issue nicely. That isn't true. media-hub doesn't require you to route the audio to it. It abstracts things internally pretty nicely so you could extend it to provide a new internal engine type which allows you to write external engines which then get commands passed in to play/stop/next/... music. This can be loaded from the UI with the general playback API we have from the Qt side but just each song has a URL starting with spotify:// or what ever your engine wants to play. I know several people were talking about this just someone has to start working on this to get it implemented. However it sounds easy but there are also some details to sort out like how we get the played audio to pulseaudio in a secure way (passing a socket)? regards, Simon -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] App working in background
On 23.09.2015 17:44, Gran PC wrote: But third-party apps can't actually extend media-hub, right? As I understand it, this is something that would need to be distributed with the OS. No. It would be just another executable your click package would ship and would be exposed to media-hub at runtime by .json file in a common directory (generated through a click-hook). This .json file then knows the combination of url scheme (e.g spotify://) to excutable name (below your app directory) and that is what media-hub needs to know - no hard dependency, no distribution in the core OS. This is similar to how we handle helpers for the Ubuntu Push client side implementation (see https://developer.ubuntu.com/en/start/platform/guides/push-notifications-client-guide/). For sure, there need to be some guards set around this executable in terms of security (our apparmor profiles) and also resource usage. regards, Simon -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] App working in background
On 23.09.2015 18:42, Gran PC wrote: That's a pretty cool approach! Has anyone started working on it? As far as I know no one did. I was interested in doing that but didn't had any spare free time yet. regards, Simon -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] Stuck during apt-get upgrade
On 24.09.2015 07:46, Steve Langasek wrote: On Thu, Sep 24, 2015 at 08:12:22AM +1000, Michi Henning wrote: I'm seeing this on Vivid plus overlay on my desktop as well as on my Nexus 4 when using citrain device-upgrade. Are you sure you're seeing the same issue on a Nexus 4? The ps output shows systemd-specific tools being invoked. This should not ever happen on a Nexus 4, where the init system is still upstart. During package installation, the bluez install hangs. Looking at the processes, I see 28628 pts/1S+ 0:00 sudo apt-get upgrade 28629 pts/1S+29:25 apt-get upgrade 36342 pts/20 Ss+0:00 /usr/bin/dpkg --status-fd 66 --unpack --auto-deconfigure /var/cache/apt/archives/bluez_4.101 36348 pts/20 S+ 0:00 /bin/sh /var/lib/dpkg/info/bluez.prerm upgrade 4.101+15.04.20150914.2-0ubuntu1 36351 pts/20 S+ 0:00 /bin/sh /usr/sbin/invoke-rc.d bluetooth stop 36392 pts/20 S+ 0:00 systemctl stop bluetooth.service 36393 pts/20 S+ 0:00 /bin/systemd-tty-ask-password-agent --watch 36394 pts/20 Sl+0:00 /usr/bin/pkttyagent --notify-fd 5 --fallback Can anyone suggest a fix/work-around? I can point you to bugs describing this issue: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1456789 https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1489630 The reason for this isn't clear yet however I modified the citrain utility to do an device upgrade without service restart and then directly reboot the device recently. See https://code.launchpad.net/~morphis/phablet-tools/citrain-changes This should let the upgrade run through. Not sure when ogra has time to land that change. regards, Simon -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] Stuck during apt-get upgrade
On 24.09.2015 20:34, Robert Park wrote: On Wed, Sep 23, 2015 at 11:56 PM, Simon Fels wrote: The reason for this isn't clear yet however I modified the citrain utility to do an device upgrade without service restart and then directly reboot the device recently. See https://code.launchpad.net/~morphis/phablet-tools/citrain-changes This should let the upgrade run through. Not sure when ogra has time to land that change. Is there a reason you're waiting for ogra? As the author of citrain tool I might be more appropriate to work on that, but I'm reluctant to release this change if it's causing this issue. Also I'd like to consult other users of citrain tool (QA people mostly) to make sure this change doesn't break anything for them. CC'd Jibel for input on how this MP impacts QA's use of citrain tool. I think the reason was that you were on holiday and ogra said he has access to that ppa so could dput the new package in there after merging the open branches in. Lets catchup on this on IRC to get things going. regards, Simon -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] SIM toolkit on UT product team decision
On 01.10.2015 14:22, Pat McGowan wrote: On Thu, Oct 1, 2015 at 4:36 AM, sturmflut wrote: Good morning dear list, I agree that SIM Tookit support is crucial for many countries. As far as I know, ofono has a D-Bus API for it and the functionality is very simple, so we might "just" have to build a simple, unconfined core app that talks to ofono? Yes one could do that. The app would only get notifications if it was active but many menu functions could be implemented which could satisfy most of the use cases. https://github.com/rilmodem/ofono/blob/master/doc/stk-api.txt Just one note: That the dbus API is there doesn't mean the backend for the RIL service is implement for this! I am pretty sure Alfonso or Tony can shed some light here how far this is or if it is even implemented. regards, Simon -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] The problem with "no background processing for apps"
On 02.10.2015 09:36, Alberto Mardegan wrote: On 02.10.2015 10:29, Yann wrote: If I can add my insight ... I think some applications (not all) should be able to run on background like Facebook for example ... everybody has Facebook Messenger on other platforms, and they write messages only through this program. The problem is that we don't have any Facebook notification (or at least i don't, and yet i have activated the FB notifications in settings), and as long as we don't check the webpage, we don't know. Maybe there is a way to have notifications only for private messages ?? I think that for this case, as well as the Dekko example mentioned at the beginning of the thread, are not good use cases for asking apps to be able to run in the background. The reason is that I want to get e-mail and Facebook notifications regardless of whether the respective application is running or not. So, at least for these cases some kind of system service must be used. Maybe we don't have it right now, but that's the way to go IMHO. I still believe that background processing is something we'll have to allow in some cases (especially for navigation apps), but I'm also against allowing any app to continue running in the background. I totally agree with that. Just running the full app all the time doesn't make any sense. When a app needs to run something while it's not visible there is always a specific thing it wants to do any those bits are what we need to abstract in some way so that the system still has this under control and can limit those bits to only run when the system is in a good state. For example think about the case where we're really short in battery and don't want anything power intensive to run. If we would just allow any app to run in background and do anything it wants we don't get enough time to get to the next power outlet. For such cases the system needs to limit what runs and what doesn't. For your example above we already have one abstraction layer: account-polld. It already polls some of your accounts for new messages and presents those as notifications. The control over this, when a poll should be run and how long is still up to the system. Some time ago I started experimenting with adding support for external pollers in account-polld which would enable every app to put in a poller for its accounts. For this is just an experiment and nothing which will land anywhere anytime but I think those bits are what we need to get out of "no background process for apps". Similar case is spotify support which was already discussed in another thread where a similar solution would apply to extend media-hub to allow external players which a spotify app would then implement one for. Btw. for messaging we have the upcoming messaging-framework to solve this problem ... regards, Simon -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] Bluetooth and browser bugs
On 02.10.2015 12:54, Niklas Wenzel wrote: Hi! Am Freitag, 2. Oktober 2015 schrieb Bry Wilson : Hi, Apologies for posting to the list for this but had noticed two bugs I wanted to report was unsure where to on Launchpad - so some pointers would be wonderful! launchpad.net/webbrowser-app would be the way to go here. ;) I'm on a Nexus 4, currently running Ubuntu 15.04 r328. Which channel are you using? I'm on rc-proposed (mako) and the current image number is around 120. Have you tried the stable channel? Oh, and just to inform you: I found your email while looking through my spam folder today ... Can you also please follow https://wiki.ubuntu.com/DebuggingBluetooth while reproducing the bluetooth problems and send me the logs or attach them to a new bug report? That would be really helpful to analyse what is going wrong here! regards, Simon -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
[Ubuntu-phone] Defining the form factor of an Ubuntu Touch device
Hey everyone, while currently working on heading towards BlueZ 5.x in Ubuntu Touch I came to the point where we need to expose what type of device we are running on. When you start discovering other Bluetooth devices you always get the so call "Class of Device" back which describes what kind of device you've found (pc, smartphone, tablet, printer, ...) with some further details. You can find more details about this in [1]. Until now we always say we're a "smartphone" which isn't really what we should do when we're starting to support other form factors like tablets. There are multiple ways to configure BlueZ which class of device to use but we will determine that at runtime. For PCs there is already the DMI interface to check which type of device we're running on. Something similar isn't available for our Touch devices and also the Android side doesn't expose anything valuable. This kind of information is really something we need to include in the device tarball and for this there are multiple ways. We can either add a new property which exposes the form factor we're running on or add another static file in some other location we can check at runtime. This new information bit will then be read by BlueZ and runtime and the class of device will be set accordingly. Know I need your help to find the best place for this kind of information. My current preferred place is a new property which is exposed from the Android property system. Each target device then has to make sure this new property is correctly configured and included in the device tarball or we will fallback to a proper default value. Any objections? Is there a better place? Do we already have this form factor information somewhere but I just missed it? regards, Simon [1]: https://www.bluetooth.org/en-us/specification/assigned-numbers/baseband -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] Defining the form factor of an Ubuntu Touch device
On 08.10.2015 12:16, Michał Sawicz wrote: W dniu 08.10.2015 o 11:54, Michael Zanetti pisze: Not sure if the Android layer is really the place to go. What happens when we run on an x86 based tablet which doesn't have the Android bits? Will that always have the DMI interface instead? x86 based tablets should have the DMI interface. I agree, we need to plan for not having Android around. IMO we should have a device file shipped, as you said, in the device tarball, that configures the device. The user should be able to easily override things stored there (for development purposes or other). Sounds good and it looks like we already have a file for this: $ cat /etc/ubuntu-touch-session.d/android.conf GRID_UNIT_PX=17 QTWEBKIT_DPR=2.0 So what about just extending this one which comes either from the device tarball (krillin, arale) or from the ubuntu-touch-session package (flo, mako)? Priority should be: - user override - device tarball - auto-detected fallback Sure. Where a user override exists then this one should be applied first. In the case of the Bluetooth device class the user doesn't have any control over this. regards, Simon -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] Defining the form factor of an Ubuntu Touch device
On 08.10.2015 13:34, Michał Sawicz wrote: W dniu 08.10.2015 o 12:48, Simon Fels pisze: On 08.10.2015 12:16, Michał Sawicz wrote: W dniu 08.10.2015 o 11:54, Michael Zanetti pisze: Not sure if the Android layer is really the place to go. What happens when we run on an x86 based tablet which doesn't have the Android bits? Will that always have the DMI interface instead? x86 based tablets should have the DMI interface. I agree, we need to plan for not having Android around. IMO we should have a device file shipped, as you said, in the device tarball, that configures the device. The user should be able to easily override things stored there (for development purposes or other). Sounds good and it looks like we already have a file for this: $ cat /etc/ubuntu-touch-session.d/android.conf GRID_UNIT_PX=17 QTWEBKIT_DPR=2.0 So what about just extending this one which comes either from the device tarball (krillin, arale) or from the ubuntu-touch-session package (flo, mako)? Longer-term I think we should go away from putting it all in environment (which is where they end up with) and use a richer file format (.ini, .json, .yaml seems to be a choice often these days). Until then, I'm fine with putting it there. Priority should be: - user override - device tarball - auto-detected fallback Sure. Where a user override exists then this one should be applied first. In the case of the Bluetooth device class the user doesn't have any control over this. Is there a reason why we would disallow overriding this? We'll have devices that can't easily be categorized as one (I mean, is a 10" tablet with GSM a phone or a tablet?). A tablet stays a tablet. Having a modem included doesn't make it a phone. The Bluetooth device class is meant to stay static for one device forever. No dynamic changes. It is your first point to find out what kind of Bluetooth device you've found. Btw. that a tablet includes a GSM modem still doesn't say anything about if it also allows you to do voice calls ... If we have a "phablet" device then this needs to be categorized as a phone as it provides voice call capabilities. See https://www.bluetooth.org/en-us/specification/assigned-numbers/baseband for some more details on the major and minor device classes we're talking about here. Putting the device into the right major/minor class is crucial as some car kits doesn't allow you to pair them only with devices part of the phone device class... Also what would be the benefit of having an option for the user to override this? regards, Simon -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] Defining the form factor of an Ubuntu Touch device
On 08.10.2015 13:49, Oliver Grawert wrote: hi, Am Donnerstag, den 08.10.2015, 12:48 +0200 schrieb Simon Fels: So what about just extending this one which comes either from the device tarball (krillin, arale) or from the ubuntu-touch-session package (flo, mako)? if anyone works on this, it would be nice to unify this (i.e. make flo and mako also ship the right file in their device tarball and actually remove the files from the package)... that was a long standing low prio TODO of the former phablet team (together with wiping everything but PATH from /etc/environemt as it should be). Sounds good. What is with all the other files for community ported devices? We just break them? regards, Simon -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] Defining the form factor of an Ubuntu Touch device
On 08.10.2015 14:30, Michał Sawicz wrote: W dniu 08.10.2015 o 14:00, Simon Fels pisze: A tablet stays a tablet. Having a modem included doesn't make it a phone. The Bluetooth device class is meant to stay static for one device forever. No dynamic changes. It is your first point to find out what kind of Bluetooth device you've found. Btw. that a tablet includes a GSM modem still doesn't say anything about if it also allows you to do voice calls ... If we have a "phablet" device then this needs to be categorized as a phone as it provides voice call capabilities. See https://www.bluetooth.org/en-us/specification/assigned-numbers/baseband for some more details on the major and minor device classes we're talking about here. Putting the device into the right major/minor class is crucial as some car kits doesn't allow you to pair them only with devices part of the phone device class... Also what would be the benefit of having an option for the user to override this? I think you just wrote what would be the benefit - some car kits only connect to phone devices. What if I wanted my 3G tablet (no voice, but VoIP still works!) to connect to the car? That would a use case, yes, but still really a workaround for a corner case. However that wouldn't work with our implementation playing the role of the audio gateway strictly requires a modem with voice call capabilities.. no way to inject your VoIP stack here. It also hardly depends on how the hardware is build. For HFP on most Android devices the audio is directly routed from the microphone to the BT chip without involving the CPU so we can gurantee you're even able to inject your VoIP audio data. regards, Simon -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] Defining the form factor of an Ubuntu Touch device
On 08.10.2015 15:03, Michał Sawicz wrote: W dniu 08.10.2015 o 14:57, Simon Fels pisze: That would a use case, yes, but still really a workaround for a corner case. However that wouldn't work with our implementation playing the role of the audio gateway strictly requires a modem with voice call capabilities.. no way to inject your VoIP stack here. It also hardly depends on how the hardware is build. For HFP on most Android devices the audio is directly routed from the microphone to the BT chip without involving the CPU so we can gurantee you're even able to inject your VoIP audio data. You mean you can't use Skype with a BT headset? Sounds like we'll get flack over that. That depends. We're bound to the audio routing capabilities we get with the Android HAL implementation. Also lets differentiate HFP and HSP here. The HFP implementation is meant for voice call capabilities with a modem and that is how we deal with it at the moment. The other thing is HSP which is just meant for headsets without voice call control capabilities. With HSP we should be able to set things up that you can use it for Skype or whatever VoIP system you want. However we still need to figure how that is possible with the Android audio HAL. My only point is this: since I believe we should have a generic mechanism for reading the per-device and user-overridable bits of that file, I see no reason for implementing special exceptions for this use case to *prevent* the user changing it. We will only read whatever file this has in only once for Bluetooth on start and then take with what we were configured for. If that changes across restarts of the service then it does. However I still see only corner cases where this is required to be adjusted by the user for Bluetooth. It should for sure be nothing which is changeable in the settings app for a normal user as he wouldn’t really know what he is dealing with .. regards, Simon -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] Defining the form factor of an Ubuntu Touch device
On 08.10.2015 15:08, Michael Zanetti wrote: On 08.10.2015 14:57, Simon Fels wrote: On 08.10.2015 14:30, Michał Sawicz wrote: W dniu 08.10.2015 o 14:00, Simon Fels pisze: A tablet stays a tablet. Having a modem included doesn't make it a phone. The Bluetooth device class is meant to stay static for one device forever. No dynamic changes. It is your first point to find out what kind of Bluetooth device you've found. Btw. that a tablet includes a GSM modem still doesn't say anything about if it also allows you to do voice calls ... If we have a "phablet" device then this needs to be categorized as a phone as it provides voice call capabilities. See https://www.bluetooth.org/en-us/specification/assigned-numbers/baseband for some more details on the major and minor device classes we're talking about here. Putting the device into the right major/minor class is crucial as some car kits doesn't allow you to pair them only with devices part of the phone device class... Also what would be the benefit of having an option for the user to override this? I think you just wrote what would be the benefit - some car kits only connect to phone devices. What if I wanted my 3G tablet (no voice, but VoIP still works!) to connect to the car? That would a use case, yes, but still really a workaround for a corner case. However that wouldn't work with our implementation playing the role of the audio gateway strictly requires a modem with voice call capabilities.. no way to inject your VoIP stack here. It also hardly depends on how the hardware is build. For HFP on most Android devices the audio is directly routed from the microphone to the BT chip without involving the CPU so we can gurantee you're even able to inject your VoIP audio data. Hmm... wouldn't be so sure about that.. Yes, HFP's control channel is based on AT commands, and it's also correct that most hardware wires the sound chip with the Bluetooth chip directly, still, every Bluetooth chip I came across so far allowed routing audio data through the HCI. AFAIK, bypassing the HCI is the optional case here. I did see dummy AT command layers injecting VoIP into HFP before... On Android devices that is the regular case. The audio data is passed to the BT chip over a PCM line rather than through HCI. That still doesn't say it's not possible to do it but that is a way nobody tested yet and proved it works. In our current setup we're using the PCM line approach which also saves us from burning CPU cycles on this rather than letting the BT chip which is optimised for this doing that. The next bigger point is how HFP is currently implemented. With the shift to BlueZ 5 the implementation moved into ofono as that is the natural place where you want to do AT command processing. The current implementation expects a voice call capable modem to be present before we even even allow the HFP AG profile to be connected. As there can be only one provider in the system for a profile we would have to integrate what VoIP solution we want to use over HFP into ofono to let it expose a modem which we can use as control interface ... However that doesn't say that we can add another provider for the HFP profile which becomes active in scenarios where we don't have a GSM modem but then has to implement the whole profile support on its own with the point of proper audio routing still being sorted. regards, Simon -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] Defining the form factor of an Ubuntu Touch device
On 08.10.2015 16:32, Pat McGowan wrote: What does this mean in the converged world where a phone is also a desktop? That a phone still stays a phone. In the bluetooth world that doesn't change anything. The device class is just a way to tell other bluetooth devices which capabilities we have to they can adjust their discovery to just look for audio devices for examples and leave out all others. It's something bound to the hardware rather than to what we're doing in software. regards, Simon -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] Hardware required to use Ubuntu phone as desktop
On 10.10.2015 13:02, Simos Xenitellis wrote: On Sat, Oct 10, 2015 at 1:22 PM, Ionut Negru wrote: Hello, I wonder if there is anyone that has tried to use the phone with external keyboard, mouse and display all together. Is mhl support working yet? What accessories did you use? I run ubuntu on mx4. Thanks! There was a recent discussion about MHL support. Meizu does not explicitly mention MHL support for the MX4 (not the MX4 Pro) on Android. Some people asked at http://forum.meizu.com/viewthread.php?tid=17450 with no reply. What is not conclusive, is whether the MX4 has the full hardware set of parts to support MHL. The SoC for the MX4 (MediaTek) supports MHL, however the phone needs an extra chip that will work with the SoC for MHL. It is not clear if it is there. If you see http://www.siliconimage.com/Company/News_and_Events/Press_Releases/2014_02_23_-_Silicon_Image_Announces_New_MHL%C2%AE_Smartphone_Reference_Designs_with_MediaTek/ it mentions (that's how I interpret it) that a device needs to also have the SiI8348 MHL transmitter chip to work with the SoC. We either get the Meizu tech people to make a statement, or we find some high resolution images of the MX4 board and then try to identify whether the MHL support chip is present on the board. Regarding keyboard and mouse: there will be an update in the Bluetooth software to BlueZ 5.0 (currently BlueZ 4.0) which will probably allow to use Bluetooth peripherals. Some Bluetooth devices might work already, however the update to BlueZ 5 will be substantial. Bluetooth keyboard and mouse already work with the BlueZ 4.x stack we have on the devices. Just pair and connect one and you will be able to use. However there is a bug on krillin currently which breaks support for those HID devices. This will be fixed hopefully with ota8. On all other devices (arale, mako, flo) BT HID devices are fully working. If specific ones are not please file a bug against the bluez package. regards, Simon -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] Music App suggest | question
On 23.10.2015 12:15, Andrew Hayzen wrote: Hey, Currently the next and previous buttons do not function as we have not landed this support yet. We are currently working [0] with upstream (media-hub and indicator-sound) to complete the remaining issues, which will then allow for the platform to implement support for things such as bluetooth media controls. This will hopefully be implemented in the short to medium future. This is already working in rc-proposed with the upcoming switch to BlueZ 5. You will be able to use the MPRIS controls over bluetooth and we should support already most of the features including the first steps to also expose playlists over AVRCP. However just the basic bits (play, pause, next, previous) have been verified so far. regards, Simon -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
[Ubuntu-phone] BlueZ 5.x finally landed on Touch
Hey everyone, it finally happened: We are switching to BlueZ 5.x on our Touch images on all supported devices. To make this happen a huge amount of work through the last five months from different people was needed. Thank you all for the great work and support to make this happen! QA approved all silos now and they will be merged by the CI guards today. All device tarballs for supported devices (krillin, vegetahd, arale, mako, flo) were updated to support everything needed for BlueZ 5.x and are already available in the rc-proposed channel. This is just a first step for better Bluetooth support on Ubuntu Touch. We now have the same bluetooth stack in the kernel on all our devices which makes it a lot easier to fix bugs at the same time across all our devices. As this is a very huge and complex landing things can break. We spent a lot time to make sure this doesn't happen. However as Bluetooth is a very complex technology there can and will still be interoperability issues with devices on the market. As we're now releasing this into rc-proposed and will ship this to our users with OTA 9 it would be great if anybody running rc-proposed and experience any problems sends us bug reports. There is a guideline in the wiki at [1] which describes necessary steps to include additional information about what goes wrong in the system. Bugs can be filed against the bluez package at [2]. NOTE: There is currently a suspend issue with the new bluetooth stack in the kernel on arale. See [3] for more details. We're working actively on a fix for that. One final word: Generally having BlueZ 5.x will give us a lot more stable Bluetooth experience. What we're landing right now will not directly bring any new Bluetooth features. This is just the base for future work but opens the gate for a lot things :) regards, Simon [1]: https://wiki.ubuntu.com/DebuggingBluetooth [2]: https://bugs.launchpad.net/ubuntu/+source/bluez [3]: https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1505241 -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] BlueZ 5.x finally landed on Touch
On 21.11.2015 01:47, Robert Park wrote: On Nov 20, 2015 8:29 AM, "Simon Fels" wrote: Hey everyone, it finally happened: We are switching to BlueZ 5.x on our Touch images on all supported devices. To make this happen a huge amount of work through the last five months from different people was needed. Thank you all for the great work and support to make this happen! Wow, congrats! This is just a first step for better Bluetooth support on Ubuntu Touch. We now have the same bluetooth stack in the kernel on all our devices which makes it a lot easier to fix bugs at the same time across all our devices. Does this mean we can finally stop using an ancient kernel in the touch stack? No. And this will never happen. All kernels we have are heavily customized from what we have for Linux upstream. Porting over > 10.000 lines of code in a good quality doesn't make fun nor is it worth the work respecting that we don't have any insight through specs or manuals on the actual components used. For Bluetooth what I did was something like cp -r linux-4.2/net/bluetooth linux-/net/bluetooth For sure no as easy as this single line but you get the idea. The real thing I used for this is the Kernel backports project (see [1]). regards, Simon [1]: https://backports.wiki.kernel.org/index.php/Main_Page -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] WiFi mac address changes every reboot
Can you check if the following file is still present on your Nexus 4? phablet@ubuntu-phablet:~$ sudo ls -alh /persist/wifi/.macaddr -rw-r--r--. 1 root root 13 Jan 3 1970 /persist/wifi/.macaddr regards, Simon On 23.11.2015 14:29, Heroldich Robin wrote: Hey, As I see this is not the same bug. My WiFi mac address is the same on the About Page and with ifconfig command too. My problem is that my WiFi mac address changes with every reboot, so I need to readd my connection details every time and there will be a new connection with this name, just add a plus number to it, like: RobinH RobinH 1 RobinH 2 Robinh 3 ... etc. I'm using a Nexus 4. Date: Mon, 23 Nov 2015 08:12:49 -0500 Subject: Re: [Ubuntu-phone] WiFi mac address changes every reboot From: pat.mcgo...@canonical.com To: robinh...@outlook.hu CC: ubuntu-phone@lists.launchpad.net This sounds like https://bugs.launchpad.net/ubuntu/+source/ubuntu-system-settings/+bug/1399723 which was fixed some time ago. What device are you on and where do you get the mac address? May warrant a new bug report. Pat On Mon, Nov 23, 2015 at 4:02 AM, Heroldich Robin wrote: Hi! I'm using Ubuntu on my Nexus 4 and I've found an interesting bug. I need to connect to my WiFi network after every reboot, the reason is the mac address of WiFi changes every reboot. It works well with Android. Any idea how can I set it permanent? It's very fustrating... -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] BlueZ 5.x finally landed on Touch
On 24.11.2015 15:25, Dmytryi Fedorov wrote: It is car speakers. Everything is fine with them, Samsung Galaxy Nexus on Android works fine. But on my Meizu MX4 (r185) music stutters. But not always, ~90% of times. I must connect\reconnect about 10 times to play music normally It would be awesome if you file a bug about this. When you do so follow https://wiki.ubuntu.com/DebuggingBluetooth carefully and include all necessary log files and information requested on the wiki page in the bug report. Without further information we can't do anything. There are a lot of bluetooth devices out there which all behave differently in some regard. I could be either us or the remote side for this particular problem doing something wrong. And to be able to argue for one or the other we need more details on what is going on our side. As Michael is saying a bit further down it could be also a problem with the combo chip for BT/WiFi/GPS the MX 4 includes but that is something we need to find out first. If the problem still remains when you turn off WiFi and GPS this might be an indicator that this isn't a problem. Also which car are you talking about? regards, Simon -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] BlueZ 5.x finally landed on Touch
On 25.11.2015 12:19, Dmytryi Fedorov wrote: I will do it tomorrow when the car (Chevrolet Sonic (or Aveo T300)) will be available. On what package I need to fill this bug? Against https://bugs.launchpad.net/ubuntu/+source/bluez But please check first if there isn't a bug already which describes the same you're seeing. regards, Simon -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
[Ubuntu-phone] Ubuntu Touch Bluetooth Enablement
Hey everyone, as we introduced a backported bluetooth stack on the kernel side for all our devices and have to do that for all other ports too to make sure we're running the same stack across all of our devices I documented the basic steps to do at [1]. I've included links to two reference kernels (pure 3.4/3.10) which have the basic patchset applied we need. If you have any questions or corrections feel free to drop me a mail. regards, Simon [1]: https://wiki.ubuntu.com/Touch/BluetoothEnablement -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] Ubuntu Touch and Smart Watches
On 26.12.2015 22:28, Gareth France wrote: On 26/12/15 00:17, Michael Zanetti wrote: And will it work with my generic >watch? No. >If not is there anything that can be done to encourage two way >communication between the watch and phone? I would require writing something like Rockwork, suited for your watch model, probably something AndroidWear compatible. Why oh why don't people design these things to some sort of standard? So if this is the case is this the sort of device we are likely to see near universal support emerging for in the future? I mean I'm used to just being able to buy any device and have it work automatically without any effort (touchscreen, printer, webcam, soundcard etc). Or is there some major challenge to auto identifying smart watches and dealing with them? There is a standard which Android Wear uses: Bluetooth Smart (aka Bluetooth Low Energy). On top of that there are certain profiles specified (see [1]) which all use GATT as base and give you all the features you want. Its pebble who did something different here as it sounds to me (never really looked into this). Support for BLE will land with ota9 and from what I've heard we will also make it available through our Qt APIs we expose in the SDK. regards, Simon [1]: https://developer.bluetooth.org/gatt/Pages/GATT-Specification-Documents.aspx -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] RC Proposed Bluetooth
On 04.01.2016 20:10, Daniel Wood wrote: I've been having issues with bluetooth on a nexus 7 running RC proposed. I have filed a bug here: https://bugs.launchpad.net/canonical-devices-system-image/+bug/1530807 Can anyone advice if bluetooth connectivity is logged anywhere or if there is any furthur information I can provide? Would be awesome if you can follow https://wiki.ubuntu.com/DebuggingBluetooth and add the requested details to the bug. regards, Simon -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] RC Proposed Bluetooth
On 05.01.2016 19:43, Randall Ross wrote: On 01/04/2016 09:58 PM, Simon Fels wrote: On 04.01.2016 20:10, Daniel Wood wrote: I've been having issues with bluetooth on a nexus 7 running RC proposed. I have filed a bug here: https://bugs.launchpad.net/canonical-devices-system-image/+bug/1530807 Can anyone advice if bluetooth connectivity is logged anywhere or if there is any furthur information I can provide? Would be awesome if you can follow https://wiki.ubuntu.com/DebuggingBluetooth and add the requested details to the bug. regards, Simon Hi Simon, is there any way the scripts on that page could be added to Checkbox? I attached my Checkbox results to the bug yesterday, but noticed that the "Logs" tab in the spreadsheet that is generated by Checkbox is blank. I am not really sure what checkbox does, but if its something to automate those steps for users, that is absolutely something which can be added. Feel free to ping me for details. regards, Simon -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] Miracast - WiFi Displays
On 28.02.2016 19:32, Marco Graziotti wrote: > Hi Robin, > > I'm interested in "aethercast" because my MX4 don't support wired > connection. > Can you indicate the correct procedure to install and try aethercast? We already have code in place which does proper display streaming but this is currently working only on one particular device: The upcoming Meizu MX Pro 5. The reason for this is just that we used specific API functions which are available just on Android 5.x and therefore not on devices based based on Android 4.x like the MX4. However this doesn't mean that Miracast wont work on that device and that wont add support for it. It just requires us to rework the encoding side in aethercast a bit so that it supports multiple Android versions. Work for this is currently in progress. Currently if you follow the instructions on [1] you wont get anything working on any other device than the Meizu MX Pro 5. There is quite a lot of work going on and we will for sure state in the public when this is ready for test on other devices. Sorry that you can't test this yet but we're working quite hard to make that possible. regards, Simon [1]: https://wiki.ubuntu.com/Touch/DisplayCasting -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] Miracast - WiFi Displays
On 29.02.2016 09:57, Heroldich Robin wrote: > Thanks everybody for your answers. > > Maybe a stupid question. But why don't you rebase all phones to Android 5.x? > Is it possible? Possible is everything but time and business wise that doesn't make sense and would just open the gate for a lot more bugs. In the end its just a BSP package we got from a vendor. regard, Simon -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] Miracast - WiFi Displays
> Does this mean that DisplayCast will be available soon for krillin and > vegeta?.If this specific API works for Android devices based on 5.x, > krillin and vegeta are right now on Android 5.0, could be this API used > for them too?. Its just API functionality we use to make things easier and get a first working implementation faster. Android 4.x supports all we need and we just have to adopt our implementation to do the encoding in a more common way. For which actual devices we will enable Miracast by default still depends on different things. If the performance will be worse on a particular device it doesn't make sense to enable Miracast support on that device by default. However all software components will be there so you could always then enable it on your own. That said and with keeping in mind that we have things running only on __one__ device so far don't take this as a comment to judge on support for any other device. Time will tell. regards, Simon -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] Bluetooth transmitter as headset instead of other type
On 14.03.2016 12:36, Krzysztof Tataradziński wrote: > In /var/lib/bluetooth I can see one folder with some MAC address (maybe) > 38:BC:1A:..., but it's empty (but I cannot go inside; clicking on it (in file > manager) does do nothing). You need to be root to do that. For other users than root those things (as they contain the security keys used from encrypted connections) are not accessible. Only way is through the command line. Also, you should not start to manipulate those files manually. That will only lead to problems. regards, Simon -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] Bluetooth transmitter as headset instead of other type
On 13.03.2016 14:29, Krzysztof Tataradziński wrote: > Hello, > I've got two bluetooth devices I'm using with my phone: > (1) headphones with mic (I think that is called headset in english) > (2) Bluetooth transmitter with mic also. > > (1) is recognized in Ubuntu System Settings, bluetooth part as "Other Audio" > - I > can listen to music and call to someone using that build-in mic. Everything > seems to work fine ;) > (2) is recognized in USS as "Headset" - I can listen to music, but I can't > talk > with that. When I call to someone, phone use its mic and speaker (it should > use > transmitter mic like in device (1)); in call screen I don't have option to > change into bluetooth one. (2) is actually a bug we're working on. See [1] for example. regards, Simon [1]: https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1494225 -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] File synch - could we get owncloud-client-cmd added to standard image?
On 04.04.2016 11:48, Filip Dorosz wrote: > How do you get around dependcies? > > owncloud-client-cmd depens on some libs that are not installed. Either by building a static binary which includes all necessary libraries or a wrapper script which adjusts LD_LIBRARY_PATH to include a path where you put all additional libs to. regards, Simon -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] MX4 and Miracast, something new?
On 12.04.2016 14:31, Marco Graziotti wrote: > So, you think it's possible to developing the Miracast support for Meizu MX4? It is possible for sure. The actual part we're talking about here is the hardware encoding we're reusing from Android. Android 5.x introduced a small layer around the actual hardware encoder we're using for a small and simple implementation. Backporting those bits to Android 4.x is possible but requires some work. The most important thing about this is that the Android side source code for the MX4 is private and not available to the public. So if someone from the community wants to start helping out here we need to do this on one of the devices supported by the phablet Android source tree (see [1]). The actual bits we need is the MediaCodecSource class (see [2]). We're using this one through libhybris and then in aethercast to encode frames we're receiving from mir. This class is not available in Android 4.x (yet). There are other options to work around this or work more closely with the MediaCodec class (which we're already using for video encoding through libhybris). But none of those was investigated yet. If someone wants to help us, backporting the MediaCodecSource to an Android 4.x tree is the first step. This can be done without targetting the MX4 as we can port things easily across different Android 4.x trees once we have a working version. You can have a look at [3] to see how you can build the Android 4.x tree for the Nexus 4. regards, Simon [1]: https://code-review.phablet.ubuntu.com/#/admin/projects/ [2]: http://androidxref.com/5.1.1_r6/xref/frameworks/av/media/libstagefright/MediaCodecSource.cpp [3]: https://developer.ubuntu.com/en/start/ubuntu-for-devices/porting-new-device/ -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] draytek 5G
On 19.04.2016 09:37, Wayne Ward wrote: > Im just setting up a new draytek VigorAP AP900 > The wireless access point is running in 5G and available from all > devices apart from the ubuntu touch phone > Does the device not support that connection ? > If not i could add a 2.4G access point Which Ubuntu Touch device are you talking about? The BQ Aquaris 4.5 only supports 2.4 GHz where the Meizu MX 4 supports both 2.4 and 5 GHz. regards, Simon -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] MX4 and Miracast, something new?
On 12.04.2016 14:52, Simon Fels wrote: > On 12.04.2016 14:31, Marco Graziotti wrote: >> So, you think it's possible to developing the Miracast support for Meizu MX4? > > It is possible for sure. The actual part we're talking about here is the > hardware encoding we're reusing from Android. Android 5.x introduced a > small layer around the actual hardware encoder we're using for a small > and simple implementation. Backporting those bits to Android 4.x is > possible but requires some work. > > The most important thing about this is that the Android side source code > for the MX4 is private and not available to the public. So if someone > from the community wants to start helping out here we need to do this on > one of the devices supported by the phablet Android source tree (see [1]). > > The actual bits we need is the MediaCodecSource class (see [2]). We're > using this one through libhybris and then in aethercast to encode frames > we're receiving from mir. This class is not available in Android 4.x > (yet). There are other options to work around this or work more closely > with the MediaCodec class (which we're already using for video encoding > through libhybris). But none of those was investigated yet. > > If someone wants to help us, backporting the MediaCodecSource to an > Android 4.x tree is the first step. This can be done without targetting > the MX4 as we can port things easily across different Android 4.x trees > once we have a working version. You can have a look at [3] to see how > you can build the Android 4.x tree for the Nexus 4. For those interested: I had a quick idea some days back of how to easily backport the relevant bits on the Android side to an Android 4.x tree and did this as proof-of-concept for the Nexus 4. There are now three changes I pushed for inclusion: https://code-review.phablet.ubuntu.com/444 https://code-review.phablet.ubuntu.com/445 https://code-review.phablet.ubuntu.com/446 With those three I got WiFi Display working on the Nexus 4. However the whole thing is quite unstable and needs still a lot love to work correctly and reliable. Especially the WiFi Direct implementation seems to be really flaky which is most likely due to incompatibilities between the kernel side WiFi driver and our wpa-supplicant version. We will merge the three changes above in the near future and release a new device tarball for mako with those included. In general this doesn't change our plan that we will not put active development in adding WiFi Display as a official supported feature on Nexus 4 but it gives everyone else in the community a place to play with or port it to any other community supported device. The necessary Ubuntu side bits for WiFi Display support will land soon in rc-proposed. All you then have to do to enable WiFi Display (which is only enabled by default on selected devices): 1. Run the following command on the command line $ setprop ubuntu.widi.supported 0 NOTE: This change remains temporary and will be revert after a device reboot. 2. If you had ubuntu-system-settings running close and restart it. 3. You will now have an item "Wireless Display" under "Brightness & Display" regards, Simon -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
[Ubuntu-phone] NetworkManager and Wireless Display
Hey everyone, we've just landed a big update for NetworkManager, our central network managing component, and all bits to enable Wireless Display support in Ubuntu Touch. All of these changes will be available in an image build over the weekend and published to rc-proposed. As we had to get everything in before the string freeze there are some bugs left we will fix over the the next days: * The one major feature that's not reliable with NM 1.2 is hotspot. Debugging has shown that the issues are currently with the code in indicator-network that configures/enables hotspot. We're actively working in this and should have a fix for this soon. * VPN also has not been heavily tested, however we're also planning on uploading a newer version of the openvpn plugin next week which should bring us up to par with xenial. * Also we have a list of remaining bugs for Wireless Display support. In detail these are https://bugs.launchpad.net/aethercast/+bug/157 https://bugs.launchpad.net/aethercast/+bug/1566674 https://bugs.launchpad.net/aethercast/+bug/1576613 We're working actively on fixing them and will get them all done for the OTA 11 release. * The documentation at https://wiki.ubuntu.com/Touch/DisplayCasting about how to use Wireless Display needs updating now that everything has landed. * NOTE: Even if we have Wireless Display support now in our generic Ubuntu Touch images it will be only enabled on the Meizu MX Pro 5 aka turbo. regards, Simon -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] Wireless display
On 30.04.2016 23:14, Francisco Mulas Caracuel wrote: > Im running rc-proposed channel and not have this feature. The only supported device for Wireless Display support so far is the Meizu MX Pro 5. Even if the Ubuntu rootfs on each phone is identical we disable the option for Wireless Display in ubuntu-system-settings for devices which don't support this feature. regards, Simon -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] MX4 aethercast
On 01.06.2016 18:50, Krzysztof Tataradziński wrote: > Hello, > > I just want to sum up what we know about wireless display support. For now, > theoretically we've two options to get it working on Meizu MX4: > (1) Change Android BSP from 4.x to 5.x. > (2) Backport MediaCodecSource class (and maybe some other bits) to actual > Android BSP 4.x. > > Am I right? That is correct. I did that already for the Nexus 4 and pushed patches https://code-review.phablet.ubuntu.com/444 https://code-review.phablet.ubuntu.com/445 https://code-review.phablet.ubuntu.com/446 That enables the basic bits for the media encoding side. On the Nexus 4 the more hard thing is the getting WiFi Direct support working as the WiFi driver we have in the kernel seems to be quite busy. However to highlight the important thing: The Android side source of the MX4 is not available to the public and will not. Only people inside Canonical have access to it. We don't have any plans to enable aethercast on the MX4 and krillin by default. I've shared those patches basically for community ports based on Android 4.x. Also don't expect you're done with just importing those three patches into your tree. Depending on how the encoder is structured and performing there are more changes necessary involving debugging and insight into the whole thing. > Regarding (1) - Meizu released 5.x OS recently. I'm not a tech guy, but is it > not 'only' to grab what we need from that release and put it instead of > actual one? > Where is a problem with changing BSP to 5.x? Changing to a newer BSP requires a two to three month effort for multiple people involved. Not an easy thing and isn't really worth for Ubuntu Touch as we don't gain any new features and will only risk regressions etc. The BSP we have stabilized very much over time so there is absolutely no reason to change to a newer version of Android for the MX4. regards, Simon -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] Aethercast and MWDA v2
On 13.08.2016 22:50, Kristijan wrote: > Hi, > > Has anybody tested an Ubuntu Phone that has working Aethercast > capability with Microsoft Wireless Display Adapter V2? I only know that > devs are developing with MWDA V1. > I'm looking to buy one of those so I want to be sure that it works with > Aethercast before I make a purchase. I didn't tested it myself yet but mostly should just work. If not, please file a bug on https://bugs.launchpad.net/aethercast We've just landed a few fixes in rc-proposed which should improve the compatibility with a lot of dongles. regards, Simon -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] Aethercast and MWDA v2
On 14.08.2016 05:15, Radics Geza wrote: > Hi! > It works and the range is quite good. Awesome! regards, Simon >> Original Message >> Subject: Re: [Ubuntu-phone] Aethercast and MWDA v2 >> Local Time: August 14, 2016 5:45 AM >> UTC Time: August 13, 2016 9:45 PM >> From: simon.f...@canonical.com >> To: ubuntu-phone@lists.launchpad.net >> >> On 13.08.2016 22:50, Kristijan wrote: >> > Hi, >> > >> > Has anybody tested an Ubuntu Phone that has working Aethercast >> > capability with Microsoft Wireless Display Adapter V2? I only know that >> > devs are developing with MWDA V1. >> > I'm looking to buy one of those so I want to be sure that it works with >> > Aethercast before I make a purchase. >> >> I didn't tested it myself yet but mostly should just work. If not, >> please file a bug on https://bugs.launchpad.net/aethercast >> >> We've just landed a few fixes in rc-proposed which should improve the >> compatibility with a lot of dongles. >> >> regards, >> Simon >> >> >> -- >> Mailing list: https://launchpad.net/~ubuntu-phone >> Post to : ubuntu-phone@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~ubuntu-phone >> More help : https://help.launchpad.net/ListHelp > -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] OPEN BETA: Git support in Bileto!
This is awesome!!! Great work! On Wed, Aug 31, 2016 at 9:44 AM, Lukasz Zemczak < lukasz.zemc...@canonical.com> wrote: > Sweet! > > On 30 August 2016 at 21:45, Robert Park wrote: > > Hi all, > > > > I've just rolled experimental git support into production Bileto. This > > means it's now possible for Bileto to merge git merges for you in > > addition to the usual bzr. I know some people were wanting this for a > > long time, and some people are using git for development then export > > to bzr just to use Bileto, well those days are over! Now you can use > > your git branches natively! > > > > The support has been tested and works well in staging, but the test > > data set was somewhat small so it won't surprise me if not everything > > works perfect right out of the gate. Please do try it out and report > > issues to me ASAP and I will fix up whatever problems are found. > > > > Thanks! > > > > -- > > robru > > > > -- > > Mailing list: https://launchpad.net/~ubuntu-phone > > Post to : ubuntu-phone@lists.launchpad.net > > Unsubscribe : https://launchpad.net/~ubuntu-phone > > More help : https://help.launchpad.net/ListHelp > > > > -- > Łukasz 'sil2100' Zemczak > Foundations Team > lukasz.zemc...@canonical.com > www.canonical.com > > -- > Mailing list: https://launchpad.net/~ubuntu-phone > Post to : ubuntu-phone@lists.launchpad.net > Unsubscribe : https://launchpad.net/~ubuntu-phone > More help : https://help.launchpad.net/ListHelp > -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] OPEN BETA: Git support in Bileto!
I've just did a quick test on https://requests.ci-train.ubuntu.com/log/1889/build/latest/ which tries to build from https://code.launchpad.net/~morphis/aethercast/+git/aethercast/+merge/304460 but this directly fails with missing access rights. Any idea? regards, Simon On Wed, Aug 31, 2016 at 11:22 AM, Konrad Zapałowicz < konrad.zapalow...@canonical.com> wrote: > Awesome! > > On Wed, Aug 31, 2016 at 11:10 AM, Simon Fels > wrote: > >> This is awesome!!! Great work! >> >> On Wed, Aug 31, 2016 at 9:44 AM, Lukasz Zemczak < >> lukasz.zemc...@canonical.com> wrote: >> >>> Sweet! >>> >>> On 30 August 2016 at 21:45, Robert Park >>> wrote: >>> > Hi all, >>> > >>> > I've just rolled experimental git support into production Bileto. This >>> > means it's now possible for Bileto to merge git merges for you in >>> > addition to the usual bzr. I know some people were wanting this for a >>> > long time, and some people are using git for development then export >>> > to bzr just to use Bileto, well those days are over! Now you can use >>> > your git branches natively! >>> > >>> > The support has been tested and works well in staging, but the test >>> > data set was somewhat small so it won't surprise me if not everything >>> > works perfect right out of the gate. Please do try it out and report >>> > issues to me ASAP and I will fix up whatever problems are found. >>> > >>> > Thanks! >>> > >>> > -- >>> > robru >>> > >>> > -- >>> > Mailing list: https://launchpad.net/~ubuntu-phone >>> > Post to : ubuntu-phone@lists.launchpad.net >>> > Unsubscribe : https://launchpad.net/~ubuntu-phone >>> > More help : https://help.launchpad.net/ListHelp >>> >>> >>> >>> -- >>> Łukasz 'sil2100' Zemczak >>> Foundations Team >>> lukasz.zemc...@canonical.com >>> www.canonical.com >>> >>> -- >>> Mailing list: https://launchpad.net/~ubuntu-phone >>> Post to : ubuntu-phone@lists.launchpad.net >>> Unsubscribe : https://launchpad.net/~ubuntu-phone >>> More help : https://help.launchpad.net/ListHelp >>> >> >> >> -- >> Mailing list: https://launchpad.net/~ubuntu-phone >> Post to : ubuntu-phone@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~ubuntu-phone >> More help : https://help.launchpad.net/ListHelp >> >> > -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] Aethercast on MX4 - how users can help?
On 29.09.2016 12:34, M G wrote: > Hi list, > > how MX4 users can contribute to develop aethercast? > > I remember that there are two way to reach this goal: > > 1. Changing Android BSP from 4 to 5 (with OTA-13 this process is > completed, right?) No. The MX4 still runs the 4.x based BSP and will never change to a newer one. > 2. Backport MediaCodecSource I've outlined the necessary changes in various mails on this mailing list already. However the BSP source for the MX4 is not available to the public so such work could only happen inside Canonical. > There's something new about this? AFAIK nobody started work on this. regards, Simon -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
