To standardize the key naming, I think we should rewrite irrecord to use a=
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=
just asked the user to press the "ok" button, etc., the user may not select=
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=
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
> 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=
> 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  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:
> 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
> 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 )
> > - sniffing by HWDB projects like distro' (Mdk , ...),
> > FSF' ()
> > The 3 above principles have been applied, or will be soon,
> > to NUT 
> 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 , 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
> > ---
> >  http://eu1.networkupstools.org/doc/2.0.0/new-names.html
> >  http://www.mandrakelinux.com/fr/hardware.php3
> >  http://lists.gnu.org/mailman/listinfo/hfdb
> >  http://eu2.networkupstools.org/compat/stable.html
> >  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,
> 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