Re: [tuxdroid-user] Tuxdroid gamepad interface

[Bruno C. <bru...@fr...>]

Philippe Teuwen a écrit :
>>> - light level
>>> future: battery level
>>>     
>> Can be mapped to 2 analogs axis
>>
>>   
> So the idea is to use an existing API but with such a mapping
> you could hardly use it with anything else than the daemon.
> Mapping the three buttons to joystick buttons allow basic control
> of other softwares expecting a joypad but mapping light level
> and battery level to analog axis make the tux hardly usable
> as a joypad!

True, the analog part is really borderline, it's still a good compromise 
in my opinion. Looking at GCompris, if I want to use the light level, 
it's clearly easier for me to use the joystick api for that than having 
to support gamepad for buttons and using another API for the light. I 
could as well detect the gamepad name as being a tuxdroid and have some 
specific code for it.

> Shortly said: I don't see the benefit of mapping to an existing API
> if the result could be used anyway only by the daemon
> or tux-specific programs.

That's not true, in GCompris case, if we add basic gamepad support, it 
will work with tuxdroid and regular gamepads, modulo the analog part 
which is borderline but for which the use case is not evident for 
GCompris anyway. If you believe analog mapping is a bad idea, just don't 
implement it and just provide the buttons.

> 
> Maybe getting the 3 button events mapped to a USB mouse could help
> (but no movements) so applications controlled by mouse buttons
> (diaporama, ooimpress,...) can be controlled by the tux.
> 
That would even be easier for me. Hum, in fact no, there is a focus 
issue. Will work in diaporama but nothing more. In GCompris, I receive 
click events only when you click on an item that expects it. I can 
return you your remark: If you plug sth pretending to be a joypad^W 
mouse but acting as a mad^Wbroken mouse, it's a tuxdroid problem ;)