Sorry -- I misread the issue :|

I too have not found a way to still run X, with HAL dead.

Sasha

Maybe a totally different question: but why is HAL bad? It took me some getting-used-to, but eventually I found it the solution to many of my issues... This gets me curious, and curiosity can only be met with answers :-)

Ramurd, as stated in my first post here:
So please post your question elsewhere, here could be a good place.

edit:
moved my reply to Ramurd to here to keep this thread clean.

Thanks GazL.

About disabling HAL, unfortunately the problem is not solved in avoiding dbus usage, as CUPS needs dbus to work -- and I need CUPS to print.

Trying to print without it this morning (Paris time) I saw this in /var/log/syslog:
Any thought ?

I guess you could look at recompiling the xserver package and see if you can configure out HAL support at compile time and see if it avoids the problem. But it's getting a little on the involved side.

I hate to say it, but perhaps it's best to just reconsider letting HAL run.

I agree, fwiw : compiling HAL out of X is getting more involved, and the end may/probably doesn't justify the means.

Here's a thought (though again, more complex than may justify doing it):

We know that X/K/GDM quits/restarts repeatedly if HAL isn't running at the *DM login. BUT: we also seem to know that once we're logged in, HAL can be killed and stuff seems to work fine. SO:

A little bit of editing of the X or DE startup scripts could produce a situation whereby HAL gets stopped after login, but gets restarted before/during/after logout.

This would have HAL running outside of X, but when using X, it would not be running.

...just a thought
Sasha

I tried to compile xserver with --disable-config-hal option (just editing /source/x/x11/configure/xorg-server in the slackware64-13 tree) but got a compilation error. I will try to find out why this evening (Paris time).

Did you get any further with this Didier?

Yes, it works!

I didn't post earlier because at first I had compilation errors.

I suspected this being a side effect of installing all the packages needed to get a multilib Slackware as explained in this page written by Eric Hameleers aka Alien BOB. So I removed all new packages and installed back the "original" ones. But still the same errors.

To make sure it was not caused by some modification of my system before I complain to Pat something like "heh, one of your Slackbuilds don't work" I ended up doing this:
- install VirtualBox in Slackware64-13.0
- install Slackware64-13.0 in a virtual machine with VirtualBox
- mount the DVD as /mnt in the embedded Slackware-13.0 (not modified at all) and run directly /mnt/source/x/x11/x11.Slackbuild

It worked and I got all the packages!

Then as I need only xorg-server I ran following command:
/mnt/source/x1/X11/x11.Slackbuild xserver

It worked!

All I had to do now was edit the configure file, make the packages again and reinstall (in the "physical" machine, of course) the updated packages.

Now I am writing under X and without HAL (but with the dBus daemon running, so I can print with CUPS) and so far, everything seems to work.

To make a long story short, if your installation is cleaner than mine all you have to do is:
1) Copy somewhere the directory /source/x/x11 of the DVD (or a mirror) of the distribution and cd there
2) Edit the file configure/xorg-server (that is to say, source/x/x11/configure/xorg-server) to add following option:
4) Run following command:
5) Replace the "original" packages by the new ones:
6) Kill X, then stop the HAL daemon and prevent it from starting at next (re)boot:
Then you can start X again or reboot.

WARNINGS
1) Remember that if/when a new xorg-server is released by Pat (for instance following a security advisory) and you still don't want to use HAL, you will have to follow that procedure again.
2) This seems to work here but I didn't make methodical testing.

May be only xorg-server-1.6.3 needs to be modified for all this to work, I don't know.

Happy Slackin!

PS I still don't know why I got these compilation errors on my "real" system but that's another story.

EDIT. This seems to work with as well as without an xorg.conf file and (if HAL is launched) do not prevent auto-mounting of removable devices in XFCE and KDE; may be I could suggest Pat to add the "--disable-config-hal" option in the official xorg-server packages ? What do you think ?

Excellent stuff!

I can't see Pat wanting to go with '--disable-hal' in the stock packages. Though there does seem to be a fair number of us who'd rather not have any hal in our X system, hal is becoming the expected norm. Perhaps he'd be open to having a non-hal alternate package in 'extra' though to save people the effort of recompiling it themselves?

The fact the Xserver as shipped was blowing up when dbus was running but hal wasn't, is clearly a bug. It ought to fallback to non-hal mode gracefully in that situation, but at least now we have a proven workaround. Hopefully recompiling won't be necessary in future versions.

Anyway, good job and thanks for posting the results.

Thanks from me too, for the effort & time put into this.

I agree, it'd be nice to have the option of a NON-Hal Xorg in Slackware /Extra but I would understand if Pat is not open to the idea; it does kinda cause a fork in the road so to speak, in terms of him maintaining two versions of the same package, just because a few of us don't like HAL. Also, at times like bug reporting, it may be looked upon as a 'taint' by which, if we report a bug yet are running non-HAL-Xorg, we may be told to re-test for the bug with the official Xorg (in the same sense of bug reporting on tainted kernels)

Anyhow, nice work!
Once I have my install finalized, I'll be rebuilding X as was described here.

Sasha

Most things doesn't seem to change if one --disable-config-hal in xorg-server: one can still use HAL and if the HAL daemon is launched auto-mounting of removable devices works.

Only caveat AFAIK: in this case any X setting should be made through an /etc/X11/xorg.conf, not an fdi file in /etc/hal as stated in CHANGES_AND_HINTS.TXT

Would someone be eager to look at this issue more thoroughly please do it

Not really a caveat though in this case; I think that's how things _should_ be: X stuff gets configured in xorg.conf. Makes perfect sense (to me anyway)

What we need is another word; if "caveat" = "beware", and beware being the forboding, ominous sort of word that it is, we need a word meaning "be aware"...

Cheers
Sasha

Sasha, I meant caveat as in caveat emptor.

Please forgive my bad English anyway; sixty years old and still trying to learn it

Hopefully with the help of WordNet, available at Slackbuilds.org it will be easier.