On 12/09/2010 03:00 PM, [email protected] wrote:
> Send wayland-devel mailing list submissions to
>       [email protected]
> 
> 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
>       [email protected]
> 
> You can reach the person managing the list at
>       [email protected]
> 
> 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 <[email protected]>
> Subject: Re: Blender3D & cursor clamping.
> To: Campbell Barton <[email protected]>
> Cc: [email protected]
> Message-ID:
>       <[email protected]>
> Content-Type: text/plain; charset=UTF-8
> 
> On Sun, Dec 5, 2010 at 8:27 PM, Campbell Barton <[email protected]> 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
> [email protected]
> 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.
_______________________________________________
wayland-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Reply via email to