Since the removal of the motion history handling by Danial Stone, in commit 0514d53e10b3521bb708a9cbde4bab525248eadb many input drivers are not building because they still try to make use of ->history_size in struct _LocalDeviceRec. I don't understand how a build regression like this can persist in the mainline sources for months :-/ If these drivers are not supposed to be built, take them out of the build.sh script or something like that. From a quick grep of drivers/xf86-input-*/*/*.c it seems like pretty much every single xf86-input driver won't build because of this.
*** 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.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.