So you're running an X server? Well, my lad or lass, sit down and let me tell you about the neverending story of X server input configuration changes that has hopefully ended now. I'm just pushing the latest X server goodness into rawhide and enabling udev, completing (from the X server's POV) the excision of the hardware abstraction layer that shall not be named.
From F9 to including F12 (and rawhide until today) we've used hal to
discover the input devices. For lack of better options, this means that many configurations have moved into fdi files. As you may know, hal is deprecated and as much as fdi files may be pleasing to the eyes, there's just no future in them. You'll just have to let it go, even if it hurts.
Instead, we have the newest latest and greatest bits, namely xorg.conf.d support and InputClasses. You can drop configuration files into the new directory and the server will pick it up on startup. e.g. /etc/xorg.conf.d/foobar.conf "A configuration directory? Is this even possible?" you say? I know, it sounds mightily advanced but we have to keep surfing the wave of new technological achievements.
The existing section types in xorg.conf(5) weren't really suitable, so we now have something that resembles the functionality provided by hal's fdi files. A section of type InputClass will match against multiple devices and even hotplugged ones - depending on the match rules. An example section looks like this:
Section "InputClass" Identifier "superhero mouse config" MatchIsPointer "on" MatchProduct "Mighty Mouse" Driver "evdev" Option "X-Ray vision" "on" EndSection
Any pointer device that contains "Mighty Mouse" in its product name will match against this section and be added with the evdev driver and the options as specified. That's just one example, I've tried to detail the new configurations on our wiki. https://fedoraproject.org/wiki/Input_device_configuration If you think there's anything missing, please let me know or add it yourself.
Because the match rules are different to hal's matching rules, we don't have an automatic conversion from your custom fdi files into xorg.conf format. If you have custom rules, I recommend porting them to the new format before updating to ensure a smooth upgrade.
Cheers, Peter
Hi,
So you're running an X server? Well, my lad or lass, sit down and let me tell you about the neverending story of X server input configuration changes that has hopefully ended now. I'm just pushing the latest X server goodness into rawhide and enabling udev, completing (from the X server's POV) the excision of the hardware abstraction layer that shall not be named.
From F9 to including F12 (and rawhide until today) we've used hal to
discover the input devices. For lack of better options, this means that many configurations have moved into fdi files. As you may know, hal is deprecated and as much as fdi files may be pleasing to the eyes, there's just no future in them. You'll just have to let it go, even if it hurts.
Instead, we have the newest latest and greatest bits, namely xorg.conf.d support and InputClasses. You can drop configuration files into the new directory and the server will pick it up on startup. e.g. /etc/xorg.conf.d/foobar.conf "A configuration directory? Is this even possible?" you say? I know, it sounds mightily advanced but we have to keep surfing the wave of new technological achievements.
The existing section types in xorg.conf(5) weren't really suitable, so we now have something that resembles the functionality provided by hal's fdi files. A section of type InputClass will match against multiple devices and even hotplugged ones - depending on the match rules. An example section looks like this:
Section "InputClass" Identifier "superhero mouse config" MatchIsPointer "on" MatchProduct "Mighty Mouse" Driver "evdev" Option "X-Ray vision" "on" EndSection
Any pointer device that contains "Mighty Mouse" in its product name will match against this section and be added with the evdev driver and the options as specified. That's just one example, I've tried to detail the new configurations on our wiki. https://fedoraproject.org/wiki/Input_device_configuration If you think there's anything missing, please let me know or add it yourself.
How is this going to affect some users that don't read release notes nor fedora devel list? Also, I have some configuration in fdi files (for touchpad for example). Will it still work with some (not too much visible?) complains in logs "this is deprecated"? Will it stop working without any information in logs? ...
Because the match rules are different to hal's matching rules, we don't have an automatic conversion from your custom fdi files into xorg.conf format. If you have custom rules, I recommend porting them to the new format before updating to ensure a smooth upgrade.
Cheers, Peter
Cheers, Michal
On Tue, Feb 16, 2010 at 08:25:54AM +0100, Michal Hlavinka wrote:
Hi,
So you're running an X server? Well, my lad or lass, sit down and let me tell you about the neverending story of X server input configuration changes that has hopefully ended now. I'm just pushing the latest X server goodness into rawhide and enabling udev, completing (from the X server's POV) the excision of the hardware abstraction layer that shall not be named.
From F9 to including F12 (and rawhide until today) we've used hal to
discover the input devices. For lack of better options, this means that many configurations have moved into fdi files. As you may know, hal is deprecated and as much as fdi files may be pleasing to the eyes, there's just no future in them. You'll just have to let it go, even if it hurts.
Instead, we have the newest latest and greatest bits, namely xorg.conf.d support and InputClasses. You can drop configuration files into the new directory and the server will pick it up on startup. e.g. /etc/xorg.conf.d/foobar.conf "A configuration directory? Is this even possible?" you say? I know, it sounds mightily advanced but we have to keep surfing the wave of new technological achievements.
The existing section types in xorg.conf(5) weren't really suitable, so we now have something that resembles the functionality provided by hal's fdi files. A section of type InputClass will match against multiple devices and even hotplugged ones - depending on the match rules. An example section looks like this:
Section "InputClass" Identifier "superhero mouse config" MatchIsPointer "on" MatchProduct "Mighty Mouse" Driver "evdev" Option "X-Ray vision" "on" EndSection
Any pointer device that contains "Mighty Mouse" in its product name will match against this section and be added with the evdev driver and the options as specified. That's just one example, I've tried to detail the new configurations on our wiki. https://fedoraproject.org/wiki/Input_device_configuration If you think there's anything missing, please let me know or add it yourself.
How is this going to affect some users that don't read release notes nor fedora devel list? Also, I have some configuration in fdi files (for touchpad for example). Will it still work with some (not too much visible?) complains in logs "this is deprecated"? Will it stop working without any information in logs? ...
hmm, at this point, yes, pretty much. The fdi files are merged in by HAL itself and their content is part of the information that HAL provides to the server. since the server doesn't listen to HAL anymore, this information gets ignored. All you'll see in the log is that it now says "udev" where it used to say "HAL".
I can put a giant warning into the log that if input devices don't work then the users should have a look at the website above for reconfiguration. How does that sound? Do you have any better suggestions?
Cheers, Peter
On 16.2.2010 08:47, Peter Hutterer wrote:
I can put a giant warning into the log that if input devices don't work then the users should have a look at the website above for reconfiguration. How does that sound? Do you have any better suggestions?
Do we have all currently packaged .fdi files converted to The New World Order™? If no, I guess that's the job for this lowly bugmaster.
Matěj
On Tue, Feb 16, 2010 at 10:54:37AM +0100, Matěj Cepl wrote:
On 16.2.2010 08:47, Peter Hutterer wrote:
I can put a giant warning into the log that if input devices don't work then the users should have a look at the website above for reconfiguration. How does that sound? Do you have any better suggestions?
Do we have all currently packaged .fdi files converted to The New World Order™? If no, I guess that's the job for this lowly bugmaster.
evdev and synaptics are updated, so those two are converted. I know fpit has an fdi file and there's some exceptions in x11-input.fdi that need to be added too. I need to do this tomorrow unless you want to beat me to it :)
Cheers, Peter
Peter Hutterer wrote:
evdev and synaptics are updated, so those two are converted. I know fpit has an fdi file and there's some exceptions in x11-input.fdi that need to be added too. I need to do this tomorrow unless you want to beat me to it :)
It's funny how short-lived the "no default xorg.conf" idea was, now we get default xorg.conf.d snippets. :-)
Kevin Kofler
On Wed, Feb 17, 2010 at 12:38:37AM +0100, Kevin Kofler wrote:
Peter Hutterer wrote:
evdev and synaptics are updated, so those two are converted. I know fpit has an fdi file and there's some exceptions in x11-input.fdi that need to be added too. I need to do this tomorrow unless you want to beat me to it :)
It's funny how short-lived the "no default xorg.conf" idea was, now we get default xorg.conf.d snippets. :-)
yep. the more things change, the more they stay the same.
note that we (well, Dan, mostly) put some effort into having the new InputClass section work with this approach and it works distinctively different to the old InputDevice section. So the snippets aren't quite the same as the old xorg.conf, it's more hal's fdi files in xorg.conf syntax.
Cheers, Peter
On Wed, 2010-02-17 at 00:38 +0100, Kevin Kofler wrote:
Peter Hutterer wrote:
evdev and synaptics are updated, so those two are converted. I know fpit has an fdi file and there's some exceptions in x11-input.fdi that need to be added too. I need to do this tomorrow unless you want to beat me to it :)
It's funny how short-lived the "no default xorg.conf" idea was, now we get default xorg.conf.d snippets. :-)
You can have the defaults in the X server, or you can have them somewhere else on the filesystem...
- ajax
I'm not sure I understand exactly what you need here, but AIUI you just need this:
what I meant is that the scenario of having a composed layout (eg. Arabic/English or Arabic/French) should be part of QA tests
because a problem in them will case the user unable to login https://bugzilla.redhat.com/show_bug.cgi?id=508628 https://bugzilla.redhat.com/show_bug.cgi?id=493650
GDM in fedora used to reset grp:alt_shift_toggle to an empty string
of course when F13 alpha/beta is out I'll file full details if there is a problem, I'm currently using ojuba 3/Fedora 11) but I want to put you in the problem in advance as part of QA testing
On Tuesday 16 February 2010 08:47:20 Peter Hutterer wrote:
On Tue, Feb 16, 2010 at 08:25:54AM +0100, Michal Hlavinka wrote:
Hi,
So you're running an X server? Well, my lad or lass, sit down and let me tell you about the neverending story of X server input configuration changes that has hopefully ended now. I'm just pushing the latest X server goodness into rawhide and enabling udev, completing (from the X server's POV) the excision of the hardware abstraction layer that shall not be named.
From F9 to including F12 (and rawhide until today) we've used hal to
discover the input devices. For lack of better options, this means that many configurations have moved into fdi files. As you may know, hal is deprecated and as much as fdi files may be pleasing to the eyes, there's just no future in them. You'll just have to let it go, even if it hurts.
Instead, we have the newest latest and greatest bits, namely xorg.conf.d support and InputClasses. You can drop configuration files into the new directory and the server will pick it up on startup. e.g. /etc/xorg.conf.d/foobar.conf "A configuration directory? Is this even possible?" you say? I know, it sounds mightily advanced but we have to keep surfing the wave of new technological achievements.
The existing section types in xorg.conf(5) weren't really suitable, so we now have something that resembles the functionality provided by hal's fdi files. A section of type InputClass will match against multiple devices and even hotplugged ones - depending on the match rules. An example section looks like this:
Section "InputClass"
Identifier "superhero mouse config" MatchIsPointer "on" MatchProduct "Mighty Mouse" Driver "evdev" Option "X-Ray vision" "on"
EndSection
Any pointer device that contains "Mighty Mouse" in its product name will match against this section and be added with the evdev driver and the options as specified. That's just one example, I've tried to detail the new configurations on our wiki. https://fedoraproject.org/wiki/Input_device_configuration If you think there's anything missing, please let me know or add it yourself.
How is this going to affect some users that don't read release notes nor fedora devel list? Also, I have some configuration in fdi files (for touchpad for example). Will it still work with some (not too much visible?) complains in logs "this is deprecated"? Will it stop working without any information in logs? ...
hmm, at this point, yes, pretty much. The fdi files are merged in by HAL itself and their content is part of the information that HAL provides to the server. since the server doesn't listen to HAL anymore, this information gets ignored. All you'll see in the log is that it now says "udev" where it used to say "HAL".
I can put a giant warning into the log that if input devices don't work then the users should have a look at the website above for reconfiguration. How does that sound? Do you have any better suggestions?
Are existing *.fdi files going to be used by something (except hal itself)? If not, hal should be complaining during start up about "deprecated configuration found".
Also, is this 1:1 change or was something "improved", so we can see changes in behavior for touchpad or anything else?
Cheers, Peter
On Tue, Feb 16, 2010 at 12:16:42PM +0100, Michal Hlavinka wrote:
So you're running an X server? Well, my lad or lass, sit down and let me tell you about the neverending story of X server input configuration changes that has hopefully ended now. I'm just pushing the latest X server goodness into rawhide and enabling udev, completing (from the X server's POV) the excision of the hardware abstraction layer that shall not be named.
From F9 to including F12 (and rawhide until today) we've used hal to
discover the input devices. For lack of better options, this means that many configurations have moved into fdi files. As you may know, hal is deprecated and as much as fdi files may be pleasing to the eyes, there's just no future in them. You'll just have to let it go, even if it hurts.
Instead, we have the newest latest and greatest bits, namely xorg.conf.d support and InputClasses. You can drop configuration files into the new directory and the server will pick it up on startup. e.g. /etc/xorg.conf.d/foobar.conf "A configuration directory? Is this even possible?" you say? I know, it sounds mightily advanced but we have to keep surfing the wave of new technological achievements.
The existing section types in xorg.conf(5) weren't really suitable, so we now have something that resembles the functionality provided by hal's fdi files. A section of type InputClass will match against multiple devices and even hotplugged ones - depending on the match rules. An example section looks like this:
Section "InputClass"
Identifier "superhero mouse config" MatchIsPointer "on" MatchProduct "Mighty Mouse" Driver "evdev" Option "X-Ray vision" "on"
EndSection
Any pointer device that contains "Mighty Mouse" in its product name will match against this section and be added with the evdev driver and the options as specified. That's just one example, I've tried to detail the new configurations on our wiki. https://fedoraproject.org/wiki/Input_device_configuration If you think there's anything missing, please let me know or add it yourself.
How is this going to affect some users that don't read release notes nor fedora devel list? Also, I have some configuration in fdi files (for touchpad for example). Will it still work with some (not too much visible?) complains in logs "this is deprecated"? Will it stop working without any information in logs? ...
hmm, at this point, yes, pretty much. The fdi files are merged in by HAL itself and their content is part of the information that HAL provides to the server. since the server doesn't listen to HAL anymore, this information gets ignored. All you'll see in the log is that it now says "udev" where it used to say "HAL".
I can put a giant warning into the log that if input devices don't work then the users should have a look at the website above for reconfiguration. How does that sound? Do you have any better suggestions?
Are existing *.fdi files going to be used by something (except hal itself)? If not, hal should be complaining during start up about "deprecated configuration found".
input.x11_driver and input.x11_options are used only by X, so that'd be an option.
Also, is this 1:1 change or was something "improved", so we can see changes in behavior for touchpad or anything else?
The problem we had over the last few releases is that we had to resort to sticking xorg configuration into HAL for lack of an xorg-specific way. this was bad to begin with but got worse when HAL was deprecated. now we have to switch to a new config backend (udev) and instead of porting xorg configuration in HAL format to xorg configuration in udev format, we implemented an actual xorg-specific way upstream. so now, your xorg-specific configuration can be in xorg.conf or in /etc/xorg.conf.d/.
so in that way - it's mostly a 1:1 change in functionality, but an improvement in terms of integration.
neither server nor driver behaviour is affected by this, though, it's simply a change in how to get the same configuration options into the server.
Cheers, Peter
On Tue, Feb 16, 2010 at 09:26:54PM +1000, Peter Hutterer wrote:
On Tue, Feb 16, 2010 at 12:16:42PM +0100, Michal Hlavinka wrote: configuration can be in xorg.conf or in /etc/xorg.conf.d/.
Can it be /etc/X11/xorg.conf.d/ instead please? It would suck to have to look in two different places, /etc/X11/xorg.conf vs. /etc/xorg.conf.d/ instead of having everything under one parent directory. Thanks.
2010/2/16 Chuck Anderson cra@wpi.edu:
On Tue, Feb 16, 2010 at 09:26:54PM +1000, Peter Hutterer wrote:
On Tue, Feb 16, 2010 at 12:16:42PM +0100, Michal Hlavinka wrote: configuration can be in xorg.conf or in /etc/xorg.conf.d/.
Can it be /etc/X11/xorg.conf.d/ instead please? It would suck to have to look in two different places, /etc/X11/xorg.conf vs. /etc/xorg.conf.d/ instead of having everything under one parent directory. Thanks.
I hope not. It's pretty fine to have a foo.d folder in /etc and not in /etc/foo/.
On Tue, Feb 16, 2010 at 03:25:24PM +0100, Thomas Janssen wrote:
2010/2/16 Chuck Anderson cra@wpi.edu:
On Tue, Feb 16, 2010 at 09:26:54PM +1000, Peter Hutterer wrote:
On Tue, Feb 16, 2010 at 12:16:42PM +0100, Michal Hlavinka wrote: configuration can be in xorg.conf or in /etc/xorg.conf.d/.
Can it be /etc/X11/xorg.conf.d/ instead please? It would suck to have to look in two different places, /etc/X11/xorg.conf vs. /etc/xorg.conf.d/ instead of having everything under one parent directory. Thanks.
I hope not. It's pretty fine to have a foo.d folder in /etc and not in /etc/foo/.
Except I didn't recommend /etc/xorg.conf and /etc/xorg.
/etc/X11 is where the X11 config bits live. All I'm saying, is make the new xorg.conf.d live where all the other X11 config lives.
Why would you want to have the new config:
/etc/xorg.conf.d/*
when the existing config files are:
/etc/X11/xorg.conf /etc/X11/fontpath.d/* /etc/X11/xinit/*
Unless you are going to move everything:
/etc/xorg.conf.d/xorg.conf /etc/xorg.conf.d/fontpath.d/* /etc/xorg.conf.d/xinit/*
2010/2/16 Chuck Anderson cra@wpi.edu:
On Tue, Feb 16, 2010 at 03:25:24PM +0100, Thomas Janssen wrote:
2010/2/16 Chuck Anderson cra@wpi.edu:
On Tue, Feb 16, 2010 at 09:26:54PM +1000, Peter Hutterer wrote:
On Tue, Feb 16, 2010 at 12:16:42PM +0100, Michal Hlavinka wrote: configuration can be in xorg.conf or in /etc/xorg.conf.d/.
Can it be /etc/X11/xorg.conf.d/ instead please? It would suck to have to look in two different places, /etc/X11/xorg.conf vs. /etc/xorg.conf.d/ instead of having everything under one parent directory. Thanks.
I hope not. It's pretty fine to have a foo.d folder in /etc and not in /etc/foo/.
Except I didn't recommend /etc/xorg.conf and /etc/xorg.
/etc/X11 is where the X11 config bits live. All I'm saying, is make the new xorg.conf.d live where all the other X11 config lives.
Why would you want to have the new config:
/etc/xorg.conf.d/*
when the existing config files are:
/etc/X11/xorg.conf /etc/X11/fontpath.d/* /etc/X11/xinit/*
Unless you are going to move everything:
/etc/xorg.conf.d/xorg.conf /etc/xorg.conf.d/fontpath.d/* /etc/xorg.conf.d/xinit/*
That's how i understand the change. Like do it right and move everything to /etc/xorg.conf.d/* Maybe i could have said that in the first place. My bad.
how about keyboard layout ? f-s-keyboard (now system-setup-keyboard) used to send /etc/sysconfig/keyboard conf through hal to X
please consider the following points: we need to specify two layouts with functional switching (in previous releases we in ojuba.org were forced to hack and patch many packages like gdm to get switching, for example gdm does this: "system-wide conf should be ignored to let the user have a fancy menu having all layout", then it fail to activate switching)
we need to specify xim as default input method because it's the only input method that supports two-letters per key (needed for the two letters لا in Arabic layout located on key "b")
BTW: how hard does it take to make the default input method support this ?
the package description need to be changed
https://admin.fedoraproject.org/pkgdb/packages/name/system-setup-keyboard
"Hal keyboard layout callout" it should be something like "track system-wide keyboard layout configuration"
On Tue, Feb 16, 2010 at 10:32:19PM +0200, Muayyad AlSadi wrote:
how about keyboard layout ? f-s-keyboard (now system-setup-keyboard) used to send /etc/sysconfig/keyboard conf through hal to X
the package is already updated to create /etc/xorg.conf.d/00-system-setup-keyboard.conf (instead of merging into HAL).
please consider the following points: we need to specify two layouts with functional switching (in previous releases we in ojuba.org were forced to hack and patch many packages like gdm to get switching, for example gdm does this: "system-wide conf should be ignored to let the user have a fancy menu having all layout", then it fail to activate switching)
I'm not sure I understand exactly what you need here, but AIUI you just need this:
Section "InputClass" Identifier "custom layout" MatchIsKeyboard "on" Option "XkbLayout" "foo,bar" ... EndSection
save this as /etc/xorg.conf.d/99-custom-layout.conf and that should then overwrite the config by system-setup-keyboard.
we need to specify xim as default input method because it's the only input method that supports two-letters per key (needed for the two letters لا in Arabic layout located on key "b")
BTW: how hard does it take to make the default input method support this ?
I cannot answer this, I've only had high-level interaction with input methods so far.
Cheers, Peter
On Tue, 2010-02-16 at 17:40 +0100, Thomas Janssen wrote:
That's how i understand the change. Like do it right and move everything to /etc/xorg.conf.d/* Maybe i could have said that in the first place. My bad.
The main reason for continuing to read the monolithic xorg.conf file is for backwards compatibility. That doesn't square with moving it someplace else.
Peter Hutterer wrote:
...
Thanks for the 'Heads Up'. As I had said so long ago, I couldn't possibly read every developer's blog to find out what I must do to avoid inevitable doom after updating my system and not taking the required configuration measures -- that I would only know about, had I read the blog.
Since most of us have no xorg.conf anymore, we likely don't have to do anything.
Excellent work !! ;-)
On Tue, Feb 16, 2010 at 11:31 AM, Peter Hutterer peter.hutterer@who-t.net wrote:
options as specified. That's just one example, I've tried to detail the new configurations on our wiki. https://fedoraproject.org/wiki/Input_device_configuration If you think there's anything missing, please let me know or add it yourself.
Any pointers on how to migrate the 'enable touchpad tap-to-click' feature from the existing .fdi file(s)?
Cheers, Peter
Rajeesh K Nambiar wrote:
Any pointers on how to migrate the 'enable touchpad tap-to-click' feature from the existing .fdi file(s)?
The best solution is to just set it up in your desktop. (For KDE, install kcm_touchpad, it will be installed by default on the F13 KDE Live spin. For GNOME, the touchpad UI has been installed by default for a while now.)
Kevin Kofler
On Wed, 17 Feb 2010 at 11:13pm, Kevin Kofler wrote
Rajeesh K Nambiar wrote:
Any pointers on how to migrate the 'enable touchpad tap-to-click' feature from the existing .fdi file(s)?
The best solution is to just set it up in your desktop. (For KDE, install kcm_touchpad, it will be installed by default on the F13 KDE Live spin. For GNOME, the touchpad UI has been installed by default for a while now.)
That's not best if a) you want it enabled in g/kdm and/or b) you don't use KDE or GNOME.
On Wed, Feb 17, 2010 at 05:42:59PM -0500, Joshua Baker-LePain wrote:
On Wed, 17 Feb 2010 at 11:13pm, Kevin Kofler wrote
Rajeesh K Nambiar wrote:
Any pointers on how to migrate the 'enable touchpad tap-to-click' feature from the existing .fdi file(s)?
The best solution is to just set it up in your desktop. (For KDE, install kcm_touchpad, it will be installed by default on the F13 KDE Live spin. For GNOME, the touchpad UI has been installed by default for a while now.)
That's not best if a) you want it enabled in g/kdm and/or b) you don't use KDE or GNOME.
Section "InputClass" Identifier "tap-by-default" MatchIsTouchpad "on" Option "TapButton1" "1" EndSection
drop that into your xorg.conf(.d) and restart the server, that should do it. Once you got it working to your liking, please do me a favour and add this to the wiki page as an example configuration - I'm sure it'll help others too.
Cheers, Peter
On Thu, Feb 18, 2010 at 4:29 AM, Peter Hutterer peter.hutterer@who-t.net wrote:
Rajeesh K Nambiar wrote:
Any pointers on how to migrate the 'enable touchpad tap-to-click' feature from the existing .fdi file(s)?
Section "InputClass" Identifier "tap-by-default" MatchIsTouchpad "on" Option "TapButton1" "1" EndSection
drop that into your xorg.conf(.d) and restart the server, that should do it. Once you got it working to your liking, please do me a favour and add this to the wiki page as an example configuration - I'm sure it'll help others too.
Going to try it out in the weekend. Thanks, Peter!
On Thu, Feb 18, 2010 at 12:36 AM, Rajeesh K Nambiar rajeeshknambiar@gmail.com wrote:
On Thu, Feb 18, 2010 at 4:29 AM, Peter Hutterer peter.hutterer@who-t.net wrote:
Rajeesh K Nambiar wrote:
Any pointers on how to migrate the 'enable touchpad tap-to-click' feature from the existing .fdi file(s)?
Section "InputClass" Identifier "tap-by-default" MatchIsTouchpad "on" Option "TapButton1" "1" EndSection
drop that into your xorg.conf(.d) and restart the server, that should do it. Once you got it working to your liking, please do me a favour and add this to the wiki page as an example configuration - I'm sure it'll help others too.
Going to try it out in the weekend.
Sorry - got time to test only today. I had downloaded the Live image from Rawhide nightly build - desktop-x86_64-20100227.20.iso and added the configuration file to the /etc/xorg.conf.d/, and it works well at the GDM login screen. I have also added this to the wiki page (http://fedoraproject.org/wiki/Input_device_configuration#Device_configuratio...) now.
Once again, thanks Peter!