On Tue, Jun 17, 2008 at 12:53:52PM -0300, Mauro Carvalho Chehab wrote: > On Sun, 15 Jun 2008 18:28:07 +0200 > Stefan Richter <stefanr at s5r6.in-berlin.de> wrote: > > > Stefan Richter wrote: > > > This means that firesat needs to be ported to the new stack eventually. > > > The question remains if that should be done before mainline submission > > > or after. I tend to the latter, > > > > http://forum.digital-everywhere.com/viewforum.php?f=34 shows that people > > are eager to test the driver. One user even posted an own small fixup > > patch there. I.e. we should get it into mainline sooner rather than > > later. A conversion to the new firewire stack would be easier after > > mainline merge anyway, from the development POV. > > > > Mauro, did the status regarding the driver's interface with the DVB > > subsystem change since your comment in April? > > http://driverdev.linuxdriverproject.org/pipermail/devel/2008-April/000382.html > > Yes. The issues I've pointed there were fixed. > > Still, the remote controller handling seems to be using a bad approach. Instead of > registering a key table, and allowing IR code redefinition, the firesat-rc has > a hardcoded table that returns a keycode, instead of a scancode. This seems bad, > since newer IR's may have a different scancode table. Also, I suspect that this > approach doesn't allow the loading of other keys, if you want to use a > different IR with more keys. IMO, it would be interesting to get Dmitry's > review for the input code. > Hmm, unless I am looking in the wrong place the driver still uses static input device allocation and so is unlikely to work on any recent (year or so) kernel. The keymap is a bit interesting too as I did not know remotes having alpha keys such as P, M, R, etc. input_sync() calls are also missing, sysfs links, but type setup, name, phys, etc. -- Dmitry
