On Thu, 2013-07-25 at 03:40 +0200, Michał Sawicz wrote:
> W dniu 25.07.2013 01:28, Robert Carr pisze:
> > I don't mean to raise FUD but it is unclear enough to me that I would
> > not know the first step if assigned it as a task (My first question
> > would be, does ms::Surface implement QQuickItem
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 a
'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:
&
On Tue, 2013-11-05 at 12:04 +0200, Alexandros Frantzis wrote:
> On Tue, Nov 05, 2013 at 08:22:28AM +0100, 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 "m
On Wed, 2013-11-06 at 09:15 +0100, Thomas Hellstrom wrote:
> On 11/06/2013 12:21 AM, Christopher James Halse Rogers wrote:
> > On Tue, 2013-11-05 at 12:04 +0200, Alexandros Frantzis wrote:
> >> On Tue, Nov 05, 2013 at 08:22:28AM +0100, Thomas Hellstrom wrote:
> >>> H
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 us
On Mon, 2013-11-11 at 10:33 -0200, Daniel d'Andrada wrote:
> Hi Christopher,
>
> The job of EventHub, in short, is multiplexing the event streams from
> all those /dev/input/event* files into a single output stream of events
> (those events then having device ids to identify from which device th
On Mon, 2013-11-11 at 12:11 -0800, Robert Carr wrote:
> >> 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 t
On Tue, 2013-11-12 at 11:51 -0800, Robert Carr wrote:
> >> I don't think it makes sense to have the uncooked events leave the
> >> device-specific code. What currently happens is that InputReader “cooks”
> >> them, but needs to call back into EventHub in order to do that.
>
> >> Only the device-sp
On Wed, 2013-11-13 at 09:27 -0200, Daniel d'Andrada wrote:
> On 12/11/13 21:57, Christopher James Halse Rogers wrote:
> > I think we might have different stages of cooking here :). I want the
> > events leaving EventHub to be a usefully accurate representation of the
> &g
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 co
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 c
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 contribution
On Mon, 2013-11-25 at 08:12 +0100, Thomas Voß wrote:
> On Mon, Nov 25, 2013 at 7:51 AM, 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
> > co
On Mon, 2013-11-25 at 15:00 +0800, Daniel van Vugt wrote:
> (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
Thanks for starting this off Alan,
On Wed, 2013-12-11 at 14: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
On Thu, 2013-12-12 at 10:01 +0800, Daniel van Vugt wrote:
> "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* thought I was agreeing with the Simple/Simplistic method :). When
Alan brought up
On Thu, 2013-12-12 at 10:34 +0100, Thomas Voß wrote:
> On Thu, Dec 12, 2013 at 5:46 AM, Christopher James Halse Rogers
> wrote:
> > On Thu, 2013-12-12 at 10:01 +0800, Daniel van Vugt wrote:
> >> "Half-assed" is inaccurate I think. Under that heading you describe
>
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
On Tue, 2013-12-17 at 14:56 +, Alan Griffiths wrote:
> On 16/12/13 01:39, Daniel van Vugt wrote:
> > 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?
>
> Wrong.
>
> > I'm still mo
On Fri, 2013-12-20 at 08:45 +0100, Thomas Hellstrom wrote:
> Hi,
>
> Thanks for the reply.
>
> On 12/20/2013 03:25 AM, Daniel van Vugt wrote:
> > Thomas,
> >
> > Excellent work, thanks.
> >
> > The two people best placed to answer your questions are now on
> > vacation, but I shall try;
> >
> > 1
On Fri, 2013-12-20 at 15:59 +0800, Christopher James Halse Rogers wrote:
> On Fri, 2013-12-20 at 08:45 +0100, Thomas Hellstrom wrote:
> > Hi,
> >
> > Thanks for the reply.
> >
> > On 12/20/2013 03:25 AM, Daniel van Vugt wrote:
> > > Thomas,
> > >
Because I'd like to remove it, because adding a dependency on libudev to
the android build makes setup-partial-armhf-chroot.sh very unhappy, and
fixing it will be much more ugly and time consuming than documenting how
to use an armhf schroot properly.
I'll adjust cross-compile-chroot.sh appropriat
On Sun, 2014-01-26 at 12:17 -0800, 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
On Tue, 2014-01-28 at 12:32 +0100, Marco Trevisan wrote:
> Il giorno mar, 28/01/2014 alle 14.47 +0800, Daniel van Vugt ha scritto:
> >1. Create a diff: bzr diff --old :parent > ~/bigone.diff
> >2. Create a new branch and reapply the changes: patch -p0 <
> > ~/bigone.diff
> >3. Identif
On Tue, 2014-01-28 at 15:03 -0800, Kevin DuBois wrote:
> I think we have 3 issues that drive up diff size:
>
> 1) Bzr has branches, but they aren't cheap enough. The simple fact that you
> have to compile each branch in its own directory is too big of a cost to
> branch as often as I would in git.
Hey all!
While wandering through the various latent valgrind errors that
udevify-eventhub somehow exposes I noticed that we have an open TODO to
work out what the lifecycle of MirWaitHandles should be.
Thinking about it, in the new context of our plan to finish moving
error-handling into err
On Thu, Mar 13, 2014 at 9:54 AM, Daniel van Vugt
wrote:
You know it's a feature of MirWaitHandle that multiple threads can
and do wait on the same handle? We rely on this feature; I forget
where.
But that means your actual wait call can't free the wait object. More
wait calls can and will co
Hey all!
In conversation with Robert just now I discovered he wasn't aware of
the existence of mtf::InProcessServer.
If you're ever writing tests which need to exercise client<->server
communication, this should be your go-to fixture. It's got a number of
advantages:
1) It doesn't rely on
Interesting reading from everyone's favourite break-nvidia's-security
researcher!
http://mupuf.org/blog/2014/03/18/managing-auth-ui-in-linux/http://mupuf.org/blog/2014/02/19/wayland-compositors-why-and-how-to-handle/
--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsub
Oh, hi. Looks like someone forgot the space bar!
http://mupuf.org/blog/2014/02/19/wayland-compositors-why-and-how-to-handle/
and
http://mupuf.org/blog/2014/03/18/managing-auth-ui-in-linux/
--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://li
On Tue, Apr 1, 2014 at 12:38 AM, Kevin Gunn
wrote:
On Sun, Mar 30, 2014 at 9:06 PM, Daniel van Vugt
wrote:
This topic sounds like what I've been working on - moving the pieces
around so that anything and everyone can play nicely with Mir. It's
really an evolution toward reaching some c
On Wed, Apr 2, 2014 at 7:47 PM, Alan Griffiths
wrote:
On 02/04/14 04:03, Daniel van Vugt wrote:
We're almost at final freeze [1]. However Mir 0.1.8 requires one or
two more fixes before it gets tagged. In the mean time, please try
to
avoid top-approving anything that's not a critical fi
Hey Daniel!
On Fri, Apr 4, 2014 at 3:40 AM, Daniel Holbach
wrote:
Hello everybody,
…
We are currently at libxkcommon 0.3.1, Debian has 0.4.0. Timo
Aaltonen in #ubuntu-x was very helpful, did a test-build of 0.4.1,
pushed it to Debian git and to
https://launchpad.net/~tjaalton/+archive/te
Hm. I've just tried ubuntu-desktop-mir, and it (mostly) works for me on
Intel HW.
Things went pear-shaped when I tried to VT switch - it did indeed look
like Xorg was trying to VT switch too, which results in sadness - but
by and large things worked (multimonitor, resolution changes,
suspend/
On Wed, Apr 9, 2014 at 5:44 PM, Thomas Hellstrom
wrote:
Hi!
Thanks for the reply.
I've done a bit of debugging, and this happens because the
unity-greeter
tries to create up a pixmap of size (0,0). X doesn't allow that and
sends an error to unity-greeter that shuts down. Lightdm then shuts
On Wed, Apr 9, 2014 at 8:24 PM, Thomas Hellstrom
wrote:
Hi!
Please see below.
On 04/09/2014 10:11 AM, Christopher James Halse Rogers wrote:
On Wed, Apr 9, 2014 at 5:44 PM, Thomas Hellstrom
wrote:
Hi!
Thanks for the reply.
I've done a bit of debugging, and this happens becaus
We've got a bug filed¹ documenting that we don't support
single-buffered clients. I'd like to mark this as WontFix.
The reasoning being: single buffered clients cannot reliably render
without glitches, EGL allows us to not support frontbuffer rendering,
and our current pseudo-support for singl
On Tue, Apr 29, 2014 at 4:12 PM, Daniel van Vugt
wrote:
It does kind of work now, providing you honor the limitation of not
producing and consuming at the same time.
And how do you honour that limitation? By ‘consuming’ here you mean
‘compositing’, right? Your global framerate is then limi
On Tue, Apr 29, 2014 at 4:40 PM, Christopher James Halse Rogers
wrote:
On Tue, Apr 29, 2014 at 4:12 PM, Daniel van Vugt
wrote:
> It does kind of work now, providing you honor the limitation of not
> producing and consuming at the same time.
And how do you honour that limitati
For those playing at home, there's further discussion on
https://code.launchpad.net/~vanvugt/mir/single-buffer/+merge/217555
--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/mir-devel
On Fri, May 2, 2014 at 1:53 AM, Alan Griffiths
wrote:
On 01/05/14 16:51, Cemil Azizoglu wrote:
The platform interface is not much different from mir server and
client ABI in terms of backward/forward compatibility.
+1
Regardless, I think these should be moved out of the dynamic loader's
d
On Tue, May 13, 2014 at 1:52 PM, Daniel van Vugt
wrote:
All,
I'd like (in the somewhat distant future) for us to be able to run
Mir's tests under helgrind [1] so that we can automatically detect
races in continuous integration.
It's not going to be a short journey, as there's a fair amount
On Tue, May 13, 2014 at 4:21 PM, Daniel van Vugt
wrote:
The std::atomic issue is minor and well understood (helgrind only
understands critical sections implemented using pthread primitives).
We can either suppress std::atomic using valgrind rules or replace it
(less efficiently). That said, pl
On Wed, Jul 9, 2014 at 12:00 PM, Daniel van Vugt
wrote:
Sounds better to just pass buffers around although I'm not keen on
any change that doesn't make progress on the performance bottleneck
LP: #1253868. The bottleneck is the swapping/exchanging approach
which limits the client to holding onl
On Thu, Jul 10, 2014 at 3:53 AM, Alberto Aguirre
wrote:
I think RAOF point is accurate, with the current existing approach
(triple buffered by default), BufferQueue has 2 buffers for clients,
1 for compositor. rpc next_buffer(SurfaceId) returns (Buffer) will
return immediately as BufferQueu
Hey all!
I'll just point out that if you ever need to fiddle with the Mir
packaging that I'm an Ubuntu Core Dev and so have a pretty good handle
on all the various things that you'll need to do. :)
If you do something that needs packaging work - add a new library, bump
SONAME, whatever - and
Hey, y'all.
One of the things the RPC transport rework has shaken out is the
interaction of mir_lifecycle_connection_lost and mir_connection_release.
Previously, mir_connection_release would not generate a connection_lost
lifecycle event; now it (mostly) does, and this is reflected in the
up
So, I think the cause of much of the heartache in the packaging in
https://code.launchpad.net/~mir-team/mir/libmircommon/+merge/226704
is because the CI test is using our tools in a way that doesn't match
standard practice.
The Breaks/Replaces pair *should* work, using apt to install those
pac
On Tue, Jul 22, 2014 at 10:04 AM, Thomi Richards
wrote:
Hi,
I commented on the bug, but I may as well comment here:
On Tue, Jul 22, 2014 at 11:42 AM, Gerry Boland
wrote:
3. Mir let the clients find their surface's screen position
I'm pushing for this solution, for a variety of reasons.
On Tue, Jul 22, 2014 at 11:23 AM, Luke Yelavich
wrote:
On Tue, Jul 22, 2014 at 09:42:42AM EST, Gerry Boland wrote:
Hey folks,
in working on QtCompositor, I stumbled across a problem ([1]).
Autopilot needs to know the position of items in an application
(buttons, etc) in screen coordinat
On Wed, Jul 23, 2014 at 7:11 AM, Thomi Richards
wrote:
…
This may, or may not all be true, but none of it helps solve the
problem :)
I think this conversation is drifting away from the original point.
Are there any strong objections to making the existing Qt API "just
work" on mir?
Fun
On Thu, Jul 24, 2014 at 12:03 PM, Daniel van Vugt
wrote:
While events are being injected into evdev at the kernel level, you
do have to know screen coordinates of the window in the least, so
touches match up. That makes Mir's sharing the window position
important.
We could take Mir out of
Hey all.
This is somewhat of a revival of a discussion from London, and
tangentially related to the contentious fatal-error branch.
We currently have no logging in our codebase outside of the 3rd_party
android code. This makes it difficult to work out what's happening when
things go wrong be
On Thu, Jul 24, 2014 at 4:01 PM, Daniel van Vugt
wrote:
Just remember to map points like the Qt interface does:
Point screen_coord = mir_surface_coord_to_screen(surface,
client_coord);
So we are covered for arbitrary 3D transformations (don't assume
windows are on screen as rectangles).
On Thu, Jul 24, 2014 at 4:14 PM, Daniel van Vugt
wrote:
We currently have no logging in our codebase outside of the 3rd_party
android code.
Yes we do. Just remember to re-use or enhance it:
include/shared/mir/logging/logger.h
src/shared/logging/dumb_console_logger.cpp
Yes, we have some i
On Thu, Jul 24, 2014 at 4:36 PM, Daniel van Vugt
wrote:
Yeah that's problem (2) mentioned below. And not really a problem.
Autopilot only wants to know one point where it can click a button.
The outcome is unaffected if the surface is rendered in multiple
different locations. Just click _one_
Hey all!
As seen on IRC last night:
18:22 Seems like we need a way to replicate what the silos are
doing - building mir, creating packages from it, installing them, and
then building downstreams... I.e. not just building downstreams using
mir binaries, but using mir packages..
Fortunat
On Sat, Aug 9, 2014 at 11:22 AM, Cemil Azizoglu
wrote:
Sync'ed up 0.6 with devel@r1831 since we were in TRAINCON-0.
Everything built successfully.
Using image #179 with 0.6, mir itself works (i.e. mir-demos &
nested), but USC has the following error :
root@ubuntu-phablet:~# cat
/var/log/li
On Tue, Aug 12, 2014 at 3:09 AM, Gerry Boland
wrote:
Hey folks,
this discussion fizzled out and a conclusion wasn't clear to me. I've
taken the liberty to summarize where the discussion got so far.
The options considered possible (1. was dismissed):
2. AP injects events directly into Qt/unity
On Tue, Aug 12, 2014 at 12:33 PM, Daniel van Vugt
wrote:
There is a 5th option which would satisfy more (not all) of the
people mentioned:
5. Shell mediates if a client has permission to ask for surface
coordinates. The API is restricted by default. The API _does_not_
return the top-left cor
On Tue, Aug 12, 2014 at 1:13 PM, Daniel van Vugt
wrote:
I think it's mathematically pedantic to say the function does not
exist.
The *best kind* of pedantry!
Acknowledging that such a function would theoretically return a set;
one, multiple or none coordinates (offscreen or occluded), we
al Message-
From: "Gerry Boland"
Sent: 12/08/2014 18:40
To: "Christopher James Halse Rogers"
Cc: "mir-devel@lists.ubuntu.com"
Subject: Re: Clients reading their surface position on screen
On 12/08/14 03:33, Christopher James Halse Rogers wrote:
> On Tue, Aug
Ok. I think we've explored all the relevant options
If I implemented
mir_debug_surface_coord_to_screen(MirSurface, int x, int y, int* outx,
int* outy)
in libmirclient-debug and hooked it up to a --debug flag, who would
object, and what would those objections be?
--
Mir-devel mailing list
ction and make it "just work" [QWidget::mapToGlobal()].
Go nuts, Chris :)
On 14/08/14 07:51, Thomi Richards wrote:
On Thu, Aug 14, 2014 at 11:31 AM, Christopher James Halse Rogers
mailto:ch...@cooperteam.net>> wrote:
in libmirclient-debug and hooked it up to a --debug flag, w
On Thu, Aug 14, 2014 at 6:28 PM, Daniel van Vugt
wrote:
I think a MirBool is enough. Although if anyone does implement the Qt
function later then that one doesn't have such luxury. You would have
to return some invalid Point for Qt.
Which is one reason why we absolutely should not implement t
On Fri, Aug 15, 2014 at 9:32 AM, Gerry Boland
wrote:
On 14/08/14 00:31, Christopher James Halse Rogers wrote:
Ok. I think we've explored all the relevant options
If I implemented
mir_debug_surface_coord_to_screen(MirSurface, int x, int y, int*
outx,
int* outy)
in libmirclient-
On Fri, Aug 15, 2014 at 5:14 PM, Gerry Boland
wrote:
On 15/08/14 00:56, Christopher James Halse Rogers wrote:
On Fri, Aug 15, 2014 at 9:32 AM, Gerry Boland
wrote:
> On 14/08/14 00:31, Christopher James Halse Rogers wrote:
>> Ok. I think we've explored all the relevant optio
On Fri, Aug 15, 2014 at 5:21 PM, Gerry Boland
wrote:
On 15/08/14 08:17, Christopher James Halse Rogers wrote:
On Fri, Aug 15, 2014 at 5:14 PM, Gerry Boland
wrote:
> On 15/08/14 00:56, Christopher James Halse Rogers wrote:
>> On Fri, Aug 15, 2014 at 9:32 AM, Gerry Boland
&
So, having implemented the controversial surface-to-screen interface
for autopilot, it's now also a controversial merge proposal!
https://code.launchpad.net/~raof/mir/the-least-dirty-thing/+merge/231679
The question is “should we have the debugging interface provided by a
separate libmirclient
I thought Qt was already smart enough to do this. Clearly not; thanks
Jolla!
http://blog.rburchell.com/2014/09/profiling-is-not-understanding.html
--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/mir-devel
I, too, like the idea of a generalised approach. I just think that this
is insufficiently generalised :).
We're talking about extensions here, but again we're talking about
throwing void* around. It's entirely possible to add a mechanism for
the platform (or other code) to register extra proto
On Tue, Oct 21, 2014 at 1:10 PM, Daniel van Vugt
wrote:
Missing (possibly just due to over-simplification in the high level
design):
* Non-input events
Correct. Non-input events aren't input events, and so will be treated
separately :)
* Event struct size field (would allow for compression
Hey all.
We're getting into the meaty bit of client API support I thought I'd
write some things about API design philosophy to see if they're
controversial.
*) An API with lots of functions that do one thing each is simpler than
an API with few functions that do different things depending on
ee on the measurement criteria it's very difficult to reach
consensus on the code :)
On 10/11/14 10:48, Christopher James Halse Rogers wrote:
Hey all.
We're getting into the meaty bit of client API support I thought I'd
write some things about API design philosophy to see if t
On Tue, Nov 11, 2014 at 12:33 PM, Daniel van Vugt
wrote:
We are actually in violent agreement on "policy" and conflating two
different issues. So please, let's separate them :)
It is indeed up to the server/shell to dictate policy, particularly
as it can and will vary between shells/modes
On Tue, Nov 11, 2014 at 12:48 PM, Daniel van Vugt
wrote:
On the second issue of client API design, it's useful to point out
why the menu example is not a good argument:
1. Depending on your shell, and its current mode, a "menu" might not
have a relative position dictated by the window posi
writing asynchronous client functions so they don't
> return errors immediately. Rather you can optionally wait for their
> completion and then query what actually happened.
>
>
> On 11/11/14 10:12, Christopher James Halse Rogers wrote:
>>
>>
>> On Tue, Nov 11,
On Fri, Nov 21, 2014 at 2:50 AM, Alan Griffiths
wrote:
As part of the mir::Server API migration I'm looking at some
acceptance
tests that customize the [frontend]DisplayChanger.
Now, with the phone we've not got any downstreams that use this
customization so it is currently hidden.
But I thin
I have nothing much to add to this, besides my +1. Cheap precondition
tests should abort.
--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/mir-devel
On Thu, Dec 11, 2014 at 7:59 AM, Kevin DuBois
wrote:
…
Details of why:
HWC's prepare() and set() functions post to all the displays in one
call.
Incidentally, how does this work with displays of different refresh
rate? Does HWC drop pending flips when a new flip is scheduled?
--
Mir-de
On Wed, Jan 21, 2015 at 1:36 AM, Alan Griffiths
wrote:
On 20/01/15 14:19, Kevin Gunn wrote:
hi all -
Just catching up on some bug house cleaning & found an open question
on this bug
https://bugs.launchpad.net/mir/+bug/1401916
Is there an architectural preference for where to save off
On Tue, Jan 27, 2015 at 2:50 PM, Daniel van Vugt
wrote:
We seem to have some client functions residing in libmircommon now...
That sounds reasonable at first but doesn't this prevent us from
being able to bump the common ABI without breaking clients?
No? They'll just link to libmirclient8. T
On Fri, Jan 23, 2015 at 1:01 PM, Daniel van Vugt
wrote:
dandrada:
Yeah the separation of touch from mouse events doubles the number of
functions, but that's probably useful in the long run. Only dumb
legacy apps want to treat them as the same thing. Any modern app will
see them as differe
mon, right?
In which case the client code never references anything in
libmircommon, it's symbol table contains nothing from libmircommon, and
everything is handled by ld.so when libmirclient is loaded.
On 28/01/15 08:57, Christopher James Halse Rogers wrote:
On Tue, Jan 27, 2015 at 2:50
ut never client
code→libmircommon, right?
In which case the client code never references anything in
libmircommon,
it's symbol table contains nothing from libmircommon, and everything
is
handled by ld.so when libmirclient is loaded.
On 28/01/15 08:57, Christopher James Halse Rogers wrote:
On
On Wed, Feb 18, 2015 at 12:08 AM, Alan Griffiths
wrote:
On 17/02/15 12:37, Alexandros Frantzis wrote:
Let me know what you think.
There are probably four important constituencies that need to build
Mir
and they may well be targeting different platforms.
1. Mir developers - they are clearl
On Wed, Feb 18, 2015 at 1:18 PM, Daniel van Vugt
wrote:
Also worth noting, it takes less effort to support trusty:
https://code.launchpad.net/~vanvugt/mir/revive-trusty/+merge/249789
than it does to start using C++14 features:
https://code.launchpad.net/~afrantzis/mir/introduce-c++14/+me
On Mon, Mar 23, 2015 at 3:33 AM, Cemil Azizoglu
wrote:
Thanks Daniel for noticing this. I agree that there may be unforeseen
risks even though things seem to work. We should fix this ASAP,
preferably with a test case that screams when two versions are loaded
simultaneously. Bumping the priorit
On Fri, May 29, 2015 at 2:35 AM, Alan Griffiths
wrote:
There's a comment in unity-system-compositor (src/window_manager.cpp)
// We need to wait for the second frame before marking the session
// as ready. The first frame posted from sessions is a blank
frame.
// TODO: Solve thi
On Tue, Jun 2, 2015 at 2:02 AM, Alan Griffiths
wrote:
…
The only disagreement on this thread seems to be whether or not
mir_demo_server should clear the background when started. I propose
to take the easier approach of retaining the existing behaviour (of
not).
This is fine by me.
--
Mir-
On Mon, Jun 15, 2015 at 7:09 PM, Alan Griffiths
wrote:
In extracting some sensible default behaviour from USC I've touched on
an issue (highlighted by Alexandros) that needs discussion. As some of
interested parties may not have tracked the MP I've copied it here:
> We have always assumed one
On Fri, Jun 26, 2015 at 12:09 PM, Daniel van Vugt
wrote:
+1 on having a discussion. I wondered the same when I touched those
APIs a few months ago.
I don't think the intermediate InputEvent is useful enough to keep.
Conceivably any app/toolkit developer could want to correlate other
types of
On Fri, Jun 26, 2015 at 12:39 PM, Daniel van Vugt
wrote:
I'm curious (but not yet concerned) about how the new plan will deal
with the transitions we have between 2-3-4 buffers which is neatly
self-contained in the single BufferQueue class right now. Although as
some responsibilities clearly l
have worded that poorly too. The point is in
the
> new world (tm) frame dropping mostly happens in the client (as
opposed
> to all in the server like it is today). But some of it still needs
to
> happen in the server because you don't want a compositor that tries
to
> keep up
reasoning.
Ah, yes. A frame callback is indeed a fine idea that neatly bypasses
all the problems.
On 26/06/15 12:16, Christopher James Halse Rogers wrote:
On Fri, Jun 26, 2015 at 2:04 PM, Daniel van Vugt
wrote:
Hmm, maybe not. If we assume the server is only communicating with
the
clie
On Wed, Jul 1, 2015 at 3:36 AM, Alberto Aguirre
wrote:
I think we should avoid replicating validation rules when possible,
because in the end, validation is really up to the window manager
policy - its the one entity which knows the valid combination of
parameters.
I don't think this should
On Thu, Jul 2, 2015 at 4:45 AM, Alberto Aguirre
wrote:
On Tue, Jun 30, 2015 at 11:35 PM, Christopher James Halse Rogers
wrote:
On Wed, Jul 1, 2015 at 3:36 AM, Alberto Aguirre
wrote:
I think we should avoid replicating validation rules when possible,
because in the end, validation is
On Tuesday, 21 July 2015 7:32:11 PM AWST, Kevin DuBois wrote:
Sounds like it'll make usc management easier, +1.
On Tue, Jul 21, 2015 at 6:03 AM, Alan Griffiths <
alan.griffi...@canonical.com> wrote:
On 21/07/15 11:00, Alexandros Frantzis wrote:
> I propose that we move to the same
> scheme for
Woot! Good work everyone.
On Mon, Aug 10, 2015 at 11:58 PM Gerry Boland
wrote:
> Hey folks,
> a quick announcement, we have initial support for Qt clients on Mir
> (i.e. qtubuntu) upstream in Qt! It'll land in Qt5.6.
>
> https://codereview.qt-project.org/#/c/122984/
>
> A huge thanks to Paul Ola
1 - 100 of 133 matches
Mail list logo
