Bug 10262

*** Bug 10263 has been marked as a duplicate of this bug. ***

yeah, i'm aware of the issue and it's on my todo list.  but quite low on my todo list, since i can virtually guarantee you don't use those drivers anyway.

also, out of interest, why are you trying to build the entire x tree from scratch? unless you're using sls or something, your distribution should have reasonably up to date sources for the large percentage of modules that haven't changed at all in years.

I wanted to start hacking on X, so the first thing I did was read
the documentation on how to build the tree out of GIT, using the
build.sh script, and it failed.  Part of what I wanted to improve
were any build warnings or failures specific to Linux/sparc64.

This is a serious quality control issue in my opinion.  If you change
interfaces you should either get the drivers using them fixed up
quickly or deprecate the drivers.  If you don't have time to do this,
the changes aren't ready to go in yet, ask someone for help.  For
something as important as input device hot-plug I'm sure you could
find someone if it was holding up the merge. :-)

A few weeks I could understand, especially if the infrastructure change
was enormous.  But 4 months?  You've got to be kidding me.  Also, if
you don't nip these kinds of things in the butt from the get-go, by the
time you get to it most of the context will be swapped out of your brain
and it'll be harder and more error prone to do the conversions.

If we did this in the Linux kernel people would publicly hang us.  Rarely
do the most obscure drivers go unbuildable for more than a day or two
because lots of people are doing builds with every driver enabled.

welcome to the land of x, where we have a desperate developer shortage, and one of two input developers is juggling input/xkb, a reverse-engineered driver, x.org foundation board, fd.o admin, et al, and the other one is juggling a phd and multiple-cursor work.

i counted the other day and only came up with about 16 currently active developers, of which maybe half are full-time.  this isn't the kernel ...

regardless, i've added the old api back.  enjoy.

Please do me a real huge favor, type 'make' in a few input drivers
before closing this bug, I'd really appreciate it, thanks.

The bug isn't fixed, most of the input drivers still don't
build, and looking at your xserver changeset I don't see how
you expected it to fix the build regressions added by the input
layer hot-plug stuff.  You added the ->history_size bit back,
but you didn't add any of the other old things your removed which
these various input drivers want, such as motion_history_proc.

One example error is, with xf86-input-acecad:

acecad.c:50:1 warning: "NEED_XF86_TYPES" redefined
In file included from ../config.h:4
                 from acecad.c:29:
/opt/xorg/include/xorg/xorg-xserver.h:69:1: warning: this is the location of the previous definition
acecad.c: In function 'AceCadPreInit':
acecad.c:192: error: 'struct _LocalDeviceRec' has no member named 'motion_history_proc'
acecad.c:283: error: invalid use of void expression

But you can try just about any input driver and you'll see this failure.

Please don't rush this and fix the build regression properly, thanks
a lot.

(In reply to comment #5)
> Please do me a real huge favor, type 'make' in a few input drivers
> before closing this bug, I'd really appreciate it, thanks.

i did, actually (mainly calcomp, iirc).  not that this paragraph is making me extremely keen to download all the other drivers and try those too.

> The bug isn't fixed, most of the input drivers still don't
> build, and looking at your xserver changeset I don't see how
> you expected it to fix the build regressions added by the input
> layer hot-plug stuff.  You added the ->history_size bit back,
> but you didn't add any of the other old things your removed which
> these various input drivers want, such as motion_history_proc.

i didn't realise people were setting m_h_p as well, because there's no reason i can see that they would want to.

From what I saw by building the input drivers in Debian recently, the ones that still don't build with input proto 1.4 are:
xf86-input-calcomp
xf86-input-citron
xf86-input-dmc
xf86-input-dynapro
xf86-input-elo2300
xf86-input-microtouch
xf86-input-penmount

Created attachment 9866 [details] [review]
Build patch

Created attachment 9867 [details] [review]
Build patch

Created attachment 9868 [details] [review]
Build patch

Created attachment 9869 [details] [review]
Build patch

Created attachment 9870 [details] [review]
Build patch

Created attachment 9871 [details] [review]
Build patch

Created attachment 9872 [details] [review]
Build patch

This one didn't compile on my computer but that may be an error on my side.
Please omit if unnecessary.

Following up Brice's list of the seven broken drivers, they all have the common problem "error: 'TS_Raw' undeclared".

TS_Raw (and friends) was added to XI.h in commit 4383a95e0bbc2f09394deefc453c2edd1c813d0f, 14 Nov 2003 by Kaleb Keithley, "XFree86 4.3.0.1".

Daniel removed them in commit 7a4a2a3e733378abced0a184627adfda4ed387b9, 17 Jul 2006, "add DevicePresenceNotify event, clean up", saying "Clean up some random detritus from the MetroLink merge.".

Daniel, does this mean these MetroLink TS_ defines are needed after all?

TS_Raw was ostensibly there as a wire constant, but it was unused in that sense.  if drivers need it as an internal value, they can use an enum or something else internal.  i'll fix these up when i get back from holiday.

all of the drivers now build.

> all of the drivers now build.

I can't see any substantial changes to the code. Testing calcomp, for instance, I still get the same error:  'TS_Raw' undeclared.  Did you need to push the fixes up to the freedesktop.org repo, or did I miss something important?

Drew, TS_Raw has been re-added to xf86XInput.h in Xserver in commit 9398d62f27ee1b287e4458fd8b011c10f7b59efd

Ah thanks, I see it now.  I saw that it hadn't been added back to XI.h and didn't know where else to look.

That means the fix did not make it into xserver 1.3.0.0, which is what I was building against.  Is there any sense in adding a patch to 1.3 (release a 1.3.1?), or should we just ignore the problem, especially since xserver 1.4 is nearly ready?

After talking to daniels on IRC I pushed fixes to acecad, vmmouse, and void
based on the code he put in xf86-input-mouse to make them build without the
old motion_history stuff.     That seems to leave citron as the only driver
I can't build the current git tree of against xserver-1.4-branch - it fails with:

xf86-input-citron:
  "citron.c", line 2023: undefined symbol: xDeviceTSCalibrationCtl

Line 2023 is:
        xDeviceTSCalibrationCtl *c = (xDeviceTSCalibrationCtl *) control;

that should be replaced by AbsCalibCtl, IIRC.

Just one driver left isn't enough to block release.  Clearing status.

Fix to citron pushed to git master too now.   Closing as fixed.