View Full Version : Idea for input redirection?
enigma_0Z
October 11th, 2007, 01:17 AM
I was just reading some threads on the forum, and I got this idea... we are all "waiting" for input redirection in X, before we do things like input-enabled scaled windows, input from cube, etc...
But here's my idea/question. Why can't we simply have Compiz grab the mouse like a fullscreen game. Compiz then could control where the mouse pointer is, and where the clicks are actually directed to. So then, Compiz controls the mouse, right? Then we could implement redirection, as compiz would display the mouse pointer at one location, but send the redirected click to the proper window/location in X.
Example: Window one is scaled to 50%. The user clicks in the middle fo the window. let's say this "50%" center is at 100,100 on screen. Compiz registers the click (in the full screen compiz window) and sends it to the (100,100)/.5 ... which is 200,200--the acutal X location.
This seems simple to me, but I understand there is a reason that it has not been done. I am asking why this wouldn't work, and why.
some-guy
October 11th, 2007, 01:34 AM
actually i think it will work and I think this has been used in Beryl and in the Enhanced Zoom plugin, but it is not the proper way to do it, and code can get messy(i think :D)
enigma_0Z
October 12th, 2007, 05:25 PM
actually i think it will work and I think this has been used in Beryl and in the Enhanced Zoom plugin, but it is not the proper way to do it, and code can get messy(i think :D)
Yes, it will definitely get messy...
But I think that the way Bery did it, is that your cursor just happens to be in the correct spot when zooming to click on the zoomed elements... (for example, the corners do not zoom past the cube).
maniac
October 15th, 2007, 11:03 AM
I was just reading some threads on the forum, and I got this idea... we are all "waiting" for input redirection in X, before we do things like input-enabled scaled windows, input from cube, etc...
But here's my idea/question. Why can't we simply have Compiz grab the mouse like a fullscreen game. Compiz then could control where the mouse pointer is, and where the clicks are actually directed to. So then, Compiz controls the mouse, right? Then we could implement redirection, as compiz would display the mouse pointer at one location, but send the redirected click to the proper window/location in X.
That doesn't work with the current infrastructure. There is not just ButtonPress events, but also things like EnterNotify (mouse pointer entered a window). Compiz doesn't have _any_ control over those currently; it can't prevent mouse clicks being sent to the "original position".
Your idea is one of the two ideas to implement input redirection in the X server:
Either send the mouse and keyboard events to the compositor (Compiz) first, so that it can modify it and send it to X after that (your idea)
or give the server an idea of the window transformation by passing the transformation information to it.
As far as I know, the second route was chosen - I don't know about the specific advantages and disadvantages of each route, though. But both routes require X server support and are not solvable inside Compiz.
enigma_0Z
October 15th, 2007, 02:55 PM
That doesn't work with the current infrastructure. There is not just ButtonPress events, but also things like EnterNotify (mouse pointer entered a window). Compiz doesn't have _any_ control over those currently; it can't prevent mouse clicks being sent to the "original position".
Your idea is one of the two ideas to implement input redirection in the X server:
Either send the mouse and keyboard events to the compositor (Compiz) first, so that it can modify it and send it to X after that (your idea)
or give the server an idea of the window transformation by passing the transformation information to it.
As far as I know, the second route was chosen - I don't know about the specific advantages and disadvantages of each route, though. But both routes require X server support and are not solvable inside Compiz.
From what I understand, the first route is possible with the current technology, but would agreed be very very messy... It just came to me, and I thought that I would pose the question.
The second route, however the better one, would require an addition to xorg of course. The first advantage is that compiz would no longer need to maintain the translation information between X and the WM, and the implementation would be much cleaner and clearer.
How this ought to (in my opinion) work is that input redirection is implemented through an Xorg input driver and the compiz devs would have to write the corresponding code... But I'm not an Xorg developer, so I don't know.
Thanks everyone, for clearing this up.
gahre
October 21st, 2007, 01:16 PM
As far as I know, the second route was chosen - I don't know about the specific advantages and disadvantages of each route, though. But both routes require X server support and are not solvable inside Compiz.
So if I understand this correctly then there are already people working on it? X devs? Compiz devs? I'd love to have a look at the code if there is any...
vBulletin® v3.7.3, Copyright ©2000-2008, Jelsoft Enterprises Ltd.