
Please think architecture (2007) - cnst
https://lists.freebsd.org/pipermail/freebsd-arch/2007-August/006763.html
======
hcarvalhoalves
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...

~~~
asveikau
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
What laptop are you using for freebsd? Also what desktop environment? I've
tried forever to get a BSD laptop setup working.

~~~
asveikau
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].

------
dooglius
So what happens if you plug your laptop into a docking station that has its
own backlight? What if a new laptop comes out that has multiple backlights
(perhaps of different colors)? In both of these circumstances the assumption
that there is one backlight is faulty and not future-proofed.

Not to mention that the units don't carry over from one vendor to another.

~~~
cnst
> Not to mention that the units don't carry over from one vendor to another.

Who cares about the units? When was the last time you used a vendor-provided
utility to configure a Network Interface Card, instead of just using ifconfig
(if you're on BSD)? On OpenBSD, there's also bioctl for RAID management, too —
[https://en.wikipedia.org/wiki/Bioctl](https://en.wikipedia.org/wiki/Bioctl).
And sysctl hw.sensors for temperature sensors and more.

How's brightness any different? It's a percentage value from 0 to 100%. Would
the user really care how many internal settings a given machine has, and that
100% is really just 16 internally?

~~~
theamk
Sure they do! When I press "brightness up" shortcut on my keyboard, I want my
laptop to brighten by 1 physical step, or by 2%, whatever is bigger.

Having to press the key multiple times just to get any effect is super
frustrating.

~~~
cnst
I think those shortcuts are often handled by the driver itself, so, it'll
already know the required stepping. Another option could be to provide such
stepping explicitly as another sysctl.

Otherwise, realistically, the keyboard shortcut stepping could simply be
assumed to have only 16 variations in the first place, even if you're still
using a percentage point through the interface.

------
twic
His next post on that list, on a different subject, is also pretty
entertaining:

[https://lists.freebsd.org/pipermail/freebsd-
arch/2007-August...](https://lists.freebsd.org/pipermail/freebsd-
arch/2007-August/006764.html)

------
viraptor
Has this changed since 2007? (don't have any freebsd available to check)

~~~
livueta
Guess not:
[https://www.freebsd.org/cgi/man.cgi?query=acpi_fujitsu&sekti...](https://www.freebsd.org/cgi/man.cgi?query=acpi_fujitsu&sektion=4&manpath=FreeBSD+12.0-RELEASE)

> hw.acpi.fujitsu.lcd_brightness

From man acpi_fujitsu on an actual system:

    
    
      SYSCTL VARIABLES
         These sysctls are currently implemented:
    
         hw.acpi.fujitsu.lcd_brightness
                 Makes the LCD backlight brighter or dimmer.
    
         hw.acpi.fujitsu.pointer_enable
                 Enables or disables the internal mouse pointer.
    
         hw.acpi.fujitsu.volume
                 Controls the speaker volume.
    
         hw.acpi.fujitsu.mute
                 Mutes the speakers.

------
mntmoss
The "generic" one is necessarily a UI to the device, not the actual device,
because there's always some kind of special casing or variation in an abstract
property like that. Having the UI is of benefit when it serves as a building
block, but not if it cuts off customization for some task.

------
ryanthedev
Negative. Backlighting is vendor specific. Different implementations offer
different configurations.

I do agree you probably want a base object for inheritance, exposing a common
interface wouldn't be a good idea.

No matter what, you need to implement your abstraction. You're always going to
end up with a list of vendor specific implementations.

~~~
cnst
> Negative. Backlighting is vendor specific. Different implementations offer
> different configurations.

Are you joking? For an analogy, do any NIC vendors even provide their own
tools for configuring their Ethernet cards? And even if some do, how many
people actually bother to use those, instead of OS-specific utilities like
ifconfig? How's backlighting any different here?

~~~
regularfry
The networking analogy would be things like DPDK, where yes, you do need to
know what the hardware is doing, and yes, there's vendor-specific support. The
answer to "how many people bother" would be "as many as have a damn good
reason to do so."
[http://doc.dpdk.org/guides/nics/overview.html](http://doc.dpdk.org/guides/nics/overview.html)
shows the non-homogeneity of NIC feature support across vendors; if you don't
care about this stuff, there's no reason to know it, but if you do, it's make
or break.

~~~
cnst
Sure, that's a lot of variation. Sure, some of these features are essential
for certain applications, like checksum offload etc. However, most of these
features are still uniform enough that a whole bunch of them are supported by
standard drivers included with all BSD operating systems, and configurable
with the standard ifconfig of each BSD, too:

[http://mdoc.su/-/ifconfig.8](http://mdoc.su/-/ifconfig.8)

The fact that you even have a whole table with these features shows that these
features are not that difficult to categorise and unbrand to be general enough
to have OS-defined behaviours and configurations for.

