Open LoKolbasz opened 1 week ago
This is a very good idea! Are you interested in converting it into a python?
If you want to convert it to python:
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.
Thank you a lot for your help!
I suggest the following implementation tips:
jc
might also be interesting.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.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?
@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
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.
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 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 theWMI 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?
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?
Thanks, but I think I can manage. :smiley:
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.
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 fordmidecode
does not seem to be available as a Ubuntu system package. In that case, just call the programdmidecode
though shell. You can check the filelegion.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
.
Thanks for the tip. I was checking out the
pip
packages fordmidecode
but they all seemed to be lacking/incomplete. My plan is to parse thedmidecode
output into a nested python dictionary. I was looking into reading thedmi
information directly from the filesystem, as described here suggested by @MrDuartePT butdmidecode
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 themarkdown
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?
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:
markdown
file with
acpi
tables can be attachedwmi
entries can be attachedacpi
tableswmi
entriesmarkdown
)
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 thedmidecode
commands and thefancurve
. It also generates awmi-entries.tar.gz
and anacpi-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 generatedspecs.md
files should be manually copied into the comment. The script uses thespec_issue_template.md
as a template for the comment. The script also removes theUUID
and theSerial Number
from the system information. #46