On Thu, May 12, 2011 at 11:14:43AM +0200, Dan wrote:
> Thx. for your prompt replies.
> > Did you actually use this driver in the past?
> Yes. I can positivly confirm this driver has worked in the past. It
> could be used with the mouse or touchpad in parallel. The working is
> such that when you put the "cursor" or "puck" on the tablet, the pointer
> jumps to the respective place on the screen, from where you can move it
> away using the mouse. The pointer jumps back to the original position as
> soon as you touch the puck again. We've used our tablets with their
> styluses and 4-button pucks, which was both OK with the X11 driver. (The
> protocol indicates if a 4-button puck, a 16-button puck, or the stylus
> is connected to the tablet.)
>
> I have a SummaSketch III ("MM III 1201") in front of me (sensitive area:
> 12x12 inch, but larger tablets exist, I think up to DIN A3 landscaped,
> or so, with a model number of "17something"), and an earlier model sits
> in a box waiting for light (some SummaSketch II model). The tablets have
> been in wide use in the 1990ies with CAD software and are very robust.
> Several devices of other brands emulate their standard protocol, though
> simple, which is called just the "MM" protocol. The original SummaSketch
> tablets can talk one other protocol, but I think it is not used by the
> X11 SummaSketch driver. Actually, most of the SummaSketch tablets
> originally may well have been run with Unix because at least one
> prominent CAD software, Nemetschek Allplan,
> * http://en.wikipedia.org/wiki/Nemetschek
> * http://de.wikipedia.org/wiki/Nemetschek_Allplan
> was delivered for commercial Unices since the end of the 1980ies.
>
> It seems the tablets have fallen off the earth mostly because of missing
> driver support on Win and on X11. Search engine results indicate people
> have made attempts to turn the lights of their SummaSketches back on
> until recently, but appearently none has filed a bug report or feature
> request somewhere.
>
> Before I posted here I made an attempt to get away with the F10 386 RPM
> of the driver on a F14 installation but did not succeed because of at
> least one missing symbol, according to the X11 log file.
>
> I guess I'm not competent enough to write support for the MM protocol as
> a kernel module from the ground. (Really, you don't want me to put my
> fingers into to the kernel machinery, because I'm a Lisp guy.) For now,
> I could try to revive the driver mostly as is, and even then I'll have a
> steap learning curve. Currently, I don't have even a remote idea of the
> evdev driver, let alone the X11 API, I'm only about to get familiar with
> the source of the SummaSketch driver.
Search through the evdev driver git logs for anything that includes ABI in
general or GET_ABI_MAJOR. Up to input ABI 12, all that happened was pretty much
adding/removing parameters from InitValuatorClassDeviceStruct and similar,
so that's straightforward enough.
Input ABI 12 (which is what's in F15) introduced a new PreInit scheme.
Again, you can get the basics from the evdev or synaptics driver (or even
one of the other drivers like acecad) to get a guideline. It's mostly going
to be shuffling code around and changing return codes.
http://cgit.freedesktop.org/xorg/driver/xf86-input-acecad/commit/?id=f85c4b580c074f7054eac98753d1f4e91f08305e
and the few commits beforehand, summa will need the same ones.
Cheers,
Peter
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
