On Wednesday 27 June 2012 18:27:37 Daniel Vetter wrote:
On Wed, Jun 27, 2012 at 05:09:02PM +0200, Lekensteyn wrote:
On Wednesday 27 June 2012 17:03:02 Daniel Vetter wrote:
On Tue, Jun 26, 2012 at 11:07:55PM +0200, Daniel Vetter wrote:
On Tue, Jun 26, 2012 at 02:04:00PM -0700, Jesse Barnes wrote:
On Tue, 26 Jun 2012 00:36:24 +0200
Lekensteyn lekensteyn@gmail.com wrote:
This is rather a hack to fix brightness hotkeys on a Clevo laptop. CADL is not used anywhere in the driver code at the moment, but it could be used in BIOS as is the case with the Clevo laptop.
The Clevo B7130 requires the CADL field to contain at least the ID of the LCD device. If this field is empty, the ACPI methods that are called on pressing brightness / display switching hotkeys will not trigger a notification. As a result, it appears as no hotkey has been pressed.
Not ideal, but definitely better than nothing.
Acked-by: Jesse Barnes jbarnes@virtuousgeek.org
Queued for -next, thanks for the patch.
Unfortunately this results in a neat black screen on my ivb zenbook. Until I've figured out what exactly's going on, I have to drop this from -next again. -Daniel
Can you share your acpidump on https://bugs.freedesktop.org/show_bug.cgi?id=45452 ?
Attached. -Daniel
Thank you, I've now written a partial analysis which is available at https://github.com/Lekensteyn/acpi- stuff/blob/HEAD/dsl/Asus_Zenbook_DanielVetter/analysis.txt (note: URL is cut in two parts in this mail, concat them as needed).
Question: can you try disabling the asus-laptop module and try booting again w/ and w/o the CADL patch applied? - Does it boot in both cases? - Do the brightness hotkeys work? - Can you change brightness via /sys/class/backlight?
Can you SSH in it and check the logs? Any ACPI warnings/errors or messages from the asus-laptop module? (or whatever asus module(s) is/are loaded)
Can you also generate dmidecode.txt? (peek in http://lekensteyn.nl/files/get- acpi-info.sh, you do not have to run all of the commands since I already have your acpidump)
Thanks, Peter
On Thu, Jun 28, 2012 at 1:24 AM, Lekensteyn lekensteyn@gmail.com wrote:
Thank you, I've now written a partial analysis which is available at https://github.com/Lekensteyn/acpi- stuff/blob/HEAD/dsl/Asus_Zenbook_DanielVetter/analysis.txt (note: URL is cut in two parts in this mail, concat them as needed).
Question: can you try disabling the asus-laptop module and try booting again w/ and w/o the CADL patch applied?
- Does it boot in both cases?
- Do the brightness hotkeys work?
- Can you change brightness via /sys/class/backlight?
Can you SSH in it and check the logs? Any ACPI warnings/errors or messages from the asus-laptop module? (or whatever asus module(s) is/are loaded)
Can you also generate dmidecode.txt? (peek in http://lekensteyn.nl/files/get- acpi-info.sh, you do not have to run all of the commands since I already have your acpidump)
Ok, because I have an ecrypted root fs I've tried to reload the i915.ko with CADL after booting. Test-results: - asus_wmi.ko doesn't seem to have any effect whatsoever on the endresult. - asus_nb_wmi.ko doesn't load (ENODEV). - brightness-keys (and also sound control) don't work, but controlling the backlight with /sys/class/backlight/acpi_video0/brightness works (if I can turn the panel on somehow, see below). - When loading the i915.ko with the CADL patch the screen went black (like at boot), but with some excessive vt-switching and X restarting I've managed to light it up. Although it is flickery as hell, especially the lower part of the screen. And if the screen is somewhat stable, I just get the upper part of the screen duplicated in the lower part. - dmidecode is attached. - no errors in the logs anywhere (if you ignore some ACPI resource conflicts because ACPI reserves some pch stuff itself, which then conflicts with the native gpio, sensors, whatever drivers).
So I think this might be simply a timing issue that with CADL enabled we expose a pre-existing bug somewhere in our modeset sequence. I'm already chasing two issues on this machine: - edp refuses to light up crtc 1/2, only works after having switched back to crtc 0. - disabled pipes get stuck in the active state once having been used be edp.
I have a feeling that all these issues are related, so I guess until I've tracked down the above the things we won't make much progress with this CADL patch.
Still, if you have any insights or need more dumps/logs from my machine, I'll happily help out.
Cheers, Daniel
On Thu, Jun 28, 2012 at 1:05 PM, Daniel Vetter daniel@ffwll.ch wrote:
- When loading the i915.ko with the CADL patch the screen went black
(like at boot), but with some excessive vt-switching and X restarting I've managed to light it up. Although it is flickery as hell, especially the lower part of the screen. And if the screen is somewhat stable, I just get the upper part of the screen duplicated in the lower part.
Just a small note: Reloading i915.ko without the CADL patch fixes things. No idea how that could happen ... -Daniel
On Thursday 28 June 2012 13:22:02 Daniel Vetter wrote:
On Thu, Jun 28, 2012 at 1:05 PM, Daniel Vetter daniel@ffwll.ch wrote:
- When loading the i915.ko with the CADL patch the screen went black
(like at boot), but with some excessive vt-switching and X restarting I've managed to light it up. Although it is flickery as hell, especially the lower part of the screen. And if the screen is somewhat stable, I just get the upper part of the screen duplicated in the lower part.
Just a small note: Reloading i915.ko without the CADL patch fixes things. No idea how that could happen ... -Daniel
Does CADL gets reinitialised to zeroes on module load? (I think so, but could you verify that by checking the contents of that field after loading the module w/ and w/o the CADL patch?)
Peter
On Thu, Jun 28, 2012 at 01:58:54PM +0200, Lekensteyn wrote:
On Thursday 28 June 2012 13:22:02 Daniel Vetter wrote:
On Thu, Jun 28, 2012 at 1:05 PM, Daniel Vetter daniel@ffwll.ch wrote:
- When loading the i915.ko with the CADL patch the screen went black
(like at boot), but with some excessive vt-switching and X restarting I've managed to light it up. Although it is flickery as hell, especially the lower part of the screen. And if the screen is somewhat stable, I just get the upper part of the screen duplicated in the lower part.
Just a small note: Reloading i915.ko without the CADL patch fixes things. No idea how that could happen ... -Daniel
Does CADL gets reinitialised to zeroes on module load? (I think so, but could you verify that by checking the contents of that field after loading the module w/ and w/o the CADL patch?)
Yeah, the CADL is cleared out again. -Daniel
On Thu, Jun 28, 2012 at 01:05:58PM +0200, Daniel Vetter wrote:
On Thu, Jun 28, 2012 at 1:24 AM, Lekensteyn lekensteyn@gmail.com wrote:
Thank you, I've now written a partial analysis which is available at https://github.com/Lekensteyn/acpi- stuff/blob/HEAD/dsl/Asus_Zenbook_DanielVetter/analysis.txt (note: URL is cut in two parts in this mail, concat them as needed).
Question: can you try disabling the asus-laptop module and try booting again w/ and w/o the CADL patch applied?
- Does it boot in both cases?
- Do the brightness hotkeys work?
- Can you change brightness via /sys/class/backlight?
Can you SSH in it and check the logs? Any ACPI warnings/errors or messages from the asus-laptop module? (or whatever asus module(s) is/are loaded)
Can you also generate dmidecode.txt? (peek in http://lekensteyn.nl/files/get- acpi-info.sh, you do not have to run all of the commands since I already have your acpidump)
Ok, because I have an ecrypted root fs I've tried to reload the i915.ko with CADL after booting. Test-results:
- asus_wmi.ko doesn't seem to have any effect whatsoever on the endresult.
- asus_nb_wmi.ko doesn't load (ENODEV).
- brightness-keys (and also sound control) don't work, but controlling
the backlight with /sys/class/backlight/acpi_video0/brightness works (if I can turn the panel on somehow, see below).
- When loading the i915.ko with the CADL patch the screen went black
(like at boot), but with some excessive vt-switching and X restarting I've managed to light it up. Although it is flickery as hell, especially the lower part of the screen. And if the screen is somewhat stable, I just get the upper part of the screen duplicated in the lower part.
- dmidecode is attached.
- no errors in the logs anywhere (if you ignore some ACPI resource
conflicts because ACPI reserves some pch stuff itself, which then conflicts with the native gpio, sensors, whatever drivers).
So I think this might be simply a timing issue that with CADL enabled we expose a pre-existing bug somewhere in our modeset sequence. I'm already chasing two issues on this machine:
- edp refuses to light up crtc 1/2, only works after having switched
back to crtc 0.
- disabled pipes get stuck in the active state once having been used be edp.
I have a feeling that all these issues are related, so I guess until I've tracked down the above the things we won't make much progress with this CADL patch.
Good news: I've fixed my edp issues (switching crtcs works reliable now and nothing gets stuck in a half-disabled state) and now I don't get a black/flashing screen any more when applying your patch.
Bad news: We need to refactor a big chunk of our driver to properly fix this issue. Which means I can't merge your patch right away :(
Cheers, Daniel
dri-devel@lists.freedesktop.org
-
Daniel Vetter -
Lekensteyn