-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 22/08/15 13:48, Idwer Vollering wrote:
2015-08-22 11:04 GMT+02:00 Francis Rowe info@gluglug.org.uk: Any ideas?
Boot into vendor BIOS/EFI thing, install and start acpi_listen, then press the mute button. http://linux.die.net/man/8/acpi_listen
I tried that just now. I don't see any events in acpi_listen, when I use the mute button. I do see events for the up/down volume buttons.
The mute button does work (only in factory BIOS), but I don't see any events in the OS. The volume in gnome isn't shown muted, either. I think the mute button might be hardware based, while the volume buttons are software (ACPI).
On 22/08/15 14:09, Alexander Couzens wrote:> On Sat, 22 Aug 2015
and take a look on "Interaction with the Embedded Controller" at https://wiki.ubuntu.com/Kernel/Reference/ACPITricksAndTips
you want to know which _QXX function is called. maybe that one is
empty in the coreboot aml for h8s..
Thanks, I'll take a look. It doesn't seem like the mute button is controlled by ACPI, though.
Perhaps I could use ectool (and other utils?) to see what happens when muting.
Thanks, I'll take a look. It doesn't seem like the mute button is controlled by ACPI, though.
Perhaps I could use ectool (and other utils?) to see what happens when muting.
maybe, maybe not. acpi_listen only helps you, when something in the user space is missing. It'll show you what acpi event is generated from acpi code. But when the acpi code is missing, you don't see anything there. Take a look on the ubutun wiki and do the kernel debug thing it's described there.
ectool might show you what's changed, but I would bet, the ec is generating an ACPI query event, which must be handled by _Qxx function.
cheers, lynxis
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I haven't got anywhere yet, but I did notice that factory BIOS defines a table called ECDT, while coreboot doesn't. iasl shows this as being related to the EC. I can see different ectool output (using the -i option) option on different runs, even without changing the mute/unmute status, and also some changes when muting, but I haven't managed to figure it out yet.
Would it help if I include logs here? If so, which logs?
On 22/08/15 16:07, Alexander Couzens wrote:
Thanks, I'll take a look. It doesn't seem like the mute button is controlled by ACPI, though.
Perhaps I could use ectool (and other utils?) to see what happens when muting.
maybe, maybe not. acpi_listen only helps you, when something in the user space is missing. It'll show you what acpi event is generated from acpi code. But when the acpi code is missing, you don't see anything there. Take a look on the ubutun wiki and do the kernel debug thing it's described there.
ectool might show you what's changed, but I would bet, the ec is generating an ACPI query event, which must be handled by _Qxx function.
cheers, lynxis
- -- Minifree Ltd, trading as Ministry of Freedom | Registered in England, No. 9361826 | VAT No. GB202190462 Registered Office: 19 Hilton Road, Canvey Island, Essex SS8 9QA, UK | Tel: +44 (0) 1268 857 837 | Web: http://minifree.org/
Use free software. Use GNU/Linux. https://www.gnu.org/philosophy/free-sw.html
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Would it help if I include logs here? If so, which logs?
ectool will also show some timers, which are counting upwards in the dump. Last time I've looked at the ECDT (x201) it doesn't contain any additional information. There are multiple ways to provide the information saved in the ECDT. Coreboot is using the DSDT for that.
Let's say you know which byte is changing in the EC ram, what would you do than?
Best, lynxis
PS: http://www.coreboot.org/EC:lenovo/x201
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 22/08/15 18:13, Alexander Couzens wrote:
Would it help if I include logs here? If so, which logs?
ectool will also show some timers, which are counting upwards in the dump. Last time I've looked at the ECDT (x201) it doesn't contain any additional information. There are multiple ways to provide the information saved in the ECDT. Coreboot is using the DSDT for that.
Let's say you know which byte is changing in the EC ram, what would you do than?
Best, lynxis
Here is the diff (from factory BIOS):
user@user-ThinkPad-X200:~/Desktop$ diff -u ectool.log ectool.mute.log - --- ectool.log 2015-08-22 16:14:32.602441403 +0100 +++ ectool.mute.log 2015-08-22 16:14:38.780364169 +0100 @@ -2,13 +2,13 @@
00: a6 05 a0 00 fe 96 00 00 1f 02 47 00 00 00 80 00 10: 00 00 ff ff f4 3c 87 09 5b ff 83 04 ff ff 2d 00 - -20: 00 00 00 00 00 00 00 60 00 00 00 00 00 00 00 80 - -30: 07 00 02 00 30 04 00 00 00 00 20 10 00 50 00 00 +20: 00 00 00 00 00 00 00 df 00 00 00 00 00 00 00 80 +30: 47 00 02 00 30 04 00 00 00 00 20 10 00 50 00 00 40: 00 00 00 00 00 00 14 04 40 01 00 00 00 00 00 00 50: 00 c0 02 19 df 07 08 16 0e 0a 31 04 04 d0 07 48 60: 0d d8 0e cc 10 00 00 00 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 12 30 80 27 32 80 2c 80 80 80 80 - -80: 00 00 00 06 ce 0e 03 00 00 00 00 00 00 00 6c 00 +80: 00 00 00 06 e3 0e 03 00 00 00 00 00 00 00 6c 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x27 changes. 0x30 changes. 0x84 changes.
Here is the diff from coreboot (on another X200, though, so probably different EC version):
user@user-ThinkPad-X200:~/Desktop$ diff -u ectool.log ectool.mute.log - --- ectool.log 2015-08-22 17:31:27.684144336 +0100 +++ ectool.mute.log 2015-08-22 17:31:34.775508137 +0100 @@ -2,17 +2,17 @@
00: a6 04 a0 11 fe 96 00 00 1f 02 43 00 00 00 80 00 10: 00 00 ff ff f4 3c 80 01 01 ff ff ff ff ff 00 00 - -20: 00 00 00 00 00 00 00 2b 00 00 00 00 00 00 00 80 - -30: 03 00 00 00 30 04 00 00 00 00 70 10 00 00 00 00 +20: 00 00 00 00 00 00 00 58 00 00 00 00 00 00 00 80 +30: 43 00 00 00 30 04 00 00 00 00 70 10 00 00 00 00 40: 00 00 00 00 00 00 14 04 42 01 00 00 00 00 00 00 50: 00 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 12 30 80 30 2f 80 33 80 80 80 80 - -80: 00 00 00 00 6c 0e 00 00 00 00 00 00 00 00 00 00 +80: 00 00 00 00 6a 0e 00 00 00 00 00 00 00 00 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 - -c0: 33 38 80 80 80 80 80 80 00 41 1a 00 00 00 00 00 +c0: 33 37 80 80 80 80 80 80 00 41 0d 00 00 00 00 00 d0: 06 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 10 60 b9 06 04 2e 55 03 f0: 37 58 48 54 32 34 57 57 13 74 62 b4 13 74 61 9c
0x27 changes. 0x30 changes. 0x84 changes.
Also on this dump, 0xc1 and 0xca change.
I'm not currently sure what to make of this.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Please disregard this thread. from the #coreboot IRC channel:
<francis7> lynxis, hi * redpill has quit (Ping timeout: 264 seconds) * redpill (~redpill@unaffiliated/redpill) has joined #coreboot <lynxis> 0x30 does volumecontrol. I've also written that down in http://www.coreboot.org/EC:lenovo/x201 <francis7> oh <lynxis> try to play with that using ectool -w <> -z <> <francis7> Yes, to see if that changes volume. <lynxis> you can try to read the disassemlbed acpi code. take a look on the dsdt. acpi asm is very easy to read. * siro has quit (Quit: Leaving.) <francis7> lynxis, confirmed <francis7> lynxis, I have this running: <francis7> sudo watch -n .1 ./ectool -i <francis7> When I mute (factory bios), 0x30 changes from 0x03 to 0x43 <francis7> When unmuting, it changes back to 0x03 <lynxis> on x201: it's 0x40 or 0x00 <francis7> The same also happens in coreboot. <francis7> However, on coreboot, no actual muting occurs. <lynxis> x201: the speaker got muted. <francis7> ok, wtf <francis7> I tested it on another X200 with coreboot <francis7> mute works <francis7> wtf <lynxis> francis7: can you send me a dump of the acpi with OEM bios? <francis7> lynxis, "acpidump > acpidump.log" ? <lynxis> acpidump -b dump_dir <francis7> -b outputs nothing <lynxis> it should dump everything into a directory <lynxis> sudo acpidump -b . <francis7> ok now it works <lynxis> francis7: 0x84 should be the fan speed <francis7> seems I already have your GPG key <francis7> (public one) <lynxis> 0xA0DF8604 fp: 390D CF78 8BF9 AA50 4F8F F1E2 C29E 9DA6 A0DF 8604 <francis7> yep * tlaurion (~tlaurion@dsl-154-8.b2b2c.ca) has joined #coreboot <francis7> lynxis, weird though <francis7> the mute didn't seem to work earlier. <francis7> maybe I was only testing it on headphones <francis7> even in factory bios, the mute only mutes the internal speakers built into the laptop <francis7> external speakers/headphones are not muted via that button <francis7> I apologize for wasting your time....
On 22/08/15 18:40, Francis Rowe wrote:
On 22/08/15 18:13, Alexander Couzens wrote:
Would it help if I include logs here? If so, which logs?
ectool will also show some timers, which are counting upwards in the dump. Last time I've looked at the ECDT (x201) it doesn't contain any additional information. There are multiple ways to provide the information saved in the ECDT. Coreboot is using the DSDT for that.
Let's say you know which byte is changing in the EC ram, what would you do than?
Best, lynxis
Here is the diff (from factory BIOS):
user@user-ThinkPad-X200:~/Desktop$ diff -u ectool.log ectool.mute.log --- ectool.log 2015-08-22 16:14:32.602441403 +0100 +++ ectool.mute.log 2015-08-22 16:14:38.780364169 +0100 @@ -2,13 +2,13 @@
00: a6 05 a0 00 fe 96 00 00 1f 02 47 00 00 00 80 00 10: 00 00 ff ff f4 3c 87 09 5b ff 83 04 ff ff 2d 00 -20: 00 00 00 00 00 00 00 60 00 00 00 00 00 00 00 80 -30: 07 00 02 00 30 04 00 00 00 00 20 10 00 50 00 00 +20: 00 00 00 00 00 00 00 df 00 00 00 00 00 00 00 80 +30: 47 00 02 00 30 04 00 00 00 00 20 10 00 50 00 00 40: 00 00 00 00 00 00 14 04 40 01 00 00 00 00 00 00 50: 00 c0 02 19 df 07 08 16 0e 0a 31 04 04 d0 07 48 60: 0d d8 0e cc 10 00 00 00 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 12 30 80 27 32 80 2c 80 80 80 80 -80: 00 00 00 06 ce 0e 03 00 00 00 00 00 00 00 6c 00 +80: 00 00 00 06 e3 0e 03 00 00 00 00 00 00 00 6c 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x27 changes. 0x30 changes. 0x84 changes.
Here is the diff from coreboot (on another X200, though, so probably different EC version):
user@user-ThinkPad-X200:~/Desktop$ diff -u ectool.log ectool.mute.log --- ectool.log 2015-08-22 17:31:27.684144336 +0100 +++ ectool.mute.log 2015-08-22 17:31:34.775508137 +0100 @@ -2,17 +2,17 @@
00: a6 04 a0 11 fe 96 00 00 1f 02 43 00 00 00 80 00 10: 00 00 ff ff f4 3c 80 01 01 ff ff ff ff ff 00 00 -20: 00 00 00 00 00 00 00 2b 00 00 00 00 00 00 00 80 -30: 03 00 00 00 30 04 00 00 00 00 70 10 00 00 00 00 +20: 00 00 00 00 00 00 00 58 00 00 00 00 00 00 00 80 +30: 43 00 00 00 30 04 00 00 00 00 70 10 00 00 00 00 40: 00 00 00 00 00 00 14 04 42 01 00 00 00 00 00 00 50: 00 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 12 30 80 30 2f 80 33 80 80 80 80 -80: 00 00 00 00 6c 0e 00 00 00 00 00 00 00 00 00 00 +80: 00 00 00 00 6a 0e 00 00 00 00 00 00 00 00 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -c0: 33 38 80 80 80 80 80 80 00 41 1a 00 00 00 00 00 +c0: 33 37 80 80 80 80 80 80 00 41 0d 00 00 00 00 00 d0: 06 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 10 60 b9 06 04 2e 55 03 f0: 37 58 48 54 32 34 57 57 13 74 62 b4 13 74 61 9c
0x27 changes. 0x30 changes. 0x84 changes.
Also on this dump, 0xc1 and 0xca change.
I'm not currently sure what to make of this.
- -- Minifree Ltd, trading as Ministry of Freedom | Registered in England, No. 9361826 | VAT No. GB202190462 Registered Office: 19 Hilton Road, Canvey Island, Essex SS8 9QA, UK | Tel: +44 (0) 1268 857 837 | Web: http://minifree.org/
Use free software. Use GNU/Linux. https://www.gnu.org/philosophy/free-sw.html
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
For my future reference: <lynxis> francis7: on x201 it doesn't generate any acpi event. <francis7> on X200 it doesn't, either. <lynxis> francis7: in dsdt, bit 7 of 0x30 is named HMUT <francis7> HMUT = hardware mute? <lynxis> it's bit6, if you count from 0. yes. acpi variables names are limited to 4 bytes. <francis7> lynxis, please assume that I will be counting from the right-most bit (^0) <francis7> and assume that I will count from 0 <francis7> If you say bit 7, I'll think you mean the one that equals 128 or 0x80 when set to 1 <francis7> when really you meant 64 or 0x40 <lynxis> francis7: me too, but I miscounted it this time. please forgive me ;) <francis7> :) <francis7> this is what causes "off by one" errors in programming <lynxis> it was more reading it. because it says 6 bit are empty, nextbit is HMUT
On 22/08/15 19:37, Francis Rowe wrote:
Please disregard this thread. from the #coreboot IRC channel:
<francis7> lynxis, hi * redpill has quit (Ping timeout: 264 seconds) * redpill (~redpill@unaffiliated/redpill) has joined #coreboot <lynxis> 0x30 does volumecontrol. I've also written that down in http://www.coreboot.org/EC:lenovo/x201 <francis7> oh <lynxis> try to play with that using ectool -w <> -z <> <francis7> Yes, to see if that changes volume. <lynxis> you can try to read the disassemlbed acpi code. take a look on the dsdt. acpi asm is very easy to read. * siro has quit (Quit: Leaving.) <francis7> lynxis, confirmed <francis7> lynxis, I have this running: <francis7> sudo watch -n .1 ./ectool -i <francis7> When I mute (factory bios), 0x30 changes from 0x03 to 0x43 <francis7> When unmuting, it changes back to 0x03 <lynxis> on x201: it's 0x40 or 0x00 <francis7> The same also happens in coreboot. <francis7> However, on coreboot, no actual muting occurs. <lynxis> x201: the speaker got muted. <francis7> ok, wtf <francis7> I tested it on another X200 with coreboot <francis7> mute works <francis7> wtf <lynxis> francis7: can you send me a dump of the acpi with OEM bios? <francis7> lynxis, "acpidump > acpidump.log" ? <lynxis> acpidump -b dump_dir <francis7> -b outputs nothing <lynxis> it should dump everything into a directory <lynxis> sudo acpidump -b . <francis7> ok now it works <lynxis> francis7: 0x84 should be the fan speed <francis7> seems I already have your GPG key <francis7> (public one) <lynxis> 0xA0DF8604 fp: 390D CF78 8BF9 AA50 4F8F F1E2 C29E 9DA6 A0DF 8604 <francis7> yep * tlaurion (~tlaurion@dsl-154-8.b2b2c.ca) has joined #coreboot <francis7> lynxis, weird though <francis7> the mute didn't seem to work earlier. <francis7> maybe I was only testing it on headphones <francis7> even in factory bios, the mute only mutes the internal speakers built into the laptop <francis7> external speakers/headphones are not muted via that button <francis7> I apologize for wasting your time....
On 22/08/15 18:40, Francis Rowe wrote:
On 22/08/15 18:13, Alexander Couzens wrote:
Would it help if I include logs here? If so, which logs?
ectool will also show some timers, which are counting upwards in the dump. Last time I've looked at the ECDT (x201) it doesn't contain any additional information. There are multiple ways to provide the information saved in the ECDT. Coreboot is using the DSDT for that.
Let's say you know which byte is changing in the EC ram, what would you do than?
Best, lynxis
Here is the diff (from factory BIOS):
user@user-ThinkPad-X200:~/Desktop$ diff -u ectool.log ectool.mute.log --- ectool.log 2015-08-22 16:14:32.602441403 +0100 +++ ectool.mute.log 2015-08-22 16:14:38.780364169 +0100 @@ -2,13 +2,13 @@
00: a6 05 a0 00 fe 96 00 00 1f 02 47 00 00 00 80 00 10: 00 00 ff ff f4 3c 87 09 5b ff 83 04 ff ff 2d 00 -20: 00 00 00 00 00 00 00 60 00 00 00 00 00 00 00 80 -30: 07 00 02 00 30 04 00 00 00 00 20 10 00 50 00 00 +20: 00 00 00 00 00 00 00 df 00 00 00 00 00 00 00 80 +30: 47 00 02 00 30 04 00 00 00 00 20 10 00 50 00 00 40: 00 00 00 00 00 00 14 04 40 01 00 00 00 00 00 00 50: 00 c0 02 19 df 07 08 16 0e 0a 31 04 04 d0 07 48 60: 0d d8 0e cc 10 00 00 00 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 12 30 80 27 32 80 2c 80 80 80 80 -80: 00 00 00 06 ce 0e 03 00 00 00 00 00 00 00 6c 00 +80: 00 00 00 06 e3 0e 03 00 00 00 00 00 00 00 6c 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x27 changes. 0x30 changes. 0x84 changes.
Here is the diff from coreboot (on another X200, though, so probably different EC version):
user@user-ThinkPad-X200:~/Desktop$ diff -u ectool.log ectool.mute.log --- ectool.log 2015-08-22 17:31:27.684144336 +0100 +++ ectool.mute.log 2015-08-22 17:31:34.775508137 +0100 @@ -2,17 +2,17 @@
00: a6 04 a0 11 fe 96 00 00 1f 02 43 00 00 00 80 00 10: 00 00 ff ff f4 3c 80 01 01 ff ff ff ff ff 00 00 -20: 00 00 00 00 00 00 00 2b 00 00 00 00 00 00 00 80 -30: 03 00 00 00 30 04 00 00 00 00 70 10 00 00 00 00 +20: 00 00 00 00 00 00 00 58 00 00 00 00 00 00 00 80 +30: 43 00 00 00 30 04 00 00 00 00 70 10 00 00 00 00 40: 00 00 00 00 00 00 14 04 42 01 00 00 00 00 00 00 50: 00 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 12 30 80 30 2f 80 33 80 80 80 80 -80: 00 00 00 00 6c 0e 00 00 00 00 00 00 00 00 00 00 +80: 00 00 00 00 6a 0e 00 00 00 00 00 00 00 00 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -c0: 33 38 80 80 80 80 80 80 00 41 1a 00 00 00 00 00 +c0: 33 37 80 80 80 80 80 80 00 41 0d 00 00 00 00 00 d0: 06 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 10 60 b9 06 04 2e 55 03 f0: 37 58 48 54 32 34 57 57 13 74 62 b4 13 74 61 9c
0x27 changes. 0x30 changes. 0x84 changes.
Also on this dump, 0xc1 and 0xca change.
I'm not currently sure what to make of this.
- -- Minifree Ltd, trading as Ministry of Freedom | Registered in England, No. 9361826 | VAT No. GB202190462 Registered Office: 19 Hilton Road, Canvey Island, Essex SS8 9QA, UK | Tel: +44 (0) 1268 857 837 | Web: http://minifree.org/
Use free software. Use GNU/Linux. https://www.gnu.org/philosophy/free-sw.html
-
Alexander Couzens -
Francis Rowe