questions and issues about the modular X updates

[Mike A. Harris]

Jason Dravet wrote:
> I just updated my rawhide system to the new modular x.  I have been 
> reading some of the threads discussing this and I have a couple of 
> questions:
> 
> 1.  With modular X (when released) have support for automatically 
> turning on numlock when I start X?

You can do that with any version of X, by calling xset from
~/.Xclients or ~/.xinitrc, or one of the systemwide locations.

> 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
> rpm -e xorg-x11-drv-trident
> error: Failed dependencies:
>        xorg-x11-drv-trident is needed by (installed) 
> xorg-x11-drivers-0.99.2-3.i386

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.


However, the system is designed intentionally to still install all of
the X drivers all of the time, and to expect that they are all there.

The disk space usage of the entire set of drivers is very minimal with
today's hard disk sizes, so saving disk space by being able to remove
the drivers one does not need (or does not think they need), is not an
intended "feature".  In fact removing individual driver packages is
very strongly discouraged, as it can break upgrades.

At a minimum, if someone uninstalls a driver, and later switches
or adds hardware that needs that hardware, the config tools will detect
the new hardware, and configure X to use the driver that is not there.
The X server will fail to start, complaining that there is no such
driver, and the user may file a bug report to us about a missing
driver, that is not missing, it's just been uninstalled.

Please note that this is just a short term thing.  In the long term,
perhaps in FC6 or FC7 depending on various factors, I would like to
see the config tools updated with the capability to know about all
of the drivers shipped in the OS, and be able to ask for the Fedora
CDROM or use yum to download them if you have uninstalled a driver
that you now have hardware for.  However if you do that now, things
_WILL_ break.  If not right away, then when you do your next OS
upgrade.

So, for FC5, make no mistake:  Do not uninstall individual X drivers
unless you want to end up in a whole world of pain, just to save
the equivalent of about 5 cents worth of disk space.

The xorg-x11-drivers package is a meta-package that does nothing
other than "Require: <driver>" all of the drivers, in order to
ensure that they are all installed - like almost every modern
operating system does nowadays because disk space is cheap and
drivers are small comparatively.

The X server package is probably going to pick up a new dependency
soon of "Requires: xorg-x11-drivers" to further enforce that all
drivers are always installed.

This is entirely a support decision, to minimize end user technical
problems that could potentially happen, until we have improved the
rest of the OS to be more dynamically friendly WRT drivers.


> Will I be able to uninstall unnecessary drivers?

In theory, you could force them to uninstall, breaking the dependency
chain, but then you take all risks of the OS not working on upgrades.

People who force things to be uninstalled, and then experience problems
and file bug reports, will generally not get any pity, and will
see CLOSED->NOTABUG likely.  ;o)


> 3.  My Microsoft Intellimouse explorer (usb) no longer functions as 
> expected.  I still have
>        Option "Protocol" "ExplorerPS/2"
>        Option "Device" "/dev/input/mice"
>        Option "Buttons" "7"
>        Option "ZAxisMapping" "6 7"
> in my xorg.conf.  I also have the mouse.sh file in /etc/X11/xinit/xinitrc.d
> #!/bin/sh
> # /etc/X11/xinit/xinitrc.d/mouse.sh
> # Required for the configuration of a 5-button mouse
> xmodmap -e "pointer = 1 2 3 6 7 4 5"
> In short the back and forward buttons work as a scroll.  How can I fix 
> this?

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 at 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



> If I need to open bugzilla tickets I will be happy to do so.  A quick 
> guess would be to file #1 and #3 will bugzilla.freedesktop.org, and #2 
> should probably goto bugzilla.redhat.com.  Would this be correct?

#1 isn't a bug, you can already do that in every X release
#2 isn't a bug, it is an intended support/engineering feature designed
    to minimize end user problems and unnecessary bug reports.
#3 might be an Xorg bug as mentioned above.

Hope this helps!

Take care,
TTYL