On Fri, 2012-10-05 at 10:11 -0600, Daniel Drake wrote: > On Fri, Oct 5, 2012 at 9:50 AM, Bastien Nocera <hadess@xxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
