Add a simple bash script generating test reports for issue #46

[LoKolbasz]

I wrote a little bash script for generating reports on linux laptops. This makes it easier it easier for volunteers to submit their test results. It generates a specs.md file that contains the results from the dmidecode commands and the fancurve. It also generates a wmi-entries.tar.gz and an acpi-tables.tar.gz file containing the wmi entries and the acpi tables respectively. These files need to be attached manually to the issue comment, while the contents of the generated specs.md files should be manually copied into the comment. The script uses the spec_issue_template.md as a template for the comment. The script also removes the UUID and the Serial Number from the system information. #46

[johnfanv2]

This is a very good idea! Are you interested in converting it into a python?

• Currently the hardest challenge is to get to get an overview which features work on which model.
• So I was thinking about automating this process and let volunteers generate a report that can be sent to me. The tool (GUI or CLI) would change a setting and read it back to check if it works. For many features the tool would also ask the user if he sees or recognizes the change, e.g. higher fan speed.
• If you can convert your script to python this would be the basis/foundation for the process mentioned above since it collects the basic system information.

If you want to convert it to python:

• You can still use command line tools like dmidecode from python if there is no simple python way (e.g. just reading it from a file).
• Formatting and extracting data is a lot easier in python.
• I can guide you through it and help you.

[LoKolbasz]

I'll see whether I can convert it to python as suggested. Other than regex do you have any specific formatting tools in mind? For now I'll probably stick to the commands in the quide (where python bindings aren't available) and invoking them through python shell access. This way I think I'll be able to get it done by the end of the week.

Another thing I thought of is that we could probably generate these issue comments through github's API, if you intend to keep using this method for user reports. I have no experience with it, but it might be worth a shot.

[johnfanv2]

Thank you a lot for your help!

I suggest the following implementation tips:

• I was just thinking about regex for input parsing and python formatting stings for output.
• If you want to parse the output of dmidecode the tool/library jc might also be interesting.
• Please only rely on tools and python libraries that are available as a system package (not pip) in the 4 main flavors in the README (Ubuntu, Fedore, ...). Though, I have not checked that jc is available on all. The package Python with bindings for dmidecode does not seem to be available as a Ubuntu system package. In that case, just call the program dmidecode though shell. You can check the file legion.py in the Python code of this repo that is already calling some programs.
• You can collect all the information retrieved in a Python dataclass. Then it can easily be later serialized to a JSON/YAML or used a the information source of a report.

I have not really though about automatically committing the data. Is you idea to use githubs's API such that LLL creates a issue/comment on behalf of the user on github or do you have another feature in mind?

[MrDuartePT]

@LoKolbasz you might want to give a look at this: https://github.com/hhd-dev/hwinfo/tree/master/devices/readme.md

I saw you extract some of the information on there, like the acpi tables, but the WMI Methods it also interesting to have

[MrDuartePT]

I have not really though about automatically committing the data. Is you idea to use githubs's API such that LLL creates a issue/comment on behalf of the user on github or do you have another feature in mind?

Being fare I don't think the github api allow that kind of things to be done.
I think would be better to have a md failed generated automatically and the user just need to paste it and move the files.

[LoKolbasz]

Being fare I don't think the github api allow that kind of things to be done. I think would be better to have a md failed generated automatically and the user just need to paste it and move the files.

I've just checked, and it is possible to create a new issue comment by using the github REST API. It requires either the github cli or a fine grained personal access token (with the required permissions). But I agree that for now this is beyond the scope of this script.

[LoKolbasz]

@LoKolbasz you might want to give a look at this: https://github.com/hhd-dev/hwinfo/tree/master/devices/readme.md

I saw you extract some of the information on there, like the acpi tables, but the WMI Methods it also interesting to have

Thanks!
I was only concerned with automating the script but yeah, it seems like a good idea. The tool suggested in the instructions doesn't have a prepackaged version but builds pretty quickly. Should we just build it from source or should we create some sort of artifact that is fetched at launch?

[MrDuartePT]

I was only concerned with automating the script but yeah, it seems like a good idea. The tool suggested in the instructions doesn't have a prepackaged version but builds pretty quickly. Should we just build it from source or should we create some sort of artifact that is fetched at launch?

Yes just build from source, save the source in /tmp that why get deleted at shutdown. I can automate that part if you prefer?

[LoKolbasz]

Thanks, but I think I can manage. 😃

[LoKolbasz]

I have not really though about automatically committing the data. Is you idea to use githubs's API such that LLL creates a issue/comment on behalf of the user on github or do you have another feature in mind?

Yes, that is what I imagined.

[LoKolbasz]

Thank you a lot for your help!

I suggest the following implementation tips:

• I was just thinking about regex for input parsing and python formatting stings for output.
• If you want to parse the output of dmidecode the tool/library jc might also be interesting.
• Please only rely on tools and python libraries that are available as a system package (not pip) in the 4 main flavors in the README (Ubuntu, Fedore, ...). Though, I have not checked that jc is available on all. The package Python with bindings for dmidecode does not seem to be available as a Ubuntu system package. In that case, just call the program dmidecode though shell. You can check the file legion.py in the Python code of this repo that is already calling some programs.
• You can collect all the information retrieved in a Python dataclass. Then it can easily be later serialized to a JSON/YAML or used a the information source of a report.

Thanks for the tip. I was checking out the pip packages for dmidecode but they all seemed to be lacking/incomplete. My plan is to parse the dmidecode output into a nested python dictionary. I was looking into reading the dmi information directly from the filesystem, as described here suggested by @MrDuartePT but dmidecode appears to extract more information than what could find in them so I'll be sticking to parsing the dmidecode output.

My keyboard's backlight is only single color with 3 intensity levels. So while I could find where the max brightness is stored, I couldn't find where the color information is. Do you know where it could be found?

Also If we make the structure of these comments more rigid, then you might be able to derive some useful metrics from them. Would you like the data to be represented as yaml/json in the markdown for easier parsing later?

Another issue is that attachments cannot be added to the markdown procedurally as githubs API does not have a file upload endpoint (for attachments). So it seems the ACPI tables will have to be attached by the user manually unless we set up a fileserver/repository where these files could be stored and linked to from the markdown.

[johnfanv2]

Thanks for the tip. I was checking out the pip packages for dmidecode but they all seemed to be lacking/incomplete. My plan is to parse the dmidecode output into a nested python dictionary. I was looking into reading the dmi information directly from the filesystem, as described here suggested by @MrDuartePT but dmidecode appears to extract more information than what could find in them so I'll be sticking to parsing the dmidecode output.

Sounds like a good idea. You could either parse in manuelly or `jc.

My keyboard's backlight is only single color with 3 intensity levels. So while I could find where the max brightness is stored, I couldn't find where the color information is. Do you know where it could be found?

On many Legion Laptops controlling and reading the backlight of the keyboard is made possible by the LLL kernel module. It exports the number of states to /sys/class/leds/*::kbd_backlight/max_brightness. But we need this info from the user to check if the driver is configured properly or how we could adapt it. So this really can't be read without using LLL itself. So I guess we should not log this automatically but ask the user.

Also If we make the structure of these comments more rigid, then you might be able to derive some useful metrics from them. Would you like the data to be represented as yaml/json in the markdown for easier parsing later?

Yes, that is exactly my idea. My idea was to create a compatibility matrix from the data to show which features are confirmed to work on which model. Therefore, we need a a more rigid structure. Thus I proposed, writing it all to a dataclass object that then could be easily serialized/deserialized to/from JSON or YAML in a single line.

Another issue is that attachments cannot be added to the markdown procedurally as githubs API does not have a file upload endpoint (for attachments). So it seems the ACPI tables will have to be attached by the user manually unless we set up a fileserver/repository where these files could be stored and linked to from the markdown.

Yeah, lets think about it later. Maybe the easiest idea is first to let the user copy the text for the message (markdown) from the output of the script and let him attach a JSON file with the data (can be easily automatically read) and the ACPI table files.

What are your thoughts about it?

[LoKolbasz]

Yeah, lets think about it later. Maybe the easiest idea is first to let the user copy the text for the message (markdown) from the output of the script and let him attach a JSON file with the data (can be easily automatically read) and the ACPI table files.

I agree that the automatic file upload is beyond the scope of this script (for the initial version at least).
Although we might be able to just dump the whole acpi tables as text in the comment I suspect that github wouldn't really appreciate it.

Anywways.

If I understand it correctly, the script should generate:

1. A markdown file with
   • All the information in a human readable format using the format in Testing new features on 2022 models [looking for testers] #46
   • A place where the compressed acpi tables can be attached
   • A place where the wmi entries can be attached
   • A place where the compressed serialized data requested in the issue can be attached
2. The compressed acpi tables
3. The compressed wmi entries
4. The compressed serialized system information (that was previously pasted into the markdown)

[LoKolbasz]

It's kind of unclear to me, what acpi tables should be uploaded. Is the DSDT.dsl file enough, or are the other files (copied/generated) in the acpi_re directory needed as well?

[MrDuartePT]

It's kind of unclear to me, what acpi tables should be uploaded. Is the DSDT.dsl file enough, or are the other files (copied/generated) in the acpi_re directory needed as well?

DSDT.dsl is enough to get all WMI call needed for LLL

[johnfanv2]

@LoKolbasz Do you need any help on it? If you already have some pieces we can also use it as the basis.