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@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 -- Jarod Wilson jarod@xxxxxxxxxx -- 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
