The editor will be open source, as well as a bulk of the effects plugins - this should be sufficient for 99% users and use-cases. MIT licensed, and I’m happy to donate the code base to Haiku.
However some of the plugins will remain closed source, specifically plugins which deal with 3D geometry import, skeleton animation and anything 3D engine related.
We can have both right? And well, there’s another advantage in libcodec, that we can do the same as libhybris…
Eh well I was thinking VA-API is basically supported across all desktop GPUs in Mesa and via wrapper so is the least path of resistance as well as most bang for your buck development time wise.
The concept of good defaults can apply to developer just as well as it does to users. Will OpenMax/Stagefright work with hardware acceleration down the road, I think it’s questionable. Kinda pointless to support a framework that has very little direct hardware support.
Maybe you have some particular reason for wanting that I don’t follow?
Well, that’s why I am for a kernel switch. All this stuff we could advantage from and it’s just because we keep using our own kernel. Who know, in the meantime things can change. But at least I can build some support, while using it under linux…Haiku will benefit anyway from the infrastructural updates.
Well that’s never gonna happen so what’s the point in arguing it, I’m sure people will help out with your project as well once it takes off though.
Even under Linux though isn’t libstagefright acceleration limited to mostly proprietary mobile hardware, again whats the point of that? I mean unless you want to run Haiku on a tablet with closed poorly written undebuggable drivers… bleh leave that crap to Android/IOS. Most ARM hardware is nothing but unstandardized commodity throwaway junk… which is a crying shame as some of it is pretty impressive power/perf wise.
Edit: apparently I’m a bit off as Mesa supports OpenMax to some degree https://www.x.org/wiki/RadeonFeature/
This also is worth looking at https://trac.ffmpeg.org/wiki/HWAccelIntro looks like support is spotty for all hardware/API combinations.
At some point, perhaps in two or three decades we may have more stuff released. Hopefully.
Well, what can I do? If we had a proprietary radeon driver would you not use it?
Let’s get what we can. Nothing prevents me from using bionic libc.
Again, what you don’t get is that I am interested in studying the technology. Whatever I implement is pure hobby, and I am not promising nothing to anyone. I have at least two use cases for my stuff and that’s enough. Both of them imply running Haiku on ARM…
Again, what you don’t get is that I am interested in studying the technology. Whatever I implement is pure hobby, and I am not promising nothing to anyone. I have at least two use cases for my stuff and that’s enough. Both of them imply running Haiku on ARM…
Yeah I get you, I personally don’t feel ARM is viable but knock yourself out ha! In any case a lot of the stuff you are pushing for is indeed quite interesting. Even running Haiku software on alternate kernels, however bear in mind that one of the major draws for Haiku at least for me is that it is a different kernel.
Also, remember there is x86 tablet hardware out there, and some of it quite good and almost as efficient as ARM… so unless you are going for phone hardware then you have other options too. Take my GPD Win or some of the other Intel Atom based tablets as example…
I keep wondering how the things that matter most to our users is “what is your kernel?” and “which version of gcc do you use?”. These should be irrelevant when selling Haiku, unless you are a kernel hacker or want to write OS code using modern C++ features.
I’m a computer engineer… the average Haiku user isn’t always as average as the potential userbase at large.
I am really convinced the kernel question is mostly apparent. I am just to a point where I am not going to care about the kernel, linux, zircon, BSD…whatever.
That hardware can’t be compared to ARM devices in terms of cost/functionality.
Not sure what you mean by can’t be compared?
The x86 tablets are fast, often have open graphics drivers, are compatible with a wider range of software, and many of them have better input devices (presure sensititivity than comparable ARM devices). You have to be careful in selecting any device lest you get burned but they definitly are comparable.
I mean you are talking about devices in the $200-700 range… right the quality of tablet devices there varies pretty much irrespective of the CPU they have in them. The $200 devices are mostly media consumption devices and you start getting decent features around $400+ even on ARM devices like larger storage and better input. I’m not sure you really even loose out on battery life honestly… running the same software with similar screen size and brightness they’ll have similar runtime. The kicker is that the x86 tablets can run more software, software that is typically not mobile optimised so you can see shorter battery life if you choose to run that software.
I’m just saying that targeting a tablet if it is an ARM tablet essentially means targeting one device or a small group of them, not a platform, whereas all x86 tablets are effectively already supported PCs with tablet hardware attached to them.
But I am already targeting x86 of course. But I have also a number of spare ARM devices around, plus an orange pi that should arrive in the next weeks.