[PATCH weston.ini.man v2] Improvement of weston.ini.man. Add key:shell and remove tablet-shell
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 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Is there any way to let compositor set the data in client space and then return back to client?
Hi, All I want to allocate some space in client, and let compositor set some data in this space and then return back to client. It seems like user data mechanism. Any way to implement that? Thanks Regards Quanxian Wang ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Help compiling mesa/gallium from git!
On Fri, 07 Feb 2014 09:54:36 -0800 Bill Spitzak spit...@gmail.com wrote: Okay, removing everything with gallium in it's name from the install worked. But make install in mesa puts it all back! Would clean fix this? What I am really interested in is the proper configure line for mesa. I am currently only interested in running wayland atop an Nvidia X server, and running GL/EGL wayland clients inside that, and some of the errors indicate that I may be able to run software-emulated EGL with the proper configuration. *sigh*... I wrote a long nice reply and then my laptop crashed. Ok, here's the summary anyway. - your configure line looks fine, but - you need --enable-gallium-egl, because you want software rendered Wayland GL/GLES apps to work - you need to use weston's pixman renderer, not gl-renderer. Sw-rendered GL apps will work anyway with egl_gallium.so, but not with egl_dri2.so. - if you used weston's gl-renderer, you need to get weston to load NVIDIA libEGL, but you always need Wayland apps to load Mesa libEGL. That is almost impossible without serious hacking, especially if you built weston-desktop-shell to use EGL. So better to not have weston use EGL/GL at all. - you probably run not the binaries you think you are, because of the problems and the warnings about source being more recent than executable. That needs to be fixed. Check /proc/PID/maps for what binaries are loaded for a process. Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH libinput] Make it possible to have persistent libinput_seat instances
With this patch, a user can keep a reference to a libinput_seat
instance, which will cause the seat to never be unlinked from the
libinput context nor destroyed.
Previously, a when the last device of a seat was removed, the seat was
unlinked and if a new device was discovered with a previously empty seat
a new seat instance would always be created, meaning two potential seat
instances with identical physical and logical seat name pairs.
Signed-off-by: Jonas Ådahl jad...@gmail.com
---
src/libinput.c | 1 +
src/libinput.h | 5 +++
src/path.c | 14 +++--
src/path.h | 9 +++---
src/udev-seat.c | 9 --
test/path.c | 94 +
test/udev.c | 77 ++
7 files changed, 193 insertions(+), 16 deletions(-)
diff --git a/src/libinput.c b/src/libinput.c
index cfce2c5..cc84fb5 100644
--- a/src/libinput.c
+++ b/src/libinput.c
@@ -508,6 +508,7 @@ libinput_seat_init(struct libinput_seat *seat,
seat-logical_name = strdup(logical_name);
seat-destroy = destroy;
list_init(seat-devices_list);
+ list_insert(libinput-seat_list, seat-link);
}
LIBINPUT_EXPORT void
diff --git a/src/libinput.h b/src/libinput.h
index 9cd9d5b..4a481d2 100644
--- a/src/libinput.h
+++ b/src/libinput.h
@@ -1023,6 +1023,11 @@ libinput_device_get_output_name(struct libinput_device
*device);
*
* Get the seat associated with this input device.
*
+ * A seat can be uniquely identified by the physical and logical seat name.
+ * There will ever be only one seat instance with a given physical and logical
+ * seat name pair at any given time, but if no external reference is kept, it
+ * may be destroyed if no device belonging to it is left.
+ *
* @param device A previously obtained device
* @return The seat this input device belongs to
*/
diff --git a/src/path.c b/src/path.c
index 2893ad4..4e2cf1f 100644
--- a/src/path.c
+++ b/src/path.c
@@ -68,7 +68,6 @@ path_seat_create(struct path_input *input,
libinput_seat_init(seat-base, input-base, seat_name,
seat_logical_name, path_seat_destroy);
- list_insert(input-base.seat_list, seat-base.link);
return seat;
}
@@ -142,13 +141,22 @@ path_input_enable(struct libinput *libinput)
return -1;
}
- seat = path_seat_create(input, seat_name, seat_logical_name);
+ if (!input-seat) {
+ input-seat = path_seat_create(input,
+ seat_name,
+ seat_logical_name);
+ if (!input-seat) {
+ close_restricted(libinput, fd);
+ log_info(could not create seat '%s'.\n, seat_name);
+ return -1;
+ }
+ }
+ seat = input-seat;
free(seat_name);
free(seat_logical_name);
device = evdev_device_create(seat-base, devnode, sysname, fd);
free(sysname);
- libinput_seat_unref(seat-base);
if (device == EVDEV_UNHANDLED_DEVICE) {
close_restricted(libinput, fd);
diff --git a/src/path.h b/src/path.h
index b840acf..12bbfb8 100644
--- a/src/path.h
+++ b/src/path.h
@@ -26,16 +26,17 @@
#include config.h
#include libinput-private.h
+struct path_seat {
+ struct libinput_seat base;
+};
+
struct path_input {
struct libinput base;
char *path;
+ struct path_seat *seat;
struct evdev_device *device;
};
-struct path_seat {
- struct libinput_seat base;
-};
-
int path_input_process_event(struct libinput_event);
#endif
diff --git a/src/udev-seat.c b/src/udev-seat.c
index 5936511..161b294 100644
--- a/src/udev-seat.c
+++ b/src/udev-seat.c
@@ -221,14 +221,6 @@ udev_input_remove_devices(struct udev_input *input)
seat-base.devices_list, base.link) {
close_restricted(input-base, device-fd);
evdev_device_remove(device);
- if (list_empty(seat-base.devices_list)) {
- /* if the seat may be referenced by the
- client, so make sure it's dropped from
- the seat list now, to be freed whenever
-* the device is removed */
- list_remove(seat-base.link);
- list_init(seat-base.link);
- }
}
libinput_seat_unref(seat-base);
}
@@ -329,7 +321,6 @@ udev_seat_create(struct udev_input *input,
libinput_seat_init(seat-base, input-base,
device_seat, seat_name,
udev_seat_destroy);
- list_insert(input-base.seat_list, seat-base.link);
return seat;
}
diff --git a/test/path.c b/test/path.c
index
Re: Is there any way to let compositor set the data in client space and then return back to client?
On Sat, 8 Feb 2014 08:19:06 + Wang, Quanxian quanxian.w...@intel.com wrote: Hi, All I want to allocate some space in client, and let compositor set some data in this space and then return back to client. It seems like user data mechanism. Any way to implement that? Not really, it's nothing like user data. You have to make the client bind to a new protocol interface you designed, and then use events to pass the data to the client. If you need to pass significant amounts of data, you can use a mechanism similar to passing XKB keymaps, see wl_keyboard.keymap event. There the compositor creates the shm file. If you want the shm file created by the client, you pass the file descriptor in the other direction, similar to wl_shm.create_pool, have the server fill out the memory, and then send an event to say it's done or rely on a wl_display.sync roundtrip. Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Is there any way to let compositor set the data in client space and then return back to client?
Well, there's not really anything that allows process A to arbitrarily modify process B's memory. The only thing that's close is memory-mapped files, and that's already what we use to share image data between the client and the compositor. There's also memfd, which is more secure than a memory-mapped tmpfile, simply because it allows sealing the fd, so you can be sure it will never change as you try to read from it. But memfd isn't a public API yet. What exactly are you trying to do here? On Sat, Feb 8, 2014 at 3:19 AM, Wang, Quanxian quanxian.w...@intel.comwrote: Hi, All I want to allocate some space in client, and let compositor set some data in this space and then return back to client. It seems like user data mechanism. Any way to implement that? Thanks Regards Quanxian Wang ___ 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 wayland 3/3] Add a debug handler and use it to print out protocol debug messages
On Wed, Feb 5, 2014 at 11:04 PM, Kristian Høgsberg hoegsb...@gmail.comwrote:
On Wed, Dec 18, 2013 at 08:56:20PM -0600, Jason Ekstrand wrote:
In order to keep from overloading the debug handler, we first squash the
entire message into a string and call wl_debug once.
Signed-off-by: Jason Ekstrand ja...@jlekstrand.net
---
src/connection.c | 54
---
src/wayland-client.c | 6 ++
src/wayland-client.h | 1 +
src/wayland-private.h | 2 ++
src/wayland-server.c | 6 ++
src/wayland-server.h | 1 +
src/wayland-util.c| 19 ++
7 files changed, 65 insertions(+), 24 deletions(-)
diff --git a/src/connection.c b/src/connection.c
index 1d8b61b..b7f02b4 100644
--- a/src/connection.c
+++ b/src/connection.c
@@ -1088,67 +1088,73 @@ void
wl_closure_print(struct wl_closure *closure, struct wl_object *target,
int send)
{
int i;
+ struct wl_array msg;
struct argument_details arg;
const char *signature = closure-message-signature;
struct timespec tp;
unsigned int time;
+ wl_array_init(msg);
+ wl_array_add(msg, 128); /* This should be big enough for most
cases */
+ msg.size = 0;
+
clock_gettime(CLOCK_REALTIME, tp);
time = (tp.tv_sec * 100L) + (tp.tv_nsec / 1000);
- fprintf(stderr, [%10.3f] %s%s@%u.%s(,
- time / 1000.0,
- send ? - : ,
- target-interface-name, target-id,
- closure-message-name);
+ wl_array_printf(msg, [%10.3f] %s%s@%u.%s(,
+ time / 1000.0,
+ send ? - : ,
+ target-interface-name, target-id,
+ closure-message-name);
Could we just call wl_debug() instead and avoid building up a string?
The way you've written this, wl_debug() is always called with one complete
line of debug text, but do you actually need that?
Technically, no. Obviously the debug handler can use something similar to
wl_array_printf to let debug messages build up and then split it into
lines. In fact, this is exactly what I'll do in my code if you prefer (the
debug handler I'm forwarding stuff to needs complete liens). This just
makes it a little easier on the debug handler, especially if stuff is
multi-threaded.
--Jason
for (i = 0; i closure-count; i++) {
signature = get_next_argument(signature, arg);
if (i 0)
- fprintf(stderr, , );
+ wl_array_printf(msg, , );
switch (arg.type) {
case 'u':
- fprintf(stderr, %u, closure-args[i].u);
+ wl_array_printf(msg, %u, closure-args[i].u);
break;
case 'i':
- fprintf(stderr, %d, closure-args[i].i);
+ wl_array_printf(msg, %d, closure-args[i].i);
break;
case 'f':
- fprintf(stderr, %f,
- wl_fixed_to_double(closure-args[i].f));
+ wl_array_printf(msg, %f,
+
wl_fixed_to_double(closure-args[i].f));
break;
case 's':
- fprintf(stderr, \%s\, closure-args[i].s);
+ wl_array_printf(msg, \%s\,
closure-args[i].s);
break;
case 'o':
if (closure-args[i].o)
- fprintf(stderr, %s@%u,
-
closure-args[i].o-interface-name,
- closure-args[i].o-id);
+ wl_array_printf(msg, %s@%u,
+
closure-args[i].o-interface-name,
+ closure-args[i].o-id);
else
- fprintf(stderr, nil);
+ wl_array_printf(msg, nil);
break;
case 'n':
- fprintf(stderr, new id %s@,
- (closure-message-types[i]) ?
- closure-message-types[i]-name :
- [unknown]);
+ wl_array_printf(msg, new id %s@,
+ (closure-message-types[i]) ?
+ closure-message-types[i]-name :
+ [unknown]);
if (closure-args[i].n != 0)
- fprintf(stderr, %u, closure-args[i].n);
+ wl_array_printf(msg, %u,
closure-args[i].n);
else
- fprintf(stderr, nil);
+ wl_array_printf(msg, nil);
break;
case 'a':
-
Re: [PATCH weston.ini.man v2] Improvement of weston.ini.man. Add key:shell and remove tablet-shell
Nobuhiko, These look pretty good assuming they properly compile (I can't compile the man format in my head). One comment, is that we should probably remove tablet-shell from the list of shells while we're at it. It might also be worth noting that this can be used to load other shell plugins than the ones provided with weston. --Jason Ekstrand On Sat, Feb 8, 2014 at 2:01 AM, Nobuhiko Tanibata nobuhiko_tanib...@xddp.denso.co.jp 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 --- 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 ___ 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] [weston] Don't crash when eglCreateContext fails
eglCreateContext fails with every EGLConfig that nvidia blob 334.16 provides causing NULL pointer dereference in gl_renderer_destroy when destroying fragment and fan bindings. This should fix #74699. Signed-off-by: Mariusz Ceier mceier+wayl...@gmail.com --- src/gl-renderer.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/src/gl-renderer.c b/src/gl-renderer.c index d03bce6..76325f4 100644 --- a/src/gl-renderer.c +++ b/src/gl-renderer.c @@ -1766,8 +1766,10 @@ gl_renderer_destroy(struct weston_compositor *ec) wl_array_release(gr-vertices); wl_array_release(gr-vtxcnt); - weston_binding_destroy(gr-fragment_binding); - weston_binding_destroy(gr-fan_binding); + if (gr-fragment_binding) + weston_binding_destroy(gr-fragment_binding); + if (gr-fan_binding) + weston_binding_destroy(gr-fan_binding); free(gr); } -- 1.8.5.4 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC v2] Wayland presentation extension (video protocol)
More comments! On Fri, Jan 31, 2014 at 7:29 AM, Pekka Paalanen ppaala...@gmail.com wrote: On Thu, 30 Jan 2014 17:35:17 +0200 Pekka Paalanen ppaala...@gmail.com wrote: 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. ... interface name=presentation_feedback version=1 description summary=presentation time feedback event A presentation_feedback object returns the feedback information about a wl_surface content update becoming visible to the user. One object corresponds to one content update submission (wl_surface.commit), queued or immediate. There are two possible outcomes: the content update may be presented to the user, in which case the presentation timestamp is delivered. Otherwise, the content update is discarded, and the user never had a chance to see it before it was superseded or the surface was destroyed. Once a presentation_feedback object has delivered an event, it becomes inert, and should be destroyed by the client. /description request name=destroy type=destructor description summary=destroy presentation feedback object The object is destroyed. If a feedback event had not been delivered yet, it is cancelled. /description /request event name=sync_output description summary=presentation synchronized to this output As presentation can be synchronized to only one output at a time, this event tells which output it was. This event is only sent prior to the presented event. As clients may bind to the same global wl_output multiple times, this event is sent for each bound instance that matches the synchronized output. If a client has not bound to the right wl_output global at all, this event is not sent. /description arg name=output type=object interface=wl_output summary=presentation output/ /event event name=presented description summary=the content update was displayed The associated content update was displayed to the user at the indicated time (tv_sec, tv_nsec). For the interpretation of the timestamp, see presentation.clock_id event. The timestamp corresponds to the time when the content update turned into light the first time on the surface's main output. Compositors may approximate this from the framebuffer flip completion events from the system, and the latency of the physical display path if known. This event is preceeded by all related sync_output events telling which output's refresh cycle the feedback corresponds to, i.e. the main output for the surface. Compositors are recommended to choose to the output containing the largest part of the wl_surface, or keeping the output they previously chose. Having a stable presentation output association helps clients to predict future output refreshes (vblank). Argument 'refresh' gives the compositor's prediction of how many nanoseconds after tv_sec, tv_nsec the very next output refresh may occur. This is to further aid clients in predicting future refreshes, i.e., estimating the timestamps targeting the next few vblanks. If such prediction cannot usefully be done, the argument is zero. The 64-bit value combined from seq_hi and seq_lo is the value of the output's vertical retrace counter when the content update was first scanned out to the display. This value must be compatible with the definition of MSC in GLX_OML_sync_control specification. Note, that if the display path has a non-zero latency, the time instant specified by this counter may differ from the timestamp's. If the output does not have a constant refresh rate, explicit video mode switches excluded, then the refresh argument must be zero. If the output does not have a concept of vertical retrace or a refresh cycle, or the output device is self-refreshing without a way to query the refresh count, then the arguments seq_hi and seq_lo must be zero. /description arg name=tv_sec type=uint summary=seconds part of the presentation timestamp/ arg name=tv_nsec type=uint summary=nanoseconds part of the presentation timestamp/ arg name=refresh type=uint
Re: [RFC v2] Wayland presentation extension (video protocol)
On Wed, Feb 5, 2014 at 1:32 AM, Pekka Paalanen ppaala...@gmail.com wrote: 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. ... interface name=presentation version=1 request name=destroy type=destructor request name=feedback request name=queue request name=discard_queue event name=clock_id /interface interface name=presentation_feedback version=1 request name=destroy type=destructor event name=sync_output event name=presented event name=discarded /interface Hi, another random thought; should we support queueing frames (buffers) in reverse chronological order? It's not really possible with the scheduling algorithm I wrote down in the spec. There is no timestamp associated with the currently showing content, which means that if you queue a frame with a target timestamp in the past, it will replace the current content, even if the current content was originally queued with a later target timestamp. I wonder if we could define, that the current content effectively has the timestamp of when it was presented, and all queued updates with an earlier target timestamp will be discarded. That should work, right? Now, is there a corner case... output update has been submitted to hardware but has not been presented yet, which means the content in flight has no timestamp determined yet... but we won't update the output again before the update in flight has completed, which gives the presented timestamp for the was-in-flight current content. If we do need the timestamp for content in flight, we could use the target timestamp it had when queued, or the timestamp the compositor is targeting. Since clients have a choice between queued and immediate updates, I guess using the compositor's target timestamp would be better defined. Opinions? I agree. The current frame (or frame for the currently pending flip) should be treated as if it has a timestamp of its expected next presentation time. I'm still not completely understanding the algorithm for presenting stuff correctly, but it should be possible for the client to sneak a frame in for the next present. I need some time at my chalkboard to try and get my head wrapped around all this. Maybe it would be good if you made a couple of little timeline pictures to go with it? --Jason Ekstrand I think I should fix it like that. Isn't queueing (writing into the audio scanout buffer) audio samples in reverse chronological order the proper method to update audio content on the fly with minimal umm... latency? Wonder if some video-like playback would benefit from a similar algorithm, which minimizes latency(?) or the difference to wall time at the cost of possibly skipping older new updates. Errm, to avoid shifting the content on the time axis. Or something. 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
Re: [RFC v2] Wayland presentation extension (video protocol)
Hi, On 08/02/2014, Jason Ekstrand wrote : For each surface with queued content updates and matching main output, the compositor picks the update with the highest timestamp no later than a half frame period after the predicted presentation time. The intent is to pick the content update whose target timestamp as rounded to the output refresh period granularity matches the same display update as the compositor is targeting, while not displaying any content update more than a I'm not really following 100% here. It's not your fault, this is just a terribly awkward sort of thing to try and put into English. It sounds to me like the following: If P0 is the time of the next present and P1 is the time of the one after that, you look for the largest thing less than the average of P1 and P2. Is this correct? Why go for the average? The client is going to have to adjust anyway. If you target t, and P0 and P1 are possible pageflips time, if P0t(1/2)P0+(1/2)P1 then you take the pageflip at P0 if (1/2)P0+(1/2)P1tP1 then you take the pageflip at P1 That way the length of the intersection of the interval (t,t+time between two pageflips) and 'time interval at which it is displayed' is maximized. half frame period too early. If all the updates in the queue are already late, the highest timestamp update is taken regardless of how late it is. Once an update in a queue has been chosen, all remaining updates with an earlier timestamp in the queue are discarded. Ok, I think what you are saying works. Again, it's difficult to parse but these things always are. My one latent concern is that I still don't think we're entirely handling the case that QtQuick wants. What they want is to do their rendering a few frames in advance in case of CPU/GPU jitter. Technically, this extension handles this by the client simply doing a good job of guessing presentation times on a one-per-frame baseis. However, it doesn't allow for any damage tracking. In the case of QtQuick they want a linear queue of buffers where no buffer ever gets skipped. In this case, you could do damage tracking by allowing it to accumulate from one frame to another and you get all of the damage-tracking advantages that you had before. I'm not sure how much this matters, but it might be worth thinking about it. If they really want to work that way, why not doing this queue client side? It doesn't need to be done in the compositor. Hope that helps, --Jason Ekstrand Axel Davy ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC v2] Wayland presentation extension (video protocol)
OK, that makes more sense. Thank you for stating it in terms of intervals. I still need to think about it a bit more. On Feb 8, 2014 4:14 PM, Axel Davy axel.d...@ens.fr wrote: On 08/02/2014, Axel Davy wrote : Hi, On 08/02/2014, Jason Ekstrand wrote : For each surface with queued content updates and matching main output, the compositor picks the update with the highest timestamp no later than a half frame period after the predicted presentation time. The intent is to pick the content update whose target timestamp as rounded to the output refresh period granularity matches the same display update as the compositor is targeting, while not displaying any content update more than a I'm not really following 100% here. It's not your fault, this is just a terribly awkward sort of thing to try and put into English. It sounds to me like the following: If P0 is the time of the next present and P1 is the time of the one after that, you look for the largest thing less than the average of P1 and P2. Is this correct? Why go for the average? The client is going to have to adjust anyway. If you target t, and P0 and P1 are possible pageflips time, if P0t(1/2)P0+(1/2)P1 then you take the pageflip at P0 if (1/2)P0+(1/2)P1tP1 then you take the pageflip at P1 That way the length of the intersection of the interval (t,t+time between two pageflips) and 'time interval at which it is displayed' is maximized. Well it isn't really the reason why this is choosen (else one might say it would be better to maximize with (t-T/2,t+T/2) with T the time between two pageflips.). The reason is more that you want to minimize the time at when the pageflip happens and t, so the real presentation time and t doesn't differ more than T/2. Axel Davy ___ 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: [RFC] libinput configuration interface
On Thu, Feb 06, 2014 at 11:28:49PM +0100, Eugen Friedrich wrote:
Hi together,
i would like to put some input from the embedded/ automotive perspective.
you can think about huge amount of different configurations for different
device types.
A lot of configuration in the initial post deals with behavior of buttons
and scrolling
areas of the touch panels.
The good approach could be a kind of general configuration of button and
scrolling areas of the touch panels
the button area could contain a position and dimension of the button in the
device coordinate system and the button code
the slider area could contain a position and dimension of the slider along
with the range.
generally for real touch screens (i.e. not touchpads) I think any
interpretation of the values should be on the client side, not in the input
library. There just isn't enough context to interpret it otherwise since
you're at least partially reliant on UI hints or other elements to make sure
you're emulating the right thing.
For specialized cases like having a permanent input region that maps into
semantic buttons (e.g. the button bar on the Android phones) this should IMO
be handled by the compositor.
Also the weston code contains calibration of the absolute values.
It would be good also to have a calibration possibilities in libinput.
Yes, calibration is a required feature, I forgot to mention that since it's
already supported.
Cheers,
Peter
What do you think?
2014-02-03 6:11 GMT+01:00 Alexander E. Patrakov patra...@gmail.com:
2014-02-03 Peter Hutterer peter.hutte...@who-t.net:
On Fri, Jan 31, 2014 at 08:26:54PM +0600, Alexander E. Patrakov wrote:
Peter Hutterer wrote:
I've been thinking about how to add a device configuration interface
to
libinput, and after getting feedback from Jonas and Benjamin, here's a
proposal (no code yet).
First, I think the configuration should be feature-specific, not
device
specific, so it is independent of a classification or capabilities of
a
device. To the user it doesn't matter if we classify something as
touchpad
or as mouse, if middle mouse button emulation works that's the only
thing
that counts. At least for configuration purposes, this also avoids the
difficult task of classifying a device correctly. Those pesky HW
manufacturers do have a habit of coming up with devices that elude
previously agreed-on classification schemes, e.g. mice with touchpads
on
them.
Aside from setting an item, there should be calls to get the current
value,
and a call to reset to the built-in defaults. And, since we're
feature-based, a call to check if the config item is possible for a
device.
Which leads us the the following quartet for each item:
int libinput_device_config_set_foo(device, value);
int libinput_device_config_get_foo(device, value);
int libinput_device_config_reset_foo(device);
bool libinput_device_config_has_foo(device);
And the actual configuration items I've come up with so far:
* {set|get|reset|has}_tap_single_finger_button
* tap_double_finger_button
* tap_triple_finger_button
* click_finger_single
* click_finger_double
* click_finger_triple
* twofinger_scroll_vertical
* twofinger_scroll_horizonal
* edge_scroll_vertical
* edge_scroll_horizontal
* disable_while_typing
* disable_touch (while pen is in use)
these two could be merged into disable while linked device is in
use
* softbutton_left
* softbutton_middle
* softbutton_right
* emulate_middle_button
* button_mapping
* emulate_wheel
* rotation
* palm_detection
* mode (relative/absolute)
* valid_area
This is needed on tablets that have a different ratio than the
monitor.
Mapping them to the monitor results in uneven x/y movements, so the
easiest approach here is to cut a portion of the tablet off to
match the
ratio.
* stylus_button_behaviour(some enum)
Some tablets don't report proximity, the only way to get a
right-button
click is to hold the right button down and then tip with the stylus.
Note that the above is not a 1:1 API mapping, e.g. tapping
configuration
could be an API taking nfingers as argument as opposed to 3 different
calls.
Likewise, they can take more than one value argument, e.g. middle
button
emulation could take a boolean to enable it, and a timeout.
This list excludes options we currently have in the X drivers to
adjust for
hw-specific quirks. Such as defining which pressure makes up a tap,
etc. I
really hope this is something we can work out based on the device.
It also excludes configurations that I'd really like to hide away if
possible. For example, on the new T440-style touchpads the top part
of it is
a set of buttons for the trackstick. There's nothing to
