The documentation is still at 1.3 on the website
Hi, please update it to 1.4 and/or add a simple step by step how to build the docs yourself (be it in the FAQ region, or in building from source). ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland v2] protocol: try to clarify frame callback semantics
On Feb 23, 2014 1:45 AM, Pekka Paalanen ppaala...@gmail.com wrote: Hi, thanks for all the comments, it's encouraging to see a concensus emerging. One reply below... On Sat, 22 Feb 2014 07:50:01 -0600 Jason Ekstrand ja...@jlekstrand.net wrote: On Feb 22, 2014 2:44 AM, Axel Davy axel.d...@ens.fr wrote: Hi, I like very much the rewording proposed by Pekka. But I dislike your proposition to send frame callbacks right away if the attached buffer has been attached for a long time. Your argument seems to be that the client may manage to get to the next pageflip if the frame callback is called right away. But with this argument, I don't see why this behaviour would be only for buffers attached long ago (and then we refresh at a higher frequency than the screen refresh) Moreover we may say we can always get the two behaviours with client side code: . If we keep the current behaviour, the client could know it has attached a buffer for a long time (and that the frame callback it had put, was already called), so if it wants to try to hit next pageflip, it could just commit right away with a new attach Yes, this is what they should be doing. The more I think about the frame callback, the more I think that clients should just put one with every new draw and just track whether that one has been released or not. Unfortunately, we have to do something reasonable in the case where the client requests a frame without drawing. I don't want to restrict the server too much on what it does in that case. It may, for instance, be running on some sort of refresh-on-demand hardware and have no concept of next flip. When the client asks for a frame callback, it is effectively asking when is a good time to repaint. If now is a good time, the server should be allowed to say so. Pekka, one thing I forgot to mention that should probably be added is that we really should guarantee that frame callbacks get fired in the same order they are requested (per surface order, not global order). Ah, ok. That should be easy to implement by just being careful in how the callback lists are managed. Can you elaborate on a use case where this is especially useful? Recall that frame callbacks never get discarded, except when the surface is destroyed(?). If the update it was part of gets overridden, the callbacks simply move on to the new update that overwrote the old one, which means that several update's worth of callbacks can trigger at the same time. I guess this is somehow behind your proposition? Yes, it is. First off, we may want to use the language same order as they are committed instead of same order as they are requested to make all frame callbacks on the same commit the same. I looked at the code and it seems that Weston already does this, so it shouldn't break anything or take any extra work to implement. Really, it's a nice guarantee for the client that takes basically no work to implement in the server. If a client normally throttles on frame callbacks and then has to suddenly repaint or some reason, it may allow it to avoid the extra logic for detecting the old frame callback and throwing it out. I don't know how big of a deal that is because they're all timestamped anyway, but it's kind of nice. More importantly, it cleans up some of the edge-cases. Most of the time, it's going to be one frame call back per application component per attach. However, this may not always be the case. In particular, it makes the frame+commit case slightly better defined by providing the simple guarantee that the callback from the frame+commit will come after the callback from the last attach. Maybe that's not a good reason for the aditional server-side requirement, but it just seems to clean things up nicely. --Jason Thanks, pq . With your proposition the client could always attach (and perhaps +damage) with a frame+commit (even with the old buffer not released), to be sure to get current behaviour. What do you mean by current behavior? And why would they want it? I don't think having to do an attach with the old buffer is a good idea, and I favor Pekka's proposition. I wasn't arguing against it. :-) Axel Davy On 22/02/2014, Jason Ekstrand wrote : Pekka, Sorry this e-mail took so long to send. Not much time lately. The first time or two I read this suggested re-wording I didn't like it, but now it's starting to grow on me. I still kind of like the idea of the buffer you sent is now in use, go ahead and send the next one but I don't know that it's that much better or that it actually changes anything. The big thing I'd like to leave open (and I think your change does) is the following: Suppose a client commits a buffer and then, several seconds later (after the attached buffer was first used), the user does something that causes the client to refresh. If it does a
Re: [PATCH wayland v2] protocol: try to clarify frame callback semantics
On Feb 23, 2014 1:50 AM, Pekka Paalanen ppaala...@gmail.com wrote: On Fri, 21 Feb 2014 21:38:15 -0600 Jason Ekstrand ja...@jlekstrand.net wrote: Pekka, Sorry this e-mail took so long to send. Not much time lately. The first time or two I read this suggested re-wording I didn't like it, but now it's starting to grow on me. I still kind of like the idea of the buffer you sent is now in use, go ahead and send the next one but I don't know that it's that much better or that it actually changes anything. Hi, there is a slight difference. If the semantics were written as the update you sent is now applied which is the same as the buffer getting into use, just in different words, then that implies that we should be queueing also frame callbacks when an update is queued. Yes, it does change that a bit. I still do not know if it is better to queue frame callbacks or not, but my current code does not queue them and it avoids the corner case of what to do with the callbacks when a queued update gets discarded. Let's go with that for now. We can always add frame callback queueing if someone decides it's useful, but we can never take it away once it hits libwayland. Also, it's not clear what interaction other extensions may have with the frame callback and we don't want to make it more complicated for them if we don't have to. --Jason Ekstrand Thanks, pq The big thing I'd like to leave open (and I think your change does) is the following: Suppose a client commits a buffer and then, several seconds later (after the attached buffer was first used), the user does something that causes the client to refresh. If it does a frame+commit without an attach, the server should be able to respond immediately without waiting for another pageflip. This way the client may be able to render in time for the next flip. Sure, the client might be too slow and miss the flip, but that's really no worse than waiting before sending the frame callback. Point is, it should be a compositor decision and I think you made that clear enough. Looks good to me. --Jason Ekstrand Reviewed-by: Jason Ekstrand ja...@jlekstrand.net On Fri, Feb 21, 2014 at 7:46 AM, Pekka Paalanen ppaala...@gmail.com wrote: From: Pekka Paalanen pekka.paala...@collabora.co.uk the callback event will arrive after the next output refresh is wrong, if you interpret output refresh as framebuffer flip or the moment when the new pixels turn into light the first time. Weston has probably never worked this way. Weston triggers the frame callbacks when it submits repainting commands to the GPU, which is before the framebuffer flip. Strike the incorrect claim, and the rest of the paragraph which no longer offers useful information. As a replacement, expand on the throttling and driving animations characteristic. The main purpose is to let clients animate at the display refresh rate, while avoiding drawing frames that will never be presented. The new claim is that the server should give some time between triggering frame callbacks and repainting itself, for clients to draw and commit. This is somewhat intimate with the repaint scheduling algorithm a compositor uses, but hopefully the right intention. Another point of this update is to imply, that frame callbacks should not be used to count compositor repaint cycles nor monitor refresh cycles. It has never been guaranteed to work. Removing the mention of frame callback without an attach hopefully discourages such use. v2: don't just remove a paragraph, but add useful information about the request's intent. Signed-off-by: Pekka Paalanen pekka.paala...@collabora.co.uk Cc: Axel Davy axel.d...@ens.fr Cc: Jason Ekstrand ja...@jlekstrand.net --- protocol/wayland.xml | 26 ++ 1 file changed, 18 insertions(+), 8 deletions(-) diff --git a/protocol/wayland.xml b/protocol/wayland.xml index e1edbe5..6e370ad 100644 --- a/protocol/wayland.xml +++ b/protocol/wayland.xml @@ -1059,22 +1059,32 @@ /request request name=frame - description summary=request repaint feedback - Request notification when the next frame is displayed. Useful - for throttling redrawing operations, and driving animations. + description summary=request a frame throttling hint + Request a notification when it is a good time start drawing a new + frame, by creating a frame callback. This is useful for throttling + redrawing operations, and driving animations. + + When a client is animating on a wl_surface, it can use the 'frame' + request to get notified when it is a good time to draw and commit the + next frame of animation. If the client commits an update earlier than + that, it is likely that some updates will not make it to
Re: [PATCH libinput 1/2] Hook up libevdev as backend
On Sat, Feb 22, 2014 at 03:51:57PM +0100, Jonas Ådahl wrote:
On Tue, Feb 18, 2014 at 04:09:09PM +1000, Peter Hutterer 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.
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
Looks good to me as well, with one comment inline.
Reviewed-by: Jonas Ådahl jad...@gmail.com
..
@@ -624,6 +607,10 @@ evdev_device_create(struct libinput_seat *seat,
libinput_device_init(device-base, seat);
+ rc = libevdev_new_from_fd(fd, device-evdev);
+ if (rc != 0)
+ return NULL;
+
device-seat_caps = 0;
device-is_mt = 0;
device-mtdev = NULL;
@@ -635,10 +622,7 @@ evdev_device_create(struct libinput_seat *seat,
device-dispatch = NULL;
device-fd = fd;
device-pending_event = EVDEV_NONE;
-
- ioctl(device-fd, EVIOCGNAME(sizeof(devname)), devname);
- devname[sizeof(devname) - 1] = '\0';
- device-devname = strdup(devname);
+ device-devname = libevdev_get_name(device-evdev);
This makes the assumption that the const char * returned by
libevdev_get_name() is valid until we destroy the device. Is this
guaranteed anywhere by libevdev?
It's guaranteed by the kernel. There is no facility to set the name through
the API and there is no facility to notify the caller if the name would
change. so libevdev (which has a copy, obviuosly) wouldn't know that it
changed. libevdev_change_fd() doesn't re-sync the name, so yes, this name
is constant.
Cheers,
Peter
libinput_seat_ref(seat);
@@ -742,8 +726,7 @@ evdev_device_destroy(struct evdev_device *device)
dispatch-interface-destroy(dispatch);
libinput_seat_unref(device-base.seat);
-
- free(device-devname);
+ libevdev_free(device-evdev);
free(device-devnode);
free(device-sysname);
free(device);
diff --git a/src/evdev.h b/src/evdev.h
index 3c9f93a..a9e27bf 100644
--- a/src/evdev.h
+++ b/src/evdev.h
@@ -27,6 +27,7 @@
#include config.h
#include linux/input.h
+#include libevdev/libevdev.h
#include libinput-private.h
@@ -55,10 +56,11 @@ struct evdev_device {
struct libinput_source *source;
struct evdev_dispatch *dispatch;
+ struct libevdev *evdev;
char *output_name;
char *devnode;
char *sysname;
- char *devname;
+ const char *devname;
int fd;
struct {
int min_x, max_x, min_y, max_y;
@@ -86,16 +88,6 @@ struct evdev_device {
int is_mt;
};
-/* copied from udev/extras/input_id/input_id.c */
-/* we must use this kernel-compatible implementation */
-#define BITS_PER_LONG (sizeof(unsigned long) * 8)
-#define NBITS(x) x)-1)/BITS_PER_LONG)+1)
-#define OFF(x) ((x)%BITS_PER_LONG)
-#define BIT(x) (1ULOFF(x))
-#define LONG(x) ((x)/BITS_PER_LONG)
-#define TEST_BIT(array, bit)((array[LONG(bit)] OFF(bit)) 1)
-/* end copied */
-
#define EVDEV_UNHANDLED_DEVICE ((struct evdev_device *) 1)
struct evdev_dispatch;
--
1.8.4.2
___
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 1/2] Hook up libevdev as backend
On Mon, Feb 24, 2014 at 09:28:49AM +1000, Peter Hutterer wrote: On Sat, Feb 22, 2014 at 03:51:57PM +0100, Jonas Ådahl wrote: On Tue, Feb 18, 2014 at 04:09:09PM +1000, Peter Hutterer 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. Signed-off-by: Peter Hutterer peter.hutte...@who-t.net Looks good to me as well, with one comment inline. Reviewed-by: Jonas Ådahl jad...@gmail.com ... @@ -624,6 +607,10 @@ evdev_device_create(struct libinput_seat *seat, libinput_device_init(device-base, seat); + rc = libevdev_new_from_fd(fd, device-evdev); + if (rc != 0) + return NULL; + device-seat_caps = 0; device-is_mt = 0; device-mtdev = NULL; @@ -635,10 +622,7 @@ evdev_device_create(struct libinput_seat *seat, device-dispatch = NULL; device-fd = fd; device-pending_event = EVDEV_NONE; - - ioctl(device-fd, EVIOCGNAME(sizeof(devname)), devname); - devname[sizeof(devname) - 1] = '\0'; - device-devname = strdup(devname); + device-devname = libevdev_get_name(device-evdev); This makes the assumption that the const char * returned by libevdev_get_name() is valid until we destroy the device. Is this guaranteed anywhere by libevdev? It's guaranteed by the kernel. There is no facility to set the name through the API and there is no facility to notify the caller if the name would change. so libevdev (which has a copy, obviuosly) wouldn't know that it changed. libevdev_change_fd() doesn't re-sync the name, so yes, this name is constant. I should've been more precise here: there is no facility to set the name through the _kernel_ API. libevdev enables a caller to change the name (and thus free the string) though I'm strongly inclined to say that's a caller problem that we don't need to worry about. I'll add some extra notes to the libevdev documentation here. Cheers, Peter ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH libinput] test: Add seat slot tests
On Sat, Feb 22, 2014 at 03:38:28PM +0100, Jonas Ådahl wrote:
Add one test that checks uniqueness of seat slots when having multiple
devices with active touch points.
Add one test that checks that libinput drops touch points when it could
not represent them with a seat wide slot.
This commit also adds support for from a test case add test devices to
an existing libinput context. Only litest-wacom-touch supports this so
far.
Signed-off-by: Jonas Ådahl jad...@gmail.com
---
Needs to be applied after 'Split up the touch event into the different
touch types'.
test/litest-wacom-touch.c | 24 ++-
test/litest.c | 30 -
test/litest.h | 13 +++-
test/touch.c | 156
++
4 files changed, 217 insertions(+), 6 deletions(-)
diff --git a/test/litest-wacom-touch.c b/test/litest-wacom-touch.c
index 464d541..a6c22ef 100644
--- a/test/litest-wacom-touch.c
+++ b/test/litest-wacom-touch.c
@@ -24,11 +24,22 @@
#include config.h
#endif
+#include stdio.h
+
#include litest.h
#include litest-int.h
#include libinput-util.h
-void litest_wacom_touch_setup(void)
+static int device_ids = 0;
+
+static void
+litest_wacom_touch_destroy(struct litest_device *dev)
+{
+ device_ids = ~dev-device_id;
+}
+
+void
+litest_wacom_touch_setup(void)
{
struct litest_device *d = litest_create_device(LITEST_WACOM_TOUCH);
litest_set_current_device(d);
@@ -104,14 +115,23 @@ litest_create_wacom_touch(struct litest_device *d)
{ ABS_MT_TRACKING_ID, 0, 65535, 0 },
};
struct input_absinfo *a;
+ char name[256];
+ int device_id;
int rc;
d-interface = interface;
+ d-destroy = litest_wacom_touch_destroy;
dev = libevdev_new();
ck_assert(dev != NULL);
- libevdev_set_name(dev, Wacom ISDv4 E6 Finger);
+ device_id = ffs(~device_ids) - 1;
+ ck_assert_int_ge(device_id, 0);
+ device_ids |= 1 device_id;
+ d-device_id = device_id;
+ snprintf(name, sizeof name, Wacom ISDv4 E6 Finger (%d), device_id);
+ libevdev_set_name(dev, name);
+
IMO the actual devices should stay as close to the real thing as possible.
That leaves us, for this test, with two options: put a 1.5s sleep in to
avoid the uinput duplicate issue, or push this code into the generic touch
device that you created for the scaling overflow issue. with that we have
more freedom of messing around with the device name.
libevdev_set_id_bustype(dev, 0x3);
libevdev_set_id_vendor(dev, 0x56a);
libevdev_set_id_product(dev, 0xe6);
diff --git a/test/litest.c b/test/litest.c
index 78a0472..e69f354 100644
--- a/test/litest.c
+++ b/test/litest.c
@@ -325,8 +325,15 @@ const struct libinput_interface interface = {
.close_restricted = close_restricted,
};
+const struct libinput_interface *
+litest_get_libinput_interface()
+{
+ return interface;
+}
+
struct litest_device *
-litest_create_device(enum litest_device_type which)
+litest_create_device_for(struct libinput *libinput,
+ enum litest_device_type which)
{
struct litest_device *d = zalloc(sizeof(*d));
int fd;
@@ -358,7 +365,7 @@ litest_create_device(enum litest_device_type which)
rc = libevdev_new_from_fd(fd, d-evdev);
ck_assert_int_eq(rc, 0);
- d-libinput = libinput_path_create_context(interface, NULL);
+ d-libinput = libinput;
ck_assert(d-libinput != NULL);
d-libinput_device = libinput_path_add_device(d-libinput, path);
@@ -372,6 +379,19 @@ litest_create_device(enum litest_device_type which)
return d;
}
+struct litest_device *
+litest_create_device(enum litest_device_type which)
+{
+ struct libinput *libinput;
+ struct litest_device *d;
+
+ libinput = libinput_path_create_context(interface, NULL);
+ d = litest_create_device_for(libinput, which);
+ d-owns_context = true;
+
+ return d;
+}
+
int
litest_handle_events(struct litest_device *d)
{
@@ -392,8 +412,12 @@ litest_delete_device(struct litest_device *d)
if (!d)
return;
+ if (d-destroy)
+ d-destroy(d);
+
libinput_device_unref(d-libinput_device);
- libinput_destroy(d-libinput);
+ if (d-owns_context)
+ libinput_destroy(d-libinput);
libevdev_free(d-evdev);
libevdev_uinput_destroy(d-uinput);
memset(d,0, sizeof(*d));
diff --git a/test/litest.h b/test/litest.h
index 9cc0ff5..fef051d 100644
--- a/test/litest.h
+++ b/test/litest.h
@@ -60,8 +60,11 @@ struct litest_device {
struct libevdev *evdev;
struct libevdev_uinput *uinput;
struct libinput *libinput;
+ void (*destroy)(struct litest_device *d);
+ bool owns_context;
struct libinput_device *libinput_device;
struct litest_device_interface *interface;
+ int
