1 |
On 2/8/2010 5:20 PM, Alan Mackenzie wrote: |
2 |
|
3 |
> . Am I the only person that finds this semantic gibberish? Is there |
4 |
> any explanation somewhere of what a "policy" aka "device rule" is? What |
5 |
> is the semantic significance of a "device rule"? What does it mean, to |
6 |
> "rule a device", or what sort of restrictions are being placed on this |
7 |
> device? |
8 |
|
9 |
> Given that one might desire a "basic working keyboard/mouse |
10 |
> combination", what is the chain of reasoning that ends up selecting the |
11 |
> file called "10-input-policy.fdi" from all the other ones? |
12 |
|
13 |
> This file is an inpenetrable stanza of uncommented XML. Are its verbs |
14 |
> documented somewhere? What do "<match ...>" and"<append ....>" mean, |
15 |
> for example? |
16 |
|
17 |
The way HAL works, in a nutshell, is to scan your system for |
18 |
every known piece of hardware it can find, and stores the |
19 |
information in a tree-like database of key/value pairs. |
20 |
Software can then query this database for information about |
21 |
whatever hardware you have. The information includes things |
22 |
like the bus location of the hardware, the manufacturer |
23 |
information, state information, and a lists of known |
24 |
capabilities like "keyboard", "mouse", "disk", etc. |
25 |
|
26 |
Device Rules are simply ways for the user to change values |
27 |
in the database after a device has been detected. The XML |
28 |
files work in two steps: |
29 |
|
30 |
1. <match> an existing node in the database, |
31 |
2. <append> or <merge new values into those nodes. |
32 |
|
33 |
For example, the hplip printer/scanner drivers include a set |
34 |
of HAL rules that match HP devices by their PCI device |
35 |
information, then append "scanner" to their list of |
36 |
capabilities. Other software can then scan the HAL database |
37 |
for "all scanners" and find them. The synaptics touchpad |
38 |
driver (if you build it +hal) includes a set of HAL rules |
39 |
that overrides the standard 'mouse' rules to make your |
40 |
touchpad more useful. |
41 |
|
42 |
That bit about you having to do anything to make a "basic |
43 |
working" setup function, though, is wrong. On Gentoo, at |
44 |
least, everything you need for a working keyboard and mouse |
45 |
in X should be installed properly for you by default. You'd |
46 |
only need to mess with the rules if something didn't work. |
47 |
But, see below. |
48 |
|
49 |
> Can this new-style fragmented XML configuration do anything that a good |
50 |
> old-fashioned, human-readable and compact xorg.conf can't? If so, what? |
51 |
> What am I missing here? |
52 |
|
53 |
HAL manages a *lot* more than just your X configuration. |
54 |
It's intended to be a complete hardware management layer, |
55 |
one that was able to keep pace with new hardware more |
56 |
quickly than the kernel could. If you run the HAL database |
57 |
dump utility "lshal" you'll see more information about your |
58 |
hardware than you could ever possible care to know. |
59 |
|
60 |
> Please, somebody, tell me all this HAL stuff is straightforwardly |
61 |
> explained in an easily accessible Gentoo document, so that I can hang my |
62 |
> head in shame and apologise for the noise! ;-) |
63 |
|
64 |
Oddly enough, the most complete explanation of HAL I've ever |
65 |
found was on the Gentoo wiki and I think the page may be |
66 |
lost. It was never really documented that well, though |
67 |
there are a number of places you can find specific ways to |
68 |
do specific things (like using a touchpad) with HAL. |
69 |
|
70 |
The key point here, though, is that HAL is going away. Not |
71 |
because it was hard to configure, though -- because the code |
72 |
is an "unmaintainable mess" and because other software, like |
73 |
udev, duplicated much of its purpose. |
74 |
|
75 |
At this point, if it's not working for you out of the box, |
76 |
turn it back off and revert to the old style configuration file. |