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

[Pekka Paalanen]

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.freedesktop.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