Hello,
about the *mandatory* it was a bad expression, I should have said :
'make two new daemons mandatory IF you want to follow the modern-move' :)
Of course the 'hal' useflag is such a gentoo nice thing !
I did the xorg+hal switch, but I forgot that hald make use of dbus
(I would dreamed about Xorg only asking hal advises once at boot instead having
fluxbox honoured by 2 more daemons) anyway, I moved away the xorg.conf and
all works fine now ... except my fonts.
(can I fully get rid of this xorg.conf "Files Section" by putting
the-right-thing in my ~/.xinitrc ? which means how to globally *register*
new fonts for the server by a client)
After some trace :
- /usr/sbin/hald just makes a tiny poll each 15 seconds.
- hald-addon-storage polls my dvd drive each 2 seconds (I should change
that... or remove it (even if that's still less than a simple ipager))
- dbus seems quiet (blessed)
- hald-addon-input is far more expensive : reacts to each key pressed
but not to the mouse moves.
I don't know if it's a kind of wrapper for evdev or if it polls the
/dev/input/event ... uselessly
But, I'll gave those daemons a chance for the moment.
Thank for your influence all
Raph
On Mon, Apr 13, 2009 at 08:34:00PM -0400, Mike Edenfield wrote:
> gibbo...@gmail.com wrote:
>
>> 1) I don't want hal, one more daemon running only to... spot /dev/input/*,
>> from what I understand xf86-input-* does this pretty well. I won't
>> unplug my mouse and so want to keep my xorg simple conf.
>
> Hal does a lot more than just monitor /dev/input for you. It's a
> framework for providing consolidated and consistent access to *all*
> hardware information on your system. Gnome's automounting, for example,
> relies on hal to let it know when a new device was plugged in, what mount
> point its on, what type of device it is, etc. The vendor database of
> FDI files includes information about everything from batteries to power
> management to keyboards to rf kill switches.
>
> And really, how much simpler an xorg.conf can you get than by deleting
> 2/3 of it?
>
>> 2) Anyway, I tried to make use of evdev instead of the *deprecated*
>> mouse and kbd drivers but...
>> 3) evdev without hal replaced well my mouse driver (for the moment I
>> just replaced /dev/input/mice by /dev/input/event2 in the mouse section)
>> 4) for the keyboard it's far less simple : if I switch to evdev, I
>> cannot define the Xkb{Variant,Model,..} in xorg.conf so :
>> stuck with the 'kbd' driver.
>
> There's nothing wrong with continuing to use the old drivers. Nothing
> about hal requires you to switch to evdev... and nothing about evdev
> requires to you use hal :)
>
> The various non-Linux OS's supported by Xorg won't even have the proper
> kernel support for evdev, so the "old" keyboard and mouse drivers will
> probably be around for a long time. They are only "deprecated" in the
> sense that the Linux generic input layer exists at all.
>
>> I believed gentoo users would be more sceptic when it comes to make a
>> new daemon mandatory ;)
>
> Well, it's clearly not *mandatory* because you can just turn it off with
> -hal :)
>
> Having said that, hal is exactly the kind of thing I would expect Gentoo
> users to flock to: its powerful, flexible, extensible, configurable, and
> it's the new cutting-edge stuff from the upstream vendors. Before it
> went offline, the Gentoo wiki was easily the most informative place on
> the web to find information about hal. I would have predicted hal going
> mainsteam on Gentoo years ahead of Red Hat or Debian.
>
> Also, just for the record, hal isn't by any stretch of the imagination a
> "new" daemon. Its been a USE option for Gentoo's gnome-vfs package since
> Gnome 2.8, in 2004.
>
>> (Any advice to use evdev, define a keyboard layout,model,variant without
>> having to install hal and its <con<fi<gu>r>ation>files and daemon ?)
>
> Unless you have a general aversion to using XML for anything (which I
> understand, if tend to disagree with), the FDI syntax is pretty
> straightfoward. That's even without the abundance of sample code that
> ships with hal. You basically need to know two tags: match and merge.
> In this case:
>
> <?xml version="1.0" encoding="UTF-8" ?>
> <deviceinfo>
> <device>
> <match key="info.capabilities" contains="input.keys">
> <merge key="input.x11_driver" type="string">keyboard</merge>
> </match>
> </device>
> </deviceinfo>
>
> goes into /etc/hal/fdi/policy/keyboard_driver_ftw.fdi and restart hal.
> Since hal lets you "merge" arbitrary keys to its database, Xorg will also
> look for any input.x11_options.foo keys, replacing everything that went
> into xorg.conf.
>
> ---Mike
>
