Re: Protocol (scanner) proposals
On Sat, 2 Aug 2014 15:07:19 +0200 Auke Booij a...@tulcod.com wrote: On 30 July 2014 20:27, Pekka Paalanen ppaala...@gmail.com wrote: Actually no. Binding writers are expected to write their own code generator for their language, like wayland-scanner is for C. You are expected to not use the static inline generated C functions. Okay, that makes some amount of sense. But in that case, that should be documented. It was, hidden in a small paragraph in the documentation... Instead the functions actually exported by the library are the ABI. I guess that this is convention in C? Maybe, but mostly for practical reasons. Static inlines are API, but they get compiled into the application using the library, so changing the library later cannot change what static inlines are. In that sense, the static inlines are not ABI. If you make an incompatible change in a static inline's call signature, all existing binaries will keep on working, which means that the library ABI did not change. But, you cannot recompile the applications without fixing them, which means the library API did change. Doing things with static inlines like done in libwayland-client means, that you can compile an application against a new libwayland-client, but still run it against an old libwayland-client, even if the old libwayland-client does not have all the protocol bits added to the new version. When e.g. bumping the version of a protocol interface when adding a request, the libwayland-client ABI does not change, but the API gets a new wrapper static inline function. That's pretty nice, because it allows to run application binaries even on older systems as long as the application can deal with older interface versions properly. It just means that there won't be any runtime linker issues with unresolved symbols. Note, that the above applies only to additions to the protocol XML specification. And even then, I'm not sure if it works for whole new interfaces, but it should work for extending existing interfaces. I would love to see documentation patches! Speaking of which, is there a reason the code samples don't show up correctly in the online documentation? Which code samples exactly? It is quite possible that the doc generator just messes something up. Not many developers have Publican installed, so fixing them is hard. Moving away from Publican would be nice, IMHO... Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] xdg-shell: Align surface life-time rules with that of wl_shell
On Mon, 21 Jul 2014 13:23:23 -0700
Jason Ekstrand ja...@jlekstrand.net wrote:
I think the way it's handled in subsurfaces allows you to create a
subsurface from a surface, delete the surface, and then re-use the surface
as something else. If I recall correctly, weston allows a fair amount of
surface re-use right now.
That said, I'm not opposed to not allowing it for xdg surfaces, but I do
think they should still have an explicit destructor.
Like I wrote in my recent blog post [1], not completely unrelated to
this discussion in irc, IIRC, I strongly suggest adding destructor
protocol unless you can prove that having destructor protocol is
actively harmful.
To decide what the destructor semantics are, if you already have
well-thought semantics for the no-destructor case, you can think
about what happens when the wl_surface gets destroyed, and make the
xdg_surface destructor work in a way that looks similar to the
client.
In irc, Jasper did raise a good question about what should happen
when the client destroys the xdg_shell object. The ping/pong
messages are(?) part of xdg_shell interface, not xdg_surface. In
that case my proposition was to make the behaviour the same as if
the client is not responding to pings at all. The client cannot
receive pings, so it cannot send pongs; therefore, assume the client
is unresponsive. Destroying xdg_shell while there are windows up is
something that a client should not do, so we just need a roughly
sane behaviour for a corner-case that should not normally be hit.
As for wl_surface re-use after destroying a role, I have found that
resetting a role to allow re-use is much easier and cleaner than
not to, in Weston code. That's why I've been silently advocating to
allow re-use, but at the same I don't really expect clients to use
that. Yes, conflicting... so I suppose I don't have a real strong
preference there. Removing a role loses all role-specific
information, so whether the wl_surface get re-used or re-created
does not make any difference.
But, we already do rely on re-use in some cases, I believe, like
for cursors. A wl_surface can be set as cursor, then lose the role,
and then be set again. We have to keep that working. However, that
is more of a Weston internal detail than something that is directly
apparent in a client.
Thanks,
pq
[1]
http://ppaalanen.blogspot.fi/2014/07/wayland-protocol-design-object-lifespan.html
On Mon, Jul 21, 2014 at 12:07 PM, Jasper St. Pierre jstpie...@mecheye.net
wrote:
Note that I fixed GTK+ to always create a new wl_surface and never reuse
it. I don't think it makes any sense to keep the wl_surface around in the
background. I certainly don't think it ever makes sense to destroy the
xdg_surface and then make it into an xdg_popup or similar.
The semantics of once a role of a wl_surface is established, it's locked
in is something I'm comfortable supporting if it makes compositor
implementations easier, since I don't think switching at runtime is a valid
use case.
We should probably keep around the destructor to prevent leaks, but I'm
not really sure what destroying the role would mean, though.
And whatever we choose, we should try to make it consistent with the
subsurface roles, too, so we don't have different semantics for those.
On Mon, Jul 21, 2014 at 2:14 PM, Sjoerd Simons
sjoerd.sim...@collabora.co.uk wrote:
On Mon, 2014-07-21 at 10:03 -0700, Jason Ekstrand wrote:
On Mon, Jul 21, 2014 at 1:47 AM, Sjoerd Simons
sjoerd.sim...@collabora.co.uk wrote:
Remove the explicit destroy method from xdg_surface and xdg_popup as
neither of them can be re-created after being destroyed. As a results
a
wl_surface gets into an odd sort of odd limbo state after a
xdg_{surface,popup}.destroy call where it not only no longer has an
xdg_{surface,popup} associated with it but where it's also not
possible
to re-created one.
This also happens to align the life-time rules of xdg_{surface,popup}
to
match those of wl_shell_surface, which is probably good for
consistency.
Sjoerd,
First of all, making xdg_shell consistent with wl_shell is a non-reason
for
doing anything. The objective to xdg_shell is to *replace* wl_shell so
they are going to have different symantics.
Ofcourse, but there is no reason to have different for the sake of being
different. And for clients that either are moving from wl_shell to
xdg_shell or what to implement both having similar semantics in places
where it makes sense shoudl make things easier :).
Second, regarding your original patch. I'm sorry that it never got
reviewed, but implementation details of desktop-shell are, again, not a
good driving force for xdg_shell. If weston's desktop-shell has
wl_shell_surface symantics too closely tied to xdg_shell, that's a bug
in
weston's desktop-shell, not a bug in xdg_shell.
This was never about the semantics implemented by
An status update of wayland-tracer - a wayland protocol dumper
Hi all, Previously I posted patches about wayland-tracer, a wire protocol dumper for wayland. It has turned into a self-contained project and a lot of development have taken place. Now, I'm happy to announce that XML parser and protocol analyzer has been added so it can produce a human-readable format similar to WAYLAND_DEBUG, making the tool practical to use. People who are interested can visit the repository on github: https://github.com/dboyan/wayland-tracer and feedbacks are welcomed. Regards, Boyan Ding ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: RFC : xdg_surface_present() look-and-feel and implementation
On Wed, 30 Jul 2014 00:00:37 +0200 Manuel Bachmann manuel.bachm...@open.eurogiciel.org wrote: Hi Jasper, Jason, Agreed. Especially if you start an application, but it's slow to start, and you have typed into the current window or have navigated away from it since, you should get a popup instead of the window immediately mapped. This is known as focus stealing prevention. Good point. I will work on this. Unfortunately, the protocol as Manuel mocked up doesn't have the event timestamp. This is required so we can track when the surface was intended to be presented. Have to get familiar with timestamps, looking for some useful code right now. No, timestamp at least is the wrong thing. We do not use timestamps in wayland for tracking actions, because they are easily faked. You cannot rely on the clock incrementing every time you need a new token, which means you cannot guarantee ordering always. You also cannot know how much the increment is from the previous. I completely agree with what Jason said to Jasper in IRC recently, that serials should be used instead. The compositor can bump the serial exactly when appropriate and there is no need for heuristics of how long is too long. Users can be fast or slow to get bored and switch apps. Whether you want to key off the input event serials or have a new one in xdg_shell, I cannot say. However, I have one thing to add. I'm not sure if serials are global. Are they? Should they be? Maybe not. We have an outstanding issue of how to tell the compositor when a client is launching another client. This requires the new client to identify itself somehow, so that the compositor knows this is caused by the old client. Focus stealing prevention needed something like this and maybe something else needed it, too, right? This will probably require defining a standard way to pass a token from the old client to the new client, so that the new client can identify to the compositor why it was being launched. Even if serials in xdg_shell were global, they would not be enough, because it cannot identify the source, the old client. It seems that the old client needs a way to ask the compositor to create a launch token (this can be associated with an xdg_shell serial if needed, and the serial does not need to be global), pass the launch token to the new client (via some standard env?), and the new client will pass the token to the compositor again. This creates a link for the old client launching the new client. Then you can do what is best. Does this make any sense, and did X11 already have something like this? I suppose getting the token could be associated with a launch notifier in the DE or what it is. What I wrote above is almost completely unrelated to the attention request, so the attention request might not need to take this into account at all. If the new client presents a current token, the attention request could simply be acted on by raising and activating the window. (Wait... which window?) That's just some of my mind flow, not a serious request you should do this. :-) Another question for Manuel: Does present() interact with the surface commit? Should it? Not in a way that I know of. From a compositor point of view, present() (when the user interacts to show) does only change the surface worskpace, stacking order, and focus. I doesn't trigger a commit, or at least it's unwanted. I think it can be compared to what happens when you cycle through windows with Mod-Tab and choose one. The only question I can think of there is, can a window demand attention if it is not mapped? Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: RFC : xdg_surface_present() look-and-feel and implementation
On Fri, 1 Aug 2014 17:08:14 +0200 Manuel Bachmann manuel.bachm...@open.eurogiciel.org wrote: Hello everybody, I just updated the repo today ( https://github.com/Tarnyko/weston-xdg_surface_present/commit/0aca29d4b6dbe10d5237aaf5f35f72d25db3ac30). The xdg_surface_present() request not accepts a timestamp (uint32_t type) as an additional parameter. If different of 0, and it is the first time the surface should be shown, the shell will check if a significant amount of time passed between this timestamp and the actual present() request, and it it did, will show a notification instead of directly mapping the surface. You can see a demo here (1st case immediate, 2nd case delayed) : https://www.youtube.com/watch?v=IDa2W_xMg10 The implementation is still pretty naive, but I will improve it with the following considerations : - if any of the application surfaces focused, or not ; - are we on the same workspace ; - etc. Interested in your feedback on the protocol definition especially. Like has already been said about the request name, I agree with the following points: - raise does not describe what it does - activate does not describe what it does, activate is already related to decorations state etc. whether the window is currently in focus or activated, I believe. And I add one: - present is confusing, because presenting means hitting the screen, and the term is heavily used in the future Presentation extension, which is on a lower level than shell. I think attention or some variation of it is perfect. A client or window is requesting attention... that describes exactly what it is about. request name=present description summary=map the surface in the current context Calling this request on a newly-created shell surface is mandatory to map it to the current graphical context. If the request is called more than once, the shell will send interactive GUI notifications, so the user can bring the surface back easily. /description arg name=serial type=uint summary=serial for advanced focus management, can be 0/ /request Judging from the discussion so far, I don't think should have anything to do with the client mapping the surface. The compositor can and should do focus stealing prevention always, and whether you send one more request or not is irrelevant, also for mapping. Isn't the mapping of a top-level window an implied request for attention? You didn't document what the serial really is, where do you get one, how it is used, or what it causes, and what special meaning does 0 have. Note, that we explicitly define serial to not be a timestamp in Wayland, they are two completely different concepts. Also, considering that a serial is not cross-client thing, what use cases would the serial here have? Could this request be used by a client to activate a top-level window B as a response to a user action in its window A? Would that be in or out of scope for this request? In the case of App1 launching App2 and using the launch-token protocol I sketched in the other email, App2's top-level window will already be implictly associated with App1 launching it. The question there is, do we need an explicit association? Like, if you can get a new serial from the launch-token in App2, you could activate already existing windows (the Kate use case) by passing that serial with attention request. Or activate several top-level windows, or just one top-level window that yet was not the first one created by App2. Anyway, these are just my ideas, and I don't know how much they make sense, because I don't know how these things work currently in X11. I just got the funny idea that launch-notification would be related here. Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: RFC : xdg_surface_present() look-and-feel and implementation
On Sun, Aug 3, 2014 at 6:27 AM, Pekka Paalanen ppaala...@gmail.com wrote: On Fri, 1 Aug 2014 17:08:14 +0200 Manuel Bachmann manuel.bachm...@open.eurogiciel.org wrote: Hello everybody, I just updated the repo today ( https://github.com/Tarnyko/weston-xdg_surface_present/commit/0aca29d4b6dbe10d5237aaf5f35f72d25db3ac30 ). The xdg_surface_present() request not accepts a timestamp (uint32_t type) as an additional parameter. If different of 0, and it is the first time the surface should be shown, the shell will check if a significant amount of time passed between this timestamp and the actual present() request, and it it did, will show a notification instead of directly mapping the surface. You can see a demo here (1st case immediate, 2nd case delayed) : https://www.youtube.com/watch?v=IDa2W_xMg10 The implementation is still pretty naive, but I will improve it with the following considerations : - if any of the application surfaces focused, or not ; - are we on the same workspace ; - etc. Interested in your feedback on the protocol definition especially. Like has already been said about the request name, I agree with the following points: - raise does not describe what it does - activate does not describe what it does, activate is already related to decorations state etc. whether the window is currently in focus or activated, I believe. And I add one: - present is confusing, because presenting means hitting the screen, and the term is heavily used in the future Presentation extension, which is on a lower level than shell. I think attention or some variation of it is perfect. A client or window is requesting attention... that describes exactly what it is about. I'm a bit concerned about attention, because toolkit authors usually have both a present this window and mark this window as needing attention API. Under X11, one maps to _NET_WM_ACTIVATE and the other maps to the _NET_WM_STATE_DEMANDS_ATTENTION flag. This request is the former, not the latter. If somebody IMs me, the taskbar button might blink, but it should never immediately raise and show the window. There's also on guarantee that this request will do focus-stealing or pay attention to the serial at all. For users that turn the behavior off, the window will simply pop up in front of them, and if app developers start using this as a non-obtrusive way of trying to gain attention, they will be disappointed. I don't want to bikeshed on the list though. I'll continue to brainstorm. request name=present description summary=map the surface in the current context Calling this request on a newly-created shell surface is mandatory to map it to the current graphical context. If the request is called more than once, the shell will send interactive GUI notifications, so the user can bring the surface back easily. /description arg name=serial type=uint summary=serial for advanced focus management, can be 0/ /request Judging from the discussion so far, I don't think should have anything to do with the client mapping the surface. The compositor can and should do focus stealing prevention always, and whether you send one more request or not is irrelevant, also for mapping. Isn't the mapping of a top-level window an implied request for attention? We currently don't have a serial or timestamp in get_xdg_surface to do focus-prevention stealing on, and I figured that that calling present made sense, since then we don't have the map on first commit semantics. Instead, now we have a request for show the window to the user. You didn't document what the serial really is, where do you get one, how it is used, or what it causes, and what special meaning does 0 have. Note, that we explicitly define serial to not be a timestamp in Wayland, they are two completely different concepts. Also, considering that a serial is not cross-client thing, what use cases would the serial here have? Could this request be used by a client to activate a top-level window B as a response to a user action in its window A? Would that be in or out of scope for this request? In the case of App1 launching App2 and using the launch-token protocol I sketched in the other email, App2's top-level window will already be implictly associated with App1 launching it. The question there is, do we need an explicit association? Like, if you can get a new serial from the launch-token in App2, you could activate already existing windows (the Kate use case) by passing that serial with attention request. Or activate several top-level windows, or just one top-level window that yet was not the first one created by App2. Anyway, these are just my ideas, and I don't know how much they make sense, because I don't know how these things work currently in X11. I just got the funny idea that launch-notification would be related here. On X11,
Re: RFC : xdg_surface_present() look-and-feel and implementation
On Sun, 3 Aug 2014 07:30:25 -0400 Jasper St. Pierre jstpie...@mecheye.net wrote: On Sun, Aug 3, 2014 at 6:27 AM, Pekka Paalanen ppaala...@gmail.com wrote: On Fri, 1 Aug 2014 17:08:14 +0200 Manuel Bachmann manuel.bachm...@open.eurogiciel.org wrote: Hello everybody, I just updated the repo today ( https://github.com/Tarnyko/weston-xdg_surface_present/commit/0aca29d4b6dbe10d5237aaf5f35f72d25db3ac30 ). The xdg_surface_present() request not accepts a timestamp (uint32_t type) as an additional parameter. If different of 0, and it is the first time the surface should be shown, the shell will check if a significant amount of time passed between this timestamp and the actual present() request, and it it did, will show a notification instead of directly mapping the surface. You can see a demo here (1st case immediate, 2nd case delayed) : https://www.youtube.com/watch?v=IDa2W_xMg10 The implementation is still pretty naive, but I will improve it with the following considerations : - if any of the application surfaces focused, or not ; - are we on the same workspace ; - etc. Interested in your feedback on the protocol definition especially. Like has already been said about the request name, I agree with the following points: - raise does not describe what it does - activate does not describe what it does, activate is already related to decorations state etc. whether the window is currently in focus or activated, I believe. And I add one: - present is confusing, because presenting means hitting the screen, and the term is heavily used in the future Presentation extension, which is on a lower level than shell. I think attention or some variation of it is perfect. A client or window is requesting attention... that describes exactly what it is about. I'm a bit concerned about attention, because toolkit authors usually have both a present this window and mark this window as needing attention API. Under X11, one maps to _NET_WM_ACTIVATE and the other maps to the _NET_WM_STATE_DEMANDS_ATTENTION flag. This request is the former, not the latter. If somebody IMs me, the taskbar button might blink, but it should never immediately raise and show the window. There's also on guarantee that this request will do focus-stealing or pay attention to the serial at all. For users that turn the behavior off, the window will simply pop up in front of them, and if app developers start using this as a non-obtrusive way of trying to gain attention, they will be disappointed. I don't want to bikeshed on the list though. I'll continue to brainstorm. Right, ACTIVATE vs. DEMANDS_ATTENTION. I assume these are two different things in X11, as the client can simply force its way. Present this window OTOH just means map this window, and I do not see an obvious reason why we would need that in the Wayland protocol, as we can do the same with the first wl_surface.commit that carries a wl_buffer. Sorry I haven't read everything, maybe you already explained somewhere why we need a map/show request? Do we have a way to hide, too? Note, that I imagine this is different to ACTIVATE, since in my mind activating means getting some input focus and maybe even raising to top. Quite likely I am just confused here on what you mean, I'm playing based on what the names sound like. On Wayland, we cannot have activate me now request, we can only have I would like to be activated because..., and OTOH we have the concept of demanding attention. What is the difference between demanding attention and wishing to be activated? I didn't see a difference, and so conflated the concepts. And which one was this xdg_surface_present supposed to be? Those two questions are my confusion here. If it is about ACTIVATE, call it something like activate then. request name=present description summary=map the surface in the current context Calling this request on a newly-created shell surface is mandatory to map it to the current graphical context. If the request is called more than once, the shell will send interactive GUI notifications, so the user can bring the surface back easily. /description arg name=serial type=uint summary=serial for advanced focus management, can be 0/ /request Judging from the discussion so far, I don't think should have anything to do with the client mapping the surface. The compositor can and should do focus stealing prevention always, and whether you send one more request or not is irrelevant, also for mapping. Isn't the mapping of a top-level window an implied request for attention? We currently don't have a serial or timestamp in get_xdg_surface to do focus-prevention stealing on, and I figured that that calling present made sense, since then we don't have the map on first commit semantics. Instead, now we
Re: RFC : xdg_surface_present() look-and-feel and implementation
On Sun, Aug 3, 2014 at 8:43 AM, Pekka Paalanen ppaala...@gmail.com wrote: On Sun, 3 Aug 2014 07:30:25 -0400 Jasper St. Pierre jstpie...@mecheye.net wrote: On Sun, Aug 3, 2014 at 6:27 AM, Pekka Paalanen ppaala...@gmail.com wrote: On Fri, 1 Aug 2014 17:08:14 +0200 Manuel Bachmann manuel.bachm...@open.eurogiciel.org wrote: Hello everybody, I just updated the repo today ( https://github.com/Tarnyko/weston-xdg_surface_present/commit/0aca29d4b6dbe10d5237aaf5f35f72d25db3ac30 ). The xdg_surface_present() request not accepts a timestamp (uint32_t type) as an additional parameter. If different of 0, and it is the first time the surface should be shown, the shell will check if a significant amount of time passed between this timestamp and the actual present() request, and it it did, will show a notification instead of directly mapping the surface. You can see a demo here (1st case immediate, 2nd case delayed) : https://www.youtube.com/watch?v=IDa2W_xMg10 The implementation is still pretty naive, but I will improve it with the following considerations : - if any of the application surfaces focused, or not ; - are we on the same workspace ; - etc. Interested in your feedback on the protocol definition especially. Like has already been said about the request name, I agree with the following points: - raise does not describe what it does - activate does not describe what it does, activate is already related to decorations state etc. whether the window is currently in focus or activated, I believe. And I add one: - present is confusing, because presenting means hitting the screen, and the term is heavily used in the future Presentation extension, which is on a lower level than shell. I think attention or some variation of it is perfect. A client or window is requesting attention... that describes exactly what it is about. I'm a bit concerned about attention, because toolkit authors usually have both a present this window and mark this window as needing attention API. Under X11, one maps to _NET_WM_ACTIVATE and the other maps to the _NET_WM_STATE_DEMANDS_ATTENTION flag. This request is the former, not the latter. If somebody IMs me, the taskbar button might blink, but it should never immediately raise and show the window. There's also on guarantee that this request will do focus-stealing or pay attention to the serial at all. For users that turn the behavior off, the window will simply pop up in front of them, and if app developers start using this as a non-obtrusive way of trying to gain attention, they will be disappointed. I don't want to bikeshed on the list though. I'll continue to brainstorm. Right, ACTIVATE vs. DEMANDS_ATTENTION. I assume these are two different things in X11, as the client can simply force its way. _NET_WM_ACTIVATE in X11 says please show this window to the user. It's used for instance if I have an IM open with a person, and then I click their name in the buddy list again. It will switch to that window. It's used when clicking on a link and having the web browser open a new tab in its existing window. Or when opening files in a new tab in gedit. There is an event timestamp passed along, and the window-manager will switch to it if it's new enough. There is no guarantee the window will be immediately raised and available. The window manager *might* decide to downgrade the request to saying the window wants attention. This is what mutter does if the event timestamp is too old. [0] Imagine I click on a link, Firefox takes a while to start up, and then I keep chatting with my friend. Instead of having Firefox steal the focus, the request is downgraded to a blinking taskbar icon or a notification, so my keystrokes now go to my friend instead of being interrupted mid-type. _NET_WM_STATE_DEMANDS_ATTENTION in X11 is a hint to say the window wants some attention. Feel free to show a notification, or blink the taskbar icon. It should never switch to the window. The proposed xdg_surface_present() extension is equivalent to _NET_WM_ACTIVATE. I am fine with calling it xdg_surface_activate(). https://git.gnome.org/browse/mutter/tree/src/core/window.c#n3389 Present this window OTOH just means map this window, and I do not see an obvious reason why we would need that in the Wayland protocol, as we can do the same with the first wl_surface.commit that carries a wl_buffer. Sorry I haven't read everything, maybe you already explained somewhere why we need a map/show request? Do we have a way to hide, too? Note, that I imagine this is different to ACTIVATE, since in my mind activating means getting some input focus and maybe even raising to top. Quite likely I am just confused here on what you mean, I'm playing based on what the names sound like. On Wayland, we cannot have activate me now
Re: Protocol (scanner) proposals
On 3 August 2014 09:08, Pekka Paalanen ppaala...@gmail.com wrote: It was, hidden in a small paragraph in the documentation... I have to apologize, you are right. I guess that this is convention in C? [...] Thanks for your perfectly clear explanation, that does clarify it a lot. Speaking of which, is there a reason the code samples don't show up correctly in the online documentation? Which code samples exactly? http://wayland.freedesktop.org/docs/html/chap-Library.html - wl_list - wl_display_prepare_read - wl_proxy_marshal (but this code sample doesn't seem to be in the current git source?) http://wayland.freedesktop.org/docs/html/sect-Library-Server.html - (again wl_list) - wl_listener ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Protocol (scanner) proposals
On Sun, 3 Aug 2014 17:07:44 +0200 Auke Booij a...@tulcod.com wrote: Speaking of which, is there a reason the code samples don't show up correctly in the online documentation? Which code samples exactly? http://wayland.freedesktop.org/docs/html/chap-Library.html - wl_list - wl_display_prepare_read - wl_proxy_marshal (but this code sample doesn't seem to be in the current git source?) http://wayland.freedesktop.org/docs/html/sect-Library-Server.html - (again wl_list) - wl_listener I looked at the first wl_list example, and that one is not marked up in the source at all, it's just written verbatim. Maybe there is some form of mark-up we could use, or maybe not, I am not familiar with the doc generators. Trying Doxygen mark-up could be worth it, if you can regenerate the docs. I don't know how Publican gets the text or if it can use the Doxygen formatting. Indeed, the docs could use not just writing more, but formatting too. Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: RFC : xdg_surface_present() look-and-feel and implementation
On Sun, 3 Aug 2014 09:23:06 -0400 Jasper St. Pierre jstpie...@mecheye.net wrote: On Sun, Aug 3, 2014 at 8:43 AM, Pekka Paalanen ppaala...@gmail.com wrote: On Sun, 3 Aug 2014 07:30:25 -0400 Jasper St. Pierre jstpie...@mecheye.net wrote: On Sun, Aug 3, 2014 at 6:27 AM, Pekka Paalanen ppaala...@gmail.com wrote: On Fri, 1 Aug 2014 17:08:14 +0200 Manuel Bachmann manuel.bachm...@open.eurogiciel.org wrote: Hello everybody, I just updated the repo today ( https://github.com/Tarnyko/weston-xdg_surface_present/commit/0aca29d4b6dbe10d5237aaf5f35f72d25db3ac30 ). The xdg_surface_present() request not accepts a timestamp (uint32_t type) as an additional parameter. If different of 0, and it is the first time the surface should be shown, the shell will check if a significant amount of time passed between this timestamp and the actual present() request, and it it did, will show a notification instead of directly mapping the surface. You can see a demo here (1st case immediate, 2nd case delayed) : https://www.youtube.com/watch?v=IDa2W_xMg10 The implementation is still pretty naive, but I will improve it with the following considerations : - if any of the application surfaces focused, or not ; - are we on the same workspace ; - etc. Interested in your feedback on the protocol definition especially. Like has already been said about the request name, I agree with the following points: - raise does not describe what it does - activate does not describe what it does, activate is already related to decorations state etc. whether the window is currently in focus or activated, I believe. And I add one: - present is confusing, because presenting means hitting the screen, and the term is heavily used in the future Presentation extension, which is on a lower level than shell. I think attention or some variation of it is perfect. A client or window is requesting attention... that describes exactly what it is about. I'm a bit concerned about attention, because toolkit authors usually have both a present this window and mark this window as needing attention API. Under X11, one maps to _NET_WM_ACTIVATE and the other maps to the _NET_WM_STATE_DEMANDS_ATTENTION flag. This request is the former, not the latter. If somebody IMs me, the taskbar button might blink, but it should never immediately raise and show the window. There's also on guarantee that this request will do focus-stealing or pay attention to the serial at all. For users that turn the behavior off, the window will simply pop up in front of them, and if app developers start using this as a non-obtrusive way of trying to gain attention, they will be disappointed. I don't want to bikeshed on the list though. I'll continue to brainstorm. Right, ACTIVATE vs. DEMANDS_ATTENTION. I assume these are two different things in X11, as the client can simply force its way. _NET_WM_ACTIVATE in X11 says please show this window to the user. It's used for instance if I have an IM open with a person, and then I click their name in the buddy list again. It will switch to that window. It's used when clicking on a link and having the web browser open a new tab in its existing window. Or when opening files in a new tab in gedit. There is an event timestamp passed along, and the window-manager will switch to it if it's new enough. There is no guarantee the window will be immediately raised and available. The window manager *might* decide to downgrade the request to saying the window wants attention. This is what mutter does if the event timestamp is too old. [0] Imagine I click on a link, Firefox takes a while to start up, and then I keep chatting with my friend. Instead of having Firefox steal the focus, the request is downgraded to a blinking taskbar icon or a notification, so my keystrokes now go to my friend instead of being interrupted mid-type. _NET_WM_STATE_DEMANDS_ATTENTION in X11 is a hint to say the window wants some attention. Feel free to show a notification, or blink the taskbar icon. It should never switch to the window. The proposed xdg_surface_present() extension is equivalent to _NET_WM_ACTIVATE. I am fine with calling it xdg_surface_activate(). https://git.gnome.org/browse/mutter/tree/src/core/window.c#n3389 Thank you for explaining the existing semantics. I'm still did completely understand, when you would want to give a needs attention notification, but still guarantee this will not switch to the window. I would think that not switching to the window would be the majority of the cases, and the switching would happen only if the client manages to pass exactly the right serial, which would mean that the need for attention was created by a direct user action right
Re: Protocol (scanner) proposals
On 30 July 2014 20:27, Pekka Paalanen ppaala...@gmail.com wrote: Actually no. Binding writers are expected to write their own code generator for their language, like wayland-scanner is for C. You are expected to not use the static inline generated C functions. All the static inline functions are not part of the... how was it defined, ABI? Inline functions obviously get compiled into the app, not exported by the library. what about the wl_interface structs? they are exposed by the wayland-*-protocol.h files, so presumably off-limits, but opaque structs otherwise (the definition in wayland-util.h is deprecated), so I can't create my own wl_interface structs. hence, what am I supposed to pass to wl_proxy_marshal_constructor ? ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] doc: Quell warnings about missing man3 directory before its been built
sorry about the delay, was on holidays. On Fri, Jul 25, 2014 at 04:30:41PM +0300, Pekka Paalanen wrote: On Mon, 21 Jul 2014 19:23:49 + Bryce W. Harrington b.harring...@samsung.com wrote: The shell command for dist_man3_MANS gets invoked several times during the make process but before the man pages have been generated, which causes the following warnings when running `make`: find: `man/man3': No such file or directory find: `man/man3': No such file or directory find: `man/man3': No such file or directory GENxml/client/index.xml Despite these error messages, the generated dist tarball contains the man3 pages as intended, both before and after this patch. $ make dist $ tar xxf wayland-1.5.90.tar.xz $ find wayland-1.5.90/doc/doxygen/man/man3 -name wl_*.3 | wc -l 85 Signed-off-by: Bryce Harrington b.harring...@samsung.com --- doc/doxygen/Makefile.am |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/doxygen/Makefile.am b/doc/doxygen/Makefile.am index de3b31f..83622af 100644 --- a/doc/doxygen/Makefile.am +++ b/doc/doxygen/Makefile.am @@ -20,7 +20,7 @@ scanned_src_files_server = \ # find all man/man3/wl_foo.3 pages # for this to work, we need to create them before the man target (hence # all-local below) -dist_man3_MANS= $(shell find man/man3/ -name wl_*.3 -printf man/man3/%P\n) +dist_man3_MANS = $(shell test -d man find man/man3 -name wl_*.3 -printf man/man3/%P\n) xml/client/index.xml: $(scanned_src_files_client) wayland.doxygen $(AM_V_GEN)$(MKDIR_P) xml/client \ Yeah, I see it and there are lots of those during 'make distcheck', but I wonder, is this the right fix? Peter? I think it's the right fix. there may be some trickery to avoid all this but I haven't figured out what it is. Cheers, Peter Also, it seems this particular line really depends on the recursive make, as the first evaluation would not produce the intended value. Ah, so it was: 509d1d802abda4cec5a22fab5848787f92f69f02 Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH libinput] evdev: don't return a width/height if we faked the resolution
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
src/evdev.c | 7 ++-
src/evdev.h | 3 ++-
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/src/evdev.c b/src/evdev.c
index f980812..a125510 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -620,6 +620,7 @@ evdev_configure_device(struct evdev_device *device)
fixed = *absinfo;
fixed.resolution = 1;
libevdev_set_abs_info(evdev, ABS_X, fixed);
+ device-abs.fake_resolution = 1;
}
device-abs.absinfo_x = absinfo;
has_abs = 1;
@@ -629,6 +630,7 @@ evdev_configure_device(struct evdev_device *device)
fixed = *absinfo;
fixed.resolution = 1;
libevdev_set_abs_info(evdev, ABS_Y, fixed);
+ device-abs.fake_resolution = 1;
}
device-abs.absinfo_y = absinfo;
has_abs = 1;
@@ -645,6 +647,7 @@ evdev_configure_device(struct evdev_device *device)
libevdev_set_abs_info(evdev,
ABS_MT_POSITION_X,
fixed);
+ device-abs.fake_resolution = 1;
}
device-abs.absinfo_x = absinfo;
absinfo = libevdev_get_abs_info(evdev,
ABS_MT_POSITION_Y);
@@ -654,6 +657,7 @@ evdev_configure_device(struct evdev_device *device)
libevdev_set_abs_info(evdev,
ABS_MT_POSITION_Y,
fixed);
+ device-abs.fake_resolution = 1;
}
device-abs.absinfo_y = absinfo;
device-is_mt = 1;
@@ -908,7 +912,8 @@ evdev_device_get_size(struct evdev_device *device,
x = libevdev_get_abs_info(device-evdev, ABS_X);
y = libevdev_get_abs_info(device-evdev, ABS_Y);
- if (!x || !y || !x-resolution || !y-resolution)
+ if (!x || !y || device-abs.fake_resolution ||
+ !x-resolution || !y-resolution)
return -1;
*width = evdev_convert_to_mm(x, x-maximum);
diff --git a/src/evdev.h b/src/evdev.h
index fad1f84..a21b03e 100644
--- a/src/evdev.h
+++ b/src/evdev.h
@@ -67,8 +67,9 @@ struct evdev_device {
int fd;
struct {
const struct input_absinfo *absinfo_x, *absinfo_y;
+ int fake_resolution;
+
int32_t x, y;
-
int32_t seat_slot;
int apply_calibration;
--
1.9.3
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH libinput] evdev: Let dispatch instances set their own capabilities
On Sun, Jul 27, 2014 at 11:28:25PM +0200, Jonas Ådahl wrote:
It's up to a evdev device backend to configure seat capabilities it
supports. Even though it may be possible for a touchpad to have extra
keys, there is currently no support for sending keyboard events from the
touchpad driver, and if that would be implemented, it'd be a detail of
the touchpad driver, not the generic evdev device part.
Signed-off-by: Jonas Ådahl jad...@gmail.com
Reviewed-by: Peter Hutterer peter.hutte...@who-t.net
Cheers,
Peter
---
On Thu, Jul 17, 2014 at 02:25:18PM +1000, Peter Hutterer wrote:
On Wed, Jul 16, 2014 at 10:39:10PM +0200, Jonas Ådahl wrote:
The feature set configured otherwise would not work anyway as it
would need using the fallback dispatch to function.
Signed-off-by: Jonas Ådahl jad...@gmail.com
---
src/evdev.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/evdev.c b/src/evdev.c
index f980812..fec24f5 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -700,9 +700,11 @@ evdev_configure_device(struct evdev_device *device)
!libevdev_has_event_code(evdev, EV_KEY, BTN_TOOL_PEN)
(has_abs || has_mt)) {
device-dispatch = evdev_mt_touchpad_create(device);
+ device-seat_caps |= EVDEV_DEVICE_POINTER;
log_info(libinput,
input device '%s', %s is a touchpad\n,
device-devname, device-devnode);
+ return device-dispatch == NULL ? -1 : 0;
for something that is a touchpad with extra keys you're losing the keyboard
seat_cap here. same for touch, which iirc you can get for wireless receivers
where you may have more than one device multiplexed. which the touchpad code
probably won't handle yet anyway, but still.
That is more or less my point. I rewrote the patch a bit, making the
actual dispatch init function configure its own seat capabilities. If
we make the touchpad driver handle keyboard events, we should only
advertise such a capability when we actually know it will work.
Jonas
src/evdev-mt-touchpad.c | 2 ++
src/evdev.c | 1 +
2 files changed, 3 insertions(+)
diff --git a/src/evdev-mt-touchpad.c b/src/evdev-mt-touchpad.c
index b58a6ca..d831b83 100644
--- a/src/evdev-mt-touchpad.c
+++ b/src/evdev-mt-touchpad.c
@@ -824,6 +824,8 @@ tp_init(struct tp_dispatch *tp,
if (tp_init_palmdetect(tp, device) != 0)
return -1;
+ device-seat_caps |= EVDEV_DEVICE_POINTER;
+
return 0;
}
diff --git a/src/evdev.c b/src/evdev.c
index f980812..aa4cfae 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -703,6 +703,7 @@ evdev_configure_device(struct evdev_device *device)
log_info(libinput,
input device '%s', %s is a touchpad\n,
device-devname, device-devnode);
+ return device-dispatch == NULL ? -1 : 0;
}
for (i = KEY_ESC; i KEY_MAX; i++) {
if (i = BTN_MISC i KEY_OK)
--
1.8.5.1
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH libinput] test: Use only one test device for some udev and path tests
On Sun, Jul 27, 2014 at 11:28:26PM +0200, Jonas Ådahl wrote:
Some tests in test/path.c and test/udev.c are not dependent on
device behaviour but rather managing of device lifetime etc. Run those
tests only once with only one device, resulting more or less the same
code coverage but shorter run time.
Signed-off-by: Jonas Ådahl jad...@gmail.com
---
hmm, I think instead of litest_add_once which is pretty much unpredictable
maybe just add a litest_add_for_device() call where you can pass the enum
litest_device_type in. That way you get the same benefits as your patch
here, with the benefit of knowing which device the test runs for on any
given system.
so instad of
litest_add_once(udev:suspend, udev_double_suspend, LITEST_ANY,
LITEST_ANY);
you have
litest_add_for_device(udev:suspend, udev_double_suspend,
LITEST_SYNAPTICS_CLICKPAD);
Sure, works for me. Updated version of the patch:
replace all LITEST_CLICKPAD with LITEST_SYNAPTICS_CLICKPAD and then it's
Reviewed-by: Peter Hutterer peter.hutte...@who-t.net
the former is a feature flag, the latter is the actual device.
Cheers,
Peter
test/litest.c | 45 +++--
test/litest.h | 4
test/path.c | 13 +++--
test/udev.c | 15 ---
4 files changed, 54 insertions(+), 23 deletions(-)
diff --git a/test/litest.c b/test/litest.c
index deab0cf..946a0d7 100644
--- a/test/litest.c
+++ b/test/litest.c
@@ -179,11 +179,8 @@ litest_add_no_device(const char *name, void *func)
litest_add(name, func, LITEST_DISABLE_DEVICE, LITEST_DISABLE_DEVICE);
}
-void
-litest_add(const char *name,
-void *func,
-enum litest_device_feature required,
-enum litest_device_feature excluded)
+static struct suite *
+get_suite(const char *name)
{
struct suite *s;
@@ -191,10 +188,8 @@ litest_add(const char *name,
list_init(all_tests);
list_for_each(s, all_tests, node) {
- if (strcmp(s-name, name) == 0) {
- litest_add_tcase(s, func, required, excluded);
- return;
- }
+ if (strcmp(s-name, name) == 0)
+ return s;
}
s = zalloc(sizeof(*s));
@@ -203,7 +198,37 @@ litest_add(const char *name,
list_init(s-tests);
list_insert(all_tests, s-node);
- litest_add_tcase(s, func, required, excluded);
+
+ return s;
+}
+
+void
+litest_add(const char *name,
+void *func,
+enum litest_device_feature required,
+enum litest_device_feature excluded)
+{
+ litest_add_tcase(get_suite(name), func, required, excluded);
+}
+
+void
+litest_add_for_device(const char *name,
+ void *func,
+ enum litest_device_type type)
+{
+ struct suite *s;
+ struct litest_test_device **dev = devices;
+
+ s = get_suite(name);
+ while (*dev) {
+ if ((*dev)-type == type) {
+ litest_add_tcase_for_device(s, func, *dev);
+ return;
+ }
+ dev++;
+ }
+
+ ck_abort_msg(Invalid test device type);
}
static int
diff --git a/test/litest.h b/test/litest.h
index 9a9d10a..c0035d3 100644
--- a/test/litest.h
+++ b/test/litest.h
@@ -76,6 +76,10 @@ struct libinput *litest_create_context(void);
void litest_add(const char *name, void *func,
enum litest_device_feature required_feature,
enum litest_device_feature excluded_feature);
+void
+litest_add_for_device(const char *name,
+ void *func,
+ enum litest_device_type type);
void litest_add_no_device(const char *name, void *func);
int litest_run(int argc, char **argv);
diff --git a/test/path.c b/test/path.c
index 475e125..f6f6b84 100644
--- a/test/path.c
+++ b/test/path.c
@@ -793,8 +793,9 @@ START_TEST(path_seat_recycle)
}
END_TEST
-int main (int argc, char **argv) {
-
+int
+main(int argc, char **argv)
+{
litest_add_no_device(path:create, path_create_NULL);
litest_add_no_device(path:create, path_create_invalid);
litest_add_no_device(path:create, path_create_destroy);
@@ -804,13 +805,13 @@ int main (int argc, char **argv) {
litest_add_no_device(path:suspend, path_add_device_suspend_resume);
litest_add_no_device(path:suspend,
path_add_device_suspend_resume_fail);
litest_add_no_device(path:suspend,
path_add_device_suspend_resume_remove_device);
- litest_add(path:seat events, path_added_seat, LITEST_ANY, LITEST_ANY);
+ litest_add_for_device(path:seat events, path_added_seat,
LITEST_CLICKPAD);
litest_add(path:device events, path_added_device, LITEST_ANY,
LITEST_ANY);
litest_add(path:device events, path_device_sysname, LITEST_ANY,
LITEST_ANY);
- litest_add(path:device events, path_add_device,
Re: [PATCH libinput 1/4] evdev: Ignore key/button release events if key was never pressed
On Sun, Jul 27, 2014 at 11:28:28PM +0200, Jonas Ådahl wrote:
The kernel may send a 'release' event without ever having sent a key
'pressed' event in case the key was pressed before libinput was
initiated. Ignore these events so that we always guarantee a release
event always comes after a pressed event for any given key or button.
Signed-off-by: Jonas Ådahl jad...@gmail.com
---
src/evdev.c | 33 -
src/evdev.h | 2 ++
src/libinput-util.h | 29 +
test/keyboard.c | 52
4 files changed, 115 insertions(+), 1 deletion(-)
diff --git a/src/evdev.c b/src/evdev.c
index 5872856..0f4874c 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -47,6 +47,18 @@ enum evdev_key_type {
EVDEV_KEY_TYPE_BUTTON,
};
+static void
+set_key_pressed(struct evdev_device *device, int code, int pressed)
+{
+ long_set_bit_state(device-key_mask, code, pressed);
+}
+
+static int
+is_key_pressed(struct evdev_device *device, int code)
+{
+ return long_bit_is_set(device-key_mask, code);
+}
+
I'd prefer for these to be is_key_down to avoid any ever-so-slight ambiguity
about whether pressed means currently down, pressed in the past, etc.
but if you want to leave it as-is, that's fine too.
void
evdev_device_led_update(struct evdev_device *device, enum libinput_led leds)
{
@@ -294,6 +306,8 @@ static inline void
evdev_process_key(struct evdev_device *device,
struct input_event *e, uint64_t time)
{
+ enum evdev_key_type type;
+
/* ignore kernel key repeat */
if (e-value == 2)
return;
@@ -306,7 +320,24 @@ evdev_process_key(struct evdev_device *device,
evdev_flush_pending_event(device, time);
- switch (get_key_type(e-code)) {
+ type = get_key_type(e-code);
+
+ /* Ignore key release events from the kernel for keys that libinput
+ * never got a pressed event for. */
+ if (e-value == 0) {
+ switch (type) {
+ case EVDEV_KEY_TYPE_NONE:
+ break;
+ case EVDEV_KEY_TYPE_KEY:
+ case EVDEV_KEY_TYPE_BUTTON:
+ if (!is_key_pressed(device, e-code))
+ return;
+ }
+ }
+
+ set_key_pressed(device, e-code, e-value);
+
+ switch (type) {
case EVDEV_KEY_TYPE_NONE:
break;
case EVDEV_KEY_TYPE_KEY:
diff --git a/src/evdev.h b/src/evdev.h
index fad1f84..f71d387 100644
--- a/src/evdev.h
+++ b/src/evdev.h
@@ -94,6 +94,8 @@ struct evdev_device {
struct {
struct motion_filter *filter;
} pointer;
+
+ unsigned long key_mask[NLONGS(KEY_CNT)];
};
#define EVDEV_UNHANDLED_DEVICE ((struct evdev_device *) 1)
diff --git a/src/libinput-util.h b/src/libinput-util.h
index c0235ef..2f1a1db 100644
--- a/src/libinput-util.h
+++ b/src/libinput-util.h
@@ -72,6 +72,8 @@ int list_empty(const struct list *list);
pos = tmp, \
tmp = container_of(pos-member.next, tmp, member))
+#define LONG_BITS (sizeof(long) * 8)
+#define NLONGS(x) (((x) + LONG_BITS - 1) / LONG_BITS)
#define ARRAY_LENGTH(a) (sizeof (a) / sizeof (a)[0])
#define ARRAY_FOR_EACH(_arr, _elem) \
for (size_t _i = 0; (_elem = _arr[_i]) _i ARRAY_LENGTH(_arr);
_i++)
@@ -150,4 +152,31 @@ vector_get_direction(int dx, int dy)
return dir;
}
+static inline int
+long_bit_is_set(const unsigned long *array, int bit)
+{
+return !!(array[bit / LONG_BITS] (1LL (bit % LONG_BITS)));
+}
+
+static inline void
+long_set_bit(unsigned long *array, int bit)
+{
+array[bit / LONG_BITS] |= (1LL (bit % LONG_BITS));
+}
+
+static inline void
+long_clear_bit(unsigned long *array, int bit)
+{
+array[bit / LONG_BITS] = ~(1LL (bit % LONG_BITS));
+}
+
+static inline void
+long_set_bit_state(unsigned long *array, int bit, int state)
+{
+ if (state)
+ long_set_bit(array, bit);
+ else
+ long_clear_bit(array, bit);
+}
+
#endif /* LIBINPUT_UTIL_H */
diff --git a/test/keyboard.c b/test/keyboard.c
index a55405c..a7f500c 100644
--- a/test/keyboard.c
+++ b/test/keyboard.c
@@ -112,10 +112,62 @@ START_TEST(keyboard_seat_key_count)
}
END_TEST
+START_TEST(keyboard_ignore_no_pressed_release)
+{
+ struct litest_device *dev;
+ struct libinput *libinput;
+ struct libinput_event *event;
+ struct libinput_event_keyboard *kevent;
+ int events[] = {
+ EV_KEY, KEY_A,
+ -1, -1,
+ };
+ enum libinput_key_state *state;
+ enum libinput_key_state expected_states[] = {
+ LIBINPUT_KEY_STATE_PRESSED,
+ LIBINPUT_KEY_STATE_RELEASED,
+ };
+
+
+ libinput = litest_create_context();
+ dev =
Re: [PATCH libinput 1/4] evdev: Ignore key/button release events if key was never pressed
On Mon, Jul 28, 2014 at 10:03:25AM -0700, Bill Spitzak wrote: On 07/27/2014 11:48 PM, Ran Benita wrote: Hi Jonas, On Sun, Jul 27, 2014 at 11:28:28PM +0200, Jonas Ådahl wrote: The kernel may send a 'release' event without ever having sent a key 'pressed' event in case the key was pressed before libinput was initiated. Ignore these events so that we always guarantee a release event always comes after a pressed event for any given key or button. Would it be possible to describe in the docs the invariants that libinput is keeping w.r.t. key press/release ordering and count? If the user can rely on such invariants, it can simplify how he interfaces with e.g. libxkbcommon, which expects a coherent key event stream (things like modifier press with a missed release can cause some fun). IMHO such invariants are a waste of time, and add complexity to each software layer for no benefit. strict, well-defined behaviour that maps the real world and expectations of the users and developers and guarantees no suprises is not a waste of time. Cheers, Peter The final consumer of the events either can easily handle mismatched pairs, or is forced to implement the map of currently-pressed events anyway (due to the client having it's own internal routing of events which also has to match pairs, such as when objects that receive events are created or deleted). So there is no reason to waste effort implementing these maps at every level since in effect the next level is not going to rely on them. I would prefer a count of the number of down buttons, which will allow a layer to re-sync it's map in many cases, even if events were mishandled by intermediate software layers. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH libinput 2/4] evdev: Keep track of button/key press count per device
On Sun, Jul 27, 2014 at 11:28:29PM +0200, Jonas Ådahl wrote:
Keep track of the number of times a given button or key is pressed on a
device. For regular mouse devices or keyboard devices, such a count will
never exceed 1, but counting button presses could help when button
presses with the same code can originate from different sources. One could
for example implement overlapping tap-drags with button presses by
having them deal with their own life-time independently, sorting out
when the user should receive button presses or not depending on the
pressed count.
Signed-off-by: Jonas Ådahl jad...@gmail.com
---
src/evdev-mt-touchpad-buttons.c | 30 +
src/evdev-mt-touchpad-tap.c | 8 +++
src/evdev.c | 49
+
src/evdev.h | 13 +++
4 files changed, 78 insertions(+), 22 deletions(-)
diff --git a/src/evdev-mt-touchpad-buttons.c b/src/evdev-mt-touchpad-buttons.c
index fe33d0b..8a28054 100644
--- a/src/evdev-mt-touchpad-buttons.c
+++ b/src/evdev-mt-touchpad-buttons.c
@@ -606,11 +606,12 @@ tp_post_clickfinger_buttons(struct tp_dispatch *tp,
uint64_t time)
state = LIBINPUT_BUTTON_STATE_RELEASED;
}
- if (button)
- pointer_notify_button(tp-device-base,
- time,
- button,
- state);
+ if (button) {
+ evdev_pointer_notify_button(tp-device,
+ time,
+ button,
+ state);
+ }
return 1;
}
@@ -632,10 +633,10 @@ tp_post_physical_buttons(struct tp_dispatch *tp,
uint64_t time)
else
state = LIBINPUT_BUTTON_STATE_RELEASED;
- pointer_notify_button(tp-device-base,
- time,
- button,
- state);
+ evdev_pointer_notify_button(tp-device,
+ time,
+ button,
+ state);
}
button++;
@@ -707,11 +708,12 @@ tp_post_softbutton_buttons(struct tp_dispatch *tp,
uint64_t time)
tp-buttons.click_pending = false;
- if (button)
- pointer_notify_button(tp-device-base,
- time,
- button,
- state);
+ if (button) {
+ evdev_pointer_notify_button(tp-device,
+ time,
+ button,
+ state);
+ }
return 1;
}
diff --git a/src/evdev-mt-touchpad-tap.c b/src/evdev-mt-touchpad-tap.c
index 6008507..64801a8 100644
--- a/src/evdev-mt-touchpad-tap.c
+++ b/src/evdev-mt-touchpad-tap.c
@@ -113,10 +113,10 @@ tp_tap_notify(struct tp_dispatch *tp,
return;
}
- pointer_notify_button(tp-device-base,
- time,
- button,
- state);
+ evdev_pointer_notify_button(tp-device,
+ time,
+ button,
+ state);
}
static void
diff --git a/src/evdev.c b/src/evdev.c
index 0f4874c..f656a5e 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -59,6 +59,47 @@ is_key_pressed(struct evdev_device *device, int code)
return long_bit_is_set(device-key_mask, code);
}
+static int
+update_key_pressed_count(struct evdev_device *device, int code, int pressed)
see my pressed vs down comment in the previous email, update if you
updated the other one
+{
+ assert(code = 0 code KEY_CNT);
+
+ if (pressed) {
+ return ++device-key_count[code];
want to add checks for == 255? or tbh, a log_bug for something like 32 or 64
seems a sensible thing to do too.
+ } else {
+ assert(device-key_count[code] 0);
+ return --device-key_count[code];
+ }
+}
+
+void
+evdev_keyboard_notify_key(struct evdev_device *device,
+ uint32_t time,
+ int key,
+ enum libinput_key_state state)
+{
+ int pressed_count;
+
+ pressed_count = update_key_pressed_count(device, key, state);
+
+ if ((state pressed_count == 1) || (!state pressed_count == 0))
please use the enum symbolic names LIBINPUT_KEY_STATE_PRESSED etc. for the
states.
+ keyboard_notify_key(device-base, time, key, state);
+}
+
+void
Re: [PATCH libinput 3/4] evdev: Release still pressed keys/buttons when removing device
On Sun, Jul 27, 2014 at 11:28:30PM +0200, Jonas Ådahl wrote:
When removing a device, its not guaranteed that all button or key
presses have been released, resulting in an invalid seat wide button
count.
Note that kernel devices normally will send release events when being
unplugged, but this won't happen when removing a device from the path
backend.
Signed-off-by: Jonas Ådahl jad...@gmail.com
---
src/evdev.c | 47 +++
test/keyboard.c | 116
test/pointer.c | 90 +++
3 files changed, 253 insertions(+)
diff --git a/src/evdev.c b/src/evdev.c
index f656a5e..ade7eec 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -60,6 +60,12 @@ is_key_pressed(struct evdev_device *device, int code)
}
static int
+get_key_pressed_count(struct evdev_device *device, int code)
here too: pressed vs down
+{
+ return device-key_count[code];
+}
do we still need is_key_pressed then? can we drop the mask?
+
+static int
update_key_pressed_count(struct evdev_device *device, int code, int pressed)
{
assert(code = 0 code KEY_CNT);
@@ -331,6 +337,45 @@ get_key_type(uint16_t code)
}
static void
+release_pressed_keys(struct evdev_device *device)
+{
+ struct libinput *libinput = device-base.seat-libinput;
+ struct timespec ts;
+ uint64_t time;
+ int code;
+
+ if (clock_gettime(CLOCK_MONOTONIC, ts) != 0) {
+ log_bug_libinput(libinput, clock_gettime: %s\n,
strerror(errno));
+ return;
+ }
+
+ time = ts.tv_sec * 1000ULL + ts.tv_nsec / 100;
+
+ for (code = 0; code KEY_CNT; code++) {
+ if (get_key_pressed_count(device, code) 0) {
+ switch (get_key_type(code)) {
+ case EVDEV_KEY_TYPE_NONE:
+ break;
+ case EVDEV_KEY_TYPE_KEY:
+ evdev_keyboard_notify_key(
+ device,
+ time,
+ code,
+ LIBINPUT_KEY_STATE_RELEASED);
+ break;
+ case EVDEV_KEY_TYPE_BUTTON:
+ evdev_pointer_notify_button(
+ device,
+ time,
+ code,
+ LIBINPUT_BUTTON_STATE_RELEASED);
+ break;
+ }
+ }
+ }
+}
+
+static void
evdev_process_touch_button(struct evdev_device *device,
uint64_t time, int value)
{
@@ -1008,6 +1053,8 @@ evdev_device_remove(struct evdev_device *device)
libinput_remove_source(device-base.seat-libinput,
device-source);
+ release_pressed_keys(device);
+
if (device-mtdev)
mtdev_close_delete(device-mtdev);
close_restricted(device-base.seat-libinput, device-fd);
diff --git a/test/keyboard.c b/test/keyboard.c
index a7f500c..dc9c4ea 100644
--- a/test/keyboard.c
+++ b/test/keyboard.c
@@ -25,6 +25,7 @@
#include check.h
#include stdio.h
+#include libinput-util.h
#include litest.h
START_TEST(keyboard_seat_key_count)
@@ -163,11 +164,126 @@ START_TEST(keyboard_ignore_no_pressed_release)
}
END_TEST
+static void
+test_key_event(struct litest_device *dev, unsigned int key, int state)
+{
+ struct libinput *li = dev-libinput;
+ struct libinput_event *event;
+ struct libinput_event_keyboard *kevent;
+
+ litest_event(dev, EV_KEY, key, state);
+ litest_event(dev, EV_SYN, SYN_REPORT, 0);
+
+ libinput_dispatch(li);
+
+ event = libinput_get_event(li);
+ ck_assert(event != NULL);
+ ck_assert_int_eq(libinput_event_get_type(event),
LIBINPUT_EVENT_KEYBOARD_KEY);
+
+ kevent = libinput_event_get_keyboard_event(event);
+ ck_assert(kevent != NULL);
+ ck_assert_int_eq(libinput_event_keyboard_get_key(kevent), key);
+ ck_assert_int_eq(libinput_event_keyboard_get_key_state(kevent),
+ state ? LIBINPUT_KEY_STATE_PRESSED :
+ LIBINPUT_KEY_STATE_RELEASED);
+ libinput_event_destroy(event);
+}
+
+START_TEST(keyboard_key_auto_release)
+{
+ struct libinput *libinput;
+ struct litest_device *dev;
+ struct libinput_event *event;
+ enum libinput_event_type type;
+ struct libinput_event_keyboard *kevent;
+ struct {
+ int code;
+ int released;
+ } keys[] = {
+ { .code = KEY_A, },
+ { .code = KEY_S, },
+ { .code = KEY_D, },
+ { .code = KEY_G, },
+ { .code = KEY_Z, },
+ { .code =
Re: [Freedreno] Freedreno Mesa with wayland support
Hi, The issue was in my wayland package. It wasn't compiles properly with scanner enabled. Compiled wayland with the scanner support and hence fixed my issue. Thanks for the support. Regards, Shrisha On Sat, Jul 12, 2014 at 12:37 AM, Jason Ekstrand ja...@jlekstrand.net wrote: On Fri, Jul 11, 2014 at 8:33 AM, Rob Clark robdcl...@gmail.com wrote: On Wed, Jul 9, 2014 at 5:10 AM, Shrisha shrish...@gmail.com wrote: Hi, I'm tyring to build Mesa with wayland support. Our Build system is yocto which is a linux based build system and we are using ARM based chipset. When I try to compile Mesa with Wayland enabled It throws me errors as below. | /bin/bash: code: command not found | /bin/bash: client-header: command not found | make[3]: *** [wayland-drm-protocol.c] Error 127 | make[3]: /bin/bash: server-header: command not found Shrisha, It looks like your translation from automake to yocto isn't correct. It shouldn't be trying to run client-header as a command. The correct command should like something like wayland-scanner client-header mything.xml file.h. Also, you need to make sure that wayland-scanner is properly build/installed in your system. If you're doing a cross-compile, you'll have to build it for the host architecture and make sure your build tool can find it. Hope that helps, --Jason Ekstrand Probably a better question for wayland list. I think this is related to the autogenerated protocol code. IIRC, when building wayland.git it should build the tools needed to generate the protocol code. But it has been a while since I've built wayland/weston from src, since these days everything I need is packaged in fedora ;-) :-) BR, -R Where can I get these code, server-header and client-header's? Please help. Regards, Shrisha ___ Freedreno mailing list freedr...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/freedreno ___ 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
