Bluetooth mouse

[Maksim Yevmenkin]

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