pair xorg.conf with particular hardware

[Dustin Kirkland ]

Binary package hint: xorg

This is perhaps a strange request, so I'm marking this as "wishlist" and attaching a patch...

I have two laptops:
 * Thinkpad t61p, nVidia, 1400x1050
 * Thinkpad x61, Intel, 1024x768

I primarily use my t61p, however, when traveling on business, I like to swap hard drives, bringing along the x61 which is significantly smaller.

I am able to do this seamlessly for all of the hardware, except for the video which is so drastically different between the two systems (different drivers, different resolution).

I have solved this problem by painstakingly generating a "pristine" xorg.conf on each system, and I use /etc/init.d/x11-common to detect if the hardware has changed and if a suitable xorg.conf exists.

In order to do this, I "sign" the known, good /etc/X11/xorg.conf by generating an md5sum signature of the hardware with:
 * lspci | grep VGA | md5sum
and appending that to the end of /etc/X11/xorg.conf.

Is this completely brain-dead? Would this be useful to anyone else?

:-Dustin

[Dustin Kirkland  (kirkland)]

Patch attached.

Built package available in my PPA.

Comments?

:-Dustin

[Emmet Hikory (persia)]

Does this still occur with intrepid? For most cases, intrepid ought require no xorg.conf at all, which would then autdetect the appropriate configuration based on your actual hardware. Note that many hardy configurations should also work without specification of video drivers in xorg.conf

[Dustin Kirkland  (kirkland)]

On Thu, Aug 14, 2008 at 1:25 AM, Emmet Hikory <email address hidden> wrote:
> Does this still occur with intrepid?

Yes, it does.

> For most cases, intrepid ought
> require no xorg.conf at all, which would then autdetect the appropriate
> configuration based on your actual hardware. Note that many hardy
> configurations should also work without specification of video drivers
> in xorg.conf

Mine do not, unfortunately.

01:00.0 VGA compatible controller: nVidia Corporation Quadro FX 570M (rev a1)
and
00:02.0 VGA compatible controller: Intel Corporation Mobile
GM965/GL960 Integrated Graphics Controller (rev 0c) (prog-if 00 [VGA
controller])

:-Dustin

[Bryce Harrington (bryce)]

I like the patch. In fact I think it could be extended to cover more hardware.

There's a number of hacks around for hot swapping xorg.conf's for wacom tablets, for instance, and probably other stuff too. It would be nice to have a unified, official way to handle such corner cases when we've not yet solved them in the xserver itself.

The one big problem I see is that a user could get confused if they use this, then later forget and update xorg.conf manually, only to find their changes are lost. This could especially be a problem if they mix using this with using envyng/jockey. So, as a minimum I'd want to see this integrated to work with both those tools. Perhaps this could be done by adding some logic to x-kit.

Thinking more broadly, this touches on the general issue of "dealing with multiple customized xorg.conf's". This could be due to dealing with frequent hardware changes not covered by xserver's hotplugging, backups, or testing alternate configuration options (e.g. bulletproof-x). It would be nice to have a general solution that would cover all these cases.

This particular issue is with wanting to prefer -nvidia in situations where -nv works, but not as well. Kirkland tested and found nv boots okay when using no xorg.conf, however he prefers -nvidia. In Ubuntu we generally have the principle that if the open driver _works_ we should prefer it, even when the proprietary driver works better. So defaulting xorg.conf-less to use -nvidia in this particular case with this particular hardware is not the right way to go based on those principles. On the other hand, -nv lags -nvidia heavily in features, and doesn't seem to have very active maintenance, so waiting for it to improve may be a test of patience.

Anyway, so I think this is a pretty rare corner case, and not one we'd want to necessarily address in the core xserver. So kirkland's on the right track of providing the user with an opt-in mechanism for preferring a non-default config, and still be able to do semi-hotpluggable stuff. But I think this needs more thought and better integration. I've encouraged him to discuss it on the ubuntu-x@ list.

[Dustin Kirkland  (kirkland)]

Patch updated, to print success/failure messages and output the filename when performing a hw-signing.

:-Dustin

[Bryce Harrington (bryce)]

I took a look into integrating this today, but on second look I think we need something more general purpose.

I definitely think there may be a use case for this with users having removable harddrives, who might need to have non-default settings in their xorg.conf, but this is a fairly small userbase.

As mentioned before, there are additional use cases that could also benefit from a hotswappy xorg.conf - input devices like wacom tablets in particular. However, the patch as it currently stands is detecting HW changes based on lspci output, which wouldn't catch input device changes. So we'd need something a bit different here. Perhaps HAL?

As well, the idea of having alternate xorg.conf's needs to be generalized into an x-kit based library that provides a programmatic API and a command line tool to select which xorg.conf to boot, and that performs the switch. The switch could either be done via cp -f as shown in this patch, or perhaps could be done by passing it in to X via the -config flag. This functionality would then also be added to the Bulletproof-X code, to replace the current backup_xorg_conf(), etc. routines. Tool support for adding/editing/removing xorg.conf's from the library could also be done.

[Bryce Harrington (bryce)]

Hi Kirkland,

I've incorporated all of the above concepts into the X Options Editor specification:
  https://wiki.ubuntu.com/X/OptionsEditor

We needed an xorg.conf recovery mechanism so the user can experiment with different options but still restore to a known-good config, so to kill two birds with one stone I've included support in the requirements for implementing this hardware-pairing concept. I would love it if you could review the "Safety Net" section of that spec and make sure I have a sane concept laid out there.

[Bryce Harrington (bryce)]

Hi kirkland,

Thank you for taking the time to report this bug and helping to make Ubuntu better. You reported this bug a while ago and there hasn't been any activity in it recently. We were wondering is this still an issue for you? Can you try with the latest development release of Ubuntu? (ISO CD images are available from http://cdimage.ubuntu.com/releases/)

If it remains an issue, could you also attach a new /var/log/Xorg.0.log?
Thanks in advance.

[This is an automated message. Apologies if it has reached you inappropriately; please just reply to this message indicating so.]

[Dustin Kirkland  (kirkland)]

Bryce-

I'm happily using my patch. It's fairly specific to my (somewhat strange?) situation, but it works for what I need it to do, and I'm happy to continue using it.

I don't think I need you to do anything more, here, as Ubuntu's X maintainer. You may safely close this bug, and come dig up this code sometime later if it's ever generally useful.

:-Dustin

[Bryce Harrington (bryce)]

Great, thanks Dustin

[Bryce Harrington (bryce)]

[Looks like we're moving to an xorg.conf.d-based configuration approach, which gives a different/better way for handing this particular case, so I'm unmarking the patches on this bug; they really should be redone to use the xorg.conf.d approach, with a mechanism to detect which conf snippet to use based on the hardware that's present.]

[Dustin Kirkland  (kirkland)]

Bah, they're no longer necessary, since you guys have improved the
graphical display experience so immensely ;-)

Cheers to you for listening to my rant in this bug!

:-Dustin