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>
index | next in thread | previous in thread | raw e-mail
[...] > > >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, maxhome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bb4a86c70705141041s64b5e9dat98cf57ee3f6c3e3f>