Performance of future Haiku versions

Hmm perhaps I should dig out the two or three adapters I have they are all ASIX I think but I don’t think I got them to work fully.

Yes, there’s some tickets about ASIX not working so well, but those chips are older and rarer, so I don’t think anyone’s even tried to fix them. (There were a few commits recently, but I don’t know how much they helped.)

I have tablet dock station with USB 3 gigabit Ethernet controller that is working on Haiku.

There are older 100/10 ASIX but there are also newer gigabit ones… they are really cheap regardless on ebay new so not hard to come by… alot of name brand adapters use asix as well without advertising it.

For example;71;112

Yes support is there but a little spotty and as waddlesplash mentioned and I was thinking wifi is also non existant.

I mostly agree with you @cb88, however I do think that something like SwiftShader would be good to have in the meantime while graphics drivers are still being worked on. Last I heard on that front, someone was still exploring porting OpenBSD’s driver stack to Haiku (or something like that).

Well I mean waddlesplash is the only active developer that has mentioned any interests in doing so that I know of but I don’t know if his interest has overcome the fact that it’s a massive effort to do properly :slight_smile: … personally I’m in the camp of make something work first then move to making it pretty… perhaps even an accelerated OSMesa only implementation initially… to divide and conqueror a bit more (granted we already have a gallium3d port so part of that actually is done). Hooking it into the accelerated drivers is probably some work though that could be skipped.

1 Like

Isn’t there still no support for BCM43xx wireless adapters despite FreeBSD 11 having support for them?

There is the list about the currently supported chips:

i was talking about having drivers for video cards, sound cards and other odd hardware on a server. drivers that required system to boot are fine lol

I know that at least for the BCM4313 Haiku doesn’t actually work with it, since that’s the one my netbook uses and it doesn’t even show up in the network settings. With regards to BCM43xx, I personally doubt most (if any) in the series do work at the moment.

The marked line is 4312, an older one which provides only 802.11a btw. 4313’s pciid is 4327.

It does still seem to be working to a certain extent in FBSD 12, which is what Haiku’s network driver stack is based on:

Edit: Would it be possible to use FreeBSD network drivers converted from Windows NDIS ones and load them into Haiku?

Be warned, that the PCIID is not always the same as the BCM product name: in some cases Broadcom mislabelled or mixed the PCIIDs and the BCM product names.

You have probably the BCM4313 which identifies itself as “14e4:4727”, you can check it with listdev or lspci. If that’s right, then this specific model is not supported yet by Haiku, as far as i know, that model handled by “bwn” driver, but currently only the “bwi” is ported.

Hopefully @waddlesplash can comment if porting the driver or using ndis possible for your model.
Afaik other Broadcom versions working.

1 Like

Nevermind why you would ever consider running Haiku as a server anyway… since that isn’t one of the projects goals. Also most of the time you do want all the hardware supported on your sever to… video cards happen to also do compute.

I think he meant only vital drivers to provide in the basic install, so one can pull others trough depot (which doesnt have to be hosted on Haiku).
One can imagine a “hw assistant” program, which analyzes the actual hw and pulls the required drivers (this is not BeOS like, where the system just works ™, but if a basic driver provided by Haiku and an advanced one by the hw vendor in the same time with this uninstalling automatically the other would be possible, but there should be a more seamless way too to accomplish this.

I’ve previously stated that if someone (or more than one) takes care of the Mesa (and maybe also app_server) side of things, I will work on the kernel portions. But nobody has stepped up / is too busy, so I’m not even going to attempt it as such.

I’m thinking he meant that drivers would be stored on disk after download. Downloads would occur only if new hardware is detected. I get what he’s saying. But I get what you’re saying too. It would be a nightmare to implement cleanly. Perhaps that could be put on the Todo after Glass Elevator has exited through the roof.

that’s what i meant a basic drivers to get the system running. once installed a utility program could look what needs to be installed and that’s it. but if it’s too much of a hassle then nevermind ^^;

1 Like

Unfortunately the situation with USB-ECM is not that great. USB6ECM has multiple profiles, one is for native ethernet and that works fine, for example most USB-Ethernet adapters work with this. But USB-ECM also includes an “NDIS” variant, and for this we have no driver (I think it is much more complex), this would be needed for Android phones usb tethering. I think there are other profiels as well but it’s been a while since I looked into that, especially as my current phone can act as a wifi hotspot instead so I didn’t feel the need for the USB way too much :slight_smile: