Touch Driver

[Manouchehri]

As @jon1012 mentioned in an earlier commit, there's currently no driver support for the touch screen.

In Windows 8.1, it's listed as IRQ 68 KMDF HID Minidriver for Touch I2C Device OK.

[jon1012]

The device is a xSL1680 (MSSL according to acpi, compatible with GSL I guess), wired on i2c4 and the enable bit is on an unknown gpio.

There are two candidates for the driver, the client side one by @rastersoft: https://github.com/rastersoft/gsl1680 This one gives raw info (that we can then use to move the pointer by software) and needs the GPIO bit (the gpio used to activate it) in a number useable from user space.

According to @onitake, we can get this info from the acpi table and do the math. Problem is that I didn't find the correct math yet.

For this :

cp /sys/firmware/acpi/tables/DSDT .
iasl -d DSDT

then we open the file in an editor and search for "1680" to find the correct one. You will have a GPx number and a gpi number, not useable as-is. You have to find the correspondance, I guess in the kernel source code for our cpu.

And a work in progress by @onitake (that he mentioned on a gmane discussion earlier, more on that later): https://github.com/onitake/gslx680-acpi This one needs an export of the firmware file, it's explained in the readme, and it has now an hardcoded value for resolution, but it can be changed. I haven't been able to find or export the firmware file et, if someone manages to get it I'd be very happy :)

The mailing list thread I'm refering to (my message and replies) : https://groups.google.com/d/msg/linux-sunxi/yhHVNBEPhjQ/ZcjPaHRbBgAJ

[Manouchehri]

Do you still have a working Android install to see if you can pull the firmware off? I've only backed up the Windows drivers.

[Manouchehri]

Using SileadTouch.fw (md5sum: c26109179d51cc71533f76c8f70346e3), fwtool from gslx680-acpi seems to reject it.

/tmp/gslx680-acpi/firmware > ./fwtool -c /tmp/SileadTouch.fw test.fw
Loading /tmp/SileadTouch.fw...
Invalid firmware: page command missing at start at ./fwtool line 121.

[jon1012]

Thing is I didn't find the file in my android filesystem ... :(

Le sam. 8 août 2015 à 19:38, David Manouchehri notifications@github.com a écrit :

Using SileadTouch.fw (md5sum: c26109179d51cc71533f76c8f70346e3), fwtool from gslx680-acpi seems to reject it.

/tmp/gslx680-acpi/firmware > ./fwtool -c /tmp/SileadTouch.fw test.fw Loading /tmp/SileadTouch.fw... Invalid firmware: page command missing at start at ./fwtool line 121.

— Reply to this email directly or view it on GitHub https://github.com/Manouchehri/vi8/issues/1#issuecomment-129018193.

[Manouchehri]

Hmm, could you possibly make a dd image of the partition and send it to me?

[jon1012]

I managed to find something that could possibly help, it wasn't in the specified folder but in /lib/modules. I found a file named gslx68x_ts.ko, I'll try to use fwtool on it.

[Manouchehri]

http://comments.gmane.org/gmane.comp.hardware.netbook.arm.sunxi/16859

Serge Kolotylo (sergk.admin@gmail.com) seems to have done some work on it already. I skimmed through it and the main takeaway seems to be that he didn't finish, but found out the actual resolution of the touch screen is 1145×1725. Not sure if that helps much. Might be worth it to send him an email.

[jon1012]

I tried, he didn't answer. About the resolution, I've seen elsewhere it's around 1744xsomething, I don't recall where exactly.

Here are the files I extracted.

[Manouchehri]

Ah, I just saw your reply and Gregor Riepl's followup. The Windows driver is floating around on a Russian board about upgrading it to Windows 10 if you're still looking for that firmware.

[onitake]

fwtool is used to convert a Silead-style firmware into the format I designed for gslx680_ts_acpi. If it doesn't accept your firmware, then it is either not in the correct format, uses a non-standard data order or is corrupted. To just extract the firmware image in 'classic' format from the Android driver, use fw_extractor.

The 'classic' format is relatively simple: It's always pairs of a 32 bit address followed by a 32 bit data word in little endian order. The first address in a series must be the page command 0xf0, followed by the page number. After that follows 32 consecutive data words (with incrementing addresses), making up a full 128 byte page.

I'll have a look at your firmware file later. Which one is it? Or should I check the Android .ko instead?

Oh, and if you want to use the firmware with the rasterbar driver, don't use fwtool. The original format is fine for that.

[Manouchehri]

I've fetched the Windows driver and put it in the repo if that's any easier to use.

https://github.com/Manouchehri/vi8/tree/staging/touch/firmware/windows

[onitake]

That Silead.fw looks very odd to me. Scrambled maybe?

On the other hand, the firmware images extracted from gslx68x_ts.ko look good. I recommend you open up your device and verify which GSL chip you have exactly, then pick the appropriate one from the bunch, if there is one. You can't reliably go by the ACPI ID, unfortunately.

[GalaticStryder]

Could this I2CTools be useful for us? On my Windows 10 installation there's a several of these drivers regarding to thermal, smbus and stuff. Also, have you guys tested Arch i386 builds? I can give it spin tomorrow with Kali Linux too.

[Manouchehri]

I was able to boot Arch awhile back after using nomodeset, but you will definitely have to compile your own version of grub (or use mine) since last time I checked there was no 32-bit EFI binary.

I wouldn't expect Kali to have much of a difference with drivers than Debian. Most of the packages are straight copies.

[onitake]

Try Debian multiarch. It has bultin boot support for 32/64bit EFI (Mac style), 32bit UEFI, 64bit UEFI, and MBR (Legacy).

Also, could you send me a copy of your DSDT, if possible? I'm trying to work support for various devices into gslx680_ts_acpi, but I need some more data about what other people have. You can find it at /sys/firmware/acpi/tables/DSDT

[Manouchehri]

Just on the testing installer image, right? Last time I tried the live image didn't have any 32-bit EFI bootloader on it. When I spoke with Steve McIntyre (installer image builder) in May the live image team hadn't copied his work yet (apparently the two teams are completely separate).

I can upload my DSDT next weekend if @jon1012 doesn't get to it before then.

[onitake]

They managed to merge their work into debian-installer before jessie became stable. So it's in now. It was actually Steve who pointed me in the right direction when I tried to boot Debian on baytrail. See: http://blog.einval.com/debian/CDs I don't know about the Live CDs tho.

Thanks!

[Manouchehri]

Ha, Steve's inbox must be getting crushed with new Chuwi owners wondering what the heck is up with the poor 32-bit EFI support.

Nice to know it merged into stable, I'll probably fetch a new ISO to try out.

Off topic, but have you tried Debian's new EFI stub? Looks interesting; not sure if it can boot a 64-bit kernel from 32-bit though.

[jon1012]

I was away on vacation, I'll upload the dsdt as soon as I get my hand on the tablet again :)

[onitake]

If you're back from vacation, can you send me that DSDT? :)

Also, please have a look here: https://lkml.org/lkml/2015/8/25/738

If possible, try Robert's Silead driver. It requires firmware in classic Silead format (not the one produced by fw-tool). The requested file name is the ACPI device ID in lower case, supposedly. I haven't tested this yet. In my case, this would be /lib/firmware/mssl1688 I guess.

[Manouchehri]

@sigboe Would you mind uploading your DSDT for @onitake?

[sigboe]

@Manouchehri @onitake Does this suffice? http://hastebin.com/oguvosudot.coffee

[sigboe]

@Manouchehri Bonus note: After hack installing Intel Graphics drivers made for ubuntu 15.04 in ubuntu 15.10, battery reporting started to work.

[Manouchehri]

Sweet, didn't expect that to be the solution! Which .deb did you use?

[sigboe]

https://01.org/linuxgraphics/downloads/intel-graphics-installer-linux-1.2.0

I needed to change the reported distro I had in /etc/lsb-release to 15.04 vivid, and then install it and then change it back, and then reboot.

I still have to boot with nomodeset which also turns of 3d acceleration :(

[onitake]

@sigboe: Sorry, that's just the CPU core definitions. They don't help much. I'm looking for something like the following parts: https://github.com/onitake/gslx680-acpi/blob/master/acpi/gsl-dsdt.aml

[sigboe]

@onitake I'll be home in a few hours, I'll look into it asap :)

[sigboe]

@onitake Okay them, is this more correct? https://www.dropbox.com/s/qyrv6zo90yr3ynq/dsdt.dsl?dl=0

[onitake]

@sigboe Thanks, that's better. Looks like you've got one of the simplest Silead DSDT entries I've seen so far. Chances that this will work with my driver are close to zero. There is no power management definitions, only a single GPIO pin declaration, which is likely the power control pin.

Can you try the driver I from the linux-input mailing list I linked above? As mentioned, I haven't tried it myself, but the developer included some of my suggestions to make it more compatible. You will still need to obtain appropriate firmware for your device. Find out which Silead chip you actually have, then try one of these: https://github.com/Manouchehri/vi8/tree/staging/touch/firmware/android You need to name it according to the ACPI ID so the driver will pick it up. This should be /lib/firmware/mssl1680 as far as I can tell.

[Manouchehri]

@onitake The power management seems to be taken care of by an Intel video driver from what @sigboe said earlier. Unless you're not referring to the battery?

[onitake]

@Manouchehri I was referring to the power control pin of the Silead touchscreen controller.

[sigboe]

@onitake Am I understanding correctly if I say that that driver should be in 4.3-rc2 ??

[sigboe]

https://github.com/libhybris/libhybris This might be a dirty but complete way to get all the Android drivers to work in Linux.

[onitake]

@sigboe Not that I know of. It needs to be reviewed by the linux-input team first and I haven't seen any approval yet. On the other hand, the patch should apply to any 4.1 or newer kernel without problems. Use menuconfig or add TOUCHSCREEN_SILEAD=m to your kernel .config manually, then recompile and install. Don't forget to update your initrd after. On Debian, a make modules_install && make install should do this for you.

[Manouchehri]

Should work as an out of tree module build I think, right? DKMS is probably the best solution, then you don't have to roll your own kernel. That's how Virtual Box's modules are maintained on Arch Linux while still using a stock kernel.

[onitake]

@Manouchehri As it is, the patch will not work out-of-tree. You would need at least a specially crafted Makefile to make it compile. For the time being, I suggest you just try it as it is. You don't have to rebuild and install the whole kernel anyway, just insmod the module directly.

[sigboe]

@onitake Okay so I have recompile the whole kernel, and also got bluetooth working, and added the driver you linked. (took a while, learning experience :smile: )

Do you have any suggestion of which of the firmware files you linked I should try? Or how to collect information that is relevant to figuring it out?

[onitake]

Well, the obvious answer would be: Open up your device and check the etching on the chip. If that isn't an option, you could just test different firmwares, starting with the 1680 fw (that's the lowest-end chip).

Silead touchscreen controllers don't seem to have any means of determining the exact chip ID in software. And the DSDT doesn't help either.

[sigboe]

@onitake okay so the workflow would be, download all the .fw files and put them in a folder?

cp first file /lib/firmware/mssl1688 reboot, test, cp second file /lib/firmware/mssl1688 reboot, test, repeat

[onitake]

You don't have to reboot. Just insmod the module. Check the kernel log, then rmmod if it doesn't work. Rinse and repeat.

[onitake]

It's possible you may not actually see anything in the kernel log. In that case, enable debug messages for the driver.

[sigboe]

@onitake okay I am stoked now. Omw home from work now, so I can try really soon :-)

[sigboe]

@onitake Hmm I cant find my silead module, according to my buildlog it compiled just fine. I didn't compile it as a module though (im new to compiling the kernel) so does that mean it should not be listed as a mod? And would it then be correct for me to reboot every time?

[onitake]

I strongly recommend you build it as a module instead. It will be much easier (and faster) to debug. The module should be called silead.ko and you can load it directly from the kernel build tree (just pass the exact path to insmod). No need to install it during testing.

If you compiled it into the kernel (TOUCHSCREEN_SILEAD=y), then yes, you need to reboot every time as there's no way to kick of an ACPI rescan. At least, none that I know of.

[sigboe]

Okay, I will reboot this time, since I can do this in less than the time it takes to build again :yum: But the next time I will for sure compile as a module. Also if this does not work.

[onitake]

An out-of-tree module Makefile would be even faster. See https://github.com/onitake/gslx680-acpi/blob/master/Makefile for example, it shouldn't be hard to adapt this to silead.ko.

[sigboe]

@onitake sorry I would not know what to change, and while I am really interested to learn about make files I don't know if thats the best place to start :stuck_out_tongue: I have now sudo cp <file> /lib/firmware/mssl1688 sudo reboot and tested every file in the android and windows folder now. None of them work... So, I guess I'll recompile my kernel with it as a module, then potentially enable debug message for the driver (is this before compiling?), then try to look at the logs for each file...

Or might the files be wrong or wrong format? Can I use a tool to extract the correct file if I install windows? Could the filename /lib/firmware/mssl1688 be wrong?

[onitake]

All you say could be true. :)

As I mentioned before, I have not managed to test the driver thoroughly myself, so I can't tell you for certain if everything is as I say. This is merely the information I gathered from the source code.

As for changing the Makefile, this should be really easy. You just need to change gslx680_ts_acpi to silead - use search and replace. Then, copy silead.c from the kernel tree into the same directory as the Makefile and hit make. This should give you silead.ko, which you can load with insmod ./silead.ko. Make sure the module is disabled in the kernel first (and rebuild, install and reboot), or you will have a conflict.

[sigboe]

Is this helpful, found this on Youtube. If the numbers in the bottom is important I could open mine up as well.

[onitake]

Well, this is definitely helpful. The poster seems to have a Silead GSL3676 touchscreen controller. If you have the exactly same device, you should also have the same chip. But be aware that manufacturers may change their exact hardware specs at any time. Can you open the case without damaging it?