Great to see good progress, as usual.
I have a question. Obviously there are bugs to fix, many of them very important, but do you have time for enhancements, and if so, what are you aiming to do in this regard?
The one thing that is stopping me from putting Haiku onto my main computer is the present inability of the OS to use two screens - something which I find essential. I suspect other people would also like this, and I wonder whether it is on the horizon in the near future, or not.
Thanks.
I’m not sure how familiar you are with open source projects. It works something like this: somebody finds something interesting that they want to do and does it 
. So there will be bugfixes as well as enhancements.
There doesn’t appear to be anybody working on multiple monitor support at the moment, but there definitely is some interest. This ticket nicely explains the current state. From the looks of it, it’s a rather big project, so it will likely be a while before someone starts on it, maybe even years.
Waiting for June report.
Yes, I know that. But Waddlesplash is paid by the project, and is therefore obliged to do what the project decides is important. My question is, do the plans for WS involve looking into this particular item?
And, by extension, are there specific goals for Waddlesplash, or is he choosing to do whatever he thinks is important?
I mean no criticism of WS, or anybody else, but it would be nice to how it works, and who decides what he should do.
No he isn’t. : )
If you wish to express that multiple display should get a hugher priority then upvote the associated ticket.
Currently it’s not really high on the list.
https://dev.haiku-os.org/report/9
He’s not???
Seems a strange sort of contract.
Anybody reading this who wants multiple monitor support is invited to vote up No 18441, which is currently languishing on Page 2.
Waddlesplash is capable of allocating his ressources effectively, what is the point of other poeple making him work on other stuff?
I don’t think this is the place or time to discuss WS’s capabilities, which are not in question.
But speaking generally, it is usual when you employ somebody to tell them what you want them to do.
I’m not sure how much waddlesplash is paid, but it is far below average. It makes sense then, that he is given some leeway to work on what he wants to. Of course, as nephele mentioned, I believe that waddlesplash does prioritize what is helpful to Haiku.
I am sure you are right.
There is a bit more to this.
First, Haiku inc was structured in a way that the people donating money don’t directly influence the direction of the development team. The idea being, this way it is not possible for anyone to “buy” Haiku in this way.
Second, the people running Haiku inc are just some of the developers who have volunteered to keep the accounting up to date and decide on where to spend the money. That is the only thing they get: a bit of extra work. The technical decisions are handled by the development team, taking hints from the discussions here, from the roadmap to R1 (which explains why there is a lot of “just fixing bugs”) and also from the ticket voting system. But, really, largely each of us are free to pick whatever we want on the TODO list.
Waddlesplash still offered a kind of contrast, which you can find here: https://www.freelists.org/post/haiku-inc/Employment-contract-proposal-general-longterm-development
Bugs are in the list before multi-head support (although this is not necessarily in order of priorities). The contract is quite open-ended anyways, and essentially says he will continue to do what he already did for Haiku on his free time.
Yes, apologies for the delay; it should hopefully be out later today.
I pretty much have free reign to prioritize, within reason. The Inc. could make specific requests of me, but has largely chosen not to do so. I try to pay attention to what people generally seem to want or need, though, and a stable and usable system usually tops that list 
This is indeed so, but it’s mostly by choice; I currently work less hours than “full-time.” If I worked a more “normal” amount, I would get paid a more “normal” amount – but then I’d be using up Inc. funds faster, and when they run out I would need to get a different job.
Well, indeed nobody “manages” me in that sense, but I do try to pay attention to what people want, rather than just “what I think is important”, of course.
For app_server specifically, it’s not an area I know a lot about. I also don’t have much use for mutlihead support myself; I have one (large) monitor on my desktop, not multiple ones, and while I could rig up a test setup on bare-metal, it wouldn’t be something that I myself use much, so I would have to pay extra-close attention to detail.
There’s also the problem of drivers. app_server isn’t ready for multihead support, but we also don’t have any drivers that are really capable of it; or at least, that are capable of it with the hardware I have (at least one intel_extreme laptop which works well enough but this driver isn’t ready at all; and a radeon_hd desktop which can’t even use anything but the EFI framebuffer.)
radeon_hd driver is capable to support multiple screens with minor changes. Main problem is a lack of multiple screen support in accelerant API.
or at least, that are capable of it with the hardware
Cheap Radeon GPUs suitable for testing exists.
Yes, but I don’t have any hardware radeon_hd even works on; it crashes app_server for me. Which I am given to understand is a common problem under EFI…
If second screen works after being initialized by UEFI, there is a high chance that framebuffer control will work even without modesetting (modesetting can be turned off to avoid crash). It allows to set pointer to GPU framebuffer memory for each screen and receive frame flipping interrupts.
Also it is possible to setup multiple screens in a virtual machine, for example connect 2 ATI GPUs in QEMU.
Thank you, and others, for explaining how the contract works.
You’re in good company, Waddlesplash. Beethoven had a similar arrangement. His patrons didn’t want him to leave Vienna, so they paid him a salary and he was permitted to compose whatever he wanted.
It should be possible to use the same API as the old Radeon accelerant. This is mainly implemented in the src/add-ons/acceelerant/radeon/multimon.c file. This way of doing things is also supported in screen preferences (src/preferences/screen/multimon.cpp). I do have a machine with a Radeon 7000 card which is supported by this driver, and last time I tried it, dual monitors was working. But this is an old machine I don’t use very often anymore.
What it does is set up a large framebuffer and then configure the two displays to show a part of it. If we had this working, it would be a lot easier to develop the app_server parts, and maybe adjust the API in the process (it was designed to fit with the constraints of also working in BeOS, which introduced some not needed complexity).
Nice, but it is still HW dependent solution for multi-monitor (M’Mon) support.
If you have a CPU embedded Intel Extreme or an Nvidia discrete GPU – you still cannot enjoy M’Mon support on Haiku by default 
I don’t say that who has luck on their side to own a Radeon chip already … do not deserve to serve out, … but it reduces the happy users by HW again - to unlock all SW addons : just as it was in the past.
Yes, certainly I would love to have multiple monitors on my current laptop. But… I was not even able to get clone mode working or switch to the external displays at all. Modern Intel hardware has become a lot more complicated than it was last time I worked on this driver.
I’m just annoyed that people say “multi monitor is not supported”, which is not accurate, and it leads to no one working on it when actually there is some support and some of the drivers may not be far off having a basic working version. Which surely will mean more people will start using it, be annoyed by its imperfections, and improve it.