P650RS Support possible? about init-headphone HOT 27 CLOSED

Have you already tried if init-headphone works?
If it doesn't please run it with the --verbose argument and post the output here.
Do you have Windows installed?

from init-headphone.

Atm i dont have Windows installed.
I checked plug presents like described here https://pappp.net/?p=1499

I installed the package via alien as rpm package, in additional
python-smbus (3.1.1-1)
libi2c-dev (3.1.1-1)

acpi_enforce_resources=lax is set
Loaded modprobe i2c-dev

Verbose output
INFO:root:Version: 0.10
DEBUG:root:Available i2c busses: ['SMBus I801 adapter at f000', 'NVIDIA i2c adapter 1 at 1:00.0', 'NVIDIA i2c adapter 2 at 1:00.0', 'NVIDIA i2c adapter 6 at 1:00.0', 'NVIDIA i2c adapter 7 at 1:00.0', 'NVIDIA i2c adapter 8 at 1:00.0', 'NVIDIA i2c adapter 9 at 1:00.0']
DEBUG:root:Supported i2c bus names: ['SMBus I801 adapter']
DEBUG:root:Selected i2c bus: SMBus I801 adapter at f000
INFO:SMBus:Opening I2C bus: /dev/i2c-0
INFO:SMBus:Setting I2C slave address: 115
INFO:SMBus:Writing byte data on I2C bus: (device_cmd: 0xa, value: 0x41)
ERROR:SMBus:Can't transfer data on I2C bus
INFO:SMBus:Closing I2C bus
ERROR:root:Operation failed
DEBUG:root:Exception occurred:
Traceback (most recent call last):
File "/usr/sbin/init-headphone", line 315, in
main()
File "/usr/sbin/init-headphone", line 301, in main
init()
File "/usr/sbin/init-headphone", line 236, in init
set_effect(DEFAULT_EFFECT)
File "/usr/sbin/init-headphone", line 252, in set_effect
DATA_ENABLE_OUTPUT)
File "/usr/sbin/init-headphone", line 228, in write_data_to_device
prolog(i2c_bus)
File "/usr/sbin/init-headphone", line 218, in prolog
i2c_bus.write_byte_data(0x0a, 0x41)
File "/usr/sbin/init-headphone", line 131, in write_byte_data
self.__access(I2C_SMBUS_WRITE, device_cmd, I2C_SMBUS_BYTE_DATA, data)
File "/usr/sbin/init-headphone", line 125, in __access
raise RuntimeError("Can't transfer data on I2C bus")
RuntimeError: Can't transfer data on I2C bus

maybe it helps
i2cdetect -y 0
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- 08 -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

70: -- -- -- -- -- -- -- --

My alsa-info log
http://www.alsa-project.org/db/?f=503e1aec4252f390f2ffc75657e86c82fa36f473

Thx a lot

from init-headphone.

Can you try the latest file from master: https://raw.githubusercontent.com/Unrud/init-headphone/master/src/init-headphone
Just download it and start it with sudo python init-headphone --verbose

I installed the package via alien as rpm package, in additional
python-smbus (3.1.1-1)
libi2c-dev (3.1.1-1)

Deb-packages are available: https://github.com/Unrud/init-headphone-ubuntu

from init-headphone.

sudo python ./init-headphone --verbose

INFO:Version: 0.12
INFO:Trying to add module to the kernel: i2c_dev
INFO:Trying to add module to the kernel: i2c_i801
DEBUG:Available i2c busses: ['SMBus I801 adapter at f000', 'NVIDIA i2c adapter 1 at 1:00.0', 'NVIDIA i2c adapter 2 at 1:00.0', 'NVIDIA i2c adapter 6 at 1:00.0', 'NVIDIA i2c adapter 7 at 1:00.0', 'NVIDIA i2c adapter 8 at 1:00.0', 'NVIDIA i2c adapter 9 at 1:00.0']
DEBUG:Supported i2c bus names: ['SMBus I801 adapter']
DEBUG:Selected i2c bus: SMBus I801 adapter at f000
INFO:Opening I2C bus: /dev/i2c-0
INFO:Setting I2C slave address: 115
INFO:Writing byte data on I2C bus: (device_cmd: 0xa, value: 0x41)
ERROR:Can't transfer data on I2C bus
INFO:Closing I2C bus
ERROR:Operation failed
DEBUG:Exception occurred:
Traceback (most recent call last):
File "./init-headphone", line 351, in
main()
File "./init-headphone", line 309, in main
init()
File "./init-headphone", line 241, in init
set_effect(DEFAULT_EFFECT)
File "./init-headphone", line 257, in set_effect
DATA_ENABLE_OUTPUT)
File "./init-headphone", line 235, in write_data_to_device
write_prolog(i2c_bus)
File "./init-headphone", line 226, in write_prolog
i2c_bus.write_byte_data(0x0a, 0x41)
File "./init-headphone", line 143, in write_byte_data
self.__access(I2C_SMBUS_WRITE, device_cmd, I2C_SMBUS_BYTE_DATA, data)
File "./init-headphone", line 135, in __access
raise OSError(err, os.strerror(err))
OSError: [Errno -1] Unknown error -1

Unfortunately Ubuntu Xenial deb didnt install properly with Stretch

sudo dpkg -i ./init-headphone_0.11.0-xenial_all.deb
(Reading database ... 120579 files and directories currently installed.)
Preparing to unpack .../init-headphone_0.11.0-xenial_all.deb ...
Unpacking init-headphone (0.11.0) over (0.11.0) ...
Setting up init-headphone (0.11.0) ...
update-grub is /usr/sbin/update-grub
Generating grub configuration file ...
Found background image: /usr/share/images/desktop-base/desktop-grub.png
Found linux image: /boot/vmlinuz-4.7.0-1-amd64
Found initrd image: /boot/initrd.img-4.7.0-1-amd64
Adding boot menu entry for EFI firmware configuration
done
Job for init-headphone.service failed because the control process exited with error code.
See "systemctl status init-headphone.service" and "journalctl -xe" for details.
invoke-rc.d: initscript init-headphone, action "start" failed.
● init-headphone.service - Initialize headphone amplifier found in some Clevo laptops
Loaded: loaded (/lib/systemd/system/init-headphone.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Sun 2016-10-30 20:09:44 CET; 4ms ago
Process: 5516 ExecStart=/usr/sbin/init-headphone (code=exited, status=1/FAILURE)
Main PID: 5516 (code=exited, status=1/FAILURE)

Oct 30 20:09:44 shuttle systemd[1]: Starting Initialize headphone amplifier found in some Clevo laptops...
Oct 30 20:09:44 shuttle init-headphone[5516]: ERROR:SMBus:Can't transfer data on I2C bus
Oct 30 20:09:44 shuttle init-headphone[5516]: ERROR:root:Operation failed
Oct 30 20:09:44 shuttle systemd[1]: init-headphone.service: Main process exited, code=exited, status=1/FAILURE
Oct 30 20:09:44 shuttle systemd[1]: Failed to start Initialize headphone amplifier found in some Clevo laptops.
Oct 30 20:09:44 shuttle systemd[1]: init-headphone.service: Unit entered failed state.
Oct 30 20:09:44 shuttle systemd[1]: init-headphone.service: Failed with result 'exit-code'.
dpkg: error processing package init-headphone (--install):
subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
init-headphone

from init-headphone.

maybe it helps
i2cdetect -y 0

That's strange, looks like this on my system:

     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- 08 -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
40: -- -- -- -- 44 -- -- -- -- -- -- -- -- -- -- -- 
50: 50 -- 52 -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- 73 -- -- -- -- 

0x73 is the headphone amplifier. No surprise that it doesn't work.

Please check the output of dmesg | grep -i i801.

Can you test init-headphone and i2cdetect with a Ubuntu 16.10 Desktop (64-bit) live image?

Unfortunately Ubuntu Xenial deb didnt install properly with Stretch

The installation fails because the systemd service doesn't start. The reason for this is just that init-headphone returns a non-zero exit code.

Atm i dont have Windows installed.

The Windows driver consists of a kernel space component SvThANSP.sys and a user space component hp.dll.
The kernel driver is simple and only supports a few commands that allow access to I/O ports. (e.g. Read Byte, Write Byte, Enumerate PCI device).
hp.dll communicates via the device file \.\SvANSPDo with the driver and uses it to directly talk to the SMBUS controller (to which the headphone amplifier is connected).
hp.dll exports the functions InitHeadphone(), Set_Mute(bool) and Set_effect(int) to control the headphone amplifier.

Steps to figure out what the Windows driver does:

1. Load hp.dll in a debugger, hook DeviceIoControl and call the exported functions.

2. Write the argument dwIoControlCode and the contents of the buffer lpInBuffer into a file everytime DeviceIoControl gets called. (This needs to be automatized, the function gets called a lot.)

3. The dwIoControlCode for reading a byte is 0x9C4024D0 and for writing a byte is 0x9C4024C4.
   lpInBuffer / lpOutBuffer looks something like:

   struct {
       int address,       // only lower word is used
       int data_read_out, // only lower byte is used
       int data_write_in  // only lower byte is used
   }

   The dwIoControlCode for PCI device enumeration is 0x9C402494. This reads a word from the register pcireg of the specified PCI device. The Windows driver only uses this to find the SMBus controller.
   lpInBuffer / lpOutBuffer looks something like:

   struct {
       int bus,
       int device,
       int func,
       int pcireg,
       int result_out,
       int unused
   }

4. You can find a description of the SMBus controller in the chipset datasheet. Only the following register are relevant:

   • Transmit Slave Address Register: Bit 0 indicates direction, the other 7 Bits are the device address (Offset: 0x4)
   • Host Command Register: Command (Offset: 0x3)
   • Host Data 0 Register: Data (Offset: 0x5)

I've used Immunity Debugger with a simple Python script to hook DeviceIoControl and write the arguments and buffer to a file.

I tested the driver for P650RS on my system. SvThANSP.sys is the same as for all other Clevo laptops but hp.dll is different. Unfortunately it just queried the Host Status Register of the SMBus controller in an endless loop. (??)

from init-headphone.

Atm i dont have Windows installed.

It's also possible to run the Windows driver in Wine.

from init-headphone.

Please check the output of dmesg | grep -i i801.

dmesg | grep -i i801
[ 9.030672] i801_smbus 0000:00:1f.4: SMBus using PCI interrupt

I have tested ubuntu 16.10 but it didnt find anything,
dmesg | grep -i i801 nothing
i2cdetect -y 0 all --
i will do a fresh install tomorrow or so, i think its a problem with the live environment (boot parameter set)

I've also installed Win10 on a USB Drive and the headphone jack runs out of the box. So its not broken, my 600 Ohm headphones sounds great, yeah. Out of the box there is no hp.dll. I installed the driver from DVD (Control Center and Audio) and there is a hp.dll.

I will try windows driver research later, totally new terrain....

Btw i got a Intel 100 PCH, but i think there are no big differences, or?

from init-headphone.

I have tested ubuntu 16.10 but it didnt find anything,
dmesg | grep -i i801 nothing
i2cdetect -y 0 all --

As long as the i2c driver is not working, init-headphone can't work. Maybe your chipset is not (yet) correctly supported by i2c_i801.

i think its a problem with the live environment (boot parameter set)

It should work without the boot parameter. You don't have to install it.

I will try windows driver research later, totally new terrain....

As mentioned before we can try to run hp.dll in Wine. It talks directly to the SMBus controller without an intermediate driver. I wrote a debugger that intercepts calls to DeviceIoControl and emulates the Windows kernel driver.

from init-headphone.

I've uploaded the tools for running hp.dll in Wine and analyzing on Windows: https://github.com/Unrud/init-headphone-tools

from init-headphone.

It takes a bit but i get some results, i logged console output's too and i really hope i got the right one

debugger.txt
emulator.txt
io.txt

[ Edit - deleted ]

I also tried Kernel Debian 4.8.5-1 (2016-10-28) x86_64 GNU/Linux (unstable)

from init-headphone.

i logged console output's too and i really hope i got the right one

Looks ok.

0xf000 is the base address of the SMBus controller.

In;f000;0   # Device is ready
In;f000;40  # Device is ready and INUSE bit is set
Out;f004;e6 # Write to address 0x73
Out;f003;a  # Command 0xa
Out;f005;41 # Data0 0x41
Out;f006;0  # Data1 0x0
Out;f000;bf # Clear all status bits except INUSE
Out;f002;48 # Execute command "Byte Data"
In;f000;44  # Operation failed
In;f000;44  # Repeat the request 200x because why not
...
Out;f000;bf # Clear all status bits except INUSE
In;f000;40  # Device is ready and INUSE bit is set
Out;f000;ff # Clear all status bits
Out;f000;ff # Again
Out;f000;ff # And again

In conclusion the Windows driver doesn't work, it just tries to send data to a non-existent device.
Maybe your laptop doesn't have the headphone amplifier and the audio is not working for some other reason.

I've also installed Win10 on a USB Drive and the headphone jack runs out of the box.

It should not work out-of-the-box on Windows. The headphone jack should stop working after suspend.

Out of the box there is no hp.dll. I installed the driver from DVD (Control Center and Audio) and there is a hp.dll.

They probably included the driver by mistake.

from init-headphone.

Can I request this issue to be re-opened? I have a Prostar P670RS-G (Clevo P65_67RSRP), and I have the same issue. P650RS and this machine are very closely related (can run same bios and EC firmware with some tweaks) I have the debugging output from running in Windows 10 x64 Enterprise Insider Preview Edition (running 32 bit python etc.) - I do have the hotkey/clevo center app running during this time, I would guess that might affect things since it probably has the headphone amp initialized already, so I tested with headphones both plugged in and unplugged, I can also remote hotkey/clevo center and test with just driver/hp.dll if needed.

Note that all my other output from various commands is the same as reported above. Additionally, if i2cdetect is run a second time, the 0x08 returned at offset 0x08 is then reported as 0x00 each additional time time it's run.

Is there a windows utility to read i2c values like i2cdetect? So we can see if there is some issue with the linux driver for i2c.. does rwanything work? For completeness, here is the output from i2cdetect run consecutively:

daglaptop cinnamon # i2cdetect -y 0
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- 08 -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
daglaptop cinnamon # i2cdetect -y 0
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --

Debugging output below:
init unplugged
Caller;hDevice;dwIoControlCode;lpInBuffer;nInBufferSize;lpOutBuffer;nOutBufferSize;lpBytesReturned;lpOverlapped;inBuffer;bytesReturned;outBuffer; 21d8;d4;390008;0;0;104f0fc;30;104f0c8;0;;30;2e 74 61 d0 43 1a f3 92 38 ca 1e db 68 62 9b f1 a4 13 f9 18 03 92 d4 b7 29 af 3a f7 3c 28 9a 94 a6 c3 69 83 a7 15 c4 c4 b3 83 0f 21 e5 2a 3c d0

init plugged in
Caller;hDevice;dwIoControlCode;lpInBuffer;nInBufferSize;lpOutBuffer;nOutBufferSize;lpBytesReturned;lpOverlapped;inBuffer;bytesReturned;outBuffer; 1c20;e0;390008;0;0;fef324;30;fef2f0;0;;30;d8 72 b3 ce ad 6f 7d 95 aa 23 84 d0 ba 45 68 c7 94 92 e3 80 09 d1 b3 3a b6 8d b2 22 75 a1 50 e0 b1 29 20 f4 e4 84 98 31 c1 68 5a 0b b1 a3 8b e3

set effect 1 (oops, i forgot to do 0)
Caller;hDevice;dwIoControlCode;lpInBuffer;nInBufferSize;lpOutBuffer;nOutBufferSize;lpBytesReturned;lpOverlapped;inBuffer;bytesReturned;outBuffer; 41c4;d0;390008;0;0;124f694;30;124f660;0;;30;8b ef 97 09 8a 23 be f0 ae 61 b3 16 fb c0 a1 f4 49 e1 05 2f 3d 2a a6 b9 0c d4 ec 74 54 0f 5d 62 9d 4b e9 86 2f ec b4 33 e7 fa 54 d7 3c 50 a5 b6

set effect 2
Caller;hDevice;dwIoControlCode;lpInBuffer;nInBufferSize;lpOutBuffer;nOutBufferSize;lpBytesReturned;lpOverlapped;inBuffer;bytesReturned;outBuffer; e58;c0;390008;0;0;64f484;30;64f450;0;;30;83 b5 0c fc 5b 2f ce 92 79 82 e2 07 b0 2d 1d d0 ed 2a 50 94 9d e4 03 6e 19 0e ba 4a 98 b4 28 62 5f 1c dc fc 31 f4 db a0 e4 b3 37 e4 37 9c 80 27

set effect 3
Caller;hDevice;dwIoControlCode;lpInBuffer;nInBufferSize;lpOutBuffer;nOutBufferSize;lpBytesReturned;lpOverlapped;inBuffer;bytesReturned;outBuffer; 272c;dc;390008;0;0;c5f654;30;c5f620;0;;30;57 c2 78 42 a6 de 6b 2a 3a 3d f5 00 56 c9 5d c6 a3 ca 7e f8 c1 38 92 7e 76 da ec a7 dd 80 2e 28 b7 1c 50 4b 08 93 c9 65 04 20 44 c9 4e c4 b7 dc

set effect 4
Caller;hDevice;dwIoControlCode;lpInBuffer;nInBufferSize;lpOutBuffer;nOutBufferSize;lpBytesReturned;lpOverlapped;inBuffer;bytesReturned;outBuffer; 1154;c4;390008;0;0;84f584;30;84f550;0;;30;35 e1 a6 40 98 55 b2 1f 21 83 b8 46 85 13 21 08 81 05 35 be ea 96 94 17 3c 61 0d d2 94 20 28 59 ff d3 1a cb 11 b7 8c 2e d4 06 05 88 93 5a 18 da

set effect 5
Caller;hDevice;dwIoControlCode;lpInBuffer;nInBufferSize;lpOutBuffer;nOutBufferSize;lpBytesReturned;lpOverlapped;inBuffer;bytesReturned;outBuffer; 618;ec;390008;0;0;13ef59c;30;13ef568;0;;30;5e d0 80 8b c1 5e fd eb 03 bb 21 ed c9 b6 ac 87 bd 5a f7 20 9f bb f2 a1 bb 22 af 27 3c b8 a6 dc ce 9d cc 47 c3 2b e7 5d ff dd c4 1f b5 3a 3d 27

set effect 6
Caller;hDevice;dwIoControlCode;lpInBuffer;nInBufferSize;lpOutBuffer;nOutBufferSize;lpBytesReturned;lpOverlapped;inBuffer;bytesReturned;outBuffer; 109c;c8;390008;0;0;9ef594;30;9ef560;0;;30;14 a7 e9 a9 16 99 ae 60 83 9a ee f3 16 a6 a1 52 47 b2 cf 3c 17 33 8f fe 23 a6 7e 8e 8f 61 c7 2a c3 e1 74 ce 74 6e 1f 0d 9e f7 72 d2 00 36 14 ed

set mute 0
Caller;hDevice;dwIoControlCode;lpInBuffer;nInBufferSize;lpOutBuffer;nOutBufferSize;lpBytesReturned;lpOverlapped;inBuffer;bytesReturned;outBuffer; 2648;c8;390008;0;0;bef05c;30;bef028;0;;30;9e d1 db db 6e 80 9c d0 4e 0c 3e 6f 98 6a cb d1 99 e3 70 ae 57 71 ed c4 fb d3 0e 01 4a d6 a6 df 25 ec 22 9f 2b f6 65 b9 d7 bb ac 45 c1 6d c3 76

set mute 1
Caller;hDevice;dwIoControlCode;lpInBuffer;nInBufferSize;lpOutBuffer;nOutBufferSize;lpBytesReturned;lpOverlapped;inBuffer;bytesReturned;outBuffer; 4664;d0;390008;0;0;142f66c;30;142f638;0;;30;b4 1d cd f5 e3 74 c6 2f 5d c2 67 e6 b1 9b 4a f0 61 1d 19 dd 3b 0d 99 19 b1 b1 57 78 36 0d 46 66 55 9c 7f 39 94 1c 94 e9 8f d6 40 0d de 1c b4 b0

set recovery
Caller;hDevice;dwIoControlCode;lpInBuffer;nInBufferSize;lpOutBuffer;nOutBufferSize;lpBytesReturned;lpOverlapped;inBuffer;bytesReturned;outBuffer; 2ea0;dc;390008;0;0;def384;30;def350;0;;30;eb f8 e6 1e 37 47 1a 05 9e 8f ea 96 c0 fe 17 f2 cd ee b5 20 53 d9 6a 2d 10 74 11 27 bd 8b a1 dd c7 ad db 06 b6 7e 3d 76 36 b3 85 8c a9 58 4a dc

svanspenable
Caller;hDevice;dwIoControlCode;lpInBuffer;nInBufferSize;lpOutBuffer;nOutBufferSize;lpBytesReturned;lpOverlapped;inBuffer;bytesReturned;outBuffer; 2e50;e4;390008;0;0;5ef3fc;30;5ef3c8;0;;30;b4 18 73 5c d1 22 a1 7c ac a4 30 a1 63 ca e3 2d 5f 98 fc 33 11 50 72 a0 db 81 21 5c ec 06 c9 90 2d d0 a4 28 8b cf bd 37 65 40 ab 45 ad 7f 8f b8

from init-headphone.

Can I request this issue to be re-opened?

We came to the conclusion, that the laptop doesn't have the headphone amplifier. The headphones should work after a cold boot. They should stop working after wake-up from suspend.

Your debugging output doesn't look promising. It's just one command, there should be lots of communication.

from init-headphone.

Hmm, might there be some issue with the debugging output? I didn't really check to see that it was capturing ok (although it would look to be ok, except for being so short)

I wonder if the headphone amp is handled somewhat differently on this model. I recall the amp being advertised as being present. There are stickers on the model indicating Burr-Brown headphone amp presence. The performance on my Sennheiser Momentum Wireless 2.0 headphones (connected through wired connection obviously) seems to be comparable to its' performance when being driven by an external amp. There is an audible relay click when the headphones are plugged in, in windows. The relay is also visible on the PCB near the SPD/IF / headphone jack. I didn't take a photo of the bottom of the audio board where the op-amp is most likely located at, but certainly could if needed. However, I don't think it would be necessary, as the service manual is available for both the OP's P650RS and my P670RS here: http://www.mediafire.com/file/hiq6sy4kk0tvicq/P67xRS_ESM.zip - if I read it correctly (I certainly may not be), referencing page 131, ALC898's SENSE_A (jack sensing) triggers AS700A GPIO low, which accompanied with the relay being triggered activates the OPA1622 chip, which would appear to be the Headphone Amp used on our boards: http://www.ti.com/product/OPA1622

Certainly this audible relay click is not heard in Linux, and I think here lies our key, the OPA1622 is simply not powered on. I am not so great at interpreting diagrams (I am always learning...!) - Going by this forum post: http://forum.notebookreview.com/threads/official-clevo-p775dm2-3-g-p75xdm2-g-sager-np9152-np9172-wingman-2-0-batman-3-0-lounge.794538/page-123#post-10347919 another component of Clevo Control Center may be missing here, as headphone impedence is measured, communicated to EC, which is then reflected in Clevo Control Center, at which point the relay is triggered (by...?), enabling OPA1622 power-up.

from init-headphone.

I took a look at the service manual and here are my initial thoughts:

There are two variants. The Audio Board P67_3DAMP_E looks very familiar. The Audio Board P65_ESS_A is very different. Your model seem to have the latter.

The laptop has a line-out and a combined headphone/SPDIF port. The line-out port and and SPDIF portion of the combined port are connected directly to the audio codec. The sense connectors of both ports are also directly connected to the codec.

Linux should be able to detect if a plug is inserted into the ports. The line-out and the SPDIF outputs should work. (You may have to change the profile in the audio settings.)

The headphone port is more interesting: It has an external DAC (ESS ES9018). The DAC gets fed from the SPDIF output of the codec (the same SPDIF output as the external SPDIF port). The output of the DAC gets amplified and then goes to a relay.
The relay switches the headphone port between the audio signal (from the amplifier) and the mysterious chip SV3S700A (I guess for measuring the impedance of the headphones). The DAC, amplifier and relay is turned on/off by a GPIO pin of SV3S700A.
The DAC and the mysterious chip are both connected to the SMBUS.

I guess that the Windows software uses the audio driver to check if headphones are plugged in. Then communicates over the SMBUS with SV3S700A to measure the impedance of the headphones. Next sets the GPIO pin of SV3S700A, to switch the relay and turn on the DAC and amplifier. Finally it may be necessary to initialize the DAC over the SMBUS.

Am I right in the assumption that the relay doesn't click only once on boot, but every time headphones are plugged in or at least when the control center software displays the impedance.

This is much more involved, than simply initializing a headphone amplifier.

daglaptop cinnamon # i2cdetect -y 0

Are you sure that you are probing the correct bus?

ALC898's SENSE_A (jack sensing) triggers AS700A GPIO low

I don't think that this happen directly, but that the Windows software is involved in this step.

as headphone impedence is measured, communicated to EC, which is then reflected in Clevo Control Center

Why do you think that the EC is involved? It seems reasonable to me that the Windows software talks to SV3S700A directly.

Next I would try to identify the exact part of the Windows software which talks to SV3S700A and the DAC.

from init-headphone.

Thanks for looking into it for/with me. :)

Am I right in the assumption that the relay doesn't click only once on boot, but every time headphones are plugged in or at least when the control center software displays the impedance.

Correct, there is a short delay after plugging in headphones, it sounds as though codec is playing a short test signal in headphones directly after plugging in, at which point jack detection notification comes up in windows, accompanied by impedence showing in clevo control center. At the same moment impedence is updated, the relay is audibly heard clicking over. At the moment headphones are unplugged, relay clicks again and impedence display goes back to --

Are you sure that you are probing the correct bus?

Yes, my output from i2cdetect -l is same as Sardaukai, so I am using bus SMBus I801 adapter at f000.

Why do you think that the EC is involved? It seems reasonable to me that the Windows software talks to SV3S700A directly.

I thought the same, and typed as much originally, but later edited my comment after reading the referenced forum post which talks about EC being involved. I really haven't looked into it that much in depth yet (I plan to shortly!), so I don't know more beyond a cursory glance at the service manual and some guesses. :)

Next I would try to identify the exact part of the Windows software which talks to SV3S700A and the DAC.

OK, I will try to identify this soon. Drivers for P65_67_RS_RP are available here: Clevo Drivers Page for P65xRS(-G)/P67xRS(-G)/P67xRP6(-G)

from init-headphone.

/mnt/windows $ grep -rnw . -e 'SvThANSP'
Binary file ./hiberfil.sys matches
Binary file ./init-headphone-tools-master/hp.dll matches
./init-headphone-tools-master/ReadMe.md:24: * The kernel driver SvThANSP.sys must be installed.
Binary file ./Program Files (x86)/Hotkey/hp.dll matches
Binary file ./Program Files (x86)/Hotkey/SvThANSP.sys matches
./Windows/appcompat/appraiser/APPRAISER_FileInventory.xml:1218:
Binary file ./Windows/LiveKernelReports/PoW32kWatchdog-20170522-1634.dmp matches
Binary file ./Windows/LiveKernelReports/PoW32kWatchdog-20170602-0120.dmp matches
Binary file ./Windows/LiveKernelReports/PoW32kWatchdog-20170603-2113.dmp matches
Binary file ./Windows/System32/config/SYSTEM matches

Would seem to indicate that nothing else is communicating with the SV3S700A driver. A bit of poking around the driver and the internets would seem to indicate that the driver is for the Clevo "ANSP" 3D headphone technology (aka "3D sound technology on headphone output"), which is only present on the "RP" model of the 650/670, per your look at the Service Manual this is the tech you're used to seeing that works well with init-headphone. The "RS" model is billed as having "ESS™ SABRE HiFi DAC for High resolution headphone audio" - so perhaps there isn't communication with this driver needed for support. Looking at Clevo's Gaming Notebooks Page any model ending in *K(1), *J, or *P*-G features ANSP, and any model ending in *S-G or *M*-G features ESS Sabre. As there is a unified Clevo Control Center, but a separate driver for the RP/RS models, i'd guess the driver plays the major part here. I'll attempt a comparison on the drivers and see if something pokes me in the face.

from init-headphone.

it sounds as though codec is playing a short test signal in headphones directly after plugging in

The codec is not connected to the headphone jack until the relay is switched (besides the jack detection pin). Maybe you are hearing the test current from SV3S700A for measuring the impedance.

/mnt/windows $ grep -rnw . -e 'SvThANSP'

Please try something like

grep -ialP 'SvANSPDo|S\x00v\x00A\x00N\x00S\x00P\x00D\x00o' -r .

\\.\SvANSPDo is the device file provided by the SvThANSP.sys driver. The name is not case-sensitive. The \x00 are for the case that the string is UTF-16 encoded.

Is there a windows utility to read i2c values like i2cdetect?

I don't think so. It's pretty difficult to talk to the SMBUS on Windows. The Clevo driver uses a workaround. They implemented a simple driver for the i2c controller in user space using SvThANSP.sys, which basically provides direct access to I/O ports.

Would seem to indicate that nothing else is communicating with the SV3S700A driver

Try to break it, to find out what is involved and what is not. Kill processes that are connected to the Clevo driver in the task manager, until the relay stops clicking. What happens when you disable the sound card in the device manager. Does it still work when you rename hp.dll. Uninstall the SvThANSP.sys driver.

Edit: I fixed the grep command. The -a argument is required to switch into text mode, otherwise the NULL byte is not matched.

from init-headphone.

Okee dokee, I'm in Windows right now poking things, as soon as I get into linux again i'll grep.

Removed Clevo Control Center completely, it would seem to have no part in kicking the relay over as it happens with only the driver loaded. Then tried uninstalling the Realtek driver, during the uninstall process the relay kicked over. So that would seem to confirm the driver playing the major part (note I had rebooted already, so Clevo Control Center was certainly unloaded)

RwAnything (Windows Program) would seem to be able to read/write to i2c, although i'm not quite sure the parameters to feed it to get similar readouts to i2cdetect.

Maybe you are hearing the test current from SV3S700A for measuring the impedance.

Indeed, I'm sure that's what it is.

I used Process Monitor for Windows to get a dump of process activity just in case that shared any insight, but I don't see anything jumping out at me, you can see windows picking up on adding/removing the audio endpoints upon detection. Note that I went from unplugged -> plugged -> unplugged -> plugged -> unplugged during this capture. I filtered out the processes that were clearly unrelated.

Logfile.zip

I didn't directly pay attention, but I would assume the SvThANSP.sys driver was uninstalled along with Clevo Control Center, as that's where it came from, so likely not involved at all in triggering the relay. I would assume hp.dll plays no part, also.

from init-headphone.

I didn't directly pay attention, but I would assume the SvThANSP.sys driver was uninstalled along with Clevo Control Center

Verify it. (e.g. DriverView)

from init-headphone.

Confirmed with DriverView that the SvThANSP.sys driver did NOT uninstall with Clevo Control Center...
...Set it not to start via registry, rebooted, confirmed it wasn't loaded, and still get the relay triggering when headphones are plugged in. Will continue to narrow down, but definitely looks like the Realtek driver handles this.

Update: Looks like RTKVHD64.sys is (either directly or indirectly) responsible for triggering the relay. If i set this service not to start, the relay won't be triggered anymore. Although, the audio icon shows a broken speaker when the service is removed, so it could be an artifact of the whole audio system being borked without it. But either way removing that service triggers the relay not to function anymore.

Update2: Looking at the various strings contained within, i see the following interesting stuffs:
SmartAmpCFGRetry
SmartAmpInitTime
RTAMPCFG%d
RTAMPCFG
RTKAMP => RtkI2C => RtkSmartAmpCMD_Case
RTKAMPInfo
RtkAmpInitPostProcessing->bNeedActionA
\Registry\Machine\Software\Realtek\SmartAmpCMD
RtkSmartAmpCMD_Retry
RSA%01x_%ws_AMP_55
RSA%01x_%ws_AMP_56
RSA%01x_%ws_AMP_4E
RSA%01x_%ws_AMP_4F
Smart AMP controls
\Registry\Machine\SYSTEM\CurrentControlSet\Services\Mssmbios\Data

Which would seem to lend some credence to this RealTek driver handling things..

Unfortunately, my disassembly skills aren't so good. I don't think I can manage to take it much further myself, I don't know how to manipulate stuffs like IDA Pro well enough to follow the program execution, branching, etc. I'm still learning....

from init-headphone.

Set it not to start via registry, rebooted, confirmed it wasn't loaded, and still get the relay triggering when headphones are plugged in.

Did you also power off the computer? If some hardware component just needs some kind of initialization, it's possible that a simple reboot doesn't reset it. (It's the case for the amplifier, which gets initialized by hp.dll.)

Which would seem to lend some credence to this RealTek driver handling things..

Looks like a red herring to me. Maybe Clevo has bundled their driver in the audio driver package. I can't imagine that this is a feature of the Realtek driver.

from init-headphone.

Did you also power off the computer? If some hardware component just needs some kind of initialization, it's possible that a simple reboot doesn't reset it. (It's the case for the amplifier, which gets initialized by hp.dll.)

Yes, I powered off the machine. I also wiped out the Clevo-supplied driver and loaded up the generic Realtek HD Audio Codec driver from Realtek's page (2.81 dated 1/7/2017) - So far as I can tell, I've gotten rid of all traces of the Clevo Control Center and accompanying drivers, and also all traces of the Clevo-Supplied Realtek audio drivers. DriverView shows the new version loaded. I believe Clevo/Realtek addressed the issue of the ANSP amp state going undetermined after suspend/resume or a reboot with this relay - When I reboot the system I can hear the relay click off as soon as the driver's unloaded. Similar behavior if I simply unload the driver. I can load the driver and hear the relay click on immediately. I wonder what the behavior would be if I rebooted the system without allowing the realtek driver to Close() properly.

I didn't think it would be a feature of the Realtek driver either. But poking around inside various driver bits shows a heck of a lot of stuff in there from various other companies, Clevo being only one. For example, mbfiltx64.sys gets loaded with the generic realtek drivers - this is apparently a filter allowing for the functionality of Creative X-Fi MB5. Which, incidentally comes with this system as well. If I follow what I loosely understand from looking at the disassembly (I'm sure I'm horribly wrong, but i'm trying...!) - The Realtek driver access SMBios data Windows automagically stores in the registry, and parses what's returned to determine what support to load. There are various branches depending what SMBios says.

There are lots of references to various OEMs inside the driver. It looks to me like the build process is similar to how Microsoft used to handle Windows Mobile (Pre WinPhone) - OEMs forward design specs, etc. to Realtek, who then builds a new driver version, tacking on some stuff to the old base. It appears this way looking at the build enviornment strings that get left in the binaries, some versions were built in folders like: /RealTek/Beta-New-For-ASUS/ - wash, rinse, repeat for the next build for another OEM. Microsoft used to maintain various branches with functionality differences, but Realtek looks like they just throw it all in one big package. There's stuff there for quite a few of the major OEMs. There's old stuff for Dell in there that I don't remember seeing deployed on an actual running machine for 7+ years.

It might be of note that I have my BIOS unlocked (I can alter hundreds of settings that are not visible on the EFI menu system), and there are a lot of codec related options in there. At one point I was tinkering with it and was able to set the codec to an alternate mode where it was picked up by Windows as Intel SST Audio - there might be something relevant there, i'll poke it in a bit.

From what I can see after analyzing a few versions of the Realtek driver, all changes are cumulative. So, using a driver made before this specific build for P65_67_RS wouldn't have the code to trigger the relay, while using any build made after would. I will try to confirm my suspicions shortly by using an older Realtek driver. I suspect it won't trigger the relay. Then I'll upgrade to 2.81 and see if the relay begins functioning again. For now, without the SvThANSP.sys driver loaded, or any other part of Clevo Control Center/Hotkey (like hp.dll), my audio is functioning well from the Amplified Speaker output.

Update: Confirming that running Realtek Driver 2.76 6.0.1.7487 works fine audio-wise (speakers, line out work), but does not trigger the relay on plugging in headphones. This, however, might be due to the driver only picking up on the center jack of the 3 (it doesn't see the line out or the headphone/spdif jack) - interestingly the headphone/spdif jack has optical out enabled by default (the proper driver doesn't have optical out enabled until JACK_SENSE on that port)

Update2: Of the official releases, 2.79 exhibits the above behavior, with only one jack detected and no relay action, and 2.80 and above functions as normal. The latest driver from Windows Update functions as normal, also. Perhaps a comparison between 2.79 and 2.80 releases would shed some light on things. This whitepaper for Realtek 888 has a lot of info about things, maybe useful.

from init-headphone.

@dagnarf I'm really interested in getting my ESS chip working. Have you found anything else besides what you documented here?

from init-headphone.

From what I measured with a multimeter, and the patch from system76, I think the barrier is the es9018 chip. SPDIF has signal and relay can be manually triggered. However, no analogue output was coming out from the es9018. Even the i2c controller is not working properly. The datasheet marked the address as 0x90(8bit addressing, 0x48 in 7bit addressing) but it doesn't work when sending a signal to 0x48. I just bought an oscilloscope and a logic analyzer and will measure more when it arrives.

from init-headphone.

I've captured some i2c traffics, anyone who is interested in this can ask me to get a copy of captures.

from init-headphone.

I have some updates on my project, Link here.

from init-headphone.