Re: Inter-client surface embedding
On Mon, Feb 17, 2014 at 10:59:11PM +, Mark Thomas wrote: On Mon, 17 Feb 2014, Pekka Paalanen wrote: On Mon, 17 Feb 2014 00:04:19 + (GMT) Mark Thomas mark-wayland-de...@efaref.net wrote: - The subsurface has separate focus from the main window surface. For the usual use cases of embedding like this, you'd prefer the parent surface to remain focused (or at least, appear focused) while the embedded surface is being interacted with. Not sure if this is a general feature of subsurfaces, nor what could be done about it. set an empty input region, and the input events will fall through the surface. So you intend that the embedded client never gets input for the embedded surface directly? I think that the embedded client should still get input as normal, however the surface that it's embedded within should still appear to be focussed. I guess this is a shell interface question, and will probably need a shell interface extension. I'll think about this more later on when I come round to writing the shell plugin that I'll undoubtedly need. Did you know about the earlier attempts on this? I think you should be able to find some discussion or a proposal by searching the wayland-devel@ archives for foreign surface protocol, IIRC. At that time, the conclusion was to use a nested mini-compositor approach instead, which is demoed in weston clients as weston-nested. I did not. That's quite frustrating, I could have saved myself some time. I went back and looked and none of the posts mentioned embed or plug/socket so that's why I didn't find them. :( Do you know if any code came about from the foreign surface proposals? Hi, I did the previous proposal first called logical surfaces and then foreign surfaces. I had a proof-of-concept implementation, but did not finalize nor publish it as the discussion concluded that it was not the way forward, instead favoring the nested compositor approach. Jonas The nested mini-compositor example doesn't build for me as I don't have working EGL, so I never even noticed it! Reading about it the approach seems to be more suited to nested application situations, e.g. a web browser embedding a document viewer. For the panel use case it seems like the wrong approach, as the embedded panel objects are merely fastened to the panel like badges, rather than part of the panel itself. It seems a shame to reimplement a compositor in the panel when we've already got a perfectly good compositor to use. I see your protocol definition lacks all documentation on how it is supposed to be used and implemented. A verbal description would be nice, giving an overview. I did try to give a quick overview in the email, but it was late last night and I may not have been clear. I've pushed some doc updates to the protocol.xml file my git repo. But in terms of Jonas Ådahl's proposal, my protocol works the other way round: A creates a main surface A creates a hole on that surface and sets its position and size A gets the uid (handle) from the server A passes that uid to B via IPC B creates a surface B creates a plug on that surface with the uid it got from A B receives a configure event from the server with the size of the hole B creates a buffer of the correct size and renders its image to the surface How do you handle glitch-free resizing? Sub-surfaces handle glitch-free resizing by temporarily changing the sub-surface into synchronized mode, assuring the sub-surface has new content in the correct new size, and then atomically commits the whole tree of sub-surfaces with a commit to the root wl_surface. Do you have any synchronization guarantees like that? With separate processes cooperating to create a single window it will be even more important than with the existing sub-surfaces case, and you will need more IPC between the two clients. Using client1-client2 IPC would be more efficient than client1-server-client2. I don't. Sorting out glitch-free interactive resizing is delegated to the clients, although you can get pretty good glitchy resizing by B repainting whenever it receives the configure event. My anticipated use case is applets inside panels, which aren't typically resized, so this implementation should be sufficient. Have you considered if your use case could be better served by moving some functionality into a special DE-specific client (e.g. weston-desktop-shell) and having separate protocol (an alternative shell interface) for panel clients to tell their wl_surface needs to be embeded into the panel, rather than implementing a generic mechanism where you need to solve all corner-cases in a generic way? If the protocol extension was designed particularly for panels, you might have an easy way out by defining special resize behaviour which would avoid most client-client negotiation. My plan was to patch Gtk3 to implement GtkPlug and GtkSocket in
Re: Core protocol change; [RFC v2] Wayland presentation extension
Hi Jason, thanks for the reply. I think I wrote more like a flamebait than a solution there. After sleeping over it and discussing with Axel, I think changing the existing core protocol behaviour is not appropriate, and we need to find another way around this. More below. On Mon, 17 Feb 2014 10:30:54 -0600 Jason Ekstrand ja...@jlekstrand.net wrote: On Feb 17, 2014 2:35 AM, Pekka Paalanen ppaala...@gmail.com wrote: Hi, there is one important thing in the below spec I really need to highlight! See further below. On Thu, 30 Jan 2014 17:35:17 +0200 Pekka Paalanen ppaala...@gmail.com wrote: Hi, it's time for a take two on the Wayland presentation extension. 1. Introduction The v1 proposal is here: http://lists.freedesktop.org/archives/wayland-devel/2013-October/011496.html In v2 the basic idea is the same: you can queue frames with a target presentation time, and you can get accurate presentation feedback. All the details are new, though. The re-design started from the wish to handle resizing better, preferably without clearing the buffer queue. All the changed details are probably too much to describe here, so it is maybe better to look at this as a new proposal. It still does build on Frederic's work, and everyone who commented on it. Special thanks to Axel Davy for his counter-proposal and fighting with me on IRC. :-) Some highlights: - Accurate presentation feedback is possible also without queueing. - You can queue also EGL-based rendering, and get presentation feedback if you want. Also EGL can do this internally, too, as long as EGL and the app do not try to use queueing at the same time. - More detailed presentation feedback to better allow predicting future display refreshes. - If wl_viewport is used, neither video resolution changes nor surface (window) size changes alone require clearing the queue. Video can continue playing even during resizes. The protocol interfaces are arranged as global.method(wl_surface, ...) just for brewity. We could as well do the factory approach: o = global.get_presentation(wl_surface) o.method(...) Or if we wanted to make it a mandatory part of the Wayland core protocol, we could just extend wl_surface itself: wl_surface.method(...) and put the clock_id event in wl_compositor. That all is still open and fairly uninteresting, so let's concentrate on the other details. The proposal refers to wl_viewport.set_source and wl_viewport.destination requests, which do not yet exist in the scaler protocol extension. These are just the wl_viewport.set arguments split into separate src and dst requests. Here is the new proposal, some design rationale follows. Please, do ask why something is designed like it is if it puzzles you. I have a load of notes I couldn't clean up for this email. This does not even intend to completely solve all XWayland needs, but for everything native on Wayland I hope it is sufficient. 2. The protocol specification ?xml version=1.0 encoding=UTF-8? protocol name=presentation_timing copyright Copyright © 2013-2014 Collabora, Ltd. Permission to use, copy, modify, distribute, and sell this software and its documentation for any purpose is hereby granted without fee, provided that the above copyright notice appear in all copies and that both that copyright notice and this permission notice appear in supporting documentation, and that the name of the copyright holders not be used in advertising or publicity pertaining to distribution of the software without specific, written prior permission. The copyright holders make no representations about the suitability of this software for any purpose. It is provided as is without express or implied warranty. THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. /copyright interface name=presentation version=1 description summary=timed presentation related wl_surface requests Since this spec doc is a wall of text, I'll add some headings here to make it more readable. I have these headings in my WIP branch as xml comments. The WIP xml file is here:
Re: [PATCH libinput 1/2] Hook up libevdev as backend
On 18 February 2014 07:09, Peter Hutterer peter.hutte...@who-t.net wrote: libevdev wraps the various peculiarities of the evdev kernel API into a type-safe API. It also buffers the device so checking for specific features at a later time is easier than re-issuing the ioctls. Plus, it gives us almost free support for SYN_DROPPED events (in the following patch). This patch switches all the bit checks over to libevdev and leaves the event processing as-is. Makes it easier to review. This looks fine to me. Can we also add a libevdev_set_clock_id(device-evdev, CLOCK_MONOTONIC); on device creation? CLOCK_MONOTONIC is already a hard dependency in configure.ac and it's required for good interoperability between xwayland (which uses it for its time stamps) and mutter. Rui ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC] libinput configuration interface
On Mon, 03 Feb 2014 11:02:42 +1000, Peter Hutterer wrote: tbh, I'm not planning to support every potential option under the sun. There's a fine and rather blurry line between what is a preference and what is merely configuration because we can't commit to a single default. I'd rather have less configuration options and support those well and do the synaptics approach of supporting everything but being quite bad at how the various options interact. snip As for the softbuttons config items, I'm somewhat leaning towards finger movement in the button areas, but no clicks outside the button area. And to actually trigger a button, you need to start inside the button area - which becomes easier when you have proper finger tracking (synaptics currently doesn't). Does that imply the following use case will be supported? Being used to TP trackpoints, I am using the index finger outside the button area (on a touchpad that doubles as one hardware button) and the thumb to click. I'd expect to able to move the pointer with the index finger while clicking, disregarding slight thumb movements while doing so. This seems to very difficult to archieve (if at all) with the synaptics driver; the points jumps widely, especially if the index finger is removed from the touch pad immediately before clicking. I can imagine that this boils down to having areas insensitive to motion, but still working as softbuttons. Dominic ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Core protocol change; [RFC v2] Wayland presentation extension
Hi, If you read the above paragraph carefully, you see that the last sentence CHANGES EXISTING WAYLAND CORE PROTOCOL BEHAVIOUR. The change is very subtle. It means, that without a wl_surface.attach, the buffer state is no longer applied on commit at all! To recap, the buffer state is: - frame callbacks (!) - set_buffer_transform - set_buffer_scale - the src_* arguments of wl_viewport.set The reason is explained in my recent email: http://lists.freedesktop.org/archives/wayland-devel/2014-February/013293.html An immediate commit without an attach should not apply any buffer state, because previous queueing of frames may have left buffer state that is incorrect for the currently showing buffer. Immediate commits without attach are used to update surface (and shell!) state, and applying incorrect buffer state could cause a visual glitch. We could claim, that this change in the core protocol exists only if the presentation extension is advertised by the server, but that would cause a lot more work to fix clients that get bit by this change, rather than fix the clients to always attach a wl_buffer when they want to change buffer state, even if it is the same buffer they just attached and committed already. Therefore I would like to bring the concepts of surface state and buffer state to the core protocol, and have the core procotol define that buffer state is applied only if there is an attach. In the past, we already changed the wl_surface.attach semantics to not re-attach the current buffer again, when there is a wl_surface.commit. The practical consequence of that was that a commit without an attach cannot cause any wl_buffer on this surface to become reserved and readable by the server, and hence no (new) wl.buffer.release would be posted either. That means that clients already need to re-attach the same wl_buffer again, if they changed the buffer contents and want to show the new image. I think this should mitigate the impact of the core protocol change. I guess the only interesting case is the frame callback, and whether anyone (ab)uses it without an attach. Would this proposition be acceptable? Thanks, pq As Jason pointed, it's useful to be able to do frame+commit when we want, outside of the part of the program doing attach+damage+commit, and get the frame callback. I agree the definition of the frame callback should be clarified though. I think a clarification of frame shouldn't break existing programs. I don't see the point of queuing frame callbacks, and that should be more apparent if we change frame meaning. I've seen you proposed the change: - A client can request a frame callback even without an attach, - damage, or any other state changes. wl_surface.commit triggers - display update, so the callback event will arrive after the next - output refresh where the surface is visible. - Why not replace that by: A client can request a frame callback even without an attach, damage, or any other state changes. The frequency at which the frame callbacks are called by the compositor is not defined, but the client can expect it to be similar to the refresh rate if the surface is focused and visible on the screen. Axel Davy ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH libinput] evdev: fix device_transform_ functions
On Tue, Feb 18, 2014 at 02:28:53PM +1000, Peter Hutterer wrote:
On Mon, Feb 17, 2014 at 01:42:52PM -0500, Benjamin Tissoires wrote:
X and Y are li_fixed_t, which is 24.8 fixed point real number.
li_fixed_t max is thus ~8388607.
On a touchscreen with a range of 32767 values (like a 3M sensor), and
mapped on monitor with a resolution of 1920x1080, we currently have:
(x - li_fixed_from_int(device-abs.min_x)) * width == 62912640
which is 7 times bigger than li_fixed_t max.
To keep the precision of the sensor, first compute the uniformized
coordinate (in range 0 .. 1.0) of the touch point, then multiply it
by the screen dimension, and revert it to a li_fixed_t.
Signed-off-by: Benjamin Tissoires benjamin.tissoi...@gmail.com
---
Hi,
I have hit this problem by playing with a touchscreen reporting 4096
values, on
xf86-input-libinput. xf86-input-libinput does not use the real screen size,
but
0x instead. This allows to report a touchscreen with a range of 128
values
to work properly :(
I went through the multitouch device database, and took one example of a
more
real use-case (xf86-input-libinput is still in an early shape).
fwiw, this is exactly the type of use-case where it would be simple and
worth it to knock up a test for a single device and make sure that the
coordinates are correct. which gives us a nice reproducer and prevents us
from errors like this in the future.
src/evdev.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/evdev.c b/src/evdev.c
index d8dff65..0d033b8 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -91,8 +91,9 @@ evdev_device_transform_x(struct evdev_device *device,
li_fixed_t x,
uint32_t width)
{
- return (x - li_fixed_from_int(device-abs.min_x)) * width /
+ double x_scaled = (li_fixed_to_double(x) - device-abs.min_x) /
(device-abs.max_x - device-abs.min_x + 1);
+ return li_fixed_from_double(x_scaled * width);
A simple 1L * should suffice, right?
It would if 1L means 64 bit, but that is not the case on all platforms.
A cast to uint64_t is enough for this case though.
Jonas
Cheers,
Peter
}
li_fixed_t
@@ -100,8 +101,9 @@ evdev_device_transform_y(struct evdev_device *device,
li_fixed_t y,
uint32_t height)
{
- return (y - li_fixed_from_int(device-abs.min_y)) * height /
+ double y_scaled = (li_fixed_to_double(y) - device-abs.min_y) /
(device-abs.max_y - device-abs.min_y + 1);
+ return li_fixed_from_double(y_scaled * height);
}
static void
--
1.8.5.3
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH libinput 2/2] test: Add scale li_fixed overflow test
Add a test case and test device that checks if the scale transform can
handle high resolution devices and output monitor resolutions.
The test case is created in a way that it will fail if the coordinate
transform expression will overflow if only 32 bit integer data
containers are used.
Signed-off-by: Jonas Ådahl jad...@gmail.com
---
fwiw, this is exactly the type of use-case where it would be simple and
worth it to knock up a test for a single device and make sure that the
coordinates are correct. which gives us a nice reproducer and prevents us
from errors like this in the future.
And here is such a test case. It will fail as is, but pass if either the
expression uses 64 bit integers or doubles.
Jonas
test/Makefile.am| 1 +
test/litest-generic-highres-touch.c | 139
test/litest.c | 2 +
test/litest.h | 1 +
test/touch.c| 40 ++-
5 files changed, 182 insertions(+), 1 deletion(-)
create mode 100644 test/litest-generic-highres-touch.c
diff --git a/test/Makefile.am b/test/Makefile.am
index 59687f6..4b923aa 100644
--- a/test/Makefile.am
+++ b/test/Makefile.am
@@ -14,6 +14,7 @@ liblitest_la_SOURCES = \
litest-synaptics.c \
litest-trackpoint.c \
litest-wacom-touch.c \
+ litest-generic-highres-touch.c \
litest.c
run_tests = test-udev test-path test-pointer test-touch
diff --git a/test/litest-generic-highres-touch.c
b/test/litest-generic-highres-touch.c
new file mode 100644
index 000..bd326ce
--- /dev/null
+++ b/test/litest-generic-highres-touch.c
@@ -0,0 +1,139 @@
+/*
+ * Copyright © 2013 Red Hat, Inc.
+ * Copyright © 2014 Jonas Ådahl
+ *
+ * Permission to use, copy, modify, distribute, and sell this software and its
+ * documentation for any purpose is hereby granted without fee, provided that
+ * the above copyright notice appear in all copies and that both that copyright
+ * notice and this permission notice appear in supporting documentation, and
+ * that the name of the copyright holders not be used in advertising or
+ * publicity pertaining to distribution of the software without specific,
+ * written prior permission. The copyright holders make no representations
+ * about the suitability of this software for any purpose. It is provided as
+ * is without express or implied warranty.
+ *
+ * THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS SOFTWARE,
+ * INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO
+ * EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY SPECIAL, INDIRECT OR
+ * CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE,
+ * DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER
+ * TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE
+ * OF THIS SOFTWARE.
+ */
+
+#include config.h
+
+#include litest.h
+#include litest-int.h
+#include libinput-util.h
+
+void litest_generic_highres_touch_setup(void)
+{
+ struct litest_device *d =
+ litest_create_device(LITEST_GENERIC_HIGHRES_TOUCH);
+ litest_set_current_device(d);
+}
+
+void
+litest_generic_highres_touch_touch_down(struct litest_device *d,
+ unsigned int slot,
+ int x, int y)
+{
+ static int tracking_id;
+ struct input_event *ev;
+ struct input_event down[] = {
+ { .type = EV_ABS, .code = ABS_X, .value = x },
+ { .type = EV_ABS, .code = ABS_Y, .value = y },
+ { .type = EV_ABS, .code = ABS_MT_SLOT, .value = slot },
+ { .type = EV_ABS, .code = ABS_MT_TRACKING_ID, .value =
++tracking_id },
+ { .type = EV_ABS, .code = ABS_MT_POSITION_X, .value = x },
+ { .type = EV_ABS, .code = ABS_MT_POSITION_Y, .value = y },
+ { .type = EV_KEY, .code = BTN_TOUCH, .value = 1 },
+ { .type = EV_SYN, .code = SYN_REPORT, .value = 0 },
+ };
+
+ down[0].value = litest_scale(d, ABS_X, x);
+ down[1].value = litest_scale(d, ABS_Y, y);
+ down[4].value = litest_scale(d, ABS_X, x);
+ down[5].value = litest_scale(d, ABS_Y, y);
+
+ ARRAY_FOR_EACH(down, ev)
+ litest_event(d, ev-type, ev-code, ev-value);
+}
+
+void
+litest_generic_highres_touch_move(struct litest_device *d,
+ unsigned int slot,
+ int x, int y)
+{
+ struct input_event *ev;
+ struct input_event move[] = {
+ { .type = EV_ABS, .code = ABS_MT_SLOT, .value = slot },
+ { .type = EV_ABS, .code = ABS_X, .value = x },
+ { .type = EV_ABS, .code = ABS_Y, .value = y },
+ { .type = EV_ABS, .code = ABS_MT_POSITION_X, .value = x },
+ { .type = EV_ABS, .code = ABS_MT_POSITION_Y, .value = y },
+
[PATCH libinput 1/2] test: Fix touch_down in wacom touch test device
Signed-off-by: Jonas Ådahl jad...@gmail.com --- test/litest-wacom-touch.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/test/litest-wacom-touch.c b/test/litest-wacom-touch.c index a33e085..464d541 100644 --- a/test/litest-wacom-touch.c +++ b/test/litest-wacom-touch.c @@ -54,8 +54,8 @@ litest_wacom_touch_touch_down(struct litest_device *d, down[0].value = litest_scale(d, ABS_X, x); down[1].value = litest_scale(d, ABS_Y, y); - down[5].value = litest_scale(d, ABS_X, x); - down[6].value = litest_scale(d, ABS_Y, y); + down[4].value = litest_scale(d, ABS_X, x); + down[5].value = litest_scale(d, ABS_Y, y); ARRAY_FOR_EACH(down, ev) litest_event(d, ev-type, ev-code, ev-value); -- 1.8.3.2 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Inter-client surface embedding
On 02/18/2014 11:09 AM, Mark Thomas wrote: I think the above description can be greatly simplified by removing the hole and plug objects and just using a subsurface: A creates a main surface A creates a subsurface for the hole A gets the uid of the subsurface from the compositor A passes that uid to B via IPC B uses this uid to get access to the subsurface B can now attach buffers and do other actions to the subsurface The hole and plug are meaningful objects and are needed, at least server-side, for some associated state. They're also helpful for limiting the amount of uid-dipping a client can do, as only holes and plugs have uids. I proposed that the uid be an encrypted number so clients can't guess them (or dipping as you call it). Basically if the server is asked for the object for a given uid it fails if it is not a number recently delivered by it to another client. Otherwise you are going to have to create a hole and plug object for every single Wayland object. Also you can't create a subsurface without both surfaces available, so there is a chicken-and-egg issue, too. I don't understand this. Obviously when the subsurface is created there is only one surface available (the parent) because the subsurface is not created yet. That is why I have A create the subsurface. B is still in charge of the buffers so there seems to be no problem here. Having thought about it, I think I'm in agreement with Pekka and the others that a generic interface is probably not appropriate, as the requirements change depending on the use case. What's probably more useful is making it easy for shell plugins to do it the way they want. So that's my plan. I don't like the idea that we are saying that things like Firefox have to be shell plugins. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston v2 6/6] tests: Properly report skipped tests
On Fri, Feb 07, 2014 at 09:34:48AM +0100, Emilio Pozuelo Monfort wrote:
From: Emilio Pozuelo Monfort emilio.pozu...@collabora.co.uk
We were calling exit(0) when tests were skipped, which counted
them as passed instead of skipped. Fix this by properly exiting
with 77 (which is what automake expects for skipped tests) from
the tests themselves, then returning 77 again from weston-test-runner
if all the tests were skipped. Finally the weston-test.so module
catches weston-test-runner's exit code and uses it as an exit code,
which is what automake will see and use.
All 6 patches applied, thanks.
Kristian
Signed-off-by: Emilio Pozuelo Monfort emilio.pozu...@collabora.co.uk
---
tests/weston-test-client-helper.c | 8 +---
tests/weston-test-runner.c| 41
---
tests/weston-test.c | 6 ++
3 files changed, 41 insertions(+), 14 deletions(-)
diff --git a/tests/weston-test-client-helper.c
b/tests/weston-test-client-helper.c
index 399aa44..186b395 100644
--- a/tests/weston-test-client-helper.c
+++ b/tests/weston-test-client-helper.c
@@ -505,9 +505,11 @@ skip(const char *fmt, ...)
vfprintf(stderr, fmt, argp);
va_end(argp);
- /* automake tests uses exit code 77, but we don't have a good
- * way to make weston exit with that from here. */
- exit(0);
+ /* automake tests uses exit code 77. weston-test-runner will see
+ * this and use it, and then weston-test's sigchld handler (in the
+ * weston process) will use that as an exit status, which is what
+ * automake will see in the end. */
+ exit(77);
}
static void
diff --git a/tests/weston-test-runner.c b/tests/weston-test-runner.c
index 4274b39..ef45bae 100644
--- a/tests/weston-test-runner.c
+++ b/tests/weston-test-runner.c
@@ -32,6 +32,8 @@
#include signal.h
#include weston-test-runner.h
+#define SKIP 77
+
extern const struct weston_test __start_test_section, __stop_test_section;
static const struct weston_test *
@@ -67,6 +69,7 @@ static int
exec_and_report_test(const struct weston_test *t, void *test_data, int
iteration)
{
int success = 0;
+ int skip = 0;
int hardfail = 0;
siginfo_t info;
@@ -91,6 +94,8 @@ exec_and_report_test(const struct weston_test *t, void
*test_data, int iteration
fprintf(stderr, exit status %d, info.si_status);
if (info.si_status == EXIT_SUCCESS)
success = 1;
+ else if (info.si_status == SKIP)
+ skip = 1;
break;
case CLD_KILLED:
case CLD_DUMPED:
@@ -106,7 +111,10 @@ exec_and_report_test(const struct weston_test *t, void
*test_data, int iteration
if (success !hardfail) {
fprintf(stderr, , pass.\n);
return 1;
- } else {
+ } else if (skip) {
+ fprintf(stderr, , skip.\n);
+ return SKIP;
+ } else {
fprintf(stderr, , fail.\n);
return 0;
}
@@ -114,13 +122,16 @@ exec_and_report_test(const struct weston_test *t, void
*test_data, int iteration
/* Returns number of tests and number of pass / fail in param args */
static int
-iterate_test(const struct weston_test *t, int *passed)
+iterate_test(const struct weston_test *t, int *passed, int *skipped)
{
- int i;
+ int ret, i;
void *current_test_data = (void *) t-table_data;
for (i = 0; i t-n_elements; ++i, current_test_data +=
t-element_size)
{
- if (exec_and_report_test(t, current_test_data, i))
+ ret = exec_and_report_test(t, current_test_data, i);
+ if (ret == SKIP)
+ ++(*skipped);
+ else if (ret)
++(*passed);
}
@@ -132,6 +143,7 @@ int main(int argc, char *argv[])
const struct weston_test *t;
int total = 0;
int pass = 0;
+ int skip = 0;
if (argc == 2) {
const char *testname = argv[1];
@@ -149,19 +161,26 @@ int main(int argc, char *argv[])
exit(EXIT_FAILURE);
}
- int number_passed_in_test = 0;
- total += iterate_test(t, number_passed_in_test);
+ int number_passed_in_test = 0, number_skipped_in_test = 0;
+ total += iterate_test(t, number_passed_in_test,
number_skipped_in_test);
pass += number_passed_in_test;
+ skip += number_skipped_in_test;
} else {
for (t = __start_test_section; t __stop_test_section; t++) {
- int number_passed_in_test = 0;
- total += iterate_test(t, number_passed_in_test);
+ int number_passed_in_test = 0, number_skipped_in_test =
0;
+ total += iterate_test(t, number_passed_in_test,
number_skipped_in_test);
Re: [PATCH weston.ini.man] Improvement of weston.ini.man. Add key:shell and remove tablet-shell.
On Sat, Feb 08, 2014 at 04:44:14PM +0900, Nobuhiko Tanibata wrote: Add key:shell to CORE SECTION and move a example of desktop-shell from key:modules to key:shell. Add cms-colord.so to key:modules of CORE SECTION. Signed-off-by: Nobuhiko Tanibata nobuhiko_tanib...@xddp.denso.co.jp Thank you, patch applied. I amended the commit to remove the 0001-Improvement-of-weston.ini.man.patch file that snug in there. Kristian --- 0001-Improvement-of-weston.ini.man.patch | 50 man/weston.ini.man | 17 +-- 2 files changed, 64 insertions(+), 3 deletions(-) create mode 100644 0001-Improvement-of-weston.ini.man.patch diff --git a/0001-Improvement-of-weston.ini.man.patch b/0001-Improvement-of-weston.ini.man.patch new file mode 100644 index 000..bcaad57 --- /dev/null +++ b/0001-Improvement-of-weston.ini.man.patch @@ -0,0 +1,50 @@ +From 619cd4c17aa1f856522aad7d6f68f504e0007257 Mon Sep 17 00:00:00 2001 +From: Nobuhiko Tanibata nobuhiko_tanib...@xddp.denso.co.jp +Date: Fri, 7 Feb 2014 14:18:48 +0900 +Subject: [PATCH weston.ini.man] Improvement of weston.ini.man Add key:shell to + CORE SECTION and move a example of desktop-shell from key:modules to + key:shell. Add cms-colord.so to key:modules of CORE SECTION. + +Signed-off-by: Nobuhiko Tanibata nobuhiko_tanib...@xddp.denso.co.jp +--- + man/weston.ini.man | 17 ++--- + 1 file changed, 14 insertions(+), 3 deletions(-) + +diff --git a/man/weston.ini.man b/man/weston.ini.man +index ce3f928..7b9ce0a 100644 +--- a/man/weston.ini.man b/man/weston.ini.man +@@ -92,16 +92,27 @@ The + .B core + section is used to select the startup compositor modules. + .TP 7 +-.BI modules= desktop-shell.so,xwayland.so +-specifies the modules to load (string). Available modules in the ++.BI shell= desktop-shell.so ++specifies the shell to load (string). Available shells in the + .IR __weston_modules_dir__ + directory are: + .PP + .RS 10 + .nf + .BR desktop-shell.so +-.BR tablet-shell.so ++.fi ++.RE ++.TP 7 ++.TP 7 ++.BI modules= xwayland.so,cms-colord.so ++specifies the modules to load (string). Available modules in the ++.IR __weston_modules_dir__ ++directory are: ++.PP ++.RS 10 ++.nf + .BR xwayland.so ++.BR cms-colord.so + .fi + .RE + .TP 7 +-- +1.8.3.1 + diff --git a/man/weston.ini.man b/man/weston.ini.man index ce3f928..7b9ce0a 100644 --- a/man/weston.ini.man +++ b/man/weston.ini.man @@ -92,16 +92,27 @@ The .B core section is used to select the startup compositor modules. .TP 7 -.BI modules= desktop-shell.so,xwayland.so -specifies the modules to load (string). Available modules in the +.BI shell= desktop-shell.so +specifies the shell to load (string). Available shells in the .IR __weston_modules_dir__ directory are: .PP .RS 10 .nf .BR desktop-shell.so -.BR tablet-shell.so +.fi +.RE +.TP 7 +.TP 7 +.BI modules= xwayland.so,cms-colord.so +specifies the modules to load (string). Available modules in the +.IR __weston_modules_dir__ +directory are: +.PP +.RS 10 +.nf .BR xwayland.so +.BR cms-colord.so .fi .RE .TP 7 -- 1.8.3.1 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston.ini.man v3] Improvement of weston.ini.man. Add key:shell and remove tablet-shell
On Mon, Feb 10, 2014 at 12:15:11PM +0900, Nobuhiko Tanibata wrote: Add description of key:shell to CORE SECTION and move a example of desktop-shell from key:modules to key:shell. Add cms-colord.so to key:modules of CORE SECTION. Signed-off-by: Nobuhiko Tanibata nobuhiko_tanib...@xddp.denso.co.jp I backed out the v1 of this patch that I mentioned above and applied this one. Btw, it's always good to write a quick comment about what changed between v1 and v2 of a patch so everybody knows why the new version was sent out. --- Here, below the --- that git inserts is a good place to put the comment about what changes - for example: v2: Remove 0001-weston.ini.man.patch from v1 of this patch Kristian man/weston.ini.man | 19 --- 1 file changed, 16 insertions(+), 3 deletions(-) diff --git a/man/weston.ini.man b/man/weston.ini.man index ce3f928..dfb00c6 100644 --- a/man/weston.ini.man +++ b/man/weston.ini.man @@ -92,16 +92,29 @@ The .B core section is used to select the startup compositor modules. .TP 7 -.BI modules= desktop-shell.so,xwayland.so -specifies the modules to load (string). Available modules in the +.BI shell= desktop-shell.so +specifies a shell to load (string). This can be used to load your own +implemented shell or one with Weston as default. Available shells +in the .IR __weston_modules_dir__ directory are: .PP .RS 10 .nf .BR desktop-shell.so -.BR tablet-shell.so +.fi +.RE +.TP 7 +.TP 7 +.BI modules= xwayland.so,cms-colord.so +specifies the modules to load (string). Available modules in the +.IR __weston_modules_dir__ +directory are: +.PP +.RS 10 +.nf .BR xwayland.so +.BR cms-colord.so .fi .RE .TP 7 -- 1.8.3.1 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH libinput] Add a customizable log handler
On Fri, Feb 14, 2014 at 10:16:02AM +1000, Peter Hutterer wrote:
The previous log handler wasn't actually hooked up to anything. Add a public
API for the log handler with priority filtering, defaulting to priority
'error' and stderr as output stream.
And to keep the diff down and convenience up, provide a few simple wrappers
for logging. The generic is log_msg(), but let's use log_info, log_error, etc.
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
Looks good to me.
Reviewed-by: Jonas Ådahl jad...@gmail.com
---
src/libinput-private.h | 7 ++
src/libinput-util.c| 20 --
src/libinput.c | 62 ++
src/libinput.h | 76 ++
src/path.c | 4 +-
test/Makefile.am | 7 +-
test/log.c | 169
+
7 files changed, 322 insertions(+), 23 deletions(-)
create mode 100644 test/log.c
diff --git a/src/libinput-private.h b/src/libinput-private.h
index 0d7de90..1fff7de 100644
--- a/src/libinput-private.h
+++ b/src/libinput-private.h
@@ -74,6 +74,13 @@ typedef void (*libinput_source_dispatch_t)(void *data);
struct libinput_source;
+#define log_debug(...) log_msg(LIBINPUT_LOG_PRIORITY_DEBUG, __VA_ARGS__)
+#define log_info(...) log_msg(LIBINPUT_LOG_PRIORITY_INFO, __VA_ARGS__)
+#define log_error(...) log_msg(LIBINPUT_LOG_PRIORITY_ERROR, __VA_ARGS__)
+
+void
+log_msg(enum libinput_log_priority priority, const char *format, ...);
+
int
libinput_init(struct libinput *libinput,
const struct libinput_interface *interface,
diff --git a/src/libinput-util.c b/src/libinput-util.c
index a3534e1..eeb9786 100644
--- a/src/libinput-util.c
+++ b/src/libinput-util.c
@@ -35,26 +35,6 @@
#include libinput-util.h
#include libinput-private.h
-static FILE *g_log_file = NULL;
-
-void
-set_logging_enabled(int enabled)
-{
- g_log_file = enabled ? stdout : NULL;
-}
-
-void
-log_info(const char *format, ...)
-{
- va_list ap;
-
- if (g_log_file) {
- va_start(ap, format);
- vfprintf(g_log_file, format, ap);
- va_end(ap);
- }
-}
-
void
list_init(struct list *list)
{
diff --git a/src/libinput.c b/src/libinput.c
index cfce2c5..b4879af 100644
--- a/src/libinput.c
+++ b/src/libinput.c
@@ -78,6 +78,68 @@ struct libinput_event_touch {
};
static void
+libinput_default_log_func(enum libinput_log_priority priority,
+ void *data,
+ const char *format, va_list args)
+{
+ const char *prefix;
+
+ switch(priority) {
+ case LIBINPUT_LOG_PRIORITY_DEBUG: prefix = debug; break;
+ case LIBINPUT_LOG_PRIORITY_INFO: prefix = info; break;
+ case LIBINPUT_LOG_PRIORITY_ERROR: prefix = error; break;
+ default: prefix=invalid priority; break;
+ }
+
+ fprintf(stderr, libinput %s: , prefix);
+ vfprintf(stderr, format, args);
+}
+
+struct log_data {
+ enum libinput_log_priority priority;
+ libinput_log_handler handler;
+ void *user_data;
+};
+
+static struct log_data log_data = {
+ .priority = LIBINPUT_LOG_PRIORITY_ERROR,
+ .handler = libinput_default_log_func,
+ .user_data = NULL,
+};
+
+void
+log_msg(enum libinput_log_priority priority, const char *format, ...)
+{
+ va_list args;
+
+ if (log_data.handler log_data.priority = priority) {
+ va_start(args, format);
+ log_data.handler(priority, log_data.user_data, format, args);
+ va_end(args);
+ }
+}
+
+LIBINPUT_EXPORT void
+libinput_log_set_priority(enum libinput_log_priority priority)
+{
+ log_data.priority = priority;
+}
+
+LIBINPUT_EXPORT enum libinput_log_priority
+libinput_log_get_priority(void)
+{
+ return log_data.priority;
+}
+
+LIBINPUT_EXPORT void
+libinput_log_set_handler(libinput_log_handler log_handler,
+ void *user_data)
+{
+ log_data.handler = log_handler;
+ log_data.user_data = user_data;
+}
+
+static void
libinput_post_event(struct libinput *libinput,
struct libinput_event *event);
diff --git a/src/libinput.h b/src/libinput.h
index e87b2b7..6bf538a 100644
--- a/src/libinput.h
+++ b/src/libinput.h
@@ -42,6 +42,15 @@
typedef int32_t li_fixed_t;
/**
+ * Log priority for internal logging messages.
+ */
+enum libinput_log_priority {
+ LIBINPUT_LOG_PRIORITY_DEBUG = 10,
+ LIBINPUT_LOG_PRIORITY_INFO = 20,
+ LIBINPUT_LOG_PRIORITY_ERROR = 30,
+};
+
+/**
* @ingroup device
*
* Capabilities on a device. A device may have one or more capabilities
@@ -875,6 +884,73 @@ void
libinput_destroy(struct libinput *libinput);
/**
+ * @ingroup base
+ *
+ * Set the global log priority. Messages with priorities equal to or
+ * higher than the argument will be printed to the current log handler.
+ *
+ * The default
Re: [PATCH weston] exposay: arrange views per-output
On Mon, Feb 10, 2014 at 01:22:32PM +0100, Emilio Pozuelo Monfort wrote:
From: Emilio Pozuelo Monfort emilio.pozu...@collabora.co.uk
https://bugs.freedesktop.org/show_bug.cgi?id=73173
Thanks for fixing this, patch applied and bug closed.
Kristian
---
desktop-shell/exposay.c | 108
desktop-shell/shell.c | 7
desktop-shell/shell.h | 74 +++--
3 files changed, 107 insertions(+), 82 deletions(-)
diff --git a/desktop-shell/exposay.c b/desktop-shell/exposay.c
index fe7a3a7..b7e32c9 100644
--- a/desktop-shell/exposay.c
+++ b/desktop-shell/exposay.c
@@ -30,6 +30,7 @@
struct exposay_surface {
struct desktop_shell *shell;
+ struct exposay_output *eoutput;
struct weston_surface *surface;
struct weston_view *view;
struct wl_list link;
@@ -140,6 +141,7 @@ exposay_highlight_surface(struct desktop_shell *shell,
shell-exposay.row_current = esurface-row;
shell-exposay.column_current = esurface-column;
+ shell-exposay.cur_output = esurface-eoutput;
activate(shell, view-surface, shell-exposay.seat);
shell-exposay.focus_current = view;
@@ -178,32 +180,32 @@ exposay_pick(struct desktop_shell *shell, int x, int y)
* aspect ratio into account really. Also needs to be notified of surface
* addition and removal and adjust layout/animate accordingly. */
static enum exposay_layout_state
-exposay_layout(struct desktop_shell *shell)
+exposay_layout(struct desktop_shell *shell, struct shell_output
*shell_output)
{
struct workspace *workspace = shell-exposay.workspace;
- struct weston_compositor *compositor = shell-compositor;
- struct weston_output *output = get_default_output(compositor);
+ struct weston_output *output = shell_output-output;
+ struct exposay_output *eoutput = shell_output-eoutput;
struct weston_view *view;
struct exposay_surface *esurface, *highlight = NULL;
int w, h;
int i;
int last_row_removed = 0;
- wl_list_init(shell-exposay.surface_list);
-
- shell-exposay.num_surfaces = 0;
+ eoutput-num_surfaces = 0;
wl_list_for_each(view, workspace-layer.view_list, layer_link) {
if (!get_shell_surface(view-surface))
continue;
- shell-exposay.num_surfaces++;
+ if (view-output != output)
+ continue;
+ eoutput-num_surfaces++;
}
- if (shell-exposay.num_surfaces == 0) {
- shell-exposay.grid_size = 0;
- shell-exposay.hpadding_outer = 0;
- shell-exposay.vpadding_outer = 0;
- shell-exposay.padding_inner = 0;
- shell-exposay.surface_size = 0;
+ if (eoutput-num_surfaces == 0) {
+ eoutput-grid_size = 0;
+ eoutput-hpadding_outer = 0;
+ eoutput-vpadding_outer = 0;
+ eoutput-padding_inner = 0;
+ eoutput-surface_size = 0;
return EXPOSAY_LAYOUT_OVERVIEW;
}
@@ -219,37 +221,39 @@ exposay_layout(struct desktop_shell *shell)
* XXX: Surely there has to be a better way to express this maths,
* right?!
*/
- shell-exposay.grid_size = floor(sqrtf(shell-exposay.num_surfaces));
- if (pow(shell-exposay.grid_size, 2) != shell-exposay.num_surfaces)
- shell-exposay.grid_size++;
- last_row_removed = pow(shell-exposay.grid_size, 2) -
shell-exposay.num_surfaces;
+ eoutput-grid_size = floor(sqrtf(eoutput-num_surfaces));
+ if (pow(eoutput-grid_size, 2) != eoutput-num_surfaces)
+ eoutput-grid_size++;
+ last_row_removed = pow(eoutput-grid_size, 2) - eoutput-num_surfaces;
- shell-exposay.hpadding_outer = (output-width / 10);
- shell-exposay.vpadding_outer = (output-height / 10);
- shell-exposay.padding_inner = 80;
+ eoutput-hpadding_outer = (output-width / 10);
+ eoutput-vpadding_outer = (output-height / 10);
+ eoutput-padding_inner = 80;
- w = output-width - (shell-exposay.hpadding_outer * 2);
- w -= shell-exposay.padding_inner * (shell-exposay.grid_size - 1);
- w /= shell-exposay.grid_size;
+ w = output-width - (eoutput-hpadding_outer * 2);
+ w -= eoutput-padding_inner * (eoutput-grid_size - 1);
+ w /= eoutput-grid_size;
- h = output-height - (shell-exposay.vpadding_outer * 2);
- h -= shell-exposay.padding_inner * (shell-exposay.grid_size - 1);
- h /= shell-exposay.grid_size;
+ h = output-height - (eoutput-vpadding_outer * 2);
+ h -= eoutput-padding_inner * (eoutput-grid_size - 1);
+ h /= eoutput-grid_size;
- shell-exposay.surface_size = (w h) ? w : h;
- if (shell-exposay.surface_size (output-width / 2))
- shell-exposay.surface_size = output-width / 2;
- if (shell-exposay.surface_size
Re: [PATCH weston] exposay: don't crash if a view goes away
On Mon, Feb 10, 2014 at 02:23:04PM +0100, Emilio Pozuelo Monfort wrote:
From: Emilio Pozuelo Monfort emilio.pozu...@collabora.co.uk
When a view was destroyed while we were on exposay, we didn't
remove it from the list of views, and so when leaving exposay
we were trying to animate (and sometimes activate) a
non-existent view, causing a crash.
Signed-off-by: Emilio Pozuelo Monfort emilio.pozu...@collabora.co.uk
Applied, thanks.
Kristian
---
desktop-shell/exposay.c | 31 +--
1 file changed, 29 insertions(+), 2 deletions(-)
diff --git a/desktop-shell/exposay.c b/desktop-shell/exposay.c
index b7e32c9..ca36358 100644
--- a/desktop-shell/exposay.c
+++ b/desktop-shell/exposay.c
@@ -33,6 +33,7 @@ struct exposay_surface {
struct exposay_output *eoutput;
struct weston_surface *surface;
struct weston_view *view;
+ struct wl_listener view_destroy_listener;
struct wl_list link;
int x;
@@ -57,6 +58,20 @@ static void exposay_set_state(struct desktop_shell *shell,
static void exposay_check_state(struct desktop_shell *shell);
static void
+exposay_surface_destroy(struct exposay_surface *esurface)
+{
+ wl_list_remove(esurface-link);
+ wl_list_remove(esurface-view_destroy_listener.link);
+
+ if (esurface-shell-exposay.focus_current == esurface-view)
+ esurface-shell-exposay.focus_current = NULL;
+ if (esurface-shell-exposay.focus_prev == esurface-view)
+ esurface-shell-exposay.focus_prev = NULL;
+
+ free(esurface);
+}
+
+static void
exposay_in_flight_inc(struct desktop_shell *shell)
{
shell-exposay.in_flight++;
@@ -110,8 +125,7 @@ exposay_animate_out_done(struct weston_view_animation
*animation, void *data)
struct exposay_surface *esurface = data;
struct desktop_shell *shell = esurface-shell;
- wl_list_remove(esurface-link);
- free(esurface);
+ exposay_surface_destroy(esurface);
exposay_in_flight_dec(shell);
}
@@ -176,6 +190,16 @@ exposay_pick(struct desktop_shell *shell, int x, int y)
}
}
+static void
+handle_view_destroy(struct wl_listener *listener, void *data)
+{
+ struct exposay_surface *esurface = container_of(listener,
+ struct exposay_surface,
+ view_destroy_listener);
+
+ exposay_surface_destroy(esurface);
+}
+
/* Pretty lame layout for now; just tries to make a square. Should take
* aspect ratio into account really. Also needs to be notified of surface
* addition and removal and adjust layout/animate accordingly. */
@@ -267,6 +291,9 @@ exposay_layout(struct desktop_shell *shell, struct
shell_output *shell_output)
esurface-eoutput = eoutput;
esurface-view = view;
+ esurface-view_destroy_listener.notify = handle_view_destroy;
+ wl_signal_add(view-destroy_signal,
esurface-view_destroy_listener);
+
esurface-row = i / eoutput-grid_size;
esurface-column = i % eoutput-grid_size;
--
1.9.rc1
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston 2/2] exposay: avoid needlessly activating the active view
On Mon, Feb 10, 2014 at 04:52:33PM +0100, Emilio Pozuelo Monfort wrote:
From: Emilio Pozuelo Monfort emilio.pozu...@collabora.co.uk
Signed-off-by: Emilio Pozuelo Monfort emilio.pozu...@collabora.co.uk
These two applied, thanks.
Kristian
---
desktop-shell/exposay.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/desktop-shell/exposay.c b/desktop-shell/exposay.c
index fe7a3a7..feadfdc 100644
--- a/desktop-shell/exposay.c
+++ b/desktop-shell/exposay.c
@@ -138,6 +138,9 @@ exposay_highlight_surface(struct desktop_shell *shell,
{
struct weston_view *view = esurface-view;
+ if (shell-exposay.focus_current == view)
+ return;
+
shell-exposay.row_current = esurface-row;
shell-exposay.column_current = esurface-column;
--
1.9.rc1
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] Prevent zero sized wl_egl_window
On Fri, Feb 14, 2014 at 09:31:45AM +0200, Pekka Paalanen wrote:
On Thu, 13 Feb 2014 18:18:23 +
Yeh, Sinclair sinclair@intel.com wrote:
The below seems fine, but I wonder if we could make this one cause an
error to be returned later where we can, rather than silently ignoring.
I'm not sure where or how, though.
Would it make sense to change wl_egl_window_resize() so that it return a
value? Either that, or it should be documented somewhere in the API
spec that setting width/height =0 will be ignored.
I'm not sure we can change the function signature, it's public stable
ABI.
Surely drivers have maximum size limits, too, those must be catched
somewhere already.
But this might be worth looking into: if the window system produces a
bad size, what do drivers do when they cannot allocate or render to it?
In X11 it's all hidden from the app, but I don't think the gfx stack can
guarantee valid sizes in all cases, can it?
Anyway, my suggestion is just for convenience, and if drivers already
just silently do whatever on a bad size, being silent here does not
make it any worse.
We could maybe make it raise an EGL error, I'm a little concerned with how
this silently fails. However, the behavior with Sinclairs patch is
better than what we had before, so I've pushed that.
Thanks,
pq
egl_window-width = width;
egl_window-height = height;
egl_window-dx = dx;
@@ -24,6 +27,9 @@ wl_egl_window_create(struct wl_surface *surface,
{
struct wl_egl_window *egl_window;
+ if (width = 0 || height = 0)
+ return NULL;
+
egl_window = malloc(sizeof *egl_window);
if (!egl_window)
return NULL;
Thanks,
pq
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Inter-client surface embedding
On Tue, 18 Feb 2014, Bill Spitzak wrote: On 02/18/2014 11:09 AM, Mark Thomas wrote: The hole and plug are meaningful objects and are needed, at least server-side, for some associated state. They're also helpful for limiting the amount of uid-dipping a client can do, as only holes and plugs have uids. I proposed that the uid be an encrypted number so clients can't guess them (or dipping as you call it). Basically if the server is asked for the object for a given uid it fails if it is not a number recently delivered by it to another client. I've essentially done that, although the uid is more of a nonce. Even a random number can be guessed or snooped. Otherwise you are going to have to create a hole and plug object for every single Wayland object. Only the ones you want to embed. It's a rare occurrence. Plus creating objects is easy because the wayland protocol is very lightweight. Also you can't create a subsurface without both surfaces available, so there is a chicken-and-egg issue, too. I don't understand this. Obviously when the subsurface is created there is only one surface available (the parent) because the subsurface is not created yet. That is why I have A create the subsurface. B is still in charge of the buffers so there seems to be no problem here. I suggest you read up on the subsurface protocol. A subsurface object takes two surface arguments, one is the parent to attach to, and the other is the child surface that becomes the subsurface. Having thought about it, I think I'm in agreement with Pekka and the others that a generic interface is probably not appropriate, as the requirements change depending on the use case. What's probably more useful is making it easy for shell plugins to do it the way they want. So that's my plan. I don't like the idea that we are saying that things like Firefox have to be shell plugins. I think things like firefox are potentially better served by passing through the buffers from the plugin, rather than the plugin connecting to wayland itself -- a parent-child relationship rather than a sibling one. That way it gets to do things to the buffer synchronously as it passes through (like crop or scale it)*. I think this is what is meant by the subcompositor model. It sounds like it could work, though I expect there would be lots of edge cases to work through. Until someone actually tries it, though, this is all just hot air. * - I had an idea for smooth, synchronized resizing and scrolling, where the outer client requests the inner client provide it a buffer with an extra amount of rendered data around the outside of the subwindow that it is providing. The outer window crops this buffer to the correct dimensions (by asking the compositor to do so) and also draws the border of the subwindow and its scroll bars. Then the outer client can scroll and resize synchronously by repainting the existing buffer it has with a differenct crop region, whilst asynchronously requesting a new buffer from the inner client with the new geometry. I think this would work pretty well for the document viewer class of use case. Just an idea, though. I don't plan to do anything with it. -- Mark. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] scanner: Add GCC pragmas to disable -Wredundant-decls
On Sat, Feb 15, 2014 at 01:29:16PM -0500, Jasper St. Pierre wrote:
The code very intentionally emits a lot of redundant declarations
to simplify the scanner code. Somebody building with -Wredundant-decls
would have compile errors, so emit special pragmas to turn those
warnings off.
These pragmas should be ignored outside of gcc/clang.
Looks good, applied.
Kristian
---
src/scanner.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/scanner.c b/src/scanner.c
index 243ddfd..e8bfc7c 100644
--- a/src/scanner.c
+++ b/src/scanner.c
@@ -1165,11 +1165,13 @@ emit_code(struct protocol *protocol)
#include stdint.h\n
#include \wayland-util.h\\n\n);
+ printf(#pragma GCC diagnostic push\n
+#pragma GCC diagnostic ignored \-Wredundant-decls\\n);
wl_list_for_each(i, protocol-interface_list, link) {
emit_types_forward_declarations(protocol, i-request_list);
emit_types_forward_declarations(protocol, i-event_list);
}
- printf(\n);
+ printf(#pragma GCC diagnostic pop\n\n);
printf(static const struct wl_interface *types[] = {\n);
emit_null_run(protocol);
--
1.8.5.3
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH libinput] evdev: set CLOCK_MONOTONIC as the time source
Avoids erroneous timestamps when the system time is reset. This used to a be a problem with the X.Org synaptics driver where taps, scrolling and a couple of other things would potentially lock up. Signed-off-by: Peter Hutterer peter.hutte...@who-t.net --- src/evdev.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/evdev.c b/src/evdev.c index 2c88c04..ab5a0c9 100644 --- a/src/evdev.c +++ b/src/evdev.c @@ -31,6 +31,7 @@ #include fcntl.h #include mtdev-plumbing.h #include assert.h +#include time.h #include libinput.h #include evdev.h @@ -639,6 +640,8 @@ evdev_device_create(struct libinput_seat *seat, if (rc != 0) return NULL; + libevdev_set_clock_id(device-evdev, CLOCK_MONOTONIC); + device-seat_caps = 0; device-is_mt = 0; device-mtdev = NULL; -- 1.8.4.2 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] connection: Use wl_log to report errors
On Mon, Feb 17, 2014 at 07:04:28PM -0500, Jasper St. Pierre wrote:
In some cases, like Xwayland, stdout and stderr are redirected to
/dev/null, losing us valuable information, while wl_log can be
overridden, allowing us to send it to a log file instead. This
can help debugging immensely.
---
Yeah, I think that's fine, patch applied.
Kristian
src/connection.c | 36 ++--
1 file changed, 18 insertions(+), 18 deletions(-)
diff --git a/src/connection.c b/src/connection.c
index d05341a..40a2182 100644
--- a/src/connection.c
+++ b/src/connection.c
@@ -512,7 +512,7 @@ wl_closure_marshal(struct wl_object *sender, uint32_t
opcode,
count = arg_count_for_signature(message-signature);
if (count WL_CLOSURE_MAX_ARGS) {
- printf(too many args (%d)\n, count);
+ wl_log(too many args (%d)\n, count);
errno = EINVAL;
return NULL;
}
@@ -557,13 +557,13 @@ wl_closure_marshal(struct wl_object *sender, uint32_t
opcode,
fd = args[i].h;
dup_fd = wl_os_dupfd_cloexec(fd, 0);
if (dup_fd 0) {
- fprintf(stderr, dup failed: %m);
+ wl_log(dup failed: %m);
abort();
}
closure-args[i].h = dup_fd;
break;
default:
- fprintf(stderr, unhandled format code: '%c'\n,
+ wl_log(unhandled format code: '%c'\n,
arg.type);
assert(0);
break;
@@ -615,7 +615,7 @@ wl_connection_demarshal(struct wl_connection *connection,
count = arg_count_for_signature(message-signature);
if (count WL_CLOSURE_MAX_ARGS) {
- printf(too many args (%d)\n, count);
+ wl_log(too many args (%d)\n, count);
errno = EINVAL;
wl_connection_consume(connection, size);
return NULL;
@@ -642,7 +642,7 @@ wl_connection_demarshal(struct wl_connection *connection,
signature = get_next_argument(signature, arg);
if (arg.type != 'h' p + 1 end) {
- printf(message too short,
+ wl_log(message too short,
object (%d), message %s(%s)\n,
*p, message-name, message-signature);
errno = EINVAL;
@@ -669,7 +669,7 @@ wl_connection_demarshal(struct wl_connection *connection,
next = p + DIV_ROUNDUP(length, sizeof *p);
if (next end) {
- printf(message too short,
+ wl_log(message too short,
object (%d), message %s(%s)\n,
closure-sender_id, message-name,
message-signature);
@@ -680,7 +680,7 @@ wl_connection_demarshal(struct wl_connection *connection,
s = (char *) p;
if (length 0 s[length - 1] != '\0') {
- printf(string not nul-terminated,
+ wl_log(string not nul-terminated,
message %s(%s)\n,
message-name, message-signature);
errno = EINVAL;
@@ -695,7 +695,7 @@ wl_connection_demarshal(struct wl_connection *connection,
closure-args[i].n = id;
if (id == 0 !arg.nullable) {
- printf(NULL object received on non-nullable
+ wl_log(NULL object received on non-nullable
type, message %s(%s)\n, message-name,
message-signature);
errno = EINVAL;
@@ -707,7 +707,7 @@ wl_connection_demarshal(struct wl_connection *connection,
closure-args[i].n = id;
if (id == 0 !arg.nullable) {
- printf(NULL new ID received on non-nullable
+ wl_log(NULL new ID received on non-nullable
type, message %s(%s)\n, message-name,
message-signature);
errno = EINVAL;
@@ -715,7 +715,7 @@ wl_connection_demarshal(struct wl_connection *connection,
}
if (wl_map_reserve_new(objects, id) 0) {
- printf(not a valid new object id (%d),
+ wl_log(not a valid new object id (%d),
message %s(%s)\n,
Re: [RFC] libinput configuration interface
On Tue, Feb 18, 2014 at 04:33:53PM +, Dominic Jänichen wrote: On Mon, 03 Feb 2014 11:02:42 +1000, Peter Hutterer wrote: tbh, I'm not planning to support every potential option under the sun. There's a fine and rather blurry line between what is a preference and what is merely configuration because we can't commit to a single default. I'd rather have less configuration options and support those well and do the synaptics approach of supporting everything but being quite bad at how the various options interact. snip As for the softbuttons config items, I'm somewhat leaning towards finger movement in the button areas, but no clicks outside the button area. And to actually trigger a button, you need to start inside the button area - which becomes easier when you have proper finger tracking (synaptics currently doesn't). Does that imply the following use case will be supported? Being used to TP trackpoints, I am using the index finger outside the button area (on a touchpad that doubles as one hardware button) and the thumb to click. I'd expect to able to move the pointer with the index finger while clicking, disregarding slight thumb movements while doing so. This seems to very difficult to archieve (if at all) with the synaptics driver; the points jumps widely, especially if the index finger is removed from the touch pad immediately before clicking. I can imagine that this boils down to having areas insensitive to motion, but still working as softbuttons. The set of touchpad patches I sent out recently already handle this by default. When the physical clickpad button is depressed, the driver picks the finger that is pressing the button (sometimes guessing, but hey...). That finger cannot control the pointer movement until the button is released again. In your specific use case, the driver would see two touchpoints and it will select the one closer to the bottom edge as the pressing finger (i.e. your thumb). The index finger can still move while the button is down. Cheers, Peter ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH libinput 2/2] test: Add scale li_fixed overflow test
On Tue, Feb 18, 2014 at 08:13:58PM +0100, Jonas Ådahl wrote:
Add a test case and test device that checks if the scale transform can
handle high resolution devices and output monitor resolutions.
The test case is created in a way that it will fail if the coordinate
transform expression will overflow if only 32 bit integer data
containers are used.
Signed-off-by: Jonas Ådahl jad...@gmail.com
---
fwiw, this is exactly the type of use-case where it would be simple and
worth it to knock up a test for a single device and make sure that the
coordinates are correct. which gives us a nice reproducer and prevents us
from errors like this in the future.
And here is such a test case. It will fail as is, but pass if either the
expression uses 64 bit integers or doubles.
Jonas
test/Makefile.am| 1 +
test/litest-generic-highres-touch.c | 139
test/litest.c | 2 +
test/litest.h | 1 +
test/touch.c| 40 ++-
5 files changed, 182 insertions(+), 1 deletion(-)
create mode 100644 test/litest-generic-highres-touch.c
diff --git a/test/Makefile.am b/test/Makefile.am
index 59687f6..4b923aa 100644
--- a/test/Makefile.am
+++ b/test/Makefile.am
@@ -14,6 +14,7 @@ liblitest_la_SOURCES = \
litest-synaptics.c \
litest-trackpoint.c \
litest-wacom-touch.c \
+ litest-generic-highres-touch.c \
litest.c
run_tests = test-udev test-path test-pointer test-touch
diff --git a/test/litest-generic-highres-touch.c
b/test/litest-generic-highres-touch.c
new file mode 100644
index 000..bd326ce
--- /dev/null
+++ b/test/litest-generic-highres-touch.c
@@ -0,0 +1,139 @@
+/*
+ * Copyright © 2013 Red Hat, Inc.
+ * Copyright © 2014 Jonas Ådahl
+ *
+ * Permission to use, copy, modify, distribute, and sell this software and
its
+ * documentation for any purpose is hereby granted without fee, provided that
+ * the above copyright notice appear in all copies and that both that
copyright
+ * notice and this permission notice appear in supporting documentation, and
+ * that the name of the copyright holders not be used in advertising or
+ * publicity pertaining to distribution of the software without specific,
+ * written prior permission. The copyright holders make no representations
+ * about the suitability of this software for any purpose. It is provided
as
+ * is without express or implied warranty.
+ *
+ * THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS
SOFTWARE,
+ * INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO
+ * EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY SPECIAL, INDIRECT OR
+ * CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF
USE,
+ * DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER
+ * TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
PERFORMANCE
+ * OF THIS SOFTWARE.
+ */
+
+#include config.h
+
+#include litest.h
+#include litest-int.h
+#include libinput-util.h
+
+void litest_generic_highres_touch_setup(void)
+{
+ struct litest_device *d =
+ litest_create_device(LITEST_GENERIC_HIGHRES_TOUCH);
+ litest_set_current_device(d);
+}
+
+void
+litest_generic_highres_touch_touch_down(struct litest_device *d,
+ unsigned int slot,
+ int x, int y)
+{
+ static int tracking_id;
+ struct input_event *ev;
+ struct input_event down[] = {
+ { .type = EV_ABS, .code = ABS_X, .value = x },
+ { .type = EV_ABS, .code = ABS_Y, .value = y },
+ { .type = EV_ABS, .code = ABS_MT_SLOT, .value = slot },
+ { .type = EV_ABS, .code = ABS_MT_TRACKING_ID, .value =
++tracking_id },
+ { .type = EV_ABS, .code = ABS_MT_POSITION_X, .value = x },
+ { .type = EV_ABS, .code = ABS_MT_POSITION_Y, .value = y },
+ { .type = EV_KEY, .code = BTN_TOUCH, .value = 1 },
+ { .type = EV_SYN, .code = SYN_REPORT, .value = 0 },
+ };
+
+ down[0].value = litest_scale(d, ABS_X, x);
+ down[1].value = litest_scale(d, ABS_Y, y);
+ down[4].value = litest_scale(d, ABS_X, x);
+ down[5].value = litest_scale(d, ABS_Y, y);
+
+ ARRAY_FOR_EACH(down, ev)
+ litest_event(d, ev-type, ev-code, ev-value);
+}
+
+void
+litest_generic_highres_touch_move(struct litest_device *d,
+ unsigned int slot,
+ int x, int y)
+{
+ struct input_event *ev;
+ struct input_event move[] = {
+ { .type = EV_ABS, .code = ABS_MT_SLOT, .value = slot },
+ { .type = EV_ABS, .code = ABS_X, .value = x },
+ { .type = EV_ABS, .code = ABS_Y, .value = y },
+ { .type = EV_ABS,
Re: Inter-client surface embedding
On Tue, Feb 18, 2014 at 2:22 PM, Bill Spitzak spit...@gmail.com wrote: On 02/18/2014 11:09 AM, Mark Thomas wrote: I think the above description can be greatly simplified by removing the hole and plug objects and just using a subsurface: A creates a main surface A creates a subsurface for the hole A gets the uid of the subsurface from the compositor A passes that uid to B via IPC B uses this uid to get access to the subsurface B can now attach buffers and do other actions to the subsurface The hole and plug are meaningful objects and are needed, at least server-side, for some associated state. They're also helpful for limiting the amount of uid-dipping a client can do, as only holes and plugs have uids. I proposed that the uid be an encrypted number so clients can't guess them (or dipping as you call it). Basically if the server is asked for the object for a given uid it fails if it is not a number recently delivered by it to another client. Otherwise you are going to have to create a hole and plug object for every single Wayland object. I have no idea what an encrypted number is. Also you can't create a subsurface without both surfaces available, so there is a chicken-and-egg issue, too. I don't understand this. Obviously when the subsurface is created there is only one surface available (the parent) because the subsurface is not created yet. That is why I have A create the subsurface. B is still in charge of the buffers so there seems to be no problem here. Having thought about it, I think I'm in agreement with Pekka and the others that a generic interface is probably not appropriate, as the requirements change depending on the use case. What's probably more useful is making it easy for shell plugins to do it the way they want. So that's my plan. I don't like the idea that we are saying that things like Firefox have to be shell plugins. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel -- Jasper ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH libinput] evdev: set CLOCK_MONOTONIC as the time source
Em qua 19 fev 2014, às 08:47:32, Peter Hutterer escreveu: + libevdev_set_clock_id(device-evdev, CLOCK_MONOTONIC); What happens if the monotonic clock isn't supported? Shouldn't you check that sysconf(_SC_MONOTONIC_CLOCK) 0 ? -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH libinput] evdev: set CLOCK_MONOTONIC as the time source
... and what if it fails? I'd say that requiring CLOCK_MONOTONIC is fine. Are there any popular Linux setups that don't have CLOCK_MONOTONIC? On Tue, Feb 18, 2014 at 10:13 PM, Thiago Macieira thi...@kde.org wrote: Em qua 19 fev 2014, às 08:47:32, Peter Hutterer escreveu: + libevdev_set_clock_id(device-evdev, CLOCK_MONOTONIC); What happens if the monotonic clock isn't supported? Shouldn't you check that sysconf(_SC_MONOTONIC_CLOCK) 0 ? -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel -- Jasper ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH libinput] evdev: set CLOCK_MONOTONIC as the time source
Em ter 18 fev 2014, às 22:33:26, Jasper St. Pierre escreveu: ... and what if it fails? I'd say that requiring CLOCK_MONOTONIC is fine. Are there any popular Linux setups that don't have CLOCK_MONOTONIC? I'm guessing that some weird and niche embedded boards might not support it. Which is a use-case for libinput. However, I'm guessing that it's ok to let the ioctl fail. No need to check if it will fail, simply let it. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Inter-client surface embedding
Mark Thomas wrote: I suggest you read up on the subsurface protocol. A subsurface object takes two surface arguments, one is the parent to attach to, and the other is the child surface that becomes the subsurface. You are right, the actual object I wanted to send from A to B is a surface, not a wl subsurface: A creates a surface A does calls so that surface is a subsurface A gets the id number for that surface and sends it to B using IPC B sends that number to wayland and gets the surface to attach buffers to. I think things like firefox are potentially better served by passing through the buffers from the plugin, rather than the plugin connecting to wayland itself -- a parent-child relationship rather than a sibling one. That way it gets to do things to the buffer synchronously as it passes through (like crop or scale it)*. I think this is what is meant by the subcompositor model. This does sound like what is planned for wayland with the subcompositor idea. Firefox would act as a compositor, it's clients talk to it, and it then copies the buffers (hopefully in some zero-copy way) from the phony surfaces the clients are using to the actual surfaces that it sends to wayland. It still bothers me that the subcompositor is not actually doing any compositing, and wayland is therefore aware of the full complexity of the scene, yet all this information must pass through the intermediate compositor. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH 1/5] shell: add taskbar and taskbar_handler widgets
We draw a taskbar surface in desktop-shell, extend the
desktop-shell protocol to send it to the compositor, and
the compositor will draw it in a new taskbar layer at the
bottom.
Signed-off-by: Manuel Bachmann manuel.bachm...@open.eurogiciel.org
---
clients/desktop-shell.c| 144
desktop-shell/shell.c | 53 +++-
desktop-shell/shell.h |1 +
protocol/desktop-shell.xml |5 ++
4 files changed, 201 insertions(+), 2 deletions(-)
diff --git a/clients/desktop-shell.c b/clients/desktop-shell.c
index a0c6b6d..c341a91 100644
--- a/clients/desktop-shell.c
+++ b/clients/desktop-shell.c
@@ -85,6 +85,16 @@ struct panel {
uint32_t color;
};
+struct taskbar {
+ struct surface base;
+ struct window *window;
+ struct widget *widget;
+ struct wl_list handler_list;
+ struct desktop *desktop;
+ int painted;
+ uint32_t color;
+};
+
struct background {
struct surface base;
struct window *window;
@@ -102,6 +112,7 @@ struct output {
struct wl_list link;
struct panel *panel;
+ struct taskbar *taskbar;
struct background *background;
};
@@ -123,6 +134,16 @@ struct panel_clock {
int clock_fd;
};
+struct taskbar_handler {
+ struct widget *widget;
+ struct taskbar *taskbar;
+ cairo_surface_t *icon;
+ int focused, pressed;
+ char *title;
+ int state;
+ struct wl_list link;
+};
+
struct unlock_dialog {
struct window *window;
struct widget *widget;
@@ -173,6 +194,8 @@ is_desktop_painted(struct desktop *desktop)
wl_list_for_each(output, desktop-outputs, link) {
if (output-panel !output-panel-painted)
return 0;
+ if (output-taskbar !output-taskbar-painted)
+ return 0;
if (output-background !output-background-painted)
return 0;
}
@@ -566,6 +589,119 @@ panel_create(struct desktop *desktop)
return panel;
}
+static void
+taskbar_redraw_handler(struct widget *widget, void *data)
+{
+ cairo_surface_t *surface;
+ cairo_t *cr;
+ struct taskbar *taskbar = data;
+
+ cr = widget_cairo_create(taskbar-widget);
+ cairo_set_operator(cr, CAIRO_OPERATOR_SOURCE);
+ set_hex_color(cr, taskbar-color);
+ cairo_paint(cr);
+
+ cairo_destroy(cr);
+ surface = window_get_surface(taskbar-window);
+ cairo_surface_destroy(surface);
+ taskbar-painted = 1;
+ check_desktop_ready(taskbar-window);
+}
+
+static void
+taskbar_resize_handler(struct widget *widget,
+int32_t width, int32_t height, void *data)
+{
+ struct taskbar_handler *handler;
+ struct taskbar *taskbar = data;
+ cairo_t *cr;
+ cairo_text_extents_t extents;
+ int x, y, w, h;
+
+ x = 10;
+ y = 16;
+ wl_list_for_each(handler, taskbar-handler_list, link) {
+ cr = cairo_create (handler-icon);
+ cairo_text_extents (cr, handler-title, extents);
+
+ w = cairo_image_surface_get_width(handler-icon) +
extents.width + 8;
+ h = cairo_image_surface_get_height(handler-icon);
+ widget_set_allocation(handler-widget,
+ x, y - h / 2, w + 1, h + 1);
+ x += w + 10;
+
+ cairo_destroy (cr);
+ }
+}
+
+static void
+taskbar_configure(void *data,
+ struct desktop_shell *desktop_shell,
+ uint32_t edges, struct window *window,
+ int32_t width, int32_t height)
+{
+ struct surface *surface = window_get_user_data(window);
+ struct taskbar *taskbar = container_of(surface, struct taskbar, base);
+
+ window_schedule_resize(taskbar-window, width, 32);
+}
+
+static void
+taskbar_destroy_handler(struct taskbar_handler *handler)
+{
+ free(handler-title);
+
+ cairo_surface_destroy(handler-icon);
+
+ widget_destroy(handler-widget);
+ wl_list_remove(handler-link);
+
+ free(handler);
+}
+
+static void
+taskbar_destroy(struct taskbar *taskbar)
+{
+ struct taskbar_handler *tmp;
+ struct taskbar_handler *handler;
+
+ wl_list_for_each_safe(handler, tmp, taskbar-handler_list, link) {
+ taskbar_destroy_handler(handler);
+ }
+
+ widget_destroy(taskbar-widget);
+ window_destroy(taskbar-window);
+
+ free(taskbar);
+}
+
+static struct taskbar *
+taskbar_create(struct desktop *desktop)
+{
+ struct taskbar *taskbar;
+ struct weston_config_section *s;
+
+ taskbar = xzalloc(sizeof *taskbar);
+
+ taskbar-base.configure = taskbar_configure;
+ taskbar-desktop = desktop;
+ taskbar-window = window_create_custom(desktop-display);
+ taskbar-widget = window_add_widget(taskbar-window, taskbar);
+
[PATCH 3/5] shell: add managed_surface interface, request and events
We create a new managed_surface object which will track
a surface compositor-side, and receive events shell-side
to handle 3 cases :
- a toplevel surface has been created ;
- a toplevel surface has been destroyed ;
- a toplevel surface has a new title ;
Signed-off-by: Manuel Bachmann manuel.bachm...@open.eurogiciel.org
---
clients/desktop-shell.c| 69
desktop-shell/shell.c | 63
desktop-shell/shell.h |8 +
protocol/desktop-shell.xml | 49 +++
4 files changed, 189 insertions(+)
diff --git a/clients/desktop-shell.c b/clients/desktop-shell.c
index c341a91..5f861b2 100644
--- a/clients/desktop-shell.c
+++ b/clients/desktop-shell.c
@@ -139,6 +139,7 @@ struct taskbar_handler {
struct taskbar *taskbar;
cairo_surface_t *icon;
int focused, pressed;
+ struct managed_surface *surface;
char *title;
int state;
struct wl_list link;
@@ -186,6 +187,14 @@ show_menu(struct panel *panel, struct input *input,
uint32_t time)
x - 10, y - 10, menu_func, entries, 4);
}
+static void
+update_window(struct window *window)
+{
+ struct rectangle allocation;
+ window_get_allocation(window, allocation);
+ window_schedule_resize(window, allocation.width, allocation.height);
+}
+
static int
is_desktop_painted(struct desktop *desktop)
{
@@ -1113,6 +1122,20 @@ desktop_shell_prepare_lock_surface(void *data,
}
static void
+desktop_shell_add_managed_surface(void *data,
+ struct desktop_shell *desktop_shell,
+ struct managed_surface *managed_surface)
+{
+ struct desktop *desktop = data;
+ struct output *output;
+
+ wl_list_for_each(output, desktop-outputs, link) {
+ /* will follow in next patch : add the actual handler here */
+ update_window(output-taskbar-window);
+ }
+}
+
+static void
desktop_shell_grab_cursor(void *data,
struct desktop_shell *desktop_shell,
uint32_t cursor)
@@ -1162,10 +1185,56 @@ desktop_shell_grab_cursor(void *data,
static const struct desktop_shell_listener listener = {
desktop_shell_configure,
desktop_shell_prepare_lock_surface,
+ desktop_shell_add_managed_surface,
desktop_shell_grab_cursor
};
static void
+managed_surface_state_changed(void *data,
+ struct managed_surface *managed_surface,
+ uint32_t state)
+{
+ struct taskbar_handler *handler = data;
+
+ if (handler-surface == managed_surface) {
+ /* set the handler state */
+ handler-state = state;
+ }
+}
+
+static void
+managed_surface_title_changed(void *data,
+ struct managed_surface *managed_surface,
+ const char *title)
+{
+ struct taskbar_handler *handler = data;
+
+ if (handler-surface == managed_surface) {
+ /* change the handler title text */
+ handler-title = strdup(title);
+ update_window(handler-taskbar-window);
+ }
+}
+
+static void
+managed_surface_removed(void *data,
+ struct managed_surface *managed_surface)
+{
+ struct taskbar_handler *handler = data;
+
+ if (handler-surface == managed_surface) {
+ /* will follow in next patch : destroy the actual handler here
*/
+ update_window(handler-taskbar-window);
+ }
+}
+
+static const struct managed_surface_listener managed_surface_listener = {
+ managed_surface_state_changed,
+ managed_surface_title_changed,
+ managed_surface_removed
+};
+
+static void
background_destroy(struct background *background)
{
widget_destroy(background-widget);
diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
index b9b4ad9..57afe5b 100644
--- a/desktop-shell/shell.c
+++ b/desktop-shell/shell.c
@@ -2023,6 +2023,14 @@ set_title(struct shell_surface *shsurf, const char
*title)
{
free(shsurf-title);
shsurf-title = strdup(title);
+
+ if (shsurf-type == SHELL_SURFACE_TOPLEVEL) {
+ struct managed_surface *managed_surface;
+ wl_list_for_each(managed_surface,
shsurf-shell-managed_surfaces_list, link) {
+ if (managed_surface-surface == shsurf-surface)
+ managed_surface_send_title_changed
(managed_surface-resource, shsurf-title);
+ }
+ }
}
static void
@@ -2991,6 +2999,16 @@ destroy_shell_surface(struct shell_surface *shsurf)
remove_popup_grab(shsurf);
}
+ if (shsurf-type == SHELL_SURFACE_TOPLEVEL) {
+ struct managed_surface *managed_surface;
+ wl_list_for_each(managed_surface,
shsurf-shell-managed_surfaces_list, link) {
+ if
[PATCH 2/5] compositor: consider taskbar height on surfaces maximizing
As we have a new taskbar layer at the bottom, substract its
height from the desired size of maximized surfaces, so they
never get hovered by it.
Signed-off-by: Manuel Bachmann manuel.bachm...@open.eurogiciel.org
---
desktop-shell/shell.c | 26 --
1 file changed, 24 insertions(+), 2 deletions(-)
diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
index 7d7efaa..b9b4ad9 100644
--- a/desktop-shell/shell.c
+++ b/desktop-shell/shell.c
@@ -2084,6 +2084,26 @@ get_output_panel_height(struct desktop_shell *shell,
return panel_height;
}
+static int
+get_output_taskbar_height(struct desktop_shell *shell,
+ struct weston_output *output)
+{
+struct weston_view *view;
+int taskbar_height = 0;
+
+if (!output)
+return 0;
+
+wl_list_for_each(view, shell-taskbar_layer.view_list, layer_link) {
+if (view-surface-output == output) {
+taskbar_height = view-surface-height;
+break;
+}
+}
+
+return taskbar_height;
+}
+
/* The surface will be inserted into the list immediately after the link
* returned by this function (i.e. will be stacked immediately above the
* returned link). */
@@ -2404,17 +2424,19 @@ set_maximized(struct shell_surface *shsurf,
struct weston_output *output)
{
struct desktop_shell *shell;
- uint32_t edges = 0, panel_height = 0;
+ uint32_t edges = 0, panel_height = 0, taskbar_height = 0;
shell_surface_set_output(shsurf, output);
shell = shell_surface_get_shell(shsurf);
panel_height = get_output_panel_height(shell, shsurf-output);
+ taskbar_height = get_output_taskbar_height(shell, shsurf-output);
edges = WL_SHELL_SURFACE_RESIZE_TOP | WL_SHELL_SURFACE_RESIZE_LEFT;
shsurf-client-send_configure(shsurf-surface, edges,
shsurf-output-width,
- shsurf-output-height - panel_height);
+ shsurf-output-height - panel_height
+ - taskbar_height);
shsurf-next_state.maximized = true;
shsurf-state_changed = true;
--
1.7.10.4
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH 5/5] compositor: effectively minimize and unminimize.
When receiving a managed_surface_set_state request from
desktop-shell, compositor will know eventually hide the
target surface by sending it to an dedicated layer.
Signed-off-by: Manuel Bachmann manuel.bachm...@open.eurogiciel.org
---
desktop-shell/shell.c | 48 ++--
desktop-shell/shell.h |1 +
2 files changed, 43 insertions(+), 6 deletions(-)
diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
index 8910df4..8f50046 100644
--- a/desktop-shell/shell.c
+++ b/desktop-shell/shell.c
@@ -2473,6 +2473,45 @@ unset_maximized(struct shell_surface *shsurf)
}
static void
+set_minimized(struct weston_surface *surface, uint32_t is_true)
+{
+ struct shell_surface *shsurf;
+ struct workspace *current_ws;
+ struct weston_seat *seat;
+ struct weston_surface *focus;
+ struct weston_view *view;
+
+ view = get_default_view(surface);
+ if (!view)
+ return;
+
+ assert(weston_surface_get_main_surface(view-surface) == view-surface);
+
+ shsurf = get_shell_surface(surface);
+ current_ws = get_current_workspace(shsurf-shell);
+
+ wl_list_remove(view-layer_link);
+ if (is_true)
+ wl_list_insert(shsurf-shell-minimized_layer.view_list,
view-layer_link);
+ else
+ wl_list_insert(current_ws-layer.view_list, view-layer_link);
+
+ shell_surface_update_child_surface_layers(shsurf);
+
+ drop_focus_state(shsurf-shell, current_ws, view-surface);
+ wl_list_for_each(seat, shsurf-shell-compositor-seat_list, link) {
+ if (!seat-keyboard)
+ continue;
+
+ focus = weston_surface_get_main_surface(seat-keyboard-focus);
+ if (focus == view-surface)
+ weston_keyboard_set_focus(seat-keyboard, NULL);
+ }
+
+ weston_view_damage_below(view);
+}
+
+static void
shell_surface_set_maximized(struct wl_client *client,
struct wl_resource *resource,
struct wl_resource *output_resource)
@@ -3969,12 +4008,8 @@ managed_surface_set_state(struct wl_client *client,
struct managed_surface *managed_surface =
wl_resource_get_user_data(resource);
struct weston_surface *surface = managed_surface-surface;
- if (state)
-/* compositor hides surface on its own ; will follow in next
patch */
- weston_log (minimize stub\n);
- else
-/* compositor unhides surface on its own ; will follow in next
patch */
- weston_log (unminimize stub\n);
+/* compositor hides/unhides surface on its own */
+ set_minimized(surface, state);
}
static const struct managed_surface_interface managed_surface_implementation =
{
@@ -6020,6 +6055,7 @@ module_init(struct weston_compositor *ec,
activate_workspace(shell, 0);
wl_list_init(shell-managed_surfaces_list);
+ weston_layer_init(shell-minimized_layer, NULL);
wl_list_init(shell-workspaces.anim_sticky_list);
wl_list_init(shell-workspaces.animation.link);
diff --git a/desktop-shell/shell.h b/desktop-shell/shell.h
index ed563b9..8c62e3d 100644
--- a/desktop-shell/shell.h
+++ b/desktop-shell/shell.h
@@ -205,6 +205,7 @@ struct desktop_shell {
enum animation_type focus_animation_type;
struct wl_list managed_surfaces_list;
+ struct weston_layer minimized_layer;
struct wl_listener output_create_listener;
struct wl_listener output_move_listener;
--
1.7.10.4
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC] libinput configuration interface
19.02.2014 04:52, Peter Hutterer wrote: The set of touchpad patches I sent out recently already handle this by default. When the physical clickpad button is depressed, the driver picks the finger that is pressing the button (sometimes guessing, but hey...). That finger cannot control the pointer movement until the button is released again. In your specific use case, the driver would see two touchpoints and it will select the one closer to the bottom edge as the pressing finger (i.e. your thumb). The index finger can still move while the button is down. From my experience with the Sony touchpad (Vaio Z23A4R laptop), I'd say that it doesn't solve the whole problem. Here is what goes wrong with the old synaptics driver by default and can be worked around with AreaBottomEdge. Option SoftButtonAreas 4360 0 4000 0 2880 4359 3500 0 Option AreaBottomEdge 3500 1. I move the right-hand index finger on the touchpad, thus moving the pointer to the place where I want to click. 2. I place the left-hand index finger into the virtual-button area, while still keeping the right finger on the touchpad. I cannot remove the right-hand finger: if I do that, while the contact area shrinks, its center also moves, and the driver picks that up. 3. As I increase the pressure on the left-hand finger until the touchpad clicks, the contact area increases. Unfortunately, its center moves, too, and this can accumulate to ~2-3 pixels until it clicks. The important point is that the bad thing happens before the hardware button click, so the quoted solution totally misses the point. So we need something, either a sledgehammer solution in the form of ignoring all motion in the virtual button area (but that would break Sony Vaio Duo 13 because the only usable height of the virtual button area is 100% there), or some very good filter that pays attention to changes in pressure and filters any spurious movement (i.e. any movement that is combined with significant pressure changes) out. But hey, Sony in their new laptops started to ignore the problem under Windows, too, so I think I just have to swallow this and/or use my Bluetooth mouse. -- Alexander E. Patrakov ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Help compiling mesa/gallium from git!
Okay, a bit more luck, in that I can compile weston. I mostly discovered that there are parts of mesa you just cannot turn off, no matter how much you are certain they are not used. Mesa internally has calls into various functions in these modules from others so they cannot be removed. My current mesa configuration: ./autogen.sh --prefix=$WLD --enable-gles2 --enable-gallium-egl \ --with-egl-platforms=wayland,x11,drm --enable-gbm \ --with-gallium-drivers=swrast \ --with-dri-drivers=swrast --disable-dri3 --disable-glx The most important thing was the dri-driver, otherwise you get the _glapi_Dispatch symbol missing. Also x11, drm, gbm, and gles2 are needed or mesa just will not compile. I now have to run wayland with --use-pixman, when before it either detected that it needed to use this, or the gl-renderer worked for some reason. I cannot run any egl demos, even though I have been told this will allow them to run with software emulation. weston-simple-egl produces this: $ env ELG_LOG_LEVEL=debug weston/weston-simple-egl weston-simple-egl: clients/simple-egl.c:159: init_egl: Assertion `ret n = 1' failed. [23:44:01.295] libwayland: disconnect from client 0x7578d0 Aborted spitzak@asus:~/swdevl/wayland$ env EGL_LOG_LEVEL=debug weston/weston-simple-egl libEGL debug: Native platform type: wayland (autodetected) libEGL debug: EGL search path is /home/spitzak/install/lib/egl libEGL debug: added /home/spitzak/install/lib/egl/egl_gallium.so to module array libEGL debug: dlopen(/home/spitzak/install/lib/egl/egl_gallium.so) libEGL info: use wayland for display 0x1e28010 libEGL debug: EGL user error 0x3001 (EGL_NOT_INITIALIZED) in eglInitialize(failed to initialize screen) libEGL info: use wayland for display 0x1e28010 libEGL info: use software fallback libEGL debug: the best driver is Gallium libEGL debug: the value (0x8) of attribute 0x3040 did not meet the criteria (0x4) libEGL debug: the value (0x8) of attribute 0x3040 did not meet the criteria (0x4) libEGL debug: the value (0x8) of attribute 0x3040 did not meet the criteria (0x4) libEGL debug: the value (0x8) of attribute 0x3040 did not meet the criteria (0x4) libEGL debug: the value (0x8) of attribute 0x3040 did not meet the criteria (0x4) libEGL debug: the value (0x8) of attribute 0x3040 did not meet the criteria (0x4) libEGL debug: the value (0x8) of attribute 0x3040 did not meet the criteria (0x4) libEGL debug: the value (0x8) of attribute 0x3040 did not meet the criteria (0x4) libEGL debug: the value (0x8) of attribute 0x3040 did not meet the criteria (0x4) libEGL debug: the value (0x8) of attribute 0x3040 did not meet the criteria (0x4) weston-simple-egl: clients/simple-egl.c:159: init_egl: Assertion `ret n = 1' failed. [23:44:06.115] libwayland: disconnect from client 0x7578d0 Aborted ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
