Mouse problems
by Boris Goldowsky
Anyone know if the necessary configurations for scroll-wheel mouses have
changed with the new X version?
I have a microsoft intellimouse optical which is usb with a ps/2
adapter. I used to use it as a PS/2 mouse in XFree86 with a setting
like this:
Section "InputDevice"
Identifier "Mouse0"
Driver "mouse"
Option "Protocol" "IMPS/2"
Option "Device" "/dev/psaux"
Option "Buttons" "7"
Option "ZAxisMapping" "6 7"
EndSection
And with that the scroll wheel and side buttons worked well. But with
XOrg I have been unable to make that work - it does not see any mouse on
/dev/psaux (or any other device that I can locate - I tried /dev/mouse,
/dev/input/mice, etc). I can get basic mousing to work with it plugged
in to a usb port, but that does not recognize the scrollwheel or extra
buttons.
Anyone have a mouse like this working, or can you give me any pointers?
I did read README.mouse and look at the x.org site, but didn't find
anything helpful there.
Thanks -
Boris
19 years, 12 months
Re: X and Logitech optical mouse (OEM)
by Brian Bober
I know PS/2 disconnects/reconnects (i.e. from a KVM switch) can cause erratic
mouse behavior on Intellimouse in X windows. Maybe its similiar. Check to see
if your mouse is pushed in enough.
19 years, 12 months
RE: header/RPM mismatch
by Fulko.Hew＠sita.aero
"-=Brian Truter=-" <brian(a)famvid.com>@redhat.com on 04/30/2004 10:10:01 AM
commented:
>> Yesterday I was complaining about missing RPMs and the fact
>> that the update icon, and up2date were out of sync., so today
>> I thought I'd look at it some more.
>>
>> Today, my icon still says there are 2 RPMs to upgrade, but
>> up2date says that only one is available. But up2date hangs
>> while trying to resolve dependencies.
>>
>> So I went back to using yum.
>>
>> Yum told me that there are two other RPMs (gaim and
>> rpmdb-fedora) that needed updating, and that there were
>> problems with perl-XML-Twig that needs XML::Path, which is not found.
>>
>> So again I told it to ignore perl-XML-Twig, and yum installed
>> gaim and rpmdb-fedora. But alas the icon and up2date are
>> still as confused as ever.
>>
>> Looking at the alert notification tool I see that it says:
>>
>> Package Version Installed Version Available
>> perl-Net-DNS perl-Net-DNS-0.31.3.2 perl-Net-DNS-0.45-2
>> perl-XML-Twig perl-XML-Twig-3.09-3 perl-XML-Twig-3.13-4
>>
>> OK, I need perl-XML-Twig-3.13-4. So I manually look at the mirror
>> site:
>> http://mirrors.kernel.org/fedora/core/development/i386/Fedora/RPMS
>> and the only version of perl-XML-Twig it has is 3.09-3 and
>> the same goes for perl-Net-DNS (only the old version).
>>
>>
>> Now i look in the mirrors header directory, and they don't
>> have the new version either. But at some time, my system did
>> fetch that header and now it thinks that's what it needs.
>>
>> Did someone release new versions of the headers, without the
>> RPMs, (that my machine sucked)... and then pulled back the
>> new headers, (causing my machine to get into a mode)?
>>
>>
>> 1/ If so, why?
>> 2/ And how do I get my machine to forget about the headers
>> that point to
>> non-existant RPMs?
>
>I didn't see your post from yersterday, so sorry if this was stated before
>but,
>
>Is your up2date using the same repository as yum? Both tools can be
pointed
>at completely different repos. Up2date has its configuration file in
>/etc/sysconfig/rhn/sources, and yum has its in /etc/yum.conf.
Yes, they are pointing at the same repository.
I am also using yum and up2date (as-is, out of the box).
I looked a little deeper for perl-Net-DNS
yum list perl-Net-DNS
Looking in Available Packages:
Name Arch Version Repo
---------------------------------------------
perl-Net-DNS i386 0.45-2 development
Looking in Available Packages:
Name Arch Version Repo
---------------------------------------------
perl-Net-DNS noarch 0.31-3.2 db
Now having seen this, and transcribed it, it sounds like
another email from the last 24 hours.
>If they are not using the same repository, you will get results like you
are
>explaining. Also, updates that come out from fedora.redhat.com arent
picked
>up by mirrors immediately. There is varying time periods before each
mirror
>will sync with the main repo.
<RANT ON>
But both tools should be using the same config file!!!
and the master site and the mirror site should be
consistent within themselves ie. I better have the RPM that
my hdr file points at. Ie. copy header files last.
Also I don't think, by design you should allow either system to 'get into
a mode' where the various tables, databases and directories can 'get out
of sync' like this.
And while I'm at it... This business about three different updating tools
that
use three different techniques, and 3 different stores, is a piece of ...
Pick one and throw the rest away. Its hard enough testing new
distributions
for real problems without having to go through this aggravation that
manufactures
its own problems.
<\RANT OFF>
19 years, 12 months
RE: header/RPM mismatch
by Fulko.Hew＠sita.aero
WARNING: Additional ranting ahead.
"William Hooper" <whooperhsd3(a)earthlink.net>@redhat.com on 04/30/2004
11:08:31 AM added:
>Fulko.Hew(a)sita.aero said:
>
>> <RANT ON>
>> But both tools should be using the same config file!!!
>
>So yum should loose features and use up2date's config file (not very
>portable to non-RH systems), or should up2date loose features (RHN, apt
>support) so it can use yum's config file?
If yum is supposed to replace up2date, then its config file, should be a
superset
of up2date. After all, they are both supposed to do the same thing.
The bigger issues is that headers are saved in two different directories
on your system, so its guaranteed to get out of sync.
As a user, which tool am I supposed to use.
The answer (right now is) is...
a) we give you a pretty icon on your desktop, but sometimes it lies.
b) when you click on the icon it runs up2date, but sometimes it lies
And it now lies about the packages sizes too!
c) If you decide to carry on with up2date, you now have to ignore all
of the GPG errors, because of... (well I don't know).
e) Ohh, sometimes up2date hangs... Well just re-install, maybe it'll
work.
d) If you get frustrated by the now broken up2date and the GPG issues
you resort to using yum. But sometimes _it_ lies.
So in the end you don't know what you've got, who's wrong, whats wrong
or where and how to fix it.
I don't mind having choices, but at least one of those choices should
work, and if the others don't. Then they shouldn't be supplied.
"A man with two clocks, never knows what time it is."
Sorry, there just appears to be too much of the
'barely good enough engineering' going on here.
Do one thing, make it work, then go on to the next. Not:
"It powered up in the lab once, ship it, its a legacy product."
Just because certain vendors do that, doesn't mean the Linux community
should stoop to their levels.
>> and the master site and the mirror site should be
>> consistent within themselves ie. I better have the RPM that
>> my hdr file points at. Ie. copy header files last.
>
>So set up multiple rsync jobs and have a human check that the first is
done?
No, set up one job that rsyncs the RPMs, and then rsyncs the headers.
>> Also I don't think, by design you should allow either system to 'get
into
>> a mode' where the various tables, databases and directories can 'get out
>> of sync' like this.
>>
>> And while I'm at it... This business about three different updating
tools
>> that
>> use three different techniques, and 3 different stores, is a piece of
...
>> Pick one and throw the rest away.
>
>Yes, I think you should pick one and throw the rest away.
OK, which one? Which one works? ...Neither.
> Fedora shouldn't because different people like different
> packages. What's this business with multiple GUIs?
But you only run one GUI at a time.
> multiple editors?
But if I had two different editors and one only handled upper case
and the other only handled lower case, and both would randomly decide
whether they would support punctiatoion, they'd both be pretty useless.
> multiple browsers?
And can you say 'built for IE' only?
>For that matter, Fedora only ships two (up2date and yum) and both are
>using the same format for backend repos by default.
But neither of them use the same front end database and neither
seem to work right... anymore.
19 years, 12 months
Disk Druid hangs on install Test3
by Stefan Rystedt
Disk druid hangs when trying to install Test 3.
When I install I first get a message that one of my two disks has
inconsistent partition table which I chose to ignore. Then I chose new
install, personal install and partitioning with disk druid. So far so
good but if i then click a little with my mouse on the different
partitions Disk Druid hangs. Note that I hav not used any of the buttons
to create modify and so on I just changes the highlighted partition. I
have not investigated it to much yet. I think it happens when I click on
the graphics of the partitions rather then the text list. It works a
couple of time but then it hangs. I have switched to the different
console window to se if I could se any errors printed but I could not.
So the only option is to reboot. I have not issue a bugzilla on it yet I
thought I should ask if any other has the same problem. I have an ASUS
A7V mother bord with two UDMA 100 hard drives.
/ryz
19 years, 12 months
RE: header/RPM mismatch
by William Hooper
Fulko.Hew(a)sita.aero said:
>
>
> WARNING: Additional ranting ahead.
>
> "William Hooper" <whooperhsd3(a)earthlink.net>@redhat.com on 04/30/2004
> 11:08:31 AM added:
>
>
>>Fulko.Hew(a)sita.aero said:
>>
>>> <RANT ON>
>>> But both tools should be using the same config file!!!
>>
>>So yum should loose features and use up2date's config file (not very
>>portable to non-RH systems), or should up2date loose features (RHN, apt
>>support) so it can use yum's config file?
>
> If yum is supposed to replace up2date, then its config file, should be a
> superset
> of up2date.
Who said yum is supposed to replace up2date?
> After all, they are both supposed to do the same thing.
Again, KDE vs. Gnome, vi vs. emacs, etc.
> The bigger issues is that headers are saved in two different directories
> on your system, so its guaranteed to get out of sync.
Huh? Neither needs the others headers.
> As a user, which tool am I supposed to use.
> The answer (right now is) is...
>
> a) we give you a pretty icon on your desktop, but sometimes it lies.
> b) when you click on the icon it runs up2date, but sometimes it lies
> And it now lies about the packages sizes too!
> c) If you decide to carry on with up2date, you now have to ignore all
> of the GPG errors, because of... (well I don't know).
Of install the correct GPG keys...
> e) Ohh, sometimes up2date hangs... Well just re-install, maybe it'll
> work.
Have a reproducible situation? A bug number? I've been using up2date on
FC1, FC2Test2, and FC2Test3 and I don't recall any hangs.
> d) If you get frustrated by the now broken up2date and the GPG issues
> you resort to using yum. But sometimes _it_ lies.
So if "you resort to using yum" why do you think it should replace up2date?
> So in the end you don't know what you've got,
rpm -q
> who's wrong, whats wrong
> or where and how to fix it.
They all use the same rpm database.
> I don't mind having choices, but at least one of those choices should
> work, and if the others don't. Then they shouldn't be supplied.
Both work for me. YMMV.
> "A man with two clocks, never knows what time it is."
>
> Sorry, there just appears to be too much of the
> 'barely good enough engineering' going on here.
> Do one thing, make it work, then go on to the next. Not:
> "It powered up in the lab once, ship it, its a legacy product."
I'm sorry, if you are not interested in new features why are you running a
test release?
[snip]
>>So set up multiple rsync jobs and have a human check that the first is
> done?
>
>
> No, set up one job that rsyncs the RPMs, and then rsyncs the headers.
And the case of headers being release on the main site after the first job
is started is resolved how?
[snip]
>>> Pick one and throw the rest away.
>>
>>Yes, I think you should pick one and throw the rest away.
>
> OK, which one? Which one works? ...Neither.
In my experience both.
>> Fedora shouldn't because different people like different
>> packages. What's this business with multiple GUIs?
>
> But you only run one GUI at a time.
If you are trying to run up2date and yum at the same time you might have
just answered your own question.
>> multiple editors?
>
> But if I had two different editors and one only handled upper case
> and the other only handled lower case, and both would randomly decide
> whether they would support punctiatoion, they'd both be pretty useless.
A analogy, but no link to the original subject.
>> multiple browsers?
>
> And can you say 'built for IE' only?
Fedora doesn't ship IE.
>>For that matter, Fedora only ships two (up2date and yum) and both are
>>using the same format for backend repos by default.
>
> But neither of them use the same front end database and neither
> seem to work right... anymore.
Both use a yum repo and both put transactions into the RPM database. What
database are you talking about?
--
William Hooper
19 years, 12 months
kickstart under Fedora Core 2 Test 3
by Martin Robb
Mostly good news. Kickstart (both ks=cdrom and ks=floppy) is working
better for me under FC2t3 than it was under FC2t2!
Flaw 1: (major) though kickstart is still not quite working for me, I'm
getting much farther than under t1 and t2 and I'm getting consistent
behavior on several different platforms. In t1 and t2 I was being asked
to load additional drivers by kickstart even though an interactive
install using the same CD sailed right through. Under t3 I'm sailing
right past that point and getting through most of the install.
However, the install eventually dies with an "error installing
at-3.1.8-52" dialog box. This happens consistently on different
architectures and with different install CDs. The at rpm installs
cleanly in an interactive install using the same install CDs.
Flaw 2: (minor) The automatically built /root/anaconda-ks.cfg file is
close but not quite there. It listed the following clearpart and part
lines:
#clearpart --linux
#part / --fstype ext3 --onpart hda5
#part swap --noformat --onpart hda6
#part /sandbox --fstype ext3 --onpart hda7
Simply uncommenting these lines causes the install to fail with a
"requested partition does not exist ... hda5" error. However, using the
lines:
clearpart --all --initlabel
part / --fstype ext3 --size 4096
part /sandbox --fstype ext3 --size 1 --grow
part swap --size 1024
everything partitions cleanly.
As an aside, FC2t3 is installing cleanly (without kickstart) on the HP
Proliant platform -- under t1 and t2 I was getting the dreaded "loading
cciss drivers" hang. With kickstart it is at least giving me consistent
behavior with my other platforms.
Marty
MartinRobb(a)ieee.org
19 years, 12 months
RE: header/RPM mismatch
by William Hooper
Fulko.Hew(a)sita.aero said:
> <RANT ON>
> But both tools should be using the same config file!!!
So yum should loose features and use up2date's config file (not very
portable to non-RH systems), or should up2date loose features (RHN, apt
support) so it can use yum's config file?
> and the master site and the mirror site should be
> consistent within themselves ie. I better have the RPM that
> my hdr file points at. Ie. copy header files last.
So set up multiple rsync jobs and have a human check that the first is done?
> Also I don't think, by design you should allow either system to 'get into
> a mode' where the various tables, databases and directories can 'get out
> of sync' like this.
>
> And while I'm at it... This business about three different updating tools
> that
> use three different techniques, and 3 different stores, is a piece of ...
> Pick one and throw the rest away.
Yes, I think you should pick one and throw the rest away. Fedora
shouldn't because different people like different packages. What's this
business with multiple GUIs? multiple editors? multiple browsers?
For that matter, Fedora only ships two (up2date and yum) and both are
using the same format for backend repos by default.
--
William Hooper
19 years, 12 months
