ACPI problems (implement sleep modes and lid driver)

[skfir]

Hello everybody. Sorry for so many tickets, but on my alfa I have a problem. In the Kernel file I enabled the APM and ACPI. But neither the power button, not closing the lid do nothing. When I close the lid, for example, the screen is still shining and the system doesn't go into the sleep mode.

[tqh]

Haiku don't have sleep-modes yet. Not sure there are any actions at all for lid either. Power button should work, but I think that the alpha was before some important fixes to ACPI.

If you want to test if power button and maybe powerstatus works ok you might want to try a nightly build over at ​http://www.haiku-files.org/

Thanks for testing and reporting bugs. It will make Haiku even better.

[bitigchi]

Proposing bumping priority to something higher. Would this count as a blocker? It wouldn’t make sense to ship a 1.0 release without sleep/lid close functionality.

[tqh]

Closing this as the original problem should be fixed. We have power and sleep button support, we sleep on idle and such.

We do lack other ACPI features, but that is not what this ticket is about.

Open a new ticket to report any problems with newer versions of Haiku.

[waddlesplash]

I don't know what you are referring to. We do support power button press, yes, but we don't do anything on lid close and we certainly don't implement sleep states at all.

[nephele]

We could atleast blank/unblank the screen for lid events.

​https://cgit.haiku-os.org/haiku/tree/src/servers/power/lid_monitor.cpp

[pulkomandy]

On all of my machines the screen turns off when closing the laptop lid. We don't need to do anything special for this to happen, it is handled by the hardware or by ACPI.

The acpi_id driver would be useful if you want to trigger more actions. But that is already tracked by #11227.

So indeed, let's close this old ticket, the work here is done. And let's discuss the next steps (suspend to RAM) in a newer ticket.

[tqh]

I want to note that waddlesplash always does the exact opposite to what I do, always trying to pick arguments, -2 every PR I've done for years. It is not healthy and this is a prime example of this bad behaviour, he did it within 1 minute of me closing this.

[waddlesplash]

I happened to be at my computer and saw the notification come in. I tend to review pretty much all ticket changes these days.

I definitely do not "always do the exact opposite". I don't want to be a "contrarian", but I do want to keep up Haiku's exacting standards of quality. Some of your changes that I have -2'ed in the past were temporary measures. I do it to my own changes, and to other's changes, from time to time.

But it absolutely is not true I have -2'ed every PR of yours, not even close. I can see a few of them which I initially did (and then once comments had been addressed, removed my -2), a number of them which I made no comments on at all, and at least one which I was the one to +2 and merge (aligned-alloc attributes.)

I reopened this ticket because I read your comment, and since we don't have sleep on idle, and we do nothing when the "sleep" button is pressed, I reopened it since I couldn't see how your remarks were correct about what we currently support.

Your work on ACPI over the years has been much needed.

[nephele]

I reopened this ticket because I read your comment, and since we don't have sleep on idle, and we do nothing when the "sleep" button is pressed, I reopened it since I couldn't see how your remarks were correct about what we currently support.

Tbh, in that case I'd always ask for clarification instead of just reverting it. overwriting another developers decision to close the ticket seems rude to me, if it was in error the other developer themselves can reopen it.

[pulkomandy]

This ticket is not really the place to discuss this, but anyways:

tqh is our local ACPI expert, if he says the ticket can be closed, he is probably right and we can assume he knows what he is doing. If you don't understand why he closed the ticket, instead of reopening, you could have simply asked him to clarify why he closed it, to clear the misunderstanding or make sure it wasn't by mistake. It would have saved time and frustration for all 3 of us.

Regarding the -2 tickets, I have a few myself, for changes that I think are of not great consequences and I don't always want to put the energy on getting them in a state where everyone is perfectly happy about them. And, since a -2 is blocking other people until you (the person who put a -2 in the first place) manually remove them, it is perceived as strongly blocking (it is, effectively, a veto to a change). That can be useful in some cases, but for the general discussion between developers, I think we could use -1, or even no vote at all, and do the code review with just comments and trust each other that people won't merge something without solving all comments that they feel are important, and it does not need your personal approval to check that they have done so.

We already had this discussion and I had proposed to change the way the -2 works, but that wasn't accepted either.

[tqh]

No it is not, it is just an example that he did not read the title, the description or anything, or my comment about please open a new one or reached out on IRC. He has done this for years, and without any consequences to him. So for the time being I am just leaving this example as how I do not think any employee of Haiku should be allowed to continue to behave.

[waddlesplash]

I'm sorry, I guess I should have asked you on IRC or responded here before just reopening, nephele is probably correct. I'll do better.

[kallisti5]

tqh is our local ACPI expert, if he says the ticket can be closed, he is probably right and we can assume he knows what he is doing.

While I agree with this in theory, nobody "owns" anything in Haiku. We have subject matter experts which their opinions count higher than others, however that also doesn't place them above explanation of their work or opinions.

We're data driven. If you feel strongly about something, communicate your position. Everyone's time is valuable, but nobody's immune to challenge by other developers.

[pulkomandy]

The keyword is "communicate". If you don't understand why another developer did something, ask them for clarification before undoing the change. That seems not too much to ask, and if we don't do this, we will have "edit wars" instead of constructive discussions.