3 ms·

Who's right? Trees couple hierarchy into information, and there lies the problem. Same thing could be modelled as a table, and allow both views: root

Who's right? Trees couple hierarchy into information, and there lies the problem. Same thing could be modelled as a table, and allow both views: root hw vendor_submodule acpi vendor fujitsu vendor_feature lcd_brightness submodule backlight feature brightness value 4 Architecture ain't easy...

lilyball 7y ago
I'm not aware of any sysctl values that can be accessed from two separate paths.
- ahartmetz 7y ago
  IIRC there are many values like that. There are "subsystem" or "driver" directories that don't even look like symlinks but lead into other subtrees. You can use such inter-subsystem links to create infinitely long sysctl paths.
twblalock 7y ago
Why is it necessary to include vendor information in a setting like this? The value, which represents the user’s desired brightness setting, could be an opaque number and the device driver could be responsible for translating that into whatever is needed to make the display behave.
asveikau 7y ago
The freebsd laptop I'm writing this on has: $ sysctl -a | grep brightness hw.acpi.video.lcd0.brightness: 50 compat.linuxkpi.i915_invert_brightness: 0 So if you want to write a script that works both, you need to put fujitsu-specific knowledge in your script. Vs. alternatively, an interface that works everywhere. (Incidentally I think this sysctl doesn't do much and I instead use a utility called intel_backlight(1) from ports.)
- aphextron 7y ago
  What laptop are you using for freebsd? Also what desktop environment? I've tried forever to get a BSD laptop setup working.
  - asveikau 7y ago
    Lenovo X1 Carbon 6th gen. I don't use a big "desktop" like gnome, just a normal/light X setup resembling the 1990s. Lately it's dwm. Sometimes I do others. Some things that might save you some time in loader.conf: acpi_video_load="YES" acpi_ibm_load="YES" Also, had to set ACPI to "Linux" mode in bios. After that plus the two lines above, suspend works. Also, xf86-video-intel from ports. Wifi is slow but I'm ok with that. Long ago I used OpenBSD on a laptop, and in my experience, with thinkpads, it has a bit more of a "just works" feel than FreeBSD for hardware support. But I'm on freebsd because of a few things that don't work on openbsd these days [like linux binary emulation].
  - jonhohle 7y ago
    For what value of working? I have a Lenovo X220 that works mostly fine. Sleeps on lid close, WiFi, trackpad. I don’t use it often, I keep it as a disposable backup, but it works.
- ryanthedev 7y ago
  I like how the abstraction point is at LCD. It's abstracting a specific hardware type, not a hardware feature.
  - clarry 7y ago
    And this is why we still have lots of applications where it's difficult or impossible to bind certain inputs. Someone had a mental image of a typical keyboard, then a typical mouse, and that's what we're stuck with. It's not like the sixth thumb button in my mouse is very different from the Print Screen key on my keyboard or the X button in my wireless gamepad. And that's why tools that make your input device X emulate a different type of input device Y are common (but annoying to set up since the setup is going to be application specific). I'm not aware of a single API that offers a sufficiently device-agnostic view of inputs that you can write the application code once and then let the user bind anything they can connect to their computer somehow. The USB spec actually comes close since it starts at the actual hardware inputs (toggle switch, button, relative motion, absolute motion, etc.) and their range, and then offers hints about their intended usage or meaning. It's the layers above that suck.

lilyball 7y ago

I'm not aware of any sysctl values that can be accessed from two separate paths.

ahartmetz 7y ago
IIRC there are many values like that. There are "subsystem" or "driver" directories that don't even look like symlinks but lead into other subtrees. You can use such inter-subsystem links to create infinitely long sysctl paths.

twblalock 7y ago

Why is it necessary to include vendor information in a setting like this? The value, which represents the user’s desired brightness setting, could be an opaque number and the device driver could be responsible for translating that into whatever is needed to make the display behave.

asveikau 7y ago

The freebsd laptop I'm writing this on has: $ sysctl -a | grep brightness hw.acpi.video.lcd0.brightness: 50 compat.linuxkpi.i915_invert_brightness: 0 So if you want to write a script that works both, you need to put fujitsu-specific knowledge in your script. Vs. alternatively, an interface that works everywhere. (Incidentally I think this sysctl doesn't do much and I instead use a utility called intel_backlight(1) from ports.)

aphextron 7y ago
What laptop are you using for freebsd? Also what desktop environment? I've tried forever to get a BSD laptop setup working.
- asveikau 7y ago
  Lenovo X1 Carbon 6th gen. I don't use a big "desktop" like gnome, just a normal/light X setup resembling the 1990s. Lately it's dwm. Sometimes I do others. Some things that might save you some time in loader.conf: acpi_video_load="YES" acpi_ibm_load="YES" Also, had to set ACPI to "Linux" mode in bios. After that plus the two lines above, suspend works. Also, xf86-video-intel from ports. Wifi is slow but I'm ok with that. Long ago I used OpenBSD on a laptop, and in my experience, with thinkpads, it has a bit more of a "just works" feel than FreeBSD for hardware support. But I'm on freebsd because of a few things that don't work on openbsd these days [like linux binary emulation].
- jonhohle 7y ago
  For what value of working? I have a Lenovo X220 that works mostly fine. Sleeps on lid close, WiFi, trackpad. I don’t use it often, I keep it as a disposable backup, but it works.
ryanthedev 7y ago
I like how the abstraction point is at LCD. It's abstracting a specific hardware type, not a hardware feature.
- clarry 7y ago
  And this is why we still have lots of applications where it's difficult or impossible to bind certain inputs. Someone had a mental image of a typical keyboard, then a typical mouse, and that's what we're stuck with. It's not like the sixth thumb button in my mouse is very different from the Print Screen key on my keyboard or the X button in my wireless gamepad. And that's why tools that make your input device X emulate a different type of input device Y are common (but annoying to set up since the setup is going to be application specific). I'm not aware of a single API that offers a sufficiently device-agnostic view of inputs that you can write the application code once and then let the user bind anything they can connect to their computer somehow. The USB spec actually comes close since it starts at the actual hardware inputs (toggle switch, button, relative motion, absolute motion, etc.) and their range, and then offers hints about their intended usage or meaning. It's the layers above that suck.