On Jan 22, 9:19 pm, Alex Holkner <[email protected]> wrote: > The Joystick class normalises axis values, The evdev wrapper passes the values trough unnormalized on r2428
> and the Tablet class throws them away and uses window coordinates instead. I haven't toyed with my tablet yet, but I can imagine situations where it would be desirable that the input is mapped to a sub-region of the window. > When > developing for the more esoteric devices, such as space controllers, > my expectation is that the developer is targetting the user's device > specifically, I've got a 6axis space controller, but I intend to use it no different then a joystick and not target it specifically. > (which are often incorrect). This sheds an entirely new light on the min/max topic, I though they would be correct. If they're often incorrect I might as well just implement a device calibration utility to be used on a device before that device can actually be used by a program. The space controller of mine (3dconnexion space navigator PE) has a problem with evdev that its axes are reported as Relative (even though they're Absolute), and from having a quick glance at evdev.c in the linux kernel I can tell there's no way to get min/max information for relative axes (you have a #TODO there, but you can just as well drop that for evdev) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pyglet-users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/pyglet-users?hl=en -~----------~----~----~----~------~----~------~--~---
