Re: Final remote(4) / remote(9) API proposal

[Alan Barrett <apb%cequrux.com@localhost>]

On Fri, 10 Oct 2008, Jared D. McNeill wrote:
>> I also don't care about the name, provided it's not confusing.  I'd
>> suggest some sort of abbreviation that incorporates parts of both words
>> "remote" and "control".
>
> I thought about "rc", but that's even more confusing :) "irc" is still  
> sort've confusing, and implies that the API is limited to IR devices.

Some random ideas on the "remote control" theme:  "remctl",
"remcontrol", "remotectl ", or even "remotecontrol".

To me, the fact that it's "remote" is incidental to the protocol; it
seems to me that if you took an identical set of keys/buttons and
mounted them on the front panel of your device, it would no longer be
"remote", but you might still want to use the same API.  So a name
that emphasises the idea of controlling stuff through a set of keys or
sensors may be appropriate, and could ignore issues like whether it's
mounted on the front panel, tethered by a cable, or using some kind
of wireless communications.

I believe that NetBSD already has a way to interact with remote controls
that are used for controlling presentations (basically a keyboard
with a few buttons like enter/escape/page up/page down, but in a form
factor that resembles a remote control with a built in laser pointer);
I suspect that they appear as btkbd/ukbd devices, but I am not sure.
Re-using that interface might or might not be sensible, but I think it
would be sensible to have an interface that could be used by devices
including game controllers (think steering, gear shift, pedals, fire
buttons), presentation remotes, and TV/VCR/DVD-style remote controls.
The framework could probably also handle button panels built in to
laptops and currently handled by drivers such as sony(4), hpqlb(4),
thinkpad(4).

--apb (Alan Barrett)