The way to use system cursor and custom(client) cursor

[Elvis Lee(이광웅)]

> -----Original Message-----
> From: Pekka Paalanen [mailto:ppaalanen at gmail.com]
> Sent: Tuesday, June 11, 2013 12:25 AM
> To: Elvis Lee ("이광웅")
> Cc: wayland-devel at lists.freedesktop.org
> Subject: Re: The way to use system cursor and custom(client) cursor
> 
> On Mon, 10 Jun 2013 10:52:34 -0700
> Elvis Lee(이광웅) <kwangwoong.lee at lge.com> wrote:
> 
> > > -----Original Message-----
> > > From:
> > > wayland-devel-bounces+kwangwoong.lee=lge.com at lists.freedesktop.org
> > > [mailto:wayland-devel-bounces+kwangwoong.lee=lge.com at lists.freedeskt
> > > op.org]
> > > On Behalf Of Pekka Paalanen
> > > Sent: Sunday, June 09, 2013 11:03 PM
> > > To: Elvis Lee (______)
> > > Cc: wayland-devel at lists.freedesktop.org
> > > Subject: Re: The way to use system cursor and custom(client) cursor
> > >
> > > On Sun, 9 Jun 2013 16:01:48 -0700
> > > Elvis Lee(______) <kwangwoong.lee at lge.com> wrote:
> > >
> > > > Hello.
> > > >
> > > >
> > > >
> > > > I feel unnatural to implement custom cursor scenario. Here is a
> question.
> > > >
> > > > How does a client request compositor to use system cursor?
> > > >
> > > >
> > > >
> > > > The system cursor means a current default cursor for compositor.
> > > >
> > > > Currently, client should know about the system cursor in order to
> > > > use it as parameter of wl_pointer.set_cursor.
> > > >
> > > > Otherwise, cursor surface should be destroyed to request
> > > > compositor a rollback to system cursor from custom cursor.
> > > >
> > > >
> > > >
> > > > I think it¡¯s enough to detach buffer from cursor surface for
> > > > hiding the cursor.
> > > >
> > > > And set_cursor(null surface) can be used to request to stop using
> > > > custom cursor. (rollback)
> > > >
> > > >
> > > >
> > > > Here are some states and protocols.
> > > >
> > > >
> > > >
> > > > 1.     System cursor -> Custom cursor
> > > >
> > > > A.     set_cursor(cursor_surface)
> > > >
> > > > B.      cursor_surface.attach(buffer for custom image)
> > > >
> > > > C.      cursor_surface.damage
> > > >
> > > > D.     cursor_surface.commit
> > > >
> > > >
> > > >
> > > > 2.     Custom cursor -> System cursor
> > > >
> > > > A.     set_cursor(null surface)
> > > >
> > > >
> > > >
> > > > 3.     Custom cursor -> Hide Cursor
> > > >
> > > > A.     set_cursor(cursor_surface)   (can be omitted if it is already
> set)
> > > >
> > > > B.      cursor_surface.attach(null buffer)
> > > >
> > > > C.      cursor_surface.commit
> > > >
> > > >
> > > >
> > > > 4.     System cursor -> Hide Cursor
> > > >
> > > > A.     set_cursor(cursor_surface)
> > > >
> > > > B.      cursor_surface.attach(null buffer) (can be omitted if it is
> > > already
> > > > detached)
> > > >
> > > > C.      cursor_surface.commit
> > > >
> > > >
> > > >
> > > > I think this can cover up a scenario when pointer enters into a
> > > > surface of client.
> > > >
> > > > If there is no specific cursor for client to want when pointer
> > > > enters, it¡¯s enough to request set_cursor(null).
> > > >
> > > >
> > > >
> > > > Is this approach possible? I want to listen your opinions.
> > >
> > > Hi Elvis,
> > >
> > > do I understand right, that you would like to add the concept of a
> > > system cursor?
> > >
> > > I guess it would be possible, but why?
> > >
> > > It seems the system cursor you propose would be one arbitrary cursor
> > > without any meaning. When and why would applications ever want to use
> it?
> > >
> > > The compositor usually cannot, and there is no need to, switch to a
> > > system cursor on its own, so it would always be requested by a client.
> > > I can understand applications wanting a specific cursor, or no
> > > cursor, but what would be the purpose of a system cursor?
> > >
> > > If you also consider cursor themes, the system cursor would be from
> > > one theme. An application using a system cursor would need to use
> > > the same theme for its other cursors to look consistent.
> > >
> > > We already have libwayland-cursor to help you load a cursor theme,
> > > so using a proper cursor should not be too hard.
> > >
> >
> > Hi, Pekka.
> >
> > Thanks for your opinion.
> >
> > Possibly, The word 'system cursor' can attract over attention.
> > As you said, it's just one of the cursor themes.
> >
> >
> > It might be unclear for my explain. Here is a simple scenario.
> > Compositor can own its cursor without client or with minimized client or
> outside focused client window.
> > And the cursor is configurable.
> > Compositor stared with blue cursor, then user changes it to red one.
> > After launching a client, the client override the cursor with specific
> one.
> > After a while, client want to use the cursor which is used by compositor
> just before.
> 
> What do you mean by the compositor's cursor?
> 
> Like krh explained to Bill, in Weston, there are no noticeable surfaces
> owned by the compositor. Everything, including the background color fill,
> are owned by some client. That client gets pointer enter events and sets
> the cursor on enter, as any client does. A scenario or screen areas
> without *any* clients is a bug in Weston's world.
> 
> However, for embedded, I guess it can be useful for the compositor to use
> a hardware color fill as the background, e.g. to save memory. In that case,
> the compositor needs to mimic the behaviour of a client providing that
> background: generate internal pointer enter events and set the cursor,
> when the pointer enters compositor-owned area. The compositor itself could
> probably be using libwayland-cursor to load the default cursor theme. (If
> this is not possible with the current libwayland-cursor, I believe patches
> are welcome.)
> 
> Or, a third option is to let a helper client similar to weston-desktop-
> shell load and set the cursors, and have some private protocol for the
> helper to set a special wl_surface, that will act as the background except
> that the background color fill is still drawn by the compositor itself.
> 
> > There are my questions.
> > Which cursor should client choose? How to know about it? Or should
> client know about it?
> 
> libwayland-cursor should solve that, you can load the default cursor theme,
> which is configurable system-wide and per-user. However, it does not
> support dynamic switching of the default theme, I believe.
> 
> Is dynamic switching of the default cursor theme a real goal for you?
> If yes, your issue is not wanting a system cursor, but wanting dynamic
> cursor theme switching.
> 
> > For consistency whole system UX, client can use the same cursor with
> compositor.
> > As I mentioned, the cursor is configurable.
> > Unless we support a kind of get_cursor, client cannot know about which
> theme is used for the compositor.
> 
> libwayland-cursor has builtin mechanisms to determine, what cursor theme
> is the default. It follows the same rules as libXcursor. Both compositor
> (helper clients, actually) and client side use the same.
> 
> > I think client needs a way to inform that it doesn’t want to use
> specific cursor anymore.
> 
> Why does it need this? What is your use case?
> In what situation would a client say "I don't care what the cursor is,
> just make it whatever"?
> 
> > It can be done with set_cursor(null).
> > In my case, I want to regard it as a delegation for cursor from client
> to compositor.
> > And the way to hide cursor can be replaced with detaching buffer.
> > That's what I want to say.
> 
> Yeah, there was a Wayland design decision that there are no "server
> cursors" I believe, unlike X.
> 
> > I hope that I explained well about my needs and approach.
> > And I think my needs might be general one.
> 
> Yes, I understood what you suggest, but not why. :-) I am wondering
> whether this is your real issue at all, and is there some real use case
> behind this, that would be solved better in a different way.
> 
> 
> Thanks,
> pq


Thanks for your comments. It's really helpful.
I almost understood the Wayland designs for cursor.
Basically, I respect the designs. And possibly my issue can be handled with dynamic-switching of wayland-cursor.
But I'm not sure yet that it's good approach.

Here goes *real* use-case, expecting to find a better way.

There is a compositor which includes UXs like a *launcher*.
>From this point, I think it’s going to different way with the Wayland design. :(
As I know, it’s for performance since the UXs have lots of hovering, animations and images.
For those UXs, compositor should have *system cursor*. Actually that's not problem yet.
Because focuses without client can be handled well on compositor.

Also, for system, there is a setting app which can change theme of system cursor.

For example, we can think about SDL game app.
It will use custom cursor for specific game scene.
But it want to use same cursor with system UXs for scenes like a menu selection.
Usually it uses a API to store system cursor. - SDL_GetCursor -- Get the currently active mouse cursor.
But there is no way to support this API on Wayland. Currently it's not important to support this API.
Because there is no guarantee for that current cursor is same with system cursor.

In case of any app having mouse focus, it will handle pointer_enter.
If the app wants to use same cursor with system UX's *current* one,
it should know about what it is. Because the system cursor is configurable.

Now I return to the origin point.
According to Wayland design, there might be no way except supporting dynamic-switching for theme of wayland-cursor.
Can I find another approach?

Thanks.
Elvis.