On 2017-12-14 05:40 AM, Pekka Paalanen wrote:
From: Pekka Paalanen
Reacting to DRM hotplug events is racy. It is theoretically possible to
get hotplug events for a quick swap from one monitor to another and
process both only after the new monitor is connected. Hence it is
possible for display d
On 2017-12-14 05:40 AM, Pekka Paalanen wrote:
From: Pekka Paalanen
Add support for subscribing to weston_head destruction.
The primary use case for heads being destroyed arbitrarily is the
DRM-backend with MST connectors, which may disappear on unplug. It is
not just the connector becoming dis
On 2017-12-14 05:40 AM, Pekka Paalanen wrote:
From: Pekka Paalanen
Introduce the API for users (compositors) to create an output from a
head, attach and detach heads, and destroy outputs created this way.
This also adds the backend-facing API to libweston.
In the new API design, a backend crea
On 2017-12-14 05:40 AM, Pekka Paalanen wrote:
From: Pekka Paalanen
Add a hook for compositors to get a callback when heads are added or
their connection status changes, to which compositors likely want to
react to by enabling or disabling outputs (API for that to be added
later).
As many head
Bump! Can you give me feedback please? Having a safe wl_signal_emit would
greatly benefit libwayland users.
---
Simon Ser
https://emersion.fr
Original Message
On January 28, 2018 6:37 PM, Simon Ser wrote:
>
>This is a RFC to be able to run tests and check that this approach
>
On 2017-12-14 05:40 AM, Pekka Paalanen wrote:
From: Pekka Paalanen
Heads may be disconnected or connected and the compositor needs to be
able to know the state to know which heads to take into use.
Currently a single head is automatically created with an output, and
outputs are only ever creat
On 2018-02-02 03:45 AM, Pekka Paalanen wrote:
On Thu, 1 Feb 2018 22:10:33 +
Daniel Stone wrote:
Hi,
On 1 February 2018 at 22:00, Derek Foreman wrote:
On 2017-12-14 05:40 AM, Pekka Paalanen wrote:
The 'head' member of 'struct weston_output' is going to go unused and
then disappear, so s
On 2018-02-02 02:06 AM, Pekka Paalanen wrote:
On Thu, 1 Feb 2018 13:59:24 -0600
Derek Foreman wrote:
On 2017-12-14 05:40 AM, Pekka Paalanen wrote:
From: Pekka Paalanen
In order to support clone modes, libweston needs the concept of a head
that is separate from weston_output. While weston_ou
On 2018-02-02 02:32 AM, Pekka Paalanen wrote:
On Thu, 1 Feb 2018 15:36:55 -0600
Derek Foreman wrote:
On 2017-12-14 05:40 AM, Pekka Paalanen wrote:
From: Pekka Paalanen
The intention is that in the future backends will dynamically allocate
weston_heads based on the resources they have. The l
On Thu, 1 Feb 2018 22:10:33 +
Daniel Stone wrote:
> Hi,
>
> On 1 February 2018 at 22:00, Derek Foreman wrote:
> > On 2017-12-14 05:40 AM, Pekka Paalanen wrote:
> >> The 'head' member of 'struct weston_output' is going to go unused and
> >> then disappear, so stop using it and find a head
On Thu, 1 Feb 2018 15:36:55 -0600
Derek Foreman wrote:
> On 2017-12-14 05:40 AM, Pekka Paalanen wrote:
> > From: Pekka Paalanen
> >
> > The intention is that in the future backends will dynamically allocate
> > weston_heads based on the resources they have. The lifetime of a
> > weston_head wil
On Thu, 1 Feb 2018 14:14:35 -0600
Derek Foreman wrote:
> On 2017-12-14 05:40 AM, Pekka Paalanen wrote:
> > From: Pekka Paalanen
> >
> > Split out a new function. This is a pure refactoring, no change in
> > behaviour.
> >
> > This helps a following patch that adds a loop over output->head_list
On Thu, 1 Feb 2018 13:59:24 -0600
Derek Foreman wrote:
> On 2017-12-14 05:40 AM, Pekka Paalanen wrote:
> > From: Pekka Paalanen
> >
> > In order to support clone modes, libweston needs the concept of a head
> > that is separate from weston_output. While weston_output manages buffers
> > and the
13 matches
Mail list logo
