All,
We continue to get a lot of large (~1000 lines) proposals. You might
notice these are very slow to get reviewed and land. The biggest reason
(I think) being that no one wants to stop work for a few hours to review
each revision of each large proposal.
So in the interests of faster revie
Hi all,
I've just moved tag v0.1.4 back to r1330 which is where that release
actually happened:
https://launchpad.net/mir/+milestone/0.1.4
To solve the annoying conflicting tags message just:
bzr pull --overwrite
Remember the development branch is for upstream Mir and is independent
of w
It's been four weeks since 0.1.4 so here's something even better :)
https://launchpad.net/mir/+milestone/0.1.5
--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/mir-devel
Hi all,
I've just moved tag v0.1.4 back to r1330 which is where that release
actually happened:
https://launchpad.net/mir/+milestone/0.1.4
To solve the annoying conflicting tags message just:
bzr pull --overwrite
Remember the development branch is for upstream Mir and is independent
of w
Joe,
Thanks for pointing that out. I'm not sure if it's an intentional
change, perhaps mterry can answer. In the mean time I've logged a bug
for it:
https://bugs.launchpad.net/ubuntu/+source/unity-system-compositor/+bug/1280924
I have seen some people like XMir in its old (saucy) form becaus
Nice.
And this command works too (with BGRA as well):
mplayer -fixed-vo -demuxer rawvideo \
-rawvideo fps=60:w=1920:h=1200:format=bgra /tmp/*bgra
Although it renders in a jerky way.
To create a lossless video file which plays back more realistically:
mencoder -demuxer rawvideo \
-rawvideo f
ngle video file instead of many separate images. There are also
performance problems:
https://bugs.launchpad.net/mir/+bug/1280938
But these are all things to work on...
- Danirl
On 17/02/14 12:32, Oliver Ries wrote:
On Sun, Feb 16, 2014 at 7:56 PM, Daniel van Vugt
mailto:daniel.van.v...@canoni
It's unlikely many people have noticed, but Mir's bug count has hovered
surprisingly reliably between 180 and 200 since mid last year.
It seems we're in a cycle of:
1. Bug count nears 200
2. We do a point release
3. Bug count drops to 180+.
4. Repeat
Given that 72 bugs are presently "Hi
g said, I'll schedule some time to do a good scrubbing for
state & priority.
As such, I might be aggressive on the closure of bugs...so please,
reopen & comment if I happen to conclude a bug you still think is valid.
br,kg
On Wed, Feb 19, 2014 at 8:00 PM, Daniel van Vugt
mailto:
If you think you're a guru of C++ exceptions (particularly within
threads), then please have a look at this:
https://bugs.launchpad.net/mir/+bug/1237332
- Daniel
--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/m
Mir 0.1.6 was tagged last week. Sorry for the delay in announcement as
we didn't have the release notes written :)
https://launchpad.net/mir/+milestone/0.1.6
Also, progress on the next point release is being made at what looks
like record pace, which is exciting:
https://launchpad.net/mir/+m
I notice how non-trivial it is to update all the projects, rebuilds and
packages every time we need to integrate a new Mir release into touch.
But we could make this much easier if the Mir team consciously separated
ABI-break releases from smaller (and more frequent) minor releases. This
would
. We don't have any
client ABI changes on the horizon just yet, but when we do that can form
the basis of choosing "1.0.0".
- Daniel
On 07/03/14 14:42, Daniel van Vugt wrote:
I notice how non-trivial it is to update all the projects, rebuilds and
packages every time we need
unity-mir,
platform-api, & unity-system-compositor. I think Robert was going to
chase a solution to do this with our jenkins jobs used on our
dev-branch. And, I hope he beats me in that race :) as the jenkins runs
have the android driver capability.
br,kg
On Sun, Mar 9, 2014 at 10:58 PM, Dan
e jenkins scripts to
designate each branch as a abi-breaking or not.
Kevin
On Mon, Mar 10, 2014 at 7:20 PM, Daniel van Vugt
mailto:daniel.van.v...@canonical.com>>
wrote:
Yeah the removal of "configure_output" coming in Mir 0.1.7 is a good
example. As I did that, I will d
You know it's a feature of MirWaitHandle that multiple threads can and
do wait on the same handle? We rely on this feature; I forget where.
But that means your actual wait call can't free the wait object. More
wait calls can and will come along and use it later (from different
threads even).
ization. I think we should solve bug
1194384 first.
On 13/03/14 10:00, Christopher James Halse Rogers wrote:
On Thu, Mar 13, 2014 at 9:54 AM, Daniel van Vugt
wrote:
You know it's a feature of MirWaitHandle that multiple threads can and
do wait on the same handle? We rely on this feature;
Today I noticed an opportunity in which we had no serious bug fixes
waiting to land and seized it as a good place to tag v0.1.7:
https://launchpad.net/mir/+milestone/0.1.7
Version 0.1.7 contains several important bug fixes amongst other things.
--
Mir-devel mailing list
Mir-devel@lists.ubun
All,
I've been trying to keep my hands out of the compositor/renderer stuff
recently while alan_g and kdub move large parts around, but I keep
thinking of a nicer design and wonder if anyone's thought about it...
Presently we have:
DefaultDisplayBufferCompositor implements bypass decision log
OK, that proposal does have problems too.
But still I'd like to discuss the possibility that "Renderer" classes
should not exist. They should (somehow) be part of a hierarchy of
"Compositor" classes.
- Daniel
On 20/03/14 11:53, Daniel van Vugt wrote:
All,
I&
shells above them) might want to have some ability
to "program" the gl renderer for "some effects" strive to keep this
interface tinker-toyish. Or do we say if someone wants more they
replace/override our GLRenderer/GLCompositor?
br,kg
On Thu, Mar 20, 2014 at 12:57 AM, Da
This topic sounds like what I've been working on - moving the pieces
around so that anything and everyone can play nicely with Mir. It's
really an evolution toward reaching some common interface that Unity8/Qt
and other pure OpenGL shells could use simultaneously.
On kdub's points:
> Does it
een the compositor and the GL code. At some point it
was made public and overridable, and became a much bigger/more important
interface than we originally intended
On Mon, Mar 31, 2014 at 6:38 AM, Kevin Gunn mailto:kevin.g...@canonical.com>> wrote:
On Sun, Mar 30, 2014 at 9:06 PM, Da
All,
We're almost at final freeze [1]. However Mir 0.1.8 requires one or two
more fixes before it gets tagged. In the mean time, please try to avoid
top-approving anything that's not a critical fix, until it's tagged.
- Daniel
[1] https://wiki.ubuntu.com/TrustyTahr/ReleaseSchedule
--
Mir-de
"critical fix" means critical bug fixes, and not enhancement/feature work.
But I just tagged. So no need to hold back anything now...
On 02/04/14 16:47, Alan Griffiths wrote:
On 02/04/14 04:03, Daniel van Vugt wrote:
We're almost at final freeze [1]. However Mir 0.1.8 requ
Mir 0.1.8 has now been released. Full details are on the milestone page:
https://launchpad.net/mir/trusty/0.1.8
--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/mir-devel
Original Message
Subject: [Bug 1256116] Re: Documentation instructs to install the
package unity-system-compositor, but this is not sufficient for having Mir
Date: Thu, 03 Apr 2014 09:36:51 -
From: Thomas Hellström <1256...@bugs.launchpad.net>
Reply-To: Bug 1256116 <1256
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 every day or so. If you can't keep up with that then abstain or set WIP.
- Daniel
On 15/04/14
All,
Please remember to assign a bug to yourself before embarking on any
serious progress toward it. Several times this past week I've found
other people working on the same bugs as me, because people are
forgetting to update or check bug status/assignee. Duplicating effort is
of course frust
k to assign and unassign if things change, and to even
put a comment in a bug with any of your new discoveries :) scnr
br,kg
On Wed, Apr 23, 2014 at 8:45 PM, Daniel van Vugt
mailto:daniel.van.v...@canonical.com>>
wrote:
All,
Please remember to assign a bug to yourself before embarki
It does kind of work now, providing you honor the limitation of not
producing and consuming at the same time. And it can easily be fixed to
work adequately (e.g. for dumb clients like mir_demo_client_fingerpaint
or static raster image windows).
I would rather just implement it. It's trivial to
If you're using a touch device with 60Hz display, the glitches you
notice in 0.1.9 should be minimal. But if you're one of the rare people
with a refresh rate significantly different to 60Hz, then it might be a
better idea to stick with 0.1.8. Read on in:
https://bugs.launchpad.net/mir/+bug/130
Mir 0.1.9 has now hit utopic:
https://launchpad.net/ubuntu/+source/mir
Although the landing process must have changed because the 0.1.9
packages were released without anything landing in lp:mir yet(!?).
On 30/04/14 21:17, Kevin Gunn wrote:
Hi all,
As some may have been following, we've taken
Does anyone have a preference on which direction to go with:
https://bugs.launchpad.net/mir/+bug/1293944
?
I can imagine either solution proposed in the bug should work. Maybe
someone can think of a third option?
Regardless of the solution though it will take multiple releases to see
the b
n Thu, May 1, 2014 at 2:08 AM, Michał Sawicz
mailto:michal.saw...@canonical.com>> wrote:
On 01.05.2014 08:03, Daniel van Vugt wrote:
> Although the landing process must have changed because the 0.1.9
> packages were released without anything landing in lp:mir yet(!?).
Sure, not disastrous. Just that fixes documented (in the proposal) as
being fixed in "0.1.9" may not actually have made it into the package.
So inaccurate. It's nice to have accurate info about where things are
fixed :)
On 02/05/14 14:46, Michał Sawicz wrote:
On 02.05.2014 03
All,
I'd like (in the somewhat distant future) for us to be able to run Mir's
tests under helgrind [1] so that we can automatically detect races in
continuous integration.
It's not going to be a short journey, as there's a fair amount of errors
to fix yet. They're mostly benign but the noise
On 13/05/14 13:55, Christopher James Halse Rogers wrote:
On Tue, May 13, 2014 at 1:52 PM, Daniel van Vugt
wrote:
All,
I'd like (in the somewhat distant future) for us to be able to run
Mir's tests under helgrind [1] so that we can automatically detect
races in continuous integration.
t's a
human problem :)
If there are some "safe races" floating around, I think it's worth the
pain to be forced to assess and deal with them individually.
On 13/05/14 14:34, Christopher James Halse Rogers wrote:
On Tue, May 13, 2014 at 4:21 PM, Daniel van Vugt
wrote:
I was hoping we could resolve most if not all the bugs marked as
[regression] before rolling 0.2.0:
https://launchpad.net/mir/+milestone/0.2.0
Two of them were known at the time of releasing 0.1.9 and I personally
think we should wait until most of the regressions have fixes landed.
Most of
All,
We branched this yesterday:
lp:mir/0.2
It's the place where versions 0.2.* will be stabilized and released
from. Meanwhile, all changes should still go to development-branch first.
So there are two target milestones open at present:
0.2.0 - Fixes already applied to the 0.2 stable
Sounds better to just pass buffers around although I'm not keen on any
change that doesn't make progress on the performance bottleneck LP:
#1253868. The bottleneck is the swapping/exchanging approach which
limits the client to holding only one buffer, so I don't think it's a
good idea for new d
swap buffers would no longer have to wait for a round-trip before
returning and would instead be almost instant.
On 09/07/14 10:00, Daniel van Vugt wrote:
Sounds better to just pass buffers around although I'm not keen on any
change that doesn't make progress on the performance bottlene
e out the surface(Id) from the Buffer struct.
On 09/07/14 15:41, Daniel van Vugt wrote:
Note that we're working on making double-buffering the default again and
triple the exception. In that case fixing LP: #1253868 may seem
pointless, but it is surprisingly still relevant. Becau
ng any protocol change from next_buffer()
needs to support parallelism and not be so synchronous.
- Daniel
On 09/07/14 16:08, Daniel van Vugt wrote:
Oops. I keep forgetting that the new BufferQueue disallows the
compositor to own less than one buffer, so there would no longer be any
benefit to
on giving empty buffers back to the clients to allow them to have a
"queue" of empty buffers at their disposal (i'm not sure if RAOF is
correct or duflu in that its "synchronously waiting for a round trip
every swap"...can we already have an empty buffer queue on the client
sid
(9-12ms)
+1 on giving empty buffers back to the clients to allow them to
have a "queue" of empty buffers at their disposal (i'm not sure
if RAOF is correct or duflu in that its "synchronously waiting
for a round trip every swap"...can we alr
I notice, as predicted, we had to change the development focus back to
"utopic" despite that being obviously wrong:
https://launchpad.net/mir
It also makes the milestone graph misleading and the latest download
link wrong...
This was expected because the branch alias lp:mir is dynamically d
You know we could just let lp:mir/0.5 be the development branch and be
more careful about noticing ABI breaks (at which point we must branch).
Then everyone wins and lp:mir would be the development branch as well as
one for packaging in Ubuntu-next.
So long as distro releases didn't happen wit
I am assuming that RTM != Utopic. RTM would be more stable fixed on 0.4
while Utopic would be >=0.5.
On 11/07/14 14:51, Daniel van Vugt wrote:
You know we could just let lp:mir/0.5 be the development branch and be
more careful about noticing ABI breaks (at which point we must branch).
T
untu could use that setting and know to package Utopic from
lp:mir/0.4
On 11/07/14 15:12, Cemil Azizoglu wrote:
So you mean make devel == trunk. Now you've opened a can of worms... :-)
On Fri, Jul 11, 2014 at 9:53 AM, Daniel van Vugt
mailto:daniel.van.v...@canonical.com>>
wrote:
Good news. I've done some visual testing and there definitely is visibly
reduced lag from double-buffering.
My previous argument was both right and wrong:
"Even the slightest pause then, and you can be certain that the "ready"
sub-queue is emptied and thus it's only one frame lag from client to
So far we've been talking about RTM as if it's out-of-band. Something
that's happening sooner and needs to be more mature than the Mir in
utopic even.
So where/how is RTM being built if it needs to be separate to utopic?
--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or u
Sounds like a reasonable request.
As a matter of purity Mir has tried to hide compositor information like
screen position from clients, which is otherwise a good idea.
Until now we've dithered between two approaches:
(a) Support arbitrary 3D transformations but only support input
correctly
= mir_surface_coord_to_screen_coord(0, 0);
to support all future use cases, while also making like maximally simple
for testers of 2D shells right now :)
On 22/07/14 09:15, Daniel van Vugt wrote:
Sounds like a reasonable request.
As a matter of purity Mir has tried to hide compositor information like
screen position from
"making *life* maximally simple"
On 22/07/14 09:26, Daniel van Vugt wrote:
What we could do is map point-to-point so as to be ready for correctly
supporting arbitrary 3D transformations of the surfaces being touched,
but let the shell itself make the assumption that it only eve
If accessibility and Autopilot can live with a point (centre of a
widget) rather than needing an accurate region then we can just deal in
one point per widget. And that keeps anpok's dream alive of perfect
input mapping in 3D shells :)
On 22/07/14 15:52, Christopher James Halse Rogers wrote:
I think we can make QWidget::mapToGlobal() work pretty easily. It just
requires a new function in libmirclient under the hood first.
That's such a simple task, we should just do it. If it's helpful to
accessibility then great. But I expect accessibility to require more
work later.
On 23/07/
While events are being injected into evdev at the kernel level, you do
have to know screen coordinates of the window in the least, so touches
match up. That makes Mir's sharing the window position important.
We could take Mir out of the equation if:
(a) The event injection moved up the stack;
e mapping stuff only cares about the real
surface location.
So there don't seem to be any practical problems other than us wanting
to keep private information mostly hidden.
On 24/07/14 13:52, Christopher James Halse Rogers wrote:
On Thu, Jul 24, 2014 at 12:03 PM, Daniel van Vugt
wrot
We currently have no logging in our codebase outside of the 3rd_party
android code.
Yes we do. Just remember to re-use or enhance it:
include/shared/mir/logging/logger.h
src/shared/logging/dumb_console_logger.cpp
--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubs
07/14 14:31, Christopher James Halse Rogers wrote:
On Thu, Jul 24, 2014 at 4:01 PM, Daniel van Vugt
wrote:
Just remember to map points like the Qt interface does:
Point screen_coord = mir_surface_coord_to_screen(surface,
client_coord);
So we are covered for arbitrary 3D transformations (
After a long sleep, the Mir docs web site is now getting updated daily
with the latest documentation from the source:
http://unity.ubuntu.com/mir/index.html
That makes it as current as possible. If you find things that are out of
date (like the XMir information seems) then that's a bug to log
This CI error seems to be blocking all proposals to the 0.5 branch we've
made this week. Any ideas?
touch /.setup_complete
...
rm: cannot remove '.setup_complete': No such file or directory
--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.u
Oh, it's blocking at least one proposal to devel too:
rm: cannot remove '.setup_complete': No such file or directory
remote object '/.setup_complete' does not exist
SETUP FAILED - CAN'T CONTINUE
On 25/07/14 11:40, Daniel van Vugt wrote:
This CI error seems to be
OK, I admit it. Recalculating the scene graph elements to display on
every frame is now hurting. If you add up the bottlenecks found so far
it accounts for around 20% of Mir's CPU usage (with a low number of
surfaces even).
https://bugs.launchpad.net/mir/+bugs?field.tag=performance
Seems like
Following on from the proof of concept in May, native Mir support for
GTK apps has landed in utopic-proposed (3.12.2-0ubuntu6):
https://launchpad.net/ubuntu/+source/gtk+3.0
Basic stuff works but more work is required, if anyone wants to help out
with the immediate major stuff:
1. Cursor AP
Also note this means there are projects "outside the silo" that depend
on MIRCLIENT_ABI 8 by direct linkage to "libmirclient.so.8". Be very
wary if you ever want to change the client ABI from now on...
On 04/08/14 10:17, Daniel van Vugt wrote:
Following on from the pro
And it's been promoted now! If you're running utopic then your GTK apps
can render directly to a Mir server (with the right environment variables).
Still, please consider this a tech preview. There are significant bugs
that need fixing yet.
On 04/08/14 10:17, Daniel van
crashing (SIGSEGV) for me. So I'll have to
look into what has changed.
On 06/08/14 11:59, Oliver Ries wrote:
On Tue, Aug 5, 2014 at 8:43 PM, Daniel van Vugt
mailto:daniel.van.v...@canonical.com>>
wrote:
And it's been promoted now! If you're running utopic then your GT
ncounter:
* Menus
* Dialogs
* Non-arrow cursors
* Mir touch event support not implemented - mouse only?
* Random crashes/non-starting apps
But it's still nice to have something on screen. And to be able to run
utopic's desktop apps unmodified inside Mir is quite nice.
On 0
BTW, I've been maintaining branched bugs tasks to match up with the
actual point where the code was branched (tag "br0.6" in devel == r1806).
So any fixes that land on devel after r1806 should have two separate
tasks: 0.6 and 0.7, to accurately represent where and if a fix got
applied to each
Discussion moved to: https://bugs.launchpad.net/mir/+bug/1355005
On 09/08/14 09:22, Cemil Azizoglu wrote:
Sync'ed up 0.6 with devel@r1831 since we were in TRAINCON-0. Everything
built successfully.
Using image #179 with 0.6, mir itself works (i.e. mir-demos & nested),
but USC has the following
There is a 5th option which would satisfy more (not all) of the people
mentioned:
5. Shell mediates if a client has permission to ask for surface
coordinates. The API is restricted by default. The API _does_not_ return
the top-left corner of the surface. Instead it maps a local surface
coordi
int* screenx, int* screeny);
Admittedly that only works for your own surfaces created in your own
process.
On 12/08/14 10:56, Christopher James Halse Rogers wrote:
On Tue, Aug 12, 2014 at 12:33 PM, Daniel van Vugt
wrote:
There is a 5th option which would satisfy more (not all) of
I only noticed yesterday that when a change is cross-compiled for armhf
even in the lp:mir/0.5 tree (my phone has Mir 0.5.1) that the resulting
binaries just made Unity8 crash. This is obviously not right because I
had chosen the 0.5 series with the same Mir ABI levels as the phone is
using.
The function Chris mentions would indeed allow us to implement the Qt
function and make it "just work" [QWidget::mapToGlobal()].
Go nuts, Chris :)
On 14/08/14 07:51, Thomi Richards wrote:
On Thu, Aug 14, 2014 at 11:31 AM, Christopher James Halse Rogers
mailto:ch...@cooperteam.net>> wrote:
I think a MirBool is enough. Although if anyone does implement the Qt
function later then that one doesn't have such luxury. You would have to
return some invalid Point for Qt.
On 14/08/14 16:25, Alan Griffiths wrote:
On 14/08/14 00:31, Christopher James Halse Rogers wrote:
mir_debug_surfa
Welcome to a new week. CI is working now, so remember to kick Jenkins to
turn all your "Needs fixing" into "Approved".
--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/mir-devel
Can we get some more eyes on this?
https://code.launchpad.net/~vanvugt/mir/butter/+merge/230767
It's really important to improving phone usability...
--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/mir-devel
How very timely. That's exactly the "touch responsiveness" enhancement
that we just released in Mir 0.7.0 on 1 September :)
And in fact, the scenario discussed in the blog is exactly what the new
test case "rendering_does_not_lag_behind_input" covers:
http://bazaar.launchpad.net/~mir-team/mir
Today we have a new curve-ball to block everyone's branches. Please look
at this ASAP
https://code.launchpad.net/~vanvugt/mir/fix-1369389/+merge/234613
--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/mir-deve
landed the touch
processing stuff. I hadn't noticed that Qt landed this change though, nice to
know.
-G
On 15/09/14 03:20, Daniel van Vugt wrote:
How very timely. That's exactly the "touch responsiveness" enhancement
that we just released in Mir 0.7.0 on 1 September :)
And in f
Does anyone know how to fix this? The CI failure is holding up a few
branches...
Traceback (most recent call last):
File "/usr/bin/phablet-config", line 327, in
main()
File "/usr/bin/phablet-config", line 324, in main
args.func(adb, args)
File "/usr/bin/phablet-config", line 147,
-config -s $ANDROID_SERIAL welcome-wizard --disable
exec_with_adb 'touch /userdata/.writable_image'
exec_with_adb 'reboot'
sleep 10
adb -s $ANDROID_SERIAL wait-for-device
sleep 65
phablet-config -s $ANDROID_SERIAL edges-intro --disable
phablet-network -s $ANDROID_SERIAL
On Mon, Sep 15, 201
Hey all,
I've found the right person and got the CI team to change train landings
from using "lp:mir" to monitoring "lp:mir/ubuntu" instead. So future
Ubuntu release proposals should target lp:mir/ubuntu.
So we are free to use alias "lp:mir" for ourselves again. "lp:mir" will
now always be a
Noting that the hiding of headers in Mir 0.8, while causing some
teething problems, has been very successful in reducing ABI bumps.
Although we did bump ABIs in 0.8 it wasn't until late in the cycle that
changes were committed needing any bumps. So that's a great improvement.
I do like the ide
If you can find the time, I highly recommend sitting through John
Carmack's recent talk from the Oculus conference:
http://www.youtube.com/watch?v=nqzpAbK9qFk
It's interesting to see that the performance and latency problems Oculus
is solving for VR and Android are often the same issues we face
Thomas,
Yes, log a bug please.
All evdev motion should work (eventually) to some usable extent.
Although I have observed some laptop touchpads simply don't work (e.g.
in the presence of a TrackPoint). Sounds like the same kind of issue. We
do need to revisit Mir's range of motion device suppo
It's worth noting Android-x86 seems to have the same input bugs, because
it's the same input code :)
But for Ubuntu we do eventually need better pointing device support than
Android provides right now.
On 02/10/14 17:33, Daniel van Vugt wrote:
Thomas,
Yes, log a bug please.
Joseph,
We would like to get to the bottom of your high CPU problem and fix it.
Can you by any chance force a core dump of the spinning process when
it's happening?... Like with:
kill -ABRT
If that fails to generate a problem report, then please log it here:
https://bugs.launchpad.net/xmi
All,
You might find it useful to know that the Mir client performance report
(new in 0.8) doesn't only work for client apps, but also works for
nested servers (which themselves are clients):
bin/mir_demo_server_minimal -f /tmp/outer & sleep 1 ; env
MIR_CLIENT_PERF_REPORT=log bin/mir_demo_ser
(14.10).
- Daniel
On 08/10/14 06:56, Joseph Rushton Wakeling wrote:
On 06/10/14 03:36, Daniel van Vugt wrote:> Joseph,
We would like to get to the bottom of your high CPU problem and fix
it. Can you
by any chance force a core dump of the spinning process when it's
happening?...
Like w
f the problems you're
experiencing, any fixes for Mir will probably never be backported to 14.04.
On 09/10/14 04:12, Joseph Rushton Wakeling wrote:
On 08/10/14 03:36, Daniel van Vugt wrote:
Also, I just noticed you say "14.04". Mir on 14.04 is effectively
unsupported and now
g has a lot of these lines:
[ 51.495859] traps: compiz[2730] trap invalid opcode
ip:7f186f59c6e5 sp:7fff8e230020 error:0
Any idea?
2014-10-09 3:42 GMT+02:00 Daniel van Vugt mailto:daniel.van.v...@canonical.com>>:
Absolutely, if you want stability then stick to 14.04.
Liking the idea of a generalised approach... Although on first glance
this does not sound like a real function name:
mir_connection_platform_operation()
I know we want to be generic, but that sounds somehow overly generic
with "platform operation". Maybe we need a better function name there.
Remember a few of us at least aspire to retiring Protobuf eventually.
One way or the other. Don't get too tied to it.
On 14/10/14 16:45, Alexandros Frantzis wrote:
On Tue, Oct 14, 2014 at 09:14:46AM +0100, Alan Griffiths wrote:
On 14/10/14 08:14, Christopher James Halse Rogers wrote:
We're
Missing (possibly just due to over-simplification in the high level design):
* Non-input events
* Event struct size field (would allow for compression, omitting unused
array entries).
On 21/10/14 12:18, Robert Carr wrote:
Notes from me and chris
--
Mir-devel mailing list
Mir-devel@lists
neric size (in bytes)
field. So the code that's passing around (and putting on the wire)
MirEvents knows how big each one is.
On 21/10/14 13:30, Christopher James Halse Rogers wrote:
On Tue, Oct 21, 2014 at 1:10 PM, Daniel van Vugt
wrote:
Missing (possibly just due to over-simplificat
You have input-specific fields "EventId", "DeviceId", "EventTime" in the
generic event structure. These fields only apply to input events.
So your "MirEvent" needs to be called "MirInputEvent" (slightly nicer
than "MirDeviceEvent") and MirInputEvent is a variation of a generic
MirEvent.
On
101 - 200 of 384 matches
Mail list logo
