Re: The case for a "SceneGraph"

[Daniel van Vugt]

Yes indeed the shell is meant to implement the scene graph. But that 
implementation is still inside libmirserver. It needs to be pulled out 
of the server library.


Interface:   mir::compositor::Scene
Implementation:  mir::surfaces::SurfaceStack

That implementation should go in the shell, whenever feasible. Though 
there is a reasonable argument for keeping a nice fallback SurfaceStack 
implementation in libmirserver for simple shells.



On 19/07/13 17:55, Michał Sawicz wrote:

W dniu 19.07.2013 01:58, Gerry Boland pisze:

What shell will need is, for every surface, the following properties:
- x, y, z, width, height
- opacity, visible
- scale
- ability to set more complex transformations/shaders, so can desaturate
surface colours, do more advanced animations, blurs etc.

Shell will implement window management through QML. I would like to have
as much flexibility with surfaces as the Qt Scenegraph gives me with
Items [1] [2].


FWIW every time I think of a list of things we'll need to communicate to
the compositor, it feels like we're doing something wrong. We'll
basically have two SceneGraphs (one of the shell, one Mir-internal) and
will have to keep them in sync.

This, I feel, might make it really difficult to achieve some UX that
we're wanting for. It also makes it difficult to think security when
letting others render to the shell (think video/map in dash, custom
infographics, even OSK).

I'm sure it was discussed before, but can you guys please give me a
summary why it's not possible to just keep the shell's scenegraph (in
our case the Qt/QML one) in play? Or if there maybe is another way for
shell's scenegraph to another process's surface for "internal" composition?

Cheers,





--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/mir-devel

Re: The case for a "SceneGraph"

[Daniel van Vugt]

Sorry, no. It's all in-process and (so far) assumed that the shell pid 
== server pid.



On 19/07/13 18:40, Michał Sawicz wrote:

W dniu 19.07.2013 12:02, Daniel van Vugt pisze:

Yes indeed the shell is meant to implement the scene graph. But that
implementation is still inside libmirserver. It needs to be pulled out
of the server library.

Interface:   mir::compositor::Scene
Implementation:  mir::surfaces::SurfaceStack

That implementation should go in the shell, whenever feasible. Though
there is a reasonable argument for keeping a nice fallback SurfaceStack
implementation in libmirserver for simple shells.


Is what you're saying that it *is* planned to be possible to access
out-of-process surfaces in the shell's (Qt/QML for unity8) scenegraph?



--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/mir-devel

No Android for me

[Daniel van Vugt]

Is anyone else experiencing this?
https://bugs.launchpad.net/phablet-tools/+bug/1206369

It's preventing me from doing any Android work right now.

- Daniel

--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/mir-devel

Re: No Android for me

[Daniel van Vugt]

Nevermind. It's actually a Mir dev script bug killing adb :)


On 30/07/13 13:28, Daniel van Vugt wrote:

Is anyone else experiencing this?
https://bugs.launchpad.net/phablet-tools/+bug/1206369

It's preventing me from doing any Android work right now.

- Daniel


--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/mir-devel

Running Mir on phablet

[Daniel van Vugt]

Kevin, anyone,

I notice running Mir on the latest phablet images (Nexus 4) is still not 
foolproof. Half the time, when I stop Unity8, that completely blanks the 
screen which prevents any Mir server from starting.


Mir can only start, it seems, if the screen is not fully blanked. If it 
is blanked then I get permission errors (failed to unblank display), 
even running as root.


What's the trick/recommended approach? It seems my old tricks don't work 
any more now the phablet images are "flipped".


- Daniel

--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/mir-devel

Re: Running Mir on phablet

[Daniel van Vugt]

SurfaceFlinger actually coexists with Mir so long as it's not being used 
(Unity8). It's quite happy to let Mir flip buffers when it's not (stop 
ubuntu-touch-session USER=phablet).


My issue is that I can't start Mir if it happens that the screen has 
been turned off (locked/screensaver). Mir doesn't have the smarts to 
know how to turn it on. Unless I'm doing something wrong...


This issue was first reported as part of:
https://bugs.launchpad.net/mir/+bug/1188504


On 30/07/13 16:24, Kevin Gunn wrote:

Hey Daniel,
I'm no expert, but is there a chance you're fighting with
surfaceflinger...this is what the intended Kevin usually says.
Apparently its fairly stubborn about being killed (and tries
aggressively restart)

Also, mterry had put together some updated instructions
https://wiki.ubuntu.com/Touch/Testing/Mir
just in case things have change from what process you might be following.
it has some surface flinger related instructions at the bottom...hoping
it helps.

br,kg


On Tue, Jul 30, 2013 at 3:06 AM, Daniel van Vugt
mailto:daniel.van.v...@canonical.com>>
wrote:

Kevin, anyone,

I notice running Mir on the latest phablet images (Nexus 4) is still
not foolproof. Half the time, when I stop Unity8, that completely
blanks the screen which prevents any Mir server from starting.

Mir can only start, it seems, if the screen is not fully blanked. If
it is blanked then I get permission errors (failed to unblank
display), even running as root.

What's the trick/recommended approach? It seems my old tricks don't
work any more now the phablet images are "flipped".

- Daniel

--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com <mailto:Mir-devel@lists.ubuntu.com>
Modify settings or unsubscribe at:
https://lists.ubuntu.com/__mailman/listinfo/mir-devel
<https://lists.ubuntu.com/mailman/listinfo/mir-devel>




--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/mir-devel

Re: Running Mir on phablet

[Daniel van Vugt]

On the other hand, if you follow mterry's instructions for disabling 
surfaceflinger, the screen never locks. So it seems like a good 
workaround...


We should make the instructions [1] a bit clearer and add them to the 
docs in lp:mir.


[1] 
https://wiki.ubuntu.com/Touch/Testing/Mir#Switch_from_SurfaceFlinger_to_Mir



On 30/07/13 16:38, Daniel van Vugt wrote:

SurfaceFlinger actually coexists with Mir so long as it's not being used
(Unity8). It's quite happy to let Mir flip buffers when it's not (stop
ubuntu-touch-session USER=phablet).

My issue is that I can't start Mir if it happens that the screen has
been turned off (locked/screensaver). Mir doesn't have the smarts to
know how to turn it on. Unless I'm doing something wrong...

This issue was first reported as part of:
https://bugs.launchpad.net/mir/+bug/1188504


On 30/07/13 16:24, Kevin Gunn wrote:

Hey Daniel,
I'm no expert, but is there a chance you're fighting with
surfaceflinger...this is what the intended Kevin usually says.
Apparently its fairly stubborn about being killed (and tries
aggressively restart)

Also, mterry had put together some updated instructions
https://wiki.ubuntu.com/Touch/Testing/Mir
just in case things have change from what process you might be following.
it has some surface flinger related instructions at the bottom...hoping
it helps.

br,kg


On Tue, Jul 30, 2013 at 3:06 AM, Daniel van Vugt
mailto:daniel.van.v...@canonical.com>>
wrote:

Kevin, anyone,

I notice running Mir on the latest phablet images (Nexus 4) is still
not foolproof. Half the time, when I stop Unity8, that completely
blanks the screen which prevents any Mir server from starting.

Mir can only start, it seems, if the screen is not fully blanked. If
it is blanked then I get permission errors (failed to unblank
display), even running as root.

What's the trick/recommended approach? It seems my old tricks don't
work any more now the phablet images are "flipped".

- Daniel

--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com <mailto:Mir-devel@lists.ubuntu.com>
Modify settings or unsubscribe at:
https://lists.ubuntu.com/__mailman/listinfo/mir-devel
<https://lists.ubuntu.com/mailman/listinfo/mir-devel>






--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/mir-devel

Re: Mir client API extensibility

[Daniel van Vugt]

I strongly recommend against dividing libmirclient into many 
libmirclient*'s. It makes things much harder for people to understand 
and will lead to increased time wastage for users. Not to mention 
increased maintenance burden for us. And the third disadvantage is 
significantly increased code bloat from duplicate template 
instantiations across SO's. I don't see any good reason to divide 
libmirclient up right now...


It's possible you're also thinking about the imperfection of the 
mir_debug_ calls added recently. Those two particular functions could be 
unified and cleaned up under one:

   int mir_surface_get(MirSurface *s, MirSurfaceAttrib a);
which functionally exists already just under the hood of libmirclient.

- Daniel


On 15/08/13 11:19, Christopher James Halse Rogers wrote:

Or: Fragmenting Mir Clients The Right Way™

This is mainly a missive to get us to start thinking about how - and
whether - we want to handle extensibility in the Mir client API.

This is motivated by the observation that we currently have two
different targets for Mir: unity-system-compositor and Unity8. We
already have a bunch of client API that only makes sense for u-s-c
clients or Unity8 clients¹ but that is available to both because both
clients share the same API. I expect this to only get worse over time,
as both u-s-c and Unity8 gain features. This is also an impediment to
anyone else who wants to use Mir to write a compositor.

I think that having entry points in the client API that clients cannot
call is ugly, and we should work to avoid it.

I think this lends itself to an extension solution; the core bits of API
common to all clients - connection creation, surface creation, buffer
management, etc - live in mirclient, and the bits specific to the
environment live in mirclient-system and mirclient-session.

Clients would then link against the libraries they need, and we'd have
the ability to fail connections to compositors which do not support what
the client requires.

This leaves open the possibility of optional extensions; I've not got
strong opinions on them.

What do other people think about this? Do people share the feeling that
this is a problem to solve?

Chris

¹: For example:
mir_connection_apply_display_config only makes sense for u-s-c clients;
Unity8 clients should not be able to fiddle with the display
configuration in this way.

mir_surface_{get/set}_type make no sense for u-s-c clients, but are
obviously required for Unity8 clients




--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/mir-devel

Re: Mir client API extensibility

[Daniel van Vugt]

I also disagree with your examples...

> ¹: For example:
> mir_connection_apply_display_config only makes sense for u-s-c clients;
> Unity8 clients should not be able to fiddle with the display
> configuration in this way.

Wrong. We will need some kind of control-center client which can 
configure and change the display config. That is true for Unity8, any 
shell, games, etc.


>
> mir_surface_{get/set}_type make no sense for u-s-c clients, but are
> obviously required for Unity8 clients
>

Right, so only USC has no use for mir_surface_{get,set}_type. But why 
care? For real toolkits speaking native mir (post-XMir), such functions 
are critical. Just because there's one use case which doesn't require a 
function, does not mean removing the function.


And again, the Mir libraries already have significant template bloat. We 
would need to have a very good reason to increase disk and memory 
footprints further by splitting libraries.


- Daniel


On 15/08/13 15:55, Christopher James Halse Rogers wrote:

On Thu, Aug 15, 2013 at 3:27 PM, Daniel van Vugt
 wrote:

I strongly recommend against dividing libmirclient into many
libmirclient*'s.



I wouldn't expect there to be many libmirclient*s; two would be my guess.

And it's not just mirclient - the server currently has to implement
these things. We've not yet got too much stuff that's obviously and
totally unnecessary in a given server, but I think we'll get some -
copy/paste and drag and drop spring to mind.


 It makes things much harder for people to understand and will lead to
increased time wastage for users. Not to mention increased maintenance
burden for us. And the third disadvantage is significantly increased
code bloat from duplicate template instantiations across SO's. I don't
see any good reason to divide libmirclient up right now...

It's possible you're also thinking about the imperfection of the
mir_debug_ calls added recently. Those two particular functions could be

‘2’

No, I'm not thinking about them at all, although that would be a nice
cleanup.

I'm thinking that we're currently required to support two different
use-cases with the same API, and I'm concerned that the intersection of
the APIs required by both use cases is going to become a smaller and
smaller part of the whole API.

We're going to need a drag-and-drop API and a copy-paste API; neither of
those are sensible for the system compositor. We're going to need a
surface *resize* API; even that makes no sense for the system compositor.

On the other side we've got the multihead configuration API, the write
end of which Unity8 will want to deny to all clients.


- Daniel


On 15/08/13 11:19, Christopher James Halse Rogers wrote:
> Or: Fragmenting Mir Clients The Right Way™
>
> This is mainly a missive to get us to start thinking about how - and
> whether - we want to handle extensibility in the Mir client API.
>
> This is motivated by the observation that we currently have two
> different targets for Mir: unity-system-compositor and Unity8. We
> already have a bunch of client API that only makes sense for u-s-c
> clients or Unity8 clients¹ but that is available to both because both
> clients share the same API. I expect this to only get worse over time,
> as both u-s-c and Unity8 gain features. This is also an impediment to
> anyone else who wants to use Mir to write a compositor.
>
> I think that having entry points in the client API that clients cannot
> call is ugly, and we should work to avoid it.
>
> I think this lends itself to an extension solution; the core bits of
API
> common to all clients - connection creation, surface creation, buffer
> management, etc - live in mirclient, and the bits specific to the
> environment live in mirclient-system and mirclient-session.
>
> Clients would then link against the libraries they need, and we'd have
> the ability to fail connections to compositors which do not support
what
> the client requires.
>
> This leaves open the possibility of optional extensions; I've not got
> strong opinions on them.
>
> What do other people think about this? Do people share the feeling that
> this is a problem to solve?
>
> Chris
>
> ¹: For example:
> mir_connection_apply_display_config only makes sense for u-s-c clients;
> Unity8 clients should not be able to fiddle with the display
> configuration in this way.
>
> mir_surface_{get/set}_type make no sense for u-s-c clients, but are
> obviously required for Unity8 clients
>
>

--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/mir-devel





--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/mir-devel

Re: Sam`s GDK-Mir Backend

[Daniel van Vugt]

Looking good. And for those who might be wondering, I believe that GTK 
without a theme loaded is meant to look like that :)



On 22/08/13 12:57, Leslie Zhai wrote:

Hi Sam, gtk3-demo WORKED :)

But there is still some bug need to fix, such as Invalid rectangle region.

Leslie


That looks like the fix I applied. Have you tried stepping through the
library to make sure it was conditionally compiled in?


On Thu, Aug 22, 2013 at 11:34 AM, Leslie Zhai mailto:xiangzha...@gmail.com>> wrote:

Hi Sam,

Did you fixed the gdkdisplaymanager without mir bug like this?

diff --git a/gdk/gdkdisplaymanager.c b/gdk/gdkdisplaymanager.c
index 075f507..84c07a4 100644
--- a/gdk/gdkdisplaymanager.c
+++ b/gdk/gdkdisplaymanager.c
@@ -60,6 +60,10 @@
 #include "wayland/gdkprivate-wayland.h"
 #endif

+#ifdef GDK_WINDOWING_MIR
+#include "mir/gdkprivate-mir.h"
+#endif
+
 /**
  * SECTION:gdkdisplaymanager
  * @Short_description: Maintains a list of all open GdkDisplays
@@ -270,6 +274,9 @@ static GdkBackend gdk_backends[] = {
 #ifdef GDK_WINDOWING_WAYLAND
   { "wayland",  _gdk_wayland_display_open },
 #endif
+#ifdef GDK_WINDOWING_MIR
+  { "mir",  _gdk_mir_display_open },
+#endif
 #ifdef GDK_WINDOWING_X11
   { "x11",  _gdk_x11_display_open },
 #endif

I using GDK_BACKEND=mir GTK_CSD=1 ./gtk/examples/hello-world
But still (lt-hello-world:6443): Gtk-WARNING **: cannot open
display: :0

I built the gtk ./autogen.sh --enable-mir-backend
--disable-wayland-backend ...
Did you disable  the wayland backend? it is useless.

Leslie


Hey Leslie,

I'm currently running it natively - you need to explicitly tell
GDK to use the mir backend.

./autogen.sh --enable-mir-backend ...
GDK_BACKEND=mir GTK_CSD=1 ./gtk/examples/hello-world

There was a bug for a little bit where the backend stub to pick
the mir backend in gdkdisplaymanager wasn't checked in to source
control, but I've fixed that now.

I've (mostly) fixed the display lag problem. Part of that is a
fix to the mir compositor so you'll need a recent (955+) revision
of that. There is still a condition where frame swaps can get out
of sync with input events which I'll look into soon.

Sam.


On Thu, Aug 22, 2013 at 11:17 AM, Leslie Zhai
mailto:xiangzha...@gmail.com>> wrote:

Hi Sam,

I came back to "just for fun open source project" from
business development.

I running Mir natively described in doc/using_mir_on_pc.md


$ sudo mir_demo_server
 - log in to VT 2
$ sudo chmod 777 /tmp/mir_socket
$ gtk/examples/hello-world
 - switch back to Mir

But (lt-hello-world:6443): Gtk-WARNING **: cannot open
display: :0

So did you test the GDK Mir backend using Mir natively way?
or whether directly using XMir?

Leslie


Hey Leslie,

Just wanted to update you on this - I've got a very (basic)
version of gtk+ up and running. Display, mouse and key
events should work to a limited extent. There is no support
for key modifiers or more complicated keys yet. I've also
disabled support for crossing events as Mir seems to send
mir_motion_event_hover_exit as soon as a mouse button is
pressed, which tends to confuse the toolkit (as I've
experienced in the past ...). I've also noticed that the
display lags a bit behind the input - I suspect this is
because frame clock support is also unimplemented, so we are
probably doing a buffer swap at the wrong point in the paint
cycle.

https://github.com/smspillaz/gtk/commits/wip/mir

Anyways, its something to look at (or submit pull requests!)
if you want.

Thanks for doing the initial work on this.

Sam.


On Thu, Aug 8, 2013 at 7:32 PM, Leslie Zhai
mailto:xiangzha...@gmail.com>> wrote:

Hi Sam,

You are welcome :) OK, I will git push to
https://github.com/gnome/gtk


Hi Leslie,

Excellent. What I'd suggest doing instead of creating a
new repo is instead creating a fork of
https://github.com/gnome/gtk so that changes will be
tracked on head (and not on a divergent branch).

I haven't pushed my changes anywhere primarily because
there's nothing particularly interesting  - just gdk
with a copypasted wayland backend with s/wayland/mir at
the moment. It might make sense for me to work on your
branch directly.

As for cursor and device support - I don't think that
this is particularly fatal to any kind of Mir work. It
should be possible to just function as though there is

Re: Proposal: Drop author fields from copyright headers

[Daniel van Vugt]

I think it does make sense to have author fields when they're accurate.

Hopefully people will have some pride in new source files they write. 
But more importantly, if the author field is accurate then you know who 
to ask about the code.


The issues we've had recently were just bzr getting confused from file 
renames and large chunks of code moving around. That should not be the 
norm though.



On 23/08/13 11:27, Robert Ancell wrote:

Hi all,

I'd like to propose we drop the author fields from the copyright headers
in Mir - they're very hard to keep up to date and more accurate
information can be retrieved using 'bzr annotate'. Chances are they
either only list the initial author or are copied and pasted from other
code [1].

Most people I've talked to in the team don't have any love for them -
anyone want to keep them?

--Robert

[1] http://bazaar.launchpad.net/~mir-team/mir/trunk/revision/1000




--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/mir-devel

Re: Suggestion: clarify on the wiki that Mir/XMir testing might imply some risks.

[Daniel van Vugt]

Mario,

Any documentation which asks you to use any PPA should also come with a 
warning: "This may break your system and you need to be knowledgeable 
enough to fix it if that happens."


Though, Mir no longer requires PPAs.

One could also argue such warnings should be in place for anyone who 
installs a pre-release of Ubuntu. I think it would make sense... We get 
a lot of bugs from people testing pre-release code but don't know how to 
recover from problems when they find them.


Thirdly, yes, if you need to follow any instructions from a Wiki to 
install something then that probably also indicates it's not ready for 
prime time and should have warnings.


I agree we need more warnings, in multiple places.

- Daniel


On 24/08/13 01:12, Mario Rugiero wrote:

Hi, my name is Mario Rugiero, I've been following the mail list since
one or two months ago, I think.
As the subject says, I think it would be wise to put a statement about
testing Mir/XMir right now, since Ubuntu is also aimed to common folks
that might not know software in development might contain bugs of
varying severity.
What I thought was just adding on the main Mir page such fact, and
pointing to the bug tracker (I see there is a link on the page, but it
only suggests to file the ones they find, not to check for which bugs
are already known) so novice testers may know which kind of things to
expect, and make and informed decision. Just an idea.

Thanks for your time.
Mario.




--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/mir-devel

uint32_t

[Daniel van Vugt]

I notice it's become fashionable to use lots of uint32_t in the toolkit 
headers. Is there a reason for this? It's not like we need to enforce a 
particular integer size for cross-platform communication...


- Daniel

--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/mir-devel

Re: Update Known Issues on Mir installation page?

[Daniel van Vugt]

Thanks Joe,

That's really an Ubuntu page which is not maintained by the Mir team.

We maintain: http://unity.ubuntu.com/mir/

However, of course we can and should fix the Ubuntu wiki where it needs 
fixing.


- Daniel


On 31/08/13 15:20, Joseph Rushton Wakeling wrote:

Hello Mir people :-)

Is it possible to update the list of Known Issues on
https://wiki.ubuntu.com/Mir/Installing in light of the latest Mir/XMir
code released?  These are given "as of 8/22/13" and you all have done a
lot of work since then!

In particular what's written about the VT switching security bug
 is confusing.  You link
to a branch

that has been merged, which might give the impression the bug has been
fixed.

On the other hand the bug itself is reported as being fixed in Mir but
not in XMir.  So, it would be nice to have a link to the branch where
the XMir work is taking place.

The Known Issues listed also include fix-released issues such as
multimonitor support and bypass composition.  So some
update/clarification may be useful here too.

I should add that personally the VT switching security issue is the one
that's stopping me from installing Mir (I have tried it out, albeit
briefly, via a startup disk).

Thanks for all the hard work, and best wishes,

 -- Joe



--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/mir-devel

Re: Update Known Issues on Mir installation page?

[Daniel van Vugt]

Joe,

The distortion around the mouse cursor is known:
https://bugs.launchpad.net/xmir/+bug/1218735

And the general skipping/freezing I think is covered by:
https://bugs.launchpad.net/xmir/+bug/1216472

Both bugs have workarounds you can try.

Those are significant bugs which confuse and mask each other. I don't 
think it would be useful to hypothesize about further display bugs until 
they're squashed and out of the equation.


- Daniel


On 03/09/13 21:10, Joseph Rushton Wakeling wrote:

On 03/09/13 03:34, Daniel van Vugt wrote:

Thanks Joe,

That's really an Ubuntu page which is not maintained by the Mir team.

We maintain: http://unity.ubuntu.com/mir/

However, of course we can and should fix the Ubuntu wiki where it
needs fixing.

- Daniel


Dear Daniel,

Thanks for clarification and for updating the wiki page.  By coincidence
today I decided to give Mir a spin, installing unity-system-compositor
from universe: libmirserver1 is version 0.0.10+13.10.20130829.2-0ubuntu1.

This is on a ThinkPad T420, graphics:

 VGA compatible controller: Intel Corporation 2nd Generation Core
Processor Family Integrated Graphics Controller (rev 09)
 Subsystem: Lenovo Device 21ce
 Kernel driver in use: i915

There's a lot of distortion around the mouse cursor, particularly when
moving it slowly or when there is a heavy-ish load on the system.

Doing anything like playing a video (e.g. YouTube) seems to slow
everything down a lot, the video is choppy and there is distortion
elsewhere on the screen (e.g. while typing this email, there is
distortion around the letters I'm typing as they appear).  Sometimes
during a heavy system load the display will even freeze, although this
doesn't appear to be a crash -- other things (such as audio playback)
will continue, and the display unfreezes itself after a period of time
(e.g. if a video ends).

Multi-monitor seems broadly OK although once when I Ctrl-Alt-Del'd to
try and escape a frozen display, I wound up with both laptop and
external screen active and was unable to reconfigure the system to use
just the external display without a restart.

I'm not sure to what extent these are known issues and given how vague
the report is I wasn't sure whether to turn this into a bug report or a
report on the wiki page Jono Bacon set up:
https://wiki.ubuntu.com/Mir/GPUTesting

So, I thought I'd put it on record here -- let me know if you'd like it
written up either on Launchpad or the wiki and I'll do so.

Thanks & best wishes,

-- Joe


--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/mir-devel

Re: Radeon HD 6870

[Daniel van Vugt]

Thanks. We know about that issue. It is being discussed here:
https://bugs.launchpad.net/mir/+bug/1218815

If you have any different issues in future, please report them using 
this link:

https://bugs.launchpad.net/mir/+filebug

- Daniel


On 09/09/13 17:38, s...@nmset.info wrote:

Hello

Don't know if it's the right place to report this.

Mir testing failed with Radeon HD 6870. 13.10 beta freshly installed. Mir
installed following web available info.

Screen with multiple vertical black unstable stripes.

TECH INFO:

(The info below is drawn from an ARCH session).

lspci -v
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI]
Barts XT [Radeon HD 6870] (prog-if 00 [VGA controller])
 Subsystem: XFX Pine Group Inc. Device 3108
 Flags: bus master, fast devsel, latency 0, IRQ 55
 Memory at d000 (64-bit, prefetchable) [size=256M]
 Memory at fbac (64-bit, non-prefetchable) [size=128K]
 I/O ports at b000 [size=256]
 Expansion ROM at fbaa [disabled] [size=128K]
 Capabilities: [50] Power Management version 3
 Capabilities: [58] Express Legacy Endpoint, MSI 00
 Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+
 Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010

 Capabilities: [150] Advanced Error Reporting
 Kernel driver in use: fglrx_pci
 Kernel modules: fglrx

lspci -vv
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI]
Barts XT [Radeon HD 6870] (prog-if 00 [VGA controller])
 Subsystem: XFX Pine Group Inc. Device 3108
 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR+ FastB2B- DisINTx+
 Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
SERR- 
 Capabilities: [150 v1] Advanced Error Reporting
 UESta:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt-
RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
 UEMsk:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt-
RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
 UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt-
RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
 CESta:  RxErr- BadTLP- BadDLLP- Rollover- Timeout-
NonFatalErr+
 CEMsk:  RxErr- BadTLP- BadDLLP- Rollover- Timeout-
NonFatalErr+
 AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+
ChkEn-
 Kernel driver in use: fglrx_pci
 Kernel modules: fglrx


Regards.




--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/mir-devel

Re: VESA DDC/CI display backlight

[Daniel van Vugt]

Alexander,

If it's part of DDC then certainly Mir might be the place to implement 
that. I don't think it's a high priority for the team in 13.10 though.


Maybe it should be discussed as part of:
https://bugs.launchpad.net/xmir/+bug/1211797
?

- Daniel


On 09/09/13 01:52, Alexander GamePad wrote:

Well, this is a feature that is presents in most displays, but is
hardly ever used by software.

Xorg could handle backlight of notebook displays, but not of standalone
displays.

There is a project called ddccontrol: http://ddccontrol.sourceforge.net/
The core of this project is not really tough to implement inside Mir,
because it is just a simple wrapper of I2C protocol.

Practical usage:
- Unified backlight interface (ACPI from notebooks, DDC/CI, maybe, HDMI)
- Ability to control display backlight from System Settings, xbacklight
(well, mirbacklight, of course ;) ) and from any other display tool.
- Ability to create such a cool feature as automatic backlight (using a
webcam).

So, is there a possibility to include DDC support in Mir?





--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/mir-devel

Re: Update Known Issues on Mir installation page?

[Daniel van Vugt]

Joe,

Feedback is appreciated. And mir-devel is relatively quiet so it's a 
good place, for now.


Compiz CPU usage is most certainly not related to Mir in any way. It 
generally trends with screen "damage" which is when any part of the 
screen changes. Compiz CPU is however significantly impacted by the 
relatively large and complex unityshell plugin that runs inside it. And 
unityshell does affect the damage calculations too. But still, that's 
all not related to Mir.


- Daniel


On 09/09/13 19:27, Joseph Rushton Wakeling wrote:

On 04/09/13 03:32, Daniel van Vugt wrote:

The distortion around the mouse cursor is known:
https://bugs.launchpad.net/xmir/+bug/1218735

And the general skipping/freezing I think is covered by:
https://bugs.launchpad.net/xmir/+bug/1216472

Both bugs have workarounds you can try.

Those are significant bugs which confuse and mask each other. I don't
think it
would be useful to hypothesize about further display bugs until
they're squashed
and out of the equation.


Belated thanks for the info. :-)

Just as a "qualitative" report -- I don't want to speculate about
particular bugs -- things got much better with Mir updates that arrived
shortly after your last email.

The issue with video playback has become more subtle.  What seems to
happen is that any video playback of any kind results in Compiz
massively increasing its CPU usage, and that heightened CPU burden
doesn't go away when the video has stopped -- it's less than when the
video was playing, but not absent.

The effect is more strongly pronounced if e.g. the video is HTML5 video
being played through a web browser, rather than a local file being
played via mplayer -- but it's there in all cases.  System
responsiveness as a whole decreases as a result.

I suspect this can also be interpreted in terms of existing bugs --
maybe even the ones you already pointed me to -- so don't worry about
spending time responding to me or pointing me to bug reports.  I have
strong trust in the Mir team to solve all the significant problems
before release, this email is just an "FYI". :-)

But do let me know if this use of the mir-devel list is inappropriate --
I don't want to take up space and attention here if these kind of user
experience reports can be better made elsewhere.

Thanks & best wishes,

 -- Joe


--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/mir-devel

Mir bug importance

[Daniel van Vugt]

All,

As we focus on the most severe bugs, it's worth discussing what bug 
severity actually is. I don't want to confuse everyone with a detailed 
examination/discussion/argument. But to start with, I think we need to 
agree on what "Critical" means...


Normally critical means that the system is unusable [1]. Good examples 
of definitely critical bugs are:


"Mir/unity-system-compositor fails to start: Error opening DRM device"
https://bugs.launchpad.net/mir/+bug/1206633

"[radeon] Graphic glitches and screen corruption (vertical lines) on 
XMir surfaces only"

https://bugs.launchpad.net/mir/+bug/1218815

These are bugs which prevent the machine from being usable. But if it's 
not that bad, then please consider marking bugs as High or Medium.


- Daniel

[1] https://wiki.ubuntu.com/Bugs/Importance

--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/mir-devel

Re: Mir bug importance

[Daniel van Vugt]

I suspected that was the case, and I think that approach is flawed. By 
your rules, you're giving equal weighting to:


"The system is broken and cannot start"
vs
"Power management is not implemented yet"

If you mark everything as "critical" you lose sight of the fact that the 
first one is actually much more important than the second.


- Daniel


On 10/09/13 10:31, Robert Ancell wrote:

Kevin Gunn, correct me if I'm wrong, but the way we were using bugs was
Critical = Needs to be fixed for 13.10 release.

[1] refers to the Ubuntu bug importances, not project bug importances.
The reason for that page is there was inconsistency between different
Ubuntu packages. As an upstream project, I don't think we have to follow
these definitions.

When you change the importance, Launchpad has the following description
for each value:

Undecided - Not decided yet. Maybe needs more discussion.
Critical - Fix now or as soon as possible.
High - Schedule to be fixed soon.
Medium - Fix when convenient, or schedule to fix later.
Low - Fix when convenient.
Wishlist - Not a bug. It's an enhancement/new feature.

Which I think are good guides for how we should use them. i.e. Critical
= fix now, regardless of how much damage the actual bug causes. A
missing feature that needs to be done before release could be critical,
or a feature that's blocking other teams.

Note, I really don't understand the above definition for Medium,
especially how it compares to Low :)

--Robert


On Tue, Sep 10, 2013 at 2:07 PM, Daniel van Vugt
mailto:daniel.van.v...@canonical.com>>
wrote:

All,

As we focus on the most severe bugs, it's worth discussing what bug
severity actually is. I don't want to confuse everyone with a
detailed examination/discussion/__argument. But to start with, I
think we need to agree on what "Critical" means...

Normally critical means that the system is unusable [1]. Good
examples of definitely critical bugs are:

"Mir/unity-system-compositor fails to start: Error opening DRM device"
https://bugs.launchpad.net/__mir/+bug/1206633
<https://bugs.launchpad.net/mir/+bug/1206633>

"[radeon] Graphic glitches and screen corruption (vertical lines) on
XMir surfaces only"
https://bugs.launchpad.net/__mir/+bug/1218815
<https://bugs.launchpad.net/mir/+bug/1218815>

These are bugs which prevent the machine from being usable. But if
it's not that bad, then please consider marking bugs as High or Medium.

- Daniel

[1] https://wiki.ubuntu.com/Bugs/__Importance
<https://wiki.ubuntu.com/Bugs/Importance>

--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com <mailto:Mir-devel@lists.ubuntu.com>
Modify settings or unsubscribe at:
https://lists.ubuntu.com/__mailman/listinfo/mir-devel
<https://lists.ubuntu.com/mailman/listinfo/mir-devel>




--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/mir-devel

Re: Mir bug importance

[Daniel van Vugt]

That's also not accurate. If a bug has crept into distro then it  should 
have a distro task: "mir (ubuntu)"


This is necessary to distinguish between a fix that has landed in 
upstream Mir, but not yet landed in Ubuntu distro.


- Daniel


On 10/09/13 10:35, Robert Ancell wrote:

Also worth mentioning about bugs:

I've been moving all the Ubuntu bugs against Mir to Mir project bugs.
This is what the software center team did as it makes it simpler to just
have one bug list.

--Robert


On Tue, Sep 10, 2013 at 2:07 PM, Daniel van Vugt
mailto:daniel.van.v...@canonical.com>>
wrote:

All,

As we focus on the most severe bugs, it's worth discussing what bug
severity actually is. I don't want to confuse everyone with a
detailed examination/discussion/__argument. But to start with, I
think we need to agree on what "Critical" means...

Normally critical means that the system is unusable [1]. Good
examples of definitely critical bugs are:

"Mir/unity-system-compositor fails to start: Error opening DRM device"
https://bugs.launchpad.net/__mir/+bug/1206633
<https://bugs.launchpad.net/mir/+bug/1206633>

"[radeon] Graphic glitches and screen corruption (vertical lines) on
XMir surfaces only"
https://bugs.launchpad.net/__mir/+bug/1218815
<https://bugs.launchpad.net/mir/+bug/1218815>

These are bugs which prevent the machine from being usable. But if
it's not that bad, then please consider marking bugs as High or Medium.

- Daniel

[1] https://wiki.ubuntu.com/Bugs/__Importance
<https://wiki.ubuntu.com/Bugs/Importance>

--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com <mailto:Mir-devel@lists.ubuntu.com>
Modify settings or unsubscribe at:
https://lists.ubuntu.com/__mailman/listinfo/mir-devel
<https://lists.ubuntu.com/mailman/listinfo/mir-devel>




--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/mir-devel

Re: Mir bug importance

[Daniel van Vugt]

To assert that any Mir bug only affects a small number of people is 
dangerous. As Mir is not enabled by default, and the audience is 
presently opt-in experimenters, the Mir user base is still microscopic 
compared to that of Ubuntu in general.


We probably have to assume that a bug "affecting" one person now could 
affect hundreds of thousands of people later. Some might say "millions"...




On 10/09/13 11:30, Robert Ancell wrote:

Note the field is actually "importance" not "severity" - thus is makes
sense for "Power management is not implemented yet" to be more important
than "The system is broken and cannot start" in certain cases, e.g. if
the second only affects a small number of people and the former needs to
be done by feature freeze.

--Robert


On Tue, Sep 10, 2013 at 2:38 PM, Daniel van Vugt
mailto:daniel.van.v...@canonical.com>>
wrote:

I suspected that was the case, and I think that approach is flawed.
By your rules, you're giving equal weighting to:

"The system is broken and cannot start"
vs
"Power management is not implemented yet"

If you mark everything as "critical" you lose sight of the fact that
the first one is actually much more important than the second.

- Daniel



On 10/09/13 10:31, Robert Ancell wrote:

Kevin Gunn, correct me if I'm wrong, but the way we were using
bugs was
Critical = Needs to be fixed for 13.10 release.

[1] refers to the Ubuntu bug importances, not project bug
importances.
The reason for that page is there was inconsistency between
different
Ubuntu packages. As an upstream project, I don't think we have
to follow
these definitions.

When you change the importance, Launchpad has the following
description
for each value:

Undecided - Not decided yet. Maybe needs more discussion.
Critical - Fix now or as soon as possible.
High - Schedule to be fixed soon.
Medium - Fix when convenient, or schedule to fix later.
Low - Fix when convenient.
Wishlist - Not a bug. It's an enhancement/new feature.

Which I think are good guides for how we should use them. i.e.
Critical
= fix now, regardless of how much damage the actual bug causes. A
missing feature that needs to be done before release could be
critical,
or a feature that's blocking other teams.

Note, I really don't understand the above definition for Medium,
especially how it compares to Low :)

--Robert


On Tue, Sep 10, 2013 at 2:07 PM, Daniel van Vugt
mailto:daniel.van.v...@canonical.com>
<mailto:daniel.van.vugt@__canonical.com
<mailto:daniel.van.v...@canonical.com>>>

wrote:

 All,

 As we focus on the most severe bugs, it's worth discussing
what bug
 severity actually is. I don't want to confuse everyone with a
 detailed examination/discussion/argument. But to start
with, I

 think we need to agree on what "Critical" means...

 Normally critical means that the system is unusable [1]. Good
 examples of definitely critical bugs are:

 "Mir/unity-system-compositor fails to start: Error opening
DRM device"
https://bugs.launchpad.net/mir/+bug/1206633
<https://bugs.launchpad.net/__mir/+bug/1206633>

 <https://bugs.launchpad.net/__mir/+bug/1206633
<https://bugs.launchpad.net/mir/+bug/1206633>>

 "[radeon] Graphic glitches and screen corruption (vertical
lines) on
 XMir surfaces only"
https://bugs.launchpad.net/mir/+bug/1218815
<https://bugs.launchpad.net/__mir/+bug/1218815>

 <https://bugs.launchpad.net/__mir/+bug/1218815
<https://bugs.launchpad.net/mir/+bug/1218815>>

 These are bugs which prevent the machine from being usable.
But if
 it's not that bad, then please consider marking bugs as
High or Medium.

 - Daniel

 [1] https://wiki.ubuntu.com/Bugs/Importance
<https://wiki.ubuntu.com/Bugs/__Importance>

 <https://wiki.ubuntu.com/Bugs/__Importance
<https://wiki.ubuntu.com/Bugs/Importance>>

 --
 Mir-devel mailing list
Mir-devel@lists.ubuntu.com <mailto:Mir-devel@lists.ubuntu.com>
<mailto:Mir-devel@lists.__ubuntu.com
<mailto:Mir-devel@lists.ubuntu.com>>

 Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/mir-devel
<https://lists

Re: Radeon HD 6870

[Daniel van Vugt]

Also, you appear to have the AMD/ATI driver "fglrx" loaded. This could 
likely prevent Mir from working properly (as it uses the "radeon" 
module). If you want to test Mir, please remove all "fglrx*" packages.


- Daniel


On 10/09/13 09:29, Daniel van Vugt wrote:

Thanks. We know about that issue. It is being discussed here:
https://bugs.launchpad.net/mir/+bug/1218815

If you have any different issues in future, please report them using
this link:
https://bugs.launchpad.net/mir/+filebug

- Daniel


On 09/09/13 17:38, s...@nmset.info wrote:

Hello

Don't know if it's the right place to report this.

Mir testing failed with Radeon HD 6870. 13.10 beta freshly installed. Mir
installed following web available info.

Screen with multiple vertical black unstable stripes.

TECH INFO:

(The info below is drawn from an ARCH session).

lspci -v
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI]
Barts XT [Radeon HD 6870] (prog-if 00 [VGA controller])
 Subsystem: XFX Pine Group Inc. Device 3108
 Flags: bus master, fast devsel, latency 0, IRQ 55
 Memory at d000 (64-bit, prefetchable) [size=256M]
 Memory at fbac (64-bit, non-prefetchable) [size=128K]
 I/O ports at b000 [size=256]
 Expansion ROM at fbaa [disabled] [size=128K]
 Capabilities: [50] Power Management version 3
 Capabilities: [58] Express Legacy Endpoint, MSI 00
 Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+
 Capabilities: [100] Vendor Specific Information: ID=0001
Rev=1 Len=010

 Capabilities: [150] Advanced Error Reporting
 Kernel driver in use: fglrx_pci
 Kernel modules: fglrx

lspci -vv
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI]
Barts XT [Radeon HD 6870] (prog-if 00 [VGA controller])
 Subsystem: XFX Pine Group Inc. Device 3108
 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr-
Stepping- SERR+ FastB2B- DisINTx+
 Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
SERR- 
 Capabilities: [150 v1] Advanced Error Reporting
 UESta:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt-
UnxCmplt-
RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
 UEMsk:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt-
UnxCmplt-
RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
 UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt-
UnxCmplt-
RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
 CESta:  RxErr- BadTLP- BadDLLP- Rollover- Timeout-
NonFatalErr+
 CEMsk:  RxErr- BadTLP- BadDLLP- Rollover- Timeout-
NonFatalErr+
 AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+
ChkEn-
 Kernel driver in use: fglrx_pci
 Kernel modules: fglrx


Regards.






--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/mir-devel

Re: Radeon HD 6870

[Daniel van Vugt]

No problem. Then the bug you reported is indeed:
https://bugs.launchpad.net/mir/+bug/1218815


On 10/09/13 14:50, s...@nmset.info wrote:

Le mardi 10 septembre 2013 14:21:42 Daniel van Vugt a écrit :

Also, you appear to have the AMD/ATI driver "fglrx" loaded. This could
likely prevent Mir from working properly (as it uses the "radeon"
module). If you want to test Mir, please remove all "fglrx*" packages.

- Daniel



The info I provided comes from ARCH running on the same host after reboot, for
the details of the card. The fglrx package is not installed in Ubuntu 13.10
beta.




--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/mir-devel

Commit messages

[Daniel van Vugt]

All,

Please put some more effort into commit messages. Recently many of them 
have become cryptic single sentences, with no bug numbers or elaboration 
in the description.


When reviewing a merge proposal this makes life hard because the 
intention of the branch is not adequately stated. When reviewing bzr 
log, this makes life hard again because there are no bug numbers 
mentioned to understand what's being fixed. So at every stage it is very 
hard to tell what's changing and why. Please use more words.


- Daniel

--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/mir-devel

Chris's XDC2013 presentation about XMir

[Daniel van Vugt]

In case you haven't seen it yet... RAOF's XDC2013 presentation about 
XMir is here:


http://www.youtube.com/watch?v=khXlETtVaKY

--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/mir-devel

Input plans

[Daniel van Vugt]

Do we have a roadmap for how to deal with the future of Mir input?

I mean, Mir uses Android input. When there's a bug or missing feature, 
do we intend to maintain and branch the Android input code? Is that more 
desirable than Mir having its own implementation to be molded as required?


- Daniel

--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/mir-devel

Nexus 7

[Daniel van Vugt]

Has anyone else played with Mir on Nexus 7?  It looks like there's only 
_one_ bug stopping it from really working...


https://bugs.launchpad.net/mir/+bugs?field.tag=nexus7

I mention this because my N4 is in for repairs and I only have the N7 
right now.


- Daniel

--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/mir-devel

Re: Script to bump server ABI

[Daniel van Vugt]

I think there are likely many case where we fear an ABI break is 
happening when really it's not. Like some of last night's landings.


In future I shall have to remind myself to point this out in the MP 
description... "I'm changing the server headers but it's not an ABI/API 
break".


Of course, if no one's gone to the trouble of thoroughly checking then 
we need to assume it's a break and bump.



On 03/10/13 08:37, Robert Ancell wrote:

Find attached a script you can use to bump the ABI on libmirserver to
save time doing it manually.

Run from the bzr checkout with:
$ chmod +x bump_abi.py
$ ./bump_abi.py

Enjoy!
--Robert




--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/mir-devel

Mir saucy final

[Daniel van Vugt]

Well we just passed final freeze for saucy, so I assume this is the one:
https://launchpad.net/ubuntu/+source/mir/0.0.14+13.10.20131010-0ubuntu1

Unless there was some kind of exception in place?

--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/mir-devel

Enhancements as opposed to bugs

[Daniel van Vugt]

We always seem to have lots of enhancements logged as bugs in the Mir 
project. And we seem to have a requirement that many of them be more 
important than "Wishlist" which is what LP historically uses to 
represent enhancements.


So assuming we can't convince everyone that all enhancements should be 
Importance==Wishlist, how about some other formal approach?


Maybe prefix all enhancements as "[enhancement]" ?

- Daniel

--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/mir-devel

Re: Enhancements as opposed to bugs

[Daniel van Vugt]

I think we all agree Launchpad does not represent enhancement/feature 
requests ideally. That's why I asked how we'd like to work around the 
shortcomings.


Also, I just found the bug (which itself is actually a feature request) 
and it looks unlikely to be resolved:

https://bugs.launchpad.net/launchpad/+bug/176431


On 15/10/13 22:09, Michał Sawicz wrote:

On 15.10.2013 16:04, Daniel d'Andrada wrote:


Bugs and new features are, on a slighly higher level, the same thing:
work that has to be done on some piece of software, according to some
specs, with a target milestone, an assignee, a given priority, a state
(in progress, new, commited, released), a discussion around it, etc.

At my previous job we had different systems for those (bugs and
features) for a long time and it was awesome when we finally started
using only one (the bug tracker, but tweaked a bit to better accommodate
those two kinds of tasks) for everything. I think it's just natural to
do so.


I believe the biggest problem with launchpad in that regard is that
"Wishlist" is the lowest priority (Importance) level. You can't make an
enhancement higher priority than a bug, that's why some clear
distinguishing between a bug and a feature would be nice indeed.



--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/mir-devel

Re: Enhancements as opposed to bugs

[Daniel van Vugt]

Though I recall some of the proprietary issue tracking systems I've used 
in the past clearly distinguished between Bug and Enhancement.


And that in itself was sometimes problematic. Where people can't decide 
or agree if something is a bug or a feature, you either need a third 
classification or a more neutral system that just doesn't care (like 
Launchpad).



On 16/10/13 09:28, Daniel van Vugt wrote:

I think we all agree Launchpad does not represent enhancement/feature
requests ideally. That's why I asked how we'd like to work around the
shortcomings.

Also, I just found the bug (which itself is actually a feature request)
and it looks unlikely to be resolved:
https://bugs.launchpad.net/launchpad/+bug/176431


On 15/10/13 22:09, Michał Sawicz wrote:

On 15.10.2013 16:04, Daniel d'Andrada wrote:


Bugs and new features are, on a slighly higher level, the same thing:
work that has to be done on some piece of software, according to some
specs, with a target milestone, an assignee, a given priority, a state
(in progress, new, commited, released), a discussion around it, etc.

At my previous job we had different systems for those (bugs and
features) for a long time and it was awesome when we finally started
using only one (the bug tracker, but tweaked a bit to better accommodate
those two kinds of tasks) for everything. I think it's just natural to
do so.


I believe the biggest problem with launchpad in that regard is that
"Wishlist" is the lowest priority (Importance) level. You can't make an
enhancement higher priority than a bug, that's why some clear
distinguishing between a bug and a feature would be nice indeed.





--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/mir-devel

Re: Enhancements as opposed to bugs

[Daniel van Vugt]

I don't think "[ER]" is very user-friendly. No one outside the team 
would understand it.


How about "[feature]" or "[enhancement]"?


On 16/10/13 21:02, Kevin Gunn wrote:

thanks for the feedback.
it likely won't be something to be fixed in a short term - but i agree,
bugs (over blueprints) seem closer to being 'everything' you'd want when
looking at the vices & virtues of bugs vs blueprints.
i think what bugs are missing is a bit of aggregation & reporting ...as
well as a way to better reflect scheduling (for a big picture view)

in the near term - there is certainly nothing wrong with pre-pending to
the bug title...i would suggest "[ER]" for 'enhancement request'...



On Tue, Oct 15, 2013 at 9:10 PM, Daniel van Vugt
mailto:daniel.van.v...@canonical.com>>
wrote:

Though I recall some of the proprietary issue tracking systems I've
used in the past clearly distinguished between Bug and Enhancement.

And that in itself was sometimes problematic. Where people can't
decide or agree if something is a bug or a feature, you either need
a third classification or a more neutral system that just doesn't
care (like Launchpad).



On 16/10/13 09:28, Daniel van Vugt wrote:

I think we all agree Launchpad does not represent
enhancement/feature
requests ideally. That's why I asked how we'd like to work
around the
shortcomings.

Also, I just found the bug (which itself is actually a feature
request)
and it looks unlikely to be resolved:
https://bugs.launchpad.net/__launchpad/+bug/176431
<https://bugs.launchpad.net/launchpad/+bug/176431>


On 15/10/13 22:09, Michał Sawicz wrote:

On 15.10.2013 16:04, Daniel d'Andrada wrote:


Bugs and new features are, on a slighly higher level,
the same thing:
work that has to be done on some piece of software,
according to some
specs, with a target milestone, an assignee, a given
priority, a state
(in progress, new, commited, released), a discussion
around it, etc.

At my previous job we had different systems for those
(bugs and
features) for a long time and it was awesome when we
finally started
using only one (the bug tracker, but tweaked a bit to
better accommodate
those two kinds of tasks) for everything. I think it's
just natural to
do so.


I believe the biggest problem with launchpad in that regard
is that
"Wishlist" is the lowest priority (Importance) level. You
can't make an
enhancement higher priority than a bug, that's why some clear
distinguishing between a bug and a feature would be nice indeed.



--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com <mailto:Mir-devel@lists.ubuntu.com>
Modify settings or unsubscribe at:
https://lists.ubuntu.com/__mailman/listinfo/mir-devel
<https://lists.ubuntu.com/mailman/listinfo/mir-devel>






--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/mir-devel

Re: Enhancements as opposed to bugs

[Daniel van Vugt]

Well I tagged a bunch of bugs as [feature] yesterday and already ran 
into ambiguity in some (feature vs enhancement vs bug). I think 
[enhancement] is a better classification because not all enhancement 
requests represent distinct "features". Might switch them to 
[enhancement] today.



On 17/10/13 21:01, Daniel d'Andrada wrote:

I agree. Cryptic acronyms are bad.

Another ides is using tags, like suggested here
https://bugs.launchpad.net/launchpad/+bug/176431/comments/4. That would
save us some precious space in the bug title.

On 16/10/13 23:03, Daniel van Vugt wrote:

I don't think "[ER]" is very user-friendly. No one outside the team
would understand it.

How about "[feature]" or "[enhancement]"?


On 16/10/13 21:02, Kevin Gunn wrote:

thanks for the feedback.
it likely won't be something to be fixed in a short term - but i agree,
bugs (over blueprints) seem closer to being 'everything' you'd want when
looking at the vices & virtues of bugs vs blueprints.
i think what bugs are missing is a bit of aggregation & reporting ...as
well as a way to better reflect scheduling (for a big picture view)

in the near term - there is certainly nothing wrong with pre-pending to
the bug title...i would suggest "[ER]" for 'enhancement request'...



On Tue, Oct 15, 2013 at 9:10 PM, Daniel van Vugt
mailto:daniel.van.v...@canonical.com>>
wrote:

Though I recall some of the proprietary issue tracking systems I've
used in the past clearly distinguished between Bug and Enhancement.

And that in itself was sometimes problematic. Where people can't
decide or agree if something is a bug or a feature, you either need
a third classification or a more neutral system that just doesn't
care (like Launchpad).



On 16/10/13 09:28, Daniel van Vugt wrote:

I think we all agree Launchpad does not represent
enhancement/feature
requests ideally. That's why I asked how we'd like to work
around the
shortcomings.

Also, I just found the bug (which itself is actually a feature
request)
and it looks unlikely to be resolved:
https://bugs.launchpad.net/__launchpad/+bug/176431
<https://bugs.launchpad.net/launchpad/+bug/176431>


On 15/10/13 22:09, Michał Sawicz wrote:

On 15.10.2013 16:04, Daniel d'Andrada wrote:


Bugs and new features are, on a slighly higher level,
the same thing:
work that has to be done on some piece of software,
according to some
specs, with a target milestone, an assignee, a given
priority, a state
(in progress, new, commited, released), a discussion
around it, etc.

At my previous job we had different systems for those
(bugs and
features) for a long time and it was awesome when we
finally started
using only one (the bug tracker, but tweaked a bit to
better accommodate
those two kinds of tasks) for everything. I think it's
just natural to
do so.


I believe the biggest problem with launchpad in that regard
is that
"Wishlist" is the lowest priority (Importance) level. You
can't make an
enhancement higher priority than a bug, that's why some
clear
distinguishing between a bug and a feature would be nice
indeed.





--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/mir-devel

Saucy done

[Daniel van Vugt]

For the curious...

It was Mir 0.0.15 that made it into saucy in the end:
https://launchpad.net/ubuntu/+source/mir

Everything after 0.0.15 has now been retargeted to the t-series:
https://launchpad.net/mir/+series

If you don't like the new target milestone name "0.1.0", that's OK. It 
can be quickly and safely renamed without affecting anything. My only 
advice is that it probably must be >=0.1.0 to avoid conflicting with any 
saucy maintenance (0.0.*).


- Daniel

--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/mir-devel

Re: Mir considered about Multi-display && Multi-touch devices?

[Daniel van Vugt]

Leslie,

XMir does not use Mir's input system at the moment. It lets X use the 
existing evdev interface instead. Also, XMir does not use Mir's hardware 
cursor either. So it is X rendering the mouse pointer(s) in software.


So in theory your issue has nothing to do with Mir and would still 
happen in plain X too. I think you should direct the problem to an X 
mailing list.


- Daniel


On 19/10/13 12:54, Leslie Zhai wrote:

Hi Mir developers,

I use Projected Capacitive touch screen device
http://en.wikipedia.org/wiki/Touchscreen#Projected_capacitance
It can be pasted on the normal monitor, then it is able to touch, the
cursor will move to the position where touched. It experienced like
iphone and other single touch screen device.

But when I put multiple Projected Capacitive touch screen devices on
several monitors, then touch some of them simultaneously, the cursor of
X Window was only moving in the first monitor, even though it was able
to move to other monitors` display, it still failed to show the correct
position. Did Mir consider about Multi-display && Multi-touch devices?

Why the cursor of X Window wired? Some people might argue that it is
Linux kernel Multi-touch Protocol issue
https://www.kernel.org/doc/Documentation/input/multi-touch-protocol.txt

Nope!

For Protocol Example B

Here is what a minimal event sequence for a two-contact touch would look
like for a type B device:

ABS_MT_SLOT 0
ABS_MT_TRACKING_ID 45
ABS_MT_POSITION_X x[0]
ABS_MT_POSITION_Y y[0]
ABS_MT_SLOT 1
ABS_MT_TRACKING_ID 46
ABS_MT_POSITION_X x[1]
ABS_MT_POSITION_Y y[1]
SYN_REPORT

Here is the sequence after moving contact 45 in the x direction:

ABS_MT_SLOT 0
ABS_MT_POSITION_X x[0]
SYN_REPORT

Here is the sequence after lifting the contact in slot 0:

ABS_MT_TRACKING_ID -1
SYN_REPORT

The slot being modified is already 0, so the ABS_MT_SLOT is omitted. The
message removes the association of slot 0 with contact 45, thereby
destroying contact 45 and freeing slot 0 to be reused for another contact.

Finally, here is the sequence after lifting the second contact:

ABS_MT_SLOT 1
ABS_MT_TRACKING_ID -1
SYN_REPORT

Here ABS_MT_SLOT distinguished which finger touch the screen,
ABS_MT_POSITION_X and ABS_MT_POSITION_Y shown the position where the
finger touched.
In case ABS_MT_XXX martix like below:

(0, 0)-(4075, 0)
| |
| |
| |
| (X, Y) |
| |
| |
| |
| |
| |
| |
| |
(0, 4095)---(4075, 4095)

For single touch screen device situation, the X axis range of the
position is [0, 4075], the Y`s is [0, 4095]; then for multi-devices, the
matrix could not be transformed, the range might never be changed, it
will not increased by multiply the number of monitors. It means if I
could touch several monitors in the same or about position
simultaneously, I am so lucky :) the (X, Y) position values might be the
same, then the cursor of X Window wired.

Then someone might be doubt about it is X evdev input driver issue
http://cgit.freedesktop.org/xorg/driver/xf86-input-evdev/

In the function EvdevAddAbsValuatorClass(DeviceIntPtr device, int
want_scroll_axes)
http://cgit.freedesktop.org/xorg/driver/xf86-input-evdev/tree/src/evdev.c#n1249

It only consider about one single device, a Projected Capacitive touch
screen device connected to Linux box via USB, but what about multi-touch
devices, how to handle several file descriptors? It might be fixed by
Leslie MultiTouch way!

Leslie MultiTouch

I hacked the get devices function via reading /proc/bus/input/devices

void getDevices(std::string DeviceName, std::vector* Devices)
{
std::string strLine;
std::string strDevPath;
std::ifstream DevFile("/proc/bus/input/devices");
int nPos;

while (std::getline(DevFile, strLine))
{
if (strLine.size() == 0)
continue;

if (strLine[0] == 'N')
{
if (ToLower(strLine).find(ToLower(DeviceName)) != std::string::npos)
{
while (std::getline(DevFile, strLine))
{
if (strLine[0] == 'H')
break;
}
nPos = strLine.find("event");
if (nPos != std::string::npos) {
strDevPath = "/dev/input/" + strLine.substr(nPos, strLine.size() - nPos
- 1);
#if DEBUG
// such as /dev/input/event13
std::cout << "DEBUG: " << strDevPath << std::endl;
#endif
Devices->push_back(strDevPath);
}
}
}
}
}

Then it need to create a thread pool to handle several DeviceIntPtr
objects simultaneously.

And it need to identify each touch screen device like Xorg Xinerama conf
style:

Section "MultiTouchLayout"
Identifier "MultiTouch Device"
Device 0 "Device0" 0 0
Device 1 "Device1" RightOf "Device0" # LeftOf, BelowOf, AboveOf
Option "MultiTouch" "true"
EndSection

Section "Device"
Identifier "Device0"
Device "/dev/input/event13"
Monitor "Monitor0"
DefaultDepth 24
SubSection "Display"
Viewport 0 0
Depth 24
Modes "1680x1050"
EndSubSection
EndSection

Section "Device"
Identifier "Device1"
Device "/dev/input/event16"
Monitor "Monitor1"
DefaultDepth 24
SubSection "Display"
Viewport 0 0
Depth 24
Modes "1680x1050"
EndSubSection
EndSection

When it send a (X, Y) position event from the tou

Re: Crossing namespaces

[Daniel van Vugt]

Ping. Any movement on this discussion?


On 03/07/13 18:43, Daniel van Vugt wrote:

Certainly, we have cases where the namespace is an integral part of the
class name right now. Cases like those can't be merged into a single
namespace unless you change the class names too (which I encourage).


On 03/07/13 18:28, Thomas Voß wrote:

I think making a deeper hierarchy does not conclude into complexity.
Trying to think in a flat mir::server namespace, I would think that it
is likely that we will end up with something like Graphics*
class/struct names as opposed to having a graphics:: namespace. Of
course, both is valid, but Graphics* is just very redundant and
syntactic noise in the end.

On Wed, Jul 3, 2013 at 12:23 PM, Daniel van Vugt
 wrote:

I think making things more complicated (deeper namespaces) is not an
ideal
way to make them easier to understand. Maybe hold off on that.



On 03/07/13 18:21, Thomas Voß wrote:


On Wed, Jul 3, 2013 at 12:16 PM, Daniel van Vugt
 wrote:


Umm, no. I don't recommend making the namespaces any deeper than they
already are :)




Hmmm, why not? It's arguably a very good way to classify components
into different categories (which is the purpose here, iiuc) and
namespace aliasing helps in avoiding spelling out deep namespace
hierarchies.





On 03/07/13 18:11, Thomas Voß wrote:



Fair point. I'm +1 on mir::server::${SUBNAMESPACE} as a first go to
reflect the directory structure.



On Wed, Jul 3, 2013 at 12:09 PM, Daniel van Vugt
 wrote:



I should also mention the below namespaces/directories are already
underneath src/server/. So if they're used outside of the server
then
we
should fix that too.



On 03/07/13 18:08, Thomas Voß wrote:




Hey Daniel,

I think pulling everything under mir::server is difficult as
some of
the functionality is shared with the client and potentially testing
infrastructure, too. My proposal would be that we refactor into
more
appropriate namespaces if required/when severe issues are
encountered.
Doing a full sweep right now seems to be overkill to me.

What do you think?

Thomas

On Wed, Jul 3, 2013 at 12:00 PM, Daniel van Vugt
 wrote:




Looking through our class hierarchies, particularly in the
server, it
occurs
to me that we cross namespaces a few times. This is particularly
apparent
trying to trace server logic through multiple subdirectories,
which
it
crosses a lot. I'm referring mainly to:
mir::graphics::
mir::compositor::
mir::surfaces::
mir::frontend::

These namespaces are often so related and interdependent that I
can't
see
the justification in them being separate. It just makes things
more
complicated. And if they should be separate then they're not quite
separated
in an optimal way yet.

Does anyone have a good reason why server classes shouldn't live
under
mir::server:: ? I don't imagine many of the sub-namespaces are
really
required or even logical any deeper than that.


--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/mir-devel




--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/mir-devel

Component clarification

[Daniel van Vugt]

OK, let's try again. There seems to be reasonable agreement that at 
least some components are poorly named and therefore confusing. Of 
course, any change requires significant search and replace in the least 
so I'd like to discuss it before any proposals occur.


How about...

mir::surfaces:: --> mir::core::
This component already represents the core platform-independent state 
and implementation code. So rather than call it "surfaces" which 
confuses the numerous existing Surface classes (75% of which are not in 
the "surfaces" component), why not call the component "core" or some such?


mir::graphics::*:: --> mir::platform::*:: or
mir::graphics::*:: --> mir::*::
The whole project is about graphics so we need to stop calling one 
component "graphics". This component already represents the 
platform-specific code. So why not name it "platform" or even remove the 
word "platform"/"graphics" completely and use the actual platform name 
mir::gbm::, mir::android:: etc?


- Daniel

--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/mir-devel

Latency and nesting

[Daniel van Vugt]

Has anyone else noticed there's a number of context switches between a 
client rendering a frame and it finally reaching the framebuffer?


Obviously there's a minimum of one, since the client and server will be 
different processes. But I'm concerned about the increased latency we're 
imposing by other threads. The server takes an additional context switch 
internally to pass a buffer swap from "frontend" to the backend 
(compositor threads).


As for clients, I think they stay in the same thread for rendering and 
sending data to the server. So that's good. But clients suffer a similar 
problem whereby incoming data from the server is in a different thread 
to that where the rendering (probably) happens.


I suspect these context switches, when compounded, could become 
significant to input (touch!) latency. And nesting will multiply the 
issue further.


So we should be keep this in mind going forward, and try to avoid adding 
any more context switches between threads.


- Daniel

--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/mir-devel

Re: Component clarification

[Daniel van Vugt]

Yeah, very good point about "gbm". That confused me when I joined to 
project too. It should be called "dri", I think.


And yes, there are some components that are clearly not graphical -- 
input, protobuf. However that leaves "compositor" and "surfaces" in the 
least, which we're saying are not part of "graphics". That's confusing.


- Daniel


On 25/10/13 22:22, Kevin Gunn wrote:

Don't take me wrong, i'm all for making things less confusing.
But to the statement the "whole project is about graphics" isn't
completely true imho, there's also input. To me anything that's related
to reading, writing, manipulating pixel data is worthy of being referred
to as graphics.

I'm ok with "state & implementation code" changing from "surface" to
"core". I'm sure others will weigh in.
to be clear, a "surface" is any buffer/container of pixel data that a
app/compositor wants rendered (potentially placed on screen)

also, just challenging (as i really don't know the answer)...but is
mir::gbm heading down a "confusing" path?? is it _really_ gbm specific ?
or is it also specific to other things (drm, kms etc)...?
also...alot of people don't know what "gbm" is outside of graphics stack
junkies (i had to explain what it was to a very savvy person just
yesterday...that when mir team says "gbm" they really mean desktop)
also consider this...you suggested "android"not "gralloc"...food for
thot
br,kg


On Fri, Oct 25, 2013 at 2:37 AM, Daniel van Vugt
mailto:daniel.van.v...@canonical.com>>
wrote:

OK, let's try again. There seems to be reasonable agreement that at
least some components are poorly named and therefore confusing. Of
course, any change requires significant search and replace in the
least so I'd like to discuss it before any proposals occur.

How about...

mir::surfaces:: --> mir::core::
This component already represents the core platform-independent
state and implementation code. So rather than call it "surfaces"
which confuses the numerous existing Surface classes (75% of which
are not in the "surfaces" component), why not call the component
"core" or some such?

mir::graphics::*:: --> mir::platform::*:: or
mir::graphics::*:: --> mir::*::
The whole project is about graphics so we need to stop calling one
component "graphics". This component already represents the
platform-specific code. So why not name it "platform" or even remove
the word "platform"/"graphics" completely and use the actual
platform name mir::gbm::, mir::android:: etc?

- Daniel

--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com <mailto:Mir-devel@lists.ubuntu.com>
Modify settings or unsubscribe at:
https://lists.ubuntu.com/__mailman/listinfo/mir-devel
<https://lists.ubuntu.com/mailman/listinfo/mir-devel>




--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/mir-devel

CI is blocked

[Daniel van Vugt]

The clang-trusty job is failing and blocking CI on all merge proposals. 
I've proposed a fix to unblock it:


https://code.launchpad.net/~vanvugt/mir/fix-1246590/+merge/193381

--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/mir-devel

Re: Qt Scenegraph and Mir

[Daniel van Vugt]

Comments added to the doc. And now some high-level thoughts:

1. To make communication of requirements between Unity and Mir teams 
more clear, we should avoid using any Q-words. This is simply because 
Mir is not toolkit specific and any Mir work is not toolkit specific. 
The Mir team will better understand what you mean and want if it's 
expressed in a way that also does not sound toolkit specific (even if it 
comes from toolkit-specific requirements, which are fine).


2. As with any siginificant Google doc, we should ensure all comments 
are agreed upon and marked as resolved. Then the comments will no longer 
be visible. If something important is in a comment and not in the 
document, it needs to be moved into the document.


3. I got a bit of a surprise to find the document is much about work 
I've already implemented. We have optimizations in place to dynamically 
switch between hardware non-GL compositing and GL compositing (and 
dynamic optimizations to GL compositing). The most relevant code is in:

  src/server/compositor/bypass.cpp
  src/server/compositor/occlusion.cpp
  src/server/compositor/default_display_buffer_compositor.cpp

Despite already being implemented, I fully support changes to the Scene 
classes and composition algorithms. And I would be happy to see the 
aforementioned source files replaced with a cleaner Scene model. So long 
as we don't lose any functionality or performance already established.


- Daniel


On 31/10/13 00:01, Gerry Boland wrote:

Hi folks,
as many of you know, on the current phone/tablet, all the application
switching animations are not done with live surfaces, but instead with
screenshots. This obviously is not ideal, so I want to fix that.

I've been researching ways to more tightly combine Mir surfaces with
Qt/QML, so that a Mir surface integrates nicely with QML, so they can be
transformed and animated with the usual QML syntax. It also discusses
non-GL hardware acceleration, and input handling.

I've written up the results of my research, and several proposed
solutions in this document:
https://docs.google.com/a/canonical.com/document/d/12tzE3Ha7ZJR_U4FZsAqKTgqDkWawXFSxY4Q-6PifgD4/edit?usp=sharing

Anything unclear or vague, please comment and I'll address it as best I can.

I want to open discussions on the topic ASAP, so that we can decide the
best strategy forward, and let me get to work on this!

Thanks
-Gerry



--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/mir-devel

Re: Mir on vmwgfx

[Daniel van Vugt]

Thanks Thomas, nice work.

Would you be able to log the individual problems separately here; ?
https://bugs.launchpad.net/mir/+filebug


On 05/11/13 15:22, Thomas Hellstrom wrote:

Hi!

I'm new to this list and I'm trying to get Mir running in a VMware
virtual machine on top of the vmwgfx driver stack.
The idea is to first get "mir_demo_server_basic" running with demo
clients and then move on to Xmir, patching up our drivers as necessary.

So far, I've encountered a couple of issues that might need attention
from MIR developers:

1) function mggh::DRMHelper::is_appropriate_device() in
gbm_display_helpers.c checks whether a drm device has any children
except itself. This is not true for vmwgfx, and the server will fail to
start thinking that our drm device is not appropriate. Why the child
requirement?

2) Once I get the basic server to start, the cursor disappears as soon
as I move the mouse. This boils down to Mir thinking that the cursor is
outside of the current mode bounding box. At Mir server startup, there
is no KMS setup configured, hence
DisplayConfigurationOutput::current_mode_index will be set to max (or
-1) in mgg::RealKMSDisplayConfiguration::add_or_update_output().
The value of DisplayConfigurationOutput::current_mode_index then doesn't
seem to change even when Mir sets a display configuration, and when the
mode bounding box is calculated, an out of bounds array access is
performed.

3) Minor thing: The "Virtual" connector type is not recognized by Mir.
(actually it's not in xf86drmMode.h either, I'll see if I can fix that
up), but it's in the kernel user-space api file "drm_mode.h" and is
right after the "eDP" connector type. Should be added in
connector_type_name() in real_kms_output.cpp

4) vmwgfx does not yet implement the drm "Prime" mechanism for sharing
of dma buffers, which Mir relies on. I'm about to implement that.
However, it seems like Mir is using dma buffers in an illegal way:
1) Mir creates a GBM bufffer.
2) Mir uses Prime to export a dma_buf handle which it shares with its
clients.
3) The client imports the dma_buf handle and uses drm to turn it into a
drm buffer handle.
4) The buffer handle is typecast to a "dumb" buffer handle, and then
mmap'ed. in struct GBMMemoryRegion : mcl::MemoryRegion.

It's illegal to typecast a GBM buffer to a dumb buffer in this way. It
accidently happens to work on the major driver because deep inside, both
a GBM buffer and a dumb buffer is represented by a GEM buffer object.
With vmwgfx that's not the case either for a GBM buffer or a dumb
buffer, and they are different objects.

In fact, currently the only way to mmap() a GBM buffer (unless it's a
cursor buffer) is to export a dma_buf and use it's mmap() operation. But
that is not implemented by any of the major drivers since it's not
really desired. The reason is that a GBM buffer is completely opaque and
may not even reside in mappable memory. Hence any attempt to map it may
result in coherence issues and, in some cases, extremely costly
operations. This results in awkward driver code that attempts to guess
the usage-patterns of applications that mix mmap'ed cpu-access and
accelerated access to the same object.

The correct way to do this is to have the client import the buffer to
the appropriate API, and use texsubImage like operations (or perhaps
readPixels / writePixels) to access the buffer from the CPU.

IMHO, I think this is something that needs to be addressed as soon as
possible.

Thanks,
Thomas



--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/mir-devel

Re: Component clarification

[Daniel van Vugt]

I agree with "mesa", but wonder is that still true if we find ourselves 
using Mesa's LLVMpipe on top of fbdev (vesa) later?



On 05/11/13 18:51, Alexandros Frantzis wrote:

On Tue, Nov 05, 2013 at 11:36:34AM +0100, Thomas Voß wrote:

On Tue, Nov 5, 2013 at 11:34 AM, Alexandros Frantzis
 wrote:

On Mon, Oct 28, 2013 at 10:41:29AM +0800, Daniel van Vugt wrote:

Yeah, very good point about "gbm". That confused me when I joined to
project too. It should be called "dri", I think.


What about just "mesa"? I think "mesa" is more recognizable, and
adequately descriptive of the backend's target driver model and APIs.
I don't think Mesa has or will have significant competing non-dri
backends. Having said that, I am fine with either "dri" or "mesa".



I would rather prefer dri as opposed to mesa. Although your argument
is technically correct, there is the difference of interface name
(dri) and implementation (mesa) and I tend to favor the interface name
perspective.


We are heavily using some Mesa components/interfaces, like GBM, that are
not part of DRI, though.

Thanks,
Alexandros



--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/mir-devel

Hold on

[Daniel van Vugt]

There seems to be a significant performance regression crept into the 
Mir code this week:

  https://bugs.launchpad.net/mir/+bug/1249210

Fortunately it happened after 0.1.1 so that release is not affected.

It looks like quite a nontrivial problem to solve, and I'm just about 
out of time for the week.


Could someone please take a look? And of course, please don't do a 
release of 0.1.2 until it's fixed :)


- Daniel

--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/mir-devel

Re: Untangling EventHub/InputReader

[Daniel van Vugt]

We do have recent precedent for putting our own input code (GPL) under 
3rd party, when it belongs next to the existing Android input stuff.


I think it's a given that we've modified Android Input beyond being able 
to pull in new versions. So new code of our own won't get lost.



On 11/11/13 12:59, Christopher James Halse Rogers wrote:

Hi all,

As a part of making Mir-on-the-desktop useful we'll need to make
touchpad (and, in general, non-touchcreen) support non-terrible.
Currently it looks like we basically take what evdev sends us and run
with it; to see how terrible that is, uninstall
xserver-xorg-input-synaptics and try to use your touchpad :).

So, we need to do some fairly significant post-evdev-pre-Mir filtering.
In order to make our lives easier this should be done by something like
libtouchpad¹. This means I'm in the market for reworking the ball of
cats that is 3rd_party/.../EventHub.cpp.

As I understand it, the EventHub is responsible for:
1) Discovering new/disappearing devices
2) Emitting events on hotplug
3) Initialising devices
4) Device configuration
5) Reading events from devices and spewing the raw evdev at the caller
6) Describing device capabilities
7) Translating between keycodes and scancodes
8) Getting axis values from devices
9) Vibrating the phone
...
Which seems a /little/ bit like a grab bag.

On top of that, InputReader appears to be responsible for processing the
raw evdev events into something that's actually useful.

This needs cleaning.

For a first go, and to allow me to add proper touchpad support in a sane
way, I think splitting out an honest Device class would be a good first
step in cleaning up.

This Device interface would be responsible for
1) Device initialisation
2) Device configuration
3) Reading events from the device, processing them, and emitting useful
output events
4) Describing device capabilities

If necessary there could be extra interfaces for touchscreens,
touchpads, keyboards, etc, but it looks to me like those are only
necessary because InputReader needs to do device post-processing.

Now, I'm not sure how we want to deal with wide-ranging changes to
3rd_party sources. Presumably we want to pull them into the src/ tree
and test it from there, and have 3rd_party have a weird dependency on
src/?

Chris

¹: https://github.com/whot/libtouchpad / also RAOF/libtouchpad





--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/mir-devel

Landing manually

[Daniel van Vugt]

All,

If you find yourself needing to land a branch manually (like while 
Jenkins is down), please remember the --author parameter...

bzr commit --author "Some Body "
It's required to retain author info in the history.

Please also remember "(LP: #1234567)" on the end of commit messages for 
bug fixes.


- Daniel

--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/mir-devel

Re: Is -Werror=pedantic necessary?

[Daniel van Vugt]

I would prefer to keep pedantic mode. Issues like using C99 
designated-initializers in C++ are actually compliance issues you should 
be told about. It's nice to know when you're no longer using the 
language standard you told the compiler you would use.


If you need to include other peoples' code which use non-compliant 
language features then why not just:


   #pragma GCC diagnostic push
   #pragma GCC diagnostic ignored "-pedantic"
   #include 
   #pragma GCC diagnostic pop

or localize the removal of pedantic (like we already do):

   string(REPLACE "-pedantic" "" CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS})



On 15/11/13 07:14, Christopher James Halse Rogers wrote:

Hey all,

Just a quick one, but one that might generate lots of discussion: should
we be building with -Werror=pedantic? What does this buy us?

It *costs* us things like C99 designated-initialisers, which are nice.

As far as I can tell from the gcc manpage, -pedantic doesn't produce
errors for code where it's likely that the behaviour intended by the
programmer doesn't match the actual behaviour (ie: it doesn't seem like
it will help catch coding errors). -pedantic *explicitly* doesn't
provide a guarantee that code that builds with -pedantic set will build
on another ISO C++-compliant compiler, and we already get most of that
benefit by building with clang anyway.

This message brought to you by my latest build failing again because of
the use of C99 designated-initialisers where they're obviously
appropriate.

(If it turns out that we do get value from -Werror=pedantic; great! I
can refer back to the message next time I get annoyed at not being able
to use sensible features ☺).

Chris





--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/mir-devel

Nesting?

[Daniel van Vugt]

I see there's some activity around nesting again. Does it work? Can we 
please have some docs on how to use it? :)


- Daniel

--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/mir-devel

Re: Is -Werror=pedantic necessary?

[Daniel van Vugt]

Unfortunately C99 is not a subset of C++11. They're very different 
things. So to assume your compiler needs to support both simultaneously 
is a danger to portability.


Portability to other platforms is nice-to-have for Mir. But also within 
Linux, static analysis tools (and compilers) will typically only handle 
strong enforcement of one language spec at a time.


I would prefer we kept strong enforcement of a standard, any standard, 
rather than relaxing the rules and making Mir less portable.


"Strong" doesn't guarantee compliance, like you say. But it's better 
than weak.



On 15/11/13 12:17, Christopher James Halse Rogers wrote:

On Fri, 2013-11-15 at 09:39 +0800, Daniel van Vugt wrote:

I would prefer to keep pedantic mode. Issues like using C99
designated-initializers in C++ are actually compliance issues you should
be told about. It's nice to know when you're no longer using the
language standard you told the compiler you would use.


This is what I'm asking - is it really? Especially given that using
-pedantic does *not* guarantee you're using the language standard you
told the compiler you would use anyway.

The standard is useful to not tie you into a single compiler, but it's
not like any sensible compiler is going to support C++11 but *not* C99,
and our clang builds already guarantee that we're not tied into a single
compiler.



If you need to include other peoples' code which use non-compliant
language features then why not just:


It's not that I want to use other peoples' non-compliant code. It's that
*I* want to write non-compliant code. Or, rather, I want to write code
that I know all non-stupid compilers are going to interpret correctly,
but isn't strictly in the C++11 spec.



--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/mir-devel

Re: Component clarification

[Daniel van Vugt]

I am "weakly for core", but have a counter-offer...

Why do we need to name this component at all? What if we put all 
clearly-defined server components in:


mir::server::COMPONENT::

And then any server-specific logic that doesn't have an obvious 
component name to live in can go in:


mir::server::

All this talk of data models is an over-complication, I feel. Let's just 
call it what it is; server. And any components which can be clearly 
defined in themselves can still be named under that.



On 18/11/13 18:27, Alan Griffiths wrote:

This came up again with my resent proposal to move Session related state
to the "surfaces" component.

On 25/10/13 15:22, Kevin Gunn wrote:

I'm ok with "state & implementation code" changing from "surface" to
"core". I'm sure others will weigh in.


I'm not convinced that it says "semantic data model" but neither does
"surfaces". But what do folks think about "core"?

Strongly For/Weakly For/Weakly Against/Strongly Against?



--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/mir-devel

Re: Component clarification

[Daniel van Vugt]

I understand "scene" and the word did cross my mind too, but I think it 
would be better to simply name things "server" because the reality is 
that it's a server-side implementation component.


Also, in Unity8-land, Unity is taking over "scene" responsibilities soon 
so it makes less sense then to name yet more things "scene" in Mir.


I think we're all getting too caught up in abstract concepts and models, 
and forgetting how to communicate effectively with 
whoever-reads-the-code-next.



On 20/11/13 03:30, Kevin DuBois wrote:

+1 to scene from me too


On Tue, Nov 19, 2013 at 11:03 AM, Kevin Gunn mailto:kevin.g...@canonical.com>> wrote:

+1 for me too
as much as i could have gotten behind diaroma...let's use scene


On Tue, Nov 19, 2013 at 8:31 AM, Thomas Voß
mailto:thomas.v...@canonical.com>> wrote:

On Tue, Nov 19, 2013 at 3:18 PM, Alan Griffiths
mailto:alan.griffi...@canonical.com>> wrote:
 > I think the natural domain name is "scene".
 >

+1.

 > It was the first suggestion and was only doubted because we've it
 > misinterpreted as implying that it /is a/ scenegraph (rather
than /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".
 >
 >

Seconded, scene feels natural to the problem domain that elements in
the namespace help solving.

Cheers,

   Thomas

 > On 19/11/13 01:38, Kevin DuBois wrote:
 >
 > 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 though,
'scene' would be my
 > preference.
 >
 >
 > Cheers,
 > Kevin
 >
 >
 > On Mon, Nov 18, 2013 at 3:32 AM, Alexandros Frantzis
 > mailto:alexandros.frant...@canonical.com>> wrote:
 >>
 >> On Mon, Nov 18, 2013 at 10:27:31AM +, Alan Griffiths wrote:
 >> > This came up again with my resent proposal to move Session
related state
 >> > to the "surfaces" component.
 >> >
 >> > On 25/10/13 15:22, Kevin Gunn wrote:
 >> > > I'm ok with "state & implementation code" changing from
"surface" to
 >> > > "core". I'm sure others will weigh in.
 >> >
 >> > I'm not convinced that it says "semantic data model" but
neither does
 >> > "surfaces". But what do folks think about "core"?
 >> >
 >> > Strongly For/Weakly For/Weakly Against/Strongly Against?
 >>
 >> I think the term "core" is at the same time too vague and
too strong.
 >> It's too vague because it doesn't describe what the "core"
component of
 >> mir contains. It's too strong because "core" forces us to
think in terms
 >> of a special core component and other non-core components,
which I don't
 >> think is appropriate for our architecture.
 >>
 >> My vote is on the stronger verge of "Weakly Against"; I am
sure we could
 >> get used to it, but I think we can do better. Some alternatives
 >> mentioned on IRC:
 >>
 >> mir::scene
 >> mir:model
 >> mir::model_controller
 >>
 >> Thanks,
 >> Alexandros
 >>
 >> --
 >> Mir-devel mailing list
 >> Mir-devel@lists.ubuntu.com 
 >> Modify settings or unsubscribe at:
 >> https://lists.ubuntu.com/mailman/listinfo/mir-devel
 >
 >
 >
 >
 > --
 > Mir-devel mailing list
 > Mir-devel@lists.ubuntu.com 
 > Modify settings or unsubscribe at:
 > https://lists.ubuntu.com/mailman/listinfo/mir-devel
 >

--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com 
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/mir-devel



--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com 
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/mir-devel






--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/mir-devel

Re: Subsurface support, or delegated compositing

[Daniel van Vugt]

(a) What's the use-case for needing to synchronize parent/child 
rendering? I'm thinking most use-cases don't need synchronization 
between the two clients. The server already ensures there's always being 
a buffer to render (without blocking) and without tearing.


(b) Why wouldn't we just deliver input to whatever is on top and 
handling input? Any events not handled by the child/subsurface can work 
down the stack (to the parent and beyond). Although I don't think we 
have the client API ability yet to designate an "input area" or to tell 
the server to replay events to the lower level.



On 25/11/13 14:51, Christopher James Halse Rogers wrote:

One of the architectural things that I want to get done at the sprint
next week is a solid idea of how we want to do nested
compositing/out-of-process plugins/subsurfaces - which all seem to me to
be aspects of the same problem.

In order to prime the discussion - and to invite outside contributions -
I thought I'd lay out the usecases as I see them before we get to
London.

There are two conceptual use-cases here -
1) “I want to delegate some of my UI to a third party”, and
2) “I need to do some compositing, and want to do this efficiently”

A Unity8 session running under unity-system-compositor falls under (2).

A video player playing a YUV stream that might also want to throw some
RGB-rendered UI over it is also (2); a video player that has some chrome
around a video widget is (1) and (2).

The “embed bits of other applications in our window” requested on
https://bugs.launchpad.net/mir/+bug/1230091 is firmly in (2).

As I see it, there are also two classes of problem:
a) How is the rendering loop coordinated between parent and child - does
the parent need to swap each time the child has new rendering, or can
the child swap independently, or are both modes available? What happens
if a child also wishes to embed children of its own?

This is the only concern for the type (2) use-case.

b) How is input handled? Does the parent need to proxy input events and
forward them on? How does enter/leave notification work for the parent
and child? Can the child return events to the parent? Etc.

This is necessary for the type (1) use-cases, and also seems to be the
hairy bit.

Weston (but not yet Wayland) currently partially solves (2) with the
subsurfaces protocol, which has chosen the “no child rendering appears
until the parent swaps” approach, and doesn't handle out of process
renderers at all.

For full out-of-process rendering, and for type-1 usecases, the my
understanding of the current state of the art is that the parent should
become a Wayland compositor itself. This seems a bit of a co-out to me,
and doesn't really solve case 2; however, this area is gnarly, so it
might prove to be the best solution.

For X, the relevant prior-art is XEMBED¹, in all of its
map-an-invisible-1x1-window-to-work-around-X11's-focus-model glory.

¹: http://standards.freedesktop.org/xembed-spec/xembed-spec-latest.html





--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/mir-devel

Re: Subsurface support, or delegated compositing

[Daniel van Vugt]

If you want to generalize Scene beyond just a stack (and I think we all 
do) then even a tree is too specific. I think the complete 
generalization is simply a queryable Scene interface which then lets the 
implementation work out the real mechanics:


Surface surface_on_top_at(Point p)
Surface next_surface_below(Surface above, Point p)

Thus you're not restricted to saying there's only one surface on top. Or 
that there's only one Surface immediately below it. The answer also 
depends on the location p. There's a world of possibility that opens up 
when you throw away the notion of a linear stack.


Although subsurfaces would have a single parent, of course.


On 26/11/13 07:40, Christopher James Halse Rogers wrote:

And this obviously only works if the model*is*  a stack, which I don't
believe it will be in general; it'll be a tree. An obvious example is a
browser window with two different pieces of flash embedded.


--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/mir-devel

Re: screenshotting, screencasting & unity8+mir

[Daniel van Vugt]

On an implementation note...

I think adding yet more library dependencies (dbus) to Mir would be a 
mistake. It's already quite bloated in that respect.


The key recording functionality in Mir shouldn't care about the 
communications anyway. So it would probably be a cleaner division of 
responsibility to make the bus communication external to libmir*. Either 
attached to unity-mir or some privileged client etc.



On 26/11/13 20:31, Daniel d'Andrada wrote:

Hi,

On November 26th I (Unity8), Kevin Gunn, Chris Gagnon (Autopilot) and
Alexandros Frantzis (Mir) had a meeting on the requirements and
implementation of screenshotting and screencasting.

Chris told us that what autopilot really wants is screencasting (not
screen shots) as it records all that happens during a test case and
publishes the resulting video in case of failure.

Kevin came with the point that application developers already want
screenshotting and screencasting and therefore the solution should also
cater to them (as opposed to having a solution that works for autopilot
now and for other/third-party applications to be done only later).

Thus considering those requirements and the future mir architecture
(using qt scenegraph), that's the implementation we agreed upon:

Unity8 would provide a D-Bus service for clients (applications,
autopilot) to request for a screencast or screenshot. In case of a
screenshot, the requestor would just provide a filename (or directory)
where the screenshot(s) should be placed and unity8 would do it. For
screencasts unity8 would provide a shared memory area to the requestor
that would be kept up to date with the contents of the screen. Access to
that shared memory area would be controlled with a semaphore and a
mutex. So the problem of handling codecs, recording and audio stream to
go along with it, etc is left to the user (i.e. an actual screencasting
application or tool).

D-Bus was chosen because access control to the screenshot/screencast
feature can be easily implemented using D-Bus security policies.
According to Alexandros, Mir probably won't have to be modified for
screen[shotting|casting]. As a QQuickWindow will be controlling the
composition now (qt-scenegraph approach), what would have to be done is
calling glReadPixels right after the scene graph is rendered, which is
essentially how "QImage QQuickWindow::grabWindow()" is implemented (if I
understood its code correctly).

So that's where I'm heading with the implementation (didn't start yet).
If someone has a better idea, sees a problem with this approach or
otherwise has something to add, please advise.

Feedback already received so far:

Thomi Richards:
  - Clarified that autopilot also wants screenshots.
  - Asked for a command line tool that does all the work of talking to
that proposed screencasting API and outputs an ogv.

Michał Sawicz:
  - "I'm not sold on the idea that it's unity8's / unity-mir's
responsibility to provide that interface, though, as the ability to do
those feels like a very generic need that should be built into the
display server itself. Maybe the fact that we might be using Qt's
scenegraph changes something here, though - but maybe that just means
there's a new project growing on unity-mir's side?"



--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/mir-devel

Re: screenshotting, screencasting & unity8+mir

[Daniel van Vugt]

Another interesting thought...

Mir already has the code to share buffers with external processes at 
high speed. Think about that for a while :)



On 27/11/13 09:38, Daniel van Vugt wrote:

On an implementation note...

I think adding yet more library dependencies (dbus) to Mir would be a
mistake. It's already quite bloated in that respect.

The key recording functionality in Mir shouldn't care about the
communications anyway. So it would probably be a cleaner division of
responsibility to make the bus communication external to libmir*. Either
attached to unity-mir or some privileged client etc.


On 26/11/13 20:31, Daniel d'Andrada wrote:

Hi,

On November 26th I (Unity8), Kevin Gunn, Chris Gagnon (Autopilot) and
Alexandros Frantzis (Mir) had a meeting on the requirements and
implementation of screenshotting and screencasting.

Chris told us that what autopilot really wants is screencasting (not
screen shots) as it records all that happens during a test case and
publishes the resulting video in case of failure.

Kevin came with the point that application developers already want
screenshotting and screencasting and therefore the solution should also
cater to them (as opposed to having a solution that works for autopilot
now and for other/third-party applications to be done only later).

Thus considering those requirements and the future mir architecture
(using qt scenegraph), that's the implementation we agreed upon:

Unity8 would provide a D-Bus service for clients (applications,
autopilot) to request for a screencast or screenshot. In case of a
screenshot, the requestor would just provide a filename (or directory)
where the screenshot(s) should be placed and unity8 would do it. For
screencasts unity8 would provide a shared memory area to the requestor
that would be kept up to date with the contents of the screen. Access to
that shared memory area would be controlled with a semaphore and a
mutex. So the problem of handling codecs, recording and audio stream to
go along with it, etc is left to the user (i.e. an actual screencasting
application or tool).

D-Bus was chosen because access control to the screenshot/screencast
feature can be easily implemented using D-Bus security policies.
According to Alexandros, Mir probably won't have to be modified for
screen[shotting|casting]. As a QQuickWindow will be controlling the
composition now (qt-scenegraph approach), what would have to be done is
calling glReadPixels right after the scene graph is rendered, which is
essentially how "QImage QQuickWindow::grabWindow()" is implemented (if I
understood its code correctly).

So that's where I'm heading with the implementation (didn't start yet).
If someone has a better idea, sees a problem with this approach or
otherwise has something to add, please advise.

Feedback already received so far:

Thomi Richards:
  - Clarified that autopilot also wants screenshots.
  - Asked for a command line tool that does all the work of talking to
that proposed screencasting API and outputs an ogv.

Michał Sawicz:
  - "I'm not sold on the idea that it's unity8's / unity-mir's
responsibility to provide that interface, though, as the ability to do
those feels like a very generic need that should be built into the
display server itself. Maybe the fact that we might be using Qt's
scenegraph changes something here, though - but maybe that just means
there's a new project growing on unity-mir's side?"





--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/mir-devel

Re: screenshotting, screencasting & unity8+mir

[Daniel van Vugt]

In fact, there's probably no reason why we can't just add a special 
function:

mir_connection_create_readback_surface()

Such a surface would work in reverse for a single DisplayBuffer. You 
could read from it by existing means (like 
mir_surface_get_current_buffer) to get the framebuffer, but swapping it 
just provides you with "the next composited frame". A readback surface 
never affects screen contents, only returns them.


I think I prototyped something that worked like that when experimenting 
in the early days of GBM bypass support.


The only significant challenge then is enforcing security. Deciding how 
to authenticate a privileged client before it can 
mir_connection_create_readback_surface()...


Regardless of the actual implementation details, I think we would be 
silly to not utilize the existing buffer IPC code we already have.



On 27/11/13 09:41, Daniel van Vugt wrote:

Another interesting thought...

Mir already has the code to share buffers with external processes at
high speed. Think about that for a while :)


On 27/11/13 09:38, Daniel van Vugt wrote:

On an implementation note...

I think adding yet more library dependencies (dbus) to Mir would be a
mistake. It's already quite bloated in that respect.

The key recording functionality in Mir shouldn't care about the
communications anyway. So it would probably be a cleaner division of
responsibility to make the bus communication external to libmir*. Either
attached to unity-mir or some privileged client etc.


On 26/11/13 20:31, Daniel d'Andrada wrote:

Hi,

On November 26th I (Unity8), Kevin Gunn, Chris Gagnon (Autopilot) and
Alexandros Frantzis (Mir) had a meeting on the requirements and
implementation of screenshotting and screencasting.

Chris told us that what autopilot really wants is screencasting (not
screen shots) as it records all that happens during a test case and
publishes the resulting video in case of failure.

Kevin came with the point that application developers already want
screenshotting and screencasting and therefore the solution should also
cater to them (as opposed to having a solution that works for autopilot
now and for other/third-party applications to be done only later).

Thus considering those requirements and the future mir architecture
(using qt scenegraph), that's the implementation we agreed upon:

Unity8 would provide a D-Bus service for clients (applications,
autopilot) to request for a screencast or screenshot. In case of a
screenshot, the requestor would just provide a filename (or directory)
where the screenshot(s) should be placed and unity8 would do it. For
screencasts unity8 would provide a shared memory area to the requestor
that would be kept up to date with the contents of the screen. Access to
that shared memory area would be controlled with a semaphore and a
mutex. So the problem of handling codecs, recording and audio stream to
go along with it, etc is left to the user (i.e. an actual screencasting
application or tool).

D-Bus was chosen because access control to the screenshot/screencast
feature can be easily implemented using D-Bus security policies.
According to Alexandros, Mir probably won't have to be modified for
screen[shotting|casting]. As a QQuickWindow will be controlling the
composition now (qt-scenegraph approach), what would have to be done is
calling glReadPixels right after the scene graph is rendered, which is
essentially how "QImage QQuickWindow::grabWindow()" is implemented (if I
understood its code correctly).

So that's where I'm heading with the implementation (didn't start yet).
If someone has a better idea, sees a problem with this approach or
otherwise has something to add, please advise.

Feedback already received so far:

Thomi Richards:
  - Clarified that autopilot also wants screenshots.
  - Asked for a command line tool that does all the work of talking to
that proposed screencasting API and outputs an ogv.

Michał Sawicz:
  - "I'm not sold on the idea that it's unity8's / unity-mir's
responsibility to provide that interface, though, as the ability to do
those feels like a very generic need that should be built into the
display server itself. Maybe the fact that we might be using Qt's
scenegraph changes something here, though - but maybe that just means
there's a new project growing on unity-mir's side?"







--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/mir-devel

Re: screenshotting, screencasting & unity8+mir

[Daniel van Vugt]

Keeping in mind recording at full frame rate (or near) would solve both 
problems, I think we should have a single approach.


The key thing to remember is bandwidth. Only the buffer sharing logic 
used in client IPC has the bandwidth to cope with recording/screencasting.


Consider: 1920x1200 x 4bytesperpixel x 60FPS
--> 553 megabytes per second

Or even: 1366x768 x 4bytesperpixel x 30FPS
--> 126 megabytes per second

Hopefully it would be encoded more efficiently for storage, but still, 
you need to use buffer IPC that's designed for speed. Fortunately we 
have that already.



On 27/11/13 23:30, Ricardo Mendoza wrote:

On Wed, 2013-11-27 at 07:32 +0100, Thomas Voß wrote:

On Tue, Nov 26, 2013 at 4:12 PM, Alexandros Frantzis
 wrote:

On Tue, Nov 26, 2013 at 01:13:28PM +, Gerry Boland wrote:

Hey,
The system compositor will probably not be using the Qt scenegraph, but
instead Mir's own compositor. I don't know if using
QQuickWindow::grabWindow() will work in that case (though if it just
calls glReadPixels, it probably will).

Also if hardware (non-GL) compositing is being used, reading back pixels
via glReadPixels won't be enough as not everything on screen will be
drawn by GL.


The original discussion was about autopilot being able to take
screenshots/casts of unity8 for testing and validation purposes, and we
came up with a simple solution for this use case.



That's a fair point. As I understand it, there is the immediate
requirement to support QA with screenshotting capabilities and the
presented approach can be used to provide the required functionality.


Back to this, providing a screenshotting interface with a default file
sink is a matter of... 30 minutes? I believe extending the
com.canonical.Unity.Screen interface; as long as you decide on a place
to put screenshot files and a default format.

I believe we should provide this right away for QA, the rest of the plan
seems more broad and therefore not really committable to a strict
timeframe. I agree that casting would be great and that we need it, just
not sure if its the right time to slot it into the dev plan.


However, it seems that people have more use cases for screen capturing
that require additional complexity. I think we need to discuss a bit
more about what we really need and when, check what is feasible in our
time frames and prioritize work. The upcoming sprint seems ideal for
this.



+1.

Cheers,

   Thomas


Thanks,
Alexandros


Regards,


  Ricardo




--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/mir-devel

Unity8 performance boost, almost there

[Daniel van Vugt]

All,

It's been a while coming, but the pieces are almost all in place for 
what could be a significant performance boost to Unity 8.


It started with basic occlusion detection in Mir:
https://bugs.launchpad.net/mir/+bug/1227739

And then recently progressed with opaque pixel format support:
https://bugs.launchpad.net/mir/+bug/1240833

So now the only piece missing is a fix for platform-api, to choose a 
non-alpha pixel format by fixing:


static MirPixelFormat
mir_choose_default_pixel_format(MirConnection *connection)
{
MirDisplayInfo info;
mir_connection_get_display_info(connection, &info);
return info.supported_pixel_format[0];
}

(https://bugs.launchpad.net/mir/+bug/1227739)

When all put together with Mir 0.1.2+, I hope you will find the Unity8 
touch experience to be noticeably smoother.


- Daniel

--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/mir-devel

Re: Nesting?

[Daniel van Vugt]

Hello?

On 15/11/13 02:54, Daniel van Vugt wrote:

I see there's some activity around nesting again. Does it work? Can we
please have some docs on how to use it? :)

- Daniel



--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/mir-devel

Re: Unity8 performance boost, almost there

[Daniel van Vugt]

Just waiting for Mir 0.1.2 to hit the archive (now done), _and_ for 
someone to fix platform-api 
(https://bugs.launchpad.net/mir/+bug/1227739). That could be me, or 
anyone else...



On 02/12/13 19:58, Oliver Ries wrote:

On Wed, Nov 27, 2013 at 8:22 PM, Daniel van Vugt
mailto:daniel.van.v...@canonical.com>>
wrote:

All,

It's been a while coming, but the pieces are almost all in place for
what could be a significant performance boost to Unity 8.

...

When all put together with Mir 0.1.2+, I hope you will find the
Unity8 touch experience to be noticeably smoother.


that's exciting, when will this be available?


--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/mir-devel

Bugs

[Daniel van Vugt]

All,

Several times recently, people have been talking about issues that 
already have bugs for them, but people are not familiar with the bugs.


It's probably a good idea to familiarize yourself with at least the most 
severe bugs:

https://bugs.launchpad.net/mir/+bugs
https://bugs.launchpad.net/xmir/+bugs
https://bugs.launchpad.net/unity-system-compositor/+bugs

- Daniel

--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/mir-devel

Re: Nesting?

[Daniel van Vugt]

Update:
Nesting doesn't yet work on desktop because requisite Mesa changes 
aren't in Ubuntu yet.


It does work on Android, but only on some devices (like Nexus 4) right now.


On 03/12/13 16:20, Alan Griffiths wrote:

On 03/12/13 16:07, Daniel van Vugt wrote:

Hello?

On 15/11/13 02:54, Daniel van Vugt wrote:

I see there's some activity around nesting again. Does it work? Can we
please have some docs on how to use it? :)

- Daniel





mir_demo_server_basic -h
...
   --host-socket arg Host socket filename.
[string:default={$MIR_SOC
 KET,$XDG_RUNTIME_DIR/mir_socket}]




--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/mir-devel

Re: Switching mode with XMir

[Daniel van Vugt]

Thomas,

XMir is a relatively small thing. There is no documentation specifically 
for XMir, but I think you will find answers in:


https://github.com/RAOF/xserver/blob/vladmir-upstreaming/hw/xfree86/xmir/xmir-output.c
or more generally:
   https://github.com/RAOF/xserver/tree/vladmir-upstreaming/hw/xfree86/xmir

There are some known issues with XMir mode switching, listed here:
   https://bugs.launchpad.net/xmir/+bugs?field.tag=multimonitor

Further questions specifically about XMir? Chris Halse Rogers is the 
expert (and author).


- Daniel


On 09/12/13 18:43, Thomas Hellstrom wrote:

Hi!

Is there any documentation on how modeswitching with XMir is done, and
by that I mean
what mechanism is used to resize the root pixmap?

I assume the xf86Crtc system is completely bypassed?

Is SwitchMode and ValidMode ever called, or is XMir simply calling
modifyPixmapHeader on the root pixmap
to switch modes?

Any insight would be appreciated.

Thanks,
Thomas Hellström, VMware



--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/mir-devel

Re: Bugs

[Daniel van Vugt]

I try to do so every day. Was something missed?

mir-team likely won't see most of the bug traffic because it wasn't 
subscribed to them last I checked. Robert Ancell said he preferred it 
that way, so people could opt-in. It's harder to opt-out. Although I 
personally think mir-team should be subscribed to all Mir bug sources.



On 11/12/13 12:02, Ricardo Salveti wrote:

On Wed, Dec 4, 2013 at 12:30 PM, Daniel van Vugt
 wrote:

All,

Several times recently, people have been talking about issues that already
have bugs for them, but people are not familiar with the bugs.

It's probably a good idea to familiarize yourself with at least the most
severe bugs:
 https://bugs.launchpad.net/mir/+bugs
 https://bugs.launchpad.net/xmir/+bugs
 https://bugs.launchpad.net/unity-system-compositor/+bugs


Do you know if we also have someone doing bug triaging for the
package-specific launchpad tasks (and maybe linking them with the
upstream projects)?

Such as:
https://bugs.launchpad.net/ubuntu/+source/mir
https://bugs.launchpad.net/ubuntu/+source/unity-system-compositor

Cheers,



--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/mir-devel

Re: Bugs

[Daniel van Vugt]

Yeah, we had a rude shock when people started using XMir last cycle. 
Bugs were piling up against the package tasks for some time, invisible 
to the upstream projects and invisible to mir-team. Now we're aware of 
it I think it's under control.


Anyone who wants to see all Mir bug reports should subscribe to all Mir 
bug sources:


https://bugs.launchpad.net/mir/+bugs
https://bugs.launchpad.net/ubuntu/+source/mir/+bugs
https://bugs.launchpad.net/xmir/+bugs
https://bugs.launchpad.net/ubuntu/+source/xmir/+bugs
https://bugs.launchpad.net/unity-system-compositor/+bugs
https://bugs.launchpad.net/ubuntu/+source/unity-system-compositor/+bugs

A bug report in any of those could of course be a Mir bug. Users rarely 
file against the right project/package first time.



On 11/12/13 12:11, Ricardo Salveti wrote:

On Wed, Dec 11, 2013 at 2:05 AM, Daniel van Vugt
 wrote:

I try to do so every day. Was something missed?


Nothing specifically, just checking as we had some bad experience with
a few canonical-upstream projects in the past (people not checking the
packaging bugs at all).

Thanks for taking care of those bugs :-)


mir-team likely won't see most of the bug traffic because it wasn't
subscribed to them last I checked. Robert Ancell said he preferred it that
way, so people could opt-in. It's harder to opt-out. Although I personally
think mir-team should be subscribed to all Mir bug sources.


Yeah, I see no reason why the mir-team would only track bugtasks
assigned to the upstream project, as ideally we want trunk to be in
sync with the package anyway.

Thanks,



--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/mir-devel

Lotsa numbers

[Daniel van Vugt]

The current archive release of Mir is:
0.1.2+14.04.20131128.1-0ubuntu2

But do we really need to keep all that  date info? Surely all we really 
want is:

0.1.2-0ubuntu2

It's just as unique, and less a jumble of numbers. It might also stop 
Launchpad from complaining:

"Mir 0.1.2 is older than the current packaged version"...

- Daniel

--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/mir-devel

CI failures

[Daniel van Vugt]

It seems CI has become a little over-ambitious recently and no branch 
can pass all the runs. Can we disable the broken ones?



On 11/12/13 17:01, PS Jenkins bot wrote:

Review: Needs Fixing continuous-integration

FAILED: Continuous integration, rev:1282
http://jenkins.qa.ubuntu.com/job/mir-team-mir-development-branch-ci/514/
Executed test runs:
 FAILURE: 
http://jenkins.qa.ubuntu.com/job/mir-android-trusty-i386-build/401/console
 SUCCESS: http://jenkins.qa.ubuntu.com/job/mir-clang-trusty-amd64-build/397
 FAILURE: 
http://jenkins.qa.ubuntu.com/job/mir-mediumtests-trusty-touch/6/console
 SUCCESS: 
http://jenkins.qa.ubuntu.com/job/mir-team-mir-development-branch-trusty-amd64-ci/240
 deb: 
http://jenkins.qa.ubuntu.com/job/mir-team-mir-development-branch-trusty-amd64-ci/240/artifact/work/output/*zip*/output.zip
 SUCCESS: 
http://jenkins.qa.ubuntu.com/job/mir-team-mir-development-branch-trusty-armhf-ci/243
 deb: 
http://jenkins.qa.ubuntu.com/job/mir-team-mir-development-branch-trusty-armhf-ci/243/artifact/work/output/*zip*/output.zip
 SUCCESS: 
http://jenkins.qa.ubuntu.com/job/mir-mediumtests-builder-trusty-armhf/6
 deb: 
http://jenkins.qa.ubuntu.com/job/mir-mediumtests-builder-trusty-armhf/6/artifact/work/output/*zip*/output.zip
 FAILURE: 
http://jenkins.qa.ubuntu.com/job/mir-mediumtests-runner-mako/45/console
 SUCCESS: http://s-jenkins.ubuntu-ci:8080/job/touch-flash-device/2218

Click here to trigger a rebuild:
http://s-jenkins.ubuntu-ci:8080/job/mir-team-mir-development-branch-ci/514/rebuild



--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/mir-devel

Re: Bugs

[Daniel van Vugt]

I don't think there's anything different about the Mir project. Just the 
standard Ubuntu instructions. All the relevant links are here:


https://wiki.ubuntu.com/HelpingWithBugs


On 11/12/13 18:23, Oliver Ries wrote:

On Tue, Dec 10, 2013 at 9:18 PM, Daniel van Vugt
mailto:daniel.van.v...@canonical.com>>
wrote:

Yeah, we had a rude shock when people started using XMir last cycle.
Bugs were piling up against the package tasks for some time,
invisible to the upstream projects and invisible to mir-team. Now
we're aware of it I think it's under control.

Anyone who wants to see all Mir bug reports should subscribe to all
Mir bug sources:

https://bugs.launchpad.net/__mir/+bugs
<https://bugs.launchpad.net/mir/+bugs>
https://bugs.launchpad.net/__ubuntu/+source/mir/+bugs
<https://bugs.launchpad.net/ubuntu/+source/mir/+bugs>
https://bugs.launchpad.net/__xmir/+bugs
<https://bugs.launchpad.net/xmir/+bugs>
https://bugs.launchpad.net/__ubuntu/+source/xmir/+bugs
<https://bugs.launchpad.net/ubuntu/+source/xmir/+bugs>
https://bugs.launchpad.net/__unity-system-compositor/+bugs
<https://bugs.launchpad.net/unity-system-compositor/+bugs>
https://bugs.launchpad.net/__ubuntu/+source/unity-system-__compositor/+bugs
<https://bugs.launchpad.net/ubuntu/+source/unity-system-compositor/+bugs>

A bug report in any of those could of course be a Mir bug. Users
rarely file against the right project/package first time.


just a random comment (oh beware...:)

I think it's flawed if a project (e.g. Mir) does not actively look at
the bugs of it's key consumer (i.e. Ubuntu). I really appreciate
Daniel's effort in triaging all the bug, but that might be an issue
if/when he is going on vacation etc.

@mir-developers, I would suggest that you make this a team effort to
support Daniel in this task.

@Daniel, do you have some documentation to guide new contributors in
that effort? (thinking of coordinated use of states, importance etc)

thx
Olli




On 11/12/13 12:11, Ricardo Salveti wrote:

On Wed, Dec 11, 2013 at 2:05 AM, Daniel van Vugt
mailto:daniel.van.v...@canonical.com>__> wrote:

I try to do so every day. Was something missed?


Nothing specifically, just checking as we had some bad
experience with
a few canonical-upstream projects in the past (people not
checking the
packaging bugs at all).

Thanks for taking care of those bugs :-)

mir-team likely won't see most of the bug traffic because it
wasn't
subscribed to them last I checked. Robert Ancell said he
preferred it that
way, so people could opt-in. It's harder to opt-out.
Although I personally
think mir-team should be subscribed to all Mir bug sources.


Yeah, I see no reason why the mir-team would only track bugtasks
assigned to the upstream project, as ideally we want trunk to be in
sync with the package anyway.

Thanks,


--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com <mailto:Mir-devel@lists.ubuntu.com>
Modify settings or unsubscribe at:
https://lists.ubuntu.com/__mailman/listinfo/mir-devel
<https://lists.ubuntu.com/mailman/listinfo/mir-devel>




--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/mir-devel

Re: Lotsa numbers

[Daniel van Vugt]

"0.1.2" is the upstream version number, and there is only one tarball;
  https://launchpad.net/mir/+milestone/0.1.2

I'm not sure where the suggestion of multiple upstream tarballs comes from.

For iterations between upstream releases, we have the -NubuntuM suffix. 
That's what it's for (!?).



On 12/12/13 03:51, Michał Sawicz wrote:

On 11.12.2013 19:46, Kevin Gunn wrote:

I can't remember exactly why, but I believe its the release teams
process to add the date in when they insert it into archive.


0.1.2+14.04.20131128.1-0ubuntu2

Upstream_Version+Target_Release.Date[.Iteration]

AFAICT the purpose was to be able to easily determine what the package
really is - as in what it's targeted for (14.04) and the unique release
date (+optional iteration, if there were two on the same day).

On top of that, 0.1.2 alone can't be the upstream version number, as
code changes would be rejected by dpkg - you can't have two upstream
.orig tarballs with different contents (that generally excludes the
debian/ folder).



--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/mir-devel

Re: CI failures

[Daniel van Vugt]

Of course I was not suggesting disabling tests. Just to disable broken 
test _machines_.


It appears they're all fixed today, so problem solved :)


On 12/12/13 00:01, Chris Gagnon wrote:

The demos say there is an error because of output on stderr, but it
won't fail the build because of it. Currently it will block the build
when an integration test or acceptance test fails.

These tests pass when  I ran CI on the current trunk of the
mir-development branch[1]  and the tests passed, the test also passed
before enabling CI more than one time. It looks like the new code is
causing these tests to fail.

We cannot disable tests when they start to fail.

[1] http://s-jenkins.ubuntu-ci:8080/job/mir-mediumtests-trusty-touch/8/

On Wed, Dec 11, 2013 at 4:04 AM, Daniel van Vugt
mailto:daniel.van.v...@canonical.com>>
wrote:

It seems CI has become a little over-ambitious recently and no
branch can pass all the runs. Can we disable the broken ones?


On 11/12/13 17:01, PS Jenkins bot wrote:

Review: Needs Fixing continuous-integration

FAILED: Continuous integration, rev:1282

http://jenkins.qa.ubuntu.com/__job/mir-team-mir-development-__branch-ci/514/

<http://jenkins.qa.ubuntu.com/job/mir-team-mir-development-branch-ci/514/>
Executed test runs:
  FAILURE:

http://jenkins.qa.ubuntu.com/__job/mir-android-trusty-i386-__build/401/console

<http://jenkins.qa.ubuntu.com/job/mir-android-trusty-i386-build/401/console>
  SUCCESS:
http://jenkins.qa.ubuntu.com/__job/mir-clang-trusty-amd64-__build/397
<http://jenkins.qa.ubuntu.com/job/mir-clang-trusty-amd64-build/397>
  FAILURE:

http://jenkins.qa.ubuntu.com/__job/mir-mediumtests-trusty-__touch/6/console

<http://jenkins.qa.ubuntu.com/job/mir-mediumtests-trusty-touch/6/console>
  SUCCESS:

http://jenkins.qa.ubuntu.com/__job/mir-team-mir-development-__branch-trusty-amd64-ci/240

<http://jenkins.qa.ubuntu.com/job/mir-team-mir-development-branch-trusty-amd64-ci/240>
  deb:

http://jenkins.qa.ubuntu.com/__job/mir-team-mir-development-__branch-trusty-amd64-ci/240/__artifact/work/output/*zip*/__output.zip

<http://jenkins.qa.ubuntu.com/job/mir-team-mir-development-branch-trusty-amd64-ci/240/artifact/work/output/*zip*/output.zip>
  SUCCESS:

http://jenkins.qa.ubuntu.com/__job/mir-team-mir-development-__branch-trusty-armhf-ci/243

<http://jenkins.qa.ubuntu.com/job/mir-team-mir-development-branch-trusty-armhf-ci/243>
  deb:

http://jenkins.qa.ubuntu.com/__job/mir-team-mir-development-__branch-trusty-armhf-ci/243/__artifact/work/output/*zip*/__output.zip

<http://jenkins.qa.ubuntu.com/job/mir-team-mir-development-branch-trusty-armhf-ci/243/artifact/work/output/*zip*/output.zip>
  SUCCESS:

http://jenkins.qa.ubuntu.com/__job/mir-mediumtests-builder-__trusty-armhf/6

<http://jenkins.qa.ubuntu.com/job/mir-mediumtests-builder-trusty-armhf/6>
  deb:

http://jenkins.qa.ubuntu.com/__job/mir-mediumtests-builder-__trusty-armhf/6/artifact/work/__output/*zip*/output.zip

<http://jenkins.qa.ubuntu.com/job/mir-mediumtests-builder-trusty-armhf/6/artifact/work/output/*zip*/output.zip>
  FAILURE:

http://jenkins.qa.ubuntu.com/__job/mir-mediumtests-runner-__mako/45/console

<http://jenkins.qa.ubuntu.com/job/mir-mediumtests-runner-mako/45/console>
  SUCCESS:
http://s-jenkins.ubuntu-ci:__8080/job/touch-flash-device/__2218
<http://s-jenkins.ubuntu-ci:8080/job/touch-flash-device/2218>

Click here to trigger a rebuild:

http://s-jenkins.ubuntu-ci:__8080/job/mir-team-mir-__development-branch-ci/514/__rebuild

<http://s-jenkins.ubuntu-ci:8080/job/mir-team-mir-development-branch-ci/514/rebuild>




--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/mir-devel

Re: Shell communication channel: simple, half-assed or fully-arsed?

[Daniel van Vugt]

"Half-assed" is inaccurate I think. Under that heading you describe 
what we had already agreed to do (as much as the team can agree on 
something).


I suggest being careful trying to merge the existing areas of opacity in 
the protocol. I'm not sure they belong together.


Protobuf is quite extendable already. Are we not using it in a way 
that's compatible with extension? I'm not a fan of protobuf, and am even 
open to the idea of trying the Wayland protocol, but I don't yet see a 
serious problem with protobuf that needs solving.



On 11/12/13 22:00, Alan Griffiths wrote:

I'm trying to summarise some discussions around the need for Mir to
provide a ABI stable channel of communications to shells and client
toolkits (such as unity8/platform-api) that make use of it. This should
allow messages to be passed that Mir has no need nor ability to interpret.

Future nice-to-haves:
   o consistency between shells and a framework for protocol extensions
   o some messages to be meaningful to Mir to enable optimizations
   o Migrating the current API (e.g. attribute setting) onto the same
channel

There are several approaches to this.

*Simple/Simplistic

*This is what I've sketched out in
https://code.launchpad.net/~alan-griffiths/mir/message-passing-api/+merge/198422

Mir simply punts all concerns about protocol negotiation, versioning and
structure to the shell and relies on the shell to provide all
information that Mir will ever need.

The advantage of this approach is that we can do it without further
discussion and unblock unity8 work.

The disadvantage of this approach is that the "nice to haves" are left
as an exercise for the interested Mir user.

*Half-assed*

Mir can provide some helpful fields - e.g. a protocol-id,
version-number**and message-discriminator to pass with the message - and
define some base protocols (sizing, copy-paste, protocol-extension). Mir
(or "shellinator") can then implement defaults for the base protocols.

We discussed this last week and felt that it raised more issues than it
addressed.

*fully-arsed*

Projects like X11 and Wayland have effective protocol definition and
extension mechanisms. We should build on this - Wayland being the better
example as it builds on the X11 experience.

I don't yet have a clear vision of what a successful implementation of
this approach looks like - and suspect that different team members have
differing thoughts on how we would go about this.

*Conclusion*

I think that we should discuss the fully-arsed and flesh out some
specific ideas. But as that may not lead to a quick (or any) conclusion
it is worth implementing the simple approach in parallel so as to
unblock unity8 development.




--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/mir-devel

Re: Bugs

[Daniel van Vugt]

:)

Correction; XMir is in:
https://bugs.launchpad.net/xmir/+bugs
https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bugs


On 11/12/13 22:43, Timo Aaltonen wrote:

On 11.12.2013 06:18, Daniel van Vugt wrote:

Yeah, we had a rude shock when people started using XMir last cycle.
Bugs were piling up against the package tasks for some time, invisible
to the upstream projects and invisible to mir-team. Now we're aware of
it I think it's under control.

Anyone who wants to see all Mir bug reports should subscribe to all Mir
bug sources:

https://bugs.launchpad.net/ubuntu/+source/xmir/+bugs


this doesn't exist




--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/mir-devel

Re: Lotsa numbers

[Daniel van Vugt]

Oh, I see where the confusion is.

No, Mir is not on daily releases because it affects too many other 
projects and we need to manually coordinate ABI/API changes for each 
release. Mir is on weekly-ish releases, all of which have proper version 
numbers. Hence, only one tarball :)



On 12/12/13 16:20, Michał Sawicz wrote:

On 12.12.2013 02:19, Daniel van Vugt wrote:

"0.1.2" is the upstream version number, and there is only one tarball;
https://launchpad.net/mir/+milestone/0.1.2

I'm not sure where the suggestion of multiple upstream tarballs comes
from.


Do you bump the upstream version number between packages into going into
Ubuntu? As in - is there really only one code tree per-upstream-version?

It's not the case for most other projects under daily release, at least
- we only bump the version numbers when needed for dependency reasons
(or well, when it makes sense). Difference is we're not doing dev branch
vs. trunk, all code goes into trunk, and it's the release team that
ultimately decides when to release. Sure, we could bump after each
release, but that's what the automagic release does for us, effectively.
It's a kind-of-rolling-release scenario for us.


For iterations between upstream releases, we have the -NubuntuM suffix.
That's what it's for (!?).


Downstream releases, no? You can't change the upstream code between
differently-suffixed packages (other than putting patches in debian/,
that is).



--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/mir-devel

Re: Bugs

[Daniel van Vugt]

XMir support is still in distro. It's not in a form that represents the 
end goal, but I don't think we had plans to remove it either.


Some users report that XMir is useful in smoothing out their desktop 
experience... where the default X driver doesn't page flip as nicely as 
Mir does (!?). So it does have users :)



On 12/12/13 17:18, Timo Aaltonen wrote:

On 12.12.2013 08:45, Daniel van Vugt wrote:

:)

Correction; XMir is in:
https://bugs.launchpad.net/xmir/+bugs
https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bugs


yes, looks better :)

also, during saucy we got a bunch of crashers against
xserver-xorg-video-intel that turned out to be due to xmir. Is running a
full xmir session still supposed to be supported? I'd expect not, now
that we're not doing that by default. From what I understand the
situation with rootless xmir is much different and shouldn't hit (all)
these issues..




--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/mir-devel

Input latency

[Daniel van Vugt]

Here are some fun numbers I've collected about the latency between input 
events sent from the top-level Mir server to a client. All in 
milliseconds...


Desktop (3.12.0-7-generic)
Direct 0.8ms
Nested 1.3ms

Desktop (3.11.0-11-lowlatency)
Direct 1.0ms
Nested 1.7ms

Nexus4 (3.4.0-3-mako)
Direct 0.9ms
Nested 1.5ms with high variance; frequent spikes to 73ms. Sometimes 700ms.

The above numbers are for motion events. Key events appear to be twice 
as fast (half the latency). This suggests we could yet optimize the 
processing of motion events to perform better like key events do.


In summary, we're looking pretty good. Only the Nexus has potential 
usability issues, and even then, only with nested servers.


- Daniel

--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/mir-devel

Re: Shell communication channel: simple, half-assed or fully-arsed?

[Daniel van Vugt]

I assume you're not talking about exposing the fact that Mir uses 
protobuf to shell+toolkits? You still mean hiding extendability behind a 
library, right?


I'm still mostly trying to not have an opinion on this thread, but to 
break the information hiding we have now and expose the underlying 
protocol library to the shell or toolkit sounds like a bad idea. 
Information hiding is useful.



On 13/12/13 19:33, Alan Griffiths wrote:

On 12/12/13 12:35, Thomas Voß wrote:

This could quite easily be implemented on top of:

   
https://developers.google.com/protocol-buffers/docs/reference/cpp/google.protobuf.dynamic_message


Summarizing discussion from hangout...

The use of a definition language and code generation isn't a short term
option - but is nice for the future.

Short term we're going with:

Mir client and server provide a "-private-def" package with C++
interfaces into the communications protocol that allows shell+toolkit(s)
to pass arbitrary protobuf messages.

This will allow unity8/platform-api to prototype and refine interfaces
before they are migrated into the core Mir APIs

This mechanism will need some methods for identifying and transmitting
FDs across the socket (e.g. a special field name.) This is something
that was not allowed for in the raw buffer approach described in the OP.




--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/mir-devel

Re: Input latency

[Daniel van Vugt]

If I had a theory, I could test if it correlates with the spikes. At the 
moment I don't even have a theory.


The other weird thing I didn't mention was that the "lowlatency" kernel 
has higher latency :). But it was worth a try. As are different kernel 
schedulers, I haven't tried playing with them yet.



On 13/12/13 18:27, Christopher James Halse Rogers wrote:

On Fri, 2013-12-13 at 17:31 +0800, Daniel van Vugt wrote:

Here are some fun numbers I've collected about the latency between input
events sent from the top-level Mir server to a client. All in
milliseconds...

Desktop (3.12.0-7-generic)
Direct 0.8ms
Nested 1.3ms

Desktop (3.11.0-11-lowlatency)
Direct 1.0ms
Nested 1.7ms

Nexus4 (3.4.0-3-mako)
Direct 0.9ms
Nested 1.5ms with high variance; frequent spikes to 73ms. Sometimes 700ms.


Do we have any way to get insight into the spikes? Something strange is
obviously happening when the variance is ~3 orders of magnitude.





--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/mir-devel

Re: Input latency

[Daniel van Vugt]

Yes indeed. I did think about that, but if you look at the merge 
proposal it's all about using the existing reports unmodified right now. 
And my primary task was to assess the feasibility of nesting vs non-nested.


I wasn't going to spend any more time on input latency measurements this 
week but perhaps there is sufficient interest to get more details...



On 16/12/13 14:27, Andreas Pokorny wrote:

Hi,
Can we split the times up? .. decoding from evdev until a EV_SYN ..
internal processing in the shell.. transfer to client?



On Mon, Dec 16, 2013 at 6:52 AM, Daniel van Vugt
mailto:daniel.van.v...@canonical.com>>
wrote:

If I had a theory, I could test if it correlates with the spikes. At
the moment I don't even have a theory.

The other weird thing I didn't mention was that the "lowlatency"
kernel has higher latency :). But it was worth a try. As are
different kernel schedulers, I haven't tried playing with them yet.



On 13/12/13 18:27, Christopher James Halse Rogers wrote:

    On Fri, 2013-12-13 at 17:31 +0800, Daniel van Vugt wrote:

Here are some fun numbers I've collected about the latency
between input
events sent from the top-level Mir server to a client. All in
milliseconds...

Desktop (3.12.0-7-generic)
Direct 0.8ms
Nested 1.3ms

Desktop (3.11.0-11-lowlatency)
Direct 1.0ms
Nested 1.7ms

Nexus4 (3.4.0-3-mako)
Direct 0.9ms
Nested 1.5ms with high variance; frequent spikes to 73ms.
Sometimes 700ms.


Do we have any way to get insight into the spikes? Something
strange is
obviously happening when the variance is ~3 orders of magnitude.




--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com <mailto:Mir-devel@lists.ubuntu.com>
Modify settings or unsubscribe at:
https://lists.ubuntu.com/__mailman/listinfo/mir-devel
<https://lists.ubuntu.com/mailman/listinfo/mir-devel>




--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/mir-devel

Re: Input latency

[Daniel van Vugt]

Existing reports, output as logs, collated across the multiple processes 
using awk.


The procedure of collating the data isn't relevant to the accuracy of 
the results. The accuracy hinges on the timestamps in the log reports, 
which seem pretty accurate (I've compared with other timing APIs). 
Perhaps some time in future we could convince LTTNG to correlate the 
data like my script does, but I'm not sure how to make LTTNG gather and 
match data across multiple processes.


P.S. I wanted to attend your LTTNG talk in London but was trapped in a 
meeting at the time :)



On 16/12/13 14:44, Thomas Voß wrote:

On Mon, Dec 16, 2013 at 7:30 AM, Daniel van Vugt
 wrote:

Yes indeed. I did think about that, but if you look at the merge proposal
it's all about using the existing reports unmodified right now. And my
primary task was to assess the feasibility of nesting vs non-nested.

I wasn't going to spend any more time on input latency measurements this
week but perhaps there is sufficient interest to get more details...




Out of curiosity: When you say leveraging existing reports, does that
mean this evaluation is using the lttng traces?

Thanks,

   Thomas



On 16/12/13 14:27, Andreas Pokorny wrote:


Hi,
Can we split the times up? .. decoding from evdev until a EV_SYN ..
internal processing in the shell.. transfer to client?



On Mon, Dec 16, 2013 at 6:52 AM, Daniel van Vugt
mailto:daniel.van.v...@canonical.com>>

wrote:

 If I had a theory, I could test if it correlates with the spikes. At
 the moment I don't even have a theory.

 The other weird thing I didn't mention was that the "lowlatency"
 kernel has higher latency :). But it was worth a try. As are
 different kernel schedulers, I haven't tried playing with them yet.



 On 13/12/13 18:27, Christopher James Halse Rogers wrote:

     On Fri, 2013-12-13 at 17:31 +0800, Daniel van Vugt wrote:

 Here are some fun numbers I've collected about the latency
 between input
 events sent from the top-level Mir server to a client. All in
 milliseconds...

 Desktop (3.12.0-7-generic)
 Direct 0.8ms
 Nested 1.3ms

 Desktop (3.11.0-11-lowlatency)
 Direct 1.0ms
 Nested 1.7ms

 Nexus4 (3.4.0-3-mako)
 Direct 0.9ms
 Nested 1.5ms with high variance; frequent spikes to 73ms.
 Sometimes 700ms.


 Do we have any way to get insight into the spikes? Something
 strange is
 obviously happening when the variance is ~3 orders of magnitude.




 --
 Mir-devel mailing list
 Mir-devel@lists.ubuntu.com <mailto:Mir-devel@lists.ubuntu.com>

 Modify settings or unsubscribe at:
 https://lists.ubuntu.com/__mailman/listinfo/mir-devel
 <https://lists.ubuntu.com/mailman/listinfo/mir-devel>




--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/mir-devel


--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/mir-devel

Re: Input latency

[Daniel van Vugt]

Nexus10 (3.4.0-4-manta)
Direct 1.0ms with sporadic spikes to 74ms, sometimes 400ms
Nested 1.2ms with sporadic spikes to 100ms, sometimes 1000ms

I'm not convinced the problem is specifically Android. It could just be 
a common issue visible on the slowest hardware.


On the Nexus10, just running a single server and client (egltriangle) 
occupies almost 100% of one of the cores. So stressing the CPU doesn't 
leave much time for being responsive.



On 13/12/13 17:31, Daniel van Vugt wrote:

Here are some fun numbers I've collected about the latency between input
events sent from the top-level Mir server to a client. All in
milliseconds...

Desktop (3.12.0-7-generic)
Direct 0.8ms
Nested 1.3ms

Desktop (3.11.0-11-lowlatency)
Direct 1.0ms
Nested 1.7ms

Nexus4 (3.4.0-3-mako)
Direct 0.9ms
Nested 1.5ms with high variance; frequent spikes to 73ms. Sometimes 700ms.

The above numbers are for motion events. Key events appear to be twice
as fast (half the latency). This suggests we could yet optimize the
processing of motion events to perform better like key events do.

In summary, we're looking pretty good. Only the Nexus has potential
usability issues, and even then, only with nested servers.

- Daniel



--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/mir-devel

Re: Input latency

[Daniel van Vugt]

I observed egltriangle on the N10 (2 cores):
server 30%
client 20%

I misinterpreted that as 100% of one core, which is true for some tools, 
and "top" on some Unixes. But I just realized top on Linux goes to 100% 
multiple times (for each core).


So my assessment should have been 50% of one core, sorry.


On 17/12/13 07:30, Kevin Gunn wrote:

hey Daniel - thanks for the numbers, however the last statement of
having a core 100% loaded with mir_demo_client_egltriangle doesn't seem
reasonable.
running on N4 shows ~20% load on cpu at most.

br,kg


On Mon, Dec 16, 2013 at 2:40 AM, Daniel van Vugt
mailto:daniel.van.v...@canonical.com>>
wrote:

Nexus10 (3.4.0-4-manta)
Direct 1.0ms with sporadic spikes to 74ms, sometimes 400ms
Nested 1.2ms with sporadic spikes to 100ms, sometimes 1000ms

I'm not convinced the problem is specifically Android. It could just
be a common issue visible on the slowest hardware.

On the Nexus10, just running a single server and client
(egltriangle) occupies almost 100% of one of the cores. So stressing
the CPU doesn't leave much time for being responsive.



    On 13/12/13 17:31, Daniel van Vugt wrote:

Here are some fun numbers I've collected about the latency
between input
events sent from the top-level Mir server to a client. All in
milliseconds...

Desktop (3.12.0-7-generic)
Direct 0.8ms
Nested 1.3ms

Desktop (3.11.0-11-lowlatency)
Direct 1.0ms
Nested 1.7ms

Nexus4 (3.4.0-3-mako)
Direct 0.9ms
Nested 1.5ms with high variance; frequent spikes to 73ms.
Sometimes 700ms.

The above numbers are for motion events. Key events appear to be
twice
as fast (half the latency). This suggests we could yet optimize the
processing of motion events to perform better like key events do.

In summary, we're looking pretty good. Only the Nexus has potential
usability issues, and even then, only with nested servers.

- Daniel


--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com <mailto:Mir-devel@lists.ubuntu.com>
Modify settings or unsubscribe at:
https://lists.ubuntu.com/__mailman/listinfo/mir-devel
<https://lists.ubuntu.com/mailman/listinfo/mir-devel>




--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/mir-devel

Re: CI failures

[Daniel van Vugt]

Actually, they're not fixed. Which is why very little has landed this 
past week...


https://bugs.launchpad.net/mir/+bugs?field.tag=blockingci

One is a minor scripting issue due to changes in libhybris. The other is 
an annoyingly intermittent (Galaxy)Nexus(/4) test failure.


There may be other issues still blocking CI. If you find them, please 
use tag "blockingci".


- Daniel


On 12/12/13 09:40, Daniel van Vugt wrote:

Of course I was not suggesting disabling tests. Just to disable broken
test _machines_.

It appears they're all fixed today, so problem solved :)


On 12/12/13 00:01, Chris Gagnon wrote:

The demos say there is an error because of output on stderr, but it
won't fail the build because of it. Currently it will block the build
when an integration test or acceptance test fails.

These tests pass when  I ran CI on the current trunk of the
mir-development branch[1]  and the tests passed, the test also passed
before enabling CI more than one time. It looks like the new code is
causing these tests to fail.

We cannot disable tests when they start to fail.

[1] http://s-jenkins.ubuntu-ci:8080/job/mir-mediumtests-trusty-touch/8/

On Wed, Dec 11, 2013 at 4:04 AM, Daniel van Vugt
mailto:daniel.van.v...@canonical.com>>
wrote:

It seems CI has become a little over-ambitious recently and no
branch can pass all the runs. Can we disable the broken ones?


On 11/12/13 17:01, PS Jenkins bot wrote:

Review: Needs Fixing continuous-integration

FAILED: Continuous integration, rev:1282

http://jenkins.qa.ubuntu.com/__job/mir-team-mir-development-__branch-ci/514/


<http://jenkins.qa.ubuntu.com/job/mir-team-mir-development-branch-ci/514/>

Executed test runs:
  FAILURE:

http://jenkins.qa.ubuntu.com/__job/mir-android-trusty-i386-__build/401/console


<http://jenkins.qa.ubuntu.com/job/mir-android-trusty-i386-build/401/console>

  SUCCESS:

http://jenkins.qa.ubuntu.com/__job/mir-clang-trusty-amd64-__build/397

<http://jenkins.qa.ubuntu.com/job/mir-clang-trusty-amd64-build/397>
  FAILURE:

http://jenkins.qa.ubuntu.com/__job/mir-mediumtests-trusty-__touch/6/console


<http://jenkins.qa.ubuntu.com/job/mir-mediumtests-trusty-touch/6/console>
  SUCCESS:

http://jenkins.qa.ubuntu.com/__job/mir-team-mir-development-__branch-trusty-amd64-ci/240


<http://jenkins.qa.ubuntu.com/job/mir-team-mir-development-branch-trusty-amd64-ci/240>

  deb:

http://jenkins.qa.ubuntu.com/__job/mir-team-mir-development-__branch-trusty-amd64-ci/240/__artifact/work/output/*zip*/__output.zip


<http://jenkins.qa.ubuntu.com/job/mir-team-mir-development-branch-trusty-amd64-ci/240/artifact/work/output/*zip*/output.zip>

  SUCCESS:

http://jenkins.qa.ubuntu.com/__job/mir-team-mir-development-__branch-trusty-armhf-ci/243


<http://jenkins.qa.ubuntu.com/job/mir-team-mir-development-branch-trusty-armhf-ci/243>

  deb:

http://jenkins.qa.ubuntu.com/__job/mir-team-mir-development-__branch-trusty-armhf-ci/243/__artifact/work/output/*zip*/__output.zip


<http://jenkins.qa.ubuntu.com/job/mir-team-mir-development-branch-trusty-armhf-ci/243/artifact/work/output/*zip*/output.zip>

  SUCCESS:

http://jenkins.qa.ubuntu.com/__job/mir-mediumtests-builder-__trusty-armhf/6


<http://jenkins.qa.ubuntu.com/job/mir-mediumtests-builder-trusty-armhf/6>
  deb:

http://jenkins.qa.ubuntu.com/__job/mir-mediumtests-builder-__trusty-armhf/6/artifact/work/__output/*zip*/output.zip


<http://jenkins.qa.ubuntu.com/job/mir-mediumtests-builder-trusty-armhf/6/artifact/work/output/*zip*/output.zip>

  FAILURE:

http://jenkins.qa.ubuntu.com/__job/mir-mediumtests-runner-__mako/45/console


<http://jenkins.qa.ubuntu.com/job/mir-mediumtests-runner-mako/45/console>
  SUCCESS:
http://s-jenkins.ubuntu-ci:__8080/job/touch-flash-device/__2218
<http://s-jenkins.ubuntu-ci:8080/job/touch-flash-device/2218>

Click here to trigger a rebuild:

http://s-jenkins.ubuntu-ci:__8080/job/mir-team-mir-__development-branch-ci/514/__rebuild


<http://s-jenkins.ubuntu-ci:8080/job/mir-team-mir-development-branch-ci/514/rebuild>







--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/mir-devel

Re: CI failures

[Daniel van Vugt]

Chris,

We still have some weird CI failures that are not the fault of Mir:
https://jenkins.qa.ubuntu.com/job/mir-android-trusty-i386-build/472/consoleFull
https://jenkins.qa.ubuntu.com/job/mir-mediumtests-runner-mako/112/console

and perhaps:
https://jenkins.qa.ubuntu.com/job/mir-mediumtests-trusty-touch/78/console
(why can't I see any useful log there?)

- Daniel


On 17/12/13 15:49, Daniel van Vugt wrote:

Actually, they're not fixed. Which is why very little has landed this
past week...

https://bugs.launchpad.net/mir/+bugs?field.tag=blockingci

One is a minor scripting issue due to changes in libhybris. The other is
an annoyingly intermittent (Galaxy)Nexus(/4) test failure.

There may be other issues still blocking CI. If you find them, please
use tag "blockingci".

- Daniel


On 12/12/13 09:40, Daniel van Vugt wrote:

Of course I was not suggesting disabling tests. Just to disable broken
test _machines_.

It appears they're all fixed today, so problem solved :)


On 12/12/13 00:01, Chris Gagnon wrote:

The demos say there is an error because of output on stderr, but it
won't fail the build because of it. Currently it will block the build
when an integration test or acceptance test fails.

These tests pass when  I ran CI on the current trunk of the
mir-development branch[1]  and the tests passed, the test also passed
before enabling CI more than one time. It looks like the new code is
causing these tests to fail.

We cannot disable tests when they start to fail.

[1] http://s-jenkins.ubuntu-ci:8080/job/mir-mediumtests-trusty-touch/8/

On Wed, Dec 11, 2013 at 4:04 AM, Daniel van Vugt
mailto:daniel.van.v...@canonical.com>>
wrote:

It seems CI has become a little over-ambitious recently and no
branch can pass all the runs. Can we disable the broken ones?


On 11/12/13 17:01, PS Jenkins bot wrote:

Review: Needs Fixing continuous-integration

FAILED: Continuous integration, rev:1282

http://jenkins.qa.ubuntu.com/__job/mir-team-mir-development-__branch-ci/514/



<http://jenkins.qa.ubuntu.com/job/mir-team-mir-development-branch-ci/514/>


Executed test runs:
  FAILURE:

http://jenkins.qa.ubuntu.com/__job/mir-android-trusty-i386-__build/401/console



<http://jenkins.qa.ubuntu.com/job/mir-android-trusty-i386-build/401/console>


  SUCCESS:

http://jenkins.qa.ubuntu.com/__job/mir-clang-trusty-amd64-__build/397

<http://jenkins.qa.ubuntu.com/job/mir-clang-trusty-amd64-build/397>
  FAILURE:

http://jenkins.qa.ubuntu.com/__job/mir-mediumtests-trusty-__touch/6/console



<http://jenkins.qa.ubuntu.com/job/mir-mediumtests-trusty-touch/6/console>

  SUCCESS:

http://jenkins.qa.ubuntu.com/__job/mir-team-mir-development-__branch-trusty-amd64-ci/240



<http://jenkins.qa.ubuntu.com/job/mir-team-mir-development-branch-trusty-amd64-ci/240>


  deb:

http://jenkins.qa.ubuntu.com/__job/mir-team-mir-development-__branch-trusty-amd64-ci/240/__artifact/work/output/*zip*/__output.zip



<http://jenkins.qa.ubuntu.com/job/mir-team-mir-development-branch-trusty-amd64-ci/240/artifact/work/output/*zip*/output.zip>


  SUCCESS:

http://jenkins.qa.ubuntu.com/__job/mir-team-mir-development-__branch-trusty-armhf-ci/243



<http://jenkins.qa.ubuntu.com/job/mir-team-mir-development-branch-trusty-armhf-ci/243>


  deb:

http://jenkins.qa.ubuntu.com/__job/mir-team-mir-development-__branch-trusty-armhf-ci/243/__artifact/work/output/*zip*/__output.zip



<http://jenkins.qa.ubuntu.com/job/mir-team-mir-development-branch-trusty-armhf-ci/243/artifact/work/output/*zip*/output.zip>


  SUCCESS:

http://jenkins.qa.ubuntu.com/__job/mir-mediumtests-builder-__trusty-armhf/6



<http://jenkins.qa.ubuntu.com/job/mir-mediumtests-builder-trusty-armhf/6>

  deb:

http://jenkins.qa.ubuntu.com/__job/mir-mediumtests-builder-__trusty-armhf/6/artifact/work/__output/*zip*/output.zip



<http://jenkins.qa.ubuntu.com/job/mir-mediumtests-builder-trusty-armhf/6/artifact/work/output/*zip*/output.zip>


  FAILURE:

http://jenkins.qa.ubuntu.com/__job/mir-mediumtests-runner-__mako/45/console



<http://jenkins.qa.ubuntu.com/job/mir-mediumtests-runner-mako/45/console>

  SUCCESS:
http://s-jenkins.ubuntu-ci:__8080/job/touch-flash-device/__2218
<http://s-jenkins.ubuntu-ci:8080/job/touch-flash-device/2218>

Click here to trigger a rebuild:

http://s-jenkins.ubuntu-ci:__8080/job/mir-team-mir-__development-branch-ci/514/__rebuild



<http://s-jenkins.ubuntu-ci:8080/job/mir-team-mir-development-branch-ci/514/rebuild>










--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/mir-devel

Mir: What's On?

[Daniel van Vugt]

Just a reminder, you can always see much of the current development 
activity on the upcoming milestone page:

   https://launchpad.net/mir/+milestone/0.1.3

That excludes feature development attached to blueprints, unfortunately. 
But only because the real Mir blueprints are under the Ubuntu project 
where they can't be linked to Mir milestones :(


- Daniel

--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/mir-devel

Nested servers frame rate

[Daniel van Vugt]

At first glance, comparing frame rates between direct (single) and 
nested (double) server configurations reveals nothing unexpected...


Full screen
Direct (bypass) 2600
Direct (bypass off) 2400
Nested (bypass) 2450
Nested (bypass off) 2330

But for surfaces which can't be bypassed, something strange happens; 
nesting is faster!


Windowed
Nested 4890
Direct 4400

My best theory right now is that we're crippling Mir in the single 
server case due to:

https://bugs.launchpad.net/mir/+bug/1253868
and nesting provides a workaround for that problem by supplying extra 
levels of buffering.


Can anyone else think why nested would sometimes be faster than not nested?

- Daniel

--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/mir-devel

Re: Nested servers frame rate

[Daniel van Vugt]

The issue is in your response: "almost immediately" :)

At present, "almost immediately" means waiting for a round trip. Whereas 
we can do better than that in theory, by pushing free buffers to the 
client as soon as they're available.



On 18/12/13 16:58, Thomas Voß wrote:

On Wed, Dec 18, 2013 at 9:43 AM, Daniel van Vugt
 wrote:

At first glance, comparing frame rates between direct (single) and nested
(double) server configurations reveals nothing unexpected...

Full screen
Direct (bypass) 2600
Direct (bypass off) 2400
Nested (bypass) 2450
Nested (bypass off) 2330

But for surfaces which can't be bypassed, something strange happens; nesting
is faster!

Windowed
Nested 4890
Direct 4400

My best theory right now is that we're crippling Mir in the single server
case due to:
https://bugs.launchpad.net/mir/+bug/1253868
and nesting provides a workaround for that problem by supplying extra levels
of buffering.


Not sure I'm following your reasoning here: The bug states exactly the
opposite, i.e., additional buffering wouldn't help.
In addition: I do not see how a steady-state update scheme on the
client-side is a problem here. If there are more than two buffers
available per surface, the client almost immediately receives a new
buffer when it calls next_buffer. Sure, there is always only one
buffer in flight, but I cannot see why this would lead to the numbers
you are reporting here.

Cheers,

   Thomas



Can anyone else think why nested would sometimes be faster than not nested?

- Daniel

--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/mir-devel


--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/mir-devel

Re: Nested servers frame rate

[Daniel van Vugt]

I'll work on getting numbers. In the mean time, any other theories on 
why nesting is sometimes faster?


I think the first logical step is to assume nesting shouldn't be faster. 
But instead non-nested is being throttled somehow, like already described.



On 18/12/13 17:04, Thomas Voß wrote:

On Wed, Dec 18, 2013 at 10:01 AM, Daniel van Vugt
 wrote:

The issue is in your response: "almost immediately" :)

At present, "almost immediately" means waiting for a round trip. Whereas we
can do better than that in theory, by pushing free buffers to the client as
soon as they're available.



Fair, but I would like to see numbers on the roundtrip penalty you are
suspecting here, first :)

Cheers,

   Thomas




On 18/12/13 16:58, Thomas Voß wrote:


On Wed, Dec 18, 2013 at 9:43 AM, Daniel van Vugt
 wrote:


At first glance, comparing frame rates between direct (single) and nested
(double) server configurations reveals nothing unexpected...

Full screen
Direct (bypass) 2600
Direct (bypass off) 2400
Nested (bypass) 2450
Nested (bypass off) 2330

But for surfaces which can't be bypassed, something strange happens;
nesting
is faster!

Windowed
Nested 4890
Direct 4400

My best theory right now is that we're crippling Mir in the single server
case due to:
https://bugs.launchpad.net/mir/+bug/1253868
and nesting provides a workaround for that problem by supplying extra
levels
of buffering.



Not sure I'm following your reasoning here: The bug states exactly the
opposite, i.e., additional buffering wouldn't help.
In addition: I do not see how a steady-state update scheme on the
client-side is a problem here. If there are more than two buffers
available per surface, the client almost immediately receives a new
buffer when it calls next_buffer. Sure, there is always only one
buffer in flight, but I cannot see why this would lead to the numbers
you are reporting here.

Cheers,

Thomas



Can anyone else think why nested would sometimes be faster than not
nested?

- Daniel

--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/mir-devel


--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/mir-devel

Re: XMir now on vmwgfx

[Daniel van Vugt]

Thomas,

Excellent work, thanks.

The two people best placed to answer your questions are now on vacation, 
but I shall try;


1) There is no explicit message that DRM mastership has been dropped. 
Mir will just block in the page flip while the (Mir) server is no longer 
consuming buffers:

https://github.com/RAOF/xserver/blob/vladmir-upstreaming/hw/xfree86/xmir/xmir-window.c#L149
But that happens after the drop of mastership so there's still a 
potential race between the server dropping it, and the DDX rendering. 
Worst case is that the DDX could render 2 frames before filling the 
queue and then no more will be requested until the server resumes. Is it 
more than 2 extraneous frames you're seeing? Or is two still a problem 
for the DDX? Do we need something like this?...

   mir_drm_lock();
   /* DDX code in which mastership won't be dropped */
   mir_drm_unlock();

2) The pixel format of the XMir surface appears to be fixed at 
mir_pixel_format_xrgb_ right now. See:

https://github.com/RAOF/xserver/blob/vladmir-upstreaming/hw/xfree86/xmir/xmir-output.c#L311

3) I'm not sure. But the region comes from xmir_window_get_dirty(), here:
https://github.com/RAOF/xserver/blob/vladmir-upstreaming/hw/xfree86/xmir/xmir-window.c#L169

- Daniel


On 19/12/13 21:08, Thomas Hellstrom wrote:

Hi!

I just pushed a branch "hosted" to xf86-video-vmware that enables XMir
(and also XWayland). It will probably not be part of next release which
might happen very soon, but probably with the next release. I'm not sure
what X support on Mir will look like in the end, but all XMir - specific
code is confined to a single file, so it should be easy to change if needed.

Performance seems OK, given that the vmwgfx driver fakes pageflipping
with multiple fullscreen copies. This also means that performance of
XMir compared to bare Xorg might look a bit bad.

A couple of outstanding issues:

1) When Mir VT switches, I guess it drops DRM master. Still, from what I
can tell, the XMir driver is not informed, and may attempt to continue
to render using the drm file-descriptor. Is there a way to inform the
driver about this?
2) I'd like to have a way to get the pixel format of the XMir copy
buffer. I guess it's whatever GBM gives Mir for a given depth, but is it
safe
to assume that the depth of the XMir copy buffer is identical to the
depth of the source window drawable?
3) Is the region given as the second argument to xmir_window_proc
relative to the source window drawable or relative to the underlying pixmap?

Thanks,
Thomas Hellstrom



--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/mir-devel

[ANNOUNCE] Mir 0.1.3

[Daniel van Vugt]

Mir 0.1.3 is now out, for your pixel putting pleasure. Details are on 
the milestone page:


https://launchpad.net/mir/+milestone/0.1.3

--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/mir-devel

[ANNOUNCE] Mir 0.1.4

[Daniel van Vugt]

Another point release, but a significant one...

https://launchpad.net/mir/+milestone/0.1.4

--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/mir-devel

Re: Mir in a virtual machine

[Daniel van Vugt]

Rian,

VMware (Thomas Hellstrom) has implemented Mir support. Apparently you 
need kernel 3.13 for the requisite graphics driver DRM changes. And you 
need a newish Mesa.


I don't think anyone has documented the particulars yet. But we 
certainly should at least by the time regular Ubuntu (trusty?) has all 
the prerequisites in place.


- Daniel


On 22/01/14 05:08, Rian Quinn wrote:

Is it possible to get Mir up and running in a Virtual Machine. I have
both VMWare and VirtualBox. Currently, under VMWare, you get an error
about open_drm_device. Basically, I am working with Mir for some client
/ server development, and would like to do testing in a virtual machine
to start.

Thanks,
- Rian




--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/mir-devel

Re: Mir in a virtual machine

[Daniel van Vugt]

Q: Does Mir support multiple monitors? If so, do you have any examples 
or at least a starting point on how to set that up.

A: Yes... The API for affecting the multi-monitor config is
  mir_connection_create_display_config
  mir_connection_apply_display_config
  etc.. http://unity.ubuntu.com/mir/group__mir__toolkit.html
To enable basic multi-monitor testing you can:
  mir_demo_server_shell --display-config sidebyside
Mir's multi-monitor configuration is already used in detail by XMir. 
That's how you can configure displays from X under XMir.


Q: How does Mir handle surfaces with shapes cut out of them. For 
example, a smiley face where the background is shown through the eyes 
and mouth.
A: Create your surface with an alpha channel (e.g. 
mir_pixel_format_abgr_) and then any pixels with alpha==0 will be 
transparent. As an example of a free-form shape, you can run:

mir_demo_client_egltriangle -b 0.0

Q: Do clients need to have root access. For the fingerprint test, I 
could not get it to run without a sudo.
A: Yes and no. A client can run as the same user as the server, 
including non-root. This works perfectly for touch (Android) devices 
however desktop has the problem of requiring root to access input 
devices. You can run mir server and client on desktop as non-root but 
you won't be able to interact with it.



On 23/01/14 01:21, Rian Quinn wrote:

Daniel,

I was able to update my system, and my sources and was able to get Mir
up and running.

I am actually really impressed with the Mir source code. We were
considering writing a lot of this ourselves, but I think that Mir has
everything that we need already.

I do have a couple of questions.
- Does Mir support multiple monitors? If so, do you have any examples or
at least a starting point on how to set that up.
- How does Mir handle surfaces with shapes cut out of them. For example,
a smiley face where the background is shown through the eyes and mouth.
- Do clients need to have root access. For the fingerprint test, I could
not get it to run without a sudo.

Thanks,
- Rian

For others interested in how I got Mir up and running, here were my steps:

1:
Install the 3.13 linux kernel. Here is what I used for that:
http://linuxg.net/how-to-install-kernel-3-13-rc-7-on-ubuntu-linux-mint-pear-os-and-elementary-os/

2:
Install libDRM from the following PPA:
https://launchpad.net/~oibaf/+archive/graphics-drivers/

3:
run sudo apt-get build-dep mir

4:
Download and compile Mir form the following:
http://unity.ubuntu.com/mir/building_source_for_pc.html

5:
Download and compile Mir's version of Mesa and here are the compilation
steps:
http://www.mesa3d.org/install.html

I had to add --disable-dri3 to get it to compile, plus the
--with-egl-platform=mir,drm

Once I was done with that, I could get the examples to execute.







On Tue, Jan 21, 2014 at 8:44 PM, Daniel van Vugt
mailto:daniel.van.v...@canonical.com>>
wrote:

Rian,

VMware (Thomas Hellstrom) has implemented Mir support. Apparently
you need kernel 3.13 for the requisite graphics driver DRM changes.
And you need a newish Mesa.

I don't think anyone has documented the particulars yet. But we
certainly should at least by the time regular Ubuntu (trusty?) has
all the prerequisites in place.

- Daniel



On 22/01/14 05:08, Rian Quinn wrote:

Is it possible to get Mir up and running in a Virtual Machine. I
have
both VMWare and VirtualBox. Currently, under VMWare, you get an
error
about open_drm_device. Basically, I am working with Mir for some
client
/ server development, and would like to do testing in a virtual
machine
to start.

Thanks,
- Rian





--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/mir-devel

CI + touch images

[Daniel van Vugt]

It seems we've had a couple of occasions where code has landed that 
makes mir_*_tests fail on touch devices. And yet CI passes and the merge 
proposals land. Certainly CI is ensuring our tests pass on armhf for 
some configurations, but it seems not enough...


Can we get better coverage of real touch images/devices for CI?

- Daniel

--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/mir-devel

Re: CI + touch images

[Daniel van Vugt]

The recent issues are actually odd edge cases with reasonable 
explanations for slipping through CI:


https://bugs.launchpad.net/mir/+bug/1271434
CI runs tests on the build machine. Hence it has the required build deps 
installed. Until a couple of days ago we could also run tests on fresh 
touch images (which is an awesome feature I use all the time), but not 
any more.


https://bugs.launchpad.net/mir/+bug/1270685
Nexus 10 only. So CI would not have noticed.

- Daniel


On 23/01/14 22:26, Kevin Gunn wrote:

hey Daniel -
this is something I've been raising with the CI team in general.
They do have actual devices running the tests - so, is this a matter
intermittent failure of the tests? meaning we need to request repeat
runs of the tests ?

Or is your concern the actual models (galaxy vs n4 vs n7 etc) ?

br,kg


On Thu, Jan 23, 2014 at 1:56 AM, Daniel van Vugt
mailto:daniel.van.v...@canonical.com>>
wrote:

It seems we've had a couple of occasions where code has landed that
makes mir_*_tests fail on touch devices. And yet CI passes and the
merge proposals land. Certainly CI is ensuring our tests pass on
armhf for some configurations, but it seems not enough...

Can we get better coverage of real touch images/devices for CI?

- Daniel

--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com <mailto:Mir-devel@lists.ubuntu.com>
Modify settings or unsubscribe at:
https://lists.ubuntu.com/__mailman/listinfo/mir-devel
<https://lists.ubuntu.com/mailman/listinfo/mir-devel>




--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/mir-devel

Re: Mir in a virtual machine

[Daniel van Vugt]

Rian,

Both of the issues you describe /had/ simple solutions, documented under 
"Running Mir natively":

  http://unity.ubuntu.com/mir/using_mir_on_pc.html
  or: $SRC/doc/using_mir_on_pc.md

Though I just retested non-root clients with a root server, and it 
doesn't work as documented. So that's a bug, sorry;

  https://bugs.launchpad.net/mir/+bug/1272143

- Daniel


On 23/01/14 20:48, Rian Quinn wrote:

I would prefer to run the server as non-root, but if I attempt to do
that, it complains about not being able to open the DRM device. If I run
the fingerprint demo as non-root, and the server as root, the client
complains about not being able to make a connection to the server. And
some of the clients I cannot get to connect at all regardless of root or
not (like all of the EGL examples).

I am a little confused though. If Mir is to replace X someday, clients
will have to be able to be run as non-root. The ideal solution is where
both the server/compositor, and clients are running as non-root which is
one of the things that X doesn’t do today. Are there plans to fixing the
privilege issue (everything needing root), or am I not understanding
something.

Thanks
- Rian


On Jan 22, 2014, at 9:35 PM, Daniel van Vugt
 wrote:

Q: Does Mir support multiple monitors? If so, do you have any examples
or at least a starting point on how to set that up.
A: Yes... The API for affecting the multi-monitor config is
mir_connection_create_display_config
mir_connection_apply_display_config
etc.. http://unity.ubuntu.com/mir/group__mir__toolkit.html
To enable basic multi-monitor testing you can:
mir_demo_server_shell --display-config sidebyside
Mir's multi-monitor configuration is already used in detail by XMir.
That's how you can configure displays from X under XMir.

Q: How does Mir handle surfaces with shapes cut out of them. For
example, a smiley face where the background is shown through the eyes
and mouth.
A: Create your surface with an alpha channel (e.g.
mir_pixel_format_abgr_) and then any pixels with alpha==0 will be
transparent. As an example of a free-form shape, you can run:
mir_demo_client_egltriangle -b 0.0

Q: Do clients need to have root access. For the fingerprint test, I
could not get it to run without a sudo.
A: Yes and no. A client can run as the same user as the server,
including non-root. This works perfectly for touch (Android) devices
however desktop has the problem of requiring root to access input
devices. You can run mir server and client on desktop as non-root but
you won't be able to interact with it.


On 23/01/14 01:21, Rian Quinn wrote:

Daniel,

I was able to update my system, and my sources and was able to get Mir
up and running.

I am actually really impressed with the Mir source code. We were
considering writing a lot of this ourselves, but I think that Mir has
everything that we need already.

I do have a couple of questions.
- Does Mir support multiple monitors? If so, do you have any
examples or
at least a starting point on how to set that up.
- How does Mir handle surfaces with shapes cut out of them. For
example,
a smiley face where the background is shown through the eyes and
mouth.
- Do clients need to have root access. For the fingerprint test, I
could
not get it to run without a sudo.

Thanks,
- Rian

For others interested in how I got Mir up and running, here were
my steps:

1:
Install the 3.13 linux kernel. Here is what I used for that:

http://linuxg.net/how-to-install-kernel-3-13-rc-7-on-ubuntu-linux-mint-pear-os-and-elementary-os/


2:
Install libDRM from the following PPA:
https://launchpad.net/~oibaf/+archive/graphics-drivers/

3:
run sudo apt-get build-dep mir

4:
Download and compile Mir form the following:
http://unity.ubuntu.com/mir/building_source_for_pc.html

5:
Download and compile Mir's version of Mesa and here are the
compilation
steps:
http://www.mesa3d.org/install.html

I had to add --disable-dri3 to get it to compile, plus the
--with-egl-platform=mir,drm

Once I was done with that, I could get the examples to execute.







    On Tue, Jan 21, 2014 at 8:44 PM, Daniel van Vugt
mailto:daniel.van.v...@canonical.com>>
wrote:

Rian,

VMware (Thomas Hellstrom) has implemented Mir support. Apparently
you need kernel 3.13 for the requisite graphics driver DRM changes.
And you need a newish Mesa.

I don't think anyone has documented the particulars yet. But we
certainly should at least by the time regular Ubuntu (trusty?) has
all the prerequisites in place.

- Daniel



On 22/01/14 05:08, Rian Quinn wrote:

Is it possible to get Mir up and running in a Virtual Machine. I
have
both VMWare and VirtualBox. Currently, under VMWare, you get an
error
about open_drm_device. Basically, I am working wi

Re: Mir in a virtual machine

[Daniel van Vugt]

Rian,

The distinction between "software" and "hardware" buffers in Mir is 
confusing, I know, due to the vague names. What it actually means is:


mir_buffer_usage_software: Client draws individual pixels and the server 
composites this (in hardware still). Presently glTexImage2D, I know. :/


mir_buffer_usage_hardware: Client never has access to address individual 
pixels and must use OpenGL.


So if you want to draw the pixels yourself then you must use 
mir_buffer_usage_software. If you feel glTexImage2D is too slow at that, 
then it's an enhancement for Mir later. But not something that's visible 
to the client.


To see the various implementations just search for the "bind_to_texture" 
method:


grep -r '::bind_to_texture' *

- Daniel


On 27/01/14 04:17, Rian Quinn wrote:

I went back and re-read the gbm code, and noticed that it only creates
the dumb buffer if you set the GBM_BO_USE_WRITE flag, which means that
you can use the gbm_bo_write command which takes a char*. So that makes
sense to me now. What I guess I was looking for, was something more like
DirectDraw, where a client could get access to device memory, and render
directly into for 2D.

In my case I’m not really interested in 3D, but instead my clients are
rendering using the VGA spec, 2D pixel data. I’m trying to figure out
the best way to reduce the number of memcpys. At the moment, I am going
to assume that I need to use a software buffer for the clients, and the
server will copy the pixel data to the scanout buffer.

That being the case, what is the best method for transferring this ARGB
pixel data from shared RAM, onto a scanout buffer? From what I
understand, glTexSubImage2D does a memcpy via the CPU. Ideally, I would
prefer this transfer to be done via DMA and not the CPU. Keep in mind
that each client is rendering as a VGA device, so I don’t really have
control of “when” the client decides to modify it’s char*.

After reading a lot of the compositor code in Mir, I so far have not
been able to locate how this is done for a software buffer vs. a
hardware buffer.

Also, is there an example of how someone would use Mir to composite
multiple clients. From what I can tell, all of the server examples just
call run_mir, and don’t really do anything.

Thanks
- Rian


On Jan 26, 2014, at 6:10 AM, Alexandros Frantzis
 wrote:

On Sat, Jan 25, 2014 at 02:04:29PM -0800, Rian Quinn wrote:

At the moment I am trying to better understand how buffers are used
and shared in Mir. I have spent the past couple of days doing nothing
but reading the Mir source code, the DRM source code, and portions of
the Mesa source code. Here is what I think I have learned so far,
which will lead me to a question:


- The server creates the buffers. It can create either a hardware
buffer, which is a gbm allocated “dumb” buffer, or a software buffer,
which is nothing more than shared memory (in RAM).


Using the mir_buffer_usage_hardware flag leads to the creation of a
normal gbm buffer, i.e., one suited for direct usage by the GPU. This is
*not* a gbm "dumb" buffer.

You are correct that using mir_buffer_usage_software creates a shared
memory (RAM) buffer.

- When a hardware buffer is created, it uses DRM prime
(drmPrimeHandleToFD) to create an FD for the “dumb" buffer.


Correct, but as noted above, it's not a gbm "dumb" buffer, but a normal
gbm buffer.

- The server then provides the client with a “ClientBuffer” which is
an abstraction of the hardware / software buffer containing the
information about the buffer (like format, stride, etc…) and its FD.


- To draw into this buffer, you need to
call mir_surface_get_graphics_region which through some indirection,
mmaps the buffer to a vaddr that can be written into.


Not correct for hardware buffers, see below for more. This only works
for software buffers, in which case the fd passed to the client is a
shared memory fd which can be mapped. In the case of hardware buffers
it's a "prime" fd which in general doesn't support sensible mapping of
that kind.

If you look at the basic.c demo, it creates a hardware buffer, and if
you look at the fingerpaint.c demo, it creates a software buffer. If I
modify the basic.c demo to call mir_surface_get_graphics_region, it
fails on VMWare, saying that it could not mmap the buffer. It works
fine if I change the basic.c to use a software buffer.

Is this an issue with VMWare? Or am I fundamentally not understanding
something about how hardware buffer’s are used? If I am… why would a
client use hardware buffers if it cannot map the buffer to use it?


In general, buffers created for direct GPU usage cannot be reasonably
mmap-ed and their pixels accessed directly. Even if the mapping
operation itself is supported by the driver, the contents of the mapped
area are usually not laid out in memory in a linear fashion (i.e. they
have some sort of tiling), and therefore not useful for pixel
manip

Re: Mir in a virtual machine

[Daniel van Vugt]

Incidentally, Mir had the ability to bypass software buffers until 
recently (before the SHM work). Bypass means no compositing required, no 
texture upload, just dump it (fullscreen surfaces) to the display.


However even when we could, I disabled bypass of software buffers 
because it was apparently always slower than compositing. I guess the 
bus doesn't like you poking pixels individually into VRAM. It seems to 
prefer a single copy of the whole buffer, for performance.


That all said, there are other ways to avoid glTexImage2D uploads of 
software buffers. We just haven't implemented them yet.



On 28/01/14 09:35, Daniel van Vugt wrote:

Rian,

The distinction between "software" and "hardware" buffers in Mir is
confusing, I know, due to the vague names. What it actually means is:

mir_buffer_usage_software: Client draws individual pixels and the server
composites this (in hardware still). Presently glTexImage2D, I know. :/

mir_buffer_usage_hardware: Client never has access to address individual
pixels and must use OpenGL.

So if you want to draw the pixels yourself then you must use
mir_buffer_usage_software. If you feel glTexImage2D is too slow at that,
then it's an enhancement for Mir later. But not something that's visible
to the client.

To see the various implementations just search for the "bind_to_texture"
method:

grep -r '::bind_to_texture' *

- Daniel


On 27/01/14 04:17, Rian Quinn wrote:

I went back and re-read the gbm code, and noticed that it only creates
the dumb buffer if you set the GBM_BO_USE_WRITE flag, which means that
you can use the gbm_bo_write command which takes a char*. So that makes
sense to me now. What I guess I was looking for, was something more like
DirectDraw, where a client could get access to device memory, and render
directly into for 2D.

In my case I’m not really interested in 3D, but instead my clients are
rendering using the VGA spec, 2D pixel data. I’m trying to figure out
the best way to reduce the number of memcpys. At the moment, I am going
to assume that I need to use a software buffer for the clients, and the
server will copy the pixel data to the scanout buffer.

That being the case, what is the best method for transferring this ARGB
pixel data from shared RAM, onto a scanout buffer? From what I
understand, glTexSubImage2D does a memcpy via the CPU. Ideally, I would
prefer this transfer to be done via DMA and not the CPU. Keep in mind
that each client is rendering as a VGA device, so I don’t really have
control of “when” the client decides to modify it’s char*.

After reading a lot of the compositor code in Mir, I so far have not
been able to locate how this is done for a software buffer vs. a
hardware buffer.

Also, is there an example of how someone would use Mir to composite
multiple clients. From what I can tell, all of the server examples just
call run_mir, and don’t really do anything.

Thanks
- Rian


On Jan 26, 2014, at 6:10 AM, Alexandros Frantzis
 wrote:

On Sat, Jan 25, 2014 at 02:04:29PM -0800, Rian Quinn wrote:

At the moment I am trying to better understand how buffers are used
and shared in Mir. I have spent the past couple of days doing
nothing
but reading the Mir source code, the DRM source code, and
portions of
the Mesa source code. Here is what I think I have learned so far,
which will lead me to a question:


- The server creates the buffers. It can create either a hardware
buffer, which is a gbm allocated “dumb” buffer, or a software
buffer,
which is nothing more than shared memory (in RAM).


Using the mir_buffer_usage_hardware flag leads to the creation of a
normal gbm buffer, i.e., one suited for direct usage by the GPU. This is
*not* a gbm "dumb" buffer.

You are correct that using mir_buffer_usage_software creates a shared
memory (RAM) buffer.

- When a hardware buffer is created, it uses DRM prime
(drmPrimeHandleToFD) to create an FD for the “dumb" buffer.


Correct, but as noted above, it's not a gbm "dumb" buffer, but a normal
gbm buffer.

- The server then provides the client with a “ClientBuffer” which is
an abstraction of the hardware / software buffer containing the
information about the buffer (like format, stride, etc…) and its FD.


- To draw into this buffer, you need to
call mir_surface_get_graphics_region which through some indirection,
mmaps the buffer to a vaddr that can be written into.


Not correct for hardware buffers, see below for more. This only works
for software buffers, in which case the fd passed to the client is a
shared memory fd which can be mapped. In the case of hardware buffers
it's a "prime" fd which in general doesn't support sensible mapping of
that kind.

If you look at the basic.c demo, it creates a hardware buffer,
and if
you look at the fingerpaint.c demo, it creates a software buffer.
If I
modify the b

Re: Mir in a virtual machine

[Daniel van Vugt]

Before anyone corrects me... I know mir_buffer_usage_hardware is 
intentionally vague and not called mir_buffer_usage_opengl for a reason. 
The reason is that mir_buffer_usage_hardware is not limited to OpenGL. 
In XMir for example we use mir_buffer_usage_hardware and the various DDX 
drivers implement their own acceleration.



On 28/01/14 09:35, Daniel van Vugt wrote:

Rian,

The distinction between "software" and "hardware" buffers in Mir is
confusing, I know, due to the vague names. What it actually means is:

mir_buffer_usage_software: Client draws individual pixels and the server
composites this (in hardware still). Presently glTexImage2D, I know. :/

mir_buffer_usage_hardware: Client never has access to address individual
pixels and must use OpenGL.

So if you want to draw the pixels yourself then you must use
mir_buffer_usage_software. If you feel glTexImage2D is too slow at that,
then it's an enhancement for Mir later. But not something that's visible
to the client.

To see the various implementations just search for the "bind_to_texture"
method:

grep -r '::bind_to_texture' *

- Daniel


On 27/01/14 04:17, Rian Quinn wrote:

I went back and re-read the gbm code, and noticed that it only creates
the dumb buffer if you set the GBM_BO_USE_WRITE flag, which means that
you can use the gbm_bo_write command which takes a char*. So that makes
sense to me now. What I guess I was looking for, was something more like
DirectDraw, where a client could get access to device memory, and render
directly into for 2D.

In my case I’m not really interested in 3D, but instead my clients are
rendering using the VGA spec, 2D pixel data. I’m trying to figure out
the best way to reduce the number of memcpys. At the moment, I am going
to assume that I need to use a software buffer for the clients, and the
server will copy the pixel data to the scanout buffer.

That being the case, what is the best method for transferring this ARGB
pixel data from shared RAM, onto a scanout buffer? From what I
understand, glTexSubImage2D does a memcpy via the CPU. Ideally, I would
prefer this transfer to be done via DMA and not the CPU. Keep in mind
that each client is rendering as a VGA device, so I don’t really have
control of “when” the client decides to modify it’s char*.

After reading a lot of the compositor code in Mir, I so far have not
been able to locate how this is done for a software buffer vs. a
hardware buffer.

Also, is there an example of how someone would use Mir to composite
multiple clients. From what I can tell, all of the server examples just
call run_mir, and don’t really do anything.

Thanks
- Rian


On Jan 26, 2014, at 6:10 AM, Alexandros Frantzis
 wrote:

On Sat, Jan 25, 2014 at 02:04:29PM -0800, Rian Quinn wrote:

At the moment I am trying to better understand how buffers are used
and shared in Mir. I have spent the past couple of days doing
nothing
but reading the Mir source code, the DRM source code, and
portions of
the Mesa source code. Here is what I think I have learned so far,
which will lead me to a question:


- The server creates the buffers. It can create either a hardware
buffer, which is a gbm allocated “dumb” buffer, or a software
buffer,
which is nothing more than shared memory (in RAM).


Using the mir_buffer_usage_hardware flag leads to the creation of a
normal gbm buffer, i.e., one suited for direct usage by the GPU. This is
*not* a gbm "dumb" buffer.

You are correct that using mir_buffer_usage_software creates a shared
memory (RAM) buffer.

- When a hardware buffer is created, it uses DRM prime
(drmPrimeHandleToFD) to create an FD for the “dumb" buffer.


Correct, but as noted above, it's not a gbm "dumb" buffer, but a normal
gbm buffer.

- The server then provides the client with a “ClientBuffer” which is
an abstraction of the hardware / software buffer containing the
information about the buffer (like format, stride, etc…) and its FD.


- To draw into this buffer, you need to
call mir_surface_get_graphics_region which through some indirection,
mmaps the buffer to a vaddr that can be written into.


Not correct for hardware buffers, see below for more. This only works
for software buffers, in which case the fd passed to the client is a
shared memory fd which can be mapped. In the case of hardware buffers
it's a "prime" fd which in general doesn't support sensible mapping of
that kind.

If you look at the basic.c demo, it creates a hardware buffer,
and if
you look at the fingerpaint.c demo, it creates a software buffer.
If I
modify the basic.c demo to call mir_surface_get_graphics_region, it
fails on VMWare, saying that it could not mmap the buffer. It works
fine if I change the basic.c to use a software buffer.

Is this an issue with VMWare? Or am I fundamentally not
understanding
something about how h