Skip to content

Withdrawn - #54

Closed
iverbovoy wants to merge 47 commits into
mainfrom
compositor
Closed

iverbovoy wants to merge 47 commits into
mainfrom
compositor

Conversation

@iverbovoy

@iverbovoy iverbovoy commented Oct 1, 2026 •

Copy link
Copy Markdown
Contributor

Withdrawn.

…panels

Rust with no crates, libhybris opened with dlopen, cross-built on the PC:
hwc2 display 0, libhybris' hwcomposer window under EGL, fences through
set_client_target and present. 20 s at 59-60 fps, 16.7 ms between frames,
2 frames over 20 ms, no copy - against 30 fps on the Lindroid chain.
probe B's hwcomposer code becomes crates/hybris-hwc; smithay 0.7 gets an
EGLNativeDisplay on the Android platform and an EGLNativeSurface over the
hwcomposer window, and GlesRenderer draws at 60 fps, 1-1.5 ms a frame.
The first run's numbers were right and its frame was not: the hinge and the
bar were clipped away. With the damage relative to each rectangle the frame
reads back as drawn and the bar runs on screen.
A minimal smithay compositor on hybris-hwc and the EGL traits (now
crates/smithay-hybris): a window per panel, maximized, at 60 fps. GL
clients' buffers from libhybris' android_wlegl import through
bind_wl_display; shm clients' upload. Rendered with a vertical flip for the
EGL surface's default framebuffer.
libinput on its path interface into smithay's wl_touch: the window under the
finger gets the touch and the keyboard. The touchscreen covers the output
one to one, hinge and all. The port's sfduo-pen-split grabs the raw
digitizer, so the fingers come from its sfduo touchscreen.
…r's session

compositor/ splits probes/wl-panels into layout, state, input and output,
and tools/session-run.sh runs it as droidian on tty7 as phosh.service runs
phosh. As the user hwcomposer, EGL, touch and 60 fps work; GTK clients start
slowly because xdg-desktop-portal answers in 8-25 s in this session, found
with dbus-monitor. Clients get a stopgap environment.
phosh's session left its desktop name and dead Wayland socket in the user's
systemd, and the portals waited on them. The compositor listens on
wayland-item; session-run.sh gives the session XDG_CURRENT_DESKTOP=item,
that socket and a gtk portals configuration in /tmp for the run, and puts
phosh's back after. Two GTK apps map in 1.6 and 1.8 s, with no stopgaps.
One page for the day: the frame's path, the renderer, clients, touch and the
session, each with its number; the probes that got there; what the Duo gives
a compositor; and how to cross-build and run it.
The loop sleeps until a client, a touch or a vsync; hwcomposer's vsync wakes
it through a ping; a frame is drawn only if something changed, and the swap
no longer waits. The first frame is drawn at start (hwcomposer sends no
vsync before one). With a finger tapping: frames equal commits, none when
still; touch to screen about 45 ms through GTK.
… said

At each vsync the frame is aimed at the next one and drawn at that vsync
less a measured budget; misses are counted. The breakdown of a frame shows
hwcomposer's present at 2.5-3.5 ms on the loop's thread and the scene at
3-13 ms (likely an shm client uploaded whole each frame): too much for a
late draw to pay. Next: damage and buffer age, present off the loop.
The damage tracker gets the buffer age (always 2 here) and redraws only what
changed; nothing damaged, no swap. A frame redraws one panel's window, not
the screen: 2 ms for a GL client, 9-11 ms for an shm one, which is uploaded
whole each frame.
…te draw measured

libhybris' hwcomposer window hands out its 3 buffers in strict turn, so the
buffer age is 3, not EGL's 2: an empty panel flickered with the wrong one.
presentOrValidate kills the compositor on the Duo and stays off. A present
thread would race the window's release fences. tools/tap.py and bench.sh tap
the calculator through a virtual touchscreen; with them, drawing late takes
about 5 ms off touch to screen (44 -> 39 ms).
…om swapped frames, the run at the finger's speed
…rtial redraws); screenshots, frame runs, a scroll benchmark
…ame drawn at once, never two waiting in hwcomposer
…frame is drawn, vsync-time ones kept as an option
iverbovoy and others added 17 commits September 30, 2026 20:15
…input-method, text-input, virtual-keyboard; the globals it waits for
…ers by the gap, the neck; windows through the hinge
git-subtree-dir: compositor
git-subtree-mainline: 8869800
git-subtree-split: 134df6f
…f our own and copied whole; the tap against phosh measured right
…ting client's frame one vsync after its commit, not two
@iverbovoy iverbovoy closed this Oct 1, 2026
@iverbovoy
iverbovoy deleted the compositor branch October 1, 2026 00:41
@iverbovoy iverbovoy changed the title compositor: item-shell's next base, a compositor of its own Withdrawn Oct 1, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant