add the possibility to define specific firmware name

[holzingerm]

by loading the module with parameter fw_name=PATH/FIRMWARE.fw it is possible to load user defined firmware files especially for generic system setups it will be possible to decide which firmware to be loaded based on HW constants (e.g. product_name,..)

[onitake]

Ok, this sounds like a useful feature.

I have some reservations, though: If there are multiple touch screens in the system (unlikely, but not impossible), the module parameter can only specify the firmware name for a single controller (or more precisely: for all controllers). This is in contrast with the approach of silead_ts, where the firmware is named according to a parameter in the DSDT or DT, or (as a fallback) the hardware ID.

Of course, the hard-coded firmware name is not better either. I'd like to merge the features of silead_ts and gslx680-acpi at some point to get the most compatibility. But for now, a module parameter is fine.

I'll await your updated patch.

[holzingerm]

so you mean we shall extend the patch "in future" to allow to define multiple firmware files.

I will try to play a bit with (pointer to) arrays and how they needs to be defined by commandline loading the module

how many displays do you think shall be maximum? 3 or more

[onitake]

Not exactly.

The approach of silead_ts is more sophisticated: It checks a string parameter in the DSDT (for x86) or DT (for ARM) that specifies the exact file name. If that parameter is not available, it converts the HID (which is usually MSSL1680 on x86) to lower case and tries to load a firmware of that name. If there are multiple Silead chips in the system, each of them can have a different firmware file name in the DT.

If you use an array module parameter, there is no way to determine reliably which chip is configured first. There needs to be a way to match the parameter to the exact device entry.

So, I think it's fine to leave this as it stands, however I'm going to rework your patch a bit so it uses a device structure field instead of a global variable. Global variables are bad. :)

[holzingerm]

:-D

I know. I'm only a guy that can handle Google to fit allready developed sollutions together for my purpose :-)

[onitake]

Ah darn, it looks like that isn't possible. Module parameters are always global. But I'll still add that fw_name field and copy the value, just like in silead_ts.

[onitake]

Ok. Patch up on 3b116d9. It's untested, please let me know if it works (with and without module parameter).

[holzingerm]

I will pull your github sources cleanly and retest the patch of course thank so far.

[holzingerm]

tested, and it works like expected great

testet to load without /lib/firmware/silead_ts.fw ==> do not work (as expected) testet to load with /lib/firmware/silead_ts.fw ==> work like before (nothing broken by the patch) testet to load without /lib/firmware/silead_ts.fw and parameter fw_name=gslx680/ST70416-6.fw ==> works like a charm (firmware is stored in /lib/firmware/gslx680/ST70416-6.fw)

BTW: I played a bit around on my Trekstore Surftab Wintron 7.0 and found that creating the firmware with ./fwtool -c SileadTouch.fw -3 -m 1680 -w 885 -h 635 -t 10 -f track silead_ts.fw

is a nearly perfect setting to create a accurate firmware that also work with slide from the edge. (on the ST70416-6)

[onitake]

Awesome!

I recently uploaded new settings for the old TrekStor (ST...-5) that work fine in general, but now I'm having trouble dragging undersized scrollbars close to the edges (thank you, Firefox). Looks like I need a proper finger scrolling solution after all. Perhaps with multiple fingers? Haven't tried that at all so far.

Would you like to create a pull request on gsl-firmware, or should I commit your stuff?

[holzingerm]

no prob I will generate a pull request for the Firmware I use so you only need to apply it in the firmware repository