[PATCH weston-ivi-shell v5 6/9] A reference implementation of UI client how to use ivi-hmi-controller.
This is launched from hmi-controller by using hmi_client_start and create a pthread. The basic flow is as followed, 1/ create pthread 2/ read configuration from weston.ini. 3/ draw png file to surface according to configuration of weston.ini 4/ set up UI by using ivi-hmi-controller protocol 5/ Enter event loop 6/ If a surface receives touch/pointer event, followings are invoked according to type of event and surface 6-1/ If a surface to launch ivi_application receive touch up, it execs ivi-application configured in weston.ini. 6-2/ If a surface to switch layout mode receive touch up, it sends a request, ivi_hmi_controller_switch_mode, to hmi-controller. 6-3/ If a surface to show workspace having launchers, it sends a request, ivi_hmi_controller_home, to hmi-controller. 6-4/ If touch down events happens in workspace, ivi_hmi_controller_workspace_control is sent to slide workspace. When control finished, event: ivi_hmi_controller_workspace_end_control is received. Signed-off-by: Nobuhiko Tanibata nobuhiko_tanib...@xddp.denso.co.jp --- Changes for v2: - squash Makefile to this patch Changes for v3 and v4: - nothing. Version number aligned to the first patch Changes for v5: - usleep with roundtrip uses CPU. replace them with wl_display_dispatch ivi-shell/Makefile.am |2 + ivi-shell/hmi-controller-homescreen.c | 1369 + ivi-shell/hmi-controller-homescreen.h | 36 + ivi-shell/hmi-controller.c|3 +- 4 files changed, 1409 insertions(+), 1 deletion(-) create mode 100644 ivi-shell/hmi-controller-homescreen.c create mode 100644 ivi-shell/hmi-controller-homescreen.h diff --git a/ivi-shell/Makefile.am b/ivi-shell/Makefile.am index 28589f8..afaa5e3 100644 --- a/ivi-shell/Makefile.am +++ b/ivi-shell/Makefile.am @@ -46,6 +46,8 @@ hmi_controller_la_LIBADD = $(CLIENT_LIBS) $(IVI_SHELL_LIBS) ./libweston-layout.l hmi_controller_la_CFLAGS = $(GCC_CFLAGS) $(IVI_SHELL_CFLAGS) hmi_controller_la_SOURCES =\ hmi-controller.c\ + hmi-controller-homescreen.h \ + hmi-controller-homescreen.c \ ivi-application-protocol.c \ ivi-application-client-protocol.h \ ivi-hmi-controller-protocol.c \ diff --git a/ivi-shell/hmi-controller-homescreen.c b/ivi-shell/hmi-controller-homescreen.c new file mode 100644 index 000..6dc3b11 --- /dev/null +++ b/ivi-shell/hmi-controller-homescreen.c @@ -0,0 +1,1369 @@ +/* + * Copyright (C) 2013 DENSO CORPORATION + * + * 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 representations about the suitability of this software for any + * purpose. It is provided as is without express or implied warranty. + * + * THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS + * SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND + * FITNESS, IN NO EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY + * SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER + * RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF + * CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN + * CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. + */ + +#include sys/wait.h +#include unistd.h +#include stdlib.h +#include stdio.h +#include string.h +#include linux/input.h +#include assert.h +#include fcntl.h +#include signal.h +#include sys/mman.h +#include getopt.h +#include pthread.h +#include wayland-cursor.h +#include hmi-controller-homescreen.h +#include ../shared/cairo-util.h +#include ../shared/config-parser.h +#include ivi-application-client-protocol.h +#include ivi-hmi-controller-client-protocol.h + +/** + * A reference implementation how to use ivi-hmi-controller interface to interact + * with hmi-controller. This is launched from hmi-controller by using + * hmi_client_start and create a pthread. + * + * The basic flow is as followed, + * 1/ create pthread + * 2/ read configuration from weston.ini. + * 3/ draw png file to surface according to configuration of weston.ini + * 4/ set up UI by using ivi-hmi-controller protocol + * 5/ Enter event loop + * 6/ If a surface receives touch/pointer event, followings are invoked according + *to type of event and surface + * 6-1/ If a surface to launch ivi_application receive touch up, it execs + * ivi-application configured in weston.ini. + * 6-2/ If a surface to switch layout
Re: [PATCH weston 0/8] wl_viewport enhancements
On Fri, 14 Mar 2014 14:38:10 +0200 Pekka Paalanen ppaala...@gmail.com wrote: From: Pekka Paalanen pekka.paala...@collabora.co.uk Hi, this series replaces the first 5 patches from http://lists.freedesktop.org/archives/wayland-devel/2014-March/013580.html Compared to the old series, this series carries the same 5 patches rebased on top of the current master branch. It adds a tiny fix (patch 4). The big thing added in this series is patch 7, which adds two new wl_viewport requests for setting the source rectangle and destination size separately. This will be needed by the Presentation extension, which classifies source rectangle as buffer state and destination size as surface state, hence going through different commit paths. Clients will need a way to set these separately. We now also define what it means if source rectangle is set, but destination size is not set, and vice versa. This patch series does not yet change the wl_surface.commit behaviour. When wl_scaler/wl_viewport eventually migrates to Wayland, my intention is to drop the wl_viewport.set request and the error codes. I guess this would also need to rename the global interface, which gives us the opportunity to change the interface style from factory to something else, if we want. Pekka Paalanen (8): compositor: refactor more into weston_surface_attach compositor: buffer can be non-NULL only if newly_attached compositor: refactor code into weston_surface_reset_pending_buffer() compositor: use surface_set_size() in one more case compositor: reorganize struct weston_buffer_viewport compositor: replace weston_buffer_viewport::viewport_set protocol,compositor: split wl_viewport setters clients/scaler: add modes to test wl_scaler version 2 clients/scaler.c | 143 +- desktop-shell/shell.c | 6 +- protocol/scaler.xml | 77 +++ src/compositor-drm.c | 12 +-- src/compositor.c | 208 ++ src/compositor.h | 31 +--- src/gl-renderer.c | 2 +- src/pixman-renderer.c | 59 -- 8 files changed, 400 insertions(+), 138 deletions(-) Hi, anyone else than Bill got any comments? Would you agree with Bill that 0x0 source rect should not be legal? Or if we should raise an error on negative sizes rather than just take it as disable? I am indifferent on these two questions, so if no-one voices their support for these minor changes, I won't bother. Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston 0/8] wl_viewport enhancements
Hi Pekka, I've been meaning to get around to this one. Sorry it took me so long. On Mar 20, 2014 2:46 AM, Pekka Paalanen pekka.paala...@collabora.co.uk wrote: On Fri, 14 Mar 2014 14:38:10 +0200 Pekka Paalanen ppaala...@gmail.com wrote: From: Pekka Paalanen pekka.paala...@collabora.co.uk Hi, this series replaces the first 5 patches from http://lists.freedesktop.org/archives/wayland-devel/2014-March/013580.html Compared to the old series, this series carries the same 5 patches rebased on top of the current master branch. It adds a tiny fix (patch 4). The big thing added in this series is patch 7, which adds two new wl_viewport requests for setting the source rectangle and destination size separately. This will be needed by the Presentation extension, which classifies source rectangle as buffer state and destination size as surface state, hence going through different commit paths. Clients will need a way to set these separately. We now also define what it means if source rectangle is set, but destination size is not set, and vice versa. This patch series does not yet change the wl_surface.commit behaviour. When wl_scaler/wl_viewport eventually migrates to Wayland, my intention is to drop the wl_viewport.set request and the error codes. I guess this would also need to rename the global interface, which gives us the opportunity to change the interface style from factory to something else, if we want. Pekka Paalanen (8): compositor: refactor more into weston_surface_attach compositor: buffer can be non-NULL only if newly_attached compositor: refactor code into weston_surface_reset_pending_buffer() compositor: use surface_set_size() in one more case compositor: reorganize struct weston_buffer_viewport compositor: replace weston_buffer_viewport::viewport_set protocol,compositor: split wl_viewport setters clients/scaler: add modes to test wl_scaler version 2 clients/scaler.c | 143 +- desktop-shell/shell.c | 6 +- protocol/scaler.xml | 77 +++ src/compositor-drm.c | 12 +-- src/compositor.c | 208 ++ src/compositor.h | 31 +--- src/gl-renderer.c | 2 +- src/pixman-renderer.c | 59 -- 8 files changed, 400 insertions(+), 138 deletions(-) Hi, anyone else than Bill got any comments? Would you agree with Bill that 0x0 source rect should not be legal? Or if we should raise an error on negative sizes rather than just take it as disable? As far as 0x0 goes, I don't see why we would want to allow 0-sized surfaces. As a client, I would expect the compositor to sample exactly the rectangle I gave it and no further. If I wanted to sample just one pixel, I would give it a 1x1 source, not a 0x0. Also, making both require 0 would add some nice symmetry. That said, I'm not going to be insistant on the point. As far as negative size - disable goes, I like it. We need some way of disabling them, and that works fine. You could make an argument about how we should send an actual error and kill the client, but I think just turning off crop-and-scale is sufficient. --Jason I am indifferent on these two questions, so if no-one voices their support for these minor changes, I won't bother. Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Effort for upgrading from 1.3 to 1.5
Hello everybody, Question: Given that somebody has Wayland/Weston 1.3 already integrated in their system, what would it take to upgrade to the upcoming Wayland/Weston 1.5? Is this just a matter of re-building it and everything will continue working out of the box? Are there any adjustments in the graphics stack (drivers, EGL support, etc.) needed to support 1.5? Are there any adjustments on the application side needed to work with 1.5? Background: The question is related to the weston-ivi-shell patch series submitted by Nobuhiko Tanibata. This work is connected to the work that GENIVI [1] previously did in the area of IVI Layer Management. On the GENIVI side, the original plan was to propose the ivi-shell and the corresponding protocol to the Wayland project. However, it was expected that it will take time to review and agree the protocols. Until then the plan provided for adopting an out-of-tree patch based on Wayland/Weston 1.3 for GENIVI purposes. Once the ivi-shell would be integrated in Wayland/Weston, GENIVI would switch to the upstream version. Now that the patch series was well accepted and that only a few changes were suggested to the original protocol, it would make more sense for GENIVI to align with the upstream right away. The only catch is that the content of the next GENIVI release is being finalized right now and the decision must be done quickly. During the original reviews in GENIVI, using Wayland/Weston 1.3 as the basis was already approved. The above question is an attempt to estimate the impact of adopting 1.5 instead. Any hints and information on possible upgrade problems would be therefore greatly appreciated. Thanks, --Pavel Konopelko [1] http://projects.genivi.org/ ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Effort for upgrading from 1.3 to 1.5
On Thu, 20 Mar 2014 13:31:31 + Konopelko, Pavel (P.) pkono...@visteon.com wrote: Hello everybody, Question: Given that somebody has Wayland/Weston 1.3 already integrated in their system, what would it take to upgrade to the upcoming Wayland/Weston 1.5? Is this just a matter of re-building it and everything will continue working out of the box? Are there any adjustments in the graphics stack (drivers, EGL support, etc.) needed to support 1.5? Are there any adjustments on the application side needed to work with 1.5? Hi, oh, 1.3 seems like ages ago, I can't remember. But, looking at the git history of few selected files should be enlightening, for instance in Wayland src/wayland-client.h and src/wayland-server.h, and also the protocol specification in protocol/wayland.xml. In Weston src/compositor.h. For clients, things are kept backward-compatible. For Weston plugins, change from 1.n to 1.n+1 is not guaranteed to be compatible. Libwayland API is stable and backward-compatible. The Wayland protocol is also kept stable, but we are moving from wl_shell to xdg_shell, though that probably does not concern you. On EGL front, you probably should be looking at the history of the specification files in Mesa, e.g.: http://cgit.freedesktop.org/mesa/mesa/log/docs/specs/WL_bind_wayland_display.spec to get an overview. I think application side should just work, all in all. Background: The question is related to the weston-ivi-shell patch series submitted by Nobuhiko Tanibata. This work is connected to the work that GENIVI [1] previously did in the area of IVI Layer Management. On the GENIVI side, the original plan was to propose the ivi-shell and the corresponding protocol to the Wayland project. However, it was expected that it will take time to review and agree the protocols. Until then the plan provided for adopting an out-of-tree patch based on Wayland/Weston 1.3 for GENIVI purposes. Once the ivi-shell would be integrated in Wayland/Weston, GENIVI would switch to the upstream version. Now that the patch series was well accepted and that only a few changes were suggested to the original protocol, it would make more sense for GENIVI to align with the upstream right away. The only catch is that the content of the next GENIVI release is being finalized right now and the decision must be done quickly. During the original reviews in GENIVI, using Wayland/Weston 1.3 as the basis was already approved. The above question is an attempt to estimate the impact of adopting 1.5 instead. Any hints and information on possible upgrade problems would be therefore greatly appreciated. Sorry, I think well accepted may still be a slight overstatement at the moment. It's just so hard to find time to review anything. When you get a looks good to me then that's accepted by that particular person, but even that is not enough to get into Wayland/Weston upstream. For that you need to convince Kristian, who seems to be extremely busy nowadays. Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Effort for upgrading from 1.3 to 1.5
On Mar 20, 2014 9:59 AM, Pekka Paalanen ppaala...@gmail.com wrote: On Thu, 20 Mar 2014 13:31:31 + Konopelko, Pavel (P.) pkono...@visteon.com wrote: Hello everybody, Question: Given that somebody has Wayland/Weston 1.3 already integrated in their system, what would it take to upgrade to the upcoming Wayland/Weston 1.5? Is this just a matter of re-building it and everything will continue working out of the box? Are there any adjustments in the graphics stack (drivers, EGL support, etc.) needed to support 1.5? Are there any adjustments on the application side needed to work with 1.5? Hi, oh, 1.3 seems like ages ago, I can't remember. But, looking at the git history of few selected files should be enlightening, for instance in Wayland src/wayland-client.h and src/wayland-server.h, and also the protocol specification in protocol/wayland.xml. In Weston src/compositor.h. For clients, things are kept backward-compatible. For Weston plugins, change from 1.n to 1.n+1 is not guaranteed to be compatible. Libwayland API is stable and backward-compatible. The Wayland protocol is also kept stable, but we are moving from wl_shell to xdg_shell, though that probably does not concern you. On EGL front, you probably should be looking at the history of the specification files in Mesa, e.g.: http://cgit.freedesktop.org/mesa/mesa/log/docs/specs/WL_bind_wayland_display.spec to get an overview. I think application side should just work, all in all. As Pekka said, from the libwayland and client-side everything *should* be stable. We've put a lot of work into keeping things API and ABI-stable as we've changed them. EGL implementations should be following the EGL API's that haven't changed. On the weston side, things are not so stable. In particular, the weston_view structure was added in 1.4 and this changed the weston scenegraph somewhat substantially. In particulare, the concepts of node in the scenegraph and client surface were split apart so that the same surface can appear at multiple locations at once. If you are writing your own shell plugin this change may be small or large depending on how the plugin is written. My guess, given the little I understand about IVI is that it shouldn't be too hard, but it won't be trivial. Background: The question is related to the weston-ivi-shell patch series submitted by Nobuhiko Tanibata. This work is connected to the work that GENIVI [1] previously did in the area of IVI Layer Management. On the GENIVI side, the original plan was to propose the ivi-shell and the corresponding protocol to the Wayland project. However, it was expected that it will take time to review and agree the protocols. Until then the plan provided for adopting an out-of-tree patch based on Wayland/Weston 1.3 for GENIVI purposes. Once the ivi-shell would be integrated in Wayland/Weston, GENIVI would switch to the upstream version. Now that the patch series was well accepted and that only a few changes were suggested to the original protocol, it would make more sense for GENIVI to align with the upstream right away. The only catch is that the content of the next GENIVI release is being finalized right now and the decision must be done quickly. During the original reviews in GENIVI, using Wayland/Weston 1.3 as the basis was already approved. The above question is an attempt to estimate the impact of adopting 1.5 instead. Any hints and information on possible upgrade problems would be therefore greatly appreciated. Sorry, I think well accepted may still be a slight overstatement at the moment. It's just so hard to find time to review anything. When you get a looks good to me then that's accepted by that particular person, but even that is not enough to get into Wayland/Weston upstream. For that you need to convince Kristian, who seems to be extremely busy nowadays. Agreed. Personally, I like the direction the protocol has taken. Unfortunately, I haven't had time to review any of the code or the library api. As Pekka said, to a certain extent, we're waiting on Kristian to be able to take a look at it and give an opinion on how it ought to fit into the Wayland ecosystem. However, he's been pretty busy with the X.org and GNOME merge windows coming up so I wouldn't expect a lot for a little bit yet. Hope that helps, --Jason Ekstrand ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
RE: Effort for upgrading from 1.3 to 1.5
Pekka, Jason, Jason Ekstrand wrote on 2014-03-20: On Mar 20, 2014 9:59 AM, Pekka Paalanen ppaala...@gmail.com wrote: On Thu, 20 Mar 2014 13:31:31 + Konopelko, Pavel (P.) pkono...@visteon.com wrote: Hello everybody, Question: Given that somebody has Wayland/Weston 1.3 already integrated in their system, what would it take to upgrade to the upcoming Wayland/Weston 1.5? Is this just a matter of re-building it and everything will continue working out of the box? Are there any adjustments in the graphics stack (drivers, EGL support, etc.) needed to support 1.5? Are there any adjustments on the application side needed to work with 1.5? Hi, oh, 1.3 seems like ages ago, I can't remember. But, looking at the git history of few selected files should be enlightening, for instance in Wayland src/wayland-client.h and src/wayland-server.h, and also the protocol specification in protocol/wayland.xml. In Weston src/compositor.h. For clients, things are kept backward-compatible. For Weston plugins, change from 1.n to 1.n+1 is not guaranteed to be compatible. Libwayland API is stable and backward-compatible. The Wayland protocol is also kept stable, but we are moving from wl_shell to xdg_shell, though that probably does not concern you. On EGL front, you probably should be looking at the history of the specification files in Mesa, e.g.: http://cgit.freedesktop.org/mesa/mesa/log/docs/specs/WL_bind_wayl and_display.spec to get an overview. I think application side should just work, all in all. As Pekka said, from the libwayland and client-side everything *should* be stable. We've put a lot of work into keeping things API and ABI-stable as we've changed them. EGL implementations should be following the EGL API's that haven't changed. On the weston side, things are not so stable. In particular, the weston_view structure was added in 1.4 and this changed the weston scenegraph somewhat substantially. In particulare, the concepts of node in the scenegraph and client surface were split apart so that the same surface can appear at multiple locations at once. If you are writing your own shell plugin this change may be small or large depending on how the plugin is written. My guess, given the little I understand about IVI is that it shouldn't be too hard, but it won't be trivial. Thanks a bunch for your feedback. I will go through the individual hints above to get a better picture. Background: The question is related to the weston-ivi-shell patch series submitted by Nobuhiko Tanibata. This work is connected to the work that GENIVI [1] previously did in the area of IVI Layer Management. On the GENIVI side, the original plan was to propose the ivi- shell and the corresponding protocol to the Wayland project. However, it was expected that it will take time to review and agree the protocols. Until then the plan provided for adopting an out- of-tree patch based on Wayland/Weston 1.3 for GENIVI purposes. Once the ivi-shell would be integrated in Wayland/Weston, GENIVI would switch to the upstream version. Now that the patch series was well accepted and that only a few changes were suggested to the original protocol, it would make more sense for GENIVI to align with the upstream right away. The only catch is that the content of the next GENIVI release is being finalized right now and the decision must be done quickly. During the original reviews in GENIVI, using Wayland/Weston 1.3 as the basis was already approved. The above question is an attempt to estimate the impact of adopting 1.5 instead. Any hints and information on possible upgrade problems would be therefore greatly appreciated. Sorry, I think well accepted may still be a slight overstatement at the moment. It's just so hard to find time to review anything. When you get a looks good to me then that's accepted by that particular person, but even that is not enough to get into Wayland/Weston upstream. For that you need to convince Kristian, who seems to be extremely busy nowadays. Agreed. Personally, I like the direction the protocol has taken. Unfortunately, I haven't had time to review any of the code or the library api. As Pekka said, to a certain extent, we're waiting on Kristian to be able to take a look at it and give an opinion on how it ought to fit into the Wayland ecosystem. However, he's been pretty busy with the X.org and GNOME merge windows coming up so I wouldn't expect a lot for a little bit yet. OK, I see. It's always tempting to declare a job done. Thanks, --Pavel Konopelko ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston 0/8] wl_viewport enhancements
Pekka Paalanen wrote: The sampling really goes into hair-splitting. It depends on how you interpret a texel image; is each pixel a solid-colored tile, or does the color vary smoothly from texel to the next. Then you have the source rectangle, which is divided into dst_width x dst_height pixels (let's assume output_scale=1). For each pixel, do you take a point sample from its middle, or do you integrate an average over the pixel's area in the source texture. In any case, I see that point sampling is well-defined always, and a theoretical prerequisite for the integration since we can and will sample between texels. In that respect, a 0x0 source rectangle would just mean that all pixels will be point samples at src_x,src_y. I see the source image as being solid-colored tiles for the pixels, but accessing a value from it involves integrating the product of these tiles with a sampling filter. Actual implementations convert the continuous filter to a weight for each pixel's color, note that these weights depend on the fractional part of the sample position. The bilinear interpolation that I believe you are considering is equivalent to making the filter a 1x1 square centered on the sample position. This interpretation is necessary to produce correct sampling when an image is scaled down. The filter is then bigger than 1x1. This cannot be done with a point-sampled continuous source unless that source varies depending on the scale, an approach which I find much harder to deal with than sampling filters. It also makes it possible to do more complex filters such as sync filters. For continous filters with a frequency of 1/2 or less (such as the sync at scales = 1) it is accurate to use the value of the filter at the center of each pixel as the weight for that pixel. Normally when scaling *up* the filter does not get smaller, it stops at the same size it is at scale=1. This is what bilinear interpolation does. However this scheme can well-define a scaling up that lets the user see pixels as blocks but with anti-aliased edges. This can be done with a filter that is smaller than 1x1. There is some desire for this behavior, for instance OS/X does it by default. So, better forget that and do what seems natural. The minimum sampling area (source rect) will be 1/256 x 1/256 texels per surface pixel, then. Output_scale would make that respectively smaller, too. Okay I was unaware that the source did not align with pixels. I thought the reason you were using fixed-point is to allow it to be aligned with pixels even if buffer scale is not 1. As I saw it the scaling was expected to transform the center of each output pixel to a location in the input and center a filter there. If you assume you are scaling up and a 1x1 box filter is used, the center of the samples will never be closer than .5 to the edge of the source rectangle and thus the filtering will never multiply any point outside the source rectangle by non-zero. This assumption is false if the box is allowed to be smaller than 1x1. It is also somewhat false if the box does not align with pixels (the filter is still inside, but when translated to weights at pixel centers it puts a non-zero weight outside the box. The filter also goes outside if there is scaling down instead of up, or if a more complex filter than a box is used. I was under the impression that an implementation was either required, or at least allowed, to clamp the filter locations to be inside the box. It now sounds like the box should be ignored except to calculate a scale+translate that should be done, followed by a crop to the destination rectangle. As far as negative size - disable goes, I like it. We need some way of disabling them, and that works fine. You could make an argument about how we should send an actual error and kill the client, but I think just turning off crop-and-scale is sufficient. Yes I'm ok with negative meaning disable. I was just recommending that zero *also* mean disable. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston 0/8] wl_viewport enhancements
On Thu, Mar 20, 2014 at 8:04 AM, Pekka Paalanen ppaala...@gmail.com wrote: On Thu, 20 Mar 2014 07:22:33 -0500 Jason Ekstrand ja...@jlekstrand.net wrote: Hi Pekka, I've been meaning to get around to this one. Sorry it took me so long. Hi Jason, no worries. On Mar 20, 2014 2:46 AM, Pekka Paalanen pekka.paala...@collabora.co.uk wrote: On Fri, 14 Mar 2014 14:38:10 +0200 Pekka Paalanen ppaala...@gmail.com wrote: From: Pekka Paalanen pekka.paala...@collabora.co.uk Hi, this series replaces the first 5 patches from http://lists.freedesktop.org/archives/wayland-devel/2014-March/013580.html Compared to the old series, this series carries the same 5 patches rebased on top of the current master branch. It adds a tiny fix (patch 4). The big thing added in this series is patch 7, which adds two new wl_viewport requests for setting the source rectangle and destination size separately. This will be needed by the Presentation extension, which classifies source rectangle as buffer state and destination size as surface state, hence going through different commit paths. Clients will need a way to set these separately. We now also define what it means if source rectangle is set, but destination size is not set, and vice versa. This patch series does not yet change the wl_surface.commit behaviour. When wl_scaler/wl_viewport eventually migrates to Wayland, my intention is to drop the wl_viewport.set request and the error codes. I guess this would also need to rename the global interface, which gives us the opportunity to change the interface style from factory to something else, if we want. Pekka Paalanen (8): compositor: refactor more into weston_surface_attach compositor: buffer can be non-NULL only if newly_attached compositor: refactor code into weston_surface_reset_pending_buffer() compositor: use surface_set_size() in one more case compositor: reorganize struct weston_buffer_viewport compositor: replace weston_buffer_viewport::viewport_set protocol,compositor: split wl_viewport setters clients/scaler: add modes to test wl_scaler version 2 clients/scaler.c | 143 +- desktop-shell/shell.c | 6 +- protocol/scaler.xml | 77 +++ src/compositor-drm.c | 12 +-- src/compositor.c | 208 ++ src/compositor.h | 31 +--- src/gl-renderer.c | 2 +- src/pixman-renderer.c | 59 -- 8 files changed, 400 insertions(+), 138 deletions(-) Hi, anyone else than Bill got any comments? Would you agree with Bill that 0x0 source rect should not be legal? Or if we should raise an error on negative sizes rather than just take it as disable? As far as 0x0 goes, I don't see why we would want to allow 0-sized surfaces. As a client, I would expect the compositor to sample exactly the rectangle I gave it and no further. If I wanted to sample just one pixel, I would give it a 1x1 source, not a 0x0. Also, making both require 0 would add some nice symmetry. That said, I'm not going to be insistant on the point. Ok, I should remember to change that when I revisit this again. The sampling really goes into hair-splitting. It depends on how you interpret a texel image; is each pixel a solid-colored tile, or does the color vary smoothly from texel to the next. Then you have the source rectangle, which is divided into dst_width x dst_height pixels (let's assume output_scale=1). For each pixel, do you take a point sample from its middle, or do you integrate an average over the pixel's area in the source texture. In any case, I see that point sampling is well-defined always, and a theoretical prerequisite for the integration since we can and will sample between texels. In that respect, a 0x0 source rectangle would just mean that all pixels will be point samples at src_x,src_y. Ok, I think I see what you're getting at: what happens if you upscale a single pixel? I'm not 100% sure what to say here. Part of me is inclined to say that you treat the crop as a hard crop and don't use anything outside of the specified rectangle. This would mean a 1x1 crop is is always a solid color. However, I can also see where this requirement may not always make sense and, for the benefit of implementers with strange hardware to work on, we probably don't want to specify this too closely. If compositors are going to do some sort of bilinear sampling and you're upscaling (so it may go outside of the middles of the source pixels), I guess allowing 0x0 source makes some sense. I have no idea if that's going to cause hardware problems anywhere or not. Another option would be to say negative removes the source rectangle and leave 0x0
Re: [PATCH] Make RDP backend supports arbitrary modes
Hardening,
By and large, I think it looks good. I have a few nit-picking comments
below that should take ~20 seconds to address.
I was trying to test it on my machine and nothing seems to resize. Is this
because the xfreerdp client doesn't support resizing or is it from some
other reason?
Thanks,
--Jason Ekstrand
On Tue, Mar 18, 2014 at 12:15 PM, Hardening rdp.eff...@gmail.com wrote:
This patch removes the extra modes parameter for the RDP compositor. And
make it support any mode that is requested (be aware that RDP client may
not
support all possible modes, especially odd resolution).
This is definitely useful for the fullscreen shell.
---
src/compositor-rdp.c | 105
+++
src/compositor.c | 1 -
2 files changed, 38 insertions(+), 68 deletions(-)
diff --git a/src/compositor-rdp.c b/src/compositor-rdp.c
index e8e4a8d..22380cb 100644
--- a/src/compositor-rdp.c
+++ b/src/compositor-rdp.c
@@ -49,6 +49,7 @@
#define MAX_FREERDP_FDS 32
#define DEFAULT_AXIS_STEP_DISTANCE wl_fixed_from_int(10)
+#define RDP_MODE_FREQ 60 * 1000
struct rdp_compositor_config {
int width;
@@ -58,7 +59,6 @@ struct rdp_compositor_config {
char *rdp_key;
char *server_cert;
char *server_key;
- char *extra_modes;
int env_socket;
};
@@ -121,7 +121,6 @@ rdp_compositor_config_init(struct
rdp_compositor_config *config) {
config-rdp_key = NULL;
config-server_cert = NULL;
config-server_key = NULL;
- config-extra_modes = NULL;
config-env_socket = 0;
}
@@ -320,11 +319,13 @@ rdp_output_repaint(struct weston_output
*output_base, pixman_region32_t *damage)
pixman_renderer_output_set_buffer(output_base,
output-shadow_surface);
ec-renderer-repaint_output(output-base, damage);
- wl_list_for_each(outputPeer, output-peers, link) {
- if ((outputPeer-flags RDP_PEER_ACTIVATED)
- (outputPeer-flags
RDP_PEER_OUTPUT_ENABLED))
- {
- rdp_peer_refresh_region(damage, outputPeer-peer);
+ if (pixman_region32_n_rects(damage)) {
use pixman_region32_not_empty here instead
+ wl_list_for_each(outputPeer, output-peers, link) {
+ if ((outputPeer-flags RDP_PEER_ACTIVATED)
+ (outputPeer-flags
RDP_PEER_OUTPUT_ENABLED))
+ {
+ rdp_peer_refresh_region(damage,
outputPeer-peer);
+ }
}
}
@@ -352,16 +353,29 @@ finish_frame_handler(void *data)
return 1;
}
+static struct weston_mode *
+rdp_insert_new_mode(struct weston_output *output, int width, int height,
int rate) {
+ struct weston_mode *ret;
+ ret = zalloc(sizeof *ret);
+ if(!ret)
+ return ret;
a) Missing the space between if and (. Also, let's do if (!ret) return
NULL; It makes it easier to read.
+ ret-width = width;
+ ret-height = height;
+ ret-refresh = rate;
+ wl_list_insert(output-mode_list, ret-link);
+ return ret;
+}
static struct weston_mode *
-find_matching_mode(struct weston_output *output, struct weston_mode
*target) {
+ensure_matching_mode(struct weston_output *output, struct weston_mode
*target) {
struct weston_mode *local;
wl_list_for_each(local, output-mode_list, link) {
if((local-width == target-width) (local-height ==
target-height))
return local;
}
- return 0;
+
+ return rdp_insert_new_mode(output, target-width, target-height,
RDP_MODE_FREQ);
}
static int
@@ -372,7 +386,7 @@ rdp_switch_mode(struct weston_output *output, struct
weston_mode *target_mode) {
pixman_image_t *new_shadow_buffer;
struct weston_mode *local_mode;
- local_mode = find_matching_mode(output, target_mode);
+ local_mode = ensure_matching_mode(output, target_mode);
if(!local_mode) {
weston_log(mode %dx%d not available\n,
target_mode-width, target_mode-height);
return -ENOENT;
@@ -398,6 +412,9 @@ rdp_switch_mode(struct weston_output *output, struct
weston_mode *target_mode) {
wl_list_for_each(rdpPeer, rdpOutput-peers, link) {
settings = rdpPeer-peer-settings;
+ if (settings-DesktopWidth == target_mode-width
settings-DesktopHeight == target_mode-height)
+ continue;
+
if(!settings-DesktopResize) {
/* too bad this peer does not support desktop
resize */
rdpPeer-peer-Close(rdpPeer-peer);
@@ -411,49 +428,12 @@ rdp_switch_mode(struct weston_output *output, struct
weston_mode *target_mode) {
}
static int
-parse_extra_modes(const char *modes_str, struct
[PATCH] Make RDP backend supports arbitrary modes v2
This patch removes the extra modes parameter for the RDP compositor. And
make it support any mode that is requested (be aware that RDP client may not
support all possible modes, especially odd resolution).
This new version fixes remarks done by Jason Ekstrand. It also fixes
some missing spaces between if and (.
---
src/compositor-rdp.c | 161 +--
src/compositor.c | 1 -
2 files changed, 66 insertions(+), 96 deletions(-)
diff --git a/src/compositor-rdp.c b/src/compositor-rdp.c
index e8e4a8d..909e225 100644
--- a/src/compositor-rdp.c
+++ b/src/compositor-rdp.c
@@ -49,6 +49,7 @@
#define MAX_FREERDP_FDS 32
#define DEFAULT_AXIS_STEP_DISTANCE wl_fixed_from_int(10)
+#define RDP_MODE_FREQ 60 * 1000
struct rdp_compositor_config {
int width;
@@ -58,7 +59,6 @@ struct rdp_compositor_config {
char *rdp_key;
char *server_cert;
char *server_key;
- char *extra_modes;
int env_socket;
};
@@ -121,7 +121,6 @@ rdp_compositor_config_init(struct rdp_compositor_config
*config) {
config-rdp_key = NULL;
config-server_cert = NULL;
config-server_key = NULL;
- config-extra_modes = NULL;
config-env_socket = 0;
}
@@ -320,11 +319,13 @@ rdp_output_repaint(struct weston_output *output_base,
pixman_region32_t *damage)
pixman_renderer_output_set_buffer(output_base, output-shadow_surface);
ec-renderer-repaint_output(output-base, damage);
- wl_list_for_each(outputPeer, output-peers, link) {
- if ((outputPeer-flags RDP_PEER_ACTIVATED)
- (outputPeer-flags RDP_PEER_OUTPUT_ENABLED))
- {
- rdp_peer_refresh_region(damage, outputPeer-peer);
+ if (pixman_region32_not_empty(damage)) {
+ wl_list_for_each(outputPeer, output-peers, link) {
+ if ((outputPeer-flags RDP_PEER_ACTIVATED)
+ (outputPeer-flags
RDP_PEER_OUTPUT_ENABLED))
+ {
+ rdp_peer_refresh_region(damage,
outputPeer-peer);
+ }
}
}
@@ -352,16 +353,29 @@ finish_frame_handler(void *data)
return 1;
}
+static struct weston_mode *
+rdp_insert_new_mode(struct weston_output *output, int width, int height, int
rate) {
+ struct weston_mode *ret;
+ ret = zalloc(sizeof *ret);
+ if (!ret)
+ return NULL;
+ ret-width = width;
+ ret-height = height;
+ ret-refresh = rate;
+ wl_list_insert(output-mode_list, ret-link);
+ return ret;
+}
static struct weston_mode *
-find_matching_mode(struct weston_output *output, struct weston_mode *target) {
+ensure_matching_mode(struct weston_output *output, struct weston_mode *target)
{
struct weston_mode *local;
wl_list_for_each(local, output-mode_list, link) {
- if((local-width == target-width) (local-height ==
target-height))
+ if ((local-width == target-width) (local-height ==
target-height))
return local;
}
- return 0;
+
+ return rdp_insert_new_mode(output, target-width, target-height,
RDP_MODE_FREQ);
}
static int
@@ -372,13 +386,13 @@ rdp_switch_mode(struct weston_output *output, struct
weston_mode *target_mode) {
pixman_image_t *new_shadow_buffer;
struct weston_mode *local_mode;
- local_mode = find_matching_mode(output, target_mode);
- if(!local_mode) {
+ local_mode = ensure_matching_mode(output, target_mode);
+ if (!local_mode) {
weston_log(mode %dx%d not available\n, target_mode-width,
target_mode-height);
return -ENOENT;
}
- if(local_mode == output-current_mode)
+ if (local_mode == output-current_mode)
return 0;
output-current_mode-flags = ~WL_OUTPUT_MODE_CURRENT;
@@ -398,7 +412,10 @@ rdp_switch_mode(struct weston_output *output, struct
weston_mode *target_mode) {
wl_list_for_each(rdpPeer, rdpOutput-peers, link) {
settings = rdpPeer-peer-settings;
- if(!settings-DesktopResize) {
+ if (settings-DesktopWidth == target_mode-width
settings-DesktopHeight == target_mode-height)
+ continue;
+
+ if (!settings-DesktopResize) {
/* too bad this peer does not support desktop resize */
rdpPeer-peer-Close(rdpPeer-peer);
} else {
@@ -411,49 +428,12 @@ rdp_switch_mode(struct weston_output *output, struct
weston_mode *target_mode) {
}
static int
-parse_extra_modes(const char *modes_str, struct rdp_output *output) {
- const char *startAt = modes_str;
- const char *nextPos;
- int w, h;
- struct weston_mode *mode;
-
- while(startAt *startAt) {
-
[PATCH libinput 3/3] Expand documentation for libinput_udev_create_for_seat
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
src/libinput.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/src/libinput.h b/src/libinput.h
index d6bf9f8..3e09871 100644
--- a/src/libinput.h
+++ b/src/libinput.h
@@ -691,6 +691,12 @@ struct libinput_interface {
* the given seat ID. New devices or devices removed will appear as events
* during libinput_dispatch.
*
+ * libinput_udev_create_for_seat() fails for internal values only. No
+ * guarantee is made that a device is available once the call finishes, and
+ * only devices handled by libinput are avialable. Devices that cannot be
+ * opened in @ref libinput_interface::open_restricted or do not match
+ * libinput requirements are ignored.
+ *
* @param interface The callback interface
* @param user_data Caller-specific data passed to the various callback
* interfaces.
--
1.8.5.3
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH libinput 1/3] Return the length or a neg errno from libinput_device_get_keys()
Previous return value was the straight ioctl, we should try to avoid errno
mangling.
This changes the API, if not the ABI. Callers with code along the lines of
if (libinput_device_get_keys() == -1) will now break.
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
weston is not affected by this, it checks for .
src/evdev.c| 6 +-
src/libinput.h | 2 ++
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/src/evdev.c b/src/evdev.c
index 5d01e3b..ba7c8b3 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -715,8 +715,12 @@ err:
int
evdev_device_get_keys(struct evdev_device *device, char *keys, size_t size)
{
+ int len;
+
memset(keys, 0, size);
- return ioctl(device-fd, EVIOCGKEY(size), keys);
+ len = ioctl(device-fd, EVIOCGKEY(size), keys);
+
+ return (len == -1) ? -errno : len;
}
const char *
diff --git a/src/libinput.h b/src/libinput.h
index 9a9cd8c..d6bf9f8 100644
--- a/src/libinput.h
+++ b/src/libinput.h
@@ -1169,6 +1169,8 @@ libinput_device_led_update(struct libinput_device *device,
* @param device A current input device
* @param keys An array filled with the bitmask for the keys
* @param size Size of the keys array
+ *
+ * @return The number of valid bytes in keys, or a negative errno on failure
*/
int
libinput_device_get_keys(struct libinput_device *device,
--
1.8.5.3
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH libinput 2/3] udev: factor out device_removed handling
No functional changes
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
I needed this for the rescan patch but it makes the calls more symmetrical,
so we might as well push it independently.
src/udev-seat.c | 41 +++--
1 file changed, 23 insertions(+), 18 deletions(-)
diff --git a/src/udev-seat.c b/src/udev-seat.c
index e622de2..366c92b 100644
--- a/src/udev-seat.c
+++ b/src/udev-seat.c
@@ -116,6 +116,26 @@ device_added(struct udev_device *udev_device, struct
udev_input *input)
return 0;
}
+static void
+device_removed(struct udev_device *udev_device, struct udev_input *input)
+{
+ const char *devnode;
+ struct evdev_device *device, *next;
+ struct udev_seat *seat;
+
+ devnode = udev_device_get_devnode(udev_device);
+ list_for_each(seat, input-base.seat_list, base.link) {
+ list_for_each_safe(device, next,
+ seat-base.devices_list, base.link)
+ if (!strcmp(device-devnode, devnode)) {
+ log_info(input device %s, %s removed\n,
+ device-devname,
device-devnode);
+ evdev_device_remove(device);
+ break;
+ }
+ }
+}
+
static int
udev_input_add_devices(struct udev_input *input, struct udev *udev)
{
@@ -155,10 +175,7 @@ evdev_udev_handler(void *data)
{
struct udev_input *input = data;
struct udev_device *udev_device;
- struct evdev_device *device, *next;
const char *action;
- const char *devnode;
- struct udev_seat *seat;
udev_device = udev_monitor_receive_device(input-udev_monitor);
if (!udev_device)
@@ -171,22 +188,10 @@ evdev_udev_handler(void *data)
if (strncmp(event, udev_device_get_sysname(udev_device), 5) != 0)
goto out;
- if (!strcmp(action, add)) {
+ if (!strcmp(action, add))
device_added(udev_device, input);
- }
- else if (!strcmp(action, remove)) {
- devnode = udev_device_get_devnode(udev_device);
- list_for_each(seat, input-base.seat_list, base.link) {
- list_for_each_safe(device, next,
- seat-base.devices_list, base.link)
- if (!strcmp(device-devnode, devnode)) {
- log_info(input device %s, %s
removed\n,
-device-devname,
device-devnode);
- evdev_device_remove(device);
- break;
- }
- }
- }
+ else if (!strcmp(action, remove))
+ device_removed(udev_device, input);
out:
udev_device_unref(udev_device);
--
1.8.5.3
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC PATCH libinput] udev: add libinput_udev_rescan_devices()
So you're saying that every time we're suspended, we simply throw out the
entire context and drop all the devices on the floor, as if you just
unplugged all of them?
I suppose I just never thought of that. On first though, I don't see
anything wrong with that.
If that's what we should do, should we remove libinput_suspend /
libinput_resume then?
On Mon, Mar 17, 2014 at 11:21 PM, Peter Hutterer
peter.hutte...@who-t.netwrote:
On Sat, Mar 15, 2014 at 07:59:29PM +0100, Jonas Ådahl wrote:
On Thu, Mar 13, 2014 at 04:18:20PM +1000, Peter Hutterer wrote:
When a libinput context for a given seat is initialized, not all
devices may
be available. Some or all devices may be paused by systemd-logind.
Waiting for
a unplug event is not appropriate here as the devices are physically
available, just prevented from getting access.
Add a libinput_udev_rescan_devices() function that triggers a scan of
all
devices on the current udev seat. Devices that do not exist on the
seat are
added, devices that already exist on the seat but have been revoked are
removed.
Note that devices that have been physically removed are not removed,
instead
we wait for the udev event to handle this for us.
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
The idea here is basically to start a udev context as usual. If the
compositor doesn't have the session, open_restricted will fail. Once
the
ResumeDevice signals are handled by the compositor it can ask libinput
to
rescan the device list to add the ones that failed before (or remove
revoked
ones).
Notes on why this approach:
* libinput_device_suspend()/resume() seems nicer at first but if a
device
fails to open, we don't have a libinput_device context. handling that
would make the API complicated since we cannot guarantee that all
libinput_device_* functions (specificall has_capability) work on all
devices anymore.
* I suspect in the 90% case the the PauseDevice/ResumeDevice signals
come in
in a batch anyway, so the compositor should be able to optimise this
to
one single call
* this is a udev specific call, for the path backend the compositor
can and
should maintain the devices manually anyway
* EVIOCGVERSION was picked because it always succeeds, except after
revoke
This is an RFC at this point, let me know if that approach works.
Still need
to write tests and better evdev duplicate detection - right now there
is a
race condition that could remove the wrong device.
Hi,
So what this patch is trying to solve is handling the following flow:
* create libinput udev context
- some or all devices will fail to open due to being paused
* devices are resumed
What stops us from simply doing
* devices are resumed
* create libinput udev context
Jasper? you can answer that better than me
As you say, a compositor should be able to know when it should rescan,
and in most cases (?) before this, we won't get a single device anyway
so whats the point of creating earlier than that? For resuming after
session switch I suppose we'd have the same problem, but this would then
just work the same:
* devices are resumed
* resume libinput context
the question here is: is there a use-case for a single device to be
paused/resumed outside of the usual process? David?
We're struggling with this in X but that's caused by a completely different
problem and is rather orthogonal to this.
Cheers,
Peter
src/evdev.c | 15 +++
src/evdev.h | 2 ++
src/libinput.h | 21 +
src/udev-seat.c | 46 +-
4 files changed, 79 insertions(+), 5 deletions(-)
diff --git a/src/evdev.c b/src/evdev.c
index ba7c8b3..018fbb1 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -790,3 +790,18 @@ evdev_device_destroy(struct evdev_device *device)
free(device-sysname);
free(device);
}
+
+int
+evdev_device_is_alive(struct evdev_device *device)
+{
+ int rc;
+ int version;
+
+ rc = ioctl(device-fd, EVIOCGVERSION, version);
+
+ if (rc 0 errno != ENODEV)
+ log_info(evdev: %s failed with errno %d (%s)\n,
+__func__, errno, strerror(errno));
+
+ return rc != -1;
+}
diff --git a/src/evdev.h b/src/evdev.h
index b83a2f9..82a3873 100644
--- a/src/evdev.h
+++ b/src/evdev.h
@@ -156,4 +156,6 @@ evdev_device_remove(struct evdev_device *device);
void
evdev_device_destroy(struct evdev_device *device);
+int
+evdev_device_is_alive(struct evdev_device *device);
#endif /* EVDEV_H */
diff --git a/src/libinput.h b/src/libinput.h
index 3e09871..dadcac2 100644
--- a/src/libinput.h
+++ b/src/libinput.h
@@ -715,6 +715,27 @@ libinput_udev_create_for_seat(const struct
libinput_interface *interface,
/**
Re: [RFC PATCH libinput] udev: add libinput_udev_rescan_devices()
On Fri, Mar 21, 2014 at 12:27:45AM -0400, Jasper St. Pierre wrote:
So you're saying that every time we're suspended, we simply throw out the
entire context and drop all the devices on the floor, as if you just
unplugged all of them?
fwiw, this is effectively what happens internally anyway, you get removed
events for every device on suspend, and added events on resume for those
still there.
I suppose I just never thought of that. On first though, I don't see
anything wrong with that.
If that's what we should do, should we remove libinput_suspend /
libinput_resume then?
libinput_suspend/resume only tear down the devices, but not anything
else. there isn't much global state that's kept across suspend/resume yet
(seats are one example though) but the biggest difference is that that you
can't use _any_ object around after libinput_destroy(). suspend/resume
keeps them alive until you unref them.
Cheers,
Peter
On Mon, Mar 17, 2014 at 11:21 PM, Peter Hutterer
peter.hutte...@who-t.netwrote:
On Sat, Mar 15, 2014 at 07:59:29PM +0100, Jonas Ådahl wrote:
On Thu, Mar 13, 2014 at 04:18:20PM +1000, Peter Hutterer wrote:
When a libinput context for a given seat is initialized, not all
devices may
be available. Some or all devices may be paused by systemd-logind.
Waiting for
a unplug event is not appropriate here as the devices are physically
available, just prevented from getting access.
Add a libinput_udev_rescan_devices() function that triggers a scan of
all
devices on the current udev seat. Devices that do not exist on the
seat are
added, devices that already exist on the seat but have been revoked are
removed.
Note that devices that have been physically removed are not removed,
instead
we wait for the udev event to handle this for us.
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
The idea here is basically to start a udev context as usual. If the
compositor doesn't have the session, open_restricted will fail. Once
the
ResumeDevice signals are handled by the compositor it can ask libinput
to
rescan the device list to add the ones that failed before (or remove
revoked
ones).
Notes on why this approach:
* libinput_device_suspend()/resume() seems nicer at first but if a
device
fails to open, we don't have a libinput_device context. handling that
would make the API complicated since we cannot guarantee that all
libinput_device_* functions (specificall has_capability) work on all
devices anymore.
* I suspect in the 90% case the the PauseDevice/ResumeDevice signals
come in
in a batch anyway, so the compositor should be able to optimise this
to
one single call
* this is a udev specific call, for the path backend the compositor
can and
should maintain the devices manually anyway
* EVIOCGVERSION was picked because it always succeeds, except after
revoke
This is an RFC at this point, let me know if that approach works.
Still need
to write tests and better evdev duplicate detection - right now there
is a
race condition that could remove the wrong device.
Hi,
So what this patch is trying to solve is handling the following flow:
* create libinput udev context
- some or all devices will fail to open due to being paused
* devices are resumed
What stops us from simply doing
* devices are resumed
* create libinput udev context
Jasper? you can answer that better than me
As you say, a compositor should be able to know when it should rescan,
and in most cases (?) before this, we won't get a single device anyway
so whats the point of creating earlier than that? For resuming after
session switch I suppose we'd have the same problem, but this would then
just work the same:
* devices are resumed
* resume libinput context
the question here is: is there a use-case for a single device to be
paused/resumed outside of the usual process? David?
We're struggling with this in X but that's caused by a completely different
problem and is rather orthogonal to this.
Cheers,
Peter
src/evdev.c | 15 +++
src/evdev.h | 2 ++
src/libinput.h | 21 +
src/udev-seat.c | 46 +-
4 files changed, 79 insertions(+), 5 deletions(-)
diff --git a/src/evdev.c b/src/evdev.c
index ba7c8b3..018fbb1 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -790,3 +790,18 @@ evdev_device_destroy(struct evdev_device *device)
free(device-sysname);
free(device);
}
+
+int
+evdev_device_is_alive(struct evdev_device *device)
+{
+ int rc;
+ int version;
+
+ rc = ioctl(device-fd, EVIOCGVERSION, version);
+
+ if (rc 0 errno != ENODEV)
+ log_info(evdev: %s failed
Re: [PATCH] compositor: Use weston_log rather than perror for error messages
On Wed, Mar 19, 2014 at 09:19:03AM +0200, Pekka Paalanen wrote:
On Wed, 19 Mar 2014 00:21:20 +0100
Hardening rdp.eff...@gmail.com wrote:
Le 18/03/2014 20:34, Bryce W. Harrington a écrit :
weston_log() seems to be the standard elsewhere in the codebase for
errors. These are the only two instances where perror() is used
instead, and their error messages aren't that informative anyway.
Signed-off-by: Bryce Harrington b.harring...@samsung.com
---
src/compositor-wayland.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/compositor-wayland.c b/src/compositor-wayland.c
index 238946b..83eb59c 100644
--- a/src/compositor-wayland.c
+++ b/src/compositor-wayland.c
@@ -211,13 +211,13 @@ wayland_output_get_shm_buffer(struct wayland_output
*output)
fd = os_create_anonymous_file(height * stride);
if (fd 0) {
- perror(os_create_anonymous_file);
+ weston_log(could not create an anonymous file buffer\n);
perror writes a human readable message, perhaps
weston_log(could not create an anonymous file buffer: %s\n,
strerror(error));
would be better ?
Yeah. FWIW, all of weston seems to use the glibc extension %m as a
shorthand.
Ah, sounds good. Thanks for the review, will respin the patch directly.
Bryce
Thanks,
pq
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH] compositor: Use weston_log rather than perror for error messages
weston_log() seems to be the standard elsewhere in the codebase for
errors. These are the only two instances where perror() is used
instead, and their error messages aren't that informative anyway.
Signed-off-by: Bryce Harrington b.harring...@samsung.com
---
src/compositor-wayland.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/compositor-wayland.c b/src/compositor-wayland.c
index 238946b..0f67419 100644
--- a/src/compositor-wayland.c
+++ b/src/compositor-wayland.c
@@ -211,13 +211,13 @@ wayland_output_get_shm_buffer(struct wayland_output
*output)
fd = os_create_anonymous_file(height * stride);
if (fd 0) {
- perror(os_create_anonymous_file);
+ weston_log(could not create an anonymous file buffer: %m\n);
return NULL;
}
data = mmap(NULL, height * stride, PROT_READ | PROT_WRITE, MAP_SHARED,
fd, 0);
if (data == MAP_FAILED) {
- perror(mmap);
+ weston_log(could not mmap %d memory for data: %m\n, height *
stride);
close(fd);
return NULL;
}
--
1.7.9.5
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
