[Bf-committers] spaceball patch 3688

[Stealth Apprentice]

Hi Jean-Luc,

I am studying the libusb solution now, and have some
ideas on how to proceed. I think the path from the
current patch to a "good" solution for Blender is very
straight forward.

The main integration for GHOST starts here:

extern void GHOST_OpenNDOF(GHOST_SystemHandle
systemhandle, 
                           GHOST_WindowHandle
windowhandle,
                           GHOST_NDOFLibraryInit_fp
setNdofLibraryInit, 
                          
GHOST_NDOFLibraryShutdown_fp setNdofLibraryShutdown,
                           GHOST_NDOFDeviceOpen_fp
setNdofDeviceOpen,
                           GHOST_NDOFEventHandler_fp
setNdofEventHandler);

I think this API is simple enough and broad enough to
cover all possible ndof devices. This API will work
for joysticks, and other devices, even pan controllers
on a MIDI keyboard ;) We may have to add one more
function for polling, but I expect the EventHandler
could be pumped from Blender, so another function may
be superfluous.


For a first pass,

GHOST_TEventNDOFData

is a sufficient structure as well, although it will
need to be extended in a upgrade to handle buttons and
keys on the NDOF device. I want to address buttons &
keys when the new NDOF infrastructure is stable &
working in Blender.

Nothing in my proposed GHOST-NDOF API specifies how
the device interface works - it is not hard-coded to
windows events, USB, serial, etc - all of that is
abstracted through the handler API specified to
GHOST_OpenNDOF.

So, I suggest we keep the GHOST side patched API as
is.

On the Blender side, where presently I open a DLL, I
think we need some more work.

Using libusb we can write a "Device driver" for the
spaceball, and pass our new Device Driver API into
GHOST. The GHOST-NDOF driver is responsible for
creating the GHOST events for Blender to interpret. So
the only extra work here is the device driver, the
rest of the infrastructure works as-is.

The view manipulation I put into Blender also remains
the same as it too is independent of device.

There is some new work I think we should add on the
Blender side.

1) "NDOF Discovery" routines. The discovery routines
inspect the USB bus for compatible devices. It should
also inspect the serial ports for compatible devices.
I would prefer to be able to discover DLL plugins as
well to allow hardware manufacturers to create drivers
for Blender by themselves.

2) "preferences". The user should have a mechanism in
Blender's preferences to choose a discovered
compatible device. Blender should remember this
preference, and use this device whenever it has been
discovered during Blender's start up sequence.



--- Jean-Luc Peuri�re <jlp at nerim.net> wrote:

> 
> Le 3 mars 06 � 23:23, Stealth Apprentice a �crit
:
> 
> > I am considering the HID solution on Windows. My
> test
> > program using the WinDDK shows the device
> > successfully.
> >
> > My question there is that it requires a download
> of
> > the Windows DDK from Microsoft, and I wasn't sure
> if
> > that would be an obstacle for general Windows
> blender
> > developers? The download is free, but I couldn't
> find
> > a download without registering as a developer.
> >
> > On Linux, the non libusb solution involves
> something
> > like open("fancydevice:") or some such, and then
> you
> > have to deal with X events in the main loop. It's
> > easy, but not very portable, and really hard to
> > emulate on Windows.
> >
> > I did a bit of reading on the SDL approach, and
> came
> > across this tidbit:
> >
> >
>
http://aspn.activestate.com/ASPN/Mail/Message/pygame-users/2292374
> >
> > It appears that for spaceball, it might be
> possible to
> > get the messages using the SYSWMEVENT message. If
> that
> > works, WIndows wouldn't need WinDDK, 3dxware SDK,
> > libusb or SDL...
> >
> 
> I would use the SDL solution as last resort, as this
> lib status is not
> guaranteed in the future.
> 
> the libusb solution is for me the most appealing
> even if if is more  
> work.
> But only if the quality of the lib is good which is
> still unknown  
> quantity.
> 
> there is HID support in linux, but problem is with
> X, and that not all
> kernels may have this support. dont know how many.
> HID support
> in linux use the traditionnal /dev/....
> Also opening a device in linux could conflict with
> Xinput and others  
> beside
> the separate development from windows.
> 
> the fact the DDK need registration is a problem if
> it  is needed to  
> compile,
> if those using cygwin are blocked.
> 
> Now, we need to find a X11 coder ;)
> 
> tested libusb on the mac, seem to work
> 
> 
> > _______________________________________________
> Bf-committers mailing list
> Bf-committers at projects.blender.org
>
http://projects.blender.org/mailman/listinfo/bf-committers
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com