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  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 20:50:46 -0800
From:	Dmitry Torokhov <>
To:	Andy Walls <>
Cc:	Jon Smirl <>, Krzysztof Halasa <>,
	Christoph Bartelmus <>,,,,,,,,,,
Subject: Re: [RFC] What are the goals for the architecture of an in-kernel
	IR  system?

On Sat, Nov 28, 2009 at 11:32:01PM -0500, Andy Walls wrote:
> On Sat, 2009-11-28 at 12:37 -0500, Jon Smirl wrote:
> > On Sat, Nov 28, 2009 at 12:35 PM, Krzysztof Halasa <> wrote:
> > > Jon Smirl <> 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.
> BTW, circa 1995 my serial mouse "Just Worked" in Linux.  Sometime around
> the release of Fedora Core 3 or 4, serial mice stopped being well
> supported as input devices AFAICT.  (I still have a dual boot
> Windows95/Linux machine with a serial mouse because it has ISA slots.)

serport + sermouse combo should work well. At least I don't get any bug
reports ;P

> Are serial port connected IR devices going to see the same fate in this
> model?
> Why not consider IR devices as bi-directional communications devices vs.
> input devices like mice or keyboards?  Theoretically the TTY layer with
> line discipline modules for underlying IR hardware could also interface
> IR devices to user space.
> Sorry, the input subsystem cannot meet all the end user IR requirements.

Again, what end users are you taling about here? An application that
wants to prcess key (or button) presses? Or something entirely
different, lice lirc itself?

> I doubt it could easily support all the current user space only IR
> drivers moving into the kernel.  I suspect the serial port connected IR
> devices will be deemed "too hard" and IR Tx as "not input" and dropped
> on the floor.
> The more I think about IR integration with input, the more I think any
> effort beyond the plug-and-plug for default configurations is a waste of
> time and effort.  Something more is needed to handle the transmitters
> and serial connected IRs.  It's also too convenient to access USB IR
> hardware from existing userspace drivers to bother porting into the
> kernel.

Having support 2 different interfaces for regular applications is also a
waste of time and effort. The applications who don;t care about IRC
protocol decoding should be able to just work with standard input

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists