Ticket created by ~ifreund on ~exec64/imv
In response to a configure imv
- acks the configure
- commits the surface with the old buffer/dimensions
- waits for the next frame
- commits a new buffer with the dimensions requested in the configure
The part that is problematic/incorrect here is 2. Committing after acking a configure informs the compositor that this commit takes the ack'd configure into account. However, imv has not yet attached a buffer with the new size.
I noticed this problematic behavior since it can lead to loops where imv is continuously resized each frame. This log is a small snippet of an infinite configure loop running imv 4.4.0 under this branch of river:
[3686613.150] xdg_toplevel@13.configure(1773, 893, array[20]) [3686613.154] xdg_surface@12.configure(23620) [3686613.156] -> xdg_surface@12.ack_configure(23620) [3686613.158] -> wl_surface@11.commit() [3686613.287] wl_buffer@17.release() [3686613.289] -> wl_buffer@17.destroy() [3686613.290] wl_callback@15.done(322960831) [3686613.411] -> xdg_toplevel@13.set_title("imv - [1/1] [960x1280] [69%] /home/ifreund/downloads/photo1629123898.jpeg [scale to fit]") [3686614.876] -> wl_surface@11.frame(new id wl_callback@15) [3686614.894] -> zwp_linux_dmabuf_v1@10.create_params(new id zwp_linux_buffer_params_v1@19) [3686614.905] -> zwp_linux_buffer_params_v1@19.add(fd 13, 0, 0, 7168, 16777215, 4294967295) [3686614.908] -> zwp_linux_buffer_params_v1@19.create_immed(new id wl_buffer@20, 1773, 893, 808669784, 0) [3686614.911] -> zwp_linux_buffer_params_v1@19.destroy() [3686614.913] -> wl_surface@11.attach(wl_buffer@20, 0, 0) [3686614.914] -> wl_surface@11.damage(0, 0, 2147483647, 2147483647) [3686614.954] -> wl_surface@11.commit() [3686615.511] wl_display@1.delete_id(17) [3686615.514] wl_display@1.delete_id(19) [3686615.800] wl_display@1.delete_id(15) [3686616.011] xdg_toplevel@13.configure(1767, 895, array[20]) [3686616.016] xdg_surface@12.configure(23623) [3686616.018] -> xdg_surface@12.ack_configure(23623) [3686616.019] -> wl_surface@11.commit() [3686616.230] wl_buffer@18.release() [3686616.232] -> wl_buffer@18.destroy() [3686616.233] wl_callback@15.done(322960833) [3686616.358] -> xdg_toplevel@13.set_title("imv - [1/1] [960x1280] [69%] /home/ifreund/downloads/photo1629123898.jpeg [scale to fit]") [3686617.700] -> wl_surface@11.frame(new id wl_callback@15) [3686617.717] -> zwp_linux_dmabuf_v1@10.create_params(new id zwp_linux_buffer_params_v1@19) [3686617.729] -> zwp_linux_buffer_params_v1@19.add(fd 13, 0, 0, 7168, 16777215, 4294967295) [3686617.732] -> zwp_linux_buffer_params_v1@19.create_immed(new id wl_buffer@17, 1767, 895, 808669784, 0) [3686617.734] -> zwp_linux_buffer_params_v1@19.destroy() [3686617.736] -> wl_surface@11.attach(wl_buffer@17, 0, 0) [3686617.738] -> wl_surface@11.damage(0, 0, 2147483647, 2147483647) [3686617.781] -> wl_surface@11.commit() [3686618.362] wl_display@1.delete_id(18) [3686618.366] wl_display@1.delete_id(19) [3686618.579] wl_display@1.delete_id(15) [3686618.580] xdg_toplevel@13.configure(1773, 893, array[20]) [3686618.584] xdg_surface@12.configure(23626) [3686618.586] -> xdg_surface@12.ack_configure(23626) [3686618.588] -> wl_surface@11.commit() [3686618.722] wl_buffer@20.release() [3686618.724] -> wl_buffer@20.destroy() [3686618.726] wl_callback@15.done(322960836) [3686618.849] -> xdg_toplevel@13.set_title("imv - [1/1] [960x1280] [69%] /home/ifreund/downloads/photo1629123898.jpeg [scale to fit]") [3686620.262] -> wl_surface@11.frame(new id wl_callback@15) [3686620.277] -> zwp_linux_dmabuf_v1@10.create_params(new id zwp_linux_buffer_params_v1@19) [3686620.287] -> zwp_linux_buffer_params_v1@19.add(fd 13, 0, 0, 7168, 16777215, 4294967295) [3686620.290] -> zwp_linux_buffer_params_v1@19.create_immed(new id wl_buffer@18, 1773, 893, 808669784, 0) [3686620.292] -> zwp_linux_buffer_params_v1@19.destroy() [3686620.294] -> wl_surface@11.attach(wl_buffer@18, 0, 0) [3686620.296] -> wl_surface@11.damage(0, 0, 2147483647, 2147483647) [3686620.335] -> wl_surface@11.commit() [3686620.860] wl_display@1.delete_id(20) [3686620.864] wl_display@1.delete_id(19) [3686621.078] wl_display@1.delete_id(15) [3686621.080] xdg_toplevel@13.configure(1767, 895, array[20]) [3686621.084] xdg_surface@12.configure(23629) [3686621.085] -> xdg_surface@12.ack_configure(23629) [3686621.087] -> wl_surface@11.commit() [3686621.216] wl_buffer@17.release() [3686621.218] -> wl_buffer@17.destroy() [3686621.224] wl_callback@15.done(322960839) [3686621.344] -> xdg_toplevel@13.set_title("imv - [1/1] [960x1280] [69%] /home/ifreund/downloads/photo1629123898.jpeg [scale to fit]") [3686622.790] -> wl_surface@11.frame(new id wl_callback@15) [3686622.806] -> zwp_linux_dmabuf_v1@10.create_params(new id zwp_linux_buffer_params_v1@19) [3686622.818] -> zwp_linux_buffer_params_v1@19.add(fd 13, 0, 0, 7168, 16777215, 4294967295) [3686622.821] -> zwp_linux_buffer_params_v1@19.create_immed(new id wl_buffer@20, 1767, 895, 808669784, 0) [3686622.823] -> zwp_linux_buffer_params_v1@19.destroy() [3686622.824] -> wl_surface@11.attach(wl_buffer@20, 0, 0) [3686622.826] -> wl_surface@11.damage(0, 0, 2147483647, 2147483647) [3686622.865] -> wl_surface@11.commit()
Ticket created by ~ifreund on ~exec64/imv
From the
wl_pointer.enterevent inwayland.xml:When a seat's focus enters a surface, the pointer image is undefined and a client should respond to this event by setting an appropriate pointer image with the set_cursor request.
imv doesn't have a single wl_pointer_set_cursor() call in its codebase from a quick grep.
Originally reported here: https://github.com/riverwm/river/issues/616
Comment by ~ifreund on ~emersion/gamja
Here's a screenshot showing this issue: https://0x0.st/os0d.jpg
There's another closely related issue on iOS at least that is more severe in terms of usability impact. Long links in channel topics do not get broken/wrapped between lines which results in the leave button and part of the channel content being pushed off of the screen. See these screenshots: https://0x0.st/os0k.jpg https://0x0.st/os0R.jpg
Comment by ~ifreund on ~sircmpwn/aerc2
Indeed it is, I should have updated before reporting.
Thanks
REPORTED RESOLVED FIXED
bug added by ~ifreund on ~sircmpwn/aerc2
Ticket created by ~ifreund on ~sircmpwn/aerc2
In the original message umlauts are rendered correctly (e.g.
könnt) however when using the reply quoted (rq) command, the quoted message contains mangled versions of the umlauts (e.g.könnt=>k=C3=B6nnt). This may be true of other non-ascii characters as well, I haven't tested.
