Input transformations: Compiz

[Sam Spilsbury]

CC'd the list

On Thu, Jan 22, 2009 at 9:23 AM, Sam Spilsbury <smspillaz at gmail.com> wrote:
> On Thu, Jan 22, 2009 at 3:58 AM, Bipin George Mathew <bipingm at gmail.com> wrote:
>> Thanks Joel. This mostly clear things. btw, where did is this comment found?
>> I grep'ed through the compiz 0.7.8 code
>> (http://packages.ubuntu.com/source/intrepid/compiz) and could not find such
>> a comment. Beryl's code perhaps?
>>
>> Chris,
>>
>> You mentioned that the XServer needs rework - do you know what the nature of
>> the rework is and why it is needed?
>>
>> Thanks!
>> -Bipin
>
> I really don't know where this discussion is going, but I think you
> guys are confusing ezoom's fake input handling with real input
> redirection. (That comment is in the plugins-main package by the way).
>
> For ezoom's fake cursor drawing, we need proper handling of hiding and
> replacing animated X cursors. It's really wishy-washy, I remember
> Kristian told me one that instead of the contrary, the animated
> cursors disappeared when zoomed in and re-appeared when zoomed out.
> Someone really needs to have a look at the code.
>
> As for input redirection, not too many changes in the server were
> actually required there, it was mostly a change to XComposite to add a
> triangular mesh co-ordinate space conversion system and then a hook in
> tryClientEvents (or whatever it was) where is a window was clicked on
> and had a mesh, that input would be transformed according to the mesh
> and then sent to the client.
>
> It's still not as good as I'd like it to be to be honest, there are
> numerous glitches that occur when a mesh is set, even if it is the
> same as the normal input mesh:
>  * Menus appear in the wrong place
>  * The way I draw the mesh, because of triangle underlap and overlap,
> some input can just be 'missed' and fall through to the next window.
>  * XDnd doesn't work (anymore)
>  * It's really complicated to figure out a correct input mesh. You
> have to handle situations where both plugins set different meshes.
> What I've ended up doing is just creating a mesh out of the
> CompTransform passed around in paintWindow, but that is a sub-optimal
> solution. As soon as someone gives me some documentation on how
> drawWindowGeometry works (which, I believe is the function responsible
> for setting all the verticies of a window as a polygon then passing to
> drawWindowTexture), I'll use the data in that.
>>
>> On Tue, Jan 20, 2009 at 8:01 PM, Joel Bosveld <joel.bosveld at gmail.com>
>> wrote:
>>>
>>> On Wed, Jan 21, 2009 at 11:57 AM, Bipin George Mathew <bipingm at gmail.com>
>>> wrote:
>>>>
>>>> Given that the upstream compiz does not use David's APIs, how is the
>>>> zoom plugin able to translate the co-ordinates for ButtonPress?
>>>>
>>>> While looking at the compiz code, I did find XGrabButton was called on
>>>> each window created to intercept the events; but I was expecting an
>>>> XSendEvent with the ButtonPressMask to be called with the transformed
>>>> co-ordinates- which I not find. Also, I read on the mailinglist that
>>>> clients can ignore synth events of XSendEvent.
>>>> Any pointers on how this translation is done?
>>>
>>>
>>> From the comments at the top of the code:
>>>
>>> Note on input
>>>
>>> We can not redirect input yet, but this plug-in offers two fundamentally
>>> different approaches to achieve input enabled zoom:
>>>
>>> 1. Always have the zoomed area be in sync with the mouse cursor. This
>>> binds the zoom area to the mouse position at any given time. It allows using
>>> the original mouse cursor drawn by X, and is technically very safe. First
>>> used in Beryl's inputzoom.
>>>
>>> 2. Hide the real cursor and draw our own where it would be when zoomed in.
>>> This allows us to navigate with the mouse without constantly moving the zoom
>>> area. This is fairly close to what we want in the end when input redirection
>>> is available.
>>>
>>> This second method has one huge issue, which is bugged XFixes. After
>>> hiding the cursor once with XFixes, some mouse cursors will simply be
>>> invisible. The Firefox loading cursor being one of them. An other minor
>>> annoyance is that mouse sensitivity seems to increase as
>>> you zoom in, since the mouse isn't really zoomed at all.
>>>
>>>
>>
>>
>> _______________________________________________
>> xorg mailing list
>> xorg at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/xorg
>>
>
>
> Cheers,
>
> Sam
>
>
> --
> Sam Spilsbury
>



-- 
Sam Spilsbury