[PATCH] doc: be explicit about requests not returning a value
From: Varad Gautam document how the asynchronous model works for requests and events to avoid any confusion. Signed-off-by: Varad Gautam Suggested-by: Pekka Paalanen --- doc/publican/sources/Protocol.xml | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/doc/publican/sources/Protocol.xml b/doc/publican/sources/Protocol.xml index ba6b5f1..b8c30fe 100644 --- a/doc/publican/sources/Protocol.xml +++ b/doc/publican/sources/Protocol.xml @@ -52,7 +52,12 @@ object ID and the event opcode, from which the client can determine the type of event. Events are generated both in response to requests (in which case the request and the event constitutes a round trip) or - spontaneously when the server state changes. + spontaneously when the server state changes. As the Wayland protocol + follows an asynchronous request model, there is no concept of + 'return value' for requests. A client can only receive information from + the server in the form of events. Hence, if a client cannot proceed + without getting some information from the server, it must invoke a + round trip by issuing a wl_display_roundtrip call. -- 2.10.0 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: wl_output ambiguity, xdg_shell fullscreen refresh rate
2017-05-15 (月) の 12:19 +0200 に Philipp Zabel さんは書きました: > On Mon, 2017-05-15 at 11:18 +0300, Pekka Paalanen wrote: > > On Sun, 14 May 2017 14:43:44 +0200 > > Philipp Kerling wrote: > > > * Am I correct in that if I use zxdg_toplevel (i.e. give this > > > role to > > > a surface), I cannot also use wl_shell_surface? If so, this > > > would be > > > > Yes. wl_shell and xdg_shell suites of protocol extensions are > > mutually > > exclusive, you cannot use both for the same wl_surface. wl_shell is > > the > > deprecated one, and xdg_shell suite is the replacement waiting to > > be > > decleared stable. > > > > > quite a problem. I can see that zxdg_toplevel functionality is > > > mostly superior to that of wl_shell_surface, but it has one > > > omission > > > that is crucial for Kodi: the ability to request a specific > > > refresh > > > rate for fullscreen display. This is needed for closely > > > matching the > > > display and video FPS so duplicated and skipped frames are > > > kept to a > > > minimum. Is this an intentional omission and/or is there > > > anything > > > that provides this functionality? > > > > Hopefully the xdg_shell designers would answer that, but I believe > > it > > has been omitted for now to make it easier to declare the first > > fundamental parts of xdg_shell stable. It is missing a lot, but the > > foundation must agreed upon first before building more on top. > > Rather than combining the FPS request with fullscreening, wouldn't it > be > better to let applications set FPS as a property of the surface? > > That way the client would make a promise that is is going to update > surface contents with periodic commits of the specified rate, > completely > independent of the actual output hardware or fullscreen state. > > The server could use that information to choose the best display > refresh > rate even if not in fullscreen mode. I would not want my compositor to do that, since changing the refresh rate means that the monitor will go blank for a while while resyncing on most hardware. Doing this on a regular basis would be very disturbing. Kodi can get away with it since * it only does it when starting to play a video, * it only does it in full-screen mode when nothing else is on the screen anyway, and * it has the option to wait a configurable amount of time before starting playback to ensure that the mode switch is complete. But I can see how this is the more general solution and also supports the video playback use case. If this operation would include a recommendation that the compositor should try to closely match the requested framerate of currently displayed full-screen surfaces to the vertical refresh rate of the corresponding output, I guess it would be fine. - Philipp ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: wl_output ambiguity, xdg_shell fullscreen refresh rate
Thanks for your answers! See reply below. 2017-05-15 (月) の 11:18 +0300 に Pekka Paalanen さんは書きました: > On Sun, 14 May 2017 14:43:44 +0200 > Philipp Kerling wrote: > > To start off: > > * Kodi should offer the user the opportunity to select inside the > > application on which monitor he/she wants to have Kodi displayed > > on > > when in full-screen mode. Now I see that I can do this with > > either > > wl_shell_surface::set_fullscreen and > > zxdg_toplevel::set_fullscreen, > > which expect a wl_output to display the window on. But I am not > > sure > > how I should match the wl_output instance I get from Wayland > > with > > the monitor that the user selected. As far as I can see, I can > > only > > identify the monitor by way of "make" and "model". This seems > > reasonable enough at first glance, but I think that in multi- > > monitor > > configurations it is not so uncommon to buy the same monitor > > model > > multiple times - I personally have done this. Naturally, the > > "make" > > and "model" of both monitors are identical, so I cannot discern > > which is which by looking at the wl_output metadata. Am I > > missing > > something here? > > That is all true, you are not missing anything. > > It is a missing piece of protocol - I believe no-one has had both the > need and the time to work on getting anything better yet. > > > Why isn't e.g. the connector the output is connected > > to exported? > > Because connector names are specific to DRM while Wayland (core > protocol at least) is not. I'm not sure I agree. See further below. > Also, would you not want to identify the > monitor rather than which connector it happens to be plugged in? I think that it's not quite decided yet what we want the user experience to be on the Kodi side, i.e. do we want to bind output to the physical monitor (however it is identified) or the GPU connector? You can probably find use cases for both, so it's not an easy decision to make. With X11 it was limited to the latter, so my first approach was to mimic that. Ideally, both would be possible with Wayland and the application can decide what is best for its specific use case. I realize that this might be too much to ask for all at once, so I'll talk to my mentor to decide which case we want to focus on for Kodi. There are also two different points involved in this discussion: I. How the *user* identifies which output/monitor the fullscreen display should be on (e.g. with make+model+connector name, or by compositor-specific numbering). II. How *Kodi* or any other application then stores this, re-identifies this output/monitor and maps it to a wl_output on application start and hotplug. Possiblities include saving information pertaining to the output, the connector, the physical device, or any combination. > Would > a user even know which connector name matches to which monitor? Yes, I also thought about this. Tech-savvy users might actually be able to identify the connector name, but you are absolutely right that usually users should not be expected to. In fact, having make and model available actually is an improvement in that regard (on X11, Kodi *only* displays connector since that is what's available via RANDR). So: How do you suggest to identify a particular monitor then? As I said, make and model are not sufficient - but serial number will not help the user in identification. If there are multiple monitors of the same model, I do not think that they (i.e. the physical devices) can be reasonably discerned in a way that is transparent to the user. That's why I suggested the connector name. > To expose such a name in the protocol, we should define the space or > meaning of the names. Human-readable? That's not the connector name, > IMHO. Machine-parseable? Needs a very strict definition to work. > Both? RANDR output names (which are somewhat close to what I refer to as connector names - it's a matter of debate whether output or connector name would be more fitting for the Kodi use case) are specifically meant to be "presented to the user", but I can see your point. I think that machine-parseable is doable, also considering that RANDR did have a "ConnectorType" property which is probably part of what we'd want here. > A simple numbering with a way in the compositor to identify the > monitors? Maybe. What exactly do you mean by "a way in the compositor to identify the monitors"? Like you can tell the compositor to display the output names (briefly) on the outputs so the user knows which is which? If so, couldn't this also be done by the application at least with more or less arbitrarily assigned numbers by mapping a surface to each known output that displays said number? I'm beginning to think that something along those lines might be one of the more user-friendly options of solving I. above. > > This would allow way better matching and also give the > > user a chance to select the
Re: [PATCH weston] libweston-desktop/xwayland: Make sure racy surfaces are properly mapped
On Mon, 15 May 2017 15:29:29 +0200
Quentin Glidic wrote:
> From: Quentin Glidic
>
> Signed-off-by: Quentin Glidic
> ---
> libweston-desktop/xwayland.c | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/libweston-desktop/xwayland.c b/libweston-desktop/xwayland.c
> index 4f4b453f..4dcb5f03 100644
> --- a/libweston-desktop/xwayland.c
> +++ b/libweston-desktop/xwayland.c
> @@ -61,6 +61,7 @@ struct weston_desktop_xwayland_surface {
> const struct weston_xwayland_client_interface *client_interface;
> struct weston_geometry next_geometry;
> bool has_next_geometry;
> + bool committed;
> bool added;
> enum weston_desktop_xwayland_surface_state state;
> };
> @@ -99,6 +100,14 @@ weston_desktop_xwayland_surface_change_state(struct
> weston_desktop_xwayland_surf
> weston_desktop_api_surface_added(surface->desktop,
>surface->surface);
> surface->added = true;
> + if (surface->state == NONE && surface->committed)
> + /* We had a race, and wl_surface.commit() was
> + * faster, just fake a commit to map the
> + * surface */
> + weston_desktop_api_committed(surface->desktop,
> + surface->surface,
> + 0, 0);
> +
> } else if (surface->added) {
> weston_desktop_api_surface_removed(surface->desktop,
> surface->surface);
> @@ -134,6 +143,7 @@ weston_desktop_xwayland_surface_committed(struct
> weston_desktop_surface *dsurfac
> struct weston_geometry oldgeom;
>
> assert(dsurface == surface->surface);
> + surface->committed = true;
>
> #ifdef WM_DEBUG
> weston_log("%s: xwayland surface %p\n", __func__, surface);
Hi Quentin,
thanks for making the patch so fast! It clarified my thoughts.
I wonder, could it become a problem to never unset 'committed'? In case
something causes XWM or Xwayland to "unmap" the surface and later map
again.
We'd want to check for "has content", and checking for a buffer is not
always right as the renderer may have made a copy and released the
buffer, so... weston_surface width and height > 0?
Calling weston_desktop_api_commit() sounds like the right solution.
Is surface->state reset back to NONE when the surface is unmapped? What
about !weston_surface_is_mapped()?
I feel I should explain more background for the bug we are trying to
fix here, as I have no reliable way to reproduce. Hopefully that
inspires a commit message. ;-)
The question is about a fundamental race between the Wayland and X11
protocol streams for XWM. Wayland carries the surface content, which is
latched in with wl_surface.commit that leads to calling into the shell
plugin to map the window. X11 carries the window management
information, essentially the shell role for the window/surface.
Obviously we cannot actually map a window until it has both content and
role.
So the race is between setting the content and setting the role. IIRC
e.g. xdg_shell simply forbids this race, requiring role to be set
first. Unfortunately with Xwayland I don't think we have the luxury of
that. There is the _XWAYLAND_ALLOW_COMMITS feature which could mitigate
the problem, but it is not yet in any xorg-xserver release, and we need
to be able to do without it.
The actual bug is, that if content is set first, setting the role does
not complete mapping the surface. As the surface is not mapped, the frame
callbacks are not sent, and Xwayland will never commit again. The
window is lost in an unmapped limbo.
At least, I believe we have that bug. Actually I am helping to fix this
bug on Weston 1.11 which is before the introduction of
libweston-desktop. I have had reports of this issue on 1.11, and when I
looked at the code in master, I believe the problem is still there, but
have not been able to reproduce it. Doesn't help that I'm generally
running with _XWAYLAND_ALLOW_COMMITS support too.
Thanks,
pq
pgptRaVFWTZCH.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC PATCH] xwm: Don't change focus on focus events from grabs
On Mon, 15 May 2017 15:26:45 +0100 Daniel Stone wrote: > Hi Olivier, > > On 15 May 2017 at 12:32, Olivier Fourdan wrote: > > xwm would not let X clients change the focus behind the compositor's > > back, reverting focus where it's supposed to be when this occurs. > > > > However, X11 grab also issue focus in events, on which some clients > > rely and reverting focus in this case braks the client logic (e.g. > > combobox menu in gtk+ using the X11 backend). > > > > Check if the focus event is actually coming from a grab or ungrab and > > do not revert focus in this case, to avoid breaking clients logic. > > Thanks for tracking this down! Similarly to Pekka, about the best I > can offer is: > Acked-by: Daniel Stone > > However, given the general paucity of understanding of XWM, I think > pushing with these two acks is fine if we wait a week or so. Hi, mind that I am about disappear for two weeks by the end of this week. Quentin gave his Acked-by in irc. Thanks, pq pgpyuuuSzt_c_.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC PATCH] xwm: Don't change focus on focus events from grabs
Hi Olivier, On 15 May 2017 at 12:32, Olivier Fourdan wrote: > xwm would not let X clients change the focus behind the compositor's > back, reverting focus where it's supposed to be when this occurs. > > However, X11 grab also issue focus in events, on which some clients > rely and reverting focus in this case braks the client logic (e.g. > combobox menu in gtk+ using the X11 backend). > > Check if the focus event is actually coming from a grab or ungrab and > do not revert focus in this case, to avoid breaking clients logic. Thanks for tracking this down! Similarly to Pekka, about the best I can offer is: Acked-by: Daniel Stone However, given the general paucity of understanding of XWM, I think pushing with these two acks is fine if we wait a week or so. Cheers, Daniel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Return values in Wayland XML specification
On Mon, 15 May 2017 14:22:32 +0100 adlo wrote: > > On 15 May 2017, at 08:46, Pekka Paalanen wrote: > > > > Yes, that is a good design suggestion. > > > > If the events are always sent only as a response to a request, then > > there is no need for a 'done' event. The client can send the request > > followed by wl_display.sync, and once the sync callback arrives, all > > responses have been received. > > > > But, if the server can spontaneously send a series of events, then you > > probably need a 'done' for the client to know when the series is > > complete again. > > What are events? Are they things that are sent by an interface or > received by it? > > How do you link the request with its corresponding response event? If > the client sends a get_window request, how does the server know how > to respond to it? Do they both need to be specified in the XML? Hi, how about you read through Chapter 4 in https://wayland.freedesktop.org/docs/html/ first, please? Thanks, pq pgp6cNcOt16fZ.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH weston] libweston-desktop/xwayland: Make sure racy surfaces are properly mapped
From: Quentin Glidic
Signed-off-by: Quentin Glidic
---
libweston-desktop/xwayland.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/libweston-desktop/xwayland.c b/libweston-desktop/xwayland.c
index 4f4b453f..4dcb5f03 100644
--- a/libweston-desktop/xwayland.c
+++ b/libweston-desktop/xwayland.c
@@ -61,6 +61,7 @@ struct weston_desktop_xwayland_surface {
const struct weston_xwayland_client_interface *client_interface;
struct weston_geometry next_geometry;
bool has_next_geometry;
+ bool committed;
bool added;
enum weston_desktop_xwayland_surface_state state;
};
@@ -99,6 +100,14 @@ weston_desktop_xwayland_surface_change_state(struct
weston_desktop_xwayland_surf
weston_desktop_api_surface_added(surface->desktop,
surface->surface);
surface->added = true;
+ if (surface->state == NONE && surface->committed)
+ /* We had a race, and wl_surface.commit() was
+* faster, just fake a commit to map the
+* surface */
+ weston_desktop_api_committed(surface->desktop,
+surface->surface,
+0, 0);
+
} else if (surface->added) {
weston_desktop_api_surface_removed(surface->desktop,
surface->surface);
@@ -134,6 +143,7 @@ weston_desktop_xwayland_surface_committed(struct
weston_desktop_surface *dsurfac
struct weston_geometry oldgeom;
assert(dsurface == surface->surface);
+ surface->committed = true;
#ifdef WM_DEBUG
weston_log("%s: xwayland surface %p\n", __func__, surface);
--
2.12.2
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Return values in Wayland XML specification
On 5/15/17 3:13 PM, adlo wrote: On 15 May 2017, at 10:52, Quentin Glidic wrote: If you are writing/porting a window switcher, please consider using Wayland Wall window-switcher protocol[1]. If you are not, please don’t, as this protocol is very specific to switchers (it has "switch_to" and "close" requests). If you need for more than this protocol offers, or something doesn’t fit your software, just fill an issue and we will discuss the possible designs. Does your protocol have window thumbnails and damage events for these thumbnails? How does your protocol compare to KDE's org_kde_plasma_windowmanagement? KDE protocol seems to be designed for window managers, not window switchers. My protocol does allow to display thumbnails, but everything is on the compositor side, the client just ask it to display them at a specific position of its own surface. I believe KDE’s protocol is too complex for simple compositors to use it easily. Cheers, -- Quentin “Sardem FF7” Glidic ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Return values in Wayland XML specification
> On 15 May 2017, at 08:46, Pekka Paalanen wrote: > > Yes, that is a good design suggestion. > > If the events are always sent only as a response to a request, then > there is no need for a 'done' event. The client can send the request > followed by wl_display.sync, and once the sync callback arrives, all > responses have been received. > > But, if the server can spontaneously send a series of events, then you > probably need a 'done' for the client to know when the series is > complete again. What are events? Are they things that are sent by an interface or received by it? How do you link the request with its corresponding response event? If the client sends a get_window request, how does the server know how to respond to it? Do they both need to be specified in the XML? Regards adlo ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Return values in Wayland XML specification
> On 15 May 2017, at 10:52, Quentin Glidic > wrote: > > If you are writing/porting a window switcher, please consider using Wayland > Wall window-switcher protocol[1]. If you are not, please don’t, as this > protocol is very specific to switchers (it has "switch_to" and "close" > requests). > If you need for more than this protocol offers, or something doesn’t fit your > software, just fill an issue and we will discuss the possible designs. Does your protocol have window thumbnails and damage events for these thumbnails? How does your protocol compare to KDE's org_kde_plasma_windowmanagement? Regards adlo ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC PATCH] xwm: Don't change focus on focus events from grabs
On Mon, 15 May 2017 13:32:01 +0200
Olivier Fourdan wrote:
> xwm would not let X clients change the focus behind the compositor's
> back, reverting focus where it's supposed to be when this occurs.
>
> However, X11 grab also issue focus in events, on which some clients
> rely and reverting focus in this case braks the client logic (e.g.
> combobox menu in gtk+ using the X11 backend).
>
> Check if the focus event is actually coming from a grab or ungrab and
> do not revert focus in this case, to avoid breaking clients logic.
>
> Signed-off-by: Olivier Fourdan
> ---
> xwayland/window-manager.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/xwayland/window-manager.c b/xwayland/window-manager.c
> index 2608075..2500853 100644
> --- a/xwayland/window-manager.c
> +++ b/xwayland/window-manager.c
> @@ -2055,6 +2055,12 @@ static void
> weston_wm_handle_focus_in(struct weston_wm *wm, xcb_generic_event_t *event)
> {
> xcb_focus_in_event_t *focus = (xcb_focus_in_event_t *) event;
> +
> + /* Do not interfere with grabs */
> + if (focus->mode == XCB_NOTIFY_MODE_GRAB ||
> + focus->mode == XCB_NOTIFY_MODE_UNGRAB)
> + return;
> +
> /* Do not let X clients change the focus behind the compositor's
>* back. Reset the focus to the old one if it changed. */
> if (!wm->focus_window || focus->event != wm->focus_window->id)
Hi,
unfortunately I don't understand enough X11 window management to give
an R-b, but I can give these:
Acked-by: Pekka Paalanen
Tested-by: Pekka Paalanen
This patch does fix gtk3-demo on Xwayland: the comboboxes demo and
context menus now work, where as before they would never get pointer
events.
Other things I tested that seem to at least not regress:
- xterm and menus
- dmenu
- geany: menus, context menus, tooltips
- gimp: toolboxes, menus
- kcachegrind (Qt4): tooltips, menus, context menus
I'd like to merge this patch very soon now.
Thanks,
pq
pgp_FXMJNoh6S.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[RFC PATCH] xwm: Don't change focus on focus events from grabs
xwm would not let X clients change the focus behind the compositor's
back, reverting focus where it's supposed to be when this occurs.
However, X11 grab also issue focus in events, on which some clients
rely and reverting focus in this case braks the client logic (e.g.
combobox menu in gtk+ using the X11 backend).
Check if the focus event is actually coming from a grab or ungrab and
do not revert focus in this case, to avoid breaking clients logic.
Signed-off-by: Olivier Fourdan
---
xwayland/window-manager.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/xwayland/window-manager.c b/xwayland/window-manager.c
index 2608075..2500853 100644
--- a/xwayland/window-manager.c
+++ b/xwayland/window-manager.c
@@ -2055,6 +2055,12 @@ static void
weston_wm_handle_focus_in(struct weston_wm *wm, xcb_generic_event_t *event)
{
xcb_focus_in_event_t *focus = (xcb_focus_in_event_t *) event;
+
+ /* Do not interfere with grabs */
+ if (focus->mode == XCB_NOTIFY_MODE_GRAB ||
+ focus->mode == XCB_NOTIFY_MODE_UNGRAB)
+ return;
+
/* Do not let X clients change the focus behind the compositor's
* back. Reset the focus to the old one if it changed. */
if (!wm->focus_window || focus->event != wm->focus_window->id)
--
2.9.3
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH libinput] util: harmonize container_of() definition with linux kernel one
commit 3925936 introduced changes to container_of, this is hopefully the
last part of it.
In the linux kernel, container_of() takes a type name, and not a
variable. Without this, in some cases it is needed to declare an unused
variable in order to call container_of().
example:
return container_of(dispatch, struct fallback_dispatch, base);
instead of:
struct fallback_dispatch *p;
return container_of(dispatch, p, base);
This introduce also list_first_entry(), a simple wrapper around
container_of() to retrieve the first element of a non empty list. It
allows to simplify list_for_each() and list_for_each_safe().
Signed-off-by: Gabriel Laskar
---
As they were no documentation for all the list functions/macros I did not add
one for list_first_entry(), if it is necessary, I will add them.
src/evdev-lid.c | 4 +---
src/evdev-mt-touchpad.h | 4 +---
src/evdev-tablet-pad.h | 4 +---
src/evdev-tablet.h | 4 +---
src/evdev.h | 8 ++--
src/libinput-util.h | 19 +++
6 files changed, 17 insertions(+), 26 deletions(-)
diff --git a/src/evdev-lid.c b/src/evdev-lid.c
index baf7185..9e694ba 100644
--- a/src/evdev-lid.c
+++ b/src/evdev-lid.c
@@ -44,11 +44,9 @@ struct lid_switch_dispatch {
static inline struct lid_switch_dispatch*
lid_dispatch(struct evdev_dispatch *dispatch)
{
- struct lid_switch_dispatch *l;
-
evdev_verify_dispatch_type(dispatch, DISPATCH_LID_SWITCH);
- return container_of(dispatch, l, base);
+ return container_of(dispatch, struct lid_switch_dispatch, base);
}
static void
diff --git a/src/evdev-mt-touchpad.h b/src/evdev-mt-touchpad.h
index 304e92f..ef0171d 100644
--- a/src/evdev-mt-touchpad.h
+++ b/src/evdev-mt-touchpad.h
@@ -391,11 +391,9 @@ struct tp_dispatch {
static inline struct tp_dispatch*
tp_dispatch(struct evdev_dispatch *dispatch)
{
- struct tp_dispatch *tp;
-
evdev_verify_dispatch_type(dispatch, DISPATCH_TOUCHPAD);
- return container_of(dispatch, tp, base);
+ return container_of(dispatch, struct tp_dispatch, base);
}
#define tp_for_each_touch(_tp, _t) \
diff --git a/src/evdev-tablet-pad.h b/src/evdev-tablet-pad.h
index 5569007..c80e144 100644
--- a/src/evdev-tablet-pad.h
+++ b/src/evdev-tablet-pad.h
@@ -73,11 +73,9 @@ struct pad_dispatch {
static inline struct pad_dispatch*
pad_dispatch(struct evdev_dispatch *dispatch)
{
- struct pad_dispatch *p;
-
evdev_verify_dispatch_type(dispatch, DISPATCH_TABLET_PAD);
- return container_of(dispatch, p, base);
+ return container_of(dispatch, struct pad_dispatch, base);
}
static inline struct libinput *
diff --git a/src/evdev-tablet.h b/src/evdev-tablet.h
index 43ed897..7d17e36 100644
--- a/src/evdev-tablet.h
+++ b/src/evdev-tablet.h
@@ -88,11 +88,9 @@ struct tablet_dispatch {
static inline struct tablet_dispatch*
tablet_dispatch(struct evdev_dispatch *dispatch)
{
- struct tablet_dispatch *t;
-
evdev_verify_dispatch_type(dispatch, DISPATCH_TABLET);
- return container_of(dispatch, t, base);
+ return container_of(dispatch, struct tablet_dispatch, base);
}
static inline enum libinput_tablet_tool_axis
diff --git a/src/evdev.h b/src/evdev.h
index c9a44f8..2bd58c1 100644
--- a/src/evdev.h
+++ b/src/evdev.h
@@ -247,9 +247,7 @@ struct evdev_device {
static inline struct evdev_device *
evdev_device(struct libinput_device *device)
{
- struct evdev_device *d;
-
- return container_of(device, d, base);
+ return container_of(device, struct evdev_device, base);
}
#define EVDEV_UNHANDLED_DEVICE ((struct evdev_device *) 1)
@@ -371,11 +369,9 @@ struct fallback_dispatch {
static inline struct fallback_dispatch*
fallback_dispatch(struct evdev_dispatch *dispatch)
{
- struct fallback_dispatch *f;
-
evdev_verify_dispatch_type(dispatch, DISPATCH_FALLBACK);
- return container_of(dispatch, f, base);
+ return container_of(dispatch, struct fallback_dispatch, base);
}
struct evdev_device *
diff --git a/src/libinput-util.h b/src/libinput-util.h
index 6d9bbe2..e34a500 100644
--- a/src/libinput-util.h
+++ b/src/libinput-util.h
@@ -86,22 +86,25 @@ void list_insert(struct list *list, struct list *elm);
void list_remove(struct list *elm);
bool list_empty(const struct list *list);
-#define container_of(ptr, sample, member) \
- (__typeof__(sample))((char *)(ptr) -\
-offsetof(__typeof__(*sample), member))
+#define container_of(ptr, type, member)
\
+ (__typeof__(type) *)((char *)(ptr) -\
+offsetof(__typeof__(type), member))
+
+#define list_first_entry(head, pos, member)\
+ container_of((head)->next, __typeof__(*pos), member)
#define list_for_each(pos, head, member) \
- for
Re: wl_output ambiguity, xdg_shell fullscreen refresh rate
On Mon, 15 May 2017 12:19:47 +0200 Philipp Zabel wrote: > On Mon, 2017-05-15 at 11:18 +0300, Pekka Paalanen wrote: > > On Sun, 14 May 2017 14:43:44 +0200 > > Philipp Kerling wrote: > > > > >quite a problem. I can see that zxdg_toplevel functionality is > > >mostly superior to that of wl_shell_surface, but it has one omission > > >that is crucial for Kodi: the ability to request a specific refresh > > >rate for fullscreen display. This is needed for closely matching the > > >display and video FPS so duplicated and skipped frames are kept to a > > >minimum. Is this an intentional omission and/or is there anything > > >that provides this functionality? > > > > Hopefully the xdg_shell designers would answer that, but I believe it > > has been omitted for now to make it easier to declare the first > > fundamental parts of xdg_shell stable. It is missing a lot, but the > > foundation must agreed upon first before building more on top. > > Rather than combining the FPS request with fullscreening, wouldn't it be > better to let applications set FPS as a property of the surface? > > That way the client would make a promise that is is going to update > surface contents with periodic commits of the specified rate, completely > independent of the actual output hardware or fullscreen state. > > The server could use that information to choose the best display refresh > rate even if not in fullscreen mode. Hi, that's a pretty good reason to not have it in the xdg_shell fullscreen request. ;-) There are lots of this kind of details to consider for every single feature added, which is why people tend to prefer not adding features to xdg_shell until the foundation is stabilized, I believe. Thanks, pq pgpztCj7G8gir.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: wl_output ambiguity, xdg_shell fullscreen refresh rate
On Mon, 2017-05-15 at 11:18 +0300, Pekka Paalanen wrote: > On Sun, 14 May 2017 14:43:44 +0200 > Philipp Kerling wrote: > > > Hi Wayland team and community, > > > > allow me to quickly introduce myself first, since this is my first post > > on this list. > > I'm Philipp, studying Computer Engineering and currently working on > > getting Wayland support (back) in Kodi as Google Summer of Code project > > [1] [2].I might have to ask some questions about specific aspects of > > Wayland over the next few months. I'll try not to be too annoying > > though :-) > > Please tell me if this is not the right place to ask this kind of stuff > > or if anything is unclear. > > Hi, > > you are exactly in the right place. :-) > > > To start off: > > * Kodi should offer the user the opportunity to select inside the > >application on which monitor he/she wants to have Kodi displayed on > >when in full-screen mode. Now I see that I can do this with either > >wl_shell_surface::set_fullscreen and zxdg_toplevel::set_fullscreen, > >which expect a wl_output to display the window on. But I am not sure > >how I should match the wl_output instance I get from Wayland with > >the monitor that the user selected. As far as I can see, I can only > >identify the monitor by way of "make" and "model". This seems > >reasonable enough at first glance, but I think that in multi-monitor > >configurations it is not so uncommon to buy the same monitor model > >multiple times - I personally have done this. Naturally, the "make" > >and "model" of both monitors are identical, so I cannot discern > >which is which by looking at the wl_output metadata. Am I missing > >something here? > > That is all true, you are not missing anything. > > It is a missing piece of protocol - I believe no-one has had both the > need and the time to work on getting anything better yet. > > > Why isn't e.g. the connector the output is connected > >to exported? > > Because connector names are specific to DRM while Wayland (core > protocol at least) is not. Also, would you not want to identify the > monitor rather than which connector it happens to be plugged in? Would > a user even know which connector name matches to which monitor? > > To expose such a name in the protocol, we should define the space or > meaning of the names. Human-readable? That's not the connector name, > IMHO. Machine-parseable? Needs a very strict definition to work. Both? > A simple numbering with a way in the compositor to identify the > monitors? Maybe. > > > This would allow way better matching and also give the > >user a chance to select the right monitor without having to try all > >options. Serial number (or anything similar - not sure if the EDID > >has this though) could also be OK. > > EDID may have a serial number, yes. > > Physical monitor devices are not the only things though. An output > could be just a window in another window system. An output could be at > the end of a streaming network connection. Etc. So aiming for a generic > solution here would have a really wide scope. > > However, there already is a unique numbering for wl_outputs, even > though it's not exactly user-friendly. It is the wl_output "name" > advertised by wl_registry, which you use in wl_registry.bind request to > create a wl_output instance. This "name" is the same for all clients. > > What we would really need is a new protocol extension designed to cater > for specific use cases and offering the additional information to help > make user-friendly UIs. Maybe compositors should a) number of the > outputs, and b) let the user give them arbitrary names to be shown in > application UIs? But then, do you tie the output identity to the > connector or the physical device? Or an intelligent mix? > > Would it be in scope for your work to design such an extension? It's > relatively easy to write a protocol proposal, but getting it reviewed > and hopefully ack'd by more than one DE project is often hard and time > consuming. And then you'd need to provide an implementation on at least > one compositor, unless you find someone else to collaborate with you. > > > * Am I correct in that if I use zxdg_toplevel (i.e. give this role to > >a surface), I cannot also use wl_shell_surface? If so, this would be > > Yes. wl_shell and xdg_shell suites of protocol extensions are mutually > exclusive, you cannot use both for the same wl_surface. wl_shell is the > deprecated one, and xdg_shell suite is the replacement waiting to be > decleared stable. > > >quite a problem. I can see that zxdg_toplevel functionality is > >mostly superior to that of wl_shell_surface, but it has one omission > >that is crucial for Kodi: the ability to request a specific refresh > >rate for fullscreen display. This is needed for closely matching the > >display and video FPS so duplicated and skipped frames are kept to a > >minimum. Is this an
Re: Return values in Wayland XML specification
On 5/15/17 9:46 AM, Pekka Paalanen wrote:
On Mon, 15 May 2017 07:05:26 +0200
Wojciech Kluczka wrote:
In Wayland array can contain only integers.
Hi,
not exactly. The data type inside an array is unspecified by the XML
language. You can use literally anything, it's just a binary blob with
a size, with some array-like helpers around.
The helpers are the ones that impose the most restrictions, which is
that each element in the "array" must be of the same size. But if you
never use wl_arrat_for_each(), even that is not strictly necessary.
Of course, one should use some common sense when defining (in
documentation!) what array contents are. Getting too creative with
array type arguments is probably not good.
See how listing of outputs is done. Server creates one global `wl_output`
per output, client binds to the global, server sends events with output
parameters (list of modes among them) and then event `done` to indicate it
stopped sending info about this output. You probably don't want one global
per window. I'd go with one global `window_manager` which sends events (one
per window) after bind and after creation of window (or on request,
depending on your needs).
Yes, that is a good design suggestion.
If the events are always sent only as a response to a request, then
there is no need for a 'done' event. The client can send the request
followed by wl_display.sync, and once the sync callback arrives, all
responses have been received.
But, if the server can spontaneously send a series of events, then you
probably need a 'done' for the client to know when the series is
complete again.
On Mon, 15 May 2017 04:05:43 +0100
adlo wrote:
For example, getting a list of windows and returning it as an array.
How would this be done? How are arrays represented in Wayland XML?
The above is one design.
I would perhaps not use an array to list windows, because when you get
to around a thousand simultaneous windows maybe, it's possible you
cannot send the event anymore. There are limits to how big one message
can be.
You also need to update the window list over time, which is much better
done by sending events just for new and removed windows, rather than
sending the whole list every time.
Also, if you need to transmit meta-data for each window, it might be
useful to write a protocol interface for a window, and create a
protocol object to represent each window. When the meta-data changes,
the server can send an event on that protocol object rather than a
tuple { window id, attribute }.
If you are writing/porting a window switcher, please consider using
Wayland Wall window-switcher protocol[1]. If you are not, please don’t,
as this protocol is very specific to switchers (it has "switch_to" and
"close" requests).
If you need for more than this protocol offers, or something doesn’t fit
your software, just fill an issue and we will discuss the possible designs.
Cheers,
[1]
--
Quentin “Sardem FF7” Glidic
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: wl_output ambiguity, xdg_shell fullscreen refresh rate
On Sun, 14 May 2017 14:43:44 +0200 Philipp Kerling wrote: > Hi Wayland team and community, > > allow me to quickly introduce myself first, since this is my first post > on this list. > I'm Philipp, studying Computer Engineering and currently working on > getting Wayland support (back) in Kodi as Google Summer of Code project > [1] [2].I might have to ask some questions about specific aspects of > Wayland over the next few months. I'll try not to be too annoying > though :-) > Please tell me if this is not the right place to ask this kind of stuff > or if anything is unclear. Hi, you are exactly in the right place. :-) > To start off: > * Kodi should offer the user the opportunity to select inside the >application on which monitor he/she wants to have Kodi displayed on >when in full-screen mode. Now I see that I can do this with either >wl_shell_surface::set_fullscreen and zxdg_toplevel::set_fullscreen, >which expect a wl_output to display the window on. But I am not sure >how I should match the wl_output instance I get from Wayland with >the monitor that the user selected. As far as I can see, I can only >identify the monitor by way of "make" and "model". This seems >reasonable enough at first glance, but I think that in multi-monitor >configurations it is not so uncommon to buy the same monitor model >multiple times - I personally have done this. Naturally, the "make" >and "model" of both monitors are identical, so I cannot discern >which is which by looking at the wl_output metadata. Am I missing >something here? That is all true, you are not missing anything. It is a missing piece of protocol - I believe no-one has had both the need and the time to work on getting anything better yet. > Why isn't e.g. the connector the output is connected >to exported? Because connector names are specific to DRM while Wayland (core protocol at least) is not. Also, would you not want to identify the monitor rather than which connector it happens to be plugged in? Would a user even know which connector name matches to which monitor? To expose such a name in the protocol, we should define the space or meaning of the names. Human-readable? That's not the connector name, IMHO. Machine-parseable? Needs a very strict definition to work. Both? A simple numbering with a way in the compositor to identify the monitors? Maybe. > This would allow way better matching and also give the >user a chance to select the right monitor without having to try all >options. Serial number (or anything similar - not sure if the EDID >has this though) could also be OK. EDID may have a serial number, yes. Physical monitor devices are not the only things though. An output could be just a window in another window system. An output could be at the end of a streaming network connection. Etc. So aiming for a generic solution here would have a really wide scope. However, there already is a unique numbering for wl_outputs, even though it's not exactly user-friendly. It is the wl_output "name" advertised by wl_registry, which you use in wl_registry.bind request to create a wl_output instance. This "name" is the same for all clients. What we would really need is a new protocol extension designed to cater for specific use cases and offering the additional information to help make user-friendly UIs. Maybe compositors should a) number of the outputs, and b) let the user give them arbitrary names to be shown in application UIs? But then, do you tie the output identity to the connector or the physical device? Or an intelligent mix? Would it be in scope for your work to design such an extension? It's relatively easy to write a protocol proposal, but getting it reviewed and hopefully ack'd by more than one DE project is often hard and time consuming. And then you'd need to provide an implementation on at least one compositor, unless you find someone else to collaborate with you. > * Am I correct in that if I use zxdg_toplevel (i.e. give this role to >a surface), I cannot also use wl_shell_surface? If so, this would be Yes. wl_shell and xdg_shell suites of protocol extensions are mutually exclusive, you cannot use both for the same wl_surface. wl_shell is the deprecated one, and xdg_shell suite is the replacement waiting to be decleared stable. >quite a problem. I can see that zxdg_toplevel functionality is >mostly superior to that of wl_shell_surface, but it has one omission >that is crucial for Kodi: the ability to request a specific refresh >rate for fullscreen display. This is needed for closely matching the >display and video FPS so duplicated and skipped frames are kept to a >minimum. Is this an intentional omission and/or is there anything >that provides this functionality? Hopefully the xdg_shell designers would answer that, but I believe it has been omitted for now to make it easier to declare the first fundamental parts of xdg_shell s
Re: Return values in Wayland XML specification
On Mon, 15 May 2017 07:05:26 +0200
Wojciech Kluczka wrote:
> In Wayland array can contain only integers.
Hi,
not exactly. The data type inside an array is unspecified by the XML
language. You can use literally anything, it's just a binary blob with
a size, with some array-like helpers around.
The helpers are the ones that impose the most restrictions, which is
that each element in the "array" must be of the same size. But if you
never use wl_arrat_for_each(), even that is not strictly necessary.
Of course, one should use some common sense when defining (in
documentation!) what array contents are. Getting too creative with
array type arguments is probably not good.
> See how listing of outputs is done. Server creates one global `wl_output`
> per output, client binds to the global, server sends events with output
> parameters (list of modes among them) and then event `done` to indicate it
> stopped sending info about this output. You probably don't want one global
> per window. I'd go with one global `window_manager` which sends events (one
> per window) after bind and after creation of window (or on request,
> depending on your needs).
Yes, that is a good design suggestion.
If the events are always sent only as a response to a request, then
there is no need for a 'done' event. The client can send the request
followed by wl_display.sync, and once the sync callback arrives, all
responses have been received.
But, if the server can spontaneously send a series of events, then you
probably need a 'done' for the client to know when the series is
complete again.
On Mon, 15 May 2017 04:05:43 +0100
adlo wrote:
> For example, getting a list of windows and returning it as an array.
> How would this be done? How are arrays represented in Wayland XML?
The above is one design.
I would perhaps not use an array to list windows, because when you get
to around a thousand simultaneous windows maybe, it's possible you
cannot send the event anymore. There are limits to how big one message
can be.
You also need to update the window list over time, which is much better
done by sending events just for new and removed windows, rather than
sending the whole list every time.
Also, if you need to transmit meta-data for each window, it might be
useful to write a protocol interface for a window, and create a
protocol object to represent each window. When the meta-data changes,
the server can send an event on that protocol object rather than a
tuple { window id, attribute }.
Thanks,
pq
pgpxkOBdv0Sbr.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
