Re: [RFC wayland] doc: generate doxygen html output from the scanner

On Tue, Nov 3, 2015 at 2:02 PM, Peter Hutterer wrote: > On Tue, Nov 03, 2015 at 12:37:39PM -0800, Bill Spitzak wrote: > > On Sun, Nov 1, 2015 at 6:21 PM, Peter Hutterer > > > wrote: > > > > > On Sun, Nov 01, 2015 at 05:41:04PM -0800, Bill Spitzak wrote: > > > > On 11/01/2015 04:27 PM, Peter Hutt

Re: [PATCH v5 wayland] protocol: add wl_pointer.frame, axis_source, axis_stop, and axis_discrete

On Wed, Oct 28, 2015 at 03:34:31PM +1000, Peter Hutterer wrote: > The frame event groups separate pointer events together. The primary use-case > for this at the moment is diagonal scrolling - a vertical/horizontal scroll > event can be grouped together to calculate the correct motion vector. > Fra

Re: [RFC wayland] doc: generate doxygen html output from the scanner

On Tue, Nov 03, 2015 at 12:37:39PM -0800, Bill Spitzak wrote: > On Sun, Nov 1, 2015 at 6:21 PM, Peter Hutterer > wrote: > > > On Sun, Nov 01, 2015 at 05:41:04PM -0800, Bill Spitzak wrote: > > > On 11/01/2015 04:27 PM, Peter Hutterer wrote: > > > > > > >but: the current API docs in publican are us

Re: xdg_surface initial configuration

Hi, On 3 November 2015 at 20:24, Bill Spitzak wrote: > I'm thinking now that this is occurring often enough that it would be > cleaner to build such commits in at a low-level into wayland. Rather than > the commit message on wl_surface, and the new "axis finished" events being > sent the other wa

Re: [RFC wayland] doc: generate doxygen html output from the scanner

On Sun, Nov 1, 2015 at 6:21 PM, Peter Hutterer wrote: > On Sun, Nov 01, 2015 at 05:41:04PM -0800, Bill Spitzak wrote: > > On 11/01/2015 04:27 PM, Peter Hutterer wrote: > > > > >but: the current API docs in publican are useless. look at appendix B, > the > > >"client API". http://wayland.freedeskt

Re: xdg_surface initial configuration

On Mon, Nov 2, 2015 at 1:20 PM, Michael Forney wrote: > On Wed, Sep 23, 2015 at 12:10:02PM -0700, Bill Spitzak wrote: > > Seems like the wl_display.sync() can do the job. The compositor may send > > several configure events, that is harmless. Just use the last one. > > > > A compositor *may* try

Re: [PATCH wayland] protocol: Improve data source notification around DnD progress

On Mon, Nov 2, 2015 at 9:28 AM, Carlos Garnacho wrote: > On Fri, Oct 30, 2015 at 7:10 PM, Bill Spitzak wrote: > > I think what is wanted is an indication that the drag really did finish. > For > > That's data_source.drag_finished in the patch you're commenting. > According to the documentation

Re: [PATCH v2] protocol: Improve data source notification around DnD progress

Hey :), On Tue, Nov 3, 2015 at 1:36 AM, Jonas Ådahl wrote: > On Fri, Oct 30, 2015 at 09:55:37PM +0100, Carlos Garnacho wrote: >> Currently, there's no means for the DnD origin to know whether the >> destination is actually finished with the DnD transaction, short of >> finalizing it after the fir

[PATCH weston] libinput: don't fail if no input device exists

There is no reason to fail at udev_input_init, if no input device is recognized by libinput. An input device can be hot-plugged later. Signed-off-by: Emre Ucan --- src/libinput-seat.c |1 - 1 file changed, 1 deletion(-) diff --git a/src/libinput-seat.c b/src/libinput-seat.c index 5b2dbec..

Re: Why does drm-backend fail to start without input devices ?

2015-11-03 12:18 GMT+02:00 Ucan, Emre (ADITG/SW1) : > Hi, > > drm_backend_create function fails, if udev_input_init returns -1. > > udev_input_init returns -1 when no input devices are recognized by udev. > > This means, it is not possible to use drm-backend without input devices. > > Is there a s

Why does drm-backend fail to start without input devices ?

Hi, drm_backend_create function fails, if udev_input_init returns -1. udev_input_init returns -1 when no input devices are recognized by udev. This means, it is not possible to use drm-backend without input devices. Is there a special reason for this restriction ? Best regards Emre Ucan __