<div dir="ltr">On Wed, Jul 15, 2015 at 5:09 AM, Daniel Stone <span dir="ltr"><<a href="mailto:daniel@fooishbar.org" target="_blank">daniel@fooishbar.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 29 June 2015 at 20:22, Bill Spitzak <<a href="mailto:spitzak@gmail.com">spitzak@gmail.com</a>> wrote:<br>
<span class="">> On Sun, Jun 28, 2015 at 7:32 AM, x414e54 <<a href="mailto:x414e54@linux.com">x414e54@linux.com</a>> wrote:<br>
>> Clients do not draw the mouse cursor, either the GPU (using hardware<br>
>> overlays) or the WM does.<br>
><br>
> Yes, I want to allow clients to use this CPU/WM support. Currently the<br>
> client *has* to draw the cursor (and hide the hardware one) to sync it's<br>
> position with the drawing. If instead the client just *moves* the cursor,<br>
> then the cursor is actually drawn by the compositor like you say.<br>
<br>
</span>I haven't read the vast majority of this thread, but this isn't really<br>
true. There's nothing special about the cursor in drawing: just hide<br>
the cursor, create a small subsurface with SHM buffers, and Weston<br>
will use the hardware cursor as it would for an actual cursor surface.<br>
Problem solved.<br></blockquote><div><br></div><div>The problem I have with that is that it is impossible to prevent an incorrect composite where there is either no cursor or two cursors rendered.<br><br></div><div>The wayland api could be changed so that setting a cursor image is buffered until a matching wl_surface commit, and this could fix the entry into pointer-lock mode. However when locked mode is lost I don't see any way to do it, as it may be a different client setting the cursor image than the one that would be removing the subsurface with the fake cursor in it.<br><br></div><div>This is probably not a big deal except (as far as I can tell) it can be fixed with a trivial change to the proposed pointer-lock. The current proposal makes the cursor stop moving (which means the client has to hide the cursor in any conceivable usage) and adds a "set_cursor_hint" request that is used to set the xy position the cursor will be at when pointer lock is lost. I want "set_cursor_hint" to actually move the cursor (and possibly rename it to remove the word "hint"). If the client does not want that it can hide the cursor, which it has to do anyway in the current proposal.<br><br></div><div>For some reason this has degraded into a big argument about whether locking the cursor position to the rendered graphics is good or bad. But since the alternative of using a subsurface would also do that, it does not matter whether that is good or bad for deciding this.<br><br></div><div>This change combined with a pointer lock that lasts the exact same time that the implicit grab for a button down lasts would be very useful to make a "slow scrollbar" or a 3-D trackball where the cursor sticks to the rendered ball's surface. Reusing an api designed for games for this seems like a good idea to reduce Wayland's api size.<br><br></div></div></div></div>