Re: X11 SummaSketch Driver?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux