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 [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Reply via email to