[Ubuntu-phone] openssh broken? Cannot ssh into phablet image
Hi all, in cdimage-touch images from yesterday onwards, I'm not able to just install openssh-server and then ssh into my phone. This has broken my workflow as lots of scripts I use all rely on ssh. For the moment, these steps are my work-around, until I can dig more thoroughly: adb shell dpkg-reconfigure openssh-server mkdir /var/run/sshd chmod 644 /var/run/sshd /usr/bin/sshd -D& Now sshd runs, so I can ssh in. But I'd like to campaign to get ssh fixed in the phablet images. Thanks -Gerry -- 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] openssh broken? Cannot ssh into phablet image
On Fri 13 Sep 2013 16:12:29 CEST, Sergio Schvezov wrote: > On Fri, Sep 13, 2013 at 6:02 AM, Gerry Boland > wrote: > >> Hi all, >> in cdimage-touch images from yesterday onwards, I'm not able to just >> install openssh-server and then ssh into my phone. >> >> This has broken my workflow as lots of scripts I use all rely on ssh. >> >> For the moment, these steps are my work-around, until I can dig more >> thoroughly: >> >> adb shell >> dpkg-reconfigure openssh-server >> mkdir /var/run/sshd >> chmod 644 /var/run/sshd >> /usr/bin/sshd -D& >> >> Now sshd runs, so I can ssh in. >> > > It's disabled by default, delete the /etc/init/ssh.override to enable it > Aha, I hadn't noticed the override file. Thanks, I've updated my scripts to suit. -G -- 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] Desktop file parsing - lets standardize
Hi folks, Ryan Lortie and Lars Ubernickel were at this years FreeDesktop Summit [1]. One thing they've mentioned to me is the fact that it was decided to have a binary cache of desktop files, to improve access and searching of that data. This reminded me that our desktop file parsing situation is a bit of a mess. Right now we have multiple approaches: - unity (Qt) launcher uses QSettings ini file parser [should be standard compliant] - unity-mir/qtubuntu (Qt) has it's own super-basic parser, which needs to be replaced - upstart-app-launch (bash/C) has a tiny C util to read the "Exec" strong from a desktop file - click lenses (Vala) use GLib.KeyFile, another ini file parser [standard compliant] and there's probably more. Since we use many GTK-based tools, GDesktopAppInfo is often used too. The cache is generated by the tool that can be found at [5]. The main point of the cache is answering complex questions like "give me the apps associated with application/pdf", though it will also probably speed up single .desktop-file key-value data reads since the cache will most probably be kept in memory or disk cache. A desktop file reader could benefit if it supports this new cache. So having a custom parser, or just using ini file parsers, would not ideal if we want to use this cache in future. I think a logical approach is to standardize (as much as possible) on a single desktop file parser implementation ASAP. Should we later want to use the cache, we can add it to our chosen parser, and thus all its users will immediately benefit. Here are possible solutions: 1. GDesktopAppInfo [2] - will support the new cache shortly. - we would need to wrap this for easy use with Qt however. - pulls in GIO - usable though Vala too. - it will be well tested and used by more than just us. 2. KDE frameworks 5 [3] - cache support not landed yet. - whole framework is not released and thus not packaged for Ubuntu. We would have to help the KDE guys out on this. - would integrate nicely with Qt. - will be well tested with many users aside from us. - not usable with Vala. 3. QtXDG [4] - no plans to support cache currently. Would need extending to support the cache. - packaged for Ubuntu, but Qt4 only. It does build and work on Qt5 however. Would need the Qt5 version to be packaged. - integrates nicely with Qt. - not many users, nor well tested. - not usable with Vala. 4. Make something home-grown - Antii Kaijanmäki has written a desktop file parser in Qt5 [6]. It would need to be split into a separate library, and be packaged. - no plans to support cache currently. - integrates nicely with Qt. - We would be the sole users, and this having less "in the wild" testing. - not usable with Vala, without significant changes. What do people think? Are there alternatives I'm missing? Thanks -Gerry [1] https://en.opensuse.org/openSUSE:2013_Desktop_Summit#Agenda [2] https://developer.gnome.org/gio/unstable/gio-Desktop-file-based-GAppInfo.html [3] http://quickgit.kde.org/?p=kdelibs.git&a=tree&h=96b05b9b35e395ef2de16dc2188bbfd8eb190de7&hb=c2e988586e7b8788030195dbec625a21c1dd03af&f=tier1%2Fkconfig%2Fsrc%2Fcore [4] https://github.com/hawaii-desktop/qtxdg/blob/master/src/xdg/qdesktopfile.h [5] https://github.com/desrt/desktop-file-index [6] https://code.launchpad.net/~kaijanmaki/unity8/launcher-backend/+merge/179663 -- 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] Desktop file parsing - lets standardize
Hey, reply inline On 13/11/13 10:40, Thomas Voß wrote: > On Wed, Nov 13, 2013 at 11:19 AM, Michael Zanetti > wrote: >> On Wednesday 13 November 2013 10:01:24 you wrote: >>> On Wed, Nov 13, 2013 at 9:30 AM, Michael Zanetti >>> >>> wrote: >>> Okay, let's clarify the problem "complexity" here: >>> >>> (1.) We need to parse a very simple text file format that is well-spec'd. >>> (2.) Value types are constraint and well-defined: >>> http://standards.freedesktop.org/desktop-entry-spec/latest/ar01s03.html >>> (3.) Keys are simple strings that don't need further interpretation. >>> >>> Just parsing and validating this data, exposing well-known, default >>> keys and making that accessible to any sort of toolkit is really >>> simple. Please point out places where I'm oversimplifying the problem, >>> but I think this is really simple to implement and expose via an API. >>> A second step then would be toolkit-specific APIs, including toolkit >>> specific types and so on. But that toolkit-specific API is a second >>> layer from my POV. >> >> I'm not saying that this is a complex task. Still I think we don't need yet >> another lib. And this would give a perfect chance to actually do what we tell >> people we do: Collaborate with others. >> > > Oh, I'm totally aligned with that and I'm actually proposing to unify > the parsing across toolkits as much as possible by means of a simple, > well-tested low-level library that does exactly that. We'd first need to see if the other toolkit developers would even want this. GTK has its own solution, the one we rely upon today on the desktop. Qt is a more OS agnostic toolkit, so I expect great resistance to adding a linux-specific API. KDE as a result has written and maintains its own. EFL probably has it's own. XFCE too. Why would they change? Can we write a lower-level library in a way that respects the toolkit's existing API? Maybe we'd have to do it without C++11 support (or C alone?). And then persuade the maintainers it won't introduce breakages. This does not sound trivial, and frankly I think we've more important things to do. There are more efficient ways to collaborate. > >>> >>> I do agree that we shouldn't pull in lots of >>> dependencies for this, but given that we use Qt in all the places we consume it, makes it seem like a good idea to at least look at the existing Qt implementations before coming up with something ourselves. >>> >>> Well, we need to consume desktop file entries from Vala, too, as per >>> Gerry's list. >> > One thing we have to keep in mind is that our ecosystem is not Qt/QML > only, but also consists of HTML5/JS and Go is in the pipeline to > become a first class citizen, too. On top, we need to make integration > of different runtimes as easy as possible to ease porting of e.g. game > engines. While I do agree that toolkit-specific APIs are required, > too, we as platform maintainers need to make sure that different > runtimes/toolkits can easily leverage our platform offerings. For > that, I'm proposing a layered approach that offers a low-level > reference implementation meant to be consumed by toolkits and > runtimes. I think we need to keep our requirements clear. For this particular case, parsing desktop files is primarily a task for shell and process supporting shell (lenses, upstart-app-launch). I cannot think of a common use-case where an application would want such abilities. As a result, let's just choose something that will work for our needs. I'm not against diversity of toolkits, but we really need to focus on having at least one good developer story, and not have several poor options for a developer. And we need to target our resources to executing that in the best way possible. What worries me about this diversity discussion is the logical conclusion: we will up with a huge mass of pure C/C++ libraries that we have to write and maintain ourselves, and additionally we'll have wrappers for Qt/Go/HTML+JS [1]. This would be a nightmare. -G [1] and I'm of the opinion that wrappers frequently are forced to mirror the design of the low-level wrapped API upon the high-level API, resulting in an API which does not respect the higher-level language's design paradigm. -- 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] Desktop file parsing - lets standardize
On 13/11/13 13:26, Thomas Voß wrote: > On Wed, Nov 13, 2013 at 1:27 PM, Alberto Mardegan > wrote: >> On 11/12/2013 04:56 PM, Gerry Boland wrote: >>> I think a logical approach is to standardize (as much as possible) on a >>> single desktop file parser implementation ASAP. Should we later want to >>> use the cache, we can add it to our chosen parser, and thus all its >>> users will immediately benefit. >> >> I would like to highlight the "as much as possible": until we don't have >> a single programming language/toolkit, we don't need a single >> implementation. To clarify: >> >>> Here are possible solutions: >>> >>> 1. GDesktopAppInfo [2] >>> - will support the new cache shortly. >>> - we would need to wrap this for easy use with Qt however. >>> - pulls in GIO >>> - usable though Vala too. >>> - it will be well tested and used by more than just us. >> >> This will be developed regardless of our involvement, and it's the only >> API which will be usable from Vala. Vala applications already depend on >> GObject and GIO, so as long as we support Vala it doesn't make sense to >> come up with a different implementation, and this will be in our archive >> anyway. >> >> I think the question is whether we want to wrap it into a Qt API, or >> using something else. This is my favoured approach. It should be relatively quick to wrap for Qt usage, and works with everything else. >>> 2. KDE frameworks 5 [3] >>> - cache support not landed yet. >>> - whole framework is not released and thus not packaged for Ubuntu. We >>> would have to help the KDE guys out on this. >>> - would integrate nicely with Qt. >>> - will be well tested with many users aside from us. >>> - not usable with Vala. >> >> Despite my desire to collaborate with KDE as much as possible, I don't >> think that this, in its current implementation, is usable for us. It's >> too bloated :-) It reimplements the whole parsing (which we already >> have in QSettings) and in practice the benefits it brings over QSettings >> are minimal (a few APIs which would be trivial to implement with QSettings). Sadly yeah, I have to agree. The KDE Frameworks 5 will modularize their huge library greatly, but it's simply not ready yet. >> >>> 3. QtXDG [4] >>> - no plans to support cache currently. Would need extending to support >>> the cache. >>> - packaged for Ubuntu, but Qt4 only. It does build and work on Qt5 >>> however. Would need the Qt5 version to be packaged. >>> - integrates nicely with Qt. >>> - not many users, nor well tested. >>> - not usable with Vala. >> >> It seems the author dropped this in favor of KConfig (the link is no >> longer valid). >> However, razor-qt/LXDE is still using it: >> https://github.com/Razor-qt/razor-qt/tree/master/libraries/qtxdg Ah, news to me. Yep I'd found it from Razor-Qt, it appears to have a bunch of XDG utility libraries written in Qt, which I've kept an eye on. >> >>> 4. Make something home-grown >>> - Antii Kaijanmäki has written a desktop file parser in Qt5 [6]. It >>> would need to be split into a separate library, and be packaged. >>> - no plans to support cache currently. >>> - integrates nicely with Qt. >>> - We would be the sole users, and this having less "in the wild" testing. >>> - not usable with Vala, without significant changes. >>> >>> What do people think? Are there alternatives I'm missing? >> >> I think that, at least for now, the API is more important than the >> implementation. I'd like to see us agreeing with KDE and Razor-qt over a >> Qt API (at first sight, the one used by razor-qt looks good enough). > > I think your assumption that a Qt API is sufficient is slightly > biased. If we start investing time and effort here, we should make > sure that our use-cases are covered. That being said, I don't see any > particular reason why we shouldn't agree on the full stack with KDE > and razor-qt and we share the burden of implementing and maintaining > it instead of defining an API, coming up with one implementation, > testing and maintaining it, to ultimately diverge from the pre-defined > API as it does not fit anymore. I don't see the benefit here. Yep, developing something upstream would be a good option. Having our own implementation that isn't used by others is a bad solution. I'd much rather sharing something with several other projects. >> We could
Re: [Ubuntu-phone] Qt 5.2 - Events are queued when rendering blocked
On Thu 27 Mar 2014 22:42:33 GMT, Michal Hruby wrote: > On 27/03/14 22:18, Michał Sawicz wrote: >> On 27.03.2014 22:49, Michal Hruby wrote: >>> Just let Qt know that the shell window is obscured, that's when the >>> render thread stops. >> Problem here is that's racy - by the time the expose event reaches >> whatever it needs to reach, the render thread might already be blocked >> in eglSwapBuffers. > > I didn't back off from my suggestion to stop blocking and just return > true there. It's not like turning off the display disallowed us from > copying a buffer. > One worry I have about eglSwapBuffers blocking is what happens at unblock. It blocks when powering down the display. Unblock happens when the display is powered back up, however the GL pipeline still contains the commands for rendering the last frame before the screen was powered down. So at display on, the first frame rendered will be a before-display-off frame - which is bad. Is there something I'm missing? -G -- 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] Unity8 & Mir update May 20, 2014
On 21/05/14 13:03, Thomas Voß wrote: > On Tue, May 20, 2014 at 7:24 PM, Rick Spencer > wrote: >> >> >> On Tue, May 20, 2014 at 6:47 PM, Michał Sawicz >> wrote: >>> >>> On 20.05.2014 18:34, Kevin Gunn wrote: But I guess your question is still valid, do we want to hold off landing something that might make the sensitivity of rotation more annoying than it is atm ? >>> >>> It won't make it more annoying, since apps rotate inside their own >>> surfaces reacting to the same already. Only difference will be that the >>> shell rotates as well. >>> > > Exactly, and I think the resulting experience would be quite messy to > say the least :) > I would (weakly) vote to land shell rotation independent of the sensitivity bug...but we're weeks away from that, maybe it gets fixed prior. >>> >>> +1, probably even higher priority would be to add the whole system of >>> orientation locking and "negotiation" with apps. > > +2. > > I think there are 3 steps required to ensure that the shell and app > rotation experience works well: > > (1.) Adjust our current naive sensor implementation to leverage the > fusioned rotation sensor available from Android. I listed the > respective details on the bug report mentioned before. With that, we > would be able to improve the app rotation experience first, and get > some mileage on the newly introduced glue code. > -> Requires adjustments to: platform api, QtUbuntu sensors > > (2.) Introduce a centralized decision maker that triggers UI rotation: > Right now, the apps and the shell are independently listening to raw > rotation sensor readings. For coordinated shell and app rotations, > this central component (likely living in the shell) would act upon raw > sensor readings and decide whether a rotation should be triggered. At > that point, both the shell and the app(s) would receive the same > trigger signal and start transitioning (plus some potential > coordination on the transition). > -> Requires adjustments to: UI toolkit > -> Requires new rotation API -> U8 I agree with this, with small additions: Mir needs a small IPC addition to allow shell to notify an application of the orientation change shell decided. Also needed is IPC for application to inform shell the orientations it supports (but can be done via Mir's existing side-channel) > (3.) Teach the shell and Mir how to rotate. > > All of the above three work items could be worked on in parallel. > However, I would suggest to land them in the order presented before to > prevent from UI issues with independently rotation apps and to address > the potential problems mentioned in this thread. > > Did I miss something? I think we're covered! -G > > HTH, > > Thomas > >> It sounds to me that we have one rotation system right now that is wrong in >> a couple of ways. We have implemented and are about to embark on testing >> another system for rotation that, while perhaps separate in some technical >> ways, will none the less interaction with the first system at the user >> experience level at a minimum. >> >> If it were me, I would very much want to pin down the app rotation system >> before landing shell rotation so I had overall less complexity and fewer >> changes to cope with. >> >> Cheers, Rick >> >> >> -- >> 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] help with touchscreen configuration - gestures are not working
On 07/10/15 13:36, Pavel Andrejs wrote: > Hi, > first of all, please, let me know, if I am on a wrong mailing list. > This page > https://developer.ubuntu.com/en/start/ubuntu-for-devices/porting-new-device/ > lead me here. > > To the problem - I noticed this error message > > DirectionalDragArea: recognition properties are wrongly set. Gesture > recognition is impossible > > in unity8 log. I did some debugging a found that in > unity8/plugins/Ubuntu/Gestures/DirectionalDragArea.cpp there is a > method DirectionalDragArea::itemChange which calls > value.window->screen()->physicalDotsPerInch(). The last one returns a > bad value. This leads to an inf value pixelsPerMm later and disables > the gesture recognition. For now I solved this with a little hack - I > hardcoded pixelsPerMm to 306 / 25.4. With this the gesture recognition > works. I suppose I would eventually find the correct place for this > value, but some of you may have it faster :-) Hey Pavel, the QScreen::physicalDotsPerInch() calculation requires an accurate value for QScreen::physicalSize(). That is supplied via qtmir/qtubuntu by Mir. Mir tries to get this info from the hardware, but either the hardware doesn't know/lies, or Mir has a bug in retrieving this information. On your device, please run this command: sudo MIR_SOCKET=/run/mir_socket mirout Here is the output I get on my Nexus 7: Connected to server: Card 0: Max 2 simultaneous outputs Output 0: Card 0, LVDS, connected, 1200x1920+0+0, used, on, 95mm x 151mm (7.0"), normal 1200x1920 60.00*+ Output 1: Card 0, DisplayPort, disconnected where you see the physical dimensions of the display being printed. What do you see? -Gerry signature.asc Description: OpenPGP digital signature -- 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] help with touchscreen configuration - gestures are not working
Hey Pavel, I need the Mir team to chip in then, that's a layer under me. -G On 08/10/15 12:59, Pavel Andrejs wrote: > Hi Gerry, > the dimensions are wrongly detected, the mirout command returns this: > > Connected to server: > Card 0: Max 2 simultaneous outputs > Output 0: Card 0, LVDS, connected, 720x1280+0+0, used, off, 0mm x 0mm > (0.0"), normal > 720x1280 60.51*+ > Output 1: Card 0, LVDS, disconnected > 720x1280 60.51*+ > > The screen is definitely bigger :) I suppose the problem is somewhere > in the android layer, but where to look? > > > Thanks everyone for advices. :) > > > Pavel > > > 2015-10-08 13:41 GMT+02:00 Gerry Boland : >> On 07/10/15 13:36, Pavel Andrejs wrote: >>> Hi, >>> first of all, please, let me know, if I am on a wrong mailing list. >>> This page >>> https://developer.ubuntu.com/en/start/ubuntu-for-devices/porting-new-device/ >>> lead me here. >>> >>> To the problem - I noticed this error message >>> >>> DirectionalDragArea: recognition properties are wrongly set. Gesture >>> recognition is impossible >>> >>> in unity8 log. I did some debugging a found that in >>> unity8/plugins/Ubuntu/Gestures/DirectionalDragArea.cpp there is a >>> method DirectionalDragArea::itemChange which calls >>> value.window->screen()->physicalDotsPerInch(). The last one returns a >>> bad value. This leads to an inf value pixelsPerMm later and disables >>> the gesture recognition. For now I solved this with a little hack - I >>> hardcoded pixelsPerMm to 306 / 25.4. With this the gesture recognition >>> works. I suppose I would eventually find the correct place for this >>> value, but some of you may have it faster :-) >> >> Hey Pavel, >> the QScreen::physicalDotsPerInch() calculation requires an accurate >> value for QScreen::physicalSize(). That is supplied via qtmir/qtubuntu >> by Mir. >> >> Mir tries to get this info from the hardware, but either the hardware >> doesn't know/lies, or Mir has a bug in retrieving this information. >> >> On your device, please run this command: >> sudo MIR_SOCKET=/run/mir_socket mirout >> >> Here is the output I get on my Nexus 7: >> Connected to server: >> Card 0: Max 2 simultaneous outputs >> Output 0: Card 0, LVDS, connected, 1200x1920+0+0, used, on, 95mm x >> 151mm (7.0"), normal >> 1200x1920 60.00*+ >> Output 1: Card 0, DisplayPort, disconnected >> >> where you see the physical dimensions of the display being printed. What >> do you see? >> -Gerry >> >> >> >> -- >> 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 >> > signature.asc Description: OpenPGP digital signature -- 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] Landing QtCompositor plugged into Mir
Hi everyone, I'm excited to announce that we have a silo ready for testing QtCompositor! We'd really appreciate as many people testing it as possible. To do so, follow the steps in this wiki page: https://wiki.ubuntu.com/Unity8/QtComp This is a significant change so please give it a go and if you spot any regressions, please report them (instructions in the wiki). Thanks! -Gerry On 30/06/14 16:03, Kevin Gunn wrote: > Hi all, > First, thanks for reading & please consider participating in this testing. > We've had the experience recently of having lower than desired > participation in significant changes (split greeter anyone? :). We want to > be systematic & only want to land QtCompositor plugged into Mir (QtComp for > short) in the instance we're confident. This call for testing is a vehicle > to help us do just that. > > Background... > For some time now, the Mir & Unity UI team has been working on enabling the > shell to plugin its own compositor as well as progressing on some of the > advanced ui features that will leverage it. This will be used to support > several key RTM features such as animations of applications in trusted > sessions, moving to dash-as-app, and better handling of killed app ui shots > in spread. As well as rotation, "splitstage" and other spread/sidestage > animations. However, this landing is really to deliver QtComp with as much > feature parity as possible, while leaving the more advanced features turned > off as not to inject risk (for instance, we've got rotation almost fully > working, but we want to keep that a separate landing-effort). > > The plan... > Bear with me, duration of TRAINCON-0 might alter some of this. > We are currently landing Mir0.4.0, once this happens we will move to have a > ci-train silo for testing, target to have this by Friday July4 (altho > possibly sooner). > I will send a follow up mail when the silo is prepared (...I've sent this > mail early so you can plan :) Given the nature of the change, we plan for > the silo to be under test for a full week at a minimum. > If you're willing to test, please follow the guidelines here > https://wiki.ubuntu.com/Unity8/QtComp > This wiki will continue to be updated through closure of the call for > testing. > We will land when we are finished testing and we are in a confident, > non-regressed state on Ubuntu Phone. > > Feedback... > In order to get a feel for the response, if you do test, please take time > to add your name & mark which platform here > https://docs.google.com/a/canonical.com/spreadsheets/d/1QcZOt9x_rY1m5d4NmmQ3FUjcWHKVoesMUv65Hm9VUK8 > Note, the sheet is only to track participation, not bug tracking, please > use bugs when appropriate, per the instructions in the wiki. > > br,kg > > > -- 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] Landing QtCompositor plugged into Mir
Hi Roman, I don't quite understand your question, but I can assure you that we care greatly for the performance of the entire Ubuntu Touch platform, not just in graphical smoothness but also in responsiveness of the UI and app startup speed. We've still got work to do, but we've lots of time scheduled for such optimisations. Thanks -Gerry On 04/07/14 16:45, Roman Zonov wrote: > What about device performance at all? > 04.07.2014, 18:29, "Gerry Boland" : >> >> Hi everyone, >> I'm excited to announce that we have a silo ready for testing QtCompositor! >> >> We'd really appreciate as many people testing it as possible. >> >> To do so, follow the steps in this wiki page: >> https://wiki.ubuntu.com/Unity8/QtComp >> >> This is a significant change so please give it a go and if you spot any >> regressions, please report them (instructions in the wiki). >> >> Thanks! >> -Gerry > > Best regards, > Roman Zonov. > VK: http://vk.com/zonov_roman > Facebook: https://www.facebook.com/roman2861 > Twitter: https://twitter.com/zonov_roman > -- 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] Convergence on Ubuntu Touch Nexus 4 with slimport
On 16/05/15 06:06, Zachary Igielman wrote: > Hi, > > I was wondering if it is possible to get the convergence experience > running Ubuntu Touch on a Nexus 4. I currently have a Nexus 4 running > Ubuntu touch (stable) and have been using it as my phone for a while. I > have developed apps for it but now I want to try convergence with it. > > I bought a slimport adapter which at the moment just shows a blank > screen. How can I set it up to give me a converged experience, soemthing > like in this video?: https://youtu.be/bk9-v8Sl4yU > > I would love to start developing and using convergence. How can I get a > converged experience with an Ubuntu Touch Nexus 4 and a slimport? > > Thanks, > Zach > Hi Zach, as Marco rightly pointed out, we haven't added the convergence support to unity8 yet. The code we demoed in your video just wasn't high enough quality to ship to all users. We're still working on that, but it's a high priority task for us. We'll post a mail to this ML when we land it, so watch this space -G signature.asc Description: OpenPGP digital signature -- 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] Convergence on Ubuntu Touch Nexus 4 with slimport
On 22/05/15 09:43, Marco F wrote: >> I believe there was a video clip out there of an in-development state > of Ubuntu convergence (which perhaps Gerry thought you shared), but > these are not the same thing. > > Which is > https://www.youtube.com/watch?v=c3PUYoa1c9M&feature=youtu.be&t=2m45s > > Marco > You read my mind Marco, thanks for the clarification -G signature.asc Description: OpenPGP digital signature -- 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] Desktop file location
Hi Mitchell, glad you found it, that's where user applications have their desktop files placed. For system-wide apps (e.g. webbrowser, dialer), you'll find those desktop files in /usr/share/applications Cheers -Gerry On 19/07/15 00:22, Mitchell Reese wrote: > Found it - /home/phablet/.local/share/applications > > Thanks! > > Mitchell > > > On Sunday, 19 July 2015 9:17:29 AM AEST, Mitchell Reese wrote: > > Does anyone know where the default .desktop file locations are for > > applications? I.e., I need to edit a few of them - some applications > > don't rotate the shell by default, and I'm finding the current > > implementation of side stage on a Nexus 7 useless. While I can see the > > code for applications under /opt/com.ubuntu.click/, edititng the > > .desktop files there does nothing - am I right in assuming they are > > copied to another location on install of a click package? If so, where? > > > > Thanks, > > > > Mitchell > > > > -- 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] Memory..
On 07/16/2016 08:48 PM, Thomas Voß wrote:
> On Sat, Jul 16, 2016 at 8:25 PM, รัชนันท์ ศรีรัตนเมธ
> wrote:
>> In Ubuntu touch, I have no idea where oom_adj is computed. (Please anyone
>> tell me?) But from my experiment, all suspended applications have the same
>> value of oom_adj. How this affects the problem? Imagine this:
>
> You are almost right, but we are not using Android's lowmemorykiller, yet.
> Instead, we configure the vanilla OOM killer by altering oom_score_adj
> (oom_adj is deprecated).
>
> Android's lowmemorykiller sits on top of this mechanism and allows for
> specifying ranges of memory
> and mappings to oom{_score}_adj values.
>
> As you describe later, we are not yet deploying a heuristic that
> assigns a higher oom_score_adj value
> to app instances that have been used less recently (think about: least
> recently used is more likely to be killed under the assumption
> of a uniform distribution of memory usage). The respective feature is
> under development iirc, but I'll
> let Gerry and Ted comment on this explicitly (I CC'ed both of them
> explicitly).
Thomas is correct, while we're setting an OOM score to influence the OOM
killer's decisions, we currently set the same OOM score for all
background apps, irrespective of how recently they were used.
We're now working on more advanced OOM score calculation, so that a
recently-used background app is less likely to be killed than one used
less recently. This bug tracks that task:
https://bugs.launchpad.net/ubuntu/+source/ubuntu-app-launch/+bug/1579799
>>
>> 2.Ubuntu touch's choice for using QML. Out of curiosity, I opened an SSH
>> session, ran "top", and looked at the calculator app's memory usage on my
>> phone. I found out it's around 113 MB. 113 MB just for a caculator!? I'm
>> speechless.
>> I believe this can be reduced somehow. One of the idea is that, as many QML
>> component in Ubuntu is shipped as source .qml files, I understand that each
>> application will have to load those files, parse that files, and keep those
>> parsed code individually in each application's memory (please correct me if
>> I'm wrong). As many Android kernel has enabled KSM (kernel samepage
>> merging), maybe we should try exploiting it? I've tried enabling KSM on my
>> device, but the result was pretty disappointing. Maybe we should mark those
>> memory as mergeable?
>>
>
> I think we should take the time and analyze memory usage first before
> starting to optimize.
> Specifically, for the reported 113 MB, is that RSS, USS or PSS?. I
> don't have a phone with ssh handy right now
> but I will try to reproduce your test case tomorrow first thing. I
> would start analyzing /proc/$pid/smaps first.
>
> I would also propose to establish a memory baseline measurement by
> considering a very simple QML app just displaying a rectangle.
> That should give a reasonable baseline for comparisons. Even if the
> calculator is simple, it still puts its own app logic on top (stack of
> calculations etc.).
QML is a very easy language to use, but that has a consequence: it is
easy to write code in a memory wasteful manner.
One can easily write code that loads all the views your application will
ever have into memory - even though only one view is shown at a time. It
just takes a little care to properly load/unload views to lower your
memory use (using the UITK will help with that).
It is too easy to load big images into memory and scale them down on the
GPU. Complex QML widgets can be expensive in memory too - the UITK team
are working on rewrite existing QML widgets to be more efficient.
The sad truth is that when developing an application, monitoring memory
usage is one of the last things thought of!
To address thing we're working on a performance monitoring system to
give a high-level perspective on application resource usage
(CPU/memory/IO...), so we can quickly identify wasteful apps and help
them improve. Watch this space!
Thanks for sharing your thoughts.
-Gerry
signature.asc
Description: OpenPGP digital signature
--
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] "platform-api" dependency!
On 15/11/16 15:51, ali hagigat wrote: > The Ubuntu architecture has a layer named "platform-api". Does this > layer depend on the type of Ubuntu distribution? Like, "platform-api" > for UbuntuTouch is different with "platform-api" in the desktop x86_64 > Ubuntu? > Yep. Platform-api is intended to abstract away low-level platform differences. For example, on UbuntuTouch the "platform" APIs (which are for things like sensors, gps, alarms) are backed by code that may be running on the android side, and pass via libhybris. On desktop, those APIs are usually backed by more typical daemons and kernel interfaces. We didn't want developers to care about those details, and ease convergence. -G signature.asc Description: OpenPGP digital signature -- 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] How to access to "platform-api"?
On 15/11/16 15:58, ali hagigat wrote: > I am trying to develop a user space code for the following platform : > > Nexus 5 + UbuntuTouch + ubuntu 15.04 Vivid > > Can i access to "platform-api" functions of the operating system? and how? > Code is at lp:platform-api For UbuntuTouch, there is a part of platform-api that lies on the android side, and another part on the Ubuntu side. If you check out the code for UbuntuTouch for some existing platform we've worked on, you will find platform-api in there, and part of it (the "android" subdirectory) is built with the android toolchain to live on the android side. Then on the Ubuntu side, hybris is used to link that android library with an Ubuntu-side library, giving Ubuntu-side applications access to those hardware bits. -G signature.asc Description: OpenPGP digital signature -- 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] Thank you
On 10/04/17 19:21, Pat McGowan wrote: > Dear contributors and enthusiasts > > On behalf of the entire team that worked on Ubuntu Touch, Unity8, Mir, > the apps, the services, the hw enablement, the QA, the releases, the CI > infrastructure... thanks for your commitment, patience and the many > kind words for the developers and the products. > > Working on this great software was a very rewarding experience made more > so by your involvement. > I share the hope that it lives on. > > So long for now > Pat > > PS As far as I know this list will remain open. > > Dear Pat, it was an honor and a pleasure. -Gerry signature.asc Description: OpenPGP digital signature -- 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] Testing Unity 8 with Mir
Hey Gianguido and others, packages have been updated, unity+mir is working on my phone again. Please let us know if you've any issues. Thanks for the heads up -Gerry P.S. there is more refactoring work in progress with platform-api, so these packages will break again probably soon. But once the refactoring completes, we will land all the other bits, so there'll be no need for the sketchpad instructions. On 28/05/13 17:56, Gianguido Sorà wrote: > Ok, I'll wait for an email from you. > Thanks again for your work. > > Gianguido Sorà > > > 2013/5/28 Gerry Boland > >> Hey, >> yes I see Mir has merged some quite large refactoring changes. I'll need >> to update the packages to reflect those. I'll email when I've new >> packages available. >> -Gerry >> >> >> On 28/05/13 16:39, Gianguido Sorà wrote: >>> Unfortunately I got some errors when the "run_on_device -m" command is >>> issued, here [1] you'll find the backtrace. >>> Hoping it will help to debug. >>> >>> [1] http://pastebin.com/TZgxMPvU >>> >>> Gianguido Sorà >>> >>> >>> 2013/5/28 Gianguido Sorà >>> >>>> I'm testing right now, I'll let you know. >>>> Thanks a lot! >>>> >>>> Gianguido Sorà >>>> >>>> >>>> 2013/5/28 Gerry Boland >>>> >>>>> On 28/05/13 15:09, Gianguido Sorà wrote: >>>>>> Yesterday I was reading the Ubuntu Devel mailing list when I saw this >>>>> [1]. >>>>>> As you can read, it contains instructions useful to test Unity 8 and >>>>> Mir on >>>>>> Ubuntu Touch. >>>>>> I followed all the instructions but this [2] link cannot be reached >>>>> without >>>>>> an "OpenID Auth". >>>>> >>>>>> [1] http://studio.sketchpad.cc/gmY0M6iqeh? >>>>> >>>>> Hi Gianguido, >>>>> I've put the packages somewhere that everyone can access, and updated >>>>> the sketchpad with the new location. >>>>> >>>>> Let me know if there are any problems >>>>> -Gerry >>>>> >>>> >>>> >>> >> >> > -- 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
