Jonas Ådahl writes:
> Sure, if relying on mipointer doing this is fine then why not.
Yeah, there are lots of places where the original API design from 1987
doesn't make much sense in 2015. Who would have thought?
> I'd still need to add the 'invalidate' state to mipointer.c
On Fri, Sep 25, 2015 at 12:13:13PM -0500, Keith Packard wrote:
> Jonas Ådahl writes:
>
> > The reason I didn't do this was that we'd send duplicate set_cursor
> > requests when the cursor actually did change. What the patch does is
> > make it so that the path that actually
Jonas Ådahl writes:
> The reason I didn't do this was that we'd send duplicate set_cursor
> requests when the cursor actually did change. What the patch does is
> make it so that the path that actually does change the cursor when it
> changes according to the X server always
On Mon, Sep 21, 2015 at 10:28:14PM +0100, Keith Packard wrote:
> Jonas Ådahl writes:
>
> > In Wayland, a client (in this case XWayland) should set the cursor
> > surface when it receives pointer focus. Not doing this will leave the
> > curser at whatever it was previously.
>
>
On 21/09/15 11:19, Daniel Stone wrote:
Hi,
On 21 September 2015 at 09:52, Jonas Ådahl wrote:
In Wayland, a client (in this case XWayland) should set the cursor
surface when it receives pointer focus. Not doing this will leave the
curser at whatever it was previously.
When
Jonas Ådahl writes:
> In Wayland, a client (in this case XWayland) should set the cursor
> surface when it receives pointer focus. Not doing this will leave the
> curser at whatever it was previously.
It seems like it would be far simpler to just remember the last cursor
set
In Wayland, a client (in this case XWayland) should set the cursor
surface when it receives pointer focus. Not doing this will leave the
curser at whatever it was previously.
When running on XWayland, the X server will not be the entity that controls
what actual pointer cursor is displayed, and