Re: [PATCH v14 19/41] compositor-drm: Extract buffer->plane co-ord translation

Hi Pekka, Thanks for the explanation; I'm not sure why it's requiring so much mental contortion on my end. :\ On 26 February 2018 at 08:30, Pekka Paalanen wrote: > On Fri, 23 Feb 2018 17:25:49 + Daniel Stone wrote: >> Hm ... I am feeling

Re: [PATCH wayland-protocols] unstable: add xdg-toplevel-decoration protocol

Hi, I agree with your point regarding a SSD-capable compositor not always wanting them, and certainly I can see the usefulness for cases such as what you've cited. However, in the example you provided, it's easy enough for an application to determine what desktop it's running in and then

[PATCH wayland-protcols v2] unstable: add xdg-toplevel-decoration protocol

This adds a new protocol to negotiate server- and client-side rendering of window decorations for xdg-toplevels. This allows compositors that want to draw decorations themselves to send their preference to clients, and clients that prefer server-side decorations to request them. This is inspired

Re: Is it possible to emit event at client side?

On Fri, 02 Mar 2018 14:51:54 + Sichem Zhou wrote: > Hi PQ, > > Thanks for your answer. It would be nice have it though. Sorry, not going to happen. Thanks, pq > Le ven. 2 mars 2018 09 h 41, Pekka Paalanen a écrit : > > > On Fri, 02 Mar 2018

Re: [PATCH] gl-renderer: Create a high priority context

Quoting Emil Velikov (2018-03-02 14:52:28) > Hi Chris, > > On 1 March 2018 at 08:28, Chris Wilson wrote: > > EGL_IMG_context_priority allows the client to request that their > > rendering be considered high priority. For ourselves, this is important > > as we are

Re: [PATCH] gl-renderer: Create a high priority context

Hi Chris, On 1 March 2018 at 08:28, Chris Wilson wrote: > EGL_IMG_context_priority allows the client to request that their > rendering be considered high priority. For ourselves, this is important > as we are interactive and any delay in our rendering causes

Re: Is it possible to emit event at client side?

Hi PQ, Thanks for your answer. It would be nice have it though. Regards, X Le ven. 2 mars 2018 09 h 41, Pekka Paalanen a écrit : > On Fri, 02 Mar 2018 14:27:23 + > Sichem Zhou wrote: > > > Hi all, > > > > I have a question regarding the Wayland

Re: Is it possible to emit event at client side?

On Fri, 02 Mar 2018 14:27:23 + Sichem Zhou wrote: > Hi all, > > I have a question regarding the Wayland client side API. I see there is API > to create a `wl_ event_queue` but it seems you can only assign `wl_proxy` > and send command to server. > > Is anyway that I

Is it possible to emit event at client side?

Hi all, I have a question regarding the Wayland client side API. I see there is API to create a `wl_ event_queue` but it seems you can only assign `wl_proxy` and send command to server. Is anyway that I can create a event queue and keep it to myself, it's use case lies in multi threading

Re: Sharing wl display/surface with another process.

On Fri, 02 Mar 2018 15:12:40 +0200 Maksim Sisov wrote: > Hi, > > I have a question about a proper client side of implementation of > wayland with egl. > > The idea is that we have wayland ui related stuff on ui process > (creating wayland window, managing mouse/keyboard

Sharing wl display/surface with another process.

Hi, I have a question about a proper client side of implementation of wayland with egl. The idea is that we have wayland ui related stuff on ui process (creating wayland window, managing mouse/keyboard inputs and etc), and have egl related stuff created and rendering on another gpu process.

[PATCH libinput] Add libinput_device_touch_get_touch_count()

This makes it possible for callers to detect whether a touch device is single or multitouch (or even check for things like dual-touch vs real multi-touch) and adjust the interface accordingly. Note that this is for touch devices only, not touchpads that are just pointer devices.