Reworking our support for platform specific functions

[Kevin DuBois]

Thinking from a different angle,

Some of this has to do with the fact that the mesa native window and native
display interface and the mir client api is blended together. If we
separated them out and moved the mesa stuff to native window headers, we'd
have a cleaner api.

Like, I consider these functions platform-specific:
mir_surface_get_platform_type
mir_surface_get_current_buffer
mir_connection_drm_auth_magic
mir_connection_drm_set_gbm_device
because they're used by mesa's egl and android (and android clients) don't
really use them, just mesa egl needs them for various reasons.

If our 'upstream' mesa would define a native buffer and native display
interface (or if certain mir headers would just migrate upstream), this
would let mir's mesa platform implement these interfaces. Android is forced
into doing this because we can't move the egl libraries, and must rely on
<system/window.h> for the native window type (android doesn't have a native
display type really)

Then, we could have a smaller client api with the sole role of supporting
people writing mir clients, instead of supporting both the people writing
mir clients and one of the platform's egl implementations.

Cheers,
Kevin

P.S.
Same line-of-thinking, but slightly different... MirNativeBuffer isn't a
convenient buffer type for android (have to unpack the ANativeWindowBuffer
into mesa's MirNativeBuffer)



On Tue, Oct 14, 2014 at 9:16 AM, Alexandros Frantzis <
alexandros.frantzis at canonical.com> wrote:

> On Tue, Oct 14, 2014 at 12:00:59PM +0100, Alan Griffiths wrote:
> > On 13/10/14 12:37, Alexandros Frantzis wrote:
> <snip>
> > >
> > > Client API: mir_connection_platform_operation(type, DataAndFds
> request, ...);
> > > Client    : MirConnection::platform_operation(type, ...)
> > > Protobuf  : rpc platform_operation(type, DataAndFds) returns
> (DataAndFds)
> > > Server    : SessionMediator::platform_operation()
> > > Platform  : DataAndFds PlatformIpcOperations::platform_operation(type,
> DataAndFds)
> > >
> > > Each platform should expose a header with its operation types and
> > > expected parameters types. For mesa it could be something like:
> > >
> > > enum MesaPlatformOperationType { drm_auth_magic, drm_get_auth_fd };
> > > struct DRMAuthMagicRequest { int magic; }
> > > struct DRMAuthMagicReply { int status; }
> > > ...
> > >
> > > And a request would be:
> > >
> > > DRMAuthMagicRequest request = { magic };
> > >
> > > void platform_operation_callback(
> > >     MirConnection* connection, DataAndFds const* reply, void* context)
> > > {
> > >     struct DRMAuthMagicReply const* magic_reply = reply->data;
> > >     ...
> > > }
> > >
> > > mir_connection_platform_operation(
> > >     drm_auth_magic, request, platform_operation_callback);
> <snip>
> > > Thoughts?
> >
> > I like the general approach, but have concerns about a bit of the detail.
>
> A caveat: the original email was meant mainly to illustrate the overall
> approach, I didn't focus on the details much (e.g. names and types are
> all tentative).
>
> > 1. Is there any point to having separating "type" from "data" and "fds"?
> > Or should the various data structures combine all three.
>
> We could avoid exposing any structure, apart from data vs fds (see
> below).
>
> > 2. In the client API would be good to use an opaque "PlatformMessage"
> > type, rather than a DataAndFds struct.
>
> We need to be able to separate the fds from the rest of the data, so
> that our RPC layer can send the fds properly. That's what the
> (tentative) name was trying to convey.
>
> > E.g.
> >
> >    DRMAuthMagicReply const* magic_reply = (DRMAuthMagicReply
> const*)mir_platform_get_data(reply);
> >
> > 3. With a C API we have to be explicit about ownership. E.g. does the
> client have to release
> > magic_reply or does it become invalid after the call?
>
> We could go either way, weighing the cost of copying data (and dup()-ing
> fds) vs the potential for memory/fd leaks. Let's be consistent with how
> we handle other similar cases in the client API (do we have other such
> cases?).
>
> > 4. Do we need to address byte encoding, sizes and alignment of platform
> data?
>
> I would say not in Mir. If a message has special needs, the sender
> should take care to serialize/deserialize it properly.
>
> Thanks,
> Alexandros
>
> --
> Mir-devel mailing list
> Mir-devel at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/mir-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/mir-devel/attachments/20141014/76652d77/attachment.html>