Am 2018-01-05 12:48, schrieb Marco Martin:
I would like to give it a try about it if you don't mind(ie had
precise plans or code started)..
I don't mind :-)
so i was thinking about a property for the current state, plus a
signal for state change.
as for the location, into ConnectionAdaptor would probably be the
easiest, iff makes semantically sense it comes from
org.kde.KWin.InputDeviceManager, which is proably arguable for both
yes and no ;)
I wouldn't put it into ConnectionAdaptor. What I had in mind was basing
it on top of D9521 which passes the event down into KWin core. That way
other areas in KWin can use it.
So I would do something like a small class
class TabletModeManager : public QObject, public InputEventSpy
{
};
and monitor from there whatever the state is. That would make the
feature independent from the libinput implementation.
Cheers
Martin
On Fri, Jan 5, 2018 at 6:23 AM, Martin Flöser <mgraess...@kde.org>
wrote:
I want to provide a dbus service in KWin to export the state. Apps
cannot use libinput directly, one needs root for that.
Cheers
Martin
Am 4. Januar 2018 23:22:43 MEZ schrieb Marco Martin
<notm...@gmail.com>:
Hi all,
one thing i wanted to look into, is to detect when a trasformable
laptop goes
in tablet mode from applications, so that plasmashell and kirigami
apps
can
adapt themselves and do things(tm)
KWin does that (on wayland) already, and i see it uses libinput for
that, like
i seem to evince from this recent commit (and the logic when to show
the on
screen keyboard)
https://cgit.kde.org/kwin.git/commit/?
id=ac2f41c86d3b5b13ba3655e6c2f17f59a4cb7f01
would a normal application use libinput too or is something reserved
to
the
compositor?
what would be the right way(tm) there? a dbus signal from KWin?
