gsl-firmware

gsl-firmware copied to clipboard

Hello, fairly new to this whole thing so please bear with me, I didn't really know where else to ask this question. I have a 2 in 1 tab on which I installed Mint 19.3(xfce) , it is a "French" tablet but was clearly made in China. Ubuntu (in french) tells me that the OEM is likely a jumper teclast or Chuwi, unfortunately none of the firmwares provided for those manufacturers worked. So I made an hypothesis that the firmware for the Trekstore primetab T13B would be okay (maybe not...) and simply added :

  {
	/* Archos 133 FLIP */
	.driver_data = (void *)&trekstor_primetab_t13b_data
	.matches = {
		DMI_MATCH(DMI_SYS_VENDOR, "Archos"),
		DMI_MATCH(DMI_PRODUCT_NAME, "ARCHOS 133 FLIP"),
	},
},

DMI_BOARD_NAME was TBD so i didn't include it Assuming the firmware is correct could this work or are there hidden parameters that would make this unviable? I need to know if my hypothesis is sound (I have already recompiled many times and it is a long process on a baytrail...)

P.S : my Windows install was broken which is why I didn't try to keep it or get files from it (didn't know then I'd need to drivers) so getting the files from windows is not an option.

EDIT : here's my dmesg | grep i2c

[ 3.731341] i2c /dev entries driver [ 3.931359] i2c_designware 80860F41:04: I2C bus managed by PUNIT [ 9.977871] axp20x-i2c i2c-INT33F4:00: AXP20x variant AXP288 found [ 10.007298] silead_ts i2c-MSSL1680:00: i2c-MSSL1680:00 supply vddio not found, using dummy regulator [ 10.007349] silead_ts i2c-MSSL1680:00: i2c-MSSL1680:00 supply avdd not found, using dummy regulator [ 10.010804] silead_ts i2c-MSSL1680:00: Silead chip ID: 0x80360000 [ 10.027707] axp20x-i2c i2c-INT33F4:00: AXP20X driver loaded [ 10.123331] bmc150_accel_i2c i2c-BMA250E:00: mounting matrix not found: using identity... [ 10.200256] silead_ts i2c-MSSL1680:00: firmware: direct-loading firmware silead/mssl1680.fw [ 11.333378] input: axp20x-pek as /devices/platform/80860F41:04/i2c-4/i2c-INT33F4:00/axp221-pek/input/input14 [ 11.751165] silead_ts i2c-MSSL1680:00: Initialization error, status: 0x0

Thanks in advance

Aside from the missing comma at the end of line 3, you can certainly try this. But please keep in mind that there may be subtle differences between touchscreens, even between devices of the same model line.

On the other hand, the error indicates it's a firmware or chip startup issue. The DMI overrides are primarily intended for setting touchscreen parameters such as size or number of tracking points, which is lacking in the ACPI tables of these devices or the hardware itself. If the firmware doesn't load cleanly when you copy it to /lib/firmware/.../silead/mssl1680.fw, the DMI override won't help either. But there's no harm in trying anyway...

Hello and thank you for the reply I have since found a partial firmware match with onda obook 20 plus some portions of the screen work (but the input are reversed should remove inverse and x and y parameters), though I found another match which I think would fit better the VOYO VBOOK A1 (I think it's 13 iinches) which has the firmware (and is probably the same chip ID) unfortunately while the firmware is available in the master file provided I can't find a entry relating to it in the file touchscreen_dmi.c , so I was wondering how I could determine the x and y values for my particular capacitive screen (it seems to differ from one 13.3 to another...)

here's the original entry for the touchscreen_dmi.c :

static const struct property_entry onda_obook_20_plus_props[] = { PROPERTY_ENTRY_U32("touchscreen-size-x", 1728), PROPERTY_ENTRY_U32("touchscreen-size-y", 1148), PROPERTY_ENTRY_BOOL("touchscreen-inverted-x"), PROPERTY_ENTRY_BOOL("touchscreen-inverted-y"), PROPERTY_ENTRY_BOOL("touchscreen-swapped-x-y"), PROPERTY_ENTRY_STRING("firmware-name", "gsl3676-onda-obook-20-plus.fw"), PROPERTY_ENTRY_U32("silead,max-fingers", 10), PROPERTY_ENTRY_BOOL("silead,home-button"), { } };

modified entry in touchscreen_dmi.c :

static const struct property_entry onda_obook_20_plus_props[] = { PROPERTY_ENTRY_U32("touchscreen-size-x", 2500), PROPERTY_ENTRY_U32("touchscreen-size-y", 1900), PROPERTY_ENTRY_BOOL("touchscreen-inverted-x"), PROPERTY_ENTRY_BOOL("touchscreen-inverted-y"), PROPERTY_ENTRY_BOOL("touchscreen-swapped-x-y"), PROPERTY_ENTRY_STRING("firmware-name", "gsl3676-onda-obook-20-plus.fw"), PROPERTY_ENTRY_U32("silead,max-fingers", 10), PROPERTY_ENTRY_BOOL("silead,home-button"), { } };

and thanks again for taking the time.

EDIT : Wait if I got this right you're saying that if the VOYO firmware is fully compatible and works out of the gate I won't need to modify the .c file and recompile? I thought I had to trick the chip into loading each corresponding data entry... ( I feel dumb)

EDIT2 : nevermind figured out how to extract VOYO firmware.fw

First of all sorry about the double post but who knows my trial and error may help someone someday, the entire screen is recognized now(still inverted x and y axis) so I set out trying to make my entry into the touchscreen_dmi.c with:

static const struct property_entry archos_133flip_props[] = {
	PROPERTY_ENTRY_STRING("firmware-name", "gsl1680-archos_133flip.fw"),
	PROPERTY_ENTRY_BOOL("touchscreen-inverted-x"),
	PROPERTY_ENTRY_BOOL("touchscreen-inverted-y"),	
    PROPERTY_ENTRY_U32("silead,max-fingers", 10),
	{ }
};
static const struct silead_ts_dmi_data archos_133flip_data = {
	.acpi_name	= "MSSL1680:00",
	.properties	= archos_133flip_props,
};

and in the dmi_table

static const struct dmi_system_id touchscreen_dmi_table[] = {
    {
		/* Archos 133 FLIP */
		.driver_data = (void *)&archos_133flip_data,
		.matches = {
			DMI_MATCH(DMI_SYS_VENDOR, "Archos"),
			DMI_MATCH(DMI_PRODUCT_NAME, "ARCHOS 133 FLIP"),
		},
	},	

here's dmidecode on system info:

System Information Manufacturer: ARCHOS Product Name: ARCHOS 133 FLIP Version: Type1 - TBD by OEM

and finally the error message I get when I try to compile

  CC      drivers/platform/x86/touchscreen_dmi.o
drivers/platform/x86/touchscreen_dmi.c:33:21: error: variable ‘archos_133flip_data’ has initializer but incomplete type
 static const struct silead_ts_dmi_data archos_133flip_data = {
                     ^~~~~~~~~~~~~~~~~~
drivers/platform/x86/touchscreen_dmi.c:34:3: error: ‘const struct silead_ts_dmi_data’ has no member named ‘acpi_name’
  .acpi_name = "MSSL1680:00",
   ^~~~~~~~~
drivers/platform/x86/touchscreen_dmi.c:34:15: warning: excess elements in struct initializer
  .acpi_name = "MSSL1680:00",
               ^~~~~~~~~~~~~
drivers/platform/x86/touchscreen_dmi.c:34:15: note: (near initialization for ‘archos_133flip_data’)
drivers/platform/x86/touchscreen_dmi.c:35:3: error: ‘const struct silead_ts_dmi_data’ has no member named ‘properties’
  .properties = archos_133flip_props,
   ^~~~~~~~~~
drivers/platform/x86/touchscreen_dmi.c:35:16: warning: excess elements in struct initializer
  .properties = archos_133flip_props,
                ^~~~~~~~~~~~~~~~~~~~
drivers/platform/x86/touchscreen_dmi.c:35:16: note: (near initialization for ‘archos_133flip_data’)
drivers/platform/x86/touchscreen_dmi.c:33:40: error: storage size of ‘archos_133flip_data’ isn’t known
 static const struct silead_ts_dmi_data archos_133flip_data = {

                                    ^~~~~~~~~~~~~~~~~~~

Do you outrightly see anything wrong with the entries that I have added to the file?

Edit: found my stupid mistake

static const struct ts_dmi_data archos_133flip_data = {

and not static const struct silead_ts_dmi_data archos_133flip_data = {

will let you know if everything works after i'm done recompiling

EDIT : No dice, controls are inverted no matter what I do and I seem to have a calibration issue also. I tested xinput configurator and it gave me :

Section "InputClass" Identifier "calibration" MatchProduct "silead_ts" Option "MinX" "30754" Option "MaxX" "-1331" Option "MinY" "24581" Option "MaxY" "25" Option "SwapXY" "0" # unless it was already set to 1 Option "InvertX" "0" # unless it was already set Option "InvertY" "0" # unless it was already set EndSection

Though I read online that it was only meant for resistive touch (dunno if that is still applicable today) I see that the constants in touchscreen_dmi.c are unsigned so I don't really know what to think...

I really could use your input

Hello again toying around with various firmware I came across a very interesting tidbit that was at the end of the README.md of the chuwi surfbook mini, it led me to this https://wiki.archlinux.org/index.php/Talk:Calibrating_Touchscreen and particulary `device=$(xinput_calibrator --list) device=$(sed -n 's/.Device\s"(.)".*/\1/p' <<< $device)

#reset xinput matrix xinput set-prop "$device" 'Coordinate Transformation Matrix' 1 0 0 0 1 0 0 0 1

out=$(xinput_calibrator)

device_name=$(sed -n 's/.MatchProduct"\s"([0-9]).*/\1/p' <<< $out)

wtot=$(sed -n 's/.max_x=([0-9])./\1/p' <<< $out) htot=$(sed -n 's/.max_y=([0-9])./\1/p' <<< $out)

minx=$(sed -n 's/.MinX"\s"([0-9])./\1/p' <<< $out) maxx=$(sed -n 's/.MaxX"\s"([0-9])./\1/p' <<< $out) miny=$(sed -n 's/.MinY"\s"([0-9])./\1/p' <<< $out) maxy=$(sed -n 's/.MaxY"\s"([0-9])./\1/p' <<< $out)

wtouch=$(bc <<< "$maxx - $minx") htouch=$(bc <<< "$maxy - $miny")

c0=$(bc -l <<< "$wtot / $wtouch") c1=$(bc -l <<< "-$minx / $wtouch") c2=$(bc -l <<< "$htot / $htouch") c3=$(bc -l <<< "-$miny / $htouch")

tf_matrix="$c0 0 $c1 0 $c2 $c3 0 0 1"

#alter the setting for now xinput set-prop "$device" 'Coordinate Transformation Matrix' $tf_matrix

echo "To make this permanent, save the following content under '/etc/X11/xorg.conf.d/98-screen-calibration.conf' or '/usr/share/X11/xorg.conf.d/98-screen-calibration.conf'" echo "Section "InputClass"" echo " Identifier "calibration"" echo " MatchProduct "$device"" echo " Option "TransformationMatrix" "$tf_matrix"" echo "EndSection"` this fixes my issues nearly all my issues (up until the next reboot where I have to reinput the above commands hence the"nearly" ) I seem to have read that the problem was libinput. Do you have an idea how I could remedy this?

That's strange.... putting this into an xorg.conf file should make it autoload the next time X is started. I'm not quite sure why that isn't the case.

I got it to work by putting the section directly into the libinput.conf file but now while most of the screen is pretty responsive, it has 2 relatively small deadzones, is that firmware incompatibility? another thing I noticed is that when I run dmesg | grep I2c it turns out that it's the generic mssl1680.fw that is loaded and not my modified gsl1680-xxx.fw. I'm not too sure why I have of course checked the Kernel config file and CONFIG_TOUCHSCREEN_DMI = y .

I have contacted a guy who works for the company in china I will see what comes of it (hopefully the silead.sys file or better yet the .h file). We shall see

It could be a zone that is assigned to touch buttons. Some tablets scan these using the touch panel instead of having dedicated physical buttons. Not much that can be done there, except for getting better firmware...

Hi! I have the exact same machine, the archos 133 flip. But i am not as much of an expert in linux...So all your explainations above are confusing a lot for me...

I would be so happy if you could guide me step by step to make the touchscreen work...

Thanks in advance!!