Re: [PATCH v2 weston 00/16] Atomic modesetting support
On Tue, 23 Jun 2015 11:48:56 +0100 Daniel Stone dan...@fooishbar.org wrote: Hi, On 23 June 2015 at 11:26, Pekka Paalanen ppaala...@gmail.com wrote: you asked me to take a look at the assing_planes code wrt. TEST_ONLY and backtracking. Thanks! As a general comment, carried over from IRC: I think we should get Mario's series reviewed and merged first. It looks like good work, and I don't have any objection to the DRM bits, but am entirely underqualified to review the shell patches. I'd look to get this merged in two parts, with the drm_plane and universal plane conversion coming first, and then the atomic conversion coming later when it's a bit more bedded down and some of those mega-comments have gone away. /* XXX: At this point, we need two runs through assign_planes; * one to prepare any necessary views, and see if there * are any currently-unused planes. This process may * actually free up some planes for other views to use; * if any planes have been freed up, we should do another * pass to see if any planeless views can use any planes * which have just been freed. But we want to cache what * we can, so we're not, e.g., calling gbm_bo_import * twice. */ This is relevant ... Yeah, the logic for populating the atomic req seems mostly ok, but is it missing the primary weston_plane assignment to the primary DRM plane? Or if we are going to do a modeset, shouldn't that be here somehow too? I mean for cases where the primary DRM plane will actually change. If it doesn't change, then I'd assume DRM maintains the state that is not touched. Right, exactly. The atomic ioctl starts by duplicating existing state, and then all property changes are strictly additive; otherwise we wouldn't have any use for the cache at all. Mind you, the cache is broken, because it assumes a strictly linear set of changes, which this breaks, e.g.: + initial modeset - generate new req - populate internal cache with complete desired state - post new req to kernel + repaint - generate new req - populate internal cache with values for new primary fb - post new req to kernel + repaint - assign_planes - generate new req - populate internal cache with speculative values for checking plane - submit req as TEST_ONLY - generate new req - populate internal cache with same values as previous; they're identical, so no change - req doesn't have plane values since our cache says they're unchanged This is the reason for the large 'XXX' comment when calling populate_atomic_plane inside repaint_atomic. So far, my thought has been to add yet another parameter (ugh) to populate_atomic_plane, and thus to plane_add_atomic, which would just call SetProp and not fill the internal cache. A much more flexible solution would be to wrap every drmModeAtomicReq inside a new drm_atomic_state struct, which would contain our internal cache (wdrm_plane_properties etc), but I haven't yet seen anything so far which would demand this more complex solution. The main argument for taking the complex approach is that this is what the kernel does: drm_atomic_state (and its children for CRTC/plane/connector state) are duplicated internally for each request. I think all those problems go away, if you build the final atomic req once and for all, like I suggested below. I think it's fairly error-prone to build it once, test, and build (almost) the same again, not to mention a little wasteful. There would be some fiddling still when you need to back up because a TEST commit said no, but then it'd be only that plane's worth of state. We could simply add a pending value in addition to the current value stored in struct property_item, but yeah, this is all just details. So, the DRM planes we have not assigned yet but were enabled, shouldn't they be disabled in the TEST_ONLY commit? Otherwise they will contain old state and we validate against some new DRM plane states with some previous DRM plane states? That might lead to unnecessary failures from TEST_ONLY commit if we would eventually end up disabling or updating the already enabled DRM planes. The relevant comment above leads to that, yeah. We really need to split the walk up into two passes: firstly find anything currently on a plane which shouldn't be and free those planes up, then walk through and assign everything. I suspect this will be particularly relevant for, e.g., using the primary plane to directly scan out a client buffer. But can you do that in two passes? How can you know if a view is no longer good for a plane if you don't already assing planes to begin with and try with TEST_ONLY commit? The TEST_ONLY call should
Re: [PATCH v2 weston 00/16] Atomic modesetting support
On Tue, Jun 23, 2015 at 12:48 PM, Daniel Stone dan...@fooishbar.org wrote: This is assuming we cannot do without the primary plane. If it was possible to drive truely universal planes, we would not know if we need a primary plane until we know if there is anything on it. You'd have to first assume the primary plane is needed, test the additional plane setups, and then if we don't need the primary plane, test once more without it. Sure, in theory the primary plane can be disabled, but that's not the reality of a lot of common hardware, so we'll have to deal with that assumption for a very long time to come. Just a quick clarification discussed with Daniel on irc: Restrictions on requiring an enabled primary plane are mostly just software since the default primary plane enabled by universal planes can't do anything else. It can also only do rgbx. But atomic (and already even the transitional plane helpers) lift that restriction, and drivers must take explicit action in their atomic_check callbacks to refuse a config with enabled crtc but disabled primary. The default assumption is that primary/cursor planes aren't anything special at all compared to other planes and only used for implementing backwards compatibility with old userspace. The only thing where this differes is that for cursors and primary planes we have dedicated properties to tell userspace the size limits, for sprites there's nothing like that. But givin that max size is just a small part of figuring out what kind of surfaces a driver supports I don't think that's a big deal really ;-) -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 13/13] ivi-shell: rename to ivi_layout_layer_destroy()
On Mon, 22 Jun 2015 15:32:23 +0900 Nobuhiko Tanibata nobuhiko_tanib...@xddp.denso.co.jp wrote: From: Nobuhiko Tanibata nobuhiko_tanib...@xddp.denso.co.jp remove is not proper name beacause it destorys a layer. The name of the api is changed from layer_remove to layer_destroy. Signed-off-by: Nobuhiko Tanibata nobuhiko_tanib...@xddp.denso.co.jp Reviewed-by: Pekka Paalanen pekka.paala...@collabora.co.uk --- ivi-shell/ivi-layout-export.h | 2 +- ivi-shell/ivi-layout.c| 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) Hi Tanibata-san, I decided to push all the 13 fix patches, they should be simple enough: 4ff3874..3aa8aed master - master Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston] compositor: Separate hardcoded backend related code from compositor
Hi Giulio, pq! 2015-06-23 20:57 GMT+09:00 Pekka Paalanen ppaala...@gmail.com: On Tue, 23 Jun 2015 14:14:53 +0300 Giulio Camuffo giuliocamu...@gmail.com wrote: Hi, This kinda goes in the opposite direction to my libweston patches. In that series i move the command line handling away from the backends code to make them work in multiple compositors. This moves even more compositor-specific stuff in the backends so we need to decide if we want this or libweston. We want libweston. I just quick review the libweston on the github ( https://github.com/giucam/weston/). When it will be applied to mainstream ? My understanding about libweston is for reuse the x11/drm related code for other compositor project (like libinput). Yes, It is everyone want :-) But, since the backend structure which manages multiple plugins and load symbol 'backend_xxx()' is weston compositor specific stuff and it is not in the scope of libweston, I believe my proposal is not the opposite idea to the libweston what you are preparing. (In your repository, my proposal may change the src/weston.c to remove hardcoded backend option outputs. It is not part of libweston library. ) 2015-06-23 13:29 GMT+03:00 JoonCheol Park joonch...@gmail.com: Instead of adding available backends and usage outputs at build time, this patch finds all available backend plugins in MODULEDIR and prints them. It also prints usage output for selected backend by calling backend_usage() in the plugin. By this patch, we can remove all hardcode for backends from compositor. 3rd party backend plugin can be listed in help output. Backend developer can freely add additional description for backend. Signed-off-by: JoonCheol Park joonch...@gmail.com --- src/compositor-drm.c | 11 src/compositor-fbdev.c| 9 +++ src/compositor-headless.c | 11 src/compositor-rdp.c | 15 + src/compositor-rpi.c | 12 src/compositor-wayland.c | 14 + src/compositor-x11.c | 13 + src/compositor.c | 141 -- src/compositor.h | 3 + 9 files changed, 125 insertions(+), 104 deletions(-) JoonCheol, any particular reason you are proposing this? Are you building external backends? Yeap, I'm trying to make some fun experiments based on headless backend code. When I tried to add new options for backend plugin, I had to add option outputs for my backend into main compositor code. not in the plugin itself. Since it is kind of hardcode, I thought it doesn't look good. I think that plugin should have such information of itself and compositor should load such information from plugin file. (similar case: In case of NPAPI, Web browser can show plugin's information by getting/calling NP_GetMIMEDescription() from each plugin .so file. e.g - about:config in Mozilla) So, I created this patch for better (weston specific) backend plugin management structure. AFAIK the Weston SDK (the installed headers) for external plugins never supported external backends, so I'm curious. Since this kind of plugin just need header files for building and weston.pc is also already supported, I thought that building external backend plugin is supported (and ideally possible in current version of weston)... but wasn't it?? If it can be supported, it would be good for like my case. Developer can create the backend plugin without build all weston source.. (like other '-dev' pkg supported program) We are going in the direction of backends becoming libweston internal details, not something you can plug and switch arbitrarily, at least for the middle-term. Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston 11/11] configure: add an option to allow building only the libraries
Le 22/06/2015 22:02, Giulio Camuffo a écrit : the --enable/disable-weston-binaries enables or disables the creation of 'weston', 'weston-launch' and all the binaries that are installed in $prefix/lib/libexec. This allows, together with --enable-clients, to only build the libraries, making possible to build and install different libweston versions at the same time. --- Makefile.am | 15 +++ configure.ac | 8 2 files changed, 23 insertions(+) diff --git a/Makefile.am b/Makefile.am index 2d24bcc..43b69ad 100644 --- a/Makefile.am +++ b/Makefile.am @@ -106,6 +106,8 @@ nodist_libweston_@ABI_VERSION@_la_SOURCES = \ BUILT_SOURCES += $(nodist_libweston_@ABI_VERSION@_la_SOURCES) + +if BUILD_WESTON_BINARIES bin_PROGRAMS += weston weston_LDFLAGS = -export-dynamic @@ -135,6 +137,7 @@ nodist_weston_SOURCES = \ protocol/text-server-protocol.h \ protocol/input-method-protocol.c\ protocol/input-method-server-protocol.h +endif BUILT_SOURCES += $(nodist_weston_SOURCES) @@ -178,6 +181,7 @@ endif .FORCE : if BUILD_WESTON_LAUNCH +if BUILD_WESTON_BINARIES bin_PROGRAMS += weston-launch weston_launch_SOURCES = src/weston-launch.c src/weston-launch.h weston_launch_CPPFLAGS = -DBINDIR='$(bindir)' @@ -200,6 +204,7 @@ install-exec-hook: false; \ fi endif +endif # BUILD_WESTON_BINARIES endif # BUILD_WESTON_LAUNCH @@ -445,6 +450,7 @@ if BUILD_CLIENTS bin_PROGRAMS += weston-terminal weston-info +if BUILD_WESTON_BINARIES libexec_PROGRAMS += \ weston-desktop-shell\ weston-screenshooter\ @@ -455,6 +461,7 @@ if ENABLE_IVI_SHELL libexec_PROGRAMS += \ weston-ivi-shell-user-interface endif +endif demo_clients = \ weston-flower \ @@ -574,6 +581,7 @@ weston_flower_SOURCES = clients/flower.c weston_flower_LDADD = libtoytoolkit.la weston_flower_CFLAGS = $(AM_CFLAGS) $(CLIENT_CFLAGS) +if BUILD_WESTON_BINARIES weston_screenshooter_SOURCES = \ clients/screenshot.c nodist_weston_screenshooter_SOURCES =\ @@ -581,6 +589,7 @@ nodist_weston_screenshooter_SOURCES = \ protocol/screenshooter-client-protocol.h weston_screenshooter_LDADD = $(CLIENT_LIBS) libshared.la weston_screenshooter_CFLAGS = $(AM_CFLAGS) $(CLIENT_CFLAGS) +endif weston_terminal_SOURCES =\ clients/terminal.c \ @@ -692,6 +701,7 @@ weston_editor_LDADD = libtoytoolkit.la $(PANGO_LIBS) weston_editor_CFLAGS = $(AM_CFLAGS) $(CLIENT_CFLAGS) $(PANGO_CFLAGS) endif +if BUILD_WESTON_BINARIES weston_keyboard_SOURCES = clients/keyboard.c nodist_weston_keyboard_SOURCES = \ protocol/desktop-shell-client-protocol.h\ @@ -707,6 +717,7 @@ nodist_weston_simple_im_SOURCES = \ protocol/input-method-client-protocol.h weston_simple_im_LDADD = $(CLIENT_LIBS) weston_simple_im_CFLAGS = $(AM_CFLAGS) $(CLIENT_CFLAGS) +endif weston_info_SOURCES =\ clients/weston-info.c \ @@ -717,6 +728,7 @@ nodist_weston_info_SOURCES = \ weston_info_LDADD = $(WESTON_INFO_LIBS) libshared.la weston_info_CFLAGS = $(AM_CFLAGS) $(CLIENT_CFLAGS) +if BUILD_WESTON_BINARIES weston_desktop_shell_SOURCES = \ clients/desktop-shell.c \ shared/helpers.h @@ -725,7 +737,9 @@ nodist_weston_desktop_shell_SOURCES = \ protocol/desktop-shell-protocol.c weston_desktop_shell_LDADD = libtoytoolkit.la weston_desktop_shell_CFLAGS = $(AM_CFLAGS) $(CLIENT_CFLAGS) +endif +if BUILD_WESTON_BINARIES if ENABLE_IVI_SHELL weston_ivi_shell_user_interface_SOURCES =\ clients/ivi-shell-user-interface.c \ @@ -738,6 +752,7 @@ nodist_weston_ivi_shell_user_interface_SOURCES = \ weston_ivi_shell_user_interface_LDADD = libtoytoolkit.la weston_ivi_shell_user_interface_CFLAGS = $(AM_CFLAGS) $(CLIENT_CFLAGS) endif +endif if BUILD_FULL_GL_CLIENTS demo_clients += weston-gears diff --git a/configure.ac b/configure.ac index f6780e8..3578811 100644 --- a/configure.ac +++ b/configure.ac @@ -357,6 +357,12 @@ PKG_CHECK_MODULES(SYSTEMD_LOGIN_209, [libsystemd-login = 209], AS_IF([test x$have_systemd_login_209 = xyes], [AC_DEFINE([HAVE_SYSTEMD_LOGIN_209], [1], [Have systemd-login = 209])]) +AC_ARG_ENABLE(weston-binaries, + AS_HELP_STRING([--enable-weston-binaries], +
Re: [PATCH weston] compositor: Separate hardcoded backend related code from compositor
2015-06-23 20:40 GMT+03:00 JoonCheol Park joonch...@gmail.com: Hi Giulio, pq! 2015-06-23 20:57 GMT+09:00 Pekka Paalanen ppaala...@gmail.com: On Tue, 23 Jun 2015 14:14:53 +0300 Giulio Camuffo giuliocamu...@gmail.com wrote: Hi, This kinda goes in the opposite direction to my libweston patches. In that series i move the command line handling away from the backends code to make them work in multiple compositors. This moves even more compositor-specific stuff in the backends so we need to decide if we want this or libweston. We want libweston. I just quick review the libweston on the github (https://github.com/giucam/weston/). When it will be applied to mainstream ? My understanding about libweston is for reuse the x11/drm related code for other compositor project (like libinput). Yes, It is everyone want :-) But, since the backend structure which manages multiple plugins and load symbol 'backend_xxx()' is weston compositor specific stuff and it is not in the scope of libweston, I believe my proposal is not the opposite idea to the libweston what you are preparing. (In your repository, my proposal may change the src/weston.c to remove hardcoded backend option outputs. It is not part of libweston library. ) Well, but you are adding weston specific stuff into the backends code, that is the options handling. In libweston the backends do not parse the command line or the config file, so all the backend options are weston specific. 2015-06-23 13:29 GMT+03:00 JoonCheol Park joonch...@gmail.com: Instead of adding available backends and usage outputs at build time, this patch finds all available backend plugins in MODULEDIR and prints them. It also prints usage output for selected backend by calling backend_usage() in the plugin. By this patch, we can remove all hardcode for backends from compositor. 3rd party backend plugin can be listed in help output. Backend developer can freely add additional description for backend. Signed-off-by: JoonCheol Park joonch...@gmail.com --- src/compositor-drm.c | 11 src/compositor-fbdev.c| 9 +++ src/compositor-headless.c | 11 src/compositor-rdp.c | 15 + src/compositor-rpi.c | 12 src/compositor-wayland.c | 14 + src/compositor-x11.c | 13 + src/compositor.c | 141 -- src/compositor.h | 3 + 9 files changed, 125 insertions(+), 104 deletions(-) JoonCheol, any particular reason you are proposing this? Are you building external backends? Yeap, I'm trying to make some fun experiments based on headless backend code. When I tried to add new options for backend plugin, I had to add option outputs for my backend into main compositor code. not in the plugin itself. Since it is kind of hardcode, I thought it doesn't look good. I think that plugin should have such information of itself and compositor should load such information from plugin file. (similar case: In case of NPAPI, Web browser can show plugin's information by getting/calling NP_GetMIMEDescription() from each plugin .so file. e.g - about:config in Mozilla) So, I created this patch for better (weston specific) backend plugin management structure. AFAIK the Weston SDK (the installed headers) for external plugins never supported external backends, so I'm curious. Since this kind of plugin just need header files for building and weston.pc is also already supported, I thought that building external backend plugin is supported (and ideally possible in current version of weston)... but wasn't it?? If it can be supported, it would be good for like my case. Developer can create the backend plugin without build all weston source.. (like other '-dev' pkg supported program) We are going in the direction of backends becoming libweston internal details, not something you can plug and switch arbitrarily, at least for the middle-term. Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH libinput 2/5] Add configuration interface for tap drag-lock
On Sun, Jun 21, 2015 at 9:54 PM, Peter Hutterer peter.hutte...@who-t.net wrote: In some applications, notably Inkscape, where it is common to frequently drag objects a short distance the default to drag-lock always-on is frustrating for users. Make it configurable, with the current default to on. New API: libinput_device_config_tap_set_drag_lock_enabled libinput_device_config_tap_get_drag_lock_enabled libinput_device_config_tap_get_default_drag_lock_enabled Any device capable of tapping is capable of drag lock, there is no explicit availability check for drag lock. Configuration is independent, drag lock may be enabled when tapping is disabled. Perhaps you are already doing this, but can't you require the mouse to be held down and/or moved more than some threshold on the first drag to turn on drag-lock mode? I would think also that it would help to only turn it on if the finger is released near the edge of the touchpad, and not in the middle. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston] compositor: Separate hardcoded backend related code from compositor
Actually... yesterday I was just bouncing off of Bryce some ideas in regards to tuning up the options parser to clean up a bit of the current mess in regards to params, help messages, keeping multiple areas in sync, etc. I *think* I've been starting to see some of the same issues that JoonCheol is trying to address. It also looks to me that Giulio's work and this are not completely blocking of each other... and that some clarification might help facilitate covering both sets of needs. The problems seem very similar to plugin architecture issues I've worked on in the past, so after some review it should not be too hard to put forth some technical details on different ways to reconcile these needs. There are also a few different approaches to parameter handling that could be leveraged. At least I won't have to code support for Unicode params on Win95 again :-) On 06/23/2015 12:22 PM, Giulio Camuffo wrote: 2015-06-23 21:57 GMT+03:00 JoonCheol Park joonch...@gmail.com: 2015-06-24 2:49 GMT+09:00 Giulio Camuffo giuliocamu...@gmail.com: 2015-06-23 20:40 GMT+03:00 JoonCheol Park joonch...@gmail.com: Hi Giulio, pq! 2015-06-23 20:57 GMT+09:00 Pekka Paalanen ppaala...@gmail.com: On Tue, 23 Jun 2015 14:14:53 +0300 Giulio Camuffo giuliocamu...@gmail.com wrote: Hi, This kinda goes in the opposite direction to my libweston patches. In that series i move the command line handling away from the backends code to make them work in multiple compositors. This moves even more compositor-specific stuff in the backends so we need to decide if we want this or libweston. We want libweston. I just quick review the libweston on the github (https://github.com/giucam/weston/). When it will be applied to mainstream ? My understanding about libweston is for reuse the x11/drm related code for other compositor project (like libinput). Yes, It is everyone want :-) But, since the backend structure which manages multiple plugins and load symbol 'backend_xxx()' is weston compositor specific stuff and it is not in the scope of libweston, I believe my proposal is not the opposite idea to the libweston what you are preparing. (In your repository, my proposal may change the src/weston.c to remove hardcoded backend option outputs. It is not part of libweston library. ) Which branch should I see on your repository? libweston ? libweston-v2 ? I found that you mentioned structure in branch libweston-v2. (right ?) libweston-v2 was slighly old, i updated it now. Well, but you are adding weston specific stuff into the backends code, that is the options handling. backend plugin (and option handling) is the *weston* compositor specific. so this is not the problem I think. The backends are not weston specific, that is one of the point of libweston, to share them. Only the initialization is compositor specific. In libweston the backends do not parse the command line or the config file, so all the backend options are weston specific. In your code (src/weston.c, branch libweston-v2), as you explained, the weston (compositor main) have the code for parse options for all known backend plugin before init it. But, there are many hard code option outputs for only known backend plugins. In this case, we don't have to load plugin file dynamically. And it use the weston_compositor_init_backend of the libweston.so which has hard coded backend list. I think this function should not be included in the libweston.so if its goal is to be reused for other compositor. Since the weston_compositor_init_backend is for weston specific backend plugin initialization, it is not necessary function for others. actually the version i sent to the list doesn't have the backends enum, they are loaded like now by using the filename of the .so or the absolute path. and as i said above the backends are meant to be shared between compositor. 2015-06-23 13:29 GMT+03:00 JoonCheol Park joonch...@gmail.com: Instead of adding available backends and usage outputs at build time, this patch finds all available backend plugins in MODULEDIR and prints them. It also prints usage output for selected backend by calling backend_usage() in the plugin. By this patch, we can remove all hardcode for backends from compositor. 3rd party backend plugin can be listed in help output. Backend developer can freely add additional description for backend. Signed-off-by: JoonCheol Park joonch...@gmail.com --- src/compositor-drm.c | 11 src/compositor-fbdev.c| 9 +++ src/compositor-headless.c | 11 src/compositor-rdp.c | 15 + src/compositor-rpi.c | 12 src/compositor-wayland.c | 14 + src/compositor-x11.c | 13 + src/compositor.c | 141 -- src/compositor.h | 3 + 9 files changed, 125 insertions(+), 104 deletions(-) JoonCheol, any particular reason you are proposing
Re: [PATCH weston] compositor: Separate hardcoded backend related code from compositor
2015-06-23 21:57 GMT+03:00 JoonCheol Park joonch...@gmail.com: 2015-06-24 2:49 GMT+09:00 Giulio Camuffo giuliocamu...@gmail.com: 2015-06-23 20:40 GMT+03:00 JoonCheol Park joonch...@gmail.com: Hi Giulio, pq! 2015-06-23 20:57 GMT+09:00 Pekka Paalanen ppaala...@gmail.com: On Tue, 23 Jun 2015 14:14:53 +0300 Giulio Camuffo giuliocamu...@gmail.com wrote: Hi, This kinda goes in the opposite direction to my libweston patches. In that series i move the command line handling away from the backends code to make them work in multiple compositors. This moves even more compositor-specific stuff in the backends so we need to decide if we want this or libweston. We want libweston. I just quick review the libweston on the github (https://github.com/giucam/weston/). When it will be applied to mainstream ? My understanding about libweston is for reuse the x11/drm related code for other compositor project (like libinput). Yes, It is everyone want :-) But, since the backend structure which manages multiple plugins and load symbol 'backend_xxx()' is weston compositor specific stuff and it is not in the scope of libweston, I believe my proposal is not the opposite idea to the libweston what you are preparing. (In your repository, my proposal may change the src/weston.c to remove hardcoded backend option outputs. It is not part of libweston library. ) Which branch should I see on your repository? libweston ? libweston-v2 ? I found that you mentioned structure in branch libweston-v2. (right ?) libweston-v2 was slighly old, i updated it now. Well, but you are adding weston specific stuff into the backends code, that is the options handling. backend plugin (and option handling) is the *weston* compositor specific. so this is not the problem I think. The backends are not weston specific, that is one of the point of libweston, to share them. Only the initialization is compositor specific. In libweston the backends do not parse the command line or the config file, so all the backend options are weston specific. In your code (src/weston.c, branch libweston-v2), as you explained, the weston (compositor main) have the code for parse options for all known backend plugin before init it. But, there are many hard code option outputs for only known backend plugins. In this case, we don't have to load plugin file dynamically. And it use the weston_compositor_init_backend of the libweston.so which has hard coded backend list. I think this function should not be included in the libweston.so if its goal is to be reused for other compositor. Since the weston_compositor_init_backend is for weston specific backend plugin initialization, it is not necessary function for others. actually the version i sent to the list doesn't have the backends enum, they are loaded like now by using the filename of the .so or the absolute path. and as i said above the backends are meant to be shared between compositor. 2015-06-23 13:29 GMT+03:00 JoonCheol Park joonch...@gmail.com: Instead of adding available backends and usage outputs at build time, this patch finds all available backend plugins in MODULEDIR and prints them. It also prints usage output for selected backend by calling backend_usage() in the plugin. By this patch, we can remove all hardcode for backends from compositor. 3rd party backend plugin can be listed in help output. Backend developer can freely add additional description for backend. Signed-off-by: JoonCheol Park joonch...@gmail.com --- src/compositor-drm.c | 11 src/compositor-fbdev.c| 9 +++ src/compositor-headless.c | 11 src/compositor-rdp.c | 15 + src/compositor-rpi.c | 12 src/compositor-wayland.c | 14 + src/compositor-x11.c | 13 + src/compositor.c | 141 -- src/compositor.h | 3 + 9 files changed, 125 insertions(+), 104 deletions(-) JoonCheol, any particular reason you are proposing this? Are you building external backends? Yeap, I'm trying to make some fun experiments based on headless backend code. When I tried to add new options for backend plugin, I had to add option outputs for my backend into main compositor code. not in the plugin itself. Since it is kind of hardcode, I thought it doesn't look good. I think that plugin should have such information of itself and compositor should load such information from plugin file. (similar case: In case of NPAPI, Web browser can show plugin's information by getting/calling NP_GetMIMEDescription() from each plugin .so file. e.g - about:config in Mozilla) So, I created this patch for better (weston specific) backend plugin management structure. AFAIK the Weston SDK (the installed
Re: [PATCH weston] compositor: Separate hardcoded backend related code from compositor
2015-06-23 21:22 GMT+03:00 Bill Spitzak spit...@gmail.com: On Tue, Jun 23, 2015 at 10:49 AM, Giulio Camuffo giuliocamu...@gmail.com wrote: Well, but you are adding weston specific stuff into the backends code, that is the options handling. In libweston the backends do not parse the command line or the config file, so all the backend options are weston specific. This just seems wrong to me. Why are these backends .so files at all, then? The compositor cannot load any it does not know about since it requires passing this option structure that it had to know about at compile time. It would be far more efficient to just link all of them into the compositor then and it would start up faster. It is true that weston.c currently needs to know about the plugins at compile time, however nobody stops another compositor (or weston) to put the backend inititalization in its own plugins, and gain back support for random backends, with one plugin for libweston and one plugin for the compositor that inits the new backend. Going away with the plugins in libweston would remove that possibility. I agree it does not look perfect, but i'm not sure what better options there are. It's true that this is not going to really kill anything, but it does suffer from code smell. Adding an option to a backend will require modifying a header file that compositors have to include (the one defining the option structure for that backend) and changing all compositors to set that option in the structure, as well as modifying the backend itself. There is no header to modify, only a new one to add. If you go with the compositor plugins as above you don't need to touch the main compositor code. Passing a weston_options structure and letting the backend remove options it understands I think will work fine. That does not mean the compositor has to use the weston option parser to create the structure. And it certainly does not mean the backends are parsing the command line. The current ones are not being passed argv so this is obviously false. The current backends (in master), do parse the command line, check again. Anyway, all this is easily said, but my attempts at doing so failed. My hope is that after we settle down with the initial break we will be able to unify the backends api. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston] compositor: Separate hardcoded backend related code from compositor
2015-06-24 2:49 GMT+09:00 Giulio Camuffo giuliocamu...@gmail.com: 2015-06-23 20:40 GMT+03:00 JoonCheol Park joonch...@gmail.com: Hi Giulio, pq! 2015-06-23 20:57 GMT+09:00 Pekka Paalanen ppaala...@gmail.com: On Tue, 23 Jun 2015 14:14:53 +0300 Giulio Camuffo giuliocamu...@gmail.com wrote: Hi, This kinda goes in the opposite direction to my libweston patches. In that series i move the command line handling away from the backends code to make them work in multiple compositors. This moves even more compositor-specific stuff in the backends so we need to decide if we want this or libweston. We want libweston. I just quick review the libweston on the github (https://github.com/giucam/weston/). When it will be applied to mainstream ? My understanding about libweston is for reuse the x11/drm related code for other compositor project (like libinput). Yes, It is everyone want :-) But, since the backend structure which manages multiple plugins and load symbol 'backend_xxx()' is weston compositor specific stuff and it is not in the scope of libweston, I believe my proposal is not the opposite idea to the libweston what you are preparing. (In your repository, my proposal may change the src/weston.c to remove hardcoded backend option outputs. It is not part of libweston library. ) Which branch should I see on your repository? libweston ? libweston-v2 ? I found that you mentioned structure in branch libweston-v2. (right ?) Well, but you are adding weston specific stuff into the backends code, that is the options handling. backend plugin (and option handling) is the *weston* compositor specific. so this is not the problem I think. In libweston the backends do not parse the command line or the config file, so all the backend options are weston specific. In your code (src/weston.c, branch libweston-v2), as you explained, the weston (compositor main) have the code for parse options for all known backend plugin before init it. But, there are many hard code option outputs for only known backend plugins. In this case, we don't have to load plugin file dynamically. And it use the weston_compositor_init_backend of the libweston.so which has hard coded backend list. I think this function should not be included in the libweston.so if its goal is to be reused for other compositor. Since the weston_compositor_init_backend is for weston specific backend plugin initialization, it is not necessary function for others. 2015-06-23 13:29 GMT+03:00 JoonCheol Park joonch...@gmail.com: Instead of adding available backends and usage outputs at build time, this patch finds all available backend plugins in MODULEDIR and prints them. It also prints usage output for selected backend by calling backend_usage() in the plugin. By this patch, we can remove all hardcode for backends from compositor. 3rd party backend plugin can be listed in help output. Backend developer can freely add additional description for backend. Signed-off-by: JoonCheol Park joonch...@gmail.com --- src/compositor-drm.c | 11 src/compositor-fbdev.c| 9 +++ src/compositor-headless.c | 11 src/compositor-rdp.c | 15 + src/compositor-rpi.c | 12 src/compositor-wayland.c | 14 + src/compositor-x11.c | 13 + src/compositor.c | 141 -- src/compositor.h | 3 + 9 files changed, 125 insertions(+), 104 deletions(-) JoonCheol, any particular reason you are proposing this? Are you building external backends? Yeap, I'm trying to make some fun experiments based on headless backend code. When I tried to add new options for backend plugin, I had to add option outputs for my backend into main compositor code. not in the plugin itself. Since it is kind of hardcode, I thought it doesn't look good. I think that plugin should have such information of itself and compositor should load such information from plugin file. (similar case: In case of NPAPI, Web browser can show plugin's information by getting/calling NP_GetMIMEDescription() from each plugin .so file. e.g - about:config in Mozilla) So, I created this patch for better (weston specific) backend plugin management structure. AFAIK the Weston SDK (the installed headers) for external plugins never supported external backends, so I'm curious. Since this kind of plugin just need header files for building and weston.pc is also already supported, I thought that building external backend plugin is supported (and ideally possible in current version of weston)... but wasn't it?? If it can be supported, it would be good for like my case. Developer can create the backend plugin without build all weston source.. (like other '-dev' pkg supported program) We
Re: Wayland Relative Pointer API Progress
On Sun, Jun 21, 2015 at 11:46 PM, x414e54 x414...@linux.com wrote: Hi I have been away for a while and quite busy so I did not get a chance to response. On Tue, Apr 28, 2015 at 3:46 AM, Bill Spitzak spit...@gmail.com wrote: No, I absolutely 100% disagree. Synchronized updating so things don't vibrate or shift is more important than FPS. It is even stated as part of Wayland's basic design criteria: every frame is perfect. Wow... no seriously... This is wrong on so many levels and probably shows you either have never used either Weston or Gnome Shell when they had laggy slow mouse issues. You do not seem to be understanding in the least what I am asking for. There is one key word in there lag. I am not introducing any lag. If the client takes 1/2 second to draw the result of a mouse movement, it will still take 1/2 second under my scheme. Exactly the same amount of lag. However in my scheme the cursor will be drawn in the correct place atop the dragged object, thus satisfying the every frame is perfect requirement while not changing anything about lag. So in your system the compositor would have to block mouse cursor movement until an application had dispatched and processed its events. Literally in this instance the user would be moving the physical mouse and nothing happening on screen Yes, despite your attempt to be condescending, you are accurately describing EXACTLY what I want! nothing happening on the screen is BETTER than the wrong thing is drawn on the screen. Just like all other interaction such as window raising the compositor can certainly time out and fake it if it appears the client is dead. I also thought it might be ok to limit sync mouse cursor to times when the button is down, and make it optional for the client, by some slight modifications to the proposed pointer lock api. But you may be correct (even though you are pertending you are wrong) that it is desirable even when moving the mouse, as it would allow the program to highlight fine detail hit targets. This is useful in complex geometry to make it easier to pick things that are close together. Current programs either require the user to hold the mouse still for a split second to make sure the correct thing will be picked on click, or complex things like Maya typically draw their own manipulator to force sync. . Which is why (I assume) for moving windows the compositor does 100% of the work. The compositor is doing the window moving so that it can implement snapping. The client does not have sufficient information to do this. I sure hope it is not because somebody said Wayland is too slow to do this any other way. That would be really sad if the developers of Wayland thought that. Because if the application was involved there would be lagging movement whilst the application was switched out or doing something else. The application is involved already. Window dragging will not start until the application responds with the drag request. It does not work which is why no Window Managers ever do or should do this. Really? Simple experiments show that Windows does this when dragging a window (drag a window really fast and spot where it drew the cursor, it draws is many fewer times than if you move the mouse the same speed without dragging, and perfectly locked to the window). This is almost 100% of the reason people think Windows drags windows more smoothly than X11. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston] compositor: Separate hardcoded backend related code from compositor
On Tue, Jun 23, 2015 at 10:49 AM, Giulio Camuffo giuliocamu...@gmail.com wrote: Well, but you are adding weston specific stuff into the backends code, that is the options handling. In libweston the backends do not parse the command line or the config file, so all the backend options are weston specific. This just seems wrong to me. Why are these backends .so files at all, then? The compositor cannot load any it does not know about since it requires passing this option structure that it had to know about at compile time. It would be far more efficient to just link all of them into the compositor then and it would start up faster. It's true that this is not going to really kill anything, but it does suffer from code smell. Adding an option to a backend will require modifying a header file that compositors have to include (the one defining the option structure for that backend) and changing all compositors to set that option in the structure, as well as modifying the backend itself. Passing a weston_options structure and letting the backend remove options it understands I think will work fine. That does not mean the compositor has to use the weston option parser to create the structure. And it certainly does not mean the backends are parsing the command line. The current ones are not being passed argv so this is obviously false. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Weston hangs with copypaste actions from /to gedit and firefox ??
Hi list, I do not have an backtrace nor some hints, but FYI I have a problem with firefox and gedit under wayland-devel I have opened a text file (a patch in this case) and doing copy and paste into the gmail editor window of firefox. suddenly the weston desktop hangs - a remote login is possible and the only way to reset the session. Ok the hardware power button is working too, so a clean shutdown is possible. This issue with the hang of weston is reproduce able and I avoid to use gedit or gvim in a weston session. DId some others notice that issue or have also the same behaviour ? or is this only my local box?? I did not retest on another box yet, cause having two boxes to pull and compile - needs a lot of time. In the case I want to make a valueable backtrace, what do you suggest to enable the right DEBUG settings ? I also notice often that in the Copy Paste case that some lines are missing like you see below: I have selected the first screen of the weston startup messages and paste it into the gmail editor, but all lines starting with TAB or WHITESPACE seems to be deleted/ignored or whatever... On the other hand I can use weston over some weeks without any big issues (or reboots etc) - that must be said, it is soo nice to have weston as a native display manager/ desktop. [13:28:14.653] weston 1.8.90 here I miss some lines, they are all empty added instead really pasted here [13:28:14.653] OS: Linux, 3.19.8.0, #121 SMP Tue May 12 11:13:35 CEST 2015, x86_64 [13:28:14.653] Using config file '/home/b23/.config/weston.ini' [13:28:14.656] Loading module '/usr/local/lib/weston/wayland-backend.so' [13:28:14.671] Output repaint window is 7 ms maximum. [13:28:14.672] Loading module '/usr/local/lib/weston/gl-renderer.so' [13:28:14.680] EGL client extensions: EGL_EXT_client_extensions [13:28:14.728] Creating 1024x640 wayland output at (0, 0) [13:28:14.730] EGL version: 1.4 (DRI2) Ok I have started weston on top of a weston session and reproduce the mentioned issue above and I got in the terminal: [13:50:53.124] GTK_TEXT_BUFFER_CONTENTS [13:50:53.124] GTK_TEXT_BUFFER_CONTENTS [13:50:53.124] xfixes selection notify event: owner 0 [13:50:53.124] GTK_TEXT_BUFFER_CONTENTS [13:50:53.124] GTK_TEXT_BUFFER_CONTENTS [13:50:53.124] xfixes selection notify event: owner 0 [13:50:53.124] GTK_TEXT_BUFFER_CONTENTS [13:50:53.124] GTK_TEXT_BUFFER_CONTENTS [13:50:53.124] xfixes selection notify event: owner 0 [13:50:53.124] GTK_TEXT_BUFFER_CONTENTS [13:50:53.124] GTK_TEXT_BUFFER_CONTENTS [13:50:53.124] xfixes selection notify event: owner 0 [13:50:53.124] GTK_TEXT_BUFFER_CONTENTS [13:50:53.124] GTK_TEXT_BUFFER_CONTENTS [13:50:53.124] xfixes selection notify event: owner 0 [13:50:53.124] GTK_TEXT_BUFFER_CONTENTS [13:50:53.124] GTK_TEXT_BUFFER_CONTENTS [13:50:53.124] xfixes selection notify event: owner 0 [13:50:53.124] GTK_TEXT_BUFFER_CONTENTS [13:50:53.124] GTK_TEXT_BUFFER_CONTENTS [13:50:53.124] xfixes selection notify event: owner 0 [13:50:53.124] GTK_TEXT_BUFFER_CONTENTS [13:50:53.124] GTK_TEXT_BUFFER_CONTENTS [13:50:53.124] xfixes selection notify event: owner 0 [13:50:53.124] GTK_TEXT_BUFFER_CONTENTS [13:50:53.124] GTK_TEXT_BUFFER_CONTENTS [13:50:53.124] xfixes selection notify event: owner 0 [13:50:53.125] GTK_TEXT_BUFFER_CONTENTS [13:50:53.125] GTK_TEXT_BUFFER_CONTENTS I hope some of you have an idea whats going on. The weston on top of weston still hangs, spotting all the time these message until I kill weston ;) Good work so far. Cheers, Christian H. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston] compositor: Separate hardcoded backend related code from compositor
On Tue, 23 Jun 2015 14:14:53 +0300 Giulio Camuffo giuliocamu...@gmail.com wrote: Hi, This kinda goes in the opposite direction to my libweston patches. In that series i move the command line handling away from the backends code to make them work in multiple compositors. This moves even more compositor-specific stuff in the backends so we need to decide if we want this or libweston. We want libweston. 2015-06-23 13:29 GMT+03:00 JoonCheol Park joonch...@gmail.com: Instead of adding available backends and usage outputs at build time, this patch finds all available backend plugins in MODULEDIR and prints them. It also prints usage output for selected backend by calling backend_usage() in the plugin. By this patch, we can remove all hardcode for backends from compositor. 3rd party backend plugin can be listed in help output. Backend developer can freely add additional description for backend. Signed-off-by: JoonCheol Park joonch...@gmail.com --- src/compositor-drm.c | 11 src/compositor-fbdev.c| 9 +++ src/compositor-headless.c | 11 src/compositor-rdp.c | 15 + src/compositor-rpi.c | 12 src/compositor-wayland.c | 14 + src/compositor-x11.c | 13 + src/compositor.c | 141 -- src/compositor.h | 3 + 9 files changed, 125 insertions(+), 104 deletions(-) JoonCheol, any particular reason you are proposing this? Are you building external backends? AFAIK the Weston SDK (the installed headers) for external plugins never supported external backends, so I'm curious. We are going in the direction of backends becoming libweston internal details, not something you can plug and switch arbitrarily, at least for the middle-term. Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC PATCH] Allow more file descriptors than clients limit
Hi
I've filed bug https://bugs.freedesktop.org/show_bug.cgi?id=91072 to keep track
of this issue and copying Wayland-devel ML as well since this is affecting
Wayland/XWayland primarily.
Cheers,
Olivier
- Original Message -
The X server assumes that one file descriptor is opened per client, so
it limits the number of file descriptors to the number of clients.
Unfortunately Xwayland opens a lot more file descriptors than a regular
X server because of those weston-shared-XX anonymous files for
sharing buffers. The number of additional file descriptors opened depends
on the clients so the actual limit depends on what applications are
running.
Once the X server (Xwayland) reaches the maximum number of file
descriptors opened, it will raise a Maximum number of clients reached
error and deny new connections even if the actual number of clients is
a lot less that the expected limit, thus limiting the number of clients
in Xwayland to a much lower value than the expected default limit of 256
clients.
Raise the limit of file descriptors to match XFD_SETSIZE set in Xproto
while retaining the current limit of clients to a lower value, allowing
for more usable clients in Xwayland (even if the client limit will
remain a theoretical limit unlikely to be reachable in Xwayland).
Signed-off-by: Olivier Fourdan ofour...@redhat.com
---
See also: http://lists.x.org/archives/xorg-devel/2015-May/046543.html
include/opaque.h | 1 +
os/WaitFor.c | 4 ++--
os/connection.c | 38 ++
3 files changed, 21 insertions(+), 22 deletions(-)
diff --git a/include/opaque.h b/include/opaque.h
index a2c54aa..99e310e 100644
--- a/include/opaque.h
+++ b/include/opaque.h
@@ -36,6 +36,7 @@ from The Open Group.
extern _X_EXPORT const char *defaultTextFont;
extern _X_EXPORT const char *defaultCursorFont;
extern _X_EXPORT int MaxClients;
+extern _X_EXPORT int limitFileDesc;
extern _X_EXPORT volatile char isItTimeToYield;
extern _X_EXPORT volatile char dispatchException;
diff --git a/os/WaitFor.c b/os/WaitFor.c
index 431f1a6..74e0b2e 100644
--- a/os/WaitFor.c
+++ b/os/WaitFor.c
@@ -220,10 +220,10 @@ WaitForSomething(int *pClientsReady)
i = -1;
else if (AnyClientsWriteBlocked) {
XFD_COPYSET(ClientsWriteBlocked, clientsWritable);
-i = Select(MaxClients, LastSelectMask, clientsWritable, NULL,
wt);
+i = Select(limitFileDesc, LastSelectMask, clientsWritable,
NULL, wt);
}
else {
-i = Select(MaxClients, LastSelectMask, NULL, NULL, wt);
+i = Select(limitFileDesc, LastSelectMask, NULL, NULL, wt);
}
selecterr = GetErrno();
WakeupHandler(i, (void *) LastSelectMask);
diff --git a/os/connection.c b/os/connection.c
index c36b125..4df6a67 100644
--- a/os/connection.c
+++ b/os/connection.c
@@ -119,7 +119,7 @@ SOFTWARE.
#include probes.h
-static int lastfdesc; /* maximum file descriptor */
+int limitFileDesc = -1; /* maximum file descriptor */
fd_set WellKnownConnections;/* Listener mask */
fd_set EnabledDevices; /* mask for input devices that are on */
@@ -264,44 +264,42 @@ lookup_trans_conn(int fd)
return NULL;
}
-/* Set MaxClients and lastfdesc, and allocate ConnectionTranslation */
+/* Set MaxClients and limitFileDesc, and allocate ConnectionTranslation */
void
InitConnectionLimits(void)
{
-lastfdesc = -1;
-
#ifndef __CYGWIN__
#if !defined(XNO_SYSCONF) defined(_SC_OPEN_MAX)
-lastfdesc = sysconf(_SC_OPEN_MAX) - 1;
+limitFileDesc = sysconf(_SC_OPEN_MAX) - 1;
#endif
#ifdef HAVE_GETDTABLESIZE
-if (lastfdesc 0)
-lastfdesc = getdtablesize() - 1;
+if (limitFileDesc 0)
+limitFileDesc = getdtablesize() - 1;
#endif
#ifdef _NFILE
-if (lastfdesc 0)
-lastfdesc = _NFILE - 1;
+if (limitFileDesc 0)
+limitFileDesc = _NFILE - 1;
#endif
#endif /* __CYGWIN__ */
/* This is the fallback */
-if (lastfdesc 0)
-lastfdesc = MAXSOCKS;
+if (limitFileDesc 0)
+limitFileDesc = MAXSOCKS;
-if (lastfdesc MAXSELECT)
-lastfdesc = MAXSELECT;
+if (limitFileDesc MAXSELECT)
+limitFileDesc = MAXSELECT;
-if (lastfdesc MAXCLIENTS) {
-lastfdesc = MAXCLIENTS;
+if (limitFileDesc XFD_SETSIZE) {
+limitFileDesc = XFD_SETSIZE;
if (debug_conns)
-ErrorF(REACHED MAXIMUM CLIENTS LIMIT %d\n, MAXCLIENTS);
+ErrorF(REACHED MAXIMUM CONNECTIONS LIMIT %d\n, XFD_SETSIZE);
}
-MaxClients = lastfdesc;
+MaxClients = MIN(MAXCLIENTS, limitFileDesc);
#ifdef DEBUG
ErrorF(InitConnectionLimits: MaxClients = %d\n, MaxClients);
@@ -309,7 +307,7 @@ InitConnectionLimits(void)
#if !defined(WIN32)
if
dlopen(libglapi) (Re: [PATCH 08/11] confiigure: drop unused variable GBM_BACKEND_DIRS)
On Sun, 21 Jun 2015 16:03:09 + Emil Velikov emil.l.veli...@gmail.com wrote: On 19/06/15 22:00, Eric Anholt wrote: I find 9/10 weird -- if the DRI drivers need libglapi, why aren't they just linking libglapi? Short version - currently they don't because of hysterical raisins, once we move to shared-glapi only libGL we'll add the link. Long version - the dri modules require glapi provider. Which could be either one of: 1) the xserver glapi (no longer there since ~1.14) 2) libGL with static glapi 3) the shared glapi Thanks to some interesting overlinking of libgbm, which itself has propagated to libEGL, people won't notice the issue if they're not using 1) or 2). So people working directly with EGL/gbm (wayland/weston folk, everyone writing their wayland compositor, Google with their gbm work) has noticed those and had the same workaround for a while. While most of us working with X and/or GLX did not see it. This of course is prominent, (only?) when using dlopen(libgbm/libEGL), rather than linking against them. Aaah, so this explains all the hassle with http://cgit.freedesktop.org/wayland/weston/tree/src/compositor-drm.c?id=1.8.0#n1382 When 1) and 2) are gone (second is on it's way out), we can add the link to the dri modules. Although neither helps in the case of using old dri module with new loader, thus the need for the explicit dlopen(). A nice reminder of that strange piece of code in Weston. Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH libinput 1/2] touchpad: only send most recent edge delta when triggering threshold
Hi,
On 23-06-15 06:00, Peter Hutterer wrote:
When edge scrolling is triggered by exceeding the motion threshold (5mm) we
sent the whole delta as the first scroll event, causing a big jump.
Instead, send only the current delta. This effectively introduces a 5mm dead
zone when edge scrolling, still better than the jump.
https://bugs.freedesktop.org/show_bug.cgi?id=90990
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
Series looks good and is:
Reviewed-by: Hans de Goede hdego...@redhat.com
Regards,
Hans
---
src/evdev-mt-touchpad-edge-scroll.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/src/evdev-mt-touchpad-edge-scroll.c
b/src/evdev-mt-touchpad-edge-scroll.c
index 56f1e8a..992a169 100644
--- a/src/evdev-mt-touchpad-edge-scroll.c
+++ b/src/evdev-mt-touchpad-edge-scroll.c
@@ -353,7 +353,7 @@ tp_edge_scroll_post_events(struct tp_dispatch *tp, uint64_t
time)
struct tp_touch *t;
enum libinput_pointer_axis axis;
double *delta;
- struct normalized_coords normalized;
+ struct normalized_coords normalized, tmp;
const struct normalized_coords zero = { 0.0, 0.0 };
const struct discrete_coords zero_discrete = { 0.0, 0.0 };
@@ -402,11 +402,14 @@ tp_edge_scroll_post_events(struct tp_dispatch *tp,
uint64_t time)
t-scroll.edge_state);
break;
case EDGE_SCROLL_TOUCH_STATE_EDGE_NEW:
+ tmp = normalized;
normalized = tp_normalize_delta(tp,
device_delta(t-point,
t-scroll.initial));
if (fabs(*delta) DEFAULT_SCROLL_THRESHOLD)
normalized = zero;
+ else
+ normalized = tmp;
break;
case EDGE_SCROLL_TOUCH_STATE_EDGE:
break;
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston] build: Use AM_CFLAGS instead of GCC_CFLAGS
On Thu, 18 Jun 2015 09:59:42 -0700 Jon A. Cruz j...@osg.samsung.com wrote: On 06/18/2015 09:43 AM, Derek Foreman wrote: AM_CFLAGS is the default for any target that doesn't specify its own cflags. We should use AM_CFLAGS in preference to GCC_CFLAGS so we can change AM_CFLAGS and get all targets. Signed-off-by: Derek Foreman der...@osg.samsung.com --- Makefile.am | 64 ++--- 1 file changed, 32 insertions(+), 32 deletions(-) Looks good. As I mentioned to Derek earlier I had just hit this in the documentation when checking for some other things I was adding (and disentangling for testing). Reviewed-by: Jon A. Cruz j...@osg.samsung.com This one had some conflicts with Added new include file to all SOURCES variables with files that use it. but I think I sorted them out. Pushed: b37ac40..4ff3874 master - master Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland] build: Use AM_CFLAGS instead of GCC_CFLAGS everywhere
On Thu, 18 Jun 2015 09:59:26 -0700 Jon A. Cruz j...@osg.samsung.com wrote: On 06/18/2015 09:27 AM, Derek Foreman wrote: This will make it easier if we ever want to add new flags to everything in the future. Signed-off-by: Derek Foreman der...@osg.samsung.com --- Makefile.am | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/Makefile.am b/Makefile.am index 845c116..58f5595 100644 --- a/Makefile.am +++ b/Makefile.am @@ -34,7 +34,7 @@ else wayland_scanner = wayland-scanner endif -libwayland_util_la_CFLAGS = $(GCC_CFLAGS) +libwayland_util_la_CFLAGS = $(AM_CFLAGS) libwayland_util_la_SOURCES = \ src/wayland-util.c \ src/wayland-util.h @@ -65,7 +65,7 @@ nodist_include_HEADERS = \ protocol/wayland-server-protocol.h \ protocol/wayland-client-protocol.h -libwayland_server_la_CFLAGS = $(FFI_CFLAGS) $(GCC_CFLAGS) -pthread +libwayland_server_la_CFLAGS = $(FFI_CFLAGS) $(AM_CFLAGS) -pthread libwayland_server_la_LIBADD = $(FFI_LIBS) libwayland-util.la -lrt -lm libwayland_server_la_LDFLAGS = -version-info 1:0:1 libwayland_server_la_SOURCES = \ @@ -77,7 +77,7 @@ nodist_libwayland_server_la_SOURCES = \ protocol/wayland-server-protocol.h \ protocol/wayland-protocol.c -libwayland_client_la_CFLAGS = $(FFI_CFLAGS) $(GCC_CFLAGS) -pthread +libwayland_client_la_CFLAGS = $(FFI_CFLAGS) $(AM_CFLAGS) -pthread libwayland_client_la_LIBADD = $(FFI_LIBS) libwayland-util.la -lrt -lm libwayland_client_la_LDFLAGS = -version-info 3:0:3 libwayland_client_la_SOURCES = \ @@ -131,7 +131,7 @@ libwayland_cursor_la_LIBADD = libwayland-client.la pkgconfig_DATA += cursor/wayland-cursor.pc libwayland_cursor_la_CFLAGS = \ - $(GCC_CFLAGS) \ + $(AM_CFLAGS)\ -I$(top_builddir)/src \ -I$(top_srcdir)/src \ -DICONDIR=\$(ICONDIR)\ Looks good. As I mentioned to Derek earlier I had just hit this in the documentation when checking for some other things I was adding (and disentangling for testing). Reviewed-by: Jon A. Cruz j...@osg.samsung.com Pushed: a8a8601..4cdc510 master - master Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland] cosmetic: gratuitous whitespace changes in event-loop.c
On Thu, 18 Jun 2015 09:56:09 -0700 Jon A. Cruz j...@osg.samsung.com wrote: On 06/18/2015 09:48 AM, Derek Foreman wrote: Signed-off-by: Derek Foreman der...@osg.samsung.com --- src/event-loop.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/event-loop.c b/src/event-loop.c index d1e03fa..130c7be 100644 --- a/src/event-loop.c +++ b/src/event-loop.c @@ -199,7 +199,7 @@ wl_event_loop_add_timer(struct wl_event_loop *loop, source-base.interface = timer_source_interface; source-base.fd = timerfd_create(CLOCK_MONOTONIC, - TFD_CLOEXEC | TFD_NONBLOCK); +TFD_CLOEXEC | TFD_NONBLOCK); source-func = func; return add_source(loop, source-base, WL_EVENT_READABLE, data); Looks good. (Seems like someone had tabs set to 4 and didn't notice.) Reviewed-by: Jon A. Cruz j...@osg.samsung.com Pushed: 4cdc510..ab254f7 master - master Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston] compositor: Separate hardcoded backend related code from compositor
Hi,
This kinda goes in the opposite direction to my libweston patches. In
that series i move the command line handling away from the backends
code to make them work in multiple compositors. This moves even more
compositor-specific stuff in the backends so we need to decide if we
want this or libweston.
--
Giulio
2015-06-23 13:29 GMT+03:00 JoonCheol Park joonch...@gmail.com:
Instead of adding available backends and usage outputs at build time,
this patch finds all available backend plugins in MODULEDIR and prints
them. It also prints usage output for selected backend by calling
backend_usage() in the plugin.
By this patch, we can remove all hardcode for backends from compositor.
3rd party backend plugin can be listed in help output. Backend developer
can freely add additional description for backend.
Signed-off-by: JoonCheol Park joonch...@gmail.com
---
src/compositor-drm.c | 11
src/compositor-fbdev.c| 9 +++
src/compositor-headless.c | 11
src/compositor-rdp.c | 15 +
src/compositor-rpi.c | 12
src/compositor-wayland.c | 14 +
src/compositor-x11.c | 13 +
src/compositor.c | 141
--
src/compositor.h | 3 +
9 files changed, 125 insertions(+), 104 deletions(-)
diff --git a/src/compositor-drm.c b/src/compositor-drm.c
index 6d8684d..0714f34 100644
--- a/src/compositor-drm.c
+++ b/src/compositor-drm.c
@@ -3002,3 +3002,14 @@ backend_init(struct wl_display *display, int *argc,
char *argv[],
return drm_compositor_create(display, param, argc, argv, config);
}
+
+WL_EXPORT const char *
+backend_usage(void)
+{
+ return Options for fbdev-backend.so:\n\n
+ --connector=ID\tBring up only this connector\n
+ --seat=SEAT\t\tThe seat that weston should run on\n
+ --tty=TTY\t\tThe tty to use\n
+ --use-pixman\t\tUse the pixman (CPU) renderer\n
+ --current-mode\tPrefer current KMS mode over EDID preferred mode;
+}
diff --git a/src/compositor-fbdev.c b/src/compositor-fbdev.c
index a6fd823..c4d6166 100644
--- a/src/compositor-fbdev.c
+++ b/src/compositor-fbdev.c
@@ -928,3 +928,12 @@ backend_init(struct wl_display *display, int *argc, char
*argv[],
return fbdev_compositor_create(display, argc, argv, config, param);
}
+
+WL_EXPORT const char *
+backend_usage(void)
+{
+ return Options for fbdev-backend.so:\n\n
+ --tty=TTY\t\tThe tty to use\n
+ --device=DEVICE\tThe framebuffer device to use\n
+ --use-gl\t\tUse the GL renderer;
+}
diff --git a/src/compositor-headless.c b/src/compositor-headless.c
index c0e35ce..d1d1b75 100644
--- a/src/compositor-headless.c
+++ b/src/compositor-headless.c
@@ -287,3 +287,14 @@ backend_init(struct wl_display *display, int *argc, char
*argv[],
return headless_compositor_create(display, param, display_name,
argc, argv, config);
}
+
+WL_EXPORT const char *
+backend_usage(void)
+{
+ return Options for headless-backend.so:\n\n
+ --width=WIDTH\t\tWidth of memory surface\n
+ --height=HEIGHT\tHeight of memory surface\n
+ --transform=TR\tThe output transformation, TR is one of:\n
+ \tnormal 90 180 270 flipped flipped-90 flipped-180 flipped-270\n
+ --use-pixman\t\tUse the pixman (CPU) renderer (default: no
rendering);
+}
diff --git a/src/compositor-rdp.c b/src/compositor-rdp.c
index 6d4d1e4..750aa67 100644
--- a/src/compositor-rdp.c
+++ b/src/compositor-rdp.c
@@ -1275,3 +1275,18 @@ backend_init(struct wl_display *display, int *argc,
char *argv[],
return rdp_compositor_create(display, config, argc, argv, wconfig);
}
+
+WL_EXPORT const char *
+backend_usage(void)
+{
+ return Options for rdp-backend.so:\n\n
+ --width=WIDTH\t\tWidth of desktop\n
+ --height=HEIGHT\tHeight of desktop\n
+ --env-socket=SOCKET\tUse that socket as peer connection\n
+ --address=ADDR\tThe address to bind\n
+ --port=PORT\t\tThe port to listen on\n
+ --no-clients-resize\tThe RDP peers will be forced to the size of
the desktop\n
+ --rdp4-key=FILE\tThe file containing the key for RDP4 encryption\n
+ --rdp-tls-cert=FILE\tThe file containing the certificate for TLS
encryption\n
+ --rdp-tls-key=FILE\tThe file containing the private key for TLS
encryption;
+}
diff --git a/src/compositor-rpi.c b/src/compositor-rpi.c
index 8012461..9bf39bc 100644
--- a/src/compositor-rpi.c
+++ b/src/compositor-rpi.c
@@ -584,3 +584,15 @@ backend_init(struct wl_display *display, int *argc, char
*argv[],
return rpi_compositor_create(display, argc, argv, config, param);
}
+
+WL_EXPORT const char *
+backend_usage(void)
+{
+ return Options for rpi-backend.so:\n\n
+ --tty=TTY\t\tThe tty to use\n
+
Re: Wayland Relative Pointer API Progress
On Mon, 22 Jun 2015 15:46:41 +0900 x414e54 x414...@linux.com wrote: This is wrong on so many levels and probably shows you either have never used either Weston or Gnome Shell when they had laggy slow mouse issues. I believe Gnome has partially fixed it but there was still massive lag when entering/exiting some Windows and it changed over the image last time I checked. This means every so often the mouse got stuck then flew across the screen. FWIW, Weston does not block pointer motion on client response. If a client is lagging, the effect you will see[*] is that the cursor will keep on moving as normal, but the cursor image will change only when the client catches up (e.g. from arrow to hand). If the pointer is already gone when the client catches up, that client cannot change the cursor anymore (implemented with input serials). That's the exception we make to the every frame is perfect rule: the compositor cannot wait for arbitrary clients. If the client is the one drawing and moving the cursor, the rules change: the user is on the mercy of the client's responsiveness. Then the every frame is perfect rule is in full strength: all state updates the client sends need a way to be applied atomically to avoid the possibility of transient visual glitches. Which mode one should pick is a whole another question. Obviously you can't have the benefits of both without requiring real-time responsiveness from the client, in which case the choice becomes mostly irrelevant. Thanks, pq [*] There are other reasons that may stall Weston's output: a heavy GPU task in a client can slow everything down. Those are a very different matter and cause. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH v2 weston 00/16] Atomic modesetting support
Hi, On 23 June 2015 at 11:26, Pekka Paalanen ppaala...@gmail.com wrote: you asked me to take a look at the assing_planes code wrt. TEST_ONLY and backtracking. Thanks! As a general comment, carried over from IRC: I think we should get Mario's series reviewed and merged first. It looks like good work, and I don't have any objection to the DRM bits, but am entirely underqualified to review the shell patches. I'd look to get this merged in two parts, with the drm_plane and universal plane conversion coming first, and then the atomic conversion coming later when it's a bit more bedded down and some of those mega-comments have gone away. /* XXX: At this point, we need two runs through assign_planes; * one to prepare any necessary views, and see if there * are any currently-unused planes. This process may * actually free up some planes for other views to use; * if any planes have been freed up, we should do another * pass to see if any planeless views can use any planes * which have just been freed. But we want to cache what * we can, so we're not, e.g., calling gbm_bo_import * twice. */ This is relevant ... Yeah, the logic for populating the atomic req seems mostly ok, but is it missing the primary weston_plane assignment to the primary DRM plane? Or if we are going to do a modeset, shouldn't that be here somehow too? I mean for cases where the primary DRM plane will actually change. If it doesn't change, then I'd assume DRM maintains the state that is not touched. Right, exactly. The atomic ioctl starts by duplicating existing state, and then all property changes are strictly additive; otherwise we wouldn't have any use for the cache at all. Mind you, the cache is broken, because it assumes a strictly linear set of changes, which this breaks, e.g.: + initial modeset - generate new req - populate internal cache with complete desired state - post new req to kernel + repaint - generate new req - populate internal cache with values for new primary fb - post new req to kernel + repaint - assign_planes - generate new req - populate internal cache with speculative values for checking plane - submit req as TEST_ONLY - generate new req - populate internal cache with same values as previous; they're identical, so no change - req doesn't have plane values since our cache says they're unchanged This is the reason for the large 'XXX' comment when calling populate_atomic_plane inside repaint_atomic. So far, my thought has been to add yet another parameter (ugh) to populate_atomic_plane, and thus to plane_add_atomic, which would just call SetProp and not fill the internal cache. A much more flexible solution would be to wrap every drmModeAtomicReq inside a new drm_atomic_state struct, which would contain our internal cache (wdrm_plane_properties etc), but I haven't yet seen anything so far which would demand this more complex solution. The main argument for taking the complex approach is that this is what the kernel does: drm_atomic_state (and its children for CRTC/plane/connector state) are duplicated internally for each request. So, the DRM planes we have not assigned yet but were enabled, shouldn't they be disabled in the TEST_ONLY commit? Otherwise they will contain old state and we validate against some new DRM plane states with some previous DRM plane states? That might lead to unnecessary failures from TEST_ONLY commit if we would eventually end up disabling or updating the already enabled DRM planes. The relevant comment above leads to that, yeah. We really need to split the walk up into two passes: firstly find anything currently on a plane which shouldn't be and free those planes up, then walk through and assign everything. I suspect this will be particularly relevant for, e.g., using the primary plane to directly scan out a client buffer. The TEST_ONLY call should contain everything the final atomic commit call will, right? So once assign_planes is done, we should already have the complete atomic req, and in output_repaint what's left to do is to actually render the leftovers and commit. I suppose this means we need to prepare the next buffer for a primary weston_plane already at assign_planes start and use it in the TEST_ONLY commit, before we even render to it. I hope it won't screw up any fencing in DRM or EGL. But can we get it out of EGL/GBM *before* we render it? We need an equivalent buffer that the primary DRM plane's buffer is going to be for TEST_ONLY commits, so that we can check what can go to overlays, so we know what we will need to render. Indeed; the key is an equivalent buffer, rather than a rendered buffer, because we can't know what to render (think planes with alpha) until we've
Re: [PATCH v2 weston 00/16] Atomic modesetting support
On Mon, 22 Jun 2015 17:25:05 +0100
Daniel Stone dani...@collabora.com wrote:
Hi,
Thanks to everyone who reviewed the previous series. This new series
cleans up the previous patches, introduces a few fixes (e.g. not relying
on a repaint to pull us out of DPMS), and crucially adds support for the
libdrm TEST_ONLY interface (allowing us to check before we commit, e.g.
that a particular plane combination is workable), using the new cursor
API from libdrm.
This still relies on support not yet mainlined. Currently I am using:
git://git.collabora.co.uk/git/user/daniels/linux.git#wip/4.2.x/atomic-i915
git://git.collabora.co.uk/git/user/daniels/libdrm.git#atomic
Hi Daniel,
you asked me to take a look at the assing_planes code wrt. TEST_ONLY
and backtracking.
The selected code quotations below are from after the complete series.
static void
drm_plane_update_begin(struct drm_plane *plane)
{
plane-props.value_pend_mask = 0;
}
/**
* Try to use the primary DRM plane to directly display a full-screen view
*
* If a surface covers an entire output and is unoccluded, attempt to directly
* pageflip the primary DRM plane (not to be confused with the primary Weston
* plane) to the buffer. In legacy DRM usage, this will use drmModePageFlip;
* in atomic, this is just another plane.
*
* @param output Output to target
* @param ev View to prospectively use the primary plane
*/
static struct weston_plane *
drm_output_prepare_scanout_view(struct drm_output *output,
struct weston_view *ev)
{
struct drm_compositor *c =
(struct drm_compositor *) output-base.compositor;
struct weston_buffer *buffer = ev-surface-buffer_ref.buffer;
struct weston_buffer_viewport *viewport = ev-surface-buffer_viewport;
struct gbm_bo *bo;
uint32_t format;
if (ev-geometry.x != output-base.x ||
ev-geometry.y != output-base.y ||
buffer == NULL || c-gbm == NULL ||
buffer-width != output-base.current_mode-width ||
buffer-height != output-base.current_mode-height ||
output-base.transform != viewport-buffer.transform ||
ev-transform.enabled)
return NULL;
if (ev-geometry.scissor_enabled)
return NULL;
bo = gbm_bo_import(c-gbm, GBM_BO_IMPORT_WL_BUFFER,
buffer-resource, GBM_BO_USE_SCANOUT);
/* Unable to use the buffer for scanout */
if (!bo)
return NULL;
format = drm_output_check_scanout_format(output, ev-surface, bo);
if (format == 0) {
gbm_bo_destroy(bo);
return NULL;
}
output-primary_plane-next = drm_fb_get_from_bo(bo, c, format);
if (!output-primary_plane-next) {
gbm_bo_destroy(bo);
return NULL;
}
drm_fb_set_buffer(output-primary_plane-next, buffer);
return output-fb_plane;
}
static struct weston_plane *
drm_output_prepare_overlay_view(struct drm_output *output,
struct weston_view *ev)
{
struct weston_compositor *ec = output-base.compositor;
struct drm_compositor *c = (struct drm_compositor *)ec;
struct weston_buffer_viewport *viewport = ev-surface-buffer_viewport;
struct drm_plane *p;
struct drm_plane *cur = NULL;
int found = 0;
struct gbm_bo *bo;
pixman_region32_t dest_rect, src_rect;
pixman_box32_t *box, tbox;
uint32_t format;
wl_fixed_t sx1, sy1, sx2, sy2;
if (c-gbm == NULL)
return NULL;
if (viewport-buffer.transform != output-base.transform)
return NULL;
if (viewport-buffer.scale != output-base.current_scale)
return NULL;
if (c-sprites_are_broken)
return NULL;
if (ev-output_mask != (1u output-base.id))
return NULL;
if (ev-surface-buffer_ref.buffer == NULL)
return NULL;
if (ev-alpha != 1.0f)
return NULL;
if (wl_shm_buffer_get(ev-surface-buffer_ref.buffer-resource))
return NULL;
if (!drm_view_transform_supported(ev))
return NULL;
/* Find the current view this plane is assigned to, if any. */
wl_list_for_each(p, c-plane_list, link) {
if (p-view != ev || p-output != output)
continue;
cur = p;
break;
}
bo = gbm_bo_import(c-gbm, GBM_BO_IMPORT_WL_BUFFER,
ev-surface-buffer_ref.buffer-resource,
GBM_BO_USE_SCANOUT);
wl_list_for_each(p, c-plane_list, link) {
if (!bo)
continue;
if (!drm_plane_crtc_supported(output, p-possible_crtcs))
continue;
Re: [PATCH v4 1/6] Added simple unit/integration test framework and corresponding test program.
On 06/22/2015 07:19 AM, Pekka Paalanen wrote: Hi Jon, this is just a quick casual look, so I'm only mentioning what cought my eye but mostly ignoring minor issues like style. I know you sent a v5 series, but it sounded like my comments here are still applicable. I do get kind of confused every time a function is used earlier in the file than where it is defined. I have a habit of scrolling up when I see a function call I want to know what it does. Is that just me? Looking into it more, I think I've figured out much of that on my part comes from C++ and other OO languages I've worked in. Especially with C++ one should start a class declaration with a single 'public' section followed optionally by a single 'protected' section and finally a single 'private' section if needed. So the general structure tends to be from higher-level first in the file down to lower-level later on. Also IDE use can promote the F3 to go do declaration over manually scrolling approach. Since weston here is solidly in the non-C++ C camp I'll be reworking the order to match (either in later revisions or in follow-ups as needed). More below. On Thu, 11 Jun 2015 22:01:27 -0700 Jon A. Cruz j...@osg.samsung.com wrote: Added a simple C-based test framework and an example program that uses it to run through some simple wayland client checks. This is new code inspired primarily by the approaches of Google Test, Boost Test, JUnit and TestNG. Factors of others were also considered during design and implementation. Signed-off-by: Jon A. Cruz j...@osg.samsung.com --- .gitignore |3 + Makefile.am| 87 +- tools/waycheck/moretest.c | 89 ++ tools/waycheck/rough_draw.c| 273 + tools/waycheck/rough_draw.h| 62 + tools/waycheck/waycheck.c | 435 +++ tools/waycheck/waycheck.dox| 29 + tools/wayland_fixtures/inc/wtst_fixtures.h | 279 + tools/wayland_fixtures/src/wtst_fixtures.c | 1115 ++ tools/zunitc/doc/zunitc.dox| 138 +++ tools/zunitc/inc/zunitc/zunitc.h | 681 +++ tools/zunitc/inc/zunitc/zunitc_impl.h | 102 ++ tools/zunitc/src/main.c| 46 + tools/zunitc/src/zuc_base_logger.c | 401 +++ tools/zunitc/src/zuc_base_logger.h | 35 + tools/zunitc/src/zuc_collector.c | 424 +++ tools/zunitc/src/zuc_collector.h | 55 + tools/zunitc/src/zuc_context.h | 55 + tools/zunitc/src/zuc_event.h | 83 ++ tools/zunitc/src/zuc_event_listener.h | 171 +++ tools/zunitc/src/zuc_types.h | 77 ++ tools/zunitc/src/zunitc_impl.c | 1726 tools/zunitc/test/fixtures_test.c | 104 ++ tools/zunitc/test/zunitc_test.c| 456 24 files changed, 6925 insertions(+), 1 deletion(-) create mode 100644 tools/waycheck/moretest.c create mode 100644 tools/waycheck/rough_draw.c create mode 100644 tools/waycheck/rough_draw.h create mode 100644 tools/waycheck/waycheck.c create mode 100644 tools/waycheck/waycheck.dox create mode 100644 tools/wayland_fixtures/inc/wtst_fixtures.h create mode 100644 tools/wayland_fixtures/src/wtst_fixtures.c create mode 100644 tools/zunitc/doc/zunitc.dox create mode 100644 tools/zunitc/inc/zunitc/zunitc.h create mode 100644 tools/zunitc/inc/zunitc/zunitc_impl.h create mode 100644 tools/zunitc/src/main.c create mode 100644 tools/zunitc/src/zuc_base_logger.c create mode 100644 tools/zunitc/src/zuc_base_logger.h create mode 100644 tools/zunitc/src/zuc_collector.c create mode 100644 tools/zunitc/src/zuc_collector.h create mode 100644 tools/zunitc/src/zuc_context.h create mode 100644 tools/zunitc/src/zuc_event.h create mode 100644 tools/zunitc/src/zuc_event_listener.h create mode 100644 tools/zunitc/src/zuc_types.h create mode 100644 tools/zunitc/src/zunitc_impl.c create mode 100644 tools/zunitc/test/fixtures_test.c create mode 100644 tools/zunitc/test/zunitc_test.c diff --git a/tools/waycheck/moretest.c b/tools/waycheck/moretest.c new file mode 100644 index 000..f0c2a4c --- /dev/null +++ b/tools/waycheck/moretest.c @@ -0,0 +1,89 @@ +/* + * Copyright © 2015 Samsung Electronics Co., 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
Re: [PATCH weston 04/11] make the backends compositor-neutral
On 06/22/2015 10:51 PM, Giulio Camuffo wrote: 2015-06-23 3:52 GMT+03:00 Bill Spitzak spit...@gmail.com: It seems like prev On Mon, Jun 22, 2015 at 1:02 PM, Giulio Camuffo giuliocamu...@gmail.com wrote: The backends used to have lots of code dealing with weston specific configs. To allow them to be used by other compositors with their own configurations remove all the usage of weston_config from the backends code and move it in weston.c. It seems like the previous version allowed the backend to decide on the name, type, and number of config options that it understood, while this requires the main program to have all that knowledge. Thus it does not seem as good. Not really. The previous versions had quite frankestein plugins, in that they also had an entry point specific for the compositor weston. Other compositors still needed to handle config in the compositor itself. By making all even for all compositors i think the new version is better. Yes... I really like that we don't have the I-call-you-now-you-call-me-again loops anymore. Just because it is a weston_config structure does not mean it has to contain the contents of a weston configuration. A different compositor could just extract any backend-specific details from it's own configuration database and write a dummy weston_config containing them. I'm not sre what you mean. Other compositors will not use weston_config, many needed functions for it are not even exported. And there is not just weston_config, there also is the command line options handling which can vary between compositors. Aside from working on various plugin systems, I was just addressing some of the command-line parsing/config issues for the newer testing framework so certain concepts jumped out at me. First, the aspect that the backends are half-dynamic and half-hardcoded is an aspect that raised some flags in my mind right away. Since patch 2 added an API to manage instances, it seems good to try to go with that all the way. And then minimizing the use of void* would help, since that is often a source of problems. (to clarify, using 'void *' for an opaque value to be returned for callbacks is good, but using one as a key input that must be of the correct type for the situation gets to be very problematic). One design choice would be to have backends parse out what they need. Another would be to remove all knowledge of parsing and parameters and leave that up to the hosting code. This patch had started on the route of moving things out of the parser, but then we end up with a lot in main.c/weston.c. If this was chosen then I'd suggest breaking those parts out to a separate file so the ugly guts of backend-specific hardcoding was more encapsulated. However... I personally would prefer to see more follow-up on the API added in patch 2. One way to facilitate this would be to add a call for fetching the option-parser struct details from a backend. Then adding argc and argv to the *init() entrypoint would remove the need for all the hardcoding in weston.c/main.c. The main code could pull out known parameters from the argv list and pass a controlled (or entirely synthesized) list to the backend. For processing help messages, returning the info from a backend call would help. Add a member to the struct for help and then all hardcoding could be removed from the main code. This is a separate issue, but could remove a lot of string duplication and chance for maintenance error. (this was what Bryce mentioned on the thread [PATCH weston] compositor: Separate hardcoded backend related code from compositor There are many different ways to implement the details of param handling that avoid the explicit structs added here. Backends could parse out or the hosting weston.c/main.c could. Anyway... since this patchset looks to be at least 80% of the way to nicely abstracting the backends, I think it would be quite worth it to complete the final 20% and not punt by hardcoding. Secondary issue is that we've now ended up with overloading the term compositor in our code to have weston_compositor and compositor_x11 belonging to different sets. However that does look to me like something we can clean up in a later patchset. -- Jon A. Cruz - Senior Open Source Developer Samsung Open Source Group j...@osg.samsung.com ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston 06/11] build a libweston.so used by the weston binary
On 06/22/2015 01:02 PM, Giulio Camuffo wrote: The library is versioned, so a -N is appended to its name, e.g. libweston-1.so. The same is done for the pc file, the include and lib/weston dirs. This allows multiple libweston versions to be installed together. Ooooh! ABI-versions. Nice. I've been in a few situations where this really helps. Looks good. Reviewed-by: Jon A. Cruz j...@osg.samsung.com --- Makefile.am | 59 ++- configure.ac | 3 +++ src/input.c | 2 +- 3 files changed, 42 insertions(+), 22 deletions(-) diff --git a/Makefile.am b/Makefile.am index 29430e3..581014f 100644 --- a/Makefile.am +++ b/Makefile.am @@ -3,7 +3,7 @@ ACLOCAL_AMFLAGS = -I m4 bin_PROGRAMS = noinst_PROGRAMS = libexec_PROGRAMS = -moduledir = $(libdir)/weston +moduledir = $(libdir)/weston-$(ABI_VERSION) module_LTLIBRARIES = noinst_LTLIBRARIES = BUILT_SOURCES = @@ -59,26 +59,20 @@ CLEANFILES = weston.ini \ internal-screenshot-00.png \ $(BUILT_SOURCES) -bin_PROGRAMS += weston - -weston_LDFLAGS = -export-dynamic -weston_CPPFLAGS = $(AM_CPPFLAGS) -DIN_WESTON -weston_CFLAGS = $(GCC_CFLAGS) $(COMPOSITOR_CFLAGS) $(LIBUNWIND_CFLAGS) -weston_LDADD = $(COMPOSITOR_LIBS) $(LIBUNWIND_LIBS) \ +lib_LTLIBRARIES = libweston-@ABI_VERSION@.la +libweston_@ABI_VERSION@_la_CPPFLAGS =\ + $(AM_CPPFLAGS) -DIN_WESTON +libweston_@ABI_VERSION@_la_CFLAGS = \ + $(GCC_CFLAGS) $(COMPOSITOR_CFLAGS) \ + $(LIBUNWIND_CFLAGS) +libweston_@ABI_VERSION@_la_LIBADD = \ + $(COMPOSITOR_LIBS) $(LIBUNWIND_LIBS)\ $(DLOPEN_LIBS) -lm libshared.la -weston_SOURCES = \ +libweston_@ABI_VERSION@_la_SOURCES = \ src/git-version.h \ - src/log.c \ src/compositor.c\ src/compositor.h\ - src/compositor-x11.h\ - src/compositor-wayland.h\ - src/compositor-drm.h\ - src/compositor-headless.h \ - src/compositor-fbdev.h \ - src/compositor-rdp.h\ - src/compositor-rpi.h\ src/input.c \ src/data-device.c \ src/screenshooter.c \ @@ -93,7 +87,6 @@ weston_SOURCES =\ src/timeline.c \ src/timeline.h \ src/timeline-object.h \ - src/weston.c\ shared/helpers.h\ shared/matrix.c \ shared/matrix.h \ @@ -101,7 +94,7 @@ weston_SOURCES = \ shared/platform.h \ src/weston-egl-ext.h -nodist_weston_SOURCES = \ +nodist_libweston_@ABI_VERSION@_la_SOURCES = \ protocol/screenshooter-protocol.c \ protocol/screenshooter-server-protocol.h\ protocol/text-cursor-position-protocol.c\ @@ -117,7 +110,28 @@ nodist_weston_SOURCES = \ protocol/scaler-protocol.c \ protocol/scaler-server-protocol.h -BUILT_SOURCES += $(nodist_weston_SOURCES) +BUILT_SOURCES += $(nodist_libweston_@ABI_VERSION@_la_SOURCES) + +bin_PROGRAMS += weston + +weston_LDFLAGS = -export-dynamic +weston_CPPFLAGS = $(AM_CPPFLAGS) -DIN_WESTON +weston_CFLAGS = $(GCC_CFLAGS) $(COMPOSITOR_CFLAGS) $(LIBUNWIND_CFLAGS) +weston_LDADD = $(COMPOSITOR_LIBS) $(LIBUNWIND_LIBS) \ + $(DLOPEN_LIBS) -lm libshared.la \ + libweston-@ABI_VERSION@.la + +weston_SOURCES = \ + src/weston.c\ + src/compositor-x11.h\ + src/compositor-wayland.h\ + src/compositor-drm.h\ + src/compositor-headless.h \ + src/compositor-fbdev.h \ + src/compositor-rdp.h\ + src/compositor-rpi.h\ + src/log.c \ + shared/helpers.h # Track this dependency explicitly instead of using BUILT_SOURCES. We # add BUILT_SOURCES to CLEANFILES, but we want to keep git-version.h @@ -185,13
Re: [PATCH weston] compositor: Separate hardcoded backend related code from compositor
On Tue, Jun 23, 2015 at 12:48:13PM -0700, Jon A. Cruz wrote: Actually... yesterday I was just bouncing off of Bryce some ideas in regards to tuning up the options parser to clean up a bit of the current mess in regards to params, help messages, keeping multiple areas in sync, etc. Yeah at the time I added all those ifdef's I wondered if it'd be better to make the options help text live with the backend code itself, to improve modularity. So I think this patch is a step in the right direction. I have some further suggestions though. I *think* I've been starting to see some of the same issues that JoonCheol is trying to address. It also looks to me that Giulio's work and this are not completely blocking of each other... and that some clarification might help facilitate covering both sets of needs. It's mainly patch 4 of libweston v2 that conflicts with this patch. Bill's review makes a good point that moving the backend init code into weston.c makes the backend code less well organized. I tend to agree with him, and think keeping the backend code compartmentalized will be more beneficial to us in the long run. The backend init code sets up the command line options, and it makes sense to move the backend-specific option help text to live in the backend next to the setup code, as this patch proposes. Bryce The problems seem very similar to plugin architecture issues I've worked on in the past, so after some review it should not be too hard to put forth some technical details on different ways to reconcile these needs. There are also a few different approaches to parameter handling that could be leveraged. At least I won't have to code support for Unicode params on Win95 again :-) On 06/23/2015 12:22 PM, Giulio Camuffo wrote: 2015-06-23 21:57 GMT+03:00 JoonCheol Park joonch...@gmail.com: 2015-06-24 2:49 GMT+09:00 Giulio Camuffo giuliocamu...@gmail.com: 2015-06-23 20:40 GMT+03:00 JoonCheol Park joonch...@gmail.com: Hi Giulio, pq! 2015-06-23 20:57 GMT+09:00 Pekka Paalanen ppaala...@gmail.com: On Tue, 23 Jun 2015 14:14:53 +0300 Giulio Camuffo giuliocamu...@gmail.com wrote: Hi, This kinda goes in the opposite direction to my libweston patches. In that series i move the command line handling away from the backends code to make them work in multiple compositors. This moves even more compositor-specific stuff in the backends so we need to decide if we want this or libweston. We want libweston. I just quick review the libweston on the github (https://github.com/giucam/weston/). When it will be applied to mainstream ? My understanding about libweston is for reuse the x11/drm related code for other compositor project (like libinput). Yes, It is everyone want :-) But, since the backend structure which manages multiple plugins and load symbol 'backend_xxx()' is weston compositor specific stuff and it is not in the scope of libweston, I believe my proposal is not the opposite idea to the libweston what you are preparing. (In your repository, my proposal may change the src/weston.c to remove hardcoded backend option outputs. It is not part of libweston library. ) Which branch should I see on your repository? libweston ? libweston-v2 ? I found that you mentioned structure in branch libweston-v2. (right ?) libweston-v2 was slighly old, i updated it now. Well, but you are adding weston specific stuff into the backends code, that is the options handling. backend plugin (and option handling) is the *weston* compositor specific. so this is not the problem I think. The backends are not weston specific, that is one of the point of libweston, to share them. Only the initialization is compositor specific. In libweston the backends do not parse the command line or the config file, so all the backend options are weston specific. In your code (src/weston.c, branch libweston-v2), as you explained, the weston (compositor main) have the code for parse options for all known backend plugin before init it. But, there are many hard code option outputs for only known backend plugins. In this case, we don't have to load plugin file dynamically. And it use the weston_compositor_init_backend of the libweston.so which has hard coded backend list. I think this function should not be included in the libweston.so if its goal is to be reused for other compositor. Since the weston_compositor_init_backend is for weston specific backend plugin initialization, it is not necessary function for others. actually the version i sent to the list doesn't have the backends enum, they are loaded like now by using the filename of the .so or the absolute path. and as i said above the backends are meant to be shared between compositor. 2015-06-23 13:29 GMT+03:00 JoonCheol Park joonch...@gmail.com: Instead of adding available backends and
Re: [PATCH libinput 2/5] Add configuration interface for tap drag-lock
On Tue, Jun 23, 2015 at 4:17 PM, Peter Hutterer peter.hutte...@who-t.net wrote: Perhaps you are already doing this, but can't you require the mouse to be held down and/or moved more than some threshold on the first drag to turn on drag-lock mode? interesting idea, but I don't think it'll work. too much guesswork, too easy to get wrong. for example, when I know I need to cover a large distance while dragging, a quick 3-4cm repeated drag is faster than a couple of large moves. I was thinking the threshold would be much smaller than 3-4 cm, more like 1 cm. However I don't actually have a trackpad that works this way so I really am not one to guess what would work. Have you seen similar behaviour on Windows or Mac and can you experiment to see what they did? I would not be suprised if they break Inkscape in the same way, however. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH libinput 2/5] Add configuration interface for tap drag-lock
On Tue, Jun 23, 2015 at 05:59:54PM -0700, Bill Spitzak wrote: On Tue, Jun 23, 2015 at 4:17 PM, Peter Hutterer peter.hutte...@who-t.net wrote: Perhaps you are already doing this, but can't you require the mouse to be held down and/or moved more than some threshold on the first drag to turn on drag-lock mode? interesting idea, but I don't think it'll work. too much guesswork, too easy to get wrong. for example, when I know I need to cover a large distance while dragging, a quick 3-4cm repeated drag is faster than a couple of large moves. I was thinking the threshold would be much smaller than 3-4 cm, more like 1 cm. However I don't actually have a trackpad that works this way so I really am not one to guess what would work. Have you seen similar behaviour on Windows or Mac and can you experiment to see what they did? I would not be suprised if they break Inkscape in the same way, however. OS X has a toggle for this, hidden in the accessibility section (not the normal touchpad settings panel). Windows calls it ClickLock apparently and too has a setting (though it's a bit different, it also applies to physical buttons) Cheers, Peter ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston 04/11] make the backends compositor-neutral
Just a few minor low-level items in this feedback... On 06/22/2015 01:02 PM, Giulio Camuffo wrote: The backends used to have lots of code dealing with weston specific configs. To allow them to be used by other compositors with their own configurations remove all the usage of weston_config from the backends code and move it in weston.c. The backends are now initialized with the new weston_compositor_init_backend() function which takes a pointer to a weston_backend_config struct. Each backend now installs one header where a subclass of weston_backend_config is defined, and the compositor creates an instance of the backend-specific config struct and passes it to weston_compositor_init_backend(). This means that the compositor now needs to know about all the backends to be able to instantiate them, but no backend specific API such as xcb or libdrm leaks through, so there are no new dependencies for the compositor. A backend may now set a vfunc pointer to create a new compositor. Not all do though, and use instead a callback function to configure a new output that comes from below the compositor, instead of above it. --- Makefile.am | 21 ++ src/compositor-drm.c | 163 + src/compositor-drm.h | 77 ++ src/compositor-fbdev.c| 66 ++--- src/compositor-fbdev.h| 58 + src/compositor-headless.c | 81 +++ src/compositor-headless.h | 47 src/compositor-rdp.c | 57 + src/compositor-rdp.h | 54 + src/compositor-rpi.c | 50 ++-- src/compositor-rpi.h | 51 src/compositor-wayland.c | 222 - src/compositor-wayland.h | 58 + src/compositor-x11.c | 166 - src/compositor-x11.h | 55 + src/compositor.c | 40 +++- src/compositor.h | 20 +- src/weston.c | 599 -- 18 files changed, 1283 insertions(+), 602 deletions(-) create mode 100644 src/compositor-drm.h create mode 100644 src/compositor-fbdev.h create mode 100644 src/compositor-headless.h create mode 100644 src/compositor-rdp.h create mode 100644 src/compositor-rpi.h create mode 100644 src/compositor-wayland.h create mode 100644 src/compositor-x11.h diff --git a/Makefile.am b/Makefile.am index fa90853..29430e3 100644 --- a/Makefile.am +++ b/Makefile.am @@ -72,6 +72,13 @@ weston_SOURCES = \ src/log.c \ src/compositor.c\ src/compositor.h\ + src/compositor-x11.h\ + src/compositor-wayland.h\ + src/compositor-drm.h\ + src/compositor-headless.h \ + src/compositor-fbdev.h \ + src/compositor-rdp.h\ + src/compositor-rpi.h\ src/input.c \ src/data-device.c \ src/screenshooter.c \ @@ -188,6 +195,13 @@ westonincludedir = $(includedir)/weston westoninclude_HEADERS = \ src/version.h \ src/compositor.h\ + src/compositor-x11.h\ + src/compositor-wayland.h\ + src/compositor-drm.h\ + src/compositor-headless.h \ + src/compositor-fbdev.h \ + src/compositor-rdp.h\ + src/compositor-rpi.h\ src/timeline-object.h \ shared/matrix.h \ shared/config-parser.h \ @@ -224,6 +238,7 @@ x11_backend_la_CFLAGS = \ $(GCC_CFLAGS) x11_backend_la_SOURCES = \ src/compositor-x11.c\ + src/compositor-x11.h\ shared/helpers.h endif @@ -251,6 +266,7 @@ drm_backend_la_CFLAGS = \ $(GCC_CFLAGS) drm_backend_la_SOURCES = \ src/compositor-drm.c\ + src/compositor-drm.h\ $(INPUT_BACKEND_SOURCES)\ shared/helpers.h\ src/libbacklight.c \ @@ -279,6 +295,7 @@ wayland_backend_la_CFLAGS = \ $(GCC_CFLAGS) wayland_backend_la_SOURCES = \ src/compositor-wayland.c\ + src/compositor-wayland.h\ shared/helpers.h nodist_wayland_backend_la_SOURCES = \ protocol/fullscreen-shell-protocol.c\ @@ -306,6
Re: [PATCH weston 02/11] compositor: add API to manage compositor instances
Oh I forgot an item on the placement of comments.
On 06/23/2015 04:31 PM, Jon A. Cruz wrote:
Minor doxygen note: the explicit \brief is not needed, and the brief
description should end with a '.' to allow the auto-brief to pick it up.
Overall looks good, but missing a few extra management calls. However
those seem applicable to patch 4/11.
On 06/22/2015 01:02 PM, Giulio Camuffo wrote:
This commit adds three new exported functions:
- weston_compositor_create() returns a new weston_compositor instance,
initializing it as the now removed weston_compositor_init() did.
- weston_compositor_exit(compositor) asks the compositor to tear
down by calling the compositor's exit vfunc which is set by the
libweston application.
- weston_compositor_destroy(compositor) is called by the libweston
application when tearing down the compositor. The compositor is destroyed
and the memory freed.
---
Reviewed-by: Jon A. Cruz j...@osg.samsung.com
src/compositor-drm.c | 8 +--
src/compositor-fbdev.c| 6 --
src/compositor-headless.c | 9 +--
src/compositor-rdp.c | 4 --
src/compositor-wayland.c | 9 +--
src/compositor-x11.c | 5 +-
src/compositor.c | 167
+-
src/compositor.h | 14 +++-
8 files changed, 137 insertions(+), 85 deletions(-)
diff --git a/src/compositor-drm.c b/src/compositor-drm.c
index 6d24f05..4302f40 100644
--- a/src/compositor-drm.c
+++ b/src/compositor-drm.c
@@ -2424,7 +2424,7 @@ update_outputs(struct drm_backend *b, struct
udev_device *drm_device)
/* FIXME: handle zero outputs, without terminating */
if (b-connector_allocator == 0)
-wl_display_terminate(b-compositor-wl_display);
+weston_compositor_exit(b-compositor);
}
static int
@@ -2845,12 +2845,6 @@ drm_backend_create(struct weston_compositor
*compositor,
b-use_pixman = param-use_pixman;
-if (weston_compositor_init(compositor, argc, argv,
- config) 0) {
-weston_log(%s failed\n, __func__);
-goto err_base;
-}
-
/* Check if we run drm-backend using weston-launch */
compositor-launcher = weston_launcher_connect(compositor, param-tty,
param-seat_id, true);
diff --git a/src/compositor-fbdev.c b/src/compositor-fbdev.c
index 6a640ee..7117bc5 100644
--- a/src/compositor-fbdev.c
+++ b/src/compositor-fbdev.c
@@ -826,10 +826,6 @@ fbdev_backend_create(struct weston_compositor
*compositor, int *argc, char *argv
return NULL;
backend-compositor = compositor;
-if (weston_compositor_init(compositor, argc, argv,
- config) 0)
-goto out_free;
-
if (weston_compositor_set_presentation_clock_software(
compositor) 0)
goto out_compositor;
@@ -902,8 +898,6 @@ out_udev:
out_compositor:
weston_compositor_shutdown(compositor);
-
-out_free:
free(backend);
return NULL;
diff --git a/src/compositor-headless.c b/src/compositor-headless.c
index 8e40152..b1be3a0 100644
--- a/src/compositor-headless.c
+++ b/src/compositor-headless.c
@@ -218,8 +218,7 @@ headless_destroy(struct weston_compositor *ec)
static struct headless_backend *
headless_backend_create(struct weston_compositor *compositor,
struct headless_parameters *param,
-const char *display_name, int *argc, char *argv[],
-struct weston_config *config)
+const char *display_name)
{
struct headless_backend *b;
@@ -228,9 +227,6 @@ headless_backend_create(struct weston_compositor
*compositor,
return NULL;
b-compositor = compositor;
-if (weston_compositor_init(compositor, argc, argv, config) 0)
-goto err_free;
-
if (weston_compositor_set_presentation_clock_software(compositor) 0)
goto err_free;
@@ -287,8 +283,7 @@ backend_init(struct weston_compositor *compositor,
if (weston_parse_transform(transform, param.transform) 0)
weston_log(Invalid transform \%s\\n, transform);
-b = headless_backend_create(compositor, param, display_name,
-argc, argv, config);
+b = headless_backend_create(compositor, param, display_name);
if (b == NULL)
return -1;
return 0;
diff --git a/src/compositor-rdp.c b/src/compositor-rdp.c
index 96d4b5f..86c5b2a 100644
--- a/src/compositor-rdp.c
+++ b/src/compositor-rdp.c
@@ -1172,9 +1172,6 @@ rdp_backend_create(struct weston_compositor
*compositor,
return NULL;
b-compositor = compositor;
-if (weston_compositor_init(compositor, argc, argv, wconfig) 0)
-goto err_free;
-
b-base.destroy =
Re: [PATCH libinput 2/5] Add configuration interface for tap drag-lock
On Tue, Jun 23, 2015 at 12:14:21PM -0700, Bill Spitzak wrote: On Sun, Jun 21, 2015 at 9:54 PM, Peter Hutterer peter.hutte...@who-t.net wrote: In some applications, notably Inkscape, where it is common to frequently drag objects a short distance the default to drag-lock always-on is frustrating for users. Make it configurable, with the current default to on. New API: libinput_device_config_tap_set_drag_lock_enabled libinput_device_config_tap_get_drag_lock_enabled libinput_device_config_tap_get_default_drag_lock_enabled Any device capable of tapping is capable of drag lock, there is no explicit availability check for drag lock. Configuration is independent, drag lock may be enabled when tapping is disabled. Perhaps you are already doing this, but can't you require the mouse to be held down and/or moved more than some threshold on the first drag to turn on drag-lock mode? interesting idea, but I don't think it'll work. too much guesswork, too easy to get wrong. for example, when I know I need to cover a large distance while dragging, a quick 3-4cm repeated drag is faster than a couple of large moves. I would think also that it would help to only turn it on if the finger is released near the edge of the touchpad, and not in the middle. see above. Cheers, Peter ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH v2] xwayland: keep temp files out of the client mask
On 23.06.2015 23:28, Olivier Fourdan wrote: From: Chris Wilson ch...@chris-wilson.co.uk Xwayland opens anonymous files for its sharing buffers, move these file descriptors out of the of irange of the the client select mask Spelling: out of the range of the client select mask? to avoid reaching the maximum number of clients prematurely. https://bugs.freedesktop.org/show_bug.cgi?id=91072 Reported-and-tested-by: Olivier Fourdan four...@gmail.com Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk With the above fixed, Reviewed-by: Michel Dänzer michel.daen...@amd.com -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston] compositor: Separate hardcoded backend related code from compositor
On Tue, Jun 23, 2015 at 07:29:17PM +0900, JoonCheol Park wrote:
Instead of adding available backends and usage outputs at build time,
this patch finds all available backend plugins in MODULEDIR and prints
them. It also prints usage output for selected backend by calling
backend_usage() in the plugin.
By this patch, we can remove all hardcode for backends from compositor.
3rd party backend plugin can be listed in help output. Backend developer
can freely add additional description for backend.
Signed-off-by: JoonCheol Park joonch...@gmail.com
---
src/compositor-drm.c | 11
src/compositor-fbdev.c| 9 +++
src/compositor-headless.c | 11
src/compositor-rdp.c | 15 +
src/compositor-rpi.c | 12
src/compositor-wayland.c | 14 +
src/compositor-x11.c | 13 +
src/compositor.c | 141
--
src/compositor.h | 3 +
9 files changed, 125 insertions(+), 104 deletions(-)
diff --git a/src/compositor-drm.c b/src/compositor-drm.c
index 6d8684d..0714f34 100644
--- a/src/compositor-drm.c
+++ b/src/compositor-drm.c
@@ -3002,3 +3002,14 @@ backend_init(struct wl_display *display, int *argc,
char *argv[],
return drm_compositor_create(display, param, argc, argv, config);
}
+
+WL_EXPORT const char *
+backend_usage(void)
+{
+ return Options for fbdev-backend.so:\n\n
+ --connector=ID\tBring up only this connector\n
+ --seat=SEAT\t\tThe seat that weston should run on\n
+ --tty=TTY\t\tThe tty to use\n
+ --use-pixman\t\tUse the pixman (CPU) renderer\n
+ --current-mode\tPrefer current KMS mode over EDID preferred mode;
+}
I think that moving the help text into the relevant backend is a step in
the right direction. Thanks for posting this.
I'm not sure that this routine is the right abstraction though.
Notice that in the backend_init code for compositor-drm.c there already
exists a structure for the supported options:
const struct weston_option drm_options[] = {
{ WESTON_OPTION_INTEGER, connector, 0, param.connector },
{ WESTON_OPTION_STRING, seat, 0, param.seat_id },
{ WESTON_OPTION_INTEGER, tty, 0, param.tty },
{ WESTON_OPTION_BOOLEAN, current-mode, 0,
option_current_mode },
{ WESTON_OPTION_BOOLEAN, use-pixman, 0, param.use_pixman },
};
One thought is to add a member to this structure for holding help text.
Then, move this structure from being internal to backend_init(), to
being an exported object, that can be used in main.c to generate the
usage text formatted as main() wishes.
This would decouple the presentation of the options from the definition
of them, as well as reduce the number of places one needs to tinker with
when adding a new option.
But I'll add this is just one possible approach. I chatted with Jon
Cruz about this very thing the other day and it sounded like he had some
further ideas.
Bryce
diff --git a/src/compositor-fbdev.c b/src/compositor-fbdev.c
index a6fd823..c4d6166 100644
--- a/src/compositor-fbdev.c
+++ b/src/compositor-fbdev.c
@@ -928,3 +928,12 @@ backend_init(struct wl_display *display, int *argc, char
*argv[],
return fbdev_compositor_create(display, argc, argv, config, param);
}
+
+WL_EXPORT const char *
+backend_usage(void)
+{
+ return Options for fbdev-backend.so:\n\n
+ --tty=TTY\t\tThe tty to use\n
+ --device=DEVICE\tThe framebuffer device to use\n
+ --use-gl\t\tUse the GL renderer;
+}
diff --git a/src/compositor-headless.c b/src/compositor-headless.c
index c0e35ce..d1d1b75 100644
--- a/src/compositor-headless.c
+++ b/src/compositor-headless.c
@@ -287,3 +287,14 @@ backend_init(struct wl_display *display, int *argc, char
*argv[],
return headless_compositor_create(display, param, display_name,
argc, argv, config);
}
+
+WL_EXPORT const char *
+backend_usage(void)
+{
+ return Options for headless-backend.so:\n\n
+ --width=WIDTH\t\tWidth of memory surface\n
+ --height=HEIGHT\tHeight of memory surface\n
+ --transform=TR\tThe output transformation, TR is one of:\n
+ \tnormal 90 180 270 flipped flipped-90 flipped-180 flipped-270\n
+ --use-pixman\t\tUse the pixman (CPU) renderer (default: no
rendering);
+}
diff --git a/src/compositor-rdp.c b/src/compositor-rdp.c
index 6d4d1e4..750aa67 100644
--- a/src/compositor-rdp.c
+++ b/src/compositor-rdp.c
@@ -1275,3 +1275,18 @@ backend_init(struct wl_display *display, int *argc,
char *argv[],
return rdp_compositor_create(display, config, argc, argv, wconfig);
}
+
+WL_EXPORT const char *
+backend_usage(void)
+{
+ return Options for rdp-backend.so:\n\n
+ --width=WIDTH\t\tWidth of desktop\n
+ --height=HEIGHT\tHeight of desktop\n
+
Re: [PATCH weston 03/11] compositor: move the main() to a new weston.c file
On Mon, Jun 22, 2015 at 11:02:50PM +0300, Giulio Camuffo wrote:
This commits starts to separate the libweston code from the weston
specific code. As such, the main() is moved, together with signals
handling and configuration handling.
---
Makefile.am | 1 +
src/compositor.c | 801 +---
src/weston.c | 843
+++
Just to avoid any ambiguity, perhaps name this new file main.c?
Apart from that, this seems like a straightforward refactoring. I see
no reason why it couldn't be landed now, independently of the rest of
the libweston set.
3 files changed, 845 insertions(+), 800 deletions(-)
create mode 100644 src/weston.c
diff --git a/Makefile.am b/Makefile.am
index 6b2d6c7..fa90853 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -86,6 +86,7 @@ weston_SOURCES =\
src/timeline.c \
src/timeline.h \
src/timeline-object.h \
+ src/weston.c\
shared/helpers.h\
shared/matrix.c \
shared/matrix.h \
diff --git a/src/compositor.c b/src/compositor.c
index 1924e6a..6e111f1 100644
--- a/src/compositor.c
+++ b/src/compositor.c
@@ -51,11 +51,6 @@
#include time.h
#include errno.h
-#ifdef HAVE_LIBUNWIND
-#define UNW_LOCAL_ONLY
-#include libunwind.h
-#endif
-
#include timeline.h
#include compositor.h
@@ -88,37 +83,6 @@ timespec_to_nsec(const struct timespec *a)
return (int64_t)a-tv_sec * NSEC_PER_SEC + a-tv_nsec;
}
-static struct wl_list child_process_list;
-static struct weston_compositor *segv_compositor;
-
-static int
-sigchld_handler(int signal_number, void *data)
-{
- struct weston_process *p;
- int status;
- pid_t pid;
-
- while ((pid = waitpid(-1, status, WNOHANG)) 0) {
- wl_list_for_each(p, child_process_list, link) {
- if (p-pid == pid)
- break;
- }
-
- if (p-link == child_process_list) {
- weston_log(unknown child process exited\n);
- continue;
- }
-
- wl_list_remove(p-link);
- p-cleanup(p, status);
- }
-
- if (pid 0 errno != ECHILD)
- weston_log(waitpid error %m\n);
-
- return 1;
-}
-
static void
weston_output_transform_scale_init(struct weston_output *output,
uint32_t transform, uint32_t scale);
@@ -290,12 +254,6 @@ weston_output_mode_switch_to_temporary(struct
weston_output *output,
return 0;
}
-WL_EXPORT void
-weston_watch_process(struct weston_process *process)
-{
- wl_list_insert(child_process_list, process-link);
-}
-
static void
child_client_exec(int sockfd, const char *path)
{
@@ -4454,17 +4412,6 @@ compositor_bind(struct wl_client *client,
compositor, NULL);
}
-static void
-log_uname(void)
-{
- struct utsname usys;
-
- uname(usys);
-
- weston_log(OS: %s, %s, %s, %s\n, usys.sysname, usys.release,
- usys.version, usys.machine);
-}
-
WL_EXPORT int
weston_environment_get_fd(const char *env)
{
@@ -4539,6 +4486,7 @@ weston_compositor_create(struct wl_display *display,
void *user_data)
ec-session_active = 1;
ec-output_id_pool = 0;
+ ec-repaint_msec = DEFAULT_REPAINT_WINDOW;
Is this an unrelated change? If so maybe move to its own patch?
if (!wl_global_create(ec-wl_display, wl_compositor_interface, 3,
ec, compositor_bind))
@@ -4596,47 +4544,6 @@ fail:
return NULL;
}
-static int
-weston_compositor_init_config(struct weston_compositor *ec,
- struct weston_config *config)
-{
- struct xkb_rule_names xkb_names;
- struct weston_config_section *s;
-
- s = weston_config_get_section(config, keyboard, NULL, NULL);
- weston_config_section_get_string(s, keymap_rules,
- (char **) xkb_names.rules, NULL);
- weston_config_section_get_string(s, keymap_model,
- (char **) xkb_names.model, NULL);
- weston_config_section_get_string(s, keymap_layout,
- (char **) xkb_names.layout, NULL);
- weston_config_section_get_string(s, keymap_variant,
- (char **) xkb_names.variant, NULL);
- weston_config_section_get_string(s, keymap_options,
- (char **) xkb_names.options, NULL);
-
- if (weston_compositor_xkb_init(ec, xkb_names) 0)
-
Re: [PATCH weston 02/11] compositor: add API to manage compositor instances
Minor doxygen note: the explicit \brief is not needed, and the brief
description should end with a '.' to allow the auto-brief to pick it up.
Overall looks good, but missing a few extra management calls. However
those seem applicable to patch 4/11.
On 06/22/2015 01:02 PM, Giulio Camuffo wrote:
This commit adds three new exported functions:
- weston_compositor_create() returns a new weston_compositor instance,
initializing it as the now removed weston_compositor_init() did.
- weston_compositor_exit(compositor) asks the compositor to tear
down by calling the compositor's exit vfunc which is set by the
libweston application.
- weston_compositor_destroy(compositor) is called by the libweston
application when tearing down the compositor. The compositor is destroyed
and the memory freed.
---
Reviewed-by: Jon A. Cruz j...@osg.samsung.com
src/compositor-drm.c | 8 +--
src/compositor-fbdev.c| 6 --
src/compositor-headless.c | 9 +--
src/compositor-rdp.c | 4 --
src/compositor-wayland.c | 9 +--
src/compositor-x11.c | 5 +-
src/compositor.c | 167
+-
src/compositor.h | 14 +++-
8 files changed, 137 insertions(+), 85 deletions(-)
diff --git a/src/compositor-drm.c b/src/compositor-drm.c
index 6d24f05..4302f40 100644
--- a/src/compositor-drm.c
+++ b/src/compositor-drm.c
@@ -2424,7 +2424,7 @@ update_outputs(struct drm_backend *b, struct
udev_device *drm_device)
/* FIXME: handle zero outputs, without terminating */
if (b-connector_allocator == 0)
- wl_display_terminate(b-compositor-wl_display);
+ weston_compositor_exit(b-compositor);
}
static int
@@ -2845,12 +2845,6 @@ drm_backend_create(struct weston_compositor
*compositor,
b-use_pixman = param-use_pixman;
- if (weston_compositor_init(compositor, argc, argv,
-config) 0) {
- weston_log(%s failed\n, __func__);
- goto err_base;
- }
-
/* Check if we run drm-backend using weston-launch */
compositor-launcher = weston_launcher_connect(compositor, param-tty,
param-seat_id, true);
diff --git a/src/compositor-fbdev.c b/src/compositor-fbdev.c
index 6a640ee..7117bc5 100644
--- a/src/compositor-fbdev.c
+++ b/src/compositor-fbdev.c
@@ -826,10 +826,6 @@ fbdev_backend_create(struct weston_compositor
*compositor, int *argc, char *argv
return NULL;
backend-compositor = compositor;
- if (weston_compositor_init(compositor, argc, argv,
-config) 0)
- goto out_free;
-
if (weston_compositor_set_presentation_clock_software(
compositor) 0)
goto out_compositor;
@@ -902,8 +898,6 @@ out_udev:
out_compositor:
weston_compositor_shutdown(compositor);
-
-out_free:
free(backend);
return NULL;
diff --git a/src/compositor-headless.c b/src/compositor-headless.c
index 8e40152..b1be3a0 100644
--- a/src/compositor-headless.c
+++ b/src/compositor-headless.c
@@ -218,8 +218,7 @@ headless_destroy(struct weston_compositor *ec)
static struct headless_backend *
headless_backend_create(struct weston_compositor *compositor,
struct headless_parameters *param,
- const char *display_name, int *argc, char *argv[],
- struct weston_config *config)
+ const char *display_name)
{
struct headless_backend *b;
@@ -228,9 +227,6 @@ headless_backend_create(struct weston_compositor
*compositor,
return NULL;
b-compositor = compositor;
- if (weston_compositor_init(compositor, argc, argv, config) 0)
- goto err_free;
-
if (weston_compositor_set_presentation_clock_software(compositor) 0)
goto err_free;
@@ -287,8 +283,7 @@ backend_init(struct weston_compositor *compositor,
if (weston_parse_transform(transform, param.transform) 0)
weston_log(Invalid transform \%s\\n, transform);
- b = headless_backend_create(compositor, param, display_name,
- argc, argv, config);
+ b = headless_backend_create(compositor, param, display_name);
if (b == NULL)
return -1;
return 0;
diff --git a/src/compositor-rdp.c b/src/compositor-rdp.c
index 96d4b5f..86c5b2a 100644
--- a/src/compositor-rdp.c
+++ b/src/compositor-rdp.c
@@ -1172,9 +1172,6 @@ rdp_backend_create(struct weston_compositor *compositor,
return NULL;
b-compositor = compositor;
- if (weston_compositor_init(compositor, argc, argv, wconfig) 0)
- goto err_free;
-
b-base.destroy = rdp_destroy;
b-base.restore = rdp_restore;
b-rdp_key =
