Jason Dravet wrote:
You can do that with any version of X, by calling xset from
~/.Xclients or ~/.xinitrc, or one of the systemwide locations.
I saw the saw the setup for xset. I was hoping for a cleaner solution.
For example IMO having a line in the xorg.conf file to control the caps
lock, scroll lock, and num lock would be the best solution. It keeps
all of the configuration data together. When I move to new version of
Fedora I format my hard drive and copy the data back from a usb thumb
drive. Right now I have to copy back approximately 20 configuration
files and alot of odds and ends to get the system back to where it was
before I updated. If there was a line in xorg to control the lock keys
then to get X back up and running I would only have to put the xorg.conf
back. Right now I have put xorg.conf back, copy my mouse.sh file back,
and copy the numlock.sh file back. Am I crazy for thinking 1 file is
better than 3?
If you would like to see future Xorg X server releases have such a
feature, please feel free to file a feature request into X.Org
bugzilla:
http://bugs.freedesktop.org
You might also want to explore the existing options available in
the config file, as there might (or might not) be a way to do it
already.
Either way, it's an upstream X.Org issue, rather than an operating
system specific one.
2. When I did the yum update all of the xorg-x11-drv rpms
downloaded. This is 56 files several >>of which I don't need. I have
a Number nine Revolution IV video supported by the i128 package. >>I
don't need the cirrus, trident, s3, nv, etc packages, but I can't
uninstall them. I get
Yes, this is intentional. The reasons for splitting the drivers out
into individual packages, was to:
- make it very easy for us to release single driver updates
- to drastically reduce the amount of downloading necessary to update
a single driver
- drastically reduce the disk space consumption and network bandwidth
consumption for mirror sites as well as internal build machines
- to make it easy to add new video drivers to a release without
having to release a whole new 150Mb of X packages.
I agree this is a good thing. Being able to release new drivers as soon
as they come out without having to respwan all of X is great. My
concern is for bandwidth. Looking at the xorg-x11-drv files there are
about 2.3MB of drivers. This number is only going to go up as time goes
on and drivers are added and updated.
New drivers are a scarce commodity, as more and more hardware vendors
go the route of proprietary drivers. There are about 70 driver
packages in total right now, with smaller numbers of them on a specific
architecture, because some are only shipped on a subset of all of the
architectures. New drivers do not come forth very often, and at any
rate, we're talking about extremely small numbers here. I don't think
it is fair to complain about really. It's so insignificantly small that
it really doesn't matter. You don't have to download 150Mb of
monolithic X anymore, be happy about it. ;o)
If this is the biggest complaint about the new modular X, then I must
say I'm rather impressed. Maybe I should go break something in the
next update, just to keep people on their toes. ;o)
The idea about installing new
hardware and having yum or some other application go and download the
driver is good. I agree that such functionality will not be here for
FC5. If this is where things are going then I will shut up and download
everything.
/me whistles innocently
I believe they've been playing with this part of the code in Xorg CVS
lately, and that it might have gotten broken. I think I saw some CVS
commits go in in the last few days related to button ordering, but I
don't remember the details. My recommendation, is to post a message to
xorg lists freedesktop org about it for now, and see what feedback you
get back. If it turns out it is a bug, and is not fixed in CVS, query
xorg bugzilla to see if someone has already reported it or not, and if
not, file a bug, and attach your X server config and log, and your
script to the report, and mark it blocking the release blocker
bug #1690
You are correct there is a thread called ZAxisMapping causing trouble at
http://lists.freedesktop.org/archives/xorg/2005-November/date.html. I
will keep checking the list for updates.
Thank you for the reply the information was very helpful.
Glad I could help. ;o)
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
