linux-bluetooth.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
To: Alex Deymo <deymo@chromium.org>
Cc: Marcel Holtmann <marcel@holtmann.org>,
	linux-bluetooth <linux-bluetooth@vger.kernel.org>,
	keybuk <keybuk@chromium.org>
Subject: Re: [PATCH v3 1/2] input: Documentation for new Input1 interface
Date: Thu, 4 Apr 2013 16:52:06 -0300	[thread overview]
Message-ID: <20130404195206.GG2715@samus> (raw)
In-Reply-To: <CAGd9gwiJxU0oDh4-rkw7moQhsT07AF0td27kt0u9hQa-_Ex-Sw@mail.gmail.com>

Hi Alex,

On 12:13 Thu 04 Apr, Alex Deymo wrote:
> On Wed, Apr 3, 2013 at 9:43 PM, Vinicius Costa Gomes
> <vinicius.gomes@openbossa.org> wrote:
> > Just for fun, the only idea that I could come up with is: "ReconnectionMode"
> > or "Mode" with two values: "active" (the remote is not normally connectable,
> > but is able to initiate connections), "passive" (the remote is not able to
> > initiate connections but is normally connectable) and "dual".
> >
> > Alex, does something like this cover the use cases that you have in mind?
> >
> Hi!
> The HID profile spec [1], page 77, Table 5.7, defines the four values
> as valid (True/False for each property). I don't know any device that
> has both values in False, and it looks kind of weird to have to click
> some sort of hidden connect button in a input only HID device every
> time you want to reconnect since you can do data-driven reconnections,
> but well, the specs allows that option. The important thing here is
> that these four values are meaningful to the user interface and we
> should export them in some way, because you have to notify the user to
> do actions like "please, move your mouse to reconnect" or "please,
> click the connect button in your mouse to reconnect" or similar
> messages in situations where the host can't simply reconnect to the
> device with user interaction.
> 
> I agree that the spec names aren't the best ones, but at least are the
> standard names defined in the spec. Exporting two boolean properties
> with different names than the spec will simply add more noise. Combine
> both properties in one "ReconnectionMode" looks better to me since
> both variables are coupled in the mentioned table, but it will have
> the four values ("none", "active", "passive", "dual").

Yeah, even if it doesn't make much sense we should handle the "none" case.

> 
> Other option:
> "ReconnectInitiator": "none", "device", "host", "both"

I still like "ReconnectionMode" slightly better, but no strong feelings about
it. And in this case I would rename "both" to "any".

> 
> Tell me which one do you like the most.
> Cheers,
> Alex.
> 
> [1] https://www.bluetooth.org/docman/handlers/downloaddoc.ashx?doc_id=246761
> 
> 
> > Cheers,
> > --
> > Vinicius


Cheers,
-- 
Vinicius

  reply	other threads:[~2013-04-04 19:52 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-19  1:05 [PATCH] Expose HIDNormallyConnectable and HIDReconnectInitiate properties Alex Deymo
2013-03-20 15:47 ` Marcel Holtmann
2013-04-01 21:39 ` [PATCH v2] core: " Alex Deymo
2013-04-01 21:48   ` Marcel Holtmann
2013-04-01 22:54     ` Alex Deymo
2013-04-02  0:40 ` [PATCH v3 0/2] HID Connetabillity Alex Deymo
2013-04-02  0:40   ` [PATCH v3 1/2] input: Documentation for new Input1 interface Alex Deymo
2013-04-04  3:48     ` Marcel Holtmann
2013-04-04  4:43       ` Vinicius Costa Gomes
2013-04-04 19:13         ` Alex Deymo
2013-04-04 19:52           ` Vinicius Costa Gomes [this message]
2013-04-02  0:40   ` [PATCH v3 2/2] input: Expose HIDNormallyConnectable and HIDReconnectInitiate properties Alex Deymo
2013-04-04  3:42     ` Marcel Holtmann

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=20130404195206.GG2715@samus \
    --to=vinicius.gomes@openbossa.org \
    --cc=deymo@chromium.org \
    --cc=keybuk@chromium.org \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=marcel@holtmann.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 NNTP newsgroup(s).