Hi all,
I have been working on eglCreateImageKHR for the Mir EGL platform in
Mesa, using gbm_bo as the "native pixmap" type (EGL_NATIVE_PIXMAP_KHR).
This is needed by nested Mir, but could also be useful in general.
The current state of the (still very hacky) WIP can be found at:
lp:~afrantzis/m
On Fri, Sep 06, 2013 at 09:24:16PM +0300, Alexandros Frantzis wrote:
> Hi all,
>
> I have been working on eglCreateImageKHR for the Mir EGL platform in
> Mesa, using gbm_bo as the "native pixmap" type (EGL_NATIVE_PIXMAP_KHR).
> This is needed by nested Mir, but could
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 "mir_demo_server_basic" running with demo
> clients and then move on to Xmir
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
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
On Tue, Nov 05, 2013 at 03:36:52AM -0800, Jakob Bornecrantz wrote:
[SNIP]
Hi Jakob!
> >
> > Note that the Mesa codebase we are using has some changes in the GBM code
> > (experimental, not upstream yet). Notably:
> > * we allow creation of "dumb" drm buffers of arbitrary size (not just
> >
On Tue, Nov 05, 2013 at 12:13:42PM +0100, Thomas Hellstrom wrote:
[snip]
> Again that depends on the use-case. Is there any coherence assumed
> or data-transfer
> going on between the dumb drm buffer and the DRIimage? Or are you
> using it to be
> able to render to cursors?
The main use case for t
On Tue, Nov 05, 2013 at 03:17:49PM +0100, Thomas Hellstrom wrote:
> On 11/05/2013 02:55 PM, Alexandros Frantzis wrote:
[snip]
> >The main use case for this is to allow direct surface pixel access for
> >clients that either can't, or prefer not to use GL to render, wh
On Tue, Nov 05, 2013 at 06:47:55PM +0100, Thomas Hellstrom wrote:
[snip]
> >When creating a dumb GBM buffer we create a DRIimage associated with the
> >dumb DRM buffer using DRI's createImageFromName(). After that we treat the
> >GBM buffer as a normal non-dumb buffer as far as rendering is concer
On Wed, Nov 06, 2013 at 09:08:11AM +0100, Thomas Hellstrom wrote:
> I'm trying to tell you this as politely as I can, but I urge you to
> rework this path.
OK, hint taken. I will investigate what's involved in using shmem
instead of dumb buffers in Mir, and also what the performance
implications a
On Wed, Nov 06, 2013 at 06:07:30AM -0800, Jakob Bornecrantz wrote:
> - Original Message -
> > On Wed, Nov 06, 2013 at 09:08:11AM +0100, Thomas Hellstrom wrote:
> > > I'm trying to tell you this as politely as I can, but I urge you to
> > > rework this path.
> >
> > OK, hint taken. I will i
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'
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 probab
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. H
On Mon, Mar 31, 2014 at 03:04:29PM -0700, Kevin DuBois wrote:
> [1] Last I've heard about QtSG, DefaultDisplayBufferCompositor is the place
> that needs replacement). Correct me if things have changed :)
QtSG provides its own rendering threads, which are difficult to manage
externally and to dise
Hi all,
we recently hid a lot of our public headers, to avoid frequent ABI
breaks. As we start to gradually re-expose useful headers I think it
will be good to have broad guidelines about the limits of what we
expose.
One point I feel needs further discussion is the level (if any) at which
we st
On Fri, Oct 03, 2014 at 12:23:40PM +0100, Alan Griffiths wrote:
> Some time ago we introduce a "temporary" facility to hook into the
> protobuf messaging protocol. This is exemplified by the
> DemoPrivateProtobuf acceptance tests. This support was intended to allow
> faster prototyping of some feat
Hi all,
the need has arisen to add another platform-specific function, in order
to resolve bug LP: #1379266. This addition triggered some concerns about
the way we implement such functions.
The problem
---
In our current implementation, adding a platform-specific function
causes platform
On Tue, Oct 14, 2014 at 09:14:46AM +0100, Alan Griffiths wrote:
> On 14/10/14 08:14, Christopher James Halse Rogers wrote:
> >
> > We're 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 c
On Tue, Oct 14, 2014 at 12:00:59PM +0100, Alan Griffiths wrote:
> On 13/10/14 12:37, Alexandros Frantzis wrote:
> >
> > Client API: mir_connection_platform_operation(type, DataAndFds request,
> > ...);
> > Client: MirConnection::platform_operation(typ
On Tue, Nov 18, 2014 at 02:29:52PM +, Alan Griffiths wrote:
> On 18/11/14 10:04, Daniel van Vugt wrote:
> > I'd be happy with weekly (which I do already with the USA), but
> > spanning all timezones with one meeting isn't feasible...
>
> We have a daily "standup" with the USA, but whatever wor
Hi all,
in a recent review the subject of how to deal with precondition failures
in the client API came up again. In discussions we had yesterday the
consensus was that we should abort the process. This has the benefit of
catching the error as early as possible, making debugging much easier.
The
On Tue, Jan 20, 2015 at 08:19:32AM -0600, 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 display configs
> ? and reason
Hi all,
I think it's to time to consider moving from C++11 to C++14 (at least
the C++14 features our compilers support). C++14 offers some useful
improvements over C++11, like:
* std::make_unique()
* standard literal suffixes for std::chrono (e.g. auto delay = 10ms;)
* std::shared_timed_mutex (ak
Hello all,
there have recently been a few occasions where we wanted to experiment with
performance improvements, but lacked a way to easily measure their effect.
There have also been a few occasions where different implementations of the
(supposedly) same performance test came up with different re
On Fri, Jun 19, 2015 at 11:55:54AM +0100, Alan Griffiths wrote:
> On 19/06/15 11:52, Alan Griffiths wrote:
> > On 19/06/15 11:22, Alexandros Frantzis wrote:
> >> Hello all,
> >>
> >> there have recently been a few occasions where we wanted to experiment wit
On Thu, Jun 25, 2015 at 10:45:10AM -0700, Robert Carr wrote:
> Hi!
> I think the value of MirInputEvent is pretty limited.
Having a base MirInputEvent and deriving specialized input event types
seems like a natural model for the domain. However, it's problematic
since the interface shared by the
Hi all,
in the Mir project we are following the standard practice of forking off
a new branch from trunk for each (minor) release. The benefits of this
approach are well known, but to summarize, the main points are:
* Decouples trunk from the release process, i.e., we don't need
to temporar
On Tue, Aug 18, 2015 at 05:47:19PM +0100, Alan Griffiths wrote:to
> We're planning to try switching the clang builds to run on Vivid.
If we manage to fix the phone CI problem, which will then leave the
clang problem as the only CI blocker, I suggest that we disable clang
builds until the issue is
On Fri, Aug 28, 2015 at 04:46:24PM +0100, Alan Griffiths wrote:
> The current approach to naming stanzas in the symbol maps leads to a
> potential for mistakes. For example, src/platform/symbols.map has the
> following stanzas:
>
> MIRPLATFORM_9 {
> ...
> }
>
> MIRPLATFORM_9.1 {
> ...
> } MIRPLAT
On Wed, Sep 30, 2015 at 02:04:00PM +1000, Christopher James Halse Rogers wrote:
> Forked from review¹.
>
> I think we're currently handling display configuration events incorrectly,
> or at least in a way that will be surprising to clients.
For a bit of background, the current scheme is:
1. User
On Mon, Oct 05, 2015 at 11:33:44AM +0100, Alan Griffiths wrote:
> In debugging our cursor code and getting it under tests I found
> something surprising (to me). Vis:
>
> std::shared_ptr
> mir::DefaultServerConfiguration::the_cursor_images()
> {
> return cursor_images( [this]() -> std::shared_
On Wed, Sep 30, 2015 at 12:50:14PM +0300, Alexandros Frantzis wrote:
> On Wed, Sep 30, 2015 at 02:04:00PM +1000, Christopher James Halse Rogers
> wrote:
> > Forked from review¹.
> >
> > I think we're currently handling display configuration events incorrectly,
>
On Mon, Oct 12, 2015 at 02:14:17PM +0100, Alan Griffiths wrote:
> On 12/10/15 12:53, Alexandros Frantzis wrote:
> > So, my take is that the only config that clients need to be notified
> > about is the base one. Clients also need to be able to set the session
> > and bas
On Tue, Mar 01, 2016 at 05:08:47PM +1100, r...@ubuntu.com wrote:
> Hey all,
>
> Pursuant to Alan's comment¹ and subsequent follow-ons, in the interests of
> rapid CI turnaround Jenkins now does regular CI runs with
> DEB_BUILD_OPTIONS=noopt. This currently means it does an -O0 build, and will
> di
On Wed, Mar 02, 2016 at 07:58:44PM +0200, Alexandros Frantzis wrote:
> On Tue, Mar 01, 2016 at 05:08:47PM +1100, r...@ubuntu.com wrote:
> > Hey all,
> >
> > Pursuant to Alan's comment¹ and subsequent follow-ons, in the interests of
> > rapid CI turnaround Jenki
Hi all,
for a few years now, Mir has provided the --offscreen option to render
to offscreen buffers instead of the real outputs (note that it still
needs proper GPU/GLESv2 support, and it doesn't work in all
environments). This option was implemented experimentally in order to
help with automated
37 matches
Mail list logo
