<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 16, 2015 at 11:55 AM, Carlos Garnacho <span dir="ltr"><<a href="mailto:carlosg@gnome.org" target="_blank">carlosg@gnome.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">It's probably worth pointing out that his concerns are moot, there is<br>
no blinking, or rather, has an easy solution in compositors.<br>
<br>
When a tool physically enters in proximity over a surface, the cursor<br>
should be effectively invisible, the client below it will emit<br>
wp_tablet_tool.set_cursor in response to proximity_in, and it will be<br>
set accordingly from the previous invisible state. If the tool moves<br>
across surfaces, the cursor won't be modified until the new focus<br>
surface calls wp_tablet_tool.set_cursor, just like it happens with<br>
wl_pointer.set_cursor and wl_pointer.enter. When the tool physically<br>
leaves proximity, the cursor would be made invisible, destroyed, or<br>
whatnot.<br>
<br>
Compositors may of course want to set a default cursor if the<br>
proximity_in happened outside a surface, so that there's something<br>
visible until the tool enters a surface, but this is easy enough to<br>
detect before even showing the cursor. AFAICS the only source of<br>
"blinking" would be compositors invariably setting a visible cursor<br>
before the client has an opportunity to do so, that sounds somewhat<br>
sloppy though.<br></blockquote><div><br></div><div>I'm not sure why you think I am arguing for an old point, as Carlos describes exactly the same thing I am thinking of.<br><br>His proposal removes the need for there to be a per-tool cursor in the client api. The client only sets the cursor for the most recent tool, and the user can only see one cursor. IMHO this can be done in the easiest way by reusing the wl_pointer api, rather than adding new api that clients will just be forced to select between because only one of the api's works at any time.<br><br>He is proposing the "strong" version of what I said, which is that the cursor is actually frozen (not moving or changing) until a cursor-set is received from the client that has focus. If this is a good idea it probably should be done for normal pointer enter events as well. The benifit of this is that it obeys the "every frame is perfect" rule of Wayland.<br><br>I was assuming a "soft" version that works like the current pointer enter events, where the cursor does not change but follows the pointer without waiting for the client to set the image. The cursor image is thus a "guess" by the compositor. IMHO the best "guess" is to leave the cursor unchanged from whatever it is now, as this will reduce the number of transitions when the guess is wrong, and it is how enter events work currently. However a compositor could try to save a "guess" that tracks the cursor per-tool, per-surface, or even per tool+surface combination. None of that should be visible in the client api however.<br><br></div><div>Changing the cursor on proximity-in outside any client is an interesting problem. I think the compositor should be entirely in charge of this, though "guessing" that it is the same as the most-recent client, which seems to be the proposal here, may be reasonable. The compositor is still going to need an image to use if no client has gotten a proximity-in yet, so this does not remove the need for it to supply something without client help.<br><br></div><div>I also have no idea what you mean by this being a repeat of some mistake done by X11. I am not changing in any way what events are being received by the client compared to the current proposal, therefore if my idea is wrong, so is the current proposal.<br><br></div></div></div></div>