[TRACKER]: Features to be implemented

[kernel-dev]

As the base of this application continues to expand, and as it gets more and more complex overtime, I think opening up a “tracker” of sorts so that both users and potential contributors are very well aware of what is to (hopefully) be implemented over the years to come.

First off, let's get basic features, refactoring and further implementations necessary (or well, more-so “preferred”):

• (1.) Building an efficient and responsive TUI to toggle displaying particular data (GPUs, Device IDs, Connector types for input devices, etc.)

  • This would also include toggling data of particular groups/categories (CPU, GPU, Memory, ...)

  • Ideally, the TUI should be written in Rust, and it can then communicate with the Python codebase (using an event emitter, or something of the sorts) to tell the application what data to toggle on/off, and the device manager's methods would be called accordingly when needed.

  • However, if we, for whatever reason, decide to write the TUI in Python, there is an interop^1 already written in Rust for capturing key presses (and key combos, such as Ctrl + C), which should alleviate the concern as far as that subject is concerned. Otherwise, we would likely need to refactor the entire application to implement some adaption of curses.

  • Say the user toggles off the entire GPU category - the TUI would emit an event—which we'll arbitrarily name data_off—which the application would listen for, and remove the entire category from the device manager instance's info attribute. If the user toggles it back on, it should call the DM's (from hereon out, this is what I'll use to refer to the device manager instance) gpu_info() method.

• (2.) To quickly mention, the development team has been working on another project, whose purpose is to “pack” the core of this application (for hardware discovery) into a single, versatile library called PySysInfo^2. With this library, we could focus more on maintaining the core of OCSysInfo without bothering about retaining stability and hardware discovery. Here are some of the benefits of this approach:

  • More attention to pay to UI/UX design;

  • Makes the codebase a lot cleaner, more easy to preview, shorter, etc.;

  • We could eventually consider adapting a GUI version, which may or may not be detrimental, but this is still in discussion.

• (3.) Add detection for Display devices (resolution, which parent GPU it's attached to, refresh rate, model, etc.) — this would be rather convenient for our end-users, as I've seen a lot of individuals struggle to find the exact model of their monitor on the occasion.

• (4.) Implement codename detection for Apple ARM64 chips (M1, M1 Pro, M1 Max, etc.); this would be a hard-coded list, which we can gradually update as each new model comes around.

• (5.) Refactor CPU codename managers (for Intel and AMD) to pull from a hardcoded list instead of fetching them online (so that offline compatibility remains)

• (6.) Add detection for chipsets; this would be rather challenging, because I'm not entirely certain if Windows and Linux expose this information anywhere, but it is still worth looking into.

That is pretty much it for now, it is going to be a long journey, but I'm hoping they'll come around eventually.

I will be continuously updating this as features are implemented, or if there are any other features that may be useful which require implementations.

[Overc1ocker]

[Input] Does not work on linux.

When I run this tool, no input devices show up. I assume this has not been implemented yet so here are some tips.

Hwinfo already some of what you need. Here are the input devices on my laptop

21: **PS/2 00.0: 10800 Keyboard**                                   
  [Created at input.226]
  Unique ID: c3zD.+49ps10DtUF
  Hardware Class: keyboard
  Model: "AT Translated Set 2 keyboard"
  Vendor: 0x0001 
  Device: 0x0001 "AT Translated Set 2 keyboard"
  Compatible to: int 0x0211 0x0001
  Device File: /dev/input/event4
  Device Files: /dev/input/event4, /dev/input/by-path/platform-i8042-serio-0-event-kbd
  Device Number: char 13:68
  Driver Info #0:
    XkbRules: xfree86
    XkbModel: pc104
  Config Status: cfg=new, avail=yes, need=no, active=unknown

36: PS/2 00.0: 10500 PS/2 Mouse                                 
  [Created at input.249]
  Unique ID: AH6Q.EtaYDSYgYo2
  Hardware Class: mouse
  Model: "DELL0817:00 044E:121F Mouse"
  Vendor: 0x044e 
  Device: 0x121f "DELL0817:00 044E:121F Mouse"
  Compatible to: int 0x0210 0x0043
  Device File: /dev/input/mice (/dev/input/mouse0)
  Device Files: /dev/input/mice, /dev/input/mouse0, /dev/input/event16
  Device Number: char 13:63 (char 13:32)
  Driver Info #0:
    Buttons: 3
    Wheels: 4
    XFree86 Protocol: explorerps/2
    GPM Protocol: exps2
  Config Status: cfg=new, avail=yes, need=no, active=unknown

37: PS/2 00.0: 10500 PS/2 Mouse
  [Created at input.249]
  Unique ID: AH6Q.DZfybgQnY29
  Hardware Class: mouse
  Model: "DELL0817:00 044E:121F Touchpad"
  Vendor: 0x044e 
  Device: 0x121f "DELL0817:00 044E:121F Touchpad"
  Compatible to: int 0x0210 0x0002
  Device File: /dev/input/mice (/dev/input/mouse1)
  Device Files: /dev/input/mice, /dev/input/mouse1, /dev/input/event17, /dev/input/by-path/pci-0000:00:15.1-platform-i2c_designware.1-event-mouse, /dev/input/by-path/pci-0000:00:15.1-platform-i2c_designware.1-mouse
  Device Number: char 13:63 (char 13:33)
  Driver Info #0:
    Buttons: 2
    Wheels: 0
    XFree86 Protocol: explorerps/2
    GPM Protocol: exps2
  Config Status: cfg=new, avail=yes, need=no, active=unknown

[kernel-dev]

Thank you for your input, @Overc1ocker. However, it is technically implemented, don’t know on which distributions it does and doesn’t work, nor do I care that deeply about it. I, personally, cannot be arsed to deal with Linux. The entire reason why Linux is even supported is due to the help from a plethora of wonderful users who helped me in figuring out how to implement each feature for Linux platforms.

For the record, here you can find the exact method responsible for extracting input device information.

This, of course, might not work across various distributions, as each distro developer(s) tend to pertain to their own ideologies and practices, and I do not want to hassle myself with keeping up with every distro’s custom practices. Some of the methods there I didn’t even write at all. input_info was written by @1Revenger1, block_info (storage) was written by @rvstry, mem_info was greatly contributed by @flagersgit, @nadiaholmquist, @joshj23, @rusty-bits, cpu_info for ARM platforms was written by @ThatCopy.

Obviously, contribution of users doesn’t only pertain to the Linux platform, but major contributions were done there. I’m thankful to all of them for their work, and OCSI wouldn’t be what it is without them.