On Thu, Oct 22, 2015 at 5:15 AM, Thomas Voß
wrote:
On Wed, Oct 21, 2015 at 4:38 PM, Alan Griffiths
wrote:
On 21/10/15 11:38, Thomas Voß wrote:
Well, we always need to satisfy the case of handing configuration
up & down a
nested shell scene. If we don't add the respective functionality
On 21/10/15 19:15, Thomas Voß wrote:
> On Wed, Oct 21, 2015 at 4:38 PM, Alan Griffiths
> wrote:
>> On 21/10/15 11:38, Thomas Voß wrote:
>>> Well, we always need to satisfy the case of handing configuration up & down
>>> a
>>> nested shell scene. If we don't add the respective functionality to
>>>
On Wed, Oct 21, 2015 at 4:38 PM, Alan Griffiths
wrote:
> On 21/10/15 11:38, Thomas Voß wrote:
>> Well, we always need to satisfy the case of handing configuration up & down a
>> nested shell scene. If we don't add the respective functionality to
>> the client api, we end up in
>> the situation of
On 21/10/15 11:38, Thomas Voß wrote:
> Well, we always need to satisfy the case of handing configuration up & down a
> nested shell scene. If we don't add the respective functionality to
> the client api, we end up in
> the situation of Unity8 being unable to speak to its parent Mir
> instance. Wit
On Wed, Oct 21, 2015 at 12:21 PM, wrote:
> On Tue, Oct 20, 2015 at 11:16 PM, Gerry Boland
> wrote:
>>
>> Hey folks,
>> it appears this topic has gone stale, without any consensus being reached.
>> A core issue impacting this discussion which remains undecided is the
>> following:
>>
>> - Is it i
On Tue, Oct 20, 2015 at 11:16 PM, Gerry Boland
wrote:
Hey folks,
it appears this topic has gone stale, without any consensus being
reached. A core issue impacting this discussion which remains
undecided is the following:
- Is it in Mir's scope as a display server to provide a client api
for
On 20/10/15 13:16, Gerry Boland wrote:
> - Is it in Mir's scope as a display server to provide a client api for
> configuring mir server settings like those for displays & input devices? Or
> should Mir expose a mirserver API for these settings, and require the shell
> to implement its own API v
Hey folks,
it appears this topic has gone stale, without any consensus being reached. A
core issue impacting this discussion which remains undecided is the following:
- Is it in Mir's scope as a display server to provide a client api for
configuring mir server settings like those for displays &
On Mon, Oct 12, 2015 at 10:53 PM, Alexandros Frantzis
wrote:
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 configura
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 base configs (subject to permis
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 base configs (subject to permission restrictions):
I know the current scheme also has issues, but how
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,
> > or at least in a way that will b
On Fri, Oct 2, 2015 at 7:00 AM, Gerry Boland
wrote:
On 01/10/15 17:55, Alan Griffiths wrote:
On 01/10/15 17:20, Gerry Boland wrote:
/me suspecting we'll need a doc.
We will, but at the moment we're still brainstorming requirements.
BTW IIRC at the pocket desktop sprint you were interest
On 01/10/15 17:55, Alan Griffiths wrote:
> On 01/10/15 17:20, Gerry Boland wrote:
>> /me suspecting we'll need a doc.
>
> We will, but at the moment we're still brainstorming requirements.
>
> BTW IIRC at the pocket desktop sprint you were interested in additional
> information in the config (e.g
On 01/10/15 17:20, Gerry Boland wrote:
> /me suspecting we'll need a doc.
We will, but at the moment we're still brainstorming requirements.
BTW IIRC at the pocket desktop sprint you were interested in additional
information in the config (e.g. EDID for monitors).
--
Mir-devel mailing list
Mir-
On 30/09/15 09:16, Alan Griffiths wrote:
> On 30/09/15 05:04, 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.
>
> I totally agree that the exis
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 30/09/15 05:04, 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.
I totally agree that the existing behaviour is "surprising"; what isn't
clear to
18 matches
Mail list logo
