From: Bastien Nocera <hadess@hadess.net>
To: Daniel Drake <dsd@laptop.org>
Cc: Kay Sievers <kay@vrfy.org>, Greg KH <greg@kroah.com>,
Dmitry Torokhov <dmitry.torokhov@gmail.com>,
linux-input@vger.kernel.org, linux-hotplug@vger.kernel.org,
Carlos Garnacho <carlosg@gnome.org>
Subject: Re: Communicating tablet mode status to userspace
Date: Fri, 05 Oct 2012 16:40:34 +0000 [thread overview]
Message-ID: <1349455234.11150.12.camel@novo.hadess.net> (raw)
In-Reply-To: <CAMLZHHR8gk_D-zU2Wu819vQeJ4HV2n7RwoW-MUa1pDtkrH+Vdg@mail.gmail.com>
On Fri, 2012-10-05 at 10:11 -0600, Daniel Drake wrote:
> On Fri, Oct 5, 2012 at 9:50 AM, Bastien Nocera <hadess@hadess.net> wrote:
> > I think that there's a more generic approach to this, which would also
> > work with the tablet Thinkpads.
> >
> > I would export the current "tablet mode" status through sysfs (which is
> > great if your driver keeps state), and send a uevent when the mode
> > changes (in addition to sending out that input event).
>
> When we tried to add such an attibute in the past, Dmitry rejected it:
> http://article.gmane.org/gmane.linux.drivers.platform.x86.devel/1089
>
> Apart from that, what your suggesting doesn't seem very different from
> the earlier outcome here. We seem to have reached a generic solution,
> where udev would identify input devices that have SW_TABLET_MODE and
> make them accessible to the current seat. Then gnome-settings-daemon
> can monitor them for evdev events (similar to the udev event
> monitoring that would be necessary in your proposal).
If that's the way we're going, then we probably want to have the
tracking and storage of the state done in:
- a udev property (as I did for the accelerometer stuff)
or
- a system-wide D-Bus daemon (exactly like upower does for the lid
status, but obviously, upower seems like the wrong place to do this).
The udev property is easier to put in place, and if Kay doesn't mind it,
it's probably the route I'd go for. This also has the benefit of
allowing the same interface for the Thinkpads.
Cheers
next prev parent reply other threads:[~2012-10-05 16:40 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-02 22:27 Communicating tablet mode status to userspace Daniel Drake
2012-10-02 22:39 ` Alan Cox
2012-10-02 23:36 ` Dmitry Torokhov
2012-10-03 2:58 ` Greg KH
2012-10-03 14:52 ` Daniel Drake
2012-10-03 15:05 ` Greg KH
2012-10-03 15:23 ` Kay Sievers
2012-10-03 16:04 ` Daniel Drake
2012-10-05 15:50 ` Bastien Nocera
2012-10-05 16:11 ` Daniel Drake
2012-10-05 16:40 ` Bastien Nocera [this message]
2012-10-04 13:35 ` Mark Brown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1349455234.11150.12.camel@novo.hadess.net \
--to=hadess@hadess.net \
--cc=carlosg@gnome.org \
--cc=dmitry.torokhov@gmail.com \
--cc=dsd@laptop.org \
--cc=greg@kroah.com \
--cc=kay@vrfy.org \
--cc=linux-hotplug@vger.kernel.org \
--cc=linux-input@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).