Already considered and handled as such.
Signed-off-by: Emil Velikov
---
libweston/launcher-direct.c| 2 +-
libweston/launcher-impl.h | 8
libweston/launcher-logind.c| 2 +-
libweston/launcher-util.c | 6 +++---
libweston/launcher-weston-launch.c | 2 +-
Makes the code easier to read and browse through.
Signed-off-by: Emil Velikov
---
libweston/launcher-direct.c| 14 +++---
libweston/launcher-logind.c| 14 +++---
libweston/launcher-weston-launch.c | 14 +++---
3 files changed, 21 insertions(+), 21 deletion
Hi Daniel,
Not a huge expert on this code, so take the following with a grain of salt.
On 10 February 2017 at 17:43, Daniel Stone wrote:
> Given that we can have render-only devices, or vgem in a class of its
> own, ignore any non-KMS devices in compositor-drm's device selection.
> For x86 platf
I remember facing similar marshalling issues when writing my bindings. The
thing is that the wire args do not always match the literal protocol args,
especially when creating a new object iirc. If it might be of any help, you
can always take a look at wayland-java-bindings on github to get an idea
Hi
Thanks for your hints.
Here is what I get with WAYLAND_DEBUG=1:
from client:
[3998325.807] -> wl_display@1.get_registry(new id wl_registry@2)
[3998325.834] -> wl_disp...@1.sync(new id wl_callback@3)
message too short, object (2), message error(ous)
from server:
[3998325.858] wl_display@1.g
Given that we can have render-only devices, or vgem in a class of its
own, ignore any non-KMS devices in compositor-drm's device selection.
For x86 platforms, this is mostly a non-issue since we look at the udev
boot_vga issue, but other architectures which lack this, and have
multiple KMS devices
Expose to the DMABUF protocol the pixel formats already explicitly
supported as fallback by gl-renderer in import_yuv_dmabuf function plus
the standard RGB formats that all GPU supports:
ARGB, XRGB, RGB565, YUYV, NV12, YUV420 and YUV444.
Signed-off-by: Vincent Abriou
---
v2:
- Remove dep
On 07/02/2017 20:51, Matthias Treydte wrote:
I already brought this up on IRC before and finally started to work
on it. The goal is to give an Wayland client some identifier which
allows it to recognize the physical connector which corresponds to
some Wayland output.
The rationale why such an
Hi,
Series looks good, but patch 1/2 introduces
tp_is_tpkb_combo_below() and patch 2/2 then moves it around
to avoid doing a forward declaration, it would be better IMHO
if patch 1/2 simply defined it in the place where 2/2 puts it.
With that fixed:
Reviewed-by: Hans de Goede
Regards,
Hans
Hi,
On 09-02-17 23:55, Peter Hutterer wrote:
On Thu, Feb 09, 2017 at 05:25:36PM +0100, Hans de Goede wrote:
Hi,
First of all patches 1-9 and 11 looks good to me and are:
Reviewed-by: Hans de Goede
thx, fwiw, I already pushed these, so fixups will come as a separate patch.
I've some remar
On Tue, 07 Feb 2017 20:51:32 +0100
Matthias Treydte wrote:
> I already brought this up on IRC before and finally started to work on
> it. The goal is to give an Wayland client some identifier which allows
> it to recognize the physical connector which corresponds to some Wayland
> output.
Hi,
On Thu, 9 Feb 2017 08:07:37 +0100
Rémi Thébault wrote:
> 2017-02-09 7:56 GMT+01:00 Rémi Thébault :
>
> > Hello,
> >
> > I've started to build new bindings to Wayland for the D programming
> > language.
> > Available at github.com/rtbo/wayland-d. Only client protocol supported at
> > the moment.
From: Varad Gautam
provide a mechanism that allows clients to import the added dmabufs
and immediately use the newly created wl_buffers without waiting on
an event. this is useful to clients that are sure of their import
request succeeding, and wish to avoid the wl_buffer communication
roundtrip.
13 matches
Mail list logo
