libwayland-egl.so missing 'wl_drm_interface'

Hi, I ran into a link error when trying to compile the demos repository according to the instructions on the Building page: CCLD compositor libwayland-egl.so: undefined reference to `wl_drm_interface' make[3]: *** [compositor] Error 1 All of the packages are freshly compiled from Git

Re: weston sometime fails to start using systemd unit file

Hi; I think that you might rather have more success if you just instruct your weston.service unit file that Weston isn't allowed to start until the DRI device appears. E.g., [Unit] ... Requires=dev-dri-card0.device # or dev-drm-card0.device as appropriate for your board

Re: weston: recommendations for implementing splashscreen in a custom shell?

On Fri, Jan 13, 2017 at 5:50 AM, Daniel Stone wrote: > I'd be 100% in favour of this approach: delaying the original modesets > until the shell indicates that the scene graph as it stands is totally > quiescent. I'm working along those lines as we speak for atomic > anyway:

weston: recommendations for implementing splashscreen in a custom shell?

Hi, I maintain a small Weston shell plugin for an an embedded use-case. On the embedded device, the bootloader first paints a buffer and installs it as the scanout buffer to the graphics hardware. At some point, userspace has to take over responsibility for painting that background image. It

Re: [PATCH] libweston-desktop: add signals for title, app_id

Hi, Any further consensus on this? On Tue, Jul 25, 2017 at 8:07 AM, Matt Hoosier <matt.hoos...@gmail.com> wrote: > On Tue, Jul 25, 2017 at 7:26 AM, Jonas Ådahl <jad...@gmail.com> wrote: > >> On Tue, Jul 25, 2017 at 06:42:34AM -0600, Matt Hoosier wrote: >> > I'd

Make DRM plane-assignment algorithm tolerant of more than one fullscreen opaque surface?

Currently the DRM backend ends up picking the bottom-most view which meets all the checks for eligibility, for direct scanout usage. If more than one such view exists, we get a visual result counter to expectations -- it should be the highest-sorted such view that the user sees. The big loop in

Re: Linux: Smooth splashscreen with system having weston with drm-backend

On Fri, Jul 14, 2017 at 8:56 AM, Daniel Vetter wrote: > On Fri, Jul 14, 2017 at 03:07:11PM +0530, Vikas Patil wrote: > > On Thu, Jul 13, 2017 at 7:20 PM, Daniel Vetter > wrote: > > > On Thu, Jul 13, 2017 at 3:33 PM, Vikas Patil >

libweston-desktop: publish changes to title-changed and app-id-changed?

I'm finding that it would be useful for shells implemented against libweston-desktop to be able to know when the application's title or app-id changes. Right now, that information is swallowed up inside the internal logic. Would a patch exporting changes to title or app_id be welcome? If so, do

[PATCH] libweston-desktop: add signals for title, app_id

-off-by: Matt Hoosier <matt.hoos...@gmail.com> --- libweston-desktop/libweston-desktop.h | 6 ++ libweston-desktop/surface.c | 21 + 2 files changed, 27 insertions(+) diff --git a/libweston-desktop/libweston-desktop.h b/libweston-desktop/libweston-des

Re: [PATCH] libweston-desktop: add signals for title, app_id

the app happens to post a buffer next. On Tue, Jul 25, 2017 at 12:17 AM, Jonas Ådahl <jad...@gmail.com> wrote: > On Fri, Jul 21, 2017 at 05:21:38PM +0200, Quentin Glidic wrote: > > On 7/20/17 4:33 PM, Matt Hoosier wrote: > > > It's useful for the shell implementation t

Re: [PATCH] libweston-desktop: add signals for title, app_id

On Tue, Jul 25, 2017 at 7:26 AM, Jonas Ådahl <jad...@gmail.com> wrote: > On Tue, Jul 25, 2017 at 06:42:34AM -0600, Matt Hoosier wrote: > > I'd find it a little bit inconvenient for the title, class, and app-id to > > be treated as buffered state. They make a

Re: [PATCH] libweston-desktop: add signals for title, app_id

On Fri, Jul 21, 2017 at 10:21 AM, Quentin Glidic < sardemff7+wayl...@sardemff7.net> wrote: > On 7/20/17 4:33 PM, Matt Hoosier wrote: > >> It's useful for the shell implementation to know when these change, >> for example to relay the information on to taskbars or similar.

Re: [PATCH] libweston-desktop: add signal title/app-id changes

Okay, this one should be ready to review. Sorry for the noise on the first attempt. On Tue, Aug 8, 2017 at 10:56 AM, Matt Hoosier <matt.hoos...@gmail.com> wrote: > It's useful for the shell implementation to know when these change, > for example to relay the information on to taskbar

Re: [PATCH] libweston-desktop: add signals for title, app_id

On Sun, Aug 6, 2017 at 11:11 PM, Jonas Ådahl <jad...@gmail.com> wrote: > On Tue, Jul 25, 2017 at 08:07:01AM -0600, Matt Hoosier wrote: > > On Tue, Jul 25, 2017 at 7:26 AM, Jonas Ådahl <jad...@gmail.com> wrote: > > > > > On Tue, Jul 25, 2017 at 06:42:34AM -0

[PATCH] libweston-desktop: add signal title/app-id changes

-off-by: Matt Hoosier <matt.hoos...@gmail.com> --- libweston-desktop/libweston-desktop.h | 6 ++ libweston-desktop/surface.c | 21 + 2 files changed, 27 insertions(+) diff --git a/libweston-desktop/libweston-desktop.h b/libweston-desktop/libweston-des

Re: [PATCH] libweston-desktop: add signals for title, app_id

Okay. I'll revise to make the changes Quentin asked for and resubmit. On Tue, Aug 8, 2017 at 9:41 AM, Jonas Ådahl <jad...@gmail.com> wrote: > On Tue, Aug 08, 2017 at 09:13:42AM -0500, Matt Hoosier wrote: > > On Sun, Aug 6, 2017 at 11:11 PM, Jonas Ådahl <jad...@gmail.com>

[PATCH] libweston-desktop: add signal title/app-id changes

-off-by: Matt Hoosier <matt.hoos...@gmail.com> --- libweston-desktop/libweston-desktop.h | 3 +++ libweston-desktop/surface.c | 12 2 files changed, 15 insertions(+) diff --git a/libweston-desktop/libweston-desktop.h b/libweston-desktop/libweston-desktop.h index 03

Re: [PATCH] libweston-desktop: add signal title/app-id changes

This revision was broken. Disregard, I'm re-sending. On Tue, Aug 8, 2017 at 10:45 AM, Matt Hoosier <matt.hoos...@gmail.com> wrote: > It's useful for the shell implementation to know when these change, > for example to relay the information on to taskbars or similar. > > To

Re: [PATCH wayland-protocols] Add zwp_linux_explicit_synchronization_v1

On Fri, Sep 22, 2017 at 10:24 AM, Pekka Paalanen <ppaala...@gmail.com> wrote: > On Wed, 20 Sep 2017 07:11:57 -0700 > Daniel Stone <dan...@fooishbar.org> wrote: > >> Hi Matt, >> >> On 20 September 2017 at 05:48, Matt Hoosier <matt.hoos...@g

Re: [PATCH wayland-protocols] Add zwp_linux_explicit_synchronization_v1

On Tue, Sep 19, 2017 at 6:46 PM, Daniel Stone wrote: > Signed-off-by: Daniel Stone > --- > Makefile.am| 1 + > unstable/linux-explicit-synchronization/README | 5 + >

Ideas on portable APIs to cheaply copy a GBM bo?

Hi all, My organization maintains a small patch against the DRM compositor that causes it to register another output. This output accepts the usual compositor scenegraph, does the rendering down to a primary plane, and then funnels the resulting GBM buffer through a codepath that does video

[PATCH] compositor: fix starvation of wl_buffer::release

. Signed-off-by: Matt Hoosier <matt.hoos...@gmail.com> --- clients/nested.c | 3 +-- libweston/compositor.c | 3 +-- 2 files changed, 2 insertions(+), 4 deletions(-) diff --git a/clients/nested.c b/clients/nested.c index e9070e9b..e2bdf684 100644 --- a/clients/nested.c +++ b/clients/ne

Re: [PATCH] compositor: fix starvation of wl_buffer::release

Done: https://lists.freedesktop.org/archives/wayland-devel/2017-September/035191.html On Tue, Sep 26, 2017 at 2:28 AM, Pekka Paalanen <ppaala...@gmail.com> wrote: > On Mon, 25 Sep 2017 10:31:35 -0500 > Matt Hoosier <matt.hoos...@gmail.com> wrote: > >> This change

[PATCH v2] compositor: fix starvation of wl_buffer::release

. v2: More information about the historical reasons why this change hadn't happened yet, and the consensus to finally move ahead with it can be found at the discussion terminating in this message: https://lists.freedesktop.org/archives/wayland-devel/2017-September/035147.html Signed-off-by: Matt

[PATCH] compositor-drm: fix z-order inversion in plane assignment

As discussed in the following thread: https://lists.freedesktop.org/archives/wayland-devel/2017-August/034755.html the existing plane assignment in the DRM backend is vulnerable to accidental masking of the intended fullscreen surface. This change adds a simple stateful memory to the plane

Re: [RFC] compositor-drm: name outputs according to connectors if EDID is unavailable

On Thu, Aug 24, 2017 at 2:49 AM, Pekka Paalanen wrote: > Hi, > > using connector name to describe the connected monitor doesn't sound > right to me. I didn't really like it either. Thanks for the suggestions below. > > If you actually need the connector name in clients then

Re: Make DRM plane-assignment algorithm tolerant of more than one fullscreen opaque surface?

On Tue, Aug 15, 2017 at 9:16 AM, Daniel Stone wrote: > > No, that's all the way broken. I assume the only way this hasn't yet > bitten us is that the background in stock desktop-shell is a SHM-only > client, so won't get promoted to a plane. > > That should be fixed in the

[RFC] compositor-drm: name outputs according to connectors if EDID is unavailable

On embedded systems, EDID is typically unavailble for connectors on buses such as LVDS or DSI. This change enhances the original opportunistic naming done in 2b2092adb499d8cdc10390cf19876706bcfe69cb to report the make and model of an output according to the KMS connector (e.g., "DSI-1") if no

Re: [PATCH] compositor-drm: fix z-order inversion in plane assignment

On Thu, Aug 24, 2017 at 9:24 AM, Matt Hoosier <matt.hoos...@gmail.com> wrote: > As discussed in the following thread: > > https://lists.freedesktop.org/archives/wayland-devel/2017-August/034755.html > > the existing plane assignment in the DRM backend is vulnerable to

[PATCH v2] libweston-desktop: add signal for title/app-id changes

definition public, new functions are introduced for attaching listeners to these signals. Signed-off-by: Matt Hoosier <matt.hoos...@gmail.com> --- libweston-desktop/libweston-desktop.h | 3 +++ libweston-desktop/surface.c | 12 2 files changed, 15 insertions(+) diff

Re: [PATCH] compositor-drm: fix z-order inversion in plane assignment

On Tue, Sep 5, 2017 at 9:00 AM, Daniel Stone wrote: > It can't be correct to raise it to the cursor plane either, since both > cursor and overlay planes strictly stack above the scanout plane. I > guess this would read a lot easier with: > if (picked_scanout) >

Re: Ideas on portable APIs to cheaply copy a GBM bo?

On Tue, Oct 10, 2017 at 11:53 AM, Daniel Stone wrote: > That more or less makes sense at the moment, though there has been > quite a bit of work on less insane remoting within Weston. And then > GNOME is using PipeWire for this. But anyway, you probably know this > and it's

Re: [PATCH weston v12 00/40] Atomic modesetting

On Tue, Sep 26, 2017 at 12:15 PM, Daniel Stone wrote: > Hi, > Here's a cleaned-up and fully-tested version of the atomic series. Hi; Just wondering: do you maintain these in a publicly fetchable repo somewhere? I didn't turn up anything after some light searching --

Re: [PATCH wayland] cursor: Use shm_open() instead of XDG_RUNTIME_DIR files

On Wed, Oct 18, 2017 at 4:23 AM, Quentin Glidic wrote: > + fd = shm_open("/wayland-cursor-shared", O_CREAT | O_RDWR, 0); > + shm_unlink("/wayland-cursor-shared"); This seems to be a departure from the anonymous behavior that mkstemp() previously

Automatically choosing a VT for DRM compositor?

It would be nice for non-session uses of Weston (embedded systems) if the controlling TTY didn't need to be manually supplied. Has anybody suggested using something like VT_OPENQRY in the weston-launcher code to pick a TTY if one wasn't manually given? (Or if that's too auto-magic for taste here,

Re: [PATCH v2] libweston-desktop: add signal for title/app-id changes

Ping On Tue, Sep 5, 2017 at 8:05 AM, Matt Hoosier <matt.hoos...@gmail.com> wrote: > As discussed on > https://lists.freedesktop.org/archives/wayland-devel/2017-August/034720.html, > it's useful for the shell implementation to know when these change, > for example to rel

Contact for freenode #wayland adminstration questions?

I'm having some trouble joining the Wayland channel on Freenode. Is there a specific person to contact about that? ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH v4 wayland] client: Allow absolute paths in WAYLAND_DISPLAY

From: Matt Hoosier <matt.hoos...@garmin.com> In order to support system compositor instances, it is necessary to allow clients' wl_display_connect() to find the compositor's listening socket somewhere outside of XDG_RUNTIME_DIR. For a full account, see the discussion beginning here:

Re: [PATCH v3 wayland] client: Allow absolute paths in WAYLAND_DISPLAY

On Mon, Nov 27, 2017 at 3:16 AM, Pekka Paalanen <ppaala...@gmail.com> wrote: > On Sat, 25 Nov 2017 08:11:43 -0600 > Matt Hoosier <matt.hoos...@gmail.com> wrote: > >> Hi Jonas, Pekka, >> >> I have no objection to making the tweaks that Jonas mentions, b

Re: Hide surface

On Sun, Nov 26, 2017 at 2:23 PM, ferreiradaselva wrote: > Hi, > > My first time posting here (sorry if I'm posting on the wrong place). You're in the right place. Welcome! > > I'm working on this window creation framework >

Re: [PATCH v3 wayland] client: Allow absolute paths in WAYLAND_DISPLAY

, Jonas Ådahl <jad...@gmail.com> wrote: > On Tue, Nov 14, 2017 at 12:23:55PM -0600, Matt Hoosier wrote: >> From: Matt Hoosier <matt.hoos...@garmin.com> >> >> In order to support system compositor instances, it is necessary to >> allow clients' wl_display_conne

Re: [PATCH v3 wayland] client: Allow absolute paths in WAYLAND_DISPLAY

Hi Jonas (and Pekka), How well does v4 address your requests? -Matt On Mon, Nov 27, 2017 at 9:00 AM, Matt Hoosier <matt.hoos...@gmail.com> wrote: > On Mon, Nov 27, 2017 at 3:16 AM, Pekka Paalanen <ppaala...@gmail.com> wrote: >> On Sat, 25 Nov 2017 08:11:43 -0600 >&

Re: [PATCH v4 wayland] client: Allow absolute paths in WAYLAND_DISPLAY

On Mon, Dec 11, 2017 at 2:03 AM, Pekka Paalanen <ppaala...@gmail.com> wrote: > On Mon, 27 Nov 2017 08:54:54 -0600 > Matt Hoosier <matt.hoos...@gmail.com> wrote: > >> From: Matt Hoosier <matt.hoos...@garmin.com> >> >> In order to support system comp

Re: [PATCH v3 wayland] client: Allow absolute paths in WAYLAND_DISPLAY

On Fri, Nov 17, 2017 at 2:22 AM, Pekka Paalanen <ppaala...@gmail.com> wrote: > On Tue, 14 Nov 2017 12:23:55 -0600 > Matt Hoosier <matt.hoos...@gmail.com> wrote: > >> From: Matt Hoosier <matt.hoos...@garmin.com> >> >> In order to support system comp

Re: [PATCH wayland] client: Allow absolute paths in WAYLAND_DISPLAY

Hi, On Fri, Nov 10, 2017 at 5:37 AM, Pekka Paalanen <ppaala...@gmail.com> wrote: > On Thu, 9 Nov 2017 09:36:29 -0600 > Matt Hoosier <matt.hoos...@gmail.com> wrote: > >> From: Matt Hoosier <matt.hoos...@garmin.com> >> >> In order to support system comp

[PATCH v2 wayland] client: Allow absolute paths in WAYLAND_DISPLAY

From: Matt Hoosier <matt.hoos...@garmin.com> In order to support system compositor instances, it is necessary to allow clients' wl_display_connect() to find the compositor's listening socket somewhere outside of XDG_RUNTIME_DIR. For a full account, see the discussion beginning here:

Re: [PATCH wayland] client: Allow absolute paths in WAYLAND_DISPLAY

On Thu, Nov 9, 2017 at 8:53 PM, Jonas Ådahl <jad...@gmail.com> wrote: > On Thu, Nov 09, 2017 at 09:36:29AM -0600, Matt Hoosier wrote: >> From: Matt Hoosier <matt.hoos...@garmin.com> >> >> In order to support system compositor instances, it is necessary to >

Re: [PATCH v2 wayland] client: Allow absolute paths in WAYLAND_DISPLAY

On Tue, Nov 14, 2017 at 8:22 AM, Pekka Paalanen <ppaala...@gmail.com> wrote: > On Fri, 10 Nov 2017 11:20:42 -0600 > Matt Hoosier <matt.hoos...@gmail.com> wrote: > >> From: Matt Hoosier <matt.hoos...@garmin.com> >> >> In order to support system comp

Re: [PATCH v2 wayland] client: Allow absolute paths in WAYLAND_DISPLAY

On Tue, Nov 14, 2017 at 8:25 AM, Matt Hoosier <matt.hoos...@gmail.com> wrote: > On Tue, Nov 14, 2017 at 8:22 AM, Pekka Paalanen <ppaala...@gmail.com> wrote: >> On Fri, 10 Nov 2017 11:20:42 -0600 >> Matt Hoosier <matt.hoos...@gmail.com> wrote: >> >>

[PATCH v3 wayland] client: Allow absolute paths in WAYLAND_DISPLAY

From: Matt Hoosier <matt.hoos...@garmin.com> In order to support system compositor instances, it is necessary to allow clients' wl_display_connect() to find the compositor's listening socket somewhere outside of XDG_RUNTIME_DIR. For a full account, see the discussion beginning here:

Re: [PATCH v2 wayland] client: Allow absolute paths in WAYLAND_DISPLAY

On Tue, Nov 14, 2017 at 8:22 AM, Pekka Paalanen <ppaala...@gmail.com> wrote: > On Fri, 10 Nov 2017 11:20:42 -0600 > Matt Hoosier <matt.hoos...@gmail.com> wrote: > >> From: Matt Hoosier <matt.hoos...@garmin.com> >> >> In order to support system comp

Re: New paths for Wayland sockets (Re: Enabling Android-style per application user ids)

On Fri, Nov 3, 2017 at 2:33 AM, Pekka Paalanen <ppaala...@gmail.com> wrote: > On Thu, 2 Nov 2017 10:07:28 -0500 > Matt Hoosier <matt.hoos...@gmail.com> wrote: > > > On Thu, Nov 2, 2017 at 3:36 AM, Pekka Paalanen <ppaala...@gmail.com> > wrote: > > > >

Re: [PATCH weston v12 00/40] Atomic modesetting

On Fri, Nov 3, 2017 at 2:46 AM, Pekka Paalanen <ppaala...@gmail.com> wrote: > > On Thu, 2 Nov 2017 14:13:42 -0500 > Matt Hoosier <matt.hoos...@gmail.com> wrote: > > > What sort of testing on this series would be most helpful? I figure that > > you and pq have

Re: [PATCH weston v12 27/40] compositor-drm: Add modifiers to GBM dmabuf import

On Tue, Sep 26, 2017 at 12:16 PM, Daniel Stone wrote: > Add support for the GBM_BO_IMPORT_FD_MODIFIER path, which allows us to > import multi-plane dmabufs, as well as format modifiers. > > Signed-off-by: Daniel Stone > --- > configure.ac

Re: [PATCH weston v12 00/40] Atomic modesetting

What sort of testing on this series would be most helpful? I figure that you and pq have most of the code review covered, so the main contribution I can make with the hardware available to me is to exercise this on consumer-grade systems like Macbooks with Intel display controllers. Are there are

Re: [PATCH weston 00/14] Desktop Protocol Support for IVI-Shell

On Tue, Nov 7, 2017 at 11:58 AM, Quentin Glidic <sardemff7+wayl...@sardemff7.net> wrote: > On 11/7/17 6:01 PM, Matt Hoosier wrote: >> >> Hi Pekka, >> >> On Wed, Oct 25, 2017 at 10:09 AM, Ucan, Emre (ADITG/ESB) >> <eu...@de.adit-jv.com> wrote: >

Re: New paths for Wayland sockets (Re: Enabling Android-style per application user ids)

On Wed, Nov 8, 2017 at 2:16 AM, Pekka Paalanen wrote: > On Tue, 7 Nov 2017 19:42:42 + > Daniel Stone wrote: > >> Hi, >> >> On 3 November 2017 at 07:33, Pekka Paalanen wrote: > >> > - when the current socket search fails, add

[PATCH wayland] client: Allow absolute paths in WAYLAND_DISPLAY

From: Matt Hoosier <matt.hoos...@garmin.com> In order to support system compositor instances, it is necessary to allow clients' wl_display_connect() to find the compositor's listening socket somewhere outside of XDG_RUNTIME_DIR. For a full account, see the discussion beginning here:

Enabling Android-style per application user ids

There has been a surge of recent interest in the details of using Wayland on nontraditional systems that don't have the normal notion of human-user login sessions. Discussions are ongoing about the details of how to manage the allocation of TTYs and Weston's vision of the best practices for

Re: Enabling Android-style per application user ids

On Thu, Nov 2, 2017 at 3:36 AM, Pekka Paalanen <ppaala...@gmail.com> wrote: > On Wed, 1 Nov 2017 13:44:50 -0500 > Matt Hoosier <matt.hoos...@gmail.com> wrote: > > > There has been a surge of recent interest in the details of using Wayland > > on nontraditional s

Re: New paths for Wayland sockets (Re: Enabling Android-style per application user ids)

Hi Pekka, What do you think is a good amount of time to allow for people to respond to your call for acks/nacks? On Fri, Nov 3, 2017 at 8:33 AM, Carsten Haitzler wrote: > On Fri, 3 Nov 2017 12:47:39 +0200 Pekka Paalanen said: > >> On Fri, 3 Nov 2017

Re: [PATCH weston 00/14] Desktop Protocol Support for IVI-Shell

Hi Pekka, On Wed, Oct 25, 2017 at 10:09 AM, Ucan, Emre (ADITG/ESB) wrote: > Actually, IMO ivi-shell is not a proper wayland compositor. Because it is > violating wayland protocol by not supporting wl_shell interface. > > Therefore, we have to at least support wl_shell

Making weston (or maybe libinput) ignore an input device

Hi all, The thing I'd like to arrange is for a device which is otherwise a valid keyboard, not to get automatically vacuumed up into the Weston DRM backend's usage of libinput. Nowadays, Weston has delegated most of its former firsthand extraction of UDev properties to libinput. Nothing exists

Re: [PATCH weston v3] libweston-desktop: add signal for title/app-id changes

On Fri, Dec 8, 2017 at 4:26 AM, Quentin Glidic <sardemff7+wayl...@sardemff7.net> wrote: > On 12/8/17 11:22 AM, Quentin Glidic wrote: >> >> From: Matt Hoosier <matt.hoos...@gmail.com> >> >> As discussed on >> >> https://lists.freedesktop.org/arch

Re: Making weston (or maybe libinput) ignore an input device

On Thu, Dec 7, 2017 at 2:05 AM, Pekka Paalanen <ppaala...@gmail.com> wrote: > On Tue, 5 Dec 2017 13:57:39 -0600 > Matt Hoosier <matt.hoos...@gmail.com> wrote: > >> Hi all, >> >> The thing I'd like to arrange is for a device which is otherwise a >> vali

Re: Automatically choosing a VT for DRM compositor?

On Mon, Oct 30, 2017 at 5:10 AM, Pekka Paalanen <ppaala...@gmail.com> wrote: > On Fri, 27 Oct 2017 09:10:02 -0500 > Matt Hoosier <matt.hoos...@gmail.com> wrote: > > > On Fri, Oct 27, 2017 at 8:05 AM, Pekka Paalanen <ppaala...@gmail.com> > wrote: > >

Re: [PATCH weston 00/14] Desktop Protocol Support for IVI-Shell

On Wed, Oct 25, 2017 at 2:09 AM, Pekka Paalanen wrote: > Hi, > > the very reason why ivi-shell ever came to be was that the operating > environment of graphical applications in IVI was so different from a > normal desktop, that it was simply impossible to have desktop >

Re: Automatically choosing a VT for DRM compositor?

On Tue, Oct 24, 2017 at 1:33 AM, Pekka Paalanen <ppaala...@gmail.com> wrote: > On Mon, 23 Oct 2017 14:37:37 -0500 > Matt Hoosier <matt.hoos...@gmail.com> wrote: > >> It would be nice for non-session uses of Weston (embedded systems) if >> the controlling TTY di

Re: [PATCH weston 00/14] Desktop Protocol Support for IVI-Shell

I'm not at all familiar with the internal implementation of ivi-shell, so I can't give much meaningful review. But I am very much in favor of this patch series. Without wl_shell and xdg_shell support, I've never been able to really give ivi-shell serious consideration on my products. The ability

Re: Automatically choosing a VT for DRM compositor?

root. > It has not been written for anything else. > > > > -----Original Message- > > > From: wayland-devel [mailto:wayland-devel- > > > boun...@lists.freedesktop.org] On Behalf Of Matt Hoosier > > > Sent: Montag, 30. Oktober 2017 14:28 > > > To:

Re: [PATCH weston] launcher: don't exit when user is not root

On Mon, Oct 30, 2017 at 10:02 AM, Pekka Paalanen wrote: > On Mon, 30 Oct 2017 15:20:42 +0100 > Emre Ucan wrote: > > > weston does not need to be root. > > It requires adjusting ownership on the given tty device. > > > > If weston does not have proper

Re: libweston program segfaults on weston_compositor_load_backend

On Fri, May 4, 2018 at 8:46 AM, Pekka Paalanen <ppaala...@gmail.com> wrote: > On Fri, 4 May 2018 07:55:10 -0500 > Matt Hoosier <matt.hoos...@gmail.com> wrote: > > > On Fri, May 4, 2018 at 2:13 AM, Pekka Paalanen <ppaala...@gmail.com> > wrote

Re: libweston program segfaults on weston_compositor_load_backend

On Fri, May 4, 2018 at 2:13 AM, Pekka Paalanen wrote: > On Thu, 03 May 2018 23:38:55 +0100 > adlo wrote: > > > On Thu, 2018-05-03 at 14:12 +0300, Pekka Paalanen wrote: > > > > > > what's the backtrace from gdb for that? > > > > > > > Is this any help? >

[PATCH] log: improve handling of use-before-init

Rather than segfaulting by attempting to traverse an initially null log handler pointer, explicitly print a message and abort. Signed-off-by: Matt Hoosier <matt.hoos...@gmail.com> --- libweston/log.c | 22 -- 1 file changed, 20 insertions(+), 2 deletions(-) diff

Re: [PATCH] log: improve handling of use-before-init

Any takers to accept this one? On Fri, May 4, 2018 at 9:26 AM, Matt Hoosier <matt.hoos...@gmail.com> wrote: > Rather than segfaulting by attempting to traverse an initially > null log handler pointer, explicitly print a message and abort. > > Signed-off-by: Matt Hoosier <m

Re: Wayland content-protection extension

On Mon, Jun 18, 2018 at 8:54 AM Pekka Paalanen wrote: > Hi Matt, > > did you intend to reply on list? Please CC if you did. > > On Mon, 18 Jun 2018 08:35:56 -0500 > Matt Hoosier wrote: > > > On Mon, Jun 18, 2018 at 3:59 AM Pekka Paalanen > wrote: > > >

Re: Users of libweston?

On Mon, Jul 2, 2018 at 4:10 AM Pekka Paalanen wrote: > On Fri, 29 Jun 2018 10:05:58 -0500 > Matt Hoosier wrote: > > > Hi all, > > > > Pekka's recent comments about wanting to enable set-top boxes built with > > libweston to do DRM content got me to wondering: &

Re: Running multiple Wayland window managers in different ttys

Hi Deepak, On Fri, Oct 20, 2017 at 11:50 AM, Deepak Jois wrote: > Hi > > I have read the Wayland docs and skimmed through the API reference, > and I am trying to understand some concepts better. The questions > below are probably a bit naive, but I appreciate any >

Re: Automatically choosing a VT for DRM compositor?

HI Pekka, On Thu, Oct 26, 2017 at 2:06 AM, Pekka Paalanen <ppaala...@gmail.com> wrote: > On Tue, 24 Oct 2017 08:26:04 -0500 > Matt Hoosier <matt.hoos...@gmail.com> wrote: > > > On Tue, Oct 24, 2017 at 1:33 AM, Pekka Paalanen <ppaala...@gmail.com> > wrote: >

Re: Automatically choosing a VT for DRM compositor?

On Fri, Oct 27, 2017 at 8:05 AM, Pekka Paalanen <ppaala...@gmail.com> wrote: > On Fri, 27 Oct 2017 07:05:13 -0500 > Matt Hoosier <matt.hoos...@gmail.com> wrote: > > > HI Pekka, > > > > On Thu, Oct 26, 2017 at 2:06 AM, Pekka Paalanen <ppaala...@gmail.com&

To the libinput people: standard network protocol for remote input devices?

This question is mainly meant for the input device developers that hang out here. Does anybody know of a de facto network protocol that should be used for relaying input devices across a network? I don't have full remote-desktop situations in mind -- this is narrowly a question about devices with

Re: [systemd-devel] [PATCH weston] doc/systemd: system service example

On Dec 29, 2017 15:32, "Mantas Mikulėnas" <graw...@gmail.com> wrote: On Fri, Dec 29, 2017 at 11:09 PM, Matt Hoosier <matt.hoos...@gmail.com> wrote: > > The approach that you and Pekka most recently put on record here: > > * User=foo > * PAMName=weston > &

Re: [systemd-devel] [PATCH weston] doc/systemd: system service example

Hi Lennart, On Mon, Dec 4, 2017 at 9:11 AM, Pekka Paalanen wrote: > On Fri, 1 Dec 2017 18:25:35 +0100 > Lennart Poettering wrote: > >> On Fr, 01.12.17 13:42, Pekka Paalanen (ppaala...@gmail.com) wrote: >> >> > > > > This is racy, as the session ID is

Re: [systemd-devel] [PATCH weston] doc/systemd: system service example

On Mon, Jan 22, 2018 at 7:49 AM, Pekka Paalanen <ppaala...@gmail.com> wrote: > On Fri, 29 Dec 2017 15:09:28 -0600 > Matt Hoosier <matt.hoos...@gmail.com> wrote: > >> Hi Lennart, >> >> On Mon, Dec 4, 2017 at 9:11 AM, Pekka Paalanen <ppaala...@gmail.com>

Re: [PATCH weston 00/14] Desktop Protocol Support for IVI-Shell

On Wed, Nov 8, 2017 at 1:30 AM, Pekka Paalanen <ppaala...@gmail.com> wrote: > On Tue, 7 Nov 2017 11:01:09 -0600 > Matt Hoosier <matt.hoos...@gmail.com> wrote: > >> Hi Pekka, >> >> On Wed, Oct 25, 2017 at 10:09 AM, Ucan, Emre (ADITG/ESB) >> <eu..

Favorite external display/touch combo panels?

Hi; I'm interested in getting an external display to make testing the touch-centric changes in Weston easier when working from a PC. Does anybody have recommendations for a good model that attaches over HDMI+USB that supports a reasonably good resolution and reports a standard slotted multitouch

Re: wl_buffer is not released for long time.

Hi, Unless you're using an unreleased version of Weston, I think you're probably running into a bug that we fixed a few months ago in which wl_buffer::release() events were prone to sit undispatched in the server's outgoing queue until some other event happened to need transmitted. -Matt On

Re: wl_buffer is not released for long time.

Here's the discussion and patch that addressed the issue I was mentioning: https://lists.freedesktop.org/archives/wayland-devel/2017-September/035191.html On Mon, Mar 12, 2018 at 3:51 PM, Matt Hoosier <matt.hoos...@gmail.com> wrote: > Hi, > > Unless you're using an unreleased ve

Re: [PATCH libinput 0/1] Initialization race against udev

I encounter another "bad" behavior related to multiple firings of the UDev 'add' event for a given input node. Typically on modest embedded systems, you do not want to run the exhaustive 'udevadm trigger' during the main booting sequence. That causes hundreds or thousands of UDev nodes to be

Re: [PATCH weston 00/25] A new touchscreen calibrator

On Wed, Apr 4, 2018 at 2:27 AM, Pekka Paalanen <ppaala...@gmail.com> wrote: > On Wed, 04 Apr 2018 00:37:58 +0000 > Matt Hoosier <matt.hoos...@gmail.com> wrote: > > > On Tue, Apr 3, 2018, 08:10 Matt Hoosier <matt.hoos...@gmail.com> wrote: > > > > >

Re: [PATCH libinput 0/1] Initialization race against udev

e Base (ADITG/ESB) > > > > Tel. +49 5121 49 6921 > > > > > -Original Message- > > > From: wayland-devel [mailto:wayland-devel- > > > boun...@lists.freedesktop.org] On Behalf Of Peter Hutterer > > > Sent: Donnerstag, 5. April 2018 06:27 > &

Re: [PATCH libinput 0/1] Initialization race against udev

ngineering Software Base (ADITG/ESB) > > > > Tel. +49 5121 49 6921 > > > -Original Message- > > > From: Peter Hutterer [mailto:peter.hutte...@who-t.net] > > > Sent: Freitag, 6. April 2018 04:29 > > > To: Friedrich, Eugen (ADITG/ESB) >

Re: [PATCH weston 00/25] A new touchscreen calibrator

, 2018, 09:38 Matt Hoosier <matt.hoos...@gmail.com> wrote: > On Fri, Mar 23, 2018 at 9:30 AM, Pekka Paalanen <ppaala...@gmail.com> > wrote: > > On Fri, 23 Mar 2018 08:46:46 -0500 > > Matt Hoosier <matt.hoos...@gmail.com> wrote: > > > >> I am very

Re: [PATCH weston 00/25] A new touchscreen calibrator

ouchscreen got pegged to the correct physical output. I have the feeling that I just overlooked some aspect of configuration about this. -Matt > > > > > On Fri, Mar 23, 2018, 09:38 Matt Hoosier <matt.hoos...@gmail.com> > > wrote: > > > On Fri, Mar 23, 2018 at 9:30 A

Re: [PATCH weston 00/25] A new touchscreen calibrator

On Tue, Apr 3, 2018, 08:10 Matt Hoosier <matt.hoos...@gmail.com> wrote: > On Tue, Apr 3, 2018 at 5:35 AM, Philipp Kerling <pkerl...@casix.org> > wrote: > >> > Do you happen to know of a good readymade program that fakes the >> > presence of a touch inp

Re: [PATCH weston 00/25] A new touchscreen calibrator

On Fri, Mar 23, 2018 at 9:30 AM, Pekka Paalanen <ppaala...@gmail.com> wrote: > On Fri, 23 Mar 2018 08:46:46 -0500 > Matt Hoosier <matt.hoos...@gmail.com> wrote: > >> I am very much in favor of the overall approach on this patch series. >> I've experienced every sin

Re: [PATCH weston 00/25] A new touchscreen calibrator

I am very much in favor of the overall approach on this patch series. I've experienced every single one of the problems described in this summary, and my company currently resorts to maintaining a hacky out-of-tree calibration tool to paper over these problems. On Fri, Mar 23, 2018 at 7:00 AM,

Users of libweston?

Hi all, Pekka's recent comments about wanting to enable set-top boxes built with libweston to do DRM content got me to wondering: Who all is using libweston directly (as opposed to running /usr/bin/weston possibly with custom shells plugins or similar)? For my own purposes, I just use the full

Following all PR's on GitLab

(Fair warning, I've never used GitLab other than anonymously before.) I'd like to be able to get email notifications about all the PR's (their initial posting, subsequent code reviews, acceptance, etc) as a way to simulate the former bird's eye view that was possible when all patches passed

Source code to Wayland backend of Android HWComposer?

Hi all, A while ago, LWN.net ran an article (https://lwn.net/Articles/702075/) that overviewed the Wayland-based display architecture used by ChromeOS to allow its containerized Android runtimes to forward graphics surfaces along to the ChromeOS compositor. Does anybody know where to find the

  1   2   >