Page MenuHomeFreeBSD

Support loader screen rotation for panels mounted at non-native orientations.
Needs ReviewPublic

Authored by on Fri, Jul 29, 6:32 AM.



This is one of three patches adding support for non-native panel orientation.
The other two patches add similar support to the drm module, and to the vt framebuffer.

Each of these patches may be applied separately or not, but consistent
rotation through all phases of bootstrapping and running the system console
will require all three.

The screen orientation is set by adding


to /boot/loader.conf. This value is passed by the loader to the kernel for use after
bootstrapping, but the loader needs the information before /boot/loader.conf is

To solve this problem, during startup and shutdown the loader.conf file is read and
the appropriate rotation angle is stored in a UEFI variable by /etc/rc.d/uefivars.

Test Plan

Edit /boot/loader.conf to add the screen.rotate key/value, and reboot.

Diff Detail

rS FreeBSD src repository - subversion
Lint OK
No Unit Test Coverage
Build Status
Buildable 46695
Build 43584: arc lint + arc unit

Event Timeline

imp requested changes to this revision.Fri, Jul 29, 2:58 PM
imp added inline comments.

why is /boot/loader.conf hard coded?


-z is likely a better test.


I think this is not indented with 8 character tabs, but 4 space characters.


angle == 0 is != 90 and != 180 and != 270, so you can drop that part of the test to simplify


Style(9) doesn't align continuations like this (which is an emacs default).


this should be in a header somewhere.


why not just use the loader''s own variables instead of this indirection that requires extra effort to set in an UEFI variable at boot?

This revision now requires changes to proceed.Fri, Jul 29, 2:58 PM added inline comments.

It's necessary to set the framebuffer orientation before the framebuffer is initialized, else functional problems result. The framebuffer is initialized very early, in efi/loader/main.c cons_probe(). This is important, since if it is not, problems with mounting filesystems, etc. will not be reported. This means /boot/loader.conf is not available when we need the rotation information.

/boot/efi/EFI/FreeBSD/loader.env is not currently opened before cons_probe(), but it could be moved there. But this is not a satisfactory solution because:
It's awkward to ask users to edit it;
Opening the EFI filesystem is still a complex enough operation that errors during open should be reported, and failures here could affect booting;
Most importantly, it's not necessarily mounted and writable when the kernel is running. This is important, because there are three sources of panel orientation information:

The user, via /boot/loader.conf;
The ACPI tables, which are read by the drm-kms module when it is loaded;
The drm-kms quirk tables, also only available after this module has loaded.

I have not yet had a chance to write the code to fully use the drm-kms source; it will involve setting screen.rotate="AUTO". However, the code in the drm-kms module is well developed and simply needs to be interfaced.

So information exposed quite late in the boot process needs to be available when the loader is just starting, and it needs to be reliably written late in the kernel boot process and also during shutdown (in case a user edits /boot/loader.conf), and it needs to be easily retrieved without much other infrastructure, such as a filesystem.

The UEFI variable works very well for this.

That said, I am not entirely happy with one thing. The problem is that the uefivars script needs to parse /boot/loader.conf on its own. Of course it can read the screen.rotate variable quite reliably if it's in the /boot/loader.conf file, but the script is currently not going to search through all the various sub-files. It's actually easy to fix this by embedding /boot/lua/config.lua into an executable parser available to shell scripts, but that solution, while already written, involves introducing another complexity into the system. Perhaps it's worth it; it's potentially useful to be able to access /boot/loader.conf configuration from scripts. But for most purposes, kenv(1) provides this functionality. And that's another option, to use kenv(1), but that would mean that after editing /boot/loader.conf, a user would have to reboot twice to see the effect.

  • Modified to address review comments from D35982