Re: [PATCH weston 00/17] Relative pointer motions, locking and confinement
On Tue, Dec 02, 2014 at 02:44:55PM +, Steven Newbury wrote:
On Tue, 2014-12-02 at 21:49 +0800, Jonas Ådahl wrote:
Hi again,
At XDC2014 some of us sat down and talked through how pointer locking
and related protocols should look like, and this series is more or
less
work-in-progress result of that discussion.
The series contains two parts (and one bonus patch). The bonus patch
is the initial white space only patch formatting the input method
protocols making it slightly more readable and consistent with other
protocol files.
The first part (2 - 12) is preparation for the implementation of the
new
interfaces.
The second part (13 - 17) is the introduction, implementation and
application of the new protocol interfaces.
Accompanied with this series is also a patch to libinput (Introduce
non-accelerated motion event vectors), and implementations in GLFW
https://github.com/jadahl/glfw/commits/pointer-lock and SDL2
https://bitbucket.org/jadahl/sdl/commits/branch/pointer-lock. In
I get You do no have access to this repository. from the bitbucket
repo.
Should be fixed now. Thanks for reporting.
Jonas
GLFW
you can try the wave example, and for SDL, you could try for example
ioquake3 or openarena.
One of the things we concluded was that relative pointer motions
should
be treated separately from locking and confinement, so of the second
part, patch 13 introduces the new relative pointer object that is
an
additional interface to the wl_pointer object. Think of it in the
same
way, as in you get it from a seat, and it emits motion events, only
ones
with relative motion deltas. One can create as many as one wants, and
they don't interfere with each other, just as wl_pointer. It might be
better to simply extend wl_seat when stabilizing this protocol, but
it's
put separately for testing purposes.
For details of how the protocol works, please read the protocol XML
file.
In short, locking and confinement are two locking modes, of which
one
may only be active at once. From the discussions, there is one
difference
I can think of and that is that locking/confining an already
locked/confined pointer is invalid, instead of queued, as it
simplified
the implementation quite a lot, and I think for most cases unlocking
and
then locking again will work good enough. For the cases where such a
scenario would break the lock and fail to relock, we could for
example
change the heuristics the compositor applies to get a better
behavior,
without making the interface more complex. Please tell if you think
queued locking is indeed needed.
One thing of the specification is currently not fully implemented as
there are some semantical choices that needs to be made and specified
before it makes sense to go forward, and that is how to deal with non
rectangular locking regions. The current implementation will simply
never
lock when the union of the input region and the locking region is a
non
rectangular region. The semantical ambiguity is how to treat motion
vectors that cross corners or other borders. Consider the following
ASCII art examples:
--- ---
| ^ | | ^ |
|\| |\|
| | |
| -- or| -
| \ | | \ |
|\ | |\ |
Simply clamping as done where there is no corners or anything would
be
result in:
--- ---
| | | |
| | | |
| | |
| -- or| -
| ^ || ^ |
|\ ||\ |
Should these kind of clamping take place or not, or should they be
done
some other way? Naturally, only clamping to a rectangle is the
simplest
non-ambiguous way to go and we could simply say that locking is to
the
largest rectangle within the union of the locking region and the
input
region, but as input regions can be split, we'd have to deal with
that
situation as well. Any ideas of the preferable way to deal with the
locking regions?
Jonas
Jonas Ådahl (17):
protocol: Improve formatting of input method and text protocols
input: Pass axis events through pointer grab interfaces
input: Make pointer grab motion callbacks take an event struct
desktop-shell: Add unset_keyboard_focus_for_surface helper
desktop-shell: Clean up set_minimized a bit
desktop-shell: Make activate_binding take a view instead of surface
desktop-shell: Track the black surface by its view
Re: [PATCH weston 00/17] Relative pointer motions, locking and confinement
On Tue, 2014-12-02 at 21:49 +0800, Jonas Ådahl wrote: Hi again, At XDC2014 some of us sat down and talked through how pointer locking and related protocols should look like, and this series is more or less work-in-progress result of that discussion. The series contains two parts (and one bonus patch). The bonus patch is the initial white space only patch formatting the input method protocols making it slightly more readable and consistent with other protocol files. The first part (2 - 12) is preparation for the implementation of the new interfaces. The second part (13 - 17) is the introduction, implementation and application of the new protocol interfaces. Accompanied with this series is also a patch to libinput (Introduce non-accelerated motion event vectors), and implementations in GLFW https://github.com/jadahl/glfw/commits/pointer-lock and SDL2 https://bitbucket.org/jadahl/sdl/commits/branch/pointer-lock. In I get You do no have access to this repository. from the bitbucket repo. GLFW you can try the wave example, and for SDL, you could try for example ioquake3 or openarena. One of the things we concluded was that relative pointer motions should be treated separately from locking and confinement, so of the second part, patch 13 introduces the new relative pointer object that is an additional interface to the wl_pointer object. Think of it in the same way, as in you get it from a seat, and it emits motion events, only ones with relative motion deltas. One can create as many as one wants, and they don't interfere with each other, just as wl_pointer. It might be better to simply extend wl_seat when stabilizing this protocol, but it's put separately for testing purposes. For details of how the protocol works, please read the protocol XML file. In short, locking and confinement are two locking modes, of which one may only be active at once. From the discussions, there is one difference I can think of and that is that locking/confining an already locked/confined pointer is invalid, instead of queued, as it simplified the implementation quite a lot, and I think for most cases unlocking and then locking again will work good enough. For the cases where such a scenario would break the lock and fail to relock, we could for example change the heuristics the compositor applies to get a better behavior, without making the interface more complex. Please tell if you think queued locking is indeed needed. One thing of the specification is currently not fully implemented as there are some semantical choices that needs to be made and specified before it makes sense to go forward, and that is how to deal with non rectangular locking regions. The current implementation will simply never lock when the union of the input region and the locking region is a non rectangular region. The semantical ambiguity is how to treat motion vectors that cross corners or other borders. Consider the following ASCII art examples: --- --- | ^ | | ^ | |\| |\| | | | | -- or| - | \ | | \ | |\ | |\ | Simply clamping as done where there is no corners or anything would be result in: --- --- | | | | | | | | | | | | -- or| - | ^ || ^ | |\ ||\ | Should these kind of clamping take place or not, or should they be done some other way? Naturally, only clamping to a rectangle is the simplest non-ambiguous way to go and we could simply say that locking is to the largest rectangle within the union of the locking region and the input region, but as input regions can be split, we'd have to deal with that situation as well. Any ideas of the preferable way to deal with the locking regions? Jonas Jonas Ådahl (17): protocol: Improve formatting of input method and text protocols input: Pass axis events through pointer grab interfaces input: Make pointer grab motion callbacks take an event struct desktop-shell: Add unset_keyboard_focus_for_surface helper desktop-shell: Clean up set_minimized a bit desktop-shell: Make activate_binding take a view instead of surface desktop-shell: Track the black surface by its view desktop-shell: Change switcher to track views desktop-shell: Make activate() take a view instead of surface desktop-shell: Pass a flag bitmask instead of bool to activate() compositor: Keep track of what views were activated by clicking
Re: [PATCH weston 00/17] Relative pointer motions, locking and confinement
On Tue, Dec 2, 2014 at 5:49 AM, Jonas Ådahl jad...@gmail.com wrote: Hi again, At XDC2014 some of us sat down and talked through how pointer locking and related protocols should look like, and this series is more or less work-in-progress result of that discussion. The series contains two parts (and one bonus patch). The bonus patch is the initial white space only patch formatting the input method protocols making it slightly more readable and consistent with other protocol files. The first part (2 - 12) is preparation for the implementation of the new interfaces. The second part (13 - 17) is the introduction, implementation and application of the new protocol interfaces. Accompanied with this series is also a patch to libinput (Introduce non-accelerated motion event vectors), and implementations in GLFW https://github.com/jadahl/glfw/commits/pointer-lock and SDL2 https://bitbucket.org/jadahl/sdl/commits/branch/pointer-lock. In GLFW you can try the wave example, and for SDL, you could try for example ioquake3 or openarena. One of the things we concluded was that relative pointer motions should be treated separately from locking and confinement, so of the second part, patch 13 introduces the new relative pointer object that is an additional interface to the wl_pointer object. Think of it in the same way, as in you get it from a seat, and it emits motion events, only ones with relative motion deltas. One can create as many as one wants, and they don't interfere with each other, just as wl_pointer. It might be better to simply extend wl_seat when stabilizing this protocol, but it's put separately for testing purposes. For details of how the protocol works, please read the protocol XML file. In short, locking and confinement are two locking modes, of which one may only be active at once. From the discussions, there is one difference I can think of and that is that locking/confining an already locked/confined pointer is invalid, instead of queued, as it simplified the implementation quite a lot, and I think for most cases unlocking and then locking again will work good enough. For the cases where such a scenario would break the lock and fail to relock, we could for example change the heuristics the compositor applies to get a better behavior, without making the interface more complex. Please tell if you think queued locking is indeed needed. Yeah, I think this is probably ok. And you're right that it simplifies things substantially. It should be easy enough for compositors to add a little heuristic to make it practical. Let's see how this goes and I think we can probably deal with it later if we want. One thing of the specification is currently not fully implemented as there are some semantical choices that needs to be made and specified before it makes sense to go forward, and that is how to deal with non rectangular locking regions. The current implementation will simply never lock when the union of the input region and the locking region is a non rectangular region. The semantical ambiguity is how to treat motion vectors that cross corners or other borders. Consider the following ASCII art examples: --- --- | ^ | | ^ | |\| |\| | | | | -- or| - | \ | | \ | |\ | |\ | Simply clamping as done where there is no corners or anything would be result in: --- --- | | | | | | | | | | | | -- or| - | ^ || ^ | |\ ||\ | Should these kind of clamping take place or not, or should they be done some other way? Naturally, only clamping to a rectangle is the simplest non-ambiguous way to go and we could simply say that locking is to the largest rectangle within the union of the locking region and the input region, but as input regions can be split, we'd have to deal with that situation as well. Any ideas of the preferable way to deal with the locking regions? First off, I don't think we want to specify this in the protocol. That would be insane. If the client wants it to be particularly predictable, it should use a rectangle. If the client gives a more complex region, It gets what it gets. However, we do need to restrict to the region (that's the point of a confinement) so we can't just take the extents. With that out of the way, I'm not sure what algorithm would be best to use. Basically what we're doing is collision detection and there several algorithms for doing that reasonably efficiently.
