Mansour Al Akeel <mansour.alakeel@...> posted
20090412081011.GA4008@..., excerpted below, on Sun, 12 Apr 2009
> Martin, thank you for the fast reply. I just tried recompiling the
> drivers under x11-driver/* but still no luck.
I don't see a Serverflags section in your xorg.conf, which means if you
have compiled xorg-server with the hal USE flag it almost certainly WILL
ignore your xorg.conf InputDevice section settings and hotplug using HAL.
(No, I'm not sure what it does if you emerge xorg-server with USE=-hal.)
Here's a quote from the xorg.conf manpage, Serverflags section, for the
particular option in question:
Option "AllowEmptyInput" "boolean"
If enabled, don't add the standard keyboard and mouse drivers,
if there are no input devices in the config file. Enabled by
default if AutoAddDevices and AutoEnableDevices is enabled,
otherwise disabled. If AllowEmptyInput is on, devices using
the kbd, mouse or vmmouse driver are ignored.
(As noted there's the related AutoAddDevices and AutoEnableDevices
options as well. They're enabled by default, so this one is as well.)
As I've posted in other threads, this is all covered in Gentoo's xorg-
server 1.5 upgrade guide, with the various configuration alternatives,
here (watch the wrap):
The idea is to use hal hotplugging goodness by default but allow fallback
to the xorg.conf configured drivers when hal breaks.
Note that the upgrade guide has a link to a special hal *.fdi file for
synaptics users. You can drop that into /etc/hal/fdi/policy, making any
modifications to it you'd like just as you would to the xorg.conf
InputDevice section for a synaptics pad, and it should work.
FWIW, when I first upgraded here (I'm on ~arch so I upgraded some time
ago), I had all sorts of problems, because it was trying to default to
evdev, which I didn't have compiled for xorg or the kernel either one! I
temporarily solved that by using the AllowEmptyInput option above, then
later, thus getting mouse and keyboard working normally again, then only
later, when I had time to mess with it, tried the evdev stuff.
When I DID try evdev I followed the (then) upgrade guide, and STILL
couldn't get it to work. After trying various *.fdi edits for hours, I
eventually realized I needed evdev enabled in my kernel as well. The
upgrade guide at the time mentioned enabling it in INPUT_DEVICES in
make.conf but did *NOT* mention the kernel. That was only a few days
before they went stable with the new version and upgrade guide so I had
to hustle to get the bug in and they had to hustle to get the
instructions for the kernel added, but my experience and bug is why
that's in the upgrade guide now.
After I enabled evdev in the kernel, it pretty much "just worked", altho
I did need to modify a *.fdi file based on the various documentations to
match the keyboard key and merge an input.x11.options.XkbModel key with a
value changed from the default "evdev" to "microsoftpro", to enable the
extra keys on my Logitech keyboard. That bit is roughly the same except
for the keyboard as you're doing for the mouse by dropping that synaptics
*.fdi file in that policy subdir as I mentioned above.
One final thing. Anybody with SDL merged for anything (often games)
should pay attention to the troubleshooting tip at the bottom of the
upgrade guide. I'm not sure it applies to a synaptics, but at least a
regular mouse won't work in SDL apps using evdev, otherwise. I noticed
my DOSBOX/SDL keyboard mapping is a bit funky using the evdev keyboard
driver too, but DOSBOX has a remapping tool, which has worked for now.
Maybe I'll look into that angle further later, but the hint about
disabling dga for SDL apps using the mouse sure helped for it!
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman