| From: Bill Davidsen <davidsen(a)tmr.com&gt; | 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?

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.

> 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.

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.

> 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.

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.