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���)ߣ�
