Answer: More than likely your mouse was detected properly on installation, but if it wasn't or you changed the mouse like I did you might have to do some editing and testing to get it to work, especially a USB Mouse. The mouse I am discussing here is a Microsoft Optical Wheel Mouse USB. The procedure should work with any USB Mouse. The Optical part doesn't have anything to do with the mouse working in Linux. If you are trying to get a PS/2 Mouse to work, that usually will work fine without any of this editing, but if anyone has trouble with it I will put mine back on and write up a procedure on it also.
The first thing you should do is issue the su command in a terminal to enter superuser mode. Next do a list modules command lsmod to see what modules you have loaded. If you don't have the proper ones the USB Mouse won't work and neither will the test below to find out what is wrong. The modules needed are:usb-ohci (see note at end), input, mousedev, usbcore, hid. (Note: You can use Windows to see what kind of USB Controller you have. The OHCI stands for Open Host Controller Interface. You would see that in Windows Control Panel/System/Devices Manager/Universal Serial Bus Controller. If you see something like Universal Host Controller Interface, you will need to load: usb-uchi instead of usb-ochi). You should see something like below with lsmod:
If you see some or none than you need to load the ones you don't have in there to the modules file. It is located at /etc/modules . I believe some need to be loaded before the others so put them in this order.
Go ahead and open a terminal and type them in, the modprobe command will insert the module in the kernel. After that you need to see if they work. This will consist of typing in another command and seeing if the system can see you connect and disconnect the USB Mouse.
Press CTRL+C to stop it. If that works you can put the commands for the modules to be inserted in /etc/modules . If you do put them in the modules file you will need to reboot. If you had any troubles with the above tests not working look below the XF86Config-4 section for some more test you can run to check if the system sees the mouse. After reboot you need to see which version of XFree86 you are using. If you have the same distribution as me you will be using Version 4. Note: Even if you have a files called XF86Config and XF86Config-4, the -4 will be the one your system uses. To see which version type this command in: xdpyinfo | grep release . That is the version of XFree86 you are using.
If you are using version 3.3.6 you can go to SuSe to see how to do it. If you are using XF86Config-4 then use your favorite text editor to open the file, it is at/etc/X11/XF86Config-4 . I like to use GEdit. Look for the "InputDevice" Section. And edit it to look like this:
The most important part I found that can really mess you up and doesn't show any errors is the Identifier . Just don't name it Mouse1 or Mouse2 or MyMouse. I named it Mouse1 and all the test worked, except the mouse wouldn't work. Changed that part and it worked. Next you need to go to the very end of the XF86Config-4 file and look for the "ServerLayout" Section. Edit it to look like this for the USB Mouse Part. Note: If you have a USB Keyboard,... don't go changing it to look like this, only change the Mouse part.
Your USB Mouse should work now after you restart X-Windows again or reboot, except for the Wheel. The part below this is for more test to help you troubleshoot if the mouse don't work. Then after that part I will show you how to get the wheel to work.
If you still can't get the mouse to work, make sure you have followed the instructions above. If still not then here are some more test you can run to check if the system sees your mouse. If they work and still nogo, make sure you are editing the correct version of XFree86.
In this test you type in:cat /dev/input/mice and try moving the mouse around and the wheel. You should get strange characters across the terminal window. To stop the test press CTRL+C.
In this test you type in:cat /proc/bus/usb/devices and you should see your mouse listed.
In this test you type in:cat /proc/interrupts and you should see the USB Interrupt Request (IRQ) for the type of controller you loaded as a module.
To get the Wheel to work, from everything I have read, you need to login as a User, if you do it as Root, then Root will own it. So if you happen to be in Root then change to a User. Open a terminal and type in: imwheel you should get a positive response. If not, make sure imwheel is installed. It is in the same directory that your XF86Config-4 file was and is called imwheelrc . If it is there and you don't get the response that it was activated, try going to that directory and type imwheel again. You can test it by opening up something with a sidebar like GEdit and moving the wheel.
Now you need to make it load at boot. So start a SuperUser session (type: su in a terminal) or login as root. Edit the file called xinitrc.d and it is at: /etc/X11/xinit/xinitrc.d. There is probably something already in it, just add at the end on a new line: imwheel -k . Now save that file and when you reboot you can use the wheel also.
Answer: This will work with any wheel mouse, not just the one I have. I got this information from Colas Nahaboo X mouse wheel scroll page . You have a file in your Root directory on this distribution called .Xdefaults. There are already probably some things in there and if you have a different distribution of Linux it may be in a different place, just do a search for the file. Your wheel will work with the other items listed in there, but chances are, unless you installed with the wheel mouse, Netscape most likely isn't one of them. Easy to fix. Just copy the information I have in the picture below and paste it in your .Xdefaults at the end of the list. Then either reboot or logout and 'Restart X Server' to test it out. Now you can scroll with the wheel. If you don't want to use the Keyboard buttons with the mouse you can delete those lines.
Now, since you probably did the above in root, you need to copy the .Xdefaults to each users folder. So for example to make it work for the next user, copy this file to John folder in his Home folder. Copy to /Home/John/ .
Answer: For Linux-Mandrake 8.0 everything works right off the bat. If you have two NIC's or it does screw up during install, then all you have to do it put in the script from the icfg-eth0 below and it will work. I have done it several times and worked everytime. So for LM 8.0 just go to the icfg-eth0 section below and then restart the network. For Linux-Mandrake 7.2 First thing you need to do is get the newest netdrivers. I could not get the driver for this card that came with Mandrake 7.2 to work. You could get just the driver need, which is the Tulip driver. But I think it would be better to get the whole network drivers package and install it. So that is how this section is going to work. You get tulip drivers at www.scyld.com/network/updates.html . That is the information page. You can get the actual driver package from that site if this next link is dead, also you might want to go just to the PUB directory, cause I downloaded the newest and it wasn't on that page. ftp.scyld.com/pub/network/netdriver-2.1-3.src.rpm . Download the netdriver source package to your home directory. Now you might have to do the rest of this in Root. Open a terminal and go to the directory that you put the file in. Type this command: rpm --rebuild netdriver-2.1-3.src.rpm this will build the src (source) file into a RPM for your kernel build. Then move the file to another folder, you can do it in the file manager a little easier. So move it to /usr/src/RPM/RPMS/i586/ folder. In the terminal go to that folder and type this command: rpm -i --force netdriver-2.1-3.i586.rpm You need to force option because the new drivers may conflict with existing drivers installed. Okay, now the newest driver is installed.
I also downloaded the tulip-diag.c to test the card out and make sure it was being seen. I got it from: www.scyld.com/diag This is a file you will have to compile cause it is a source file. To compile it, I first made a Directory called TulipDiagnotics, then put the file in there and opened a terminal and moved to that directory. To actually compile use this command: cc -O -Wall -Wstrict-prototypes -o tulip-diag tulip-diag.c that worked for me. If you have problems compiling open the tulip-diag.c file and look at the bottom. They list several compiling options there. Once it is compiled then still in the termial use this command to run it: ./tulip-diag Below is what mine shows.
There are different parameters that you can put after it, like I did the -a. You should see something like this so you know it sees the card.
Now you need to make sure that you have the proper modules installed to make this run. The modules are:pci-scan and tulip . You need to tell it to insert these modules on boot-up in your /etc/modules file. To do so you type: modprobe pci-scan next line put: modprobe tulip . If you still need help look at my modules file in My Modules file . You can also open a terminal and type them in to make sure you don't have any problems. Also, pci-scan needs to be loaded first so make sure you put it first.
Next you need to setup the connection. Now, my connect is through AT&T@Home. Yours might be a little different. Sorry, can't help much there. I had to search the web for several types of ways, if yours uses DHCP then it will probably work. AT&T@Home isn't much help either, so don't even bother trying them. The web search engine www.google.com is pretty good with newgroup searches. Just go there and try to find someone that might have helped someone else. You will get all kinds of varing information, some say to use LinuxConference,.... I just could find much help in figuring it out. The best I found was to just type it in. More than likely you got a work order with your connection. That will have the information you need to type in.
Most of the stuff is self-explanatory, but from my work order the IPADDR = CIP, GATEWAY = DGA, DHCP_HOSTNAME = HST, NETMASK = NET. Put all this in a file called icfg-eth0 in /etc/sysconfig/network-scripts/icfg-eth0 . Now all you have to do if everything worked out is restart the network. You can reboot or open a terminal and type in: /etc/rc.d/init.d/network restart . You will get information and hopefully the network will restart and everything work out okay for you. This can be a little bit of a trial and error until you get the settings and proper modules working correctly. Some ISP's are better than others at helping. I guess that depends how tight they are with Microsoft. Note: I may forget to mention this from time to time, but if you have problems inserting a module(s) then you need to make sure that you have it set in the kernel to load as a module.
Answer: I tried and tried to get the actual chipset to work but couldn't. At least not as Crystal. I used ISAPnpTools,.... might get part of it, but not another part to work, for example: audio might work, but couldn't make a audio CD work,... System sees it, ISAPnpTools works, modules sort of work. Might be like the Netdrivers that came with Mandrake 7.2 and need some new ones. Not really worrying about it cause I did get it working, but as a Sound Blaster.
The easiest way is to use sndconfig with some parameters. If you don't use the parameters it won't work either. You will see in the picture directly below the parameters for sndconfig. Open a terminal and type it in just like that: sndconfig --noprobe --noautoconfig
Then you will get this pop-up window. Follow the directions, mouse doesn't work. Pick the Sound Blaster and pick io = 220 , irq = 5 , dma = 1 don't remember, but if there is another dma pick 0 for that one. Run through the test and if it works for you like it did me, it will write to the /etc/modules.conf file. Reboot or restart the X Server and you will have sound.
If though by some chance sndconfig doesn't work for you, you will have to add the lines manually to /etc/modules.conf . To add them manually open the file as superuser (ie. Root) /etc/modules.conf. I actually had it working fine with sndconfig, later on after distro upgrades I had to manually add the lines, also soundblaster did not work, but the cs4232 module did. Add these lines to modules.conf, if there is something else in there about ' sound ' you should probably comment it out with a pound sign in front of it.
EXAMPLE FOR MANDRAKE 8.2 EXAMPLE FOR MANDRAKE 7.2alias sound-slot-0 cs4232 alias sound-slot-0 sb
options cs4232 io=0x220 irq=5 dma=1 options sb io=0x220 irq=5 dma=1 (or maybe 0)
Answer: When you upgrade to 8.2 (I also believe 8.1) this works right off the bat. There is no configuration that needs to be done. So if using at least Mandrake 8.1 and up don't have to worry about setting up as per this tutorial. If you are you are still using version 8.0 then follow this to get your CDWriter working. This is simplier than it sounds and all I know about is the HP CD-Writer. I gathered the information I needed from the Internet, and had to play around with it abit to get it right so if you have something different you will probably have to also. Part of this information, the part contained in the modules file I found at www.pcquest.com which has some pretty good information on getting this going and I did find one mistake in it or maybe an update changed the way the command is entered. The article mentions that if you want to use cdrecorder to scan the bus for your CDWriter you have to enter a certain command, they have . /cdrecord-scanbus You have to enter it like this instead: cdrecord -scanbus. It isn't a script file so you don't have to put the beginning and there needs to be a space after cdrecord. I am not going to get into great detail on CD writing cause I am pretty new at it, but I can tell you how I set mine up. Note: This CD-Writer is not a SCSI device it is an IDE device. For an actual SCSI device you have to do this different and I don't know that. First of all I added this lines to my /etc/modules file. Keep a backup of this cause I have had it over written before and had to restore the file cause I couldn't write to the CD.
Well, lucky I tested this further. I had some lines added to my /etc/modules.conf file from the How-to-CDWriting and upon further testing I didn't need them. Erasing a CDRW right now as I write this. So you might be able to do a modprobe on each of these modules and test out right now if it will work. Or you could just do it and reboot, then see if it works. Remember you won't see this modules inserted until you reboot or insert them manually, manually they won't stay there after you reboot though. If you want to test it out manually, insert them to see if it works. Just do a modprobe module_name for each of them. Then try out one of the CD burn programs. If you still can't get it to work then make sure your /etc/modules.conf file does have this line: alias scsi_hostadapter ide-scsi This line is at the end of my modules.conf file and tells your system to call the ide-scsi the scsi_hostadapter. Also make sure you actually have the modules loaded by going into su mode and issuing the command lsmod in a terminal. Note: you won't see the sr0 module though, at least I don't. I know these commands work cause I just erased a CDRW and then burnt a file onto it. Checked and it was all there. You may have to eject and reinsert the CD to mount the CD though.
If you rebooted and you check your dmesg file you should see something like this. Open a terminal enter su mode and type: dmesg | less. Scroll through it and you should see this:
For example I just opened GCombust and in the 'Burn' tab the CD-Recorder device options it says Scsibus, Target, Lun. Which corresponds to the Channel, ID, Lun. It had 0, 6, 0. Mine is 0, 0, 0. I clicked the Detect Scsi Drive button and it changed to the correct numbers. If that keeps coming up you can edit the file in your home folder .gcombust/gcombustrc and change it, that way it will load up to your default each time. You can also click on File/Preferences/Devices after you open Gcombust and enter it there, it might be safer to do it in the second choice.
If you still have problems check out the CD Writing How to at: www.redhat.com. Happy Burning, maybe as I use this more I might be able to add to the tutorial. This is also the first tutorial that I have written entirely in Linux using Bluefish. Slowly getting away from Windows.
I mess around with my system alot, so sometimes have to reinstall after screwing something up bad enough. Well, found something out. I have been able to get the CD-Writer to work without doing any entry into /etc/modules.conf or modules. Last few times I have reinstalled, I do the expert install, at the part about SCSI devices I have not chosen anything, but look at the list, say I have one, then don't choose one and finish that part. Still have to edit the ID from some reason, but change it to what it should be in Preferences and everything works. Just backed up the system tonight and will reinstall in a day or so to see if it always worked or that does it. Chances may be that it worked and just couldn't tell until I tried the hard way. If so I will have to rewrite this tutorial. More to come.
Answer: Finally talked them into installing the information for this Scanner into the microtek.c driver. YAA! I am not sure at the moment when they started, but I do know as of kernel-2.4.12-3mdk they have it in there. So, if you have this kernel, there is no need to do this. You will have to still insert the module into the /etc/modules.conf file and might have to make the symlink to the device. So you can skip to that part. With kernel-2.4.18-6mdk I found that Xsane will seg fault. To fix this you need to comment out or remove the sm3600 backend in the /etc/sane.d/dll.conf file. Otherwise just added to /etc/modules.conf file this line: alias sg1 scanner . If /dev/sg1 is being used by some other device then use another /dev/sg# . Also, make sure you have a symlink to the /dev/sg1 from /dev/scanner. If you check with ls -l /dev/scanner and it doesn't exist, then make a link to the sg1 with this command: ln -s /dev/sg1 /dev/scanner . Then start XSane and it should work fine. If you still have problems then read more below and make sure you have the kernel configured properly. It might be nothing more than you have the permissions only set so root can use it. Then just change the permissions and you are set.
I finally got all my devices attached to the computer working. The Scanner was the last and it fought me all the way until I got help from Kristian Stark. I have done several scans from the scanner already and everything seems to be working great, infact I just started XSane up again to see and it worked like a charm, there are a few problems and I will put them in the end of this tutorial. Okay, first the basics on what you have to do then I'll get to the details.
First of all you are going to have to modify the kernel module microtek.c file to include the scanner. After the new kernel is recompiled and installed and you have (done what: RUN lilo AGAIN). You then make sure you have XSane, Sane, the Sane-backends and frontends, various library files and Gimp. This is normal stuff you have to do the get to run any scanner and manipulate the results and isn't any different here. After you put the alias for the scanner in modules.conf you are ready to scan. Not too much huh? I will try to walk you through it.
Okay got Gimp figured out so here is the first picture. You need to open microtek.c in your favorite editor. It is in /usr/src/linux/drivers/usb/ . Find the section that looks like what I have shown below. The two lines that I have pointed out, add those, make sure you have all of it exactly or you will get sytax or parse errors when you try to compile this driver. I got the numbers in the second line from dmesg, they are the Vendor ID and Product ID numbers of the Scanner. Yours will be the same. After you have that done Save it and you are ready to recompile the kernel.
I'm not going to go into great detail here on compiling a kernel, I am still rather new at it, especially multiple kernels. I will save that for a later tutorial. You are going to have to be Root to do this. One thing I didn't know though was that for Mandrake kernels you need to run the command: make mrproper first!!! Don't forget that or you kernel won't compile and you will be left frustrated like I was. I learned this from a mysterious person known only as b. So open a terminal and change to the linux directory. cd /usr/src/linux Type in make mrproper, then make xconfig you can also do make menuconfig, but you won't have the same graphics I do. You will see the picture below.
It would probably be a good idea to store this configuration to a file now. Click on the Store Configuration to File button and give it a name. The name OriginalKernel.config would be good. This will save the file to /usr/src/linux . Now, some of this may be different than what you need, you will have to determine that. Here is a little help: I don't actually have any SCSI Devices in my computer, but some things in Linux likes to think in SCSI. So my HP CDWriter 9100+ is working as scsi0 and my Microtek Scanner is scsi1. If you actually have a SCSI Device you may have may not want to change them to modules or maybe you do. I previously said Yes to everything I will show you and compiled SCSI and USB into the Kernel and it worked so don't fret. But, if you have No on any of these items you will certainly want to make them either modules or compile them into the kernel. Do what you need to to make your system work, but do say YES or Module.
If you want them as modules just check to make sure they are, you don't have to do them in any order. If you want them compiled into the Kernel you will have to do them in order or some of them may be Grayed out and won't let you choose. So I am showing them in the order you need to change them so you can put them into the kernel if you want by saying Yes.
Remember this scanner will work as a Module, so you don't have to say Yes. If you want Yes, then change SCSI Support first, then change SCSI Generic Support next.
This next one is the USB Support. There are three items in there that you need to make sure you change to either Modules or Yes. If you want them compiled into the kernel than change them in order from top down. According to the microtek driver author the usb scanner support is not related to the microtek driver so isn't needed. You might want to put it in anyway incase you need it in the future for another scanner.
When you are happy with your choices click on the Store Configuration to File button and give it some Name. Then click on the Save and Exit button. You will then be asked to run make dep. Before you do this you might want to go the the /boot folder and save your original Kernel files. See the next picture and save the items highlighted in Blue. I am NOT going to install this as an extra kernel, I am going to just replace the files there. So your original files will be over written. If you don't want that than you'll have to do it a little different. Open up the /boot folder and you will see some Symlinks to these files, you can just leave them for the time being (See the next picture, the symlinks are highlighted in Green). These files are links (shortcuts) and we'll change the names later. The files they link to need to be copied somewhere safe like your /home folder.
So Copy: config-2.4.3-20mdk, initrd-2.4.3-20mdk.img, System.map-2.4.3-20mdk and vmlinuz-2.4.3-20mdk and remember where you put them, if you have a different kernel then only the (ex. 2.4.3-20 ) numbers will be different. If you have trouble rebooting you can go into maintenance mode and replace them back into /boot folder with the cp command. For example: cp /home/config-2.4.3-20mdk /boot Or if you have a good boot disk you should be able to boot from it and copy them back or fix your problem. You might want to write down what the symlinks are actually named also, so you can rename them the same when we are done compiling.
Now time to compile the kernel (guess I'm going more in depth than I planned). Since you already ran make dep, run these commands in this order:
make clean (to clean up temp files left over from dep.)
make bzImage (to make the Main Kernel file.)
make modules (to make the modules you configured.)
make modules_install (to install modules where kernel can find them.)
make install (to install the Kernel in /boot.)
When it is done and if you didn't have any errors you will find the new files in /boot. Now all you have to do is go back to the /boot folder and rename the Symlinks to point to these files. You might find some of them named something.old, for example config.old would be need to be renamed just config. So do all of them that need to be renamed: config , initrd.img , System.map , vmlinuz . You might also find a vmlinuz and a vmlinuz.old , delete the old in this case and keep the other. Rename it if it doesn't match the previous name. For anybody not use to this method or not sure what I am taking about look at the picture below. I have highlighted the actual files that were replaced in this process with Blue and the symlinks in Green. It should look like this when you are done.
One other important part. The install command is going to append the new kernel information on the end of your lilo.conf file. So go to /etc and open up lilo.conf in your favorite editor and delete the new entry at the end and save it.
I'm not sure if this is needed since it is a new file, but you might want to make sure the initrd.img file is for the current kernel (if someone knows about this for sure let me know. I changed the order of the compiling, so I don't think this step is necessary anymore. If you don't do it, and run into a problem. Just go boot in rescue mode from the floppy or better yet the CD1 install. Then do the mkinitrd and it should be alright then. I have done that once and fixed the problem with no initrd image. So if you still want to do this then here it is, or just right the info down for later if you run into a problem. I am keeping this in here incase an older kernel still needs this done. Delete the initrd-2.4.3-20mdk.img file in /boot and run this command: mkinitrd /boot/initrd-2.4.3-20mdk.img 2.4.3-20mdk This will make a new one. Then run lilo -v . Last but not least, before you reboot, make a new bootdisk.
Now it should be simple. When you finish rebooting open up a terminal go to Root and type in tail -f /var/log/messages . Then unplug your scanner and replug it in. You should see a message on the screen about a device being removed and reinstalled and assigned. I get a message that has this in it: sg1 at scsi1 channel 0, id 0, lun 0, type 6. You need the sg1 part or whatever yours is called. That is the dev it is assigned to. You will need to put that in modules.conf. If this doesn't work, make sure you have Hotplug installed. So add this line to /etc/modules.conf.
alias sg1 scanner
Reboot your computer, if there are any error messages about something in this line you may have not put in the correct name of the device. Look in dmesg if you need to to find it. If you have Sane, XSane and everything else in place you should be able to start XSane up and use your scanner. If it doesn't see a device, make sure that you have done everything correctly. Something simple might be that you didn't modify the microtek.c driver before you recompiled.
If it still don't work you might not have the symlink to /dev/sg1 or whatever your device is. Check it like this: ls -l /dev/scanner. You should see /dev/scanner -> /dev/sg1 . If your device (ie sg1) is different that is okay, just whatever was the result of tail. If you don't have a symlink create one. ln -s /dev/sg1 /dev/scanner . Then check again.
My first scan was crap. After playing with the settings I got good scans. Here is a picture of my settings:
Problems:
Color: Works great! Will probably have to adjust your settings after the first scan to actually see your image correctly. Sometimes there is a problem with the motor speed, you can hear it speed up and from that point on the scan is bad.
Grayscale: Works pretty good. It will give bad scans more often than Color does.
LineArt: Don't use!! It will look up the XSane program. Buttons will turn white and you will have to kill the program. Don't worry though, every time this happened. I killed XSane, hotplugged the scanner, restarted XSane and worked fine again in Color and Grayscale.
Versions used: XSane: 0.78-2mdk , sane-backends: 1.0.5-1mdk , sane-frontends: 1.0.5-2mdk , libsane: 1.0.5-1mdk , libsane-devel: 1.0.5-1mdk .
Answer: I successfully added my Microtek ScanMaker V6UPL to my current kernel in Mandrake 8.1 without recompiling the kernel. I changed the driver and then compiled it and inserted it into the kernel. Made a few other changes and baam it worked. I used gcc-2.96-0.62mdk to compile it, so if you have a different version and have problems that might be it. I'm not an expert at this and have only tried this this once. Didn't feel like getting a different kernel and just wanted to add the module.
So, my example here will be how to add the scanner to the kernel, but you could use it to add any other driver. For example where I got part of the information was about changing the ethernet driver. So if one of your drivers was old and didn't work, then you might be able to add it this way and save yourself from recompiling the whole kernel.
First I needed to add my scanner to the microtek.c driver in /usr/src/linux-2.4.8/drivers/usb/microtek.c file. You can take a look at that tutorial if that is what you want to do (it's the tutorial right above this one). Just skip down to the part where I am adding the lines to the driver. I have graphics there showing exactly what I added, it's the first picture you see. Then save it in the same folder. If you got your hands on a new driver that doesn't need modified you can just put it in the folder where the old one was. First copy the old one to your /home folder and then replace the new one where the old one was.
Okay, now you have the modified or new driver in place in the correct folder. Now open a terminal and change to that folder. Change over to SuperUser (ie. su) and issue this command: gcc -DMODULE -D__KERNEL__ -O6 -c microtek.c . Notice the -O6, the O is capital O, not zero. If you have a different driver replace microtek.c with that name. Also the __ is a double _ character.
You should have the compiled driver in the folder now. Mine is called microtek.o. In the same folder issue this command: install -m 644 microtek.o /lib/modules/2.4.8-26mdk/kernel/drivers/usb . Replace microtek.o with your driver if different and also to location folder if different. If you don't know, then do a locate for the microtek.o.gz or whatever yours is called. But the .o.gz should be the same.
Now you will have to gzip the driver. If you don't have gzip installed then do so now. Change to the folder where you put the new driver. Issue this command: gzip microtek.o . You will have a microtek.o.gz or whatever yours is called in the folder. **Note: It would be prudent to have saved the previous driver in /home folder before doing this. Just so you can reverse incase of a mistake and just move the old driver back.
You might have to do some different things here to get it to work now. It should be the same thing as you would have to do to get the old driver to work. So don't take verbatium from here on, this is what I would have to do to get the scanner driver to work. But good chance some of it would be similar. You may need to consult other documentation. The information you would need would be to make the module (driver) work just like it was already compiled when you installed your system.
Type in tail -f /var/log/messages . Then unplug your scanner and replug it in. You should see a message on the screen about a device being removed and reinstalled and assigned. I get a message that has this in it: sg1 at scsi1 channel 0, id 0, lun 0, type 6. You need the sg1 part or whatever yours is called. That is the dev it is assigned to. You will need to put that in modules.conf. If this doesn't work, make sure you have Hotplug installed. So add this line to /etc/modules.conf.
alias sg1 scanner
Make the symlink to the sg1 now with ln -s /dev/sg1 /dev/scanner. If it says you already have a device called /dev/scanner, then delete it and then make the symlink again. Check it with ls -l /dev/scanner. You should see /dev/scanner -> /dev/sg1. You should be able to start xsane now. If you still have problems run this command and see if it can detect the scanner: sane-find-scanner. Mine worked right after I finished the symlink. I was able to get sane-find-scanner to find the scanner and xsane not work, but I didn't have the symlink in yet and it didn't work. After adding the symlink I ran sane-find-scanner and /dev/scanner was added. Then it worked like a charm.
Answer: Xvidtune doesn't work for XF86Config-4 (ie. XFree86-4.1.x). You can use it to adjust your video screen, but I haven't found out where to apply it at in that file. This is for the XF86Config file in your /etc/X11 folder. If you are using XFree86-3.3.x. then this program is for you. If you don't know which you are using, here is a simple way to tell. Open a terminal and type: xdpyinfo and near the top in the vendor string is the XFree86 you are using. If it says 3.3.x (where x is some number) than you can use this.
This tutorial is mainly about the 5597/5598 Video Chipset, but can be used with any chipset using this same XFree86. Many HP Pavilions used this chipset for the video on the motherboard. The highest resolution I could get is 800x600 with this chipset. 1024x768 had weird lines going across all graphics. A plain background looked fine, but not anything else. I found that by just shifting the screen a little left took care most of the problem. Then just fine tuned the screen location a little more and replaced the bad Modeline in the /etc/X11/XF86Config file.
Xvidtune isn't that hard to use. I have made notes on the picture I have here for you to use. Open a terminal and type in: xvidtune . First, before you do anything. You need to click OK for the warning. Then click on the show button. This will show you the current settings that you are using. Now, if you are scared of burning out your monitor by leaving it the way it is. You can do this. The ALT-CTL-(Keypad +) will switch between 3 of your screen modes. So you could run XFdrake , set up your resolution. Then switch to another resolution (after you accept the one you want to change) till you are ready to try and fix it. Then switch to the resolution you want and click on the Show button again. Now make your adjustments. Use the left, right, up, down,....buttons to move your screen around. You may notice that the screen is shifted to the right and to small vertically,... You can either use the Test button for a momentary check if you got it, or just click the Apply button to apply it. Either way will work, but the Test button will shift back to what you had previously in few seconds. I just used the Apply button. Now, when you think you got what you want, click on the Show button again. That is the Modeline settings you want to change in the XF86Config file.
Okay, that is done. Now how do you apply it. You just did right? No, this doesn't write to your XF86Config file. You have to edit it. So open you the file in su (root, you will have to be su (superuser) to edit it.): /etc/X11/XF86Config . Hopefully you either wrote down the original setting or kept the terminal window open. Now use the Find tool in a text editor like Gedit to find the Modeline in the file that exactly matches the one you originally had. Replace it entirely with the new one. You might want to replace the line above it also, cause it mentions the Vertical Sync Rate, and will probably be wrong, so put in the one you had in xvidtune when you had it set right. If you forgot what it was, then just run xvidtune again after you fix this and have restarted X again. Then go back and edit that line. This isn't really that important, cause it will still work just fine. Just might want it for information later. Below is part of my XF86Config file. I have edited it to show it a little better. There are a lot of Modelines in there that aren't used. Some are commented out with a # and some aren't. As long as you replaced the one from the original settings then when you restart X the new one will be used.
Hope this fixes your 1024x768 resolution or what ever you needed to fix. I have the fix placed to XFree86.org. hopefully it will be in an update sometime soon.
Answer: This isn't an how to on installing the modem driver. That is very simple, just untar the package, change to root and to the new folder, then type: make install, then type: hcfpciconfig . Then follow the questions. The INSTALL file in the new folder has it all. Looks like this might be an new ebuild on Gentoo soon also. Anyways folks, this is an answer for those of you that install the modem driver and the device file it creates: /dev/ttySHCF0 either is there at first, but disappears upon reboot or never appears after running hcfpciconfig. This works even if you are running devfs. Tested it with devfs on and off.
The problem with Gentoo in this regard (not to say this is bad, just that it creates a problem with installing this modem) is that the /etc/modules.conf file doesn't like to be edited. The script file update-modules like to keep it all to it's self and will overwrite anything it did not put in there. I think there are a couple ways to overcome this dilemma and here is one of them.
Go ahead and install the driver like normal. Then when done, as root, open up the file /etc/modules.conf . Look for the entries it added to the file. It will look similar or exactly like this:
alias /dev/ttySHCF[0-9]* hcfpciserialalias char-major-240 hcfpciserial
alias /dev/cuaHCF[0-9]* hcfpciserial
alias char-major-241 hcfpciserial
alias /dev/modem hcfpciserial
options hcfpciserial serialmajor=240 calloutmajor=241 pcivendorid=0x14F1 pcideviceid=0x1036
Now copy them with your favorite editor over to another file. So, highlight them and copy. Then open this file: /etc/modules.d/aliases and paste them to the bottom of that file. Save it and when you reboot it should be working or I believe you could just run update-modules. You don't have to delete the entries from the /etc/modules.conf file cause they will disappear from there anyway and be rewritten by update-modules in the way it wants. That way it won't delete them again. Hope this helps any of you having this problem.
Answer: I had this problem recently. My HP CDWriter 9100 series would read fine, but couldn't seem to hardly write anything. Every once in a while I could write something without errors, once, but next CD would fail. Made several coasters. Would get buffer underrun errors and such otherwise. When I was able to write it was only to a CDRW, it couldn't seem to write to a CDR at all. I went as far as going to the store to look for a new one. Luckily, decided to try one more thing before doing so.
This is not a software fix. So not for the faint at heart. This actually requires you taking the CDWriter apart. If your not sure about this and not mechanically inclined, maybe you can get someone else to do it for you. I also will not take any responsiblity if you mess up or destroy your CDWriter. It really isn't as hard as it seems, but there is always someone that messes stuff up and decides that it has to be someone else's fault. So you have been Warned!
Before you try this drastic method though. I hope you have made sure that you do not have some setting wrong in the Burner Software. Have you tried lowering the write speed? Have you tried buffer-underrun protection? Have you made sure that all your cables are plugged in securely? Have you tried to put more data/audio on the CDR/RW than it will hold? Those are just some of the basic questions that you need to make sure you have tried first. If so then maybe this is the next step you need to take.
Sorry I do not have any pictures. Basically take the CDWriter out of the computer, work on some kind of AntiStatic bag or something. Take the covers off and make a note of where stuff goes back. Don't be afraid to draw some pictures if you need to. You need to get the drawer open, most of these devices come with a small hole where you can stick a paperclip into to start the drive out. What that really does is push a piece inside to move the gear out of the way. Once you get it started you can usually pull the drawer out most of the way. The point you need to get to is where you can see the LENS.
