Add the possibility for the compositor backend to provide with the list
of supported pixel formats for dmabuf-based buffers.
This information is used by linux_dmabuf to inform clients when binding.
Signed-off-by: Fabien Dessenne
---
src/compositor.h | 2 ++
src/linux-dmabuf.c | 16
Hi,
> -Original Message-
> From: Daniel Stone [mailto:dan...@fooishbar.org]
> Sent: vendredi 30 octobre 2015 09:31
> To: Bryce Harrington
> Cc: Fabien DESSENNE; Giulio Camuffo; Vincent ABRIOU; Benjamin Gaignard;
> wayland-devel@lists.freedesktop.org
> Subject: Re
Hi,
> -Original Message-
> From: Daniel Stone [mailto:dan...@fooishbar.org]
> Sent: lundi 2 novembre 2015 12:44
> To: Fabien DESSENNE
> Cc: Bryce Harrington; Giulio Camuffo; Vincent ABRIOU; Benjamin Gaignard;
> wayland-devel@lists.freedesktop.org
> Subject: Re
> > Date: Thu, 26 Nov 2015 10:40:20 +0200
> > From: ppaala...@gmail.com
> > To: rdp.eff...@gmail.com; mikeyj...@hotmail.com
> > CC: wayland-devel@lists.freedesktop.org; dan...@fooishbar.org
> > Subject: Re: Process for implementing a double buffer on Wayland
> >
> > On Wed, 25 Nov 2015 21:43
Hi Daniel,
On 11/16/2016 03:25 PM, Daniel Stone wrote:
> Instead of setting state members directly in the drm_output_render
> functions (to paint using Pixman or GL), just return a drm_fb, and let
> the core function place it in state.
>
> Signed-off-by: Daniel Stone
>
> Differential Revision: h
Hi Daniel
On 11/16/2016 03:25 PM, Daniel Stone wrote:
> Currently this doesn't actually really do anything, but will be used in
> the future to track the state for both modeset and repaint requests.
> Completion of the request gives us a single request-completion path for
> both pageflip and vbl
Hi Daniel
Below are two remarks regarding (m/z/c)alloc.
By the way, as a general remark (and maybe a personal opinion) zalloc(x)
is a bit more readable than calloc(1,x)
On 11/16/2016 03:25 PM, Daniel Stone wrote:
> Track dynamic plane state (CRTC, FB, position) in separate structures,
> rathe
On 08/12/16 13:58, Daniel Stone wrote:
> Hi Fabien,
>
> On 21 November 2016 at 14:58, Fabien DESSENNE wrote:
>> On 11/16/2016 03:25 PM, Daniel Stone wrote:
>>> +/**
>>> + * Mark a drm_output_state (the output's last state) as complete. This
>>> h
As an option, allow to specify a mode (from the configuration file) by
its refresh rate.
Example of valid syntax:
- "mode=1920x1080"Select a 1920x1080 mode, refresh rate undefined.
- "mode=1920x1080-60" Select the (or one of the) 1920x1080 60 Hz mode.
Signed-off
As an option, allow to specify a mode (from the configuration file) by
its refresh rate.
Example of valid syntax:
- "mode=1920x1080"Select a 1920x1080 mode, refresh rate undefined.
- "mode=1920x1080@60" Select the (or one of the) 1920x1080 60 Hz mode.
Signed-off-by: Fabie
Hi Daniel
On 09/12/16 20:58, Daniel Stone wrote:
> Generate an output state in two stages. Firstly, attempt to run through
> and generate a configuration with all views in planes. If this succeeds,
> we can bypass the renderer completely.
>
> If this fails, we know we need to have the renderer ou
Hi
I remember I used to get < weston-simple-egl -f > working fine.
But it does not work anymore : nothing is displayed. From the logs I can see
(among others) zxdg_toplevel_v6.configure and wl_surface.commit
Testing with another client works fine: weston-terminal -f -> OK
There may be something w
nal Message-
>From: Daniel Stone [mailto:dan...@fooishbar.org]
>Sent: mardi 28 février 2017 00:18
>To: Arnaud Vrac
>Cc: Fabien DESSENNE ; wayland-
>de...@lists.freedesktop.org
>Subject: Re: weston-simple-egl fullscreen broken?
>
>Hi Arnaud,
>
>On 27 February
Hi all,
It looks like the great work proposed by Daniel to have Atomic Modesetting in
Weston did not find the success it deserves.
We tested it successfully on STMicroelectronics boards and it works great.
The kernel DRM framework has been reworked in the past months (years) in order
to support
Emit frame_signal at the end of the GL renderer processing, so the
frame_signal clients are informed after the buffer is actually updated.
Signed-off-by: Fabien Dessenne
---
libweston/gl-renderer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libweston/gl-renderer.c b
On 08/16/2016 10:18 AM, Pekka Paalanen wrote:
> On Fri, 12 Aug 2016 14:11:40 +0200
> Fabien Dessenne wrote:
>
>> Emit frame_signal at the end of the GL renderer processing, so the
>> frame_signal clients are informed after the buffer is actually updated.
>>
>&g
On 08/17/2016 09:42 AM, Pekka Paalanen wrote:
> On Tue, 16 Aug 2016 14:46:23 +0200
> Fabien DESSENNE wrote:
>
>> On 08/16/2016 10:18 AM, Pekka Paalanen wrote:
>>> On Fri, 12 Aug 2016 14:11:40 +0200
>>> Fabien Dessenne wrote:
>>>
>>&g
On 09/30/2016 08:49 PM, Derek Foreman wrote:
> On 30/09/16 04:28 AM, Tomohito Esaki wrote:
>> Multiplanar formats are supported by using drmModeAddFB2 and bypassing
>> gbm. If drmModeAddFB2 isn't available, the existing gbm bo import path
>> is used and multiplanar formats are unsupported.
> I'm n
Hi
Thank you for the patch. Please, find some minor comments below.
On 09/30/2016 11:28 AM, Tomohito Esaki wrote:
> This implementations bypasses gbm and passes the dmabuf handles directly
> to libdrm for composition.
Maybe you can split the patch in two parts:
- one part dealing with drm_fb_c
Hi,
Please find below a comment.
Fabien
On 09/30/2016 11:28 AM, Tomohito Esaki wrote:
> Multiplanar formats are supported by using drmModeAddFB2 and bypassing
> gbm. If drmModeAddFB2 isn't available, the existing gbm bo import path
> is used and multiplanar formats are unsupported.
>
> Signed
video mode (the best one of the
list, which is the first) from the ones provided by the driver.
Signed-off-by: Fabien Dessenne
---
src/compositor-drm.c |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/src/compositor-drm.c b/src/compositor-drm.c
index fbf6e49..54caaa9 100644
> From: Bryce W. Harrington [mailto:b.harring...@samsung.com]
> Sent: mardi 17 décembre 2013 03:26
> To: Fabien DESSENNE
> Cc: wayland-devel@lists.freedesktop.org; Benjamin Gaignard
> Subject: Re: [PATCH] compositor-drm: consider the best mode of the
> mode_list as an option
&
What is the next step to get this patch merged ?
I am asking because I am a new contributor and I am not really aware of the
acceptance / merge process.
Fabien
> -Original Message-
> From: Fabien DESSENNE
> Sent: mardi 17 décembre 2013 10:01
> To: 'Bryce W. Harringt
23 matches
Mail list logo
