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
|