Re: [PATCH weston v2 2/2] compositor-drm: Watchdog timer implementation
Just a couple typos spotted On Thu, Oct 30, 2014 at 01:19:15PM -0400, Frederic Plourde wrote: > > @@ -617,20 +694,24 @@ drm_output_repaint(struct weston_output *output_base, >output->next->fb_id, 0, 0, >&output->connector_id, 1, >&mode->mode_info); > if (ret) { > weston_log("set mode failed: %m\n"); > goto err_pageflip; > } > output_base->set_dpms(output_base, WESTON_DPMS_ON); > } > > + /* Start out watchdog timer */ our > + if (output->wdt.timer) > + drm_output_watchdog_timer_start(&output->wdt); > + > if (drmModePageFlip(compositor->drm.fd, output->crtc_id, > output->next->fb_id, > DRM_MODE_PAGE_FLIP_EVENT, output) < 0) { > @@ -704,20 +785,24 @@ drm_output_start_repaint_loop(struct weston_output > *output_base) > fb_id = output->current->fb_id; > > + /* Start out watchdog timer */ our > + if (output->wdt.timer) > + drm_output_watchdog_timer_start(&output->wdt); > + > if (drmModePageFlip(compositor->drm.fd, output->crtc_id, fb_id, > DRM_MODE_PAGE_FLIP_EVENT, output) < 0) { ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH libinput 0/4] some acceleration fixes, mostly for high DPI mice
On Thu, Oct 30, 2014 at 04:34:12PM -0500, Derek Foreman wrote: > The acceleration filter currently isn't particularly pleased with gaming mice. > > They generally have high DPI (can be over 8000 DPI) and can have high update > rates (1000+ per second). This can result in the accel curve being biased > heavily towards the high points on the accel curve. > > This patch set allows a way to normalize the deltas to 400DPI so when the > DPI setting of the mouse is correct, it should feel much the same as a > normal mouse. > > This is, of course, only a partial solution. Setting a reasonable default > is a massive problem that needs to be addressed in the future - for now > we just set it to 400 (which may actually not be that prevalent any more > but there doesn't seem to be such thing as a "standard" DPI mouse). Thanks, I've pushed 1 to 3 (with added comments), not quite happy with 4 yet. As a configuration interface, it's mismatched with the usual quartett of hooks that we provide for all other config options. But I think providing a visible API may not be the right approach here anyway. One idea I had here was to have this provided through udev, set as something like: LIBINPUT_MOUSE_DPI="400@80" # dpi @ poll rate over time, the udev hwdb could add those settings, or we ship them as extra rules, or users configure them themselves. this is unfortunately a rather nasty task given the amount of HW out there, but I really can't think of any other way (short of heuristics which will fail in too many ways). Any ideas on feasability or better approaches welcome. Cheers, Peter ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Python Project
在 2014年10月30日 星期四 21:36:15,martins scun 写道: > Hi everybody! I have a project for developing a Python based OS. Just for > fun.It will use the Linux kernel and a python runtime to execute core > modules and apps. Currently, I'm working on porting Wayland to python. If > anybody's interested, I appreciate any help, specially from experienced > devs. Thanks well, linux kernel is not python based. so, please write your own kernel with python! ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH libinput v2] evdev: Log evdev event queue overflows
On 30/10/14 07:14 PM, Peter Hutterer wrote: > On Wed, Oct 29, 2014 at 09:56:27AM -0500, Derek Foreman wrote: >> Log a message when the kernel event queue overflows and events are dropped. >> After 10 messages logging stops to avoid flooding the logs if the condition >> is persistent. > > merged locally, thanks. but please sign off your patches to libinput. Can I > assume your s-o-b for this patch? Yes, sorry, will do that from now on. > Cheers, >Peter > >> --- >> src/evdev.c | 11 +++ >> src/evdev.h | 4 >> 2 files changed, 15 insertions(+) >> >> diff --git a/src/evdev.c b/src/evdev.c >> index 1b4ce10..9026f5c 100644 >> --- a/src/evdev.c >> +++ b/src/evdev.c >> @@ -924,6 +924,17 @@ evdev_device_dispatch(void *data) >> rc = libevdev_next_event(device->evdev, >> LIBEVDEV_READ_FLAG_NORMAL, &ev); >> if (rc == LIBEVDEV_READ_STATUS_SYNC) { >> +if (device->syn_drops_received < 10) { >> +device->syn_drops_received++; >> +log_info(libinput, "SYN_DROPPED event from " >> + "\"%s\" - some input events have " >> + "been lost.\n", device->devname); >> +if (device->syn_drops_received == 10) >> +log_info(libinput, "No longer logging " >> + "SYN_DROPPED events for " >> + "\"%s\"\n", device->devname); >> +} >> + >> /* send one more sync event so we handle all >> currently pending events before we sync up >> to the current state */ >> diff --git a/src/evdev.h b/src/evdev.h >> index c0d6577..9e84623 100644 >> --- a/src/evdev.h >> +++ b/src/evdev.h >> @@ -135,6 +135,10 @@ struct evdev_device { >> /* Checks if buttons are down and commits the setting */ >> void (*change_to_left_handed)(struct evdev_device *device); >> } buttons; >> + >> +/* The number of times libevdev processes a SYN_DROPPED, so we can >> + * stop logging them to avoid flooding the logs. */ >> +int syn_drops_received; >> }; >> >> #define EVDEV_UNHANDLED_DEVICE ((struct evdev_device *) 1) >> -- >> 2.1.1 >> >> ___ >> wayland-devel mailing list >> wayland-devel@lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/wayland-devel >> ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH libinput v2] evdev: Log evdev event queue overflows
On Wed, Oct 29, 2014 at 09:56:27AM -0500, Derek Foreman wrote: > Log a message when the kernel event queue overflows and events are dropped. > After 10 messages logging stops to avoid flooding the logs if the condition > is persistent. merged locally, thanks. but please sign off your patches to libinput. Can I assume your s-o-b for this patch? Cheers, Peter > --- > src/evdev.c | 11 +++ > src/evdev.h | 4 > 2 files changed, 15 insertions(+) > > diff --git a/src/evdev.c b/src/evdev.c > index 1b4ce10..9026f5c 100644 > --- a/src/evdev.c > +++ b/src/evdev.c > @@ -924,6 +924,17 @@ evdev_device_dispatch(void *data) > rc = libevdev_next_event(device->evdev, >LIBEVDEV_READ_FLAG_NORMAL, &ev); > if (rc == LIBEVDEV_READ_STATUS_SYNC) { > + if (device->syn_drops_received < 10) { > + device->syn_drops_received++; > + log_info(libinput, "SYN_DROPPED event from " > + "\"%s\" - some input events have " > + "been lost.\n", device->devname); > + if (device->syn_drops_received == 10) > + log_info(libinput, "No longer logging " > + "SYN_DROPPED events for " > + "\"%s\"\n", device->devname); > + } > + > /* send one more sync event so we handle all > currently pending events before we sync up > to the current state */ > diff --git a/src/evdev.h b/src/evdev.h > index c0d6577..9e84623 100644 > --- a/src/evdev.h > +++ b/src/evdev.h > @@ -135,6 +135,10 @@ struct evdev_device { > /* Checks if buttons are down and commits the setting */ > void (*change_to_left_handed)(struct evdev_device *device); > } buttons; > + > + /* The number of times libevdev processes a SYN_DROPPED, so we can > + * stop logging them to avoid flooding the logs. */ > + int syn_drops_received; > }; > > #define EVDEV_UNHANDLED_DEVICE ((struct evdev_device *) 1) > -- > 2.1.1 > > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel > ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Reusing wl_egl_window for multiple EGL surfaces
I see, on the server side there are helpful APIs like wl_event_loop_add_timer and wl_event_source_timer_update to integrate timers into event loop but unfortunately not so on client side. I guess it might not make sense for libwaylandclient to have such APIs but instead the app/toolkits that implement the client part must have custom APIs coarsely mirroring the server's functionality. From what i understand from the file you pointed to it mainly does - 1) create main epoll_fd during setup 2) add display_fd to epoll_fd and the corresponding task handler and user data 3) create and add timer_fd to the epoll_fd with its own task handler and user_data in main event loop of my simple app just keep performing epoll_wait like in the file and invoke task handlers for generated events. I will try to get this integrated into my app and post issues if any. Thank you for all the help. - VirtualPresence On Thu, Oct 30, 2014 at 1:16 AM, Pekka Paalanen wrote: > On Wed, 29 Oct 2014 08:48:12 -0700 > Virtual Presence wrote: > > > Thank you for the detailed gyaan. I will look into the "sub-surface" > > protocol as an alternative. What I do as of now is have the 2 threads on > a > > 3 second timer where threadA renders triangle for 3 seconds then signals > a > > mutex condition and wakes up threadB which renders gears for 3 seconds > and > > so on and so on. I will also look into the option of reusing the > wl_surface > > for multiple wl_egl_window. This seems closest to what i had in mind. I > > would also like to attach 3 second timer signal to the display FD and the > > custom queue i have setup for the 2 threads so that instead of having a > > dedicated timer logic I can blend the event handling into the Wayland > > model. I haven't been successful in doing this though. As an alternative > I > > am looking into the option of writing a wl_timer protocol to provide the > > functionality. Any suggestions on how i can tie in the timer logic or any > > comments on having a dedicated wl_timer protocol? Thank you for all the > > help. > > Don't do anything with protocol about timers, unless your only goal is > to learn how to define new protocols by a throw-away toy example. > > Your client is already polling the wayland connection fd. You can just, > say, use timerfd API to create an fd for your timer needs, and simply > add that to the poll set. That is what > http://cgit.freedesktop.org/wayland/weston/tree/clients/window.c > already does (look for display_watch_fd), for instance. > > Or use an event library that offers you everything in a portable > fashion. Or a real toolkit. > > > Thanks, > pq > ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Python Project
Hi everybody! I have a project for developing a Python based OS. Just for fun.It will use the Linux kernel and a python runtime to execute core modules and apps. Currently, I'm working on porting Wayland to python. If anybody's interested, I appreciate any help, specially from experienced devs. Thanks ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH libinput 1/4] filter: Fix typo
accelator -> accelerator --- src/evdev.c | 2 +- src/filter.c | 2 +- src/filter.h | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/src/evdev.c b/src/evdev.c index dd2228b..341f7d8 100644 --- a/src/evdev.c +++ b/src/evdev.c @@ -981,7 +981,7 @@ int evdev_device_init_pointer_acceleration(struct evdev_device *device) { device->pointer.filter = - create_pointer_accelator_filter( + create_pointer_accelerator_filter( pointer_accel_profile_linear); if (!device->pointer.filter) return -1; diff --git a/src/filter.c b/src/filter.c index defbcae..205cd03 100644 --- a/src/filter.c +++ b/src/filter.c @@ -282,7 +282,7 @@ struct motion_filter_interface accelerator_interface = { }; struct motion_filter * -create_pointer_accelator_filter(accel_profile_func_t profile) +create_pointer_accelerator_filter(accel_profile_func_t profile) { struct pointer_accelerator *filter; diff --git a/src/filter.h b/src/filter.h index 1f53e81..0dc081b 100644 --- a/src/filter.h +++ b/src/filter.h @@ -53,7 +53,7 @@ typedef double (*accel_profile_func_t)(struct motion_filter *filter, uint64_t time); struct motion_filter * -create_pointer_accelator_filter(accel_profile_func_t filter); +create_pointer_accelerator_filter(accel_profile_func_t filter); /* -- 2.1.1 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH libinput 0/4] some acceleration fixes, mostly for high DPI mice
The acceleration filter currently isn't particularly pleased with gaming mice. They generally have high DPI (can be over 8000 DPI) and can have high update rates (1000+ per second). This can result in the accel curve being biased heavily towards the high points on the accel curve. This patch set allows a way to normalize the deltas to 400DPI so when the DPI setting of the mouse is correct, it should feel much the same as a normal mouse. This is, of course, only a partial solution. Setting a reasonable default is a massive problem that needs to be addressed in the future - for now we just set it to 400 (which may actually not be that prevalent any more but there doesn't seem to be such thing as a "standard" DPI mouse). Derek Foreman (4): filter: Fix typo filter: perform speed computations with doubles evdev: add DPI to evdev calculations config: Allow setting non-default device DPI src/evdev.c| 15 --- src/evdev.h| 5 + src/filter.c | 6 +++--- src/filter.h | 2 +- src/libinput.c | 7 +++ src/libinput.h | 22 ++ 6 files changed, 50 insertions(+), 7 deletions(-) -- 2.1.1 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH libinput 4/4] config: Allow setting non-default device DPI
This allows changing a device's DPI from the default 400 --- src/evdev.c| 7 +++ src/evdev.h| 3 +++ src/libinput.c | 7 +++ src/libinput.h | 22 ++ 4 files changed, 39 insertions(+) diff --git a/src/evdev.c b/src/evdev.c index 8efa21a..e267320 100644 --- a/src/evdev.c +++ b/src/evdev.c @@ -1360,6 +1360,13 @@ evdev_device_get_id_vendor(struct evdev_device *device) return libevdev_get_id_vendor(device->evdev); } +enum libinput_config_status +evdev_device_set_dpi(struct evdev_device *device, uint32_t dpi) +{ + device->dpi = dpi; + return LIBINPUT_CONFIG_STATUS_SUCCESS; +} + void evdev_device_set_default_calibration(struct evdev_device *device, const float calibration[6]) diff --git a/src/evdev.h b/src/evdev.h index 81dc140..db462c6 100644 --- a/src/evdev.h +++ b/src/evdev.h @@ -309,4 +309,7 @@ evdev_to_left_handed(struct evdev_device *device, return button; } +enum libinput_config_status +evdev_device_set_dpi(struct evdev_device *device, uint32_t dpi); + #endif /* EVDEV_H */ diff --git a/src/libinput.c b/src/libinput.c index 5780a92..88efae3 100644 --- a/src/libinput.c +++ b/src/libinput.c @@ -1501,3 +1501,10 @@ libinput_device_config_buttons_get_default_left_handed(struct libinput_device *d return device->config.left_handed->get_default(device); } + +LIBINPUT_EXPORT enum libinput_config_status +libinput_device_config_override_dpi(struct libinput_device *device, + uint32_t dpi) +{ + return evdev_device_set_dpi((struct evdev_device *) device, dpi); +} diff --git a/src/libinput.h b/src/libinput.h index 9cc6f52..a721fc2 100644 --- a/src/libinput.h +++ b/src/libinput.h @@ -2007,6 +2007,28 @@ libinput_device_config_buttons_get_left_handed(struct libinput_device *device); int libinput_device_config_buttons_get_default_left_handed(struct libinput_device *device); + +/** + * @ingroup config + * + * Change the DPI setting of the device. + * + * Libinput assumes a "normal" mouse is 400DPI for some of its calculations. + * Ideally we would query mouse DPI from the device, but that isn't actually + * possible. To make things worse, some mice support multiple DPIs configured + * by a hardware switch, so even maintaining a database of mice becomes + * difficult. This function allows overriding the setting for mice we can't + * deal with any other way. + * + * @param device The device to configure + * @param dpi The device DPI + * + * @return A config status code + */ +enum libinput_config_status +libinput_device_config_override_dpi(struct libinput_device *device, + uint32_t dpi); + #ifdef __cplusplus } #endif -- 2.1.1 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH libinput 2/4] filter: perform speed computations with doubles
Converting to integer before the sqrt calculation can cause loss of motion at low speed. --- src/filter.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/filter.c b/src/filter.c index 205cd03..afb87ef 100644 --- a/src/filter.c +++ b/src/filter.c @@ -139,8 +139,8 @@ tracker_by_offset(struct pointer_accelerator *accel, unsigned int offset) static double calculate_tracker_velocity(struct pointer_tracker *tracker, uint64_t time) { - int dx; - int dy; + double dx; + double dy; double distance; dx = tracker->dx; -- 2.1.1 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH libinput 3/4] evdev: add DPI to evdev calculations
Assume "normal" mice are 400DPI, and that all calculations should be normalized to this before being fed into the filter. There isn't yet a way to configure a device's DPI. --- src/evdev.c | 6 -- src/evdev.h | 2 ++ 2 files changed, 6 insertions(+), 2 deletions(-) diff --git a/src/evdev.c b/src/evdev.c index 341f7d8..8efa21a 100644 --- a/src/evdev.c +++ b/src/evdev.c @@ -42,6 +42,7 @@ #define DEFAULT_AXIS_STEP_DISTANCE 10 #define DEFAULT_MIDDLE_BUTTON_SCROLL_TIMEOUT 200 +#define DEFAULT_MOUSE_DPI 400 enum evdev_key_type { EVDEV_KEY_TYPE_NONE, @@ -205,8 +206,8 @@ evdev_flush_pending_event(struct evdev_device *device, uint64_t time) case EVDEV_NONE: return; case EVDEV_RELATIVE_MOTION: - motion.dx = device->rel.dx; - motion.dy = device->rel.dy; + motion.dx = device->rel.dx / ((double)device->dpi / DEFAULT_MOUSE_DPI); + motion.dy = device->rel.dy / ((double)device->dpi / DEFAULT_MOUSE_DPI); device->rel.dx = 0; device->rel.dy = 0; @@ -1282,6 +1283,7 @@ evdev_device_create(struct libinput_seat *seat, device->devname = libevdev_get_name(device->evdev); device->scroll.threshold = 5.0; /* Default may be overridden */ device->scroll.direction = 0; + device->dpi = DEFAULT_MOUSE_DPI; matrix_init_identity(&device->abs.calibration); matrix_init_identity(&device->abs.usermatrix); diff --git a/src/evdev.h b/src/evdev.h index c0d6577..81dc140 100644 --- a/src/evdev.h +++ b/src/evdev.h @@ -135,6 +135,8 @@ struct evdev_device { /* Checks if buttons are down and commits the setting */ void (*change_to_left_handed)(struct evdev_device *device); } buttons; + + int dpi; }; #define EVDEV_UNHANDLED_DEVICE ((struct evdev_device *) 1) -- 2.1.1 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC PATCH v2 0/6] Initial per-surface color management
Am 29.10.2014 um 20:15 schrieb Niels Ole Salscheider: > On Tuesday 28 October 2014, 15:45:18, Kai-Uwe Behrmann wrote: >> Am 27.10.2014 um 19:07 schrieb Niels Ole Salscheider: The support to mask the area of a surface so that its color space is not converted has been removed. Instead, the color profile of the main output of that surface can be attached if an application has a need to display uncorrected colors. >>> I had a discussion regarding this with Zoxc on the IRC channel. Does it >>> make sense to have a surface that is displayed uncorrected on multiple >>> outputs with different output profiles? >>> If so then this is not enough to detect that no color conversion should be >>> applied at all. >> For measuring the colorimetric performance of outputs, for testing and >> scalability, it appears the easiest to have a colormanagement-off >> switch. On osX, without such switch, the mechanism to attach the monitor >> profile to the input image brings headache to developers and this >> workaround does not work reliably. > Sure, I introduced the possibility to disable color correction of a surface > for these use-cases in my first proposal. > But is it really enough to just not apply color corrections to a surface? Or > would this use-case require to deactivate color correction completely, as > argued by John Kåre Alsaker? I can only guess what the motivation for a per output switch-off might be: * graphic cards video lut handling * compositing space triggering * consistency with alpha blending behaviour for stacked transparent surfaces with and without CM enabled * effects on top of windows (sepia, etc.) Some of the above mentioned mechanisms are not easy to integrate. So the best is to have access to each mechanism by an separate API and let applications handle them on need. For compositing might arise the need to switch off the compositing space. So a transparent widget on top of a graphics application will not make the case to touch the rgb numbers, except for the blending areas of course. Further the transparent widget can overlap in parts the CM-off widget and normal areas at the same time. So the compositing of the different areas has to be handled separately. Given that for different outputs different colour conversions are needed, that feature appears not that far stretched. The user experience will be relatively smooth. In contrary, a global CM-off will have many side effects, which make potentially a unwanted user experience for Yuv video, or other widgets, which should not be affected on desktops. On handheld systems, that is less of concern. > In the latter case, it might be better to add another protocol that allows > such tools to temporarily deactivate any color conversions... ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH weston v2 1/1] compositor: Add idle timeout option to weston.ini
Weston's idle timeout can already be set via the '-i' command-line option, but this patch lets users specify it also via weston.ini. Note that the command-line option takes precedence over the .ini, should the option be set by both. This patch also Updates weston.ini man page with idle-timeout bits https://bugs.freedesktop.org/show_bug.cgi?id=83921 Signed-off-by: Frederic Plourde Reviewed-by: Bryce Harrington --- man/weston.ini.man | 23 --- src/compositor.c | 6 +- 2 files changed, 25 insertions(+), 4 deletions(-) diff --git a/man/weston.ini.man b/man/weston.ini.man index c05a221..a665ce1 100644 --- a/man/weston.ini.man +++ b/man/weston.ini.man @@ -62,21 +62,21 @@ Comment lines are ignored: .RS 4 .nf .IR "#comment" .fi .RE .PP The section headers are: .PP .RS 4 .nf -.BR "core " "The core modules" +.BR "core " "The core modules and options" .BR "libinput " "Input device configuration" .BR "shell " "Desktop customization" .BR "launcher " "Add launcher to the panel" .BR "screensaver" "Screensaver selection" .BR "output " "Output configuration" .BR "input-method " "Onscreen keyboard input" .BR "keyboard " "Keyboard layouts" .BR "terminal " "Terminal application options" .BR "xwayland " "XWayland options" .BR "screen-share " "Screen sharing options" @@ -85,21 +85,21 @@ The section headers are: .PP Possible value types are string, signed and unsigned 32-bit integer, and boolean. Strings must not be quoted, do not support any escape sequences, and run till the end of the line. Integers can be given in decimal (e.g. 123), octal (e.g. 0173), and hexadecimal (e.g. 0x7b) form. Boolean values can be only 'true' or 'false'. .RE .SH "CORE SECTION" The .B core -section is used to select the startup compositor modules. +section is used to select the startup compositor modules and general options. .TP 7 .BI "shell=" desktop-shell.so specifies a shell to load (string). This can be used to load your own implemented shell or one with Weston as default. Available shells in the .IR "__weston_modules_dir__" directory are: .PP .RS 10 .nf @@ -139,20 +139,37 @@ directory are: .fi .RE .BI "gbm-format="format sets the GBM format used for the framebuffer for the GBM backend. Can be .B xrgb, .B xrgb2101010, .B rgb565. By default, xrgb is used. .RS .PP +.RE +.TP 7 +.BI "idle-time="seconds +sets Weston's idle timeout in seconds. This idle timeout is the time +after which Weston will enter an "inactive" mode and screen will fade to +black. Note that a screensaver may also start at this moment after fade-out +(if enabled in the SCREENSAVER section below), but the current idle-time +option has nothing to do with screensavers. + +.IR Important +: This option may also be set via Weston's '-i' command +line option and will take precedence over the current .ini option. This +means that if both weston.ini and command line define this idle-timeout +time, the one specified in the command-line will be used. On the other +hand, if none of these sets the value, default idle timeout will be +set to 300 seconds. +.RS .SH "LIBINPUT SECTION" The .B libinput section is used to configure input devices when using the libinput input device backend. .PP Available configuration are: .TP 7 .BI "enable_tap=" true @@ -289,21 +306,21 @@ section is optional, as are all of the entries that may be specified in it. .TP 7 .BI "path=" /usr/libexec/weston-screensaver This instructs the compositor to use the selected screensaver client on a given path (string). If this line is missing or commented out, the screensaver in .B "weston(1)" is disabled. .RE .TP 7 .BI "duration=" 600 -The idle time in seconds until the screensaver disappears in order to save power +The time in seconds until the screensaver disappears in order to save power (unsigned integer). .SH "OUTPUT SECTION" There can be multiple output sections, each corresponding to one output. It is currently only recognized by the drm and x11 backends. .TP 7 .BI "name=" name sets a name for the output (string). The backend uses the name to identify the output. All X11 output names start with a letter X. All Wayland output names start with the letters WL. The available output names for DRM backend are listed in the diff --git a/src/compositor.c b/src/compositor.c index 4540911..015037f 100644 --- a/src/compositor.c +++ b/src/compositor.c @@ -4603,21 +4603,21 @@ int main(int argc, char *argv[]) *(*backend_init)(struct wl_display *display, int *argc, char *argv[], struct weston_config *config); int i, fd; char *backend = NULL; char *shell = NULL; char *modules = NULL; char *option_modules = NULL; char *log = NULL; char *server_socket = NULL, *end; - int32_t idle_time = 300; +
[PATCH weston v2 2/2] compositor-drm: Watchdog timer implementation
Weston will not repaint until previous update has been acked by a page-flip event coming from the drm driver. However, some buggy drivers won't return those events or will stop sending them at some point and Weston output repaints will completely freeze. To ease developers' task in testing their drivers, this patch makes compositor-drm use a watchdog timer to detect cases where those page-flip events stop coming. This watchdog timer (WDT) implementation is software only and includes basic features usually found in a WDT. We simply exit Weston gracefully with an exit code when the dog barks. The watchdog timeout value can be set via weston.ini by adding a watchdog-timer-timeout= entry under a new [compositor-drm] section. Setting this timeout to 0 disables the watchdog feature. https://bugs.freedesktop.org/show_bug.cgi?id=83884 Signed-off-by: Frederic Plourde --- src/compositor-drm.c | 105 +++ 1 file changed, 105 insertions(+) diff --git a/src/compositor-drm.c b/src/compositor-drm.c index 07b83a7..45137cc 100644 --- a/src/compositor-drm.c +++ b/src/compositor-drm.c @@ -115,20 +115,22 @@ struct drm_compositor { int cursors_are_broken; int use_pixman; uint32_t prev_state; struct udev_input input; uint32_t cursor_width; uint32_t cursor_height; + + uint32_t watchdog_timer_timeout; }; struct drm_mode { struct weston_mode base; drmModeModeInfo mode_info; }; struct drm_output; struct drm_fb { @@ -176,20 +178,25 @@ struct drm_output { struct drm_fb *current, *next; struct backlight *backlight; struct drm_fb *dumb[2]; pixman_image_t *image[2]; int current_image; pixman_region32_t previous_damage; struct vaapi_recorder *recorder; struct wl_listener recorder_frame_listener; + + struct watchdog_timer { + struct wl_event_source *timer; + uint32_t timeout; + } wdt; }; /* * An output has a primary display plane plus zero or more sprites for * blending display contents. */ struct drm_sprite { struct wl_list link; struct weston_plane plane; @@ -215,20 +222,90 @@ struct drm_parameters { int tty; int use_pixman; const char *seat_id; }; static struct gl_renderer_interface *gl_renderer; static const char default_seat[] = "seat0"; static void +drm_output_watchdog_timer_bark(void *output) { + /* + * Our watchdog just barked at us, means we're not receiving drm + * page flip events anymore for that output. Let's gracefully exit + * weston with a return value so devs can debug what's going on. + */ + struct drm_output *out = (struct drm_output *) output; + struct weston_compositor *compositor = + (struct weston_compositor *) out->base.compositor; + + weston_compositor_exit_with_code(compositor, EXIT_FAILURE); +} + +/* Creates the watchdog timer. Note that timer is not armed by default */ +static int +drm_output_watchdog_timer_create(struct drm_output *output) +{ + struct wl_event_loop *loop = NULL; + struct drm_compositor *ec = + (struct drm_compositor *) output->base.compositor; + + loop = wl_display_get_event_loop(ec->base.wl_display); + if (loop) { + output->wdt.timer = wl_event_loop_add_timer(loop, + (wl_event_loop_timer_func_t)drm_output_watchdog_timer_bark, + output); + + if (output->wdt.timer) { + output->wdt.timeout = ec->watchdog_timer_timeout; + return 0; + } + } + + weston_log("creating drm watchdog timer failed: %m\n"); + return -1; +} + +/* Start/reset/arm the dog's timer. This can also be used to 'pat' the dog */ +static int +drm_output_watchdog_timer_start(struct watchdog_timer *wdt) +{ + if (wdt->timer) + return wl_event_source_timer_update(wdt->timer, wdt->timeout); + + weston_log("failed to start drm watchdog: %m\n"); + return -1; +} + +/* Disarms the watchdog */ +static int +drm_output_watchdog_timer_stop(struct watchdog_timer *wdt) +{ + if (wdt->timer) + return wl_event_source_timer_update(wdt->timer, 0); + + weston_log("failed to stop drm watchdog: %m\n"); + return -1; +} + +static void +drm_output_watchdog_timer_destroy(struct watchdog_timer *wdt) +{ + if (wdt->timer) { + wl_event_source_remove(wdt->timer); + } + + wdt->timer = NULL; +} + +static void drm_output_set_cursor(struct drm_output *output); static int drm_sprite_crtc_supported(struct weston_output *output_base, uint32_t supported) { struct weston_compositor *ec = output_base->compositor; struct drm_compositor *c =(struct drm_compositor *) ec; struct drm
Re: [WESTON PATCH 2/2] compositor-drm: Watchdog timer implementation
On 14-10-29 05:40 PM, Bill Spitzak wrote: On 10/29/2014 12:19 PM, Frederic Plourde wrote: Mhh... you mean something like : static int drm_output_watchdog_timer_create(struct drm_output *output) { struct wl_event_loop *loop = NULL; struct weston_compositor *ec = output_base->compositor; loop = wl_display_get_event_loop(ec->wl_display); if (loop) { output->wdt->timer = wl_event_loop_add_timer(loop, drm_output_watchdog_bark, ec->watchdog_timer_timeout); blah..blah... Yes that is what I meant. If so, then I think I'd prefer to completely remove 'drm_output_watchdog_timer_create" and inline it directly from 'create_output_for_connector', since it's not a very big function anyway and we're not sure as of today that we're going to reuse this for anything else. Probably that is ok as well. The main problem is that it is impossible to inline the "bark" function so one part of the code is in a different place, which may mean it is clearer to put the reference to that function up next to it too. what do you think ? I'm usually not a big fan of static functions with hard-coded values, but if you tell me it's better for clarity... I might be tempted, dunno. Generally I don't think a generic function should be written until you have at least 2 instances where it is used. I think you won me over... Let's pretend we're not going to use that for anything else for now. patch v2 coming up next :) ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[weston V2 2/2] Use AC_SEARCH_LIBS instead of AC_CHECK_LIBS for dl, jpeg, pam
--- Makefile.am | 8 +++- configure.ac | 23 ++- 2 files changed, 9 insertions(+), 22 deletions(-) diff --git a/Makefile.am b/Makefile.am index 1557953..077efbc 100644 --- a/Makefile.am +++ b/Makefile.am @@ -44,7 +44,7 @@ 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) libshared.la + libshared.la weston_SOURCES = \ src/git-version.h \ @@ -130,10 +130,9 @@ weston_launch_SOURCES = src/weston-launch.c src/weston-launch.h weston_launch_CPPFLAGS = -DBINDIR='"$(bindir)"' weston_launch_CFLAGS= \ $(GCC_CFLAGS) \ - $(PAM_CFLAGS) \ $(SYSTEMD_LOGIN_CFLAGS) \ $(LIBDRM_CFLAGS) -weston_launch_LDADD = $(PAM_LIBS) $(SYSTEMD_LOGIN_LIBS) $(LIBDRM_LIBS) +weston_launch_LDADD = $(SYSTEMD_LOGIN_LIBS) $(LIBDRM_LIBS) if ENABLE_SETUID_INSTALL install-exec-hook: @@ -818,8 +817,7 @@ libshared_cairo_la_LIBADD = \ $(PIXMAN_LIBS) \ $(CAIRO_LIBS) \ $(PNG_LIBS) \ - $(WEBP_LIBS)\ - $(JPEG_LIBS) + $(WEBP_LIBS) libshared_cairo_la_SOURCES = \ $(libshared_la_SOURCES) \ diff --git a/configure.ac b/configure.ac index e78f6c8..a1fd94a 100644 --- a/configure.ac +++ b/configure.ac @@ -42,9 +42,8 @@ AC_ARG_VAR([WESTON_SHELL_CLIENT], PKG_PROG_PKG_CONFIG() -AC_CHECK_FUNC([dlopen], [], - AC_CHECK_LIB([dl], [dlopen], DLOPEN_LIBS="-ldl")) -AC_SUBST(DLOPEN_LIBS) +AC_SEARCH_LIBS([dlopen], [dl], [], + [AC_MSG_FAILURE([Dynamic linking loader missing])]) AC_SEARCH_LIBS([sqrt], [m], [], [AC_MSG_FAILURE([Math library missing])]) @@ -292,14 +291,8 @@ if test x$enable_vaapi_recorder != xno; then fi AM_CONDITIONAL(ENABLE_VAAPI_RECORDER, test "x$have_libva" = xyes) - -AC_CHECK_LIB([jpeg], [jpeg_CreateDecompress], have_jpeglib=yes) -if test x$have_jpeglib = xyes; then - JPEG_LIBS="-ljpeg" -else - AC_ERROR([libjpeg not found]) -fi -AC_SUBST(JPEG_LIBS) +AC_SEARCH_LIBS([jpeg_CreateDecompress], [jpeg], [], + [AC_MSG_FAILURE([libjpeg not found])]) PKG_CHECK_MODULES(CAIRO, [cairo]) @@ -366,12 +359,8 @@ AS_IF([test "x$have_systemd_login_209" = "xyes"], AC_ARG_ENABLE(weston-launch, [ --enable-weston-launch],, enable_weston_launch=yes) AM_CONDITIONAL(BUILD_WESTON_LAUNCH, test x$enable_weston_launch == xyes) if test x$enable_weston_launch == xyes; then - AC_CHECK_LIB([pam], [pam_open_session], [have_pam=yes], [have_pam=no]) - if test x$have_pam == xno; then -AC_ERROR([weston-launch requires pam]) - fi - PAM_LIBS=-lpam - AC_SUBST(PAM_LIBS) + AC_SEARCH_LIBS([pam_open_session], [pam], [], + [AC_MSG_FAILURE([weston-launch requires pam])]) fi if test x$enable_egl = xyes; then -- 2.1.2 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[weston V2 1/2] Check for math (m) and real time (rt) libraries
--- Makefile.am | 19 +-- configure.ac | 6 ++ 2 files changed, 15 insertions(+), 10 deletions(-) diff --git a/Makefile.am b/Makefile.am index 1e7cc81..1557953 100644 --- a/Makefile.am +++ b/Makefile.am @@ -44,7 +44,7 @@ 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 + $(DLOPEN_LIBS) libshared.la weston_SOURCES = \ src/git-version.h \ @@ -211,7 +211,7 @@ drm_backend_la_LIBADD = \ $(COMPOSITOR_LIBS) \ $(DRM_COMPOSITOR_LIBS) \ $(INPUT_BACKEND_LIBS) \ - libshared.la -lrt \ + libshared.la\ libsession-helper.la drm_backend_la_CFLAGS =\ $(COMPOSITOR_CFLAGS)\ @@ -348,7 +348,7 @@ endif noinst_PROGRAMS += spring-tool spring_tool_CFLAGS = $(GCC_CFLAGS) $(COMPOSITOR_CFLAGS) -spring_tool_LDADD = $(COMPOSITOR_LIBS) -lm +spring_tool_LDADD = $(COMPOSITOR_LIBS) spring_tool_SOURCES = \ src/spring-tool.c \ src/animation.c \ @@ -429,7 +429,7 @@ weston_presentation_shm_LDADD = $(SIMPLE_CLIENT_LIBS) libshared.la -lm weston_multi_resource_SOURCES = clients/multi-resource.c weston_multi_resource_CFLAGS = $(AM_CFLAGS) $(SIMPLE_CLIENT_CFLAGS) -weston_multi_resource_LDADD = $(SIMPLE_CLIENT_LIBS) libshared.la -lm +weston_multi_resource_LDADD = $(SIMPLE_CLIENT_LIBS) libshared.la endif if BUILD_SIMPLE_EGL_CLIENTS @@ -439,7 +439,7 @@ nodist_weston_simple_egl_SOURCES = \ protocol/xdg-shell-protocol.c \ protocol/xdg-shell-client-protocol.h weston_simple_egl_CFLAGS = $(AM_CFLAGS) $(SIMPLE_EGL_CLIENT_CFLAGS) -weston_simple_egl_LDADD = $(SIMPLE_EGL_CLIENT_LIBS) -lm +weston_simple_egl_LDADD = $(SIMPLE_EGL_CLIENT_LIBS) endif noinst_LTLIBRARIES += libtoytoolkit.la @@ -466,7 +466,7 @@ BUILT_SOURCES += $(nodist_libtoytoolkit_la_SOURCES) libtoytoolkit_la_LIBADD = \ $(CLIENT_LIBS) \ $(CAIRO_EGL_LIBS) \ - libshared-cairo.la -lrt -lm + libshared-cairo.la libtoytoolkit_la_CFLAGS = $(AM_CFLAGS) $(CLIENT_CFLAGS) $(CAIRO_EGL_CFLAGS) weston_flower_SOURCES = clients/flower.c @@ -520,7 +520,7 @@ weston_nested_LDADD = libtoytoolkit.la $(SERVER_LIBS) weston_nested_CFLAGS = $(AM_CFLAGS) $(CLIENT_CFLAGS) weston_nested_client_SOURCES = clients/nested-client.c -weston_nested_client_LDADD = $(SIMPLE_EGL_CLIENT_LIBS) -lm +weston_nested_client_LDADD = $(SIMPLE_EGL_CLIENT_LIBS) weston_nested_client_CFLAGS = $(AM_CFLAGS) $(CLIENT_CFLAGS) endif @@ -560,7 +560,7 @@ weston_subsurfaces_CFLAGS = \ $(AM_CFLAGS)\ $(SIMPLE_EGL_CLIENT_CFLAGS) \ $(CLIENT_CFLAGS) -weston_subsurfaces_LDADD = libtoytoolkit.la $(SIMPLE_EGL_CLIENT_LIBS) -lm +weston_subsurfaces_LDADD = libtoytoolkit.la $(SIMPLE_EGL_CLIENT_LIBS) endif if HAVE_PANGO @@ -916,7 +916,7 @@ vertex_clip_test_SOURCES = \ tests/vertex-clip-test.c\ src/vertex-clipping.c \ src/vertex-clipping.h -vertex_clip_test_LDADD = libtest-runner.la -lm -lrt +vertex_clip_test_LDADD = libtest-runner.la libtest_client_la_SOURCES =\ tests/weston-test-client-helper.c \ @@ -984,7 +984,6 @@ matrix_test_SOURCES = \ shared/matrix.c \ shared/matrix.h matrix_test_CPPFLAGS = -DUNIT_TEST -matrix_test_LDADD = -lm -lrt if BUILD_SETBACKLIGHT noinst_PROGRAMS += setbacklight diff --git a/configure.ac b/configure.ac index 934..e78f6c8 100644 --- a/configure.ac +++ b/configure.ac @@ -46,6 +46,12 @@ AC_CHECK_FUNC([dlopen], [], AC_CHECK_LIB([dl], [dlopen], DLOPEN_LIBS="-ldl")) AC_SUBST(DLOPEN_LIBS) +AC_SEARCH_LIBS([sqrt], [m], [], + [AC_MSG_FAILURE([Math library missing])]) + +AC_SEARCH_LIBS([clock_gettime], [rt], [], + [AC_MSG_FAILURE([Real time library missing])]) + AC_CHECK_DECL(SFD_CLOEXEC,[], [AC_MSG_ERROR("SFD_CLOEXEC is needed to compile weston")], [[#include ]]) -- 2.1.2 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston] xwayland: fix fullscreening
On Wed, 29 Oct 2014 13:44:44 +0100 Marek Chalupa wrote: > set_fullscreen has been sending configure before changing the state > and xwayland windows added border to the fullscreen size. > > This fixes the bug: > https://bugs.freedesktop.org/show_bug.cgi?id=83502 > > Signed-off-by: Marek Chalupa > --- > desktop-shell/shell.c | 4 ++-- > xwayland/window-manager.c | 2 +- > 2 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c > index 9fafb39..8e3f79d 100644 > --- a/desktop-shell/shell.c > +++ b/desktop-shell/shell.c > @@ -2929,10 +2929,10 @@ shell_interface_set_fullscreen(struct shell_surface > *shsurf, > struct weston_output *output) > { > surface_clear_next_states(shsurf); > - set_fullscreen(shsurf, method, framerate, output); > - > shsurf->next_state.fullscreen = true; > shsurf->state_changed = true; > + > + set_fullscreen(shsurf, method, framerate, output); > } > > static int > diff --git a/xwayland/window-manager.c b/xwayland/window-manager.c > index 2902373..e7e5a7a 100644 > --- a/xwayland/window-manager.c > +++ b/xwayland/window-manager.c > @@ -2193,7 +2193,7 @@ send_configure(struct weston_surface *surface, int32_t > width, int32_t height) > struct theme *t = window->wm->theme; > int vborder, hborder; > > - if (window->decorate) { > + if (window->decorate && !window->fullscreen) { > hborder = 2 * t->width; > vborder = t->titlebar_height + t->width; > } else { > -- > 1.9.3 Hi, Marek. This patch does fix the problem. Reviewed-by: Ryo Munakata Thank you. -- Ryo Munakata ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Reusing wl_egl_window for multiple EGL surfaces
On Wed, 29 Oct 2014 08:48:12 -0700 Virtual Presence wrote: > Thank you for the detailed gyaan. I will look into the "sub-surface" > protocol as an alternative. What I do as of now is have the 2 threads on a > 3 second timer where threadA renders triangle for 3 seconds then signals a > mutex condition and wakes up threadB which renders gears for 3 seconds and > so on and so on. I will also look into the option of reusing the wl_surface > for multiple wl_egl_window. This seems closest to what i had in mind. I > would also like to attach 3 second timer signal to the display FD and the > custom queue i have setup for the 2 threads so that instead of having a > dedicated timer logic I can blend the event handling into the Wayland > model. I haven't been successful in doing this though. As an alternative I > am looking into the option of writing a wl_timer protocol to provide the > functionality. Any suggestions on how i can tie in the timer logic or any > comments on having a dedicated wl_timer protocol? Thank you for all the > help. Don't do anything with protocol about timers, unless your only goal is to learn how to define new protocols by a throw-away toy example. Your client is already polling the wayland connection fd. You can just, say, use timerfd API to create an fd for your timer needs, and simply add that to the poll set. That is what http://cgit.freedesktop.org/wayland/weston/tree/clients/window.c already does (look for display_watch_fd), for instance. Or use an event library that offers you everything in a portable fashion. Or a real toolkit. Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH Weston 1/1] desktop-shell: implement autolaunch
On Wed, 29 Oct 2014 20:01:33 + Daniel Stone wrote: > Hi, > > On Wednesday, October 29, 2014, Pekka Paalanen < > pekka.paala...@collabora.co.uk> wrote: > > > On Tue, 28 Oct 2014 16:46:24 + > > Daniel Stone > wrote: > > > On 24 October 2014 11:18, Pekka Paalanen > > > > > wrote: > > I think we all forgot a tiny detail here. > > > > weston_client_start() is a compositor internal function, while this > > patch is modifying weston-desktop-shell client. > > > Egads, I'd completely missed that, and assumed it was compositor rather > than shell. > > Any reason to have it like that? Compositor seems more natural to me ... The compositor could do the autolaunch, but we also have the panel launch buttons, that need to be executed in weston-desktop-shell. And autolaunch and the panel launchers are very similar, but not too similar to the in-weston launching. But I see what you might be getting at: if weston-desktop-shell does autolaunch, and it respawns, it will autolaunch everything again. Not good. So we'd probably need autolaunch in the server side indeed. Then we could put the command line parsing into env/cmd/args in libshared to share that with weston-desktop-shell. Keep all the respawn logic inside the compositor and maybe refactor that into some shared weston core code. Below I'll attach what I had written earlier but not sent, because then I realized the server vs. weston-desktop-shell thing. If we do autolaunch in the server, the below more or less applies again. ** Okay, if Fred or someone actually has time to do all that refactoring and writing, it's cool. It's just more work than simply adding autolaunch, which was the original goal here. So, we need to cater for two different cases: a) start a client with a pre-made connection (set WAYLAND_SOCKET), and b) start a new arbitrary process (do not set WAYLAND_SOCKET). By refactoring, both cases should then have customizable environment, and maybe optional respawn with conditions to give up if the process exits too often. Custom environment may come from weston.ini in case of manual and auto-launchers, or hardcoded in plugins (currently not done). Respawn needs the following parameters: - is respawn triggered by wl_client destruction or SIGCHLD - when to give up (- delay to respawn?) If I understood right, you suggested that respawn would be limited to observing the wl_client, which practically means purely case a). That should work, I think. Manual launchers (the panel buttons) should never support respawn. As a detail, case a) function will also need a hook that delivers the new wl_client to the calling code when respawn happens. Otherwise e.g. shell.c would not get the new authorized connection if weston-desktop-shell crashes. We will also need a way to stop respawning, e.g. shell.c uses that during shutdown when it deliberately disconnects weston-desktop-shell. When to give up? The current logic for weston-desktop-shell is that if it crashes during the first 30 seconds from session start, respawn will not be attempted, and weston is shut down instead. Later, if weston-desktop-shell crashes more than 5 times within 30 seconds, it gives up but does not exit Weston, since other clients may still work. ** Do we want to support autolaunching anything else than Wayland clients directly? If not, then case b) can be dropped, which would be nice. Can the weston-desktop-shell respawn/shutdown logic be supported by a generic respawn code, or is it too complicated to be worth it? Maybe e.g. weston-keyboard has a less complicated respawn logic that could share with autolaunch. Details... up to the person writing the code. We can then see how it looks like. I would just want to avoid designing a big and complicated launching and respawning framework just to cater the need of one special case (weston-desktop-shell). If we can do with a simple design otherwise but force weston-desktop-shell logic still be separate, that is fine. Simplicity should be the driving goal in the code design. ;-) Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH] Don't document an absent parameter.
Quells a doxygen warning: src/wayland-server.c:790: warning: argument 'None' of command @param is not found in the argument list of wl_display::wl_display_create(void) Signed-off-by: Bryce Harrington --- src/wayland-server.c | 1 - 1 file changed, 1 deletion(-) diff --git a/src/wayland-server.c b/src/wayland-server.c index 674aeca..ffe5233 100644 --- a/src/wayland-server.c +++ b/src/wayland-server.c @@ -787,7 +787,6 @@ bind_display(struct wl_client *client, struct wl_display *display) /** Create Wayland display object. * - * \param None * \return The Wayland display object. Null if failed to create * * This creates the wl_display object. -- 1.9.1 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel