From: Dmitry Torokhov <dmitry.torokhov@gmail.com> To: Mauro Carvalho Chehab <mchehab@redhat.com> Cc: Jon Smirl <jonsmirl@gmail.com>, Pavel Machek <pavel@ucw.cz>, Krzysztof Halasa <khc@pm.waw.pl>, hermann pitton <hermann-pitton@arcor.de>, Christoph Bartelmus <lirc@bartelmus.de>, awalls@radix.net, j@jannau.net, jarod@redhat.com, jarod@wilsonet.com, kraxel@redhat.com, linux-input@vger.kernel.org, linux-kernel@vger.kernel.org, linux-media@vger.kernel.org, superm1@ubuntu.com Subject: Re: [RFC] What are the goals for the architecture of an in-kernel IR system? Date: Fri, 26 Mar 2010 09:01:50 -0700 [thread overview] Message-ID: <20100326160150.GA28804@core.coreip.homeip.net> (raw) In-Reply-To: <4BACC769.6020906@redhat.com> On Fri, Mar 26, 2010 at 11:40:41AM -0300, Mauro Carvalho Chehab wrote: > David Härdeman wrote: > > On Thu, Mar 25, 2010 at 11:42:33AM -0300, Mauro Carvalho Chehab wrote: > >>> 10) extend keycode table replacement to support big/variable > >>> sized scancodes; > >> Pending. > >> > >> The current limit here is the scancode ioctl's are defined as: > >> > >> #define EVIOCGKEYCODE _IOR('E', 0x04, int[2]) /* get keycode */ > >> #define EVIOCSKEYCODE _IOW('E', 0x04, int[2]) /* set keycode */ > >> > >> As int size is 32 bits, and we must pass both 64 (or even bigger) scancodes, associated > >> with a keycode, there's not enough bits there for IR. > >> > >> The better approach seems to create an struct with an arbitrary long size, like: > >> > >> struct keycode_table_entry { > >> unsigned keycode; > >> char scancode[32]; /* 32 is just an arbitrary long array - maybe shorter */ > >> int len; > >> } > >> > >> and re-define the ioctls. For example we might be doing: > >> > >> #define EVIOCGKEYCODEBIG _IOR('E', 0x04, struct keycode_table_entry) > >> #define EVIOCSKEYCODEBIG _IOW('E', 0x04, struct keycode_table_entry) > >> #define EVIOCLEARKEYCODEBIG _IOR('E', 0x04, void) > >> > >> Provided that the size for struct keycode_table_entry is different, _IO will generate > >> a different magic number for those. > >> > >> Or, instead of using 0x04, just use another sequential number at the 'E' namespace. > >> > >> An specific function to clear the table is needed with big scancode space, > >> as already discussed. > >> > > > > I'd suggest: > > > > struct keycode_table_entry { > > unsigned keycode; > > unsigned index; > > unsigned len; > > char scancode[]; > > }; > > > > Use index in EVIOCGKEYCODEBIG to look up a keycode (all other fields are > > ignored), that way no special function to clear the table is necessary, > > instead you do a loop with: > > > > EVIOCGKEYCODEBIG (with index 0) > > EVIOCSKEYCODEBIG (with the returned struct from EVIOCGKEYCODEBIG and > > keycode = KEY_RESERVED) > > > > until EVIOCGKEYCODEBIG returns an error. > > Makes sense. Yes, I think so too. Just need a nice way to handle transition, I'd like in the end to have drivers implement only the improved methods and map legacy methods in evdev. > > > This also allows you to get all the current mappings from the kernel > > without having to blindly search through an arbitrarily large keyspace. > > > > Also, EVIOCLEARKEYCODEBIG should be: > > > > #define EVIOCLEARKEYCODEBIG _IOR('E', 0x04, struct keycode_table_entry) > > > > That way a user space application can simply call EVIOCLEARKEYCODEBIG, > > ask the user for an appropriate keycode, fill in the keycode member of > > the struct returned from EVIOCLEARKEYCODEBIG and call EVIOCSKEYCODEBIG. > > By using the index concept, I don't think we need another ioctl. Also, > there's no way for kernel to handle it, as it will be using the same > magic number of EVIOCGKEYCODEBIG. > > > On a related note, I really think the interface would benefit from > > allowing more than one keytable per irrcv device with an input device > > created per keytable. That way you can have one input device per remote > > control. This implies that EVIOCLEARKEYCODEBIG is a bit misplaced as an > > evdev IOCTL since there's an N-1 mapping between input devices and irrcv > > devices. > > I don't think that an ioctl over one /dev/input/event should be the proper way > to ask kernel to create another filtered /dev/input/event. As it were commented > that the multimedia keys on some keyboards could benefit on having a filter > capability, maybe we may have a sysfs node at class input that would allow > the creation/removal of the filtered event interface. No, if you want separate event devices just create a new instance of input device for every keymap and have driver/irrcv class route events to proper input device. Thanks. -- Dmitry
WARNING: multiple messages have this Message-ID (diff)
From: Dmitry Torokhov <dmitry.torokhov@gmail.com> To: Mauro Carvalho Chehab <mchehab@redhat.com> Cc: Jon Smirl <jonsmirl@gmail.com>, Pavel Machek <pavel@ucw.cz>, Krzysztof Halasa <khc@pm.waw.pl>, hermann pitton <hermann-pitton@arcor.de>, Christoph Bartelmus <lirc@bartelmus.de>, awalls@radix.net, j@jannau.net, jarod@redhat.com, jarod@wilsonet.com, kraxel@redhat.com, linux-input@vger.kernel.org, linux-kernel@vger.kernel.org, linux-media@vger.kernel.org, superm1@ubuntu.com Subject: Re: [RFC] What are the goals for the architecture of an in-kernel IR system? Date: Fri, 26 Mar 2010 09:01:50 -0700 [thread overview] Message-ID: <20100326160150.GA28804@core.coreip.homeip.net> (raw) In-Reply-To: <4BACC769.6020906@redhat.com> On Fri, Mar 26, 2010 at 11:40:41AM -0300, Mauro Carvalho Chehab wrote: > David Härdeman wrote: > > On Thu, Mar 25, 2010 at 11:42:33AM -0300, Mauro Carvalho Chehab wrote: > >>> 10) extend keycode table replacement to support big/variable > >>> sized scancodes; > >> Pending. > >> > >> The current limit here is the scancode ioctl's are defined as: > >> > >> #define EVIOCGKEYCODE _IOR('E', 0x04, int[2]) /* get keycode */ > >> #define EVIOCSKEYCODE _IOW('E', 0x04, int[2]) /* set keycode */ > >> > >> As int size is 32 bits, and we must pass both 64 (or even bigger) scancodes, associated > >> with a keycode, there's not enough bits there for IR. > >> > >> The better approach seems to create an struct with an arbitrary long size, like: > >> > >> struct keycode_table_entry { > >> unsigned keycode; > >> char scancode[32]; /* 32 is just an arbitrary long array - maybe shorter */ > >> int len; > >> } > >> > >> and re-define the ioctls. For example we might be doing: > >> > >> #define EVIOCGKEYCODEBIG _IOR('E', 0x04, struct keycode_table_entry) > >> #define EVIOCSKEYCODEBIG _IOW('E', 0x04, struct keycode_table_entry) > >> #define EVIOCLEARKEYCODEBIG _IOR('E', 0x04, void) > >> > >> Provided that the size for struct keycode_table_entry is different, _IO will generate > >> a different magic number for those. > >> > >> Or, instead of using 0x04, just use another sequential number at the 'E' namespace. > >> > >> An specific function to clear the table is needed with big scancode space, > >> as already discussed. > >> > > > > I'd suggest: > > > > struct keycode_table_entry { > > unsigned keycode; > > unsigned index; > > unsigned len; > > char scancode[]; > > }; > > > > Use index in EVIOCGKEYCODEBIG to look up a keycode (all other fields are > > ignored), that way no special function to clear the table is necessary, > > instead you do a loop with: > > > > EVIOCGKEYCODEBIG (with index 0) > > EVIOCSKEYCODEBIG (with the returned struct from EVIOCGKEYCODEBIG and > > keycode = KEY_RESERVED) > > > > until EVIOCGKEYCODEBIG returns an error. > > Makes sense. Yes, I think so too. Just need a nice way to handle transition, I'd like in the end to have drivers implement only the improved methods and map legacy methods in evdev. > > > This also allows you to get all the current mappings from the kernel > > without having to blindly search through an arbitrarily large keyspace. > > > > Also, EVIOCLEARKEYCODEBIG should be: > > > > #define EVIOCLEARKEYCODEBIG _IOR('E', 0x04, struct keycode_table_entry) > > > > That way a user space application can simply call EVIOCLEARKEYCODEBIG, > > ask the user for an appropriate keycode, fill in the keycode member of > > the struct returned from EVIOCLEARKEYCODEBIG and call EVIOCSKEYCODEBIG. > > By using the index concept, I don't think we need another ioctl. Also, > there's no way for kernel to handle it, as it will be using the same > magic number of EVIOCGKEYCODEBIG. > > > On a related note, I really think the interface would benefit from > > allowing more than one keytable per irrcv device with an input device > > created per keytable. That way you can have one input device per remote > > control. This implies that EVIOCLEARKEYCODEBIG is a bit misplaced as an > > evdev IOCTL since there's an N-1 mapping between input devices and irrcv > > devices. > > I don't think that an ioctl over one /dev/input/event should be the proper way > to ask kernel to create another filtered /dev/input/event. As it were commented > that the multimedia keys on some keyboards could benefit on having a filter > capability, maybe we may have a sysfs node at class input that would allow > the creation/removal of the filtered event interface. No, if you want separate event devices just create a new instance of input device for every keymap and have driver/irrcv class route events to proper input device. Thanks. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2010-03-26 16:02 UTC|newest] Thread overview: 358+ messages / expand[flat|nested] mbox.gz Atom feed top 2009-11-27 15:57 [RFC] What are the goals for the architecture of an in-kernel IR system? Jon Smirl 2009-11-27 15:57 ` Jon Smirl 2009-11-27 16:57 ` Andy Walls 2009-11-27 17:29 ` Christoph Bartelmus 2009-11-27 17:29 ` Christoph Bartelmus 2009-11-27 17:49 ` Jon Smirl 2009-11-27 17:49 ` Jon Smirl 2009-11-27 19:03 ` Ferenc Wagner 2009-11-27 19:21 ` Jon Smirl 2009-11-27 19:21 ` Jon Smirl 2009-11-28 1:34 ` Dmitry Torokhov 2009-11-29 12:01 ` Christoph Bartelmus 2009-11-29 12:01 ` Christoph Bartelmus 2009-11-30 10:41 ` Mauro Carvalho Chehab 2009-11-30 19:49 ` Krzysztof Halasa 2009-11-30 21:35 ` Jon Smirl 2009-11-30 21:35 ` Jon Smirl 2009-12-01 7:45 ` Christoph Bartelmus 2009-12-01 7:45 ` Christoph Bartelmus 2009-12-01 11:38 ` Andy Walls 2009-12-01 14:10 ` Maxim Levitsky 2009-12-03 17:31 ` Krzysztof Halasa 2009-12-03 17:31 ` Krzysztof Halasa 2009-11-28 9:04 ` Simon Kenyon 2009-11-28 9:04 ` Simon Kenyon 2009-11-28 9:04 ` Simon Kenyon 2009-11-28 11:21 ` Mauro Carvalho Chehab 2009-11-29 11:50 ` Christoph Bartelmus 2009-11-29 11:50 ` Christoph Bartelmus 2009-11-30 12:34 ` Mauro Carvalho Chehab 2009-12-01 9:52 ` Gerd Hoffmann 2009-12-01 13:11 ` Mauro Carvalho Chehab 2009-12-01 14:32 ` Jarod Wilson 2009-12-01 10:20 ` Gerd Hoffmann 2009-12-01 14:14 ` Mauro Carvalho Chehab 2009-12-01 15:28 ` Gerd Hoffmann 2009-12-03 4:29 ` Jarod Wilson 2009-12-03 12:09 ` Gerd Hoffmann 2009-12-03 17:55 ` Dmitry Torokhov 2009-12-03 18:33 ` Mauro Carvalho Chehab 2009-12-04 10:06 ` Dmitry Torokhov 2009-12-04 14:12 ` Mauro Carvalho Chehab 2009-12-04 15:42 ` Jon Smirl 2009-12-04 15:42 ` Jon Smirl 2009-12-06 7:09 ` Dmitry Torokhov 2009-12-06 11:03 ` Mauro Carvalho Chehab 2009-12-06 20:19 ` Krzysztof Halasa 2009-12-08 0:00 ` Mauro Carvalho Chehab 2009-12-08 14:06 ` Krzysztof Halasa 2009-12-07 7:48 ` Dmitry Torokhov 2009-12-07 15:34 ` Mauro Carvalho Chehab 2009-12-07 18:34 ` Dmitry Torokhov 2009-12-07 23:01 ` Mauro Carvalho Chehab 2009-12-06 7:14 ` Dmitry Torokhov 2009-12-06 11:23 ` Mauro Carvalho Chehab 2009-12-03 18:56 ` Jon Smirl 2009-12-03 18:56 ` Jon Smirl 2009-12-03 18:56 ` Jon Smirl 2009-12-03 21:10 ` Mauro Carvalho Chehab 2009-12-03 21:51 ` Christoph Bartelmus 2009-12-03 21:51 ` Christoph Bartelmus 2009-12-03 22:12 ` Dmitry Torokhov 2009-12-04 7:37 ` Christoph Bartelmus 2009-12-04 7:37 ` Christoph Bartelmus 2009-12-04 14:33 ` Mauro Carvalho Chehab 2009-12-04 21:46 ` Christoph Bartelmus 2009-12-04 21:46 ` Christoph Bartelmus 2009-12-04 22:07 ` Dmitry Torokhov 2009-12-04 23:01 ` Christoph Bartelmus 2009-12-04 23:01 ` Christoph Bartelmus 2009-12-04 23:15 ` Dmitry Torokhov 2009-12-06 11:58 ` Christoph Bartelmus 2009-12-06 11:58 ` Christoph Bartelmus 2009-12-07 7:51 ` Dmitry Torokhov 2009-12-08 22:27 ` Christoph Bartelmus 2009-12-08 22:27 ` Christoph Bartelmus 2009-12-05 0:28 ` Jon Smirl 2009-12-05 0:28 ` Jon Smirl 2009-12-05 1:48 ` Andy Walls 2009-12-05 2:10 ` Andy Walls 2009-12-05 3:45 ` Jon Smirl 2009-12-05 3:45 ` Jon Smirl 2009-12-06 2:30 ` Andy Walls 2009-12-06 17:26 ` Krzysztof Halasa 2009-12-12 22:52 ` david 2009-12-06 3:36 ` hermann pitton 2009-12-06 6:55 ` Dmitry Torokhov 2009-12-06 11:46 ` Mauro Carvalho Chehab 2009-12-06 17:48 ` Krzysztof Halasa 2009-12-06 17:52 ` Jon Smirl 2009-12-06 17:52 ` Jon Smirl 2009-12-06 20:34 ` Krzysztof Halasa 2009-12-06 21:23 ` Jon Smirl 2009-12-06 21:23 ` Jon Smirl 2009-12-07 23:44 ` Mauro Carvalho Chehab 2009-12-08 0:28 ` Jon Smirl 2009-12-08 0:28 ` Jon Smirl 2009-12-08 0:28 ` Jon Smirl 2009-12-08 11:17 ` Mauro Carvalho Chehab 2009-12-08 13:34 ` Jon Smirl 2009-12-08 13:34 ` Jon Smirl 2009-12-08 13:34 ` Jon Smirl 2009-12-08 14:56 ` Mauro Carvalho Chehab 2009-12-08 22:25 ` Christoph Bartelmus 2009-12-08 22:25 ` Christoph Bartelmus 2009-12-08 17:04 ` Dmitry Torokhov 2009-12-08 13:54 ` Krzysztof Halasa 2009-12-08 4:23 ` Dmitry Torokhov 2009-12-08 11:58 ` Mauro Carvalho Chehab 2009-12-08 14:01 ` Krzysztof Halasa 2009-12-08 14:13 ` Mauro Carvalho Chehab 2009-12-08 15:26 ` Krzysztof Halasa 2009-12-08 15:41 ` Mauro Carvalho Chehab 2009-12-08 17:12 ` Dmitry Torokhov 2009-12-08 13:57 ` Krzysztof Halasa 2009-12-08 17:25 ` Dmitry Torokhov 2009-12-08 13:52 ` Krzysztof Halasa 2009-12-08 14:07 ` Mauro Carvalho Chehab 2009-12-08 14:51 ` Jon Smirl 2009-12-08 14:51 ` Jon Smirl 2009-12-08 15:29 ` Krzysztof Halasa 2009-12-08 15:49 ` Mauro Carvalho Chehab 2009-12-08 16:26 ` Jon Smirl 2009-12-08 16:26 ` Jon Smirl 2009-12-08 4:10 ` Andy Walls 2009-12-08 22:30 ` Christoph Bartelmus 2009-12-08 22:30 ` Christoph Bartelmus 2009-12-09 2:21 ` Andy Walls 2009-12-07 18:41 ` Dmitry Torokhov 2009-12-07 20:08 ` Krzysztof Halasa 2009-12-07 21:38 ` Dmitry Torokhov 2009-12-08 15:24 ` Krzysztof Halasa 2009-12-08 0:44 ` Jon Smirl 2009-12-08 0:44 ` Jon Smirl 2009-12-08 11:23 ` Mauro Carvalho Chehab 2009-12-13 12:14 ` Mauro Carvalho Chehab 2009-12-15 11:50 ` Pavel Machek 2009-12-15 13:33 ` Mauro Carvalho Chehab 2009-12-15 13:43 ` Jon Smirl 2009-12-15 13:43 ` Jon Smirl 2009-12-15 13:43 ` Jon Smirl 2009-12-15 14:19 ` Mauro Carvalho Chehab 2009-12-15 19:58 ` Pavel Machek 2009-12-15 20:14 ` Jon Smirl 2009-12-15 20:14 ` Jon Smirl 2009-12-15 20:19 ` Pavel Machek 2009-12-15 20:19 ` Pavel Machek 2009-12-15 20:29 ` Jon Smirl 2009-12-15 20:29 ` Jon Smirl 2009-12-15 20:33 ` Pavel Machek 2009-12-15 20:45 ` Jon Smirl 2009-12-15 20:45 ` Jon Smirl 2009-12-15 20:45 ` Jon Smirl 2009-12-15 21:05 ` Pavel Machek 2009-12-15 21:05 ` Pavel Machek 2009-12-15 21:38 ` Jon Smirl 2009-12-15 21:38 ` Jon Smirl 2010-03-25 14:42 ` Mauro Carvalho Chehab 2010-03-25 18:32 ` Pavel Machek 2010-03-25 19:00 ` Mauro Carvalho Chehab 2010-03-26 11:04 ` David Härdeman 2010-03-26 11:04 ` David Härdeman 2010-03-26 11:27 ` David Härdeman 2010-03-26 11:27 ` David Härdeman 2010-03-26 14:40 ` Mauro Carvalho Chehab 2010-03-26 14:40 ` Mauro Carvalho Chehab 2010-03-26 16:01 ` Dmitry Torokhov [this message] 2010-03-26 16:01 ` Dmitry Torokhov 2010-03-26 17:22 ` Mauro Carvalho Chehab 2010-03-26 19:07 ` David Härdeman 2010-03-26 19:07 ` David Härdeman 2010-03-26 22:37 ` Jon Smirl 2010-03-26 22:37 ` Jon Smirl 2010-03-26 22:37 ` Jon Smirl 2010-03-27 8:27 ` David Härdeman 2010-03-28 23:22 ` Mauro Carvalho Chehab 2010-03-28 23:22 ` Mauro Carvalho Chehab 2010-03-29 0:51 ` Mauro Carvalho Chehab 2010-03-30 11:01 ` David Härdeman 2010-03-31 6:01 ` Mauro Carvalho Chehab 2010-03-31 6:01 ` Mauro Carvalho Chehab 2010-03-30 11:09 ` David Härdeman 2010-03-30 11:09 ` David Härdeman 2010-03-30 12:43 ` Mauro Carvalho Chehab 2010-03-30 12:43 ` Mauro Carvalho Chehab 2010-03-26 12:23 ` David Härdeman 2010-03-26 15:17 ` Mauro Carvalho Chehab 2010-03-26 15:17 ` Mauro Carvalho Chehab 2010-03-26 19:21 ` David Härdeman 2010-03-26 19:21 ` David Härdeman 2010-03-27 5:56 ` Pavel Machek 2010-03-27 5:56 ` Pavel Machek 2010-04-09 7:21 ` James Hogan 2010-04-09 10:50 ` Andy Walls 2010-04-09 12:58 ` Jarod Wilson 2010-04-09 13:02 ` Jon Smirl 2010-04-09 13:02 ` Jon Smirl 2010-04-09 13:02 ` Jon Smirl 2010-04-09 13:01 ` Mauro Carvalho Chehab 2010-04-09 21:42 ` James Hogan 2010-04-09 21:55 ` Devin Heitmueller 2010-04-09 21:55 ` Devin Heitmueller 2010-04-09 22:14 ` Andy Walls 2010-04-09 23:32 ` Mauro Carvalho Chehab 2010-04-10 0:18 ` Jon Smirl 2010-04-10 0:18 ` Jon Smirl 2010-04-10 1:01 ` Mauro Carvalho Chehab 2010-04-10 0:38 ` hermann pitton 2009-12-07 15:36 ` Mauro Carvalho Chehab 2009-12-06 11:59 ` Christoph Bartelmus 2009-12-06 11:59 ` Christoph Bartelmus 2009-12-15 11:47 ` Pavel Machek 2009-12-06 12:12 ` Christoph Bartelmus 2009-12-06 12:12 ` Christoph Bartelmus 2009-12-06 16:38 ` Jon Smirl 2009-12-06 16:38 ` Jon Smirl 2009-12-06 16:38 ` Jon Smirl 2009-12-06 20:22 ` Krzysztof Halasa 2009-12-07 23:50 ` Mauro Carvalho Chehab 2009-12-03 23:45 ` Andy Walls 2009-12-03 17:47 ` Krzysztof Halasa 2009-11-27 21:49 ` Stefan Richter 2009-11-28 1:08 ` Maxim Levitsky 2009-11-28 11:20 ` Krzysztof Halasa 2009-11-28 14:42 ` Maxim Levitsky 2009-11-28 15:25 ` Krzysztof Halasa 2009-11-28 15:35 ` Maxim Levitsky 2009-11-28 15:44 ` Krzysztof Halasa 2009-11-28 16:26 ` Maxim Levitsky 2009-11-28 16:44 ` Krzysztof Halasa 2009-11-28 16:47 ` Christoph Bartelmus 2009-11-28 16:47 ` Christoph Bartelmus 2009-11-28 17:06 ` Jon Smirl 2009-11-28 17:06 ` Jon Smirl 2009-11-28 17:35 ` Krzysztof Halasa 2009-11-28 17:37 ` Jon Smirl 2009-11-28 17:37 ` Jon Smirl 2009-11-28 17:37 ` Jon Smirl 2009-11-28 17:40 ` Krzysztof Halasa 2009-11-28 17:40 ` Krzysztof Halasa 2009-11-28 23:26 ` Andy Walls 2009-11-29 4:58 ` Dmitry Torokhov 2009-11-29 20:27 ` Krzysztof Halasa 2009-11-29 20:44 ` Jon Smirl 2009-11-29 20:44 ` Jon Smirl 2009-11-29 20:44 ` Jon Smirl 2009-11-29 21:29 ` Dmitry Torokhov 2009-11-29 21:47 ` Jon Smirl 2009-11-29 21:47 ` Jon Smirl 2009-11-29 22:48 ` Dmitry Torokhov 2009-11-29 21:31 ` Dmitry Torokhov 2009-11-30 4:50 ` Jarod Wilson 2009-11-30 0:48 ` Andy Walls 2009-12-01 10:46 ` Gerd Hoffmann 2009-12-01 11:49 ` Andy Walls 2009-12-01 14:02 ` Gerd Hoffmann 2009-12-01 14:18 ` Mauro Carvalho Chehab 2009-11-30 17:45 ` Lennart Sorensen 2009-11-29 4:32 ` Andy Walls 2009-11-29 4:50 ` Dmitry Torokhov 2009-11-29 12:40 ` Alan Cox 2009-11-29 17:28 ` Maxim Levitsky 2009-11-29 17:49 ` Ray Lee 2009-11-29 17:49 ` Ray Lee 2009-11-29 18:13 ` Alan Cox 2009-11-29 18:52 ` Ray Lee 2009-11-29 18:52 ` Ray Lee 2009-11-29 19:04 ` Alan Cox 2009-11-29 19:16 ` Jon Smirl 2009-11-29 19:16 ` Jon Smirl 2009-11-29 19:29 ` Alan Cox 2009-11-29 19:49 ` Christoph Bartelmus 2009-11-29 19:49 ` Christoph Bartelmus 2009-11-30 0:05 ` Andy Walls 2009-11-29 23:35 ` Andy Walls 2009-11-30 2:15 ` Ray Lee 2009-11-30 2:15 ` Ray Lee 2009-11-30 2:15 ` Ray Lee 2009-11-30 9:58 ` Artur Skawina 2009-11-30 11:56 ` Mauro Carvalho Chehab 2009-11-30 12:57 ` Andy Walls 2009-11-30 13:23 ` Jon Smirl 2009-11-30 13:23 ` Jon Smirl 2009-11-30 13:23 ` Jon Smirl 2009-11-30 13:24 ` Mauro Carvalho Chehab 2009-11-30 16:14 ` kevin granade 2009-11-30 16:14 ` kevin granade 2009-11-30 17:33 ` Mauro Carvalho Chehab 2009-11-30 18:02 ` Dmitry Torokhov 2009-11-30 18:27 ` Mauro Carvalho Chehab 2009-11-30 19:07 ` Dmitry Torokhov 2009-11-30 20:07 ` Krzysztof Halasa 2009-11-30 13:43 ` Maxim Levitsky 2009-11-30 14:01 ` Jon Smirl 2009-11-30 14:01 ` Jon Smirl 2009-11-30 15:04 ` Maxim Levitsky 2009-11-30 16:19 ` Mauro Carvalho Chehab 2009-11-30 20:03 ` Krzysztof Halasa 2009-11-29 18:19 ` Jon Smirl 2009-11-29 18:19 ` Jon Smirl 2009-11-29 19:00 ` Alan Cox 2009-11-30 9:57 ` Mauro Carvalho Chehab 2009-11-28 18:17 ` Stefan Richter 2009-11-28 18:58 ` Jon Smirl 2009-11-28 18:58 ` Jon Smirl 2009-11-28 18:58 ` Jon Smirl 2009-11-28 19:45 ` Stefan Richter 2009-11-28 20:08 ` Jon Smirl 2009-11-28 20:08 ` Jon Smirl 2009-11-28 20:08 ` Jon Smirl 2009-11-28 20:21 ` Krzysztof Halasa 2009-12-12 19:33 ` Pavel Machek 2009-11-28 20:29 ` Stefan Richter 2009-11-28 20:34 ` Stefan Richter 2009-11-28 20:46 ` Jon Smirl 2009-11-28 20:46 ` Jon Smirl 2009-11-28 20:46 ` Jon Smirl 2009-11-28 21:46 ` Stefan Richter 2009-11-28 22:10 ` Jon Smirl 2009-11-28 22:10 ` Jon Smirl 2009-11-28 22:10 ` Jon Smirl 2009-11-28 22:18 ` Jon Smirl 2009-11-28 22:18 ` Jon Smirl 2009-11-29 4:59 ` Dmitry Torokhov 2009-11-29 16:01 ` Mauro Carvalho Chehab 2009-11-29 16:18 ` Mauro Carvalho Chehab 2009-11-29 11:24 ` Christoph Bartelmus 2009-11-29 11:24 ` Christoph Bartelmus 2009-11-29 16:01 ` Mauro Carvalho Chehab 2009-11-28 19:55 ` Krzysztof Halasa 2009-11-28 20:14 ` Jon Smirl 2009-11-28 20:14 ` Jon Smirl 2009-11-28 20:29 ` Krzysztof Halasa 2009-11-28 17:21 ` Krzysztof Halasa 2009-11-28 17:21 ` Krzysztof Halasa 2009-11-29 11:07 ` Christoph Bartelmus 2009-11-29 11:07 ` Christoph Bartelmus 2009-11-28 16:45 ` Jon Smirl 2009-11-28 16:45 ` Jon Smirl 2009-11-28 18:45 ` Maxim Levitsky 2009-11-28 18:56 ` Jon Smirl 2009-11-28 18:56 ` Jon Smirl 2009-11-28 19:16 ` Maxim Levitsky 2009-11-28 19:30 ` Stefan Richter 2009-11-28 19:32 ` Jon Smirl 2009-11-28 19:32 ` Jon Smirl 2009-11-28 19:48 ` Stefan Richter 2009-11-29 2:47 ` Mike Lampard 2009-11-29 4:55 ` Dmitry Torokhov 2009-11-29 5:31 ` Mike Lampard 2009-11-29 7:14 ` Dmitry Torokhov 2009-11-29 21:59 ` Artur Skawina 2009-11-30 12:13 ` Mauro Carvalho Chehab 2009-12-07 17:53 Emmanuel Fusté 2009-12-07 23:16 ` Mauro Carvalho Chehab 2009-12-07 17:54 Emmanuel Fusté 2009-12-07 18:24 ` Dmitry Torokhov 2009-12-08 9:31 ` Emmanuel Fusté
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20100326160150.GA28804@core.coreip.homeip.net \ --to=dmitry.torokhov@gmail.com \ --cc=awalls@radix.net \ --cc=hermann-pitton@arcor.de \ --cc=j@jannau.net \ --cc=jarod@redhat.com \ --cc=jarod@wilsonet.com \ --cc=jonsmirl@gmail.com \ --cc=khc@pm.waw.pl \ --cc=kraxel@redhat.com \ --cc=linux-input@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-media@vger.kernel.org \ --cc=lirc@bartelmus.de \ --cc=mchehab@redhat.com \ --cc=pavel@ucw.cz \ --cc=superm1@ubuntu.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.