2:30 p.m.
Ahoy,
is there a way I can contribute to bring the X11 SummaSketch driver
package back to life?
It is not on the list of depreciated packages,
* https://fedoraproject.org/wiki/Deprecated_packages
but the package was de facto given up after F10,
* http://koji.fedoraproject.org/koji/packageinfo?packageID=859
* https://admin.fedoraproject.org/pkgdb/acls/name/xorg-x11-drv-summa
See also
* http://forums.fedoraforum.org/showthread.php?t=262859
Thx,
-- Dan
2:57 p.m.
On Wed, May 11, 2011 at 09:30:07PM +0200, Dan wrote:
but the package was de facto given up after F10,
* http://koji.fedoraproject.org/koji/packageinfo?packageID=859
* https://admin.fedoraproject.org/pkgdb/acls/name/xorg-x11-drv-summa
http://cgit.freedesktop.org/xorg/driver/xf86-input-summa/commit/?id=4477f...
- it's unmaintained upstream, so someone would have to take it over
there.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
3:06 p.m.
On Wed, 2011-05-11 at 21:30 +0200, Dan wrote:
Ahoy,
is there a way I can contribute to bring the X11 SummaSketch driver
package back to life?
Start by getting it to build against a recent X server. It's been
formally unmaintained upstream since February 2009:
http://cgit.freedesktop.org/xorg/driver/xf86-input-summa
You can probably crib from the evdev driver changelog to see what API
changes you need to adapt to. But I believe the long-term goal is to
move input drivers into the kernel as evdev sources, as much as
possible, and let the evdev X driver pick up the simple ones
automatically. (Complicated things like wacom and synaptics keeping
their own drivers, but still eating evdev events from the kernel.)
- ajax
7:15 p.m.
On Wed, May 11, 2011 at 04:06:05PM -0400, Adam Jackson wrote:
On Wed, 2011-05-11 at 21:30 +0200, Dan wrote:
> Ahoy,
>
> is there a way I can contribute to bring the X11 SummaSketch driver
> package back to life?
Start by getting it to build against a recent X server. It's been
formally unmaintained upstream since February 2009:
http://cgit.freedesktop.org/xorg/driver/xf86-input-summa
I just looked through the history of this driver. The latest commit that I
can find that _may_ be an actual fix to the driver (as opposed to general
autotool and misc fixes applied to all drivers in unison) is
d7b1d0dbf923 on 25 Nov 2003. But tbh that looks like a generic fix as well, so
you hit the first revision, the xfree86 import, from 14 Nov 2003.
There's strong evidence that this driver hasn't been tested since, at least
not by the developers.
It was deactivated over 2 years ago upstream and shortly thereafter removed
from Fedora. IIRC, I couldn't find any real bugreports for summa in either
the fd.o nor the Fedora bugzilla.
Did you actually use this driver in the past?
You can probably crib from the evdev driver changelog to see what
API
changes you need to adapt to. But I believe the long-term goal is to
move input drivers into the kernel as evdev sources, as much as
possible, and let the evdev X driver pick up the simple ones
automatically. (Complicated things like wacom and synaptics keeping
their own drivers, but still eating evdev events from the kernel.)
indeed. X input drivers are just feature-sets these days, no real drivers
anymore. And these feature sets are overlapping enough that we don't need
different drivers for different hardware.
Try to make the kernel handle the device and let evdev do the rest. the
protocol is documented in xf86Summa.c and looks reasonable simple on a first
glance, so transferring that into a kernel driver should be possible.
Cheers,
Peter
4:14 a.m.
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.
Greets,
-- Dan
7:57 p.m.
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=f85c...
and the few commits beforehand, summa will need the same ones.
Cheers,
Peter
4754
days inactive
4756
days old
5 comments
4 participants
participants (4)
-
Adam Jackson -
Dan -
Matthew Garrett -
Peter Hutterer