linux-kernel - Re: [RFC] What are the goals for the architecture of an in-kernel IR system?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 28 Nov 2009 18:26:55 -0500
From:	Andy Walls <awalls@...ix.net>
To:	Jon Smirl <jonsmirl@...il.com>
Cc:	Krzysztof Halasa <khc@...waw.pl>,
	Christoph Bartelmus <lirc@...telmus.de>,
	dmitry.torokhov@...il.com, j@...nau.net, jarod@...hat.com,
	jarod@...sonet.com, linux-input@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-media@...r.kernel.org,
	maximlevitsky@...il.com, mchehab@...hat.com,
	stefanr@...6.in-berlin.de, superm1@...ntu.com
Subject: Re: [RFC] What are the goals for the architecture of an in-kernel
 IR  system?

Jon,

On Sat, 2009-11-28 at 12:37 -0500, Jon Smirl wrote:
> On Sat, Nov 28, 2009 at 12:35 PM, Krzysztof Halasa <khc@...waw.pl> wrote:
> > Jon Smirl <jonsmirl@...il.com> writes:
> >
> >> There are two very basic things that we need to reach consensus on first.
> >>
> >> 1) Unification with mouse/keyboard in evdev - put IR on equal footing.

The only thing this buys for the user is remote/products bundles that
work out of the box.  That can only be a solution for the 80% case.

I don't hear users crying out "Please integrate IR with the input
system".  I do hear users say "I want my remote to work", and "How can I
make my remote work?".  Users are not specifically asking for this
integration of IR and the input system - a technical nuance.  If such a
tecnical desire-ment drives excessive rework, I doubt anyone will care
enough about IR to follow through to make a complete system.

What does "equal footing" mean as an incentive anyway?  The opportunity
to reimplement *everything* that exists for IR already over again in
kernel-space for the sake of developer technical desires?  That's just a
lot of work for "not invented here" syndrome.  IR transceivers are
arguably superior to keyboards and mice anyway because they can transmit
data too.

> >> 2) Specific tools (xmodmap, setkeycodes, etc or the LIRC ones) or
> >> generic tools (ls, mkdir, echo) for configuration
> >
> > I think we can do this gradually:
> > 1. Merging the lirc drivers. The only stable thing needed is lirc
> >   interface.
> 
> Doing that locks in a user space API that needs to be supported
> forever. We need to think this API through before locking it in.

No one get things right the first time - No one.

Most designs are iterated with prototypes in the commercial world.
Prototypes keep costs low so you can throw it away easily and try a new
approach, if the current approach is not panning out

Only governements try to get everything right on the first go.  It takes
them too long and the end product is usually still hosed.

Whatever gets developed won't be locked in for 20 years, that's absurd.
Technology moves on 6 month to two year cycles.  Linux changes ABIs too.
V4L transitioned from V4L1 to V4L2 and that's happened in less than 20
years for a much more complex set of devices with a more varied set of
userspace apps.

Regards,
Andy

> > 2. Changing IR input layer interface ("media" drivers and adding to lirc
> >   drivers).
> > --
> > Krzysztof Halasa

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/