f31522130f
Build system (5 gaps hardened): - COOKBOOK_OFFLINE defaults to true (fork-mode) - normalize_patch handles diff -ruN format - New 'repo validate-patches' command (25/25 relibc patches) - 14 patched Qt/Wayland/display recipes added to protected list - relibc archive regenerated with current patch chain Boot fixes (fixable): - Full ISO EFI partition: 16 MiB → 1 MiB (matches mini, BIOS hardcoded 2 MiB offset) - D-Bus system bus: absolute /usr/bin/dbus-daemon path (was skipped) - redbear-sessiond: absolute /usr/bin/redbear-sessiond path (was skipped) - daemon framework: silenced spurious INIT_NOTIFY warnings for oneshot_async services (P0-daemon-silence-init-notify.patch) - udev-shim: demoted INIT_NOTIFY warning to INFO (expected for oneshot_async) - relibc: comprehensive named semaphores (sem_open/close/unlink) replacing upstream todo!() stubs - greeterd: Wayland socket timeout 15s → 30s (compositor DRM wait) - greeter-ui: built and linked (header guard unification, sem_compat stubs removed) - mc: un-ignored in both configs, fixed glib/libiconv/pcre2 transitive deps - greeter config: removed stale keymapd dependency from display/greeter services - prefix toolchain: relibc headers synced, _RELIBC_STDLIB_H guard unified Unfixable (diagnosed, upstream): - i2c-hidd: abort on no-I2C-hardware (QEMU) — process::exit → relibc abort - kded6/greeter-ui: page fault 0x8 — Qt library null deref - Thread panics fd != -1 — Rust std library on Redox - DHCP timeout / eth0 MAC — QEMU user-mode networking - hwrngd/thermald — no hardware RNG/thermal in VM - live preload allocation — BIOS memory fragmentation, continues on demand
37 lines
2.2 KiB
Plaintext
37 lines
2.2 KiB
Plaintext
To test whether QScreen properties are updated properly when the screen
|
|
actually changes, you will need to run some kind of control panel to make
|
|
changes, and this test program at the same time. E.g. on Linux, you can use
|
|
xrandr with various parameters on the command line, but there is also a nice
|
|
GUI called arandr which will probably work on any distro. Real-world users
|
|
would probably use the Gnome or KDE control panels, so that's also a good way
|
|
to test. On OSX you can make changes in System Preferences | Displays, and you
|
|
can also configure it to put a "monitors" icon on the menubar with a drop-down
|
|
menu for convenience. On Windows you can right-click on the desktop to get
|
|
display settings.
|
|
|
|
Note that on Linux, if you have one graphics card with two outputs, typically
|
|
the two monitors connected to the outputs are combined into a single virtual
|
|
"screen", but each screen has multiple outputs. In that case there will be a
|
|
unique QScreen for each output, and they will be virtual siblings. The virtual
|
|
geometry depends on how you arrange the monitors (second one is to the right,
|
|
or above the first one, for example). This test app will
|
|
create two windows, and will center one each screen, by setting the geometry.
|
|
|
|
Alternatively you can configure xorg.conf to create separate screens for each
|
|
graphics card; then the mouse cursor can move between the screens, but
|
|
application windows cannot: each app needs to be started on the screen that
|
|
you want to run it on (by specifying e.g. DISPLAY=:0.1 for the second screen),
|
|
or the application has to set the desired screen via QWindow::setScreen() before
|
|
showing the window.
|
|
|
|
The physical size of the screen is considered to be a constant. This can create
|
|
discrepancies in DPI when orientation is changed, or when the screen is
|
|
actually a VNC server and you change the resolution. So maybe
|
|
QScreen::physicalSize should also have a notifier, but that doesn't physically
|
|
make sense except when the screen is virtual.
|
|
|
|
Another case is running two separate X servers on two graphics cards. In that
|
|
case they really do not know about each other, even at the xlib/xcb level, so
|
|
this test is irrelevant. You can run the test independently on each X server,
|
|
but you will just get one QScreen instance on each.
|