Screensaver, Widgets and Display

What is it?

This roadmap covers three desktop features: screensavers that start when the machine is idle and can hand off to the lock screen, a layer of small desktop widgets (clock, CPU and memory meters, calendar, notes), and display management (listing resolutions, choosing one in the Display applet, and a DPI setting), with multi-monitor enumeration as a stub. None of its six sections has shipped. The data the display work needs, the firmware's list of video modes, already reaches the kernel.

How does it work?

Today. None of the screensaver, widget or display-mode code exists. What does:

Video modes. The bootloader asks UEFI GOP for every mode it offers and hands up to 32 of them to the kernel in boot_info, as gop_modes[] (width, height, pixels per scan line and pixel format), gop_mode_count and gop_mode_selected (boot_info.h, filled in bootx64.c). At boot the kernel logs the active mode and how many modes were enumerated, and nothing else reads the list yet (boot_interrupts.c). GOP gives no refresh rate, and gop_mode_selected can equal gop_mode_count when the active mode is not in the table, so a reader must check the index.
Drawing. gfx_acrylic(), gfx_fill_rect(), gfx_fill_circle(), gfx_draw_line() and gfx_blit() (gfx.h), and fb_lock_compositor() for exclusive drawing (framebuffer.h).
Time and memory. system_get_ticks() and uptime() (timer.h), and pmm_get_total_frames() and pmm_get_free_frames() for a memory meter (pmm.h).

The mode cannot be changed after boot today: GOP's SetMode is gone once the loader exits boot services, so a runtime mode change needs a display driver from the GPU and Display Drivers roadmap.

Planned design.

Screensavers. The window manager records the time of the last input; after the configured idle time a screensaver takes the screen through a scr_entry_fn(msg, surface) callback with init, frame and close messages. Five are planned: blank, starfield, matrix, bouncing logo and clock.
Lock bridge. If RequirePassword is set, dismissing the screensaver opens the lock screen.
Widget framework. A struct widget with init, render, tick, click and close callbacks, drawn by the compositor on an acrylic background, draggable, with positions kept in the Registry.
Built-in widgets. Analog clock, CPU meter (a 60-second rolling bar), RAM monitor, month calendar and quick notes.
Display management. display_enum_modes() from the GOP list, the chosen mode written to the Registry for the next boot, a resolution list in the Display applet, and a DPI slider that defers to the single DPI owner in Desktop Shell Features.
Multi-monitor stubs. monitor_enum() and wm_to_monitor() returning one monitor until a multi-head driver exists.

What are its interfaces?

Interface	Status
`boot_info->gop_modes[]`, `gop_mode_count`, `gop_mode_selected`	Shipped (logged only)
`gfx_*` drawing, `fb_lock_compositor()`, `system_get_ticks()`, `pmm_get_free_frames()`	Shipped
`scr_entry_fn`, idle tracking, the five screensavers	Planned
`struct widget`, `widget_manager_render()`, the five widgets	Planned
`display_enum_modes()`, `display_get_current_mode()`, `monitor_enum()`	Planned
`HKCU\Software\Impossible\Screensaver\`, `...\Widgets\{id}\`	Planned Registry keys

How do I use it?

Boot and look for the GOP line in the serial log, in the form <width>x<height> <pixel format> (mode <n> of <count> available): it shows the active resolution and how many modes the firmware offered. Nothing else is usable yet.

What is not implemented yet?

Screensaver System and the lock screen bridge
Desktop Widget Framework and Built-in Widgets; the CPU meter needs the per-task list from the utilities roadmap
Display Management, whose Display applet is in the Control Panel roadmap
Multi-Monitor Stubs; real multi-head support belongs to the display driver roadmap

How does it compare with Windows 11 and Linux?

Windows 11 still ships classic screensavers, has a web-based Widgets panel rather than desktop widgets, and supports full multi-monitor layouts and per-monitor DPI. Linux desktops use xscreensaver or the GNOME and KDE lockers, KDE plasmoids for widgets and xrandr or Wayland output management. The Impossible OS plan draws widgets as a compositor layer with no process per widget, and reads the display modes straight from the firmware list the bootloader already hands over.