send something TO a hid device

[Maksim Yevmenkin]

[...]

> > >The keypad part works ok with bthidd (some special keys don't yet send
> > >keycodes, but that should be easily fixable).
> > ok. patches are welcome.
>
> At the moment I am trying to convert the hid report descriptor to see
> wether there is a bug in the FreeBSD parser or the descriptor. I have
> found only a windows tool which didn't really work, so I am searching
> for a spec to do it myself (in perl).  From what I've seen, this
> shouldn't be too difficult.

how about posting descriptor here in hex form, i.e. the same form you
put it into bthidd.conf?

> > it depends. what are you planning to do with the lcd display? also
> > would be nice to have hid descriptor dump (i assume hid reports are
> > used to send information to the pad).
>
> So far not. The information I got was from a Linux patch which just
> assembles raw packets (probably gained by sniffing). When I have a text
> version of the descriptor, I can tell you more about that.
>
> If it isn't in that descriptor, I will look into producing an updated
> descriptor, but from what I've seen, I'm not sure this will be easy.
>
> [...]
> > local unix or inet (on 127.0.0.1) is the way to go imo. putting stuff
> > into vkbd(4) is a bad idea, because one side (keyboard) of vkbd is
> > grabbed by the kernel another (device) is grabbed by the bthidd(8) and
> > there is no easy way to stuff extra data into vkbd(4).
> >
> > implementing a "pass-through" type of interface in bthidd(8) makes
> > more sense, however, there is aways a risk that someone will use
> > "pass-through" interface incorrectly and will, for example, mess with
> > keyboard lights or something.
> >
> > i'm not a really big fan of displays on keyboards, but someone might
> > find them useful in an "eye candy" soft of way :)
> >
> > the "pass-through" interface idea might have some value, though. i'm
> > hoping for "smart" hid devices, i.e. keyboards with programmable
> > layouts, etc.
>
> The problem is, I have abolutely no idea how to implement a device, so
> thats why I suggested a local socket. The problem with that is, that we
> need some kind of "ad hoc" protocol to select which device to talk to
> (as bthidd can have multiple connections at once, iirc). I am planning
> on a simple linewise text-based thing, but I'm not completely sure on
> that yet.

again, you do not really need a device. socket will do just fine.
local client(s) can connect to the bthidd and identify which hid
device it (they) will be taking to, i.e. tell hid device's bd_addr.
then client(s) simply sends hid reports to the bthidd via socket and
it will relay them the hid device via bluetooth.

thanks,
max