Re: Fwd: [linux-usb-devel] USB IR receivers and evdev

[Jon S. <jon...@gm...>]

On 2/14/07, Vojtech Pavlik <vo...@su...> wrote:
> On Wed, Feb 14, 2007 at 10:50:27AM -0500, Jon Smirl wrote:
> > On 2/14/07, Vojtech Pavlik <vo...@su...> 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 right interface for this.
> > >>
> > >> This could be worked into the evdev support. lircd.conf would contain
> > >> entries for the controls you wanted to send codes for. This info could
> > >> be used to created an uinput/evdev entry for the control. If evdev
> > >> supports pushing events, lircd could take the event and convert it to
> > >> IR info and push it down into the lirc drivers.
> > >>
> > >> We need Vojtech to tell us if we can push events into uinput.
> > >
> > >You can. However, the event direction depends on the event type: EV_KEY
> > >always goes from device to handler, EV_LED goes both ways. You'd have a
> > >new event type for sending out IR events: This is different from
> > >pressing a key. But it's trivial to add.
> >
> > Does pushing an event work with an app using uinput?
>
> Interesting question. Of course uinput can generate any events. But they
> will only be delivered either back to it, or to event handlers (evdev,
> ...)

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 events from the /dev/input/event* nodes

Now user app wants to generate an event. User app writes it to the
appropriate /dev/input/event* node. Does this node know it was created
by /dev/uinput Will the event written to /dev/input/event* then be
readable on the corresponding /dev/uinput handle?

You don't want the app opening /dev/uinput because that would force
lircd to read events from a /dev/input/event* for each app, and lircd
isn't going to know what is going on.

-- 
Jon Smirl
jon...@gm...