First contact report!

Hello, “new” user here :slight_smile: … I’ve used R5 somewhat in the past, so this feels more like a reencounter than anything. And i’m quite happy to see how everything has evolved. A big thank you to the devs, mantainers and community, Haiku rocks!

This is sort of a follow-up since I’ve installed Haiku nightly 3 weeks ago on my desktop PC, as main (& only) OS. I’m still learning how things work around here, bug reports etc and trying to fix stuff by myself as much as possible. But eventually I’ll need some help.

On this system (HP 6000 SFF, 6Gb RAM, C2Quad 9550) everything stock works: audio, onboard graphics, network etc. Nice! :+1: It has DP&VGA ports, and a GT610 PCIe card w/DVI&HDMI. My monitor only supports the latter so can’t use the Intel IGP ie. no accel for me… chugging along with VESA (and crippled 16:9 resolutions) for now.

HW quirks i’ve found:

  • USB Bluetooth (BCM2035) - finds devices, can’t pair, retrying too much hangs BT service
  • USB mice don’t work on startup, need to unplug-replug for the OS to detect them (all ports)
  • USB HDDs (NTFS) - sloooow transfer rate (mounted RO, never tried mounting RW though)
  • PCIe WiFi (Atheros) - works fine, but doesn’t autoconnect to last AP on startup (is this by design?)
  • PCIe GPU - situation of Nvidia HW on Haiku is well known it seems, nothing to add

On the software side:

  • Web+ was a pleasant surprise. Still not ready for daily use (can’t use it for banking, complex pages etc), but progress since the BeOS days is simply stellar.
  • Dooble is the smoothest & fastest browser RN, albeit stuck at 1.56f- still pondering if wise to get latest source and try compiling that (as a noob to Haiku). Will get back to this. Otter didn’t even last 20mins for me, too slow and fiddly.
  • Personal use-cases covered: productivity (LibreOffice, Krita, LibrePCB); media (VLC, Clementine, smtube); comms (Trojita, Transmission, VNC); and more. All working beautifully.
  • After updating the system, Tracker’ menus break: they show empty, can’t launch apps or reboot etc. Happened 3 times, solved with a forced reboot (ctrl+alt+del * 4 sec)
  • Not a single KDL or instability, the OS/kernel feels uber solid

Aaannd this grew way longer than expected :open_mouth: so that’s it for now. Sorry for the long text and thanks for the marvel that Haiku is. I’ve certainly had more fun with it on this short time, than on years of Win/Linux tinkering… Cheers!


thanks for taking the time for such a detailed review/introduction. I’ll try to answer some of your questions/points. :)

We only have modesetting currently, so even with another output you wouldn’t get 3D acceleration. That beeing said we do have llvmpipe which means you can use opengl, but maybe not as fast.
I don’t think we have modesetting driver for any recent nvidia cards though.

No, in the normal case it should reconnect, this sounds like a bug to me.

Web+, like most of haiku is not a derivative of BeOS code but rather a reimplementation. Web+ is based around the excellent webkit engine that powers safari and epiphany.
There are some improvements to Web+ ready but they will be in beta3.

I think this is a bug caused by updating the system font currently in use, i’d have to check if there is a report open for that.

Bluetooth is unsupported apart from basic pairing and discovering, i.e not ready yet.

The USB mice thing is a bug in any case.


Only pairing implemented, nothing else. It means: no support for mouse, keyboard, audio, etc, and nobody working in this field currently.

NTFS support have performance problems, try to use other FS.

It should connect automatically, but the wifi card and / or the router influences this. Create a bugreport if there is none similar.

Latest one needs QtWebEngine, which is not yet available for Haiku, so help us with that first.

1 Like

Welcome victroniko!

Are you sure? It has never auto-connected after bootup for me (it does auto-re-connect after losing connection, though). I haven’t tried for some time, because I use this line in ~/config/settings/boot/UserBootscript:

ifconfig /dev/net/iprowifi4965/0 join [myrouterSSI] [mypassword]

1 Like

Definetely, it works for me at home, but not really with any other AP.

The wifi auto-connect issue is a known bug according to @waddlesplash

1 Like

Yes, it works perfectly for me as well (on multiple laptops), which is why I could never help to investigate and fix this.

True that. But the intel_extreme accelerant can grab supported resolutions via DDC, whereas AFAIK the VESA one can’t. Depending on the monitor qualities this is more or less of a problem.

Seems about right. For the record I’m using Spanish locale, and also had that “strange fonts problem” too (from the Stargate Atlantis theme). Don’t know if both things could be related.

Will do, but it’s difficult to migrate an 1Tb drive to another FS (not complaining tho, fault’s on me for relying on propietary filesystems). Is exFAT supported?

I’ll test with more routers before reporting to have more precise data.

I’ll take a look.

One thing I forgot: Qt apps using systray icons show a ‘?’ mark instead, that keeps repeating forever after some seconds - eventually cluttering the deskbar. I’m at work now, so when I get home i’ll take a look at bugreports for this and the other things, and file some if none exist already.

Thanks for the welcome :stuck_out_tongue: (and excuse my english if it comes broken here and there, not my native language!).

This is a Haiku Qt bug with tray icons of applications. For the moment you can disable tray icons for Qt applications, or turn off localised folder and application names from Localisation settings.

I don’t think those are related, the Atlantis thingy was related to qt apps that don’t use our font rendering code.
I think the bug is basically that app_server doesn’t cleanly handle that the font that is set as one of the main fonts changes its package, probably because it’s mostly memory mapped to the file. I am unclear as to the specifics because i haven’t investigated this much (seemed more like an edge case to me). Though it does look somewhat bad.

Only read only.

Warning, boring technical details in this post.

Actually, the VESA driver can read the DDC info as well. The problem is, the VESA specification doesn’t offer any way to tell the driver to use a custom video mode. All we get is “driver, please tell us which video modes you can do” and “ok, then I want this one from the list”.

If you are lucky, the manufacturer of your video card makes it so the list it generates contains the native resolution of the display (my desktop PC does this, for example). If you are unlucky, you are restricted to a few specific video modes they decided were enough.

There is a way to improve this, but it has not been implemented in Haiku yet. The idea is that we run the VESA driver inside a small virtual machine because it is designed for running under DOS in real mode. This gives us the opportunity to live-patch the code there to inject the video modes we want. This is tracked in #10570 (Native video mode with VESA through vesa bios live patching) – Haiku , you can upvote that ticket to grab the attention of the developers on it :slight_smile:

It would result in better support for native video modes even with the VESA driver.


Hi folks, still using Haiku as main OS :+1: just not had much time to “toy” with it, only non-critical job related use: email, LibreOffice etc (for the record, yes I know the risks of using beta/dev/unstable software for that).

It’s been uneventful and everything just works, which I guess it’s a good enough compliment.

Pardon me if I’m misunderstanding: Are you affirming the actual VESA driver is a DOS-based one, just inside a wrapper? :open_mouth: or is that an idea for a possible workaround?

VESA provided by the BIOS and you have to be in real mode to use it, but real mode doesnt supports virtual memory besides other things.
The solution is to run a minimal virtual machine and run the code. This is the v86 mode.

The vesa driver is not DOS based, but VESA was developed with DOS in mind back then, so Haiku have to interface with it like DOS would do.

It’s not DOS based, but it’s BIOS based. That’s how VESA works. All operating systems using VESA have to do the same.

This is solved with UEFI, which introduces a new way to set the video mode. However, they made it impossible to change the video mode after the system has booted. Which I guess makes some sense, nowadays you will only want to use the native video mode of your diplay? We’re not in the days of CRT screens where the display would work fine at different resolutions, technology has changed

I am surely stupid, but i never understood, why modeswitching required (if modeswitching required for refresh-rate / color depth change, that part is clear, but not the resolution change part).

I would drive the display always in native resolution, and never let any program change res. Thats ugly. The screen goes blank / black, then comes up with a new res. This needs some hw orchestration/support, but i never really seen the reason why cant an OS give a drawing plane in the requested size/resolution for the program which want to use non-native res, and then just project this plane to a plane with native resolution and just show this result.

Yes, it will make things ugly if the pixels doesn’t match, but that will happen with modeswitching too (the hw can play some tricks to make the result aesthetically more pleasing, but one can do that in SW too, like scaling a bit and moving off center for better match with the physical pixels).
Am i really on the wrong path with this?

I just really dislike when i port some SDL game, try to test it, and the first thing it does is switching the desktop resolution and after exit it fails to restore the native one. Yep, SDL should be fixed, but the question is: can’t this solved more elegantly?
Alt-Tabbing from a game is also can be funky, huge icons, windows outside of the viewable area, etc).

I don’t know about any OS which does what i described. OSX doing something like this, but AFAIK they doing not really this.

You are correct on modern systems. This is a leftover of CRT screens where there wasn’t really a native resolution.

Also, having the OS do the scaling in software will be slower and less energy efficient than having the hardware doing it. Hardly noticeable if you do the scaling using the GPU, but in Haiku we don’t have that luxury yet.

But is this true? The hole matrix defined a resolution on CRT too AFAIK.

No, not really. It never matched exactly with pixels. This gives some free hardware antialiasing, and moire patterns.

Just look at closeup of CRT displays and you will see that the hole matrix isn’t even in lines:

On TVs it is in vertical lines, but not in horizontal lines. This masks the low resolution and interlacing a little. On PC displays it is even more strange, the hole matrix uses round holes and the “pixels” are almost triangular. I think it was done this way to better smooth out very sharp images.

This page shows what happens on a TV type display when you try to display text: Amstrad CPC - Technique graphique (8-le subpixel)

You can see that a 7 px wide letter ends up using 10 columns, and that the colors aren’t even properly aligned with each other in this case. I hope PC displays did a bit better but I don’t have time to look for pictures of similar experiments right now.


Thank you for the detailed explanation. This is just a simulacrum then, where we handle and drive square pixel based displays as a CRT.

But we could say in 2021 all of this is the past and should not considered important anymore with UHD displays around, right? So every technology, every solution and every workaround which based on the listed physical aspects / limitations of the CRT screens should be ditched and never take them into consideration, am i right?

1 Like