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, wh
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 libmirserve
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
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 mailin
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 blan
ve 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 phabl
g/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'
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 bl
y 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
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 th
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 conf
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
i
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 unsubscri
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 i
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 pa
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 k
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 wrot
r 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 wr
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
y 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
te:
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.c
plemented 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.
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:
Th
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 preven
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 re
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
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?
- Danie
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-
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,
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://list
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
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/la
sification 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
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
.
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:
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 qui
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
happ
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 enco
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:: -->
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
t _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 rea
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/
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
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 s
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 recogniza
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
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:
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
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' cod
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
r
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
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:
m
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 t
(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
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 nex
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
respons
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
nt 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
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 4b
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:
http
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.ubunt
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
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.launc
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:
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
-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.
nchpad.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
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 o
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-
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:da
"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 (!?).
O
hese 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
"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 exten
:)
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
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 u
r 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
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.9
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
p
#x27;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
mill
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, Danie
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 n
nning 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 se
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 Vug
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 :)
-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 is
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 proje
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 stra
oß 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 of
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
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:
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
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
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
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) h
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 t
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.
s
- 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_
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. :/
mi
mplemented 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
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 p
1 - 100 of 384 matches
Mail list logo
