WSL2: Missing /sys/class/dmi/id/product_version

[rlabrecque]

/sys/class/dmi/id/product_version contains hardware information required by some of my linux-only hardware drivers.

This would be a nice feature to have.

Related: #1161

[therealkenc]

required by some of my linux-only hardware drivers.

What is your use case and the nature of the "some of my", just so this one doesn't go as straight-to-chirping-crickets as #1161 did three years ago.

[rlabrecque]

Hey sorry yeah, I have a System76 laptop which has some features which only work on Linux.
Their tooling uses /sys/class/dmi/id/product_version to get the hardware provided Id of the laptop.

Another one of their tools uses dmidecode for similar purposes.

Another tool fails accessing /sys/bus/pci.

Does it make more sense for your team to potentially fix missing pieces with the goal of running a specific program/accomplishing a task/userstory?

Is there any additional way that I could contribute? I'd love to be able to turn off the backlight on my keyboard on windows. :)

[therealkenc]

some features

That word again.

with the goal of running a specific program/accomplishing a task/userstory?

Yes, the issue template that you deleted asks for the CLI steps.

Is there any additional way that I could contribute? I'd love to be able to turn off the backlight on my keyboard on windows. :)

Okay if I'm following your scenario correctly, you are running Windows 10 on your System76 laptop, and WSL under that. Correct? In this case the way to go would be to use WSL interop and a powershell script. Couldn't tell you how to do that script specifically (a quick google search wasn't encouraging) but you could pursue that on stack overflow and similar. There is no keyboard device in either WSL 1 nor WSL 2.

[rlabrecque]

Right, I'm running Win10 on my System76 Laptop and WSL[2]. This laptop has a set of tools[1] which are explicitly only available on Linux which control features (sorry) of the laptop such as the keyboard backlight, GPU switching, fan control, the screen backlight, etc. Essentially usermode drivers. which just poke at things in /sys/*

I can not use these tools to control these pieces of hardware from Windows (or WSL currently) without rewriting their code to do it.

Some of the tools available:
https://github.com/pop-os/system76-power
https://github.com/pop-os/system76-driver
https://github.com/pop-os/system76-dkms
https://github.com/pop-os/system76-firmware
https://github.com/pop-os/system76-oled

The OLED tool is the simplest one, it literally just controls the screens backlight brightness.
In that case they first read from /sys/class/dmi/id/sys_vendor, then read from /sys/class/dmi/id/product_version to get hardware information. From there (assuming compatible hardware) they then read /sys/class/backlight/intel_backlight/max_brightness and write to /sys/class/backlight/intel_backlight/brightness. [edit: The OLED tool is the least useful of the bunch for me, because I can adjust the backlight from Windows using the Intel GPU drivers. Just picked it because it's trivial.]

I guess the real question is, will we ever be able to generally interact with the hardware from WSL2?

I'm starting to understand the usage scenarios you care about now, in that implementing /sys/class/dmi/id/* is generally not that useful for me if I won't ever get access to /sys/class/backlight/intel_backlight/, /sys/bus/pci, etc. I was approaching this with the expectation that WSL2 would eventually get there, and /sys/class/dmi/id/ are just low hanging fruit which get me closer to running these tools. I'll update the first post this with the template and from this angle if it's valuable to you. 👍

[therealkenc]

I can not use these tools to control these pieces of hardware from Windows (or WSL currently) without rewriting their code to do it.

Right; if your hardware vendor doesn't provide Windows drivers then you are looking at writing them, or more realistically, coaxing existing drivers into working (mostly because these laptops are all at least loosely based off of reference designs from Intel or AMD).

On WSL 2, you aren't running your laptop's hardware. You're running Hyper-V's virtual hardware. That virtual hardware suite has a keyboard. But that keyboard doesn't have a backlight.

/sys/class/backlight/intel_backlight/

Good example. If you fire up Hyper-V in Windows Pro or better, you'll find /sys/class/backlight is empty. Even if it were implemented, you'd be controlling the backlight on the virtual display that is the big square Hyper-V application. Not the windows screen.

Or, as an other example, if you poke the power hardware controller in a VM, you aren't turning off your laptop.

I guess the real question is, will we ever be able to generally interact with the hardware from WSL2?

Answer depends entirely on "the hardware", and what the Hyper-V peeps (contrast WSL peeps) choose to emulate. For example, there's a popular ask for raw USB device support, and one could imagine, entirely in the hypothetical, that being added. But it wouldn't be a real USB device; it would be predicated on Windows USB device drivers being used emulate fake ones by Hyper-V.

In your screen backlight ask, WSL doesn't have a screen. In the keyboard backlight ask, you don't have Windows drivers even if the Hyper-V people were to emulate such a thing.

[rlabrecque]

Excellent, thank you that clears up a lot!

This was my big disconnect:

On WSL 2, you aren't running your laptop's hardware. You're running Hyper-V's virtual hardware. That virtual hardware suite has a keyboard. But that keyboard doesn't have a backlight.

I guess this is also similar to #327