X.org 1.5.3, hald(8), and ability to use misc/compat6x

[David Wolfskill]

After upgrading to X.org 1.5.3, I created a new xorg.conf, compared it
to the old one, and decided that the differences were consistent with
the warning in UPDATING, so I installed the newly-generated one.

It took me a while after re-starting X to realize that the comment
about hald in UPDATING probably was intended to imply that absent
appropriate evasive action, it was rather expected that a system
running X.org 1.5.3 would also actually have hald(8) running, vs.
merely installed as a dependency.  And that led to starting dbus(8)
similarly.

So after dealing with that for most of yesterday -- rebuilding all
of the X-related stuff on a laptop can take a while -- and then
updating a handful of X drivers again this morning (which was
mercifully brief -- thank you!), I actually had time to reboot from
the RELENG_7 slice to update it.

I was pleasantly surprised to see that X came up OK, with no loss
of function.  (I've been fighting an issue that pops up frequently,
but not quite always, where starting X locks the system up so tight
in RELENG_7 that it requires a power-cycle to change state.  When
this happens, the laptop's screen generally does not (completely?)
switch to graphics mode.  It also happens in HEAD, but there I can
break into the debugger from a serial console.  So far, the only
circumvention found is to disable DRI in xorg.conf.  I've been
providing the information I can to rnoland at .)

I held out a (small) hope that perhaps the update to X.org (including
dri-7.3,2) might have addressed the issue with DRI.  But it also
seemed to indicate that running ports -- all built under RELENG_6
-- while running a RELENG_7 system (with the compat6x port installed
as the only port built under RELENG_7) was (still) OK.

After updating FreeBSD on the RELENG_7 slice, I rebooted, and was
quickly disabused of both notions:

* I had a recurrence of the "lockup during transition to graphics
  mode" again.  Hacking xorg.conf to disable DRI circumvented that,
  only to yield:

* Once xdm started, I had no use of the keyboard or mouse for the
  xdm login screen.  I was, however, able to switch to an alternate
  vty.  So these symptoms were identical to thise I had under
  RELENG_6 before I started hald(8).

  As a circumvention for this, I added:

Section "ServerFlags"
	Option     "AllowEmptyInput"   "False"  # [<bool>]
	Option     "AutoAddDevices"    "False"  # [<bool>]
EndSection

  to xorg.conf.  (I expect that one of those is likely overkill,
  but it works.)

So is a hald(8) (and dbus(8)) built under RELENG_6 supposed to work
in a RELENG_7 environment that has the misc/compat6x port installed?

(In case it isn't apparent, I have the laptop sliced up so that I
can boot & run FreeBSD from any of the 4 slices; in doing so, certain
things will be the same regardless, as they will actually refer to
the same locations on disk:

* swap space
* /var
* A file system for repositories (CVS & SVN)
* A file system for miscellaneous common stuff, such as home directories.

For each slice, /usr/local is actually a symlink to a (single)
directory in that last file system listed, so /usr/local is effectively
shared across all environments.  This is something I would much
prefer to retain, as going through that X.org upgrade for each slice
is quite enough to give one significant pause.  And so far, I've
been able to avoid changing the default installation locationj for
any ports.)

[No need to Cc: me if you write to the list.]

Thanks!

Peace,
david
-- 
David H. Wolfskill				david at catwhisker.org
Depriving a girl or boy of an opportunity for education is evil.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20090125/2de7c9e7/attachment.pgp