Re: acpivout(4): directly call ws_[gs]et_param

2020-01-24 Thread Patrick Wildt
On Fri, Jan 24, 2020 at 01:04:41AM +0100, Patrick Wildt wrote: > On Thu, Jan 23, 2020 at 11:25:51PM +0100, Mark Kettenis wrote: > > Since acpi_set_brightness() can be called from anywhere, it should really > > use the acpi task queue to do its thing instead of calling AML directly. > > I didn't

Re: acpivout(4): directly call ws_[gs]et_param

2020-01-23 Thread Patrick Wildt
On Thu, Jan 23, 2020 at 11:25:51PM +0100, Mark Kettenis wrote: > Since acpi_set_brightness() can be called from anywhere, it should really > use the acpi task queue to do its thing instead of calling AML directly. I didn't know there's an acpi task queue, so that's awesome! I just saw that

Re: acpivout(4): directly call ws_[gs]et_param

2020-01-23 Thread Mark Kettenis
Patrick Wildt schreef op 2020-01-23 08:26: Hi, this is the second attempt of a diff that prepares acpivout(4) to work with the X395. The previous one broke due to recursive ACPI locking. So apparently we cannot change the brightness using the acpivout(4) ACPI methods. Instead we need to

Re: acpivout(4): directly call ws_[gs]et_param

2020-01-23 Thread Patrick Wildt
On Thu, Jan 23, 2020 at 05:03:01PM -0500, Ted Unangst wrote: > Patrick Wildt wrote: > > acpivout_[gs]et_param don't know if they are being called by itself > > or by someone else. I don't need to grab it again, I just need to > > have it before calling an ACPI method. But when acpivout(4) calls

Re: acpivout(4): directly call ws_[gs]et_param

2020-01-23 Thread Ted Unangst
Patrick Wildt wrote: > acpivout_[gs]et_param don't know if they are being called by itself > or by someone else. I don't need to grab it again, I just need to > have it before calling an ACPI method. But when acpivout(4) calls > itself, it already has it, so taking it again would break it, as

Re: acpivout(4): directly call ws_[gs]et_param

2020-01-23 Thread Patrick Wildt
On Thu, Jan 23, 2020 at 09:51:11AM +0100, Martin Pieuchot wrote: > On 23/01/20(Thu) 08:26, Patrick Wildt wrote: > > Hi, > > > > this is the second attempt of a diff that prepares acpivout(4) to work > > with the X395. The previous one broke due to recursive ACPI locking. > > > > So apparently

Re: acpivout(4): directly call ws_[gs]et_param

2020-01-23 Thread Martin Pieuchot
On 23/01/20(Thu) 08:26, Patrick Wildt wrote: > Hi, > > this is the second attempt of a diff that prepares acpivout(4) to work > with the X395. The previous one broke due to recursive ACPI locking. > > So apparently we cannot change the brightness using the acpivout(4) ACPI > methods. Instead

acpivout(4): directly call ws_[gs]et_param

2020-01-22 Thread Patrick Wildt
Hi, this is the second attempt of a diff that prepares acpivout(4) to work with the X395. The previous one broke due to recursive ACPI locking. So apparently we cannot change the brightness using the acpivout(4) ACPI methods. Instead we need to call amdgpu(4) to change the brightness. But the