Created attachment 1368380 [details]
journalctl -b 0

with the firmware for touchscreen included - later the module was unloaded to be able to work with the computer.

Created attachment 1368381 [details]
lshw; lspci; lsusb

hardware information commands

Hi,

So for the touchscreen you need the extract the extact firmware for this laptop from the windows partition, see:
https://github.com/onitake/gsl-firmware/blob/master/README.md#adding-new-firmware

Specifically there should hopefully be a SileadTouch.fw file under Windows\System32\drivers. If not then the Windows drivers uses firmware embedded in the SileadTouch.sys file under Windows\System32\drivers.

If you've a SileadTouch.sys file, open it in a hex editor (e.g. ghex), it should start with "f0 00 00 00 xx 00 00 00" where xx may be anything, if it does not it is scrambled and you need to run the unscramble script on it, download:
https://raw.githubusercontent.com/onitake/gsl-firmware/master/tools/unscramble

And then run:
perl unscramble SileadTouch.sys mssl1680.fw

To get an unscrambled fw file and try using that, it should work better, but the coordinate range will be wrong, each silead touchscreen needs an entry in:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/platform/x86/silead_dmi.c

I can help with this, but first I need to know the range of the coordinates, so once you have the extracted firmware file do:

sudo dnf install evemu
sudo evemu-record

Then select the silead touchscreen input device and check the coordinate range, find out which edges gives the highest coordinate values and go over those edges 
repeatedly while looking for the absolute highest value you see.

Then write down:
1) Which edge is giving a high value (left / right / top / bottom)
2) If the edge is giving high values for x or y coordinates
3) What the absolute highest value is for that edge (so for x or y

Normally top left is 0, 0 and the right edge will give the maximum x values,
while the bottom edge will give the maximum y values, but x and y may be swapped and the x or y coordinate ranges may be inverted. An entry in silead_dmi.c can correct for all of these, but first we need to now the right values to put in that entry.

I will also need dmi info for your device, please run:

sudo dmidecode > dmi.log

And attach the generated dmi.log file here.

If there is no SileadTouch.fw, then the firmware needs to be manually extracted from the SileadTouch.sys file, I can do this for you. In this case please put the SileadTouch.sys file somewhere where I can get it and add an URL to it here in bugzilla. Please do not attach the SileadTouch.sys file here.

###

About the touchpad, that looks like a trickier problem. First of all try:

sudo rmmod i2c-hid
sudo modprobe i2c-hid

And see if that helps.

Also I would like to look at the ACPI tables for your device, please run:

sudo dnf install acpica-tools
sudo acpidump -o acpidump.TREKSTOR-Primebook-C13

And attach the generated acpidump.TREKSTOR-Primebook-C13 file here.

Regards,

Hans

The unscramble comand on the sys file did produce an empty file :(

I then followed: https://github.com/onitake/gsl-firmware/blob/master/firmware/trekstor/surftab-twin-10.1-ST10432-8/README.md#gives-this-output

To try to extract the fw from the sys file - according to the grep command 1 firmware I extracted it with the dd command.

Unfortunately the extracted firmware does not seem to work.


Message in journal is:

Dez 15 12:06:17 dietrich.teilgedanken kernel: silead_ts i2c-MSSL1680:00: Initialization error, status: 0x0
Dez 15 12:06:17 dietrich.teilgedanken kernel: i2c_hid i2c-ELAN221D:00: hid_descr_cmd failed

so far for the progress unfortunately I'll be offline now I'll get later and try the touchpad options.

The SileadTouch.sys file is available in the package(400MB) /sileadtouch.inf/:  http://www.trekstor.de/produkte/2in1/detail-2in1/product/primebook-C13-lte.html?file=files/userFiles/products/primebook_c13/Primebook-C13.zip

Hey again,

sorry I didn't thank you for your brilliant reply by the way!

I investigated a little further with the firmware extraction page: https://github.com/onitake/gsl-firmware/blob/master/README.md#adding-new-firmware

It turns out I was able to use the `tools/untscfg` util to extract the correct firmware from a *.h file... The command I was running was:

./untscfg ./Primebook-C13/Primebook-C13_2017-11-20/sileadtouch.inf/weibu_th133a-yd_SR_5680_X64_L_ZT_1028.h mssl1680.fw

where the Primebook-13 directory is the one from the zip above.

With that firmware touch is responding as expected, but not calibrated.

I'm now trying to get the Numbers you mentioned - however I don't know which of the many to look for.


# ABS_X
  * left is small: smallest I achieved is 1 (never reached 0)
  * right is big: biggest I achieved is 2624 (most of the time 2623)

# ABS_Y
  * top is small: smallest I achieved is 8 - however it might well be that the top bar captures the events or something? I don't know - I'm on gnome3 wayland.
  * bottom is big: biggest 1914

I'll add the dmi.log

Do I add the *.fw file somewhere? Probably the gsl-firmware repository isn't it?

Thanks for your time and help!

Created attachment 1368681 [details]
sudo dmidecode > dmi.log

Created attachment 1368682 [details]
sudo acpidump -o acpidump.TREKSTOR-Primebook-C13

## Touchpad

unfortunately the touchpad does not work after removing and readding the module :(

the dump command produces an ugly file - I hope it is supposed to be that way :)

Oh and the touchpad has an (not working) finger print reader in it. I don't expect the reader to work but I thought it might have something to do with the issues...

Hi,

Thank you for all the info and great work on getting the firmware and yes the firmware should go the the gsl-firmware repository under the firmware/linux/silead directory as gsl1680-trekstor-primebook-c13.fw eventually, but first lets make sure it works correctly.

I will try to provide a patch for https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/platform/x86/silead_dmi.c for you to test during one of the coming days (I'm a bit swamped with other stuff atm). Do you know how to build your own kernel, or do you want me to provide (test) Fedora kernel rpms with the patch ?

As for the touchpad, this sounds a lot like the touchpad in my own Apollo Lake laptop (that also has the buildin fingerprint reader). I believe that this message is actually the reason why it is not working:

Dez 15 08:19:58 dietrich.teilgedanken kernel: i2c_hid i2c-SYNA3602:00: unexpected HID descriptor bcdVersion (0x00ff)

I've fixed a couple of bugs (with different symptoms) for my own Apollo Lake laptop touchpad. Those fixes are in 4.15, perhaps you can give 4.15 a try, from here: https://koji.fedoraproject.org/koji/buildinfo?buildID=1009698 download:

kernel-core-4.15.0-0.rc3.git4.1.fc28.x86_64.rpm
kernel-modules-4.15.0-0.rc3.git4.1.fc28.x86_64.rpm

And then from a dir with those 2 files in it run:
sudo rpm -ivh kernel*.rpm

And then reboot into the new kernel, this may help, but no promises.

Otherwise if you're willing to build your own kernel try changing:
drivers/hid/i2c-hid/i2c-hid.c line 846 from:
        if (le16_to_cpu(hdesc->bcdVersion) != 0x0100) {
to:
        if (le16_to_cpu(hdesc->bcdVersion) != 0x00ff) {

And see what happens then. If you've no experience with building your own kernels and 4.15 does not help then I will add this workaround/hack to the kernel I'll build to test the silead_dmi.c changes and we'll see from there.

Regards,

Hans

p.s.

I've been looking a bit into your fingerprint reader, as I expected it is a separate device / chip from your touchpad. I believe this bit of ACPI code describes it:

    Scope (\_SB.PCI0.SPI1)
    {
        Device (FPNT)
        {
            Name (_ADR, Zero)  // _ADR: Address
            Name (_HID, "GXFP3200")  // _HID: Hardware ID
            Name (_CID, "GXFP3200")  // _CID: Compatible ID
            Name (_UID, "GXFP3200")  // _UID: Unique ID
            Method (_STA, 0, NotSerialized)  // _STA: Status
            {
                Return (0x0F)
            }

            Method (_CRS, 0, Serialized)  // _CRS: Current Resource Settings
            {
                Name (BBUF, ResourceTemplate ()
                {
                    SpiSerialBusV2 (0x0000, PolarityLow, FourWireMode, 0x08,
                        ControllerInitiated, 0x002DC6C0, ClockPolarityLow,
                        ClockPhaseFirst, "\\_SB.PCI0.SPI1",
                        0x00, ResourceConsumer, , Exclusive,
                        )
    ...

Which means that it as a SPI fingerprint reader, which if someone were to add support for it would make it the first of its sort (first supported SPI fingerprint reader) AFAIK and as such quite tricky to add support for I'm afraid.

Created attachment 1369686 [details]
journalctl -b 0 on  kernel-4.15.0-0.rc3

I tried kernel 4.15 but no luck so far.

The errors in journalctl stayed the same - I think.

I think I can build my own kernel... It's been a long time since I last did that. But I should be able to. Getting the old rusty skills going should be fun...

I'll probably stick to a guide though. This one? https://fedoraproject.org/wiki/Building_a_custom_kernel

(In reply to Dietrich from comment #11)
> I'll probably stick to a guide though. This one?
> https://fedoraproject.org/wiki/Building_a_custom_kernel

Yes a good way to test would be to follow that one, before doing the 
"fedpkg local" edit kernel.spec and change:

%define with_debug     %{?_without_debug:     0} %{?!_without_debug:     1}

Into:

%define with_debug     0

Then run "fedpkg local" and press ctrl+c once it is actually compiling object files, e.g. once you see messages like this one:

+ make -s ARCH=x86_64 oldnoconfig
USING ARCH=x86_64
+ make -s ARCH=x86_64 V=1 -j4 bzImage

(this will extract the kernel, apply all Fedora specific patches and configure   the kernel using Fedora's kernel config)

Then cd into e.g. kernel-4.14.fc28/linux-4.15.0-0.rc3.git3.1.fc28.x86_64 and edit drivers/hid/i2c-hid/i2c-hid.c changing line 846 from:
        if (le16_to_cpu(hdesc->bcdVersion) != 0x0100) {
to:
        if (le16_to_cpu(hdesc->bcdVersion) != 0x00ff) {

And then follow:
https://fedoraproject.org/wiki/Building_a_custom_kernel#Building_the_kernel

And after the "make install" you can reboot into the new kernel, with maybe with some luck a working touchpad.

Note this is going to take 4-5GB of disk space! Also please keep the files around once you're done, that will safe you a lot of time when testing the silead_dmi.c patch which I'm going to write for you soonish.

Created attachment 1370526 [details]
journalctl -b 0 with the hack line change - not working

Hey,

I've now successfully built and installed a new kernel. With the onelinehack you mentioned. - It did not work. The log seems to be the same than before with a small difference:

old:
Dez 15 08:19:58 dietrich.teilgedanken kernel: i2c_hid i2c-SYNA3602:00: unexpected HID descriptor bcdVersion (0x00ff)
new:
Dez 20 16:27:15 dietrich.teilgedanken kernel: i2c_hid i2c-SYNA3602:00: unexpected HID descriptor bcdVersion (0x0000)

So the bcdVersion changed from 0x00ff to 0x0000

I checked with the other log from that 4.15 kernel you gave me to try and there the bcdVersion was 0x0000 too.

Also on the 4.15 kernel I found this line (Attachment: 1369686: journalctl -b 0 on kernel-4.15.0-0.rc3):
Dez 18 20:14:06 dietrich.teilgedanken kernel: i2c_hid i2c-SYNA3602:00: i2c-SYNA3602:00 supply vdd not found, using dummy regulator
does this help - I don't really understand it.

This message appeared only on the 4.15 kernel. (the hackline kernel is $ uname -r -> 4.14.7-300.local.fc27.x86_64)

Thank you so far!

I tried to create a work in progress patch for silead_dmi.c

I don't understand the DMI_Match strings and can't find the right ones.

So in case it helps you here it is:


https://github.com/enaut/linux/commit/e3934b351f4d30eda42fc849453f041252ce01dc

Hi,

(In reply to Dietrich from comment #14)
> I tried to create a work in progress patch for silead_dmi.c
> 
> I don't understand the DMI_Match strings and can't find the right ones.
> 
> So in case it helps you here it is:
> 
> 
> https://github.com/enaut/linux/commit/
> e3934b351f4d30eda42fc849453f041252ce01dc

Nice, we will turn you into a kernel hacker yet :)

You can find the dmi strings in the dmi.log file I asked you to generate, in the "System Information" info block, Manufacturer there maps to DMI_SYS_VENDOR and Product Name maps to DMI_PRODUCT_NAME. Anyways I've prepared a patch for you to test which I will attach here. Please also run evemu-record again and try touching the windows logo and see if that sends a "KEY_LEFTMETA" if not then the PROPERTY_ENTRY_BOOL("silead,home-button") entry can be dropped (and needs to be dropped before I submit this upstream.

About the touchpad, I've been looking at your acpidump and at the involved kernel code, but I'm afraid that nothing comes to mind. The only thing which I can still think of is you giving me remote access to the machine to debug this further. I will send you a mail outside of bugzilla about this.

I hope the patch I attach will at least fix the touchscreen for you and I wish you Merry Christmas and a Happy New Year.

Regards,

Hans

Created attachment 1371897 [details]
silead_dmi.c patch to get the touchscreen to work

To test this patch you can simply apply it as usual and then re-run the steps from: https://fedoraproject.org/wiki/Building_a_custom_kernel#Building_the_kernel again.

Yay the touchscreen is working! and it seems to be well calibrated.

there is also the KEY_LEFTMETA - I didn't know I can touch the windowsbutton until now!:

################################
#      Waiting for events      #
################################
E: 0.000001 0001 007d 0001	# EV_KEY / KEY_LEFTMETA         1
E: 0.000001 0000 0000 0000	# ------------ SYN_REPORT (0) ---------- +0ms
E: 0.037127 0001 007d 0000	# EV_KEY / KEY_LEFTMETA         0
E: 0.037127 0000 0000 0000	# ------------ SYN_REPORT (0) ---------- +37ms

(In reply to Dietrich from comment #18)
> Yay the touchscreen is working! and it seems to be well calibrated.
> 
> there is also the KEY_LEFTMETA - I didn't know I can touch the windowsbutton
> until now!:
> 
> ################################
> #      Waiting for events      #
> ################################
> E: 0.000001 0001 007d 0001	# EV_KEY / KEY_LEFTMETA         1
> E: 0.000001 0000 0000 0000	# ------------ SYN_REPORT (0) ---------- +0ms
> E: 0.037127 0001 007d 0000	# EV_KEY / KEY_LEFTMETA         0
> E: 0.037127 0000 0000 0000	# ------------ SYN_REPORT (0) ---------- +37ms

Thank you for testing, I've submitted the silead_dmi.c patch upstream.

Created attachment 1373370 [details]
journal -b 0 with working touchpad but failing after suspend

Hey again,

I noticed that, when the touchscreen is working and then the Laptop goes to suspend then afterwards the touchscreen is not working anymore.

After a
sudo rmmod silead
sudo modprobe silead
the touchscreen is working again.

the relevant logged error is:
Dez 28 19:07:39 dietrich.teilgedanken kernel: ACPI: Waking up from system sleep state S3
Dez 28 19:07:39 dietrich.teilgedanken kernel: ACPI: EC: event unblocked
Dez 28 19:07:39 dietrich.teilgedanken kernel: sd 0:0:0:0: [sda] Starting disk
Dez 28 19:07:39 dietrich.teilgedanken kernel: [drm:wait_panel_status [i915]] *ERROR* PPS state mismatch
Dez 28 19:07:39 dietrich.teilgedanken kernel: silead_ts i2c-MSSL1680:00: Resume error, status: 0x00
Dez 28 19:07:39 dietrich.teilgedanken kernel: dpm_run_callback(): silead_ts_resume+0x0/0x90 [silead] returns -19
Dez 28 19:07:39 dietrich.teilgedanken kernel: PM: Device i2c-MSSL1680:00 failed to resume: error -19

The complete log is attached.

I just thought we might fix this issue before submitting to upstream... - or is this "known" and has to be fixed manually like: https://bbs.archlinux.org/viewtopic.php?pid=1484947#p1484947 or similar?

Hi,

The touchscreen no longer working after suspend is neither a known issue, nor expected. I do wonder if a workaround like the one you link to would work (then we can fix this at the kernel level to do a re-init automatically) can you try doing:

sudo rmmod silead
sudo modprobe silead

After a suspend/resume and see if that fixes things ?

Regards,

Hans

Yes reloading the module does fix the issue!

(In reply to Dietrich from comment #22)
> Yes reloading the module does fix the issue!

Cool, I think I know how to fix this properly then, but I've been busy with other stuff. I will get back to you with a patch to test for this eventually, but it may take some days before I get around to this.

How do I ask if the fix is still on your agenda without making you feel stressed to do it right now?... In short I'm patiently waiting to test :)

Hi,

No worries, a polite ping like this is ok.

Yes this is still on my radar / on my todo list. Actually it is (slowly) getting closer to the top of my todo list :)

Regards,

Hans

Hi,

Note I've not forgotten but I've been burried in work wrt:
https://fedoraproject.org/wiki/Changes/ImprovedLaptopBatteryLife
https://fedoraproject.org/wiki/Changes/VirtualBox_Guest_Integration
https://hansdegoede.livejournal.com/18653.html
https://hansdegoede.livejournal.com/18804.html

As a result of this my todo list has gotten longer rather then shorter and this has moved down on it, sorry.

Regards,

Hans

Any news on the touchpad issue?

I have a different device: Teclast F6 pro and the touchpad does not work. It gives the same error for me: 
i2c_hid i2c-SYNA3602:00: unexpected HID descriptor bcdVersion (0x00ff)

I couldn't find anything related online, since it is a new device, so I'll appreciate any updates you have so far.

Thanks,

I did not investigate further because I just currently do not have enough time job wise :(

Also if you do manage to find something please make sure you notify me (and potentially others) here. I'll do the same.

Well I just looked at your laptop... at least visually it seems to be an exact clone of the Trekstor C13 so it might be the same issue.

kloxdami, sorry no news yet.

Dietrich, after taking another look at the ACPI tables for your device, one thing does stand out wrt the interrupt resource for the touchpad. I'm not sure yet how to fix this, other then using a DSTD overlay, which I really want to avoid. But it is an avenue to pursue to see if we can get things fixed.

Dietrich, do you think you can set me up for another remote debugging session?
Note I've not forgotten about the touchscreen suspend/resume issue that is something which I can look at then too.

I would prefer to do this during office hours, say coming Thursday (tomorrow) or Monday. But I can completely understand if the weekend works better for you, I currently don't have anything scheduled for this weekend. So either Saturday or Sunday works for me.

kloxdami, can you do an acpidump of your laptop too? :

sudo dnf install acpica-tools
sudo acpidump -o acpidump.Teclast-F6-Pro

And attach the generated acpidump.Teclast-F6-Pro file here.

Regards,

Hans

Ok, so doing an entire remote debugging session may no be necessary, I'm attaching a fixed ssdt2 ACPI table, which may fix the touchpad on the Trekstor. Do NOT use this on the Teclast, once I've an acpidump I can prepare a similar file for the Teclast.

To use this do the following:

1) Download the ssdt2.aml
2) As root do:

mkdir -p kernel/firmware/acpi
cp ssdt2.aml kernel/firmware/acpi
find kernel | cpio -H newc --create > /boot/initramfs_acpi_tables
mv /boot/initramfs-$(uname -r).img /boot/initramfs-$(uname -r).img.orig
cat /boot/initramfs_acpi_tables /boot/initramfs-$(uname -r).img.orig > /boot/initramfs-$(uname -r).img

3) Reboot, make sure you boot into the kernel you were running before.

Also see: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/acpi/initrd_table_override.txt

Created attachment 1401748 [details]
Fixed ssdt2 for the Trekstor Primebook C13

Note, this:

cat /boot/initramfs_acpi_tables /boot/initramfs-$(uname -r).img.orig > /boot/initramfs-$(uname -r).img

Is a single command / should be on a single line, but bugzilla line-breaks it because it is too long.

Created attachment 1401814 [details]
Fixed ssdt2 for the Trekstor Primebook C13

Fixed ssdt2 with the version field bumped, otherwise the kernel won't use it to override the original one.

Note when testing the fixed ssdt2 please collect the full output of dmesg directly after boot and attach it here.

Created attachment 1401984 [details]
acpidump for Teclast F6 Pro

I've attached the acpidump for Teclast F6 Pro

Created attachment 1402000 [details]
dmesg > dmesgtrekstorc13.log

dmesg right after booting - no touching but as far as I can tell nothing is added when I touch the touchpad.

Also the touchpad is not working.

As a sidenote are you looking for the entries you found previously but not on the last try?

In the Bios there is an option Chipset->Southcluster->Miscellaneous configuration->Touch Pad Device - ALPS0001 [Disable]

I changed that option to enable (because I wanted a Touchpad ;) that was during the remote session. But with the new grub file and the wonky bios settings (when setting to linux) I did reset the BIOS to factory defaults.

That could be the missing device? Or should I enable this setting? If I do there are some additional lines in the dmesg:
[   10.244837] i2c_hid i2c-ALPS0001:00: i2c-ALPS0001:00 supply vdd not found, using dummy regulator
[   10.244890] i2c_designware i2c_designware.4: i2c_dw_xfer: msgs: 2
[   10.244911] i2c_designware i2c_designware.4: enabled=0x1 stat=0x10
[   10.244948] i2c_designware i2c_designware.4: enabled=0x1 stat=0x750
[   10.247016] i2c_hid i2c-ALPS0001:00: hid_descr_cmd failed

Hi,

Ugh I made a mistake while looking at the DSDT, because of the Summary of this bug I was looking at the wrong part of the DSDT, so my override is useless.

Although in the beginning you were getting this error:
i2c_hid i2c-ELAN221D:00: hid_descr_cmd failed

Which I'm no longer seeing, but I guess that is related to some BIOS options too and that the dmesg you attached yesterday is from a boot with the BIOS reset to defaults?

I will take a look at the Teclast acpidump tomorrow, thank you for providing that.

Regards,

Hans

Hi,

the dmesg is with factory default bios! (called optimized default)

The Elan line in the Bios reads "Touch Panel Device - ELAN221D" directly above the ALPS setting.

It might be that both options do not enable real hardware...

(I'm not sure whether I do get a real IPv4 that I can use for something like ssh - I'm at my home now and last time was my parents place)

Hi,

(In reply to Dietrich from comment #39)
> Hi,
> 
> the dmesg is with factory default bios! (called optimized default)
> 
> The Elan line in the Bios reads "Touch Panel Device - ELAN221D" directly
> above the ALPS setting.
> 
> It might be that both options do not enable real hardware...

Yes, that also explains why we had the bogus i2c device entries before, so at least that riddle is solved. For now please keep the BIOS at its defaults.

> (I'm not sure whether I do get a real IPv4 that I can use for something like
> ssh - I'm at my home now and last time was my parents place)

Ah, ok. Too bad.

Regards,

Hans

Ok, so looking at both your DSTDs one thing which stands out is that the i2c bus is running at 100KHz. Maybe there is an issue with the i2c controller and the timings at 100KHz or off? I'm attaching a dsdt overlay for both of you (note use the right one!) to test, no guarantees that this will change anything...

To test:

1) Download the dsdt.aml
2) As root do:

mkdir -p kernel/firmware/acpi
cp dsdt.aml kernel/firmware/acpi
find kernel | cpio -H newc --create > /boot/initramfs_acpi_tables
mv /boot/initramfs-$(uname -r).img /boot/initramfs-$(uname -r).img.orig
cat /boot/initramfs_acpi_tables /boot/initramfs-$(uname -r).img.orig > /boot/initramfs-$(uname -r).img

Note Dietrich, you've probably already done the mv of the initramfs, don't
override your .orig one with the new one which has the ssdt2 overlay, also you can throw the ssdt2 overlay away it is not needed.

3) Reboot, make sure you boot into the kernel you were running before.

4) Please collect dmesg shortly after boot and see if the touchpad works of course.

Created attachment 1403023 [details]
DSDT with i2c speed for touchpad boosted to 400KHz for Trekstor Primebook C13

Created attachment 1403025 [details]
DSDT with i2c speed for touchpad boosted to 400KHz for Teclast F6 Pro

Note this is a longshot, don't get your hopes up this will actually fix anything.

Created attachment 1403042 [details]
dmesg > trekstror.log with dsdt-patch

Touchpad is not working...

there are some errors with snd_hda_codec_hdmi hdaudioC1D2: Unable to sync register 0x2f0d00. -5
But sound is working...

I rechecked... I truely do not have a IPv4 that I can give you - do you have a server with IPv6 connectivity? -like that you could easily ssh to that on from there to me...

Created attachment 1403167 [details]
dmesg output after dsdt.aml

Touch is not working in Teclast F6 Pro.

Nothing seems to have changed. I guess I followed the steps correctly, but is there a way to confirm that the change was applied?

Thanks for your help

Hi,

Dietrich, thank you for testing. I'm afraid that I'm all out of ideas for how to further debug this. I wonder if the touchpad really is a hid touchpad. I've seen some touchscreens which claim to be i2c-hid but are really using a custom protocol.

Can you both look in the device-manager under Windows, find out which device is the touchpad and look at details there, like driver names used, etc. If you can also find the .inf file used for the touchpad under Windows that would be great too.

kloxdami, I'm afraid I forgot to bump the version field in the dsdt override for the Teclast F6 Pro. I will attach a new one, sorry. Note given Dietrich's results I don't really expect this to help.

Regards,

Hans

Created attachment 1403791 [details]
Fixed DSDT with i2c speed for touchpad boosted to 400KHz for Teclast F6 Pro

Device Manager shows that the driver name is 'HID-compliant mouse'.

Here is some description I found.

Device HID\SYNA3602&Col01\5&20479005&0&0000 was configured.

Driver Name: msmouse.inf
Class Guid: {4d36e96f-e325-11ce-bfc1-08002be10318}
Driver Date: 06/21/2006
Driver Version: 10.0.16299.15
Driver Provider: Microsoft
Driver Section: HID_Mouse_Inst.NT
Driver Rank: 0xFF1004
Matching Device Id: HID_DEVICE_SYSTEM_MOUSE
Outranked Drivers: input.inf:HID_DEVICE:00FF1006
Device Updated: false
Parent Device: ACPI\SYNA3602\1

I was able to find this msmouse.inf file and will add it to the attachments.

Created attachment 1403804 [details]
msmouse.inf

msmouse.inf file used in Windows 10

Pretty much the same Info again... (which confirms that we are on the same hardware)...

The Device-Manager of windows produces the following event which contains a lot of useful information I hope. - will attach.

It looks like a very standard touchpad... it uses the input.inf file.
In the general section of the device description it says "Speicherort: auf I2C HID-Gerät" (english "save destination: on I2C-HID-Device")

From the device manager some keys that seem to be interesting (Note I translated the keynames from german):

Instance Path: HID\SYNA3602&COL02\5&20479005&0&0001
INF-Section: HID_Raw_Inst.NT
Matching-Device ID: HID_DEVICE_UP:000D_U:0005
Busnumber: 00000001
Configuration-ID: input.inf:HID_DEVICE_UP:000D_U:0005,HID_Raw_Inst.NT
Object name of Physical device: \Device\0000005b

If I deactivate that device Touchpad stops working... There is a Mouse device that has no effect if deactivated.

I think the msmous.inf is the mousedevice not being used...

Created attachment 1403805 [details]
Event in Windows registring the device

The device I selected in the Device-Manager is called HID-compliant Touchpad which is in the section Inputdevices (HID)...

I selected this device because it actually deactivates the touchpad if deactivated in contrast to the entry in "mouse and pointing devices"...

(note names are translated from german)

Created attachment 1404016 [details]
dmesg output after dsdt.aml

Updated dmesg output after new dsdt for Teclast F6. 
Now the error changed to:
[    6.550989] i2c_hid i2c-SYNA3602:00: weird size of HID descriptor (0)

So looking at the information of Dietrich it seems that this really is a generic i2c-hid device and for some reason the Linux driver is not working with it.

One possible reason for this is that we are using the wrong register-address to get the descriptor. I've written a little test-program to receive this from userspace.

First of all you will need to edit the .c file to match your laptop, do:

ls -l /sys/bus/i2c/devices | grep SYNA

On my system this outputs:

[root@localhost ~]# ls -l /sys/bus/i2c/devices | grep SYNA
lrwxrwxrwx. 1 root root 0  5 mrt 10:22 i2c-SYNA3602:00 -> ../../../devices/pci0000:00/0000:00:17.0/i2c_designware.4/i2c-9/i2c-SYNA3602:00

The "i2c-9" is what we're looking for, edit the attached i2c_hid_desc_dump.c
and change this line:

#define I2C_BUS         "/dev/i2c-9"

Replacing "i2c-9" with what you've on your laptop, now build the binary and then run it as root:

gcc -o i2c_hid_desc_dump i2c_hid_desc_dump.c
sudo ./i2c_hid_desc_dump

On my machine this results in:

[hans@localhost ~]# sudo ./i2c_hid_desc_dump
i2c_rdwr ret: 2 errno: 0
001e 0100 0241 0021 0024 0020 0025 0011 0022 0023 0911 5288 0002 

The "001e 0100" in the beginning is important, this is what we're currently not getting. The DSDT-s for both laptops defines the register to read to get the "i2c-hid-descriptor" as 0x20, this is set with the following line in the test program:

        cmd.c.reg = 0x20;

The microsoft example code for i2c hid, uses 0x01, so we could try that, change the line to:

        cmd.c.reg = 0x01;

And rebuild and run again:

gcc -o i2c_hid_desc_dump i2c_hid_desc_dump.c
sudo ./i2c_hid_desc_dump

And see if the output matches more closely to what we want. kloxdami it would be interesting to see the output as-is (cmd.c.reg = 0x20) since with the modified dstd we seem to be getting slightly further on your machine.

Note cmd.c.reg is 16 bits, so there are 65536 options for it, so just trying them all is not really feasible. You could try a few low numbers though. What might help is check inf files and the windows registry for the i2c-hid driver HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\hidi2c and see if maybe there is something there overriding the ACPI setting for the "i2c-hid-descriptor".

p.s.

As for your 2 laptops being the same, I don't think so. They use the same "case" and thus probably also the same touchpad, but the DSDT tables are vastly different and the Teclast one uses a (better) Goodix touchscreen where as the Trekstor one uses a Silead touchscreen.

Created attachment 1404243 [details]
i2c_hid_desc_dump.c

Ok, looking at various DSDTs commonly used values for cmd.c.reg are 0x00, 0x01 and 0x20. Please try all 3 and see if one of them results in a descriptor starting with "001e 0100"

So I've been talking to a colleague of mine (who is the author of the kernel's i2c-hid support) and if my idea with the i2c_hid_desc_dump.c and trying addresses 0x00, 0x01 and 0x20 does not work out then the next step in debugging this would be to capture the i2c trafic under Windows. He has written a special driver for this, but doing this is far from trivial, see:
https://github.com/bentiss/SimplePeripheralBusProbe

Anyways first lets try i2c_hid_desc_dump.c with cmd.c.reg set to 0x00, 0x01 and 0x20.

I followed the steps you described:

The output of ls -l /sys/bus/i2c/devices | grep SYNA is:

lrwxrwxrwx. 1 root root 0 mar  5  2018 i2c-SYNA3602:00 -> ../../../devices/pci0000:00/0000:00:15.0/i2c_designware.0/i2c-6/i2c-SYNA3602:00

So, I changed i2c_hid_desc_dump from #define I2C_BUS "/dev/i2c-9" to #define I2C_BUS "/dev/i2c-6", recompiled and run with sudo, but it fails to open the bus,

    fd = open(I2C_BUS, O_RDWR); // fd receives -1
    assert(fd > 0); // fails assertion

and the output is 
'i2c_hid_desc_dump: i2c_hid_desc_dump.c:37: main: Assertion `fd > 0' failed.
Aborted'

I checked errno and it says that there is 'No such file or directory'. I checked twice that I ran the command as root.

I also tried i2cdetect and the output is:

# i2cdetect -y 6
Error: Can't use SMBus Quick Write command on this bus

and also,

# i2cdetect -l
i2c-3	i2c       	DPDDC-A                         	I2C adapter
i2c-1	i2c       	i915 gmbus dpb                  	I2C adapter
i2c-8	smbus     	SMBus I801 adapter at f040      	SMBus adapter
i2c-6	i2c       	Synopsys DesignWare I2C adapter 	I2C adapter
i2c-4	i2c       	DPDDC-C                         	I2C adapter
i2c-2	i2c       	i915 gmbus dpd                  	I2C adapter
i2c-0	i2c       	i915 gmbus dpc                  	I2C adapter
i2c-9	i2c       	Synopsys DesignWare I2C adapter 	I2C adapter
i2c-7	i2c       	Synopsys DesignWare I2C adapter 	I2C adapter
i2c-5	i2c       	DPDDC-D                         	I2C adapter

# i2cdetect -F 6
Functionalities implemented by /dev/i2c-6:
I2C                              yes
SMBus Quick Command              no
SMBus Send Byte                  yes
SMBus Receive Byte               yes
SMBus Write Byte                 yes
SMBus Read Byte                  yes
SMBus Write Word                 yes
SMBus Read Word                  yes
SMBus Process Call               no
SMBus Block Write                yes
SMBus Block Read                 yes
SMBus Block Process Call         no
SMBus PEC                        no
I2C Block Write                  yes
I2C Block Read                   yes

I dont want to pollute the topic but I am also facing this problem on teclast f6 pro.

The output for ls -l /sys/bus/i2c/devices | grep SYNA is:
lrwxrwxrwx 1 root root 0 Mar  5 14:05 i2c-SYNA3602:00 -> ../../../devices/pci0000:00/0000:00:15.0/i2c_designware.0/i2c-7/i2c-SYNA3602:00

And after modifying and running ./i2c_hid_desc_dump the output is

i2c_hid_desc_dump: i2c_hid_desc_dump.c:36: main: Assertion `fd > 0' failed.

Ah, you need to do "sudo modprobe i2c-dev" before running the utility. I think I put that in an /etc/modules-load.d/*.conf file on my system, so I forgot about that.

As for i2cdetect not working on designware i2c-busses that is normal, try using: "i2cdetect -r -y 6" instead.

After running "sudo modprobe i2c-dev" it worked. The output is below:

## Using cmd.c.reg = 0x20;
errno: 0
i2c_rdwr ret: 2 errno: 0
0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 

When I touch/move the touchpad, the first 2 words change, for example:
errno: 0
i2c_rdwr ret: 2 errno: 0
d800 00ff 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000

Running multiple times while moving the touchpad, I always got outputs like this:
??00 00ff 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000

where ?? varies.

## Using cmd.c.reg = 0x00, 0x01, 0x02 or 0x03;
errno: 0
i2c_rdwr ret: 2 errno: 0
0000 0104 03f8 03f8 0003 0000 0200 0000 009c 0002 0000 ???? ????

In general, the last two words always vary, and the first remain unchanged. The third and fourth words vary when I move/touch the touchpad.

In my case was:

0x00 -> 0000 0304 0000 0000 4403 3420 0205 0a44 0534 0003 3400 d005 0010 

0x01 -> 0400 0003 0000 0300 2044 0534 4402 340a 0305 0000 0534 10d0 0000

0x20 -> 0000 0100 0000 0000 031c 0002 9c00 0201 0000 0534 0002 0000 fa00

In all options moving the touchpad with 1, 2, 3 fingers, clicking and etc.. give totally different results (In case this results being important just let me know so I can post it)

I sort of 'bruteforced' the values of cmd.c.reg and found that when I set it to 0x1e3d the output is

## Using cmd.c.reg = 0x1e3d
errno: 0
i2c_rdwr ret: 2 errno: 0
001e 0100 3009 3109 8115 7f25 0875 0295 0681 c0c0 0d05 0509 01a1 

I'm not sure if it helps or not.

(In reply to kloxdami from comment #67)
> I sort of 'bruteforced' the values of cmd.c.reg and found that when I set it
> to 0x1e3d the output is
> 
> ## Using cmd.c.reg = 0x1e3d
> errno: 0
> i2c_rdwr ret: 2 errno: 0
> 001e 0100 3009 3109 8115 7f25 0875 0295 0681 c0c0 0d05 0509 01a1 

The first 2 words look ok, but the rest seems bogus, sorry. Is the output consistent each run with cmd.c.reg = 0x1e3d?

Anyways I'm afraid it is time to go and catch the i2c trafic under Windows and see what is happening there. If any of you is up to this, please read:
https://github.com/bentiss/SimplePeripheralBusProbe

I can (try to) provide a modified dsdt if that helps. Noah, if you want to do this and want me to modify your dsdt for you, please run: "acpidump -o acpidump.teclast-f6-pro" and attach the generated file here. It may very well be the same as the acpidump from kloxdami, but better safe then sorry.

I ran i2c_hid_desc_dump today using cmd.c.reg=0x1e3d and the output changed completely.

I'll check the github link you sent.

Thanks

Ok, I was not able to follow through the readme. Probably because I don't have the 'skill' requirement.

I was not able to fix the errors when recompiling the DSDT. I tried commenting the lines/blocks where they apear, but there are just too many errors that I gave up.

Unfortunately the same here... Not enough skill to follow the readme.

Could you both attach the DSDT you extracted from Windows? I'll try to recompile those so we can start looking into adding the probes.

However, I can not guarantee to do it immediately, I am taking some time off until the end of the week.

Created attachment 1404920 [details]
DSDT.ASL extracted from windows 10

Ok - feels like windows-Hacker now...

I just extracted the DSDT Table from Windows.

The DSDT was extracted with this tool: http://rweverything.phpnet.us
and this guide: https://github.com/RehabMan/HP-ProBook-4x30s-DSDT-Patch/wiki/How-to-patch-your-DSDT#extracting-your-nativeclean-dsdt-using-windows


I had to use the iasl.exe (https://www.acpica.org/downloads/binary-tools) to decompile and recompile since the asl.exe from microsoft in the guide failed to build the file it extracted (and seriously I can't fix the error).

iasl.exe complained that it does need more tables because some "external control methods" are loaded from them but does compile successfully.

But now I'm stuck - as I do not know anything of the DSDT's language...

Created attachment 1404939 [details]
The binary DSDT extracted from trekstor c13 win10

Created attachment 1404941 [details]
the decompiled DSDT using iasl.exe trekstor c13 win10

This thing compiles using the iasl compiler...

But I do not know what to change...

Created attachment 1404955 [details]
The ASL file extracted with the asl.exe

mhm I noticed a huge size difference between my files and the one from kloxdami thats why I upload this too.

In my experience with working with the primebook C13 DSDT under Linux, you need to do the following to properly disassemble it under Linux

iasl -e ssdt*.dat -d dsdt.dat

This will make it look for external symbols in the ssdt*.dat files.

Then for the Teclast F6 Pro DSDT I also had to make the following changes to get something which would re-assemble without errors:

--- dsdt.dsl.orig 2018-03-02 14:01:12.465650007 +0100
+++ dsdt.dsl    2018-03-04 15:06:32.160220794 +0100
@@ -112,11 +112,9 @@
     External (_TZ_.TZ00, DeviceObj)
     External (_TZ_.TZ01, DeviceObj)
     External (ALSE, UnknownObj)
-    External (BNUM, UnknownObj)    // Conflicts with a later declaration
     External (BRTL, UnknownObj)
     External (CRBI, UnknownObj)
     External (DIDX, UnknownObj)
-    External (FFTB, MethodObj)    // 0 Arguments
     External (GSMI, UnknownObj)
     External (IGDS, UnknownObj)
     External (LHIH, UnknownObj)
@@ -127,8 +125,6 @@
     External (M64B, UnknownObj)
     External (M64L, UnknownObj)
     External (MDBG, MethodObj)    // 1 Arguments
-    External (MMRP, MethodObj)    // 0 Arguments
-    External (MMTB, MethodObj)    // 0 Arguments
     External (P0WK, UnknownObj)
     External (P1GP, UnknownObj)
     External (P1WK, UnknownObj)
@@ -159,8 +155,6 @@
     External (SAT0.NVM3.VLPM, UnknownObj)
     External (SGGP, UnknownObj)
     External (SGMD, UnknownObj)
-    External (TBTD, MethodObj)    // 1 Arguments
-    External (TBTF, MethodObj)    // 1 Arguments
 
     Name (PEBS, 0xE0000000)
     Name (PELN, 0x10000000)

I hope this helps :)

Created attachment 1405496 [details]
the decompiled DSDT using iasl.exe trekstor c13 win10

The successfully extracted DSDT extracted in windows. - no Error on decompilation; a lot of warnings on compiliation.

Now for the part to adjust it.

Created attachment 1405540 [details]
the decompiled DSDT using iasl.exe trekstor c13 win10

Ouch I failed at the previous version... just because iasl does not report an error does not mean it succeeded...

So now the DSDT that sould be better... note that I did not find all external functions in the ssdt's. So I needed some refs.txt where I simply used wildly googled:

External(MDBG, MethodObj, 1)

External(_GPE.MMTB, MethodObj, 0)

External(_SB.PCI0.LPCB.H_EC.ECWT, MethodObj, 2)
External(_SB.PCI0.LPCB.H_EC.ECRD, MethodObj, 1)
External(_SB.PCI0.LPCB.H_EC.ECMD, MethodObj, 1)
External(_SB.PCI0.PEG0.PEGP.SGPO, MethodObj, 2)
External(_SB.PCI0.GFX0.DD02._BCM, MethodObj, 1)
External(_SB.PCI0.SAT0.SDSM, MethodObj, 4)
External(_GPE.VHOV, MethodObj, 3)

Created attachment 1405541 [details]
proposed changes to the dsdt file...

I created a modified DSDT file for my device... do you guys think that is good before I brick my device - I'm a little hesitant with testing because I created it just with "pattern matching".

(In reply to Dietrich from comment #81)
> Created attachment 1405541 [details]
> proposed changes to the dsdt file...

This looks good to me.

(In reply to Hans de Goede from comment #78)
> In my experience with working with the primebook C13 DSDT under Linux, you
> need to do the following to properly disassemble it under Linux
> 
> iasl -e ssdt*.dat -d dsdt.dat
> 
> This will make it look for external symbols in the ssdt*.dat files.
> 
> Then for the Teclast F6 Pro DSDT I also had to make the following changes to
> get something which would re-assemble without errors:
> 
> --- dsdt.dsl.orig 2018-03-02 14:01:12.465650007 +0100
> +++ dsdt.dsl    2018-03-04 15:06:32.160220794 +0100
> @@ -112,11 +112,9 @@
>      External (_TZ_.TZ00, DeviceObj)
>      External (_TZ_.TZ01, DeviceObj)
>      External (ALSE, UnknownObj)
> -    External (BNUM, UnknownObj)    // Conflicts with a later declaration
>      External (BRTL, UnknownObj)
>      External (CRBI, UnknownObj)
>      External (DIDX, UnknownObj)
> -    External (FFTB, MethodObj)    // 0 Arguments
>      External (GSMI, UnknownObj)
>      External (IGDS, UnknownObj)
>      External (LHIH, UnknownObj)
> @@ -127,8 +125,6 @@
>      External (M64B, UnknownObj)
>      External (M64L, UnknownObj)
>      External (MDBG, MethodObj)    // 1 Arguments
> -    External (MMRP, MethodObj)    // 0 Arguments
> -    External (MMTB, MethodObj)    // 0 Arguments
>      External (P0WK, UnknownObj)
>      External (P1GP, UnknownObj)
>      External (P1WK, UnknownObj)
> @@ -159,8 +155,6 @@
>      External (SAT0.NVM3.VLPM, UnknownObj)
>      External (SGGP, UnknownObj)
>      External (SGMD, UnknownObj)
> -    External (TBTD, MethodObj)    // 1 Arguments
> -    External (TBTF, MethodObj)    // 1 Arguments
>  
>      Name (PEBS, 0xE0000000)
>      Name (PELN, 0x10000000)
> 
> I hope this helps :)

I got a lot more errors. The first errors were like you described, but after fixing those a lot others appeared. I don't remember exactly the error msg, but it showed an error in almost all IF statements. I kept commenting them, but they would reappear some lines below.

I'll try to follow the steps again to see if I did something wrong, or at least grab the error messages.

(In reply to Hans de Goede from comment #82)
> (In reply to Dietrich from comment #81)
> > Created attachment 1405541 [details]
> > proposed changes to the dsdt file...
> 
> This looks good to me.

Thank you! I will then proceed in the instructions and try to load it. I'm on a tight shedule the next days so probably it will be sunday until I manage to squeeze it in.

I can then also provide instructions on how to extract the info...

Mhm the spbProbe driver does not get installed for the unknown device.

I downloaded the driverfiles pointed the windows-driver install to the downloads directory and let it search for drivers - It did not find any. And said "the non existend one is already the best one".

This might be because I needed to change the Name(_HID, "spbProbe") line to Name(_HID, "DEBDEB") else compilation failed with the error "spbProbe must be all uppercase and hexadecimal") which I don't understand since other names do have non hexadecimal Characters...

Any idea why it complains?

I now succeded in installing the driver for the probe bz adjusting the name in the .inf file:

line 45: %spbProbe.DeviceDesc%=spbProbe_Device, ACPI\spbProbe
to
line 45: %spbProbe.DeviceDesc%=spbProbe_Device, ACPI\DEBDEBD

Now the probe lists in systemdevices as I2C/SPI Probe Controler Driver.

however the touchpad is not working and reporting:

"""
This device cannot find enough free resources that it can use. (Code 12)

If you want to use this device, you will need to disable one of the other devices on this system.
"""

I already tried removing the Exclusive keyword in both I2CSerialBusV2 lines - however this did not change anything...

Do you have an Idea how I could fix that?

I posted an issue summarizing the problem at the github page... I'll keep it in sync with anything important posted here. - Like that someone looking for similar problems will find the issues discussed here.

link: https://github.com/bentiss/SimplePeripheralBusProbe/issues/1

during writing that summary I noticed that it is not actually the touchpad device that fails with the mentioned error but it is a device related called 'I2C HID Device' - The actual touchpad device vanishes with the new dsdt.

without the dsdt applied it aquires successfully the resource IRQ 0x00000400 (1024)

Created attachment 1406941 [details]
the decompiled DSDT using iasl.exe trekstor c13 linux

I noticed that appart from some minor differences the linux dsdt differs in the third parameter of the I2cSerialBusV2 function:

Line 4435 (win): I2cSerialBusV2 (0x002C, ControllerInitiated, 0x000186A0,
vs.
Line 4433 (lin): I2cSerialBusV2 (0x002C, ControllerInitiated, 0x00061A80,

I did not find any other place where such a number change occurs but I did not scan the whole file as there are lots of differences like LLESS vs. <...

(In reply to Dietrich from comment #88)
> Created attachment 1406941 [details]
> the decompiled DSDT using iasl.exe trekstor c13 linux
> 
> I noticed that appart from some minor differences the linux dsdt differs in
> the third parameter of the I2cSerialBusV2 function:
> 
> Line 4435 (win): I2cSerialBusV2 (0x002C, ControllerInitiated, 0x000186A0,

0x000186A0 is 100 000 -> 100 kHz

> vs.
> Line 4433 (lin): I2cSerialBusV2 (0x002C, ControllerInitiated, 0x00061A80,

0x00061A80 is 400 000 -> 400 kHz

and looking at comment #41, you must have overloaeded the DSDT under linux :)

> 
> I did not find any other place where such a number change occurs but I did
> not scan the whole file as there are lots of differences like LLESS vs. <...

It is very unlikely that the DSDT differs from Windows under Linux. It's written by the OEM and shouldn't depend on the running system (unless they decided to do crazy things, we have seen that in the past).

What differs, is how Linux interprets the DSDT, and the drivers that are running (i2c-hid in this case).

Thanks for digging into the SPBProbe solution, we might have interesting results soon.

For the record, I answered on the github issue already.

(In reply to Benjamin Tissoires from comment #89)
> and looking at comment #41, you must have overloaeded the DSDT under linux :)

Yes that was my doing, on ARM devices I've seen that Silead touchscreens work at 400KHz but not at 100KHz (for some reason) and my own Apollo Lake laptop is using 400 KHz for the i2c-hid touchpad, so I thought that giving 400KHz a try was worth a shot.

Created attachment 1407360 [details]
Log of activation of the touchpad device

I managed to get a log of the touchpad device. I hope you can make sense of it. This file is just the activation sequence. So I deactivated the device before starting the logging and then activated it afterwards.
The logs appeared with a delay of like 2 seconds.

Created attachment 1407361 [details]
Log of activation, move and tap on touchpad.

This is the same log as before with an additional move and tap motion on the touchpad device.

move starts at: 20:01:03.638
tap is at: 20:01:20.791

If I need to do anything else please let me know.

Thanks for the logs. I had a quick look but it doesn't seem to be HID over I2C.

There is one thing I need to double check before definitively say this is a custom driver or not, it's whether the latest versions of Windows caches or not the retrieval of the HID descriptors and the HID report descriptors. If it does, we will have to trick it to not store those values so we get the very first elements.

Created attachment 1408806 [details]
New Log of I2C-HID-Device Init

There is an "i2c-HID-device" (the one that was conflicting before) in addition to the "HID-compatible Touchpad" Device.

This log is from activting this device (I did noch change anything in the DSDT)

When this device is deactivated the Touchpad device vanishes... when it is activated the Touchpad device reappears...

Does this help?

Thanks for the new log, this is much better (in term of HID/i2c protocol).
So from Windows, this is indeed HID over I2C. The HID descriptor is, as said by the DSDT at 0x0020, and the HID report descriptors are at 0x0021 (size 475).

The summary is, if we are able to set the correct parameters from the DSDT under Linux, i2c-hid should be able to deal with this device properly. There is something wrong the device doesn't like while we attempt to communicate with it.

Thank you so much!

I'm eager to test anything... I'm afraid you need to help me though as I do not know how to set those descriptors.

Should I write down my approach for others with the Teclast devices - or does this fix those devices too?

Well, my point is that the device doesn't require anything special, it's a plain HID over I2C device.

The problem lies elsewhere. The fact that the communication with the device fails makes me think of a bug in the i2c adapter. I am not sure how to debug that however.

Are there still any ideas on how to make the touchpad work?

I was wondering if it is possible to treat the touchpad as a simple generic mouse and get at least simple actions with it?

Thanks for any help

(In reply to kloxdami from comment #98)
> Are there still any ideas on how to make the touchpad work?

I am personally currently out of ideas.

> 
> I was wondering if it is possible to treat the touchpad as a simple generic
> mouse and get at least simple actions with it?

I wish it were that simple. The problem is we can not even start talking to the touchpad. So we are not even at the point where we decide about the protocol used.  From a HID point of view, the touchpad doesn't answer.

Mhm the only Thing that still comes to my mind:

could it be that this i2c-hid device is coupled with the fingerprint reader in some form?
I tried to deactivate the I2C-Hid device but the fingerprint reader is still there in contrast to the (separate) touchpad-device. So maybe the theory is wrong.

In any case I tried to write down what I did to decompile and inject the probing device https://github.com/bentiss/SimplePeripheralBusProbe/blob/master/README-IASL.md

I also submitted this in a pull request - which has been merged... thanks for the quick action!

Since I also have bought this particular notebook, I played a little bit with the touchpad. Some things I discovered:

- I opened the case up and the touchpad seems to be a SIPODEV SP1064; about the touchpad or even the company is zero information available
- Touchpad and fingerprint reader seem to be different devices, since there are two flatflex cables going to the touchpad, also the fingerprint reader looks to be an SPI device, whereas the touchpad uses I2C
- There is a SIPO TP Controller application on windows, which is famous for preventing shutdown on windows
- In the directory, where said application resides, there is also a driver (.sys and .inf) called SpPort and a file called SIPOHIDDevice.dll
- This driver is bound to a device in the Device Manager

My guess would be that the touchpad indeed uses a proprietary protocol and that the SpPort driver performs a protocol translation to make it seem like a HID device. This would make sense because what I can read from linux looks very similar to the dump from Comment 92 (every message starting with 1b 00 04).

So I tried to decode the protocol and read from the touchpad from linux. So far I can extract the x and y positions for 1-3 fingers and detect a mouse click. A small test program is uploaded at https://github.com/brotfessor/sipodev .

Maybe this is a starting point...

So Thank you so much for your work!

I tried your tool... I had to change for the adapter_nr=7;
The fedora i2c-dev package is called libi2c-devel

I'd say it reliably detects when there is one two or three fingers on the touchpad... It also detects clicks.

It detects some extra clicks sometimes when doing absolutely nothing.

It only detects fingers when they change positions.

I don't understand the coordinates - they seem to be hexadecimal and the changes are huge when almost no change in position happens...

So far should we continue the development in your github repos?

I can provide with any info you need - though I never developed anything this close to hardware...

could it work to decompile the windows translation driver?

Actually the coordinates make sense so scratch that remark.

Great work!

I tested your program and it was able to detect finger positions and clicks. For some reason, the coordinates show even after I remove the fingers. So even if I have only one finger in the touchpad, it will show three coordinates. 

I also experienced the extra clicks.

I've noticed that the value in 0x19 is the number of fingers detected, and that it detects up to 4 fingers accurately. Registers 0x13 to 0x16 seems to be the fourth finger coordinates.

I made some changes to show coordinates only when the fingers are detected and it shows only the finger coordinates if the finger is detected. The results were better for me. 

The registers 0x03 and 0x08 seem to be status bytes, as you noticed, and I think reg[0x03] == 0x01 means a tap, and reg[0x08] == 0x07 means scrolling, but for some reason these values get stuck (like the coordinates) and don't refresh after you remove the fingers, so the output I show is not really accurate.

A temporary solution might be to call xdotool in the program to simulate the mouse.

Created attachment 1422651 [details]
i2ctest.c with some changes

Created attachment 1422654 [details]
decoded protocol from dump in comment #92

To avoid you loosing too much time decoding the protocol, I translated here the logs from the dump in comment #92 to human readable form.

Instead of parsing it manually, and injecting events, you might find more useful to create a new uhid device (see [1] for an example), and just redirect the input from i2c-dev to the uhid node. Inject the report descriptors from the comment #92, and stip out the first "0x1b" in the events that corresponds to the size of the report.

The code should not grow much more compared to what you currently have but will allow you to have an actual kernel device with all the facilities enabled.

Still, I don't know why the touchpad refuses to send the initial HID descriptor.



[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/samples/uhid/uhid-example.c

First of all thank you all for your comments and additions. I finally got the touchpad in a working state, without using any userspace tools.

As Benjamin Tissoires suspected, the touchpad does indeed speak HID, but for some reason it is unable to supply any descriptors (maybe to save rom in the touchpad IC). So after adding a dirty hack into the i2c_hid driver that hardcodes the HID and the report descriptor, the touchpad works exactly how it is supposed to. So the "protocol translation driver" on windows seems to simply provide the necessary descriptors.

A patch is located in my github repo. Keep in mind that this is a dirty, dirty hack and i2c_hid won't work with another device anymore, but the touchpad is usable. If someone could tell me how to implement this in a upstream-ready fashion, I can create a proper patch :)

(In reply to Julian Sax from comment #107)
> As Benjamin Tissoires suspected, the touchpad does indeed speak HID, but for
> some reason it is unable to supply any descriptors (maybe to save rom in the
> touchpad IC). So after adding a dirty hack into the i2c_hid driver that
> hardcodes the HID and the report descriptor, the touchpad works exactly how
> it is supposed to. So the "protocol translation driver" on windows seems to
> simply provide the necessary descriptors.

Cool, I was thinking the same time after reading some of the previous mails so I think your analysis is spot on. Also man this sucks, but we should be able to work around it...

> A patch is located in my github repo. Keep in mind that this is a dirty,
> dirty hack and i2c_hid won't work with another device anymore, but the
> touchpad is usable. If someone could tell me how to implement this in a
> upstream-ready fashion, I can create a proper patch :)

Tricky, I'm thinking among these lines atm:

struct i2c_hid_desc_override {
     struct i2c_hid_desc *i2c_hid_desc;
     char                *hid_report_desc;
     unsigned int         hid_report_desc_size;
};


static const struct i2c_hid_desc_override sipodev_desc = {
      // FIXME: Initialize me
};

static const struct dmi_system_id i2c_hid_dmi_desc_override_table[] = {
        {
         .ident = "Teclast F6 Pro",
         .matches = {
                DMI_MATCH(DMI_SYS_VENDOR, "FIXME"),
                DMI_MATCH(DMI_PRODUCT_NAME, "FIXME"),
                },
         .driver_data = (void *)&sipodev_desc;
        },

struct i2c_hid_desc *i2c_hid_get_dmi_i2c_hid_desc_override(void)
{
        struct i2c_hid_desc_override *override;
        const struct dmi_system_id *system_id;
        
        system_id = dmi_first_match(i2c_hid_dmi_desc_override_table);
        if (!system_id)
                 return NULL;

        override = system_id->driver_data;
        return override->i2c_hid_desc;
}

const char *i2c_hid_get_dmi_hid_report_desc_override(unsigned int *size)
{
        struct i2c_hid_desc_override *override;
        const struct dmi_system_id *system_id;
        
        system_id = dmi_first_match(i2c_hid_dmi_desc_override_table);
        if (!system_id)
                 return NULL;

        override = system_id->driver_data;
        *size = override->hid_report_desc_size;
        return override->hid_report_desc;
}

And then in the places where we get the i2c_hid_desc / hid_report_desc call these before talking to the device and if they return non NULL use the returned data instead of querying the device.

Then stick all this "crap" (accept for the calls to the 2 new functions) in a new drivers/hid/i2c-hid/i2c-hid-dmi-quirks.c file, to keep the main i2c-hid.c readable.

Also drivers/hid/i2c-hid/i2c-hid-dmi-quirks.c should only be built when on x86 (let us know if you need help how to put that in the Makefile) and we need a drivers/hid/i2c-hid/i2c-hid.h with:

#ifdef CONFIG_X86
struct i2c_hid_desc *i2c_hid_get_dmi_i2c_hid_desc_override(void);
const char *i2c_hid_get_dmi_hid_report_desc_override(unsigned int *size);
#else
static inline struct i2c_hid_desc *i2c_hid_get_dmi_i2c_hid_desc_override(void)
{ return NULL; }
static inline const char *i2c_hid_get_dmi_hid_report_desc_override(unsigned int *size)
{ return NULL; }
#endif

Benjamin what is your take on my above suggestion?

(In reply to Hans de Goede from comment #108)
> Benjamin what is your take on my above suggestion?

This would make the driver working, for sure, but I have a feeling we can do something smarter that doesn't involve quirking i2c-hid.

Few points to consider (I am just putting words on my thoughts, so it's not *the* solution(s)):
- maybe we could think at a solution in the same way the windows probe I wrote works: a driver that binds for this ACPI pnp id only and bypasses everything but some features like HID descriptors/report descriptors
- or I'd like to have a more generic "firmware" handling as we discussed at XDC in Bordeaux.

I am not against this solution, but I have the feeling that we do not have the ideal one here, and I'd rather have a solution we could ship on existing kernels without having to rebuild i2c-hid.

Hi,

(In reply to Benjamin Tissoires from comment #109)
> (In reply to Hans de Goede from comment #108)
> > Benjamin what is your take on my above suggestion?
> 
> This would make the driver working, for sure, but I have a feeling we can do
> something smarter that doesn't involve quirking i2c-hid.
> 
> Few points to consider (I am just putting words on my thoughts, so it's not
> *the* solution(s)):
> - maybe we could think at a solution in the same way the windows probe I
> wrote works: a driver that binds for this ACPI pnp id only and bypasses
> everything but some features like HID descriptors/report descriptors

This sounds like the Windows filter driver concept, I'm pretty sure the Windows install is using some sort of i2c filter driver to make things work.

Something like that might be interesting to have, but seems like a lot of engineering work, esp. for something which is very likely to only be used in combination with the i2c-hid code. Or do you know of other i2c drivers where such a filter driver concept would make sense?

> - or I'd like to have a more generic "firmware" handling as we discussed at
> XDC in Bordeaux.

I'm afraid my memory is failing me there, that is quite some time ago, can you explain this a bit more?

> I am not against this solution, but I have the feeling that we do not have
> the ideal one here, and I'd rather have a solution we could ship on existing
> kernels without having to rebuild i2c-hid.

Hmm, even a filter driver like concept would need to be a kernel driver, unless you want to pass all i2c traffic through userspace which is going to be very problematic wrt latency.

TBH I think you might be falling into the perfect is the enemy of good trap here, I think that for now we should move forward with something as I suggest, then if in the future we come up with a more generic (in kernel) solution we can move over to that.

Regards,

Hans

(In reply to Hans de Goede from comment #110)
> Hi,
> 
> (In reply to Benjamin Tissoires from comment #109)
> > (In reply to Hans de Goede from comment #108)
> > > Benjamin what is your take on my above suggestion?
> > 
> > This would make the driver working, for sure, but I have a feeling we can do
> > something smarter that doesn't involve quirking i2c-hid.
> > 
> > Few points to consider (I am just putting words on my thoughts, so it's not
> > *the* solution(s)):
> > - maybe we could think at a solution in the same way the windows probe I
> > wrote works: a driver that binds for this ACPI pnp id only and bypasses
> > everything but some features like HID descriptors/report descriptors
> 
> This sounds like the Windows filter driver concept, I'm pretty sure the
> Windows install is using some sort of i2c filter driver to make things work.
> 
> Something like that might be interesting to have, but seems like a lot of
> engineering work, esp. for something which is very likely to only be used in
> combination with the i2c-hid code. Or do you know of other i2c drivers where
> such a filter driver concept would make sense?

Not that I can think of. I agree it's a lot of engineering, but once we get this one in it, nobody will push for a proper engineering, which is why I'd like to at least consider our options instead of just merging yet an other quirking mechanism at an other place.

> 
> > - or I'd like to have a more generic "firmware" handling as we discussed at
> > XDC in Bordeaux.
> 
> I'm afraid my memory is failing me there, that is quite some time ago, can
> you explain this a bit more?

This was relative to the Wacom tablets not providing proper HID report descriptors. The idea was that hid-core would load a firmware file that would provide the fixed report descriptor. This way, we could just drop a file in the firmware tree, and have the new device fixed as long as the kernel supports it.

I remember you having IP concerns, if this helps remembering :)

> 
> > I am not against this solution, but I have the feeling that we do not have
> > the ideal one here, and I'd rather have a solution we could ship on existing
> > kernels without having to rebuild i2c-hid.
> 
> Hmm, even a filter driver like concept would need to be a kernel driver,
> unless you want to pass all i2c traffic through userspace which is going to
> be very problematic wrt latency.

No, passing everything to userspace would not help much here. We can just use i2c-dev and uhid if we want the userspace solution. So yes, this would be a kernel driver, but I'd like to keep i2c-hid device agnostic (I know, we already have a few quirks in place there)

> 
> TBH I think you might be falling into the perfect is the enemy of good trap
> here, I think that for now we should move forward with something as I
> suggest, then if in the future we come up with a more generic (in kernel)
> solution we can move over to that.
> 

Yeah, I like to be an optimistic dreamer :)

Wording the first solution I proposed here as filtering made me realize we just need to override the __i2c_hid_command() instead of having multiple overrides. I still like the idea of having a separate kernel driver for the filtering, so I'll stick on thinking more at such a solution :)

Hello everybody, I have got similar laptop, this time it is Mediacom SB143. It seems to use same touchpad, but marketed as ALPS, which does not work.

I have checked with kernel patched with sipodev-quirk.patch from https://github.com/brotfessor/sipodev but it still does not work. 
What follows is a small xorg excerpt:


Apr 19 08:39:04 localhost /usr/libexec/gdm-x-session[1481]: (II) config/udev: Adding input device ALPS0001:00 0911:5288 Touchpad (/dev/input/event8)
Apr 19 08:39:04 localhost /usr/libexec/gdm-x-session[1481]: (**) ALPS0001:00 0911:5288 Touchpad: Applying InputClass "evdev touchpad catchall"
Apr 19 08:39:04 localhost /usr/libexec/gdm-x-session[1481]: (**) ALPS0001:00 0911:5288 Touchpad: Applying InputClass "libinput touchpad catchall"
Apr 19 08:39:04 localhost /usr/libexec/gdm-x-session[1481]: (II) Using input driver 'libinput' for 'ALPS0001:00 0911:5288 Touchpad'
Apr 19 08:39:04 localhost /usr/libexec/gdm-x-session[1481]: (II) systemd-logind: got fd for /dev/input/event8 13:72 fd 28 paused 0
Apr 19 08:39:04 localhost /usr/libexec/gdm-x-session[1481]: (**) ALPS0001:00 0911:5288 Touchpad: always reports core events
Apr 19 08:39:04 localhost /usr/libexec/gdm-x-session[1481]: (**) Option "Device" "/dev/input/event8"
Apr 19 08:39:04 localhost /usr/libexec/gdm-x-session[1481]: (**) Option "_source" "server/udev"
Apr 19 08:39:04 localhost /usr/libexec/gdm-x-session[1481]: (II) event8  - ALPS0001:00 0911:5288 Touchpad: is tagged by udev as: Touchpad
Apr 19 08:39:04 localhost /usr/libexec/gdm-x-session[1481]: (II) event8  - ALPS0001:00 0911:5288 Touchpad: device is a touchpad
Apr 19 08:39:04 localhost /usr/libexec/gdm-x-session[1481]: (II) event8  - ALPS0001:00 0911:5288 Touchpad: device removed
Apr 19 08:39:04 localhost /usr/libexec/gdm-x-session[1481]: (**) Option "config_info" "udev:/sys/devices/pci0000:00/0000:00:17.0/i2c_designware.4/i2c-8/i2c-ALPS0001:00/0018:0911:5288.
0003/input/input11/event8"
Apr 19 08:39:04 localhost /usr/libexec/gdm-x-session[1481]: (II) XINPUT: Adding extended input device "ALPS0001:00 0911:5288 Touchpad" (type: TOUCHPAD, id 11)
Apr 19 08:39:04 localhost /usr/libexec/gdm-x-session[1481]: (**) Option "AccelerationScheme" "none"
Apr 19 08:39:04 localhost /usr/libexec/gdm-x-session[1481]: (**) ALPS0001:00 0911:5288 Touchpad: (accel) selected scheme none/0
Apr 19 08:39:04 localhost /usr/libexec/gdm-x-session[1481]: (**) ALPS0001:00 0911:5288 Touchpad: (accel) acceleration factor: 2.000
Apr 19 08:39:04 localhost /usr/libexec/gdm-x-session[1481]: (**) ALPS0001:00 0911:5288 Touchpad: (accel) acceleration threshold: 4
Apr 19 08:39:04 localhost /usr/libexec/gdm-x-session[1481]: (II) event8  - ALPS0001:00 0911:5288 Touchpad: is tagged by udev as: Touchpad
Apr 19 08:39:04 localhost /usr/libexec/gdm-x-session[1481]: (II) event8  - ALPS0001:00 0911:5288 Touchpad: device is a touchpad
Apr 19 08:39:04 localhost /usr/libexec/gdm-x-session[1481]: (II) config/udev: Adding input device ALPS0001:00 0911:5288 Touchpad (/dev/input/mouse1)


What information can I provide? What possible tests can I carry on?

(In reply to Nenad Opsenica from comment #112)
> Hello everybody, I have got similar laptop, this time it is Mediacom SB143.
> It seems to use same touchpad, but marketed as ALPS, which does not work.
> 
> I have checked with kernel patched with sipodev-quirk.patch from
> https://github.com/brotfessor/sipodev but it still does not work. 
> What follows is a small xorg excerpt:
> 
> 
> Apr 19 08:39:04 localhost /usr/libexec/gdm-x-session[1481]: (II)
> config/udev: Adding input device ALPS0001:00 0911:5288 Touchpad
> (/dev/input/event8)

Clearly you have a different problem. Your touchpad is enumerated through i2c-hid, while here the touchpad doesn't even appear in xorg.log.

> What information can I provide? What possible tests can I carry on?

Please open a new bug, add a hid-recorder log (package hid-replay) and a full dmesg.

Thanks!

I compiled the kernel changing the original i2c-hid.c to the modified i2c-hid.c in Julian Sax's github and the touchpad is working fine. For me that solved the problem entirely. 

I hope you can figure out a cleaner/official solution for the problem.

Thanks for all the help!

As the initial reporter I can indeed confirm that this patch puts the touchpad in a working state.

So we finally found the issue!

Thanks guys!

If I can help with anything for the official solution I'll happily do so. So please tell me!

I tested this on my Teclast F7, finally I can use linux on this laptop, thanks.

Sorry for the long delay, I was too busy the last days.
Regarding a mainline solution, although I don't have too much experience writing kernel drivers, if someone could point me in the right direction on how to implement this as a separate driver that sneaks in between the i2c subsystem and the i2c-hid driver (assuming that is what Benjamin Tissoires meant with the "optimistic" solution), I will have a go at this. I just can't think of a solution that doesn't involve quirking either i2c or i2c-hid.

(In reply to Benjamin Tissoires from comment #111)
> I still like the idea of having a separate kernel driver for the
> filtering, so I'll stick on thinking more at such a solution :)

So have you come up with a workable solution for this? If not I think it might be best to move forward with my proposal for now?

(In reply to Hans de Goede from comment #118)
> (In reply to Benjamin Tissoires from comment #111)
> > I still like the idea of having a separate kernel driver for the
> > filtering, so I'll stick on thinking more at such a solution :)
> 
> So have you come up with a workable solution for this? If not I think it
> might be best to move forward with my proposal for now?

Yeah, sorry I couldn't get to it. We should probably have your solution instead of waiting on me.

Ok.

Julian, do you think you can turn your hacked i2c-dev.c changes into a patch for upstream, using the outline / sketch I gave in comment 108?

Yes, I will do that.

Could the owners of the Teclast F6 Pro and the Teclast F7 please tell me their DMI strings so I can include those? These should be at

/sys/class/dmi/id/sys_vendor and /product_name

(In reply to Julian Sax from comment #121)
> Yes, I will do that.
> 
> Could the owners of the Teclast F6 Pro and the Teclast F7 please tell me
> their DMI strings so I can include those? These should be at
> 
> /sys/class/dmi/id/sys_vendor and /product_name

I have a teclast f7

quark@f7:~$ cat /sys/class/dmi/id/sys_vendor
TECLAST
quark@f7:~$ cat /sys/class/dmi/id/product_name 
F7

(In reply to Bruno Jesus from comment #122)
> quark@f7:~$ cat /sys/class/dmi/id/sys_vendor
> TECLAST
> quark@f7:~$ cat /sys/class/dmi/id/product_name 
> F7

Julian, "F7" is likely to have collisions, better use DMI_EXACT_MATCH() there. I guess we should probably use DMI_EXACT_MATCH() for the DMI strings everywhere.

A normal DMI_MATCH() matches e.g. "*F7*" which means that say an "F7Pro" would also match without the EXACT match.

So, the first attempt is uploaded at my repo. As this is my first "real" kernel patch, please tell me what can be improved. 
I have used the DMI_EXACT_MATCH() macro and the architecture selection seems to work. But I can not seem to figure out how to put the second file in the Makefile properly. When I add a simple 

i2c-hid-objs += i2c-hid-dmi-quirks.o

the normal i2c-hid.c gets not built and with a

i2c-hid-objs += i2c-hid-dmi-quirks.o i2c-hid.o

make complains about some recursive dependency. At the moment I have renamed the module name to be able to build it. If someone could help me there...

(In reply to Julian Sax from comment #124)
> So, the first attempt is uploaded at my repo.

Awesome, thank you for working on this.

> As this is my first "real"
> kernel patch, please tell me what can be improved. 

I'm currently on vacation, I will take a detailed look next week.

> I have used the DMI_EXACT_MATCH() macro and the architecture selection seems
> to work. But I can not seem to figure out how to put the second file in the
> Makefile properly. When I add a simple 
> 
> i2c-hid-objs += i2c-hid-dmi-quirks.o
> 
> the normal i2c-hid.c gets not built and with a
> 
> i2c-hid-objs += i2c-hid-dmi-quirks.o i2c-hid.o
> 
> make complains about some recursive dependency. At the moment I have renamed
> the module name to be able to build it. If someone could help me there...

I'm afraid there is no other way but to either rename the module or the .c file, probably best to just rename the .c file, so do:

git mv drivers/hid/i2c-hid/i2c-hid.c drivers/hid/i2c-hid/i2c-hid-core.c

And then in the Makefile you should have something like this:

i2c-hid-objs = i2c-hid-core.o
i2c-hid-$(CONFIG_X86) += i2c-hid-dmi-quirks.o

And as said before add a drivers/hid/i2c-hid/i2c-hid.c with the following in there for the prototypes:

#ifdef CONFIG_X86
struct i2c_hid_desc *i2c_hid_get_dmi_i2c_hid_desc_override(void);
const char *i2c_hid_get_dmi_hid_report_desc_override(unsigned int *size);
#else
static inline struct i2c_hid_desc *i2c_hid_get_dmi_i2c_hid_desc_override(void)
{ return NULL; }
static inline const char *i2c_hid_get_dmi_hid_report_desc_override(unsigned int *size)
{ return NULL; }
#endif

This way all the DMI stuff becomes a nop on non x86 arches

Thinking more about this you probably will want to check for CONFIG_DMI instead of CONFIG_X86 as DMI is the actual X86 only feature we are using here.

(In reply to Julian Sax from comment #121)
> Yes, I will do that.
> 
> Could the owners of the Teclast F6 Pro and the Teclast F7 please tell me
> their DMI strings so I can include those? These should be at
> 
> /sys/class/dmi/id/sys_vendor and /product_name

Hello

On a teclast F6 pro

===============================================
F6pro:~> cat /sys/class/dmi/id/sys_vendor
TECLAST
F6pro:~> cat /sys/class/dmi/id/product_name 
F6 Pro
===============================================

Kudos to all for your efforts

I installed Linux on my Trekstor C11 recently, so I'm really interested in this patch. But I'm not sure how to understand this thread. Is Julians patch for Trekstor, for Teclast or for all devices?

Hey,
the patch from julian should "work" - meaning it kills every i2c-hid-functionality but the touchpad...

For me (Trekstor C13) a kernel with the following patch had a working touchpad:
https://github.com/brotfessor/sipodev/blob/master/sipodev-quirk.patch
(as this is the only i2c-hid device on the laptop basically the laptop is fully functional)

If you provide the following the Trekstor C11 can be included into the "quirk-list" and the function once the patch is accepted upstream:

$ cat /sys/class/dmi/id/sys_vendor
$ cat /sys/class/dmi/id/product_name

@ others -anything else needed?

(In reply to Dietrich from comment #128)

Thanks for your answer. The output of this commands is the following:

$ cat /sys/class/dmi/id/sys_vendor 
TREKSTOR
$ cat /sys/class/dmi/id/product_name 
Primebook C11

Silly question, but what is a quirk-list?

Hello!

I have a Teclast F7 and i did the substitution of the i2c-hid.c in kernel source and the compiled it in antergos arch linux. All went well and i successfully had a working mousepad.

Now i installed ubuntu and want to use the patch. But im a noob and dont know how to do it. Saw a lot of videos, but nothing helped me in this task.

Can you guys help a noob with instructions of how to do it?

I think these steps would help a lot of teclast users.

Thanks in advance.

Filipe Granja

(In reply to Filipe Granja from comment #130)
> Hello!
> 
> I have a Teclast F7 and i did the substitution of the i2c-hid.c in kernel
> source and the compiled it in antergos arch linux. All went well and i
> successfully had a working mousepad.
> 
> Now i installed ubuntu and want to use the patch. But im a noob and dont
> know how to do it. Saw a lot of videos, but nothing helped me in this task.
> 
> Can you guys help a noob with instructions of how to do it?
> 
> I think these steps would help a lot of teclast users.
> 
> Thanks in advance.
> 
> Filipe Granja

I did a simple guide here: http://strangequark.tk/index.php/blog/20180423_teclastf7linux

it does not work. When i insert "sudo apt-get source linux-image-$(uname -r)" it does this:

Reading package lists... Done
Picking 'linux-signed' as source package instead of 'linux-image-4.15.0-20-generic'
Need to get 17,8 kB of source archives.
Get:1 http://archive.ubuntu.com/ubuntu bionic/main linux-signed 4.15.0-20.21 (dsc) [2101 B]
Get:2 http://archive.ubuntu.com/ubuntu bionic/main linux-signed 4.15.0-20.21 (tar) [15,7 kB]
Fetched 17,8 kB in 2s (7568 B/s)      
dpkg-source: info: extracting linux-signed in linux-signed-4.15.0
dpkg-source: info: unpacking linux-signed_4.15.0-20.21.tar.xz

So i think its not the source kernel but some short version of it, because the file that i must replace its not in the folders or even in my entire ssd.

in antergos i just downloaded the kernel from kernel.org, replace the file and 
compiled. That was it.

in Ubuntu 18.04 i cant seem to download or compile anything.

(In reply to Filipe Granja from comment #132)
> it does not work. When i insert "sudo apt-get source linux-image-$(uname
> -r)" it does this:
> 
> Reading package lists... Done
> Picking 'linux-signed' as source package instead of
> 'linux-image-4.15.0-20-generic'
> Need to get 17,8 kB of source archives.
> Get:1 http://archive.ubuntu.com/ubuntu bionic/main linux-signed 4.15.0-20.21
> (dsc) [2101 B]
> Get:2 http://archive.ubuntu.com/ubuntu bionic/main linux-signed 4.15.0-20.21
> (tar) [15,7 kB]
> Fetched 17,8 kB in 2s (7568 B/s)      
> dpkg-source: info: extracting linux-signed in linux-signed-4.15.0
> dpkg-source: info: unpacking linux-signed_4.15.0-20.21.tar.xz
> 
> So i think its not the source kernel but some short version of it, because
> the file that i must replace its not in the folders or even in my entire ssd.
> 
> in antergos i just downloaded the kernel from kernel.org, replace the file
> and 
> compiled. That was it.
> 
> in Ubuntu 18.04 i cant seem to download or compile anything.

Try downloading from the git repo:
git clone git://kernel.ubuntu.com/ubuntu/ubuntu-bionic.git
or this if the above does not work:
git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
For ubuntu support I recommend you to go to the #ubuntu irc channel on freenode.

Quick status update:
The patch does now use CONFIG_DMI and i2c-hid.c is renamed.
Also I have included the Primebook C11. Thanks for that!

What also comes to my mind... we should probably make sure that there is no other device on all these laptops that we kill with this patch. As for my Primebook C13 there is no other i2c-hid-device, so this looks to be ok.
Could the owners of the other devices please take a quick look at
/sys/module/i2c_hid/drivers/i2c:i2c_hid/ and e.g  dmesg | grep i2c_hid
and make sure that there is no other device apart from the touchpad that uses this driver?

@ahormann Comment 129 :
The quirk list is basically a list of the laptops that are known to use this touchpad and therefore need this patch. This will at some time be included in the main linux kernel so you don't have to compile your own kernel for using the laptop.

(In reply to Julian Sax from comment #134)
> Quick status update:
> The patch does now use CONFIG_DMI and i2c-hid.c is renamed.
> Also I have included the Primebook C11. Thanks for that!
> 
> What also comes to my mind... we should probably make sure that there is no
> other device on all these laptops that we kill with this patch. As for my
> Primebook C13 there is no other i2c-hid-device, so this looks to be ok.
> Could the owners of the other devices please take a quick look at
> /sys/module/i2c_hid/drivers/i2c:i2c_hid/ and e.g  dmesg | grep i2c_hid
> and make sure that there is no other device apart from the touchpad that
> uses this driver?
> 
> @ahormann Comment 129 :
> The quirk list is basically a list of the laptops that are known to use this
> touchpad and therefore need this patch. This will at some time be included
> in the main linux kernel so you don't have to compile your own kernel for
> using the laptop.

I only got i2c-SYNA3602:00 and module under /sys/module/i2c_hid/drivers/i2c:i2c_hid

In dmesg I got the i2c-SYNA3602:00

I forgot to tell you that I ran this on a Teclast F7, sorry.

My C11 tells me wit dmesg:

dmesg | grep i2c_hid
[    5.364822] i2c_hid i2c-SYNA3602:00: i2c-SYNA3602:00 supply vdd not found, using dummy regulator
[    5.369625] i2c_hid i2c-SYNA3602:00: unexpected HID descriptor bcdVersion (0x00ff)

ls in this directory says "bind  module  uevent  unbind", if you need this.


No idea, what this means. 
I'll try to compile the kernel this night, hope it works.

Hello,

I just bought a Thomson TH14-X6 that seems to be a copy of Jumper Ezbook Pro 3 which is better know.
The touchpad (SYNA3502) does not work.

#  cat /sys/class/dmi/id/sys_vendor /sys/class/dmi/id/product_name 
Thomson
X6-4.32GR

# sudo dmesg | grep -i syna
[   11.148765] i2c_hid i2c-SYNA3602:00: i2c_hid_get_input: incomplete report (32/261)
[   11.150933] i2c_hid i2c-SYNA3602:00: i2c_hid_get_input: incomplete report (32/8713)
[   11.152120] i2c_hid i2c-SYNA3602:00: i2c_hid_get_input: incomplete report (32/261)
[   11.155324] i2c_hid i2c-SYNA3602:00: i2c_hid_get_input: incomplete report (32/23334)
[   11.165120] i2c_hid i2c-SYNA3602:00: i2c_hid_get_input: incomplete report (32/20745)
[   11.170442] i2c_hid i2c-SYNA3602:00: i2c_hid_get_input: incomplete report (32/31302)
[   11.171537] i2c_hid i2c-SYNA3602:00: i2c_hid_get_input: incomplete report (32/29952)
[   11.175831] i2c_hid i2c-SYNA3602:00: i2c_hid_get_input: incomplete report (32/22281)
[   12.090078] input: SYNA3602:00 0911:5288 Touchpad as /devices/pci0000:00/0000:00:16.1/i2c_designware.1/i2c-6/i2c-SYNA3602:00/0018:0911:5288.0003/input/input20
[   12.090919] hid-multitouch 0018:0911:5288.0003: input,hidraw2: I2C HID v1.00 Mouse [SYNA3602:00 0911:5288] on i2c-SYNA3602:00


I compiled the Linux kernel and modules from Julian Sax's modified file i2c-hid.c (https://github.com/brotfessor/sipodev/blob/master/b/i2c-hid.c). But the touchpad is still not functional.

Unfortunately, I can not use the i2ctest.c program. I modified the variable "adapter_nr" with the correct value (6) and error messages are displayed.

# ls -l /sys/bus/i2c/devices/i2c-* | grep SYNA
lrwxrwxrwx 1 root root 0 mai   10 00:10 /sys/bus/i2c/devices/i2c-SYNA3602:00 -> ../../../devices/pci0000:00/0000:00:16.1/i2c_designware.1/i2c-6/i2c-SYNA3602:00
# sudo modprobe i2c_dev
# ./i2ctest both
Error opening
# sudo ./i2ctest both
Error setting address

(In reply to Olivier Fock from comment #138)
> Hello,
> 
> I just bought a Thomson TH14-X6 that seems to be a copy of Jumper Ezbook Pro
> 3 which is better know.
> The touchpad (SYNA3502) does not work.

AFAIK the Jumper Ezbook Pro 3 touchpad has a different problem then the one being discussed in this bug. Some people report it working when doing a "rmmod i2c-hid; modprobe i2c-hid" after a suspend resume.

I tried the recommended tutorial on http://strangequark.tk/index.php/blog/20180423_teclastf7linux, but like Filipe i cant download the whole kernel with apt-get and with the kernel from kernel.org i always get errors.
 
So i tried this Guide 
https://medium.freecodecamp.org/building-and-installing-the-latest-linux-kernel-from-source-6d8df5345980

This worked great on Xubuntu (Treksor C11) and i have a working touchpad. In this 5 minutes i didnt found any disadvantages, hope this stays.

Thank you so much for this patch and the great support!!!

Julian,

I just took a look at:
https://github.com/brotfessor/sipodev/blob/master/properpatch/patch3.patch

Overal this looks good, you need to change the:

}
else {

style, to:

} else {

To match the kernel coding style and you should probably run checkpatch.pl on the patch before submitting it upstream, but other then that it looks ready to submit it upstream.

Can you please submit the patch upstream with me in the Cc? See:
https://www.kernel.org/doc/html/latest/process/submitting-patches.html

Regards,

Hans

I have one more question @Hans de Goede. You (or someone with your name) once uploaded a patch for Trekstor C13s Touchscreen. Could you please help me adding the C11 to?

Hey @ahornmann,

this was also done in this bugreport... Quite cluttered...

In comment 5 I did describe how to extract the Firmware... Is it the same as for the C13?

Also comment 3 and 9 are very interesting regarding that topic.

In short you need to get the firmwarefile, with it the touchscreen works but the cursor is not at the right position. Then you or have to get the correct maximum and minimum x and y coordinates.

With those you or someone else can patch the silead_touch.c file. For the correct calibration. Then you build your kernel or wait til it hits your distro.

Oh, didnt see that, thank you!
Looks complicated...I'll have a detailed look on it when I have more time.

All right. I took a look at the windows drivers. There aren't any .h or .fw files and diff tells me, that the .sys file is different from the one for C13. So i tried to follow the instructions of the guide (ran the given scripts) you linked in comment 5 and managed to get a .fw-file. But i was not able to find out how to test this file. The web says i have to place it in /lib/firmware, but this hasnt any effect...

Hi @ahornmann,

you have to put the .fw file in a subdirectory under /lib/firmware/silead/.

I had several tries to extract the C11 touchscreen firmware but all of them lead to a not fully working state...maybe you are more talented then me.

You have to put the few file with the name that appears in the log into the mentioned directory.

Then the touchpad should "work" - meaning it reacts to input but it is not calibrated.

But now you can read out the values for its calibration using the instructions from #3 with the evemu-record command.

You have to put the few file with the name that appears in the log into the mentioned directory.

Then the touchpad should "work" - meaning it reacts to input but it is not calibrated.

But now you can read out the values for its calibration using the instructions from #3 with the evemu-record command.

Then you post those numbers here or in a new bug and you hope that someone will create a kernelpatch.

Thank you.
I did some kind of guessing filenames and files and random replacement in the C13-Touchscreen-part of the Kernel and now the touchscreen "works" (Kernel with only Touchpad-patch doesn't even recognize the screen, so i replaced every 13 with a 11 and inserted my screen resolution). 
The biggest/smallest values i archieved with evemu are:
 
top, left:        3, 1531
top, right:    1900, 1513
bottom, left:     1,   31
bottom, right: 1888,   15

Since 0 is bottom, left the touch is mirrored in the middle, but is horrible calibrated in other respects too.

Oh, and all this points are x,y

Okay, I tried adding 

static const struct property_entry trekstor_primebook_c11_props[] = {
	PROPERTY_ENTRY_U32("touchscreen-size-x", 1920),
	PROPERTY_ENTRY_U32("touchscreen-size-y", 1530),
	PROPERTY_ENTRY_STRING("firmware-name",
			      "gsl1680-trekstor-primebook-c11.fw"),
	PROPERTY_ENTRY_U32("silead,max-fingers", 10),
	PROPERTY_ENTRY_BOOL("silead,home-button"),
	PROPERTY_ENTRY_BOOL("touchscreen-inverted-y"),
	{ }
};

static const struct silead_ts_dmi_data trekstor_primebook_c11_data = {
	.acpi_name	= "MSSL1680:00",
	.properties	= trekstor_primebook_c11_props,
};


to silead_dmi.c and its working acceptable now, not inverted anymore and often the click is near the touched point. But no moving, scrolling, zooming,... possible and some points seem to be blind.
Any ideas?

(In reply to ahormann from comment #151)
> to silead_dmi.c and its working acceptable now, not inverted anymore and
> often the click is near the touched point. But no moving, scrolling,
> zooming,... possible and some points seem to be blind.
> Any ideas?

Cool that you almost have it working, if you have dead-zones which are not dead under Windows, then you're using the wrong firmware. Sometimes the SileadTouch.sys file contains multiple firmware versions, so check if the "0xff 0x00 0x00 0x00 0x02" sequence is in there more then once and try another version.

Also there might be a SileadTouch.fw or a GSL_TS_CFG.h file on the Windows partition which is used instead of the embedded copy. Anyways of you've dead zones either your touchscreen is physically broken (this might be invisible) or you've the wrong firmware.

Youmay also have extracted the firmware in such a way that you are using an incomplete copy (unlikely).

Also see: https://github.com/onitake/gsl-firmware

Almost working would be exaggerated. Sometimes i start the system and it "works", often it doesn't recognize the screen at all (yesterday i didnt knew this...)

With Windows the touchscreen works great.
I'm pretty sure that my firmware is bullshit, because what i extracted hadn't any result.
So I ended up using firmware of other devices...not good.

There isnt any .h or .fw file neither in System32 nor in the downloadable drivers.

@Hans de Goede Thanks a lot for your help!

Now it finally works! 
No multitouch, but i didn't expect this.

I pushed kind of introduction and the files on 
https://github.com/AliciaHormann/publicStuff.git

Maybe this is helpful for anyone of you.

*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There are a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 27 kernel bugs.

Fedora 27 has now been rebased to 4.17.7-100.fc27.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you have moved on to Fedora 28, and are still experiencing this issue, please change the version to Fedora 28.

If you experience different issues, please open a new bug report for those.

(In reply to Justin M. Forbes from comment #155)
> *********** MASS BUG UPDATE **************
> 
> We apologize for the inconvenience.  There are a large number of bugs to go
> through and several of them have gone stale.  Due to this, we are doing a
> mass bug update across all of the Fedora 27 kernel bugs.
> 
> Fedora 27 has now been rebased to 4.17.7-100.fc27.  Please test this kernel
> update (or newer) and let us know if you issue has been resolved or if it is
> still present with the newer kernel.
> 
> If you have moved on to Fedora 28, and are still experiencing this issue,
> please change the version to Fedora 28.
> 
> If you experience different issues, please open a new bug report for those.

Thank you very much for trying to resolve this issue, but as far as I can see neither the Trackpad nor the Touchscreen seem to work yet.

Trekstor Primebook C11
Kernel: 4.17.9-200.fc28.x86_64

Hi, 
I have a Mediacom Flexbook Edge 11 which is basically the Trekstor Primebook c11 rebranded. It has both silead touchscreen and sipodev touchpad. 
I couldn't build ubuntu kernel due to the same problem that Felipe had and now I'm on antergos linux and I'll try using i2c driver. 

I got touchscreen working downloading the firmware from aur, but I don't understand how to get it calibrated (I suspect it has Y inverted). 
(using xinput_calibrator didn't solve and I didn't understand what to do with coordinates taken from evemu-record.

Here are my outputs for the quirk-list

cat /sys/class/dmi/id/sys_vendor 
MEDIACOM

cat /sys/class/dmi/id/product_name 
FlexBook edge11 - M-FBE11

Under /sys/module/i2c_hid/drivers/i2c:i2c_hid

I have

bind  module  uevent  unbind

And dmesg output

dmesg | grep i2c_hid
[    3.034597] i2c_hid i2c-SYNA3602:00: i2c-SYNA3602:00 supply vdd not found, using dummy regulator
[    3.040549] i2c_hid i2c-SYNA3602:00: unexpected HID descriptor bcdVersion (0x00ff)


Thank you

Hello @rmbg,
 
if your device is so similar to the C11 you can try using the calibration i linked above (https://github.com/AliciaHormann/publicStuff.git),
you have to insert the description of your device (should be the product name, but im not sure about this) there instead of the C11, but then the calibration should be done

(In reply to ahormann from comment #158)
> Hello @rmbg,
>  
> if your device is so similar to the C11 you can try using the calibration i
> linked above (https://github.com/AliciaHormann/publicStuff.git),
> you have to insert the description of your device (should be the product
> name, but im not sure about this) there instead of the C11, but then the
> calibration should be done

Hi, thank you! 

Your page was the first I checked when I started working on linux for my device, but I didn't understand why we need an horizontal patch and a vertical one..
maybe because it can't automatically switch when we rotate the device?

Exactly,
theoretically there may be a way for automatical switching since it is possible for Windows....but I really have no idea or patience to find it.
So i compiled the kernel twice to choose the calibration while booting.
Then i rotate the display-view with xrandr (or in the Settings).

I have a question: is there any way to have an i2c module driver dynamic (dkms) instead of building the kernel after every update? On arch i should build it every 2 or 3 days.

(In reply to ahormann from comment #160)
> Exactly,
> theoretically there may be a way for automatical switching since it is
> possible for Windows....but I really have no idea or patience to find it.
> So i compiled the kernel twice to choose the calibration while booting.
> Then i rotate the display-view with xrandr (or in the Settings).

Maybe with a kind of script that replace calibration data when notebook is rotated, but this would be triggered by some signal from accelerometer or gyroscope or what else.

(In reply to rmbg from comment #162)
> (In reply to ahormann from comment #160)
> > Exactly,
> > theoretically there may be a way for automatical switching since it is
> > possible for Windows....but I really have no idea or patience to find it.
> > So i compiled the kernel twice to choose the calibration while booting.
> > Then i rotate the display-view with xrandr (or in the Settings).
> 
> Maybe with a kind of script that replace calibration data when notebook is
> rotated, but this would be triggered by some signal from accelerometer or
> gyroscope or what else.

If your touchscreen and accelerometer are both configured properly then you should not need any manual configuration at all and your touchscreen coordinates should automatically follow the screen rotation when the screen is rotated because you're holding the device in non upright position.

At least this is true for a desktop environment which handles this all properly such as GNOME3, with other desktop environments you may get different results.

Anyways please try to not set any translation matrix with xrandr at all and also undo any other customizations you've done.

The touchscreen should be setup to send the right coordinates ootb with the settings for it in drivers/platform/x86/silead_dmi.c (drivers/platform/x86/touchscreen_dmi.c in newer kernels).

It is probably best to disable the accelerometer for starters to make sure you get the touchscreen coordinates right for the native orientation of the display, you can do this by doing:

systemctl mask iio-sensor-proxy.service

And then rebooting, to re-enable the accelerometer afterwards do:

systemctl unmask iio-sensor-proxy.service

To fix the accelerometer orientation (if necessary) you need to edit:
/lib/udev/hwdb.d/60-sensor.hwdb see inside that file for instructions.

Very interesting. 
I didn't do anything because I'm trying to understand how it works before "getting my hands dirty" with coding. I also think that actually the accelerometer hasn't been recognized, but I'm not sure.. I have to inspect it. 

I got some errors when trying to build my arch kernel using sipodev i2c modified driver. 
I downloaded it from here https://raw.githubusercontent.com/brotfessor/sipodev/master/b/i2c-hid.c

I took a screenshot here: https://s15.postimg.cc/8h08mhknf/Screenshot_20180820_214822.png

You almost certainly have a different kernel version than I did back then. Please try this patch against a clean kernel instead:

https://raw.githubusercontent.com/brotfessor/sipodev/master/sipodev-quirk.patch


Regarding the acceleration sensors, in the Trekstor C13 there are 2 of them (Kionix KXCJ9 i believe) and there apparently is a android driver out there, but I didn't investigate further. But some bytes can be read via i2cdump so I think in theory it should be possible to get this thing going.

(In reply to Julian Sax from comment #165)
> You almost certainly have a different kernel version than I did back then.
> Please try this patch against a clean kernel instead:
> 
> https://raw.githubusercontent.com/brotfessor/sipodev/master/sipodev-quirk.
> patch


It works, thank you!! 

Now I would like i2c-hid dynamic, which avoids thet coul kernel building after every update.
Any chance?

YESS!!!

I successfully built the module dynamically: no more kernel building after update!

I had to modify an <include> in the source file, edit makefile and finally create the dkms.conf file. 

On arch it works! 

Here is the zip file: http://s000.tinyupload.com/index.php?file_id=00594951056204483134

Now i'm gonna try it on Kubuntu 18.04 LTS

Tried my package on Kde Neon based on 18.04. It didn't work :(
I installed it using dkms add, dkms build, dkms install commands, no errors, but after reboot or shutdown and power on nothing happened to the touchpad. 

I don't know why. Could you help me?

(In reply to rmbg from comment #168)
> Tried my package on Kde Neon based on 18.04. It didn't work :(
> I installed it using dkms add, dkms build, dkms install commands, no errors,
> but after reboot or shutdown and power on nothing happened to the touchpad. 
> 
> I don't know why. Could you help me?

dkms status shows that my module is running. 
lsmod show i2c_hid used by 0 and hid used by i2c_hid and other modules.

Any status on when those fixes will hit the repos/main kernel?

I was hoping for F29 but still neither touchpad nor touchscreen work out of the box.

(In reply to Dietrich from comment #170)
> Any status on when those fixes will hit the repos/main kernel?

I'm afraid the patch has fallen through the cracks and is not in 4.19, I've just asked the upstream HID maintainer about this.

(In reply to Hans de Goede from comment #171)
> (In reply to Dietrich from comment #170)
> > Any status on when those fixes will hit the repos/main kernel?
> 
> I'm afraid the patch has fallen through the cracks and is not in 4.19, I've
> just asked the upstream HID maintainer about this.

Any news?
Who is the HID mantainer?

(In reply to rmbg from comment #172)
> Any news?

The patch for this has been queued for merging upstream now:

https://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid.git/log/?h=for-4.20/i2c-hid

Perhaps the Fedora kernel maintainers can add this patch as a downstream patch for now?  :

https://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid.git/commit/?h=for-4.20/i2c-hid&id=9ee3e06610fdb8a601cde59c92089fb6c1deb4aa

Great thank you!

The patch you mentioned in #19 is in the kernel too? Or did it get stuck in some queue?

(In reply to Dietrich from comment #174)
> Great thank you!
> 
> The patch you mentioned in #19 is in the kernel too? Or did it get stuck in
> some queue?

That patch has long gone upstream, but I believe there still is an issue with the touchscreen after suspend/resume which I promised I would write a patch for. So far I've not gotten around to writing that patch I'm afraid.

Hi,

I haven't seen the touchscreen patch from ahormann in comment #154 in the patch Hans de Goede mentioned above. Are there any plans to also merge this upstream?

I'm using the touchscreen patch in a custom kernel for a while now, and except for the suspend/resume thing it works fine.

Thanks to you all for your efforts!

(In reply to Marian Cepok from comment #176)
> Hi,
> 
> I haven't seen the touchscreen patch from ahormann in comment #154 in the
> patch Hans de Goede mentioned above. Are there any plans to also merge this
> upstream?

I don't think this was ever submitted upstream. ahormann, are you ok with me submitting the horizontal patch upstream?

I assume the device boots with the screen in horizontal orientation and you used xrandr to rotate? If you use e.g. GNOME and the gnome-control-center to rotate the display then the touch coordinates will automatically be adjusted to match.

The kernel settings for the touchscreen should match the display as it comes up without any special settings applied, so assumg that the display normally / durin early boot shows everything in landscape/horizontal mode then that is what the kernel settings should be.

(In reply to Hans de Goede from comment #177)
> I don't think this was ever submitted upstream. ahormann, are you ok with me
> submitting the horizontal patch upstream?

I didn't submit it because i have no idea how to do this.
But feel free to submit it.


(In reply to Marian Cepok from comment #176)
> 
> I'm using the touchscreen patch in a custom kernel for a while now, and
> except for the suspend/resume thing it works fine.
> 

I simply defined an alias for 'sudo modprobe -r silead;sudo modprobe silead' so the touchscreen can be fixed in a few seconds (same for touchpad with 'sudo modprobe -r silead;sudo modprobe silead').

(In reply to ahormann from comment #178)
> (In reply to Hans de Goede from comment #177)
> > I don't think this was ever submitted upstream. ahormann, are you ok with me
> > submitting the horizontal patch upstream?
> 
> I didn't submit it because i have no idea how to do this.
> But feel free to submit it.

Ok, so shall I set you as the author and may I add:

Signed-off-by: Alicia Hormann <xxx>

To the commit message then (this is mandatory if you want me to set you as the author).

Or I can make myself the author and add:

Suggested-by: Alicia Hormann <xxx>

Or I can make myself the author and not mention you at all. If you let me know which form you prefer then I will submit this upstream.

I'd prefer the suggested-by form

(In reply to ahormann from comment #180)
> I'd prefer the suggested-by form

Done.

(In reply to Hans de Goede from comment #175)
> (In reply to Dietrich from comment #174)
> > Great thank you!
> > 
> > The patch you mentioned in #19 is in the kernel too? Or did it get stuck in
> > some queue?
> 
> That patch has long gone upstream, but I believe there still is an issue
> with the touchscreen after suspend/resume which I promised I would write a
> patch for. So far I've not gotten around to writing that patch I'm afraid.

Thank you! Apparently I put the firmware file somewhere but not the right place... so now with the firmware file in the correct place it works.

Is it possible to get the firmware file into some fedora package for an 'out of the box' experience? I guess problems with licensing? 

And Thank you again for your great work!

Hi,

> Thank you! Apparently I put the firmware file somewhere but not the right
> place... so now with the firmware file in the correct place it works.
> 
> Is it possible to get the firmware file into some fedora package for an 'out of
> the box' experience? I guess problems with licensing?

Yes the Silead touchscreen firmware basically has an unknown license.

I've contacted Trekstor about this in the past, but never got an answer.

Tresktor has email addresses which you can use to contact them here:

http://www.trekstor.de/ueber-uns.html

Specifically if you click to expand the various job positions then
you will find non-generic email addresses.

I've mailed them in English. Maybe they will be more responsive to
a request in German from a German customer?

Regards,

Hans

Hey,

i would write to them. I'm not a technician, a text in would help in English.

Regards


Olaf

Hi there! 

Once enabled and calibrated what can someone do with the touchscreen? 
Windows offers some facilities like mouse disappearing when touching, more space between menu entries, a touch keyboard on screeen, some gestures, keyboard deactivation when the device is rotated.. 

What about linux? 
 
About the touchpad:
On Ubuntu I succeeded in building only the i2c-hid driver instead of the full kernel.. only a few seconds against 3 hours :D 
I think this can be possible also on Fedora and other distros.

Hi,

@rmbg Can you please explain to me how you have installed the driver under Ubuntu?

Tnanks

Olaf

(In reply to rmbg from comment #185)
> Hi there!
[...]
> What about linux?

Well most of that is userspace. Meaning this should be implemented in Gnome or other desktop environments. The orientation parts does include kernel drivers for the sensors - but as far as I know those are not standardized and no one really bothers enough to implement drivers for every device.

In Fedora 29 which is released soon the touchscreen is working well out of the box, provided that the necessary firmware is installed.

Regards
Franz

(In reply to Olaf from comment #186)
> Hi,
> 
> @rmbg Can you please explain to me how you have installed the driver under
> Ubuntu?
> 
> Tnanks
> 
> Olaf

Sure!

First of all you need to download the linux kernel source package from ubuntu repos (maybe you have to enable them), the linux headers and the build essential package. 

They will be stored into /usr/src

Extract the linux-source-'uname -r'.tar.bz2 and copy the extracted folder into your home. 

Now you have to patch the source file i2c-hid.c : it's under <your home>/linux-source-'uname -r'/drivers/hid/i2c-hid

get the sipodev-quirk.patch from here https://github.com/brotfessor/sipodev

and put it into <your home>/linux-source-'uname -r'/drivers/hid/i2c-hid cd there and give this: patch i2c-hid.c < sipodev-quirk.patch 

Now build it: make -C /lib/modules/`uname -r`/build M=<your home>/linux-source-'uname -r'/drivers/hid/i2c-hid

You'll obtain a .ko file (the driver) 

check the version (the kernel one and this one must be the same) 

modinfo <your home>/linux-source-'uname -r'/drivers/hid/i2c-hid/i2c-hid.ko


Copy the .ko file into /lib/modules/'uname -r'/kernel/drivers/hid/i2c-hid

insert it into the kernel tree:sudo insmod /lib/modules/'uname -r'/kernel/drivers/hid/i2c-hid/i2c-hid.ko

Reboot. Now it should work

Thanks :-)

(In reply to Olaf from comment #189)
> Thanks :-)

Did it work?

(In reply to rmbg from comment #190)
> (In reply to Olaf from comment #189)
> > Thanks :-)
> 
> Did it work?

Sorry I could not test it yet

(In reply to Dietrich from comment #187)
> (In reply to rmbg from comment #185)
> > Hi there!
> [...]
> > What about linux?
> 
> Well most of that is userspace. Meaning this should be implemented in Gnome
> or other desktop environments. The orientation parts does include kernel
> drivers for the sensors - but as far as I know those are not standardized
> and no one really bothers enough to implement drivers for every device.
> 
> In Fedora 29 which is released soon the touchscreen is working well out of
> the box, provided that the necessary firmware is installed.
> 
> Regards
> Franz

I downloaded the kde beta spin iso, but the touchscreen didn't work out of the box.. 
What should I do? 

Thanks

(In reply to rmbg from comment #192)
> I downloaded the kde beta spin iso, but the touchscreen didn't work out of
> the box.. 
> What should I do? 
> 
> Thanks

If the kernel already has the patches you need to download the firmware from here: https://github.com/onitake/gsl-firmware/raw/master/firmware/linux/silead/gsl1680-trekstor-primebook-c13.fw
Put that file in the following directory: /lib/firmware/silead/
You might have to create it.

(In reply to rmbg from comment #188)
> (In reply to Olaf from comment #186)
> > Hi,
> > 
> > @rmbg Can you please explain to me how you have installed the driver under
> > Ubuntu?
> > 
> > Tnanks
> > 
> > Olaf
> 
> Sure!
> 
> First of all you need to download the linux kernel source package from
> ubuntu repos (maybe you have to enable them), the linux headers and the
> build essential package. 
> 
> They will be stored into /usr/src
> 
> Extract the linux-source-'uname -r'.tar.bz2 and copy the extracted folder
> into your home. 
> 
> Now you have to patch the source file i2c-hid.c : it's under <your
> home>/linux-source-'uname -r'/drivers/hid/i2c-hid
> 
> get the sipodev-quirk.patch from here https://github.com/brotfessor/sipodev
> 
> and put it into <your home>/linux-source-'uname -r'/drivers/hid/i2c-hid cd
> there and give this: patch i2c-hid.c < sipodev-quirk.patch 
> 
> Now build it: make -C /lib/modules/`uname -r`/build M=<your
> home>/linux-source-'uname -r'/drivers/hid/i2c-hid
> 
> You'll obtain a .ko file (the driver) 
> 
> check the version (the kernel one and this one must be the same) 
> 
> modinfo <your home>/linux-source-'uname -r'/drivers/hid/i2c-hid/i2c-hid.ko
> 
> 
> Copy the .ko file into /lib/modules/'uname -r'/kernel/drivers/hid/i2c-hid
> 
> insert it into the kernel tree:sudo insmod /lib/modules/'uname
> -r'/kernel/drivers/hid/i2c-hid/i2c-hid.ko
> 
> Reboot. Now it should work

it does work, but I have to insert the sudo insmod ... command everytime I start the device, is there anyway to make it nonreversible?

(In reply to Anton Ha from comment #194)
> (In reply to rmbg from comment #188)
> > (In reply to Olaf from comment #186)
> > > Hi,
> > > 
> > > @rmbg Can you please explain to me how you have installed the driver under
> > > Ubuntu?
> > > 
> > > Tnanks
> > > 
> > > Olaf
> > 
> > Sure!
> > 
> > First of all you need to download the linux kernel source package from
> > ubuntu repos (maybe you have to enable them), the linux headers and the
> > build essential package. 
> > 
> > They will be stored into /usr/src
> > 
> > Extract the linux-source-'uname -r'.tar.bz2 and copy the extracted folder
> > into your home. 
> > 
> > Now you have to patch the source file i2c-hid.c : it's under <your
> > home>/linux-source-'uname -r'/drivers/hid/i2c-hid
> > 
> > get the sipodev-quirk.patch from here https://github.com/brotfessor/sipodev
> > 
> > and put it into <your home>/linux-source-'uname -r'/drivers/hid/i2c-hid cd
> > there and give this: patch i2c-hid.c < sipodev-quirk.patch 
> > 
> > Now build it: make -C /lib/modules/`uname -r`/build M=<your
> > home>/linux-source-'uname -r'/drivers/hid/i2c-hid
> > 
> > You'll obtain a .ko file (the driver) 
> > 
> > check the version (the kernel one and this one must be the same) 
> > 
> > modinfo <your home>/linux-source-'uname -r'/drivers/hid/i2c-hid/i2c-hid.ko
> > 
> > 
> > Copy the .ko file into /lib/modules/'uname -r'/kernel/drivers/hid/i2c-hid
> > 
> > insert it into the kernel tree:sudo insmod /lib/modules/'uname
> > -r'/kernel/drivers/hid/i2c-hid/i2c-hid.ko
> > 
> > Reboot. Now it should work
> 
> it does work, but I have to insert the sudo insmod ... command everytime I
> start the device, is there anyway to make it nonreversible?

Sorry, I forgot this:

sudo update-initramfs -k all -u 

Now, if you boot and your touchpad is not working do this: 

sudo rrmod i2c-hid

sudo insmod /lib/modules/'uname-r'/kernel/drivers/hid/i2c-hid/i2c-hid.ko

sudo update-initramfs -k all -u 

reboot

it should work.

(In reply to Dietrich from comment #193)
> (In reply to rmbg from comment #192)
> > I downloaded the kde beta spin iso, but the touchscreen didn't work out of
> > the box.. 
> > What should I do? 
> > 
> > Thanks
> 
> If the kernel already has the patches you need to download the firmware from
> here:
> https://github.com/onitake/gsl-firmware/raw/master/firmware/linux/silead/
> gsl1680-trekstor-primebook-c13.fw
> Put that file in the following directory: /lib/firmware/silead/
> You might have to create it.

My device isn't the primebook-C13.
It's the Mediacom Flexbook edge 11 which is basically the primebook-C11, but I don't know if the silead has the same values.. 

so I think I have to calibrate it.

The patch for the primebook c11 can be found here 
https://github.com/AliciaHormann/publicStuff.git

Propably your device has a different name, so you have to run
$ cat /sys/class/dmi/id/sys_vendor 
$ cat /sys/class/dmi/id/product_name 
and replace the Strings "TREKSTOR" and "Primebook C11" with the outputs

At least if i remember correctly :|

(In reply to ahormann from comment #197)
> The patch for the primebook c11 can be found here 
> https://github.com/AliciaHormann/publicStuff.git
> 
> Propably your device has a different name, so you have to run
> $ cat /sys/class/dmi/id/sys_vendor 
> $ cat /sys/class/dmi/id/product_name 
> and replace the Strings "TREKSTOR" and "Primebook C11" with the outputs
> 
> At least if i remember correctly :|

It doesn't work 

Here are my outputs: 

MEDIACOM
FlexBook edge11 - M-FBE11

Renamed the C11 firmware bu t nothing happened. 

So i tried the silead firmware from aur (arch linux user repo) which has a different name: mssl1680.fw and worked, but had non calibration. 

Renaming the C11 firmware to mssl1680.fw it works, but still has no calibration. 
(right is left and up is down :S

I'm using KDE Neon based on ubuntu 18.04 lts

(In reply to rmbg from comment #198)
> Renaming the C11 firmware to mssl1680.fw it works, but still has no
> calibration. 
> (right is left and up is down :S

See: https://github.com/onitake/gsl-firmware#silead_ts for some documentation on how to add an entry with callibration data for your laptop to the kernel.

Note that testing this will require you to build your own kernel, sorry.

Regards,

Hans

(In reply to Hans de Goede from comment #199)
> (In reply to rmbg from comment #198)
> > Renaming the C11 firmware to mssl1680.fw it works, but still has no
> > calibration. 
> > (right is left and up is down :S
> 
> See: https://github.com/onitake/gsl-firmware#silead_ts for some
> documentation on how to add an entry with callibration data for your laptop
> to the kernel.
> 
> Note that testing this will require you to build your own kernel, sorry.
> 
> Regards,
> 
> Hans

Why the entire kernel and not only some module?

(In reply to rmbg from comment #200)
> Why the entire kernel and not only some module?

Because the table attaching the extra properties to the touchscreen is part of the zImage and it is not possible to build this code as a module.

(In reply to rmbg from comment #167)
> YESS!!!
> 
> I successfully built the module dynamically: no more kernel building after
> update!
> 
> I had to modify an <include> in the source file, edit makefile and finally
> create the dkms.conf file. 
> 
> On arch it works! 
> 
> Here is the zip file:
> http://s000.tinyupload.com/index.php?file_id=00594951056204483134
> 
> Now i'm gonna try it on Kubuntu 18.04 LTS

i just installed archlabs on my teclast f7 and facing the same problem like you guys here. can was about to rebuild the kernel with that patch, but this solution looks ways better then that. is it working with the newest arch kernel and can you reup your file with maybe a small description on how to use it please? very thanks in advanced!!

(In reply to rmbg from comment #167)
> YESS!!!
> 
> I successfully built the module dynamically: no more kernel building after
> update!
> 
> I had to modify an <include> in the source file, edit makefile and finally
> create the dkms.conf file. 
> 
> On arch it works! 
> 
> Here is the zip file:
> http://s000.tinyupload.com/index.php?file_id=00594951056204483134
> 
> Now i'm gonna try it on Kubuntu 18.04 LTS

i just installed archlabs on my teclast f7 and facing the same problem like you guys here. i was about to rebuild the kernel with that patch, but this solution looks ways better then that. is it working with the newest arch kernel and can you reup your file with maybe a small description on how to use it please? very thanks in advanced!!

ON the just released Manjaro 18 the touchpad works OUT OF THE BOX!!!
What a fantastic news!!

The only feature missing is the touchscreen which needs to be calibrated.

(In reply to rmbg from comment #204)
> ON the just released Manjaro 18 the touchpad works OUT OF THE BOX!!!
> What a fantastic news!!
> 
> The only feature missing is the touchscreen which needs to be calibrated.

It's the magic of their 4.19 Kernel my friend.

(In reply to Anton Ha from comment #205)
> (In reply to rmbg from comment #204)
> > ON the just released Manjaro 18 the touchpad works OUT OF THE BOX!!!
> > What a fantastic news!!
> > 
> > The only feature missing is the touchscreen which needs to be calibrated.
> 
> It's the magic of their 4.19 Kernel my friend.

I think so 

Fedora 29: nothing changed :(

What about acceletometer? Mine is the kionix kxcj9 3-axis. I found a linux (android) driver on the kionix site, but I didn't found any kind of information about building. 
I also don't know if they already put it into the kernel (I don't know how can I test it)

What about accelerometer? Mine is the kionix kxcj9 3-axis. I found a linux (android) driver on the kionix site, but I didn't found any kind of information about building. 
I also don't know if they already put it into the kernel (I don't know how can I test it)

(In reply to rmbg from comment #206)
> (In reply to Anton Ha from comment #205)
> > (In reply to rmbg from comment #204)
> > > ON the just released Manjaro 18 the touchpad works OUT OF THE BOX!!!
> > > What a fantastic news!!
> > > 
> > > The only feature missing is the touchscreen which needs to be calibrated.
> > 
> > It's the magic of their 4.19 Kernel my friend.
> 
> I think so 
> 
> Fedora 29: nothing changed :(

Fedora 29 is still using  the 4.18, isn't it?

(In reply to Anton Ha from comment #205)
> (In reply to rmbg from comment #204)
> > ON the just released Manjaro 18 the touchpad works OUT OF THE BOX!!!
> > What a fantastic news!!
> > 
> > The only feature missing is the touchscreen which needs to be calibrated.
> 
> It's the magic of their 4.19 Kernel my friend.

Actually the patch for this has only landed in 4.20, the Manjaro devs have backported it to their 4.19 kernel.

I've also added the patch to our 4.19 kenrels now (which should show up in updates-testing in about a week or so).

In the mean time you can grab a test kernel with the patch which I've build here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=30805825

Generic install instructions for installing a kernel directly from koji are here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=30805825

Note this test kernel is not signed, so it will not work with secureboot enabled.

Erm the correct test-instructions URL is:
https://fedorapeople.org/~jwrdegoede/kernel-test-instructions.txt

(In reply to rmbg from comment #208)
> What about accelerometer? Mine is the kionix kxcj9 3-axis. I found a linux
> (android) driver on the kionix site, but I didn't found any kind of
> information about building. 
> I also don't know if they already put it into the kernel (I don't know how
> can I test it)

The accelerometer should already be supported under Fedora

What is the output of:

ls -l /sys/bus/iio/devices

?

And if you run monitor-sensor

Does it then just say "Waiting for iio-sensor-proxy to appear" or this it print more info, including accelerometer info ?

And if prints accelerometer info, does it respond to you rotating the laptop, holding it so that the screen is in portrait mode ?

(In reply to Hans de Goede from comment #212)
> (In reply to rmbg from comment #208)
> > What about accelerometer? Mine is the kionix kxcj9 3-axis. I found a linux
> > (android) driver on the kionix site, but I didn't found any kind of
> > information about building. 
> > I also don't know if they already put it into the kernel (I don't know how
> > can I test it)
> 
> The accelerometer should already be supported under Fedora
> 
> What is the output of:
> 
> ls -l /sys/bus/iio/devices
> 
> ?
> 
> And if you run monitor-sensor
> 
> Does it then just say "Waiting for iio-sensor-proxy to appear" or this it
> print more info, including accelerometer info ?
> 
> And if prints accelerometer info, does it respond to you rotating the
> laptop, holding it so that the screen is in portrait mode ?


Hi. 

ls -l /sys/bus/iio/devices

doesn't exist. I have no "iio" folder. 

monitor sensor: command not found. 

Tested on Fedora 29 KDE Live 64 bit.

(In reply to rmbg from comment #213)
> ls -l /sys/bus/iio/devices
> 
> doesn't exist. I have no "iio" folder. 

Hmm, ok.

What is the output of:

ls /sys/bus/i2c/devices

?

(In reply to Hans de Goede from comment #214)
> (In reply to rmbg from comment #213)
> > ls -l /sys/bus/iio/devices
> > 
> > doesn't exist. I have no "iio" folder. 
> 
> Hmm, ok.
> 
> What is the output of:
> 
> ls /sys/bus/i2c/devices
> 
> ?

I have i2c-x where x is from 0 to 13,
 
i2c-KIOX010A:00 and i2c-KIOX020A:00 the accelerometer

i2c-MSSL1680:00 the touchscreen controller

i2c-SYNA3602:00 the touchpad

kernel-4.19.2-301.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2018-cb49f8a11b

kernel-4.19.2-301.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-cb49f8a11b

(In reply to rmbg from comment #215)
> i2c-KIOX010A:00 and i2c-KIOX020A:00 the accelerometer

Ok, so the problem is that the KIOX010A device-id was missing from the accelerometer driver.

I've started a scratch-build of a kernel with a patch adding the missing device-id (and keeping the patch to fix the touchpad in place):

https://koji.fedoraproject.org/koji/taskinfo?taskID=31015962

Once this is done building (this takes a couple of hours) please follow these instructions to install and test the kernel and let us know if this fixes the accelerometer:

https://fedorapeople.org/~jwrdegoede/kernel-test-instructions.txt

Note that since this is a scratch-build it is not signed, so you need to disable secure-boot if you have it enabled.

Note the kernel scratch-build is finished now, so if you can give it a try that would be great.

This should also fix the accelerometer not working on a bunch of other models from this bug.

Hi, just installed your kernel packages. 
The touchpad is ok

Now
ls -l /sys/bus/iio/devices/
total 0
lrwxrwxrwx. 1 root root 0 21 nov 10.33 iio:device0 -> ../../../devices/pci0000:00/0000:00:16.3/i2c_designware.3/i2c-8/i2c-KIOX010A:00/iio:device0

(before installing your kernel packages returned nothing)

If I rotate the screen nothing happens. Installed iio-sensor-proxy but nothing changed. How can I test it?

(In reply to rmbg from comment #221)
> Hi, just installed your kernel packages. 
> The touchpad is ok
> 
> Now
> ls -l /sys/bus/iio/devices/
> total 0
> lrwxrwxrwx. 1 root root 0 21 nov 10.33 iio:device0 ->
> ../../../devices/pci0000:00/0000:00:16.3/i2c_designware.3/i2c-8/i2c-KIOX010A:
> 00/iio:device0
> 
> (before installing your kernel packages returned nothing)
> 
> If I rotate the screen nothing happens. Installed iio-sensor-proxy but
> nothing changed. How can I test it?

If you run monitor-sensor, it should say you have an accelerometer and print messages about the orientation changing when you rotate the screen.

If you run GNOME3 as desktop environment it should automatically pick up these events and rotate the display output to match (unless you've turned on the rotation-lock in the system-menu on the top right).

In general for tablet-mode functionality GNOME3 is the best desktop environment.

kernel-4.19.2-301.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report.

(In reply to Hans de Goede from comment #222)
> (In reply to rmbg from comment #221)
> > Hi, just installed your kernel packages. 
> > The touchpad is ok
> > 
> > Now
> > ls -l /sys/bus/iio/devices/
> > total 0
> > lrwxrwxrwx. 1 root root 0 21 nov 10.33 iio:device0 ->
> > ../../../devices/pci0000:00/0000:00:16.3/i2c_designware.3/i2c-8/i2c-KIOX010A:
> > 00/iio:device0
> > 
> > (before installing your kernel packages returned nothing)
> > 
> > If I rotate the screen nothing happens. Installed iio-sensor-proxy but
> > nothing changed. How can I test it?
> 
> If you run monitor-sensor, it should say you have an accelerometer and print
> messages about the orientation changing when you rotate the screen.
> 
> If you run GNOME3 as desktop environment it should automatically pick up
> these events and rotate the display output to match (unless you've turned on
> the rotation-lock in the system-menu on the top right).
> 
> In general for tablet-mode functionality GNOME3 is the best desktop
> environment.

In gnome 3 it works, but the screen is always turned upside down :S 
I don't know why. 

Can you explain me what you did to get the accelerometer recognized?

(In reply to Fedora Update System from comment #216)
> kernel-4.19.2-301.fc29 has been submitted as an update to Fedora 29.
> https://bodhi.fedoraproject.org/updates/FEDORA-2018-cb49f8a11b

On my system not fixed :(

kernel-tools-4.19.3-300.fc29 kernel-4.19.3-300.fc29 kernel-headers-4.19.3-300.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2018-367d08ef69

kernel-headers-4.19.3-200.fc28 kernel-tools-4.19.3-200.fc28 kernel-4.19.3-200.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-7cf713da0d

(In reply to rmbg from comment #224)
> In gnome 3 it works, but the screen is always turned upside down :S 
> I don't know why. 

That means you need to add an entry for your device to /lib/udev/hwdb.d/60-sensor.hwdb using the following template:

sensor:modalias:acpi:KIOX010A*:dmi:*svnFIXME*:*pnFIXME*
 ACCEL_MOUNT_MATRIX=-1, 0, 0; 0, -1, 0; 0, 0, 1

To get the FIXME values do:

cat /sys/class/dmi/id/modalias

You may want to match on more then just the svn (system-vendor) and pn (product-name) fields depending on how generic these are. The idea is to have something which will match your device but not others.

After editing the file, run (as root):

udevadm hwdb --update
udevadm trigger
systemctl restart iio-sensor-proxy.service

And then the upside-down problem should be solved. Once you've fixed this please either let me know the 2 lines you needed to add to the hwdb, or submit a pull-request with this change tot systemd upstream yourself.

> Can you explain me what you did to get the accelerometer recognized?

I added the KIOX010A ACPI hardware-id to the drivers/iio/accel/kxcjk-1013.c driver in the kernel.

kernel-4.19.3-200.fc28, kernel-headers-4.19.3-200.fc28, kernel-tools-4.19.3-200.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-7cf713da0d

kernel-4.19.3-300.fc29, kernel-headers-4.19.3-300.fc29, kernel-tools-4.19.3-300.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-367d08ef69

(In reply to rmbg from comment #225)
> (In reply to Fedora Update System from comment #216)
> > kernel-4.19.2-301.fc29 has been submitted as an update to Fedora 29.
> > https://bodhi.fedoraproject.org/updates/FEDORA-2018-cb49f8a11b
> 
> On my system not fixed :(

Do you mean that your touchpad still does not work ?

Are you sure you are running 4.19.2-301 or newer? What does uname -a say ?

Can you reboot into the new kernel and then do directly after the reboot do:

dmesg > dmesg.txt

And attach the generated dmesg.txt file here?

Fixed! I don't know why it didn't work after rebooting. Today it's fine.

(In reply to Hans de Goede from comment #228)
> (In reply to rmbg from comment #224)
> > In gnome 3 it works, but the screen is always turned upside down :S 
> > I don't know why. 
> 
> That means you need to add an entry for your device to
> /lib/udev/hwdb.d/60-sensor.hwdb using the following template:
> 
> sensor:modalias:acpi:KIOX010A*:dmi:*svnFIXME*:*pnFIXME*
>  ACCEL_MOUNT_MATRIX=-1, 0, 0; 0, -1, 0; 0, 0, 1
> 
> To get the FIXME values do:
> 
> cat /sys/class/dmi/id/modalias
> 
> You may want to match on more then just the svn (system-vendor) and pn
> (product-name) fields depending on how generic these are. The idea is to
> have something which will match your device but not others.
> 
> After editing the file, run (as root):
> 
> udevadm hwdb --update
> udevadm trigger
> systemctl restart iio-sensor-proxy.service
> 
> And then the upside-down problem should be solved. Once you've fixed this
> please either let me know the 2 lines you needed to add to the hwdb, or
> submit a pull-request with this change tot systemd upstream yourself.
> 
> > Can you explain me what you did to get the accelerometer recognized?
> 
> I added the KIOX010A ACPI hardware-id to the drivers/iio/accel/kxcjk-1013.c
> driver in the kernel.

Maybe I can rebuild only the driver module instead of the entire kernel, as I did for the touchpad.

(In reply to rmbg from comment #233)
> Maybe I can rebuild only the driver module instead of the entire kernel, as
> I did for the touchpad.

There is no need for that, the latest 4.19.3-300.fc29 kernel build:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1166021

Contains the patch already, for install instructions see:
https://fedorapeople.org/~jwrdegoede/kernel-test-instructions.txt

If that does not give you an accelerometer (you can test this with "monitor-sensor") then please do:

ls /sys/bus/i2c/devices

And copy and paste the output here.

Hi, 

I tried to build the driver in manjaro linux.

I took the source kernel from kernel.org and your patch from the link you posted above. 
Patched and started building. Everything was fine, but when I insmod.. 
"Unknown symbol in module". 

Here is the dmesg output

[ 1389.107753] kxcjk_1013: Unknown symbol __iio_trigger_register (err -2)
[ 1389.107793] kxcjk_1013: Unknown symbol devm_iio_device_alloc (err -2)
[ 1389.107828] kxcjk_1013: Unknown symbol devm_iio_trigger_alloc (err -2)
[ 1389.107868] kxcjk_1013: Unknown symbol iio_get_time_ns (err -2)
[ 1389.107906] kxcjk_1013: Unknown symbol iio_device_unregister (err -2)
[ 1389.107950] kxcjk_1013: Unknown symbol iio_trigger_notify_done (err -2)
[ 1389.107987] kxcjk_1013: Unknown symbol iio_read_const_attr (err -2)
[ 1389.108023] kxcjk_1013: Unknown symbol iio_pollfunc_store_time (err -2)
[ 1389.108062] kxcjk_1013: Unknown symbol iio_trigger_unregister (err -2)
[ 1389.108097] kxcjk_1013: Unknown symbol iio_triggered_buffer_cleanup (err -2)

Could you help me? 
Thank you

(In reply to rmbg from comment #235)
> Hi, 
> 
> I tried to build the driver in manjaro linux.
> 
> I took the source kernel from kernel.org and your patch from the link you
> posted above. 
> Patched and started building. Everything was fine, but when I insmod.. 
> "Unknown symbol in module". 
> 
> Here is the dmesg output
> 
> [ 1389.107753] kxcjk_1013: Unknown symbol __iio_trigger_register (err -2)
> [ 1389.107793] kxcjk_1013: Unknown symbol devm_iio_device_alloc (err -2)
> [ 1389.107828] kxcjk_1013: Unknown symbol devm_iio_trigger_alloc (err -2)
> [ 1389.107868] kxcjk_1013: Unknown symbol iio_get_time_ns (err -2)
> [ 1389.107906] kxcjk_1013: Unknown symbol iio_device_unregister (err -2)
> [ 1389.107950] kxcjk_1013: Unknown symbol iio_trigger_notify_done (err -2)
> [ 1389.107987] kxcjk_1013: Unknown symbol iio_read_const_attr (err -2)
> [ 1389.108023] kxcjk_1013: Unknown symbol iio_pollfunc_store_time (err -2)
> [ 1389.108062] kxcjk_1013: Unknown symbol iio_trigger_unregister (err -2)
> [ 1389.108097] kxcjk_1013: Unknown symbol iio_triggered_buffer_cleanup (err
> -2)
> 
> Could you help me? 

Try copying the driver to /lib/modules/<kernelver>/updates

And then run:

depmod -a

And then:

modprobe kxcjk_1013

You need to have a bunch of iio related modules loaded first and this way modprobe will figure this out automatically.

kernel-4.19.3-300.fc29, kernel-headers-4.19.3-300.fc29, kernel-tools-4.19.3-300.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report.

(In reply to Hans de Goede from comment #236)
> (In reply to rmbg from comment #235)
> > Hi, 
> > 
> > I tried to build the driver in manjaro linux.
> > 
> > I took the source kernel from kernel.org and your patch from the link you
> > posted above. 
> > Patched and started building. Everything was fine, but when I insmod.. 
> > "Unknown symbol in module". 
> > 
> > Here is the dmesg output
> > 
> > [ 1389.107753] kxcjk_1013: Unknown symbol __iio_trigger_register (err -2)
> > [ 1389.107793] kxcjk_1013: Unknown symbol devm_iio_device_alloc (err -2)
> > [ 1389.107828] kxcjk_1013: Unknown symbol devm_iio_trigger_alloc (err -2)
> > [ 1389.107868] kxcjk_1013: Unknown symbol iio_get_time_ns (err -2)
> > [ 1389.107906] kxcjk_1013: Unknown symbol iio_device_unregister (err -2)
> > [ 1389.107950] kxcjk_1013: Unknown symbol iio_trigger_notify_done (err -2)
> > [ 1389.107987] kxcjk_1013: Unknown symbol iio_read_const_attr (err -2)
> > [ 1389.108023] kxcjk_1013: Unknown symbol iio_pollfunc_store_time (err -2)
> > [ 1389.108062] kxcjk_1013: Unknown symbol iio_trigger_unregister (err -2)
> > [ 1389.108097] kxcjk_1013: Unknown symbol iio_triggered_buffer_cleanup (err
> > -2)
> > 
> > Could you help me? 
> 
> Try copying the driver to /lib/modules/<kernelver>/updates
> 
> And then run:
> 
> depmod -a
> 
> And then:
> 
> modprobe kxcjk_1013
> 
> You need to have a bunch of iio related modules loaded first and this way
> modprobe will figure this out automatically.

It worked!!!!

How can I create a dkms module? I tried some months ago but something was wrong. 

Now i'm working on the touchscreen. The firmware works  (the touch is responding) but the coordinates are wrong. I took the dmi.log and values. Y is swapped. 
Here are: 
abs x 1974 (right)
abs y 1518 (top)

What do I need to do?

Created attachment 1508356 [details]
dmi.log for comment 238

Created attachment 1508374 [details]
[PATCH] platform/x86: touchscreen_dmi: Add info for the Mediacom Flexbook Edge 11

(In reply to rmbg from comment #238)
> Now i'm working on the touchscreen. The firmware works  (the touch is
> responding) but the coordinates are wrong. I took the dmi.log and values. Y
> is swapped. 
> Here are: 
> abs x 1974 (right)
> abs y 1518 (top)
> 
> What do I need to do?

Those are the same values as for the trekstor_primebook_c11.

If you build a kernel with the attached patch then the coordinates should be correct, note you need to rename the firmware file to gsl1680-trekstor-primebook-c11.fw.

Also you need to do a full kernel build as the modifications the patch does are part of the kernel kernel (the vmlinuz file).

If you can report back if this patch fixes things then I can submit it upstream (and you can ask the Manjaro devs to add it to the Manjaro kernel for now).

(In reply to Hans de Goede from comment #240)
> Created attachment 1508374 [details]
> [PATCH] platform/x86: touchscreen_dmi: Add info for the Mediacom Flexbook
> Edge 11
> 
> (In reply to rmbg from comment #238)
> > Now i'm working on the touchscreen. The firmware works  (the touch is
> > responding) but the coordinates are wrong. I took the dmi.log and values. Y
> > is swapped. 
> > Here are: 
> > abs x 1974 (right)
> > abs y 1518 (top)
> > 
> > What do I need to do?
> 
> Those are the same values as for the trekstor_primebook_c11.
> 
> If you build a kernel with the attached patch then the coordinates should be
> correct, note you need to rename the firmware file to
> gsl1680-trekstor-primebook-c11.fw.
> 
> Also you need to do a full kernel build as the modifications the patch does
> are part of the kernel kernel (the vmlinuz file).
> 
> If you can report back if this patch fixes things then I can submit it
> upstream (and you can ask the Manjaro devs to add it to the Manjaro kernel
> for now).

So, if I understand correctly: 
1) put the c11 firmware renamed into the correct folder. 
2) apply the patch. 
3) build the entire kernel. 

If I don't follow 2 and 3 steps I get the y swapped and the x shifted. 

Right?

(In reply to rmbg from comment #241)
> So, if I understand correctly: 
> 1) put the c11 firmware renamed into the correct folder. 

Or your own firmware under the c11 name (they should be the same)

> 2) apply the patch. 
> 3) build the entire kernel. 
> 
> If I don't follow 2 and 3 steps I get the y swapped and the x shifted. 
> 
> Right?

Right.

Back on Fedora 29 kde. 

dnf update gave me 4.19.3-300.fc29.x86_64 kernel.touchpad ok. 

sensor-monitor recognize the accelerometer (lsmod shows that the driver is load). 

No automatic rotation. 

I installed this 

https://github.com/dos1/kded_rotation

previously and successfully used on manjaro, but on fedora kde it doesn't work.

kernel-4.19.3-200.fc28, kernel-headers-4.19.3-200.fc28, kernel-tools-4.19.3-200.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report.

(In reply to rmbg from comment #241)
> (In reply to Hans de Goede from comment #240)
> > Created attachment 1508374 [details]
> > [PATCH] platform/x86: touchscreen_dmi: Add info for the Mediacom Flexbook
> > Edge 11
> > 
> > (In reply to rmbg from comment #238)
> > > Now i'm working on the touchscreen. The firmware works  (the touch is
> > > responding) but the coordinates are wrong. I took the dmi.log and values. Y
> > > is swapped. 
> > > Here are: 
> > > abs x 1974 (right)
> > > abs y 1518 (top)
> > > 
> > > What do I need to do?
> > 
> > Those are the same values as for the trekstor_primebook_c11.
> > 
> > If you build a kernel with the attached patch then the coordinates should be
> > correct, note you need to rename the firmware file to
> > gsl1680-trekstor-primebook-c11.fw.
> > 
> > Also you need to do a full kernel build as the modifications the patch does
> > are part of the kernel kernel (the vmlinuz file).
> > 
> > If you can report back if this patch fixes things then I can submit it
> > upstream (and you can ask the Manjaro devs to add it to the Manjaro kernel
> > for now).
> 
> So, if I understand correctly: 
> 1) put the c11 firmware renamed into the correct folder. 
> 2) apply the patch. 
> 3) build the entire kernel. 

Any luck testing the patch I wrote? I would like to submit it upstream, but first I need to know if it actually works :)

I'm sorry, I didn't have time last week :(
Building it on celeron requires at least 3 hours, too many.
I ask you if I can build it on another machine (i7, 16GB ram, Kde neon) and install into the 2 in 1 and how to do it. 
Thank you

(In reply to rmbg from comment #246)
> I'm sorry, I didn't have time last week :(
> Building it on celeron requires at least 3 hours, too many.
> I ask you if I can build it on another machine (i7, 16GB ram, Kde neon) and
> install into the 2 in 1 and how to do it. 
> Thank you

In comment 243 you say you are running Fedora again, is that still true ? If that is the case I can provide a pre-built kernel as rpms for you.

(In reply to Hans de Goede from comment #247)
> (In reply to rmbg from comment #246)
> > I'm sorry, I didn't have time last week :(
> > Building it on celeron requires at least 3 hours, too many.
> > I ask you if I can build it on another machine (i7, 16GB ram, Kde neon) and
> > install into the 2 in 1 and how to do it. 
> > Thank you
> 
> In comment 243 you say you are running Fedora again, is that still true ? If
> that is the case I can provide a pre-built kernel as rpms for you.

Yes. Thank you very much!

(In reply to rmbg from comment #248)
> > In comment 243 you say you are running Fedora again, is that still true ? If
> > that is the case I can provide a pre-built kernel as rpms for you.
> 
> Yes. Thank you very much!

Ok, a test kernel with the patch is building here now:

https://koji.fedoraproject.org/koji/taskinfo?taskID=31252814

This should be done in a couple of hours. For instructions on installing kernels directly from koji, see:

https://fedorapeople.org/~jwrdegoede/kernel-test-instructions.txt

(In reply to Hans de Goede from comment #249)
> Ok, a test kernel with the patch is building here now:
> 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=31252814

OK that build failed, second attempt:

https://koji.fedoraproject.org/koji/taskinfo?taskID=31252942

The build is done now, so your rpms are ready to test.

It seems to work: if I touch the screen left is left, right is right etc.. and the pointer is under my finger. I don't know anything about multitouching, so I need to know what I should do (maybe trying touchegg?) 

I tested only the horizontal position because on plasma I need the kded-rotation helper, I don't know why it doesn't work.

(In reply to rmbg from comment #252)
> It seems to work: if I touch the screen left is left, right is right etc..
> and the pointer is under my finger. I don't know anything about
> multitouching, so I need to know what I should do (maybe trying touchegg?) 

Great, thank you for testing. I've submitted the patch upstream.

> I tested only the horizontal position

That is fine.

Aaaand another manufacturer: Odys Winbook 13 needs to be include in the quirks list.

$ cat /sys/class/dmi/id/sys_vendor 
AXDIA International GmbH

$ cat /sys/class/dmi/id/product_name 
WINBOOK 13

$ dmesg | grep i2c
[    2.847400] i2c_hid i2c-HTIX5288:00: i2c-HTIX5288:00 supply vdd not found, using dummy regulator

The i2c device id can be switched in BIOS between i2c-HTIX5288 and i2c-SYNA3602 and another one. Of course none of them worked.

Patch for i2c_hid works (as module).

Still digging into an issue with the device. It seems to go to sleep after 2s of idle time and then requires another 3s when being touched to get back to work. Of course, this is no fun. Anyone experienced similar behaviour?

Hi,

(In reply to Rene Wagner from comment #254)
> Aaaand another manufacturer: Odys Winbook 13 needs to be include in the
> quirks list.
> 
> $ cat /sys/class/dmi/id/sys_vendor 
> AXDIA International GmbH
> 
> $ cat /sys/class/dmi/id/product_name 
> WINBOOK 13
> 
> Patch for i2c_hid works (as module).

So if I understand things correctly, you've added something like this to drivers/hid/i2c-hid/i2c-hid-dmi-quirks.c:

	{
		.ident = "Odys Winbook 13",
		.matches = {
			DMI_EXACT_MATCH(DMI_SYS_VENDOR, "AXDIA International GmbH"),
			DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "WINBOOK 13"),
		},
		.driver_data = (void *)&sipodev_desc
	},

And then build your own i2c_hid module with this change and this makes the touchpad
work, correct?

If you can confirm this and I will submit a patch with this change upstream.

Is it ok if I add:

Reported-and-tested-by: Rene Wagner <redhatbugzilla>

To the patch when I submit it upstream?

> Still digging into an issue with the device. It seems to go to sleep after 2s of idle time and then requires another 3s when being touched to get back to work. Of course, this is no fun. Anyone experienced similar behaviour?

Not sure if it will help (I don't think so really, but worth a shot), but does your i2c-hid module have this change:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/hid/i2c-hid?id=807588ac92018bde88a1958f546438e840eb0158

?

Regards,

Hans

I applied the patch from comment 118 and built the module.

In order to test with your patch, I would have to build a vanilla kernel, as Canonical has not yet merged the changes to their next distro. Unfortunately there have been breaking changes in the kernel, so the 4.20 i2c_hid module does not build under Stock 4.18 Kernel source.

How else can I confirm the patch working? Any live distro I can patch and build and start from USB?

Regarding touchpad sleep: The patch was not applied in my module and it seems like a perfect match. However when starting the Winbook this morning to check for your patch, the touchpad works as expected. My assumption is, that I installed tlp as the last thing before shutting down and it did not help immediately. Anyway, thanks a lot for your check and the nice finding.

(In reply to Rene Wagner from comment #256)
> I applied the patch from comment 118 and built the module.

You mean comment 128? So this patch:

https://github.com/brotfessor/sipodev/blob/master/sipodev-quirk.patch

And that fixes the touchpad not working?  If you can confirm that then the DMI strings for your model indeed need to be added to the upstream quirk table and I will submit a patch upstream for that.

Ups. I meant Comment 188. Which effectivly uses the patch from comment 128. 118 was a typo. :(

So I can confirm the patch is working and the DMI strings are:

> $ cat /sys/class/dmi/id/sys_vendor 
> AXDIA International GmbH
> 
> $ cat /sys/class/dmi/id/product_name 
> WINBOOK 13

Thanks a lot Hans.

(In reply to Rene Wagner from comment #258)
> Ups. I meant Comment 188. Which effectivly uses the patch from comment 128.
> 118 was a typo. :(
> 
> So I can confirm the patch is working and the DMI strings are:
> 
> > $ cat /sys/class/dmi/id/sys_vendor 
> > AXDIA International GmbH
> > 
> > $ cat /sys/class/dmi/id/product_name 
> > WINBOOK 13
> 
> Thanks a lot Hans.

Great. I've submitted a patch upstream adding this model to the list of models which need their i2c-hid descriptors to be overridden.

Excellent.

I also found out more about the touchpad sleep. It can be mitigated by disabling auto Runtime power management (setting to on) for the I2C PCI Controller.

In my case I used tlp and set the PCI id to the blacklist. If anyone is facing similar issue and wants to use tlp for power managment as well:

Get the right device by dmesg and lspci

> dmesg | grep i2c

and you find something like this:
> ... Touchpad as /devices/pci0000:00/0000:00:15.1/i2c_designware.1/i2c-2/...

> lspci | grep "00:15.1"
00:15.1 Signal processing controller: Intel Corporation Sunrise Point-LP Serial IO I2C Controller #1 (rev 21)

Make sure it is set to "on" for example by

> sudo tlp ac
> sudo tlp stat -e | grep "00:15.1"
/sys/bus/pci/devices/0000:00:15.1/power/control = on   (0x118000, Signal processing controller, intel-lpss)

and then set the pci address to the blacklist in

/etc/default/tlp
RUNTIME_PM_BLACKLIST="00:15.1"

Just to confirm. The patch is working.

Due to the device name hardcoding: https://github.com/torvalds/linux/blob/master/drivers/hid/i2c-hid/i2c-hid-dmi-quirks.c#L288 it did not work out of the box.

Interestingly my i2c_name is different by default: HTIX5288:00

Fortunately it could be adjusted in BIOS to: SYNA3602:00 (in case someone else stumbles upon this too)

So I'm all fine now, but the quirks might need more love to support other i2c names too later on.

Thanks everyone.

(In reply to Hans de Goede from comment #253)
> (In reply to rmbg from comment #252)
> > It seems to work: if I touch the screen left is left, right is right etc..
> > and the pointer is under my finger. I don't know anything about
> > multitouching, so I need to know what I should do (maybe trying touchegg?) 
> 
> Great, thank you for testing. I've submitted the patch upstream.
> 
> > I tested only the horizontal position
> 
> That is fine.

I'm here again. 
I installed linux (fedora and *buntu), but I have no multitouch from the touchscreen. 

If I xinput test and touch the screen using two fingers it recognize only one touch. 

Thanks

(In reply to rmbg from comment #262)
> I'm here again. 
> I installed linux (fedora and *buntu), but I have no multitouch from the
> touchscreen. 
> 
> If I xinput test and touch the screen using two fingers it recognize only
> one touch. 

xinput is not the proper way to test multitouch support. If the touchpad
is working at all, then I would expect multitouch to work fine too.

To test this you can use evemu-record.

(In reply to Hans de Goede from comment #263)
> (In reply to rmbg from comment #262)
> > I'm here again. 
> > I installed linux (fedora and *buntu), but I have no multitouch from the
> > touchscreen. 
> > 
> > If I xinput test and touch the screen using two fingers it recognize only
> > one touch. 
> 
> xinput is not the proper way to test multitouch support. If the touchpad
> is working at all, then I would expect multitouch to work fine too.
> 
> To test this you can use evemu-record.

What should I read if it's all fine?

(In reply to rmbg from comment #264)
> What should I read if it's all fine?

The output is mostly self-explanatory. For multi-touch report different touches are reported in different slots. So you should see a couple of "ABS_MT_SLOT" events in the output, with slot 0 being the first finger down and slot 2 the second finger down.

(In reply to Hans de Goede from comment #265)
> (In reply to rmbg from comment #264)
> > What should I read if it's all fine?
> 
> The output is mostly self-explanatory. For multi-touch report different
> touches are reported in different slots. So you should see a couple of
> "ABS_MT_SLOT" events in the output, with slot 0 being the first finger down
> and slot 2 the second finger down.

It seems ok, but I have no gestures in any DE I tried (I have them only for touchpad)

(In reply to Rene Wagner from comment #261)
> Just to confirm. The patch is working.
> 
> Due to the device name hardcoding:
> https://github.com/torvalds/linux/blob/master/drivers/hid/i2c-hid/i2c-hid-
> dmi-quirks.c#L288 it did not work out of the box.
> 
> Interestingly my i2c_name is different by default: HTIX5288:00
> 
> Fortunately it could be adjusted in BIOS to: SYNA3602:00 (in case someone
> else stumbles upon this too)
> 
> So I'm all fine now, but the quirks might need more love to support other
> i2c names too later on.
> 
> Thanks everyone.

Where to change the name in bios? I checked all settings...

In my case: (Bios American Megatrends 5.12, Uefi 2.5; PI 1.4; Version 1.6)

Its under: Chipset -> Touch Pad Device -> 01_I2C SYNA3602

OK, obviously I have a different device. but it seems to be the same touch pad, which I would like to have working.
In file i2c-hid-dmi-quirks.c I just changed some existing devices to match my system:
{
		.ident = "Trekstor YOURBOOK C11B",
		.matches = {
			DMI_EXACT_MATCH(DMI_SYS_VENDOR, "TREKSTOR"),
			DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "YOURBOOK C11B"),
		},
		.driver_data = (void *)&sipodev_desc
},

Then I rebuild the module and inserted it into kernel, as described in post 188 and following. 
unfortunately the touch pad is still not doing anything.

Did I miss any step? 
Thanks for your help.

What is:

$ dmesg | grep i2c

printing?

(In reply to Rene Wagner from comment #270)
> What is:
> 
> $ dmesg | grep i2c
> 
> printing?

Output is:

[    3.448412] i2c /dev entries driver
[    3.788264] i2c_hid: loading out-of-tree module taints kernel.
[    3.788291] i2c_hid: module verification failed: signature and/or required key missing - tainting kernel
[   16.303354] i2c_hid i2c-SYNA3602:00: i2c-SYNA3602:00 supply vdd not found, using dummy regulator
[   16.303402] i2c_hid i2c-SYNA3602:00: Linked as a consumer to regulator.0
[   16.303405] i2c_hid i2c-SYNA3602:00: i2c-SYNA3602:00 supply vddl not found, using dummy regulator
[   17.331316] i2c_designware i2c_designware.2: controller timed out
[   18.355736] i2c_designware i2c_designware.3: controller timed out
[   18.355776] silead_ts i2c-MSSL1680:00: Chip ID read error -110
[   18.355895] silead_ts: probe of i2c-MSSL1680:00 failed with error -110
[   19.379487] i2c_designware i2c_designware.3: controller timed out
[   19.379512] kxcjk1013 i2c-KIOX010A:00: Error reading who_am_i
[   19.379632] kxcjk1013: probe of i2c-KIOX010A:00 failed with error -110

So your module was loaded and the i2c_name is already the right one. Means you don't need BIOS changes.

There is either something wrong with your DMI match, or it is a different device and needs other quirks.

I would probably proceed with embedding some log lines in your module, checking whether the quirks were applied at all first.