|
|
|
|
|
|
by enriquto
1692 days ago
|
|
|
> The buffer will not be possible to adjust to properly handle both monitors because 1 is 300 DPI and 1 is 70 DPI. The word "properly" here is quite subjective, though. I have a similar setup, combining monitors of different pixel sizes.
It works properly with Xorg: When I move a window of size WxH pixels from one monitor to another, it remains a window of WxH pixels. A thin line of one pixel width remains so. A checkerboard pattern that tingles the monitor refresh rate remains so. This sounds like perfectly appropriate behavior, and anything else would be ridiculously inappropriate. I accept that this usage of "appropriateness" is subjective to a subset of people that includes me, but it may not be universal. Whatever, this is such a thin point for Wayland: hey, you lose copy-paste, screenshots, xdotool and most of the apps you used before. But hey! you can combine monitors of different pixel size as if they had the same pixel size! See, the thing transparently re-scales your windows using cheap-ass bilinear interpolation so that they get the exact same size in millimeters! Fancy, isn't it? No. It's creepy. |
|
|
Wayland has had working screenshots, screen recording, clipboard functionality for text and arbitrary mimetypes, etc. for years on wlroots, GNOME, and KWin. It also has ydotool, an xdotool alternative. For pure keyboard automation it also sports wtype.
Which apps don't support Wayland? The only ones on my machine that need XWayland are some video games and FLTK apps like Dillo (I have to test with xwininfo since it's normally impossible for me to notice if a program is using XWayland). All GTK/Qt apps work OOTB on Wayland as a first class citizen, especially since those toolkits nowadays receive more Wayland testing than X11 since barely any current distros still ship X in their default installations.
Which Wayland compositor/version and GUI toolkit/library gave you blurry bilinear filters?