Mansour Al Akeel <mansour.alakeel@...> posted
20090412081011.GA4008@..., excerpted below, on  Sun, 12 Apr 2009
05:10:11 -0300:

> 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):

http://www.gentoo.org/proj/en/desktop/x/x11/xorg-server-1.5-upgrade-
guide.xml

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