questions and issues about the modular X updates

[Mike A. Harris]

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)