A few questions and a suggestion for dnd

[Fabian Henze]

On Sunday, 14 Nov 2010, 22:42-UTC, Kristian Høgsberg wrote:
> On Sun, Nov 14, 2010 at 12:08 PM, Fabian Henze <flyser42 at gmx.de> wrote:
> > 1. If the design of the pointer is controlled by the client, how will
> > this be consistent among applications? Especially, if the user wants to
> > change the system-wide pointer theme? How will clients decide what e.g.
> > the "hand" or text-selection pointer looks like?
> 
> There has to be a out-of-band theme mechanism that lets applications
> agree on a icon/font/cursor/color theme.  In X we have the xsettings
> protocol, which provides this, but that's really a workaround for the
> fact that applications can't agree on one configuration system.

Why do you intend it to be out-of-band? Broadcasting the theming information 
after a client connects, sounds like a sane solution to me.
I fear that toolkits or (much worse) application developers won't agree on a 
single mechanism to handle this and that this will take years of fdo work to 
correct. Especially, if some distribution adopts wayland, before a sane 
mechanism is ready.

> > If so:
> > 2. Will all clients have to reset the pointer once they receive motion
> > events? Isn't this ineffective? Will the "root surface" (is that what
> > it's called?) also have to do this?
> 
> Yes, clients have to set the cursor, and no, it's not inefficient.
> Wayland doesn't have sub-surfaces that would let you set a pointer per
> surface, so clients have to track motion within their surface and
> update the cursor accordingly.  For example, if the cursor moves into
> a textfield, the client has to set the I-beam cursor etc.  The
> consequence of this design is that the server can't know what cursor
> to set.  Maybe the last cursor set for a surface was the I-beam
> cursor, then the pointer exits and enters from a different edge, where
> it enters a menu.  The menu needs the arrow cursor so if the server
> was to set the I-beam cursor and the app was slow, we would just see a
> brief flash of I-beam, before the app sets it back to the pointer.  A
> tiny delay before setting the right cursor is better than setting the
> wrong cursor briefly. And typically, there wont be any noticable
> delay.
> 
> The root surface is handle by the compositor and the compositor will
> set the default cursor when the pointer enters the root surface (where
> default cursor is up to the compositor).

Sounds good :)

> > 3. What are the minimum requirements to run wayland? Does the system have
> > to have a 3D capable GPU? what about virtual GPUs? e.g. cirrus for qemu
> > or whatever other emulators use?
> 
> All wayland needs is a way to share surfaces.  And there's a shm
> mechanisms that uses fd passing,which works on any graphics cards.  So
> you could implement wayland with client side all sw rendering (cairo
> image backend, for example) and do software compositing on the server
> side.  The only requirement in that case is that you can do
> modesetting in the compositor.  Wayland could run on /dev/fb, in other
> words.

I am glad to hear that :) Is the code for /dev/fb-based wayland already there 
or is it just a possibility for the future?

> > And finally an idea for the drag and drop mechanism:
> > Would it be possible (and desirable) to modify dnd in the following way:
> > When the drag starts, the initiator surface creates a new surface, which
> > contains just an image of the drag content and is positioned relative to
> > the pointer. After the target surface accepted the drag, it gains access
> > to the surface and can do whatever animation with it. This would make
> > drag and drop visually more appealing.
> > I hope you understand what I mean and how this would be useful. If you
> > don't, I can try to create a quick mockup using gimp :-).
> 
> I think that it may be useful to split the cursor image from the image
> being dragged.  The use case I have in mind is where you want to do a
> "snap back" animation in case the drop is declined, that is, the
> dragged icon slides back to the origin if the source rejects the drop.
>  The compositor will have to implement that (it's the only place where
> we know where the drag was started and where it was rejected), but in
> the current scheme, the compositor doesn't have the dragged icon
> without the cursor composited on top.  My concern was that I don't
> want lag between the cursor and the drag icon, but the compositor can
> ensure that even if the two are not in the same texture, so I think we
> can do this.
> 
> I'm not sure about passing the image to the drop target though.  It's
> easy enough to let the client pass an ID for the buffer that holds the
> icon image, and I guess I don't see a problem with that.  I'll have to
> try to implement it and see how it works.

While the compositor knows where the drag has started, it doesn't know where 
it will affect the target surface in case the dnd is successful. The only place 
with that knowledge is the target client and imo it should be able to make use 
of this knowledge by smoothly integrating the icon surface in the target 
surface.
Otherwise the "dnd failed" case is nicely animated, while the "dnd successful" 
is not. 

Oh and one more question popped to my mind: Just out of curiosity, does 
wayland use hwcursor? I heard there were plans (or musing) in the X world to 
remove hwcursor support for some reason.

And last but not least, I tried to build and run wayland in a chroot on my 
Ironlake notebook. It works fine, but only after I patched the pci ids of my 
graphics card into the mesa source (src/egl/drivers/dri2/egl_dri2.c). Do you 
care to sync this list with the rest of mesa? Or is it intentional that 
Ironlake is not supported?

-- regards,
Fabian Henze