longstanding Linux irritants: suggested solutions?

I've had a couple of (non-production threatening) issues on my Debian Sid
system that I've just had to shove to the back burner for lack of time to
deal with them. They continue to bother me though, and I'd like to devote
a bit of time I have at the moment to solving them with help from the
list. The first has to do with a display irritant, the second with a
kernel/mouse irritant. So, first the display.

I've generated a working XF86Config-4 file and the display quality is to
my liking. The problem is that it is shifted slightly too far right on
the monitor (LCD flat screen 17"). I can, of course shift the image
manually with control buttons on the monitor itself. But when I do this,
running text that gives boot messages on startup gets cut off a bit on the
opposite side. What I've done to deal with it thus far is to run Xvidtune
and reposition the display that way - which does work. Problem is, it
doesn't hold between reboots: I have to rerun Xvidtune every time I reboot
to properly center the display. I kind of expect Xvidtune to write the
values I tune the display to to XF86Config-4, but it doesn't do that.
I've tried it both as user and as root. Judging from the man page for
Xvidtune, which says:

Show Print the currently selected settings to stdout in XF86Config
"Modeline" format. The primary selection is similarly set.

I'm guessing that I am supposed to enter some values generated by it into
XF86Config-4 manually. Does this sound correct to others here? I'm a bit
confused by "stdout" though: I don't see any programs by that name, nor am
I confronted with something called that (at least not noticeably) as I use
the machine daily. So, I was a bit confused about where to find this
output that's gotten printed to "stdout." However, while doing work on
the other problem I'll bring up later, I was looking though
/var/log/XFree86.0.log and saw the following at the tail end of the file:

GetModeLine - scrn: 0 clock: 108000
GetModeLine - hdsp: 1280 hbeg: 1328 hend: 1440 httl: 1688
vdsp: 1024 vbeg: 1025 vend: 1028 vttl: 1066 flags: 5
ModModeLine - scrn: 0 hdsp: 1280 hbeg: 1344 hend: 1456 httl: 1688
vdsp: 1024 vbeg: 1025 vend: 1028 vttl: 1066 flags: 5
ModModeLine - Succeeded
ModModeLine - scrn: 0 hdsp: 1280 hbeg: 1328 hend: 1440 httl: 1688
vdsp: 1024 vbeg: 1025 vend: 1028 vttl: 1066 flags: 5
ModModeLine - Succeeded
GetModeLine - scrn: 0 clock: 108000
GetModeLine - hdsp: 1280 hbeg: 1328 hend: 1440 httl: 1688
vdsp: 1024 vbeg: 1025 vend: 1028 vttl: 1066 flags: 5
ModModeLine - scrn: 0 hdsp: 1280 hbeg: 1328 hend: 1440 httl: 1688
vdsp: 1024 vbeg: 1025 vend: 1028 vttl: 1066 flags: 5
ModModeLine - Succeeded
ModModeLine - scrn: 0 hdsp: 1280 hbeg: 1340 hend: 1452 httl: 1688
vdsp: 1024 vbeg: 1025 vend: 1028 vttl: 1066 flags: 5
ModModeLine - Succeeded
ModModeLine - scrn: 0 hdsp: 1280 hbeg: 1328 hend: 1440 httl: 1688
vdsp: 1024 vbeg: 1025 vend: 1028 vttl: 1066 flags: 5
ModModeLine - Succeeded
ModModeLine - scrn: 0 hdsp: 1280 hbeg: 1340 hend: 1452 httl: 1688
vdsp: 1024 vbeg: 1025 vend: 1028 vttl: 1066 flags: 5
ModModeLine - Succeeded
GetModeLine - scrn: 0 clock: 108000
GetModeLine - hdsp: 1280 hbeg: 1340 hend: 1452 httl: 1688
vdsp: 1024 vbeg: 1025 vend: 1028 vttl: 1066 flags: 5

Could this be the output to stdout that I need? It seems like it could
be, since I ran Xvidtune right after having logged into the gui. I
fiddled around a bit before getting the right setting, as the output here
seems to indicate as well. If anyone could tell me whether I've
discovered Xvidtune's output at the end of this log file, I would
appreciate it. I would also be appreciative if someone could suggest just
what from this output I am supposed to enter in XF86Config-4, and where in
that file it should be placed. Thanks in advance for any input on this.

The next irritant I've encountered has to do with mice and the 2.6.4
kernel. I have a pretty much standard ps2 mouse (a trackballish type
thing but definitely with a ps2 plug). This mouse works fine with the 2.4
kernels I've tried it with thus far: I've loaded 3 or 4 different 2.4.x
kernels over the last few months and never had any problems. However,
when I tried to use a 2.6.x kernel - up to and including the latest 2.6.4
kernel - the mouse does not work. In other words, I try to move the
cursor and it won't move: it simply stays stuck in the middle of the
screen regardless of what I move on the physical mouse. These kernels are
the stock Debian Sid ones, btw - I did *not* compile them myself (ok, go
ahead and subtract geek points . . . see if I care). In other words, when
I want to try a new kernel I do apt-get install
kernel-image-whatever.ver-686. Then I do the necessary tweaking of lilo
and symlinks in /boot and so forth. The machine boots fine by this means,
btw. I just can't use the mouse with the 2.6.x kernels when it gets to
the gui stage, for some strange reason. I looked over
/var/log/XFree86.0.log and, to my untrained eye, the following message
toward the end of that file seems like it could apply:

(**) Option "Protocol" "PS/2"
(**) Configured Mouse: Protocol: "PS/2"
(**) Configured Mouse: Core Pointer
(**) Option "Device" "/dev/gpmdata"
(==) Configured Mouse: Buttons: 3
(**) Option "Protocol" "PS/2"
(**) Generic Mouse: Protocol: "PS/2"
(**) Generic Mouse: always reports core events
(**) Option "Device" "/dev/input/mice"
(EE) xf86OpenSerial: Cannot open device /dev/input/mice
No such device.
(EE) Generic Mouse: cannot open input device
(EE) PreInit failed for input device "Generic Mouse"
(II) UnloadModule: "mouse"
(II) XINPUT: Adding extended input device "Configured Mouse" (type: MOUSE)

Could anyone offer suggestions for how to resolve this mouse problem so I
can finally begin using the 2.6.4 kernel? Thanks for input on this.

And, finally, when I load a new kernel, I use the "kernel wrapper" method
for apt which Ray mentioned earlier. That is, I do apt-get install
kernel-image-2.4-686 for example, which fetches the very latest 2.4.x
kernel available from the Sid mirrors. What I'm not clear on is how I
remove the old kernel. I know about apt-get remove, but if I issue
apt-get remove kernel-image-2.4-686, I'm not quite sure exactly what would
get removed. Would that remove the last 2.4.x kernel I installed? Would
it remove all 2.4.x kernels? Of course I don't want that: I just want to
remove some of them (I've accumulated 3 or 4 now, since I was unable to
resolve how to remove them when I loaded new ones). So, would I specify
the kernel version number I want to remove, even though I did not specify
it to be installed by kernel version number? Or must I simply manually
delete things?

That's probably enough for now. I will appreciate any help with these
issues.

Thanks, James
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: longstanding Linux irritants: suggested solutions?

> I've generated a working XF86Config-4 file and the display quality is to
> my liking. The problem is that it is shifted slightly too far right on
> the monitor (LCD flat screen 17"). I can, of course shift the image
> manually with control buttons on the monitor itself. But when I do this,
> running text that gives boot messages on startup gets cut off a bit on the
> opposite side. What I've done to deal with it thus far is to run Xvidtune
> and reposition the display that way - which does work. Problem is, it
> doesn't hold between reboots: I have to rerun Xvidtune every time I reboot
> to properly center the display. I kind of expect Xvidtune to write the
> values I tune the display to to XF86Config-4, but it doesn't do that.
> I've tried it both as user and as root. Judging from the man page for
> Xvidtune, which says:
>
> Show Print the currently selected settings to stdout in XF86Config
> "Modeline" format. The primary selection is similarly set.
>

First, run xvidtune from a terminal and DO NOT close the terminal.

After you get xvidtune to the exact psoition you want press the "show"
button.

In the terminal a "Modeline" will be printed. On mine I get this:
"1600x1200" 229.50 1600 1664 1856 2160 1200 1201 1204 1250 +hsync
+vsync

In your XF86Config-4 file goto your Monitor section and add
ModeLine

So for me I'd add this to Section "Monitor":
ModeLine "1600x1200" 229.50 1600 1664 1856 2160 1200 1201 1204
1250 +hsync +vsync

Now restart X... Simple eh?

> The next irritant I've encountered has to do with mice and the 2.6.4
> kernel. I have a pretty much standard ps2 mouse (a trackballish type
> thing but definitely with a ps2 plug). This mouse works fine with the 2.4
> kernels I've tried it with thus far: I've loaded 3 or 4 different 2.4.x
> kernels over the last few months and never had any problems. However,
> when I tried to use a 2.6.x kernel - up to and including the latest 2.6.4
> kernel - the mouse does not work. In other words, I try to move the
> cursor and it won't move: it simply stays stuck in the middle of the
> screen regardless of what I move on the physical mouse. These kernels are
> the stock Debian Sid ones, btw - I did *not* compile them myself (ok, go
> ahead and subtract geek points . . . see if I care). In other words, when
> I want to try a new kernel I do apt-get install
> kernel-image-whatever.ver-686. Then I do the necessary tweaking of lilo
> and symlinks in /boot and so forth. The machine boots fine by this means,
> btw. I just can't use the mouse with the 2.6.x kernels when it gets to
> the gui stage, for some strange reason. I looked over
> /var/log/XFree86.0.log and, to my untrained eye, the following message
> toward the end of that file seems like it could apply:
>
> (**) Option "Protocol" "PS/2"
> (**) Configured Mouse: Protocol: "PS/2"
> (**) Configured Mouse: Core Pointer
> (**) Option "Device" "/dev/gpmdata"
> (==) Configured Mouse: Buttons: 3
> (**) Option "Protocol" "PS/2"
> (**) Generic Mouse: Protocol: "PS/2"
> (**) Generic Mouse: always reports core events
> (**) Option "Device" "/dev/input/mice"
> (EE) xf86OpenSerial: Cannot open device /dev/input/mice
> No such device.
> (EE) Generic Mouse: cannot open input device
> (EE) PreInit failed for input device "Generic Mouse"
> (II) UnloadModule: "mouse"
> (II) XINPUT: Adding extended input device "Configured Mouse" (type: MOUSE)
>
> Could anyone offer suggestions for how to resolve this mouse problem so I
> can finally begin using the 2.6.4 kernel? Thanks for input on this.

You are not loading in the USB input modules. Read the kernel docs on
what ones you need. I don't use debian so I can't help anymore...

--
Bryan Whitehead
SysAdmin - JPL - Interferometry and Large Optical Systems
Phone: 818 354 2903
driver@jpl.nasa.gov

-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: longstanding Linux irritants: suggested solutions?

I can only give you partial answers here, James. I hope they are enough to
be of some help.

At 02:39 PM 4/12/2004 -0500, James Miller wrote:
>I've had a couple of (non-production threatening) issues on my Debian Sid
>system that I've just had to shove to the back burner for lack of time to
>deal with them. They continue to bother me though, and I'd like to devote
>a bit of time I have at the moment to solving them with help from the
>list. The first has to do with a display irritant, the second with a
>kernel/mouse irritant. So, first the display.
>
>I've generated a working XF86Config-4 file and the display quality is to
>my liking. The problem is that it is shifted slightly too far right on
>the monitor (LCD flat screen 17"). I can, of course shift the image
>manually with control buttons on the monitor itself. But when I do this,
>running text that gives boot messages on startup gets cut off a bit on the
>opposite side. What I've done to deal with it thus far is to run Xvidtune
>and reposition the display that way - which does work. Problem is, it
>doesn't hold between reboots: I have to rerun Xvidtune every time I reboot
>to properly center the display. I kind of expect Xvidtune to write the
>values I tune the display to to XF86Config-4, but it doesn't do that.
>I've tried it both as user and as root. Judging from the man page for
>Xvidtune, which says:
>
>Show Print the currently selected settings to stdout in XF86Config
> "Modeline" format. The primary selection is similarly set.
>
>I'm guessing that I am supposed to enter some values generated by it into
>XF86Config-4 manually. Does this sound correct to others here? I'm a bit
>confused by "stdout" though: I don't see any programs by that name, nor am
>I confronted with something called that (at least not noticeably) as I use
>the machine daily. So, I was a bit confused about where to find this
>output that's gotten printed to "stdout." However, while doing work on
>the other problem I'll bring up later, I was looking though
>/var/log/XFree86.0.log and saw the following at the tail end of the file:
>
>GetModeLine - scrn: 0 clock: 108000
>GetModeLine - hdsp: 1280 hbeg: 1328 hend: 1440 httl: 1688
> vdsp: 1024 vbeg: 1025 vend: 1028 vttl: 1066 flags: 5
>ModModeLine - scrn: 0 hdsp: 1280 hbeg: 1344 hend: 1456 httl: 1688
> vdsp: 1024 vbeg: 1025 vend: 1028 vttl: 1066 flags: 5
>ModModeLine - Succeeded
>ModModeLine - scrn: 0 hdsp: 1280 hbeg: 1328 hend: 1440 httl: 1688
> vdsp: 1024 vbeg: 1025 vend: 1028 vttl: 1066 flags: 5
>ModModeLine - Succeeded
>GetModeLine - scrn: 0 clock: 108000
>GetModeLine - hdsp: 1280 hbeg: 1328 hend: 1440 httl: 1688
> vdsp: 1024 vbeg: 1025 vend: 1028 vttl: 1066 flags: 5
>ModModeLine - scrn: 0 hdsp: 1280 hbeg: 1328 hend: 1440 httl: 1688
> vdsp: 1024 vbeg: 1025 vend: 1028 vttl: 1066 flags: 5
>ModModeLine - Succeeded
>ModModeLine - scrn: 0 hdsp: 1280 hbeg: 1340 hend: 1452 httl: 1688
> vdsp: 1024 vbeg: 1025 vend: 1028 vttl: 1066 flags: 5
>ModModeLine - Succeeded
>ModModeLine - scrn: 0 hdsp: 1280 hbeg: 1328 hend: 1440 httl: 1688
> vdsp: 1024 vbeg: 1025 vend: 1028 vttl: 1066 flags: 5
>ModModeLine - Succeeded
>ModModeLine - scrn: 0 hdsp: 1280 hbeg: 1340 hend: 1452 httl: 1688
> vdsp: 1024 vbeg: 1025 vend: 1028 vttl: 1066 flags: 5
>ModModeLine - Succeeded
>GetModeLine - scrn: 0 clock: 108000
>GetModeLine - hdsp: 1280 hbeg: 1340 hend: 1452 httl: 1688
> vdsp: 1024 vbeg: 1025 vend: 1028 vttl: 1066 flags: 5
>
>Could this be the output to stdout that I need? It seems like it could
>be, since I ran Xvidtune right after having logged into the gui.

"stdout" is short for "standard output" and is, by default, the terminal
display from which a program is run. It's what you redirect with the >
character. There is also "stderr", or "standard error" ... also the running
terminal by default, but separately redirectable with the 2> characters. So
what you read just means that xvidtune (not Xvidtune; case counts) will
print the values to the screen, or to whatever file you redirect screen
output to.

As to adding the Modeline entries manually ... that's how I would read it
too. I just want to caution you that hand-editing /etc/X11/XF86Config-4
conflicts with the "Debian way", which relies on configuring through dpkg
(in this case, probably dpkg-reconfigure). It means tyou run the risk of
losing your changes as the result of an apt-get upgrade (or, more likely,
dist-upgrade). I know of no sensible workaround for this problem, except
the most basic one: keep a copy of your changes somewhere and be ready to
restore them if you need to.

> I
>fiddled around a bit before getting the right setting, as the output here
>seems to indicate as well. If anyone could tell me whether I've
>discovered Xvidtune's output at the end of this log file, I would
>appreciate it. I would also be appreciative if someone could suggest just
>what from this output I am supposed to enter in XF86Config-4, and where in
>that file it should be placed. Thanks in advance for any input on this.
>
>The next irritant I've encountered has to do with mice and the 2.6.4
>kernel. I have a pretty much standard ps2 mouse (a trackballish type
>thing but definitely with a ps2 plug). This mouse works fine with the 2.4
>kernels I've tried it with thus far: I've loaded 3 or 4 different 2.4.x
>kernels over the last few months and never had any problems. However,
>when I tried to use a 2.6.x kernel - up to and including the latest 2.6.4
>kernel - the mouse does not work. In other words, I try to move the
>cursor and it won't move: it simply stays stuck in the middle of the
>screen regardless of what I move on the physical mouse. These kernels are
>the stock Debian Sid ones, btw - I did *not* compile them myself (ok, go
>ahead and subtract geek points . . . see if I care). In other words, when
>I want to try a new kernel I do apt-get install
>kernel-image-whatever.ver-686. Then I do the necessary tweaking of lilo
>and symlinks in /boot and so forth. The machine boots fine by this means,
>btw. I just can't use the mouse with the 2.6.x kernels when it gets to
>the gui stage, for some strange reason. I looked over
>/var/log/XFree86.0.log and, to my untrained eye, the following message
>toward the end of that file seems like it could apply:
>
>(**) Option "Protocol" "PS/2"
>(**) Configured Mouse: Protocol: "PS/2"
>(**) Configured Mouse: Core Pointer
>(**) Option "Device" "/dev/gpmdata"
>(==) Configured Mouse: Buttons: 3
>(**) Option "Protocol" "PS/2"
>(**) Generic Mouse: Protocol: "PS/2"
>(**) Generic Mouse: always reports core events
>(**) Option "Device" "/dev/input/mice"
>(EE) xf86OpenSerial: Cannot open device /dev/input/mice
> No such device.
>(EE) Generic Mouse: cannot open input device
>(EE) PreInit failed for input device "Generic Mouse"
>(II) UnloadModule: "mouse"
>(II) XINPUT: Adding extended input device "Configured Mouse" (type: MOUSE)
>
>Could anyone offer suggestions for how to resolve this mouse problem so I
>can finally begin using the 2.6.4 kernel? Thanks for input on this.

I'm not using 2.6.x kernels yet, so I can't really help you if this is
anything very intricate or subtle ... and some 2.6.x changes are both of
these.

You'll note that X is trying to open two distinct mouse entries, for
"Configured Mouse" and "Generic Mouse". I have seen this before, and it
seems to be some sort of long-standing error in the dpkg-reconfigure
script. On my machines, if it gives me a problem (currently it doesn't - my
X setups ignore this one and use Confifured Mouse with no problem) I fix
it by editing support for the wrong one (in your case, Generic Mouse) out
of XF86Config-4 by hand. Just go to the section called "ServerLayout" and
delete, or comment out, the line for "Generic Mouse".

But your problem is probably with the "Configured Mouse" entry. It may be
using the wrong device (I don't have a /dev/gpmdata device here so cannot
check what it is). You may be able to fix the problem by editing
XF86Config-4 so this Device entry points to /dev/psaux (assuming you have
that device).

>And, finally, when I load a new kernel, I use the "kernel wrapper" method
>for apt which Ray mentioned earlier. That is, I do apt-get install
>kernel-image-2.4-686 for example, which fetches the very latest 2.4.x
>kernel available from the Sid mirrors. What I'm not clear on is how I
>remove the old kernel. I know about apt-get remove, but if I issue
>apt-get remove kernel-image-2.4-686, I'm not quite sure exactly what would
>get removed. Would that remove the last 2.4.x kernel I installed? Would
>it remove all 2.4.x kernels? Of course I don't want that: I just want to
>remove some of them (I've accumulated 3 or 4 now, since I was unable to
>resolve how to remove them when I loaded new ones). So, would I specify
>the kernel version number I want to remove, even though I did not specify
>it to be installed by kernel version number? Or must I simply manually
>delete things?

I don't do this either. But as I read the Debian docs, installing (or
upgrading) kernel-image-2.4-686 is just a trick, in that this is a dummy
package with nothing in it but a dependency on the latest real 2.4.x image
compiled for a "686". So it forces installation of another package with the
actual kernel (currently kernel-image-2.4.25-1-686, if my package
repository here is up to date).

So you should be able to apt-get remove kernel-image-2.4.19-686 (for
example), to get rid of the old kernels without losing the current one.
Personally, I'd also make sure any entries for them are removed from
/etc/lilo.conf (or the config file for whatever bootloader you use), then
rerun lilo, after you remove any kernel images ... I don't recall how the
package configurator handles old kernel images when updating lilo.



-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: longstanding Linux irritants: suggested solutions?

On Mon, 12 Apr 2004, James Miller wrote:

> The next irritant I've encountered has to do with mice and the 2.6.4
> kernel. I have a pretty much standard ps2 mouse (a trackballish type
> thing but definitely with a ps2 plug). This mouse works fine with the 2.4
> kernels I've tried it with thus far: I've loaded 3 or 4 different 2.4.x
> kernels over the last few months and never had any problems. However,
> when I tried to use a 2.6.x kernel - up to and including the latest 2.6.4
> kernel - the mouse does not work. In other words, I try to move the
> cursor and it won't move: it simply stays stuck in the middle of the
> screen regardless of what I move on the physical mouse. These kernels are
> the stock Debian Sid ones, btw - I did *not* compile them myself (ok, go
> ahead and subtract geek points . . . see if I care). In other words, when
> I want to try a new kernel I do apt-get install
> kernel-image-whatever.ver-686. Then I do the necessary tweaking of lilo
> and symlinks in /boot and so forth. The machine boots fine by this means,
> btw. I just can't use the mouse with the 2.6.x kernels when it gets to
> the gui stage, for some strange reason. I looked over
> /var/log/XFree86.0.log and, to my untrained eye, the following message
> toward the end of that file seems like it could apply:
>
> (**) Option "Protocol" "PS/2"
> (**) Configured Mouse: Protocol: "PS/2"
> (**) Configured Mouse: Core Pointer
> (**) Option "Device" "/dev/gpmdata"
> (==) Configured Mouse: Buttons: 3
> (**) Option "Protocol" "PS/2"
> (**) Generic Mouse: Protocol: "PS/2"
> (**) Generic Mouse: always reports core events
> (**) Option "Device" "/dev/input/mice"
> (EE) xf86OpenSerial: Cannot open device /dev/input/mice
> No such device.
> (EE) Generic Mouse: cannot open input device
> (EE) PreInit failed for input device "Generic Mouse"
> (II) UnloadModule: "mouse"
> (II) XINPUT: Adding extended input device "Configured Mouse" (type: MOUSE)
>
> Could anyone offer suggestions for how to resolve this mouse problem so I
> can finally begin using the 2.6.4 kernel? Thanks for input on this.
>


replace /dev/gpmdata with /dev/psaux i guess



--
"A mouse is a device used to point at
the xterm you want to type in".
Kim Alm on a.s.r.
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: longstanding Linux irritants: suggested solutions?

On Mon, 12 Apr 2004, Bryan Whitehead wrote:

> > to properly center the display. I kind of expect Xvidtune to write the
> > values I tune the display to to XF86Config-4, but it doesn't do that.
> > I've tried it both as user and as root. Judging from the man page for
> > Xvidtune, which says:
> >
> > Show Print the currently selected settings to stdout in XF86Config
> > "Modeline" format. The primary selection is similarly set.
> >
>
> First, run xvidtune from a terminal and DO NOT close the terminal.
>
> After you get xvidtune to the exact psoition you want press the "show"
> button.
>
> In the terminal a "Modeline" will be printed. On mine I get this:
> "1600x1200" 229.50 1600 1664 1856 2160 1200 1201 1204 1250 +hsync
> +vsync
>
> In your XF86Config-4 file goto your Monitor section and add
> ModeLine
>
> So for me I'd add this to Section "Monitor":
> ModeLine "1600x1200" 229.50 1600 1664 1856 2160 1200 1201 1204
> 1250 +hsync +vsync
>
> Now restart X... Simple eh?

Looks like it, yes. I started xvidtune in an xterm (I couldn't really see
how starting it in a terminal - which I understand to mean a virtual
terminal or console - would work, since X needs to be running to do the
positioning), and when it ran, output from it was displayed in the xterm.
Sure enough, data like you mentioned appeared when I hit the "show"
button. I copied it to a file, and have added it to XF86Config as you
suggested. I'm hoping this is going to do the job. Thanks for the tip.

On Mon, 12 Apr 2004, Ray Olszewski wrote:

> I can only give you partial answers here, James. I hope they are enough to
> be of some help.

>
> "stdout" is short for "standard output" and is, by default, the terminal
> display from which a program is run. It's what you redirect with the >
> character. There is also "stderr", or "standard error" ... also the running
> terminal by default, but separately redirectable with the 2> characters. So
> what you read just means that xvidtune (not Xvidtune; case counts) will
> print the values to the screen, or to whatever file you redirect screen
> output to.

Thanks for your input, Ray. So, stdout means within an xterm from which
an application is started, according to Bryan's directions and my
implementation of them. I had been starting xvidtune (it *does* appear
capitalized - Xvidtune - in the menu entry Debian created for it) from the
menu, as opposed to from an xterm. I guess in that case, stdout just gets
written to /dev/null, since there's no place to print to?

> As to adding the Modeline entries manually ... that's how I would read it
> too. I just want to caution you that hand-editing /etc/X11/XF86Config-4
> conflicts with the "Debian way", which relies on configuring through dpkg
> (in this case, probably dpkg-reconfigure). It means tyou run the risk of
> losing your changes as the result of an apt-get upgrade (or, more likely,
> dist-upgrade). I know of no sensible workaround for this problem, except
> the most basic one: keep a copy of your changes somewhere and be ready to
> restore them if you need to.

Ok. Hope I can remember that I saved it should I ever need to
reconfigure.

> I'm not using 2.6.x kernels yet, so I can't really help you if this is
> anything very intricate or subtle ... and some 2.6.x changes are both of
> these.
>
> You'll note that X is trying to open two distinct mouse entries, for
> "Configured Mouse" and "Generic Mouse". I have seen this before, and it
> seems to be some sort of long-standing error in the dpkg-reconfigure
> script. On my machines, if it gives me a problem (currently it doesn't - my
> X setups ignore this one and use Confifured Mouse with no problem) I fix
> it by editing support for the wrong one (in your case, Generic Mouse) out
> of XF86Config-4 by hand. Just go to the section called "ServerLayout" and
> delete, or comment out, the line for "Generic Mouse".

I'm afraid this may turn out to be intricate and/or subtle. Commenting
out Generic Mouse in the ServerLayout section of XF86Config-4 did *not*
make the mouse cursor work (i.e., same "paralyzed" cursor I described
earlier) when I booted the 2.6.4 kernel after editing. Double-checked the
entry after having booted into 2.6.4 console mode and the changes I had
made were there.

> But your problem is probably with the "Configured Mouse" entry. It may be
> using the wrong device (I don't have a /dev/gpmdata device here so cannot
> check what it is). You may be able to fix the problem by editing
> XF86Config-4 so this Device entry points to /dev/psaux (assuming you have
> that device).

I installed gpm (gives mouse cursor/action in console mode) since I've
used virtual terminals alot on other machines. On this one, I don't use
them much, so maybe I should just uninstall gpm? I did work on this 2.6.x
cursor problem a couple of months ago to try and untangle things, and as I
recall, the mouse cursor was not working with the 2.6.x kernel even before
I installed gpm. But my memory of that troubleshooting episode is fairly
faded now. If it seems like it could help, I'd be willing to uninstall
gpm. I made the entry point at /dev/gpmdata because of erratic cursor
problems after I installed gpm, btw (more hand-editing, as you can see).

On Mon, 12 Apr 2004, Bryan Whitehead wrote:

> You are not loading in the USB input modules. Read the kernel docs on
> what ones you need. I don't use debian so I can't help anymore...

Ugh. Another irritant I had shoved so far onto the back burner I forgot
it was there. I think USB is not functioning on this machine, for
whatever reason. As you might guess, I have no urgent needs for USB, so I
hadn't even thought of confronting that one yet. But this is not a USB
mouse and, at the moment, USB is not so crucial on this machine. So, why
would USB need to be working for me to use my ps2 mouse? Maybe Ray's
suggestion was meant to ignore the USB problem as I've tried to do, and
just make the computer ignore the problem entry that tries to invoke USB
as well. But that seems not to have worked either. Any other
suggestions? Must I really tackle the USB problem before I can get my ps2
mouse working under the 2.6.4 kernel?

On Mon, 12 Apr 2004, Ray Olszewski wrote:

> >resolve how to remove them when I loaded new ones). So, would I specify
> >the kernel version number I want to remove, even though I did not specify
> >it to be installed by kernel version number? Or must I simply manually
> >delete things?
>
> I don't do this either. But as I read the Debian docs, installing (or
> upgrading) kernel-image-2.4-686 is just a trick, in that this is a dummy
> package with nothing in it but a dependency on the latest real 2.4.x image
> compiled for a "686". So it forces installation of another package with the
> actual kernel (currently kernel-image-2.4.25-1-686, if my package
> repository here is up to date).
>
> So you should be able to apt-get remove kernel-image-2.4.19-686 (for
> example), to get rid of the old kernels without losing the current one.
> Personally, I'd also make sure any entries for them are removed from
> /etc/lilo.conf (or the config file for whatever bootloader you use), then
> rerun lilo, after you remove any kernel images ... I don't recall how the
> package configurator handles old kernel images when updating lilo.

Ok, I'll try that. Thanks for the advice. Maybe I'm being too hyper
about kernel upgrades, but when I read about some kernel security
vulnerability, my inclination is to upgrade to a newer kernel. Is this a
sound, or perhaps inadvisable, approach?

Thanks, James
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: longstanding Linux irritants: suggested solutions?

Responding to bits and pieces only.

At 10:28 PM 4/12/2004 -0500, James Miller wrote:
[...]
I know of no sensible workaround for this problem, except
> > the most basic one: keep a copy of your changes somewhere and be ready to
> > restore them if you need to.
>
>Ok. Hope I can remember that I saved it should I ever need to
>reconfigure.

You sound like my son. But I digress ....

Over the years, the only practice I've found that lets me avoid this sort
of problem is to maintain a configuration-notes file on each system I
admin. I keep it in /root, I always give it the same name, and I write down
everything I do, including noting the locations of any non-standard backups
I make. Since I never have more than a half-dozen machines I'm supporting,
this approach suffices (combined with using only Debian and having some
fairly predictable habits about how I do things) to let me keep track of
system-level stuff pretty well. I admit I learned this lesson the hard way.

I do wonder if others have developed better tricks than I have for keeping
track of things.

> > But your problem is probably with the "Configured Mouse" entry. It may be
> > using the wrong device (I don't have a /dev/gpmdata device here so cannot
> > check what it is). You may be able to fix the problem by editing
> > XF86Config-4 so this Device entry points to /dev/psaux (assuming you have
> > that device).
>
>I installed gpm (gives mouse cursor/action in console mode) since I've
>used virtual terminals alot on other machines. On this one, I don't use
>them much, so maybe I should just uninstall gpm?

Yes. gpm and X are known to conflict. Sometimes -- with particular X
servers and mice, I guess -- they don't .. but that's just luck.

[...]
>Ok, I'll try that. Thanks for the advice. Maybe I'm being too hyper
>about kernel upgrades, but when I read about some kernel security
>vulnerability, my inclination is to upgrade to a newer kernel. Is this a
>sound, or perhaps inadvisable, approach?

Hard to answer definitively. Most of the vulnerabilities I see reported in
Debian security announcements are local ... they are ways an ordinary user
can become root. Since only my son and I use these hosts, and we both have
root access, and they are behind a good firewall, I tend not to treat these
announcements as urgent. But if I were in a work or school setting with
many unprivileged user accounts, or I were connecting directly to the
Internet, I would be more proactive.

The security of a host or a network needs to be judged as a whole, not
piece by piece.



-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: longstanding Linux irritants: suggested solutions?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

James Miller wrote:



> On Mon, 12 Apr 2004, Ray Olszewski wrote:
>
>
>>I can only give you partial answers here, James. I hope they are enough to
>>be of some help.
>
>
>
>>"stdout" is short for "standard output" and is, by default, the terminal
>>display from which a program is run. It's what you redirect with the >
>>character. There is also "stderr", or "standard error" ... also the
running
>>terminal by default, but separately redirectable with the 2>
characters. So
>>what you read just means that xvidtune (not Xvidtune; case counts) will
>>print the values to the screen, or to whatever file you redirect screen
>>output to.
>
>
> Thanks for your input, Ray. So, stdout means within an xterm from which
> an application is started, according to Bryan's directions and my
> implementation of them. I had been starting xvidtune (it *does* appear
> capitalized - Xvidtune - in the menu entry Debian created for it) from the
> menu, as opposed to from an xterm. I guess in that case, stdout just gets
> written to /dev/null, since there's no place to print to?
>
>

Actually, when you run a program from a menu or from a run-dialog in a X
window manager, stdout would be on the console that X had been started
from. For example, if you are on tty1 and start X, and then run
xvidtune from your menu, the stdout from xvidtune would be sent back to
tty1. You normally can switch back to tty1 with ctrl-alt-F1. But
generally it is easier just to use an xterm if you need to see the
stdout from an X ap.



>>But your problem is probably with the "Configured Mouse" entry. It may be
>>using the wrong device (I don't have a /dev/gpmdata device here so cannot
>>check what it is). You may be able to fix the problem by editing
>>XF86Config-4 so this Device entry points to /dev/psaux (assuming you have
>>that device).
>
>
> I installed gpm (gives mouse cursor/action in console mode) since I've
> used virtual terminals alot on other machines. On this one, I don't use
> them much, so maybe I should just uninstall gpm? I did work on this 2.6.x
> cursor problem a couple of months ago to try and untangle things, and as I
> recall, the mouse cursor was not working with the 2.6.x kernel even before
> I installed gpm. But my memory of that troubleshooting episode is fairly
> faded now. If it seems like it could help, I'd be willing to uninstall
> gpm. I made the entry point at /dev/gpmdata because of erratic cursor
> problems after I installed gpm, btw (more hand-editing, as you can see).
>

Well, based on the gpm man page, you should only need to use repeater
mode (-R options, creates /dev/gpmdata) in order to overcome a
single-open limitation on the mouse device, which AFAIK you should only
need to worry about if you have some types of unusual bus mouse. If you
are using standard ps/2, you shouldn't need to run gpm in repeater mode.

Here's what I would do to troubleshoot this:

1. Check & confirm gpm is working in the console, and find out which
device it opened (/dev/psaux, /dev/misc/psaux, /dev/input/mics, etc).
Edit XF86Config-4 & change '/dev/gpmdata' to the same device gpm opened,
run gpm -k (to kill gpm) and try to start X.

2. If after step 1 the mouse worked, I would close X, restart gpm
WITHOUT the -R option, and then restart X. Hopefully this would work.

3a. If after step 1 the mouse worked, but after 2 didn't work, then most
likely you are having problems between X & gpm. Two possibilities here:
either always run gpm -k to stop gpm before starting X (possibly by
editing your xinit script), or

3b. Editing XF86Config-4 back to '/dev/gpmdata', running gpm -k & then
restarting gpm with '-R raw' to start repeater mode again. If you still
have problems with gpm in repeater mode, you might want to see if the
gpm man page gives you any helpful info.



HTH,
Conway S. Smith
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQFAe37hGL3AU+cCPDERAkJRAJ4pp9282EJc+GNywMZgEhb10iN9tQCg 0Y0S
K8IbQynVnr43rIQVrFyAzeQ=
=efa+
-----END PGP SIGNATURE-----
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: longstanding Linux irritants: suggested solutions?

On Mon, 12 Apr 2004, Beolach wrote:

> > I installed gpm (gives mouse cursor/action in console mode) since I've
> > used virtual terminals alot on other machines. On this one, I don't use
> > them much, so maybe I should just uninstall gpm? I did work on this 2.6.x
> > cursor problem a couple of months ago to try and untangle things, and as I
> > recall, the mouse cursor was not working with the 2.6.x kernel even before
> > I installed gpm. But my memory of that troubleshooting episode is fairly
> > faded now. If it seems like it could help, I'd be willing to uninstall
> > gpm. I made the entry point at /dev/gpmdata because of erratic cursor
> > problems after I installed gpm, btw (more hand-editing, as you can see).
> >
>
> Well, based on the gpm man page, you should only need to use repeater
> mode (-R options, creates /dev/gpmdata) in order to overcome a
> single-open limitation on the mouse device, which AFAIK you should only
> need to worry about if you have some types of unusual bus mouse. If you
> are using standard ps/2, you shouldn't need to run gpm in repeater mode.
>
> Here's what I would do to troubleshoot this:
>
> 1. Check & confirm gpm is working in the console, and find out which
> device it opened (/dev/psaux, /dev/misc/psaux, /dev/input/mics, etc).
> Edit XF86Config-4 & change '/dev/gpmdata' to the same device gpm opened,
> run gpm -k (to kill gpm) and try to start X.
>
> 2. If after step 1 the mouse worked, I would close X, restart gpm
> WITHOUT the -R option, and then restart X. Hopefully this would work.
>
> 3a. If after step 1 the mouse worked, but after 2 didn't work, then most
> likely you are having problems between X & gpm. Two possibilities here:
> either always run gpm -k to stop gpm before starting X (possibly by
> editing your xinit script), or
>
> 3b. Editing XF86Config-4 back to '/dev/gpmdata', running gpm -k & then
> restarting gpm with '-R raw' to start repeater mode again. If you still
> have problems with gpm in repeater mode, you might want to see if the
> gpm man page gives you any helpful info.

Thanks for your input, Conway. I found it a bit confusing, but here is
some feedback to it. gpm.conf indicates gpm is reading from /dev/psaux.
I have booted the 2.6.4 kernel and tried changing /dev/gpmdata in
/etc/X11/XF86Config-4 to /dev/psaux. When I do this, startx fails with
the 2.6.4 kernel. It's a fatal server error, "cannot open device
/dev/psaux no such device, Configured Mouse: cannot open input device,
Preinit failed for input device Configured Mouse, no core pointer" (those
seem the most pertinent parts of the output to stdout :) ). Steps 2-3b do
not apply, so far as I can understand, given the total failure of step 1.
Again, the problem here is loss of mouse functionality when trying to use
the 2.6.x kernels. Everything works fine using the 2.4.25 kernel.

James
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: longstanding Linux irritants: suggested solutions?

I've hacked together a pseudo solution to the 2.6.4 kernel/mouse problem,
but created others in the process. The particulars of why things are the
way they are and why what I did resolved something largely escape me. But
while I still retain some scraps of insight into it, I think I'll make a
post here about it on the off chance it may help someone else, or that it
may generate responses from those more knowledgeable who may be able to
help me work out problems that remain or have been newly created.

I'll start with the following. Someone on another list suggested adding
the line "psmouse" to the file /etc/modules - this so a certain
mouse-related module would get loaded at bootup. This did not help at all
- same frozen mouse cursor I had before. I tried changing the configured
mouse in XF86Config-4, editing /etc/gpm.conf according to things I was
finding in web seraches, but nothing seemed to make the cursor respond to
mouse movements using the 2.6.4 kernel. Neither was the mouse cursor ever
working in console mode (gpm was not functional). Then, I found something
that talked about another module needing to be loaded for ps/2 mice - it's
called "mousedev." At the same site, I learned that /dev/psaux has been
done away with by the 2.6.x kernels - much to that author's chagrin.
Since I had XF86Config-4 pointing at /dev/gpmdata, and gpm.conf, in turn,
pointing at /dev/psaux, it seemed likely that I had no referent for X to
find the mouse's physical location. Then, I ran across a site that said
to look at the output of cat /proc/bus/input/devices, which I did. This
is where I found out where the 2.6.4 kernel I was trying to use was
"looking" for the mouse (what I think of as the mouse's physical location,
though that's likely a wrong understanding): it expected a mouse at
/dev/input/mouse0, it seems. When I entered that in to XF86Config-4,
after having modprobed the additional mousedev module, the mouse cursor
began to respond to physical movement of the mouse. So, I got it working
like that. gpm, however, has ceased to work. I can't get the mouse
cursor to appear or move in console mode. I tried pointing it to the same
/dev/input/mouse0 location, but that did not make it work. I'm not sure
what my next step should be on that. Anyway, I added mousedev to
/etc/modules as well, then tried booting with the 2.4.25 kernel. Now, the
mouse cursor is frozen under the 2.4.25 kernel: it does not respond to
physical movement of the mouse.

Moral of the story: man with 2 kernels kills one mouse (an ancient Incan
proverb :) ). At least for now, it is not possible for me to boot between
2 kernels and have a working mouse: I must use either one or the other.
And I'll have to determine what further conjuring I'll need to do to get
gpm working again under 2.6.4.

Further input welcomed.

Thanks, James

PS Just noted that the console beep has ceased working under 2.6.4 as
well: another module loading problem? We'll see . . .
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: longstanding Linux irritants: suggested solutions?

On Tue, 13 Apr 2004, James Miller wrote:

> Moral of the story: man with 2 kernels kills one mouse (an ancient Incan
> proverb :) ). At least for now, it is not possible for me to boot between
> 2 kernels and have a working mouse: I must use either one or the other.
> And I'll have to determine what further conjuring I'll need to do to get
> gpm working again under 2.6.4.
>
> Further input welcomed.
>
> Thanks, James
>
> PS Just noted that the console beep has ceased working under 2.6.4 as
> well: another module loading problem? We'll see . . .
> -

lol :-)))
my gpm uses /dev/mouse which is a symlink to /dev/psaux. X uses
/dev/psaux. My configuration works in 2.4 and in 2.6. I think is an error
on your side.

To enable console beep in 2.6 you must have PC speaker support in your
kernel. Since you are using a vendor kernel you should complain to them.


--
"A mouse is a device used to point at
the xterm you want to type in".
Kim Alm on a.s.r.
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

kernel 2.6.4 report, further assistance requests

I'll make this post a sort of follow-up and report of the 2.6.4 kernel
I've been asking help with over the last day or so. I'll also ask for
some further help/suggestions.

As you may be aware, I finally got my mouse cursor to respond to physical
mouse movement by loading a couple of modules and by discovering the
device file the kernel expected it to be at. I am happy with the way the
mouse works, and it is an improvement over the way it's been working in
2.4.x: I have a tiny trackballish mouse, and the way the 2.6.x kernel
exagerrates motion is actually a benefit on this mouse. I read on the web
about how some had to tweak some settings because the motion was too
exaggerated for them, but for my mouse it works better than it ever has
(there may be a way to accomplish this same sort of thing under 2.4.x
kernels, but I was never savvy enough to find out about it or do it: heck,
I didn't even know I'd like it until I stumbled onto it by trying to use
the 2.6.x kernel). And, btw, though the console mode mouse function (gpm)
was not working earlier, it has now begun working - I know not how.
Overall, I'd say there is a noticeable increase in system speed.
Programs seem to open more quickly, shifting between desktops is quicker
and the like. I had my doubts about claims of system speeed increases
with 2.6.x, but now that I see this kernel in action, I'd cast my lot in
with those who claim noticeable performance increases.

Though I'd like to keep using this kernel, there are a couple of things
that stand in the way: one somewhat minor, but the other a real
show-stopper. The show-stopper is vmware: for some reason, I can't get
its modules to compile under this kernel. I've done these vmware
recompiles several times recently for the 2.4.x kernels I've been
upgrading to, so I know I have all the ingredients in place (e.g.,
compiler, header files etc). I tried a very recent patch for vmware, but
the process continues to abort during make. If I have to reboot into the
2.4.25 kernel just to run vmware, I'll have to abandon my 2.6.4 efforts
for now: it just won't be worth the added hassle. The other, less serious
problem (though one that really bugs me), is loss of console beep under
the 2.6.4 kernel. echo -e "\a" from the command line gives an extra blank
line, as though the system is doing something, but I hear no sound. I ran
into this problem on another 2.6.x system I was using and resolved it by
upping the volume on the PC speaker using alsamixer. Seems kind of
backward to me that a sound system like alsa should govern the system
speaker, but if I could resolve things that easily on this system, I'd do
it. alsamixer gives me error messages when I try to run it on this
machine ("alsamixer: function snd_ctl_open failed for default: No such
device") and troubleshooting the whole sound system looks like a big
headache I just can't get involved in right now. And besides, I really
don't care if I get any other sounds than the system speaker out of this
machine - at least for the time being. Using alsa to get sound from the
system speaker looks in this case a bit like trying to kill a gnat with a
sledgehammer.

Suggestions appreciated, as always.

James
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: kernel 2.6.4 report, further assistance requests

James Miller wrote:

>Though I'd like to keep using this kernel, there are a couple of things
>that stand in the way: one somewhat minor, but the other a real
>show-stopper. The show-stopper is vmware: for some reason, I can't get
>its modules to compile under this kernel. I've done these vmware
>
>
the modules for the 2.4 style kernels are different from the 2.6 ones
and I don't think they are
compatible ,i.e, if they compile on a 2.4 they wouldn't compile on a
2.6. better check for a 2.6
compatible version of vmware. also could you tell me where you can
download the same?
I've heard a lot about it and want to see what it's about.

>recompiles several times recently for the 2.4.x kernels I've been
>upgrading to, so I know I have all the ingredients in place (e.g.,
>compiler, header files etc). I tried a very recent patch for vmware, but
>the process continues to abort during make. If I have to reboot into the
>2.4.25 kernel just to run vmware, I'll have to abandon my 2.6.4 efforts
>for now: it just won't be worth the added hassle. The other, less serious
>problem (though one that really bugs me), is loss of console beep under
>the 2.6.4 kernel. echo -e "\a" from the command line gives an extra blank
>line, as though the system is doing something, but I hear no sound. I ran
>
the system speaker is not governed by alsa. that would be like killing a
microbe with a road roller actually;-)
cat your .config if you compiled your own kernel or the
System.map((?)not sure) and grep for speaker
and check if it is enabled on your kernel.

>into this problem on another 2.6.x system I was using and resolved it by
>upping the volume on the PC speaker using alsamixer. Seems kind of
>backward to me that a sound system like alsa should govern the system
>speaker, but if I could resolve things that easily on this system, I'd do
>it. alsamixer gives me error messages when I try to run it on this
>machine ("alsamixer: function snd_ctl_open failed for default: No such
>device") and troubleshooting the whole sound system looks like a big
>headache I just can't get involved in right now. And besides, I really
>don't care if I get any other sounds than the system speaker out of this
>machine - at least for the time being. Using alsa to get sound from the
>system speaker looks in this case a bit like trying to kill a gnat with a
>sledgehammer.
>
>Suggestions appreciated, as always.
>
>James
>
cheers,
Joy.MM

>-
>To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.linux-learn.org/faqs
>
>
>



-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: kernel 2.6.4 report, further assistance requests

On Wed, 14 Apr 2004, joy wrote:

> the modules for the 2.4 style kernels are different from the 2.6 ones
> and I don't think they are
> compatible ,i.e, if they compile on a 2.4 they wouldn't compile on a
> 2.6. better check for a 2.6
> compatible version of vmware. also could you tell me where you can
> download the same?
> I've heard a lot about it and want to see what it's about.

They've issued some patches that are supposed to make compiling for the
2.6.x kernels possible, and I've used them. make still fails for some
reason (I'm posting to the vmware forum in hopes of getting help with
that). vmware is available as a 30day trial version from their site (
www.vmware.com ). It's pricey if you're really considering buying it:
over $300 for end users. I got an educational discount on mine, or I
wouldn't have bought it. Were I to do this again, I'd probably try
Win4Lin, which is alot cheaper, because I only need Win98. If you need
to run something newer, vmware might be your only choice (unless you want
to try more beta-ish stuff like Bochs or maybe Colinux).

> >the 2.6.4 kernel. echo -e "\a" from the command line gives an extra blank
> >line, as though the system is doing something, but I hear no sound. I ran
> >
> the system speaker is not governed by alsa. that would be like killing a
> microbe with a road roller actually;-)
> cat your .config if you compiled your own kernel or the
> System.map((?)not sure) and grep for speaker
> and check if it is enabled on your kernel.

Yes, I checked that. It is marked with "m" in the config file, so can be
loaded as a module. The solution turned out to be "modprobe pcspkr." I
suppose I should add that to /etc/modules? Turned out to be simpler than
I thought, thankfully.

James
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: kernel 2.6.4 report, further assistance requests

Just to bring to an end this gruesome tale, I offer the following. The
vmware developer who monitors the forum and lives in the Czech Republic
mentioned that he had gotten vmware modules to compile using the latest
patch under a 2.6.5 kernel. Since the 2.6.5 kernel has now become
available on Sid mirrors (don't know since when, but recently), I decided
to test it and see if the compile would succeed under 2.6.5 where it had
failed under 2.6.4. Sure enough, it worked. So, I now have vmware
working, the PC speaker working - and everything else on the system, so
far as I can tell - with better mouse action and a snappier system under
the 2.6.x kernel. I think I'll probably stick with it now. Thanks for
your input.

Sincerely, James

-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs