public inbox for linux-media@vger.kernel.org
 help / color / mirror / Atom feed
From: Sean Young <sean@mess.org>
To: "David Härdeman" <david@hardeman.nu>
Cc: Mauro Carvalho Chehab <mchehab@s-opensource.com>,
	linux-media@vger.kernel.org
Subject: Re: [PATCH 6/6] rc-core: add protocol to EVIOC[GS]KEYCODE_V2 ioctl
Date: Sun, 11 Jun 2017 17:17:40 +0100	[thread overview]
Message-ID: <20170611161740.GB16107@gofer.mess.org> (raw)
In-Reply-To: <20170429084458.rwoty4bdce6iqftr@hardeman.nu>

On Sat, Apr 29, 2017 at 10:44:58AM +0200, David Härdeman wrote:
> >This can be implemented without breaking userspace.
> 
> How?

The current keymaps we have do not specify the protocol variant, only
the protocol (rc6 vs rc6-mce). So to support this, we have to be able
to specify multiple protocols at the same time. So I think the protocol
should be a bitmask.

Also, in your example you re-used RC_TYPE_OTHER to match any protocol;
I don't think that is a good solution since there are already keymaps
which use other.

So if we have an "struct rc_scancode" which looks like:

struct rc_scancode {
	u64 protocol;
	u64 scancode;
};

Then if the keymap protocol is rc6, ir-keytable should set the protocol
to RC_BIT_RC6_0 | RC_BIT_RC6_6A_20 | RC_BIT_RC6_6A_24 | RC_BIT_RC6_6A_32
 | RC_BIT_RC6_MCE.

If the old ioctl is used, then the protocol should be set to RC_BIT_ALL.

I can't think of anything what would break with this scheme.

Thanks
Sean

  reply	other threads:[~2017-06-11 16:17 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-27 20:33 [PATCH 0/6] rc-core - protocol in keytables David Härdeman
2017-04-27 20:33 ` [PATCH 1/6] rc-core: fix input repeat handling David Härdeman
2017-04-27 20:34 ` [PATCH 2/6] rc-core: cleanup rc_register_device David Härdeman
2017-05-01 16:49   ` Sean Young
2017-05-01 17:47     ` David Härdeman
2017-05-02 18:53       ` David Härdeman
2017-05-02 20:48         ` Sean Young
2017-05-03  9:49           ` David Härdeman
2017-04-27 20:34 ` [PATCH 3/6] rc-core: cleanup rc_register_device pt2 David Härdeman
2017-04-27 20:34 ` [PATCH 4/6] rc-core: use the full 32 bits for NEC scancodes in wakefilters David Härdeman
2017-04-27 20:34 ` [PATCH 5/6] rc-core: use the full 32 bits for NEC scancodes David Härdeman
2017-04-28 11:58   ` Sean Young
2017-04-28 16:42     ` David Härdeman
2017-04-27 20:34 ` [PATCH 6/6] rc-core: add protocol to EVIOC[GS]KEYCODE_V2 ioctl David Härdeman
2017-04-28 11:31   ` Mauro Carvalho Chehab
2017-04-28 16:59     ` David Härdeman
2017-04-28 19:42       ` Sean Young
2017-04-29  8:44         ` David Härdeman
2017-06-11 16:17           ` Sean Young [this message]
2017-06-17 11:20             ` David Härdeman
2017-04-28 11:40   ` Sean Young
2017-04-28 16:46     ` David Härdeman

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=20170611161740.GB16107@gofer.mess.org \
    --to=sean@mess.org \
    --cc=david@hardeman.nu \
    --cc=linux-media@vger.kernel.org \
    --cc=mchehab@s-opensource.com \
    /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