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

[Iain Hibbert <plunky%rya-online.net@localhost>]

On Fri, 10 Oct 2008, Jared D. McNeill wrote:

> Iain Hibbert wrote:
> > >   typedef uint32_t        remote_command_t;
> >
> > again, I don't exactly know if this is enough for a HID remote - the only
> > information I have 'seems' to show that the PS3 remote provides 11 bytes
> > of input data (this is from a posting on the FreeBSD bluetooth list):
>
> Not a problem again to increase the size here. Do you think 64-bits would be
> enough or would you like the command to be eg. a 16-byte uint8_t array?

frankly I have no idea :)

The HID specification is so open ended that anything is technically
possible. I found the following post that explains what the 11 bytes
seem to contain:

        http://xbmc.org/forum/showpost.php?p=150894&postcount=2

so probably the 32 bits would be enough depending on how you use them to
represent commands (a btpsr device would have to map them anyway)

> > >   struct remote_info {
> > >         char    ri_devid[REMOTE_DEVID_LEN];
> > >   };
> > >
> > >   #define REMOTE_GINFO    _IOR('r', 0, struct remote_info)
> >
> > so, this would be something like "uirda0-3343" for device ID 3343 sending
> > events via uirda0 ?
>
> The intent is to not use device_xname so attach order doesn't matter. My ATI
> receiver reports a serial number of 660808003247 for example, so no matter the
> order of remote or emdtv attachments, I will always know that this piece of
> hardware has generated an event.

Ah ok yes, in that case the id would end up being be
"local_addr-remote_addr" which is no problem with bluetooth either.

> > >   struct remote_event {
> > >         uint8_t                 re_toggle;
> > >         remote_addr_t           re_address;
> > >         remote_command_t        re_command;
> > >         struct timespec         re_time;
> > >   };
> >
> > you didn't say how events are transmitted out of the /dev/wsremote0, will
> > it be possible to extend the event structure in the future?
>
> These are returned when a read for sizeof(struct remote_event) bytes is
> issued. We can extend the event structure later if required simply by making
> it larger.

Ok in that case, is it good to provide a way to find the packet size, to
insulate the daemon against that eventuality? (could be ioctl, could be
size is first item, could be tagged list "[type][len][data ..]") the
daemon then could just ignore data it did not understand.

iain