[...]

> >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
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bluetooth
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to