Prestigio Multipad Visconte Quad - almost working, no touchscreen

[Kajetan Krykwiński]

Device sold with 8.1. UEFI 32bit, has legacy boot that does not work. Need proper UEFI pendrive to boot.

Has Atom Z3735G, 1GB ram, 16GB EMMC, 8" 1280x800 display, G-sensor, BT 4.0, WiFi, USB Host & charge (2.0), two cameras.
I had to change allocated GPU memory from 32 to at least 64MB in UEFI.

Devices, according to UEFI info:
Audio: Realtek ALC5642
MPI Panel: Panasonic 19x12
WiFi + BT: Realtek RGN RTL8723BS
Rear camera: Lite-On 12P2BA535
Front camera: Lite-On 13P2SF221
Charger: TI BQ24296BGE
Fuel Gauage: Maxim Max17047
ALS Sensor: Capella CM32181
Gyro sensor: ST-Micro L3GD20
Accel/Compas sensor: LSM303DLHC
No GPS Built-in

So I checked 4.4-r3 generic build, booted live and it seems to work.
What I tested:
Display, buttons, suspend (at least turns off the screen)
WiFi works OK, BT not tested yet (but it's wifi/bt combo so should work)
3D acceleration works, started Ingress without problem (using WiFi localisation)

As device has only VolUp/VolDown/Power it's impossible to select position in bootloader without usb keyboard, it jumps between items.

Device was running very hot under android. Maybe CPU governor, i was running out of battery so not checked that.

Sadly, touchscreen is not working. Under Windows it identifies itself as
"KMDF HID Minidriver for Touch I2C Device" with identifiers
HID\MSSL168A&COL01\4&24259C19&0&0000 (hid compatibile touchscreen)
ACPI\MSSL168A\3&4820EFC&0 (KMDF HID Minidriver..)
and it's obviously an i2c device.

Any chances to support this touchscreen?
I had some experience porting linux to WinCE PDAs, but that was a looong time ago.

[Kajetan Krykwiński]

Ok, in the meantime I disassembled device and found ts controller, that happens to be Silead GSL3670, and there's existing driver for it:

http://www.spinics.net/lists/linux-input/msg39997.html

I'll try to build kernel with this driver.

[Kajetan Krykwiński]

Ok, after some investigation, ts identifies itself as MSSL168A, while should use gsl3670. Adding my ID to module source code loads it with error, as I don't have firmware and have no idea where to find it, for now this thread is dead :(

[Kajetan Krykwiński]

I found some information about person who got the same touchscreen working:

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

Looks that the problem is about finding correct GPIO to enable touchscreen at all. Any sugestions about how to do this?

I saved GPIO map from kernel debugfs here: http://pastebin.com/gYNQbJ4y

[Povilas Staniulis]

There may be firmware files in Windows drivers.

[Kajetan Krykwiński]

I attached driver dumped from original Win8.1 instalation. There's only inf+cat+sys combo, so if firmware is not somehow embedded into .sys or kept somewhere else, it's not there.

I also attached kernel debugger and tried removing/installing this driver, after install it report that some "config file" is missing, then that it found I2C and GPIO and touchscreen works.

[Kajetan Krykwiński]

In 3rd version of Silead driver, written by Intel employee, (http://lkml.iu.edu/hypermail/linux/kernel/1508.3/01705.html) there's information that

If there is no named GPIO for power it falls back to using an indexed GPIO and it requests the GPIO pin with index 1. If there isn't one it disables PM support.

and in source code

#define SILEAD_PWR_GPIO_NAME "power"

Indeed, on GPIO list I posted previously there exists GPIO named "power" (gpio-16 on INT33FC:02). So it's time to try again :)

[Kajetan Krykwiński]

Ok, with some updated knowledge.

This "power" GPIO is indeed already used by some module, I don't know if it's possible to find what requested it. I guess that correct method will be enabling driver debugging for whole kernel and looking in logs?

I tried to play with this intel driver. With debugging enabled it fails on "Shutdown GPIO request failed" and obviously there's no communication later. 

I disassembled ACPI table (available there: http://paste.ubuntu.com/13267890/), touchscreen-specific entries are similar to ones I found there: https://github.com/Manouchehri/vi8/issues/1 (they have GSL3676 that identifies as MSSL1680 and were lucky with intel driver... but only on Arch Linux kernel for some reason). They have TS on GPIO...1 while in my case GPIOs starts from 244 (different method of assigning numbers between kernels?). If I find some time, I'll try to play with Arch then...

For easier tests I changed driver code a bit to use old GPIO api (that allows to use GPIO by it's number), exposed it as module parameter and tried to load module in foreach loop, iterating by all GPIO IDs. Sadly, without luck. But this can also mean that GPIO 354 (16 on INT33FC:02) is correct one, but some module used it by mistake and thus I can't access it.

[Michał Ostrowski]

Do you happen to have physical buttons and/or rotation sensor working?

[Kajetan Krykwiński]

Physical buttons yes (vol up/down shows volume OSD, power turns of display (but no backlight). Rotation sensor AFAIR wasn't working.

[Michał Ostrowski]

This might be all related to weird/nonstandard GPIO configurations, since the touchscreen in my device also uses GPIO (removing GPIO drivers from Windows kills both touchscreen and physical buttons). Do you have any idea how to read device's GPIO configuration?

[Kajetan Krykwiński]

Sadly no. This touchscreen won't respond to any I2C commands until it's somehow enabled. Windows kernel debugger shows info printed by driver that it found i2c and gpios, but no idea how. 

Now I know at least that those gpio names in debugfs are assigned by drivers, thus volume_down, volume_up and power are just hardware button gpios, power is not related to touchscreen.

What I also did already was modifying this Intel driver a bit to provide GPIO number as module parameter, and tried to load it in bash loop for every existing gpio, without success.