I detected that evdev.c is within the buildprocess during make World.
Unfortunately it fails here because it's not being able to find the defines:
Since I use the 2.6.12 Kernel tree I figured this in the include/input.h file
and everything is correctly defined there. But my System still uses the 2.4.20
headerfiles for userland compiles and thus these flags are not defined inside
the include/input.h file. It's quite common procedure to have older Kernel
headers laying around in /usr/include to compile Userland files and still being
able to use the latest Kernels out. This is even recommended by Linus and Alan
(and of course is written somewhere as FAQ too). I would therefore like to ask
whether this one can be fixed. Imagine all the 2.4.x people outside who wants to
test XOrg from CVS but fail due that file. I for now pass this stuff by simply
skipping it in the build process.
I checked this one up a bit closer and realized that some ChangeLog entries
exist and that someone added a check for 2.6.x Kernels so it avoid getting build
on 2.4.x Kernels. Though in linux.cf only the existence for an OS 2.6.x is being
checked but having 2.6.x installed doesn't necessarily mean that UserLand
applications have access to 2.6.x headers at least not in this case. It looks
like it detects my new 2.6.x Kernel but still uses the 2.4.x UserLand headers
found in /usr/include/linux.
yeah, i know, it's obnoxious.
this is exactly the place where linus' argument breaks down, because there is no
C library interface to evdev, and at least for keyboards the only way to get
evdev to work correctly is to use 2.6.
patch posted at bug #968, track it there.
*** This bug has been marked as a duplicate of 968 ***