I not only wanted to send a 'Solved' post, but pieced together a step by step on how to do this from all the posts...
Copy/Rename the FDI file... cp /usr/share/hal/fdi/policy/20thirdparty/10-synaptics.fdi \ /etc/hal/fdi/policy/11-synaptics.fdi
edit this file (11-synaptics.fdi) as indicated in the thread appropriate section for your touchpad (you can discover which touchpad section by 'cat /proc/bus/input/devices')
Reboot
I added: <merge key="input.x11_options.SHMConfig" type="string">On</merge> (allowing 'on the fly' shutting on and off of features with 'synclient') <merge key="input.x11_options.TouchpadOff" type="string">2</merge> (Turns the mouse pad tapping (and other) features off)
I can still do: synclient TouchpadOff=0 to turn the features on.
My /etc/hal/fdi/policy/11-synaptics.fdi is in the paste bin as an example... http://fpaste.org/paste/3891
Thanks, Rocco
On Tue, 2009-02-17 at 12:19 -0700, Linux Media wrote:
Copy/Rename the FDI file... cp /usr/share/hal/fdi/policy/20thirdparty/10-synaptics.fdi \ /etc/hal/fdi/policy/11-synaptics.fdi
You do want to make sure that you add in a user custom config file, not modify the default one. Because, otherwise, you'll lose your customisation at the next yum update that updates the relevant package.
I haven't tried Fedora 10, yet, but on 9, playing with SHM (one of the methods of disabling the touchpad) isn't 100% effective. Every now and then (like half a second, in the most appropriate moment) the touchpad will spring back to life, again. And there are some security issues with this technique. Unfortunately I had to take that route, because the touchpad does need to work, sometimes, and does need to be disabled at other times, and rebooting/reconfiguring is not a reasonable option.
Copy/Rename the FDI file... cp /usr/share/hal/fdi/policy/20thirdparty/10-synaptics.fdi \ /etc/hal/fdi/policy/11-synaptics.fdi
You do want to make sure that you add in a user custom config file, not modify the default one. Because, otherwise, you'll lose your customisation at the next yum update that updates the relevant package.
Are you saying there is another location for this file? Or maybe a completely different file/location?
This sounds important, I guess I just didn't understand.
Thanks, Rocco
On Wed, 2009-02-18 at 08:21 +1030, Tim wrote:
On Tue, 2009-02-17 at 12:19 -0700, Linux Media wrote:
Copy/Rename the FDI file... cp /usr/share/hal/fdi/policy/20thirdparty/10-synaptics.fdi \ /etc/hal/fdi/policy/11-synaptics.fdi
You do want to make sure that you add in a user custom config file, not modify the default one. Because, otherwise, you'll lose your customisation at the next yum update that updates the relevant package.
I haven't tried Fedora 10, yet, but on 9, playing with SHM (one of the methods of disabling the touchpad) isn't 100% effective. Every now and then (like half a second, in the most appropriate moment) the touchpad will spring back to life, again. And there are some security issues with this technique. Unfortunately I had to take that route, because the touchpad does need to work, sometimes, and does need to be disabled at other times, and rebooting/reconfiguring is not a reasonable option.
---- using the methodology as described by Linux Media,
simply running 'synclient TouchpadOff=1' in konsole indeed stops the mouse but the touchpad is still somewhat active in that the computer will wake when the touchpad is touched. The important part is to disable the mouse movement though since it is annoying to have the mouse relocate while you are typing away.
Craig
Linux Media wrote:
I not only wanted to send a 'Solved' post, but pieced together a step by step on how to do this from all the posts...
Copy/Rename the FDI file... cp /usr/share/hal/fdi/policy/20thirdparty/10-synaptics.fdi \ /etc/hal/fdi/policy/11-synaptics.fdi
edit this file (11-synaptics.fdi) as indicated in the thread appropriate section for your touchpad (you can discover which touchpad section by 'cat /proc/bus/input/devices')
Reboot
I added: <merge key="input.x11_options.SHMConfig" type="string">On</merge> (allowing 'on the fly' shutting on and off of features with 'synclient') <merge key="input.x11_options.TouchpadOff" type="string">2</merge> (Turns the mouse pad tapping (and other) features off)
I can still do: synclient TouchpadOff=0 to turn the features on.
My /etc/hal/fdi/policy/11-synaptics.fdi is in the paste bin as an example... http://fpaste.org/paste/3891
I did it by changing xorg.conf touchpad section to set the touch duration to zero. I can go dig out the details if you care, lots of discussion in this list on how to create the xorg.conf.
I not only wanted to send a 'Solved' post, but pieced together a step by step on how to do this from all the posts...
Copy/Rename the FDI file... cp /usr/share/hal/fdi/policy/20thirdparty/10-synaptics.fdi \ /etc/hal/fdi/policy/11-synaptics.fdi
edit this file (11-synaptics.fdi) as indicated in the thread appropriate section for your touchpad (you can discover which touchpad section by 'cat /proc/bus/input/devices')
Reboot
I added: <merge key="input.x11_options.SHMConfig" type="string">On</merge> (allowing 'on the fly' shutting on and off of features with 'synclient') <merge key="input.x11_options.TouchpadOff" type="string">2</merge> (Turns the mouse pad tapping (and other) features off)
I can still do: synclient TouchpadOff=0 to turn the features on.
My /etc/hal/fdi/policy/11-synaptics.fdi is in the paste bin as an example... http://fpaste.org/paste/3891
I did it by changing xorg.conf touchpad section to set the touch duration to zero. I can go dig out the details if you care, lots of discussion in this list on how to create the xorg.conf.
Thanks, but I did a lot of research prior to figuring this out and the consensus is that Fedora 10 left out xorg.conf for a reason and that it is not a good idea to use that approach anymore because it conflicts with the new approach.
You must have missed the long thread (this thread) that's been going on with this discussion.
Thanks, Rocco
On Thu, 2009-02-19 at 06:52 -0700, Linux Media wrote:
the consensus is that Fedora 10 left out xorg.conf for a reason and that it is not a good idea to use that approach anymore because it conflicts with the new approach.
Unless you plan to change graphics cards or monitors, I see no problem with having an xorg.conf file. However, there are security concerns about using SHM config, though that's a separate issue, even though a configuration option to enable it does go into the xorg.conf file.
Linux Media wrote:
I not only wanted to send a 'Solved' post, but pieced together a step by step on how to do this from all the posts...
Copy/Rename the FDI file... cp /usr/share/hal/fdi/policy/20thirdparty/10-synaptics.fdi \ /etc/hal/fdi/policy/11-synaptics.fdi
edit this file (11-synaptics.fdi) as indicated in the thread appropriate section for your touchpad (you can discover which touchpad section by 'cat /proc/bus/input/devices')
Reboot
I added: <merge key="input.x11_options.SHMConfig" type="string">On</merge> (allowing 'on the fly' shutting on and off of features with 'synclient') <merge key="input.x11_options.TouchpadOff" type="string">2</merge> (Turns the mouse pad tapping (and other) features off)
I can still do: synclient TouchpadOff=0 to turn the features on.
My /etc/hal/fdi/policy/11-synaptics.fdi is in the paste bin as an example... http://fpaste.org/paste/3891
I did it by changing xorg.conf touchpad section to set the touch duration to zero. I can go dig out the details if you care, lots of discussion in this list on how to create the xorg.conf.
Thanks, but I did a lot of research prior to figuring this out and the consensus is that Fedora 10 left out xorg.conf for a reason and that it is not a good idea to use that approach anymore because it conflicts with the new approach.
No, the "reason" was that someone decided that it wasn't needed and someone might screw it up if they had it. The Windows "we know what you want on your computer" approach. Trust me, for some hardware configurations you absolutely need it, the autoconfig simply isn't up to properly handling some displays.
You must have missed the long thread (this thread) that's been going on with this discussion.
You didn't see my name in them? About 30% of my hardware works less than optimally (or not at all) w/o xorg.conf. I believe (based on what I read) it's also needed to allow connecting a monitor to a netbook as well, otherwise you have to boot with the monitor connected and powered up every time to have it configured.
On Fri, 2009-02-20 at 18:20 -0500, Bill Davidsen wrote:
Thanks, but I did a lot of research prior to figuring this out and the consensus is that Fedora 10 left out xorg.conf for a reason and that it is not a good idea to use that approach anymore because it conflicts with the new approach.
No, the "reason" was that someone decided that it wasn't needed and someone might screw it up if they had it. The Windows "we know what you want on your computer" approach. Trust me, for some hardware configurations you absolutely need it, the autoconfig simply isn't up to properly handling some displays.
You must have missed the long thread (this thread) that's been going on with this discussion.
You didn't see my name in them? About 30% of my hardware works less than optimally (or not at all) w/o xorg.conf. I believe (based on what I read) it's also needed to allow connecting a monitor to a netbook as well, otherwise you have to boot with the monitor connected and powered up every time to have it configured.
---- The 'autoconfig' approach as you term it is not about Windows - it's about ease of use. When the system just works as you change hardware it's a lot easier for the end user than having to send the user into say runlevel 3, system-config-display --reconfig and then reboot.
The great thing about Linux is that if it doesn't work for you, you can be part of the solution by reporting your issues through systems like bugzilla, detail your hardware and the issues it presents so they can implement the necessary code so it does work in the future.
Yes, it's not perfect. I notice that on my Acer Aspire One netbook, if I boot up in Windows without having the monitor connected, it doesn't work all that well either so I'm not convinced that there's much of a difference. What I can do in Windows that I'm seemingly incapable of doing on F10 is to create a virtual screen larger than the actual 1024x600 and I would be grateful if someone could hit me with the clue stick here.
Craig
Craig White wrote:
On Fri, 2009-02-20 at 18:20 -0500, Bill Davidsen wrote:
Thanks, but I did a lot of research prior to figuring this out and the consensus is that Fedora 10 left out xorg.conf for a reason and that it is not a good idea to use that approach anymore because it conflicts with the new approach.
No, the "reason" was that someone decided that it wasn't needed and someone might screw it up if they had it. The Windows "we know what you want on your computer" approach. Trust me, for some hardware configurations you absolutely need it, the autoconfig simply isn't up to properly handling some displays.
You must have missed the long thread (this thread) that's been going on with this discussion.
You didn't see my name in them? About 30% of my hardware works less than optimally (or not at all) w/o xorg.conf. I believe (based on what I read) it's also needed to allow connecting a monitor to a netbook as well, otherwise you have to boot with the monitor connected and powered up every time to have it configured.
The 'autoconfig' approach as you term it is not about Windows - it's about ease of use. When the system just works as you change hardware it's a lot easier for the end user than having to send the user into say runlevel 3, system-config-display --reconfig and then reboot.
I'm a lot more unhappy with leaving out the ability to do that. If system-config-display is at least installed the user has the tool, and doesn't need to install from command line. Not creating xorg.conf is reasonable, but if it doesn't work and you need xorg.conf you always need the tool.
The great thing about Linux is that if it doesn't work for you, you can be part of the solution by reporting your issues through systems like bugzilla, detail your hardware and the issues it presents so they can implement the necessary code so it does work in the future.
If there is a way to use bugzilla without X for a browser, I bet fewer than 1% of all users know what it is. And not everyone has a second system to use.
Yes, it's not perfect. I notice that on my Acer Aspire One netbook, if I boot up in Windows without having the monitor connected, it doesn't work all that well either so I'm not convinced that there's much of a difference. What I can do in Windows that I'm seemingly incapable of doing on F10 is to create a virtual screen larger than the actual 1024x600 and I would be grateful if someone could hit me with the clue stick here.
I'm not just making a point here, but I think you need an entry in xorg.conf. I haven't done that since about X11R5 or so, but I think the option was something like "ViewPort" which was the physical (display) window size. I could be misremembering, that might be the virtual size, but it gives you somewhere to look. Do let us know if you find it.
Bill Davidsen wrote:
I'm a lot more unhappy with leaving out the ability to do that. If system-config-display is at least installed the user has the tool, and doesn't need to install from command line. Not creating xorg.conf is reasonable, but if it doesn't work and you need xorg.conf you always need the tool.
from the CLI (since no X)
X -configure
If there is a way to use bugzilla without X for a browser, I bet fewer than 1% of all users know what it is. And not everyone has a second system to use.
I'm not just making a point here, but I think you need an entry in xorg.conf. I haven't done that since about X11R5 or so, but I think the option was something like "ViewPort" which was the physical (display) window size. I could be misremembering, that might be the virtual size, but it gives you somewhere to look. Do let us know if you find it.
David wrote:
Bill Davidsen wrote:
I'm a lot more unhappy with leaving out the ability to do that. If system-config-display is at least installed the user has the tool, and doesn't need to install from command line. Not creating xorg.conf is reasonable, but if it doesn't work and you need xorg.conf you always need the tool.
from the CLI (since no X)
X -configure
The problem is that there are ten screens of command line options to be understood, and it gets some of its information by probing, rather than user input. Much of the information, such as that needed to use --layout, is in the xorg.conf man page, which makes for a painful process figuring out what options are needed just to generate xorg.conf with the right stanzas to edit.
If there is a way to use bugzilla without X for a browser, I bet fewer than 1% of all users know what it is. And not everyone has a second system to use.
I'm not just making a point here, but I think you need an entry in xorg.conf. I haven't done that since about X11R5 or so, but I think the option was something like "ViewPort" which was the physical (display) window size. I could be misremembering, that might be the virtual size, but it gives you somewhere to look. Do let us know if you find it.
| From: Bill Davidsen davidsen@tmr.com
| David wrote:
| > from the CLI (since no X) | > | > X -configure
Interesting that "X -help" doesn't say anything about this option.
Interesting that there is no X(1) manpage. There is no x(1) manpage.
There is an Xserver(1) manpage. It calls itself XSERVER(1) but that isn't its name, nor is xserver(1). Its synopsys says that it is invoked as "X" (with options). But it does not say anything about -configure.
There is an Xorg(1) manpage that is distinct from Xserver(1). Its synopsis says that it is invoked as "Xorg". It does document a -configure option.
xorg.conf(5) does not mention that "Xorg -configure" might be interesting.
It turns out that /usr/bin/X is a symlink to /usr/bin/Xorg. There does not seem to be an executable file called Xserver
Rather a mess.
| The problem is that there are ten screens of command line options to be | understood,
Yeah. "Xorg -help" prints 115 lines to stderr. If you want to see them, you need to use a pager. And do redirection. Like: Xorg 2>&1 | less Very friendly. And it doesn't list -configure
| and it gets some of its information by probing, rather than user | input. Much of the information, such as that needed to use --layout, is in the | xorg.conf man page, which makes for a painful process figuring out what | options are needed just to generate xorg.conf with the right stanzas to edit.
How do you figure them out?
D. Hugh Redelmeier wrote:
| From: Bill Davidsen davidsen@tmr.com
| David wrote:
| > from the CLI (since no X) | > | > X -configure
Interesting that "X -help" doesn't say anything about this option.
Interesting that there is no X(1) manpage. There is no x(1) manpage.
There is an Xserver(1) manpage. It calls itself XSERVER(1) but that isn't its name, nor is xserver(1). Its synopsys says that it is invoked as "X" (with options). But it does not say anything about -configure.
There is an Xorg(1) manpage that is distinct from Xserver(1). Its synopsis says that it is invoked as "Xorg". It does document a -configure option.
xorg.conf(5) does not mention that "Xorg -configure" might be interesting.
It turns out that /usr/bin/X is a symlink to /usr/bin/Xorg. There does not seem to be an executable file called Xserver
Rather a mess.
| The problem is that there are ten screens of command line options to be | understood,
Yeah. "Xorg -help" prints 115 lines to stderr. If you want to see them, you need to use a pager. And do redirection. Like: Xorg 2>&1 | less Very friendly. And it doesn't list -configure
| and it gets some of its information by probing, rather than user | input. Much of the information, such as that needed to use --layout, is in the | xorg.conf man page, which makes for a painful process figuring out what | options are needed just to generate xorg.conf with the right stanzas to edit.
How do you figure them out?
Well I use a three part approach: - trial and error, killing the server via ssh from another system - swearing and screaming "I hate computers" - use of mind-altering substances such as India Pale Ale
There is no good way, and AFAIK there is no way to get all the legal stanzas generated, so you can edit them. They require command line --options to get a starting point. The main problem I have is getting a touchpad stanza so I can disable pad taps while typing. That's the only thing I have to edit on almost every laptop, since the TP is right next to the space bar and gets hit regularly if you use your thumb for spaces.
-
Bill Davidsen -
Craig White -
D. Hugh Redelmeier -
David Boles -
linux media 4 -
Tim