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
>> 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
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 la
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 kn
On Sun, Nov 29, 2009 at 04:01:53PM +1030, Mike Lampard wrote:
> On Sun, 29 Nov 2009 03:25:49 pm Dmitry Torokhov wrote:
> > On Sun, Nov 29, 2009 at 01:17:03PM +1030, Mike Lampard wrote:
> > > On Sat, 28 Nov 2009 02:27:59 am Jon Smirl wrote:
> > > > On Fri, Nov 27, 2009 at 2:45 AM, Christoph Bartelmu
On Sun, 29 Nov 2009 03:25:49 pm Dmitry Torokhov wrote:
> On Sun, Nov 29, 2009 at 01:17:03PM +1030, Mike Lampard wrote:
> > On Sat, 28 Nov 2009 02:27:59 am Jon Smirl wrote:
> > > On Fri, Nov 27, 2009 at 2:45 AM, Christoph Bartelmus
> > >
> > > wrote:
> > > > Hi Mauro,
> > > >
> > > > on 26 Nov 09 a
On Sat, Nov 28, 2009 at 05:18:34PM -0500, 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 corres
On Sat, Nov 28, 2009 at 06:26:55PM -0500, Andy Walls wrote:
> Jon,
>
> 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.
On Sun, Nov 29, 2009 at 01:17:03PM +1030, Mike Lampard wrote:
> On Sat, 28 Nov 2009 02:27:59 am 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
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.
> > >>
> >
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.
On Sat, 28 Nov 2009 02:27:59 am 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 dec
Jon,
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 fo
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 splitting those 200 scancodes
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 create corresponding to how
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 create corresponding to how many
>>> remotes you have?
>> If several remotes are to be use
On Sat, Nov 28, 2009 at 3:29 PM, Stefan Richter
wrote:
> 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 t
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 create corresponding to how many
>> remotes you have?
>
> If several remotes are to be used on the same receiver, then they
> necessarily need to g
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
Jon Smirl writes:
> Endianess comes into play when send/receiving multibyte integers on
> platforms with different endianess.
It's the case when you're sending this data to a machine with
a different endianness. For example, in a network or to another CPU in
e.g. add-on card.
Ioctls are not affe
Jon Smirl writes:
> We have one IR receiver device and multiple remotes. How does the
> input system know how many devices to create corresponding to how many
> remotes you have? There is no current mechanism to do that. You need
> an input device for each remote so that you can do the EVIOCSKEYC
On Sat, Nov 28, 2009 at 2:55 PM, Krzysztof Halasa wrote:
> Jon Smirl 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
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 input drivers. (Kernel
>
Jon Smirl 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 platform and
> end
Jon Smirl wrote:
> On Sat, Nov 28, 2009 at 2:30 PM, Stefan Richter
> 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 ca
Jon Smirl wrote:
> On Sat, Nov 28, 2009 at 1:17 PM, Stefan Richter
> 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,
On Sat, Nov 28, 2009 at 2:30 PM, Stefan Richter
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 implemented
>> in us
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, 2009-11-28 at 13:56 -0500, Jon Smirl wrote:
> On Sat, Nov 28, 2009 at 1:45 PM, Maxim Levitsky
> 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 spec
On Sat, Nov 28, 2009 at 1:17 PM, Stefan Richter
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 the LIRC ones) or
>
On Sat, Nov 28, 2009 at 1:45 PM, Maxim Levitsky 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 into kernel based d
On Sat, 2009-11-28 at 11:45 -0500, Jon Smirl wrote:
> On Sat, Nov 28, 2009 at 10:35 AM, Maxim Levitsky
> wrote:
> > On Sat, 2009-11-28 at 16:25 +0100, Krzysztof Halasa wrote:
> >> Maxim Levitsky writes:
> >>
> >> >> And that's good. Especially for a popular and simple protocol such as
> >> >> RC
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:
Jon Smirl 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 to be "stab
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.
>> 2) Specific tools (xmodmap, setkeycodes, etc or the LIRC one
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.
> 2) Specific tools (xmodmap, setkeycodes, etc or the LIRC ones) or
> generic tools (ls, mkdir, echo) for configuration
I think
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
On Sat, Nov 28, 2009 at 11:47 AM, Christoph Bartelmus 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 kernel, that we
Hi Krzysztof and Maxim,
on 28 Nov 09 at 16:44, Krzysztof Halasa wrote:
> Maxim Levitsky 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
On Sat, Nov 28, 2009 at 10:35 AM, Maxim Levitsky
wrote:
> On Sat, 2009-11-28 at 16:25 +0100, Krzysztof Halasa wrote:
>> Maxim Levitsky 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 fi
Maxim Levitsky writes:
>> 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?
> Because userspace decoder is general, it doesn't depend on exact timing,
> as long as pulses vary in size it can distinguish between keys, an
On Sat, 2009-11-28 at 16:44 +0100, Krzysztof Halasa wrote:
> Maxim Levitsky 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
> "mu
Maxim Levitsky 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?
> You claim you 'fix'
On Sat, 2009-11-28 at 16:25 +0100, Krzysztof Halasa wrote:
> Maxim Levitsky 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
Maxim Levitsky 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 unsubscribe from
On Sat, 2009-11-28 at 12:20 +0100, Krzysztof Halasa wrote:
> Maxim Levitsky 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
> RC5.
> Actuall
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 features.
>
> If it ain't broke, don't fix it.
I don't kn
Maxim Levitsky 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
RC5.
Actually, it's not about adding the decoder. It's about fixing it.
I can fix it.
--
Christoph Bartelmus wrote:
> A user friendly GUI tool to configure the mapping of the remote
buttons is
> essential for good user experience. I hope noone here considers that
users
> learn command line or bash to configure their remotes.
oh please no
the major, major problem with bluetooth is
On Fri, Nov 27, 2009 at 02:21:13PM -0500, Jon Smirl wrote:
> On Fri, Nov 27, 2009 at 2:03 PM, Ferenc Wagner wrote:
> > Admittedly, I don't know why /dev/mouse is evil, maybe I'd understand if
>
> /dev/mouse is evil because it is possible to read partial mouse
> messages. evdev fixes things so tha
On Fri, 2009-11-27 at 22:49 +0100, Stefan Richter wrote:
> Jon Smirl wrote:
> > 3) No special tools - use mkdir, echo, cat, shell scripts to build maps
>
> From the POV of a distributor, there is always a special tool required.
> Whether it is implemented in bash, Python, or C doesn't make a
> di
Jon Smirl wrote:
> 3) No special tools - use mkdir, echo, cat, shell scripts to build maps
>From the POV of a distributor, there is always a special tool required.
Whether it is implemented in bash, Python, or C doesn't make a
difference to him.
For an enduser whose distributor doesn't package th
On Fri, Nov 27, 2009 at 2:03 PM, Ferenc Wagner wrote:
> Jon Smirl writes:
>
>> On Fri, Nov 27, 2009 at 12:29 PM, 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
he
Jon Smirl writes:
> On Fri, Nov 27, 2009 at 12:29 PM, 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 features.
On Fri, Nov 27, 2009 at 12:29 PM, 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 features.
>
> If it ain't broke, don't f
Hi Jon,
on 27 Nov 09 at 10:57, Jon Smirl wrote:
[...]
But I'm still a bit hesitant about the in-kernel decoding. Maybe it's
just because I'm not familiar at all with input layer toolset.
>> [...]
>>> I hope it helps for you to better understand how this works.
>>
>> So the plan is to hav
On Fri, 2009-11-27 at 10:57 -0500, Jon Smirl wrote:
> On Fri, Nov 27, 2009 at 2:45 AM, Christoph Bartelmus
> wrote:
> > So the plan is to have two ways of using IR in the future which are
> > incompatible to each other, the feature-set of one being a subset of the
> > other?
>
> Take advantage o
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 familiar at all with input layer
201 - 257 of 257 matches
Mail list logo
