10:02 <jadahl> romangg: you can't send two key down for the same key in a single seat wihtout an up in between. the "logical keyboard" MR on wayland attempts to address that

12:02 <captainchris> Hi everybody

12:04 <captainchris> I'm trying to install wayland / libinput/ dwl on Alpine Linux, My problem is libinput list-devices doesn't list devices, same as root.

12:05 <captainchris> When I'm trying to libinput debug-events, it says Expected devices event added ... Maybe you don't have the right permissions

12:05 <captainchris> It a problem with eudev

13:21 <DemiMarieObenour[m]> My compositor is having some nasty problems with resizing of terminal emulators. When one side of the terminal window’s server-side decorations is dragged by the user, the size can be set to a value the terminal emulator cannot handle. The emulator responds by resizing itself, which in turn causes *other* sides of the window to move even though the user has not requested them.

13:21 <DemiMarieObenour[m]> This problem does not occur in X11 because of WM_NORMAL_HINTS, which tells the root compositor (here an X11 compositing window manager) what the acceptable sizes are. Letting clients dictate sizes doesn’t seem to work, because I cannot delay window resizes ― instead, I am told that the resize has already happened. My current workaround is to tell clients that they are tiled, but that leads to undrawn reagions at the edges.

13:50 <vyivel> >resizing itself, which in turn causes *other* sides of the window to move

13:51 <vyivel> that's an issue in your resizing logic

13:51 <vyivel> does it happen with all edges?

13:54 <DemiMarieObenour[m]> checking right now

13:54 <DemiMarieObenour[m]> that said, the actual resizing is done by the root compositor and is not under my control

13:56 <vyivel> which root compositor?

13:57 <DemiMarieObenour[m]> XFWM4 (X11 compositing window manager)

13:59 <DemiMarieObenour[m]> it only happens with the right edge

13:59 <DemiMarieObenour[m]> when the user moves the left one

14:00 <vyivel> so you'd have to shift the window by (requested_width - actual_width) after resize is done

14:00 <vyivel> i think

14:00 <DemiMarieObenour[m]> I am not informed of when the resize is done, so that isn’t an option.

14:01 <vyivel> "instead, I am told that the resize has already happened"?

14:03 <DemiMarieObenour[m]> All I know is that the window’s size has changed. I don’t know when the user has stopped changing it.

14:03 <DemiMarieObenour[m]> I could use a timer or other heuristic but would prefer not to

14:03 <vyivel> i see

14:13 <DemiMarieObenour[m]> One workaround I tried is to tell the client (here gnome-terminal) that the surface is tiled, so that it doesn’t try to resize it. That just results in undrawn regions at edges, though.

15:01 <wlb> wayland-protocols Merge request !126 opened by () Add more window manager hints https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/126

15:25 <caveman> what's the difference between native and non-native wayland apps in terms of end user experience?