Re: [GIT PULL for v3.5-rc1] media updates for v3.5
25.05.2012 18:21, Mauro Carvalho Chehab kirjoitti: > Em 25-05-2012 11:49, Anssi Hannula escreveu: >> 25.05.2012 15:12, Mauro Carvalho Chehab kirjoitti: >>> Em 24-05-2012 19:40, Linus Torvalds escreveu: >>>> On Thu, May 24, 2012 at 3:33 PM, Mauro Carvalho Chehab >>>> wrote: >>>>> >>>>> The Kconfig default for DVB_FE_CUSTOMISE is 'n'. So, if no DVB bridge is >>>>> selected, >>>>> nothing will be compiled. >>>> >>>> Sadly, it looks like the default for distro kernels is 'y'. >>> >>> I'll change the default on Fedora (f16/f17/rawhide). >>> >>>> Which means that if you start with a distro kernel config, and then >>>> try to cut it down to match your system, you end up screwed in the >>>> future - all the new hardware will default to on. >>>> >>>> At least that's how I noticed it. Very annoying. >>> >>> A simple way to solve it seems to make those options dependent on >>> CONFIG_EXPERT. >>> >>> Not sure if all usual distributions disable it, but I guess most won't have >>> EXPERT enabled. >>> >>> The enclosed patch does that. If nobody complains, I'll submit it together >>> with the next git pull request. >>> >>> Regards, >>> Mauro >>> >>> - >>> >>> [RFC PATCH] Make tuner/frontend options dependent on EXPERT >>> >>> The media CUSTOMISE options are there to allow embedded systems and advanced >>> users to disable tuner/frontends that are supported by a bridge driver to >>> be disabled, in order to save some disk space and memory, when compiled >>> builtin. >>> >>> However, distros are mistakenly enabling it, causing problems when a >>> make oldconfig is used. >>> >>> Make those options dependent on EXPERT, in order to avoid such annoyance >>> behavior. >>> >>> Signed-off-by: Mauro Carvalho Chehab >>> >>> diff --git a/drivers/media/common/tuners/Kconfig >>> b/drivers/media/common/tuners/Kconfig >>> index bbf4945..702a3bf 100644 >>> --- a/drivers/media/common/tuners/Kconfig >>> +++ b/drivers/media/common/tuners/Kconfig >>> @@ -35,6 +35,7 @@ config MEDIA_TUNER >>> config MEDIA_TUNER_CUSTOMISE >>> bool "Customize analog and hybrid tuner modules to build" >>> depends on MEDIA_TUNER >>> + depends on EXPERT >>> default y if EXPERT >> ^^^ >> >> Hmm, why should CONFIG_EXPERT automatically mean that the tuner modules >> should be customized? I'd think this shouldn't default to y even with >> EXPERT. >> >> Not a biggie, just thought I'd point it out :) >> >> (as a sidenote, on Mageia kernels CONFIG_EXPERT is on... didn't check >> why, could be just historical reasons) >> >>> help >>> This allows the user to deselect tuner drivers unnecessary >>> diff --git a/drivers/media/dvb/frontends/Kconfig >>> b/drivers/media/dvb/frontends/Kconfig >>> index b98ebb2..6d3c2f7 100644 >>> --- a/drivers/media/dvb/frontends/Kconfig >>> +++ b/drivers/media/dvb/frontends/Kconfig >>> @@ -1,6 +1,7 @@ >>> config DVB_FE_CUSTOMISE >>> bool "Customise the frontend modules to build" >>> depends on DVB_CORE >>> + depends on EXPERT >>> default y if EXPERT >> >> Ditto. >> >>> help >>> This allows the user to select/deselect frontend drivers for their >> > > This was added on the changeset b3fc1782c8 (see below). A latter changeset > (6a108a14fa3) > renamed EMBEDDED to EXPERT. > > For embedded systems, it makes more sense to customize the tuners/demods, in > order to > remove drivers that would never be used there. That's the rationale behind > this patch. > > From my side, I don't mind removing the "default y if EXPERT", but, as I > don't usually > work with embedded devices, I don't care much about that. It would be great > to hear > some comments from embedded people about that as well. OK. > That's said, it is weird that Mageia is using CONFIG_EXPERT. Are they using > those > two Kconfig options enabled as well? No, *_CUSTOMISE are unset. CC'd our kernel maintainer in case he remembers off-hand why CONFIG_EXPERT is enabled. > Regards, > Mauro > > - > > commit b3fc1782c8b84574e44cf5869c9afa75523e2db8 > Author: Guennadi Liakhovetski > Date: Thu Aug 5 18:09:28 2010 -0300 > > V4L/DVB: V4L: do not autoselect components on embedded systems > > Tuner, DVB frontend and video helper chip drivers are by default > autoselected by their respective host cards, this, however, doesn't make > much sense on SoC-based systems. Disable autoselection on EMBEDDED > systems. > > Signed-off-by: Guennadi Liakhovetski > Signed-off-by: Mauro Carvalho Chehab [...] -- Anssi Hannula -- 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: [GIT PULL for v3.5-rc1] media updates for v3.5
25.05.2012 15:12, Mauro Carvalho Chehab kirjoitti: > Em 24-05-2012 19:40, Linus Torvalds escreveu: >> On Thu, May 24, 2012 at 3:33 PM, Mauro Carvalho Chehab >> wrote: >>> >>> The Kconfig default for DVB_FE_CUSTOMISE is 'n'. So, if no DVB bridge is >>> selected, >>> nothing will be compiled. >> >> Sadly, it looks like the default for distro kernels is 'y'. > > I'll change the default on Fedora (f16/f17/rawhide). > >> Which means that if you start with a distro kernel config, and then >> try to cut it down to match your system, you end up screwed in the >> future - all the new hardware will default to on. >> >> At least that's how I noticed it. Very annoying. > > A simple way to solve it seems to make those options dependent on > CONFIG_EXPERT. > > Not sure if all usual distributions disable it, but I guess most won't have > EXPERT enabled. > > The enclosed patch does that. If nobody complains, I'll submit it together > with the next git pull request. > > Regards, > Mauro > > - > > [RFC PATCH] Make tuner/frontend options dependent on EXPERT > > The media CUSTOMISE options are there to allow embedded systems and advanced > users to disable tuner/frontends that are supported by a bridge driver to > be disabled, in order to save some disk space and memory, when compiled > builtin. > > However, distros are mistakenly enabling it, causing problems when a > make oldconfig is used. > > Make those options dependent on EXPERT, in order to avoid such annoyance > behavior. > > Signed-off-by: Mauro Carvalho Chehab > > diff --git a/drivers/media/common/tuners/Kconfig > b/drivers/media/common/tuners/Kconfig > index bbf4945..702a3bf 100644 > --- a/drivers/media/common/tuners/Kconfig > +++ b/drivers/media/common/tuners/Kconfig > @@ -35,6 +35,7 @@ config MEDIA_TUNER > config MEDIA_TUNER_CUSTOMISE > bool "Customize analog and hybrid tuner modules to build" > depends on MEDIA_TUNER > + depends on EXPERT > default y if EXPERT ^^^ Hmm, why should CONFIG_EXPERT automatically mean that the tuner modules should be customized? I'd think this shouldn't default to y even with EXPERT. Not a biggie, just thought I'd point it out :) (as a sidenote, on Mageia kernels CONFIG_EXPERT is on... didn't check why, could be just historical reasons) > help > This allows the user to deselect tuner drivers unnecessary > diff --git a/drivers/media/dvb/frontends/Kconfig > b/drivers/media/dvb/frontends/Kconfig > index b98ebb2..6d3c2f7 100644 > --- a/drivers/media/dvb/frontends/Kconfig > +++ b/drivers/media/dvb/frontends/Kconfig > @@ -1,6 +1,7 @@ > config DVB_FE_CUSTOMISE > bool "Customise the frontend modules to build" > depends on DVB_CORE > + depends on EXPERT > default y if EXPERT Ditto. > help > This allows the user to select/deselect frontend drivers for their -- Anssi Hannula -- 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
[PATCH 1/2] [media] ati_remote: add keymap for Medion X10 OR2x remotes
Add another Medion X10 remote keymap. This is for the Medion OR2x
remotes with the Windows MCE button.
The receiver shipped with this remote has the same USB ID as the other
Medion receivers, but the name is different and is therefore used to
detect this variant.
Signed-off-by: Anssi Hannula
---
drivers/media/rc/ati_remote.c | 30 ++-
drivers/media/rc/keymaps/Makefile |1 +
drivers/media/rc/keymaps/rc-medion-x10-or2x.c | 108 +
include/media/rc-map.h|1 +
4 files changed, 136 insertions(+), 4 deletions(-)
create mode 100644 drivers/media/rc/keymaps/rc-medion-x10-or2x.c
diff --git a/drivers/media/rc/ati_remote.c b/drivers/media/rc/ati_remote.c
index 26fa043..2c70352 100644
--- a/drivers/media/rc/ati_remote.c
+++ b/drivers/media/rc/ati_remote.c
@@ -161,11 +161,33 @@ static const char *get_medion_keymap(struct usb_interface
*interface)
{
struct usb_device *udev = interface_to_usbdev(interface);
- /* The receiver shipped with the "Digitainer" variant helpfully has
-* a single additional bit set in its descriptor. */
- if (udev->actconfig->desc.bmAttributes & USB_CONFIG_ATT_WAKEUP)
- return RC_MAP_MEDION_X10_DIGITAINER;
+ /*
+* There are many different Medion remotes shipped with a receiver
+* with the same usb id, but the receivers have subtle differences
+* in the USB descriptors allowing us to detect them.
+*/
+
+ if (udev->manufacturer && udev->product) {
+ if (udev->actconfig->desc.bmAttributes & USB_CONFIG_ATT_WAKEUP)
{
+
+ if (!strcmp(udev->manufacturer, "X10 Wireless
Technology Inc")
+ && !strcmp(udev->product, "USB Receiver"))
+ return RC_MAP_MEDION_X10_DIGITAINER;
+
+ if (!strcmp(udev->manufacturer, "X10 WTI")
+ && !strcmp(udev->product, "RF receiver"))
+ return RC_MAP_MEDION_X10_OR2X;
+ } else {
+
+if (!strcmp(udev->manufacturer, "X10 Wireless
Technology Inc")
+ && !strcmp(udev->product, "USB Receiver"))
+ return RC_MAP_MEDION_X10;
+ }
+ }
+ dev_info(&interface->dev,
+"Unknown Medion X10 receiver, using default ati_remote Medion
keymap\n");
+
return RC_MAP_MEDION_X10;
}
diff --git a/drivers/media/rc/keymaps/Makefile
b/drivers/media/rc/keymaps/Makefile
index c1d977c..975e130 100644
--- a/drivers/media/rc/keymaps/Makefile
+++ b/drivers/media/rc/keymaps/Makefile
@@ -50,6 +50,7 @@ obj-$(CONFIG_RC_MAP) += rc-adstech-dvb-t-pci.o \
rc-manli.o \
rc-medion-x10.o \
rc-medion-x10-digitainer.o \
+ rc-medion-x10-or2x.o \
rc-msi-digivox-ii.o \
rc-msi-digivox-iii.o \
rc-msi-tvanywhere.o \
diff --git a/drivers/media/rc/keymaps/rc-medion-x10-or2x.c
b/drivers/media/rc/keymaps/rc-medion-x10-or2x.c
new file mode 100644
index 000..b077300
--- /dev/null
+++ b/drivers/media/rc/keymaps/rc-medion-x10-or2x.c
@@ -0,0 +1,108 @@
+/*
+ * Medion X10 OR22/OR24 RF remote keytable
+ *
+ * Copyright (C) 2012 Anssi Hannula
+ *
+ * This keymap is for several Medion X10 remotes that have the Windows MCE
+ * button. This has been tested with a "RF VISTA Remote Control", OR24V,
+ * P/N 20035335, but should work with other variants that have the same
+ * buttons, such as OR22V and OR24E.
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+ */
+
+#include
+#include
+
+static struct rc_map_table medion_x10_or2x[] = {
+ { 0x02, KEY_POWER },
+ { 0x16, KEY_TEXT }, /* "T" in a box, for teletext */
+
+ { 0x09, KEY_VOLUMEUP },
+ { 0x08, KEY_VOLUMEDOWN },
+ { 0x00, KEY_MUTE },
+ { 0x0b, KEY_CHANNELUP },
+ { 0x0c, KEY_CHANNELDOWN },
+
+ { 0x32, KEY_RED },
+ { 0x
[PATCH 2/2] [media] ati_remote: add regular up/down buttons to Medion Digitainer keymap
There are many different Medion X10 remotes that need slightly different
keymaps. We may not yet have all the needed keymaps, in which case a
wrong keymap may be used. This happened with Medion X10 OR2x remotes
before the keymap for them was added, causing the ati_remote driver to
select the Medion Digitainer keymap instead. Unfortunately, the Medion
Digitainer keymap doesn't have the standard X10 up/down scancodes
assigned to KEY_UP and KEY_DOWN keycodes, making wrongly assigned
remotes mostly unusable.
Add the regular KEY_UP and KEY_DOWN scancodes to the Medion X10
Digitainer keymap, making any Medion remote mostly usable even when
wrongly used with that keymap (standard buttons, such as
up/down/left/right, 0-9, play/stop/pause, have the same scancode in all
the X10 remotes).
Signed-off-by: Anssi Hannula
---
drivers/media/rc/keymaps/rc-medion-x10-digitainer.c |8
1 file changed, 8 insertions(+)
diff --git a/drivers/media/rc/keymaps/rc-medion-x10-digitainer.c
b/drivers/media/rc/keymaps/rc-medion-x10-digitainer.c
index 0a5ce84..966f9b3 100644
--- a/drivers/media/rc/keymaps/rc-medion-x10-digitainer.c
+++ b/drivers/media/rc/keymaps/rc-medion-x10-digitainer.c
@@ -86,6 +86,14 @@ static struct rc_map_table medion_x10_digitainer[] = {
{ 0x14, KEY_8 },
{ 0x15, KEY_9 },
{ 0x17, KEY_0 },
+
+ /* these do not actually exist on this remote, but these scancodes
+* exist on all other Medion X10 remotes and adding them here allows
+* such remotes to be adequately usable with this keymap in case
+* this keymap is wrongly used with them (which is quite possible as
+* there are lots of different Medion X10 remotes): */
+ { 0x1a, KEY_UP },
+ { 0x22, KEY_DOWN },
};
static struct rc_map_list medion_x10_digitainer_map = {
--
1.7.10
--
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] HDMI-CEC proposal
12.04.2012 23:36, Oliver Schinagl kirjoitti: > Since a lot of video cards dont' support CEC at all (not even > connected), don't have hdmi, but work perfectly fine with dvi->hdmi > adapters, CEC can be implemented in many other ways (think media centers) > > One such exammple is using USB/Arduino > > http://code.google.com/p/cec-arduino/wiki/ElectricalInterface > > Having an AVR with v-usb code and cec code doesn't look all that hard > nor impossible, so one could simply have a USB plug on one end, and an > HDMI plug on the other end, utilizing only the CEC pins. > > This would make it more something like LIRC if anything. There already exists a device like this (USB CEC adapter with hdmi in/out) with open source userspace driver, developed for the XBMC Media Center (apparently MythTV is also supported): http://www.pulse-eight.com/store/products/104-usb-hdmi-cec-adapter.aspx http://libcec.pulse-eight.com/ https://github.com/Pulse-Eight/libcec -- Anssi Hannula -- 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
[PATCH 1/2] [media] ati_remote: allow specifying a default keymap selector function
Currently the ati_remote default keymap is selected directly based on
the USB device id.
Add support for instead specifying a function returning the default
keymap, allowing more complex selection logic to be added when needed.
This will be used for Medion X10 remotes in a following commit.
Signed-off-by: Anssi Hannula
---
drivers/media/rc/ati_remote.c | 36 ++--
1 file changed, 26 insertions(+), 10 deletions(-)
diff --git a/drivers/media/rc/ati_remote.c b/drivers/media/rc/ati_remote.c
index baf907b..7a35f7a 100644
--- a/drivers/media/rc/ati_remote.c
+++ b/drivers/media/rc/ati_remote.c
@@ -151,13 +151,23 @@ MODULE_PARM_DESC(mouse, "Enable mouse device, default =
yes");
#undef err
#define err(format, arg...) printk(KERN_ERR format , ## arg)
+struct ati_receiver_type {
+ /* either default_keymap or get_default_keymap should be set */
+ const char *default_keymap;
+ const char *(*get_default_keymap)(struct usb_interface *interface);
+};
+
+static const struct ati_receiver_type type_ati = { .default_keymap =
RC_MAP_ATI_X10 };
+static const struct ati_receiver_type type_medion = { .default_keymap =
RC_MAP_MEDION_X10 };
+static const struct ati_receiver_type type_firefly = { .default_keymap =
RC_MAP_SNAPSTREAM_FIREFLY };
+
static struct usb_device_id ati_remote_table[] = {
- { USB_DEVICE(ATI_REMOTE_VENDOR_ID, LOLA_REMOTE_PRODUCT_ID),
.driver_info = (unsigned long)RC_MAP_ATI_X10 },
- { USB_DEVICE(ATI_REMOTE_VENDOR_ID, LOLA2_REMOTE_PRODUCT_ID),
.driver_info = (unsigned long)RC_MAP_ATI_X10 },
- { USB_DEVICE(ATI_REMOTE_VENDOR_ID, ATI_REMOTE_PRODUCT_ID),
.driver_info = (unsigned long)RC_MAP_ATI_X10 },
- { USB_DEVICE(ATI_REMOTE_VENDOR_ID, NVIDIA_REMOTE_PRODUCT_ID),
.driver_info = (unsigned long)RC_MAP_ATI_X10 },
- { USB_DEVICE(ATI_REMOTE_VENDOR_ID, MEDION_REMOTE_PRODUCT_ID),
.driver_info = (unsigned long)RC_MAP_MEDION_X10 },
- { USB_DEVICE(ATI_REMOTE_VENDOR_ID, FIREFLY_REMOTE_PRODUCT_ID),
.driver_info = (unsigned long)RC_MAP_SNAPSTREAM_FIREFLY },
+ { USB_DEVICE(ATI_REMOTE_VENDOR_ID, LOLA_REMOTE_PRODUCT_ID),
.driver_info = (unsigned long)&type_ati },
+ { USB_DEVICE(ATI_REMOTE_VENDOR_ID, LOLA2_REMOTE_PRODUCT_ID),
.driver_info = (unsigned long)&type_ati },
+ { USB_DEVICE(ATI_REMOTE_VENDOR_ID, ATI_REMOTE_PRODUCT_ID),
.driver_info = (unsigned long)&type_ati },
+ { USB_DEVICE(ATI_REMOTE_VENDOR_ID, NVIDIA_REMOTE_PRODUCT_ID),
.driver_info = (unsigned long)&type_ati },
+ { USB_DEVICE(ATI_REMOTE_VENDOR_ID, MEDION_REMOTE_PRODUCT_ID),
.driver_info = (unsigned long)&type_medion },
+ { USB_DEVICE(ATI_REMOTE_VENDOR_ID, FIREFLY_REMOTE_PRODUCT_ID),
.driver_info = (unsigned long)&type_firefly },
{} /* Terminating entry */
};
@@ -766,6 +776,7 @@ static int ati_remote_probe(struct usb_interface
*interface, const struct usb_de
struct usb_device *udev = interface_to_usbdev(interface);
struct usb_host_interface *iface_host = interface->cur_altsetting;
struct usb_endpoint_descriptor *endpoint_in, *endpoint_out;
+ struct ati_receiver_type *type = (struct ati_receiver_type
*)id->driver_info;
struct ati_remote *ati_remote;
struct input_dev *input_dev;
struct rc_dev *rc_dev;
@@ -827,10 +838,15 @@ static int ati_remote_probe(struct usb_interface
*interface, const struct usb_de
snprintf(ati_remote->mouse_name, sizeof(ati_remote->mouse_name),
"%s mouse", ati_remote->rc_name);
- if (id->driver_info)
- rc_dev->map_name = (const char *)id->driver_info;
- else
- rc_dev->map_name = RC_MAP_ATI_X10;
+ rc_dev->map_name = RC_MAP_ATI_X10; /* default map */
+
+ /* set default keymap according to receiver model */
+ if (type) {
+ if (type->default_keymap)
+ rc_dev->map_name = type->default_keymap;
+ else if (type->get_default_keymap)
+ rc_dev->map_name = type->get_default_keymap(interface);
+ }
ati_remote_rc_init(ati_remote);
mutex_init(&ati_remote->open_mutex);
--
1.7.9.3
--
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
[PATCH 2/2] [media] ati_remote: add support for Medion X10 Digitainer remote
Add support for another Medion X10 remote. This was apparently
originally used with the Medion Digitainer box, but is now sold
separately without any Digitainer labeling.
A peculiarity of this remote is a scrollwheel in place of up/down
buttons. Each direction is mapped to 8 different scancodes, each
corresponding to 1..8 notches, allowing multiple notches to the same
direction to be transmitted in a single scancode. The driver transforms
the multi-notch scancodes to multiple events of the single-notch
scancode.
(0x70..0x77 = 1..8 notches down, 0x78..0x7f = 1..8 notches up)
Since the scrollwheel scancodes are the same that are used for mouse on
some other X10 (ati_remote) remotes, the driver will now check whether
the active keymap has a keycode defined for the single-notch scancode
when a mouse/scrollwheel scancode (0x70..0x7f) is received. If set,
scrollwheel is assumed, otherwise mouse is assumed.
This remote ships with a different receiver than the already supported
Medion X10 remote, but they share the same USB ID. The only difference
in the USB descriptors is that the Digitainer receiver has the Remote
Wakeup bit set in bmAttributes of the Configuration Descriptor.
Therefore that is used to select the default keymap.
Thanks to Stephan Raue from OpenELEC (www.openelec.tv) for providing me
both a Medion X10 Digitainer remote+receiver and an already supported
Medion X10 remote+receiver. Thanks to Martin Beyss for providing some
useful information about the remote (including the "Digitainer" name).
This patch has been tested by both of them and myself.
Signed-off-by: Anssi Hannula
Tested-by: Stephan Raue
Tested-by: Martin Beyss
---
drivers/media/rc/ati_remote.c | 90 ++-
drivers/media/rc/keymaps/Makefile |1 +
.../media/rc/keymaps/rc-medion-x10-digitainer.c| 115
include/media/rc-map.h |1 +
4 files changed, 179 insertions(+), 28 deletions(-)
create mode 100644 drivers/media/rc/keymaps/rc-medion-x10-digitainer.c
diff --git a/drivers/media/rc/ati_remote.c b/drivers/media/rc/ati_remote.c
index 7a35f7a..26fa043 100644
--- a/drivers/media/rc/ati_remote.c
+++ b/drivers/media/rc/ati_remote.c
@@ -1,7 +1,7 @@
/*
* USB ATI Remote support
*
- *Copyright (c) 2011 Anssi Hannula
+ *Copyright (c) 2011, 2012 Anssi Hannula
* Version 2.2.0 Copyright (c) 2004 Torrey Hoffman
* Version 2.1.1 Copyright (c) 2002 Vladimir Dergachev
*
@@ -157,8 +157,20 @@ struct ati_receiver_type {
const char *(*get_default_keymap)(struct usb_interface *interface);
};
+static const char *get_medion_keymap(struct usb_interface *interface)
+{
+ struct usb_device *udev = interface_to_usbdev(interface);
+
+ /* The receiver shipped with the "Digitainer" variant helpfully has
+* a single additional bit set in its descriptor. */
+ if (udev->actconfig->desc.bmAttributes & USB_CONFIG_ATT_WAKEUP)
+ return RC_MAP_MEDION_X10_DIGITAINER;
+
+ return RC_MAP_MEDION_X10;
+}
+
static const struct ati_receiver_type type_ati = { .default_keymap =
RC_MAP_ATI_X10 };
-static const struct ati_receiver_type type_medion = { .default_keymap =
RC_MAP_MEDION_X10 };
+static const struct ati_receiver_type type_medion = { .get_default_keymap
= get_medion_keymap };
static const struct ati_receiver_type type_firefly = { .default_keymap =
RC_MAP_SNAPSTREAM_FIREFLY };
static struct usb_device_id ati_remote_table[] = {
@@ -455,6 +467,7 @@ static void ati_remote_input_report(struct urb *urb)
int acc;
int remote_num;
unsigned char scancode;
+ u32 wheel_keycode = KEY_RESERVED;
int i;
/*
@@ -494,26 +507,33 @@ static void ati_remote_input_report(struct urb *urb)
*/
scancode = data[2] & 0x7f;
- /* Look up event code index in the mouse translation table. */
- for (i = 0; ati_remote_tbl[i].kind != KIND_END; i++) {
- if (scancode == ati_remote_tbl[i].data) {
- index = i;
- break;
+ dbginfo(&ati_remote->interface->dev,
+ "channel 0x%02x; key data %02x, scancode %02x\n",
+ remote_num, data[2], scancode);
+
+ if (scancode >= 0x70) {
+ /*
+* This is either a mouse or scrollwheel event, depending on
+* the remote/keymap.
+* Get the keycode assigned to scancode 0x78/0x70. If it is
+* set, assume this is a scrollwheel up/down event.
+*/
+ wheel_keycode = rc_g_keycode_from_table(ati_remote->rdev,
+ scancode & 0x78);
+
+ if (wheel_keycode == KEY_RESERVED) {
+ /* scrollwheel was not mapped, assume mouse */
+
[PATCH 0/2] [media] ati_remote: Medion X10 Digitainer remote support
Hi! This patchset adds support for another Medion X10 remote to the ati_remote driver. See the individual patches for detailed explanations. Anssi Hannula (2): [media] ati_remote: allow specifying a default keymap selector function [media] ati_remote: add support for Medion X10 Digitainer remote drivers/media/rc/ati_remote.c | 124 ++-- drivers/media/rc/keymaps/Makefile |1 + .../media/rc/keymaps/rc-medion-x10-digitainer.c| 115 ++ include/media/rc-map.h |1 + 4 files changed, 204 insertions(+), 37 deletions(-) -- Anssi Hannula -- 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
cxd2099 CI on DDBridge not working (was: Re: DVB nGene CI : TS Discontinuities issues)
27.02.2012 00:14, Ralph Metzler kirjoitti: > Anssi Hannula writes: > > > I had it running for an hour and had no discontinuities (except at > > > restarts, might have to look into buffer flushing). > > > I tested it with nGene and Octopus boards on an Asus ION2 board and on a > > > Marvell Kirkwood based ARM board. > > > > Should your test code (quoted below) work with e.g. Octopus DDBridge on > > vanilla 3.2.6 kernel, without any additional initialization needed > > through ca0 or so? > > > > When I try it here like that, the reader thread simply blocks > > indefinitely on the first read, while the writer thread continues to > > write packets into the device. > > Am I missing something, or is this a bug? > > > Yes, it should work as it is. > I assume you adjusted the adapter numbers of course. I did. Do you have any idea on what could be the cause of the issue or any debugging tips? I have also tried to do actual decrypting with the CI. As expected, the same thing happened, i.e. data was written but no data was read (CAM in ca0 also responds properly to VDR). -- Anssi Hannula -- 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: DVB nGene CI : TS Discontinuities issues
mp(ts+8, buf+8, 180))
> printf("error\n");
> if (!(c&0x))
> printf("R %d\n", c);
> }
> (*d)++;
> }
>
> void *get_ts(void *a)
> {
> uint8_t buf[188*1024];
> int len, off;
>
> int fdi=open("/dev/dvb/adapter4/sec0", O_RDONLY);
> uint32_t d=0;
>
> while (1) {
> len=read(fdi, buf, 188*1024);
> if (len<0)
> continue;
> if (buf[0]!=0x47) { //should not happen
> read(fdi, buf, 1);
> continue;
> }
> for (off=0; off proc_buf(buf+off, &d);
> }
> }
> }
>
> #define SNUM 671
> void send(void)
> {
> uint8_t buf[188*SNUM], *cts;
> int i;
> uint32_t c=0;
> int fdo;
>
> fdo=open("/dev/dvb/adapter4/sec0", O_WRONLY);
>
>
> while (1) {
> for (i=0; i cts=buf+i*188;
> memcpy(cts, ts, 188);
> cts[4]=(c>>24);
> cts[5]=(c>>16);
> cts[6]=(c>>8);
> cts[7]=c;
> //write(fdo, fill, 188);
> //printf("S %d\n", c);
> c++;
> //usleep(10+0x&rand());
> //usleep(1000);
> }
> write(fdo, buf, 188*SNUM);
> }
> }
>
>
> int main()
> {
> pthread_t th;
>
> memset(ts+8, 180, 0x5a);
> pthread_create(&th, NULL, get_ts, NULL);
> send();
> }
>
>
> --
> 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
>
--
Anssi Hannula
--
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: Two devices, same USB ID: one needs HID, the other doesn't. How to solve this?
On 13.01.2012 12:42, Hans Verkuil wrote: > Hi! Hi! Adding Jiri Kosina, the HID maintainer. > I've made a video4linux driver for the USB Keene FM Transmitter. See: > > http://www.amazon.co.uk/Keene-Electronics-USB-FM-Transmitter/dp/B003GCHPDY/ref=sr_1_1?ie=UTF8&qid=1326450476&sr=8-1 > > The driver code is here: > > http://git.linuxtv.org/hverkuil/media_tree.git/shortlog/refs/heads/keene > > Unfortunately this device has exactly the same USB ID as the Logitech AudioHub > USB speaker (http://www.logitech.com/en-us/439/3503). > > The AudioHub has HID support for volume keys, but the FM transmitter needs > a custom V4L2 driver instead. > > I've attached the full lsusb -v output of both devices, but this is the diff > of > the two: > > $ diff keene.txt audiohub.txt -u [...] > @@ -152,7 +151,7 @@ >bCountryCode0 Not supported >bNumDescriptors 1 >bDescriptorType34 Report > - wDescriptorLength 22 > + wDescriptorLength 31 > Report Descriptors: > ** UNAVAILABLE ** >Endpoint Descriptor: > > As you can see, the differences are very small. The HID Report descriptors could be interesting as they differ. You can look at them in: /sys/kernel/debug/hid/*/rdesc I guess one option would be to make this a "regular" HID driver like those in drivers/hid/hid-*.c (and just set the v4l things up if the descriptor is as expected, otherwise let standard HID-input handle them), but there is the issue of where to place the driver, then, as it can't be both in drivers/hid and drivers/media... Probably the easy way out is to simply add the device into drivers/hid/hid-core.c:hid_ignore(), by checking e.g. vendor+product+name, and hope all "B-LINK USB Audio" devices are FM transmitters (the name suggests that may not necessarily be the case, though). Report descriptor contents are not available at hid_ignore() point yet. > In my git tree I worked around it by adding the USB ID to the ignore list > if the Keene driver is enabled, and ensuring that the Keene driver is > disabled by default. > > But is there a better method to do this? At least the iProduct strings are > different, is that something that can be tested in hid-core.c? > > Regards, > > Hans -- Anssi Hannula -- 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
[PATCH] [media] ati_remote: switch to single-byte scancodes
The ati_remote driver currently uses 2-byte scancodes. However, one of
those bytes is actually a checksum and therefore shouldn't be considered
as part of the scancode.
Fix the driver to only use the actual data byte as a scancode and to
check the checksum itself. Update the bundled keymaps accordingly.
Since ati_remote was only migrated to the rc subsystem for 3.2, the
previous scancodes weren't emitted on any stable kernel.
Reported-by: George Spelvin
Signed-off-by: Anssi Hannula
---
As noted earlier, this should go to kernel 3.2, to avoid having the
wrong keycode handling get into any stable kernel.
drivers/media/rc/ati_remote.c| 111 +--
drivers/media/rc/keymaps/rc-ati-x10.c| 96
drivers/media/rc/keymaps/rc-medion-x10.c | 128 +++---
drivers/media/rc/keymaps/rc-snapstream-firefly.c | 114 ++--
4 files changed, 220 insertions(+), 229 deletions(-)
diff --git a/drivers/media/rc/ati_remote.c b/drivers/media/rc/ati_remote.c
index 303f22e..01bb8da 100644
--- a/drivers/media/rc/ati_remote.c
+++ b/drivers/media/rc/ati_remote.c
@@ -189,7 +189,7 @@ struct ati_remote {
dma_addr_t inbuf_dma;
dma_addr_t outbuf_dma;
- unsigned char old_data[2]; /* Detect duplicate events */
+ unsigned char old_data; /* Detect duplicate events */
unsigned long old_jiffies;
unsigned long acc_jiffies; /* handle acceleration */
unsigned long first_jiffies;
@@ -221,35 +221,35 @@ struct ati_remote {
/* Translation table from hardware messages to input events. */
static const struct {
short kind;
- unsigned char data1, data2;
+ unsigned char data;
int type;
unsigned int code;
int value;
} ati_remote_tbl[] = {
/* Directional control pad axes */
- {KIND_ACCEL, 0x35, 0x70, EV_REL, REL_X, -1}, /* left */
- {KIND_ACCEL, 0x36, 0x71, EV_REL, REL_X, 1},/* right */
- {KIND_ACCEL, 0x37, 0x72, EV_REL, REL_Y, -1}, /* up */
- {KIND_ACCEL, 0x38, 0x73, EV_REL, REL_Y, 1},/* down */
+ {KIND_ACCEL, 0x70, EV_REL, REL_X, -1}, /* left */
+ {KIND_ACCEL, 0x71, EV_REL, REL_X, 1},/* right */
+ {KIND_ACCEL, 0x72, EV_REL, REL_Y, -1}, /* up */
+ {KIND_ACCEL, 0x73, EV_REL, REL_Y, 1},/* down */
/* Directional control pad diagonals */
- {KIND_LU, 0x39, 0x74, EV_REL, 0, 0},/* left up */
- {KIND_RU, 0x3a, 0x75, EV_REL, 0, 0},/* right up */
- {KIND_LD, 0x3c, 0x77, EV_REL, 0, 0},/* left down */
- {KIND_RD, 0x3b, 0x76, EV_REL, 0, 0},/* right down */
+ {KIND_LU, 0x74, EV_REL, 0, 0},/* left up */
+ {KIND_RU, 0x75, EV_REL, 0, 0},/* right up */
+ {KIND_LD, 0x77, EV_REL, 0, 0},/* left down */
+ {KIND_RD, 0x76, EV_REL, 0, 0},/* right down */
/* "Mouse button" buttons */
- {KIND_LITERAL, 0x3d, 0x78, EV_KEY, BTN_LEFT, 1}, /* left btn down */
- {KIND_LITERAL, 0x3e, 0x79, EV_KEY, BTN_LEFT, 0}, /* left btn up */
- {KIND_LITERAL, 0x41, 0x7c, EV_KEY, BTN_RIGHT, 1},/* right btn down */
- {KIND_LITERAL, 0x42, 0x7d, EV_KEY, BTN_RIGHT, 0},/* right btn up */
+ {KIND_LITERAL, 0x78, EV_KEY, BTN_LEFT, 1}, /* left btn down */
+ {KIND_LITERAL, 0x79, EV_KEY, BTN_LEFT, 0}, /* left btn up */
+ {KIND_LITERAL, 0x7c, EV_KEY, BTN_RIGHT, 1},/* right btn down */
+ {KIND_LITERAL, 0x7d, EV_KEY, BTN_RIGHT, 0},/* right btn up */
/* Artificial "doubleclick" events are generated by the hardware.
* They are mapped to the "side" and "extra" mouse buttons here. */
- {KIND_FILTERED, 0x3f, 0x7a, EV_KEY, BTN_SIDE, 1}, /* left dblclick */
- {KIND_FILTERED, 0x43, 0x7e, EV_KEY, BTN_EXTRA, 1},/* right dblclick */
+ {KIND_FILTERED, 0x7a, EV_KEY, BTN_SIDE, 1}, /* left dblclick */
+ {KIND_FILTERED, 0x7e, EV_KEY, BTN_EXTRA, 1},/* right dblclick */
/* Non-mouse events are handled by rc-core */
- {KIND_END, 0x00, 0x00, EV_MAX + 1, 0, 0}
+ {KIND_END, 0x00, EV_MAX + 1, 0, 0}
};
/* Local function prototypes */
@@ -397,25 +397,6 @@ static int ati_remote_sendpacket(struct ati_remote
*ati_remote, u16 cmd, unsigne
}
/*
- * ati_remote_event_lookup
- */
-static int ati_remote_event_lookup(int rem, unsigned char d1, unsigned char d2)
-{
- int i;
-
- for (i = 0; ati_remote_tbl[i].kind != KIND_END; i++) {
- /*
-* Decide if the table entry matches the remote input.
-*/
- if (ati_remote_tbl[i].data1 == d1 &&
- ati_remote_tbl[i].data2 == d2)
- return i;
-
- }
- return -1;
-}
-
-/*
* ati_remote_compute_accel
*
* Implements acceleration curve fo
Re: [PATCH 5/7] [media] ati_remote: add keymap for Medion X10 RF remote
On 08.08.2011 08:57, Dmitry Torokhov wrote:
> On Sun, Aug 07, 2011 at 01:18:11AM +0300, Anssi Hannula wrote:
>> Add keymap for the Medion X10 RF remote which uses the ati_remote
>> driver, and default to it based on the usb id.
>
> Since rc-core supports loading custom keytmaps should we ass medion
> keymap here?
>
> I think we should keep the original keymap to avoid regressions, but new
> keymaps should be offloaded to udev.
Well, I simply followed the convention, as all other remotes under
media/ have the default table in-kernel.
I'm not against putting it off-kernel, but in that case the same should
be done for all new media devices. Is that the plan?
> Thanks.
>
>>
>> The keymap is adapted from an earlier patch by
>> Jan Losinski :
>> https://lkml.org/lkml/2011/4/18/104
>> with KEY_PLAYPAUSE replaced by KEY_PAUSE.
>>
>> Signed-off-by: Anssi Hannula
>> ---
>> drivers/media/rc/ati_remote.c| 17 +++--
>> drivers/media/rc/keymaps/Makefile|1 +
>> drivers/media/rc/keymaps/rc-medion-x10.c | 116
>> ++
>> include/media/rc-map.h |1 +
>> 4 files changed, 128 insertions(+), 7 deletions(-)
>> create mode 100644 drivers/media/rc/keymaps/rc-medion-x10.c
>>
>> diff --git a/drivers/media/rc/ati_remote.c b/drivers/media/rc/ati_remote.c
>> index 74cc6b1..4576462 100644
>> --- a/drivers/media/rc/ati_remote.c
>> +++ b/drivers/media/rc/ati_remote.c
>> @@ -151,11 +151,11 @@ MODULE_PARM_DESC(mouse, "Enable mouse device, default
>> = yes");
>> #define err(format, arg...) printk(KERN_ERR format , ## arg)
>>
>> static struct usb_device_id ati_remote_table[] = {
>> -{ USB_DEVICE(ATI_REMOTE_VENDOR_ID, LOLA_REMOTE_PRODUCT_ID) },
>> -{ USB_DEVICE(ATI_REMOTE_VENDOR_ID, LOLA2_REMOTE_PRODUCT_ID) },
>> -{ USB_DEVICE(ATI_REMOTE_VENDOR_ID, ATI_REMOTE_PRODUCT_ID) },
>> -{ USB_DEVICE(ATI_REMOTE_VENDOR_ID, NVIDIA_REMOTE_PRODUCT_ID) },
>> -{ USB_DEVICE(ATI_REMOTE_VENDOR_ID, MEDION_REMOTE_PRODUCT_ID) },
>> +{ USB_DEVICE(ATI_REMOTE_VENDOR_ID, LOLA_REMOTE_PRODUCT_ID),
>> .driver_info = (unsigned long)RC_MAP_ATI_X10 },
>> +{ USB_DEVICE(ATI_REMOTE_VENDOR_ID, LOLA2_REMOTE_PRODUCT_ID),
>> .driver_info = (unsigned long)RC_MAP_ATI_X10 },
>> +{ USB_DEVICE(ATI_REMOTE_VENDOR_ID, ATI_REMOTE_PRODUCT_ID),
>> .driver_info = (unsigned long)RC_MAP_ATI_X10 },
>> +{ USB_DEVICE(ATI_REMOTE_VENDOR_ID, NVIDIA_REMOTE_PRODUCT_ID),
>> .driver_info = (unsigned long)RC_MAP_ATI_X10 },
>> +{ USB_DEVICE(ATI_REMOTE_VENDOR_ID, MEDION_REMOTE_PRODUCT_ID),
>> .driver_info = (unsigned long)RC_MAP_MEDION_X10 },
>> {} /* Terminating entry */
>> };
>>
>> @@ -714,8 +714,6 @@ static void ati_remote_rc_init(struct ati_remote
>> *ati_remote)
>>
>> usb_to_input_id(ati_remote->udev, &rdev->input_id);
>> rdev->dev.parent = &ati_remote->interface->dev;
>> -
>> -rdev->map_name = RC_MAP_ATI_X10;
>> }
>>
>> static int ati_remote_initialize(struct ati_remote *ati_remote)
>> @@ -827,6 +825,11 @@ static int ati_remote_probe(struct usb_interface
>> *interface, const struct usb_de
>> snprintf(ati_remote->mouse_name, sizeof(ati_remote->mouse_name),
>> "%s mouse", ati_remote->rc_name);
>>
>> +if (id->driver_info)
>> +rc_dev->map_name = (const char *)id->driver_info;
>> +else
>> +rc_dev->map_name = RC_MAP_ATI_X10;
>> +
>> ati_remote_rc_init(ati_remote);
>> mutex_init(&ati_remote->open_mutex);
>>
>> diff --git a/drivers/media/rc/keymaps/Makefile
>> b/drivers/media/rc/keymaps/Makefile
>> index 3ca9265b7..c3d0f34 100644
>> --- a/drivers/media/rc/keymaps/Makefile
>> +++ b/drivers/media/rc/keymaps/Makefile
>> @@ -48,6 +48,7 @@ obj-$(CONFIG_RC_MAP) += rc-adstech-dvb-t-pci.o \
>> rc-lirc.o \
>> rc-lme2510.o \
>> rc-manli.o \
>> +rc-medion-x10.o \
>> rc-msi-digivox-ii.o \
>> rc-msi-digivox-iii.o \
>> rc-msi-tvanywhere.o \
>> diff --git a/drivers/media/rc/keymaps/rc-medion-x10.c
>> b/drivers/media/rc/keymaps/rc-medion-x10.c
>> new file mode 100644
>> index 000..ff62aab
>> --- /dev/null
>> +++ b/drivers/media/rc/keymaps/rc-medion-x10.c
>> @@ -0,0 +1,116 @@
>> +/*
>> + *
[PATCH 4/7] [media] ati_remote: fix check for a weird byte
The ati_remote_dump() function tries to not print "Weird byte" warning
for 1-byte responses that contain 0xff or 0x00, but it doesn't work
properly as it simply falls back to the "Weird data" warning in the else
clause.
Fix that by adding an inner if clause.
Signed-off-by: Anssi Hannula
---
drivers/media/rc/ati_remote.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/media/rc/ati_remote.c b/drivers/media/rc/ati_remote.c
index 842dee4..74cc6b1 100644
--- a/drivers/media/rc/ati_remote.c
+++ b/drivers/media/rc/ati_remote.c
@@ -273,9 +273,10 @@ static struct usb_driver ati_remote_driver = {
static void ati_remote_dump(struct device *dev, unsigned char *data,
unsigned int len)
{
- if ((len == 1) && (data[0] != (unsigned char)0xff) && (data[0] != 0x00))
- dev_warn(dev, "Weird byte 0x%02x\n", data[0]);
- else if (len == 4)
+ if (len == 1) {
+ if (data[0] != (unsigned char)0xff && data[0] != 0x00)
+ dev_warn(dev, "Weird byte 0x%02x\n", data[0]);
+ } else if (len == 4)
dev_warn(dev, "Weird key %02x %02x %02x %02x\n",
data[0], data[1], data[2], data[3]);
else
--
1.7.4.4
--
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
[PATCH 7/7] [media] ati_remote: update Kconfig description
The ati_remote driver supports more remotes nowadays, update the description to reflect that. Signed-off-by: Anssi Hannula --- drivers/media/rc/Kconfig | 12 +++- 1 files changed, 7 insertions(+), 5 deletions(-) diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig index 26937b2..86c6abc 100644 --- a/drivers/media/rc/Kconfig +++ b/drivers/media/rc/Kconfig @@ -98,16 +98,18 @@ config IR_LIRC_CODEC the LIRC interface. config RC_ATI_REMOTE - tristate "ATI / X10 USB RF remote control" + tristate "ATI / X10 based USB RF remote controls" depends on USB_ARCH_HAS_HCD depends on RC_CORE select USB help - Say Y here if you want to use an ATI or X10 "Lola" USB remote control. + Say Y here if you want to use an X10 based USB remote control. These are RF remotes with USB receivers. - The ATI remote comes with many of ATI's All-In-Wonder video cards. - The X10 "Lola" remote is available at: - <http://www.x10.com/products/lola_sg1.htm> + + Such devices include the ATI remote that comes with many of ATI's + All-In-Wonder video cards, the X10 "Lola" remote, NVIDIA RF remote, + Medion RF remote, and SnapStream FireFly remote. + This driver provides mouse pointer, left and right mouse buttons, and maps all the other remote buttons to keypress events. -- 1.7.4.4 -- 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
[PATCH 6/7] [media] ati_remote: add support for SnapStream Firefly remote
Add support for SnapStream Firefly remote control.
The protocol differs by having two toggle bits in the scancode. Since
one of the bits is otherwise unused, we can safely handle the bits
unconditionally.
Signed-off-by: Anssi Hannula
---
drivers/media/rc/ati_remote.c| 15 +++-
drivers/media/rc/keymaps/Makefile|1 +
drivers/media/rc/keymaps/rc-snapstream-firefly.c | 106 ++
include/media/rc-map.h |1 +
4 files changed, 121 insertions(+), 2 deletions(-)
create mode 100644 drivers/media/rc/keymaps/rc-snapstream-firefly.c
diff --git a/drivers/media/rc/ati_remote.c b/drivers/media/rc/ati_remote.c
index 4576462..9e03efa 100644
--- a/drivers/media/rc/ati_remote.c
+++ b/drivers/media/rc/ati_remote.c
@@ -107,6 +107,7 @@
#define ATI_REMOTE_PRODUCT_ID 0x0004
#define NVIDIA_REMOTE_PRODUCT_ID 0x0005
#define MEDION_REMOTE_PRODUCT_ID 0x0006
+#define FIREFLY_REMOTE_PRODUCT_ID 0x0008
#define DRIVER_VERSION "2.2.1"
#define DRIVER_AUTHOR "Torrey Hoffman "
@@ -156,6 +157,7 @@ static struct usb_device_id ati_remote_table[] = {
{ USB_DEVICE(ATI_REMOTE_VENDOR_ID, ATI_REMOTE_PRODUCT_ID),
.driver_info = (unsigned long)RC_MAP_ATI_X10 },
{ USB_DEVICE(ATI_REMOTE_VENDOR_ID, NVIDIA_REMOTE_PRODUCT_ID),
.driver_info = (unsigned long)RC_MAP_ATI_X10 },
{ USB_DEVICE(ATI_REMOTE_VENDOR_ID, MEDION_REMOTE_PRODUCT_ID),
.driver_info = (unsigned long)RC_MAP_MEDION_X10 },
+ { USB_DEVICE(ATI_REMOTE_VENDOR_ID, FIREFLY_REMOTE_PRODUCT_ID),
.driver_info = (unsigned long)RC_MAP_SNAPSTREAM_FIREFLY },
{} /* Terminating entry */
};
@@ -482,7 +484,15 @@ static void ati_remote_input_report(struct urb *urb)
scancode[0] = (((data[1] - ((remote_num + 1) << 4)) & 0xf0) | (data[1]
& 0x0f));
- scancode[1] = data[2];
+ /*
+* Some devices (e.g. SnapStream Firefly) use 8080 as toggle code,
+* so we have to clear them. The first bit is a bit tricky as the
+* "non-toggled" state depends on remote_num, so we xor it with the
+* second bit which is only used for toggle.
+*/
+ scancode[0] ^= (data[2] & 0x80);
+
+ scancode[1] = data[2] & ~0x80;
/* Look up event code index in mouse translation table. */
index = ati_remote_event_lookup(remote_num, scancode[0], scancode[1]);
@@ -546,7 +556,8 @@ static void ati_remote_input_report(struct urb *urb)
* it would cause ghost repeats which would be a
* regression for this driver.
*/
- rc_keydown_notimeout(ati_remote->rdev, rc_code, 0);
+ rc_keydown_notimeout(ati_remote->rdev, rc_code,
+data[2]);
rc_keyup(ati_remote->rdev);
return;
}
diff --git a/drivers/media/rc/keymaps/Makefile
b/drivers/media/rc/keymaps/Makefile
index c3d0f34..5ff4d10 100644
--- a/drivers/media/rc/keymaps/Makefile
+++ b/drivers/media/rc/keymaps/Makefile
@@ -72,6 +72,7 @@ obj-$(CONFIG_RC_MAP) += rc-adstech-dvb-t-pci.o \
rc-hauppauge.o \
rc-rc6-mce.o \
rc-real-audio-220-32-keys.o \
+ rc-snapstream-firefly.o \
rc-streamzap.o \
rc-tbs-nec.o \
rc-technisat-usb2.o \
diff --git a/drivers/media/rc/keymaps/rc-snapstream-firefly.c
b/drivers/media/rc/keymaps/rc-snapstream-firefly.c
new file mode 100644
index 000..2df02e4
--- /dev/null
+++ b/drivers/media/rc/keymaps/rc-snapstream-firefly.c
@@ -0,0 +1,106 @@
+/*
+ * SnapStream Firefly X10 RF remote keytable
+ *
+ * Copyright (C) 2011 Anssi Hannula
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+ */
+
+#include
+
+static struct rc_map_table snapstream_firefly[] = {
+ { 0xf12c, KEY_ZOOM }, /* Maximize */
+ { 0xc702, KEY_CLOSE },
+
+ { 0xd20d, KEY_1 },
+ { 0xd30e, KEY_2 },
+ { 0xd40f, KEY_3 },
+ { 0xd510, KEY_4 },
+ { 0xd611, KEY_5 },
+ { 0xd712
[PATCH 3/7] [media] ati_remote: parent input devices to usb interface
Parent the input devices to usb_interface instead of usb_device. This fixes (at least) persistent input device nodes. Signed-off-by: Anssi Hannula --- drivers/media/rc/ati_remote.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/media/rc/ati_remote.c b/drivers/media/rc/ati_remote.c index a1df21f..842dee4 100644 --- a/drivers/media/rc/ati_remote.c +++ b/drivers/media/rc/ati_remote.c @@ -693,7 +693,7 @@ static void ati_remote_input_init(struct ati_remote *ati_remote) idev->phys = ati_remote->mouse_phys; usb_to_input_id(ati_remote->udev, &idev->id); - idev->dev.parent = &ati_remote->udev->dev; + idev->dev.parent = &ati_remote->interface->dev; } static void ati_remote_rc_init(struct ati_remote *ati_remote) @@ -712,7 +712,7 @@ static void ati_remote_rc_init(struct ati_remote *ati_remote) rdev->input_phys = ati_remote->rc_phys; usb_to_input_id(ati_remote->udev, &rdev->input_id); - rdev->dev.parent = &ati_remote->udev->dev; + rdev->dev.parent = &ati_remote->interface->dev; rdev->map_name = RC_MAP_ATI_X10; } -- 1.7.4.4 -- 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
[PATCH 5/7] [media] ati_remote: add keymap for Medion X10 RF remote
Add keymap for the Medion X10 RF remote which uses the ati_remote
driver, and default to it based on the usb id.
The keymap is adapted from an earlier patch by
Jan Losinski :
https://lkml.org/lkml/2011/4/18/104
with KEY_PLAYPAUSE replaced by KEY_PAUSE.
Signed-off-by: Anssi Hannula
---
drivers/media/rc/ati_remote.c| 17 +++--
drivers/media/rc/keymaps/Makefile|1 +
drivers/media/rc/keymaps/rc-medion-x10.c | 116 ++
include/media/rc-map.h |1 +
4 files changed, 128 insertions(+), 7 deletions(-)
create mode 100644 drivers/media/rc/keymaps/rc-medion-x10.c
diff --git a/drivers/media/rc/ati_remote.c b/drivers/media/rc/ati_remote.c
index 74cc6b1..4576462 100644
--- a/drivers/media/rc/ati_remote.c
+++ b/drivers/media/rc/ati_remote.c
@@ -151,11 +151,11 @@ MODULE_PARM_DESC(mouse, "Enable mouse device, default =
yes");
#define err(format, arg...) printk(KERN_ERR format , ## arg)
static struct usb_device_id ati_remote_table[] = {
- { USB_DEVICE(ATI_REMOTE_VENDOR_ID, LOLA_REMOTE_PRODUCT_ID) },
- { USB_DEVICE(ATI_REMOTE_VENDOR_ID, LOLA2_REMOTE_PRODUCT_ID) },
- { USB_DEVICE(ATI_REMOTE_VENDOR_ID, ATI_REMOTE_PRODUCT_ID) },
- { USB_DEVICE(ATI_REMOTE_VENDOR_ID, NVIDIA_REMOTE_PRODUCT_ID) },
- { USB_DEVICE(ATI_REMOTE_VENDOR_ID, MEDION_REMOTE_PRODUCT_ID) },
+ { USB_DEVICE(ATI_REMOTE_VENDOR_ID, LOLA_REMOTE_PRODUCT_ID),
.driver_info = (unsigned long)RC_MAP_ATI_X10 },
+ { USB_DEVICE(ATI_REMOTE_VENDOR_ID, LOLA2_REMOTE_PRODUCT_ID),
.driver_info = (unsigned long)RC_MAP_ATI_X10 },
+ { USB_DEVICE(ATI_REMOTE_VENDOR_ID, ATI_REMOTE_PRODUCT_ID),
.driver_info = (unsigned long)RC_MAP_ATI_X10 },
+ { USB_DEVICE(ATI_REMOTE_VENDOR_ID, NVIDIA_REMOTE_PRODUCT_ID),
.driver_info = (unsigned long)RC_MAP_ATI_X10 },
+ { USB_DEVICE(ATI_REMOTE_VENDOR_ID, MEDION_REMOTE_PRODUCT_ID),
.driver_info = (unsigned long)RC_MAP_MEDION_X10 },
{} /* Terminating entry */
};
@@ -714,8 +714,6 @@ static void ati_remote_rc_init(struct ati_remote
*ati_remote)
usb_to_input_id(ati_remote->udev, &rdev->input_id);
rdev->dev.parent = &ati_remote->interface->dev;
-
- rdev->map_name = RC_MAP_ATI_X10;
}
static int ati_remote_initialize(struct ati_remote *ati_remote)
@@ -827,6 +825,11 @@ static int ati_remote_probe(struct usb_interface
*interface, const struct usb_de
snprintf(ati_remote->mouse_name, sizeof(ati_remote->mouse_name),
"%s mouse", ati_remote->rc_name);
+ if (id->driver_info)
+ rc_dev->map_name = (const char *)id->driver_info;
+ else
+ rc_dev->map_name = RC_MAP_ATI_X10;
+
ati_remote_rc_init(ati_remote);
mutex_init(&ati_remote->open_mutex);
diff --git a/drivers/media/rc/keymaps/Makefile
b/drivers/media/rc/keymaps/Makefile
index 3ca9265b7..c3d0f34 100644
--- a/drivers/media/rc/keymaps/Makefile
+++ b/drivers/media/rc/keymaps/Makefile
@@ -48,6 +48,7 @@ obj-$(CONFIG_RC_MAP) += rc-adstech-dvb-t-pci.o \
rc-lirc.o \
rc-lme2510.o \
rc-manli.o \
+ rc-medion-x10.o \
rc-msi-digivox-ii.o \
rc-msi-digivox-iii.o \
rc-msi-tvanywhere.o \
diff --git a/drivers/media/rc/keymaps/rc-medion-x10.c
b/drivers/media/rc/keymaps/rc-medion-x10.c
new file mode 100644
index 000..ff62aab
--- /dev/null
+++ b/drivers/media/rc/keymaps/rc-medion-x10.c
@@ -0,0 +1,116 @@
+/*
+ * Medion X10 RF remote keytable
+ *
+ * Copyright (C) 2011 Anssi Hannula
+ *
+ * This file is based on a keytable provided by
+ * Jan Losinski
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+ */
+
+#include
+
+static struct rc_map_table medion_x10[] = {
+ { 0xf12c, KEY_TV },/* TV */
+ { 0xf22d, KEY_VCR }, /* VCR */
+ { 0xc904, KEY_DVD }, /* DVD */
+ { 0xcb06, KEY_AUDIO }, /* MUSIC */
+
+ { 0xf32e, KEY_RADIO }, /* RADIO */
+ { 0xca05, KEY_DIRECTORY }, /* PHOTO */
+ { 0xf42f, KEY_INFO }, /* TV-PREVIEW */
+ { 0xf530, KEY_LIST }, /* CHANNEL-LST *
[PATCH 2/7] [media] ati_remote: migrate to the rc subsystem
Migrate the ATI/X10 RF remote driver to the rc subsystem, allowing the
use of its keymap handling capabilities.
The mouse handling is kept in-driver and now appears as a separate input
device which can be disabled with a new module option (autodetection
would be possible based on receiver, but it wouldn't account for cases
where a remote with mouse is used with a receiver that came with a
remote without mouse).
The remotes have 4-bit programmable IDs, so it would be possible to
support simultaneous use of multiple remotes with different keymaps with
each remote appearing as a separate input device; however,
implementation of that is left for a later date.
The driver previously transmitted all events as keydown/keyup
combinations. That behavior is kept (at least for now) to avoid the
current issue with rc-core where repeat events continue after a button
is released, since that would be a clear regression for this driver.
The keycode mangling algorithm is kept the same, so the new external
keymap has the same values as the old static table.
Signed-off-by: Anssi Hannula
---
drivers/media/rc/Kconfig |1 +
drivers/media/rc/ati_remote.c | 262 -
drivers/media/rc/keymaps/Makefile |1 +
drivers/media/rc/keymaps/rc-ati-x10.c | 103 +
include/media/rc-map.h|1 +
5 files changed, 269 insertions(+), 99 deletions(-)
create mode 100644 drivers/media/rc/keymaps/rc-ati-x10.c
diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig
index 4a5b4a6..26937b2 100644
--- a/drivers/media/rc/Kconfig
+++ b/drivers/media/rc/Kconfig
@@ -100,6 +100,7 @@ config IR_LIRC_CODEC
config RC_ATI_REMOTE
tristate "ATI / X10 USB RF remote control"
depends on USB_ARCH_HAS_HCD
+ depends on RC_CORE
select USB
help
Say Y here if you want to use an ATI or X10 "Lola" USB remote
control.
diff --git a/drivers/media/rc/ati_remote.c b/drivers/media/rc/ati_remote.c
index bce5712..a1df21f 100644
--- a/drivers/media/rc/ati_remote.c
+++ b/drivers/media/rc/ati_remote.c
@@ -1,6 +1,7 @@
/*
* USB ATI Remote support
*
+ * Copyright (c) 2011 Anssi Hannula
* Version 2.2.0 Copyright (c) 2004 Torrey Hoffman
* Version 2.1.1 Copyright (c) 2002 Vladimir Dergachev
*
@@ -90,9 +91,11 @@
#include
#include
#include
+#include
#include
#include
#include
+#include
/*
* Module and Version Information, Module Parameters
@@ -139,6 +142,10 @@ static int repeat_delay = REPEAT_DELAY;
module_param(repeat_delay, int, 0644);
MODULE_PARM_DESC(repeat_delay, "Delay before sending repeats, default = 500
msec");
+static bool mouse = true;
+module_param(mouse, bool, 0444);
+MODULE_PARM_DESC(mouse, "Enable mouse device, default = yes");
+
#define dbginfo(dev, format, arg...) do { if (debug) dev_info(dev , format ,
## arg); } while (0)
#undef err
#define err(format, arg...) printk(KERN_ERR format , ## arg)
@@ -167,6 +174,7 @@ static char init2[] = { 0x01, 0x00, 0x20, 0x14, 0x20, 0x20,
0x20 };
struct ati_remote {
struct input_dev *idev;
+ struct rc_dev *rdev;
struct usb_device *udev;
struct usb_interface *interface;
@@ -186,11 +194,16 @@ struct ati_remote {
unsigned int repeat_count;
- char name[NAME_BUFSIZE];
- char phys[NAME_BUFSIZE];
+ char rc_name[NAME_BUFSIZE];
+ char rc_phys[NAME_BUFSIZE];
+ char mouse_name[NAME_BUFSIZE];
+ char mouse_phys[NAME_BUFSIZE];
wait_queue_head_t wait;
int send_flags;
+
+ int users; /* 0-2, users are rc and input */
+ struct mutex open_mutex;
};
/* "Kinds" of messages sent from the hardware to the driver. */
@@ -233,64 +246,11 @@ static const struct {
{KIND_FILTERED, 0x3f, 0x7a, EV_KEY, BTN_SIDE, 1}, /* left dblclick */
{KIND_FILTERED, 0x43, 0x7e, EV_KEY, BTN_EXTRA, 1},/* right dblclick */
- /* keyboard. */
- {KIND_FILTERED, 0xd2, 0x0d, EV_KEY, KEY_1, 1},
- {KIND_FILTERED, 0xd3, 0x0e, EV_KEY, KEY_2, 1},
- {KIND_FILTERED, 0xd4, 0x0f, EV_KEY, KEY_3, 1},
- {KIND_FILTERED, 0xd5, 0x10, EV_KEY, KEY_4, 1},
- {KIND_FILTERED, 0xd6, 0x11, EV_KEY, KEY_5, 1},
- {KIND_FILTERED, 0xd7, 0x12, EV_KEY, KEY_6, 1},
- {KIND_FILTERED, 0xd8, 0x13, EV_KEY, KEY_7, 1},
- {KIND_FILTERED, 0xd9, 0x14, EV_KEY, KEY_8, 1},
- {KIND_FILTERED, 0xda, 0x15, EV_KEY, KEY_9, 1},
- {KIND_FILTERED, 0xdc, 0x17, EV_KEY, KEY_0, 1},
- {KIND_FILTERED, 0xc5, 0x00, EV_KEY, KEY_A, 1},
- {KIND_FILTERED, 0xc6, 0x01, EV_KEY, KEY_B, 1},
- {KIND_FILTERED, 0xde, 0x19, EV_KEY, KEY_C, 1},
- {KIND_FILTERED, 0xe0, 0x1b, EV_KEY, KEY_D, 1},
- {KIND_FILTERED, 0xe6, 0x21, EV_KEY, KEY_E, 1},
- {KIND_FILTERED, 0xe8, 0x23, EV_KEY, KEY_F, 1},
-
- /* "special" keys */
- {KIND_FILTERED, 0xdd, 0x18,
[PATCH 0/7] ati_remote: move to rc-core and other updates
Anssi Hannula wrote: > On 25.05.2011 19:32, Dmitry Torokhov wrote: >> I believe Anssi Hannula (CCed) mentioned that he has a version of >> ati_remove ported to rc-core infrastructure that supports such >> remapping. Anssi, could you tell me what is the status of that driver? >> Is it usable with rc-core? > > Sorry, it seems for some reason I didn't receive your message via CC and > only now saw it while looking at linux-input@ messages. > > Indeed I have a patchset that makes it work with rc-core which I didn't > get around to posting yet (sorry about that). > > I'll try to look over it now and do some more testing, and then post the > set. > > Some notes about the patchset: > - The mouse handling is left as-is, and it now appears as a separate > input device (that part of the keymap is the same for all remotes > with mouse). The mouse device is created regardless of receiver, > in case another type of remote is used with the receiver. > - The driver sends rc_keyup immediately after every rc_keydown, as that > is what the driver has always done for input events as well. Doing > otherwise would cause a regression as ghost repeats would appear > with this driver while they didn't before. Here goes the patchset, comments welcome. Anssi Hannula (7): [media] move ati_remote driver from input/misc to media/rc [media] ati_remote: migrate to the rc subsystem [media] ati_remote: parent input devices to usb interface [media] ati_remote: fix check for a weird byte [media] ati_remote: add keymap for Medion X10 RF remote [media] ati_remote: add support for SnapStream Firefly remote [media] ati_remote: update Kconfig description --- drivers/input/misc/Kconfig | 16 - drivers/input/misc/Makefile |1 - drivers/input/misc/ati_remote.c | 867 drivers/media/rc/Kconfig | 23 +- drivers/media/rc/Makefile|1 + drivers/media/rc/ati_remote.c| 946 ++ drivers/media/rc/keymaps/Makefile|3 + drivers/media/rc/keymaps/rc-ati-x10.c| 103 +++ drivers/media/rc/keymaps/rc-medion-x10.c | 116 +++ drivers/media/rc/keymaps/rc-snapstream-firefly.c | 106 +++ include/media/rc-map.h |3 + 11 files changed, 1299 insertions(+), 886 deletions(-) -- Anssi Hannula -- 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: IR remote control autorepeat / evdev
On 15.05.2011 06:41, Mauro Carvalho Chehab wrote: > Em 14-05-2011 01:07, Anssi Hannula escreveu: >> On 14.05.2011 01:39, Mauro Carvalho Chehab wrote: >>> Em 13-05-2011 01:48, Anssi Hannula escreveu: >>>> On 12.05.2011 04:36, Mauro Carvalho Chehab wrote: >>>>> Em 12-05-2011 03:10, Mauro Carvalho Chehab escreveu: >>>>>> Em 12-05-2011 02:37, Anssi Hannula escreveu: >>>>> >>>>>>> I don't see any other places: >>>>>>> $ git grep 'REP_PERIOD' . >>>>>>> dvb/dvb-usb/dvb-usb-remote.c: input_dev->rep[REP_PERIOD] = >>>>>>> d->props.rc.legacy.rc_interval; >>>>>> >>>>>> Indeed, the REP_PERIOD is not adjusted on other drivers. I agree that we >>>>>> should change it to something like 125ms, for example, as 33ms is too >>>>>> short, as it takes up to 114ms for a repeat event to arrive. >>>>>> >>>>> IMO, the enclosed patch should do a better job with repeat events, without >>>>> needing to change rc-core/input/event logic. >>>> >>>> It will indeed reduce the amount of ghost events so it brings us in the >>>> right direction. >>>> >>>> I'd still like to get rid of the ghost repeats entirely, or at least >>>> some way for users to do it if we don't do it by default. >>> >>>> Maybe we could replace the kernel softrepeat with native repeats (for >>>> those protocols/drivers that have them), while making sure that repeat >>>> events before REP_DELAY are ignored and repeat events less than >>>> REP_PERIOD since the previous event are ignored, so the users can still >>>> configure them as they like? >>>> >>> >>> This doesn't seem to be the right thing to do. If the kernel will >>> accept 33 ms as the value or REP_PERIOD, but it will internally >>> set the maximum repeat rate is 115 ms (no matter what logic it would >>> use for that), Kernel (or X) shouldn't allow the user to set a smaller >>> value. >>> >>> The thing is that writing a logic to block a small value is not easy, since >>> the max value is protocol-dependent (worse than that, on some cases, it is >>> device-specific). It seems better to add a warning at the userspace tools >>> that delays lower than 115 ms can produce ghost events on IR's. >> >> From what I see, even periods longer than 115 ms can produce ghost events. >> >> For example with your patch softrepeat period is 125ms, release timeout >> 250ms, and a native rate of 110ms: >> >> There are 4 native events transmitted at >> 000 ms >> 110 ms >> 220 ms >> 330 ms >> (user stops between 330ms and 440ms) >> >> This causes these events in the evdev interface: >> 000: 1 >> 125: 2 >> 250: 2 >> 375: 2 >> 500: 2 >> 550: 0 >> >> So we got 1-2 ghost repeat events. >> >>>> Or maybe just a module option that causes rc-core to use native repeat >>>> events, for those of us that want accurate repeat events without ghosting? >>> >>> If the user already knows about the possibility to generate ghost effects, >>> with low delays, he can simply not pass a bad value to the kernel, instead >>> of forcing a modprobe parameter that will limit the minimal value. >> >> There is no "good value" for REP_PERIOD (as in ghost repeats guaranteed >> gone like with native repeats). Sufficiently large values will make >> ghost repeats increasingly rare, but the period becomes so long the >> autorepeat becomes frustratingly slow to use. >> > The 250 ms delay used internally to wait for a repeat code is there because > shorter periods weren't working on one of the first boards we've added to > rc core (it was a saa7134 - can't remember much details... too much time ago). > > I remember that I added it as a per-board timer (or per protocol?), as it > seemed > to high for me, but later, David sent a series of patches rewriting the > entire > stuff and proposing to have just one timer, arguing that later this could be > changed. As his series were improving rc-core, I ended by acking with the > changes. > > The fact is that REP_PERIODS shorter than that timer makes non-sense, as that > timer is used to actually wait for a repeat message. > > I suspect we should re-work the code, perhaps replacing the 250 ms fixed value > by REP_PERIOD. Well, that still has a 50% chance of a ghost repeat with length 1-125ms (e.g. native rate 110ms, user releases button at 900ms, last native event at 880ms, evdev repeat events at 500,625,750,875,1000ms). It would be significantly better than it was before, though, and I'll have to test it myself to see if it is good enough (though I fear it is not). > I can't work on it this weekend, as I'm about to leave Hungary to return back > home. I suspect that I'll have lots of fun next week, due to a one-week > travel, > and due to the .40 merge window (I suspect it will be opened next week). > > Maybe Jarod can find some time to do such patch and test it. > > Thanks, > Mauro. > -- Anssi Hannula -- 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: IR remote control autorepeat / evdev
On 14.05.2011 01:39, Mauro Carvalho Chehab wrote: > Em 13-05-2011 01:48, Anssi Hannula escreveu: >> On 12.05.2011 04:36, Mauro Carvalho Chehab wrote: >>> Em 12-05-2011 03:10, Mauro Carvalho Chehab escreveu: >>>> Em 12-05-2011 02:37, Anssi Hannula escreveu: >>> >>>>> I don't see any other places: >>>>> $ git grep 'REP_PERIOD' . >>>>> dvb/dvb-usb/dvb-usb-remote.c: input_dev->rep[REP_PERIOD] = >>>>> d->props.rc.legacy.rc_interval; >>>> >>>> Indeed, the REP_PERIOD is not adjusted on other drivers. I agree that we >>>> should change it to something like 125ms, for example, as 33ms is too >>>> short, as it takes up to 114ms for a repeat event to arrive. >>>> >>> IMO, the enclosed patch should do a better job with repeat events, without >>> needing to change rc-core/input/event logic. >> >> It will indeed reduce the amount of ghost events so it brings us in the >> right direction. >> >> I'd still like to get rid of the ghost repeats entirely, or at least >> some way for users to do it if we don't do it by default. > >> Maybe we could replace the kernel softrepeat with native repeats (for >> those protocols/drivers that have them), while making sure that repeat >> events before REP_DELAY are ignored and repeat events less than >> REP_PERIOD since the previous event are ignored, so the users can still >> configure them as they like? >> > > This doesn't seem to be the right thing to do. If the kernel will > accept 33 ms as the value or REP_PERIOD, but it will internally > set the maximum repeat rate is 115 ms (no matter what logic it would > use for that), Kernel (or X) shouldn't allow the user to set a smaller value. > > The thing is that writing a logic to block a small value is not easy, since > the max value is protocol-dependent (worse than that, on some cases, it is > device-specific). It seems better to add a warning at the userspace tools > that delays lower than 115 ms can produce ghost events on IR's. >From what I see, even periods longer than 115 ms can produce ghost events. For example with your patch softrepeat period is 125ms, release timeout 250ms, and a native rate of 110ms: There are 4 native events transmitted at 000 ms 110 ms 220 ms 330 ms (user stops between 330ms and 440ms) This causes these events in the evdev interface: 000: 1 125: 2 250: 2 375: 2 500: 2 550: 0 So we got 1-2 ghost repeat events. >> Or maybe just a module option that causes rc-core to use native repeat >> events, for those of us that want accurate repeat events without ghosting? > > If the user already knows about the possibility to generate ghost effects, > with low delays, he can simply not pass a bad value to the kernel, instead > of forcing a modprobe parameter that will limit the minimal value. There is no "good value" for REP_PERIOD (as in ghost repeats guaranteed gone like with native repeats). Sufficiently large values will make ghost repeats increasingly rare, but the period becomes so long the autorepeat becomes frustratingly slow to use. -- Anssi Hannula -- 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: IR remote control autorepeat / evdev
On 12.05.2011 04:36, Mauro Carvalho Chehab wrote: > Em 12-05-2011 03:10, Mauro Carvalho Chehab escreveu: >> Em 12-05-2011 02:37, Anssi Hannula escreveu: > >>> I don't see any other places: >>> $ git grep 'REP_PERIOD' . >>> dvb/dvb-usb/dvb-usb-remote.c: input_dev->rep[REP_PERIOD] = >>> d->props.rc.legacy.rc_interval; >> >> Indeed, the REP_PERIOD is not adjusted on other drivers. I agree that we >> should change it to something like 125ms, for example, as 33ms is too >> short, as it takes up to 114ms for a repeat event to arrive. >> > IMO, the enclosed patch should do a better job with repeat events, without > needing to change rc-core/input/event logic. It will indeed reduce the amount of ghost events so it brings us in the right direction. I'd still like to get rid of the ghost repeats entirely, or at least some way for users to do it if we don't do it by default. Maybe we could replace the kernel softrepeat with native repeats (for those protocols/drivers that have them), while making sure that repeat events before REP_DELAY are ignored and repeat events less than REP_PERIOD since the previous event are ignored, so the users can still configure them as they like? Or maybe just a module option that causes rc-core to use native repeat events, for those of us that want accurate repeat events without ghosting? > - > > Subject: Use a more consistent value for RC repeat period > From: Mauro Carvalho Chehab > > The default REP_PERIOD is 33 ms. This doesn't make sense for IR's, > as, in general, an IR repeat scancode is provided at every 110/115ms, > depending on the RC protocol. So, increase its default, to do a > better job avoiding ghost repeat events. > > Signed-off-by: Mauro Carvalho Chehab > > diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c > index f53f9c6..ee67169 100644 > --- a/drivers/media/rc/rc-main.c > +++ b/drivers/media/rc/rc-main.c > @@ -1044,6 +1044,13 @@ int rc_register_device(struct rc_dev *dev) >*/ > dev->input_dev->rep[REP_DELAY] = 500; > > + /* > + * As a repeat event on protocols like RC-5 and NEC take as long as > + * 110/114ms, using 33ms as a repeat period is not the right thing > + * to do. > + */ > + dev->input_dev->rep[REP_PERIOD] = 125; > + > path = kobject_get_path(&dev->dev.kobj, GFP_KERNEL); > printk(KERN_INFO "%s: %s as %s\n", > dev_name(&dev->dev), > -- Anssi Hannula -- 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: IR remote control autorepeat / evdev
On 12.05.2011 02:52, Mauro Carvalho Chehab wrote: > Em 11-05-2011 19:59, Anssi Hannula escreveu: >>> No. It actually depends on what driver you're using. For example, for most >>> dvb-usb >>> devices, this is given by the logic bellow: >>> >>> if (d->props.rc.legacy.rc_interval < 40) >>> d->props.rc.legacy.rc_interval = 100; /* default */ >>> >>> input_dev->rep[REP_PERIOD] = d->props.rc.legacy.rc_interval; >>> input_dev->rep[REP_DELAY] = d->props.rc.legacy.rc_interval + 150; >>> >>> where the rc_interval defined by device entry at the dvb usb drivers. >> >> Isn't that function only called for DVB_RC_LEGACY mode? > > I just picked one random piece of the code that covers several RC remotes > (most > dvb-usb drivers are still using the legacy mode). Similar code are there for > other devices. I don't see any other places: $ git grep 'REP_PERIOD' . dvb/dvb-usb/dvb-usb-remote.c: input_dev->rep[REP_PERIOD] = d->props.rc.legacy.rc_interval; >> Maybe I wasn't clear, but I'm talking only about the devices handled by >> rc-core. > > With just a few exceptions, the repeat period/delay that were there before > porting to rc-core were maintained. There are space for adjustments, as we > did on a few cases. The above is the only place where the repeat period is set in the drivers/media tree, and it is not an rc-core device. Other devices therefore use the 33ms kernel default. Maybe I am missing something? > Em 11-05-2011 22:53, Dmitry Torokhov escreveu: >> On Wed, May 11, 2011 at 08:59:16PM +0300, Anssi Hannula wrote: >>> >>> I meant replacing the softrepeat with native repeat for such devices >>> that have native repeats but no native release events: >>> >>> - keypress from device => keydown + keyup >>> - repeat from device => keydown + keyup >>> - repeat from device => keydown + keyup >>> >>> This is what e.g. ati_remote driver now does. >>> >>> Or alternatively >>> >>> - keypress from device => keydown >>> - repeat from device => repeat >>> - repeat from device => repeat >>> - nothing for 250ms => keyup >>> (doing it this way requires some extra handling in X server to stop its >>> softrepeat from triggering, though, as previously noted) >>> >>> With either of these, if one holds down volumeup, the repeat works, and >>> stops volumeup'ing immediately when user releases the button (as it is >>> supposed to). >>> >> >> Unfortunately this does not work for devices that do not have hardware >> autorepeat and also stops users from adjusting autorepeat parameters to >> their liking. > > Yes. A solution like the above would limit the usage. There are some remotes > (like for example, the Hauppauge Grey remotes I have here) that a simple > keypress generates, in general, up to 3 scancodes (the normal keypress and > up to two "bounced" repeat keycodes). So, the software key delay also serves > as a way to de-bounce the keypress. I probably forgot to mention it, but I'm not suggesting removal of the repetition delay (500ms), it can stay for this reason exactly. >> It appears that the delay to check whether the key has been released is >> too long (almost order of magnitude longer than our typical autorepeat >> period). > > Yes, because, for example, with NEC and RC-5 protocols, one keystroke or one > repeat event takes 110/114 ms to be transmitted. The delay actually varies > from protocol to protocol, so it is possible to do some adjustments, based on > the protocol type, but it is an order of magnitude longer than a keyboard or > mouse. > >> I think we should increase the period for remotes (both in >> kernel and in X, and also see if the release check delay can be made >> shorter, like 50-100 ms. > > Some adjustments like that can be made, but they are device-driver specific. > > For example, some in-hardware IR decoders with KS007 micro-controller just > removes all repeat keycodes and replace them with new keystrokes. There are > some shipped remotes that don't support the RC-5 or NEC key repeat event. So, > on those, if you keep a key pressed, you just receive the same scancode > several > times. > > The last time I double checked all remotes I have here, on all cases the > auto-repeat > logic were doing the right job, but I won't doubt that we need to add some > additional > adjustments for some boards/devices. Does "doing the right job&
Re: IR remote control autorepeat / evdev
On 11.05.2011 23:53, Dmitry Torokhov wrote: > On Wed, May 11, 2011 at 08:59:16PM +0300, Anssi Hannula wrote: >> >> I meant replacing the softrepeat with native repeat for such devices >> that have native repeats but no native release events: >> >> - keypress from device => keydown + keyup >> - repeat from device => keydown + keyup >> - repeat from device => keydown + keyup >> >> This is what e.g. ati_remote driver now does. >> >> Or alternatively >> >> - keypress from device => keydown >> - repeat from device => repeat >> - repeat from device => repeat >> - nothing for 250ms => keyup >> (doing it this way requires some extra handling in X server to stop its >> softrepeat from triggering, though, as previously noted) >> >> With either of these, if one holds down volumeup, the repeat works, and >> stops volumeup'ing immediately when user releases the button (as it is >> supposed to). >> > > Unfortunately this does not work for devices that do not have hardware > autorepeat Devices that have no hardware autorepeat have hardware release events, no? I'm only suggesting to do this for devices with hardware autorepeat. If there are no hw repeat events and no hw release events, obviously making repeat work at all is impossible. > and also stops users from adjusting autorepeat parameters to > their liking. True. However, I don't think adjustable autorepeat parameters are much of use for the users if the autorepeat itself is unusable (due to ghost repeats). > It appears that the delay to check whether the key has been released is > too long (almost order of magnitude longer than our typical autorepeat > period). I think we should increase the period for remotes (both in > kernel and in X, and also see if the release check delay can be made > shorter, like 50-100 ms. To make the ghost repeat issue disappear, one would have to use a release timeout of just over the native repeat rate of the remote, and a softrepeat period of just over the release timeout, right? This will make the repeat rate slower than the native repeats. I'm not 100% sure if that is an issue, but I'd guess there might be some devices that already have a slowish repeat rate, where we wouldn't want to add such additional delay. (plus there is the issue of having to fiddle the rates for every device/protocol) -- Anssi Hannula -- 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: IR remote control autorepeat / evdev
On 11.05.2011 19:51, Mauro Carvalho Chehab wrote: > Em 11-05-2011 18:33, Anssi Hannula escreveu: >> On 11.05.2011 07:46, Mauro Carvalho Chehab wrote: >>> Hi Anssi/Peter, >> >> Hi! >> >>> Em 10-05-2011 15:43, Anssi Hannula escreveu: >>>> On 10.05.2011 08:30, Peter Hutterer wrote: >>>>> On Tue, May 10, 2011 at 08:14:30AM +0300, Anssi Hannula wrote: >>>>>> On 10.05.2011 07:11, Peter Hutterer wrote: >>>>>>> On Sun, May 08, 2011 at 07:38:00AM +0300, Anssi Hannula wrote: >>>>>>>> Hi all! >>>>>>>> >>>>>>>> Most IR/RF remotes differ from normal keyboards in that they don't >>>>>>>> provide release events. They do provide native repeat events, though. >>>>>>>> >>>>>>>> Currently the Linux kernel RC/input subsystems provide a simulated >>>>>>>> autorepeat for remote controls (default delay 500ms, period 33ms), and >>>>>>>> X.org server ignores these events and generates its own autorepeat for >>>>>>>> them. >>>>>>>> >>>>>>>> The kernel RC subsystem provides a simulated release event when 250ms >>>>>>>> has passed since the last native event (repeat or non-repeat) was >>>>>>>> received from the device. >>>>>>>> >>>>>>>> This is problematic, since it causes lots of extra repeat events to be >>>>>>>> always sent (for up to 250ms) after the user has released the remote >>>>>>>> control button, which makes the remote quite uncomfortable to use. >>>>>>> >>>>>>> I got a bit confused reading this description. Does this mean that >>>>>>> remotes >>>>>>> usually send: >>>>>>> key press - repeat - repeat - ... - repeat - >>>>>>> where the silence indicates that the key has been released? Which the >>>>>>> kernel >>>>>>> after 250ms translates into a release event. >>>>>>> And the kernel discards the repeats and generates it's own on 500/33? >>>>>>> Do I get this right so far? >>>>>> >>>>>> Yes. >>>>>> >>>>>>> If so, I'm not sure how to avoid the 250ms delay since we have no >>>>>>> indication >>>>>>> from the hardware when the silence will stop, right? >>>>>> >>>>>> Yes. >>>>>> AFAICS what we need is to not use softrepeat for these devices and >>>>>> instead use the native repeats. The 250ms release delay could then be >>>>>> kept (as it wouldn't cause unwanted repeats anymore) or it could be made >>>>>> 0ms if that is deemed better. >>>>>> >>>>>> I listed some ways to do that below in my original post. >>>>>> >>>>>>> Note that the repeat delay and ratio are configurable per-device using >>>>>>> XKB, >>>>>>> so you could set up the 500/33 in X too. >>> >>> While 500/33 is good for keyboards, this is generally not good for remote >>> controllers. >> >> 500/33 is the one kernel uses for remotes. > > No. It actually depends on what driver you're using. For example, for most > dvb-usb > devices, this is given by the logic bellow: > > if (d->props.rc.legacy.rc_interval < 40) > d->props.rc.legacy.rc_interval = 100; /* default */ > > input_dev->rep[REP_PERIOD] = d->props.rc.legacy.rc_interval; > input_dev->rep[REP_DELAY] = d->props.rc.legacy.rc_interval + 150; > > where the rc_interval defined by device entry at the dvb usb drivers. Isn't that function only called for DVB_RC_LEGACY mode? Maybe I wasn't clear, but I'm talking only about the devices handled by rc-core. >>> The bit rate for IR transmissions are slow. So, one keypress can last up to >>> about >>> 110 ms[1]. That means that the maximum repeat rate for IR devices with such >>> protocol should be bellow than 10 keystrokes/sec. >>> >>> Also, the minimum initial delay for IR needs to be different on a few >>> hardware that >>> have a broken IR implementation. We default it to 500ms, but a few drivers >>> change it >>> to fit into some hardware co
Re: IR remote control autorepeat / evdev
On 11.05.2011 07:46, Mauro Carvalho Chehab wrote: > Hi Anssi/Peter, Hi! > Em 10-05-2011 15:43, Anssi Hannula escreveu: >> On 10.05.2011 08:30, Peter Hutterer wrote: >>> On Tue, May 10, 2011 at 08:14:30AM +0300, Anssi Hannula wrote: >>>> On 10.05.2011 07:11, Peter Hutterer wrote: >>>>> On Sun, May 08, 2011 at 07:38:00AM +0300, Anssi Hannula wrote: >>>>>> Hi all! >>>>>> >>>>>> Most IR/RF remotes differ from normal keyboards in that they don't >>>>>> provide release events. They do provide native repeat events, though. >>>>>> >>>>>> Currently the Linux kernel RC/input subsystems provide a simulated >>>>>> autorepeat for remote controls (default delay 500ms, period 33ms), and >>>>>> X.org server ignores these events and generates its own autorepeat for >>>>>> them. >>>>>> >>>>>> The kernel RC subsystem provides a simulated release event when 250ms >>>>>> has passed since the last native event (repeat or non-repeat) was >>>>>> received from the device. >>>>>> >>>>>> This is problematic, since it causes lots of extra repeat events to be >>>>>> always sent (for up to 250ms) after the user has released the remote >>>>>> control button, which makes the remote quite uncomfortable to use. >>>>> >>>>> I got a bit confused reading this description. Does this mean that remotes >>>>> usually send: >>>>> key press - repeat - repeat - ... - repeat - >>>>> where the silence indicates that the key has been released? Which the >>>>> kernel >>>>> after 250ms translates into a release event. >>>>> And the kernel discards the repeats and generates it's own on 500/33? >>>>> Do I get this right so far? >>>> >>>> Yes. >>>> >>>>> If so, I'm not sure how to avoid the 250ms delay since we have no >>>>> indication >>>>> from the hardware when the silence will stop, right? >>>> >>>> Yes. >>>> AFAICS what we need is to not use softrepeat for these devices and >>>> instead use the native repeats. The 250ms release delay could then be >>>> kept (as it wouldn't cause unwanted repeats anymore) or it could be made >>>> 0ms if that is deemed better. >>>> >>>> I listed some ways to do that below in my original post. >>>> >>>>> Note that the repeat delay and ratio are configurable per-device using >>>>> XKB, >>>>> so you could set up the 500/33 in X too. > > While 500/33 is good for keyboards, this is generally not good for remote > controllers. 500/33 is the one kernel uses for remotes. > The bit rate for IR transmissions are slow. So, one keypress can last up to > about > 110 ms[1]. That means that the maximum repeat rate for IR devices with such > protocol should be bellow than 10 keystrokes/sec. > > Also, the minimum initial delay for IR needs to be different on a few > hardware that > have a broken IR implementation. We default it to 500ms, but a few drivers > change it > to fit into some hardware constraits. So, a few kernel driver have some > tweaks of > repeat times, to be sure that the device will work properly. > > [1] http://www.sbprojects.com/knowledge/ir/nec.htm > >>>> It wouldn't make any difference with the actual issue which is >>>> "autorepeat happening after physical key released". >>>> >>>> I guess the reason this hasn't come up earlier is that the unified IR/RC >>>> subsystem in the linux kernel is still quite new. It definitely needs to >>>> be improved regarding this issue - just trying to figure out the best >>>> way to do it. > > The repeat events always generated troubles, as it basically depends on how > the hardware actually handles it. Some hardware decoders and some protocols > support repeat events, while others don't. There are even some remote > controllers > that, instead of generating repeat codes, they just generate multiple > keypresses. > > With the rc-core, we've unified the repeat treatment (yet, there are some > exceptions to the default way, for some devices where that uses broken > hardware > decoders). > >>> right. we used to have hardware repeats in X a few releases back. I think >>> 1.6 was the first one that s
Re: IR remote control autorepeat / evdev
On 10.05.2011 08:30, Peter Hutterer wrote: > On Tue, May 10, 2011 at 08:14:30AM +0300, Anssi Hannula wrote: >> On 10.05.2011 07:11, Peter Hutterer wrote: >>> On Sun, May 08, 2011 at 07:38:00AM +0300, Anssi Hannula wrote: >>>> Hi all! >>>> >>>> Most IR/RF remotes differ from normal keyboards in that they don't >>>> provide release events. They do provide native repeat events, though. >>>> >>>> Currently the Linux kernel RC/input subsystems provide a simulated >>>> autorepeat for remote controls (default delay 500ms, period 33ms), and >>>> X.org server ignores these events and generates its own autorepeat for >>>> them. >>>> >>>> The kernel RC subsystem provides a simulated release event when 250ms >>>> has passed since the last native event (repeat or non-repeat) was >>>> received from the device. >>>> >>>> This is problematic, since it causes lots of extra repeat events to be >>>> always sent (for up to 250ms) after the user has released the remote >>>> control button, which makes the remote quite uncomfortable to use. >>> >>> I got a bit confused reading this description. Does this mean that remotes >>> usually send: >>> key press - repeat - repeat - ... - repeat - >>> where the silence indicates that the key has been released? Which the kernel >>> after 250ms translates into a release event. >>> And the kernel discards the repeats and generates it's own on 500/33? >>> Do I get this right so far? >> >> Yes. >> >>> If so, I'm not sure how to avoid the 250ms delay since we have no indication >>> from the hardware when the silence will stop, right? >> >> Yes. >> AFAICS what we need is to not use softrepeat for these devices and >> instead use the native repeats. The 250ms release delay could then be >> kept (as it wouldn't cause unwanted repeats anymore) or it could be made >> 0ms if that is deemed better. >> >> I listed some ways to do that below in my original post. >> >>> Note that the repeat delay and ratio are configurable per-device using XKB, >>> so you could set up the 500/33 in X too. >> >> It wouldn't make any difference with the actual issue which is >> "autorepeat happening after physical key released". >> >> I guess the reason this hasn't come up earlier is that the unified IR/RC >> subsystem in the linux kernel is still quite new. It definitely needs to >> be improved regarding this issue - just trying to figure out the best >> way to do it. > > right. we used to have hardware repeats in X a few releases back. I think > 1.6 was the first one that shifted to pure software autorepeat. One of the > results we saw in the transition period was the clash of hw autorepeat (in > X's input system, anything that comes out of the kernel counts as "hw") and > software repeat. > > Integrating them back in is going to be a bit iffy, especially since you > need the integration with XKB on each device, essentially disallowing the > clients from enabling autorepeat. Not 100% what's required there. > The evtev part is going to be the simplest part of all that. I suspected it might be tricky. So maybe (at least for the time being) remote controls in X should simply get KeyRelease immediately after every KeyPress? Meaning that either a) kernel does it (while maybe providing some new extra info for those evdev users that want to distinguish repeats from new keypresses - original suggestion 4), or b) kernel provides a flag which causes the X evdev driver to follow-up every keydown/repeat event with an immediate release event. (both of these include kernel changed to use native repeats instead of softrepeats, which is trivial) >>>> Now, IMO something should be done to fix this. But what exactly? >>>> >>>> Here are two ideas that would remove these ghost repeats: >>>> >>>> 1. Do not provide any repeat/release simulation in the kernel for RC >>>> devices (by default?), just provide both keydown and immediate release >>>> events for every native keypress or repeat received from the device. >>>> + Very simple to implement >>>> - We lose the ability to track repeats, i.e. if a new event was a repeat >>>> or a new keypress; "holding down" a key becomes impossible >>>> >>>> or >>>> 2. Replace kernel autorepeat simulation by passing through the native >>>> repeat events (probably filtering them accord
Re: IR remote control autorepeat / evdev
On 10.05.2011 07:11, Peter Hutterer wrote: > On Sun, May 08, 2011 at 07:38:00AM +0300, Anssi Hannula wrote: >> Hi all! >> >> Most IR/RF remotes differ from normal keyboards in that they don't >> provide release events. They do provide native repeat events, though. >> >> Currently the Linux kernel RC/input subsystems provide a simulated >> autorepeat for remote controls (default delay 500ms, period 33ms), and >> X.org server ignores these events and generates its own autorepeat for them. >> >> The kernel RC subsystem provides a simulated release event when 250ms >> has passed since the last native event (repeat or non-repeat) was >> received from the device. >> >> This is problematic, since it causes lots of extra repeat events to be >> always sent (for up to 250ms) after the user has released the remote >> control button, which makes the remote quite uncomfortable to use. > > I got a bit confused reading this description. Does this mean that remotes > usually send: > key press - repeat - repeat - ... - repeat - > where the silence indicates that the key has been released? Which the kernel > after 250ms translates into a release event. > And the kernel discards the repeats and generates it's own on 500/33? > Do I get this right so far? Yes. > If so, I'm not sure how to avoid the 250ms delay since we have no indication > from the hardware when the silence will stop, right? Yes. AFAICS what we need is to not use softrepeat for these devices and instead use the native repeats. The 250ms release delay could then be kept (as it wouldn't cause unwanted repeats anymore) or it could be made 0ms if that is deemed better. I listed some ways to do that below in my original post. > Note that the repeat delay and ratio are configurable per-device using XKB, > so you could set up the 500/33 in X too. It wouldn't make any difference with the actual issue which is "autorepeat happening after physical key released". I guess the reason this hasn't come up earlier is that the unified IR/RC subsystem in the linux kernel is still quite new. It definitely needs to be improved regarding this issue - just trying to figure out the best way to do it. > Cheers, > Peter > >> Now, IMO something should be done to fix this. But what exactly? >> >> Here are two ideas that would remove these ghost repeats: >> >> 1. Do not provide any repeat/release simulation in the kernel for RC >> devices (by default?), just provide both keydown and immediate release >> events for every native keypress or repeat received from the device. >> + Very simple to implement >> - We lose the ability to track repeats, i.e. if a new event was a repeat >> or a new keypress; "holding down" a key becomes impossible >> >> or >> 2. Replace kernel autorepeat simulation by passing through the native >> repeat events (probably filtering them according to REP_DELAY and >> REP_PERIOD), and have a device property bit (fetchable via EVIOCGPROP) >> indicating that the keyrelease is simulated, and have the X server use >> the native repeats instead of softrepeats for such a device. >> + The userspace correctly gets repeat events tagged as repeats and >> release events when appropriate (albeit a little late) >> - Adds complexity. Also, while the kernel part is quite easy to >> implement, I'm not sure if the X server part is. >> >> or >> 3. Same as 1., but indicate the repeatness of an event with a new >>additional special event before EV_SYN (sync event). >> + Simple to implement >> - Quite hacky, and userspace still can't guess from initial >> keypress/release if the key is still pressed down or not. >> >> 4. Same as 1., but have a new EV_RC with RC_KEYDOWN and RC_KEYUP events, >>with RC_KEYDOWN sent when a key is pressed down a first time along >>with the normal EV_KEY event, and RC_KEYUP sent when the key is >>surely released (e.g. 250ms without native repeat events or another >>key got pressed, i.e. like the simulated keyup now). >> + Simple to implement, works as expected with most userspace apps with >> no changes to them; and if an app wants to know the repeatness of an >> event or held-down-ness of a key, it can do that. >> - Repeatness of the event is hidden behind a new API. >> >> What do you think? Or any other ideas? >> >> 2 and 4 seem nicest to me. >> (I don't know how feasible 2 would be on X server side, though) >> >> -- >> Anssi Hannula >> ___ >> xorg-de...@lists.x.org: X.Org development >> Archives: http://lists.x.org/archives/xorg-devel >> Info: http://lists.x.org/mailman/listinfo/xorg-devel >> > -- Anssi Hannula -- 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
IR remote control autorepeat / evdev
Hi all! Most IR/RF remotes differ from normal keyboards in that they don't provide release events. They do provide native repeat events, though. Currently the Linux kernel RC/input subsystems provide a simulated autorepeat for remote controls (default delay 500ms, period 33ms), and X.org server ignores these events and generates its own autorepeat for them. The kernel RC subsystem provides a simulated release event when 250ms has passed since the last native event (repeat or non-repeat) was received from the device. This is problematic, since it causes lots of extra repeat events to be always sent (for up to 250ms) after the user has released the remote control button, which makes the remote quite uncomfortable to use. Now, IMO something should be done to fix this. But what exactly? Here are two ideas that would remove these ghost repeats: 1. Do not provide any repeat/release simulation in the kernel for RC devices (by default?), just provide both keydown and immediate release events for every native keypress or repeat received from the device. + Very simple to implement - We lose the ability to track repeats, i.e. if a new event was a repeat or a new keypress; "holding down" a key becomes impossible or 2. Replace kernel autorepeat simulation by passing through the native repeat events (probably filtering them according to REP_DELAY and REP_PERIOD), and have a device property bit (fetchable via EVIOCGPROP) indicating that the keyrelease is simulated, and have the X server use the native repeats instead of softrepeats for such a device. + The userspace correctly gets repeat events tagged as repeats and release events when appropriate (albeit a little late) - Adds complexity. Also, while the kernel part is quite easy to implement, I'm not sure if the X server part is. or 3. Same as 1., but indicate the repeatness of an event with a new additional special event before EV_SYN (sync event). + Simple to implement - Quite hacky, and userspace still can't guess from initial keypress/release if the key is still pressed down or not. 4. Same as 1., but have a new EV_RC with RC_KEYDOWN and RC_KEYUP events, with RC_KEYDOWN sent when a key is pressed down a first time along with the normal EV_KEY event, and RC_KEYUP sent when the key is surely released (e.g. 250ms without native repeat events or another key got pressed, i.e. like the simulated keyup now). + Simple to implement, works as expected with most userspace apps with no changes to them; and if an app wants to know the repeatness of an event or held-down-ness of a key, it can do that. - Repeatness of the event is hidden behind a new API. What do you think? Or any other ideas? 2 and 4 seem nicest to me. (I don't know how feasible 2 would be on X server side, though) -- Anssi Hannula -- 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: Some issues with imon input driver
Jarod Wilson kirjoitti keskiviikko, 7. heinäkuuta 2010 16:52:59: > On Wed, Jul 07, 2010 at 05:36:45AM +0300, Anssi Hannula wrote: > > Hi! > > > > I tried to set up my imon remote, but run into the issue of buttons > > getting easily stuck. And while looking at the code, I noticed some more > > issues :) > > I'm not entirely surprised, I knew there were a few quirks left I'd not > yet fully sorted out. Generally, it works quite well, but I didn't abuse > the receiver quite as thoroughly as you. ;) > > Can I talk you into filing a bug to track this? I can probably work up > fixes for a number of these sooner or later, if you don't beat me to them, > but it'd be easy for one or more of the specific problems to slip through > the cracks if not logged somewhere. My From: address here matches my > b.k.o. account, if you want to assign said bug to me. Done, though I didn't have the permissions to assign it to you: https://bugzilla.kernel.org/show_bug.cgi?id=16351 > Ah, and because we're actually handing remote controls via > drivers/media/IR/, you should cc linux-media as well (if not instead of > linux-input) on anything regarding this driver. OK. BTW, I wonder if we should also disable kernel autorepeat and use the remote control's own repeat signals instead? Then extra repeat codes would not not emitted if the release signal is missed. -- Anssi Hannula -- 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
[PATCH] dvb-apps scan: fix zero transport stream id
scan sometimes returns services with transport stream id = 0. This
happens when the service is allocated before the transport stream
id is known. This patch simply makes copy_transponder propagate
transport stream id changes to all services of the transponder.
Symptoms of zero transport stream id include VDR not showing EPG.
Signed-off-by: Anssi Hannula
---
Index: dvb-apps-1181/util/scan/scan.c
===
--- dvb-apps-1181/util/scan/scan.c
+++ dvb-apps-1181/util/scan/scan.c 2010-01-24 22:22:25.092513605 +0200
@@ -236,6 +236,17 @@
static void copy_transponder(struct transponder *d, struct transponder *s)
{
+ struct list_head *pos;
+ struct service *service;
+
+ if (d->transport_stream_id != s->transport_stream_id) {
+ /* propagate change to any already allocated services */
+ list_for_each(pos, &d->services) {
+ service = list_entry(pos, struct service, list);
+ service->transport_stream_id = s->transport_stream_id;
+ }
+ }
+
d->network_id = s->network_id;
d->original_network_id = s->original_network_id;
d->transport_stream_id = s->transport_stream_id;
--
Anssi Hannula
--
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: Viewing HD?
Mikhail Ramendik wrote: > Hello, Hi! [...] > Instant recording worked. In mplayer, the result was viewed very > jerkily, with many messages saying "PAFF + spatial direct mode is not > implemented"; the codec was ffmpeg h.264. CPU load was maxed out > (Pentium 3 GHz). AFAIK this support was added quite some time ago; you need to upgrade your mplayer. -- Anssi Hannula -- 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: How to handle devices sitting on multiple busses ?
Laurent Pinchart wrote: [...] > As the bridge and I2C master live their own life in the Linux device tree, > they are initialized, suspended, resumed and destroyed independently. The > sensor being an I2C slave device, Linux initializes it after the I2C master > device is initialized, but doesn't ensure that the bridge is initialized > first > as well. A similar problem occurs during suspend/resume, as the I2C slave > needs to be suspended before and resumed after the video bridge. > > Have you ever encountered such a situation before ? Is there a clean way for > a > device to have multiple parents, or do you have plans for such a possibility > in the future ? I would be willing to give an implementation a try if you can > provide me with some guidelines. > It looks to me like this patch is related to your problem: http://article.gmane.org/gmane.linux.power-management.general/15651 With a quick glance it doesn't seem to involve changes in device initialization or destroying, though, but this is not really my area of expertise. -- Anssi Hannula -- 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
