subject:"Re\: \[RFC\] What are the goals for the architecture of an in\-kernel IR system\?"

On Thu, Mar 25, 2010 at 07:32:59PM +0100, Pavel Machek wrote:
 struct keycode_table_entry {
   unsigned keycode;
   int len;
   char scancode[];
 }
 
 ? gcc extension, but commonly used around kernel.

Flexible array members are ok in C99, aren't they?

-- 
David Härdeman
--
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] What are the goals for the architecture of an in-kernel IR system?

On Thu, Mar 25, 2010 at 11:42:33AM -0300, Mauro Carvalho Chehab wrote:
2) add current_protocol support on other drivers;
 
 Done. Patch were already merged upstream.
 
 The current_protocol attribute shows the protocol(s) that the device is 
 accepting
 and allows changing it to another protocol. 
 
 In the case of the em28xx hardware, only one protocol can be active, since 
 the decoder
 is inside the hardware. 
 
 On the raw IR decode implementation I've done at the saa7134, all raw pulse 
 events are
 sent to all registered decoders, so I'm thinking on using this sysfs node to 
 allow
 disabling the standard behavior of passing the IR codes to all decoders, 
 routing it
 to just one decoder.
 
 Another alternative would be to show current_protocol only for devices with 
 hardware
 decoder, and create one sysfs node for each decoder, allowing 
 enabling/disabling each
 decoder individually.

You're eventually going to want to add ioctl's to set a lot of TX or RX 
parameters in one go (stuff like active receiver(s) and transmitter(s), 
carrier frequency, duty cycle, timeouts, filter levels and resolution - 
all of which would need to be set in one operation since some hardware 
will need to be reset after each parameter is changed).

Then you'll end up with a few things being controlled via sysfs and some 
being controlled via ioctls. Maybe it's a good idea to have a bitmask of 
supported and enabled protocols in those ioctls instead?

-- 
David Härdeman
--
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] What are the goals for the architecture of an in-kernel IR system?

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.

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.

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.

ioctl's to set/get keycodes for ir should also take a flag parameter in 
the struct to allow special properties to be set/returned for a given 
keycode mapping (I'm thinking of keycodes which powers on the computer 
for instance, that should be exposed to userspace somehow).

With all of that, the struct might need to be something like:

struct keycode_table_entry {
unsigned keycode; /* e.g. KEY_A */
unsigned table;   /* Table index, for multiple keytables */
unsigned index;   /* Index in the given keytable */
unsigned flags;   /* For additional functionality */
unsigned len; /* Of the struct */
char scancode[];  /* Per-protocol scancode data follows */
};

Finally, I think irrcv should create a chardev of its own with ioctl's 
like EVIOCLEARKEYCODEBIG (and RX/TX parameter setting ioctl's).  The 
same chardev can be used for IR blasting (by writing data to it once TX 
parameters have been set).


-- 
David Härdeman
--
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] What are the goals for the architecture of an in-kernel IR system?

2010-03-26 Thread Mauro Carvalho Chehab

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.

 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.

 
 ioctl's to set/get keycodes for ir should also take a flag parameter in 
 the struct to allow special properties to be set/returned for a given 
 keycode mapping (I'm thinking of keycodes which powers on the computer 
 for instance, that should be exposed to userspace somehow).
 
 With all of that, the struct might need to be something like:
 
 struct keycode_table_entry {
   unsigned keycode; /* e.g. KEY_A */
   unsigned table;   /* Table index, for multiple keytables */
   unsigned index;   /* Index in the given keytable */
   unsigned flags;   /* For additional functionality */
   unsigned len; /* Of the struct */
   char scancode[];  /* Per-protocol scancode data follows */
 };
 

I don't see the need for a table index. If we have 3 input event interfaces
for a given IR, each will have its own private keycode table.

 Finally, I think irrcv should create a chardev of its own with ioctl's 
 like EVIOCLEARKEYCODEBIG (and RX/TX parameter setting ioctl's).  The 
 same chardev can be used for IR blasting (by writing data to it once TX 
 parameters have been set).

There are several different things mixed above. It may be a good idea
to allow extending the ioctls from the input event device to other input
classes. Yet, I'm currently not seeing any usage for it.

In the specific case of EVIOCGKEYCODEBIG/EVIOCSKEYCODEBIG, those are needed
for all input devices whose scancode is bigger than 32 bits. It is not
specific to IR.

I don't think we need to add ioctl's to change RX/TX parameters. The better
is to do it via sysfs. I've added yesterday one of such parameter for the
nec

Re: [RFC] What are the goals for the architecture of an in-kernel IR system?

2010-03-26 Thread Mauro Carvalho Chehab

David Härdeman wrote:
 On Thu, Mar 25, 2010 at 11:42:33AM -0300, Mauro Carvalho Chehab wrote:
2) add current_protocol support on other drivers;
 Done. Patch were already merged upstream.

 The current_protocol attribute shows the protocol(s) that the device is 
 accepting
 and allows changing it to another protocol. 

 In the case of the em28xx hardware, only one protocol can be active, since 
 the decoder
 is inside the hardware. 

 On the raw IR decode implementation I've done at the saa7134, all raw pulse 
 events are
 sent to all registered decoders, so I'm thinking on using this sysfs node to 
 allow
 disabling the standard behavior of passing the IR codes to all decoders, 
 routing it
 to just one decoder.

 Another alternative would be to show current_protocol only for devices with 
 hardware
 decoder, and create one sysfs node for each decoder, allowing 
 enabling/disabling each
 decoder individually.
 
 You're eventually going to want to add ioctl's to set a lot of TX or RX 
 parameters in one go (stuff like active receiver(s) and transmitter(s), 
 carrier frequency, duty cycle, timeouts, filter levels and resolution - 
 all of which would need to be set in one operation since some hardware 
 will need to be reset after each parameter is changed).

TX is a completely different history. It has nothing to do with input event
subsystem. So, another approach should be taken for it.

I haven't seen yet a hardware decoder with such parameters, but maybe I just
don't have enough specs here to adjust them. Anyway, one simple way to avoid
resetting the hardware for every new parameter change would be to use a timer
for reset. This way, an userspace application or script that is touching on 
several parameters would just send the complete RX init sequence and
after some dozens of milliseconds, the hardware will load the new parameters.

 Then you'll end up with a few things being controlled via sysfs and some 
 being controlled via ioctls. Maybe it's a good idea to have a bitmask of 
 supported and enabled protocols in those ioctls instead?

There's an interesting discussion about bitmasks x a list of enumerated values
as a way to represent a bitmask into a series of values on sysfs,
at http://lwn.net/Articles/378219/  (see A critical look at sysfs attribute 
values
article there).

That's said, I'm starting to think that the better is to have some 
differentiation
there between hardware and software decoders. IMO, software decoders are better
handled with an enabled attribute, per software decoder, inside each irrcv.

In the case of hardware decoders, just one attribute is enough to control it. I 
think
it should be a bitmask parameter, but presented with their aliases, like for 
example:
$cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
ondemand conservative performance 

This is clearly a bitmask, but it is presented as textual values, instead of a
magic number.

So, we may have
/sys/class/irrcv/irrcv0/supported_protocols

as, for example:
RC-5 NEC

and allow setting current_protocol as just RC-5 or, if the hardware supports
more than one decoder at the same time, as RC-5 NEC.

-- 

Cheers,
Mauro
--
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] What are the goals for the architecture of an in-kernel IR system?

2010-03-26 Thread Dmitry Torokhov

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-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] What are the goals for the architecture of an in-kernel IR system?

2010-03-26 Thread Mauro Carvalho Chehab

Dmitry Torokhov wrote:
 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.

Ok. I'll prepare the patches for adding the new ioctl, in a way that it will
also handle the legacy methods, and post for review.

 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.

This don't solve the issue about how to signalize to kernel that more than one
input device is needed. 

As the userspace will request the creation of those keymaps, we need some way
to receive such requests from userspace. 

I can see a few ways for doing it:

1) create a control device for the irrcv device as a hole,
that would handle such requests via ioctl (/dev/irctl[0-9]* ?)

2) create a read/write sysfs node that would indicate the number of 
event/keymaps
associated with a given IR. By writing a bigger number, it would create new 
devices.
By writing a smaller number, it will delete some maps. There's an issue though: 
what criteria would be used to delete? The newly created ones?

3) create a fixed number of event devices, and add a sysfs attribute to enable
or disable it;

4) create a fixed number of sysfs attributes to represent the keymaps. For 
example:
/sys/class/irrcv/irrcv0/keymap0/enabled
...
/sys/class/irrcv/irrcv0/keymap7/enabled

The input/event node will be created only when the enabled=1.

I don't like (2) or (3), because removing a table with (2) may end by removing 
the wrong
table, and (3) will create more event interfaces than probably needed by the 
majority
of IR users.

maybe (4) is the better one.

-- 

Cheers,
Mauro
--
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] What are the goals for the architecture of an in-kernel IR system?

On Fri, Mar 26, 2010 at 02:22:51PM -0300, Mauro Carvalho Chehab wrote:
 Dmitry Torokhov wrote:
  On Fri, Mar 26, 2010 at 11:40:41AM -0300, Mauro Carvalho Chehab wrote:
  David Härdeman wrote:
  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.
 
 Ok. I'll prepare the patches for adding the new ioctl, in a way that it will
 also handle the legacy methods, and post for review.

If EVIOCGKEYCODEBIG is going to be used as a superset of the old ioctl, 
might it be a good idea change the proposed struct to:

struct keycode_table_entry {
unsigned keycode;
unsigned index;
unsigned type;
unsigned len;
char scancode[];
};

Where type is used to give a hint of how the scancode[] member should 
be interpreted?

 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.

I fully agree!

 This don't solve the issue about how to signalize to kernel that more than one
 input device is needed. 
 
 As the userspace will request the creation of those keymaps, we need some way
 to receive such requests from userspace. 
 
 I can see a few ways for doing it:
 
 1) create a control device for the irrcv device as a hole,
 that would handle such requests via ioctl (/dev/irctl[0-9]* ?)

 2) create a read/write sysfs node that would indicate the number of 
 event/keymaps
 associated with a given IR. By writing a bigger number, it would create new 
 devices.
 By writing a smaller number, it will delete some maps. There's an issue 
 though: 
 what criteria would be used to delete? The newly created ones?

This won't work for the reason you've already set out...which keymap 
should be deleted?
 
 3) create a fixed number of event devices, and add a sysfs attribute to enable
 or disable it;

You really seem to prefer sysfs over ioctls :)

 4) create a fixed number of sysfs attributes to represent the keymaps. For 
 example:
 /sys/class/irrcv/irrcv0/keymap0/enabled
   ...
 /sys/class/irrcv/irrcv0/keymap7/enabled
 
 The input/event node will be created only when the enabled=1.

This sounds like 3)

 I don't like (2) or (3), because removing a table with (2) may end by 
 removing the wrong
 table, and (3) will create more event interfaces than probably needed by the 
 majority
 of IR users.
 
 maybe (4) is the better one.

Personally I think 1) is the best approach. Having a device for the 
irrcv device allows for three kinds of operations:

read

which corresponds to RX...you're eventually going to want to let 
userspace devices read IR commands which have no entries in a keytable 
yet in order to create keytables for new remotes, the same interface can 
also be used for lirc-type user-space apps which want to access the raw 
pulse/space timings for userspace decoding.

write
-
which would correspond to TX...I'd suggest a stream of s32 integers to 
imply pulse/space timings.

ioctl
-
for controlling the RX/TX parameters, creating/destroying additional 
keytables, etc...

Basically, we'll end up with a lirc_dev 2.0. And the irrcv class name 
will be misleading since it will be irrcv + irsnd :)

-- 
David Härdeman
--
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] What are the goals for the architecture of an in-kernel IR system?

On Fri, Mar 26, 2010 at 12:17:34PM -0300, Mauro Carvalho Chehab wrote:
 David Härdeman wrote:
  On Thu, Mar 25, 2010 at 11:42:33AM -0300, Mauro Carvalho Chehab wrote:
 2) add current_protocol support on other drivers;
  Done. Patch were already merged upstream.
 
  The current_protocol attribute shows the protocol(s) that the device is 
  accepting
  and allows changing it to another protocol. 
 
  In the case of the em28xx hardware, only one protocol can be active, since 
  the decoder
  is inside the hardware. 
 
  On the raw IR decode implementation I've done at the saa7134, all raw 
  pulse events are
  sent to all registered decoders, so I'm thinking on using this sysfs node 
  to allow
  disabling the standard behavior of passing the IR codes to all decoders, 
  routing it
  to just one decoder.
 
  Another alternative would be to show current_protocol only for devices 
  with hardware
  decoder, and create one sysfs node for each decoder, allowing 
  enabling/disabling each
  decoder individually.
  
  You're eventually going to want to add ioctl's to set a lot of TX or RX 
  parameters in one go (stuff like active receiver(s) and transmitter(s), 
  carrier frequency, duty cycle, timeouts, filter levels and resolution - 
  all of which would need to be set in one operation since some hardware 
  will need to be reset after each parameter is changed).
 
 TX is a completely different history. It has nothing to do with input event
 subsystem. So, another approach should be taken for it.

I suggest (though I might not have been clear on that point) that irrcv 
devices create a char node...ir specifics are handled via that node 
(with read/write/ioctl...see the other mail I just send).

 I haven't seen yet a hardware decoder with such parameters, but maybe I just
 don't have enough specs here to adjust them.

The entire idea is to have a common API for hardware decoders and 
decoders which provide raw pulse/space timings. That, to me, is one of 
the major points of having in-kernel IR decoders - being able to provide 
a consistent interface for both hardware decoders and pulse/space 
hardware.

 Anyway, one simple way to avoid
 resetting the hardware for every new parameter change would be to use a timer
 for reset. This way, an userspace application or script that is touching on 
 several parameters would just send the complete RX init sequence and
 after some dozens of milliseconds, the hardware will load the new parameters.

And I do not think that sounds like a good interface.

  Then you'll end up with a few things being controlled via sysfs and some 
  being controlled via ioctls. Maybe it's a good idea to have a bitmask of 
  supported and enabled protocols in those ioctls instead?
 
 There's an interesting discussion about bitmasks x a list of enumerated values
 as a way to represent a bitmask into a series of values on sysfs,
 at http://lwn.net/Articles/378219/  (see A critical look at sysfs attribute 
 values
 article there).

Not really relevant...that's just the minor detail of how a sysfs file 
might be represented.

 That's said, I'm starting to think that the better is to have some 
 differentiation
 there between hardware and software decoders. IMO, software decoders are 
 better
 handled with an enabled attribute, per software decoder, inside each irrcv.

I think we can create an interface which obscures the differences:

Software decoders will export all in-kernel IR decoders in a bitmask in 
the supported_protocols sysfs file or ioctl struct member.

Hardware decoders will export the hardware supported protocol(s) in the 
same file/member.

In addition, a sysfs file or ioctl member for enabled_protocols will 
control either the enabled in-kernel IR decoders or hardware decoder(s).



As should be quite obvious by now...I suggest ioctls (on a irrcv 
specific chardev) for controlling this :)

-- 
David Härdeman
--
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] What are the goals for the architecture of an in-kernel IR system?

2010-03-26 Thread Pavel Machek

Hi!

  Anyway, one simple way to avoid
  resetting the hardware for every new parameter change would be to use a 
  timer
  for reset. This way, an userspace application or script that is touching on 
  several parameters would just send the complete RX init sequence and
  after some dozens of milliseconds, the hardware will load the new 
  parameters.
 
 And I do not think that sounds like a good interface.

Yep. Having artifical delay is ugly, racy and error prone. (If
application is swapped out, you'll set the hardware to middle state,
anyway).

Better solution would be to have COMMIT command that actually does
the setup, or interface that allows all parameters at once...

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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] What are the goals for the architecture of an in-kernel IR system?

2010-03-25 Thread Pavel Machek

Hi!

 This were the original plan we've discussed, back in December:


Seems sane.

 struct keycode_table_entry {
   unsigned keycode;
   char scancode[32];  /* 32 is just an arbitrary long array - maybe 
 shorter */
   int len;
 }

What about

struct keycode_table_entry {
unsigned keycode;
int len;
char scancode[];
}

? gcc extension, but commonly used around kernel.
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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] What are the goals for the architecture of an in-kernel IR system?

2010-03-25 Thread Mauro Carvalho Chehab

Pavel Machek wrote:
 Hi!
 
 This were the original plan we've discussed, back in December:
 
 
 Seems sane.
 
 struct keycode_table_entry {
  unsigned keycode;
  char scancode[32];  /* 32 is just an arbitrary long array - maybe 
 shorter */
  int len;
 }
 
 What about
 
 struct keycode_table_entry {
   unsigned keycode;
   int len;
   char scancode[];
 }
 
 ? gcc extension, but commonly used around kernel.

Seems fine. Maybe we could just use char *scancode to avoid using a
gcc extension on a public interface.


-- 

Cheers,
Mauro
--
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] What are the goals for the architecture of an in-kernel IR system?

On Sun 2009-12-06 12:59:00, Christoph Bartelmus wrote:
 Hi Dmitry,
 
 on 05 Dec 09 at 22:55, Dmitry Torokhov wrote:
 [...]
  I do not believe you are being realistic. Sometimes we just need to say
  that the device is a POS and is just not worth it. Remember, there is
  still lirc hole for the hard core people still using solder to produce
  something out of the spare electronic components that may be made to
  work (never mind that it causes the CPU constantly poll the device, not
  letting it sleep and wasting electricity as a result - just hypotetical
  example here).
 
 The still seems to be is a persistent misconception that the home-brewn  
 receivers need polling or cause heavy CPU load. No they don't. All of them  
 are IRQ based.

I have at least one that needs polling/signal
processing... somewhere. IR LED connected to mic input.

Anyway, clearly hacked-up devices like that are better left for
userland solutions.
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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] What are the goals for the architecture of an in-kernel IR system?

2009-12-15 Thread Mauro Carvalho Chehab

Pavel Machek wrote:
 That is why I think we should go the other way around - introduce the
 core which receivers could plug into and decoder framework and once it
 is ready register lirc-dev as one of the available decoders.

 I've committed already some IR restruct code on my linux-next -git tree:

 http://git.kernel.org/?p=linux/kernel/git/mchehab/linux-next.git

 The code there basically moves the input/evdev registering code and 
 scancode/keycode management code into a separate ir-core module.

 To make my life easy, I've moved the code temporarily into drivers/media/IR.
 This way, it helps me to move V4L specific code outside ir-core and to later
 use it for DVB. After having it done, probably the better is to move it to
 be under /drivers or /drivers/input.
 
 Well, -next is for stuff to be merged into 2.6.34. You are quite an
 optimist.
   Pavel

Well, we need those changes anyway for the in-kernel drivers, and I'm not seeing
on the current patches any reason for not having them for 2.6.34.

I've added all the ir-core patches I did so far at linux-next. This helps people
to review and contribute.

The patches are already working with the in-kernel em28xx driver, allowing to
replace the keycode table and the protocol used by the hardware IR decoder.
I tested here by replacing an RC-5 based IR table (Hauppauge Grey) by a NEC
based IR table (Terratec Cinergy XS remote controller).

The current Remote Controller core module (ir-core) is currently doing:

- Implementation of the existing EVIO[G|S]KEYCODE, expanding/feeing 
memory
dynamically, based on the needed size for scancode/keycode table;

- scancodes can be up to 16 bits currently;

- sysfs is registering /sys/class/irrcv and creating one branch for each
different RC receiver, numbering from irrcv0 to irrcv255;

- one irrcv note is created: current_protocol;

- reading /sys/class/irrcv/irrcv*/current_protocol returns the protocol
currently used by the driver;

- writing to /sys/class/irrcv/irrcv*/current_protocol changes the 
protocol
to a new one, by calling a callback, asking the driver to change the protocol. 
If
the protocol is not support, it returns -EINVAL;

- all V4L drivers are already using ir-core;

- em28xx driver is implementing current_protocol show/store support.

TODO:
1) Port DVB drivers to use ir-core, removing the duplicated (and 
incomplete
  - as table size can't change on DVB's implementation) code that 
exists there;

2) add current_protocol support on other drivers;

3) link the corresponding input/evdev interfaces with 
/sys/class/irrcv/irrcv*;

4) make the keytable.c application aware of the sysfs vars;

5) add an attribute to uniquely identify a remote controller;

6) write or convert an existing application to load IR tables at 
runtime;

7) get the complete 16-bit scancodes used by V4L drivers;

8) add decoder/lirc_dev glue to ir-core;

9) add lirc_dev module and in-kernel decoders;

10) extend keycode table replacement to support big/variable sized 
scancodes;

11) rename IR-RC;

12) redesign or remove ir-common module. It currently handles in-kernel
keycode tables and a few helper routines for raw pulse/space decode;

13) move drivers/media/IR to a better place;


comments:

Tasks (1) to (6) for sure can happen to 2.6.34, depending on people's 
spare
time for it;

(7) is probably the more complex task, since it requires to re-test all 
in-kernel
supported remote controlle scancode/keycode tables, to get the complete IR 
keycode
and rewrite the getkeycode functions that are currently masking the IR code 
into 7 bits. 
We'll need users help on this task, but this can be done gradually, like I did 
with
two RC keytables on em28xx driver, while preserving the other keytables as-is.

(8) I suggest that this glue will be submitted together with lirc_dev 
patch
series, as the biggest client for it is lirc. In principle, kfifo seems the 
better
interface for lirc_dev - decoders interface. For the decoders - RC core 
interface,
there's an interface already used on V4L drivers, provided by ir-common, using 
evdev
kernel API. This may need some review.

(9) depends on lirc API discusions. My proposal is that people submit 
an RFC
with the lirc API reviewed to the ML's, for people to ack/nack/comment. After 
that, 
re-submit the lirc_dev module integrating it into ir-core and with the reviewed 
API;

(10) depends on EVIO[G|S]KEYCODE discussions we've already started. I 
did a proposal
about it. I'll review, based on the comments and re-submit it;

(11) if none is against renaming IR as RC, I'll do it on a next patch;

(12) depends on having lirc_dev added, for the removal of 
ir-functions.c. With
respect to the

Re: [RFC] What are the goals for the architecture of an in-kernel IR system?

On Tue, Dec 15, 2009 at 8:33 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
Pavel Machek wrote:
That is why I think we should go the other way around - introduce the
core which receivers could plug into and decoder framework and once it
is ready register lirc-dev as one of the available decoders.

I've committed already some IR restruct code on my linux-next -git tree:

http://git.kernel.org/?p=linux/kernel/git/mchehab/linux-next.git

The code there basically moves the input/evdev registering code and
scancode/keycode management code into a separate ir-core module.

To make my life easy, I've moved the code temporarily into drivers/media/IR.
This way, it helps me to move V4L specific code outside ir-core and to later
use it for DVB. After having it done, probably the better is to move it to
be under /drivers or /drivers/input.

Well, -next is for stuff to be merged into 2.6.34. You are quite an
optimist.
Pavel

Well, we need those changes anyway for the in-kernel drivers, and I'm not
seeing
on the current patches any reason for not having them for 2.6.34.

I've added all the ir-core patches I did so far at linux-next. This helps
people
to review and contribute.

The patches are already working with the in-kernel em28xx driver, allowing to
replace the keycode table and the protocol used by the hardware IR decoder.
I tested here by replacing an RC-5 based IR table (Hauppauge Grey) by a NEC
based IR table (Terratec Cinergy XS remote controller).

The current Remote Controller core module (ir-core) is currently doing:

- Implementation of the existing EVIO[G|S]KEYCODE, expanding/feeing
memory
dynamically, based on the needed size for scancode/keycode table;

- scancodes can be up to 16 bits currently;

- sysfs is registering /sys/class/irrcv and creating one branch for
each
different RC receiver, numbering from irrcv0 to irrcv255;

- one irrcv note is created: current_protocol;

- reading /sys/class/irrcv/irrcv*/current_protocol returns the protocol
currently used by the driver;

- writing to /sys/class/irrcv/irrcv*/current_protocol changes the
protocol
to a new one, by calling a callback, asking the driver to change the
protocol. If
the protocol is not support, it returns -EINVAL;

- all V4L drivers are already using ir-core;

- em28xx driver is implementing current_protocol show/store support.

TODO:

I'd add a pulse based receiver like a MSMCE to make sure the core API is right.
MSME has transmit hardware too.

What about creating multiple evdev devices with their own keymaps off
from a single receiver? That's a key part of making multi-function
remotes work.

1) Port DVB drivers to use ir-core, removing the duplicated (and
incomplete
- as table size can't change on DVB's implementation) code that
exists there;

2) add current_protocol support on other drivers;

3) link the corresponding input/evdev interfaces with
/sys/class/irrcv/irrcv*;

4) make the keytable.c application aware of the sysfs vars;

5) add an attribute to uniquely identify a remote controller;

6) write or convert an existing application to load IR tables at
runtime;

7) get the complete 16-bit scancodes used by V4L drivers;

8) add decoder/lirc_dev glue to ir-core;

9) add lirc_dev module and in-kernel decoders;

10) extend keycode table replacement to support big/variable sized
scancodes;

11) rename IR-RC;

12) redesign or remove ir-common module. It currently handles in-kernel
keycode tables and a few helper routines for raw pulse/space
decode;

13) move drivers/media/IR to a better place;

comments:

Tasks (1) to (6) for sure can happen to 2.6.34, depending on people's
spare
time for it;

(7) is probably the more complex task, since it requires to re-test
all in-kernel
supported remote controlle scancode/keycode tables, to get the complete IR
keycode
and rewrite the getkeycode functions that are currently masking the IR code
into 7 bits.
We'll need users help on this task, but this can be done gradually, like I
did with
two RC keytables on em28xx driver, while preserving the other keytables as-is.

(8) I suggest that this glue will be submitted together with lirc_dev
patch
series, as the biggest client for it is lirc. In principle, kfifo seems the
better
interface for lirc_dev - decoders interface. For the decoders - RC core
interface,
there's an interface already used on V4L drivers, provided by ir-common,
using evdev
kernel API. This may need some review.

(9) depends on lirc API discusions. My proposal is that people submit
an RFC
with the lirc API reviewed to the ML's, for people to ack/nack/comment. After
that,
re-submit the lirc_dev module

Re: [RFC] What are the goals for the architecture of an in-kernel IR system?

2009-12-15 Thread Mauro Carvalho Chehab

Jon Smirl wrote:
 On Tue, Dec 15, 2009 at 8:33 AM, Mauro Carvalho Chehab
 mche...@redhat.com wrote:
 Pavel Machek wrote:
 That is why I think we should go the other way around - introduce the
 core which receivers could plug into and decoder framework and once it
 is ready register lirc-dev as one of the available decoders.

 I've committed already some IR restruct code on my linux-next -git tree:

 http://git.kernel.org/?p=linux/kernel/git/mchehab/linux-next.git

 The code there basically moves the input/evdev registering code and
 scancode/keycode management code into a separate ir-core module.

 To make my life easy, I've moved the code temporarily into 
 drivers/media/IR.
 This way, it helps me to move V4L specific code outside ir-core and to 
 later
 use it for DVB. After having it done, probably the better is to move it to
 be under /drivers or /drivers/input.
 Well, -next is for stuff to be merged into 2.6.34. You are quite an
 optimist.
   Pavel
 Well, we need those changes anyway for the in-kernel drivers, and I'm not 
 seeing
 on the current patches any reason for not having them for 2.6.34.

 I've added all the ir-core patches I did so far at linux-next. This helps 
 people
 to review and contribute.

 The patches are already working with the in-kernel em28xx driver, allowing to
 replace the keycode table and the protocol used by the hardware IR decoder.
 I tested here by replacing an RC-5 based IR table (Hauppauge Grey) by a NEC
 based IR table (Terratec Cinergy XS remote controller).

 The current Remote Controller core module (ir-core) is currently doing:

- Implementation of the existing EVIO[G|S]KEYCODE, expanding/feeing 
 memory
 dynamically, based on the needed size for scancode/keycode table;

- scancodes can be up to 16 bits currently;

- sysfs is registering /sys/class/irrcv and creating one branch for 
 each
 different RC receiver, numbering from irrcv0 to irrcv255;

- one irrcv note is created: current_protocol;

- reading /sys/class/irrcv/irrcv*/current_protocol returns the 
 protocol
 currently used by the driver;

- writing to /sys/class/irrcv/irrcv*/current_protocol changes the 
 protocol
 to a new one, by calling a callback, asking the driver to change the 
 protocol. If
 the protocol is not support, it returns -EINVAL;

- all V4L drivers are already using ir-core;

- em28xx driver is implementing current_protocol show/store support.

 TODO:
 
 I'd add a pulse based receiver like a MSMCE to make sure the core API is 
 right.
 MSME has transmit hardware too.

Makes sense. This can be done after having the lirc_dev integrated.

 What about creating multiple evdev devices with their own keymaps off
 from a single receiver? That's a key part of making multi-function
 remotes work.

I was sure I missed something at the TODO :)

  
 
1) Port DVB drivers to use ir-core, removing the duplicated (and 
 incomplete
  - as table size can't change on DVB's implementation) code that 
 exists there;

2) add current_protocol support on other drivers;

3) link the corresponding input/evdev interfaces with 
 /sys/class/irrcv/irrcv*;

4) make the keytable.c application aware of the sysfs vars;

5) add an attribute to uniquely identify a remote controller;

6) write or convert an existing application to load IR tables at 
 runtime;

7) get the complete 16-bit scancodes used by V4L drivers;

8) add decoder/lirc_dev glue to ir-core;

9) add lirc_dev module and in-kernel decoders;

10) extend keycode table replacement to support big/variable sized 
 scancodes;

11) rename IR-RC;

12) redesign or remove ir-common module. It currently handles 
 in-kernel
keycode tables and a few helper routines for raw pulse/space 
 decode;

13) move drivers/media/IR to a better place;


So, we have also at the todo list:

14) add pulse based drivers;

15) make in-kernel pulse-based devices to use lirc_dev;

16) add an API to dynamically create evdev interfaces for scancode 
filtering;


 comments:

Tasks (1) to (6) for sure can happen to 2.6.34, depending on people's 
 spare
 time for it;

(7) is probably the more complex task, since it requires to re-test 
 all in-kernel
 supported remote controlle scancode/keycode tables, to get the complete IR 
 keycode
 and rewrite the getkeycode functions that are currently masking the IR code 
 into 7 bits.
 We'll need users help on this task, but this can be done gradually, like I 
 did with
 two RC keytables on em28xx driver, while preserving the other keytables 
 as-is.

(8) I suggest that this glue will be submitted together with lirc_dev 
 patch
 series, as the biggest client for it is lirc. In principle, kfifo seems the 
 better
 interface for lirc_dev - decoders interface.

Re: [RFC] What are the goals for the architecture of an in-kernel IR system?

Hi!

   (11) if none is against renaming IR as RC, I'll do it on a next patch;

Call it irc -- infrared remote control. Bluetooth remote controls will
have very different characteristics.

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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] What are the goals for the architecture of an in-kernel IR system?

On Tue 2009-12-15 15:14:02, Jon Smirl wrote:
 On Tue, Dec 15, 2009 at 2:58 PM, Pavel Machek pa...@ucw.cz wrote:
  Hi!
 
        (11) if none is against renaming IR as RC, I'll do it on a next 
  patch;
 
  Call it irc -- infrared remote control. Bluetooth remote controls will
  have very different characteristics.
 
 How are they different after the scancode is extracted from the
 network packet? The scancode still needs to be passed to the input
 system, go through a keymap, and end up on an evdev device.
 
 I would expect the code for extracting the scancode to live in the
 networking stack, but after it is recovered the networking code would
 use the same API as IR to submit it to input.

For one thing,  bluetooth (etc) has concept of devices (and reliable
transfer). If you have two same bluetooth remotes, you can tell them
apart, unlike IR.

So yes, keymapping is the same, but that's pretty much it. Decoding
will not be the same (IR is special), etc...
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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] What are the goals for the architecture of an in-kernel IR system?

On Tue, Dec 15, 2009 at 3:19 PM, Pavel Machek pa...@ucw.cz wrote:
 On Tue 2009-12-15 15:14:02, Jon Smirl wrote:
 On Tue, Dec 15, 2009 at 2:58 PM, Pavel Machek pa...@ucw.cz wrote:
  Hi!
 
        (11) if none is against renaming IR as RC, I'll do it on a next 
  patch;
 
  Call it irc -- infrared remote control. Bluetooth remote controls will
  have very different characteristics.

 How are they different after the scancode is extracted from the
 network packet? The scancode still needs to be passed to the input
 system, go through a keymap, and end up on an evdev device.

 I would expect the code for extracting the scancode to live in the
 networking stack, but after it is recovered the networking code would
 use the same API as IR to submit it to input.

 For one thing,  bluetooth (etc) has concept of devices (and reliable
 transfer). If you have two same bluetooth remotes, you can tell them
 apart, unlike IR.

IR has the same concept of devices. That's what those codes you enter
into a universal remote do - they set the device.

There are three classes of remotes..
Fixed function - the device is hardwired
Universal - you can change the device
Multi-function - a universal that can be multiple devices - TV, cable,
audio, etc

If you set two Bluetooth remotes both to the same device you can't
tell them apart either.
Two identical fixed function remotes can be distinguished and they
shouldn't be distinguishable.

To distinguish between universal remotes just change the device being emulated.



 So yes, keymapping is the same, but that's pretty much it. Decoding
 will not be the same (IR is special), etc...
                                                                        Pavel

 --
 (english) http://www.livejournal.com/~pavelmachek
 (cesky, pictures) 
 http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html




-- 
Jon Smirl
jonsm...@gmail.com
--
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] What are the goals for the architecture of an in-kernel IR system?

On Tue 2009-12-15 15:29:51, Jon Smirl wrote:
 On Tue, Dec 15, 2009 at 3:19 PM, Pavel Machek pa...@ucw.cz wrote:
  On Tue 2009-12-15 15:14:02, Jon Smirl wrote:
  On Tue, Dec 15, 2009 at 2:58 PM, Pavel Machek pa...@ucw.cz wrote:
   Hi!
  
         (11) if none is against renaming IR as RC, I'll do it on a next 
   patch;
  
   Call it irc -- infrared remote control. Bluetooth remote controls will
   have very different characteristics.
 
  How are they different after the scancode is extracted from the
  network packet? The scancode still needs to be passed to the input
  system, go through a keymap, and end up on an evdev device.
 
  I would expect the code for extracting the scancode to live in the
  networking stack, but after it is recovered the networking code would
  use the same API as IR to submit it to input.
 
  For one thing,  bluetooth (etc) has concept of devices (and reliable
  transfer). If you have two same bluetooth remotes, you can tell them
  apart, unlike IR.
 
 IR has the same concept of devices. That's what those codes you enter
 into a universal remote do - they set the device.

They set the device _model_.

 There are three classes of remotes..
 Fixed function - the device is hardwired
 Universal - you can change the device
 Multi-function - a universal that can be multiple devices - TV, cable,
 audio, etc
 
 If you set two Bluetooth remotes both to the same device you can't
 tell them apart either.

Untrue. Like ethernets and wifis, bluetooth devices have unique
addresses. Communication is bidirectional.

Imagine wifi connected bluetooth. It is very different from infrared.

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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] What are the goals for the architecture of an in-kernel IR system?

On Tue, Dec 15, 2009 at 3:33 PM, Pavel Machek pa...@ucw.cz wrote:
 On Tue 2009-12-15 15:29:51, Jon Smirl wrote:
 On Tue, Dec 15, 2009 at 3:19 PM, Pavel Machek pa...@ucw.cz wrote:
  On Tue 2009-12-15 15:14:02, Jon Smirl wrote:
  On Tue, Dec 15, 2009 at 2:58 PM, Pavel Machek pa...@ucw.cz wrote:
   Hi!
  
         (11) if none is against renaming IR as RC, I'll do it on a next 
   patch;
  
   Call it irc -- infrared remote control. Bluetooth remote controls will
   have very different characteristics.
 
  How are they different after the scancode is extracted from the
  network packet? The scancode still needs to be passed to the input
  system, go through a keymap, and end up on an evdev device.
 
  I would expect the code for extracting the scancode to live in the
  networking stack, but after it is recovered the networking code would
  use the same API as IR to submit it to input.
 
  For one thing,  bluetooth (etc) has concept of devices (and reliable
  transfer). If you have two same bluetooth remotes, you can tell them
  apart, unlike IR.

 IR has the same concept of devices. That's what those codes you enter
 into a universal remote do - they set the device.

 They set the device _model_.

 There are three classes of remotes..
 Fixed function - the device is hardwired
 Universal - you can change the device
 Multi-function - a universal that can be multiple devices - TV, cable,
 audio, etc

 If you set two Bluetooth remotes both to the same device you can't
 tell them apart either.

 Untrue. Like ethernets and wifis, bluetooth devices have unique
 addresses. Communication is bidirectional.

I agree with that, but the 802.15.4 remote control software I've
worked with ignores the MAC address. You set your remote to send codes
for a specific device.  The mac address of the remote is ignored so
that any remote can control the device.  You don't need to pair
802.15.4 remotes like Bluetooth devices need to be paired.

I haven't played around with a Bluetooth remote. Nothing I own can
send the signals.  How can a Bluetooth remote control multiple devices
in the same room if it needs to be paired?

If it doesn't use this API, how does a Bluetooth remote turn a button
press into a Linux keycode on an evdev device?



 Imagine wifi connected bluetooth. It is very different from infrared.

 --
 (english) http://www.livejournal.com/~pavelmachek
 (cesky, pictures) 
 http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html




-- 
Jon Smirl
jonsm...@gmail.com
--
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] What are the goals for the architecture of an in-kernel IR system?

On Tue 2009-12-15 15:45:14, Jon Smirl wrote:
 On Tue, Dec 15, 2009 at 3:33 PM, Pavel Machek pa...@ucw.cz wrote:
  On Tue 2009-12-15 15:29:51, Jon Smirl wrote:
  On Tue, Dec 15, 2009 at 3:19 PM, Pavel Machek pa...@ucw.cz wrote:
   On Tue 2009-12-15 15:14:02, Jon Smirl wrote:
   On Tue, Dec 15, 2009 at 2:58 PM, Pavel Machek pa...@ucw.cz wrote:
Hi!
   
      (11) if none is against renaming IR as RC, I'll do it on a 
next patch;
   
Call it irc -- infrared remote control. Bluetooth remote controls will
have very different characteristics.
  
   How are they different after the scancode is extracted from the
   network packet? The scancode still needs to be passed to the input
   system, go through a keymap, and end up on an evdev device.
  
   I would expect the code for extracting the scancode to live in the
   networking stack, but after it is recovered the networking code would
   use the same API as IR to submit it to input.
  
   For one thing,  bluetooth (etc) has concept of devices (and reliable
   transfer). If you have two same bluetooth remotes, you can tell them
   apart, unlike IR.
 
  IR has the same concept of devices. That's what those codes you enter
  into a universal remote do - they set the device.
 
  They set the device _model_.
 
  There are three classes of remotes..
  Fixed function - the device is hardwired
  Universal - you can change the device
  Multi-function - a universal that can be multiple devices - TV, cable,
  audio, etc
 
  If you set two Bluetooth remotes both to the same device you can't
  tell them apart either.
 
  Untrue. Like ethernets and wifis, bluetooth devices have unique
  addresses. Communication is bidirectional.
 
 I agree with that, but the 802.15.4 remote control software I've
 worked with ignores the MAC address. You set your remote to send codes
 for a specific device.  The mac address of the remote is ignored so
 that any remote can control the device.  You don't need to pair
 802.15.4 remotes like Bluetooth devices need to be paired.
 
 I haven't played around with a Bluetooth remote. Nothing I own can
 send the signals.  How can a Bluetooth remote control multiple devices
 in the same room if it needs to be paired?

I'd guess that bluetooth remote would be very similar to bluetooth
keyboard, and present itself in a very similar way.

I still believe infrared is different -- it is essentially light with
very little protocol above. 
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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] What are the goals for the architecture of an in-kernel IR system?

On Tue, Dec 15, 2009 at 3:45 PM, Jon Smirl jonsm...@gmail.com wrote:
 On Tue, Dec 15, 2009 at 3:33 PM, Pavel Machek pa...@ucw.cz wrote:
 Untrue. Like ethernets and wifis, bluetooth devices have unique
 addresses. Communication is bidirectional.

I read a little about how Bluetooth remotes work. Correct me if I get
things wrong

They create pairings between the remote and the device. Each of these
pairings is assigned a device type. Multiple devices in the same room
are handled by the remote remembering the pairings and sending
directed packets instead of broadcast. That lets you have two TVs in
the same room.

Bluetooth devices need to advertise what profiles they support. So on
the Linux box you'd run a command to load the Bluetooth profile for
TV. This command would create an evdev subdevice, load the Bluetooth
keymap for TV, and tell the networking stack to advertise TV support.
Next you initiate the pairing from the Bluetooth remote and pick the
Linux box. This causes a pairing established exchange which tells the
Linux box to make the pairing persistent.

I believe the Bluetooth remote profile is handled in user space by the
BlueZ stack. BlueZ should be aware of the remote pairings. When it
decodes a button press it would need to inject the scancode into the
correct evdev subdevice. Evdev would translate it in the keymap and
create the keyevent. This is the same mechanism LIRC is using.


At a more general level we're missing a way for something like Myth to
declare that it is a DVR device. Myth should load, say I'm a DVR, and
then the remote control subsystem should automatically create a
Bluetooth DVR profile, load an IR profile for Motorola DVR on a
universal remote if the box has Bluetooth, IR or 802.15.4.

The whole concept of a remote control subsystem seems like it needs
more design work done. We keep coming up with big areas that no one
has thought about.

-- 
Jon Smirl
jonsm...@gmail.com
--
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] What are the goals for the architecture of an in-kernel IR system?

2009-12-13 Thread Mauro Carvalho Chehab

Dmitry Torokhov wrote:
 On Sun, Dec 06, 2009 at 09:34:26PM +0100, Krzysztof Halasa wrote:
 Jon Smirl jonsm...@gmail.com writes:

 Once again: how about agreement about the LIRC interface
 (kernel-userspace) and merging the actual LIRC code first? In-kernel
 decoding can wait a bit, it doesn't change any kernel-user interface.
 I'd like to see a semi-complete design for an in-kernel IR system
 before anything is merged from any source.
 This is a way to nowhere, there is no logical dependency between LIRC
 and input layer IR.

 There is only one thing which needs attention before/when merging LIRC:
 the LIRC user-kernel interface. In-kernel IR system is irrelevant and,
 actually, making a correct IR core design without the LIRC merged can be
 only harder.
 
 This sounds like merge first, think later...
 
 The question is why we need to merge lirc interface right now, before we
 agreed on the sybsystem architecture? Noone _in kernel_ user lirc-dev
 yet and, looking at the way things are shaping, no drivers will be
 _directly_ using it after it is complete. So, even if we merge it right
 away, the code will have to be restructured and reworked. Unfortunately,
 just merging what Jarod posted, will introduce sysfs hierarchy which
 is userspace interface as well (although we not as good maintaining it
 at times) and will add more constraints on us.
 
 That is why I think we should go the other way around - introduce the
 core which receivers could plug into and decoder framework and once it
 is ready register lirc-dev as one of the available decoders.
 

I've committed already some IR restruct code on my linux-next -git tree:

http://git.kernel.org/?p=linux/kernel/git/mchehab/linux-next.git

The code there basically moves the input/evdev registering code and 
scancode/keycode management code into a separate ir-core module.

To make my life easy, I've moved the code temporarily into drivers/media/IR.
This way, it helps me to move V4L specific code outside ir-core and to later
use it for DVB. After having it done, probably the better is to move it to
be under /drivers or /drivers/input.

The enclosed patch just adds a skeleton for the new sysfs class for remote
controllers and registers an yet unused ir_protocol attribute, creating this
tree:

/sys/class/irrcv/
|-- irrcv0
|   |-- ir_protocol
|   |-- power
|   |   `-- wakeup
|   |-- subsystem - ../../irrcv
|   `-- uevent
`-- irrcv1
|-- ir_protocol
|-- power
|   `-- wakeup
|-- subsystem - ../../irrcv
`-- uevent

While writing the code, it occurred to me that calling it as IR is not the 
better way,
since there's nothing on the code that is related to infra-red, but, instead, is
is related to remote controller.

So, if it is ok for everybudy, IMO, we should use, instead rc meaning remote 
controller,
naming the core module as rc-core, putting it into drivers/rc.

Also, since the same rc chip can have a receiver and a transmitter, maybe we 
can create the
class as:
/sys/class/rc
rcrcv0/
rcrcv1/
...
rctx0/
rctx1/
...

Comments?


---
 linux/drivers/media/IR/Makefile  |2 
 linux/drivers/media/IR/ir-keytable.c |   17 +-
 linux/drivers/media/IR/ir-sysfs.c|   94 +++
 linux/include/media/ir-core.h|   12 +++-
 4 files changed, 119 insertions(+), 6 deletions(-)

--- master.orig/linux/drivers/media/IR/Makefile
+++ master/linux/drivers/media/IR/Makefile
@@ -1,5 +1,5 @@
 ir-common-objs  := ir-functions.o ir-keymaps.o
-ir-core-objs   := ir-keytable.o
+ir-core-objs   := ir-keytable.o ir-sysfs.o
 
 obj-$(CONFIG_IR_CORE) += ir-core.o
 obj-$(CONFIG_VIDEO_IR) += ir-common.o
--- master.orig/linux/drivers/media/IR/ir-keytable.c
+++ master/linux/drivers/media/IR/ir-keytable.c
@@ -448,12 +448,21 @@ int ir_input_register(struct input_dev *
input_set_drvdata(input_dev, ir_dev);
 
rc = input_register_device(input_dev);
+   if (rc  0)
+   goto err;
+
+   rc = ir_register_class(input_dev);
if (rc  0) {
-   kfree(rc_tab-scan);
-   kfree(ir_dev);
-   input_set_drvdata(input_dev, NULL);
+   input_unregister_device(input_dev);
+   goto err;
}
 
+   return 0;
+
+err:
+   kfree(rc_tab-scan);
+   kfree(ir_dev);
+   input_set_drvdata(input_dev, NULL);
return rc;
 }
 EXPORT_SYMBOL_GPL(ir_input_register);
@@ -473,6 +482,8 @@ void ir_input_unregister(struct input_de
kfree(rc_tab-scan);
rc_tab-scan = NULL;
 
+   ir_unregister_class(dev);
+
kfree(ir_dev);
input_unregister_device(dev);
 }
--- /dev/null
+++ master/linux/drivers/media/IR/ir-sysfs.c
@@ -0,0 +1,94 @@
+/* ir-register.c - handle IR scancode-keycode tables
+ *
+ * Copyright (C) 2009 by Mauro Carvalho Chehab mche...@redhat.com
+ *
+ * This program is free software; you can redistribute it and/or modify

Re: [RFC] What are the goals for the architecture of an in-kernel IR system?

2009-12-12 Thread david


On Sun, 6 Dec 2009, Krzysztof Halasa wrote:


Andy Walls awa...@radix.net writes:


Yes, I agree.  I do not know what percentage of current Linux users are
technical vs non-technical, so I cannot gauge the current improtance.

I can see the trend line though: as time goes by, the percentage of all
linux users that have a technical bent will only get smaller.


This IMHO shouldn't matter. If users can configure their keymaps for
e.g. games with a graphical utility (and  they easily can), they can do
the same with their remotes, at least with these using common sane
protocols. The only thing needed is a good GUI utility. Ergo - it's not
a kernel issue.

The default bundled, or PnP, won't work well in comparison to a GUI
utility, I wouldn't worry about it too much (though adding it to udev
and co is trivial and we should do it - even if not PnP but asking first
about the actual remote used).


how is this problem any different from figuring out the keymap of a 
keyboard?


there are many defined keymaps (including cases where keys are labled 
different things on the keyboard but send identical codes)


currently in linux distros the user can either select the keymap, or the 
installer will ask the user to press specific keys (or indicate that they 
don't exist) until the installer can guess the keymap to use.


why would this not work for IR remotes as well?

and just like linux has some default keymaps that it uses that mostly work 
for the common case, there could be default IR keymaps that map the common 
keys for all remotes to the appropriate keycodes. it will mean that by 
default you won't see a difference between a DVD, VCR, DVR, etc play 
button, but it will mean that someone picking up a random remote and 
pointing it at the linux box will probably get minimal functionality.


then with a utility to tweak the keymap (or load a more specific one) the 
user can do better.


this would also integrate very nicely with they 'multimedia keyboards' 
that have lots of buttons on them as well, unless you tell it otherwise, 
play is play is play no matter which play button is pressed.


David Lang
--
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] What are the goals for the architecture of an in-kernel IR system?

2009-12-08 Thread Emmanuel Fusté


Dmitry Torokhov a écrit :

On Mon, Dec 07, 2009 at 06:54:39PM +0100, Emmanuel Fusté wrote:
  

Mauro Carvalho Chehab wrote:



In summary,

While the current EVIO[G|S]KEYCODE works sub-optimally for scancodes up 
to 16 bytes

(since a read loop for 2^16 is not that expensive), the current approach
won't scale with bigger scancode spaces. So, it is needed expand it
to work with bigger scancode spaces, used by more recent IR protocols.

I'm afraid that any tricks we may try to go around the current limits to still
keep using the same ioctl definition will sooner or later cause big headaches.
The better is to redesign it to allow using different scancode spaces.


  
  

I second you: input layer events from drivers should be augmented with a
protocol member, allowing us to define new ioctl and new ways to
efficiently store and manage sparse scancode spaces (tree, hashtable
).



Userspace has no business knowing how driver maps hardware data stream
into a keycode, only what is being mapped to what. The way is is done
can change from driver-to-driver, from release to release. If I come up
with an super-smart or super-stupid way of storing key mapping I won't
want to modify userpsace tools to support it.

  
But this is the point for IR. Userspace need a stable and universal 
driver to driver way to represent the hardware data stream. This is 
needed for only one but very important application: creating and 
modifying exchangeable remote mappings.
The way of storing in kernel key mapping should not have any impacts on 
usersapce tools. If this is the case, this is because the actual ioctl 
is too tied to the way these mapping are stored. These need to changed 
or be expanded for IR.

It will allow us to abstract the scancode value and to use
variable length scancode depending on the used protocol, and using the
most appropriate scheme to store the scancode/keycode mapping per protocol.
The today scancode space will be the legacy one, the default if not
specified protocol. It will permit to progressively clean up the
actual acceptable mess in the input layer and finally using real
scancode - keycode mappings everywhere if it is cleaner/convenient.




I am unable to parse this part, sorry.

  

My bad, my English is awful, sorry. :-(

Best regards,
Emmanuel.
--
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] What are the goals for the architecture of an in-kernel IR system?

Jon Smirl wrote:
 On Mon, Dec 7, 2009 at 1:41 PM, Dmitry Torokhov
 dmitry.torok...@gmail.com wrote:
 That is why I think we should go the other way around - introduce the
 core which receivers could plug into and decoder framework and once it
 is ready register lirc-dev as one of the available decoders.
 
 The core needs to allow for RF remotes too.
 
 -Bluetooth remotes are already in kernel somehow, I don't know how they work,
 -RF4CE, the 802.15.4 stack has been recently merged, the remotes use a
 protocol on top of that. These remotes will hit the consumer market
 next year. Sony, Panasonic and other big names are behind this.
 -Zwave, the Harmony remotes use Zwave. There is no Zwave support in
 the kernel that I am aware of. Zwave is proprietary.
 
 After these protocols are decoded you end up with scancodes. The
 scancodes need to get injected into input somehow and then flow
 through the mapping process. Decoding down to the scancodes probably
 happens over in the networking code.
 
 After an in-kernel IR decoder runs it needs to hand off the scancodes
 into the input subsystem. This same API can be used by the networking
 code to hand off RF scancodes.
 

Yes, the same core should be able to work with non infra red remotes, but, 
depending
on how the device is implemented.

Cheers,
Mauro.
--
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] What are the goals for the architecture of an in-kernel IR system?

Dmitry Torokhov wrote:
 On Mon, Dec 07, 2009 at 09:44:14PM -0200, Mauro Carvalho Chehab wrote:

 What about capabilities of the receiver, what frequencies?
 If a receiver has multiple frequencies, how do you report what
 frequency the data came in on?
 IMO, via sysfs.
 
 We probably need to think what exactly we report through sysfs siunce it
 is ABI of sorts.

Yes, sure.

Probably, the exact needs will popup only when we start to actually writing that
part of the core.

My intention for now is to just create a /sys/class/irrcv, with one node
per each IR receiver and adding a protocol enumeration/selection node
there, and add some capabilities for the in-kernel decoders and lirc_dev
to create new nodes under that class.

When the decoders/lirc_dev patches popup, we'll need to review those sysfs
API's.
 
 What about multiple apps simultaneously using the pulse data?
 IMO, the better is to limit the raw interface to just one open.

 
 Why woudl we want to do this? Quite often there is a need for observer
 that maybe does not act on data but allows capturing it. Single-user
 inetrfaces are PITA. 

That should work fine as well, but I'm not sure how we'll detect overrun with
several kfifo readers.

 How big is the receive queue?
 It should be big enough to receive at least one keycode event. Considering 
 that
 the driver will use kfifo (IMO, it is a good strategy, especially since you
 won't need any lock if just one open is allowed), it will require a power of 
 two size.

 
 Would not it be wither driver- or protocol-specific?

Probably.

 
 How does access work, root only or any user?
 IMO, it should be the same requirement as used by an input interface.

 How are capabilities exposed, sysfs, etc?
 IMO, sysfs.

 What is the interface for attaching an in-kernel decoder?
 IMO, it should use the kfifo for it. However, if we allow both raw data and
 in-kernel decoders to read data there, we'll need a spinlock to protect the
 kfifo.

 
 I think Jon meant userspace interface for attaching particular decoder.

I don't think we need an userspace interface for the in-kernel decoders. All
it needs is to enable/disable the protocol decoders, imo via sysfs interface.

 If there is an in-kernel decoder should the pulse data stop being
 reported, partially stopped, something else?
 I don't have a strong opinion here, but, from the previous discussions, it
 seems that people want it to be double-reported by default. If so, I think
 we need to implement a command at the raw interface to allow disabling the
 in-kernel decoder, while the raw interface is kept open.
 
 Why don't you simply let consumers decide where they will get their data?

How?

Cheers,
Mauro.
--
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] What are the goals for the architecture of an in-kernel IR system?

2009-12-08 Thread Jon Smirl

On Tue, Dec 8, 2009 at 6:17 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
 Jon Smirl wrote:
 On Mon, Dec 7, 2009 at 6:44 PM, Mauro Carvalho Chehab
 mche...@redhat.com wrote:

 Where is the documentation for the protocol?
 I'm not sure what you're meaning here. I've started a doc about IR at the 
 media

 What is the format of the pulse stream data coming out of the lirc device?

 AFAIK, it is at:
        http://www.lirc.org/html/index.html

 It would be nice to to add it to DocBook after integrating the API in kernel.


The point of those design review questions was to illustrate that the
existing LIRC system is only partially designed. Subsystems need to be
fully designed before they get merged.

For example 36-40K and 56K IR signals are both in use. It is a simple
matter to design a receiver (or buy two receivers)  that would support
both these frequencies. But the current LIRC model only supports  a
single IR receiver. Adjusting it to support two receivers is going to
break the ABI.

My choice would be to just tell the person with the 56K remote to just
buy a new 38K remote, but other people are against that choice. That
forces us into designing a system that can handle multiple receivers.
There is a parallel problem with baseband encoded IR signals.

We need to think about all of these use cases before designing the
ABI.  Only after we think we have a good ABI design should code start
being merged. Of course we may make mistakes and have to fix the ABI,
but there is nothing to be gained by merging the existing ABI if we
already know it has problems.

-- 
Jon Smirl
jonsm...@gmail.com
--
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] What are the goals for the architecture of an in-kernel IR system?

Mauro Carvalho Chehab mche...@redhat.com writes:

 What is the interface for attaching an in-kernel decoder?

 IMO, it should use the kfifo for it. However, if we allow both raw data and
 in-kernel decoders to read data there, we'll need a spinlock to protect the
 kfifo.

This may be an option, but I think we should be able to attach protocol
decoders in parallel, directly to the IRQ handler. At least with RC-5
(that's what I personally use) it means reliable decoding, no need for
any timeouts, the code is clean, fast (can be a part of hard IRQ
handler) and simple.

The decoder needs something like
rc5_signal_change(ptr, space_or_mark, microseconds).

At least mark-space or space-mark events must be reported. For better
reliability, both of them.
-- 
Krzysztof Halasa
--
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] What are the goals for the architecture of an in-kernel IR system?

Jon Smirl jonsm...@gmail.com writes:

 Data could be sent to the in-kernel decoders first and then if they
 don't handle it, send it to user space.

Nope. It should be sent to all of them, they aren't dependent.
-- 
Krzysztof Halasa
--
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] What are the goals for the architecture of an in-kernel IR system?

Dmitry Torokhov dmitry.torok...@gmail.com writes:

 Why woudl we want to do this? Quite often there is a need for observer
 that maybe does not act on data but allows capturing it. Single-user
 inetrfaces are PITA.

Lircd can work as a multiplexer. IMHO single-open lirc interface is ok,
though we obviously need simultaneous operation of in-kernel decoders.
-- 
Krzysztof Halasa
--
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] What are the goals for the architecture of an in-kernel IR system?

Mauro Carvalho Chehab mche...@redhat.com writes:

 I don't think we need an userspace interface for the in-kernel
 decoders.

Of course we need it, to set (and probably retrieve) scancode-keycode
mappings. This could probably be, ATM, the existing input layer channel.

 All
 it needs is to enable/disable the protocol decoders, imo via sysfs interface.

This isn't IMHO needed at all. The protocol is enabled when at least one
key using it is configured, otherwise it's disabled. We probably need
some wildcard as well, to capture decoded scancodes (through the input
layer).
This is BTW pure optimization, the protocol could stay enabled all the
time, only wasting the cycles.
-- 
Krzysztof Halasa
--
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] What are the goals for the architecture of an in-kernel IR system?

Mauro Carvalho Chehab mche...@redhat.com writes:

 Yes, an opaque type for scancode at the userspace API can be better, but
 passing a pointer to kernel will require some compat32 logic (as pointer
 size is different on 32 and 64 bits).

Yes. I think we can't avoid that, but it's a single compat handler,
I wouldn't worry about it too much. We don't need it in every driver
fortunately.

 We may use something like an u8[] with an arbitrary large number of
 bytes.

Yes. All of this pointed to by the pointer.

 In this case, we need to take some care to avoid LSB/MSB troubles.

Sure.
-- 
Krzysztof Halasa
--
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] What are the goals for the architecture of an in-kernel IR system?

Krzysztof Halasa wrote:
 Mauro Carvalho Chehab mche...@redhat.com writes:
 
 What is the interface for attaching an in-kernel decoder?
 IMO, it should use the kfifo for it. However, if we allow both raw data and
 in-kernel decoders to read data there, we'll need a spinlock to protect the
 kfifo.
 
 This may be an option, but I think we should be able to attach protocol
 decoders in parallel, directly to the IRQ handler. At least with RC-5
 (that's what I personally use) it means reliable decoding, no need for
 any timeouts, the code is clean, fast (can be a part of hard IRQ
 handler) and simple.
 
 The decoder needs something like
   rc5_signal_change(ptr, space_or_mark, microseconds).
 
 At least mark-space or space-mark events must be reported. For better
 reliability, both of them.

If you use a kfifo to store the event (space_or_mark, timestamp), 
the IRQ handler can return immediately, and a separate kernel thread 
can do the decode without needing to touch at the IRQ. It also helps to
have a decoder independent of the kernel driver.

Cheers,
Mauro.
--
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] What are the goals for the architecture of an in-kernel IR system?

Krzysztof Halasa wrote:
 Mauro Carvalho Chehab mche...@redhat.com writes:
 
 I don't think we need an userspace interface for the in-kernel
 decoders.
 
 Of course we need it, to set (and probably retrieve) scancode-keycode
 mappings. This could probably be, ATM, the existing input layer channel.

This is the standard/extended evdev interface already discussed.
 
 All
 it needs is to enable/disable the protocol decoders, imo via sysfs interface.
 
 This isn't IMHO needed at all. The protocol is enabled when at least one
 key using it is configured, otherwise it's disabled. We probably need
 some wildcard as well, to capture decoded scancodes (through the input
 layer).
 This is BTW pure optimization, the protocol could stay enabled all the
 time, only wasting the cycles.

The enable/disable protocol decoder enable/disable interface is needed anyway,
due to the needs for the hardware IR decoders (and the legacy IR decoders,
while we don't convert all of them to the generic ones).

So, IMO, the interface will be cleaner if we use it also for the generic
IR decoders.

Cheers,
Mauro.
--
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] What are the goals for the architecture of an in-kernel IR system?

2009-12-08 Thread Jon Smirl

On Tue, Dec 8, 2009 at 9:07 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
 Krzysztof Halasa wrote:
 Mauro Carvalho Chehab mche...@redhat.com writes:

 What is the interface for attaching an in-kernel decoder?
 IMO, it should use the kfifo for it. However, if we allow both raw data and
 in-kernel decoders to read data there, we'll need a spinlock to protect the
 kfifo.

 This may be an option, but I think we should be able to attach protocol
 decoders in parallel, directly to the IRQ handler. At least with RC-5
 (that's what I personally use) it means reliable decoding, no need for
 any timeouts, the code is clean, fast (can be a part of hard IRQ
 handler) and simple.

 The decoder needs something like
       rc5_signal_change(ptr, space_or_mark, microseconds).

 At least mark-space or space-mark events must be reported. For better
 reliability, both of them.

 If you use a kfifo to store the event (space_or_mark, timestamp),
 the IRQ handler can return immediately, and a separate kernel thread
 can do the decode without needing to touch at the IRQ. It also helps to
 have a decoder independent of the kernel driver.

The first version of my code ran the decoders from the IRQ. That
wasn't a good model for sharing decoders between drivers. So I
switched to using a kernel thread. There is also the problem of
handing decoded events off up the chain. You can't do that from IRQ
context.

If I remember correctly the kernel thread would run approximately two
times per IR message received. But sometimes it would only run once.
It's a random function of the load on the system. The kernel thread
empties the FIFO and sends the pulses in parallel to the decoders.

Code for doing this is in the patches I posted. I wasn't aware of
kfifo when I wrote them so I coded my own fifo.

-- 
Jon Smirl
jonsm...@gmail.com
--
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] What are the goals for the architecture of an in-kernel IR system?

Jon Smirl wrote:
 On Tue, Dec 8, 2009 at 6:17 AM, Mauro Carvalho Chehab
 mche...@redhat.com wrote:
 Jon Smirl wrote:
 On Mon, Dec 7, 2009 at 6:44 PM, Mauro Carvalho Chehab
 mche...@redhat.com wrote:
 Where is the documentation for the protocol?
 I'm not sure what you're meaning here. I've started a doc about IR at the 
 media
 What is the format of the pulse stream data coming out of the lirc device?
 AFAIK, it is at:
http://www.lirc.org/html/index.html

 It would be nice to to add it to DocBook after integrating the API in kernel.

 
 The point of those design review questions was to illustrate that the
 existing LIRC system is only partially designed. 

Ah, ok.

 Subsystems need to be
 fully designed before they get merged.

True.
 
 For example 36-40K and 56K IR signals are both in use. It is a simple
 matter to design a receiver (or buy two receivers)  that would support
 both these frequencies. But the current LIRC model only supports  a
 single IR receiver. Adjusting it to support two receivers is going to
 break the ABI.
 
 My choice would be to just tell the person with the 56K remote to just
 buy a new 38K remote, but other people are against that choice. That
 forces us into designing a system that can handle multiple receivers.
 There is a parallel problem with baseband encoded IR signals.
 
 We need to think about all of these use cases before designing the
 ABI.  Only after we think we have a good ABI design should code start
 being merged. Of course we may make mistakes and have to fix the ABI,
 but there is nothing to be gained by merging the existing ABI if we
 already know it has problems.

I have here machines with 3 or 4 IR receivers (well, in a matter of fact,
I don't use all of them at the same time). Nothing stops someone to
use all IR receivers at the same. 

I've seen some interesting applications developed for students, where just
one computer running Linux is splitted into 4 different consoles. Nothing
stops that, on such usages, you may have 4 different IR transceivers working
at the same time.

In order to keep supporting the in-kernel drivers, we should create one lirc
device per each IR transceiver.

Cheers,
Mauro.

--
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] What are the goals for the architecture of an in-kernel IR system?

Dmitry Torokhov dmitry.torok...@gmail.com writes:

 No, the IR core responsible for registering receivers and decoders.

Well. This makes me think now that LIRC can be just another decoder.

 Those are simple things. The only part which needs to be stable is the
 (in this case LIRC) kernel-user interface.

 For which some questions are still open. I believe Jon just oulined some
 of them.

Those are rather how does it work, not let's change something because
it's not optimal.

 No we do not. We do not merge something that we expect to rework almost
 completely (no, not the lirc-style device userspace inetrface, although
 even it is not completely finalized I believe, but the rest of the
 subsystem).

I don't think we need to rework it almost completely. Perhaps we need to
change a hook here or there.

 No, not at all. You merge core subsystem code, then start addig
 decoders...

You must have at least one common decoder merged with the core code,
otherwise you don't know if the core is adequate. And you have to have
at least one common input device.

But perhaps it is a workable idea after all, given the another
decoder.
-- 
Krzysztof Halasa
--
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] What are the goals for the architecture of an in-kernel IR system?

Mauro Carvalho Chehab mche...@redhat.com writes:

 The enable/disable protocol decoder enable/disable interface is needed anyway,
 due to the needs for the hardware IR decoders

Why do they need it exactly?
The key tables say all they need I hope?
-- 
Krzysztof Halasa
--
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] What are the goals for the architecture of an in-kernel IR system?

Mauro Carvalho Chehab mche...@redhat.com writes:

 If you use a kfifo to store the event (space_or_mark, timestamp), 
 the IRQ handler can return immediately, and a separate kernel thread 
 can do the decode without needing to touch at the IRQ.

But the decoding itself is a really simple thing, why complicate it?
There is no need for the kernel thread if the handler is fast (and it
is).

Userspace is obviously different.
-- 
Krzysztof Halasa
--
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] What are the goals for the architecture of an in-kernel IR system?

Krzysztof Halasa wrote:
 Mauro Carvalho Chehab mche...@redhat.com writes:
 
 The enable/disable protocol decoder enable/disable interface is needed 
 anyway,
 due to the needs for the hardware IR decoders
 
 Why do they need it exactly?
 The key tables say all they need I hope?

You can't upload a key for an unsupported protocol. Also, provided
that hardware decoders in general don't support decoding multiple
protocols at the same time, it is needed to select what protocol it
will be decoding.

So, userspace needs to:
- retrieve the list of the supported protocols;
- identify if a given IR is capable of multiple protocols;
- be able to select what protocol(s) decoder(s) will be enabled.

Cheers,
Mauro.
--
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] What are the goals for the architecture of an in-kernel IR system?

Krzysztof Halasa wrote:
 Mauro Carvalho Chehab mche...@redhat.com writes:
 
 If you use a kfifo to store the event (space_or_mark, timestamp), 
 the IRQ handler can return immediately, and a separate kernel thread 
 can do the decode without needing to touch at the IRQ.
 
 But the decoding itself is a really simple thing, why complicate it?
 There is no need for the kernel thread if the handler is fast (and it
 is).

The decoding of just one protocol may be fast, but having several decoders
serialized (without kthreads, you're serializing the decoders) will possibly
not be that fast.

Also, you don't need wake the decoders kthreads for every event, but wait
for some number of events to happen before waking it. For example,
16 pulse/space events correspond to 8 bits of data on most protocols, 
so you can wake the kthread only after 16 events for really simple decoders,
or if a timeout event is detected. The number of events to wake may be 
customized
per decoder.

Cheers,
Mauro.
--
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] What are the goals for the architecture of an in-kernel IR system?

2009-12-08 Thread Jon Smirl

On Tue, Dec 8, 2009 at 10:49 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
 Krzysztof Halasa wrote:
 Mauro Carvalho Chehab mche...@redhat.com writes:

 If you use a kfifo to store the event (space_or_mark, timestamp),
 the IRQ handler can return immediately, and a separate kernel thread
 can do the decode without needing to touch at the IRQ.

 But the decoding itself is a really simple thing, why complicate it?
 There is no need for the kernel thread if the handler is fast (and it
 is).

 The decoding of just one protocol may be fast, but having several decoders
 serialized (without kthreads, you're serializing the decoders) will possibly
 not be that fast.

 Also, you don't need wake the decoders kthreads for every event, but wait

Just wake the default kthread on each event. If you wake the default
thread multiple times it is the same as waking it once.

The default kthread doesn't schedule very fast. If you get 120 events
and call wake 120 times, the thread is only going to visit your driver
one or two times not 120 times.

 for some number of events to happen before waking it. For example,
 16 pulse/space events correspond to 8 bits of data on most protocols,
 so you can wake the kthread only after 16 events for really simple decoders,
 or if a timeout event is detected. The number of events to wake may be 
 customized
 per decoder.

 Cheers,
 Mauro.




-- 
Jon Smirl
jonsm...@gmail.com
--
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] What are the goals for the architecture of an in-kernel IR system?

2009-12-08 Thread Dmitry Torokhov

On Tue, Dec 08, 2009 at 09:58:53AM -0200, Mauro Carvalho Chehab wrote:
 Dmitry Torokhov wrote:
  On Mon, Dec 07, 2009 at 09:44:14PM -0200, Mauro Carvalho Chehab wrote:
 
  What about capabilities of the receiver, what frequencies?
  If a receiver has multiple frequencies, how do you report what
  frequency the data came in on?
  IMO, via sysfs.
  
  We probably need to think what exactly we report through sysfs siunce it
  is ABI of sorts.
 
 Yes, sure.
 
 Probably, the exact needs will popup only when we start to actually writing 
 that
 part of the core.
 
 My intention for now is to just create a /sys/class/irrcv, with one node
 per each IR receiver and adding a protocol enumeration/selection node
 there, and add some capabilities for the in-kernel decoders and lirc_dev
 to create new nodes under that class.
 
 When the decoders/lirc_dev patches popup, we'll need to review those sysfs
 API's.
  
  What about multiple apps simultaneously using the pulse data?
  IMO, the better is to limit the raw interface to just one open.
 
  
  Why woudl we want to do this? Quite often there is a need for observer
  that maybe does not act on data but allows capturing it. Single-user
  inetrfaces are PITA. 
 
 That should work fine as well, but I'm not sure how we'll detect overrun with
 several kfifo readers.
 

Push the data into readers so they can do te decoding at their own pace.
Some can do it in interrupt context, some will need workqueue/thread.
They can also regilate the depth of the buffer, according to their
needs.

  How big is the receive queue?
  It should be big enough to receive at least one keycode event. Considering 
  that
  the driver will use kfifo (IMO, it is a good strategy, especially since you
  won't need any lock if just one open is allowed), it will require a power 
  of two size.
 
  
  Would not it be wither driver- or protocol-specific?
 
 Probably.
 
  
  How does access work, root only or any user?
  IMO, it should be the same requirement as used by an input interface.
 
  How are capabilities exposed, sysfs, etc?
  IMO, sysfs.
 
  What is the interface for attaching an in-kernel decoder?
  IMO, it should use the kfifo for it. However, if we allow both raw data and
  in-kernel decoders to read data there, we'll need a spinlock to protect the
  kfifo.
 
  
  I think Jon meant userspace interface for attaching particular decoder.
 
 I don't think we need an userspace interface for the in-kernel decoders. All
 it needs is to enable/disable the protocol decoders, imo via sysfs interface.
 
  If there is an in-kernel decoder should the pulse data stop being
  reported, partially stopped, something else?
  I don't have a strong opinion here, but, from the previous discussions, it
  seems that people want it to be double-reported by default. If so, I think
  we need to implement a command at the raw interface to allow disabling the
  in-kernel decoder, while the raw interface is kept open.
  
  Why don't you simply let consumers decide where they will get their data?
 
 How?
 

You end up with N evdev devices. Let application (MythTV) say I want to
use /dev/input/event1 (well, it will need persistent udev rule, but
that's a detail). Another application will chose another event node.
User can decide she'd rather use lircd - and so configire applications
to use event5. Any maybe turned off the in-kernel decoders if they are
of no use and there is a concern that they consume too mcuh resoures.

Won't this work? 

-- 
Dmitry
--
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] What are the goals for the architecture of an in-kernel IR system?

2009-12-08 Thread Dmitry Torokhov

On Tue, Dec 08, 2009 at 09:17:42AM -0200, Mauro Carvalho Chehab wrote:
 Jon Smirl wrote:
  On Mon, Dec 7, 2009 at 6:44 PM, Mauro Carvalho Chehab
  mche...@redhat.com wrote:
 
  Where is the documentation for the protocol?
  I'm not sure what you're meaning here. I've started a doc about IR at the 
  media
  
  What is the format of the pulse stream data coming out of the lirc device?
 
 AFAIK, it is at:
   http://www.lirc.org/html/index.html
 
 It would be nice to to add it to DocBook after integrating the API in kernel.
 
  docbook. This is currently inside the kernel Documents/DocBook. If you want
  to browse, it is also available as:
 
 http://linuxtv.org/downloads/v4l-dvb-apis/ch17.html
 
  For sure we need to better document the IR's, and explain the API's there.
 
  Is it a device interface or something else?
  lirc_dev should create a device interface.
 
  What about capabilities of the receiver, what frequencies?
  If a receiver has multiple frequencies, how do you report what
  frequency the data came in on?
  IMO, via sysfs.
  
  Say you have a hardware device with two IR diodes, one at 38K and one
  at 56K. Both of these receivers can get pulses. How do we tell the
  user space app which frequency the pulses were received on? Seems to
  me like there has to be a header on the pulse data indicating the
  received carrier frequency. There is also baseband signaling. sysfs
  won't work for this because of the queuing latency.
 
 Simply create two interfaces. One for each IR receiver. At sysfs, you'll
 have /sys/class/irrcv/irrcv0 for the first one and /sys/class/irrcv/irrcv1.

Yes, please. Distinct hardware - distinct representation in the kernel.
This is the most sane way.

...
 
  What is the interface for attaching an in-kernel decoder?
  IMO, it should use the kfifo for it. However, if we allow both raw data and
  in-kernel decoders to read data there, we'll need a spinlock to protect the
  kfifo.

Probably we should do what input layer does - the data is pushed into
all handlers that are signed up for it and they can deal with it at
their leisure.

 
  If there is an in-kernel decoder should the pulse data stop being
  reported, partially stopped, something else?
  I don't have a strong opinion here, but, from the previous discussions, it
  seems that people want it to be double-reported by default. If so, I think
  we need to implement a command at the raw interface to allow disabling the
  in-kernel decoder, while the raw interface is kept open.
  
  Data could be sent to the in-kernel decoders first and then if they
  don't handle it, send it to user space.

You do not know what userspace wants to do with the data. They may want
to simply observe it, store or do something else. Since we do provide
interface for such raw[ish] data we just need to transmit it to
userpsace as long as there are users (i.e. interface is open).

 
 Hmm... like adding a delay if the raw userspace is open and, if the raw 
 userspace
 doesn't read all pulse data, it will send via in-kernel decoder instead? This 
 can
 work, but I'm not sure if this is the better way, and will require some logic 
 to
 synchronize lirc_dev and IR core modules. Also, doing it key by key will 
 introduce
 some delay.
 
 If you're afraid of having the userspace app hanged and having no IR output, 
 it would be simpler to just close the raw interface if an available data 
 won't be
 read after a bigger timeout (3 seconds? 5 seconds?).

We can not foresee all use cases. Just let all parties signed up for the
data get and process it, do not burden the core with heuristics.

-- 
Dmitry
--
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] What are the goals for the architecture of an in-kernel IR system?

2009-12-08 Thread Dmitry Torokhov

On Tue, Dec 08, 2009 at 02:57:15PM +0100, Krzysztof Halasa wrote:
 Dmitry Torokhov dmitry.torok...@gmail.com writes:
 
  Why woudl we want to do this? Quite often there is a need for observer
  that maybe does not act on data but allows capturing it. Single-user
  inetrfaces are PITA.
 
 Lircd can work as a multiplexer. 

What this has to do with my statement? Did you mean retransmitter of sorts?

Also I may explicitely not want the data stream to be multiplexed...

 IMHO single-open lirc interface is ok,
 though we obviously need simultaneous operation of in-kernel decoders.

Why is the distinction?

-- 
Dmitry
--
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] What are the goals for the architecture of an in-kernel IR system?

2009-12-08 Thread Christoph Bartelmus

Hi Dmitry,

on 06 Dec 09 at 23:51, Dmitry Torokhov wrote:
[...]
 I suppose we could add MSC_SCAN_END event so that we can transmit
 scancodes of arbitrary length. You'd get several MSC_SCAN followed by
 MSC_SCAN_END marker. If you don't get MSC_SCAN_END assume the code is 32
 bit.

 And I set a timeout to know that no MSC_SCAN_END will arrive? This is
 broken design IMHO.


 EV_SYN signals the end of state transmission.

 Furthermore lircd needs to know the length of the scan code in bits, not
 as a multiple of 32.

 I really do not think that LIRCD is the type of application that should
 be using evdev interface, but rather other way around.

Well, all I'm asking is that lircd can keep using the LIRC interface for  
getting the scan codes. ;-)

Christoph
--
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] What are the goals for the architecture of an in-kernel IR system?

2009-12-08 Thread Christoph Bartelmus

Hi Jon,

on 08 Dec 09 at 08:34, Jon Smirl wrote:
[...]
 The point of those design review questions was to illustrate that the
 existing LIRC system is only partially designed. Subsystems need to be
 fully designed before they get merged.

I'd say that a system that has proven itself in real world applications  
for 10 years, does not deserve to be called partially designed.

 For example 36-40K and 56K IR signals are both in use. It is a simple
 matter to design a receiver (or buy two receivers)  that would support
 both these frequencies. But the current LIRC model only supports  a
 single IR receiver. Adjusting it to support two receivers is going to
 break the ABI.

Really? When we added support for multiple transmitters, we somehow  
managed to do without breaking the ABI. Do I miss something?

Your example could even now be solved by using the LIRC_SET_REC_CARRIER  
ioctl. The driver would have to choose the receiver that best fits the  
requested frequency.

[...]
 We need to think about all of these use cases before designing the
 ABI.  Only after we think we have a good ABI design should code start
 being merged. Of course we may make mistakes and have to fix the ABI,
 but there is nothing to be gained by merging the existing ABI if we
 already know it has problems.

The point is that we did not get up this morning and started to think  
about how the LIRC interface should look like. That happened 10 years ago.

I'm not saying that the interface is the nicest thing ever invented, but  
it works and is extendable. If you see that something is missing please  
bring it up.

Christoph
--
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] What are the goals for the architecture of an in-kernel IR system?

2009-12-08 Thread Christoph Bartelmus

Hi Andy,

on 07 Dec 09 at 23:10, Andy Walls wrote:
[...]
 (Christoph can correct me if I get anything wrong.)

Just a few additions.

[...]
 What is the time standard for the data, where does it come from?

 I think it is usec, IIRC.

Yes, it is.

 I know that the hardware I work with has sub 100 ns resolution,

Highest IR carrier frequency I know is 500kHz. usec resolution is enough  
even for raw modulated IR pulses. But you only look at the signal after it  
has been demodulated by the IR chip, so higher resolution would be  
overkill.

[...]
 How do you define the start and stop of sequences?

 For the end of Rx signalling:

 Well with the Conexant hardware I can set a maximum pulse (mark or
 space) width, and the hardware will generate an Rx Timeout interrupt to
 signal the end of Rx when a space ends up longer than that max pulse
 width.  The hardware also puts a special marker in the hardware pulse
 widht measurement FIFO (in band signalling essentially).

 I'm not sure anything like that gets communicated to userspace via
 lirc_dev, and I'm too tired to doublecheck right now.

There is no such thing in the protocol. Some devices cannot provide any  
end of signal marker, so lircd handles this using timers.

If there is some interest, the MODE2 protocol can be extended. We still  
have 7 bits unused...

 If you have determined the protocol you are after, it's easy to know
 what the pulse count should be and what the max pulse width should be (+
 slop for crappy hardware) so finding the end of an Rx isn't hard.  The
 button repeats intervals are *very* large.  I've never seen a remote
 rapid fire codes back to back.

I did. There are some protocols that have a gap of only 6000 us between  
signals. And the settop boxes are very picky about this. If you make it  
too long, they won't accept the command.

[...]
 Is transmitting synchronous or queued?

 kfifo's IIRC.

No, it's synchronous.

 How big is the transmit queue?

No queue.

[...]
 My particular gripes about the current LIRC interface:

 1. The one thing that I wish were documented better were the distinction
 between LIRC_MODE_PULSE, LIRC_MODE_RAW, and LIRC_MODE2 modes of
 operation.  I think I've figured it out, but I had to look at a lot of
 LIRC drivers to do so.

No driver uses RAW until now and lircd does not support it.
PULSE is used on the transmit path, MODE2 on the receive path.
There is no special reasoning for that, it's rather historic.
MODE2 makes sense on the receive path because you can easily distinguish  
between pulse/space.

 2. I have hardware where I can set max_pulse_width so I can optimize
 pulse timer resolution and have the hardware time out rapidly on end of
 RX.  I also have hardware where I can set a min_pulse_width to set a
 hardware low-pass/glitch filter.  Currently LIRC doesn't have any way to
 set these, but it would be nice to have.

Should be really easy to add these. The actual values could be derived  
from the config files easily.

 In band signalling of a
 hardware detected end of Rx may also make sense then too.

See above.

 3. As I mentioned before, it would be nice if LIRC could set a batch of
 parameters atomically somehow, instead of with a series of ioctl()s.  I
 can work around this in kernel though.

Is there any particular sequence that you are concerned about?
Setting carrier frequency and then duty cycle is a bit problematic.
Currently it's solved by resetting the duty cycle to 50% each time you  
change the carrier frequency.
But as the LIRC interface is one user only, I don't see a real problem.

Christoph
--
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] What are the goals for the architecture of an in-kernel IR system?

2009-12-08 Thread Andy Walls

On Tue, 2009-12-08 at 23:30 +0100, Christoph Bartelmus wrote:
 Hi Andy,
 
 on 07 Dec 09 at 23:10, Andy Walls wrote:
 [...]
  (Christoph can correct me if I get anything wrong.)
 
 Just a few additions.

Christoph,

Thanks for the corrections and additions. :)

 [...]

  I know that the hardware I work with has sub 100 ns resolution,
 
 Highest IR carrier frequency I know is 500kHz. usec resolution is enough  
 even for raw modulated IR pulses. But you only look at the signal after it  
 has been demodulated by the IR chip, so higher resolution would be  
 overkill.

Yes, it's overkill.  It is more of a side effect of how I set up the
hardware to uses as much of the bits in the pulse width measurement
counter as possible for the longest expected valid measurment width.
The LSB of the hardware pulse width measurement counter can convey a
time change of as little as 74 ns depending on the setup of the Conexant
integrated IR controller.


 [...]
  How do you define the start and stop of sequences?
 
  For the end of Rx signalling:
 
  Well with the Conexant hardware I can set a maximum pulse (mark or
  space) width, and the hardware will generate an Rx Timeout interrupt to
  signal the end of Rx when a space ends up longer than that max pulse
  width.  The hardware also puts a special marker in the hardware pulse
  widht measurement FIFO (in band signalling essentially).
 
  I'm not sure anything like that gets communicated to userspace via
  lirc_dev, and I'm too tired to doublecheck right now.
 
 There is no such thing in the protocol. Some devices cannot provide any  
 end of signal marker, so lircd handles this using timers.
 
 If there is some interest, the MODE2 protocol can be extended. We still  
 have 7 bits unused...

As I thought about this more, I could just pass up a space the length of
the pulse width measurment timeout from the kernel up to LIRC.  LIRC's
decoders should know that the space is too long as well.  No changes
needed - I think.




 [...]
  Is transmitting synchronous or queued?
 
  kfifo's IIRC.
 
 No, it's synchronous.
 
  How big is the transmit queue?
 
 No queue.

Oops, thanks for the correction.



 [...]
  My particular gripes about the current LIRC interface:

  2. I have hardware where I can set max_pulse_width so I can optimize
  pulse timer resolution and have the hardware time out rapidly on end of
  RX.  I also have hardware where I can set a min_pulse_width to set a
  hardware low-pass/glitch filter.  Currently LIRC doesn't have any way to
  set these, but it would be nice to have.
 
 Should be really easy to add these. The actual values could be derived  
 from the config files easily.

Good.  I thought it would be so.

  In band signalling of a
  hardware detected end of Rx may also make sense then too.
 
 See above.
 
  3. As I mentioned before, it would be nice if LIRC could set a batch of
  parameters atomically somehow, instead of with a series of ioctl()s.  I
  can work around this in kernel though.
 
 Is there any particular sequence that you are concerned about?
 Setting carrier frequency and then duty cycle is a bit problematic.
 Currently it's solved by resetting the duty cycle to 50% each time you  
 change the carrier frequency.
 But as the LIRC interface is one user only, I don't see a real problem.

The case I worry about is enabling the IR Rx hardware without the low
pass filter properly set up to be consistent with the minimum expected
Rx pulse width and the desired Rx carrier window or maximum expected Rx
pulse width.  The result could be a lot of useless interrupts from IR
glitch measurements in bad ambient light conditions until all the
parameters are consistent.

Regards,
Andy

 Christoph


--
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] What are the goals for the architecture of an in-kernel IR system?

Dmitry Torokhov wrote:
 On Sun, Dec 06, 2009 at 09:03:31AM -0200, Mauro Carvalho Chehab wrote:
 Dmitry Torokhov wrote:
 On Fri, Dec 04, 2009 at 12:12:34PM -0200, Mauro Carvalho Chehab wrote:
 Em Fri, 4 Dec 2009 02:06:42 -0800
 Dmitry Torokhov dmitry.torok...@gmail.com escreveu:

 evdev does not really care what you use as scancode. So nobody stops
 your driver to report index as a scancode and accept index from the
 ioctl. The true scancode will thus be competely hidden from userspace.
 In fact a few drivers do just that.
 Let me better express here. It is all about how we'll expand the limits of 
 those
 ioctls to fulfill the needs.

 The point is that we'll have, let's say something like to 50-500 
 scancode/keycode tuples
 sparsely spread into a 2^64 scancode universe (assuming 64 bits - Not sure 
 if is there any
 IR protocol/code with a bigger scancode).

 On such universe if we want to get all keycodes with the current ioctls 
 for a scancode in
 the range of 32 bits, we need to do something like:

 u32 code;
 int codes[2];
 for (code = 0; code = (unsigned u32) - 1; code++) {
codes[0] = (int)code;
if (!ioctl(fd, EVIOCGKEYCODE, codes))
printf(scancode 0x%08x = keycode 0x%08x\n, codes[0], 
 codes[1]);
 }

 So, on the 32 bits case, we'll do about 4 billions calls to EVIOGKEYCODE 
 ioctl to
 read the complete scancode space, to get those 50-500 useful codes.

 Right, currently there is no need to query all scancodes defined by
 device. Quite often drivers don't even know what scancodes device
 actually generates (ex AT keyboard).

 Could you describe in more detail how you are using this data?
 It is useful if you want to dump the keycode maps into file with the current
 scancode attribution, in order to modify some keystrokes.

 Right now, programs like dumpkeys (from kbd package) allow you to dump for 
 example
 the attribution keys from your keyboard.

 In the case of IR's this functionality is very important.

 For example, you may need to replace the scancode/KEY_CHANNELUP tuple by 
 scancode/KEY_UP,
 in order to make your IR to work with some applications that don't recognize 
 the IR
 specific keycodes.

 In practice, with such applications, you'll need to replace several 
 different scancodes.

 So, you may end by having different scancodes producing the same keycode, as 
 such applications
 aren't capable of differentiating an UP key from a CHANNELUP key. This is 
 the case, for example
 of the popular tvtime application.

 The better way is to just generate a dump file, modify the needed entries 
 and reload the
 table by calling EVIOSKEYCODE, in order to use the new table.

 I wrote a small application that just do the above, and I use to load some 
 special tables
 to work with some applications like tvtime and mplayer. (with mplayer, you 
 need to map 
 channel down as KEY_H and channel up as KEY_K).

 I hope that, after we finish addressing IR's, we'll finally have media 
 applications handling
 directly the proper keycodes, but people may still need to write different 
 keycodes to do
 other things. I used to have a keymap file in order to use an IR to control 
 the slide show
 with openoffice.

 Due to the current API limit, we don't have any way to use the full 64bits 
 space for scancodes.

 Can we probably reduce the scancode space? ARe all 64 bits in
 protocols used to represent keypresses or some are used for some kind of
 addressing?
 All the IR's I found with V4L/DVB use up to 16 bits code (or 24 bits, for 
 NEC extended protocol).
 However, currently, the drivers were getting only 7 bits, due to the old way 
 to implement
 EVIO[S|G]KEYCODE. 

 I know, however, one i2c chip that returns a 5 byte scancode when you press 
 a key. 
 We're currently just discarding the remaining bits, so I'm not really sure 
 what's there.


 The usage of 7 bits, in practice, were meaning that it weren't possible to 
 use
 a different remote than the one provided by the device manufacturer, as the 
 scancodes produced
 by other remotes differ on more than 7 bits. Also, this means that, if your 
 TV and your PC
 are using the same protocol, like RC5, if you press a button on your TV 
 remote, the PC will
 also get it.

 I know, however, one IR driver that produces 6 bytes when you press a key. 
 We're currently just discarding the remaining bits, so I'm not really sure
 what else is there. Some badly optimized protocol? a bigger scancode? a 
 protocol indication?

 In general, the scancode contains 8 or 16 bits for address, and 8 bits for 
 command.

 However, the scancode table needs to handle the address as well, since we 
 don't want that a
 scancode meant to go to your TV to be handled by the PC, but we may want to 
 get codes from
 different addresses there, as we may need to use the address to 
 differentiate the commands
 meant to control the TV volume, for example, than the same command meant to 
 control the PC
 master volume.
 
 Right, but this data is not interesting to

Re: [RFC] What are the goals for the architecture of an in-kernel IR system?

Jon Smirl wrote:
 On Sun, Dec 6, 2009 at 12:48 PM, Krzysztof Halasa k...@pm.waw.pl wrote:
 Once again: how about agreement about the LIRC interface
 (kernel-userspace) and merging the actual LIRC code first? 

That's fine for me.

 In-kernel
 decoding can wait a bit, it doesn't change any kernel-user interface.

This may occur in parallel, but, as we've been discussing, there are
still some needs there that will require kernel-user interfaces.

 I'd like to see a semi-complete design for an in-kernel IR system
 before anything is merged from any source.

There are some tasks there that are independent of any API design.

For example, I'm currently doing some cleanups and improvements 
at the existing IR in-kernel code to create a common IR core that replaces
the already existing feature of handling 7-bits scancode/keycode table to
use the complete scancodes found at the current in-kernel drivers.

This approach works for the current drivers, as none of them currently support
any protocol that requires more than 16 bits for scancodes. However, the
current EVIOGKEYCODE implementation won't scale with bigger scancode spaces.

This code is written to be generic enough to be used by V4L, DVB and LIRC
drivers. So, after having this work done, it should be easy to connect the 
lirc_dev
to a decoder and to this core support. There are already some in-kernel decoders
that can be used for some protocols, but the better is to review the decoders in
the light of lirc. I expect that the lirc decoders will be in a better shape.

While I'm here, I intend also to create the sysfs bits to create 
sys/class/irrcv,
as already discussed and submit the patch here for discussions.

Of course, after writing different API's to control the IR tables, we'll
need to improve it, but this depends on the results of the architecture 
discussions.

Cheers,
Mauro
--
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] What are the goals for the architecture of an in-kernel IR system?

On Mon, Dec 07, 2009 at 01:34:10PM -0200, Mauro Carvalho Chehab wrote:
  
  Scancodes in input system never been real scancodes. Even if you look
  into atkbd it uses some synthetic data composed out of real scancodes
  sent to the keyboard, and noone cares. If you are unsatisfied with
  mapping you fire up evtest, press the key, take whatever the driver
  [mis]represents as a scancode and use it to load the new definition. And
  you don't care at all whether the thing that driver calls cancode makes
  any sense to the hardware device.
 
 We used a mis-represented scancode, but this proofed to be a broken design
 along the time.
 
 For users, whatever the scancode cookie means, the same IR device should
 provide the same cookie no matter what IR receiver is used, since the same
 IR may be found on different devices, or the user can simply buy a new card
 and opt to use their old IR (there are very good reasons for that, since
 several new devices are now coming with small IR's that has half of the
 keys of the ones available at the older models).

OK, this is a fair point. We need to keep the scancodes stable across
receivers.

However I am not sure if the index approach is the best - it will not
work well if driver decides to implement the keymap using data structure
different from array, let's say linked list or a hash table. Lists by
their nature do not have a stable index and even if we were to generate
one on fly we could not rely on it for subsequent EVIOSKEYCODE: some
other program may cause insertion or deletion of an element making the
artificial index refer to another entry in the map.

While extending scancode size is pretty straightforward (well, almost
;) ) I am not sure what is the best way to enumerate keymap for a given
device.

-- 
Dmitry
--
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] What are the goals for the architecture of an in-kernel IR system?

On Sun, Dec 06, 2009 at 09:34:26PM +0100, Krzysztof Halasa wrote:
 Jon Smirl jonsm...@gmail.com writes:
 
  Once again: how about agreement about the LIRC interface
  (kernel-userspace) and merging the actual LIRC code first? In-kernel
  decoding can wait a bit, it doesn't change any kernel-user interface.
 
  I'd like to see a semi-complete design for an in-kernel IR system
  before anything is merged from any source.
 
 This is a way to nowhere, there is no logical dependency between LIRC
 and input layer IR.
 
 There is only one thing which needs attention before/when merging LIRC:
 the LIRC user-kernel interface. In-kernel IR system is irrelevant and,
 actually, making a correct IR core design without the LIRC merged can be
 only harder.

This sounds like merge first, think later...

The question is why we need to merge lirc interface right now, before we
agreed on the sybsystem architecture? Noone _in kernel_ user lirc-dev
yet and, looking at the way things are shaping, no drivers will be
_directly_ using it after it is complete. So, even if we merge it right
away, the code will have to be restructured and reworked. Unfortunately,
just merging what Jarod posted, will introduce sysfs hierarchy which
is userspace interface as well (although we not as good maintaining it
at times) and will add more constraints on us.

That is why I think we should go the other way around - introduce the
core which receivers could plug into and decoder framework and once it
is ready register lirc-dev as one of the available decoders.

-- 
Dmitry
--
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] What are the goals for the architecture of an in-kernel IR system?

2009-12-07 Thread Krzysztof Halasa

Dmitry Torokhov dmitry.torok...@gmail.com writes:

 There is only one thing which needs attention before/when merging LIRC:
 the LIRC user-kernel interface. In-kernel IR system is irrelevant and,
 actually, making a correct IR core design without the LIRC merged can be
 only harder.

 This sounds like merge first, think later...

I'd say merge the sane agreed and stable things first and think later
about improvements.

 The question is why we need to merge lirc interface right now, before we
 agreed on the sybsystem architecture?

Because we need the features and we can't improve something which is
outside the kernel. What subsystem architecture do you want to
discuss? Unrelated (input layer) interface?

Those are simple things. The only part which needs to be stable is the
(in this case LIRC) kernel-user interface.

 Noone _in kernel_ user lirc-dev
 yet and, looking at the way things are shaping, no drivers will be
 _directly_ using it after it is complete. So, even if we merge it right
 away, the code will have to be restructured and reworked.

Sure. We do this constantly to every part of the kernel.

 Unfortunately,
 just merging what Jarod posted, will introduce sysfs hierarchy which
 is userspace interface as well (although we not as good maintaining it
 at times) and will add more constraints on us.

Then perhaps it should be skipped, leaving only the things udev needs to
create /dev/ entries. They don't have to be particularly stable.
Perhaps it should go to the staging first. We can't work with the code
outside the kernel, staging has not such limitation.

 That is why I think we should go the other way around - introduce the
 core which receivers could plug into and decoder framework and once it
 is ready register lirc-dev as one of the available decoders.

That means all the work has to be kept and then merged atomically,
it seems there is a lack of manpower for this.
-- 
Krzysztof Halasa
--
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] What are the goals for the architecture of an in-kernel IR system?

On Mon, Dec 07, 2009 at 09:08:57PM +0100, Krzysztof Halasa wrote:
 Dmitry Torokhov dmitry.torok...@gmail.com writes:
 
  There is only one thing which needs attention before/when merging LIRC:
  the LIRC user-kernel interface. In-kernel IR system is irrelevant and,
  actually, making a correct IR core design without the LIRC merged can be
  only harder.
 
  This sounds like merge first, think later...
 
 I'd say merge the sane agreed and stable things first and think later
 about improvements.
 
  The question is why we need to merge lirc interface right now, before we
  agreed on the sybsystem architecture?
 
 Because we need the features and we can't improve something which is
 outside the kernel. What subsystem architecture do you want to
 discuss? Unrelated (input layer) interface?


No, the IR core responsible for registering receivers and decoders.

 Those are simple things. The only part which needs to be stable is the
 (in this case LIRC) kernel-user interface.

For which some questions are still open. I believe Jon just oulined some
of them.

 
  Noone _in kernel_ user lirc-dev
  yet and, looking at the way things are shaping, no drivers will be
  _directly_ using it after it is complete. So, even if we merge it right
  away, the code will have to be restructured and reworked.
 
 Sure. We do this constantly to every part of the kernel.

No we do not. We do not merge something that we expect to rework almost
completely (no, not the lirc-style device userspace inetrface, although
even it is not completely finalized I believe, but the rest of the
subsystem).

 
  Unfortunately,
  just merging what Jarod posted, will introduce sysfs hierarchy which
  is userspace interface as well (although we not as good maintaining it
  at times) and will add more constraints on us.
 
 Then perhaps it should be skipped, leaving only the things udev needs to
 create /dev/ entries. They don't have to be particularly stable.
 Perhaps it should go to the staging first. We can't work with the code
 outside the kernel, staging has not such limitation.

OK, say we add this to staging as is. What is next? Who will be using
this code that is now in staging? Do we encougrage driver's writers to
hook into it (given that we intend on redoing it soon)? Do something
else?

 
  That is why I think we should go the other way around - introduce the
  core which receivers could plug into and decoder framework and once it
  is ready register lirc-dev as one of the available decoders.
 
 That means all the work has to be kept and then merged atomically,
 it seems there is a lack of manpower for this.

No, not at all. You merge core subsystem code, then start addig
decoders... In the meantime driver-writers could start preparing their
drivers to plug into it.

In the mean time out-of-tree LIRC can be used by consumers undisturbed.

-- 
Dmitry
--
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] What are the goals for the architecture of an in-kernel IR system?

Dmitry Torokhov wrote:
On Mon, Dec 07, 2009 at 01:34:10PM -0200, Mauro Carvalho Chehab wrote:

Scancodes in input system never been real scancodes. Even if you look
into atkbd it uses some synthetic data composed out of real scancodes
sent to the keyboard, and noone cares. If you are unsatisfied with
mapping you fire up evtest, press the key, take whatever the driver
[mis]represents as a scancode and use it to load the new definition. And
you don't care at all whether the thing that driver calls cancode makes
any sense to the hardware device.
We used a mis-represented scancode, but this proofed to be a broken design
along the time.

For users, whatever the scancode cookie means, the same IR device should
provide the same cookie no matter what IR receiver is used, since the same
IR may be found on different devices, or the user can simply buy a new card
and opt to use their old IR (there are very good reasons for that, since
several new devices are now coming with small IR's that has half of the
keys of the ones available at the older models).

OK, this is a fair point. We need to keep the scancodes stable across
receivers.

However I am not sure if the index approach is the best - it will not
work well if driver decides to implement the keymap using data structure
different from array, let's say linked list or a hash table. Lists by
their nature do not have a stable index and even if we were to generate
one on fly we could not rely on it for subsequent EVIOSKEYCODE: some
other program may cause insertion or deletion of an element making the
artificial index refer to another entry in the map.

Any addition/deletion of an element will cause problems, even with a simple
table. I don't think we should consider a case where two applications are
changing the table at the same time. The end result will likely be different
than what's expected anyway. Btw, while an index for EVIOGSKEYCODE is really
important, except for symmetry, there are no other reasons why we can't use
scancode as the primary key for EVIOSKEYCODE. We can't allow two identical
scancodes anyway at the scancode/keycode table. So, we can define the
EVIOSKEYCODE without an index.

While extending scancode size is pretty straightforward (well, almost
;) ) I am not sure what is the best way to enumerate keymap for a given
device.

Btw, if you want to take a look, I've finished to implement the table
insert/delete
logic. Extending/reducing space at the table required some care, but it is
working
fine:

http://git.kernel.org/?p=linux/kernel/git/mchehab/linux-next.git;a=commitdiff;h=87d73cbd33235b162e8da62305ba8b5926a1fbf8

The code is not optimized by using a hash table or a binary search yet (patches
to
improve are welcome), but it is already working as expected.

Cheers,
Mauro.
--
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] What are the goals for the architecture of an in-kernel IR system?

Emmanuel Fusté wrote:
 Mauro Carvalho Chehab wrote:
 
 In summary,

 While the current EVIO[G|S]KEYCODE works sub-optimally for scancodes
 up to 16 bytes
 (since a read loop for 2^16 is not that expensive), the current approach
 won't scale with bigger scancode spaces. So, it is needed expand it
 to work with bigger scancode spaces, used by more recent IR protocols.

 I'm afraid that any tricks we may try to go around the current limits
 to still
 keep using the same ioctl definition will sooner or later cause big
 headaches.
 The better is to redesign it to allow using different scancode spaces.


   
 I second you: input layer events from drivers should be augmented with a
 protocol member,

Yeah, I added the protocol type info inside the internal representation of
the IR table. As I managed to do all the work inside one file (ir-keytable.c),
changing it to use arbitrary sized scancode lengths will be trivial (currently,
it is u16 just because just because it currently enough for the in-kernel 
drivers,
but this will be changed when integrating with lirc):

http://linuxtv.org/hg/v4l-dvb/rev/7b983cd30f0f

 allowing us to define new ioctl and new ways to
 efficiently store and manage sparse scancode spaces (tree, hashtable
 ). It will allow us to abstract the scancode value and to use
 variable length scancode depending on the used protocol, and using the
 most appropriate scheme to store the scancode/keycode mapping per protocol.

True.

 The today scancode space will be the legacy one, the default if not
 specified protocol. It will permit to progressively clean up the
 actual acceptable mess in the input layer and finally using real
 scancode - keycode mappings everywhere if it is cleaner/convenient.

Yes. By purpose, I added IR_TYPE_UNKNOWN as 0. This way, all tables that don't
specify a protocol can be considered legacy.

Cheers,
Mauro.
--
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] What are the goals for the architecture of an in-kernel IR system?

Let me add my view for those questions.

Jon Smirl wrote:
 On Sun, Dec 6, 2009 at 3:34 PM, Krzysztof Halasa k...@pm.waw.pl wrote:
 Jon Smirl jonsm...@gmail.com writes:

 Once again: how about agreement about the LIRC interface
 (kernel-userspace) and merging the actual LIRC code first? In-kernel
 decoding can wait a bit, it doesn't change any kernel-user interface.
 I'd like to see a semi-complete design for an in-kernel IR system
 before anything is merged from any source.
 This is a way to nowhere, there is no logical dependency between LIRC
 and input layer IR.

 There is only one thing which needs attention before/when merging LIRC:
 the LIRC user-kernel interface. In-kernel IR system is irrelevant and,
 actually, making a correct IR core design without the LIRC merged can be
 only harder.
 
 Here's a few design review questions on the LIRC drivers that were posted
 
 How is the pulse data going to be communicated to user space?

lirc_dev will implement a revised version of the lirc API. I'm assuming that
Jerod and Christoph will do this review, in order to be sure that it is stable
enough for kernel inclusion (as proposed by Gerd).

 Can the pulse data be reported via an existing interface without
 creating a new one?

Raw pulse data should be reported only via lirc_dev, but it can be converted
into a keycode and reported via evdev as well, via an existing interface.

 Where is the documentation for the protocol?

I'm not sure what you're meaning here. I've started a doc about IR at the media
docbook. This is currently inside the kernel Documents/DocBook. If you want
to browse, it is also available as:

http://linuxtv.org/downloads/v4l-dvb-apis/ch17.html

For sure we need to better document the IR's, and explain the API's there.

 Is it a device interface or something else?

lirc_dev should create a device interface.

 What about capabilities of the receiver, what frequencies?
 If a receiver has multiple frequencies, how do you report what
 frequency the data came in on?

IMO, via sysfs.

 What about multiple apps simultaneously using the pulse data?

IMO, the better is to limit the raw interface to just one open.

 How big is the receive queue?

It should be big enough to receive at least one keycode event. Considering that
the driver will use kfifo (IMO, it is a good strategy, especially since you
won't need any lock if just one open is allowed), it will require a power of 
two size.

 How does access work, root only or any user?

IMO, it should be the same requirement as used by an input interface.

 How are capabilities exposed, sysfs, etc?

IMO, sysfs.

 What is the interface for attaching an in-kernel decoder?

IMO, it should use the kfifo for it. However, if we allow both raw data and
in-kernel decoders to read data there, we'll need a spinlock to protect the
kfifo.

 If there is an in-kernel decoder should the pulse data stop being
 reported, partially stopped, something else?

I don't have a strong opinion here, but, from the previous discussions, it
seems that people want it to be double-reported by default. If so, I think
we need to implement a command at the raw interface to allow disabling the
in-kernel decoder, while the raw interface is kept open.

 What is the mechanism to make sure both system don't process the same pulses?

I don't see a good way to avoid it.

 Does it work with poll, epoll, etc?
 What is the time standard for the data, where does it come from?
 How do you define the start and stop of sequences?
 Is receiving synchronous or queued?
 What about transmit, how do you get pulse data into the device?
 Transmitter frequencies?
 Multiple transmitters?
 Is transmitting synchronous or queued?
 How big is the transmit queue?

I don't have a clear answer for those. I'll let those to LIRC developers to 
answer.


Cheers,
Mauro


--
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] What are the goals for the architecture of an in-kernel IR system?

Christoph Bartelmus wrote:
 Hi Jon,
 
 on 04 Dec 09 at 19:28, Jon Smirl wrote:
 BTW, I just came across a XMP remote that seems to generate 3x64 bit
 scan codes. Anyone here has docs on the XMP protocol?
 Assuming a general purpose receiver (not one with fixed hardware
 decoding), is it important for Linux to receive IR signals from all
 possible remotes no matter how old or obscure? Or is it acceptable to
 [...]
 Of course transmitting is a completely different problem, but we
 haven't been talking about transmitting. I can see how we would need
 to record any IR protocol in order to retransmit it. But that's in the
 5% of users world, not the 90% that want MythTV to just work.  Use
 something like LIRC if you want to transmit.
 
 I don't think anyone here is in the position to be able to tell what is  
 90% or 5%.

True. Yet, cases like IR devices made by someone's own use is something
that we don't need to care to have an in-kernel driver.

 Personally I use LIRC exclusively for transmit to my settop box  
 using an old and obscure RECS80 protocol.
 No, I won't replace my setup just because it's old and obscure.
 
 Cable companies tend to provide XMP based boxes to subscribers more often  
 these days. Simply not supporting these setups is a no-go for me.

I don't see any reason why not supporting STB protocols. Several such
hardware use Linux, anyway. So, eventually the STB manufacturers may send
us decoders that work with their IR's.

Cheers,
Mauro.



--
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] What are the goals for the architecture of an in-kernel IR system?

Krzysztof Halasa wrote:
 Mauro Carvalho Chehab mche...@redhat.com writes:
 

 struct input_keytable_entry {
  u16 index;
  u64 scancode;
  u32 keycode;
 } __attribute__ ((packed));

 (the attribute packed avoids needing a compat for 64 bits)
 
 Maybe { u64 scancode; u32 keycode; u16 index; u16 reserved } would be a
 bit better, no alignment problems and we could eventually change
 reserved into something useful.
 
 But I think, if we are going to redesign it, we better use scancodes of
 arbitrary length (e.g. protocol-dependent length). It should be opaque
 except for the protocol handler.

Yes, an opaque type for scancode at the userspace API can be better, but
passing a pointer to kernel will require some compat32 logic (as pointer
size is different on 32 and 64 bits).

We may use something like an u8[] with an arbitrary large number of bytes.
In this case, we need to take some care to avoid LSB/MSB troubles.

Cheers,
Mauro.
--
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] What are the goals for the architecture of an in-kernel IR system?

2009-12-07 Thread Jon Smirl

On Mon, Dec 7, 2009 at 6:44 PM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
 Let me add my view for those questions.

 Jon Smirl wrote:
 On Sun, Dec 6, 2009 at 3:34 PM, Krzysztof Halasa k...@pm.waw.pl wrote:
 Jon Smirl jonsm...@gmail.com writes:

 Once again: how about agreement about the LIRC interface
 (kernel-userspace) and merging the actual LIRC code first? In-kernel
 decoding can wait a bit, it doesn't change any kernel-user interface.
 I'd like to see a semi-complete design for an in-kernel IR system
 before anything is merged from any source.
 This is a way to nowhere, there is no logical dependency between LIRC
 and input layer IR.

 There is only one thing which needs attention before/when merging LIRC:
 the LIRC user-kernel interface. In-kernel IR system is irrelevant and,
 actually, making a correct IR core design without the LIRC merged can be
 only harder.

 Here's a few design review questions on the LIRC drivers that were posted

 How is the pulse data going to be communicated to user space?

 lirc_dev will implement a revised version of the lirc API. I'm assuming that
 Jarod and Christoph will do this review, in order to be sure that it is stable
 enough for kernel inclusion (as proposed by Gerd).

 Can the pulse data be reported via an existing interface without
 creating a new one?

 Raw pulse data should be reported only via lirc_dev, but it can be converted
 into a keycode and reported via evdev as well, via an existing interface.

 Where is the documentation for the protocol?

 I'm not sure what you're meaning here. I've started a doc about IR at the 
 media

What is the format of the pulse stream data coming out of the lirc device?

 docbook. This is currently inside the kernel Documents/DocBook. If you want
 to browse, it is also available as:

        http://linuxtv.org/downloads/v4l-dvb-apis/ch17.html

 For sure we need to better document the IR's, and explain the API's there.

 Is it a device interface or something else?

 lirc_dev should create a device interface.

 What about capabilities of the receiver, what frequencies?
 If a receiver has multiple frequencies, how do you report what
 frequency the data came in on?

 IMO, via sysfs.

Say you have a hardware device with two IR diodes, one at 38K and one
at 56K. Both of these receivers can get pulses. How do we tell the
user space app which frequency the pulses were received on? Seems to
me like there has to be a header on the pulse data indicating the
received carrier frequency. There is also baseband signaling. sysfs
won't work for this because of the queuing latency.

How is over-run signaled to the app? You'd get an over-run if the app
is too slow at reading the data out of the FIFO. If you ignore
over-run you'll be processing bad data because part of the message was
lost. An over-run signal tell the abort to abort the signal and start
over.

 What about multiple apps simultaneously using the pulse data?

 IMO, the better is to limit the raw interface to just one open.

 How big is the receive queue?

 It should be big enough to receive at least one keycode event. Considering 
 that
 the driver will use kfifo (IMO, it is a good strategy, especially since you
 won't need any lock if just one open is allowed), it will require a power of 
 two size.

How is end of a pulse train detected? timeout? without decoding the
protocol there is no way to tell the end of signal other than timeout.


 How does access work, root only or any user?

 IMO, it should be the same requirement as used by an input interface.

 How are capabilities exposed, sysfs, etc?

 IMO, sysfs.

 What is the interface for attaching an in-kernel decoder?

 IMO, it should use the kfifo for it. However, if we allow both raw data and
 in-kernel decoders to read data there, we'll need a spinlock to protect the
 kfifo.

 If there is an in-kernel decoder should the pulse data stop being
 reported, partially stopped, something else?

 I don't have a strong opinion here, but, from the previous discussions, it
 seems that people want it to be double-reported by default. If so, I think
 we need to implement a command at the raw interface to allow disabling the
 in-kernel decoder, while the raw interface is kept open.

Data could be sent to the in-kernel decoders first and then if they
don't handle it, send it to user space.



 What is the mechanism to make sure both system don't process the same pulses?

 I don't see a good way to avoid it.

 Does it work with poll, epoll, etc?
 What is the time standard for the data, where does it come from?
 How do you define the start and stop of sequences?
 Is receiving synchronous or queued?
 What about transmit, how do you get pulse data into the device?
 Transmitter frequencies?
 Multiple transmitters?
 Is transmitting synchronous or queued?
 How big is the transmit queue?

 I don't have a clear answer for those. I'll let those to LIRC developers to 
 answer.


 Cheers,
 Mauro






-- 
Jon Smirl
jonsm...@gmail.com
--
To

Re: [RFC] What are the goals for the architecture of an in-kernel IR system?

2009-12-07 Thread Jon Smirl

On Mon, Dec 7, 2009 at 1:41 PM, Dmitry Torokhov
dmitry.torok...@gmail.com wrote:
 That is why I think we should go the other way around - introduce the
 core which receivers could plug into and decoder framework and once it
 is ready register lirc-dev as one of the available decoders.

The core needs to allow for RF remotes too.

-Bluetooth remotes are already in kernel somehow, I don't know how they work,
-RF4CE, the 802.15.4 stack has been recently merged, the remotes use a
protocol on top of that. These remotes will hit the consumer market
next year. Sony, Panasonic and other big names are behind this.
-Zwave, the Harmony remotes use Zwave. There is no Zwave support in
the kernel that I am aware of. Zwave is proprietary.

After these protocols are decoded you end up with scancodes. The
scancodes need to get injected into input somehow and then flow
through the mapping process. Decoding down to the scancodes probably
happens over in the networking code.

After an in-kernel IR decoder runs it needs to hand off the scancodes
into the input subsystem. This same API can be used by the networking
code to hand off RF scancodes.

-- 
Jon Smirl
jonsm...@gmail.com
--
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] What are the goals for the architecture of an in-kernel IR system?

2009-12-07 Thread Andy Walls

On Sun, 2009-12-06 at 16:23 -0500, Jon Smirl wrote:
 On Sun, Dec 6, 2009 at 3:34 PM, Krzysztof Halasa k...@pm.waw.pl wrote:
  Jon Smirl jonsm...@gmail.com writes:
 
  Once again: how about agreement about the LIRC interface
  (kernel-userspace) and merging the actual LIRC code first? In-kernel
  decoding can wait a bit, it doesn't change any kernel-user interface.
 
  I'd like to see a semi-complete design for an in-kernel IR system
  before anything is merged from any source.
 
  This is a way to nowhere, there is no logical dependency between LIRC
  and input layer IR.
 
  There is only one thing which needs attention before/when merging LIRC:
  the LIRC user-kernel interface. In-kernel IR system is irrelevant and,
  actually, making a correct IR core design without the LIRC merged can be
  only harder.
 
 Here's a few design review questions on the LIRC drivers that were posted

I will answer based on my understanding of LIRC as it exists today, but
I'm tired and am not going to dig into too many details I can't find
easily.

(Christoph can correct me if I get anything wrong.)


An architecture drawing can be found here:

http://www.lirc.org/html/technical.html

 How is the pulse data going to be communicated to user space?

Currently that is via lirc_dev which shows up as /dev/lircN (IIRC) in
userspace.

The lirc_dev module is a helper and abstraction layer for other
modules. It registers /dev/lirc device in a system (including support
for devfs) and waits for plugin registration. After that it serves
device requests (open, read, poll, ioctl, close) and if needed calls
callback functions from plugin(s) to communicate with the physical
device.

The function call for hardware drivers to register with lirc_dev from
within kernel space is lirc_register_driver() which requires a structure
with points to hardware specifi operations, IIRC.


 Can the pulse data be reported via an existing interface without
 creating a new one?

Yes.


 Where is the documentation for the protocol?

http://www.lirc.org/html/technical.html


 Is it a device interface or something else?

Device for a kernelspace driver/plugin registering with lirc_dev.


 Does it work with poll, epoll, etc?

lirc_dev has an function irctl_poll() that will call a hardware specifi
poll operation if it exists, otherwise it has default poll logic.


 What is the time standard for the data, where does it come from?

I think it is usec, IIRC.

I know that the hardware I work with has sub 100 ns resolution, so
that's what is used as the basis for v4l2_subdev_ir_ops time values in
kernel.  The conversion to usec is rather trivial.

The hardware I work with is very configurable, but I always use the
BT.656 video pixel clock of of 13.5 MHz * 8 = 108 MHz as the master
frequency reference for all the pulse width measurement circuitry.


 How do you define the start and stop of sequences?

For the end of Rx signalling:

Well with the Conexant hardware I can set a maximum pulse (mark or
space) width, and the hardware will generate an Rx Timeout interrupt to
signal the end of Rx when a space ends up longer than that max pulse
width.  The hardware also puts a special marker in the hardware pulse
widht measurement FIFO (in band signalling essentially).

I'm not sure anything like that gets communicated to userspace via
lirc_dev, and I'm too tired to doublecheck right now.

If you have determined the protocol you are after, it's easy to know
what the pulse count should be and what the max pulse width should be (+
slop for crappy hardware) so finding the end of an Rx isn't hard.  The
button repeats intervals are *very* large.  I've never seen a remote
rapid fire codes back to back.


For the start of a sequence:

Easy, the first mark after a *very* long (10's of msec) space.
You could also look for very long mark header which many protocols (NEC,
RC-6, ...) have to help the IR hardware's AGC get set.


 What about capabilities of the receiver, what frequencies?

LIRC's API has a LIRC_GET_FEATURES ioctl().


 If a receiver has multiple frequencies, how do you report what
 frequency the data came in on?

I'm not sure most hardware can pick up a pulse on an arbitrary freq.
Usually you set a desired carrier and a window.  The windows can be very
generous on some hardware: Fc * 16/20 to Fc * 16/12 (e.g. for 38 kHz
that's 30.4 kHz to 50.667 kHz). 

Hardware can have a special learn mode to really make fine
measurements about the waveform without a specified carrier, but usually
requires some special setup and the user being prompted to take action
to get a good measurement.


 What about multiple apps simultaneously using the pulse data?

LIRC multiplexes a single device node with a daemon in userspace.


 Is receiving synchronous or queued?

kfifo's in lirc_dev IIRC.


 How big is the receive queue?

Device HW FIFO's can have a depth of 1 to 16.

My software queues for CX2388[58] devices are 512 pulse measurments deep
--  overkill except for maybe a protocol with a

Re: [RFC] What are the goals for the architecture of an in-kernel IR system?

On Mon, Dec 07, 2009 at 09:44:14PM -0200, Mauro Carvalho Chehab wrote:
 Let me add my view for those questions.
 
 Jon Smirl wrote:
  On Sun, Dec 6, 2009 at 3:34 PM, Krzysztof Halasa k...@pm.waw.pl wrote:
  Jon Smirl jonsm...@gmail.com writes:
 
  Once again: how about agreement about the LIRC interface
  (kernel-userspace) and merging the actual LIRC code first? In-kernel
  decoding can wait a bit, it doesn't change any kernel-user interface.
  I'd like to see a semi-complete design for an in-kernel IR system
  before anything is merged from any source.
  This is a way to nowhere, there is no logical dependency between LIRC
  and input layer IR.
 
  There is only one thing which needs attention before/when merging LIRC:
  the LIRC user-kernel interface. In-kernel IR system is irrelevant and,
  actually, making a correct IR core design without the LIRC merged can be
  only harder.
  
  Here's a few design review questions on the LIRC drivers that were 
  posted
  
  How is the pulse data going to be communicated to user space?
 
 lirc_dev will implement a revised version of the lirc API. I'm assuming that
 Jerod and Christoph will do this review, in order to be sure that it is stable
 enough for kernel inclusion (as proposed by Gerd).
 
  Can the pulse data be reported via an existing interface without
  creating a new one?
 
 Raw pulse data should be reported only via lirc_dev, but it can be converted
 into a keycode and reported via evdev as well, via an existing interface.
 
  Where is the documentation for the protocol?
 
 I'm not sure what you're meaning here. I've started a doc about IR at the 
 media
 docbook. This is currently inside the kernel Documents/DocBook. If you want
 to browse, it is also available as:
 
   http://linuxtv.org/downloads/v4l-dvb-apis/ch17.html
 
 For sure we need to better document the IR's, and explain the API's there.
 
  Is it a device interface or something else?
 
 lirc_dev should create a device interface.
 
  What about capabilities of the receiver, what frequencies?
  If a receiver has multiple frequencies, how do you report what
  frequency the data came in on?
 
 IMO, via sysfs.

We probably need to think what exactly we report through sysfs siunce it
is ABI of sorts.

 
  What about multiple apps simultaneously using the pulse data?
 
 IMO, the better is to limit the raw interface to just one open.
 

Why woudl we want to do this? Quite often there is a need for observer
that maybe does not act on data but allows capturing it. Single-user
inetrfaces are PITA. 

  How big is the receive queue?
 
 It should be big enough to receive at least one keycode event. Considering 
 that
 the driver will use kfifo (IMO, it is a good strategy, especially since you
 won't need any lock if just one open is allowed), it will require a power of 
 two size.
 

Would not it be wither driver- or protocol-specific?

  How does access work, root only or any user?
 
 IMO, it should be the same requirement as used by an input interface.
 
  How are capabilities exposed, sysfs, etc?
 
 IMO, sysfs.
 
  What is the interface for attaching an in-kernel decoder?
 
 IMO, it should use the kfifo for it. However, if we allow both raw data and
 in-kernel decoders to read data there, we'll need a spinlock to protect the
 kfifo.
 

I think Jon meant userspace interface for attaching particular decoder.

  If there is an in-kernel decoder should the pulse data stop being
  reported, partially stopped, something else?
 
 I don't have a strong opinion here, but, from the previous discussions, it
 seems that people want it to be double-reported by default. If so, I think
 we need to implement a command at the raw interface to allow disabling the
 in-kernel decoder, while the raw interface is kept open.

Why don't you simply let consumers decide where they will get their data?

 
  What is the mechanism to make sure both system don't process the same 
  pulses?
 
 I don't see a good way to avoid it.
 
  Does it work with poll, epoll, etc?
  What is the time standard for the data, where does it come from?
  How do you define the start and stop of sequences?
  Is receiving synchronous or queued?
  What about transmit, how do you get pulse data into the device?
  Transmitter frequencies?
  Multiple transmitters?
  Is transmitting synchronous or queued?
  How big is the transmit queue?
 
 I don't have a clear answer for those. I'll let those to LIRC developers to 
 answer.
 

-- 
Dmitry
--
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] What are the goals for the architecture of an in-kernel IR system?

2009-12-06 Thread Mauro Carvalho Chehab

Dmitry Torokhov wrote:
 On Fri, Dec 04, 2009 at 12:12:34PM -0200, Mauro Carvalho Chehab wrote:
 Em Fri, 4 Dec 2009 02:06:42 -0800
 Dmitry Torokhov dmitry.torok...@gmail.com escreveu:

 evdev does not really care what you use as scancode. So nobody stops
 your driver to report index as a scancode and accept index from the
 ioctl. The true scancode will thus be competely hidden from userspace.
 In fact a few drivers do just that.
 Let me better express here. It is all about how we'll expand the limits of 
 those
 ioctls to fulfill the needs.

 The point is that we'll have, let's say something like to 50-500 
 scancode/keycode tuples
 sparsely spread into a 2^64 scancode universe (assuming 64 bits - Not sure 
 if is there any
 IR protocol/code with a bigger scancode).

 On such universe if we want to get all keycodes with the current ioctls for 
 a scancode in
 the range of 32 bits, we need to do something like:

 u32 code;
 int codes[2];
 for (code = 0; code = (unsigned u32) - 1; code++) {
  codes[0] = (int)code;
  if (!ioctl(fd, EVIOCGKEYCODE, codes))
  printf(scancode 0x%08x = keycode 0x%08x\n, codes[0], 
 codes[1]);
 }

 So, on the 32 bits case, we'll do about 4 billions calls to EVIOGKEYCODE 
 ioctl to
 read the complete scancode space, to get those 50-500 useful codes.

 
 Right, currently there is no need to query all scancodes defined by
 device. Quite often drivers don't even know what scancodes device
 actually generates (ex AT keyboard).
 
 Could you describe in more detail how you are using this data?

It is useful if you want to dump the keycode maps into file with the current
scancode attribution, in order to modify some keystrokes.

Right now, programs like dumpkeys (from kbd package) allow you to dump for 
example
the attribution keys from your keyboard.

In the case of IR's this functionality is very important.

For example, you may need to replace the scancode/KEY_CHANNELUP tuple by 
scancode/KEY_UP,
in order to make your IR to work with some applications that don't recognize 
the IR
specific keycodes.

In practice, with such applications, you'll need to replace several different 
scancodes.

So, you may end by having different scancodes producing the same keycode, as 
such applications
aren't capable of differentiating an UP key from a CHANNELUP key. This is the 
case, for example
of the popular tvtime application.

The better way is to just generate a dump file, modify the needed entries and 
reload the
table by calling EVIOSKEYCODE, in order to use the new table.

I wrote a small application that just do the above, and I use to load some 
special tables
to work with some applications like tvtime and mplayer. (with mplayer, you need 
to map 
channel down as KEY_H and channel up as KEY_K).

I hope that, after we finish addressing IR's, we'll finally have media 
applications handling
directly the proper keycodes, but people may still need to write different 
keycodes to do
other things. I used to have a keymap file in order to use an IR to control the 
slide show
with openoffice.

 Due to the current API limit, we don't have any way to use the full 64bits 
 space for scancodes.

 
 Can we probably reduce the scancode space? ARe all 64 bits in
 protocols used to represent keypresses or some are used for some kind of
 addressing?

All the IR's I found with V4L/DVB use up to 16 bits code (or 24 bits, for NEC 
extended protocol).
However, currently, the drivers were getting only 7 bits, due to the old way to 
implement
EVIO[S|G]KEYCODE. 

I know, however, one i2c chip that returns a 5 byte scancode when you press a 
key. 
We're currently just discarding the remaining bits, so I'm not really sure 
what's there.


The usage of 7 bits, in practice, were meaning that it weren't possible to use
a different remote than the one provided by the device manufacturer, as the 
scancodes produced
by other remotes differ on more than 7 bits. Also, this means that, if your TV 
and your PC
are using the same protocol, like RC5, if you press a button on your TV remote, 
the PC will
also get it.

I know, however, one IR driver that produces 6 bytes when you press a key. 
We're currently just discarding the remaining bits, so I'm not really sure
what else is there. Some badly optimized protocol? a bigger scancode? a 
protocol indication?

In general, the scancode contains 8 or 16 bits for address, and 8 bits for 
command.

However, the scancode table needs to handle the address as well, since we don't 
want that a
scancode meant to go to your TV to be handled by the PC, but we may want to get 
codes from
different addresses there, as we may need to use the address to differentiate 
the commands
meant to control the TV volume, for example, than the same command meant to 
control the PC
master volume.

 if we use code[0] as an index, this means that we'll need to share the 32 
 bits on code[1]
 for scancode/keycode. Even using an 32 bits integer for keycode, it is 
 currently limited to:

Re: [RFC] What are the goals for the architecture of an in-kernel IR system?

2009-12-06 Thread Mauro Carvalho Chehab

Dmitry Torokhov wrote:
 On Fri, Dec 04, 2009 at 12:12:34PM -0200, Mauro Carvalho Chehab wrote:
 How related lirc-core to the current lirc code? If it is not the same
 maybe we should not call it lirc to avoid confusion.
 Just for better illustrate what I'm seeing, I broke the IR generic
 code into two components:

  lirc core - the module that receives raw pulse/space and creates
  a device to receive raw API pulse/space events;

  IR core - the module that receives scancodes, convert them into
keycodes and send via evdev interface.

 We may change latter the nomenclature, but I'm seeing the core as two 
 different
 modules, since there are cases where lirc core won't be used (those
 devices were there's no way to get pulse/space events).

 
 OK, I think we are close but not exactly close. I believe that what you
 call lirc core will be used always - it is the code that create3s class
 devices, connectes decorers with the data streams, etc. I believe it
 will be utilized even in case of devices using hardware decoders. That
 is why we should probably stop calling it lirc core just tso we don't
 confuse it with original lirc.
 
 Then we have decoders and lirc_dev - which implements original lirc
 interface (or maybe its modified version) and allows lircd to continue
 working.
 
 Lastly we have what you call IR core which is IR-to-input bridge of
 sorts.

It seems to be just nomenclacure ;)

what I called IR core you called lirc core
what I called lirc core you called lirc_dev

What I called IR core is the one that will be used by every IR driver, handling
sysfs, evdev's, calling decoders, etc.

I opted to use the nomenclature Lirc to the part of the IR subsystem that
will create the Lirc interface.

Currently, I almost finished the evdev part of the IR core, using the current
API to control the dynamic keycode allocation. It is already working fine with
V4L drivers.

Cheers,
Mauro.
--
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] What are the goals for the architecture of an in-kernel IR system?

2009-12-06 Thread Mauro Carvalho Chehab

Dmitry Torokhov wrote:
 Hi,
 
 On Sun, Dec 06, 2009 at 04:36:33AM +0100, hermann pitton wrote:
 Hi,

 Am Freitag, den 04.12.2009, 19:28 -0500 schrieb Jon Smirl:
 On Fri, Dec 4, 2009 at 6:01 PM, Christoph Bartelmus l...@bartelmus.de 
 wrote:
 BTW, I just came across a XMP remote that seems to generate 3x64 bit scan
 codes. Anyone here has docs on the XMP protocol?
 Assuming a general purpose receiver (not one with fixed hardware
 decoding), is it important for Linux to receive IR signals from all
 possible remotes no matter how old or obscure? Or is it acceptable to
 tell the user to throw away their dedicated remote and buy a universal
 multi-function one?  Universal multi-function remotes are $12 in my
 grocery store - I don't even have to go to an electronics store.
 finally we have some point here, IMHO, that is not acceptable and I told
 you previously not to bet on such. Start some poll and win it, and I'll
 shut up :)

 
 Who would participate in the poll though?
 
 To be frank, you are quite mad at this point, or deliver working other
 remotes to __all__ for free.

 
 I do not believe you are being realistic. Sometimes we just need to say
 that the device is a POS and is just not worth it. Remember, there is
 still lirc hole for the hard core people still using solder to produce
 something out of the spare electronic components that may be made to
 work (never mind that it causes the CPU constantly poll the device, not
 letting it sleep and wasting electricity as a result - just hypotetical
 example here).
 
 We still need to do cost-benefit analysis and decide whether supporting
 the exotic setups _in kernel_ makes sense if it encumbers implementation
 and causes issues to the other 95% people.

Fully agreed. The costs (our time) to add and keep supporting an in-kernel
driver for an IR that just one person is still using is higher than 
asking the user to get a new IR. This time would be better spent adding a new
driver for other devices.

Cheers,
Mauro.


--
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] What are the goals for the architecture of an in-kernel IR system?

2009-12-06 Thread Christoph Bartelmus

Hi Dmitry,

on 05 Dec 09 at 22:55, Dmitry Torokhov wrote:
[...]
 I do not believe you are being realistic. Sometimes we just need to say
 that the device is a POS and is just not worth it. Remember, there is
 still lirc hole for the hard core people still using solder to produce
 something out of the spare electronic components that may be made to
 work (never mind that it causes the CPU constantly poll the device, not
 letting it sleep and wasting electricity as a result - just hypotetical
 example here).

The still seems to be is a persistent misconception that the home-brewn  
receivers need polling or cause heavy CPU load. No they don't. All of them  
are IRQ based.
It's the commercial solutions like gpio based IR that need polling.
For transmitters it's a different story, but you don't transmit 24h/7.

Christoph
--
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] What are the goals for the architecture of an in-kernel IR system?

2009-12-06 Thread Christoph Bartelmus

Hi Dmitry,

on 04 Dec 09 at 15:15, Dmitry Torokhov wrote:
[...]
 http://lirc.sourceforge.net/remotes/lg/6711A20015N

 This is an air-conditioner remote.
 The entries that you see in this config file are not really separate
 buttons. Instead the remote just sends the current settings for e.g.
 temperature encoded in the protocol when you press some up/down key.
 You really don't want to map all possible temperature settings to KEY_*
 events. For such cases it would be nice to have access at the raw scan
 codes from user space to do interpretation of the data.
 The default would still be to pass the data to the input layer, but it
 won't hurt to have the possibility to access the raw data somehow.

 Interesting. IMHO, the better would be to add an evdev ioctl to return
 the scancode for such cases, instead of returning the keycode.

 That means you would have to set up a pseudo keymap, so that you can get
 the key event which you could than react on with a ioctl. Or are you
 generating KEY_UNKNOWN for every scancode that is not mapped?
 What if different scan codes are mapped to the same key event? How do you
 retrieve the scan code for the key event?
 I don't think it can work this way.


 EV_MSC/MSC_SCAN.

 How would I get the 64 bit scan codes that the iMON devices generate?
 How would I know that the scan code is 64 bit?
 input_event.value is __s32.


 I suppose we could add MSC_SCAN_END event so that we can transmit
 scancodes of arbitrary length. You'd get several MSC_SCAN followed by
 MSC_SCAN_END marker. If you don't get MSC_SCAN_END assume the code is 32
 bit.

And I set a timeout to know that no MSC_SCAN_END will arrive? This is  
broken design IMHO.

Furthermore lircd needs to know the length of the scan code in bits, not  
as a multiple of 32.

 FWIW there is MSC_RAW as well.

It took me some time to convice people that this is not the right way to  
handle raw timing data.

Christoph
--
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] What are the goals for the architecture of an in-kernel IR system?

2009-12-06 Thread Christoph Bartelmus

Hi Jon,

on 04 Dec 09 at 19:28, Jon Smirl wrote:
 BTW, I just came across a XMP remote that seems to generate 3x64 bit
 scan codes. Anyone here has docs on the XMP protocol?

 Assuming a general purpose receiver (not one with fixed hardware
 decoding), is it important for Linux to receive IR signals from all
 possible remotes no matter how old or obscure? Or is it acceptable to
[...]
 Of course transmitting is a completely different problem, but we
 haven't been talking about transmitting. I can see how we would need
 to record any IR protocol in order to retransmit it. But that's in the
 5% of users world, not the 90% that want MythTV to just work.  Use
 something like LIRC if you want to transmit.

I don't think anyone here is in the position to be able to tell what is  
90% or 5%. Personally I use LIRC exclusively for transmit to my settop box  
using an old and obscure RECS80 protocol.
No, I won't replace my setup just because it's old and obscure.

Cable companies tend to provide XMP based boxes to subscribers more often  
these days. Simply not supporting these setups is a no-go for me.

Christoph
--
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] What are the goals for the architecture of an in-kernel IR system?

2009-12-06 Thread Jon Smirl

On Sun, Dec 6, 2009 at 7:12 AM, Christoph Bartelmus l...@bartelmus.de wrote:
 Hi Jon,

 on 04 Dec 09 at 19:28, Jon Smirl wrote:
 BTW, I just came across a XMP remote that seems to generate 3x64 bit
 scan codes. Anyone here has docs on the XMP protocol?

 Assuming a general purpose receiver (not one with fixed hardware
 decoding), is it important for Linux to receive IR signals from all
 possible remotes no matter how old or obscure? Or is it acceptable to
 [...]
 Of course transmitting is a completely different problem, but we
 haven't been talking about transmitting. I can see how we would need
 to record any IR protocol in order to retransmit it. But that's in the
 5% of users world, not the 90% that want MythTV to just work.  Use
 something like LIRC if you want to transmit.

 I don't think anyone here is in the position to be able to tell what is
 90% or 5%. Personally I use LIRC exclusively for transmit to my settop box
 using an old and obscure RECS80 protocol.
 No, I won't replace my setup just because it's old and obscure.

There are two groups, technically oriented people who can handle
messing around with IR protocols and everyone else.  I'm not proposing
to remove any capabilities from the first group. Instead I'd like to
see the creation of a just works option for the other group. We
don't know the size of the everyone else group yet because that option
doesn't exist. In general non-technical people way out number the
technical ones in broad user bases. For example I had to use LIRC to
get my remotes working, but I would have rather been in the everyone
else group and not had to learn about IR.

 Cable companies tend to provide XMP based boxes to subscribers more often
 these days. Simply not supporting these setups is a no-go for me.

I suspect what we categorize as just works will expand over time.
The in-kernel support can start small and add protocols and maps over
time. Support for XMP can start in LIRC and migrate into the kernel
after we fully understand the protocol and know that enough people are
using it to justify the effort of maintaining it in-kernel.  Adding
in-kernel support for a protocol is not going to make LIRC disappear.

The critical part is getting the initial design of the in-kernel IR
system right. That design is very hard to change after it gets into
everyone's systems and apps start depending on it. Writing up use
cases, modular protocols, figuring out how many bits are needed in
fields, how are maps written, can they be autoloaded, transmitting,
etc, etc. These are the important things to be discussing. LIRC users
obviously have a lot of knowledge in this area to contribute.

PS - another area we need to be thinking about is radio remotes like
the new RF4CE devices. The button presses from these remotes will come
in on the 802.15.4 networking stack and need to get routed into the
input subsystem somehow.

-- 
Jon Smirl
jonsm...@gmail.com
--
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] What are the goals for the architecture of an in-kernel IR system?

Andy Walls awa...@radix.net writes:

 Yes, I agree.  I do not know what percentage of current Linux users are
 technical vs non-technical, so I cannot gauge the current improtance.

 I can see the trend line though: as time goes by, the percentage of all
 linux users that have a technical bent will only get smaller.

This IMHO shouldn't matter. If users can configure their keymaps for
e.g. games with a graphical utility (and  they easily can), they can do
the same with their remotes, at least with these using common sane
protocols. The only thing needed is a good GUI utility. Ergo - it's not
a kernel issue.

The default bundled, or PnP, won't work well in comparison to a GUI
utility, I wouldn't worry about it too much (though adding it to udev
and co is trivial and we should do it - even if not PnP but asking first
about the actual remote used).
-- 
Krzysztof Halasa
--
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] What are the goals for the architecture of an in-kernel IR system?

Mauro Carvalho Chehab mche...@redhat.com writes:

 I do not believe you are being realistic. Sometimes we just need to say
 that the device is a POS and is just not worth it. Remember, there is
 still lirc hole for the hard core people still using solder to produce
 something out of the spare electronic components that may be made to
 work

Which device? It was about a remote controller, not the receiver. The IR
receivers are frequently coupled with a DVB etc. receiver. There is
absolutely no problem supporting almost any remote if the hardware is
compatible with the receiver (i.e. IR to IR, the carrier frequency is
not 36 vs 56 kHz, the receiver supports the protocol etc).

I don't say we need to support in-kernel decoding for arbitrary
protocols.

 (never mind that it causes the CPU constantly poll the device, not
 letting it sleep and wasting electricity as a result - just hypotetical
 example here).

Very hypotetical, indeed :-)

Most (all?) home-made receivers don't need polling, they use IRQs
instead (the home-made receiver is based on serial port and uses IRQ).
They are hardly the obscure hardware that nobody has.

The more advanced receivers using shift registers may use polling.

 Fully agreed. The costs (our time) to add and keep supporting an in-kernel
 driver for an IR that just one person is still using is higher than 
 asking the user to get a new IR. This time would be better spent adding a new
 driver for other devices.

Agreed, I think nobody argues we should support such things in the
kernel.


Once again: how about agreement about the LIRC interface
(kernel-userspace) and merging the actual LIRC code first? In-kernel
decoding can wait a bit, it doesn't change any kernel-user interface.
-- 
Krzysztof Halasa
--
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] What are the goals for the architecture of an in-kernel IR system?

2009-12-06 Thread Jon Smirl

On Sun, Dec 6, 2009 at 12:48 PM, Krzysztof Halasa k...@pm.waw.pl wrote:
 Once again: how about agreement about the LIRC interface
 (kernel-userspace) and merging the actual LIRC code first? In-kernel
 decoding can wait a bit, it doesn't change any kernel-user interface.

I'd like to see a semi-complete design for an in-kernel IR system
before anything is merged from any source.

-- 
Jon Smirl
jonsm...@gmail.com
--
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] What are the goals for the architecture of an in-kernel IR system?

Mauro Carvalho Chehab mche...@redhat.com writes:

 All the IR's I found with V4L/DVB use up to 16 bits code (or 24 bits, for NEC 
 extended protocol).
 However, currently, the drivers were getting only 7 bits, due to the old way 
 to implement
 EVIO[S|G]KEYCODE. 

 I know, however, one i2c chip that returns a 5 byte scancode when you press a 
 key. 
 We're currently just discarding the remaining bits, so I'm not really sure 
 what's there.

Right. This will have to be investigated by owners of the exact hardware
in question. What we can do is to try to make it easy for them.
There is no hurry, though - it can and will continue to work the current
way.

 In general, the scancode contains 8 or 16 bits for address, and 8 bits for 
 command.

Right. I think the kernel shouldn't differentiate between address and
command too much.

 at include/linux/input.h, we'll add a code like:

 struct input_keytable_entry {
   u16 index;
   u64 scancode;
   u32 keycode;
 } __attribute__ ((packed));

 (the attribute packed avoids needing a compat for 64 bits)

Maybe { u64 scancode; u32 keycode; u16 index; u16 reserved } would be a
bit better, no alignment problems and we could eventually change
reserved into something useful.

But I think, if we are going to redesign it, we better use scancodes of
arbitrary length (e.g. protocol-dependent length). It should be opaque
except for the protocol handler.
-- 
Krzysztof Halasa
--
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] What are the goals for the architecture of an in-kernel IR system?

Jon Smirl jonsm...@gmail.com writes:

 The in-kernel support can start small and add protocols and maps over
 time.

Protocols, yes. Maps - we certainly don't want megatons of maps in the
kernel. The existing ones have to be removed, some time.
-- 
Krzysztof Halasa
--
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] What are the goals for the architecture of an in-kernel IR system?