Finding Vendor & Device IDs is fairly easy but time consuming. Most drivers are for specific hardware so that makes it simple. ie: driver looks for particular vendor & device ids. And yes, would be nice if there was an easier way to know hardware supported by OS (from drivers included in image).
The one that has given me trouble is hda driver. This one is not clear cut. Hard to tell what it looks for to load. For hda, would actually have to read & understand the source itself because it is general style driver (it may look for hardware Vendor ID or Codec Vendor or maybe check for hda hardware?). hda did not have any VIA or AMD vendor ids in the source but could still load for these depending on what it checked for. So, I am kinda iffy on hda. Anyone else want to look through that one?
The situation with Intel HDA is that itās a class standard, like VGA or USB storage.
So in theory you write one driver which implements the software side of the standard according to the documentation, and all conforming hardware will work. The Haiku driver roughly follows this approach, its probe function matches any PCI device which has the class information indicating it implements Intel HDA. Thus probably anyone with a modern Intel HDA device (which is most new laptops and desktops) gets this driver selected.
However, the HDA specification itself represents the codec (the bit that actually converts between PCM data and any form of sound output or input connector) as a separately programmed component. It is often the case that additional code is needed for a particular vendorās codec, or for some applications (ie specific models of computer or sound cards) of that codec. The Haiku code includes some examples of such additional code, covering some very popular devices, but it looks rather less than comprehensive. So for some users the outcome is likely that Haikuās driver seems to work, except that no sound comes out (it is playing, but to some unconnected pins deep inside their laptop, not to the speakers), or the volume controls donāt work, or the speakers on their laptop always play sound even with headphones plugged in, that sort of thing.
The codecs have unique hardware identifiers similar to PCI devices, so that the OS need only load driver software for the codecs used in the installed device. e.g. ALSA identifies the codec in this laptop and loads a driver for āsnd-hda-codec-id:14f15051ā a Conexant chip. So if Haiku actually had the new Windows 95 style driver model, this information could have been gathered too. But it might not be that helpful, at a certain point you do have to rely on user feedback on whether it really works. The same Conexant chip that works fine in this laptop might be wired up differently in another model, leaving the microphone non-functional by default.
Well, letās make one step forward: the HW compatibility database itās just the 1st face of the medal, IMHO.
I believe that the correct way to understand if a driver works (correctly or not), is to know any (registered) userās machine(s) config(s), in order to mix-up results.
In this way devs can easily understand (for example) if a driver works with any HW or just paired with others specific peripherals/drivers/biosesā¦
In other words it would be great to have the (whole) community feedback on HW/drivers.
Thanks for the information NoHaikuForMe. I was actually hoping for a simple answer like, hda driver in Haiku currently supports following hardware ā¦
I or someone else will have to read the code to figure it out. At least, I was able to do the rest of them. So, thatās a start to a general driver database.
In other words it would be great to have the (whole) community feedback on HW/drivers.
Instead, developers use a bug tracker to report problems. If a user is having an issue then they will report it, with listdev output if applicable, and developer will follow up with them. ie: if only 5% of users are having issues then you would only want their listdev info for troubleshooting. Developers only look at those having trouble and reporting it and the rest they assume are working well (with OS or program) and do not care about their info.
I get what you are saying, by having everyones HW info, developers could check if drivers work with other systems too (verify working or not working). Then group the not working (drivers) together in separate categories and try to fix the issues. A good idea but with a couple of concerns to think about.
WIth regards to hardware compatibility, how about concentrating more on what doesnāt work. Could a new ābranchā be added to the trac site to report what hardware has problems? We could make a database of hardware, and assign these problems to relevant tickets, or get a developer to take a quick look if nothing similar has been posted yet.
FWIW, people do submit unsupported hardware to the hardware database. Iāve added an extra search parameter to allow searching for supported/unsupported hardware:
You can also enter device IDs in the general search and theyāll get queried.
btw, I just poured through the video card sources for Haiku, and added almost all the supported video cards (doing the last one , the radeon branch). Iāve added all the device IDs and even pictures for the cards. Didnāt take as long as I thoughtā¦ That added about 300 supported video chipsets not including the radeon driver. Iāll publish them when Iām done though. Iāll probably do everything in audio, network and video. Itās a daunting task, but needs to be done.
Now, if someone could find for me (because Iāve looked but canāt find), which cards and device IDs the DVB driver supports, thatād be great!
thx
*edit, also, the network drivers that were imported from FreeBSD donāt show the supported devices or IDs in their sources, or maybe didnāt look hard enoughā¦ anyone know where these are?
*edit2, figured out that you can get the supported network hardware devices from the man pages. you can search for the driver man page here (e.g āalcā just make sure you have FreeBSD 8 selected):
Unfortunately, doing all that you suggest, and scouring the code to see which are commented out or not, would really slow me down. Itās pretty easy for the native drivers, as theyāre mostly listed at the top with the supported drivers. I have seen this, and not added the commented out ones.
Iām just going to do my best, and if I make mistakes, thatās what thereās comments for on the databaseā¦ I wonāt be checking if the drivers exist on the image. That doesnāt mean that they canāt be built separately, and do/or donāt work.
Itās a lot easier to just have the work done, stored on the hardware database, and then unpublish the record when someone comments it doesnāt work, or comments that x driver isnāt on the image. When it is later put on the image, I can just republish it later.
As for BSD drivers; who knows what works/doesnātā¦ Take this FreeBSD driver for example:
I assume because that because we have a wireless stack based on FreeBSD 8, and that the wi driver is in Haikuās tree, that all the PCI drivers listed on that man page *should work under Haiku, and have added them in the databaseā¦ If they donāt, people can leave a comment as was commented above, people want to know what doesnāt work as well. I can just adjust listings to supported or not easily.
Yes, not working or untested with newest Haiku revision. Youāre right that they could work still. Canāt be sure but you may want to include a note saying they are not part of default Haiku image and may or may not work if built. That way people do not expect them to be already present in Haiku.
The PCMCIA & CF cards will not work. Sorry, just saw you mentioned only PCI.
that all the PCI drivers listed on that man page *should work under Haiku, and have added them in the databaseā¦ If they donāt, people can leave a comment as was commented above, people want to know what doesnāt work as well. I can just adjust listings to supported or not easily.
Finished off the wireless networking devicesā¦ I couldnāt find a good list of the supported devices for the ath driver though. ~80 supported devices though. Now back to wired. This is going to be a b!@#$ :-p
Although the search picks these up, if a user is browsing through the networking directory, they wonāt see this unless they read the description. So, I think it may be better to individually list each of those chipsets?
I just wanted to say thanks for looking into this and making driver support more clear. Iāve been following this thread since it started and I think you guys are doing a great job. Granted, I probably should have looked around more and I may have ended up finding the supported hardware page on haikuware myself. However, I think that hardware compatibility is something so important that it should be visible from the haiku project page itself. I think that simply adding a link to the haikuware hardware page on to this page
http://www.haiku-os.org/community
would increase the visibility of this effort. Increased visibility would result in more people getting hardware support information and potentially more people contributing to it.
For hda driver you will actually have to read the source to understand how it works - kinda hard. Better to ask on the mailing list and see if you can get a response from the developer.
Thanks for doing all this work. I know it took lots of time for you to do it.
My only complaint is you list drivers in Haikuās repo (svn) which are not included in the image. People will complain or wonder why their hardware does not work since you say itās supported.
Example (below driver not in image): http://haikuware.com/details/sound-blaster-16
I suggest you include a note to say the driver is not present in the image but available for building & testing separately to make it clear. Regards,
Yes there are more. The audio & video drivers I listed in my previous posts were for drivers present in Haiku image. You can look at those to see which audio & video drivers are actually in the image. What you have to do is download haiku image (ie: vmware image), run it and go into driver directory and look. All drivers (at least for audio, video & network) have symlinks so easy to tell what drivers are available instead of browsing ābinā directory.
SBLIVE (0x0002) /* Creative Labs SoundBlaster Live /
AUDIGY (0x0004) / Creative Labs Audigy and Audigy 2 /
AUDIGY2 (0x0008) / Creative Labs Audigy 2 Value */
PS I included device IDs for audio cards because some use a different chipset and will not work with the driver. For instance, Creative came out with 2 or 3 versions of Live! cards using different chipset - meaning they need a different driver. Thatās why device ID helps to identify chipset used and important to know. Creative did the same with Audigy cards. Used another, lower cost chipset on certain models - require different driver.
Is it just me or are all the laptops listed discontinued by the manufacturer? I am not trying to be rude but has anyone tried installing on more current model laptops?
emuxki driver should not load for AC97 devices (what you have listed) because it is meant for SB Live/Audigy/Audigy2 cards. You can test with one of the listed sound cards to confirm. emuxki should only load for the Creative Lab cards.
For hda & AC97 drivers, I believe they work based on Codec Vendor, not Device IDs but better to ask on mailing list to be certain. ie: general style drivers to work with multiple sound devices from different makers.
I fixed up the emuxki driver and audigy driver listings and added a warning to the sb16 driver.
If someone else could post on the mailing list where to get a list of supported hardware for the HDA audio driver, that would be appreciated. I donāt have an account there.
@mmontalvo - I donāt think it should be necessarily surprising that the listings for laptops are outdated. These days, laptops are outdated/discontinued in three-six months. Most of these laptop listings are contributed by normal users.
