|
|
Subscribe / Log in / New account

Canonical reveals plans to launch Mir display server (The H)

Canonical reveals plans to launch Mir display server (The H)

Posted Mar 5, 2013 0:57 UTC (Tue) by heijo (guest, #88363)
Parent article: Canonical reveals plans to launch Mir display server (The H)

The protocol appears to be this (it uses Google Protocol Buffers):

message ConnectParameters {
required string application_name = 1;
optional int32 lightdm_id = 2;
}

message SurfaceParameters {
required int32 width = 1;
required int32 height = 2;
required int32 pixel_format = 3;
required int32 buffer_usage = 4;
optional string surface_name = 5;
}

message SurfaceId {
required int32 value = 1;
};

message LightdmId {
required int32 value = 1;
};

message Buffer {
optional int32 buffer_id = 1;
repeated sint32 fd = 2;
repeated int32 data = 3;
optional int32 fds_on_side_channel = 4;
optional int32 stride = 5;

optional string error = 127;
}

message Platform {
repeated sint32 fd = 1;
repeated int32 data = 2;
optional int32 fds_on_side_channel = 3;

optional string error = 127;
}

message DisplayInfo {
required int32 width = 1;
required int32 height = 2;
repeated uint32 supported_pixel_format = 3;
}

message Connection {
optional Platform platform = 1;
optional DisplayInfo display_info = 2;

optional string error = 127;
}

message Surface {
optional SurfaceId id = 1;
optional int32 width = 2;
optional int32 height = 3;
optional int32 pixel_format = 4;
optional int32 buffer_usage = 5;
optional Buffer buffer = 6;

optional string error = 127;
}

message DRMMagic {
optional uint32 magic = 1;
optional string error = 127;
}

message DRMAuthMagicStatus {
optional int32 status_code = 1;
optional string error = 127;
}

message Void {
optional string error = 127;
}

service DisplayServer {
// Platform independent requests
rpc connect(ConnectParameters) returns (Connection);
rpc disconnect(Void) returns (Void);
rpc create_surface(SurfaceParameters) returns (Surface);
rpc next_buffer(SurfaceId) returns (Buffer);
rpc release_surface(SurfaceId) returns (Void);
rpc select_focus_by_lightdm_id(LightdmId) returns (Void);

// Platform specific requests
rpc drm_auth_magic(DRMMagic) returns (DRMAuthMagicStatus);

rpc test_file_descriptors(Void) returns (Buffer);
}

First of all, the use of an "optional string error" field in every returned structure (requiring all other fields to be marked optional!!!) is a telltale sign that the designer of this is an idiot, since anyone with a bit of sense and taste would use an exception mechanism in the RPC code instead and not destroy requiredness info in the messages.

Second, putting LightDM in the core protocol is similarly horrendous and weird.

Finally, this protocol has no way to resize windows, no input support, no nontrivial vsync handling, no DPI information, no subpixel layout/transform information, no apparent support for multi-GPU and multi-monitor, no window-in-window embedding support, and generally nothing beyond a basic skeleton.

It's a toy, or perhaps a joke.


to post comments


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds