#47 imv's response to configure events is problematic/incorrect 1 year, 2 months ago

Ticket created by ~ifreund on ~exec64/imv

In response to a configure imv

  1. acks the configure
  2. commits the surface with the old buffer/dimensions
  3. waits for the next frame
  4. 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()

#19 wayland: imv does not set the cursor on wl_pointer.enter 1 year, 11 months ago

Ticket created by ~ifreund on ~exec64/imv

From the wl_pointer.enter event in wayland.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

#129 Titlebar can take up a lot of space on mobile 2 years ago

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

#381 Umlauts mangled when using reply quoted (rq) 4 years ago

Comment by ~ifreund on ~sircmpwn/aerc2

Indeed it is, I should have updated before reporting.

Thanks

REPORTED RESOLVED FIXED

#381 Umlauts mangled when using reply quoted (rq) 4 years ago

bug added by ~ifreund on ~sircmpwn/aerc2

#381 Umlauts mangled when using reply quoted (rq) 4 years ago

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.