On Fri, 2009-12-04 at 22:45 -0500, Jon Smirl wrote:
On Fri, Dec 4, 2009 at 8:48 PM, Andy Walls awa...@radix.net wrote:
On Fri, 2009-12-04 at 19:28 -0500, Jon Smirl wrote:
On Fri, Dec 4, 2009 at 6:01 PM, Christoph Bartelmus l...@bartelmus.de
wrote:
BTW, I just came across a XMP remote
Hi,
Am Freitag, den 04.12.2009, 19:28 -0500 schrieb Jon Smirl:
On Fri, Dec 4, 2009 at 6:01 PM, Christoph Bartelmus l...@bartelmus.de wrote:
BTW, I just came across a XMP remote that seems to generate 3x64 bit scan
codes. Anyone here has docs on the XMP protocol?
Assuming a general purpose
Hi,
On Sun, Dec 06, 2009 at 04:36:33AM +0100, hermann pitton wrote:
Hi,
Am Freitag, den 04.12.2009, 19:28 -0500 schrieb Jon Smirl:
On Fri, Dec 4, 2009 at 6:01 PM, Christoph Bartelmus l...@bartelmus.de
wrote:
BTW, I just came across a XMP remote that seems to generate 3x64 bit scan
On Fri, Dec 04, 2009 at 12:12:34PM -0200, Mauro Carvalho Chehab wrote:
Em Fri, 4 Dec 2009 02:06:42 -0800
Dmitry Torokhov dmitry.torok...@gmail.com escreveu:
evdev does not really care what you use as scancode. So nobody stops
your driver to report index as a scancode and accept
On Fri, Dec 04, 2009 at 12:12:34PM -0200, Mauro Carvalho Chehab wrote:
How related lirc-core to the current lirc code? If it is not the same
maybe we should not call it lirc to avoid confusion.
Just for better illustrate what I'm seeing, I broke the IR generic
code into two
On Thu, Dec 03, 2009 at 04:33:28PM -0200, Mauro Carvalho Chehab wrote:
Let me draw my view:
Em Thu, 3 Dec 2009 09:55:31 -0800
Dmitry Torokhov dmitry.torok...@gmail.com escreveu:
No, please, wait just a minute. I know it is tempting to just merge
lirc_dev and start working, but can we
Em Fri, 4 Dec 2009 02:06:42 -0800
Dmitry Torokhov dmitry.torok...@gmail.com escreveu:
On Thu, Dec 03, 2009 at 04:33:28PM -0200, Mauro Carvalho Chehab wrote:
Let me draw my view:
Em Thu, 3 Dec 2009 09:55:31 -0800
Dmitry Torokhov dmitry.torok...@gmail.com escreveu:
No, please, wait
Christoph Bartelmus wrote:
Hi Dmitry,
on 03 Dec 09 at 14:12, Dmitry Torokhov wrote:
[...]
Consider passing the decoded data through lirc_dev.
[...]
I believe it was agreed that lirc-dev should be used mainly for decoding
protocols that are more conveniently decoded in userspace and the
On Fri, Dec 4, 2009 at 9:12 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
In-kernel decoding:
[IR physical device] = [IR receiver driver] = [LIRC core] =
[decoder] = [IR core] = [input core] = [evdev]
||
Hi Mauro,
on 04 Dec 09 at 12:33, Mauro Carvalho Chehab wrote:
Christoph Bartelmus wrote:
Consider passing the decoded data through lirc_dev.
[...]
Consider cases like this:
http://lirc.sourceforge.net/remotes/lg/6711A20015N
This is an air-conditioner remote.
The entries that you see in
On Fri, Dec 04, 2009 at 10:46:00PM +0100, Christoph Bartelmus wrote:
Hi Mauro,
on 04 Dec 09 at 12:33, Mauro Carvalho Chehab wrote:
Christoph Bartelmus wrote:
Consider passing the decoded data through lirc_dev.
[...]
Consider cases like this:
Hi Dmitry,
on 04 Dec 09 at 14:07, Dmitry Torokhov wrote:
On Fri, Dec 04, 2009 at 10:46:00PM +0100, Christoph Bartelmus wrote:
Hi Mauro,
on 04 Dec 09 at 12:33, Mauro Carvalho Chehab wrote:
Christoph Bartelmus wrote:
Consider passing the decoded data through lirc_dev.
[...]
Consider cases
On Sat, Dec 05, 2009 at 12:01:00AM +0100, Christoph Bartelmus wrote:
Hi Dmitry,
on 04 Dec 09 at 14:07, Dmitry Torokhov wrote:
On Fri, Dec 04, 2009 at 10:46:00PM +0100, Christoph Bartelmus wrote:
Hi Mauro,
on 04 Dec 09 at 12:33, Mauro Carvalho Chehab wrote:
Christoph Bartelmus wrote:
On Fri, Dec 4, 2009 at 6:01 PM, Christoph Bartelmus l...@bartelmus.de wrote:
BTW, I just came across a XMP remote that seems to generate 3x64 bit scan
codes. Anyone here has docs on the XMP protocol?
Assuming a general purpose receiver (not one with fixed hardware
decoding), is it important for
On Fri, 2009-12-04 at 19:28 -0500, Jon Smirl wrote:
On Fri, Dec 4, 2009 at 6:01 PM, Christoph Bartelmus l...@bartelmus.de wrote:
BTW, I just came across a XMP remote that seems to generate 3x64 bit scan
codes. Anyone here has docs on the XMP protocol?
Assuming a general purpose receiver
On Fri, 2009-12-04 at 20:48 -0500, Andy Walls wrote:
On Fri, 2009-12-04 at 19:28 -0500, Jon Smirl wrote:
On Fri, Dec 4, 2009 at 6:01 PM, Christoph Bartelmus l...@bartelmus.de
wrote:
BTW, I just came across a XMP remote that seems to generate 3x64 bit scan
codes. Anyone here has docs on
On Fri, Dec 4, 2009 at 8:48 PM, Andy Walls awa...@radix.net wrote:
On Fri, 2009-12-04 at 19:28 -0500, Jon Smirl wrote:
On Fri, Dec 4, 2009 at 6:01 PM, Christoph Bartelmus l...@bartelmus.de
wrote:
BTW, I just came across a XMP remote that seems to generate 3x64 bit scan
codes. Anyone here
On 12/03/09 05:29, Jarod Wilson wrote:
On Dec 1, 2009, at 10:28 AM, Gerd Hoffmann wrote:
Anyway, we shouldn't postpone lirc drivers addition due to that.
There are still lots of work to do before we'll be able to split
the tables from the kernel drivers.
Indeed. The sysfs bits are future
l...@bartelmus.de (Christoph Bartelmus) writes:
Currently I would tend to an approach like this:
- raw interface to userspace using LIRC
- fixed set of in-kernel decoders that can handle bundled remotes
I'd modify it a bit:
- raw interface to userspace using LIRC
- fixed set of in-kernel
Gerd Hoffmann kra...@redhat.com writes:
I'd pick a more descriptive name like 'bundled_remote'.
Maybe an additional attribute could say which protocol the bundled
remote speaks (rc5, ...), so userspace could do something sensible by
default even if it has no data about the bundled remote.
On Thu, Dec 03, 2009 at 01:09:14PM +0100, Gerd Hoffmann wrote:
On 12/03/09 05:29, Jarod Wilson wrote:
On Dec 1, 2009, at 10:28 AM, Gerd Hoffmann wrote:
Anyway, we shouldn't postpone lirc drivers addition due to that.
There are still lots of work to do before we'll be able to split
the tables
Let me draw my view:
Em Thu, 3 Dec 2009 09:55:31 -0800
Dmitry Torokhov dmitry.torok...@gmail.com escreveu:
No, please, wait just a minute. I know it is tempting to just merge
lirc_dev and start working, but can we first agree on the overall
subsystem structure before doing so. It is still
On Thu, Dec 3, 2009 at 12:55 PM, Dmitry Torokhov
dmitry.torok...@gmail.com wrote:
On Thu, Dec 03, 2009 at 01:09:14PM +0100, Gerd Hoffmann wrote:
On 12/03/09 05:29, Jarod Wilson wrote:
On Dec 1, 2009, at 10:28 AM, Gerd Hoffmann wrote:
Anyway, we shouldn't postpone lirc drivers addition due to
Hi Mauro,
on 03 Dec 09 at 19:10, Mauro Carvalho Chehab wrote:
[...]
So the lirc_imon I submitted supports all device types, with the
onboard decode devices defaulting to operating as pure input devices,
but an option to pass hex values out via the lirc interface (which is
how they've
On Thu, Dec 03, 2009 at 10:51:00PM +0100, Christoph Bartelmus wrote:
Hi Mauro,
on 03 Dec 09 at 19:10, Mauro Carvalho Chehab wrote:
[...]
So the lirc_imon I submitted supports all device types, with the
onboard decode devices defaulting to operating as pure input devices,
but an option
Hi Dmitry,
on 03 Dec 09 at 14:12, Dmitry Torokhov wrote:
[...]
Consider passing the decoded data through lirc_dev.
[...]
I believe it was agreed that lirc-dev should be used mainly for decoding
protocols that are more conveniently decoded in userspace and the
results would be looped back into
On Dec 1, 2009, at 10:28 AM, Gerd Hoffmann wrote:
Anyway, we shouldn't postpone lirc drivers addition due to that. There are
still lots of work
to do before we'll be able to split the tables from the kernel drivers.
Indeed. The sysfs bits are future work for both lirc and evdev drivers.
Hi,
The point is that for simple usage, like an user plugging his new USB stick
he just bought, he should be able to use the shipped IR without needing to
configure anything or manually calling any daemon. This currently works
with the existing drivers and it is a feature that needs to be
Hi,
A current related problem is that i2c based devices can only be bound to
only one of ir-kbd-i2c *or* lirc_i2c *or* lirc_zilog at any one time.
Currently it is somewhat up to the bridge driver which binding is
preferred. Discussion about this for the pvrusb2 module had the biggest
email
On Tue, 2009-12-01 at 08:45 +0100, Christoph Bartelmus wrote:
Hi Jon,
on 30 Nov 09 at 16:35, Jon Smirl wrote:
Currently I would tend to an approach like this:
- raw interface to userspace using LIRC
- fixed set of in-kernel decoders that can handle bundled remotes
That would allow zero
On Tue, 2009-12-01 at 06:38 -0500, Andy Walls wrote:
On Tue, 2009-12-01 at 08:45 +0100, Christoph Bartelmus wrote:
Hi Jon,
on 30 Nov 09 at 16:35, Jon Smirl wrote:
Currently I would tend to an approach like this:
- raw interface to userspace using LIRC
- fixed set of in-kernel
Gerd Hoffmann wrote:
On 12/01/09 12:49, Andy Walls wrote:
On Tue, 2009-12-01 at 11:46 +0100, Gerd Hoffmann wrote:
Once lirc_dev is merged you can easily fix this: You'll have *one*
driver which supports *both* evdev and lirc interfaces. If lircd opens
the lirc interface raw data will be
On Dec 1, 2009, at 4:52 AM, Gerd Hoffmann wrote:
On 11/30/09 13:34, Mauro Carvalho Chehab wrote:
Christoph Bartelmus wrote:
Hi Mauro,
I just don't want to change a working interface just because it could be
also implemented in a different way, but having no other visible advantage
than
Hi,
The big issue here is: how do we document that EM28xxHVR950-00 is the
Hauppauge Grey IR that
is shipped with their newer devices.
A third approach would be to identify, instead, the Remote Controller directly.
So, we would
add a sysfs field like ir_type.
I'd pick a more descriptive
Hi Alan,
Alan Cox wrote:
Does it really make sense to put big chunks of protocol decoding crap for
an interface which runs at about 1 character per second on a good day
into the kernel ? Does it really make sense ot move 50K of code from user
context to kernel context where it must meet
Andy Walls wrote:
On Sun, 2009-11-29 at 09:49 -0800, Ray Lee wrote:
On Sun, Nov 29, 2009 at 9:28 AM, Maxim Levitsky maximlevit...@gmail.com
wrote:
This has zero advantages besides good developer feeling that My system
has one less daemon...
Surely it's clear that having an unnecessary
Christoph Bartelmus wrote:
Hi Mauro,
I just don't want to change a working interface just because it could be
also implemented in a different way, but having no other visible advantage
than using more recent kernel features.
I agree. The main reasons to review the interface is:
On Mon, Nov 30, 2009 at 7:57 AM, Andy Walls awa...@radix.net wrote:
I suppose my best answer to that is question back to you: Why does udev
run in userspace versus a kernel thread?
Because udev is a scripting system. I've always said that the
scripting piece of IR belongs in user space. IR
On Mon, 2009-11-30 at 07:57 -0500, Andy Walls wrote:
On Mon, 2009-11-30 at 09:56 -0200, Mauro Carvalho Chehab wrote:
Andy Walls wrote:
On Sun, 2009-11-29 at 09:49 -0800, Ray Lee wrote:
On Sun, Nov 29, 2009 at 9:28 AM, Maxim Levitsky
maximlevit...@gmail.com wrote:
This has zero
On Mon, Nov 30, 2009 at 8:43 AM, Maxim Levitsky maximlevit...@gmail.com wrote:
On Mon, 2009-11-30 at 07:57 -0500, Andy Walls wrote:
On Mon, 2009-11-30 at 09:56 -0200, Mauro Carvalho Chehab wrote:
Andy Walls wrote:
On Sun, 2009-11-29 at 09:49 -0800, Ray Lee wrote:
On Sun, Nov 29, 2009 at
On Mon, Nov 30, 2009 at 7:24 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
After the boot, a device can open the raw API, disabling any in-kernel
decoding/handling and handle IR directly. Alternatively, an udev rule
can load a different keymap based on some config written on a file.
Andy Walls wrote:
Nonetheless I'd still rather debug a problem with a dead process in
userspace than an oops or panic (not that an end user cares) and avoid
the risk of filesystem corruption.
Considering my experience adding in-kernel support for IR's, I'd say that
in general, a driver does
On Sat, Nov 28, 2009 at 06:26:55PM -0500, Andy Walls wrote:
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
On Mon, Nov 30, 2009 at 03:33:52PM -0200, Mauro Carvalho Chehab wrote:
kevin granade wrote:
On Mon, Nov 30, 2009 at 7:24 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
After the boot, a device can open the raw API, disabling any in-kernel
decoding/handling and handle IR directly.
Dmitry Torokhov wrote:
On Mon, Nov 30, 2009 at 03:33:52PM -0200, Mauro Carvalho Chehab wrote:
kevin granade wrote:
On Mon, Nov 30, 2009 at 7:24 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
After the boot, a device can open the raw API, disabling any in-kernel
decoding/handling and
Mauro Carvalho Chehab mche...@redhat.com writes:
That's a question that I have not answered for myself concludingly.
Is a remote control really on exactly the same level as a keyboard or
mouse?
On some devices like STB and TV sets (most of modern LCD/Plasma TV's
run Linux),
they are at
Andy Walls awa...@radix.net writes:
Nonetheless I'd still rather debug a problem with a dead process in
userspace than an oops or panic (not that an end user cares) and avoid
the risk of filesystem corruption.
I'll concentrate on IRQ-driven space/mark drivers/devices since it's
what I've been
kevin granade kevin.gran...@gmail.com writes:
This idea of the in-kernel decoding being disabled when the raw API is
opened worries me.
I don't think we need to disable the in-kernel decoding automatically.
That would be rather unfortunate.
--
Krzysztof Halasa
--
To unsubscribe from this
On Sun, Nov 29, 2009 at 7:01 AM, Christoph Bartelmus l...@bartelmus.de wrote:
Hi Jon,
on 27 Nov 09 at 12:49, Jon Smirl wrote:
[...]
Christoph, take what you know from all of the years of working on LIRC
and design the perfect in-kernel system. This is the big chance to
redesign IR support
Hi Jon,
on 30 Nov 09 at 16:35, Jon Smirl wrote:
[...]
It would be interesting to split the lirc daemon. Put the protocol
decoder stuff in one daemon and the scripting support in the other.
The scripting daemon would then be optional. What would be the
relative sizes of the two daemons?
Hi Jon,
on 27 Nov 09 at 12:49, Jon Smirl wrote:
[...]
Christoph, take what you know from all of the years of working on LIRC
and design the perfect in-kernel system. This is the big chance to
redesign IR support and get rid of any past mistakes. Incorporate any
useful chunks of code and
Hi Mauro,
on 28 Nov 09 at 09:21, Mauro Carvalho Chehab wrote:
Hi Christoph,
Christoph Bartelmus wrote:
Maybe we decide to take the existing LIRC system as is and not
integrate it into the input subsystem. But I think there is a window
here to update the LIRC design to use the latest kernel
Hi Krzysztof,
on 28 Nov 09 at 18:21, Krzysztof Halasa wrote:
[...]
This remote uses RC-5. But some of the developers must have thought that
it may be a smart idea to use 14 bits instead the standard 13 bits for
this remote. In LIRC you won't care, because this is configurable and
irrecord
Hi Stefan,
on 28 Nov 09 at 21:29, Stefan Richter wrote:
Jon Smirl wrote:
On Sat, Nov 28, 2009 at 2:45 PM, Stefan Richter
stef...@s5r6.in-berlin.de wrote:
Jon Smirl wrote:
Also, how do you create the devices for each remote? You would need to
create these devices before being able to do
BTW, circa 1995 my serial mouse Just Worked in Linux. Sometime around
Correct X11 just talked to the serial ports. In fact that is still the
way to configure it if you want any sanity in life.
and serial connected IRs. It's also too convenient to access USB IR
hardware from existing
Jon Smirl wrote:
On Sat, Nov 28, 2009 at 2:45 PM, Stefan Richter
stef...@s5r6.in-berlin.de wrote:
Jon Smirl wrote:
Also, how do you create the devices for each remote? You would need to
create these devices before being able to do EVIOCSKEYCODE to them.
The input subsystem creates devices on
Jon Smirl wrote:
I'm looking at a Sony multi-function remote right now. It has five
devices and forty keys. Each of the five devices can transmit 0-9,
power, volume, etc. It transmits 5*40 = 200 unique scancodes.
I want the five devices to correspond to five apps. What's the plan
for
Jon Smirl wrote:
On Sat, Nov 28, 2009 at 4:46 PM, Stefan Richter
stef...@s5r6.in-berlin.de wrote:
Jon Smirl wrote:
On Sat, Nov 28, 2009 at 3:29 PM, Stefan Richter
stef...@s5r6.in-berlin.de wrote:
Jon Smirl wrote:
We have one IR receiver device and multiple remotes. How does the
input
On Sun, 2009-11-29 at 12:40 +, Alan Cox wrote:
BTW, circa 1995 my serial mouse Just Worked in Linux. Sometime around
Correct X11 just talked to the serial ports. In fact that is still the
way to configure it if you want any sanity in life.
and serial connected IRs. It's also too
On Sun, Nov 29, 2009 at 9:28 AM, Maxim Levitsky maximlevit...@gmail.com wrote:
This has zero advantages besides good developer feeling that My system
has one less daemon...
Surely it's clear that having an unnecessary daemon is introducing
another point of failure? Reducing complexity is not
If decoding can *only* be sanely handled in user-space, that's one
thing. If it can be handled in kernel, then that would be better.
Why ?
I can compute fast fourier transforms in the kernel but that doesn't make
it better than doing it in user space. I can write web servers in the
kernel and
On Sun, Nov 29, 2009 at 10:13 AM, Alan Cox a...@lxorguk.ukuu.org.uk wrote:
If decoding can *only* be sanely handled in user-space, that's one
thing. If it can be handled in kernel, then that would be better.
Why ?
I can compute fast fourier transforms in the kernel but that doesn't make
it
Half of the drivers are in user space and there are two different
classes of kernel driver - LIRC and V4L.
A lot of the hardware doesn't identify itself.
There are two types of IR data in use - pulse timing and decoded protocol.
IR is an input device. We have a nice evdev input subsystem
Jon is asking for an architecture discussion, y'know, with use cases.
Maxim seems to be saying it's obvious that what we have today works
fine. Except it doesn't appear that we have a consensus that
everything is fine, nor an obvious winner for how to reduce the
complexity here and keep the
On Sun, Nov 29, 2009 at 2:04 PM, Alan Cox a...@lxorguk.ukuu.org.uk wrote:
Jon is asking for an architecture discussion, y'know, with use cases.
Maxim seems to be saying it's obvious that what we have today works
fine. Except it doesn't appear that we have a consensus that
everything is fine,
So we're just back to the status quo of last year which is to do
nothing except some minor clean up.
Which in itself is vastly preferable to some grandiose scheme that turns
out to be wrong.
And no it's not a back to the status quo, it's a request to discuss the
actual problems and options not
Hi,
on 29 Nov 09 at 14:16, Jon Smirl wrote:
On Sun, Nov 29, 2009 at 2:04 PM, Alan Cox a...@lxorguk.ukuu.org.uk wrote:
Jon is asking for an architecture discussion, y'know, with use cases.
[...]
So we're just back to the status quo of last year which is to do
nothing except some minor clean
1. Do we agree that a lirc (-style) kernel-user interface is needed at
least?
2. Is there any problem with lirc kernel-user interface?
If the answer for #1 is yes and for #2 is no then perhaps we merge
the Jarod's lirc patches (at least the core) so at least the
non-controversial part is
On Sun, Nov 29, 2009 at 3:27 PM, Krzysztof Halasa k...@pm.waw.pl wrote:
1. Do we agree that a lirc (-style) kernel-user interface is needed at
least?
2. Is there any problem with lirc kernel-user interface?
Can you consider sending the raw IR data as a new evdev message type
instead of
On Nov 29, 2009, at 12:44 PM, Jon Smirl jonsm...@gmail.com wrote:
On Sun, Nov 29, 2009 at 3:27 PM, Krzysztof Halasa k...@pm.waw.pl
wrote:
1. Do we agree that a lirc (-style) kernel-user interface is needed
at
least?
2. Is there any problem with lirc kernel-user interface?
Can you
On Nov 29, 2009, at 12:27 PM, Krzysztof Halasa k...@pm.waw.pl wrote:
1. Do we agree that a lirc (-style) kernel-user interface is needed at
least?
2. Is there any problem with lirc kernel-user interface?
If the answer for #1 is yes and for #2 is no then perhaps we merge
the Jarod's lirc
Mike Lampard wrote:
an example I have a VDR instance running in the background on my desktop
machine outputting to a TV in another room via a pci mpeg decoder - I
certainly don't want the VDR remote control interacting with my X11 desktop
in
any way unless I go out of my way to set it up
On Nov 29, 2009, at 1:47 PM, Jon Smirl jonsm...@gmail.com wrote:
On Sun, Nov 29, 2009 at 4:29 PM, Dmitry Torokhov
dmitry.torok...@gmail.com wrote:
On Nov 29, 2009, at 12:44 PM, Jon Smirl jonsm...@gmail.com wrote:
On Sun, Nov 29, 2009 at 3:27 PM, Krzysztof Halasa k...@pm.waw.pl
wrote:
1.
On Sun, 2009-11-29 at 09:49 -0800, Ray Lee wrote:
On Sun, Nov 29, 2009 at 9:28 AM, Maxim Levitsky maximlevit...@gmail.com
wrote:
This has zero advantages besides good developer feeling that My system
has one less daemon...
Surely it's clear that having an unnecessary daemon is
On Sun, Nov 29, 2009 at 3:35 PM, Andy Walls awa...@radix.net wrote:
If decoding can *only* be sanely handled in user-space, that's one
thing. If it can be handled in kernel, then that would be better.
Why does the address space in which decoding is performed make the
decoding process better
On Nov 29, 2009, at 4:31 PM, Dmitry Torokhov wrote:
On Nov 29, 2009, at 12:27 PM, Krzysztof Halasa k...@pm.waw.pl wrote:
1. Do we agree that a lirc (-style) kernel-user interface is needed at
least?
2. Is there any problem with lirc kernel-user interface?
If the answer for #1 is yes
On Sat, 2009-11-28 at 12:20 +0100, Krzysztof Halasa wrote:
Maxim Levitsky maximlevit...@gmail.com writes:
If we add in-kernel decoding, we still will end up with two different
decoding, one in kernel and one in lirc.
And that's good. Especially for a popular and simple protocol such as
Maxim Levitsky maximlevit...@gmail.com writes:
And that's good. Especially for a popular and simple protocol such as
RC5.
Actually, it's not about adding the decoder. It's about fixing it.
I can fix it.
This is nonsense.
You forgot to say why do you think so.
--
Krzysztof Halasa
--
To
On Sat, 2009-11-28 at 16:25 +0100, Krzysztof Halasa wrote:
Maxim Levitsky maximlevit...@gmail.com writes:
And that's good. Especially for a popular and simple protocol such as
RC5.
Actually, it's not about adding the decoder. It's about fixing it.
I can fix it.
This is nonsense.
Maxim Levitsky maximlevit...@gmail.com writes:
Generic decoder that lirc has is actually much better and more tolerant
that protocol specific decoders that you propose,
Actually, it is not the case. Why do you think it's better (let alone
much better)? Have you at least seen my RC5 decoder?
On Sat, 2009-11-28 at 16:44 +0100, Krzysztof Halasa wrote:
Maxim Levitsky maximlevit...@gmail.com writes:
Generic decoder that lirc has is actually much better and more tolerant
that protocol specific decoders that you propose,
Actually, it is not the case. Why do you think it's better
On Sat, Nov 28, 2009 at 10:35 AM, Maxim Levitsky
maximlevit...@gmail.com wrote:
On Sat, 2009-11-28 at 16:25 +0100, Krzysztof Halasa wrote:
Maxim Levitsky maximlevit...@gmail.com writes:
And that's good. Especially for a popular and simple protocol such as
RC5.
Actually, it's not about
Hi Krzysztof and Maxim,
on 28 Nov 09 at 16:44, Krzysztof Halasa wrote:
Maxim Levitsky maximlevit...@gmail.com writes:
Generic decoder that lirc has is actually much better and more tolerant
that protocol specific decoders that you propose,
Actually, it is not the case. Why do you think it's
On Sat, Nov 28, 2009 at 11:47 AM, Christoph Bartelmus l...@bartelmus.de wrote:
@Maxim: I think Mauro is right. We need to find an approach that makes
everybody happy. We should take the time now to discuss all the
possibilities and choose the best solution. LIRC has lived so long outside
the
l...@bartelmus.de (Christoph Bartelmus) writes:
Nobody here doubts that you can implement a working RC-5 decoder. It's
really easy. I'll give you an example why Maxim thinks that the generic
LIRC approach has advantages:
But surely not when compared to an in-kernel decoder _and_ the one
Jon Smirl jonsm...@gmail.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.
2) Specific tools (xmodmap, setkeycodes, etc or the LIRC ones) or
generic tools (ls, mkdir, echo) for
On Sat, Nov 28, 2009 at 12:35 PM, Krzysztof Halasa k...@pm.waw.pl wrote:
Jon Smirl jonsm...@gmail.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.
2) Specific tools (xmodmap,
Jon Smirl jonsm...@gmail.com writes:
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.
Sure, that's why I wrote about the need for it
Jon Smirl wrote:
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.
2) Specific tools (xmodmap, setkeycodes, etc or the LIRC ones) or
generic tools (ls, mkdir, echo) for configuration
About 2: If
On Sat, 2009-11-28 at 11:45 -0500, Jon Smirl wrote:
On Sat, Nov 28, 2009 at 10:35 AM, Maxim Levitsky
maximlevit...@gmail.com wrote:
On Sat, 2009-11-28 at 16:25 +0100, Krzysztof Halasa wrote:
Maxim Levitsky maximlevit...@gmail.com writes:
And that's good. Especially for a popular and
On Sat, Nov 28, 2009 at 1:45 PM, Maxim Levitsky maximlevit...@gmail.com wrote:
On Sat, 2009-11-28 at 11:45 -0500, Jon Smirl wrote:
What are other examples of user space IR drivers?
many libusb based drivers?
If these drivers are for specific USB devices it is straight forward
to turn them
On Sat, Nov 28, 2009 at 1:17 PM, Stefan Richter
stef...@s5r6.in-berlin.de wrote:
Jon Smirl wrote:
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.
2) Specific tools (xmodmap, setkeycodes, etc or
On Sat, 2009-11-28 at 13:56 -0500, Jon Smirl wrote:
On Sat, Nov 28, 2009 at 1:45 PM, Maxim Levitsky maximlevit...@gmail.com
wrote:
On Sat, 2009-11-28 at 11:45 -0500, Jon Smirl wrote:
What are other examples of user space IR drivers?
many libusb based drivers?
If these drivers are
Jon Smirl wrote:
If these drivers are for specific USB devices it is straight forward
to turn them into kernel based drivers. If we are going for plug and
play this needs to happen. All USB device drivers can be implemented
in user space, but that doesn't mean you want to do that. Putting
On Sat, Nov 28, 2009 at 2:30 PM, Stefan Richter
stef...@s5r6.in-berlin.de wrote:
Jon Smirl wrote:
If these drivers are for specific USB devices it is straight forward
to turn them into kernel based drivers. If we are going for plug and
play this needs to happen. All USB device drivers can be
Jon Smirl wrote:
On Sat, Nov 28, 2009 at 1:17 PM, Stefan Richter
stef...@s5r6.in-berlin.de wrote:
Jon Smirl wrote:
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.
2) Specific tools (xmodmap,
Jon Smirl wrote:
On Sat, Nov 28, 2009 at 2:30 PM, Stefan Richter
stef...@s5r6.in-berlin.de wrote:
Jon Smirl wrote:
If these drivers are for specific USB devices it is straight forward
to turn them into kernel based drivers. If we are going for plug and
play this needs to happen. All USB
Jon Smirl jonsm...@gmail.com writes:
EVIOCSKEYCODE is lacking, first parameter is an INT. Some decoded IR
codes are over 32b. Christoph posted an example that needs 128b.
This only means that the existing interface is limited.
This
is a problem with ioctls, they change size depending on
On Sat, Nov 28, 2009 at 2:45 PM, Stefan Richter
stef...@s5r6.in-berlin.de wrote:
Jon Smirl wrote:
Also, how do you create the devices for each remote? You would need to
create these devices before being able to do EVIOCSKEYCODE to them.
The input subsystem creates devices on behalf of input
On Sat, Nov 28, 2009 at 2:55 PM, Krzysztof Halasa k...@pm.waw.pl wrote:
Jon Smirl jonsm...@gmail.com writes:
EVIOCSKEYCODE is lacking, first parameter is an INT. Some decoded IR
codes are over 32b. Christoph posted an example that needs 128b.
This only means that the existing interface is
101 - 200 of 222 matches
Mail list logo
