Hi all,
In testing performance optimisations on various phones, I keep running
into an annoying hurdle.
Although you can optimise your Mir server/clients in such a way that
they're smoother more often, there's an additional variable outside of
Mir and Unity that gets in the way. That seems t
n the second core (out of eight)
comes online and everything is smooth. I wonder if more aggressive use
of threads might help...
On 14/08/15 16:48, Daniel van Vugt wrote:
Hi all,
In testing performance optimisations on various phones, I keep running
into an annoying hurdle.
Although yo
The wily archive transition is now complete and you probably noticed you
can once again build lp:mir on a fully updated wily system.
However, the transition has left a few things broken that need our
attention:
* Cross compile scripts don't work.
Solution:
https://code.launchpad.net/~vanvu
All,
Please remember Mir has retained protocol/socket level compatibility for
a long time now. What this means is that a client/server built today on
lp:mir should be able to connect to a server/client from previous
releases. The behaviour is not related to ABI levels.
Unfortunately this is
Mir 0.15.0 is now released and available in wily.
https://launchpad.net/mir/+milestone/0.15.0
Thanks Alberto.
--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/mir-devel
We've been using this as our distro branch for a while, but actually the
distro does not use it:
https://code.launchpad.net/~mir-team/mir/ubuntu
Why don't we just target future releases to the actual ubuntu (proposed)
branch instead?
https://code.launchpad.net/ubuntu/+source/mir
Present
/15 16:04, Alan Griffiths wrote:
On 24/08/15 08:45, Daniel van Vugt wrote:
We've been using this as our distro branch for a while, but actually
the distro does not use it:
https://code.launchpad.net/~mir-team/mir/ubuntu
Why don't we just target future releases to the actual ubuntu
(
OK, so the redundant distro branches have a reason: The train. Although
we could improve that slightly by renaming it to something train related
instead of the misleading lp:mir/ubuntu. But there's a better option
again...
Another apparently unnecessary part of the process is the merge proposa
Per display is kind of right, but it also varies per surface (depending
on which display it's mostly on).
We already have a "DPI" attribute per surface that's not fully wired up.
My thought was to add a "scale" attribute next to that, so that anyone
probing the DPI of a surface will get (displ
Thanks. I feared that, and was waiting for someone like you to confirm it.
So Mir's ubuntu branch messiness is all to support the train...
On 25/08/15 11:13, Alberto Aguirre wrote:
The CI train also requires a merge proposal.
On Aug 24, 2015, at 8:37 PM, Daniel van Vugt
wrote:
OK, s
ch twice. And we all know from previous experience that bzr
blindly succeeds and shows no diff landing any branch multiple times. I
think it would just work.
On 24/08/15 17:34, Stephen M. Webb wrote:
On Mon, Aug 24, 2015 at 4:17 AM, Daniel van Vugt
wrote:
I'm kind of saying we shou
If... we specified the complete function prototype for each C++ entry in
symbols.map (where the C++ symbol encodes its parameter types), then we
would be able to detect ABI breaks automatically as a build failure.
Instead of having to keep a keen eye on changes to include/*
Just a thought.
--
26/08/15 15:49, Robert Ancell wrote:
Couldn't you just add .symbols files into debian/? Then the debuild
would automatically fail until they were correctly updated.
On Wed, Aug 26, 2015 at 7:30 AM Daniel van Vugt mailto:vanv...@gmail.com>> wrote:
If... we specified the complete fun
6:06, Alan Griffiths wrote:
On 26/08/15 07:30, Daniel van Vugt wrote:
If... we specified the complete function prototype for each C++ entry
in symbols.map (where the C++ symbol encodes its parameter types),
then we would be able to detect ABI breaks automatically as a build
failure. Instead of having
we could improve...
I'm not content with keeping the whole train process as complicated as
it is forever. If we can pick away at it with small improvements at
least, that's some progress.
On 26/08/15 18:03, Michał Sawicz wrote:
W dniu 26.08.2015 o 03:50, Daniel van Vugt pisz
te:
On Wed, Aug 26, 2015 at 5:40 AM, Daniel van Vugt
wrote:
I guess the way we want to and should maintain ABIs is that the contents of
a stanza MIR_SERVER_N { } never changes (although you can always add a new
stanza MIR_SERVER_N+1 with changes). So store a historical copy of existing
"
ng on board and noticing them more often, but it's
still not automated.
On 27/08/15 11:26, Christopher James Halse Rogers wrote:
On Thu, Aug 27, 2015 at 12:05 PM, Daniel van Vugt
wrote:
That's true. If someone adds a field to a struct or changes the size
of a bool, symbol names don
must be separate to
that...
https://code.launchpad.net/~mir-team/mir/0.15/+merge/269082
If anyone has any further info, please update:
https://bugs.launchpad.net/mir/+bug/1451733
On 27/08/15 11:37, Christopher James Halse Rogers wrote:
On Thu, Aug 27, 2015 at 1:30 PM, Daniel van Vugt
I've considered using your suggested approach but also been using an
arguably cleaner solution for around the past year[*]. If you look in
src/client/symbols.map you will find:
MIR_CLIENT_9.1 { # New functions in Mir 0.15
It's no less foolproof than what you suggest, but has the added benef
Although you can easily avoid being wordy and have the best of both worlds:
MIRPLATFORM_9.0.16
MIRPLATFORM_9.0.17
On 31/08/15 09:57, Daniel van Vugt wrote:
I've considered using your suggested approach but also been using an
arguably cleaner solution for around the past year[*]. I
lightly less new
So ideally each one should not be named "*symbols*". Even using the word
"symbol" is redundant. We're just adding version suffixes really, so
keep that in mind.
On 31/08/15 10:34, Daniel van Vugt wrote:
Although you can easily avoid
to the library file names too:
https://bugs.launchpad.net/mir/+bug/1490428
Although the 'v' doesn't feel like the cleanest syntax. In an ideal
world your ABI number _is_ you major version number, so it just works
out as a version string.
On 02/09/15 00:39, Alan Griffiths wrote:
gt; libmirplatform.so.0.16
Means the Mir release is 0.17.0 but the ABI level (soname) is still
0.16. Actually that's not too confusing. It might be preferable even.
On 02/09/15 10:45, Daniel van Vugt wrote:
Yes MIR_PLATFORM_9v0.16.0 would work. Although I had hoped that we don't
get
team, who should
>> > be
>> > able to help you out.
>> >
>> > Cheers
>> >
>> > On Tue, Dec 2, 2014 at 9:01 PM, Daniel van Vugt
>> > mailto:daniel.van.v...@ca
Some might have figured this out already, but you can actually trick
Unity8 into accepting regular Mir clients like those from the mir-demos
package. All you need to do is hide the magic desktop_file_hint string
on the command line in such a way that the client itself does not reject it:
mir_d
15:01, Michał Sawicz wrote:
W dniu 18.09.2015 o 06:01, Daniel van Vugt pisze:
Admittedly that's a bit hackish. So coming in Mir 0.16.0 more of the
demo clients will understand the '--' option allowing for graceful
command line augmentation. Although it would be even better if Unity8
For mobile it totally makes sense.
For desktop I think you will find people will want to run
"unsigned/untrusted" "legacy" apps quite a lot :)
On 18/09/15 15:13, Michał Sawicz wrote:
W dniu 18.09.2015 o 09:05, Daniel van Vugt pisze:
Sounds like an improvement, than
As discussed yesterday, I think long term we need to get away from
requiring drivers to link to anything at all. Because some
vendors/lawyers require that, and specifically require that they not be
asked to link to LGPL code. Aiming for this higher goal will also force
us to think more deeply a
Mir 0.16.0 is released and hit wily last Friday:
https://launchpad.net/mir/+milestone/0.16.0
https://launchpad.net/ubuntu/+source/mir
Unfortunately at the same time, Mesa was updated to 11.0 so Mir no
longer builds on wily (bug 1499134). To get a fix for that you need to
get the latest p
There are a bunch of candidates for 0.16.2 that are either Fix Committed
or In Progress (fixes exist but not landed) here:
https://launchpad.net/mir/+milestone/0.17.0
On 03/10/15 00:25, Alan Griffiths wrote:
With Wily feature-frozen we should take a moment to consider whether
there are any f
I agree. In fact, I've always been bugged by the switching to X cursor
themes, which only happens on some systems. Not only is it inconsistent
but feels like we're leaning on legacy X too much.
It also became apparent those X cursors are unusably small on a 4K
display. We do have bigger ones f
Named cursors were not my first choice. There was some arguing when it
was proposed. I personally prefer a set enums, which matches what common
toolkits use:
https://developer.gnome.org/gdk3/stable/gdk3-Cursors.html#GdkCursorType
http://qt-project.org/doc/qt-5/qt.html#CursorShape-enum
ht
Unity8's stretchy/jiggly resizing was fix released 3 days ago apparently:
https://bugs.launchpad.net/qtmir/+bug/1497083
I had a fix proposed back in August but it was deferred in favour of
hybrid options that can support stretching on demand.
See also another issue kind of related that sti
It appears our xenial touch/armhf jobs are now passing regularly in CI!
Does anyone know how to make them mandatory jobs now? (ie. not ignored
any more by Jenkins if they fail)
--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mai
but it is not going to be installed
E: Unmet dependencies. Try 'apt-get -f install' with no packages (or
specify a solution).
On 18/12/15 10:45, Daniel van Vugt wrote:
It appears our xenial touch/armhf jobs are now passing regularly in CI!
Does anyone know how to make them mandat
Never mind. It appears someone has already flipped the switch recently
and made xenial-touch mandatory:
https://code.launchpad.net/~alan-griffiths/mir/fix-1521930/+merge/280838/comments/712027
On 18/12/15 11:06, Daniel van Vugt wrote:
Note that I said "regularly" and not "
Hi Jaeyong,
This is indeed the proper mailing list for such questions, but you can
also use https://answers.launchpad.net/mir
Good question, and I can kind of see how you might think Android is a
Mir client. But it is not.
The relevant stack is really:
Linux kernel and hardware
^
Androi
/01/16 13:37, 유재용 wrote:
> Thanks for the answer Daniel,
>
> Then, if I understand that two distinct display servers are running
> (both Mir and Surface flinger), is this correct?
>
> Jaeyong
>
> --- *Original Message* ---
>
> *Sender* : Daniel van Vugt
ity, could you tell me more about the early days
> before Mir?
>
> I'm wondering why you choose to remove surface flinger.
>
> Is there some constraint if you keep using Surface flinger and another
> graphics server?
>
> Thanks,
>
> Jaeyong
>
> ------- *Or
Support for Android apps is unlikely to happen any time soon.
You have to remember that Ubuntu Touch is not Android, but is a full
Ubuntu system. The fact that Ubuntu Touch uses an Android kernel is not
sufficient to support Android apps.
Although parts of Android remain and are visible in the Ub
That all said, there might be a short-cut. If you accept that it may
only work on Ubuntu phones that were formerly Android phones, then with
maybe some weeks/months of effort you might be able to build the
required translation layers for graphics and input etc...
On 08/01/16 09:21, Daniel van
I've been thinking we should probably address this before the next release:
https://bugs.launchpad.net/mir/+bug/1536662
And while Brandon has a fix prepared for USC to stop it happening at
login, it can still happen elsewhere:
https://bugs.launchpad.net/mir/+bug/1541188
So although what I'm ab
Someone should add(!) to the list of manual steps:
Check for open critical bugs. If a bug is critical it should block any
release:
https://bugs.launchpad.net/mir/+bugs?search=Search&field.importance=Critical
On 13/02/16 01:08, Cemil Azizoglu wrote:
Hi,
We talked about the release process an
Hmm, you sent that email a week before the latest Xmir changes landed
(12 Feb), that we need. Please check you've got them:
https://git.launchpad.net/~xmir-team/xorg-server/+git/xmir/
On 16/02/16 14:19, Timo Aaltonen wrote:
Reading through #ubuntu-mir backlog made me realize that this CFT
sho
level we can use for that
other than critical (or 'high' later as the project matures).
On 17/02/16 04:09, Kevin Gunn wrote:
inline comments
On Mon, Feb 15, 2016 at 7:19 PM, Daniel van Vugt
mailto:daniel.van.v...@canonical.com>>
wrote:
Someone should add(!) to the list o
Highjust needs to be a) outlined
somewhere & b) added to the release instructions like duflu originally
asked.
br,kg
On Tue, Feb 16, 2016 at 8:59 PM, Stephen M. Webb
mailto:stephen.w...@canonical.com>> wrote:
On 16-02-16 08:08 PM, Daniel van Vugt wrote:
> If a critical bug
/16 09:47, Kevin Gunn wrote:
the interesting thing is when you create a new vernacular within a team
- the rest of the world thinks you're saying Schedule to fix soon.
instead of
Fix now or as soon as possible.
and the rest of the world has no way to tell you Fix now or as soon as
possible.
And the bug backlog continues to stay under 300 and falling. Let's keep
that up!
On 23/02/16 23:42, Alan Griffiths wrote:
Mir 0.20 has landed in both Xenial and vivid-overlay
Enhancements:
o Allow screencasting to create a virtual output (for Miracast)
o Separate the protocol version n
If anyone finds themselves updating Mesa any time soon, please consider
fixing a bug or two that is affecting Mir:
https://bugs.launchpad.net/ubuntu/+source/mesa/+bugs?field.tag=egl-platform-mir
--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lis
Hey I've just noticed someone has subscribed all of mir-team to some
things mir-team mostly does not care about. Can we remove these
subscriptions?
https://bugs.launchpad.net/ubuntu/+source/google-glog/+subscriptions
https://bugs.launchpad.net/ubuntu/+source/systemtap/+subscriptions
There migh
Here's an observation: Two out of the top three hottest [1] Mir bugs are
Mir failing to start (USC/Unity8) due to insufficient graphics drivers:
Running in a VM:
https://bugs.launchpad.net/mir/+bug/1118903
Running with the Nvidia driver:
https://bugs.launchpad.net/mir/+bug/1553549
Not surprisi
://bugs.launchpad.net/mir/+bug/1118903
On 07/04/16 16:14, Andreas Pokorny wrote:
Hi,
On Wed, Apr 6, 2016 at 4:55 AM, Daniel van Vugt
mailto:daniel.van.v...@canonical.com>>
wrote:
Here's an observation: Two out of the top three hottest [1] Mir bugs
are Mir failing to start (USC/
Mir 0.21.0 is now released, and is in xenial too:
https://launchpad.net/mir/+milestone/0.21.0
https://launchpad.net/ubuntu/+source/mir
This release is mostly about bug fixes and not breaking ABIs leading up
to Ubuntu 16.04.
Possibly one of the more interesting developments is the improv
Mir 0.22.0 was released last week:
https://launchpad.net/mir/+milestone/0.22.0
With Ubuntu jumping from X to Y around the same time however, Ubuntu
might skip the 0.22 release if we have a 0.23 ready soon.
--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
Best I can recall, that feature is incomplete. But also the vast
majority of apps and toolkits don't care that it's still incomplete.
What we want is for it to be an actual region (union of rectangles) and
a client API to set the input region of a surface. So for example, a
non-rectangular sur
It's here. Almost four months in the making, Mir 0.24.0 is now released:
https://launchpad.net/mir/+milestone/0.24.0
If you're running yakkety, just update your system to get the 0.24.0
packages, along with a major Unity8 update.
--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify
A relative {x,y} would make sense and be much simpler than the currently
over-engineered "attach to a rectangle". In Xmir and toolkits we tend to
see empty rectangles being used:
MirRectangle placement = {dx, dy, 0, 0};
already. It should have been a simple relative {x,y} from the beginning..
That's an important point worth highlighting again:
"Wayland does prevent clients from knowing the absolute positions of
surfaces, but not for security reasons. More for being able to do
input transformations and non-traditional compositing."
Indeed compositing is potentially free-form if you ge
It feels like a hack to me. In order to maintain the assumption that
switching reports should not affect the behavior of the system they
would need to be multiplexed, effectively additive. So you add a number
of active report implementations for any given report interface without
them canceling
rts don't affect the control flow of the server. But
that's really just a naming issue -- if it was called SomethingObserver
then it would be OK. Just the word "report" makes me think it is
ineffectual to server behavior.
On 15/09/16 10:01, Christopher James Halse Rogers wrot
So actually... I now think it's OK providing the base class is named
*Observer. And only some implementations would be called *Report.
On 15/09/16 10:10, Daniel van Vugt wrote:
That's a good point. We don't need to change all the reporting locations.
I still don't like t
e...
And if a method is named "report_foo" then it would also need renaming
to something like "on_foo".
On 16/09/16 14:51, Alan Griffiths wrote:
On 16/09/16 02:51, Christopher James Halse Rogers wrote:
On Thu, Sep 15, 2016 at 12:11 PM, Daniel van Vugt
wrote:
So actually..
Whoever just created the 'trunk' series, please don't.
The Mir project is carefully (correctly) managed so that lp:mir just
points to the current focus of development, which is currently 0.25 and
soon 0.26.
For more details please see:
https://launchpad.net/mir/+series
--
Mir-devel mailing l
This email thread is a mess. Please enable comments in the doc.
Also I suggest making this a public discussion (CC'd).
On 04/10/16 00:46, Alan Griffiths wrote:
A document to start the discussion:
https://docs.google.com/document/d/1WryM41-PPg011iFIe7AFkG_FWdB4JloMNkDV1RxP36I/
--
Mir-deve
Hey team,
Just a timely reminder: The top two crashes for unity-system-compositor
this month are:
#1: nvidia-361 (LP: #1630456)
#2: VirtualBox (LP: #1584894)
https://errors.ubuntu.com/?package=unity-system-compositor&period=month
Admittedly we don't expect these to work just yet but let it b
7/10/16 23:24, Alan Griffiths wrote:
On 04/10/16 09:03, Daniel van Vugt wrote:
This email thread is a mess. Please enable comments in the doc.
Also I suggest making this a public discussion (CC'd).
Done.
--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubsc
Alternatively, we can skip the whole "what constitutes 1.0" discussion
and do the fashionable thing: just make version 0.26 into version 26. :)
On 13/10/16 09:59, Daniel van Vugt wrote:
My personal view is that we should drop this discussion.
We have been mindful of reducing ABI
Indeed this is something I'm trying to make progress on and have just
explained my plan in the comments here:
https://code.launchpad.net/~vanvugt/mir/mir-display-config-header/+merge/311246
It's disapproved right now but I think when people think about the
problem a bit more that will change.
g
in future.
On 28/11/16 09:33, Daniel van Vugt wrote:
Indeed this is something I'm trying to make progress on and have just
explained my plan in the comments here:
https://code.launchpad.net/~vanvugt/mir/mir-display-config-header/+merge/311246
It's disapproved right now but
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 of making it MirSurface after the existing
MirSurface becomes MirWindow is quite ambitious.
O
Indeed that was my position a couple of months ago. But I was swayed by
the team's bullishness about ABI/API breaks before "1.0". I mentioned
that was still only an ideal though...
More realistically I think we'll probably end up keeping MirSurface as
is, because that nomenclature has permeate
ure
what the ideal naming scheme is.
Can we avoid having three objects and somehow keep it at two? Isn't
MirBufferStream going to be just a specific case/mode of a MirRenderSurface?
On 02/12/16 09:34, Daniel van Vugt wrote:
Indeed that was my position a couple of months ago. But I was s
Hi all,
I spent a while today taking latency measurements of various Mir
releases and branches to check we're on the right track. You might find
the resulting chart interesting...
https://docs.google.com/spreadsheets/d/1RbTVDbx04ohkF4-md3wAlgmxbSI1DttstnT6xdcXhZQ/pubchart?oid=1566479835&forma
rval 0" is swapinterval 0 which
means all vsync is ignored...and it's all based on buffer availability?
br,kg
On Wed, Dec 14, 2016 at 5:22 AM, Stephen M. Webb
mailto:stephen.w...@canonical.com>> wrote:
On 2016-12-14 04:52 AM, Daniel van Vugt wrote:
>
> I sp
All,
Please try to keep merge proposals under a couple thousand lines in
size. Obviously it's not always possible, but I'm not convinced we're
trying our best to achieve it.
One thing I've noticed with Mir regressions is that often they come from
large changes of 1000 lines or more. And when
Mir 0.25.0 is released, and is in zesty too:
https://launchpad.net/mir/+milestone/0.25.0
https://launchpad.net/ubuntu/+source/mir
--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/mir-devel
Hi Michal,
We welcome all new volunteers to work on Mir. You can find more
information here:
http://unity.ubuntu.com/mir/0.25/index.html
and please do help out with any bugs that interest you:
https://bugs.launchpad.net/mir
As for paid work, that is a different question. I'm not aware of a
Hi Darren,
Touchscreen settings are on the way, but not here yet:
https://code.launchpad.net/~andreas-pokorny/mir/add-touchscreen-settings/+merge/316314
And I can think of two open bugs related to incorrect input axes, that
might relate to the problems you experience:
https://bugs.launchp
Mir 0.26 is now released and is also released in Ubuntu 17.04 zesty.
https://launchpad.net/mir/0.26/0.26.0
https://launchpad.net/mir/0.26/0.26.1
https://launchpad.net/ubuntu/+source/mir
--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.
ully optimized
and are about one frame higher than those charted values which are for
native EGL apps on desktop. And more improvement is theoretically
possible after that (e.g.
https://www.khronos.org/registry/OpenGL/extensions/NV/GLX_NV_delay_before_swap.txt).
- Daniel
On 17/02/17 10:29, D
There is still an occasional stutter in Mir 0.26.1 that comes and goes
in Unity8. If you want a workaround for that without waiting for the
next release, it's documented here:
https://bugs.launchpad.net/mir/+bug/1666372
- Daniel
On 20/02/17 16:15, Daniel van Vugt wrote:
In terms of
We may need to omit clang builds for a little while...
https://bugs.launchpad.net/bugs/1671370
--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/mir-devel
I know device screens turn black/off during testing, and it can be a
problem. I use a simple workaround for that when trying new Mir binaries:
$ sudo stop repowerd
$ mirbacklight# (or mirbacklight 99)
On 25/03/17 05:35, Florian Leeber wrote:
Hello All,
I am faithfully trying to port the
Mir 0.27.0 is finally released and is also in Ubuntu 17.10 artful.
https://launchpad.net/mir/0.27/0.27.0
--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/mir-devel
301 - 384 of 384 matches
Mail list logo
