Hi Bastien,
On Tue, Apr 4, 2017 at 2:17 AM, Bastien Nocera wrote:
> Hey Roderick,
>
> On Mon, 2017-04-03 at 16:08 -0700, Roderick Colenbrander wrote:
>> Hi Peter,
>>
>> Thanks for sharing this proposal. I have some little comments for a
>> later stage, but would rather discuss some big items fir
On Mon, Apr 3, 2017 at 9:08 PM, Peter Hutterer wrote:
>
> On Mon, Apr 03, 2017 at 04:08:21PM -0700, Roderick Colenbrander wrote:
> > Hi Peter,
> >
> > Thanks for sharing this proposal. I have some little comments for a later
> > stage, but would rather discuss some big items first.
> >
> > The fee
With
commit 47224cc9312fef05c1a523ea0da0a1aae66f100d
Author: Daniel Stone
Date: Sat Nov 5 08:04:07 2016 +
compositor-drm: Delete drm_backend_set_modes
we stopped forcing a modeset when restoring the session. The motivation
was that we would use a stale fb, so bette
On Tue, 4 Apr 2017 17:54:20 +0100
Daniel Stone wrote:
> Rather than duplicating knowledge of pixel formats across several
> components, create a custom central repository.
>
> Signed-off-by: Daniel Stone
> ---
> Makefile.am | 2 +
> libweston/pixel-formats.c | 430
> +
This adds a new protocol to let Wayland clients specify that they want
all keyboard events to be send to the client, regardless of the
compositor own shortcuts.
This is for use by virtual machine and remote connections viewers.
Signed-off-by: Olivier Fourdan
---
v2: Clarify that that the compos
This patch introduces a new protocol for grabbing the keyboard from
Xwayland.
This is needed for X11 applications that map an override redirect window
(thus not focused by the window manager) and issue an active grab on the
keyboard to capture all keyboard events.
Signed-off-by: Olivier Fourdan
On Tue, Apr 04, 2017 at 07:05:25PM -0600, Chris Murphy wrote:
> On Tue, Apr 4, 2017 at 6:25 PM, Peter Hutterer
> wrote:
> > On Tue, Apr 04, 2017 at 05:01:53PM -0600, Chris Murphy wrote:
> >> On Tue, Apr 4, 2017 at 4:36 PM, Peter Hutterer
> >> wrote:
> >> > On Tue, Apr 04, 2017 at 12:33:32PM -06
On Wed, 2017-04-05 at 11:57 +0200, Bastien Nocera wrote:
> On Wed, 2017-04-05 at 10:42 +0100, Steven Newbury wrote:
> >
>
>
> > There's a reason the mouse support from the X DGA Extension out-
> > survived the "direct framebuffer access". The latency through the
> > wire
> > whether X or Waylan
Hi Steven,
On 5 April 2017 at 11:04, Steven Newbury wrote:
> On Wed, 2017-04-05 at 10:53 +0100, Daniel Stone wrote:
>> DGA's DirectMouse doesn't change the latency. It doesn't give the
>> client a direct-to-kernel stream. It still results in the server
>> doing
>
> I wondered if I was implying th
On Wed, 2017-04-05 at 10:53 +0100, Daniel Stone wrote:
> Hi Steven,
>
> On 5 April 2017 at 10:42, Steven Newbury
> wrote:
> > On Wed, 2017-04-05 at 10:25 +0100, Daniel Stone wrote:
> > > The compositor _must_ interpose every single keyboard/mouse
> > > event,
> > > and
> > > they are simple enoug
On Wed, 2017-04-05 at 10:42 +0100, Steven Newbury wrote:
>
> There's a reason the mouse support from the X DGA Extension out-
> survived the "direct framebuffer access". The latency through the
> wire
> whether X or Wayland for mouse input it just too high for mouse
> controlled high framerate 3
Hi Steven,
On 5 April 2017 at 10:42, Steven Newbury wrote:
> On Wed, 2017-04-05 at 10:25 +0100, Daniel Stone wrote:
>> The compositor _must_ interpose every single keyboard/mouse event,
>> and
>> they are simple enough that it is possibly to easily encode them with
>> universally-accepted concept
On Wed, 2017-04-05 at 10:25 +0100, Daniel Stone wrote:
> Hi,
>
> On 5 April 2017 at 04:40, Carsten Haitzler
> wrote:
> > On Tue, 04 Apr 2017 14:45:13 +0200 Bastien Nocera > t> said:
> > > There's two possible solutions to this problem:
> > > - evdev gives you the ability the mask certain events.
On Wed, 2017-04-05 at 12:40 +0900, Carsten Haitzler wrote:
> On Tue, 04 Apr 2017 14:45:13 +0200 Bastien Nocera
> said:
>
> > On Tue, 2017-04-04 at 20:32 +0900, Carsten Haitzler wrote:
> > > On Tue, 4 Apr 2017 10:22:24 +1000 Peter Hutterer > > who-
> > > t.net>
> > > said:
> > >
> > > > On Tue,
On Tue, 4 Apr 2017 17:52:20 +0100
Daniel Stone wrote:
> From: Ander Conselvan de Oliveira
>
> When using the atomic API, one request can span multiple CRTCs, however
> one event is generated per CRTC. As we cannot disambiguate the CRTC with
> user data (since we only have one piece of user dat
Hi,
On 5 April 2017 at 04:40, Carsten Haitzler wrote:
> On Tue, 04 Apr 2017 14:45:13 +0200 Bastien Nocera said:
>> There's two possible solutions to this problem:
>> - evdev gives you the ability the mask certain events. The compositor
>> can keep one fd open masking everything but the power/men
16 matches
Mail list logo
