Dax89

Dax89

Forum Replies Created

Viewing 10 posts - 1 through 10 (of 10 total)
  • Author
    Posts
  • #44746
    Dax89
    Participant
    • Posts: 10

    @dax89, another thing. …

    @dax89, thanks good info. What is the significance of this ID 9111 in the gmesg ouput?… “[ 6.768243] Goodix-TS i2c-GDIX1001:00: ID 9111, version: 1060” Btw I found this which supports what you said…

    Re: [PATCH v7 3/9] Input: goodix – write configuration data to device On Thu, Oct 08, 2015 at 01:19:29PM +0300, Irina Tirdea wrote: > Goodix devices can be configured by writing custom data to the device at > init. The configuration data is read with request_firmware from > “goodix_<id>_cfg.bin”, where <id> is the product id read from the device > (e.g.: goodix_911_cfg.bin for Goodix GT911, goodix_9271_cfg.bin for > GT9271). > > The configuration information has a specific format described in the Goodix > datasheet. It includes X/Y resolution, maximum supported touch points, > interrupt flags, various sensitivity factors and settings for advanced > features (like gesture recognition). > > Before writing the firmware, it is necessary to reset the device. If > the device ACPI/DT information does not declare gpio pins (needed for > reset), writing the firmware will not be available for these devices. > > This is based on Goodix datasheets for GT911 and GT9271 and on Goodix > driver gt9xx.c for Android (publicly available in Android kernel > trees for various devices).

    Also in the git log I saw this…

    commit d1395df8cb307addc94cdbdfbdfe77c8047c2706 Author: Irina Tirdea <[email protected]> Date: Tue Jun 9 11:04:40 2015 -0700 Input: goodix – export id and version read from device Goodix touchscreens export through their registers a Product ID and Firmware Version. The Product ID is an ASCII encoding of the product name (e.g.: “911”). Export to sysfs (through the input subsystem) the product id and firmware version read from the device rather than using constant values.

    and this… https://patchwork.kernel.org/patch/6915171/

    tip-bot for Irina Tirdea – July 31, 2015, 5:42 p.m. This patch is not meant to be applied. It can be used to test updates to the goodix touchscreen configuration. It provides a bash script to help generate a new configuration starting from the one read from the device. Below are instructions on how to test that the config is correctly updated for goodix 911 touchscreens. For other models you need to replace 911 with your model ID. On the target: – dump current configuration of the device: $ cat /sys/class/input/input4/device/dump_config > goodix_911_cfg On the host: – modify some fields from goodix_911_cfg (e.g. change resolution of x/y axes, maximum reported touch points, switch X,Y axes). For more details check datasheet for format of Configuration Registers. – run tools/touch-goodix-generate-fw.sh on the modified script to obtain a valid config (it needs to recompute the checksum, set Config_Fresh to 1 and generate the binary config firmware image): $ ./tools/touch-goodix-generate-fw.sh goodix_911_cfg – copy goodix_911_cfg.bin on the target in /lib/firmware – when the goodix driver is initialized it will read the new config firmware from /lib/firmware/goodix_911_cfg.bin and write it to the device – check that the new firmware was actually written to the device by reading the config again on the target from /sys/class/input/input4/device/dump_config. Also check that Config_Fresh has been reset to 0. You can also check if the functionality changed in the config has actually changed (reported resolution for x/y has changed, x,y axis are switched, etc.)

    As dmesg log says, it’s the product id for that Goodix touch screen 🙂
    It seems to be part of the Goodix’s “communication interface” in order to recognize different models and load the correct configuration file.

    @zak, where are you guys posting about status and debugging? Only on Github or some forum? I would like to follow it to learn 🙂

    Only on GitHub.
    If you are already a developer, and you have some information about how a devices works (datasheet, similar device, communication data sniffed from windows), it’s not so hard do make a kernel driver.
    Other helpful things are (for example):

    • Create a table/wiki for any device in order to understand which device works and which doesn’t (which is like you said before), kernel version and distro used is very important too.
    • Post any useful resources (datasheet, similar drivers, android kernels which contains support for a particular device) in order to make developer’s life easier (if any).

    About Vi10/Hi10 touch screen, I was lucky, because the datasheet can be found online and there is a similar driver (Chipone 83XX) in stock kernel, but as I said before it’s the first “useful driver” of my life 🙂

    #44387
    Dax89
    Participant
    • Posts: 10

    Yes it’s the touch configuration.

    In these cases, the best thing to do is to look the driver’s source code in FreeElectrons, for goodix touchscreen we need to look at the “probe” procedure here:

    At some point the driver creates a string which looks like to be a filename: goodix_[touchscreen_id]_cfg.bin and it’s followed by a firmware request by calling “request_firmware_nowait”, this function is new to me so I have googled around in order to know where it looks for files, and I have found this documentation directly from kernel.org: https://www.kernel.org/doc/Documentation/firmware_class/README

    Which says:

    
    1), kernel(driver):
    - calls request_firmware(&fw_entry, $FIRMWARE, device)
    - kernel searches the firmware image with name $FIRMWARE directly
    in the below search path of root filesystem:
    User customized search path by module parameter 'path'[1]
    "/lib/firmware/updates/" UTS_RELEASE,
    "/lib/firmware/updates",
    "/lib/firmware/" UTS_RELEASE,
    "/lib/firmware"
    

    So it looks like that it’s the “standard firmware folder” of linux.

    And, about this:

    
    #ifdef CONFIG_OF
    static const struct of_device_id goodix_of_match[] = {
    { .compatible = "goodix,gt911" },
    { .compatible = "goodix,gt9110" },
    { .compatible = "goodix,gt912" },
    { .compatible = "goodix,gt927" },
    { .compatible = "goodix,gt9271" },
    { .compatible = "goodix,gt928" },
    { .compatible = "goodix,gt967" },
    { }
    };
    
    MODULE_DEVICE_TABLE(of, goodix_of_match);
    #endif
    
    

    That’s for Open Firmware systems, honestly I’ve never seen a device which uses that (yet), I have always noticed that Intel chipsets/soc uses ACPI id in order to match a device, so we can ignore that, instead, in our case, the kernel looks for:

    
    #ifdef CONFIG_ACPI
    static const struct acpi_device_id goodix_acpi_match[] = {
    { "GDIX1001", 0 },
    { }
    };
    module_device_table(acpi, goodix_acpi_match);
    #endif
    
    #43900
    Dax89
    Participant
    • Posts: 10

    The dmesg posted by @Destry on LM forum gives some hints:

    
    destry@destry-Default-string ~ $ dmesg | grep -i goodix
    [ 6.859742] Goodix-TS i2c-GDIX1001:00: ID 9111, version: 1060
    [ 6.868759] Goodix-TS i2c-GDIX1001:00: Invalid config, using defaults
    [ 6.868943] input: Goodix Capacitive TouchScreen as /devices/pci0000:00/808622C1:05/i2c-13/i2c-GDIX1001:00/input/input8
    [ 6.870031] goodix_backport: module verification failed: signature and/or required key missing - tainting kernel
    

    This log means:

    1. Linux mint kernel is compiled with Goodix touchscreen support, there is no need to use an external driver, which is pretty good.
    2. The second line tells that the driver loads correctly but in the third one tells that it can’t load/find configuration and uses the default one, which might not be good for Hi12’s touchscreen’s requirements.

    Every firmware/configuration file can be found in windows drivers’ archive: even windows needs to load these “extra” information from somewhere.

    If the screen works in live, it might be useful to compare dmesg logs and see if it gives some extra hints 🙂

     

    #43615
    Dax89
    Participant
    • Posts: 10

    Yes, should work that one too because it references the same ACPI id 🙂

    #43456
    Dax89
    Participant
    • Posts: 10

    Chuwi Hi12 have a Goodix Touchscreen (ACPI id “GDIX1001”).
    I have searched its id on github and this should be the driver: https://github.com/SharkBa1t/ap523/blob/master/drivers/input/touchscreen/goodix.c

    PS: Someone have managed to get the battery working on these tablets?
    In my case, an entire bus (i2c, no. 7) is undetected because the kernel can’t take the ownership (the “bad” driver is i2c_designware_baytrail).

    That bus contains the battery controller and module (made by X-Power).

     [ 2.916762] i2c_designware 808622C1:06: I2C bus managed by PUNIT
     [ 3.016401] i2c_designware 808622C1:06: punit semaphore timed out, resetting
     [ 3.016714] i2c_designware 808622C1:06: PUNIT SEM: 2
     ....
     [ 3.017651] i2c_designware 808622C1:06: couldn't acquire bus ownership
     [ 3.018004] i2c_designware: probe of 808622C1:06 failed with error -110

    A good news is that the kernel seems to have the X-Power battery controller drivers (AXP288) but it’s not enabled by default.

    EDIT: Goodix driver is even in mainline kernel!

    #43275
    Dax89
    Participant
    • Posts: 10

    Wait wait!

    Vi10 is a lot different that Vi10 Ultimate (from the hardware point of view).
    I don’t own an Hi12, so I don’t know which touchscreen have, however it’s possible to look in Windows 10’s device manager.

    #43271
    Dax89
    Participant
    • Posts: 10

    The driver needs to flash and boot the touchscreen’s firmware before getting any info ?<noscript>?</noscript>It’s on the repository now. I’m also adding the “install” step in order to use it like any order driver.

    OK cool. So was I even close here?

    Yes 🙂

    #43270
    Dax89
    Participant
    • Posts: 10

    @bradley-baker:

    Read above this post.

    The firmware comes from Chipone’s windows driver.
    I don’t find anything strange on it, there are some wifi cards (like the one in my Vi10 Ultimate) that needs to flash firmware before doing anything.

    #43266
    Dax89
    Participant
    • Posts: 10

    The driver needs to flash and boot the touchscreen’s firmware before getting any info 🙂

    It’s on the repository now.
    I’m also adding the “install” step in order to use it like any order driver.

    #42748
    Dax89
    Participant
    • Posts: 10

    Hi guys!

    I’m new here, but I have followed all topics related to Cherry Trail tablet issues for months (especially this topic and the Linux Mint on Hi10 one), I own a Chuwi Vi10 Ultimate and it seems that those tables shares the same issues (Wifi, Sound, Touch and Battery).

    I have worked much more with the touch screen issues: searching on internet I have found the some people have found the datasheet for ChipOne IC88xx and an user called SergK have developed a polling based driver for those touch screens, development is stopped for two months because there was some issues about waking up the screen.

    I have developed an ACPI, Interrupt based driver from scratch based on those informations (link), now I’m able to detect the number of fingers on screen and move the cursor, even the capacitive button is detected (but not handled), I’m testing it on Antergos with kernel 4.6.3.

    I’m a developer, but this is my first (useful) driver, so forgive any trivial errors in its source code 😀

    I share the code here because it might be useful to other tablet owners (Vi10, Hi10 and other brands too)

Viewing 10 posts - 1 through 10 (of 10 total)

Lost Password

Skip to toolbar