| Home | Unix/Linux | Networking | Infosec | Travel | Technical | Radio | Site Map | Contact |
|
|
 |
|
|
|
Topics on this page
If your video chipset can be automatically recognized,
you may be able to generate an initial configuration
like this:
# Xorg -configure
# mv /root/xorg.conf /etc/X11/
Start X for testing with the command Xorg.
Similarly, use xorgcfg to generate a configuration file interactively.
X won't start without a mouse, and creating an initial configuration file with Xorg -configure probably will not correctly specify the mouse device. So, you need to figure out what your mouse device is called. It's probably:
| Linux |
/dev/mouse — that is probably a
symbolic link to: /dev/input/mice |
| BSD | /dev/wsmouse |
Still no mouse? You must figure out where it is, or where it should be, before continuing. On Linux this may mean some messing around with kernel modules.
List currently-loaded kernel modules with lsmod.
Load a kernel module with modprobe —
likely suspects include:
# modprobe psaux
# modprobe psmouse
# modprobe usbmouse
# modprobe sermouse
For a list of possible modules, try this:
# modprobe -l | egrep 'mouse|usb/input'
The idea is that you should load the right module and the device
will magically appear under /dev/mice/.
OK, that wasn't the right module, let's unload that one
and try another:
# rmmod logibm
All right, I think that I found my mouse, so now what?
Make sure that you really detected the device you think you did
by running a command like this, with the mouse device name changed
as needed:
# od /dev/mouse
Run your mouse in circles and verify that you see output.
Then how it in place with one hand and click the buttons with
the other, again looking for output.
If you see output, kill the octal dump with ^C.
It looks like the device is detected, now configure X — Add or modify your /etc/X11/xorg.conf so it contains a block that looks like the following. You must adjust the Protocol and Device values to reflect your hardware and OS:
Section "InputDevice" Identifier "Mouse0" Driver "mouse" Option "Protocol" "wsmouse" Option "Device" "/dev/wsmouse" EndSection
Linux —
The device depends on which kernel driver recognized it.
However, there should be a symbolic link
/dev/input/mice
pointing to the real device.
Protocols include:
PS/2 for vanilla PS/2 mouse plugged into /dev/psaux port
IMPS/2 if it's an "Intellimouse" with a wheel
ExplorerPS/2 for my Logitech Trackman Wheel device
OpenBSD on a Dell Inspiron 1000 — Device /dev/wsmouse and protocol wsmouse as seen in the above example.
How do I disable the terribly inconveniencing tap-to-click
"feature" on a touchpad?
I wish I knew how to do this....
Supposedly you can add an option line:
Option "MaxTapTime" "0"
to the mouse InputDevice block.
But at least for me (OpenBSD 4.1 on a Dell Inspiron 1000),
it doesn't disable this annoyance.
You tried to start Xorg and it complained with output similar to the following:
Problems when running startx: nvidia: no matching Device section for instance (BusID PCI:1:2:3) found
Of course, yours will likely say something other than nvidia for the driver, and almost certainly something other than 1:2:3 for the PCI bus ID!
Make a note of what it did say.
You could investigate further if you wanted with:
# lspci
or:
# lspci -v
or even:
# lspci -vv
However, the above error message should be adequate.
Edit /etc/X11/xorg.conf and add a line like this:
BusID "PCI:1:2:3"
to the block starting:
Section "Device".
Make sure to modify 1:2:3 as appropriate for where your
video chipset connects to the PCI bus!
In order to test just the basic X server and not beconfused by any
simultaneous problems with the display manager, boot scripts, etc.,
simply run this:
# Xorg
Verify that you get an X graphical display, and that you can
move the mouse pointer around.
When you're done with this quick test, kill the X process with
<Ctrl><Alt><Backspace>
You will need to generate a new default KDM configuration:
# genkdmconf
Now you can start KDM with the relevant boot script (Linux) or simply running kdm (BSD). Login as an unpriviliged user and use the menus to modify the KDM login screen. It will ask you for the root password when needed.
See my SSH configuration page to see how to make KDM start an SSH agent at login.
I have an Nvidia card. One day I noticed that GoogleEarth no longer started. It had been a few weeks since I had used GoogleEarth or any other application that needed OpenGL support, which is provided through the GLX extensions to the X server. Meanwhile I had done a lot of package additions and updates.
There are two sets of Nvidia drivers. The nv series is an open-source driver which does not fully utilize the hardware 3D acceleration. The nvidia series is partially closed source although it is freely available for download from Nvidia's web site.
Things are really a little more complicated than that. There is only one nv driver. However, there are several nvidia drivers: nvidia71, nvidia93, and nvidia173. You use the one corresponding to your video chipset as revealed by lspci or lspci -v.
My problem was that I had installed the following Nvidia-related packages. Notice that this is from a Mandriva system, but Google searches done while investigating my problem indicated that Nvidia support can also be an issue with recent Ubuntu and Fedora distributions on recent hardware:
The dkms modules are used in Mandriva to compile and install kernel modules needed for Nvidia hardware support. Notice that the nvidia package versions are tied to the kernel release due to that kernel driver issue.
I had selected those because the Mandriva RPM naming scheme for the kernel and several other systems includes a package named packagename-current that doesn't contain anything itself, it just requires whatever the most recent available version of packagename happens to be. For example, kernel-desktop-current at the time required kernel-desktop-2.6.28.4.
If you try to update kernel-desktop-2.6.28.4 there will never be anything to do, as that package will never be updated, just replaced with something based on a newer kernel release. But updating kernel-desktop-current will soon require kernel-desktop-2.6.29.
So, packages named *-current-* are generally a good thing. Generally, but not always....
I had specified nvidia as the video card driver withing /etc/X11/xorg.conf, but the display manager would not start.
Running just plain X, killing it with <Ctrl><Alt><Backspace>, and then carefully reading /var/log/Xorg.log.o showed that the main X program initially detected an Nvidia card on the PCI bus, but then it reported that it found no hardware!
Switching to the nv driver within /etc/X11/xorg.conf let me bring up X, but it couldn't load the GLX extensions. So I got graphics but no GL applications.
The packages nvidia173 and nvidia-current are different, two complete nvidia packages. If you try to install both, what happens is that nvidia173 goes on first and then nvidia-current silently overwrites it!
Nvidia is not keeping up with Linux developments, so what they call "current" really isn't. With recent kernels it fails on hardware that would have worked under earlier kernels. This means that it fails on recent Ubuntu and Fedora distributions on some hardware platforms.
Rip out ALL the nvidia packages, make sure that you have Mesa (for the libglx.so shared libraries), and then install just the nvidia173 packages. What's very confusing is that in names nvidia-current-kernel and nvidia-current-kernel-desktop-latest the -current refers to the kernel and not to the troublesome Nvidia not-so-current drivers.
Just ask for what you really need, dkms-nvidia173 and x11-driver-vidia-nvidia173 in my case, and let it pull in what else is needed according to their dependencies. I got:
|
|
|||||||||
|
|||||||||
|
| © Bob Cromwell Mar 2010. Created with /bin/vi and ImageMagick, hosted on OpenBSD with Apache. Root password available here, privacy policy here. |