Menu
▾
▴
Re: various improvements for lirc
|
From: Arnaud Q. <arn...@fr...> - 2005-02-15 21:09:23
|
[@Vojtech: I keep you cc'ed as I still don't know if you're subscribed... Please tell me if so] Hi Chris, sorry for the lag, but I had to switch to Solution Linux fair, and back I had to deal with NUT, Debian and related stuffs... So I'm still there, simply busy as always ;-) >[...] > > >>Better integration (and standardization) of IR remote drivers in the >>kernel would be a great thing. I hope the input layer provides a good >>enough interface. If not, it can be extended. >> >> > >This has been discussed here already. I'm still convinced that the input >layer is not the correct interface for IR remote purposes. >There's no point in extending the existing interface because it would >end up just like the interface that we already have: lirc_dev. > > > I'll have to dig the list about that. Any pointers welcomed What I'm sure about is that remotes are input devices, and that LIRC is the project to handle remote on linux... After all, the key "1" (or any other) pressed on a remote or a keyboard, or any input devices, should have the same effect in userland. So why having two sets of userland drivers and config where we can have only one! (considering ie the unified X11 input driver stated by Vojtech) >I would really appreciate if the efforts would focus on getting the LIRC >drivers in a better shape, so they could go into the kernel instead of >promoting a different interface. > > don't get me wrong, I'm not there to destroy things nor to waste everybody's effort. I just want to be sure that LIRC is on the best road to get merged into the kernel! I don't want to promote a different interface, but just looking if the existing one wouldn't better fit this purpose. >What we are talking about right now is feeding the events of the remote >control back to the Linux input layer after they have been processed by >lircd so they are transparently available to applications. > > I'd better see an lirc kernel driver, using lirc_i2c, lirc_gpio,... and a resolution file (config file) to produce input events Like you, I don't think that a trip from kernel-land to user-land and back to the kernel-land is an option! But it has no need to be like that ;-) >In case of TV card remote control drivers this might be unnecessary >complicated but I rather want a uniform interface that might not be the >optimal solution in any case instead of confusing users with different >setups. > > > what makes me sad is that, as stated by Vojtech, we have some remotes supported by lirc, and some others by the kernel itself. This is IMHO more confusing to the users. The different setups is something that can be addressed by setup wizards (for users that can be confused). Power users will simply dig, and edit files by hand... My long term aim is to have remote support standardised so that we can (help) create wizard to generate the appropriate config for the user, with few mouse clicks... And things will be fine under the sun >>>>a) Create a common naming scheme >>>> >>>> >[...] > > >>The input layer (for application programmer's sanity sake) >>specifies that there should be only one input event code per a key, and >>that the key should issue 0 when released, 1 when pressed and 2 for >>repeat. >> >>So the IR remote receiver driver will need to be told that a key can >>send a release event, and keep it pressed until it gets that one, and >>optionally also set the repeat bit on the input device structure. >> >> > >This can easily be done in user space by lircd. > > yep, but as stated above, why having two sets of namespaces and userland drivers for handling the same things! >[...] > > >>>b) compile all drivers >>>------------------------------------ >>> >>>this would allow full runtime selection, >>>not needing recompilation. >>> >>> >>> >>Christoph is currently looking how it is possible >>to address that point. >> >> > >Not really. I know there are problems. But as most people who package >LIRC have found ways around this problem, this is not a high prio action >point for me. > > > let's says that it's not a high prio, and that it will be addressed later on... >>>c) Create a drivers list >>>-------------------------------------- >>> >>>with a format like: >>><manufacturer> <model name> <model extra> <driver> >>> >>> > ><driver> is not enough. > > that was the early draft of my first mail. The 2nd was: <brand> <model> <supported devices> <driver> <data file> as presented in the preliminary list: http://arnaud.quette.free.fr/lirc/remotes.list >The user needs to know which user space driver (the one compiled into >lircd) and which kernel driver to use (lirc_gpio, lirc_i2c, none, etc.). >Also most people seem to get confused if they have to run setserial uart >none if they are using a certain driver. > > > I'm not sure the user _need_ to know that, nor if it has to use setserial. For the former, wizard are made so that users don't have to fed up with that kind of stuffs. But you're right about the lircd vs kernel drivers, so we might consider: <brand> <model> <supported devices> <lircd_driver> <kernel_driver> <data file> In the long term, based on my above remark, we might have only a kernel driver left! For the latter, this could be addressed by some scripts, or lobbying for a good kernel configuration... >>- about 43 embedded in LIRC: already added to a remotes.list >>file I've (http://arnaud.quette.free.fr/lirc/remotes.list) >> >> > >Forget the files in generic. These include protocol information rather >than belonging to a certain remote/device combination. > > > argh, you should have told me first ;-) that removes 33 lines of 98... >>This is a base, made of the most common remote, that >>needs to be completed... >> - about 1850 in the remotes archives! >> >> > >The remotes in the archive will work with any device that uses the MODE2 >interface. There's no point in adding them to this list. > > > I'm not sure to follow you (mostly because I might not know enough about lirc's internal), but if you say so, it's fine. See you, Arnaud |