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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
��.n��������+%������w��{.n�����{��g����^n�r������&��z�ޗ�zf���h���~����������_��+v���)ߣ�

[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux