Date: Mon, 14 May 2007 10:41:09 -0700 From: "Maksim Yevmenkin" <maksim.yevmenkin@gmail.com> To: "Stefan `Sec` Zehl" <sec@42.org> Cc: freebsd-bluetooth@freebsd.org Subject: Re: send something TO a hid device Message-ID: <bb4a86c70705141041s64b5e9dat98cf57ee3f6c3e3f@mail.gmail.com> In-Reply-To: <20070514082040.GB24803@ice.42.org> References: <20070513140148.GA24803@ice.42.org> <bb4a86c70705131614t76526fbbya3a5253fe2e742a9@mail.gmail.com> <20070514082040.GB24803@ice.42.org>
next in thread | previous in thread | raw e-mail | index | archive | help
[...] > > >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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bb4a86c70705141041s64b5e9dat98cf57ee3f6c3e3f>