Re: [PATCH 0/3] Proposed ir-core (rc-core) changes

Re: [PATCH 0/3] Proposed ir-core (rc-core) changes

[Andy Walls]

Heh.  Between "where's the current base?", > 1 hour rebuild times for the whole kernel, and continual retooling of the IR core stuff, I can't keep up with the time I have available.

Mauro did make an announcement a few weeks back.  I thought it was the media.git tree.

R,
Andy

David Härdeman <david@hardeman.nu> wrote:

>On Thu, August 26, 2010 21:14, Jarod Wilson wrote:
>> On Wed, Aug 25, 2010 at 01:01:57AM +0200, David Härdeman wrote:
>>> The following series merges the different files that currently make up
>>> the ir-core module into a single-file rc-core module.
>>>
>>> In addition, the ir_input_dev and ir_dev_props structs are replaced
>>> by a single rc_dev struct with an API similar to that of the input
>>> subsystem.
>>>
>>> This allows the removal of all knowledge of any input devices from the
>>> rc drivers and paves the way for allowing multiple input devices per
>>> rc device in the future. The namespace conversion from ir_* to rc_*
>>> should mostly be done for the drivers with this patchset.
>>>
>>> I have intentionally not signed off on the patches yet since they
>>> haven't
>>> been tested. I'd like your feedback on the general approach before I
>>> spend
>>> the time to properly test the result.
>>>
>>> Also, the imon driver is not converted (and will thus break with this
>>> patchset). The reason is that the imon driver wants to generate mouse
>>> events on the input dev under the control of rc-core. I was hoping that
>>> Jarod would be willing to convert the imon driver to create a separate
>>> input device for sending mouse events to userspace :)
>>
>> Yeah, I could be persuaded to do that. Means that the imon driver, when
>> driving one of the touchscreen devices, will bring up 3 separate input
>> devices, but oh well. (I'd actually considered doing that when porting to
>> ir-core in the first place, but went the lazy route. ;)
>
>That would be good. I'm pretty certain that the split will be necessary
>sooner or later.
>
>>> Comments please...
>>
>> Haven't tried it out at all yet or done more than a quick skim through the
>> patches, but at first glance, I do like the idea of further abstracting
>> away the input layer. I know I tanked a few things the first go 'round,
>> thinking I needed to do both some rc-layer and input-layer setup and/or
>> teardown. It becomes more cut and dry if you don't see anything
>> input-related anywhere at all.
>
>Not to mention we will have a more consistent user experience. For
>example: some of the current hardware drivers are fiddling with the repeat
>values of the input dev...something which should be the same across the
>entire subsystem (you wouldn't expect the repetition rate for the exact
>same remote control to change just because you change the receiver).
>
>Also, it's necessary for any future support of multiple input devices (one
>per physical remote control being one example)...and it gives us more
>flexibility to make changes in rc-core when drivers do not muck around in
>subdevices (input devices that is).
>
>> One thing I did note with the patches is that a lot of bits were altered
>> from ir-foo to rc-foo, but not all of them... If we're going to make the
>> change, why no go whole hog? (Or was it only things relevant to ir
>> specifically right now that didn't get renamed?)
>
>The rule of thumb I followed was to rename stuff that I touched but leave
>unchanged code alone. Renaming the remaining functions can be done in
>later, separate, patches (some of them will be more invasive as file names
>need changing as well).
>
>On a related note, I'm getting confused wrt git the v4l-dvb git branches.
>The current patches are against staging/rc which hasn't seen much activity
>in a month or two but staging/other seems to carry some more recent
>rc-related patches...which one am I supposed to base my work on?
>
>-- 
>David Härdeman
>
>--
>To unsubscribe from this list: send the line "unsubscribe linux-media" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/3] Proposed ir-core (rc-core) changes

[Jarod Wilson]

On Fri, Aug 27, 2010 at 11:55:47AM -0400, Andy Walls wrote:
> Heh.  Between "where's the current base?", > 1 hour rebuild times for the whole kernel, and continual retooling of the IR core stuff, I can't keep up with the time I have available.
> 
> Mauro did make an announcement a few weeks back.  I thought it was the media.git tree.

Yeah, the most recent patch I've done was against media_tree.git, branch
staging/v2.6.36.

http://git.linuxtv.org/media_tree.git?a=shortlog;h=refs/heads/staging/v2.6.36

I believe there's a slightly updated mceusb.c in there vs. what this
patchset was against, and there are also streamzap.c and ene_ir.c in
there, ported from lirc to ir-core in there that would also need to be
updated for these changes. (Nb: there's a fairly major streamzap.c patch
still pending, wouldn't start working on that port until it gets merged.)


> David Härdeman <david@hardeman.nu> wrote:
> 
> >On Thu, August 26, 2010 21:14, Jarod Wilson wrote:
> >> On Wed, Aug 25, 2010 at 01:01:57AM +0200, David Härdeman wrote:
> >>> The following series merges the different files that currently make up
> >>> the ir-core module into a single-file rc-core module.
> >>>
> >>> In addition, the ir_input_dev and ir_dev_props structs are replaced
> >>> by a single rc_dev struct with an API similar to that of the input
> >>> subsystem.
> >>>
> >>> This allows the removal of all knowledge of any input devices from the
> >>> rc drivers and paves the way for allowing multiple input devices per
> >>> rc device in the future. The namespace conversion from ir_* to rc_*
> >>> should mostly be done for the drivers with this patchset.
> >>>
> >>> I have intentionally not signed off on the patches yet since they
> >>> haven't
> >>> been tested. I'd like your feedback on the general approach before I
> >>> spend
> >>> the time to properly test the result.
> >>>
> >>> Also, the imon driver is not converted (and will thus break with this
> >>> patchset). The reason is that the imon driver wants to generate mouse
> >>> events on the input dev under the control of rc-core. I was hoping that
> >>> Jarod would be willing to convert the imon driver to create a separate
> >>> input device for sending mouse events to userspace :)
> >>
> >> Yeah, I could be persuaded to do that. Means that the imon driver, when
> >> driving one of the touchscreen devices, will bring up 3 separate input
> >> devices, but oh well. (I'd actually considered doing that when porting to
> >> ir-core in the first place, but went the lazy route. ;)
> >
> >That would be good. I'm pretty certain that the split will be necessary
> >sooner or later.
> >
> >>> Comments please...
> >>
> >> Haven't tried it out at all yet or done more than a quick skim through the
> >> patches, but at first glance, I do like the idea of further abstracting
> >> away the input layer. I know I tanked a few things the first go 'round,
> >> thinking I needed to do both some rc-layer and input-layer setup and/or
> >> teardown. It becomes more cut and dry if you don't see anything
> >> input-related anywhere at all.
> >
> >Not to mention we will have a more consistent user experience. For
> >example: some of the current hardware drivers are fiddling with the repeat
> >values of the input dev...something which should be the same across the
> >entire subsystem (you wouldn't expect the repetition rate for the exact
> >same remote control to change just because you change the receiver).
> >
> >Also, it's necessary for any future support of multiple input devices (one
> >per physical remote control being one example)...and it gives us more
> >flexibility to make changes in rc-core when drivers do not muck around in
> >subdevices (input devices that is).
> >
> >> One thing I did note with the patches is that a lot of bits were altered
> >> from ir-foo to rc-foo, but not all of them... If we're going to make the
> >> change, why no go whole hog? (Or was it only things relevant to ir
> >> specifically right now that didn't get renamed?)
> >
> >The rule of thumb I followed was to rename stuff that I touched but leave
> >unchanged code alone. Renaming the remaining functions can be done in
> >later, separate, patches (some of them will be more invasive as file names
> >need changing as well).
> >
> >On a related note, I'm getting confused wrt git the v4l-dvb git branches.
> >The current patches are against staging/rc which hasn't seen much activity
> >in a month or two but staging/other seems to carry some more recent
> >rc-related patches...which one am I supposed to base my work on?
> >
> >-- 
> >David Härdeman
> >
> >--
> >To unsubscribe from this list: send the line "unsubscribe linux-media" in
> >the body of a message to majordomo@vger.kernel.org
> >More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Jarod Wilson
jarod@redhat.com

Re: [PATCH 0/3] Proposed ir-core (rc-core) changes

[Andy Walls]

David Härdeman <david@hardeman.nu> wrote:

>On Thu, August 26, 2010 21:14, Jarod Wilson wrote:
>> On Wed, Aug 25, 2010 at 01:01:57AM +0200, David Härdeman wrote:
>>> The following series merges the different files that currently make up
>>> the ir-core module into a single-file rc-core module.
>>>
>>> In addition, the ir_input_dev and ir_dev_props structs are replaced
>>> by a single rc_dev struct with an API similar to that of the input
>>> subsystem.
>>>
>>> This allows the removal of all knowledge of any input devices from the
>>> rc drivers and paves the way for allowing multiple input devices per
>>> rc device in the future. The namespace conversion from ir_* to rc_*
>>> should mostly be done for the drivers with this patchset.
>>>
>>> I have intentionally not signed off on the patches yet since they
>>> haven't
>>> been tested. I'd like your feedback on the general approach before I
>>> spend
>>> the time to properly test the result.
>>>
>>> Also, the imon driver is not converted (and will thus break with this
>>> patchset). The reason is that the imon driver wants to generate mouse
>>> events on the input dev under the control of rc-core. I was hoping that
>>> Jarod would be willing to convert the imon driver to create a separate
>>> input device for sending mouse events to userspace :)
>>
>> Yeah, I could be persuaded to do that. Means that the imon driver, when
>> driving one of the touchscreen devices, will bring up 3 separate input
>> devices, but oh well. (I'd actually considered doing that when porting to
>> ir-core in the first place, but went the lazy route. ;)
>
>That would be good. I'm pretty certain that the split will be necessary
>sooner or later.
>
>>> Comments please...
>>
>> Haven't tried it out at all yet or done more than a quick skim through the
>> patches, but at first glance, I do like the idea of further abstracting
>> away the input layer. I know I tanked a few things the first go 'round,
>> thinking I needed to do both some rc-layer and input-layer setup and/or
>> teardown. It becomes more cut and dry if you don't see anything
>> input-related anywhere at all.
>
>Not to mention we will have a more consistent user experience. For
>example: some of the current hardware drivers are fiddling with the repeat
>values of the input dev...something which should be the same across the
>entire subsystem (you wouldn't expect the repetition rate for the exact
>same remote control to change just because you change the receiver).
>
>Also, it's necessary for any future support of multiple input devices (one
>per physical remote control being one example)...and it gives us more
>flexibility to make changes in rc-core when drivers do not muck around in
>subdevices (input devices that is).
>
>> One thing I did note with the patches is that a lot of bits were altered
>> from ir-foo to rc-foo, but not all of them... If we're going to make the
>> change, why no go whole hog? (Or was it only things relevant to ir
>> specifically right now that didn't get renamed?)
>
>The rule of thumb I followed was to rename stuff that I touched but leave
>unchanged code alone. Renaming the remaining functions can be done in
>later, separate, patches (some of them will be more invasive as file names
>need changing as well).
>
>On a related note, I'm getting confused wrt git the v4l-dvb git branches.
>The current patches are against staging/rc which hasn't seen much activity
>in a month or two but staging/other seems to carry some more recent
>rc-related patches...which one am I supposed to base my work on?
>
>-- 
>David Härdeman
>
>--
>To unsubscribe from this list: send the line "unsubscribe linux-media" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/3] Proposed ir-core (rc-core) changes

[David Härdeman]

On Thu, August 26, 2010 21:14, Jarod Wilson wrote:
> On Wed, Aug 25, 2010 at 01:01:57AM +0200, David Härdeman wrote:
>> The following series merges the different files that currently make up
>> the ir-core module into a single-file rc-core module.
>>
>> In addition, the ir_input_dev and ir_dev_props structs are replaced
>> by a single rc_dev struct with an API similar to that of the input
>> subsystem.
>>
>> This allows the removal of all knowledge of any input devices from the
>> rc drivers and paves the way for allowing multiple input devices per
>> rc device in the future. The namespace conversion from ir_* to rc_*
>> should mostly be done for the drivers with this patchset.
>>
>> I have intentionally not signed off on the patches yet since they
>> haven't
>> been tested. I'd like your feedback on the general approach before I
>> spend
>> the time to properly test the result.
>>
>> Also, the imon driver is not converted (and will thus break with this
>> patchset). The reason is that the imon driver wants to generate mouse
>> events on the input dev under the control of rc-core. I was hoping that
>> Jarod would be willing to convert the imon driver to create a separate
>> input device for sending mouse events to userspace :)
>
> Yeah, I could be persuaded to do that. Means that the imon driver, when
> driving one of the touchscreen devices, will bring up 3 separate input
> devices, but oh well. (I'd actually considered doing that when porting to
> ir-core in the first place, but went the lazy route. ;)

That would be good. I'm pretty certain that the split will be necessary
sooner or later.

>> Comments please...
>
> Haven't tried it out at all yet or done more than a quick skim through the
> patches, but at first glance, I do like the idea of further abstracting
> away the input layer. I know I tanked a few things the first go 'round,
> thinking I needed to do both some rc-layer and input-layer setup and/or
> teardown. It becomes more cut and dry if you don't see anything
> input-related anywhere at all.

Not to mention we will have a more consistent user experience. For
example: some of the current hardware drivers are fiddling with the repeat
values of the input dev...something which should be the same across the
entire subsystem (you wouldn't expect the repetition rate for the exact
same remote control to change just because you change the receiver).

Also, it's necessary for any future support of multiple input devices (one
per physical remote control being one example)...and it gives us more
flexibility to make changes in rc-core when drivers do not muck around in
subdevices (input devices that is).

> One thing I did note with the patches is that a lot of bits were altered
> from ir-foo to rc-foo, but not all of them... If we're going to make the
> change, why no go whole hog? (Or was it only things relevant to ir
> specifically right now that didn't get renamed?)

The rule of thumb I followed was to rename stuff that I touched but leave
unchanged code alone. Renaming the remaining functions can be done in
later, separate, patches (some of them will be more invasive as file names
need changing as well).

On a related note, I'm getting confused wrt git the v4l-dvb git branches.
The current patches are against staging/rc which hasn't seen much activity
in a month or two but staging/other seems to carry some more recent
rc-related patches...which one am I supposed to base my work on?

-- 
David Härdeman

Re: [PATCH 0/3] Proposed ir-core (rc-core) changes

[Jarod Wilson]

On Wed, Aug 25, 2010 at 01:01:57AM +0200, David Härdeman wrote:
> The following series merges the different files that currently make up
> the ir-core module into a single-file rc-core module.
> 
> In addition, the ir_input_dev and ir_dev_props structs are replaced
> by a single rc_dev struct with an API similar to that of the input
> subsystem.
> 
> This allows the removal of all knowledge of any input devices from the
> rc drivers and paves the way for allowing multiple input devices per
> rc device in the future. The namespace conversion from ir_* to rc_*
> should mostly be done for the drivers with this patchset.
> 
> I have intentionally not signed off on the patches yet since they haven't
> been tested. I'd like your feedback on the general approach before I spend
> the time to properly test the result.
> 
> Also, the imon driver is not converted (and will thus break with this
> patchset). The reason is that the imon driver wants to generate mouse
> events on the input dev under the control of rc-core. I was hoping that
> Jarod would be willing to convert the imon driver to create a separate
> input device for sending mouse events to userspace :)

Yeah, I could be persuaded to do that. Means that the imon driver, when
driving one of the touchscreen devices, will bring up 3 separate input
devices, but oh well. (I'd actually considered doing that when porting to
ir-core in the first place, but went the lazy route. ;)

> Comments please...

Haven't tried it out at all yet or done more than a quick skim through the
patches, but at first glance, I do like the idea of further abstracting
away the input layer. I know I tanked a few things the first go 'round,
thinking I needed to do both some rc-layer and input-layer setup and/or
teardown. It becomes more cut and dry if you don't see anything
input-related anywhere at all.

One thing I did note with the patches is that a lot of bits were altered
from ir-foo to rc-foo, but not all of them... If we're going to make the
change, why no go whole hog? (Or was it only things relevant to ir
specifically right now that didn't get renamed?)

-- 
Jarod Wilson
jarod@redhat.com

[PATCH 0/3] Proposed ir-core (rc-core) changes

[David Härdeman]

The following series merges the different files that currently make up
the ir-core module into a single-file rc-core module.

In addition, the ir_input_dev and ir_dev_props structs are replaced
by a single rc_dev struct with an API similar to that of the input
subsystem.

This allows the removal of all knowledge of any input devices from the
rc drivers and paves the way for allowing multiple input devices per
rc device in the future. The namespace conversion from ir_* to rc_*
should mostly be done for the drivers with this patchset.

I have intentionally not signed off on the patches yet since they haven't
been tested. I'd like your feedback on the general approach before I spend
the time to properly test the result.

Also, the imon driver is not converted (and will thus break with this
patchset). The reason is that the imon driver wants to generate mouse
events on the input dev under the control of rc-core. I was hoping that
Jarod would be willing to convert the imon driver to create a separate
input device for sending mouse events to userspace :)

Comments please...

---

David Härdeman (3):
      merge rc-core
      remove remaining users of the ir-functions keyhandlers
      make rc_dev the primary interface for remote control drivers


 drivers/media/IR/Makefile                   |    3 
 drivers/media/IR/ir-core-priv.h             |   26 -
 drivers/media/IR/ir-functions.c             |   96 --
 drivers/media/IR/ir-jvc-decoder.c           |   13 
 drivers/media/IR/ir-keytable.c              |  552 ------------
 drivers/media/IR/ir-lirc-codec.c            |   75 +-
 drivers/media/IR/ir-nec-decoder.c           |   13 
 drivers/media/IR/ir-raw-event.c             |  270 ------
 drivers/media/IR/ir-rc5-decoder.c           |   13 
 drivers/media/IR/ir-rc6-decoder.c           |   17 
 drivers/media/IR/ir-sony-decoder.c          |   11 
 drivers/media/IR/ir-sysfs.c                 |  354 --------
 drivers/media/IR/mceusb.c                   |   99 +-
 drivers/media/IR/rc-core.c                  | 1206 +++++++++++++++++++++++++++
 drivers/media/IR/rc-map.c                   |   84 --
 drivers/media/dvb/dm1105/dm1105.c           |   45 +
 drivers/media/dvb/mantis/mantis_common.h    |    4 
 drivers/media/dvb/mantis/mantis_input.c     |   61 +
 drivers/media/dvb/ttpci/budget-ci.c         |   49 -
 drivers/media/video/bt8xx/bttv-input.c      |   67 +-
 drivers/media/video/bt8xx/bttvp.h           |    1 
 drivers/media/video/cx18/cx18-i2c.c         |    1 
 drivers/media/video/cx23885/cx23885-input.c |   93 --
 drivers/media/video/cx88/cx88-input.c       |   86 +-
 drivers/media/video/em28xx/em28xx-input.c   |   71 +-
 drivers/media/video/ir-kbd-i2c.c            |   41 -
 drivers/media/video/ivtv/ivtv-i2c.c         |    3 
 drivers/media/video/saa7134/saa7134-input.c |  121 +--
 include/media/ir-common.h                   |   32 -
 include/media/ir-core.h                     |  155 ++-
 include/media/ir-kbd-i2c.h                  |    5 
 31 files changed, 1655 insertions(+), 2012 deletions(-)
 delete mode 100644 drivers/media/IR/ir-keytable.c
 delete mode 100644 drivers/media/IR/ir-raw-event.c
 delete mode 100644 drivers/media/IR/ir-sysfs.c
 create mode 100644 drivers/media/IR/rc-core.c
 delete mode 100644 drivers/media/IR/rc-map.c