Sorry, but you simply don’t get to tell me where to put my “development ressources”.
If you care about newer hardware I suggest contributing yourself instead of harassing developers to get newer hardware. I can use whatever I want. If that is somewhat older laptops that work perfectly with Haiku then that is my choice.
This is not a matter of financially capable, I simply didn’t buy a new one by choice. The last “new” Laptop I got lasted about 1.5 years because of the horrible build quality companies nowadays employ. I don’t care for that, if the only option is shitty laptops I won’t buy one. And I definetely won’t throw my perfectly fine laptop away because you thought of some arbitrary number of when you think laptops should be thrown away.
I tried and it doesn’t build. It looks non trivial to fix without learning more about the kernel internals so I didn’t look into any further as I don’t have any more time. It would be nice for these older laptops… I have a few based on eg amd v105 and c50 that run haiku perfectly well but do get rather hot even at idle. I’m happy to test changes if that helps
The cpuidle code was reworked in 2013 but this driver wasn’t adjusted with it, not sure how much work that is to change (also some definitions from acoi changed but those are rather easy)
In addition to that i found references to an intel speedstep driver that was removed, I am not sure if the x86_cpuidle driver is it’s descendant or not though, so that may be worth investigating aswell.
I was the mentor on the cpuidle Google Summer of Code. I don’t think it was based on speedstep driver at all. However the scheduler rewrite changed cpuidle completely so I can’t say much about current code.
I believe we do not support AMD and earlier CPU’s (who had more archaic idle handling) in a good way, but newer AMD chips has probably adapted a bit to Intel handling. I kind of wish someone with an AMD CPU would try to do a more optimal init of their CPU instead of just relying on intel code, there is probably a lot to win there as other OS’es do a lot more…
It is also not enough to have power management on its own, if apps always wakes the CPU it won’t help much.
Here are two examples:
The cpuidle student noted that the network stack and Tracker was waking the CPU a lot.
Network was due to the periodic tick that happens. It turned out that at the time that network had a bug so it ticked at 1 000 000 Hz, but was supposed to tick at 1 000 Hz.
For Tracker (or Deskbar?) I think it was using an older polling API for watching files. The network one I fixed and I am pretty sure I did some work in Tracker / Deskbar to try reduce that problem as well, not sure if that fixed it.
Well, if the first cpuidle code of Haiku was targeted at the first generations of i3,i5,i7, then it’s understandable that support has been onwards and not backwards. Linux and the BSDs (for a comparison) existed and was stable for long, long time when the Pentium M speedsteep mechanisms appeared on the market. In fact, since I think this was the first dynamic clock mechanism for consumer CPUs, probably their cpuidle equivalent was built based on that, then the more nowadays standards of i3,i5,i7 built on top.
