Date: Sun, 19 Dec 2004 19:15:56 -0800 From: Maksim Yevmenkin <maksim.yevmenkin@savvis.net> To: vova@fbsd.ru Cc: bluetooth@freebsd.org Subject: Re: Bluetooth mouse Message-ID: <41C643EC.3060405@savvis.net> In-Reply-To: <1103490563.1721.28.camel@localhost> References: <1100552998.1098.5.camel@localhost> <419B8353.7040908@savvis.net> <opshmg45c1lo1qsj@mail.xs4all.nl> <419B9EF8.2090401@savvis.net> <1103269957.974.7.camel@localhost> <41C32471.2050805@savvis.net> <1103490563.1721.28.camel@localhost>
next in thread | previous in thread | raw e-mail | index | archive | help
Vladimir, >>>Also, I think, it is better to provide usual /dev/*msX interface for >>>moused ? >> >>why? > > Just because all other mouses use moused as userland programs to get > bytes from driver and push them to console. > > Actually moused do two things > 1. "knows" how to work with different mouse hardware moused(8) only knows about the particular hardware, because someone extend moused(8) to support this particular hardware. there is no universal protocol that will work for every hardware. > 2. "knows" how to adjust mouse settings (rate, buttons mappings, axis, > wheels, 3-button emulation, double-click, resolution, etc) i'm not sure what settings are you talking about. button mapping is so trivial that i would never consider to pipe the data through bthidd(8) + moused(8). i do not think that 3-button emulation and double-click are good enough reasons to involve moused(8). if we are worried about code duplication then this code could be moved into a separate file (so bthidd(8) can use it too) or even separate library. > And 1. is clearly has nothing to do with bluetooth mouse, but as for 2. > - I do not think we want to duplicate all these staff in bthidd. correct. i do not think you can even adjust anything in bluetooth mouse. > Probably I was not right when talk about one more netgraph module, and > better way is to add opened bt socket support to moused and then spawn > moused from bthidd when new mouse connected. > > What you think about this idea ? see above. do not forget that bluetooth hid sessions are come and go. bluetooth mouse, for example, will put itself to sleep after few seconds of inactivity. this means bthidd(8) would probably have to manage all moused(8) processes it had created. do not forget that at the end moused(8) just does exactly what bthidd(8) does - feeds events via /dev/console ioctl(2) call. one could argue that it is possible to extend moused(8) to support bluetooth hid devices natively. after all bluetooth is only used to pipe usb hid reports, so from moused(8) point of view bluetooth mouse is no different from a usb mouse. the only problem is that you need device's hid descriptor to parse hid report. that is what ums(4) driver does - it parses hid reports and converts them into something moused(8) can work with. in bluetooth case bthidd(8) can convert hid reports into moused(8) format, but why? if it has already done 2/3rd of the job why use moused(8) to do remaining 1/3rd? if we really want to use moused(8) then i'd suggest we teach moused(8) about bluetooth mice and drop mouse support in bthidd(8) altogether. thanks, max
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?41C643EC.3060405>