Hi Jon,
on 15 Feb 07 at 00:34, you wrote:
[...]
>> I'm only a bit concerned about scalability. It's easily possible to have
>> hundreds of remote control definitions in your lircd.conf. Creating a
>> device node for each of them will be very inefficient.
> I have about ten remotes and I thought t
On 15 Feb 2007 05:40:00 +0100, Christoph Bartelmus <[EMAIL PROTECTED]> wrote:
> Hi Jon,
>
> on 14 Feb 07 at 09:44, you wrote:
> [...]
> > Adding uinput support would also let you get rid of all the X specific
> > code since X knows how to read evdev.You just need to do is add a
> > small section to
Hi Jon,
on 14 Feb 07 at 09:44, you wrote:
[...]
> Adding uinput support would also let you get rid of all the X specific
> code since X knows how to read evdev.You just need to do is add a
> small section to your xorg.conf.
>
> Are your interested in adding this support?
Yes, I like the concept y
On 2/14/07, Vojtech Pavlik <[EMAIL PROTECTED]> wrote:
> On Wed, Feb 14, 2007 at 11:27:44AM -0500, Jon Smirl wrote:
>
> > You need something like this:
> >
> > lircd opens /dev/uinput once for each remote control. This creates the
> > corresponding /dev/input/event* nodes.
> >
> > Remote gets clicke
On Wed, Feb 14, 2007 at 11:27:44AM -0500, Jon Smirl wrote:
> You need something like this:
>
> lircd opens /dev/uinput once for each remote control. This creates the
> corresponding /dev/input/event* nodes.
>
> Remote gets clicked, lircd catches event and passes it to uinput. User
> app can read
On 2/14/07, Vojtech Pavlik <[EMAIL PROTECTED]> wrote:
> On Wed, Feb 14, 2007 at 10:50:27AM -0500, Jon Smirl wrote:
> > On 2/14/07, Vojtech Pavlik <[EMAIL PROTECTED]> wrote:
> > >On Wed, Feb 14, 2007 at 09:44:46AM -0500, Jon Smirl wrote:
> > >> >Sending an IR signal involves things like setting the
On Wed, Feb 14, 2007 at 10:50:27AM -0500, Jon Smirl wrote:
> On 2/14/07, Vojtech Pavlik <[EMAIL PROTECTED]> wrote:
> >On Wed, Feb 14, 2007 at 09:44:46AM -0500, Jon Smirl wrote:
> >> >Sending an IR signal involves things like setting the carrier frequency,
> >> >duty cycle, and then writing a stream
On 2/14/07, Vojtech Pavlik <[EMAIL PROTECTED]> wrote:
> On Wed, Feb 14, 2007 at 09:44:46AM -0500, Jon Smirl wrote:
> > >Sending an IR signal involves things like setting the carrier frequency,
> > >duty cycle, and then writing a stream of timing values.
> > >I think that evdev in general is not the
On Wed, Feb 14, 2007 at 09:44:46AM -0500, Jon Smirl wrote:
> >Sending an IR signal involves things like setting the carrier frequency,
> >duty cycle, and then writing a stream of timing values.
> >I think that evdev in general is not the right interface for this.
>
> This could be worked into the
On 14 Feb 2007 07:16:00 +0100, Christoph Bartelmus <[EMAIL PROTECTED]> wrote:
> Hi Jon,
>
> on 13 Feb 07 at 23:46, you wrote:
> [...]
> > evdev doesn't just handle keyboards.
>
> Yes, sorry for simplifying it too much. I just opt for using uinput from
> user-space so that configuration is consisten
Hi Jon,
on 13 Feb 07 at 23:46, you wrote:
[...]
> evdev doesn't just handle keyboards.
Yes, sorry for simplifying it too much. I just opt for using uinput from
user-space so that configuration is consistent for all devices.
If some devices use the kernel input layer directly, you will have to
On 14 Feb 2007 03:45:00 +0100, Christoph Bartelmus <[EMAIL PROTECTED]> wrote:
> Hi!
>
> Jon Smirl "[EMAIL PROTECTED]" wrote:
> > LIRC folks, there is an on-going discussion about possible future
> > designs for IR support in the kernel. What's your take on how to do
> > this?
>
> Pass all events to
Hi!
Jon Smirl "[EMAIL PROTECTED]" wrote:
> LIRC folks, there is an on-going discussion about possible future
> designs for IR support in the kernel. What's your take on how to do
> this?
Pass all events to userspace and let lircd do the mapping/decoding.
In case of the atiusb device there are cu
13 matches
Mail list logo
