Sorry for the day-long delay, i have a bad habit about forgetting
about the gmail labels outside of the inbox :)
Anyways, the approach described in the wiki article there looks like
it would work. I usually will move the surfaceflinger executable all
together so it can't be found, which stops the
we have an installation script? :) (just kidding)
tools/install_on_android.sh is a bit rotten, i think we were intending
to use this in CI somehow, but still are not at that point yet. (and
even at that, package deployment as opposed to adb is probably the
better way for CI) I have been using rsyn
Last time i was tinkering with the Nexus 7 (presumably the older
model, not the Nexus 7HD), most things were working, except there was
an undiagnosed problem with hybris and the nexus 7 hwc. The nvidia
drivers use a fair amount of the pthread api that the other drivers
don't use (such as process-sh
Maybe I missed an announcement somewhere, but it seems:
phablet-flash ubuntu-system --no-backup --channel trusty
gets you the latest promoted trusty image, and
phablet-flash ubuntu-system --no-backup --channel trusty-proposed
gets you the latest bleeding-edge trusty image. Hopefully saves some
time
I'm also slightly against 'core', just because people will think its more
important than it is
scene, model, and model_controller has connotations to me, maybe
mir::diaroma?
Pretty unloaded word... To me, it means 3d objects put in a box for the
purposes of displaying. If no one supports that tho
an /has
>> a/
>> > scenegraph).
>> >
>> > In the absence of a clearer, natural name I think we should go with
>> "scene"
>> > and educate people that think it is synonymous with "scenegraph".
>> >
>> >
>>
&
xnox hints here [1] that cmake recently gained the ability to cross compile
mir without any custom rigging. I haven't given this a try yet myself, but
if it works, I'd be happy to get rid of the scripts and
cmake/LinuxCrossCompile.cmake files.
I think that once we use the standard way to cross com
I think we have 3 issues that drive up diff size:
1) Bzr has branches, but they aren't cheap enough. The simple fact that you
have to compile each branch in its own directory is too big of a cost to
branch as often as I would in git. Furthermore, as illustrated by the
conversation above, if you wa
I think this proposal is sensible, and its a good improvement to the way we
have to build the stack from lp:mir/devel.
If we get a bug that's filed against unity, but the bug is in mir
libraries, I find most of the time in solving the bug is spent building the
stack to verify that the bug is fixed
The interfaces in DisplayBuffer for android overlay support are flexible
enough to handle bypass, although they are not being used yet. The approach
has added flexibility in that we can arrange for other optimisations that
the mesa platform can have (eg, we can bypass with a hardware cursor)
withou
Hello mir folks,
We have 4 users of mir in-flight right now:
1) unity8 (driving at using QtSG)
2) USC (using the default mir implementation)
3) the demo shell (using the default mir implementation, and overriding its
functionality in some areas)
4) the demo server (using the default mir animation)
t;>
>>
> agreed, and i think its good to restate this. I think the creep of
> "toolkit into mir" is something we have to be on guard for.
>
>
>> > Does it mean that when mir's compositor is overridden libmirserver.so
>> > does not touch GL state at all?
>&
itives via the tessellate
override). Android can then use it to draw the Renderables to the screen
when the Android drivers reject the surface as an overlay
Cheers,
Kevin
On Tue, Apr 1, 2014 at 4:49 AM, Alexandros Frantzis <
alexandros.frant...@canonical.com> wrote:
> On Mon, Mar 31, 2014
On Mon, Apr 14, 2014 at 6:58 PM, Daniel van Vugt <
daniel.van.v...@canonical.com> wrote:
> I was wondering how long it would take for someone else to raise this
> issue, not wanting to be the first to complain... ;)
>
> I think the simple best practice is: Check all reviews you are involved in
> e
ing a DisplayBufferCompositor
straightforward.
We still have that nice 'if/else block' around hardware optimizations, it
just now works for android as well as mesa in this branch.
Cheers,
Kevin
On Wed, Apr 2, 2014 at 2:28 PM, Kevin DuBois wrote:
> Yeah, I hope it can be tied into multit
My library had some copies, will check it out! Hopefully has some more
ideas for threaded tests...
--Kevin
On Tue, May 6, 2014 at 10:39 AM, Josh Arenson
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Purchasing as it sounds like a good read. Bummed that the local
> library doesn't
Hello mir team,
In order to get the next buffer for the client, we currently have:
rpc next_buffer(SurfaceId) returns (Buffer);
which is problematic for me in working on [1] because this implicitly
releases the buffer from the client side, whereas in working on that
performance improvement, I ha
them
>>>>> as
>>>>> MirEvents. Then you only need an RPC function to release them back to
>>>>> the server:
>>>>>
>>>>> rpc release_buffer(Buffer) returns (Void);
>>>>>
>>>>> Keep in mind the in
)
rpc remove_additional_buffer(Buffer) returns (Void)
This still would have the submission happen on the exchange call, but make
additional buffer allocations more explicit than the #5 idea.
On Wed, Jul 9, 2014 at 12:04 PM, Kevin DuBois
wrote:
> Attempting to steer the convo more towards the n
Okay, so resynthesizing the concerns to try to come up with a plan...
It seems the practical thing to do is first implement:
rpc exchange_buffer(Buffer) returns (Buffer)
which is by-in-large just an evolution of what we have now. The difference
that lets me proceed is that the buffer release is no
So it seems there's a problem with the CI where the images have selected
the mesa egl configuration:
https://bugs.launchpad.net/mir/+bug/1372926
This should be fixed in the next image release, but for the time being,
we're stuck with the CI failures.
Cheers,
Kevin
--
Mir-devel mailing list
Mir-d
This is good to think about, because it'll help us sort out the headers and
make sure that core concepts of mir are available to our users. It'll also
let us refocus; that is, make sure that the interfaces we want the
downstreams to use match up with the needs of the downstreams.
I think the compo
Thinking from a different angle,
Some of this has to do with the fact that the mesa native window and native
display interface and the mir client api is blended together. If we
separated them out and moved the mesa stuff to native window headers, we'd
have a cleaner api.
Like, I consider these fu
Hello All,
Have already embarked a bit on some android multimonitor work, and wanted
to share the plan as it stands for team comment/input.
There are two bigger chunks to the work:
Display Configuration and Control:
This is currently buried too deep behind mga::DisplayDevice. I'm going to
hoist i
upport such an approach, so long as we have the
> required triple-buffering in the compositor.
>
>
>
> On 11/12/14 10:31, Christopher James Halse Rogers wrote:
>
>> On Thu, Dec 11, 2014 at 7:59 AM, Kevin DuBois
>> wrote:
>> …
>>
>>>
>>> Deta
As for the Display changes, the branch is/was here:
https://code.launchpad.net/~kdub/qtmir/display-groups
It seems sensible to me that the mir team should keep around a list (google
docs maybe?) of the branches that fix the downstreams. If in the review
process, we find that a change breaks the do
The proving server definitely needs to move out of playground/, and rely on
the public API's. I would think that the public api's are more-or-less
equivalent to what the proving_server is doing privately, and where they
differ is a healthy topic to explore what we want to do about it. IMHO, We
twis
I'm okay with using python to execute the performance tests and
gather/parse lttng traces via babeltrace (it seems a decent api for
processing api traces). I agree that its better if we can visualize the
data nicely, but we have to deal with the problem that we're not collecting
this data at all ri
I've started spiking a bit on how to transition the system to what we've
been calling the new buffer semantics¹, and come up with a plan. We've
already landed the ipc plumbing, now we have to make use of it to its
potential.
Obviously, the number one thing to avoid is regressions in performance or
So, as far as planning goes
I think that the spreadsheet (with a few nuances, perhaps) plus the
BufferQueue.* tests give us a good capture of the requirements.
So, seems sensible to link the translation of the BufferQueue tests and the
capture of the requirements into the new integration-leve
r
for the purposes of ongoing feedback on the code to keep the reviews small.
Once all the serverside and client side features have been covered, then it
can be switched to default (which https://trello.com/c/w8qfQ59p is a
placeholder for)
Thanks,
Kevin
On Mon, Jun 29, 2015 at 10:34 AM, Kevin D
Sounds like it'll make usc management easier, +1.
On Tue, Jul 21, 2015 at 6:03 AM, Alan Griffiths <
alan.griffi...@canonical.com> wrote:
> On 21/07/15 11:00, Alexandros Frantzis wrote:
> > I propose that we move to the same
> > scheme for unity-system-compositor too.
>
> +1
>
> --
> Mir-devel mai
As for the phone CI problem, it looks like there was a package transition
from "libprotobuf-lite9" in vivid to "libprotobuf-lite9v5" in wily. The job
is building on vivid, so the package depends on "libprotobuf-lite9". When
deployed on the wily phone image, the package resolver can't figure out
whe
With the phone CI, switching everything to vivid+overlay had a small
problem that was corrected in the test runner script (overlay was pinned
higher than the packages that were installed, leading to unresolvable
situations). Clang is running against vivid, and CI should be unblocked!
On Wed, Aug 1
In the hope that its helpful to someone... (alternatives exist, like
entering the chroot golden image, and manually changing)
Step 1, create the chroot:
mk-sbuild --target=armhf --arch=amd64 --eatmydata vivid --name vividoverlay
Step 2: place "61add-overlay-ppa" (attached) in "/etc/schroot/setup.
60 bugs fixed
Cheers,
Kevin DuBois
kevin.dub...@canonical.com
--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/mir-devel
Sounds good to me, screencasting seems to have become the preferred way
that capturing output.
--Kevin
On Wed, Jul 6, 2016 at 5:24 AM, Alexandros Frantzis <
alexandros.frant...@canonical.com> wrote:
> Hi all,
>
> for a few years now, Mir has provided the --offscreen option to render
> to offscree
Two ways to answer this question make sense to me:
1) A MirRenderSurface is an EGLNativeWindowType
2) A MirRenderSurface is a mf::BufferStreamId (ie, it is the token
representing server-side)
We currently seem to be saying that MirRenderSurface are both. [1]
(crux of my point)
Given that there e
On Wed, Sep 7, 2016 at 8:01 PM, Christopher James Halse Rogers <
ch...@cooperteam.net> wrote:
>
>
> On Thu, Sep 8, 2016 at 5:09 AM, Cemil Azizoglu <
> cemil.azizo...@canonical.com> wrote:
>
>> Regardless of what EGL (or any other API) needs, there needs to be a way
>> for Mir platform to generica
On Thu, Sep 8, 2016 at 8:39 AM, Christopher James Halse Rogers <
ch...@cooperteam.net> wrote:
>
>
> On Thu, Sep 8, 2016 at 9:36 PM, Kevin DuBois
> wrote:
>
>>
>>
>> On Wed, Sep 7, 2016 at 8:01 PM, Christopher James Halse Rogers <
>> ch...@coopertea
I'm glad that the topic of EGL platforming was split off, its a different
question than the one I was raising in the "What is a MirRenderSurface?"
So really the question here is "should Mir have its own
EGL_KHR_platform_mir". I'm not opposed to this in general.
This goes back to the charter that
On Thu, Sep 8, 2016 at 8:13 PM, Christopher James Halse Rogers <
ch...@cooperteam.net> wrote:
> On Fri, Sep 9, 2016 at 4:18 AM, Cemil Azizoglu <
> cemil.azizo...@canonical.com> wrote:
>
>>
>>> We quite literally cast MirRenderSurface* to EGLNativeWindowSurface in
>>> the current WIP:
>>> http://ba
Hmm, let me try to rephrase my point, I've lost track of what is in
disagreement. We have a new thread "Does Mir have to pretend to be
SurfaceFlinger" that we can talk about our relationship to drivers. So for
further discussion, let's just assume we only have the Mesa platform.
We have a few diff
On Fri, Sep 9, 2016 at 7:59 AM, Kevin DuBois
wrote:
> Hmm, let me try to rephrase my point, I've lost track of what is in
> disagreement. We have a new thread "Does Mir have to pretend to be
> SurfaceFlinger" that we can talk about our relationship to drivers. So for
>
On Wed, Nov 30, 2016 at 9:40 PM, Daniel van Vugt <
daniel.van.v...@canonical.com> wrote:
> Tangentially, I'm still hanging out for a rename before
> mir_render_surface_* becomes a public API.
>
> MirRenderSurface I hope will get a shorter name that closer to a one word
> noun. Although the ideal o
On Thu, Dec 1, 2016 at 8:18 AM, Kevin DuBois
wrote:
>
>
> On Wed, Nov 30, 2016 at 9:40 PM, Daniel van Vugt <
> daniel.van.v...@canonical.com> wrote:
>
>> Tangentially, I'm still hanging out for a rename before
>> mir_render_surface_* becomes a public API.
&g
46 matches
Mail list logo
