I've attached screenshots showing the problem.  This is on a pi4
kernel last compiled May 24 (using the then latest source):
cpu% 9fs pidos
cpu% cd /n/pidos
cpu% cat cmdline.txt
console=0 service=cpu nvram=/dev/sdM0/nvram bootargs='local!/dev/sdM0/fs -A -a tcp!*!564' nobootprompt='local!/dev/sdM0/fs -A -a tcp!*!564'
cpu% cat config.txt
[pi4]
kernel=9pi4
arm_64bit=1
[pi3]
kernel=9pi3
arm_64bit=1
[all]
gpu_mem=16
core_freq=250
enable_uart=1
boot_delay=1
cpu% ls -l 9pi4
--rw-rw-rw- M 529 bill trog 3590848 May 24  2020 9pi4

Here's my /dev/config:

dev
	root
	cons
	swap
	env
	pipe
	proc
	mnt
	srv
	shr
	dup
	arch
	ssl
	tls
	cap
	fs
	ether	netif
	ip		arp chandial ip ipv6 ipaux iproute netlog nullmedium pktmedium inferno
	draw	screen swcursor
	mouse	mouse
	uart	gpio
	gpio	gpio
	sd
	usb
	dtracy

link
	gisb
	pci
	archbcm4
	ethergenet	ethermii
	ethermedium
	loopbackmedium
	usbxhci		pci

ip
	tcp
	udp
	il
	ipifc
	icmp
	icmp6
	ipmux

misc
	uartmini
	uartpl011
	sdmmc	sdhc
	dma
	gic
	vcore

	dtracysys
	dtracytimer

port
	int cpuserver = 0;

bootdir
	/$objtype/bin/paqfs
	/$objtype/bin/auth/factotum
	bootfs.paq
	boot

Here's the relevant output of /dev/kmesg:

127 holes free
0x00430000 0x3e600000 1042087936
1042087936 bytes free

Plan 9
4006M memory: 998M kernel data, 3008M user, 15013M swap
bus dev type vid  did intl memory
0   0/0 06 04 00 14e4 2711   0  ->1
1   0/0 0c 03 30 1106 3483   0  0:600000000 4096 
#l0: genet: 1000Mbps port 0xBD580000 irq 189 ea dca632380883
usbxhci: 0x1106 0x3483: port 0x600000000 size 0x1000 irq 0
#l0: phy1 id 600d84a2 oui 80361
hjfs: fs is /dev/sdM0/fs
3 keys read in AES format

init: starting /bin/rc
...
rio: setname failed: unknown id for draw image
rio: setname failed: unknown id for draw image
rio: setname failed: unknown id for draw image
rio: setname failed: unknown id for draw image
rio: setname failed: unknown id for draw image
rio: setname failed: unknown id for draw image
rio: setname failed: unknown id for draw image
rio: setname failed: unknown id for draw image
rio: setname failed: unknown id for draw image
rio: setname failed: unknown id for draw image
rio: setname failed: unknown id for draw image
rio: setname failed: unknown id for draw image
rio: setname failed: unknown id for draw image
rio: setname failed: unknown id for draw image
rio: setname failed: unknown id for draw image
rio: setname failed: unknown id for draw image

The message comes from /sys/src/cmd/rio/wind.c:84

I have 9front running on an rpi4 and I generally drawterm to it, but
sometimes I just use it with the screen, keyboard and mouse directly.
I have never had a problem with the screen rendering when
drawterm-ing, but I consistently have an issue with a window's content
expanding to render over the entire screen.  If I click around, some
of the windows start re-appearing, so it's not really expanding, it's
just the rendering is wrong, and stays wrong.  If I use winwatch to
have that window have focus, the entire screen is rendered over again.
If I re-size the window, it sometimes can return to a targeted size,
but it's not consistently the case.  If it does return to a normal
size, the next window I click on gets the same all-screen-rendering
problem if I try 'Move' it or 'Resize' it: it's rendered over the
entire screen.  Some windows running certain programs seem more prone
than others--acme, page, and mothra.  I haven't yet made a vanilla
'rc' window render over the entire screen, but th e window can fail to
resize (I have to choose another window).  If I do it enough times,
rio becomes inoperable as windows aren't resized and the rendering of
new windows are stuck in a 'red border with white background' state,
for lack of a better term.  Killing rio and re-starting resets the
graphics correctly.

I initially thought it had something to due with having an ultrawide
monitor: my thought was that even tho' the detected screen size was
much smaller than what was available, rio (or devdraw) had an issue
with calculating the screen size available to the window.  However,
that is not the case, as I have an HD+ (1600x900) screen and it's
still occuring.

Has anyone experienced something similar, or have suggestions on how
to resolve?