You are not logged in.
I see alot of confusion here, so I'm going to detail this in an announcement, just so everyone knows.
hwd and hwdetect are two entirely different things that just happen to have some letters in common. hwd is not an abbreviation for 'hwdetect'
hwdetect is · part of the 'initscripts' package
· created by tpowa, Archlinux Developer
· enabled by adding MOD_AUTOLOAD="yes" to /etc/rc.conf
· NOT added to the DAEMONS array
hwd is · from the 'lshwd' package
· created by z4ziggy, creator of Archie
· enabled by adding 'hwd' to the DAEMONS array in /etc/rc.conf
Offline
Thanks Phrak. I get confused easily.
I also fall down a lot, but that's neither here nor there.
Offline
Its ok Judd, its all those icy streets in Victoria.
Dusty
Offline
Where's the source for this confusion though? Do you think it's because the installation doc says 'hwd or hwdetect'? Perhaps Phrak's clarification could be added to the installation doc - it's problably the only doc that 99% of Arch users have read.
Offline
an other difference more technical:
hwdetect uses kernel dynamic detection
hwdetect can modules be blacklisted
hwd uses static tables
hwd doesn't support blacklisting
Offline
Good post, phrakture... I've not been confused by it, but I can understand how some users could be.
oz
Offline
one of them should have been named adhd.
arch dynamic hardware detection..
take your riddalin!
"Be conservative in what you send; be liberal in what you accept." -- Postel's Law
"tacos" -- Cactus' Law
"t̥͍͎̪̪͗a̴̻̩͈͚ͨc̠o̩̙͈ͫͅs͙͎̙͊ ͔͇̫̜t͎̳̀a̜̞̗ͩc̗͍͚o̲̯̿s̖̣̤̙͌ ̖̜̈ț̰̫͓ạ̪͖̳c̲͎͕̰̯̃̈o͉ͅs̪ͪ ̜̻̖̜͕" -- -̖͚̫̙̓-̺̠͇ͤ̃ ̜̪̜ͯZ͔̗̭̞ͪA̝͈̙͖̩L͉̠̺͓G̙̞̦͖O̳̗͍
Offline
Where's the source for this confusion though? Do you think it's because the installation doc says 'hwd or hwdetect'? Perhaps Phrak's clarification could be added to the installation doc - it's problably the only doc that 99% of Arch users have read.
I haven't read it
Offline
hwd doesn't support blacklisting
How does hwdetect "blacklist" a device? In hwd, a warning can be added in the pci or usb table.
hwd does:
- device and module description
- X config
- how to config manually
Markku
Offline
How does hwdetect "blacklist" a device?
You specify modules to blacklist in the MOD_BLACKLIST array in rc.conf. Pretty simple.
Offline
AAAH! Then why am I running both?! *removes lshwd*
Offline
AAAH! Then why am I running both?! *removes lshwd*
Don't get me wrong, lshwd and hwd are good tools, but running both on startup is duplicating work. Also, hwdetect is officially supported by arch.
Offline
Don't get me wrong, lshwd and hwd are good tools, but running both on startup is duplicating work. Also, hwdetect is officially supported by arch.
...and ziggy freely admits it is better
Offline
[...and ziggy freely admits it is better
Maybe better as lshwd but not hwd.
Markku
Offline
hwdetect has its pitfalls though, from what I understand it only detects modules that are installed, with a few exceptions.
So if you have a wireless driver that uses a module that's not included, and you do not have it installed, hwdetect will be lost.
imho, if hwdetect cannot find a driver by using the kernel methods first, it should drop back and check the lists. Then it would be near perfect and increase its detection ability substantially.
iphitus
Offline
So if you have a wireless driver that uses a module that's not included, and you do not have it installed, hwdetect will be lost.
iphitus, I don't quite follow. Maybe I'm understanding your meaning wrong, but if you don't have the module for a certain piece of hardware installed on your system, a module-autoloader script obviously can't load it.
Do you mean hwdetect should be robustified so that, if you don't have the module for a certain piece of hardware, it says "Device X needs module Y which hasn't been installed" as it's going along?
Offline
hwdetect has its pitfalls though, from what I understand it only detects modules that are installed, with a few exceptions.
Do you mean modules what are activated in kernel?
What I did when hwd still was using kudza (Red Hat) detect engine and had a poor pcmcia detect, I made a static table containing all pcmcia drivers from the kernel. This was easily done in kernel ver. 2.4.x containing a text file.
To make an addtional static table with all kernel drivers will slow down the speed. How about having a hwdetect-lshwd combined system as an option. This would also allow hwdetect to detect old kernels what currently doesn't do.
Markku
Offline
eg, I have X modem. The driver for that modem isnt installed on my system. If I run hwd, it tells me which driver, so I can install it. hwdetect just doesnt detect the modem. Those tables include the names of drivers that arent actually included in the stock kernel.
Thats what i meant rasat, a combined one, with the tables as a fallback for devices it cannot detect.
hwdetect cant replace hwd without such ability.
Offline
eg, I have X modem. The driver for that modem isnt installed on my system. If I run hwd, it tells me which driver, so I can install it. hwdetect just doesnt detect the modem. Those tables include the names of drivers that arent actually included in the stock kernel.
Thats what i meant rasat, a combined one, with the tables as a fallback for devices it cannot detect.
hwdetect cant replace hwd without such ability.
I disagree. hwdetect's main purpose is to load the modules you need. Adding static tables to hwdetect will slow it down and defeat it's stunning simplicity.
I think the current solution is good enough:
a) look if hwdetect detects everything
b) if something is missing, find out which module you need using lshwd
c) install the module
d) hwdetect will load it now, you're happy and can uninstall lshwd
Offline
There's a compromise here. In the case iphitus states, you have to know that you need a module and install it before it detects it. Let's take for instance the (stupid) case of a user who has a geforce, but doesn't know he needs the 'nvidia' module:
hwd/lshwd is going to report you need 'nvidia', whereas hwdetect will not.
I think this is a good thing. Because of the way hwdetect works, it shouldn't try to modprobe 'nvidia' if it doesn't exist. Using lshwd to find installable modules sounds good to me.
Offline
Just a 'heads up':
Shortly, udev itself will replace hwdetect on boot only using the uevents facility. In this case, referring to using "hwdetect" to load modules on boot will not work.
Henceforth, I suggest that we all refer to it as "MOD_AUTOLOAD":
i.e. "Are you using MOD_AUTOLOAD instead of hotplug?"
That should clear up some of this confusion.
Offline
When i'm doing system upgrade i get prompt to remove hotplug:
pacman -Syu
:: Synchronizing package databases...
current [################] 100% 48K 218.3K/s 00:00:00
extra [################] 100% 228K 475.6K/s 00:00:00
:: udev conflicts with hotplug. Remove hotplug? [Y/n]
But then it says:
pacman -R hotplug
error: this will break the following dependencies:
hotplug: is required by hwd
hotplug: is required by udev
So i'm a little confused. Is it still needed by some part of a system?
Offline
When i'm doing system upgrade i get prompt to remove hotplug:
pacman -Syu
:: Synchronizing package databases...
current [################] 100% 48K 218.3K/s 00:00:00
extra [################] 100% 228K 475.6K/s 00:00:00
:: udev conflicts with hotplug. Remove hotplug? [Y/n]But then it says:
pacman -R hotplug
error: this will break the following dependencies:
hotplug: is required by hwd
hotplug: is required by udevSo i'm a little confused. Is it still needed by some part of a system?
Take a look here to see if this is the same as your problem:
oz
Offline
Take a look here to see if this is the same as your problem:
yeap, that was it. thanx.
Offline