Blender3D & cursor clamping. (Kristian H?gsberg)

[Marty Jack]

On 12/09/2010 03:00 PM, wayland-devel-request at lists.freedesktop.org wrote:
> Send wayland-devel mailing list submissions to
> 	wayland-devel at lists.freedesktop.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://lists.freedesktop.org/mailman/listinfo/wayland-devel
> or, via email, send a message with subject or body 'help' to
> 	wayland-devel-request at lists.freedesktop.org
> 
> You can reach the person managing the list at
> 	wayland-devel-owner at lists.freedesktop.org
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of wayland-devel digest..."
> 
> 
> Today's Topics:
> 
>    1. Re: Blender3D & cursor clamping. (Kristian H?gsberg)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Thu, 9 Dec 2010 14:36:21 -0500
> From: Kristian H?gsberg <krh at bitplanet.net>
> Subject: Re: Blender3D & cursor clamping.
> To: Campbell Barton <ideasman42 at gmail.com>
> Cc: wayland-devel at lists.freedesktop.org
> Message-ID:
> 	<AANLkTi=L_gdY3jpKsBkjuq1Yp3HP4gv6JvH7thz1E=ZO at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
> 
> On Sun, Dec 5, 2010 at 8:27 PM, Campbell Barton <ideasman42 at gmail.com> wrote:
>> Hi there, I'm interested in porting blender3d to Wayland. Currently we
>> use an internal library which is a bit like SDL, talking to X11, Win32
>> and Cocoa directly.
> 
> Hi Campbell,
> 
> That's exciting, let me know what problems you run into, but also bear
> in mind that Wayland is still work in progress and even at the
> protocol level things may (and will) change.
> 
>> Since we use OpenGL directly for all drawing I don't expect the port
>> to be all that big a deal.
> 
> There's a couple of tricky things about GL in Wayland right now. First
> of, it's all EGL and GLES2.  Longer term we'll need an answer for apps
> that need full GL, but the problem is that libGL pulls in GLX and all
> the X dependencies.  The other thing is that there is no EGLSurface
> support in Wayland, you just render to a FBO and push the color buffer
> to the Wayland compositor.  We may add an EGLSurface for Wayland at
> some pointer, but for now there's a little more bookkeeping to do on
> the client side.
> 
>> I'm interested in how Wayland deals with input & about mouse coordinates.
>>
>> Currently Blender can fake off screen mouse coordinates on X11 by
>> hiding the cursor warping the position.
>> However it would be a lot nicer if the Wayland functions were able to
>> do this. (I heard this is possible on the OSX).
>>
>> Are there any docs on how to grab the mouse cursor, warp the cursor
>> and is there anything like raw events which can be used for low level
>> interface functions?
> 
> There are no docs, but we've discussed similar requirements before:
> 
>   http://lists.freedesktop.org/archives/wayland-devel/2010-November/000117.html
> 
> The idea is what I call "application pointer" in that email.  The idea
> is that the compositor hides the cursor and just sends relative motion
> events.  The application is then responsible for updating cursor
> position, including pointer acceleration etc, or just not draw a
> cursor but spin a cube, rotate the viewport or control a game.  Now
> one thing I'd like to do different from X is that this mode isn't
> going to be an open ended grab.  The compositor is going to be in
> control and will be able to override it and switch to different
> applications.  I'm thinking that this input mode is only available
> when the application is fullscreen or optionally while a mouse button
> is pressed.  Maybe also while the application has keyboard focus.
> 
> Kristian
> 
> 
> ------------------------------
> 
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
> 
> 
> End of wayland-devel Digest, Vol 3, Issue 6
> *******************************************
> 

I like the overall direction here.  What we have is the simplified drawing model of a mobile device, with the video and input device support of a desktop and enough features around the edges to give people the desktop metaphors they are used to, instead of those they get on a mobile device.

I am somewhat troubled by the amount of conditionals being discussed on the way the pointer behaves.

It reminds me of a memory management architecture long ago where the designers added something every time they found a problem.  There came a point where it became unimplementable, and there was a revolt.  The engineers who actually had to implement it went off for a month and came back with something elegant and simple, and that's how the machine was built, and that design was serviceable for twenty years.

I am also troubled by what seems to be an approach that adds a new variety of compositor every time there is something special to be done.

Not overly so on either of these points, but I encourage you to think things through until they have few rules, can be explained simply, understood, and implemented simply, to the extent possible.  However "in Wayland there is no way to ..." when it is something an application uses is a way to slow down adoption of your system.  I am still studying the new things though, and I am sure there is a lot that you have sketched in your head but we have no way of knowing as yet.

Also, I encourage you to be careful with the design of embedding.  It is important not just because of tray icons, but because of things like playing media inside a browser.

For example right now it is unnecessarily difficult to get the background drawn properly behind a tray icon, and it shouldn't be.