Re: [PATCH weston] compositor: Separate hardcoded backend related code from compositor
Thanks pq and all, I didn't think this would be hot topic :-) All reply from all in this thread was very very helpful to understand current weston project for me. 2015-06-24 16:52 GMT+09:00 Pekka Paalanen : > Hi all > > TL;DR: > > Everything is open, let's make small steps only, in priority order > determined by the intended audience. We have as many release cycles of > time to use for improving the code and interfaces as we want. > > > On Wed, 24 Jun 2015 02:40:08 +0900 > JoonCheol Park wrote: > > > Hi Giulio, pq! > > > > > > 2015-06-23 20:57 GMT+09:00 Pekka Paalanen : > > > > > On Tue, 23 Jun 2015 14:14:53 +0300 > > > Giulio Camuffo 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 ? > > We're aiming for the 1.9 release, but as I want to repeat, this > work will not be complete for a long long time. See below. > > > 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. ) > > The scope of libweston is very unclear at the moment, anyway. We > are taking small steps to making it usable by others, which will take > many release cycles. There is time to fix the details. > > Your work is much in the right direction. Until now, we have not really > cared about the details of config handling etc. so yes, it's a mess at > the moment, to be cleaned up. I'd like to see cooperation with the > libweston effort. > Thanks One idea we would like to see is that configuration is passed into > libweston in some "generic" form, so that a main program can use > whatever to load it (ini, xml, gnome-settings, registry, LDAP, generate > it on the fly, ...). So far, different backends use different sets of > options, so we have to have that somehow. How exactly is not important > right now. > > > > 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. > > It is an open question whether external backends should be supported by > libweston at all. Weston today does not support them, and that's what > we start with. Future may hold different. > > It is also an open question of how much the user of libweston should > care about the particular backends. One major difference between the > various backends is that some run on "bare" hardware (drm, fbdev, rpi) > and some are running under another display system (x11, wayland, rdp?). > I suspect the user of libweston has to care about at least that much. > > > 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?? > > For instance, gl-renderer.h was never exported (installed with Weston), > neither any of the input or launching support headers. I'm a little bit > surprised you got away with it, it certainly was not meant to work. > > Perhaps the headless backend is too simple to show those deficiencies. > It seems so. Anyway, The headless backend was good enough to start do something as skeleton, And it was quite nice to understand the backend plugin :-) > Also, Weston currently has no notion between what is API meant for > backend
Re: [PATCH weston] compositor: Separate hardcoded backend related code from compositor
2015-06-24 2:49 GMT+09:00 Giulio Camuffo : > 2015-06-23 20:40 GMT+03:00 JoonCheol Park : > > Hi Giulio, pq! > > > > > > 2015-06-23 20:57 GMT+09:00 Pekka Paalanen : > >> > >> On Tue, 23 Jun 2015 14:14:53 +0300 > >> Giulio Camuffo 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 : > >> > > 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 > >> > > --- > >> > > 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 >
Re: [PATCH weston] compositor: Separate hardcoded backend related code from compositor
Hi Giulio, pq! 2015-06-23 20:57 GMT+09:00 Pekka Paalanen : > On Tue, 23 Jun 2015 14:14:53 +0300 > Giulio Camuffo 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 : > > > 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 > > > --- > > > 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
[PATCH weston] compositor: Separate hardcoded backend related code from compositor
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
---
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, ¶m, 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, ¶m);
}
+
+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, ¶m, 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, ¶m);
}
+
+WL_EXPORT const char *
+backend_usage(void)
+{
+ return "Options for rpi-backend.so:\n\n"
+ " --tty=TTY\t\tThe tty to use\n"
+ " --single-buffer\tUse single-buffered Dispmanx elements.\n"
+ " --transform=TR\tThe output transformation, TR is one of:\n"
+ &q
[PATCH weston] compositor: add missing help text
The headless-backend.so was missing in available backend list Signed-off-by: JoonCheol Park --- src/compositor.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/compositor.c b/src/compositor.c index 38c0775..0d4acda 100644 --- a/src/compositor.c +++ b/src/compositor.c @@ -5039,6 +5039,9 @@ usage(int error_code) #if defined(BUILD_RDP_COMPOSITOR) "\t\t\t\trdp-backend.so\n" #endif +#if defined(BUILD_HEADLESS_COMPOSITOR) + "\t\t\t\theadless-backend.so\n" +#endif #if defined(BUILD_RPI_COMPOSITOR) && defined(HAVE_BCM_HOST) "\t\t\t\trpi-backend.so\n" #endif -- 1.9.1 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH libinput] test: add missing libunwind cflags to test-litest-selftest
Signed-off-by: JoonCheol Park --- test/Makefile.am | 4 1 file changed, 4 insertions(+) diff --git a/test/Makefile.am b/test/Makefile.am index fc05ff6..6f2e6e4 100644 --- a/test/Makefile.am +++ b/test/Makefile.am @@ -113,6 +113,10 @@ test_litest_selftest_SOURCES = litest-selftest.c litest.c litest-int.h litest.h test_litest_selftest_CFLAGS = -DLITEST_DISABLE_BACKTRACE_LOGGING -DLITEST_NO_MAIN test_litest_selftest_LDADD = $(TEST_LIBS) test_litest_selftest_LDFLAGS = -no-install +if HAVE_LIBUNWIND +test_litest_selftest_LDADD += $(LIBUNWIND_LIBS) -ldl +test_litest_selftest_CFLAGS += $(LIBUNWIND_CFLAGS) +endif # build-test only test_build_pedantic_c99_SOURCES = build-pedantic.c -- 1.9.1 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
