Re: Proposal for reporting remote control button presses to userland

["Jared D. McNeill" <jmcneill%invisible.ca@localhost>]

On Wed, 8 Oct 2008, David Brownlee wrote:
>         - You don't mention if the devices export some identifier to
>           wsremote - for example if I had two remote providing devices
>           that attached dynamically (say via USB), the wsremote0/wsremote1
>           order may change, so it would be good to know (if possible)
>           which is which, whether its some device type or serial
>           identifier, assuming such is available to the driver

Good point. Maybe we can have the hw driver provide a unique identifier 
(or fallback to device_xname if there is no other possibility) and we can 
add an ioctl to query this.

My USB ATSC tuner has eg. iSerialNumber=2(660808003247) in the device 
descriptor that we can use for mapping purposes. Maybe PCI devices can use 
a bus:dev:fn style identifier if nothing else is available.

>         - How would you provide a simple 'run command X for key mapping Y'?
>           Could have be a simple reader of wsremoted.sock which invokes a
>           command passing the key details as args, or even putting that
>           functionality in wsremoted?

You will have to build one or more applications on top of wsremoted.sock 
to actually perform actions, its sole responsibility is to translate from 
raw -> buttonmap -> cooked events.

>         - Could it handle needing to deliver different commands from
>           the same device to different targets. For example, volume up/down
>           to a shell script, various other options to MythTV, and everything
>           else simulate normal keyboard imput? Might be possible to do with
>           a script in the above 'command with args' option, but that
>           would incur additional latency on each command. Maybe have the
>           option to have multiple 'wsremoted.sock's and a map of which
>           keymapped command goes where.

Should be able to have multiple listeners on wsremoted.sock so I don't 
think this will be a problem.

>         Longer term thoughts:
>
>         - Could this replace usbhidacton?

Not sure what usbhidaction does, but it sounds specific to uhidev :)

>         - A lirc compatible reader of /var/run/wsremoted.sock would be
>           a nice additional app

I was thinking either that we could provide an lirc-compatible socket or 
simply add support to lirc for wsremoted.sock.

Cheers,
Jared