I found sway 1.10 and wlroots 0.18.2 will occasionally generate
wl_keyboard::keymap events with an empty keymap. I do not have
a reliable reproduction for this, but it seems to occur when
switching back and forth between workspaces with the keyboard.
This also fixes the issue where devdraw can go into a busy loop if
the compositor goes away and wl_display_dispatch() returns -1.
This tells bin/man to set the register L to very high to avoid pagination
and updates tmac/tmac.an to use that value, if it's set, to set the page
length. This is per Plan 9's rc/bin/man and sys/lib/tmac/tmac.an.
I tried running the wayland devdraw implementation on Sway 1.10,
wlroots 0.18 and encountered the error:
xdg_surface#13: error 3: xdg_surface has never been configured
According to https://wayland.app/protocols/xdg-shell#xdg_surface ,
a client must commit a surface without a buffer, *wait* for the first
configure request from the compositor, ack it, and *only then* can
it proceed to attach a buffer to the surface and tell wayland to display it.
This was caused by the following sequence of events:
1. devdraw starts, enters gfx_main
2. `gfx_main` calls `gfx_started`, which spawns the `serveproc` thread
3. `gfx_main` enters `wl_display_dispatch`, flushing any buffered requests to
the compositor, and enters `wl_display_poll()` to wait for incoming messages
4. `serveproc` calls `rpc_attach`, sets up the surface, and buffers a commit.
The race is between #3 and #4. If #3 happens first, the buffered commit
just sits there until `rpc_flush` is called, which calls `wl_display_flush()`,
but at that point a buffer is attached too quickly for the configure to happen.
This commit fixes the race by adding a `configured` field to the WaylandClient
and using it to guard `rpc_flush`.
In addition, I found that mouse warping, at least in sway, would move
the cursor but future mouse presses would register at the old location
until I moved the mouse. So I added a call to gfx_mousetrack to the end
of `rpc_setmouse`.
Basic configuration which builds p9p on latest Ubuntu & macOS.
Skipped on adding more operating systems as build would hold up
waiting for runners, whereas with -latest targets, build starts
immediately.
Supported runners can be found on
https://docs.github.com/en/actions/using-jobs/choosing-the-runner-for-a-job
Instead of only saving a window's currently displayed font's name to the
dump file, have Acme's Dump command save that window's combined low DPI
and high DPI font names when both are available.
See 9fans/plan9port#630
Previously the vertical bar in tick was always black; fine if you
use the standard black-on-white for everything, but any attempt to
add a dark mode ran into trouble with the tick being half hard-coded
black, half the new text color.
