touch-packages team mailing list archive

[Alan Griffiths <1515558@xxxxxxxxxxxxxxxxxx>]

Having a (hopefully) temporary workaround that handles some common
scenarios isn't a fix. Here (copied from the email discussion) are some
notes about resolving this:

as discussed following today's standup the problems we face involves a
number of issues beyond the probing logic.

There are three contexts that matter: The Host Server; The Nested
Server; and, The Client.

At present these all resort to some form of "probing" to decide what
platform module to load. This is wrong, but we've only recently started
seeing the problems it causes. Only the Host Server should be making a
decision on the platform, the Nested Server and the Client should
respect that decision.

Currently, the client code sees no difference between KMS and X11 - it
just chooses between "android" and "mesa", which is a decision that is
usually right. However, if we ever get additional platforms that "look
alike" it will encounter the same problems we've seen recently without
needing a nested server. Consequently, it would be better for the server
to tell it which driver to load.

The Nested Server is where we've seen problems arise. As it need not be
running as the same user, with the same rights, with the same
environment nor configuration options as the Host Server it cannot
reliably deduce which platform the host has chosen. Consequently, it
would be better for the Host Server to tell it which driver to load.

Also worth considering is that the Nested Server only needs a server
platform module to instantiate a "GuestPlatform" the principle function
of which is buffer allocation. With "New Buffer Semantics" this will be
possible through the client API - which may obsolete the need for
platform specific "GuestPlatform" implementations. If we can eliminate
loading a platform module to create a "GuestPlatform" then we achieve a
significant simplification.

Coming out of this there are several pieces of work:

1. improve the decision logic in the Host Server and platform probing to
deal with tie-breaking. (E.g. KMS should be preferred to X11.)

2. Enable the server to inform the client/nested server of the correct
platform module to load. (This doesn't need to be surfaced in the client
API, it is internal.)

3. Once the NBS client API is finalized. Revisit the need for a platform
specific GuestPlatform - ideally one can be written in terms of the
client API.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to mir in Ubuntu.
https://bugs.launchpad.net/bugs/1515558

Title:
  [regression] Nested servers on mesa-kms select wrong (dummy) guest
  platform

Status in Mir:
  Triaged
Status in Mir 0.18 series:
  Won't Fix
Status in mir package in Ubuntu:
  Invalid

Bug description:
  $ sudo bin/mir_demo_server --window-manager system-compositor --display-config sidebyside --vt 1 --arw-file
  $ bin/mir_demo_server --host /tmp/mir_socket --display-config clone 
  ...
  [1447325929.742637] mirserver: Selected driver: dummy (version 0.18.0)

  Seems to be -c 3098 as specifying a dummy --vt parameter is a
  workaround

To manage notifications about this bug go to:
https://bugs.launchpad.net/mir/+bug/1515558/+subscriptions