Linux Mint on Chuwi Hi10 & Hi12 Tablets

Linux Mint on Chuwi Hi10 & Hi12 Tablets

TechTablets Forums Chuwi Forums Chuwi Hi10 Discussion Linux Mint on Chuwi Hi10 & Hi12 Tablets

This topic contains 431 replies, has 58 voices, and was last updated by  Brad 5 months, 1 week ago.

Viewing 15 posts - 181 through 195 (of 432 total)
  • Author
    Posts
  • #43615

    Dax89
    Participant
    • Posts: 10

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

    #43891

    BBaker
    Participant
    • Posts: 283

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

    @dax89, I just saw this page that details getting the Chuwi Vi8 working on Ubuntu.  If you scroll down the the TOUCH section on that page you see he also installs a firmware file (silead_ts.fw). So I’m assuming that @destry also needs a firmware file for his Hi12.  Where can he find this file?  Oh… also, @destry said that when he booted up from a Live USB of Linux Mint the touchscreen worked, then after he installed it no longer did.  That seems strange to me. Any ideas?  Destry said…

    Before I wiped the drive and did the full install, the touch screen worked with live usb on Cinnamon18. After I wiped the drive, never had the touch screen work since even with the live usb. I have a suspicion there must have been a driver for Bios on a partition on the drive.

    #43900

    Dax89
    Participant
    • Posts: 10

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

    
    [email protected] ~ $ 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 🙂

     

    #43929

    BBaker
    Participant
    • Posts: 283

    Good feedback Dax, thanks.  It’s at least some paths to investigate by Destry.

    #44361

    BBaker
    Participant
    • Posts: 283

    `
    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 ?

    @dax89, on the Chuwi forum I found a config file for the Hi12 called TouchSetting.gt with the following contents.  It looks like this should be the TS config file. Now how/where to put it in Linux?…

    [Setting]
    ;UpdateCFG=0
    SendCFG=1 ;Send CFG to touch IC when loading driver
    SleepDisable=0
    PhysicalXsize=3072 ;Physical size£¬the unit is 0.1mm
    PhysicalYsize=1800

    [Support]
    ESD=1 ;Driver supports ESD recovery processing
    ;SensorID=0 ;According to the different SensorID send different configuration
    GtpTool=0 ;GuitarTestPlateform tool support
    X2X=0
    Y2Y=0
    X2Y=0
    Log=1
    Flashless=0
    ICType=GT910
    PrtScreen=0
    CtrlAltDel=0
    HomeKeyTouchTime=3
    VolumeKeyEnable=0
    FingerFirst=0
    PenAsFinger=0
    resetRevert=0

    [Feature]
    Pen=1 ;stylus/pen support
    NumberOfKey=1 ;The total number of keys supported,equal to 0 does not support key
    Key1=0xe3 ;0xe3 is home key,Must be a hexadecimal number
    Key2=
    Key3=
    Key4=

    [CFG]
    DefaultCFG=0x00,0x70,0x08,0x78,0x05,0x0A,0x7D,0x01,0x01,0x08,0x19,0x0F,0x64,0x3C,0x03,0x05,0x00,0x00,0x00,0x00,0x12,0x23,0x00,0x18,0x1A,0x1E,0x14,0x95,0x35,0xFF,0x38,0x3A,0x12,0x0C,0x00,0x00,0x00,0x21,0x03,0x1D,0x16,0x18,0x1A,0xA0,0x82,0x03,0x41,0x28,0x1E,0x00,0x00,0x31,0x4F,0x94,0xD5,0x02,0x08,0x00,0x00,0x04,0x8F,0x33,0x00,0x88,0x38,0x00,0x7F,0x3E,0x00,0x79,0x44,0x00,0x73,0x4B,0x00,0x73,0x80,0x00,0x00,0x00,0xF0,0x4A,0x3A,0xFF,0xFF,0x27,0xFF,0x00,0x00,0x4A,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x01,0x02,0x03,0x04,0x05,0x06,0x07,0x08,0x09,0x0A,0x0B,0x0C,0x0D,0x0E,0x0F,0x10,0x11,0x12,0x13,0x14,0x15,0x16,0x17,0x18,0x19,0x1A,0x1B,0x1C,0x1D,0x2A,0x29,0x28,0x27,0x26,0x25,0x24,0x23,0x22,0x21,0x20,0x1F,0x1E,0x1D,0x1C,0x1B,0x19,0x18,0x17,0x16,0x15,0x14,0x13,0x12,0x11,0x10,0x0F,0x0E,0x0D,0x0C,0x0B,0x0A,0x09,0x08,0x07,0x06,0x05,0x04,0x03,0x02,0x01,0x00,0xDD,0x01
    senserid_0=
    senserid_1=
    senserid_2=
    senserid_3=
    senserid_4=
    senserid_5=

    #44367

    BBaker
    Participant
    • Posts: 283

    @dax89, another thing. You think this device ID could be causing a problem?

    #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
    
    #44424

    BBaker
    Participant
    • Posts: 283

    @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.)

    #44637

    BBaker
    Participant
    • Posts: 283

    <!–more–> <hr />

    Unfortunatly, Dax89 don’t have Hi10, and it’s the only driver developer for our tablets… The good way can be to add money on paypal account, and gift to him a Chuwi Hi10 DualOS for working on it (and HiBook, except touchscreen it’s the same internal hardware/software). ?<noscript>?</noscript>I’m ready to give 20€/$, there is people who want participate ?

    <!–more–>I am working with him to make this driver full support hi10 the driver is on github you can add code and report, i have compiled kernel with sound patch will test it

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

    #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 🙂

    #45113

    Anonymous
    • Posts: 77

    If you would like to be able to customize this USB Linux Mint installation (to be able to make changes on it, which will be available on the next USB boot), then use this HOWTO: Live USB Creator.

    I tried Live USB Creator but it failed on two different USB sticks trying to write two different versions of Linux Mint (17.3 and 18 – it actually does not recognize 18 yet).

    Error while installing syslinux bootloader! Installation aborted.

    The failure is at the end of the process.

    Anyone else seeing this, please?

    It would be nice to be able to edit the USB stick – not sure why unetbootin won’t do that.

    Thanks – David

    #45119

    BBaker
    Participant
    • Posts: 283

    Use Rufus or Unetbootin. I have used both and they work well.

    #45126

    Anonymous
    • Posts: 77

    Use Rufus or Unetbootin. I have used both and they work well.

    I’m not sure what happened to my reply to this …

    Anyhow, does either create an editable USB stick, please?

    That was the reason I tried Live-USB-Install.

    I read somewhere that having an editable USB stick will be helpful to this evolving project …

    #45128

    BBaker
    Participant
    • Posts: 283

    Indeed Rufus does not support persistent data, I had not noticed that before because I don’t normally use it.  Unetbootin has a field (option) where you can specify “space used to preserve files across reboots” but in paren’s it says “Ubuntu only” so that may not be there in the Windows version if that’s what you’re using.  There is a list of such USB creation apps here: https://en.wikipedia.org/wiki/List_of_tools_to_create_Live_USB_systems
     Of those Etcher.io and the Fedora Live-USB tool looks interesting. I’ve not used any of them yet.  Obviously using a main distro tool from eg., Ubuntu, Fedora, etc., is the more secure choice. Edit: nevermind; Etcher is open source so it’s prob safe.

    #45138

    Anonymous
    • Posts: 77

    I was trying to follow the instructions here as part of setting up Etcher:

    https://github.com/probonopd/AppImageKit/wiki/FUSE

    I could not find FUSE in the JustLighthouse64/Slackware repository, so I went the non-FUSE route.

    What might this have done to my Linux directory?

    bash-4.2# mount -o loop Etcher-linux-x64.AppImage /mnt

    Suddenly I can’t look inside any folders.

    I did this by opening a folder, then opening a terminal …

    Is the solution as simple as “umount /mnt” in the same location?

    How do I undo it?

    What about “losetup -d /initrd/mnt”, based on what I read at these links?

    http://linux.about.com/od/commands/l/blcmdl8_mount.htm

    http://linux.about.com/library/cmd/blcmdl8_losetup.htm

    bash-4.2# losetup -f
    /dev/loop3
    <root> /initrd/mnt
    bash-4.2# losetup -d /initrd/mnt
    losetup: /initrd/mnt: Inappropriate ioctl for device
    <root> /initrd/mnt
    bash-4.2#

    Just reboot?

    Thanks

Viewing 15 posts - 181 through 195 (of 432 total)

You must be logged in to reply to this topic.

Lost Password