[PATCH v2 libinput] tools: print errors as red, info as highlighted

makes it easier to filter out debugging messages Signed-off-by: Peter Hutterer --- Sorry, used the wrong patch, v1 was an earlier version. tools/shared.c | 18 ++ 1 file changed, 18 insertions(+) diff --git a/tools/shared.c b/tools/shared.c index 1019184..81608c0 100644 --- a/t

[PATCH libinput] tools: print errors as highlighted

Signed-off-by: Peter Hutterer --- tools/shared.c | 13 + 1 file changed, 13 insertions(+) diff --git a/tools/shared.c b/tools/shared.c index 1019184..b976633 100644 --- a/tools/shared.c +++ b/tools/shared.c @@ -72,7 +72,20 @@ log_handler(struct libinput *li, const char *f

Re: [PATCH weston v4] compositor-drm: Ignore non-KMS devices

On 13 February 2017 at 18:57, Daniel Stone wrote: > /* > * Find primary GPU > * Some systems may have multiple DRM devices attached to a single seat. This Completely forgot: we want to update the comment above the function. > + /* Make sure this device is actually capable of m

Re: [PATCH weston 2/2] libweston/launcher: use C99 initializers for the iface(s)

Hi Emil, On 10 February 2017 at 20:14, Emil Velikov wrote: > Makes the code easier to read and browse through. Thanks, these both seem trivially correct; I'll push them whenever the tree reopens. Cheers, Daniel ___ wayland-devel mailing list wayland-d

Re: [PATCH weston v2] (multiple): Use standard permission notice

Hi Yong, On 23 January 2017 at 14:17, Yong Bakos wrote: > From: Yong Bakos > > A handful of source files were not using the MIT Expat text in > COPYING. Update these files to bring them inline with the rest, > standardizing on the MIT Expat text. Something weird with the patch, but hand-applyin

[PATCH weston] Update COPYING

Include a list of every copyright statement within the COPYING file. Signed-off-by: Daniel Stone --- COPYING | 37 - 1 file changed, 32 insertions(+), 5 deletions(-) diff --git a/COPYING b/COPYING index faefd8f..418b4b4 100644 --- a/COPYING +++ b/COPYING @@ -

Re: [PATCH 1/2] libbacklight: Fix backlight detection on recent kernels

Hi Armin, On 8 February 2017 at 12:55, Armin Krezović wrote: > I don't know when it started happening, but recent kernels > give different names for pci_device and backlight parent. > > pci_device is tied to the GPU PCI ID, while backlight parent > is tied to the connector, rather than the GPU it

Re: [PATCH 2/2] compositor-drm: Mark eDP connection as internal

Hi Armin, On 8 February 2017 at 12:55, Armin Krezović wrote: > Signed-off-by: Armin Krezović I've pushed this one as trivially correct, thanks: To ssh://git.freedesktop.org/git/wayland/weston e6b7136..9bcf4c5 push -> master Cheers, Daniel ___ way

Re: [PATCH weston v2] xwm: Add icon support to the frame

Hi Emmanuel, On 8 December 2016 at 01:55, Emmanuel Gil Peyrot wrote: > @@ -1146,6 +1150,48 @@ weston_wm_window_schedule_repaint(struct > weston_wm_window *window) > } > > static void > +weston_wm_handle_icon(struct weston_wm *wm, struct weston_wm_window *window) > +{ > + xcb_get_property

[PATCH weston v4] compositor-drm: Ignore non-KMS devices

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

Re: [PATCH v3 weston] compositor-drm: Ignore non-KMS devices

Hi Emil, Thanks for the review! On 10 February 2017 at 19:51, Emil Velikov wrote: > On 10 February 2017 at 17:43, Daniel Stone wrote: >> +static bool >> +drm_device_is_kms(struct drm_backend *b, struct udev_device *device) >> +{ >> + [...] >> + >> + b->drm.fd = fd; >> + b->drm.

Re: [PATCH weston 01/68] libweston: Add pixel-format helpers

Hi, On 14 December 2016 at 15:59, Pekka Paalanen wrote: > On Fri, 9 Dec 2016 19:57:16 + > Daniel Stone wrote: >> + { >> + .format = DRM_FORMAT_RGBX, >> + .gl_format = GL_RGBA, >> + .gl_type = GL_UNSIGNED_SHORT_4_4_4_4, > > Could there be any conce

[PATCH wayland] protocol: Clarify the meaning of NULL buffer attachment

This documents what has apparently been the case for ages - attaching a NULL buffer does *not* always remove the surface content, rather it has behaviour determined by the surface role (which may be documented elsewhere). Signed-off-by: Derek Foreman --- protocol/wayland.xml | 13 +++--