[sldev] adding support for a new input device to the SL viewer

[Ettore Pasquini]

On 9/13/07 8:46 AM, "Maurizio de Pascale" <mdepascale at dii.unisi.it> wrote:

> I'm working at adding support to the SL viewer for a new input device.
> the short term goal, in order to learn how the input system is designed,
> is to just replace the mouse (actually provide a non mutually exclusive
> alternative).
> the long term goal is to have the new device controlling operations not
> handled by the mouse.

I've been working on something like this on and off for a while (whenever I
have some free time) and currently I have a solution more or less working
for controlling the avatar, edit mode and flycam for Windows and OS X. Maybe
we can work together...

> can anyone point me to the sources/classes/functions building up the
> input system or provide docs on this?

not much is available:
https://wiki.secondlife.com/wiki/How_movement_works
https://wiki.secondlife.com/wiki/How_the_camera_works

> So far, by tracing an execution, I've seen that mouse input are received
> through standard window messages (i'm working on windows version) by the
> LLWindowWin32 class and then passed up to LLViewerWindow class through
> the handleMouseXXX methods.
> 
> it seems to me that the two invocations in the main loop:
>> gKeyboard->scanKeyboard();
>> LLViewerJoystick::scanJoystick();
> do not handle mouse input.
> 
> are this correct?

I think so - my approach was not to follow the mouse events flow because it
was just too crazy and platform specific. To get something moving (quick and
dirty style) I just added a scanDevice() call after scanJoystick, but that's
bad as well. The best approach I think depends on what kind of device you're
working on: if you're working with joysticks, 3D mice or other N degrees of
freedom devices I say LLViewerJoystick is a good class to expand. That's
what I'm doing right now.

> additionally, what is the best way to proceed:
> 1) use the new device state to generate and post mouse messages on the
> queue and have them handled as coming out from the mouse?
> 2) calling directly the handleMouseXXX methods?
> 3) ignoring the mouse input handling and calling directly "what's called
> from" handleMouseXXX methods to have viewer react accordingly?
> 
> at a first glance, for the long term, having a class like
> LLViewerJoystick looks like the way to go. Am I right?

Hacking the event system with fake mouse events seem the way to Event Hell
IMO. This is what I did/am doing (I plan on posting some patches in a few
days):

- As you know the viewer already uses DirectInput on windows for the flycam.
On OS X I'm using the HID manager, and I believe there is a library on Linux
to handle HID devices.
- I developed an open source library to have a cross-platform API to access
the device. The implementation is DI on Win and HID on OS X, any other
platforms can be added by just implementing a few functions. This makes
viewer code unaware of the underlying implementation.
- I am refactoring the joystick implementation to use the above library.

Sorry if this is too vague - expect a patch soon.

Ettore

-- 
http://www.3dconnexion.com/