Input Redirection/Transformation vs Input Shaping? What's the difference?

[psych787]

Recently, support was added to the plugin to do input shaping. Note that this is not input redirection which has been a touted feature of the X server where we can interact with any transformed window normally.

Input shaping allows us to only capture clicks inside the shape of the shelfed window, meaning that seemingly small windows are not going to capture all the clicks on your screen.


This seems to indicate that scaled windows can receive input whenever the user is clicking on them, but not be informed of clicks outside the window. The only program I can think of that would be affected by this is xeyes (http://www.xfree86.org/4.4.0/xeyes.1.html). Frankly, I don't see how this is so different from using Metisse (http://insitu.lri.fr/metisse/) with most programs.

Is interaction with scaled windows possible using Freewins++ due to input shaping? If so, what are the limitations?

This may seem like a noob question, but the video doesn't seem to show any real interaction with the scaled window and my replacement PC has yet to arrive (using OQO (www.oqo.com) atm).

Edit: This was answered on IRC. It seems that scaled down interaction is possible, but the clicks will be where they would be if the window wasn't scaled.

[delfick]

Basically, when a window is scaled, or moved around as it is in freewins, only the image of the window is affected.

as far as the xserver is concerned the window hasn't changed at all, so it doesn't know the new position of all the controls on the window.

This means if you scale the window, you click in the same position as before the scaling to interact with the window.

input redirection will mean that the xserver knows the new position of the controls, so when you scale the window, you can click on the new position of the controls to interact with them.

input shaping just means that the window will only register clicks over the area where the scaled version of it is. (as in clicks outside the scaled version of the window would be as if the window wasn't actually there)

[psych787]

Thanks for that explanation. As a matter of fact there is one thing I don't get about all this input redirection business...

When running X11 over the network, the host PC is actually running the program. Does the program know this? Not unless it wants to... So if mouse coordinates are now effectively described in terms of Cartesian coordinates, then why not just shrink the image, and integer divide the X and Y values by the scale factor?
Metisse essentially does the above by rendering windows off screen. Unfortunately, it was based on a specific configuration fvwm with limited documentation and as an OpenGL app itself it "could not handle OpenGL stuff". The end result was wierd things like printscreen mapped to Shift+Delete (and vice versa), many applications like TI-Emu and Doom received incorrect keystrokes, extreme difficulty in adding keyboard shortcuts, rdesktop seamless windows issues (I have no idea why), and slow media players.

Why is it so hard to implement Metisse-style input redirection in a Compiz plugin, which would be a huge improvement over Metisse and a satisfactory intermediate solution?

[SmSpillaz]

Because Metisse uses a modified X server.

If I remember correctly, Metisse uses an X Server architectured around VNC, so clicks are captured and then Metisse itself can communicate with the X server and change where those clicks end up. Clicks are captured by the server itself still, but Metisse can modify them.

The main Compiz developer, David Reveman, is working with others on a solution that will allow input redirection to take place with Compiz, however it is a complete re-architecturing of how the the X server handles input.

Patches are available, and they essentially work, however some applications don't play nice with it. For this reason and others (Such as input hotplugging), it has been pushed back to X Server 1.6, so we aren't going to see it for a while.

Hope that answered your question.

SmSpillaz

[psych787]

Yes, it does. I'd forgotten Metisse was based on VNC... that explains a lot of its wierd behavior, especially video playback issues through large windows. Thanks.

[shafin]

When is Xserver 1.6 coming out? Will it be included in ubuntu Hardy Heron?

[b0le]

1.5 is in march and 1.6 will most likely be 6month later, so nope

[psych787]

It is now 5/24/08. Any updates on this? From the X.Org Wiki:
"7.4 is currently under development, and is scheduled to be released in May 2008."

How much longer will this take?

[some-guy]

it isn't in xorg 7.4

[psych787]

I realize that. My point was that even 7.4 isn't here.

X.Org seems perpetually late, especially for a core part of modern *nix.

[Oasisgames]

I realize that. My point was that even 7.4 isn't here.

X.Org seems perpetually late, especially for a core part of modern *nix.
Yep.

Ten characters... Bah!

[psych787]

Xorg lateness has made it to slashdot. Ouch.

[Götz]

Now it seems that Xorg 7.4 / Xserver 1.5 will be released soon. And maybe Xserver 1.6 will come early 2009. Will Xserver 1.6 have the nice Input Redirection?

[some-guy]

Now it seems that Xorg 7.4 / Xserver 1.5 will be released soon. And maybe Xserver 1.6 will come early 2008. Will Xserver 1.6 have the nice Input Redirection?
Unfortunately I'm doubting it...

[psych787]

I'd be perfectly happy if some Compiz developers would just put the existing input redirection patches as part of Compiz along with a few simple metisse-like plugins. (giving it its own Xorg Xserver)

Metisse itself still has too many problems with rdesktop and OpenGL.

[b0le]

(giving it its own Xorg Xserver)
Like xgl? Or a fork of x? Either way, why not just recompile x with the IR patches...? That seems to me to be much easier/better.

[psych787]

I really meant a fork of X with the patches with instructions on how to compile it with a suitably modified version of Compiz.

[Oasisgames]

Speaking of a "suitably modified version of Compiz" - anyone planning on reimplementing the original input redirection modifications to the other plugins (I always loved those videos of scale)? Or anyone know where I could find some old sources that included these modifications (I feel like hacking, I need to get away from my disobediant GeForce2 machine)?

[some-guy]

Try looking in the SLED SP1 sources: ftp://forgeftp.novell.com/sledsource/SLED-10-SP1-i386-srpms/src/

[psych787]

Great. Now how could these be applied to a debian system? If someone could offer a reasonably clear set of instructions as to which of these contains the right stuff and how to get it make installable, then I might be able to do a checkinstall as well.

[some-guy]

Great. Now how could these be applied to a debian system? If someone could offer a reasonably clear set of instructions as to which of these contains the right stuff and how to get it make installable, then I might be able to do a checkinstall as well.
Recompile X, and Recompile compiz.
recompiling X isn't for a newbie or intermediate user, only advanced users who can find there way completely though cli and repair their system with cli, should attempt it.

But you shouldn't even try it without even knowing if the compiz patch exists in the sources(might have just been a preview...)

[psych787]

I'm no newbie, so don't treat me like one! :p
I've already recompiled X117.3 in an attempt to get it running under Debian Etch before I realized there was already a backport. The main problems with my compile were that it was not finding my keyboard and mouse modules, and that while I eventually got 3D NVIDIA stuff working with it, glxgears just showed a red box. After that I compiled a fresh 2.6.24 kernel, which is now a vast improvement compared to stock kernels. All this was accomplished in the last few days to solve a problem with switching X11 virtual terminals, which still remains but with less disastrous results.

Anyway, I'm less unsure about the Compiz patches than getting the plugins that belong with them. Despite extensive shell knowledge, I can't code my own plugins. Furthermore, I'll need at least a little help fixing the aforementioned problems with my X11 recompile (certainly a result of incorrect prefixes and/or replacement packaging).

[some-guy]

lol, it was just a warning ;)
I'm really not sure about IR though, OasisGames, b0le, or smsplillaz should find if its a modified source or if it's in the patches, or if it was just a preview

[psych787]

Ok, well I need a few pointers from them about this then. I'll also need to know how to apply the Xorg patches - its not clear from the mailing list how the .bin file should be applied to source, or what versions of Xorg it will work for.

EDIT:
Woah, just now found this
http://planet.compiz-fusion.org/
and this
http://forum.compiz-fusion.org/showthread.php?t=8966.
However, the bugs mentioned sound worse than metisse. Any improvements yet?

[b0le]

AFAIK there was never any patches for compiz. From what I read on the ML, davidR had a local branch of compiz with IR support, which he was going to cleanup and then release (but I could never find it :()

EDIT: also, I looked at the compiz-cvs package, and saw no indication that it was using IR (at least, a grep for mesh showed up nothing in the src/ folder (and the function used for input-redirection is XCompositeSetTriangularCoordinateMesh))

[Alice_LJ]

Good job! A prefect post make me sense!;)

__________________
jewelry store (http://www.embracejewelry.com)

[SmSpillaz]

AFAIK there was never any patches for compiz. From what I read on the ML, davidR had a local branch of compiz with IR support, which he was going to cleanup and then release (but I could never find it :()

EDIT: also, I looked at the compiz-cvs package, and saw no indication that it was using IR (at least, a grep for mesh showed up nothing in the src/ folder (and the function used for input-redirection is XCompositeSetTriangularCoordinateMesh))

Actually that applies to a lot of work that David Reveman was working on back in the day. He hasn't been around for a while so don't expect him to finish O-F or write input transformation patches now that b0le, OasisGames and I are making noise about it =)

[psych787]

Ya, I've searched for other stuff by him, but found nothing. However, the modified freewins plugin is absolutely worth looking into. It would be really helpful if there were some people I could ask questions... isn't there an IRC channel for Compiz with some experienced developers?

Oh, and finally got the CompizFusion code to compile without using any of the backported Compiz packages (which didn't quite work right). Hell yea!

[b0le]

#compiz-fusion-dev (on freenode)

[psych787]

Even after an upgrade to KDE 3.5.8's kicker and applets, CompizFusion will not play nice. Specifically,
1) Taskbar shows all windows, despite ccsm being configured to do otherwise.
2) Pager gets blasted to absurd sizes, and doesn't accurately reflect which windows are where.
3) Compiz does not respond to wmctrl's actions, which I will need to assign multiple keys to the same virtual desktop.
4) Running A Path Beyond under wine results in keypresses remaining held down outside the application, and consequently Ctrl+Alt+F# also fails. This means I have to shutdown after running the game for a few seconds.

Until these issues can be worked around, CompizFusion is not an option for me.

EDIT: I've installed compiz versions of KDE's taskbar and pager. Unfortunately, I have also found the source of all the "funny" behavior going on with respect to viewports: the cube requires one desktop stretched across 8 portals. This is not ideal, as I cannot figure out how to use wmctrl through this, and the pager refuses to display desktops in 2 rows. Any ideas?

EDIT2: Problems 1-3 have been more or less solved. However, A Path Beyond still has keyboard lockup problems, and disallowing Compiz to control it through winecfg has even bigger problems. In addition, Java programs are not displaying textboxes. I found out working in eclipse.

[SmSpillaz]

Even after an upgrade to KDE 3.5.8's kicker and applets, CompizFusion will not play nice. Specifically,
1) Taskbar shows all windows, despite ccsm being configured to do otherwise.
2) Pager gets blasted to absurd sizes, and doesn't accurately reflect which windows are where.


To quote the almighty FusioBot on IRC:
< FusioBot> SmSpillaz: Neither the KDE3 taskbar or pager properly support
viewports. To work correctly with compiz, you need to use
the versions here:
http://www.kde-apps.org/content/show.php?content=46021 and
http://www.kde-apps.org/content/show.php?content=61169 .
Also, add << ShowAllWindows=false >> to the [General] section
of ~/.kde/share/config/ktaskbarrc




[quote]
4) Running A Path Beyond under wine results in keypresses remaining held down outside the application, and consequently Ctrl+Alt+F# also fails. This means I have to shutdown after running the game for a few seconds.


Sounds like a bug in either XKB or wine.


Java programs are not displaying textboxes. I found out working in eclipse.

Known bug in java. You have to switch to metacity to get those boxes to display

By the way, this isn't really relevant to this thread. You should start a new thread in support for issues like this ;-)

[psych787]

You're right its a little off topic, but at the moment I was pretty fed up and otherwise wouldn't have bothered posting such small problems. However, since you mentioned metacity, is there a way to run a second window manager simultaneously for certain programs (I don't think so, but have to ask)?

Anyway, on to more serious stuff. I'll compile Freewins when I can get to it, probably beginning of next week.

[b0le]

If you have 2 (X) screens, you can run compiz on one, and metacity on the other. Alternatively you could switch to metacity whenever you need to run a broken application (or an application that breaks with compiz), and then back to compiz once your done.

[psych787]

I meant on the same screen, obviously. If I had two screens I wouldn't be so hell bent on making more efficient use of my 1280x1024 real estate...
Hmm... what about running the game in xnest though? *gotta try it*

Edit: All problems between Compiz and other programs have been "resolved" by making it easily switchable to kwin. The following may be useful to others as well with a few modifications:

wmctrl -n 1 ; compiz --replace ccp & pkill ksmoothdock ; sleep 3 ; dcop kicker kicker restart
wmctrl -n 8 ; kwin --replace & sleep 1 ; dcop kicker kicker restart ; ksmoothdock


Now I'm on to compiling freewins. However, the IR patch fails on event.c. Which version of freewins should I "git" for the patch to work?
EDIT: Got the right version. Now I need the configure prefixes to compile Xserver for Debian Etch.
EDIT2: Secondary Xserver completely compiled, and fixed up. Now I need a version that works with the patch.
EDIT3: compositeproto and libXcomposite successfully patched. Compit 2ffb32d61cbed1452d67abb2028ac13910550392 of composite proto was used. Correct commit of libXcomposite was e59817872ee6aec0544bd56ebb83ded9e4a5851c.
EDIT4: Using Xserver commit 15e4b6c57484b6afb790c7dc1db9f529ba2219cf everything compiles and runs. Unfortunately compiz gives a segfault the moment freewins finishes scaling. This is the same behavior as on an unpatched Xserver.
EDIT5: Using d6b8d9eaffaf3f976db330bc35da3d30eb656bac commit of Xserver, which b0le suggested should work. Unfortunately, the same problem remains.