Andy Walls writes:
> Yes, I agree. I do not know what percentage of current Linux users are
> technical vs non-technical, so I cannot gauge the current improtance.
>
> I can see the trend line though: as time goes by, the percentage of all
> linux users that have a technical bent will only get s
On Sun, Dec 6, 2009 at 7:12 AM, Christoph Bartelmus wrote:
> Hi Jon,
>
> on 04 Dec 09 at 19:28, Jon Smirl 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 wit
Hi Jon,
on 04 Dec 09 at 19:28, Jon Smirl 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 Linux to receive IR
Hi Dmitry,
on 04 Dec 09 at 15:15, Dmitry Torokhov wrote:
[...]
>> http://lirc.sourceforge.net/remotes/lg/6711A20015N
>>
>> This is an air-conditioner remote.
>> The entries that you see in this config file are not really separate
>> buttons. Instead the remote just sends the cu
Hi Dmitry,
on 05 Dec 09 at 22:55, Dmitry Torokhov wrote:
[...]
> I do not believe you are being realistic. Sometimes we just need to say
> that the device is a POS and is just not worth it. Remember, there is
> still "lirc hole" for the hard core people still using solder to produce
> something ou
Dmitry Torokhov wrote:
> 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
>>> wrote:
BTW, I just came across a XMP remote that seems to gene
Dmitry Torokhov wrote:
> 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
>>
Dmitry Torokhov wrote:
> 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 escreveu:
>>
>>> evdev does not really care what you use as scancode. So nobody stops
>>> your driver to report index as a scancode and accept ind
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 tw
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 escreveu:
>
> > >
> >
> > evdev does not really care what you use as scancode. So nobody stops
> > your driver to report index as a scancode and accept index from the
> >
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
> > wrote:
> > > BTW, I just came across a XMP remote that seems to generate 3x64 bit scan
> > > codes
Hi,
Am Freitag, den 04.12.2009, 19:28 -0500 schrieb Jon Smirl:
> On Fri, Dec 4, 2009 at 6:01 PM, Christoph Bartelmus 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 22:45 -0500, Jon Smirl wrote:
> On Fri, Dec 4, 2009 at 8:48 PM, 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
> >> wrote:
> >> > BTW, I just came across a XMP remote that seems to generate
On Fri, Dec 4, 2009 at 8:48 PM, 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
>> wrote:
>> > BTW, I just came across a XMP remote that seems to generate 3x64 bit scan
>> > codes. Anyone here has docs on the XMP prot
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
> > wrote:
> > > BTW, I just came across a XMP remote that seems to generate 3x64 bit scan
> > > codes. Anyone here has docs on the XM
On Fri, 2009-12-04 at 19:28 -0500, Jon Smirl wrote:
> On Fri, Dec 4, 2009 at 6:01 PM, Christoph Bartelmus 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
On Fri, Dec 4, 2009 at 6:01 PM, Christoph Bartelmus 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 Linux to receiv
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
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.
>> [...]
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:
> >> http://lirc.sourceforge.net
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
On Fri, Dec 4, 2009 at 9:12 AM, Mauro Carvalho Chehab
wrote:
>> In-kernel decoding:
>>
[IR physical device] => [IR receiver driver] => [LIRC core] =>
[decoder] => [IR core] => [input core] => [evdev]
||
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
Em Fri, 4 Dec 2009 02:06:42 -0800
Dmitry Torokhov 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 escreveu:
> >
> > > No, please, wait just a minute. I know it is tempting
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 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
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
On Thu, 2009-12-03 at 19:10 -0200, Mauro Carvalho Chehab wrote:
> Gerd Hoffmann wrote:
>
> > One final pass over the lirc interface would be good, taking the chance
> > to fixup anything before the ABI is set in stone with the mainline
> > merge. Things to look at:
> > (3) Someone suggested a
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,
> >>>
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'
Gerd Hoffmann wrote:
> One final pass over the lirc interface would be good, taking the chance
> to fixup anything before the ABI is set in stone with the mainline
> merge. Things to look at:
>
> (1) Make sure ioctl structs are 32/64 bit invariant.
> (2) Maybe add some reserved fields to all
On Thu, Dec 3, 2009 at 12:55 PM, Dmitry Torokhov
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 that.
>
Let me draw my view:
Em Thu, 3 Dec 2009 09:55:31 -0800
Dmitry Torokhov 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 quite inclear to me.
>
>
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
Gerd Hoffmann 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.
This is problema
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 de
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 wor
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 dri
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 descripti
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 adva
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
Gerd Hoffmann wrote:
> 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 dr
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 o
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 sent there, keystrokes come
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 using more
On Tue, 2009-12-01 at 11:46 +0100, Gerd Hoffmann wrote:
> 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
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 all
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 ch
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 kept
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 using more recent kernel features.
I agree. The main re
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?
>
On Sun, Nov 29, 2009 at 7:01 AM, Christoph Bartelmus 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 and get r
kevin granade 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 list: send the line "unsub
Andy Walls 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 using. They a
Mauro Carvalho Chehab 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 the same l
On Mon, Nov 30, 2009 at 04:27:56PM -0200, Mauro Carvalho Chehab wrote:
> 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
> >>> wrote:
> >>>
> After the boot
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
>>> wrote:
>>>
After the boot, a device can open the raw API, disabling any in-kernel
decoding/handling and h
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
> > wrote:
> >
> >> After the boot, a device can open the raw API, disabling any in-kernel
> >> decoding/handling and handle IR directly. Altern
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 user
kevin granade wrote:
> On Mon, Nov 30, 2009 at 7:24 AM, Mauro Carvalho Chehab
> 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 o
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 Mon, Nov 30, 2009 at 7:24 AM, Mauro Carvalho Chehab
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.
This idea of the in
On Mon, 2009-11-30 at 09:01 -0500, Jon Smirl wrote:
> On Mon, Nov 30, 2009 at 8:43 AM, Maxim Levitsky
> 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:
On Mon, Nov 30, 2009 at 8:43 AM, Maxim Levitsky 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 9:28 AM,
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
> > >> wrote:
> > >>> This has zero advantag
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
wrote:
> This has zero advantages besides good developer feeling that "My sy
On Mon, Nov 30, 2009 at 7:57 AM, Andy Walls 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 scripting should be
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
> >> wrote:
> >>> This has zero advantages besides good developer feeling that "My system
> >>> has one le
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:
Jon Smirl wrote:
> On Fri, Nov 27, 2009 at 2:45 AM, Christoph Bartelmus
> wrote:
>> Hi Mauro,
>>
>> on 26 Nov 09 at 14:25, Mauro Carvalho Chehab wrote:
>>> Christoph Bartelmus wrote:
>> [...]
But I'm still a bit hesitant about the in-kernel decoding. Maybe it's just
because I'm not famil
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
>> 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 intr
Christoph Bartelmus 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 and get rid of any past mistakes. Incorpor
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 s
Ray Lee wrote:
> On Sun, Nov 29, 2009 at 3:35 PM, Andy Walls 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
On Nov 29, 2009, at 4:31 PM, Dmitry Torokhov wrote:
> On Nov 29, 2009, at 12:27 PM, Krzysztof Halasa 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 Sun, Nov 29, 2009 at 3:35 PM, Andy Walls 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 or worse?
On Sun, 2009-11-29 at 21:27 +0100, Krzysztof Halasa wrote:
> 1. Do we agree that a lirc (-style) kernel-user interface is needed at
>least?
Yes. Honestly, I'm just waiting on lirc_dev for the IR devices I work
with. With that I can get those new devices supported for both IR Rx
and Tx right
On Sun, 2009-11-29 at 20:49 +0100, Christoph Bartelmus wrote:
> Hi,
>
> on 29 Nov 09 at 14:16, Jon Smirl wrote:
> > On Sun, Nov 29, 2009 at 2:04 PM, Alan Cox wrote:
> >>> Jon is asking for an architecture discussion, y'know, with use cases.
> [...]
> > So we're just back to the status quo of last
On Sun, 2009-11-29 at 09:49 -0800, Ray Lee wrote:
> On Sun, Nov 29, 2009 at 9:28 AM, Maxim Levitsky
> 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 po
On Nov 29, 2009, at 1:47 PM, Jon Smirl wrote:
On Sun, Nov 29, 2009 at 4:29 PM, Dmitry Torokhov
wrote:
On Nov 29, 2009, at 12:44 PM, Jon Smirl wrote:
On Sun, Nov 29, 2009 at 3:27 PM, Krzysztof Halasa
wrote:
1. Do we agree that a lirc (-style) kernel-user interface is
needed at
least
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
On Sun, Nov 29, 2009 at 4:29 PM, Dmitry Torokhov
wrote:
> On Nov 29, 2009, at 12:44 PM, Jon Smirl wrote:
>
>> On Sun, Nov 29, 2009 at 3:27 PM, Krzysztof Halasa wrote:
>>>
>>> 1. Do we agree that a lirc (-style) kernel-user interface is needed at
>>> least?
>>>
>>> 2. Is there any problem with l
On Nov 29, 2009, at 12:27 PM, Krzysztof Halasa 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 patches (at le
On Nov 29, 2009, at 12:44 PM, Jon Smirl wrote:
On Sun, Nov 29, 2009 at 3:27 PM, Krzysztof Halasa
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
On Sun, Nov 29, 2009 at 3:27 PM, Krzysztof Halasa 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 creating a new
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 d
Hi,
on 29 Nov 09 at 14:16, Jon Smirl wrote:
> On Sun, Nov 29, 2009 at 2:04 PM, Alan Cox 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 up.
>
> We'll be back
> 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 no
On Sun, Nov 29, 2009 at 2:04 PM, Alan Cox 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, nor an obvious win
> 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 t
> 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 subsy
On Sun, Nov 29, 2009 at 10:13 AM, Alan Cox 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 better than doin
On Sun, Nov 29, 2009 at 7:40 AM, 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 to
> 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 9:28 AM, Maxim Levitsky 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 just its own
reward in
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 a
Jon Smirl wrote:
> On Sat, Nov 28, 2009 at 4:46 PM, Stefan Richter
> wrote:
>> Jon Smirl wrote:
>>> On Sat, Nov 28, 2009 at 3:29 PM, Stefan Richter
>>> wrote:
Jon Smirl wrote:
> We have one IR receiver device and multiple remotes. How does the
> input system know how many devices to
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 s
Jon Smirl wrote:
> On Sat, Nov 28, 2009 at 2:45 PM, Stefan Richter
> 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 inp
> 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 use
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
>> irrec
101 - 200 of 256 matches
Mail list logo
