Re: [PATCH] [weston, v4] weston.ini: Add natural scroll support to weston.ini This adds support for enabling/disabling natural scrolling via a boolean in weston.ini:

2017-02-06 Thread Peter Hutterer 
On Mon, Feb 06, 2017 at 12:00:08PM +0200, Pekka Paalanen wrote:
> On Mon, 6 Feb 2017 10:36:56 +1000
> Peter Hutterer  wrote:
> 
> > On Sun, Feb 05, 2017 at 07:30:18PM -0500, Jiayi Zhao wrote:
> > > ​​
> > > Hmmm, after using udev_device_has_tag(udev_device, "ID_INPUT_TOUCHPAD"),
> > > I'm getting linking errors. Quick google of this leads to: libraries on 
> > > the
> > > command line should be after the object files being compiled.
> > > Is this a bug?  
> > 
> > come to think of it, tags are a bit different. you need
> > udev_device_get_property_value() instead. and you need to make sure that
> > libudev is linked in - that's where your linking errors come from.
> 
> Hi,
> 
> needing udev API raises further considerations.
> 
> A fundamental question is whether udev-using backends should actually
> expose udev as part of their API to libweston users (main.c) or whether
> it should expose its own abstraction. Since we (I, at least) do not
> really have a good understanding what all things one might want, it
> might be easier and more flexible to assume that udev will be part of
> libweston's DRM backend specific API.
> 
> IOW, in compositor-drm.h, the configure_device vfunc should probably
> get a new argument referring to the udev thing. This breaks the library
> ABI, forcing a libweston major version bump.
> 
> Therefore when the DRM-backend is enabled, weston (main.c) should link
> to libudev for using it, and the backend-specific API needs to grow
> things to support the use of udev. This calls for configure.ac changes.
> 
> So far Weston has not been using libudev, which is why you got the
> linker errors: it is not linked into Weston, it is only linked to the
> specific backends.
> 
> Also, it has been possible to build Weston and libweston without
> libudev by disabling the backends that depended on it. I'm not sure
> supporting that is worthwhile, though, considering DRM is really the
> main backend which already depends on libudev.

afaict libinput isn't optional and libinput requires libudev. So now we're
only talking about whether you explicitly link to it or not, it's already a
requirement anyway.

two points regarding the API discussion, and both sum up as "not needed for
this particular feature".

if udev were unavailable, it'd be easier to have a policy of "if the device
has tapping, treat it as touchpad for the natural scroll setting". that's
good enough and skirts any usage of libudev in main.c.

but we already have a libinput device here and libinput links to libudev. We
easily get the udev device from the libinput device, the only change here  
is linking libudev explicitly. no API changes to libweston needed at all.

changing the API for a little feature like this seems excessive unless you
have explicit use-cases where exposing udev through the API is required. 

Cheers,
   Peter


> Looks like libinput is already required by main.c, so following that
> example with libudev should be good.

> 
> Thanks,
> pq
> 
> > > On Sun, Feb 5, 2017 at 7:20 PM, Peter Hutterer 
> > > wrote:
> > >   
> > > > On Sun, Feb 05, 2017 at 07:13:04PM -0500, Jiayi Zhao wrote:  
> > > > > How would ID_INPUT_TOUCHPAD work?
> > > > > I have something like udev_device_has_tag(udev_device,  
> > > > ID_INPUT_TOUCHPAD)  
> > > > > Unfortunately, I'm not sure where this constant is declared and its  
> > > > unable  
> > > > > to find the tag. :/  
> > > >
> > > > it's a udev property name, so use it as a string, not a #define.
> > > > value is either 1 or 0, so you do need to check for validity.
> > > >
> > > > Cheers,
> > > >Peter
> > > >  
> > > > > On Jan 29, 2017 4:42 PM, "Peter Hutterer"   
> > > > wrote:  
> > > > >  
> > > > > > On Fri, Jan 27, 2017 at 09:46:49PM -0500, Jiayi Zhao wrote:  
> > > > > > > [libinput]
> > > > > > > natural_scroll=true
> > > > > > >
> > > > > > > CHANGES:
> > > > > > >  - libinput_device_config_scroll_has_natural_scroll() is no 
> > > > > > > longer  
> > > > > > compared to != 0  
> > > > > > >  - added configuration option to weston.ini man page
> > > > > > >
> > > > > > > Signed-off-by: Jiayi Zhao 
> > > > > > > ---
> > > > > > >  compositor/main.c  | 13 +
> > > > > > >  man/weston.ini.man |  3 +++
> > > > > > >  weston.ini.in  |  1 +
> > > > > > >  3 files changed, 17 insertions(+)
> 


___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH] testing: add section about debugging individual tests with gdb

2017-02-06 Thread Micah Fedke 
---
 testing.html | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/testing.html b/testing.html
index e5781fe..c005df1 100644
--- a/testing.html
+++ b/testing.html
@@ -184,4 +184,22 @@ way to learn how to leverage these API's is to study some 
of the existing tests
 (e.g. tests/button-test.c).
 
 
+Debugging Tests
+
+
+Debugging individual .la and .weston tests (those executed by 
weston-tests-env) using gdb is possible, but takes a few setup steps.
+First run the test normally if you have not done this already, eg.
+
+make check TESTS=button.weston
+
+- or -
+
+abs_builddir=$PWD tests/weston-tests-env button.weston
+
+The serverlog.txt file (logs/button-serverlog.txt, in this case) generated by 
the weston-tests-env script will now contain the full execution command used to 
launch weston and the test, on the line starting with "Command line:".  You can 
use gdb with this command line to debug the test binary.  Note that the 
weston-tests-env script sets a few environment variables that you will need to 
set as well:
+
+abs_builddir=$PWD abs_top_srcdir=$PWD WESTON_BUILD_DIR=$abs_builddir 
WESTON_TEST_REFERENCE_PATH=$abs_top_srcdir/tests/reference 
WESTON_TEST_CLIENT_PATH=$abs_builddir/button.weston
+
+Significantly, WESTON_TEST_CLIENT_PATH contains the path to the test you want 
to debug.  When switching between debugging different test binaries, be sure to 
use the command line from the appropriate serverlog.txt file as well as 
updating WESTON_TEST_CLIENT_PATH.
+
 
-- 
2.11.0

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH v2] clients: teach simple-dmabuf-v4l to deal with flipped input

2017-02-06 Thread Micah Fedke 
The v4l2 API can be queried to detect if the input video image is
horizontally or vertically flipped. If the image is y-flipped, we can
set the ZWP_LINUX_BUFFER_PARAMS_V1_FLAGS_Y_INVERT flag to notify the
compositor.  If the image is h-flipped, we can only print a warning
since linux_buffer_params_v1 does not support horizontal flipping.

Signed-off-by: Micah Fedke 
---
This version addresses Pekka's comments by renaming check_v4l2_control to
check_v4l2_control_bool, removing the len parameter, separating out the logic
tests in check_v4l2_control_bool and fixing spacing issues.

 clients/simple-dmabuf-v4l.c | 62 +++--
 1 file changed, 54 insertions(+), 8 deletions(-)

diff --git a/clients/simple-dmabuf-v4l.c b/clients/simple-dmabuf-v4l.c
index af25d0ea..6f41b2a7 100644
--- a/clients/simple-dmabuf-v4l.c
+++ b/clients/simple-dmabuf-v4l.c
@@ -351,21 +351,67 @@ static const struct zwp_linux_buffer_params_v1_listener 
params_listener = {
create_failed
 };
 
+static bool
+check_v4l2_control_bool(const int fd,
+const struct v4l2_query_ext_ctrl *qectrl,
+const char *control_name,
+const int expected_value)
+{
+   struct v4l2_control ctrl;
+
+   memset(, 0, sizeof(ctrl));
+   ctrl.id = qectrl->id;
+
+   if (qectrl->flags & V4L2_CTRL_FLAG_DISABLED)
+   return false;
+
+   if (!(qectrl->type == V4L2_CTRL_TYPE_BOOLEAN))
+   return false;
+
+   if (strcmp(qectrl->name, control_name))
+   return false;
+
+   /* with the early-outs out of the way, do the actual check */
+   if (xioctl(fd, VIDIOC_G_CTRL, ))
+   return false;
+
+   if (ctrl.value != expected_value)
+   return false;
+
+   return true;
+}
+
 static void
 create_dmabuf_buffer(struct display *display, struct buffer *buffer)
 {
struct zwp_linux_buffer_params_v1 *params;
uint64_t modifier;
-   uint32_t flags;
+   uint32_t lbp_flags;
unsigned i;
+   struct v4l2_query_ext_ctrl qectrl;
+   const unsigned int v4l2_qec_flags =
+   V4L2_CTRL_FLAG_NEXT_CTRL | 
V4L2_CTRL_FLAG_NEXT_COMPOUND;
+   const char *vflip_ctrl = "Vertical Flip";
+   const char *hflip_ctrl = "Horizontal Flip";
 
modifier = 0;
-   flags = 0;
-
-   /* XXX: apparently some webcams may actually provide y-inverted images,
-* in which case we should set
-* flags = ZWP_LINUX_BUFFER_PARAMS_V1_FLAGS_Y_INVERT
-*/
+   lbp_flags = 0;
+
+   /* handle relevant v4l2 controls */
+   memset(, 0, sizeof(qectrl));
+   qectrl.id |= v4l2_qec_flags;
+   while (!xioctl(display->v4l_fd, VIDIOC_QUERY_EXT_CTRL, )) {
+   if (check_v4l2_control_bool(display->v4l_fd, ,
+vflip_ctrl, 0x1)) {
+   lbp_flags = ZWP_LINUX_BUFFER_PARAMS_V1_FLAGS_Y_INVERT;
+   printf ("\"%s\" control is set, inverting Y\n", 
vflip_ctrl);
+   } else if (check_v4l2_control_bool(display->v4l_fd, ,
+   hflip_ctrl, 0x1)) {
+   printf ("\"%s\" control is set, but dmabuf output 
cannot"
+"be flipped horizontally\n", hflip_ctrl);
+   }
+   qectrl.id |= v4l2_qec_flags;
+   }
 
params = zwp_linux_dmabuf_v1_create_params(display->dmabuf);
for (i = 0; i < display->format.num_planes; ++i)
@@ -382,7 +428,7 @@ create_dmabuf_buffer(struct display *display, struct buffer 
*buffer)
  display->format.width,
  display->format.height,
  display->drm_format,
- flags);
+ lbp_flags);
 }
 
 static int
-- 
2.11.0

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

weston-simple-egl fullscreen broken?

2017-02-06 Thread Fabien DESSENNE 
Hi

I remember I used to get < weston-simple-egl -f > working fine.
But it does not work anymore : nothing is displayed. From the logs I can see 
(among others) zxdg_toplevel_v6.configure and wl_surface.commit
Testing with another client works fine: weston-terminal -f -> OK
There may be something wrong with my environment since I am testing with the 
Daniel's atomic version (forked from weston-1.12.0+), but I guess this is 
broken also with the official version.
If anyone can make a quick test and let me know.

Fabien


___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

RE: How to specify the output for a weston window?

2017-02-06 Thread Ucan, Emre (ADITG/SW1) 
Hi,

It is possible with IVI-Shell.

If you are interested, there is a quick start guide here: 
https://at.projects.genivi.org/wiki/display/WIE/01.+Quick+start

Best regards

Emre Ucan
Software Group I (ADITG/SW1)

Tel. +49 5121 49 6937
-Original Message-
From: wayland-devel [mailto:wayland-devel-boun...@lists.freedesktop.org] On 
Behalf Of Zhu, Lingyun
Sent: Montag, 6. Februar 2017 15:38
To: jad...@gmail.com
Cc: wayland-devel
Subject: How to specify the output for a weston window?

Hi, Guys

Is this possible to specify the output for a weston window (use API)?
E.g. When I connected 2 monitors (monitor A and monitor B) on my system, and I 
want to display a picture on monitor A.


Thanks,
Lingyun
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland-protocols v3] linux-dmabuf: add immediate dmabuf import path

2017-02-06 Thread Pekka Paalanen 
On Mon, 6 Feb 2017 13:33:43 +0530
Varad Gautam  wrote:

> Hi Pekka,
> 
> On Fri, Feb 3, 2017 at 8:39 PM, Pekka Paalanen
>  wrote:
> > On Tue, 31 Jan 2017 18:41:52 +0530
> > Varad Gautam  wrote:
> >  
> >> From: Varad Gautam 
> >>
> >> provide a mechanism that allows clients to import the added dmabufs
> >> and immediately use the newly created wl_buffers without waiting on
> >> an event. this is useful to clients that are sure of their import
> >> request succeeding, and wish to avoid the wl_buffer communication
> >> roundtrip.
> >>
> >> bump zwp_linux_dmabuf_v1, zwp_linux_buffer_params_v1 interface
> >> versions.
> >>
> >> v2: specify using incorrectly imported dmabufs as undefined behavior
> >> instead of sending success/failure events. (pq, daniels)
> >> v3: preserve the optional protocol error added in v2 and explicitly
> >> state the outcome of import success or failure (pq)
> >>
> >> Signed-off-by: Varad Gautam 
> >> ---
> >>  unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml | 58 
> >> +++---
> >>  1 file changed, 51 insertions(+), 7 deletions(-)
> >>
> >> diff --git a/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml 
> >> b/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml
> >> index ed2c4bb..ddb49cc 100644
> >> --- a/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml
> >> +++ b/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml
> >> @@ -24,13 +24,13 @@
> >>  DEALINGS IN THE SOFTWARE.
> >>
> >>
> >> -  
> >> +  
> >>  
> >>Following the interfaces from:
> >>
> >> https://www.khronos.org/registry/egl/extensions/EXT/EGL_EXT_image_dma_buf_import.txt
> >>and the Linux DRM sub-system's AddFb2 ioctl.
> >>
> >> -  This interface offers a way to create generic dmabuf-based
> >> +  This interface offers ways to create generic dmabuf-based
> >>wl_buffers. Immediately after a client binds to this interface,
> >>the set of supported formats is sent with 'format' events.
> >>
> >> @@ -56,10 +56,23 @@
> >>To create a wl_buffer from one or more dmabufs, a client creates a
> >>zwp_linux_dmabuf_params_v1 object with a 
> >> zwp_linux_dmabuf_v1.create_params
> >>request. All planes required by the intended format are added with
> >> -  the 'add' request. Finally, a 'create' request is issued. The server
> >> -  will reply with either a 'created' event which provides the final
> >> -  wl_buffer or a 'failed' event saying that it cannot use the dmabufs
> >> -  provided.
> >> +  the 'add' request. Finally, a 'create' or 'create_immed' request is
> >> +  issued, which has the following outcome depending on the import 
> >> success.
> >> +
> >> +  The 'create' request,
> >> +  - on success, triggers a 'created' event which provides the final
> >> +wl_buffer to the client.
> >> +  - on failure, triggers a 'failed' event to convey that the server
> >> +cannot use the dmabufs received from the client.
> >> +
> >> +  For the 'create_immed' request,
> >> +  - on success, the server immediately imports the added dmabufs to
> >> +create a wl_buffer. No event is sent from the server in this case.
> >> +  - on failure, the server can choose to either:
> >> +- terminate the client by raising a fatal error.
> >> +- create an invalid wl_buffer handle and send a 'failed' event to
> >> +  the client. The result of using this invalid wl_buffer in the
> >> +  client is left implementation-defined by the protocol.  
> >
> > Hi,
> >
> > I would phrase the latter as:
> >
> > - Mark the wl_buffer as failed and send a 'failed' event to the
> >   client. If the client uses a failed wl_buffer as an argument
> >   to any request, the behaviour is compositor
> >   implementation-defined.
> >  
> 
> ack, will fix.
> 
> >>
> >>Warning! The protocol described in this file is experimental and
> >>backward incompatible changes may be made. Backward compatible 
> >> changes
> >> @@ -105,7 +118,7 @@
> >>  
> >>
> >>
> >> -  
> >> +  
> >>  
> >>This temporary object is a collection of dmabufs and other
> >>parameters that together form a single logical buffer. The temporary
> >> @@ -138,6 +151,9 @@
> >>   summary="invalid width or height"/>
> >> >>   summary="offset + stride * height goes out of dmabuf 
> >> bounds"/>
> >> +   >> + summary="invalid wl_buffer resulted from importing dmabufs 
> >> from
> >> +   the given buffer_params"/>  
> >
> > I might have called it "import_failure". Not a big deal.  
> >>  
> >>
> >>  
> >> @@ -269,6 +285,34 @@
> >>  zlinux_buffer_params object.
> >>
> >>  
> >> +
> >> +
> >> +  
> >> +This asks for

How to specify the output for a weston window?

2017-02-06 Thread Zhu, Lingyun 
Hi, Guys

Is this possible to specify the output for a weston window (use API)?
E.g. When I connected 2 monitors (monitor A and monitor B) on my system, and I 
want to display a picture on monitor A.


Thanks,
Lingyun
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH] protocol: Add gaming input protocol

2017-02-06 Thread Pekka Paalanen 
On Mon, 23 Jan 2017 18:58:29 -0500
"Stephan Sokolow (You actually CAN reply)"  wrote:

> When I first became aware of this patch, my first response was 
> excitement that Wayland would finally take gamepad input into account 
> when doing screensaver suppression.
> 
> However, with the idea to pass file descriptors for 
> bottleneck-avoidance, I've been growing increasingly concerned that no 
> mention has been made of how it would interact with screensaver suppression.

Input device activity tracking is a very good point to raise.

Peter once mentioned me that event masking is a thing with evdev
nowadays. Even with file descriptor passing of evdev devices, I suppose
the compositor could keep copies open for itself, and subscribe only
some of the events. It would also be necessary for "system attention"
buttons (e.g. the PS button on PS3 controllers) if the kernel
does not expose a separate device.

Obviously it's a trade-off between the compositor listening vs. not,
but I believe both ways are possible even with file descriptor passing.
At least the compositor does not need to forward events even if it does
listen.

> P.S. Because my inbox is such a horrendous mess, it's not feasible for 
> me to subscribe to mailing lists and then filter down (and GMane NNTP 
> isn't working for me for some reason), so I'm watching this thread by 
> manually polling the list archive for updates twice a day.

You could subscribe and disable email delivery in the mailman settings
web page, that should allow you to post without getting the list mail,
I believe.


Thanks,
pq


pgptRdvRItj7C.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston 1/2] compositor-drm: update connectors with connector config

2017-02-06 Thread Pekka Paalanen 
On Mon, 6 Feb 2017 12:19:45 +
Daniel Stone  wrote:

> Hi Pekka,
> 
> On 6 February 2017 at 12:00, Pekka Paalanen  wrote:
> > On Mon, 6 Feb 2017 11:05:51 +
> > Daniel Stone  wrote:  
> >> I think we've got to choose between fixing it for 1.13 and removing it
> >> immediately after release (which I will happily do), or just ripping
> >> it out now.  
> >
> > I believe it works already as well as it ever has. Therefore any change
> > to how it works is something no user has ever seen before.
> >
> > I reviewed update_outputs() from Weston 1.10 release (a random pick)
> > and it seems that too uses --connector only for start-up, and never for
> > hotplug. The same for Weston 1.7, so I believe it has never worked any
> > better.
> >
> > If --connector didn't work *at all* currently, then I'd agree on just
> > removing it right now. OTOH, I have seen notes that --connector has
> > actually been used in the wild, which is why I'd say it's a major
> > feature to remove: it has a risk of user-visible breakage (unknown
> > command line option).  
> 
> OK, fair enough. I'd suggest we:
>   - merge Emre's two patches as legitimate bugfixes
>   - document --connector as deprecated in NEWS for 2.0 (must stop typing 1.13)
>   - remove it for 2.1 (or 3.0 or whatever)
> 
> How's that sound? For the record, these two patches are:
> Acked-by: Daniel Stone 

If you want to merge them, that's fine. I just wont bother myself.


Thanks,
pq


pgp0Wp9WK9B3z.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston] ivi-shell: add screen_remove_layer API

2017-02-06 Thread Pekka Paalanen 
On Mon, 30 Jan 2017 14:42:42 +
"Ucan, Emre (ADITG/SW1)"  wrote:

> Hi Pekka,
> 
> You are right. I will send second patch and add the function to end
> of the function list.
> 
> It is stated in ivi-shell/README that ivi_layout interface is stable.
> But I think should not be stable yet. Because we are missing some
> important features (e.g. output hotplugging) or some existing
> feautures are IMO unnecessary (e.g. orientation). Furthermore,
> libweston is changing quite fast. It gets new features in every
> release. If we want to use these new features in ivi-shell, we have
> to add new APIs time to time into ivi_layout interface.

So far libweston also breaks its ABI on every release (major version
bump). That covers also ivi-layout API in my opinion, but has not been
clearly documented I believe. The opinion may have even been different
at the time of writing the README, too - I think it was before
libweston was a thing.

In any case my standpoint is that ABI breaks are major features unless
there is a very good reason to break things closer to a release.

> I want to implement a shared library for ivi-shell (libweston-ivi)
> similar to weston-desktop library, when I have time. Then, it would
> be easier to handle ABI breakages. Because it will be parallely
> installable. Another advantage is that adding an API would be just a
> minor version bump, because it would be backwards compatible.

There are a lot of shared objects involved with ivi-shell already.
Would be nice to see some high level plans and architecture
documentation on how it all fits together and which parts can change
how. I fear there might be too many different interfaces that need to
be maintained.

Would you swallow ivi-layout into libweston-ivi.so?

Will hmi-controller.so be a plugin to weston, ivi-shell or
libweston-ivi.so?

Will the ivi-shell plugin remain with Weston, or move to libweston? Or
will it become libweston-ivi.so?

IVI is different from libweston-desktop: the latter needs considerable
code for handling the client-facing protocols and it implements many
practical details, while leaving the high-level window management to
the user (the desktop-shell plugin). IVI however has very little
client-facing protocol and all of window management is externalized to
controller plugins, so it's hard to see any analogue.

If your idea is to transform ivi-layout into libweston-ivi.so, merge
ivi-shell plugin into it, and change controller plugins to be on the
same level as the desktop-shell Weston plugin is, I think that might be
a good idea. A libweston-based compositor written purely for IVI would
not need a controller as a plugin at all, but just link to and use
libweston-ivi which offers the window management interfaces (ivi-layout
API).

I'm not asking you answer these questions here in this thread, but they
are things I think you would need to consider.


Thanks,
pq

PS. In my mind I have had the idea of turning main.c et al. into a
static convenience library and turning each shell plugin into a
separate executable instead. But, it's a lot of work for questionable
gain, and will have issues with weston-launch.


pgpu4peW2_KIu.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston 1/2] compositor-drm: update connectors with connector config

2017-02-06 Thread Daniel Stone 
Hi Pekka,

On 6 February 2017 at 12:00, Pekka Paalanen  wrote:
> On Mon, 6 Feb 2017 11:05:51 +
> Daniel Stone  wrote:
>> I think we've got to choose between fixing it for 1.13 and removing it
>> immediately after release (which I will happily do), or just ripping
>> it out now.
>
> I believe it works already as well as it ever has. Therefore any change
> to how it works is something no user has ever seen before.
>
> I reviewed update_outputs() from Weston 1.10 release (a random pick)
> and it seems that too uses --connector only for start-up, and never for
> hotplug. The same for Weston 1.7, so I believe it has never worked any
> better.
>
> If --connector didn't work *at all* currently, then I'd agree on just
> removing it right now. OTOH, I have seen notes that --connector has
> actually been used in the wild, which is why I'd say it's a major
> feature to remove: it has a risk of user-visible breakage (unknown
> command line option).

OK, fair enough. I'd suggest we:
  - merge Emre's two patches as legitimate bugfixes
  - document --connector as deprecated in NEWS for 2.0 (must stop typing 1.13)
  - remove it for 2.1 (or 3.0 or whatever)

How's that sound? For the record, these two patches are:
Acked-by: Daniel Stone 

Cheers,
Daniel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston 1/2] compositor-drm: update connectors with connector config

2017-02-06 Thread Pekka Paalanen 
On Mon, 6 Feb 2017 11:05:51 +
Daniel Stone  wrote:

> Hi,
> 
> On 6 February 2017 at 10:29, Pekka Paalanen  wrote:
> > On Thu, 2 Feb 2017 14:06:55 +
> > "Ucan, Emre (ADITG/SW1)"  wrote:  
> >> weston can be started with --connector option to be initialized
> >> with a particular output. But in the update_outputs this option
> >> is not considered and output is created for all the available
> >> connectors. This patch fixes this issue by considering
> >> the option for connectors in the update_outputs.  
> >
> > I would much rather see the whole --connector option removed than
> > anything to make it work "better".
> >
> > This is because the option works by DRM connector IDs, which a) are
> > very hard to find out and b) not guaranteed to be fixed. So it's really
> > just a debugging option that has outlived its purpose by five years or
> > so, IMO. I think it also gives a wrong impression about b).  
> 
> I cannot agree more.
> 
> > The modern way of defining connector states is weston.ini with its
> > [output] sections. We still don't have a way to specify the default
> > behaviour to "off" instead of "use the default/current mode". If such
> > an option is needed, I would be happy to see one added to weston.ini
> > where one could define the default behaviour for outputs not matched by
> > any named [output] section. Besides, this could be implemented already
> > with the libweston output configuration API in main.c.  
> 
> That would be a nice addition, yeah.
> 
> > Unfortunately, I consider the removal of --connector option a "major
> > feature", which means we can't do it anymore on this release cycle.  
> 
> Depends. If it's been broken throughout the entire cycle (three weeks
> since 1.12 release), you could make an argument that we effectively
> removed it then, and this is just a cleanup. You could probably even
> mostly keep a straight face whilst doing so.
> 
> I think we've got to choose between fixing it for 1.13 and removing it
> immediately after release (which I will happily do), or just ripping
> it out now.

Hi Daniel,

I believe it works already as well as it ever has. Therefore any change
to how it works is something no user has ever seen before.

I reviewed update_outputs() from Weston 1.10 release (a random pick)
and it seems that too uses --connector only for start-up, and never for
hotplug. The same for Weston 1.7, so I believe it has never worked any
better.

If --connector didn't work *at all* currently, then I'd agree on just
removing it right now. OTOH, I have seen notes that --connector has
actually been used in the wild, which is why I'd say it's a major
feature to remove: it has a risk of user-visible breakage (unknown
command line option).


Thanks,
pq


pgpQfNk38O1Ji.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH 1/2] compositor-drm: don't put y-inverted / interlaced / bottom-first dmabufs on overlays

2017-02-06 Thread Pekka Paalanen 
On Wed,  1 Feb 2017 15:28:23 -0500
Micah Fedke  wrote:

> This patch checks the attribute flags on incoming dmabufs and refuses to
> put them overlays if they have any of the flags set (currently:
> ZWP_LINUX_BUFFER_PARAMS_V1_FLAGS_Y_INVERT,
> ZWP_LINUX_BUFFER_PARAMS_V1_FLAGS_INTERLACED and
> ZWP_LINUX_BUFFER_PARAMS_V1_FLAGS_BOTTOM_FIRST), instead defaulting to
> the gl-renderer which can handle some of the flags.
> 
> This check should be superceded by buffer transforms, when they become
> available.
> ---
>  libweston/compositor-drm.c | 14 +-
>  1 file changed, 13 insertions(+), 1 deletion(-)
> 
> diff --git a/libweston/compositor-drm.c b/libweston/compositor-drm.c
> index 564e3244..a16136d3 100644
> --- a/libweston/compositor-drm.c
> +++ b/libweston/compositor-drm.c
> @@ -60,6 +60,7 @@
>  #include "vaapi-recorder.h"
>  #include "presentation-time-server-protocol.h"
>  #include "linux-dmabuf.h"
> +#include "linux-dmabuf-unstable-v1-server-protocol.h"
>  
>  #ifndef DRM_CAP_TIMESTAMP_MONOTONIC
>  #define DRM_CAP_TIMESTAMP_MONOTONIC 0x6
> @@ -1016,7 +1017,18 @@ drm_output_prepare_overlay_view(struct drm_output 
> *output,
>   .format = dmabuf->attributes.format
>   };
>  
> - if (dmabuf->attributes.n_planes != 1 || 
> dmabuf->attributes.offset[0] != 0)
> +/* XXX: TODO:
> + *
> + * Currently the buffer is rejected if any dmabuf attribute
> + * flag is set.  This keeps us from passing an inverted /
> + * interlaced / bottom-first buffer (or any other type that 
> may
> + * be added in the future) through to an overlay.  
> Ultimately,
> + * these types of buffers should be handled through buffer
> + * transforms and not as spot-checks requiring specific
> + * knowledge. */
> + if (dmabuf->attributes.n_planes != 1 ||
> +dmabuf->attributes.offset[0] != 0 ||
> + dmabuf->attributes.flags)
>   return NULL;
>  
>   bo = gbm_bo_import(b->gbm, GBM_BO_IMPORT_FD, _dmabuf,

R-b me and pushed:
   2779935..c889012  master -> master

Next time, please remember your S-o-b. :-)


Thanks,
pq


pgp2ljvAC12IV.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH 2/2] clients: teach simple-dmabuf-v4l to deal with flipped input

2017-02-06 Thread Pekka Paalanen 
On Wed,  1 Feb 2017 15:28:24 -0500
Micah Fedke  wrote:

> The v4l2 API can be queried to detect if the input video image is
> horizontally or vertically flipped. If the image is y-flipped, we can
> set the ZWP_LINUX_BUFFER_PARAMS_V1_FLAGS_Y_INVERT flag to notify the
> compositor.  If the image is h-flipped, we can only print a warning
> since linux_buffer_params_v1 does not support horizontal flipping.
> ---
>  clients/simple-dmabuf-v4l.c | 54 
> ++---
>  1 file changed, 46 insertions(+), 8 deletions(-)
> 
> diff --git a/clients/simple-dmabuf-v4l.c b/clients/simple-dmabuf-v4l.c
> index af25d0ea..e4e2d7c7 100644
> --- a/clients/simple-dmabuf-v4l.c
> +++ b/clients/simple-dmabuf-v4l.c
> @@ -351,21 +351,59 @@ static const struct zwp_linux_buffer_params_v1_listener 
> params_listener = {
>   create_failed
>  };

Hi Micah,

I only have some easy comments, it would be nice if someone could
double-check the V4L2 API usage. The functionality looks correct to me.

>  
> +static bool
> +check_v4l2_control(const int fd,

Since this seems to be hardcoded to boolean controls, how about calling
it check_v4l2_control_bool() instead?

> +   const struct v4l2_query_ext_ctrl *qectrl,
> +   const char *control_name,
> +   const int len,

I don't think 'len' is necessary, everything should be nul-terminated,
and we don't want to accidentally match a substring.

> +   const int expected_value)
> +{
> + struct v4l2_control ctrl;
> +
> + memset(, 0, sizeof(ctrl));
> + ctrl.id = qectrl->id;
> +
> + if (!(qectrl->flags & V4L2_CTRL_FLAG_DISABLED) &&
> +(qectrl->type == V4L2_CTRL_TYPE_BOOLEAN) &&
> +!strncmp(qectrl->name, control_name, len) &&
> +!xioctl(fd, VIDIOC_G_CTRL, ) &&
> +(ctrl.value == expected_value))

This pretty compactly written. Personally I'd prefer testing things a
bit more separately, to e.g. emphasize that there is a call to xioctl()
hidden in there. This is a small function where it is easy to just
return early when something doesn't match.

> + return true;
> + else
> + return false;
> +}
> +
>  static void
>  create_dmabuf_buffer(struct display *display, struct buffer *buffer)
>  {
>   struct zwp_linux_buffer_params_v1 *params;
>   uint64_t modifier;
> - uint32_t flags;
> + uint32_t lbp_flags;
>   unsigned i;
> + struct v4l2_query_ext_ctrl qectrl;
> + const unsigned int v4l2_qec_flags =
> +   V4L2_CTRL_FLAG_NEXT_CTRL | 
> V4L2_CTRL_FLAG_NEXT_COMPOUND;
> + const char *vflip_ctrl = "Vertical Flip";
> + const char *hflip_ctrl = "Horizontal Flip";
>  
>   modifier = 0;
> - flags = 0;
> -
> - /* XXX: apparently some webcams may actually provide y-inverted images,
> -  * in which case we should set
> -  * flags = ZWP_LINUX_BUFFER_PARAMS_V1_FLAGS_Y_INVERT
> -  */
> + lbp_flags = 0;
> +
> + /* handle relevant v4l2 controls */
> + memset(, 0, sizeof(qectrl));
> + qectrl.id |= v4l2_qec_flags;
> + while (!xioctl(display->v4l_fd, VIDIOC_QUERY_EXT_CTRL, )) {
> + if (check_v4l2_control(display->v4l_fd, , vflip_ctrl,
> +   strlen(vflip_ctrl), 0x1)) {
> + lbp_flags = ZWP_LINUX_BUFFER_PARAMS_V1_FLAGS_Y_INVERT;
> + printf ("\"%s\" control is set, inverting 
> Y\n",vflip_ctrl);
> + } else if (check_v4l2_control(display->v4l_fd, 
> ,hflip_ctrl,

Many missing spaces after commas.

> +  strlen(hflip_ctrl), 0x1)) {
> + printf ("\"%s\" control is set, but dmabuf output 
> cannot"
> +"be flipped horizontally\n", hflip_ctrl);
> + }
> + qectrl.id |= v4l2_qec_flags;
> + }
>  
>   params = zwp_linux_dmabuf_v1_create_params(display->dmabuf);
>   for (i = 0; i < display->format.num_planes; ++i)
> @@ -382,7 +420,7 @@ create_dmabuf_buffer(struct display *display, struct 
> buffer *buffer)
> display->format.width,
> display->format.height,
> display->drm_format,
> -   flags);
> +   lbp_flags);
>  }
>  
>  static int

Anyway, this patch does what I wanted it to do.


Thanks,
pq


pgpnVfQR8zB6j.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston 1/2] compositor-drm: update connectors with connector config

2017-02-06 Thread Daniel Stone 
Hi,

On 6 February 2017 at 10:29, Pekka Paalanen  wrote:
> On Thu, 2 Feb 2017 14:06:55 +
> "Ucan, Emre (ADITG/SW1)"  wrote:
>> weston can be started with --connector option to be initialized
>> with a particular output. But in the update_outputs this option
>> is not considered and output is created for all the available
>> connectors. This patch fixes this issue by considering
>> the option for connectors in the update_outputs.
>
> I would much rather see the whole --connector option removed than
> anything to make it work "better".
>
> This is because the option works by DRM connector IDs, which a) are
> very hard to find out and b) not guaranteed to be fixed. So it's really
> just a debugging option that has outlived its purpose by five years or
> so, IMO. I think it also gives a wrong impression about b).

I cannot agree more.

> The modern way of defining connector states is weston.ini with its
> [output] sections. We still don't have a way to specify the default
> behaviour to "off" instead of "use the default/current mode". If such
> an option is needed, I would be happy to see one added to weston.ini
> where one could define the default behaviour for outputs not matched by
> any named [output] section. Besides, this could be implemented already
> with the libweston output configuration API in main.c.

That would be a nice addition, yeah.

> Unfortunately, I consider the removal of --connector option a "major
> feature", which means we can't do it anymore on this release cycle.

Depends. If it's been broken throughout the entire cycle (three weeks
since 1.12 release), you could make an argument that we effectively
removed it then, and this is just a cleanup. You could probably even
mostly keep a straight face whilst doing so.

I think we've got to choose between fixing it for 1.13 and removing it
immediately after release (which I will happily do), or just ripping
it out now.

Cheers,
Daniel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston 2/2] compositor-drm: don't pass option_connector to create_outputs

2017-02-06 Thread Pekka Paalanen 
On Thu, 2 Feb 2017 14:06:56 +
"Ucan, Emre (ADITG/SW1)"  wrote:

> The connector option is a part of drm_backend struct.
> Therefore, it is not needed to pass it as an argument
> to create_outputs function.
> 
> Signed-off-by: Emre Ucan 
> ---
>  libweston/compositor-drm.c |9 -
>  1 file changed, 4 insertions(+), 5 deletions(-)
> 
> diff --git a/libweston/compositor-drm.c b/libweston/compositor-drm.c
> index 6d97b49..7b26e56 100644
> --- a/libweston/compositor-drm.c
> +++ b/libweston/compositor-drm.c
> @@ -2652,8 +2652,7 @@ destroy_sprites(struct drm_backend *backend)
>  }
>  
>  static int
> -create_outputs(struct drm_backend *b, uint32_t option_connector,
> -struct udev_device *drm_device)
> +create_outputs(struct drm_backend *b, struct udev_device *drm_device)
>  {
>   drmModeConnector *connector;
>   drmModeRes *resources;
> @@ -2677,8 +2676,8 @@ create_outputs(struct drm_backend *b, uint32_t 
> option_connector,
>   continue;
>  
>   if (connector->connection == DRM_MODE_CONNECTED &&
> - (option_connector == 0 ||
> -  connector->connector_id == option_connector)) {
> + (b->connector == 0 ||
> +  connector->connector_id == b->connector)) {
>   if (create_output_for_connector(b, resources,
>   connector, drm_device) 
> < 0) {
>   drmModeFreeConnector(connector);
> @@ -3216,7 +3215,7 @@ drm_backend_create(struct weston_compositor *compositor,
>  
>   b->connector = config->connector;
>  
> - if (create_outputs(b, config->connector, drm_device) < 0) {
> + if (create_outputs(b, drm_device) < 0) {
>   weston_log("failed to create output for %s\n", path);
>   goto err_udev_input;
>   }

Hi,

since the earlier patch that I didn't think was a good idea added the
member to drm_backend, this patch won't apply without it.


Thanks,
pq


pgpP_kndhsnzS.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

RE: How to do mode setting in Wayland

2017-02-06 Thread Zhu, Lingyun 
Hi, Guys

Is this possible to specify the output for a weston window?
E.g. When I connected 2 monitors (monitor A and monitor B) on my system, and I 
want to display a picture on monitor A.


Thanks,
Lingyun
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

RE: How to do mode setting in Wayland

2017-02-06 Thread Zhu, Lingyun 
Thank you very much.
It works.

Thanks,
Lingyun

-Original Message-
From: wayland-devel [mailto:wayland-devel-boun...@lists.freedesktop.org] On 
Behalf Of Emmanuel Gil Peyrot
Sent: Friday, December 23, 2016 11:59 PM
To: Zhu, Lingyun 
Cc: wayland-devel 
Subject: Re: How to do mode setting in Wayland

On Fri, Dec 23, 2016 at 08:59:20AM +, Zhu, Lingyun wrote:
> Hi,

Hi,

> 
> I'm trying to set mode for a monitor from 4K@60Hz to 4K@30Hz (all supported) 
> under wayland/weston.
> But it seems there's no api for doing this.

That’s correct.

> The only mode setting related api is wl_output::mode event, but it's a 
> notifying event.
> 
> How can I change the mode of a monitor under wayland/weston?

The mode can currently only be set at launch time, in the weston.ini 
configuration file, output section, in the mode option.

To set a specific refresh rate, you will have to generate a modeline using the 
`cvt` tool and paste that in the mode option, see `man weston.ini` and `man 
cvt` for more information.

> 
> 
> Thanks,
> Lingyun
> 

--
Emmanuel Gil Peyrot
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston 1/2] compositor-drm: update connectors with connector config

2017-02-06 Thread Pekka Paalanen 
On Thu, 2 Feb 2017 14:06:55 +
"Ucan, Emre (ADITG/SW1)"  wrote:

> weston can be started with --connector option to be initialized
> with a particular output. But in the update_outputs this option
> is not considered and output is created for all the available
> connectors. This patch fixes this issue by considering
> the option for connectors in the update_outputs.
> 
> Signed-off-by: Emre Ucan 
> ---
>  libweston/compositor-drm.c |   11 ++-
>  1 file changed, 10 insertions(+), 1 deletion(-)

Hi,

I would much rather see the whole --connector option removed than
anything to make it work "better".

This is because the option works by DRM connector IDs, which a) are
very hard to find out and b) not guaranteed to be fixed. So it's really
just a debugging option that has outlived its purpose by five years or
so, IMO. I think it also gives a wrong impression about b).

The modern way of defining connector states is weston.ini with its
[output] sections. We still don't have a way to specify the default
behaviour to "off" instead of "use the default/current mode". If such
an option is needed, I would be happy to see one added to weston.ini
where one could define the default behaviour for outputs not matched by
any named [output] section. Besides, this could be implemented already
with the libweston output configuration API in main.c.

Unfortunately, I consider the removal of --connector option a "major
feature", which means we can't do it anymore on this release cycle.


Thanks,
pq


pgpOQRUEYJGtC.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston v2] ivi-shell: add screen_remove_layer API

2017-02-06 Thread Pekka Paalanen 
On Mon, 30 Jan 2017 15:08:19 +
"Ucan, Emre (ADITG/SW1)"  wrote:

> It is analagous to layer_remove_surface API.
> The API removes a layer from the render order of
> the screen.
> 
> v2:
> add the new vfunc at the end of
> the ivi_layout_interface struct.
> 
> Signed-off-by: Emre Ucan 
> ---
>  ivi-shell/ivi-layout-export.h |   10 ++
>  ivi-shell/ivi-layout.c|   28 +++-
>  2 files changed, 37 insertions(+), 1 deletion(-)
> 
> diff --git a/ivi-shell/ivi-layout-export.h b/ivi-shell/ivi-layout-export.h
> index 2317d6e..50649e7 100644
> --- a/ivi-shell/ivi-layout-export.h
> +++ b/ivi-shell/ivi-layout-export.h
> @@ -541,6 +541,16 @@ struct ivi_layout_interface {
>   struct ivi_layout_layer *addlayer);
>  
>   /**
> +  * \brief Remove a ivi_layer to a weston_output which is currently 
> managed
> +  * by the service
> +  *
> +  * \return IVI_SUCCEEDED if the method call was successful
> +  * \return IVI_FAILED if the method call was failed
> +  */
> + int32_t (*screen_remove_layer)(struct weston_output *output,
> + struct ivi_layout_layer *removelayer);
> +
> + /**
>* \brief Sets render order of ivi_layers on a weston_output
>*
>* \return IVI_SUCCEEDED if the method call was successful

Hi,

nope, it's still in the middle here. It is the struct that matters, not
the order in which its members are initialized.

In fact, the order of setting the fields below is irrelevant, so there
you can pick any order that makes the most sense to you.


Thanks,
pq

> diff --git a/ivi-shell/ivi-layout.c b/ivi-shell/ivi-layout.c
> index b3e..21e4c1e 100644
> --- a/ivi-shell/ivi-layout.c
> +++ b/ivi-shell/ivi-layout.c
> @@ -1663,6 +1663,27 @@ ivi_layout_screen_add_layer(struct weston_output 
> *output,
>  }
>  
>  static int32_t
> +ivi_layout_screen_remove_layer(struct weston_output *output,
> + struct ivi_layout_layer *removelayer)
> +{
> + struct ivi_layout_screen *iviscrn;
> +
> + if (output == NULL || removelayer == NULL) {
> + weston_log("ivi_layout_screen_remove_layer: invalid 
> argument\n");
> + return IVI_FAILED;
> + }
> +
> + iviscrn = get_screen_from_output(output);
> +
> + wl_list_remove(>pending.link);
> + wl_list_init(>pending.link);
> +
> + iviscrn->order.dirty = 1;
> +
> + return IVI_SUCCEEDED;
> +}
> +
> +static int32_t
>  ivi_layout_screen_set_render_order(struct weston_output *output,
>  struct ivi_layout_layer **pLayer,
>  const int32_t number)
> @@ -2083,7 +2104,7 @@ static struct ivi_layout_interface ivi_layout_interface 
> = {
>   .layer_set_transition   = 
> ivi_layout_layer_set_transition,
>  
>   /**
> -  * screen controller interfaces
> +  * screen controller interfaces part1
>*/
>   .get_screens_under_layer= ivi_layout_get_screens_under_layer,
>   .screen_add_layer   = ivi_layout_screen_add_layer,
> @@ -2100,6 +2121,11 @@ static struct ivi_layout_interface 
> ivi_layout_interface = {
>*/
>   .surface_get_size   = ivi_layout_surface_get_size,
>   .surface_dump   = ivi_layout_surface_dump,
> +
> + /**
> +  * screen controller interfaces part2
> +  */
> + .screen_remove_layer= ivi_layout_screen_remove_layer,
>  };
>  
>  int



pgpXN0DJ7VzJV.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston 2/2] ivi-shell: simplfy commit_changes function

2017-02-06 Thread Pekka Paalanen 
On Mon, 30 Jan 2017 13:36:07 +
"Ucan, Emre (ADITG/SW1)"  wrote:

> It is a better idea to use one for loop instead
> of using three nested for loops.
> 
> We do not need to update the transformation of
> views according to the scenegraph. The important
> thing is that every visible view is updated before
> commit_changes function returns.
> 
> The first if statement checks, if the view is on
> the currently rendered scenegraph. The second if
> statement checks, if the view's layer or surface
> is visible. These checks ensure that we do not
> update the transformation matrix of a view, which
> is not visible on the screen.
> 
> Signed-off-by: Emre Ucan 
> ---
>  ivi-shell/ivi-layout.c |   39 ---
>  1 file changed, 20 insertions(+), 19 deletions(-)

Hi,

both are R-b me, and pushed with a little whilespace and spelling fix:
   819824d..2779935  master -> master


Thanks,
pq


pgpdR9MEm3k9d.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH] [weston, v4] weston.ini: Add natural scroll support to weston.ini This adds support for enabling/disabling natural scrolling via a boolean in weston.ini:

2017-02-06 Thread Pekka Paalanen 
On Mon, 6 Feb 2017 10:36:56 +1000
Peter Hutterer  wrote:

> On Sun, Feb 05, 2017 at 07:30:18PM -0500, Jiayi Zhao wrote:
> > ​​
> > Hmmm, after using udev_device_has_tag(udev_device, "ID_INPUT_TOUCHPAD"),
> > I'm getting linking errors. Quick google of this leads to: libraries on the
> > command line should be after the object files being compiled.
> > Is this a bug?  
> 
> come to think of it, tags are a bit different. you need
> udev_device_get_property_value() instead. and you need to make sure that
> libudev is linked in - that's where your linking errors come from.

Hi,

needing udev API raises further considerations.

A fundamental question is whether udev-using backends should actually
expose udev as part of their API to libweston users (main.c) or whether
it should expose its own abstraction. Since we (I, at least) do not
really have a good understanding what all things one might want, it
might be easier and more flexible to assume that udev will be part of
libweston's DRM backend specific API.

IOW, in compositor-drm.h, the configure_device vfunc should probably
get a new argument referring to the udev thing. This breaks the library
ABI, forcing a libweston major version bump.

Therefore when the DRM-backend is enabled, weston (main.c) should link
to libudev for using it, and the backend-specific API needs to grow
things to support the use of udev. This calls for configure.ac changes.

So far Weston has not been using libudev, which is why you got the
linker errors: it is not linked into Weston, it is only linked to the
specific backends.

Also, it has been possible to build Weston and libweston without
libudev by disabling the backends that depended on it. I'm not sure
supporting that is worthwhile, though, considering DRM is really the
main backend which already depends on libudev.

Looks like libinput is already required by main.c, so following that
example with libudev should be good.


Thanks,
pq

> > On Sun, Feb 5, 2017 at 7:20 PM, Peter Hutterer 
> > wrote:
> >   
> > > On Sun, Feb 05, 2017 at 07:13:04PM -0500, Jiayi Zhao wrote:  
> > > > How would ID_INPUT_TOUCHPAD work?
> > > > I have something like udev_device_has_tag(udev_device,  
> > > ID_INPUT_TOUCHPAD)  
> > > > Unfortunately, I'm not sure where this constant is declared and its  
> > > unable  
> > > > to find the tag. :/  
> > >
> > > it's a udev property name, so use it as a string, not a #define.
> > > value is either 1 or 0, so you do need to check for validity.
> > >
> > > Cheers,
> > >Peter
> > >  
> > > > On Jan 29, 2017 4:42 PM, "Peter Hutterer"   
> > > wrote:  
> > > >  
> > > > > On Fri, Jan 27, 2017 at 09:46:49PM -0500, Jiayi Zhao wrote:  
> > > > > > [libinput]
> > > > > > natural_scroll=true
> > > > > >
> > > > > > CHANGES:
> > > > > >  - libinput_device_config_scroll_has_natural_scroll() is no longer  
> > > > > compared to != 0  
> > > > > >  - added configuration option to weston.ini man page
> > > > > >
> > > > > > Signed-off-by: Jiayi Zhao 
> > > > > > ---
> > > > > >  compositor/main.c  | 13 +
> > > > > >  man/weston.ini.man |  3 +++
> > > > > >  weston.ini.in  |  1 +
> > > > > >  3 files changed, 17 insertions(+)



pgpmVLGYuD_T3.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland-protocols v3] linux-dmabuf: add immediate dmabuf import path

2017-02-06 Thread Varad Gautam 
Hi Pekka,

On Fri, Feb 3, 2017 at 8:39 PM, Pekka Paalanen
 wrote:
> On Tue, 31 Jan 2017 18:41:52 +0530
> Varad Gautam  wrote:
>
>> From: Varad Gautam 
>>
>> provide a mechanism that allows clients to import the added dmabufs
>> and immediately use the newly created wl_buffers without waiting on
>> an event. this is useful to clients that are sure of their import
>> request succeeding, and wish to avoid the wl_buffer communication
>> roundtrip.
>>
>> bump zwp_linux_dmabuf_v1, zwp_linux_buffer_params_v1 interface
>> versions.
>>
>> v2: specify using incorrectly imported dmabufs as undefined behavior
>> instead of sending success/failure events. (pq, daniels)
>> v3: preserve the optional protocol error added in v2 and explicitly
>> state the outcome of import success or failure (pq)
>>
>> Signed-off-by: Varad Gautam 
>> ---
>>  unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml | 58 
>> +++---
>>  1 file changed, 51 insertions(+), 7 deletions(-)
>>
>> diff --git a/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml 
>> b/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml
>> index ed2c4bb..ddb49cc 100644
>> --- a/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml
>> +++ b/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml
>> @@ -24,13 +24,13 @@
>>  DEALINGS IN THE SOFTWARE.
>>
>>
>> -  
>> +  
>>  
>>Following the interfaces from:
>>
>> https://www.khronos.org/registry/egl/extensions/EXT/EGL_EXT_image_dma_buf_import.txt
>>and the Linux DRM sub-system's AddFb2 ioctl.
>>
>> -  This interface offers a way to create generic dmabuf-based
>> +  This interface offers ways to create generic dmabuf-based
>>wl_buffers. Immediately after a client binds to this interface,
>>the set of supported formats is sent with 'format' events.
>>
>> @@ -56,10 +56,23 @@
>>To create a wl_buffer from one or more dmabufs, a client creates a
>>zwp_linux_dmabuf_params_v1 object with a 
>> zwp_linux_dmabuf_v1.create_params
>>request. All planes required by the intended format are added with
>> -  the 'add' request. Finally, a 'create' request is issued. The server
>> -  will reply with either a 'created' event which provides the final
>> -  wl_buffer or a 'failed' event saying that it cannot use the dmabufs
>> -  provided.
>> +  the 'add' request. Finally, a 'create' or 'create_immed' request is
>> +  issued, which has the following outcome depending on the import 
>> success.
>> +
>> +  The 'create' request,
>> +  - on success, triggers a 'created' event which provides the final
>> +wl_buffer to the client.
>> +  - on failure, triggers a 'failed' event to convey that the server
>> +cannot use the dmabufs received from the client.
>> +
>> +  For the 'create_immed' request,
>> +  - on success, the server immediately imports the added dmabufs to
>> +create a wl_buffer. No event is sent from the server in this case.
>> +  - on failure, the server can choose to either:
>> +- terminate the client by raising a fatal error.
>> +- create an invalid wl_buffer handle and send a 'failed' event to
>> +  the client. The result of using this invalid wl_buffer in the
>> +  client is left implementation-defined by the protocol.
>
> Hi,
>
> I would phrase the latter as:
>
> - Mark the wl_buffer as failed and send a 'failed' event to the
>   client. If the client uses a failed wl_buffer as an argument
>   to any request, the behaviour is compositor
>   implementation-defined.
>

ack, will fix.

>>
>>Warning! The protocol described in this file is experimental and
>>backward incompatible changes may be made. Backward compatible changes
>> @@ -105,7 +118,7 @@
>>  
>>
>>
>> -  
>> +  
>>  
>>This temporary object is a collection of dmabufs and other
>>parameters that together form a single logical buffer. The temporary
>> @@ -138,6 +151,9 @@
>>   summary="invalid width or height"/>
>>>   summary="offset + stride * height goes out of dmabuf bounds"/>
>> +  > + summary="invalid wl_buffer resulted from importing dmabufs from
>> +   the given buffer_params"/>
>
> I might have called it "import_failure". Not a big deal.
>>  
>>
>>  
>> @@ -269,6 +285,34 @@
>>  zlinux_buffer_params object.
>>
>>  
>> +
>> +
>> +  
>> +This asks for immediate creation of a wl_buffer by importing the
>> +added dmabufs.
>> +
>> +In case of import success, no event is sent from the server, and the
>> +wl_buffer is ready to be used by the client.
>> +
>> +Upon import failure, either of the following may happen, as seen fit
>> +by the implementation:
>> +-