[Bf-blender-cvs] SVN commit: /data/svn/bf-blender [30902] branches/soc-2010-merwin: experiments and notes

Mike Erwin significant.bit at gmail.com
Fri Jul 30 14:44:49 CEST 2010


Revision: 30902
          http://projects.blender.org/plugins/scmsvn/viewcvs.php?view=rev&root=bf-blender&revision=30902
Author:   merwin
Date:     2010-07-30 14:44:49 +0200 (Fri, 30 Jul 2010)

Log Message:
-----------
experiments and notes

Added Paths:
-----------
    branches/soc-2010-merwin/experimental/OLED test icons/
    branches/soc-2010-merwin/experimental/OLED test icons/blender-32.png
    branches/soc-2010-merwin/experimental/OLED test icons/blender-64.png
    branches/soc-2010-merwin/experimental/OLED test icons/crayons.png
    branches/soc-2010-merwin/experimental/OLED test icons/gray-ramp.png
    branches/soc-2010-merwin/experimental/TabletDeviceData.c
    branches/soc-2010-merwin/notes/week 10 notes
    branches/soc-2010-merwin/notes/week 7 notes
    branches/soc-2010-merwin/notes/week 9 notes

Added: branches/soc-2010-merwin/experimental/OLED test icons/blender-32.png
===================================================================
(Binary files differ)


Property changes on: branches/soc-2010-merwin/experimental/OLED test icons/blender-32.png
___________________________________________________________________
Name: svn:mime-type
   + image/png

Added: branches/soc-2010-merwin/experimental/OLED test icons/blender-64.png
===================================================================
(Binary files differ)


Property changes on: branches/soc-2010-merwin/experimental/OLED test icons/blender-64.png
___________________________________________________________________
Name: svn:mime-type
   + image/png

Added: branches/soc-2010-merwin/experimental/OLED test icons/crayons.png
===================================================================
(Binary files differ)


Property changes on: branches/soc-2010-merwin/experimental/OLED test icons/crayons.png
___________________________________________________________________
Name: svn:mime-type
   + image/png

Added: branches/soc-2010-merwin/experimental/OLED test icons/gray-ramp.png
===================================================================
(Binary files differ)


Property changes on: branches/soc-2010-merwin/experimental/OLED test icons/gray-ramp.png
___________________________________________________________________
Name: svn:mime-type
   + image/png

Added: branches/soc-2010-merwin/experimental/TabletDeviceData.c
===================================================================
--- branches/soc-2010-merwin/experimental/TabletDeviceData.c	                        (rev 0)
+++ branches/soc-2010-merwin/experimental/TabletDeviceData.c	2010-07-30 12:44:49 UTC (rev 30902)
@@ -0,0 +1,122 @@
+#include <stdio.h>
+#include <stdbool.h>
+
+typedef enum { NONE, PEN, ERASER, MOUSE } TabletToolType;
+
+typedef struct
+	{
+	TabletToolType type : 6; // plenty of room to grow
+
+	// capabilities
+	bool hasPressure : 1;
+	bool hasTilt : 1;
+	
+	} TabletTool;
+
+
+typedef struct
+	{
+	TabletTool tool;
+
+	float pressure;
+	float tilt_x, tilt_y;
+
+	} TabletToolData;
+
+
+void useData(TabletToolData* data)
+	{
+	switch (data->tool.type)
+		{
+		case PEN:
+			puts("from pen");
+			break;
+		case ERASER:
+			puts("from eraser");
+			break;
+		default:
+			// mouse events should not have TabletToolData attached, even for tablet mice!
+			puts("from something else");
+		}
+
+	if (data->tool.hasPressure)
+		printf("  pressure = %.3f\n", data->pressure);
+
+	if (data->tool.hasTilt)
+		printf("  tilt = %.3f,%.3f\n", data->tilt_x, data->tilt_y);
+	}
+
+
+// also look at wmEvent fields and size:
+
+typedef struct wmEvent {
+	struct wmEvent *next, *prev;
+	
+	short type;			/* event code itself (short, is also in keymap) */
+	short val;			/* press, release, scrollvalue */
+	short x, y;			/* mouse pointer position, screen coord */
+	short mval[2];		/* region mouse position, name convention pre 2.5 :) */
+	short unicode;		/* future, ghost? */
+	char ascii;			/* from ghost */
+
+	/* previous state */
+	short prevtype;
+	short prevval;
+	short prevx, prevy;
+	double prevclicktime;
+	short prevclickx, prevclicky;
+	
+	/* modifier states */
+	short shift, ctrl, alt, oskey;	/* oskey is apple or windowskey, value denotes order of pressed */
+	short keymodifier;				/* rawkey modifier */
+	
+	/* keymap item, set by handler (weak?) */
+	const char *keymap_idname;
+	
+	/* custom data */
+	short custom;		/* custom data type, stylus, 6dof, see wm_event_types.h */
+	short customdatafree;
+	void *customdata;	/* ascii, unicode, mouse coords, angles, vectors, dragdrop info */
+	
+} wmEvent;
+
+int main()
+	{
+	// nice & compact?
+	printf("tool = %d bytes\n", sizeof(TabletTool));
+	printf("data = %d bytes\n", sizeof(TabletToolData));
+	printf("wmEvent = %d bytes\n", sizeof(wmEvent));
+
+	puts("---------------------");
+
+	TabletToolData pen = {{PEN,true,true},0.5,0.2,0.1};
+	TabletToolData eraser = {{ERASER,true,false},0.8675309};
+	TabletToolData mouse = {{MOUSE,false,false}};
+
+	useData(&pen);
+	useData(&eraser);
+	useData(&mouse);
+	};
+
+
+/*
+
+Other tablet types & events will be needed soon:
+
+TabletButton
+	- down/press
+	- up/release
+
+TabletValuator
+	- adjust/change (by how much, and in which direction)
+
+-----------------------
+
+For example:
+
+tablet button 1 down
+tablet valuator 3 adjust +5
+
+These don't mean anything at the event-capture level. They do mean something to specific operators.
+
+*/


Property changes on: branches/soc-2010-merwin/experimental/TabletDeviceData.c
___________________________________________________________________
Name: svn:eol-style
   + native

Added: branches/soc-2010-merwin/notes/week 10 notes
===================================================================
--- branches/soc-2010-merwin/notes/week 10 notes	                        (rev 0)
+++ branches/soc-2010-merwin/notes/week 10 notes	2010-07-30 12:44:49 UTC (rev 30902)
@@ -0,0 +1,347 @@
+25 July --
+
+Reading about USB programming on Linux. User-space stuff, I'm not making a driver module! libusb is a nice low-level interface, libhid is a bit higher. Very handy functions within libusb:
+
+bool has_evil_driver = libusb_kernel_driver_active(...);
+
+if (has_evil_driver)
+	libusb_detach_kernel_driver(...);
+
+// communicate directly with the device
+
+if (has_evil_driver)
+	libusb_attach_kernel_driver(...);
+
+Not sure, but libhid might do that for us. It's built atop an older version of libusb.
+
+Oh yeah, new section:
+How (I think) the Linux SpaceNav driver works.
+
+Only the closed-source driver communicates with the device. When something happens and it has some data to share, it says so through Atoms. The blender plugin registers for and keeps an eye on these Atoms. When they change, it updates a data structure shared with the blender app, then sends an XClientMessage to the app to notify it of the change. When the app's event-processing code comes across an XClientMessage with the relevant bits set, it constructs an NDOF event with the new data. Whew! I think that's it.
+
+I'd like to get rid of the plugin level, possibly the driver level. This already works on Windows! And on the Mac, blender now talks directly to the driver, with no plugin.
+
+Linux supports 4 basic types of device at the HID level: keyboard, mouse, joystick, and generic. We want generic.
+
+Look in /proc/bus/usb/devices.
+
+Is there a way to simply find a "file" of the device's output, and read it in? That would be silly simple.
+
+Found an open-source alternative SpaceNav driver and SDK! Very very nice. It uses evdev underneath. I'm still leaning toward libhid for this and for some advanced Intuos stuff.
+
+
+26 July --
+
+MacPaint and QuickDraw source code released!!! It's very clean, beautiful Pascal and 68000 assembly. Most excellent.
+
+A visual scan of the NDOF capture and dispatch log suggests a revision to the Windows code. I'm using buffered RawInput, which worked well for mouse moves (now gone). The buffered version missed some mouse clicks (now gone), so I did a first pass with grabbing a single event. Once mouse was out of the way, SpaceNav is the only user of RawInput. The "grab first" then "grab rest" was getting duplicate axis input, so I simplified it to use only a buffered read. Duplicate events vanished, so I thought I was done. Nope!
+
+Some button data disappears before I have a chance to read it (the WM_INPUT gets sent, but there's no events to grab). Also, some axis events are disappearing. It's generally very responsive, but doesn't always notice the zero motion and set itself to "at rest". I'm sure other events are slipping through, but this is the most important and noticeable one. Even with buffered input, I always get only one event.
+
+Changing to "grab first" should fix all this, if other machines act like mine does now. I'm testing on a slow-ish Pentium 4 running XP SP3. No 3Dconnexion driver, just using HID. Hey, there's a good next step: try same with their driver installed. Does it change anything?
+
+Got an email and forum reply from M. Lomotan: don't include their headers in our source (or lib) tree, must install the driver to build. And of course to use. Will probably switch to HID Manager to avoid this. I like how on Windows you don't need anything but Windows to build and run. Very nice. Aim for same on Linux. Support rarer UNIX systems? Mac OS 8.6?
+
+
+29 July --
+
+Higher-level NDOF stuff, thanks to grep:
+
+editors/transform/transform.c
+editors/transform/transform_ndofinput.c
+makesrna/intern/rna_userdef.c
+windowmanager/intern/wm_init_exit.c
+editors/space_view3d/view3d_header.c
+editors/space_view3d/view3d_edit.c
+editors/include/UI_icons.h
+makesdna/DNA_view3d_types.h
+blenkernel/BKE_global.h
+
+wmEvent is defined in WM_types.h, lots of "extra" stuff per event, e.g. window and region coordinates for all events (even position-less SpaceNav events). It's probably safe to zero out all the unneeded fields.
+
+	/* custom data */
+	short custom;		/* custom data type, stylus, 6dof, see wm_event_types.h */
+	short customdatafree;
+	int pad2;
+	void *customdata;	/* ascii, unicode, mouse coords, angles, vectors, dragdrop info */
+
+typedef struct wmTabletData {
+	int Active;			/* 0=EVT_TABLET_NONE, 1=EVT_TABLET_STYLUS, 2=EVT_TABLET_ERASER */
+	float Pressure;		/* range 0.0 (not touching) to 1.0 (full pressure) */
+	float Xtilt;		/* range 0.0 (upright) to 1.0 (tilted fully against the tablet surface) */
+	float Ytilt;		/* as above */
+} wmTabletData;
+
+That's what I'm calling TabletToolData. If there's something similar for NDOF events, it's not in this file. Probably not yet defined for 2.5's new event system.
+
+From wm_event_types.h:
+
+/* customdata type */
+#define EVT_DATA_TABLET		1
+#define EVT_DATA_GESTURE	2
+#define EVT_DATA_TIMER		3
+#define EVT_DATA_LISTBASE	4
+
+/* tablet active, matches GHOST_TTabletMode */
+#define EVT_TABLET_NONE		0
+#define EVT_TABLET_STYLUS	1
+#define EVT_TABLET_ERASER	2
+
+Which confirms my suspicions -- this is where the NDOF data/flags will live.
+
+If there's a good way to do this, I'd prefer single customdata structures shared between wm and ghost. That eliminates the need to double-allocate and copy the data, and to have the same thing defined twice (and kept in sync!). I dunno, something to strive for.
+
+Each wmEvent is 72 bytes. The horror! 68 without padding fields.
+
+In wm_event_types.h:
+#define INBETWEEN_MOUSEMOVE	0x011
+

@@ Diff output truncated at 10240 characters. @@




More information about the Bf-blender-cvs mailing list