linux-bluetooth.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] hog: ignore UHID-setup events and document why
@ 2013-09-02 11:58 David Herrmann
  2013-09-06 10:38 ` Johan Hedberg
  0 siblings, 1 reply; 2+ messages in thread
From: David Herrmann @ 2013-09-02 11:58 UTC (permalink / raw)
  To: linux-bluetooth; +Cc: Johan Hedberg, Marcel Holtmann, David Herrmann

The UHID_{START,STOP,OPEN,CLOSE} events should be ignored by us to avoid
triggering the warn(). It is safe to do that. Add few comments that
explain why we don't have to handle these.
---
 profiles/input/hog.c | 32 +++++++++++++++++++++++++++++++-
 1 file changed, 31 insertions(+), 1 deletion(-)

diff --git a/profiles/input/hog.c b/profiles/input/hog.c
index 91c2802..0130f94 100644
--- a/profiles/input/hog.c
+++ b/profiles/input/hog.c
@@ -621,12 +621,42 @@ static gboolean uhid_event_cb(GIOChannel *io, GIOCondition cond,
 	DBG("uHID event type %d received", ev.type);
 
 	switch (ev.type) {
+	case UHID_START:
+	case UHID_STOP:
+		/* These are called to start and stop the underlying hardware.
+		 * For HoG we open the channels before creating the device so
+		 * the hardware is always ready. No need to handle these.
+		 * Note that these are also called when the kernel switches
+		 * between device-drivers loaded on the HID device. But we can
+		 * simply keep the hardware alive during transitions and it
+		 * works just fine.
+		 * The kernel never destroys a device itself! Only an explicit
+		 * UHID_DESTROY request can remove a device. */
+		break;
+	case UHID_OPEN:
+	case UHID_CLOSE:
+		/* OPEN/CLOSE are sent whenever user-space opens any interface
+		 * provided by the kernel HID device. Whenever the open-count
+		 * is non-zero we must be ready for I/O. As long as it is zero,
+		 * we can decide to drop all I/O and put the device asleep. This
+		 * is optional, though. Moreover, some special device drivers
+		 * are buggy in that regard, so maybe we just keep I/O always
+		 * awake like HIDP in the kernel does. */
+		break;
 	case UHID_OUTPUT:
 	case UHID_FEATURE:
 		forward_report(hogdev, &ev);
 		break;
 	case UHID_OUTPUT_EV:
-		DBG("uHID output event: type %d code %d value %d",
+		/* This is only sent by kernels prior to linux-3.11. It requires
+		 * us to parse HID-descriptors in user-space to properly handle
+		 * it. This is redundant as the kernel does it already. That's
+		 * why newer kernels assemble the output-reports and send it to
+		 * us via UHID_OUTPUT.
+		 * We never implemented this, so we rely on users to use
+		 * recent-enough kernels if they want this feature. No reason to
+		 * implement this for older kernels. */
+		DBG("Unsupported uHID output event: type %d code %d value %d",
 			ev.u.output_ev.type, ev.u.output_ev.code,
 			ev.u.output_ev.value);
 		break;
-- 
1.8.4

^ permalink raw reply related	[flat|nested] 2+ messages in thread

* Re: [PATCH] hog: ignore UHID-setup events and document why
  2013-09-02 11:58 [PATCH] hog: ignore UHID-setup events and document why David Herrmann
@ 2013-09-06 10:38 ` Johan Hedberg
  0 siblings, 0 replies; 2+ messages in thread
From: Johan Hedberg @ 2013-09-06 10:38 UTC (permalink / raw)
  To: David Herrmann; +Cc: linux-bluetooth, Marcel Holtmann

Hi David,

On Mon, Sep 02, 2013, David Herrmann wrote:
> The UHID_{START,STOP,OPEN,CLOSE} events should be ignored by us to avoid
> triggering the warn(). It is safe to do that. Add few comments that
> explain why we don't have to handle these.
> ---
>  profiles/input/hog.c | 32 +++++++++++++++++++++++++++++++-
>  1 file changed, 31 insertions(+), 1 deletion(-)

Applied. Thanks.

Johan

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2013-09-06 10:38 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-09-02 11:58 [PATCH] hog: ignore UHID-setup events and document why David Herrmann
2013-09-06 10:38 ` Johan Hedberg

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 NNTP newsgroup(s).