Am 2017-04-08 17:26, schrieb Weng Xuetian:
You're wrong about the QT_IM_MODULE stuff. To make application to use
the
wayland protocol to type (text-input), the implementation must be done
with
QT_IM_MODULE=wayland. I don't mind if it is set to certain application
but set
it in general won't work. Also to have real virtual keyboard , you need
to let
the input method daemon to provides a virtual keyboard implementation.
No you are wrong about that one :-) It might be that it used to be like
that, but Wayland is the default if no QT_IM_MODULE is specified. See
https://code.qt.io/cgit/qt/qtwayland.git/tree/src/client/qwaylandintegration.cpp#n142
And also, merging more and more daemon into kwin is not always good
even from
security point of view. The problem is, once it got merged, the whole
memory
space is being exposed. Which means, if there's a single piece of code
is
vulnerable, it will affect the whole compositor. We are not perfect
people, and
that's why put more code together will make it more vulnerable to
attacker. If
you consider that, your prevention of ptrace on kwin becomes nothing
and so
does your effort to make kwin not loading some random plugin (prevent
ld_preload and qt_plugins_path?).
The security of the system breaks with the weakest link. Whether the IM
daemon is insecure by running standalone or inside KWin isn't a
difference.
So, my proposal to this will be:
im daemon <-> kwin <-> application, and the communication is done with
some
wayland protocol.
and imho that would be best option to all people. Here's the reason
Pros
- less code to run within kwin process
- less change needed to existing im daemon (we just need an extra
frontend)
and kwin
- no hard dependency
Cons:
more ipc latency, but this only happens if user need to type.
The IPC latency is a huge problem here. If we want to have a good
experience KWin needs to decide whether to send a key event to the IM
daemon or through wl_keyboard interface to the application. This means
possibly a roundtrip in the event handling code. This code is currently
the most crucial part of KWin. It opens a can of worms if we go IPC
there and given your suggestion it needs IPC.
And even if we handle it without roundtrip we run into timing issues.
Consider:
* KWin gets key event
* KWin decides it goes to IM for window foo
* IM does something with it
* window foo closes
* IM sends the composed text for window foo to KWin
Now what? In case we would eliminate the IPC by making KWin link the IM
module it becomes:
* KWin gets key event
* KWin decides it goes to IM for window foo
* IM returns the composed text for window foo
* KWin forwards the composed text to window foo
* window foo closes
So from KWin perspective everything becomes cleaner if there is no IPC
involved towards the IM daemon. In that case KWin needs to adjust way
less as we don't need a dedicated protocol.
I understand your concerns with linking stuff and loading plugins but I
don't share them. Yes I also see this as a problem but I think it's less
of a problem than IPC in this crucial area.
Cheers
Martin
