From: Arnaud Q. <arn...@fr...> - 2005-01-26 21:52:50
|
Hi fellows, this is a private thread I started with Christoph Bartelmus, which should now go public. It talks about more standardisation in LIRC, and a better integration in the linux input layer. All this for a better and easier usability... I've put my first post to Christoph, completed by the current status and the result of the discussion with Christoph. Sit down, and have a fresh drink, it's long but anybody can help ;-) Comments, thoughts and help are welcome... Arnaud Quette a =E9crit : > Hi Christoph, > > long time lirc user and opensource developer > (see my sig), I wanted to step out for some > time, but lack of time... You know what I mean ;-) > > I'm thinking for some time about the following > minor changes for major improvements, and > wanted to talk with you before posting on the list. > > 1) minor changes for major improvements > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > note: these are minor to think/find, but huge to apply... =20 > a) Create a common naming scheme > ------------------------------------------------------------- > > This is something we've applied > successfully on NUT [1] and which > make things easier on the client > layer: 1 API, 1 set of names. This > also allows to provide a complete > sample config per app. > > This is not a so hard task. It just need > to create the name set from the existing > remote signal, and rework the remote > package. > Christoph has been thinking about it for some time. After digging a bit, the naming scheme of linux input layer seems to be the best way. See the kernel source "include/linux/input.h" file. More specifically, look at "Keys and buttons" section I've provided a sample converted file (animax) at: http://arnaud.quette.free.fr/lirc/lircd.conf.animax BTW, what to do with _UP & _DOWN symbols (ie VIDEO_DOWN & VIDEO_UP, matching the same button, but in pressed or released state) some remotes defines (like my animax)? Should these be ripped off, keeping only one occurence, or should these be assigned the same name (ie KEY_VIDEO for both, which implies to manage repeat)? Finally note that this convergence might be the first step toward a better integration in the input layer (through remotedev or evdev) Update: there are however few lacks in the input namespace. But I'm sure Vojtech will be open to update it. > 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. > c) Create a drivers list > -------------------------------------- > > with a format like: > <manufacturer> <model name> <model extra> <driver> > > This would allow: > - use in wizard and config tool (display a formated list) > - web compat list generation (as in nut [4]) > - sniffing by HWDB projects like distro' (Mdk [2], ...), > FSF' ([3]) > > The 3 above principles have been applied, or will be soon, > to NUT [4] > Christoph is for, and I've started by working on this. I've changed the format to: <brand> <model> <supported devices> <driver> <data file> Here is a current approximation of the number of remotes data files: - about 43 embedded in LIRC: already added to a remotes.list file I've (http://arnaud.quette.free.fr/lirc/remotes.list) This is a base, made of the most common remote, that needs to be completed... - about 1850 in the remotes archives! There is a good amount of work to have a clean and complete list, but I think the above remotes.list is a good base, and that it can be completed by digging deeper the data files, contacting the contributors and digging the web... Any help welcomed... > 2) bigger changes > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > I've no exact idea yet, but a recent acquisition of a usb > remote (bundled with a laptop) made me think! It's > a USB/HID remote, exposing both a keyboard and a > mouse + some more things (not looked at, hiddev seems > to report something...) > > This so made me think that there will be support for > remote out of lirc. But there should also be a common > "wrapper" for remote support... to be continued > The below point 3 might be a part of the answer. > This is linked to point 1) (evdev/remotedev) and integrating LIRC into the unified linux input layer. That way, the present point is obsolete. > 3) X11 driver / embedded protocol > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Based on a thing I use for my laptop's touchpad [5], this is > the best input entry point for any GUI! > Having support through the standard input layer, X11 should manage the various keys without problem. It also help X11 developers (ie KDE, Gnome, ...) to focus on a single naming scheme for multimedia peripherals... > I hope all the above will receive a good echo. > Continue your good work. > both are still true ;-) > Arnaud > --- > [1] http://eu1.networkupstools.org/doc/2.0.0/new-names.html > [2] http://www.mandrakelinux.com/fr/hardware.php3 > [3] http://lists.gnu.org/mailman/listinfo/hfdb > [4] http://eu2.networkupstools.org/compat/stable.html > [5] http://web.telia.com/~u89404340/touchpad/index.html > --- > Opensource Developer - http://arnaud.quette.free.fr > Debian GNU/Linux Developer - http://people.debian.org/~aquette > and these one too, more than ever ;-) I've lots more to say, but I lack of time and I'll first wait for a [positive/constructive] echo... See you, Arnaud |
From: Paul M. <pa...@pi...> - 2005-01-26 22:44:11
|
To standardize the key naming, I think we should rewrite irrecord to use a= =20 more graphical interface (ncurses, etc.) and have a list of standard key=20 names and check the off as the user programs his/her remote. I think if we= =20 just asked the user to press the "ok" button, etc., the user may not select= =20 the best possible choice. Of course, we'd still need to leave room for=20 custom buttons. With time the remote configurations will be standardized. This way, we avoid rewriting the configuration format and any incompatibili= ty=20 problems..... =2DPaul On Wednesday 26 January 2005 3:53 pm, Arnaud Quette wrote: > Hi fellows, > > this is a private thread I started with Christoph Bartelmus, > which should now go public. > > It talks about more standardisation in LIRC, and > a better integration in the linux input layer. All > this for a better and easier usability... > > I've put my first post to Christoph, completed by the > current status and the result of the discussion with > Christoph. > > Sit down, and have a fresh drink, it's long but > anybody can help ;-) > > Comments, thoughts and help are welcome... > > Arnaud Quette a =E9crit : > > Hi Christoph, > > > > long time lirc user and opensource developer > > (see my sig), I wanted to step out for some > > time, but lack of time... You know what I mean ;-) > > > > I'm thinking for some time about the following > > minor changes for major improvements, and > > wanted to talk with you before posting on the list. > > > > 1) minor changes for major improvements > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > note: these are minor to think/find, but huge > to apply... > > > a) Create a common naming scheme > > ------------------------------------------------------------- > > > > This is something we've applied > > successfully on NUT [1] and which > > make things easier on the client > > layer: 1 API, 1 set of names. This > > also allows to provide a complete > > sample config per app. > > > > This is not a so hard task. It just need > > to create the name set from the existing > > remote signal, and rework the remote > > package. > > Christoph has been thinking about it for some > time. After digging a bit, the naming scheme > of linux input layer seems to be the best way. > See the kernel source "include/linux/input.h" file. > More specifically, look at "Keys and buttons" section > > I've provided a sample converted file (animax) at: > http://arnaud.quette.free.fr/lirc/lircd.conf.animax > > BTW, what to do with _UP & _DOWN symbols (ie > VIDEO_DOWN & VIDEO_UP, matching the same > button, but in pressed or released state) some > remotes defines (like my animax)? Should these > be ripped off, keeping only one occurence, or > should these be assigned the same name (ie > KEY_VIDEO for both, which implies to manage > repeat)? > > Finally note that this convergence might be the > first step toward a better integration in the input > layer (through remotedev or evdev) > > Update: there are however few lacks in the input > namespace. But I'm sure Vojtech will be open to > update it. > > > 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. > > > c) Create a drivers list > > -------------------------------------- > > > > with a format like: > > <manufacturer> <model name> <model extra> <driver> > > > > This would allow: > > - use in wizard and config tool (display a formated list) > > - web compat list generation (as in nut [4]) > > - sniffing by HWDB projects like distro' (Mdk [2], ...), > > FSF' ([3]) > > > > The 3 above principles have been applied, or will be soon, > > to NUT [4] > > Christoph is for, and I've started by working on this. > I've changed the format to: > <brand> <model> <supported devices> <driver> <data file> > > Here is a current approximation of the number of > remotes data files: > - about 43 embedded in LIRC: already added to a remotes.list > file I've (http://arnaud.quette.free.fr/lirc/remotes.list) > This is a base, made of the most common remote, that > needs to be completed... > - about 1850 in the remotes archives! > > There is a good amount of work to have a clean and > complete list, but I think the above remotes.list is a > good base, and that it can be completed by digging > deeper the data files, contacting the contributors > and digging the web... > > Any help welcomed... > > > 2) bigger changes > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > I've no exact idea yet, but a recent acquisition of a usb > > remote (bundled with a laptop) made me think! It's > > a USB/HID remote, exposing both a keyboard and a > > mouse + some more things (not looked at, hiddev seems > > to report something...) > > > > This so made me think that there will be support for > > remote out of lirc. But there should also be a common > > "wrapper" for remote support... to be continued > > The below point 3 might be a part of the answer. > > This is linked to point 1) (evdev/remotedev) and integrating > LIRC into the unified linux input layer. That way, the present > point is obsolete. > > > 3) X11 driver / embedded protocol > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > Based on a thing I use for my laptop's touchpad [5], this is > > the best input entry point for any GUI! > > Having support through the standard input layer, X11 should > manage the various keys without problem. It also help X11 > developers (ie KDE, Gnome, ...) to focus on a single naming > scheme for multimedia peripherals... > > > I hope all the above will receive a good echo. > > Continue your good work. > > both are still true ;-) > > > Arnaud > > --- > > [1] http://eu1.networkupstools.org/doc/2.0.0/new-names.html > > [2] http://www.mandrakelinux.com/fr/hardware.php3 > > [3] http://lists.gnu.org/mailman/listinfo/hfdb > > [4] http://eu2.networkupstools.org/compat/stable.html > > [5] http://web.telia.com/~u89404340/touchpad/index.html > > --- > > Opensource Developer - http://arnaud.quette.free.fr > > Debian GNU/Linux Developer - http://people.debian.org/~aquette > > and these one too, more than ever ;-) > > I've lots more to say, but I lack of time and I'll first > wait for a [positive/constructive] echo... > > See you, > Arnaud > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting > Tool for open source databases. Create drag-&-drop reports. Save time > by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. > Download a FREE copy at http://www.intelliview.com/go/osdn_nl |
From: Arnaud Q. <arn...@fr...> - 2005-01-27 20:50:00
|
Paul Miller a =E9crit : >To standardize the key naming, I think we should rewrite irrecord to use= a=20 >more graphical interface (ncurses, etc.) > yep, good point > and have a list of standard key=20 >names > as told, we already have it in linux/input.h, and even if there are few lacks, Vojtech is now working with us ;-) > and check the off as the user programs his/her remote. I think if we=20 >just asked the user to press the "ok" button, etc., the user may not sel= ect=20 >the best possible choice. > I'm more for the latter. But as not all the remote support the whole namespace, it's right that crossing through it all and ask the user to press the corresponding key is a bad way... We might simply ask the user to cycle through all the keys of his remote, and for each, to select the _exact_ matching key of lirc naming. If nothing matches, see below... > Of course, we'd still need to leave room for=20 >custom buttons. > I think we must have finished namespace, and to only extend it upon studished request. This way, we can consider other nearby needs, and address the whole. Or did I get you wrong? > With time the remote configurations will be standardized. > > =20 > yep, one step in the right direction ;-) >This way, we avoid rewriting the configuration format and any incompatib= ility=20 >problems..... > > =20 > sure, there is no need to touch data file format... Arnaud --- Opensource Developer - http://arnaud.quette.free.fr Debian GNU/Linux Developer - http://people.debian.org/~aquette |
From: Vojtech P. <vo...@su...> - 2005-01-27 11:50:31
|
On Wed, Jan 26, 2005 at 10:53:55PM +0100, Arnaud Quette wrote: > Hi fellows, > > this is a private thread I started with Christoph Bartelmus, > which should now go public. > > It talks about more standardisation in LIRC, and > a better integration in the linux input layer. All > this for a better and easier usability... 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. > >a) Create a common naming scheme > >------------------------------------------------------------- > > > >This is something we've applied > >successfully on NUT [1] and which > >make things easier on the client > >layer: 1 API, 1 set of names. This > >also allows to provide a complete > >sample config per app. > > > >This is not a so hard task. It just need > >to create the name set from the existing > >remote signal, and rework the remote > >package. > > > Christoph has been thinking about it for some > time. After digging a bit, the naming scheme > of linux input layer seems to be the best way. > See the kernel source "include/linux/input.h" file. > More specifically, look at "Keys and buttons" section > > I've provided a sample converted file (animax) at: > http://arnaud.quette.free.fr/lirc/lircd.conf.animax > > BTW, what to do with _UP & _DOWN symbols (ie > VIDEO_DOWN & VIDEO_UP, matching the same > button, but in pressed or released state) some > remotes defines (like my animax)? Should these > be ripped off, keeping only one occurence, or > should these be assigned the same name (ie > KEY_VIDEO for both, which implies to manage > repeat)? 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. As for the syntax of the config file, that's up to you, of course. > Finally note that this convergence might be the > first step toward a better integration in the input > layer (through remotedev or evdev) > > Update: there are however few lacks in the input > namespace. But I'm sure Vojtech will be open to > update it. Definitely. I'll be harsh judging changes to the API, but where necessary, they will happen to allow full IR remote integration with the input layer. > >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. > > >c) Create a drivers list > >-------------------------------------- > > > >with a format like: > ><manufacturer> <model name> <model extra> <driver> > > > >This would allow: > >- use in wizard and config tool (display a formated list) > >- web compat list generation (as in nut [4]) > >- sniffing by HWDB projects like distro' (Mdk [2], ...), > >FSF' ([3]) > > > >The 3 above principles have been applied, or will be soon, > >to NUT [4] > > > > Christoph is for, and I've started by working on this. > I've changed the format to: > <brand> <model> <supported devices> <driver> <data file> > > Here is a current approximation of the number of > remotes data files: > - about 43 embedded in LIRC: already added to a remotes.list > file I've (http://arnaud.quette.free.fr/lirc/remotes.list) > This is a base, made of the most common remote, that > needs to be completed... > - about 1850 in the remotes archives! > > There is a good amount of work to have a clean and > complete list, but I think the above remotes.list is a > good base, and that it can be completed by digging > deeper the data files, contacting the contributors > and digging the web... > > Any help welcomed... > > >2) bigger changes > >============ > > > >I've no exact idea yet, but a recent acquisition of a usb > >remote (bundled with a laptop) made me think! It's > >a USB/HID remote, exposing both a keyboard and a > >mouse + some more things (not looked at, hiddev seems > >to report something...) > > > >This so made me think that there will be support for > >remote out of lirc. But there should also be a common > >"wrapper" for remote support... to be continued > >The below point 3 might be a part of the answer. There already are bttv-based remote receivers, even some USB TV receivers can receive data from remotes, so it's definitely beyond lirc's scope. > This is linked to point 1) (evdev/remotedev) and integrating > LIRC into the unified linux input layer. That way, the present > point is obsolete. > > >3) X11 driver / embedded protocol > >====================== > > > >Based on a thing I use for my laptop's touchpad [5], this is > >the best input entry point for any GUI! > > Having support through the standard input layer, X11 should > manage the various keys without problem. It also help X11 > developers (ie KDE, Gnome, ...) to focus on a single naming > scheme for multimedia peripherals... Indeed. But a truly generic X11 driver for the linux input layer still doesn't exist. > >I hope all the above will receive a good echo. > >Continue your good work. > > > both are still true ;-) > > >Arnaud > >--- > >[1] http://eu1.networkupstools.org/doc/2.0.0/new-names.html > >[2] http://www.mandrakelinux.com/fr/hardware.php3 > >[3] http://lists.gnu.org/mailman/listinfo/hfdb > >[4] http://eu2.networkupstools.org/compat/stable.html > >[5] http://web.telia.com/~u89404340/touchpad/index.html > >--- > >Opensource Developer - http://arnaud.quette.free.fr > >Debian GNU/Linux Developer - http://people.debian.org/~aquette > > > and these one too, more than ever ;-) > > I've lots more to say, but I lack of time and I'll first > wait for a [positive/constructive] echo... > > See you, > Arnaud > -- Vojtech Pavlik SuSE Labs, SuSE CR |
From: <li...@ba...> - 2005-01-28 16:58:00
|
Hi! Vojtech Pavlik "vo...@su..." wrote: [...] >> It talks about more standardisation in LIRC, and >> a better integration in the linux input layer. All >> this for a better and easier usability... > 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 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. 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. 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. >>>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. Christoph |
From: <li...@ba...> - 2005-01-28 16:58:02
|
Hi! Arnaud Quette "arn...@fr..." wrote: [...] >> 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. >> c) Create a drivers list >> -------------------------------------- >> >> with a format like: >> <manufacturer> <model name> <model extra> <driver> <driver> is not enough. 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. > - 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. > 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. Christoph |
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 |
From: <li...@ba...> - 2005-02-19 09:47:17
|
Hi! Arnaud Quette "arn...@fr..." wrote: [...] >>> 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. [...] > I'll have to dig the list about that. Any pointers welcomed Have a look at the "drop lircd!" thread. http://sourceforge.net/mailarchive/ forum.php?forum_id=5339&max_rows=100&style=threaded&viewmonth=200308 > 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'm not that sure that pressing "1" on a keyboard should have the same effect as pressing the button "1" on a remote control. But I fully agree that there should be the possibility to configure things like this. Feeding events from lircd to the Linux input layer is one possible solution. In fact this already is possible if you use kbdd (http:// www.handhelds.org/moin/moin.cgi/kbdd). The CVS version has LIRC support. >> 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 didn't mean to address you directly, but everybody in general. [...] > 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 ;-) Everybody who is supporting the idea to handle everything inside the kernel and use the kernel input layer as the standard interface uses lirc_i2c and lirc_gpio as examples. Unfortunately it's not that simple. The hardware that uses the drivers mentioned above does decoding of the signals in hardware. That means it's very simple to get the code of the buttons inside the kernel driver and feed it to the input layer. But the majority of the devices that LIRC supports does not decode the IR signals itself. It only makes the signal form available and the signal has to be decoded in software. This can be a very complex task and it's common understanding that this should be done in userspace by lircd. Furthermore other drivers that use a tty, midi, audio device as input, simply can't be squeezed into the suggested interface. Not to mention the possiblity to forward events over the network. I have to make sure that the interfaces make sense for all devices. It might sound complicated to go from kernel to user space and back to kernel space for TV cards, but on the other hand why should we make an exception just for these devices if we have to go that route for all other devices. And even for TV cards it's not all that simple. AFAIK newer Hauppauge devices don't do all decoding in hardware. They also have support for IR blasters that can be used to tranmit IR signals. I'm curious how the current kernel drivers want to make use of this feature. If they already used the LIRC interface instead of the input layer interface, it would be quite easy. [...] > 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. That's what I knew in advance when we had the discussion back then. It was not my decision to do this. Christoph |
From: Gerd K. <kr...@by...> - 2005-02-23 13:00:16
|
li...@ba... (Christoph Bartelmus) writes: > Have a look at the "drop lircd!" thread. > http://sourceforge.net/mailarchive/ > forum.php?forum_id=5339&max_rows=100&style=threaded&viewmonth=200308 Arnaud Quette pointed me here ;) > > 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'm not that sure that pressing "1" on a keyboard should have the same > effect as pressing the button "1" on a remote control. > But I fully agree that there should be the possibility to configure > things like this. It actually is configurable, for the drivers using the linux input layer. You can either let the events pass the usual way through the linux kbd driver and have the "1" on the remote behave exactly like "1" on the keyboard. Or you can let a application/daemon like for example lircd catch and handle these events via /dev/input/event<n>. > Feeding events from lircd to the Linux input layer is one possible > solution. In fact this already is possible if you use kbdd (http:// > www.handhelds.org/moin/moin.cgi/kbdd). The CVS version has LIRC support. I think it would be a good idea to do that for all events, i.e. split the lircd daemon into two parts: one which dispatches the events to the apps and which basically behaves like lircd with --driver=dev/input today. And another one which transforms the raw IR samples received via lirc into key events and feeds them to the input layer via uinput driver. > Everybody who is supporting the idea to handle everything inside the > kernel and use the kernel input layer as the standard interface uses > lirc_i2c and lirc_gpio as examples. Probably because these are real live examples where both lirc and input layer drivers exist. Same is true for the ati usb ones. > But the majority of the devices that LIRC supports does not decode > the IR signals itself. It only makes the signal form available and > the signal has to be decoded in software. This can be a very > complex task and it's common understanding that this should be done > in userspace by lircd. Passing samples to userspace for decoding doesn't come for free either. At least the coding were I've hacked up kernel code for (biphase, for rc5) is not complex, the function doing that is only 40 lines or so. IMHO that is far away from justifying a userspace solution. Might be different for other codings though. > Furthermore other drivers that use a tty, midi, audio device as input, > simply can't be squeezed into the suggested interface. > Not to mention the possiblity to forward events over the network. As mentioned above, you can feed the processes events to the linux input layer for cases where a in-kernel driver doesn't exist or it isn't feasonable to do stuff in-kernel (whats the audio device stuff btw? voice recognition? Or just touch-tones?). > I have to make sure that the interfaces make sense for all devices. For the _processed_ data (i.e. the keystrokes itself) the linux input layer works perfectly fine and IMHO better than lirc. For the _raw_ IR samples received (or to send) it doesn't, yes. For the raw data something like the current lirc drivers will work ok. I don't think the interface must make sense for both raw and processed data, it's fine to use different ones for the two cases. > It might sound complicated to go from kernel to user space and back to > kernel space for TV cards, but on the other hand why should we make an > exception just for these devices if we have to go that route for all > other devices. Why we all devices must be handled the same way? If everything is routed through the linux input layer events can be feeded by either in-kernel drivers or from userspace using the uinput driver. And the applications receiving the IR events don't even notice the difference. > And even for TV cards it's not all that simple. AFAIK newer > Hauppauge devices don't do all decoding in hardware. Yep. No decoding at all to be exact, you just get the raw samples. For that one I do the biphase decoding mentioned above. > They also have support for IR blasters that can be used to tranmit > IR signals. Sure? Never heared that, and it's also not in the cx2388x specs. Given the quality of the specs that doesn't say much though. > I'm curious how the current kernel drivers want to make use of this > feature. If they already used the LIRC interface instead of the input > layer interface, it would be quite easy. Using the lirc interface is *not* easy because it isn't in the mainline kernel. Will be a maintainance nightmare, I learned that lesson with bttv and I will not repeat that. It also isn't exactly user friendly. I will not even think about lirc support until lirc is merged mainline. lirc support could be useful in case of the cx88 driver to do some more advanced stuff with the raw samples than just rc5 decoding. If you want to see that happen go ahead, prepare lirc patches, take that discussion to lkml and get it merged. Ah, and also finally get a non-experimental major number for lirc. > > 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. > > That's what I knew in advance when we had the discussion back then. > It was not my decision to do this. Well, not directly maybe. But indirectly: expecting everyone supporting lirc and not trying to get it merged mainline simply isn't going to work. For drivers living within the linux kernel using the input layer is the only reasonable option at the moment. Gerd -- #define printk(args...) fprintf(stderr, ## args) |
From: <li...@ba...> - 2005-02-24 14:45:15
|
Hi! Gerd Knorr "kr...@by..." wrote: [...] >> Feeding events from lircd to the Linux input layer is one possible >> solution. In fact this already is possible if you use kbdd (http:// >> www.handhelds.org/moin/moin.cgi/kbdd). The CVS version has LIRC support. > I think it would be a good idea to do that for all events, i.e. split > the lircd daemon into two parts: one which dispatches the events to > the apps and which basically behaves like lircd with > --driver=dev/input today. And another one which transforms the raw IR > samples received via lirc into key events and feeds them to the input > layer via uinput driver. That's what we are talking about. [...] >> But the majority of the devices that LIRC supports does not decode >> the IR signals itself. It only makes the signal form available and >> the signal has to be decoded in software. This can be a very >> complex task and it's common understanding that this should be done >> in userspace by lircd. > Passing samples to userspace for decoding doesn't come for free > either. At least the coding were I've hacked up kernel code for > (biphase, for rc5) is not complex, the function doing that is only 40 > lines or so. IMHO that is far away from justifying a userspace > solution. Might be different for other codings though. But you're limited to RC5 only. About every second question about Hauppauge cards here is: can I use my <brand X> remote control instead of the crappy Hauppauge remote with my TV card... [...] > isn't feasonable to do stuff in-kernel (whats the audio device stuff > btw? voice recognition? Or just touch-tones?). Almost. If you connect an IR receiver/diode to your soundcard input you can hear your remote control "sing". ;) >> I have to make sure that the interfaces make sense for all devices. > For the _processed_ data (i.e. the keystrokes itself) the linux input > layer works perfectly fine and IMHO better than lirc. For the _raw_ > IR samples received (or to send) it doesn't, yes. For the raw data > something like the current lirc drivers will work ok. That sounds different from our last discussion. [...] >> They also have support for IR blasters that can be used to tranmit >> IR signals. > Sure? Never heared that, and it's also not in the cx2388x specs. Did you see this: http://hauppauge.lightpath.net/manuals/ir_blaster_eng_web.pdf [...] > lirc support could be useful in case of the cx88 driver to do some > more advanced stuff with the raw samples than just rc5 decoding. If > you want to see that happen go ahead, prepare lirc patches, take that > discussion to lkml and get it merged. Ah, and also finally get a Fact is: if you rely on me doing the work, it won't happen. I'm already investing more into this project than I should. Help is definitely welcome. Christoph |
From: Gerd K. <kr...@by...> - 2005-02-24 15:25:29
|
> > --driver=dev/input today. And another one which transforms the raw IR > > samples received via lirc into key events and feeds them to the input > > layer via uinput driver. > > That's what we are talking about. Ah, ok, didn't roll up the whole thread, was already expired in gnus ... > But you're limited to RC5 only. Yep. rc6 should be easy as it's biphase coded as well, others will need more work. > About every second question about Hauppauge cards here is: can I use > my <brand X> remote control instead of the crappy Hauppauge remote > with my TV card... Oh. Didn't notice yet, usually I don't do more than a quick subject scan on this list due to lack of time ... > >> They also have support for IR blasters that can be used to tranmit > >> IR signals. > > > Sure? Never heared that, and it's also not in the cx2388x specs. > > Did you see this: > http://hauppauge.lightpath.net/manuals/ir_blaster_eng_web.pdf Not yet. They don't mention which cards this applies to though. Probably only the newer cx2388x based ones. > > you want to see that happen go ahead, prepare lirc patches, take that > > discussion to lkml and get it merged. Ah, and also finally get a > > Fact is: if you rely on me doing the work, it won't happen. I can't do it as well. Due to lack of time (see above ;), I already have too many projects I care about. And also I don't know enougth about the non-tv card stuff. Gerd -- #define printk(args...) fprintf(stderr, ## args) |
From: Arnaud Q. <arn...@fr...> - 2005-02-24 21:44:20
|
Hi there, As there were a lot of subjects in the thread I launched, I've decided to split it up in as much part as subjects... Thus, it will result in the following sub-threads(with a small summary): 1) remotes.list (aka "Create a drivers list"): the aim of that point is to allow the creation of configuration wizard, and a Lirc HWDB (Hardware DataBase) for various usages. 2) common namespace (aka "key standardization", or "Create a common naming scheme") It's clear that having all the remotes in the same namespace would allow to have standardised lircrc config (not considering the potential partial merge into the input layer), with alternate config, and so on... Needless to talk once more about graphical config wizard. 3) architecture standardisation this is the major point we're discussing. Chris, Gerd and Vojtech: can you make some dia diagrams to sum up the current situation, and the possibilities? 4) Other points (might result in one thread per idea) these points have lower priority, and need some more thinking: - having all drivers compiled (aka no need to recompile lirc to activate the support of remote X) - unified X11 input driver, and things like that <add here any forgotten ideas and tasks...> Gerd Knorr a =E9crit : >Christopher a =E9crit : > >>>you want to see that happen go ahead, prepare lirc patches, take that >>>discussion to lkml and get it merged. Ah, and also finally get a >>> =20 >>> >>Fact is: if you rely on me doing the work, it won't happen. >> =20 >> > >I can't do it as well. Due to lack of time (see above ;), I already >have too many projects I care about. And also I don't know enougth >about the non-tv card stuff. > =20 > the clear fact is that all 4 of us (Christopher, Gerd, Vojtech and I) are all in charge of at least 1 big FS project! But the good point is that we seem to want to reach a rough consensus to find the best solution for remote support. And that makes me happy ;-) Christopher and all: I think that continuing the talk to find, state and explain the solutions to the various points above would allow to call for help on the list and other source (brave gnu world, LUG, ...). LIRC is a major projects, and having tasks clearly identified would make things easy for other developers to help on a specific point... @Gerd and Vojtech: you should officially join the sf team! See you soon for the next parts, Arnaud --- OpenSource Developer - http://arnaud.quette.free.fr/ Debian Developer - http://people.debian.org/~aquette/ ... and much more ... |
From: <li...@ba...> - 2005-02-26 21:49:42
|
Hi! Arnaud Quette "arn...@fr..." wrote: [...] > 3) architecture standardisation > this is the major point we're discussing. > Chris, Gerd and Vojtech: can you make some dia diagrams > to sum up the current situation, and the possibilities? I don't think the current architecture is the problem. As Gerd pointed out the real problem is that LIRC is not included in the =20 standard kernel release. From his point of view he is absolutely right. [...] > Christopher and all: I think that continuing the talk to find, > state and explain the solutions to the various points above > would allow to call for help on the list and other source > (brave gnu world, LUG, ...). LIRC is a major projects, and > having tasks clearly identified would make things easy > for other developers to help on a specific point... We would need somebody with kernel driver experience who would pick up =20 the task to tidy up the LIRC drivers and make them ready for inclusion =20 into the kernel. Christoph |
From: Arnaud Q. <arn...@fr...> - 2005-02-28 19:13:24
|
Hi Christoph Bartelmus a =E9crit : >Arnaud Quette "arn...@fr..." wrote: >[...] > =20 > >>3) architecture standardisation >>this is the major point we're discussing. >>Chris, Gerd and Vojtech: can you make some dia diagrams >>to sum up the current situation, and the possibilities? >> =20 >> > >I don't think the current architecture is the problem. > =20 > though it needs some improvements, as also told by Gerd! >As Gerd pointed out the real problem is that LIRC is not included in the= =20 >standard kernel release. From his point of view he is absolutely right. > > =20 > I do think too. what is exaclty stopping lirc from going into the mainline? =20 >[...] > =20 > >>Christopher and all: I think that continuing the talk to find, >>state and explain the solutions to the various points above >>would allow to call for help on the list and other source >>(brave gnu world, LUG, ...). LIRC is a major projects, and >>having tasks clearly identified would make things easy >>for other developers to help on a specific point... >> =20 >> > >We would need somebody with kernel driver experience who would pick up =20 >the task to tidy up the LIRC drivers and make them ready for inclusion =20 >into the kernel. > =20 > you should create a task (job) on sf.net, so we could then point this to call for help more widely. + see above See you, Arnaud |
From: Arnaud Q. <arn...@fr...> - 2005-03-01 19:14:08
|
Arnaud Quette a =E9crit : > [...] > you should create a task (job) on sf.net note that I would have done it if I could (project developer don't have the right to do so...) Arnaud |
From: Arnaud Q. <arn...@fr...> - 2005-02-24 22:28:52
|
Hi there, As things have evolved, there are points that need to be discussed to be sure that things will be fine... As stated in my previous mail ("splitting up thread"), the aim of that point is to allow the creation of 2 things: 1) [graphical] configuration wizards: - simple case: you simply select your brand/model, and the conf is generated (lircd+lircrc, but the later implies the "common namespace) - harder case: you need to choose the receiver and the remote (based on Chris remarks: "can I use my <brand X> remote control insteadof the crappy Hauppauge remote with my TV card"...). I don't have sufficient lirc knowledges to tell if the remotes.list file will be sufficient... But it should, considering the 2 fields "model" (remote model) and "supported devices" (receiver, ie standalone serial, tv card receiver, ...) @Chris and all: expertise welcomed. Once more, independantly from the "architecture standardisation" and "common namespace" threads, we should allow to build at best any config, and at least the most used. Some exotic one might (will) need manual editing, but in general, that will be the choice of power users... 2) a Lirc HWDB (Hardware DataBase), either static (as in NUT (http://eu1.networkupstools.org/compat/stable.html), or in alsa (http://www.alsa-project.org/alsa-doc/)). Thus, this file will store a lot of information. I've previously proposed the following file format: <brand> <model> <supported devices> <lircd_driver> <kernel_driver> <data file> >[...] > > >>- 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. > > > considering the above remarks, I'm now not so sure if I must remove these... >>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. > > same remark as above, but with lower and huger work. btw, "will work with any device that uses the MODE2 interface" doesn't mean that we have not to select a receiver type (lirc_*) or am I wrong? take your time to answer, we're not on a time trial ;-) See you, Arnaud --- OpenSource Developer - http://arnaud.quette.free.fr/ Debian Developer - http://people.debian.org/~aquette/ ... and much more ... |
From: <li...@ba...> - 2005-02-26 21:49:41
|
Hi! Arnaud Quette "arn...@fr..." wrote: [...] > 1) [graphical] configuration wizards: > - simple case: you simply select your brand/model, and > the conf is generated (lircd+lircrc, but the later implies > the "common namespace) Except the lircrc part, we have this already. That's exactly what setup.sh does. What I'd like to have is the information that is coded inside setup.sh and configure in a human readable form. Using wizards is great, but for the cases when the wizard fails or the use case is more complicated so it can't be handled by a wizard, the user should have the information for manual configuration. Currently this information is well hidden inside setup.data and configure.in. OTOH Debian already is using setup.data to implement an installation wizard. It already is possible but it probably can be improved. [...] > Thus, this file will store a lot of information. > > I've previously proposed the following file format: > <brand> <model> <supported devices> <lircd_driver> > <kernel_driver> <data file> I think you might still have some misconceptions regarding the config files and the hardware supported by LIRC. You can devide the receivers mainly in 3 categories: A) Low layer receivers AKA MODE2 receivers These are "dumb" receivers that only are able to capture the raw signals of the remote. Decoding has to be done in software but the advantage is that these receivers can be used with almost any remote control and that they deliver enough information to reproduce the IR signal with a transmitter. The config files found on lirc.org are for these types of receivers. The home-brew serial and parallel port receivers are the most often used devices of this type. But also e.g. The Streamzap USB receiver and some Hauppauge cards have this capability. B) Universal hardware-decoding receivers These do decoding in hardware. They still can be used with almost any remote, but they don't provide enough information to reproduce the original signal. Usually they require a different kind of config file. Most prominent representative of this type is the Irman and similar devices. Config files for the Irman have a .irman extension on lirc.org. C) Bundled products These do decoding of the signal in hardware and only react to the remote control bundled with the product. Most TV cards fall into this category. The config files for these devices only work with the dedicated hardware. Therefore the config files are included in the LIRC software package and are installed automaitcially if you select one of these devices in setup.sh. In reality everything is much more complicated as devices can have properties of different categories and there are many exceptions to the rules above. But it should be enough to get a rough picture. Christoph |