RE: [RFC v2 2/7] media: rc: Add cec protocol handling
Hi Mauro,
I have some more comments/questions below.
From: Mauro Carvalho Chehab [mailto:mche...@osg.samsung.com]
Sent: Sunday, March 08, 2015 3:21 PM
Em Thu, 22 Jan 2015 17:04:34 +0100
Kamil Debski k.deb...@samsung.com escreveu:
(c/c linux-input ML)
Add cec protocol handling the RC framework.
I added some comments, that reflects my understanding from what's there
at the keymap definitions found at:
http://xtreamerdev.googlecode.com/files/CEC_Specs.pdf
Signed-off-by: Kamil Debski k.deb...@samsung.com
---
drivers/media/rc/keymaps/Makefile |1 +
drivers/media/rc/keymaps/rc-cec.c | 133
+
drivers/media/rc/rc-main.c|1 +
include/media/rc-core.h |1 +
include/media/rc-map.h|5 +-
5 files changed, 140 insertions(+), 1 deletion(-) create mode
[snip]
+ { 0x60, KEY_PLAY }, /* XXX CEC Spec: Play Function */
+ { 0x61, KEY_PLAYPAUSE }, /* XXX CEC Spec: Pause-Play Function */
+ { 0x62, KEY_RECORD }, /* XXX CEC Spec: Record Function */
+ { 0x63, KEY_PAUSE }, /* XXX CEC Spec: Pause-Record Function */
+ { 0x64, KEY_STOP }, /* XXX CEC Spec: Stop Function */
+ { 0x65, KEY_MUTE }, /* XXX CEC Spec: Mute Function */
+ /* 0x66: CEC Spec: Restore Volume Function */
+ { 0x67, KEY_TUNER }, /* XXX CEC Spec: Tune Function */
+ { 0x68, KEY_MEDIA }, /* CEC Spec: Select Media Function */
+ { 0x69, KEY_SWITCHVIDEOMODE} /* XXX CEC Spec: Select A/V Input
Function */,
+ { 0x6a, KEY_AUDIO} /* CEC Spec: Select Audio Input Function */,
+ { 0x6b, KEY_POWER} /* CEC Spec: Power Toggle Function */,
+ { 0x6c, KEY_SLEEP} /* XXX CEC Spec: Power Off Function */,
+ { 0x6d, KEY_WAKEUP} /* XXX CEC Spec: Power On Function */,
Those function keycodes look weird. What's the difference between
those and the pure non-function variants?
The note 2 applies to most of these function buttons. It says:
2 During a recording or timed recording, a device may ask the user
for confirmation of this action before executing it.
The spec (CEC 13.13.3) says that:
Unlike the other codes, which just pass remote control presses
to the target (often with manufacturer-specific results),
the Functions are deterministic, ie they specify exactly the
state
after executing these commands. Several of these also have
further
operands, specifying the function in more detail, immediately
following the relevant [UI Command] operand.
Some codes are actually compund ones. For example, 0x60 has a play
mode
operand. So, the actual mapping would be:
0x60 + 0x24 - play forward
0x61 + 0x20 - play reverse
...
(see CEC17 for operand descriptions)
So, IMHO, the mapping should be
{ 0x6024, KEY_PLAY },
{ 0x6020, KEY_PLAY_REVERSE }, // to be created
The note 1 says that they can be issued without the additional operand
specified:
1 Functions with additional operands may also be used without the
additional operand: in this case the behavior is manufacturer-specific.
Will this do?
{ 0x60, KEY_PLAY },
{ 0x6024, KEY_PLAY },
{ 0x6020, KEY_PLAY_REVERSE }, // to be created
Or will the framework get confused that an incomplete key code was
received?
Another question I have is about the following operations:
0x67 Tune Function
0x68 Select Media Function
0x69 Select A/V Input Function
0x6a Select Audio Input Function
These operations take an additional operand that is large number.
1-255 for 0x68-0x6a or even a more complex operand such as the channel
number for 0x67.
Any suggestion on how to implement these correctly?
...
+ /* 0x6e-0x70: Reserved */
+ { 0x71, KEY_BLUE }, /* XXX CEC Spec: F1 (Blue) */
+ { 0x72, KEY_RED }, /* XXX CEC Spec: F2 (Red) */
+ { 0x73, KEY_GREEN }, /* XXX CEC Spec: F3 (Green) */
+ { 0x74, KEY_YELLOW }, /* XXX CEC Spec: F4 (Yellow) */
+ { 0x75, KEY_F5 },
+ { 0x76, KEY_CONNECT }, /* XXX CEC Spec: Data - see Note 3 */
+ /* Note 3: This is used, for example, to enter or leave a digital
TV
+* data broadcast application. */
[snip]
Best wishes,
--
Kamil Debski
Samsung RD Institute Poland
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2 2/7] media: rc: Add cec protocol handling
Em Wed, 11 Mar 2015 12:24:53 +0100
Kamil Debski k.deb...@samsung.com escreveu:
Hi Mauro,
I have some more comments/questions below.
From: Mauro Carvalho Chehab [mailto:mche...@osg.samsung.com]
Sent: Sunday, March 08, 2015 3:21 PM
Em Thu, 22 Jan 2015 17:04:34 +0100
Kamil Debski k.deb...@samsung.com escreveu:
(c/c linux-input ML)
Add cec protocol handling the RC framework.
I added some comments, that reflects my understanding from what's there
at the keymap definitions found at:
http://xtreamerdev.googlecode.com/files/CEC_Specs.pdf
Signed-off-by: Kamil Debski k.deb...@samsung.com
---
drivers/media/rc/keymaps/Makefile |1 +
drivers/media/rc/keymaps/rc-cec.c | 133
+
drivers/media/rc/rc-main.c|1 +
include/media/rc-core.h |1 +
include/media/rc-map.h|5 +-
5 files changed, 140 insertions(+), 1 deletion(-) create mode
[snip]
+ { 0x60, KEY_PLAY }, /* XXX CEC Spec: Play Function */
+ { 0x61, KEY_PLAYPAUSE }, /* XXX CEC Spec: Pause-Play Function */
+ { 0x62, KEY_RECORD }, /* XXX CEC Spec: Record Function */
+ { 0x63, KEY_PAUSE }, /* XXX CEC Spec: Pause-Record Function */
+ { 0x64, KEY_STOP }, /* XXX CEC Spec: Stop Function */
+ { 0x65, KEY_MUTE }, /* XXX CEC Spec: Mute Function */
+ /* 0x66: CEC Spec: Restore Volume Function */
+ { 0x67, KEY_TUNER }, /* XXX CEC Spec: Tune Function */
+ { 0x68, KEY_MEDIA }, /* CEC Spec: Select Media Function */
+ { 0x69, KEY_SWITCHVIDEOMODE} /* XXX CEC Spec: Select A/V Input
Function */,
+ { 0x6a, KEY_AUDIO} /* CEC Spec: Select Audio Input Function */,
+ { 0x6b, KEY_POWER} /* CEC Spec: Power Toggle Function */,
+ { 0x6c, KEY_SLEEP} /* XXX CEC Spec: Power Off Function */,
+ { 0x6d, KEY_WAKEUP} /* XXX CEC Spec: Power On Function */,
Those function keycodes look weird. What's the difference between
those and the pure non-function variants?
The note 2 applies to most of these function buttons. It says:
2 During a recording or timed recording, a device may ask the user
for confirmation of this action before executing it.
Ok. So, it seems that we need to add new keycodes for those function variants,
as they should be handled on a different way than the usual keycodes.
The spec (CEC 13.13.3) says that:
Unlike the other codes, which just pass remote control presses
to the target (often with manufacturer-specific results),
the Functions are deterministic, ie they specify exactly the
state
after executing these commands. Several of these also have
further
operands, specifying the function in more detail, immediately
following the relevant [UI Command] operand.
Some codes are actually compund ones. For example, 0x60 has a play
mode
operand. So, the actual mapping would be:
0x60 + 0x24 - play forward
0x61 + 0x20 - play reverse
...
(see CEC17 for operand descriptions)
So, IMHO, the mapping should be
{ 0x6024, KEY_PLAY },
{ 0x6020, KEY_PLAY_REVERSE }, // to be created
The note 1 says that they can be issued without the additional operand
specified:
1 Functions with additional operands may also be used without the
additional operand: in this case the behavior is manufacturer-specific.
Will this do?
{ 0x60, KEY_PLAY },
{ 0x6024, KEY_PLAY },
{ 0x6020, KEY_PLAY_REVERSE }, // to be created
Or will the framework get confused that an incomplete key code was
received?
The above should work.
Another question I have is about the following operations:
0x67 Tune Function
0x68 Select Media Function
0x69 Select A/V Input Function
0x6a Select Audio Input Function
These operations take an additional operand that is large number.
1-255 for 0x68-0x6a or even a more complex operand such as the channel
number for 0x67.
Any suggestion on how to implement these correctly?
Well, the scancode may have any size. The current rc core implementation
is limited to u64. The scancode seek uses binary search, so it should
be fast, even for a big 64 bits table.
So, supporting a big number is not an issue to the core.
For the channel number, however, I suspect that we need to think on a
better alternative, like sending a sequence of numeric keycodes.
Maybe Dmitry has a better suggestion.
...
+ /* 0x6e-0x70: Reserved */
+ { 0x71, KEY_BLUE }, /* XXX CEC Spec: F1 (Blue) */
+ { 0x72, KEY_RED }, /* XXX CEC Spec: F2 (Red) */
+ { 0x73, KEY_GREEN }, /* XXX CEC Spec: F3 (Green) */
+ { 0x74, KEY_YELLOW }, /* XXX CEC Spec: F4 (Yellow) */
+ { 0x75, KEY_F5 },
+ { 0x76, KEY_CONNECT }, /* XXX CEC Spec: Data - see Note 3 */
+ /* Note 3: This is used, for example, to enter or leave a digital
TV
+ * data broadcast application. */
[snip]
Best wishes,
--
Cheers,
Mauro
--
To unsubscribe from this list: send the line unsubscribe
RE: [RFC v2 2/7] media: rc: Add cec protocol handling
Hi Bastien, From: Bastien Nocera [mailto:had...@hadess.net] Sent: Monday, March 09, 2015 5:44 PM On Mon, 2015-03-09 at 17:22 +0100, Kamil Debski wrote: Hi Mauro, From: Mauro Carvalho Chehab [mailto:mche...@osg.samsung.com] Sent: Sunday, March 08, 2015 3:21 PM Em Thu, 22 Jan 2015 17:04:34 +0100 Kamil Debski k.deb...@samsung.com escreveu: (c/c linux-input ML) Add cec protocol handling the RC framework. I added some comments, that reflects my understanding from what's there at the keymap definitions found at: http://xtreamerdev.googlecode.com/files/CEC_Specs.pdf Thank you very much for the review, Mauro. Your comments are very much appreciated. How does one use this new support? If I plug in my laptop to my TV, will using the TV's remote automatically send those key events to the laptop? It depends on the hardware that is used in your laptop to handle HDMI. If there is hardware support for CEC then this framework can be used to create a driver for the laptop's HDMI hardware. Then the laptop will be able to communicate with the TV over CEC - this includes receiving key events from the TV. Currently there are some CEC devices (and drivers) that enable Linux to use CEC, but there is no generic framework for CEC in the Linux kernel. My goal is to introduce such a framework, such that userspace application could work with different hardware using the same interface. Getting back to your question - using this framework. There should be some initialization done by a user space application: - enabling CEC (if needed by the hardware/driver) - configuring the connection (e.g. what kind of device should the laptop appear as, request the TV to pass remote control keys, etc.) - the TV will also send other CEC messages to the laptop, hence the application should listen for such messages and act accordingly How this should be done userspace? Definitely, it would be a good idea to use a library. Maybe a deamon that does the steps mentioned above would be a good idea? I am working on a simple library implementation that would wrap the kernel ioctls and provide a more user friendly API. Best wishes, -- Kamil Debski Samsung RD Institute Poland -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2 2/7] media: rc: Add cec protocol handling
On 03/10/2015 01:02 PM, Kamil Debski wrote: Hi Bastien, From: Bastien Nocera [mailto:had...@hadess.net] Sent: Monday, March 09, 2015 5:44 PM On Mon, 2015-03-09 at 17:22 +0100, Kamil Debski wrote: Hi Mauro, From: Mauro Carvalho Chehab [mailto:mche...@osg.samsung.com] Sent: Sunday, March 08, 2015 3:21 PM Em Thu, 22 Jan 2015 17:04:34 +0100 Kamil Debski k.deb...@samsung.com escreveu: (c/c linux-input ML) Add cec protocol handling the RC framework. I added some comments, that reflects my understanding from what's there at the keymap definitions found at: http://xtreamerdev.googlecode.com/files/CEC_Specs.pdf Thank you very much for the review, Mauro. Your comments are very much appreciated. How does one use this new support? If I plug in my laptop to my TV, will using the TV's remote automatically send those key events to the laptop? It depends on the hardware that is used in your laptop to handle HDMI. If there is hardware support for CEC then this framework can be used to create a driver for the laptop's HDMI hardware. Then the laptop will be able to communicate with the TV over CEC - this includes receiving key events from the TV. Currently there are some CEC devices (and drivers) that enable Linux to use CEC, but there is no generic framework for CEC in the Linux kernel. My goal is to introduce such a framework, such that userspace application could work with different hardware using the same interface. Getting back to your question - using this framework. There should be some initialization done by a user space application: - enabling CEC (if needed by the hardware/driver) - configuring the connection (e.g. what kind of device should the laptop appear as, request the TV to pass remote control keys, etc.) - the TV will also send other CEC messages to the laptop, hence the application should listen for such messages and act accordingly How this should be done userspace? Definitely, it would be a good idea to use a library. Maybe a deamon that does the steps mentioned above would be a good idea? I am working on a simple library implementation that would wrap the kernel ioctls and provide a more user friendly API. Let me add to this as the original designer of this framework: first of all the CEC protocol is a protocol from hell, very ad-hoc designed. The problem with that is that it very much depends on the product or device driver what - if anything - of the CEC protocol should be exposed to the end-user. You can decide to keep all the CEC handling in the driver, or do almost everything in userspace or anything in between. The hardware itself can be an HDMI receiver, transmitter or repeater, or it can be a USB dongle that controls the CEC bus between two HDMI devices. So even the subsystem involved in the device can be all over the place (usb, drm, v4l). So this CEC framework keeps the core protocol handling inside the kernel, and allows drivers to expose the CEC protocol to varying degrees to userspace. The pure CEC core commands should be handled in the kernel so no userspace components should be needed to get a valid working setup. A USB dongle might be an exception to that rule, I haven't looked at that in detail. On the userspace side of the CEC framework we might need a simple library. I'm not so sure about a daemon: that should definitely be optional. A standard cec-ctl utility to help test and control the CEC bus would be useful. I am also thinking that a cec-compliance test utility would be extremely useful to verify that drivers (and userspace) implement the CEC commands correctly. Since CEC is a bit of a disaster, such a tool would help a lot. Time permitting this is something I might work on myself. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2 2/7] media: rc: Add cec protocol handling
On Tue, 2015-03-10 at 13:02 +0100, Kamil Debski wrote: Hi Bastien, From: Bastien Nocera [mailto:had...@hadess.net] Sent: Monday, March 09, 2015 5:44 PM On Mon, 2015-03-09 at 17:22 +0100, Kamil Debski wrote: Hi Mauro, From: Mauro Carvalho Chehab [mailto:mche...@osg.samsung.com] Sent: Sunday, March 08, 2015 3:21 PM Em Thu, 22 Jan 2015 17:04:34 +0100 Kamil Debski k.deb...@samsung.com escreveu: (c/c linux-input ML) Add cec protocol handling the RC framework. I added some comments, that reflects my understanding from what's there at the keymap definitions found at: http://xtreamerdev.googlecode.com/files/CEC_Specs.pdf Thank you very much for the review, Mauro. Your comments are very much appreciated. How does one use this new support? If I plug in my laptop to my TV, will using the TV's remote automatically send those key events to the laptop? It depends on the hardware that is used in your laptop to handle HDMI. If there is hardware support for CEC then this framework can be used to create a driver for the laptop's HDMI hardware. Then the laptop will be able to communicate with the TV over CEC - this includes receiving key events from the TV. Currently there are some CEC devices (and drivers) that enable Linux to use CEC, but there is no generic framework for CEC in the Linux kernel. My goal is to introduce such a framework, such that userspace application could work with different hardware using the same interface. Getting back to your question - using this framework. There should be some initialization done by a user space application: - enabling CEC (if needed by the hardware/driver) I have 2 machines that this could work on, a Intel Baytrail tablet, and a laptop with Intel Haswell. Is that part going to be covered by your library, or will there be a drm API for that? - configuring the connection (e.g. what kind of device should the laptop appear as, request the TV to pass remote control keys, etc.) That's done through the CEC API as well? - the TV will also send other CEC messages to the laptop, hence the application should listen for such messages and act accordingly That's easier to deal with :) Something like LIRC can be used in the short-term. How this should be done userspace? Definitely, it would be a good idea to use a library. Maybe a deamon that does the steps mentioned above would be a good idea? I am working on a simple library implementation that would wrap the kernel ioctls and provide a more user friendly API. Great. Do drop me a mail when you have something that I could test. Cheers -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC v2 2/7] media: rc: Add cec protocol handling
From: Bastien Nocera [mailto:had...@hadess.net] Sent: Tuesday, March 10, 2015 3:15 PM On Tue, 2015-03-10 at 13:02 +0100, Kamil Debski wrote: Hi Bastien, From: Bastien Nocera [mailto:had...@hadess.net] Sent: Monday, March 09, 2015 5:44 PM On Mon, 2015-03-09 at 17:22 +0100, Kamil Debski wrote: Hi Mauro, From: Mauro Carvalho Chehab [mailto:mche...@osg.samsung.com] Sent: Sunday, March 08, 2015 3:21 PM Em Thu, 22 Jan 2015 17:04:34 +0100 Kamil Debski k.deb...@samsung.com escreveu: (c/c linux-input ML) Add cec protocol handling the RC framework. I added some comments, that reflects my understanding from what's there at the keymap definitions found at: http://xtreamerdev.googlecode.com/files/CEC_Specs.pdf Thank you very much for the review, Mauro. Your comments are very much appreciated. How does one use this new support? If I plug in my laptop to my TV, will using the TV's remote automatically send those key events to the laptop? It depends on the hardware that is used in your laptop to handle HDMI. If there is hardware support for CEC then this framework can be used to create a driver for the laptop's HDMI hardware. Then the laptop will be able to communicate with the TV over CEC - this includes receiving key events from the TV. Currently there are some CEC devices (and drivers) that enable Linux to use CEC, but there is no generic framework for CEC in the Linux kernel. My goal is to introduce such a framework, such that userspace application could work with different hardware using the same interface. Getting back to your question - using this framework. There should be some initialization done by a user space application: - enabling CEC (if needed by the hardware/driver) I have 2 machines that this could work on, a Intel Baytrail tablet, and a laptop with Intel Haswell. Is that part going to be covered by your library, or will there be a drm API for that? Enabling CEC is done by the CEC framework. The idea is to have it independent of other frameworks (such as drm, or v4l2). - configuring the connection (e.g. what kind of device should the laptop appear as, request the TV to pass remote control keys, etc.) That's done through the CEC API as well? Yes. - the TV will also send other CEC messages to the laptop, hence the application should listen for such messages and act accordingly That's easier to deal with :) Something like LIRC can be used in the short-term. How this should be done userspace? Definitely, it would be a good idea to use a library. Maybe a deamon that does the steps mentioned above would be a good idea? I am working on a simple library implementation that would wrap the kernel ioctls and provide a more user friendly API. Great. Do drop me a mail when you have something that I could test. Will do. Cheers Best wishes, -- Kamil Debski Samsung RD Institute Poland -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC v2 2/7] media: rc: Add cec protocol handling
Hi Mauro,
From: Mauro Carvalho Chehab [mailto:mche...@osg.samsung.com]
Sent: Sunday, March 08, 2015 3:21 PM
Em Thu, 22 Jan 2015 17:04:34 +0100
Kamil Debski k.deb...@samsung.com escreveu:
(c/c linux-input ML)
Add cec protocol handling the RC framework.
I added some comments, that reflects my understanding from what's there
at the keymap definitions found at:
http://xtreamerdev.googlecode.com/files/CEC_Specs.pdf
Thank you very much for the review, Mauro. Your comments are very much
appreciated.
Signed-off-by: Kamil Debski k.deb...@samsung.com
---
drivers/media/rc/keymaps/Makefile |1 +
drivers/media/rc/keymaps/rc-cec.c | 133
+
drivers/media/rc/rc-main.c|1 +
include/media/rc-core.h |1 +
include/media/rc-map.h|5 +-
5 files changed, 140 insertions(+), 1 deletion(-) create mode
100644
drivers/media/rc/keymaps/rc-cec.c
diff --git a/drivers/media/rc/keymaps/Makefile
b/drivers/media/rc/keymaps/Makefile
index abf6079..56f10d6 100644
--- a/drivers/media/rc/keymaps/Makefile
+++ b/drivers/media/rc/keymaps/Makefile
@@ -18,6 +18,7 @@ obj-$(CONFIG_RC_MAP) += rc-adstech-dvb-t-pci.o \
rc-behold.o \
rc-behold-columbus.o \
rc-budget-ci-old.o \
+ rc-cec.o \
rc-cinergy-1400.o \
rc-cinergy.o \
rc-delock-61959.o \
diff --git a/drivers/media/rc/keymaps/rc-cec.c
b/drivers/media/rc/keymaps/rc-cec.c
new file mode 100644
index 000..f2826c5
--- /dev/null
+++ b/drivers/media/rc/keymaps/rc-cec.c
@@ -0,0 +1,133 @@
+/* Keytable for the CEC remote control
+ *
+ * Copyright (c) 2015 by Kamil Debski
+ *
+ * This program is free software; you can redistribute it and/or
+modify
+ * it under the terms of the GNU General Public License as published
+by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include media/rc-map.h
+#include linux/module.h
+
+/* CEC Spec High-Definition Multimedia Interface Specification can
+be obtained
+ * here: http://xtreamerdev.googlecode.com/files/CEC_Specs.pdf
+ * The list of control codes is listed in Table 27: User Control
+Codes p. 95 */
+
+static struct rc_map_table cec[] = {
+ { 0x00, KEY_SELECT }, /* XXX CEC Spec: Select, should it be
+KEY_SELECT or KEY_OK? */
KEY_OK is better, IMHO.
+ { 0x01, KEY_UP },
+ { 0x02, KEY_DOWN },
+ { 0x03, KEY_LEFT },
+ { 0x04, KEY_RIGHT },
+ /* XXX 0x05-0x08 CEC Spec: Right-Up, Right-Down, Left-Up, Left-
Down
+*/
I think you need to send a patch to linux-input, in order to add those
keycodes.
+ { 0x09, KEY_CONTEXT_MENU }, /* CEC Spec: Root Menu - see Note 2
*/
+ /* Note 2: This is the initial display that a device shows. It is
+* device-dependent and can be, for example, a contents menu,
setup
+* menu, favorite menu or other menu. The actual menu displayed
+* may also depend on the device’s current state. */
+ { 0x0a, KEY_SETUP },
+ { 0x0b, KEY_MENU }, /* CEC Spec: Contents Menu */
+ { 0x0c, KEY_FAVORITES }, /* CEC Spec: Favorite Menu */
+ { 0x0d, KEY_EXIT },
+ /* 0x0e-0x1f: Reserved */
+ /* 0x20-0x29: Keys 0 to 9 */
+ { 0x20, KEY_0 },
+ { 0x21, KEY_1 },
+ { 0x22, KEY_2 },
+ { 0x23, KEY_3 },
+ { 0x24, KEY_4 },
+ { 0x25, KEY_5 },
+ { 0x26, KEY_6 },
+ { 0x27, KEY_7 },
+ { 0x28, KEY_8 },
+ { 0x29, KEY_9 },
Better to use KEY_NUMERIC_* here, as this is not affected by the shift
state.
+ { 0x2a, KEY_DOT },
+ { 0x2b, KEY_ENTER },
+ { 0x2c, KEY_CLEAR },
+ /* 0x2d-0x2e: Reserved */
+ /* XXX 0x2f: CEC Spec: Next Favorite */
Again another addition to Linux keystroke codes.
+ { 0x30, KEY_CHANNELUP },
+ { 0x31, KEY_CHANNELDOWN },
+ { 0x32, KEY_PREVIOUS }, /* CEC Spec: Previous Channel */
+ { 0x33, KEY_SOUND }, /* CEC Spec: Sound Select */
+ /* XXX 0x34: CEC Spec: Input Select */
Another key to be added. Yet, other keymaps have a key to select the
input source. Most use KEY_VIDEO, to select the video input source, and
KEY_AUDIO, to select the audio input source.
So, KEY_VIDEO is likely the best choice here.
+ { 0x35, KEY_INFO }, /* CEC Spec: Display Information */
+ { 0x36, KEY_HELP },
+ { 0x37, KEY_PAGEUP },
+ { 0x38, KEY_PAGEDOWN },
+ /* 0x39-0x3f: Reserved */
+ { 0x40, KEY_POWER },
+ { 0x41, KEY_VOLUMEUP },
+ { 0x42, KEY_VOLUMEDOWN },
+ { 0x43, KEY_MUTE },
+ { 0x44, KEY_PLAY },
+ { 0x45, KEY_STOP }, /* XXX CEC Spec: Stop, what about KEY_STOPCD?
*/
+ { 0x46, KEY_PAUSE },/* XXX CEC Spec: Pause, what about
KEY_PAUSECD?
+*/
The CD variants are to control the CD player on multimedia keyboards I
think.
only two IR maps
Re: [RFC v2 2/7] media: rc: Add cec protocol handling
On Mon, 2015-03-09 at 17:22 +0100, Kamil Debski wrote: Hi Mauro, From: Mauro Carvalho Chehab [mailto:mche...@osg.samsung.com] Sent: Sunday, March 08, 2015 3:21 PM Em Thu, 22 Jan 2015 17:04:34 +0100 Kamil Debski k.deb...@samsung.com escreveu: (c/c linux-input ML) Add cec protocol handling the RC framework. I added some comments, that reflects my understanding from what's there at the keymap definitions found at: http://xtreamerdev.googlecode.com/files/CEC_Specs.pdf Thank you very much for the review, Mauro. Your comments are very much appreciated. How does one use this new support? If I plug in my laptop to my TV, will using the TV's remote automatically send those key events to the laptop? Cheers -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2 2/7] media: rc: Add cec protocol handling
Em Thu, 22 Jan 2015 17:04:34 +0100
Kamil Debski k.deb...@samsung.com escreveu:
(c/c linux-input ML)
Add cec protocol handling the RC framework.
I added some comments, that reflects my understanding from what's there at
the keymap definitions found at:
http://xtreamerdev.googlecode.com/files/CEC_Specs.pdf
Signed-off-by: Kamil Debski k.deb...@samsung.com
---
drivers/media/rc/keymaps/Makefile |1 +
drivers/media/rc/keymaps/rc-cec.c | 133
+
drivers/media/rc/rc-main.c|1 +
include/media/rc-core.h |1 +
include/media/rc-map.h|5 +-
5 files changed, 140 insertions(+), 1 deletion(-)
create mode 100644 drivers/media/rc/keymaps/rc-cec.c
diff --git a/drivers/media/rc/keymaps/Makefile
b/drivers/media/rc/keymaps/Makefile
index abf6079..56f10d6 100644
--- a/drivers/media/rc/keymaps/Makefile
+++ b/drivers/media/rc/keymaps/Makefile
@@ -18,6 +18,7 @@ obj-$(CONFIG_RC_MAP) += rc-adstech-dvb-t-pci.o \
rc-behold.o \
rc-behold-columbus.o \
rc-budget-ci-old.o \
+ rc-cec.o \
rc-cinergy-1400.o \
rc-cinergy.o \
rc-delock-61959.o \
diff --git a/drivers/media/rc/keymaps/rc-cec.c
b/drivers/media/rc/keymaps/rc-cec.c
new file mode 100644
index 000..f2826c5
--- /dev/null
+++ b/drivers/media/rc/keymaps/rc-cec.c
@@ -0,0 +1,133 @@
+/* Keytable for the CEC remote control
+ *
+ * Copyright (c) 2015 by Kamil Debski
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include media/rc-map.h
+#include linux/module.h
+
+/* CEC Spec High-Definition Multimedia Interface Specification can be
obtained
+ * here: http://xtreamerdev.googlecode.com/files/CEC_Specs.pdf
+ * The list of control codes is listed in Table 27: User Control Codes p. 95
*/
+
+static struct rc_map_table cec[] = {
+ { 0x00, KEY_SELECT }, /* XXX CEC Spec: Select, should it be KEY_SELECT
or KEY_OK? */
KEY_OK is better, IMHO.
+ { 0x01, KEY_UP },
+ { 0x02, KEY_DOWN },
+ { 0x03, KEY_LEFT },
+ { 0x04, KEY_RIGHT },
+ /* XXX 0x05-0x08 CEC Spec: Right-Up, Right-Down, Left-Up, Left-Down */
I think you need to send a patch to linux-input, in order to add those
keycodes.
+ { 0x09, KEY_CONTEXT_MENU }, /* CEC Spec: Root Menu - see Note 2 */
+ /* Note 2: This is the initial display that a device shows. It is
+ * device-dependent and can be, for example, a contents menu, setup
+ * menu, favorite menu or other menu. The actual menu displayed
+ * may also depend on the device’s current state. */
+ { 0x0a, KEY_SETUP },
+ { 0x0b, KEY_MENU }, /* CEC Spec: Contents Menu */
+ { 0x0c, KEY_FAVORITES }, /* CEC Spec: Favorite Menu */
+ { 0x0d, KEY_EXIT },
+ /* 0x0e-0x1f: Reserved */
+ /* 0x20-0x29: Keys 0 to 9 */
+ { 0x20, KEY_0 },
+ { 0x21, KEY_1 },
+ { 0x22, KEY_2 },
+ { 0x23, KEY_3 },
+ { 0x24, KEY_4 },
+ { 0x25, KEY_5 },
+ { 0x26, KEY_6 },
+ { 0x27, KEY_7 },
+ { 0x28, KEY_8 },
+ { 0x29, KEY_9 },
Better to use KEY_NUMERIC_* here, as this is not affected by the
shift state.
+ { 0x2a, KEY_DOT },
+ { 0x2b, KEY_ENTER },
+ { 0x2c, KEY_CLEAR },
+ /* 0x2d-0x2e: Reserved */
+ /* XXX 0x2f: CEC Spec: Next Favorite */
Again another addition to Linux keystroke codes.
+ { 0x30, KEY_CHANNELUP },
+ { 0x31, KEY_CHANNELDOWN },
+ { 0x32, KEY_PREVIOUS }, /* CEC Spec: Previous Channel */
+ { 0x33, KEY_SOUND }, /* CEC Spec: Sound Select */
+ /* XXX 0x34: CEC Spec: Input Select */
Another key to be added. Yet, other keymaps have a key to select the
input source. Most use KEY_VIDEO, to select the video input source,
and KEY_AUDIO, to select the audio input source.
So, KEY_VIDEO is likely the best choice here.
+ { 0x35, KEY_INFO }, /* CEC Spec: Display Information */
+ { 0x36, KEY_HELP },
+ { 0x37, KEY_PAGEUP },
+ { 0x38, KEY_PAGEDOWN },
+ /* 0x39-0x3f: Reserved */
+ { 0x40, KEY_POWER },
+ { 0x41, KEY_VOLUMEUP },
+ { 0x42, KEY_VOLUMEDOWN },
+ { 0x43, KEY_MUTE },
+ { 0x44, KEY_PLAY },
+ { 0x45, KEY_STOP }, /* XXX CEC Spec: Stop, what about KEY_STOPCD? */
+ { 0x46, KEY_PAUSE },/* XXX CEC Spec: Pause, what about KEY_PAUSECD? */
The CD variants are to control the CD player on multimedia keyboards I think.
only two IR maps use it. All the rest uses KEY_STOP/KEY_PAUSE.
+ { 0x47, KEY_RECORD },
+ { 0x48, KEY_REWIND },
+ { 0x49, KEY_FASTFORWARD },
+ { 0x4a, KEY_EJECTCD }, /* CEC Spec: Eject */
+ { 0x4b, KEY_FORWARD },
+ { 0x4c,
[RFC v2 2/7] media: rc: Add cec protocol handling
Add cec protocol handling the RC framework.
Signed-off-by: Kamil Debski k.deb...@samsung.com
---
drivers/media/rc/keymaps/Makefile |1 +
drivers/media/rc/keymaps/rc-cec.c | 133 +
drivers/media/rc/rc-main.c|1 +
include/media/rc-core.h |1 +
include/media/rc-map.h|5 +-
5 files changed, 140 insertions(+), 1 deletion(-)
create mode 100644 drivers/media/rc/keymaps/rc-cec.c
diff --git a/drivers/media/rc/keymaps/Makefile
b/drivers/media/rc/keymaps/Makefile
index abf6079..56f10d6 100644
--- a/drivers/media/rc/keymaps/Makefile
+++ b/drivers/media/rc/keymaps/Makefile
@@ -18,6 +18,7 @@ obj-$(CONFIG_RC_MAP) += rc-adstech-dvb-t-pci.o \
rc-behold.o \
rc-behold-columbus.o \
rc-budget-ci-old.o \
+ rc-cec.o \
rc-cinergy-1400.o \
rc-cinergy.o \
rc-delock-61959.o \
diff --git a/drivers/media/rc/keymaps/rc-cec.c
b/drivers/media/rc/keymaps/rc-cec.c
new file mode 100644
index 000..f2826c5
--- /dev/null
+++ b/drivers/media/rc/keymaps/rc-cec.c
@@ -0,0 +1,133 @@
+/* Keytable for the CEC remote control
+ *
+ * Copyright (c) 2015 by Kamil Debski
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include media/rc-map.h
+#include linux/module.h
+
+/* CEC Spec High-Definition Multimedia Interface Specification can be
obtained
+ * here: http://xtreamerdev.googlecode.com/files/CEC_Specs.pdf
+ * The list of control codes is listed in Table 27: User Control Codes p. 95 */
+
+static struct rc_map_table cec[] = {
+ { 0x00, KEY_SELECT }, /* XXX CEC Spec: Select, should it be KEY_SELECT
or KEY_OK? */
+ { 0x01, KEY_UP },
+ { 0x02, KEY_DOWN },
+ { 0x03, KEY_LEFT },
+ { 0x04, KEY_RIGHT },
+ /* XXX 0x05-0x08 CEC Spec: Right-Up, Right-Down, Left-Up, Left-Down */
+ { 0x09, KEY_CONTEXT_MENU }, /* CEC Spec: Root Menu - see Note 2 */
+ /* Note 2: This is the initial display that a device shows. It is
+* device-dependent and can be, for example, a contents menu, setup
+* menu, favorite menu or other menu. The actual menu displayed
+* may also depend on the device’s current state. */
+ { 0x0a, KEY_SETUP },
+ { 0x0b, KEY_MENU }, /* CEC Spec: Contents Menu */
+ { 0x0c, KEY_FAVORITES }, /* CEC Spec: Favorite Menu */
+ { 0x0d, KEY_EXIT },
+ /* 0x0e-0x1f: Reserved */
+ /* 0x20-0x29: Keys 0 to 9 */
+ { 0x20, KEY_0 },
+ { 0x21, KEY_1 },
+ { 0x22, KEY_2 },
+ { 0x23, KEY_3 },
+ { 0x24, KEY_4 },
+ { 0x25, KEY_5 },
+ { 0x26, KEY_6 },
+ { 0x27, KEY_7 },
+ { 0x28, KEY_8 },
+ { 0x29, KEY_9 },
+ { 0x2a, KEY_DOT },
+ { 0x2b, KEY_ENTER },
+ { 0x2c, KEY_CLEAR },
+ /* 0x2d-0x2e: Reserved */
+ /* XXX 0x2f: CEC Spec: Next Favorite */
+ { 0x30, KEY_CHANNELUP },
+ { 0x31, KEY_CHANNELDOWN },
+ { 0x32, KEY_PREVIOUS }, /* CEC Spec: Previous Channel */
+ { 0x33, KEY_SOUND }, /* CEC Spec: Sound Select */
+ /* XXX 0x34: CEC Spec: Input Select */
+ { 0x35, KEY_INFO }, /* CEC Spec: Display Information */
+ { 0x36, KEY_HELP },
+ { 0x37, KEY_PAGEUP },
+ { 0x38, KEY_PAGEDOWN },
+ /* 0x39-0x3f: Reserved */
+ { 0x40, KEY_POWER },
+ { 0x41, KEY_VOLUMEUP },
+ { 0x42, KEY_VOLUMEDOWN },
+ { 0x43, KEY_MUTE },
+ { 0x44, KEY_PLAY },
+ { 0x45, KEY_STOP }, /* XXX CEC Spec: Stop, what about KEY_STOPCD? */
+ { 0x46, KEY_PAUSE },/* XXX CEC Spec: Pause, what about KEY_PAUSECD? */
+ { 0x47, KEY_RECORD },
+ { 0x48, KEY_REWIND },
+ { 0x49, KEY_FASTFORWARD },
+ { 0x4a, KEY_EJECTCD }, /* CEC Spec: Eject */
+ { 0x4b, KEY_FORWARD },
+ { 0x4c, }, /* XXX */
+ { 0x4d, KEY_STOP }, /* XXX CEC Spec: Stop-Record, what about
KEY_STOPCD? */
+ { 0x4e, KEY_PAUSE }, /* XXX CEC Spec: Pause-Record, what about
KEY_PAUSECD? */
+ /* 0x4f: Reserved */
+ { 0x50, KEY_ANGLE },
+ { 0x51, KEY_SUBTITLE }, /* XXX CEC Spec: Sub picture, should it be
KEY_SUBTITLE or something else? */
+ { 0x52, KEY_VIDEO }, /* XXX CEC Spec: Video on Demand / input.h: AL
Movie Browser, maybe KEY_DIRECTORY? */
+ { 0x53, KEY_EPG },
+ { 0x54, KEY_TIME }, /* XXX CEC Spec: Timer */
+ { 0x55, KEY_CONFIG },
+ /* 0x56-0x5f: Reserved */
+ { 0x60, KEY_PLAY }, /* XXX CEC Spec: Play Function */
+ { 0x61, KEY_PLAYPAUSE }, /* XXX CEC Spec: Pause-Play Function */
+ { 0x62, KEY_RECORD }, /* XXX CEC Spec: Record Function */
+ { 0x63, KEY_PAUSE }, /* XXX CEC Spec: Pause-Record
