7 ms·

I still use X11, where and rely on the following features (amongst others): -taking screenshots -auto keyboard/mouse scripting with xdotool -not have unneces

I still use X11, where and rely on the following features (amongst others): -taking screenshots -auto keyboard/mouse scripting with xdotool -not have unnecessary mouse/keyboard to monitor delay -4K fullscreen, windowed fullscreen and windowed gaming with nvidia drivers, for native and steam proton games -choosing to have vsync enabled or disabled in games -EDIT: I should another important one for me: xclip, read from and write to the clipboard in the command line How's the current situation of Wayland for these? Thanks!

edent 4y ago
I use Wayland and it has screenshot and screen recording tools. I don't notice any delay on keyboard or mouse entry across multiple monitors. Can't answer the rest.
- maskros 4y ago
  He is referring to input lag: the delay from input to visible change on the monitor. The double buffering and compositor step added by Wayland adds some delay. You may not personally notice it, or be used to it, but it's always there. Some people are more bothered by input lag than others, and there are so many compounding factors today that make it worse than ever. It's not only the double buffering in graphics subsystems like Wayland. Monitors are also often adding a frame or two delay to bump up their pixel "response times" and reduce ghosting by looking at future frames. I swear, using Wayland or MacOS or Windows 10 on the fastest hardware today still feels slower and laggier than 10 year old hardware running plain X11 or Windows 7 (with the compositor turned off). Given the choice between tearing and input lag, I'll take tearing any day.
  - cycomanic 4y ago
    It seems your subjective feeling is not reflected in measurements. At least for kwin wayland is as fast as uncomposited x11 https://zamundaaa.github.io/wayland/2021/12/14/about-gaming-on-wayland.html https://zamundaaa.github.io/wayland/2021/12/14/about-gaming-...
    - zbuf 4y ago
      Don't these results show a 20% slower based on the median? Plus, the test uses a display at 120Hz, which is a substantial head start -- by making each frame of delay half as long compared to us mere mortals running at 60Hz.
colordrops 4y ago
- screenshots work - the keyboard and mouse can be controlled programmatically, but unaware if xdotool itself works - I don't notice any input delay with the monitors at 60Hz - I'm using the unsupported GPU flag with SwayWM and 4k games and windowed games work for me - never tried disabling vsync. I'm guessing it won't work I suspect if you use fractional scaling, the games wont run at 4k, but instead the fraction of 4k
- seba_dos1 4y ago
  > I suspect if you use fractional scaling, the games wont run at 4k, but instead the fraction of 4k X11 games maybe; SDL's Wayland backend can deal with fractional scales and make it render at native 4k.
  - colordrops 4y ago
    Sure, I'd expect anything Wayland native will work as expected. Are there many games with Wayland support though? Honest question.
    - seba_dos1 4y ago
      SDL got a pretty decent Wayland support in its last releases, so: yes, there are.
dottedmag 4y ago
Protocol for disabling vsync just landed together with the fractional scaling, now it's up to applications and compositors to implement it.
boudin 4y ago
Taking screenshot just works, there's a fair amount of tools for it. The one difference is that some tools are compositor specific. I know there's automation tools like xdottool, never used those though. I never saw much difference in term of delay, I find playing on wayland better, some games being much smoother even when using xwayland. I have AMD hardware only so can't say here. There's a procol being worked on to allow tearing, it's not available yet though https://www.phoronix.com/news/Wayland-Tearing-Control-Proto https://www.phoronix.com/news/Wayland-Tearing-Control-Proto
- pmontra 4y ago
  > There's a procol being worked on to allow tearing The irony, to say the least.
  - boudin 4y ago
    Why? It's quite a good idea IMO, the compositor allowing in specific case to optimise for speed rather than quality.
    - pmontra 4y ago
      I don't care about tearing. I'm sure my X11 tears all the time when watching videos but if I notice it I shrug it off. The point is that one of the main drivers of Wayland was to be frame perfect, have no tearing. Commendable goal, why not? but it's turning out that they had to write code to get no tearing and more code to allow it.
      - boudin 4y ago
        Wayland is frame perfect, and it's great. What's the issue with allowing users or the compositor to disable that in really specific case without sacrificing the frame perfect principle for all other uses? It's the best of both worlds
        yjftsjthsd-h 4y ago
vbezhenar 4y ago
Screenshots work. No idea what xdotool is. Did not feel any delay. Not sure about games, Factorio works fine with Intel GPU. Not sure about vsync either.
RealStickman_ 4y ago
Have you tried ydotool as a replacement for xdotool? It also works on X, as it uses uinput. https://github.com/ReimuNotMoe/ydotool https://github.com/ReimuNotMoe/ydotool
- yjftsjthsd-h 4y ago
  There are a couple of tools that can programmatically perform input events. They have some caveats because they work at a lower level so you might need to give them root permissions when that wouldn't have been necessary before, but they do work. The question is if that's all that you were using xdotool for; it's not limited to faking input events. For instance, xdotool can monitor events and trigger actions when you change focus on windows, or specific windows, and it can search across all desktops to find a specific window, bring it to the foreground, resize it, and then feed it input events. If all you need to do is simulate keyboard and mouse events, there are alternatives, but that's not all the tool could do.
  - FloatArtifact 4y ago
    This 1,000% for accessibility software or automation frameworks. We don't want a privileged root privileges for emulating mouse/key presses in any application. As a side note Monitoring events might be reasonable, but I wish service could register to monitor without root privileges. Therefore, allowing user discretion.
LeonM 4y ago
> choosing to have vsync enabled or disabled in games Good news: https://www.phoronix.com/news/Wayland-Tearing-Control-Proto https://www.phoronix.com/news/Wayland-Tearing-Control-Proto > Introduced now with Wayland Protocols 1.30 though is a new staging protocol to allow screen tearing.
enriquto 4y ago
> I still use X11, where and rely on the following features To which I would add: (1) taking screenshots from the command line (xwd) (2) moving windows around from the command line (xwit) (3) keyboard-free copy-paste between different programs: select to copy, middle-click to paste (4) global indicator of where my cursor is (xeyes) (5) define global key combinations that launch programs (xbindkeys) (6) globally configure the keyboard in a particular way, key by key, not according to some pre-configured "language" (setxkbmap, xmodmap, xkbset) (7) set keyboard repeat/delay to absurdly unusable values (xset) (8) run graphical programs from a headless virtual machine (ssh -X) I do not mind whether I'm running x11 or wayland, but I care a lot for all these features that are crucial to my workflow. How likely is it that items (1)--(8) will be supported somehow under wayland? I'm a bit concerned that wayland gives a lot of attention to things that are meaningless to me (tearing, scaling, etc), and does not care at all about these basic usability features.
- deleted 4y ago
  [deleted]
- gbil 4y ago
  adding mouse gestures with easystroke
- from 4y ago
  See: https://news.ycombinator.com/item?id=32297479 https://news.ycombinator.com/item?id=32297479 None of these discussions ever go anywhere. They will tell you that wlroots is standardizing all these things etc etc but as it stands today every compositor is at best reimplementing a subset of the features you describe. If I had enough money I would pay the Wayland people to work on something else and let the project collapse because they are constantly undermining the reasons I use Linux on the desktop.
  - QEIAo7BCrzKtYQ 4y ago
    That post is some pretty bad misinformation. An API for global keyboard shortcuts was being worked on and just got merged 2 months ago. https://github.com/flatpak/xdg-desktop-portal/issues/624 https://github.com/flatpak/xdg-desktop-portal/issues/624 There is a way to protect against LD_PRELOAD: use sandboxing. X11 is bad for security because it's an intentional escape around the sandbox. The "tear it down and build something else argument" is also going nowhere, anything else you build is going to run into the same questions of how to go about implementing these features.
MichaelCollins 4y ago
Just do yourself a favor and stick with using what already works. Don't upgrade to the new shiny thing unless you already know the reasons why you want to. Among all the other technical issues, Wayland devs have an attitude issue. Users asked for fractional scaling for years and were faced with flat refusals and insulting quips from the wayland developers. The only reason they've added it now is because Valve asked them for it. Wayland devs think users are worms and corporations are gods.
- mort96 4y ago
  The thing is, the old way is also clearly broken. For me, X11 has always been a slow, stuttery, screen-tearing mess across a range of hardware, while Wayland is much better at shipping complete frames on time during normal desktop use. So it's a choice between the broken old thing and the broken new thing.
ybc37 4y ago
> xclip, read from and write to the clipboard in the command line There's wl-clipboard with the commands wl-copy and wl-paste: https://github.com/bugaevc/wl-clipboard https://github.com/bugaevc/wl-clipboard Works flawless in my experience.
- mort96 4y ago
  Doesn't that have to create a window to interact with the clipboard? That makes it quite disruptive in some contexts.
  - chlorion 4y ago
    No it doesn't do anything like that. I am not sure where this idea came from but it's totally incorrect. I have also been using the wl-clipboard program with no issues like the parent commenter. I use it for my password store, which decrypts a file containing the password with GPG and pipes it into the clipboard!
luislezcair 4y ago
I also noticed this delay in mouse movement but I couldn't find anything online or even people noticing the same problem. For me it happens in the second monitor (120Hz with HDMI) there's a lag in the cursor movement. When I switch to X11 that lag is gone and the movement feels more fluid. The strange thing is that I don't see that effect on the laptop screen (144Hz). I'm using Plasma btw
hackyhacky 4y ago
People are responding to this comment by saying "Screenshots work," and yes, they do, somewhat. However, you're limited to using the screenshot tool built in to your Wayland compositor, rather than any third-party tool. For example, my favorite screenshot tool supports automatic timed screenshots, of particular windows or the whole screen or of a specified region, of one desktop or several, and various customizations. Those features aren't supported by my compositor, and I don't have a choice. So Wayland limits my options. Another area missing functionality is remote desktop. Yes, most Wayland compositors support VNC or similar remote desktop, but without the functionality of previous solutions. For example, I used x11vnc extensively: with it, I can share just one window or a whole screen, with various security options, and I can do so programmatically from the command line. Because VNC is now a feature built into the compositor, I no longer have a choice which remote desktop tool to use, and adding features is not a priority for maintainers of the compositors. So, while, yes technically, you're right that some analogues of screenshots and remote desktop exist on Wayland, they do so without any of the modularity and flexibility that Linux is (allegedly) proud of.
- sho_hn 4y ago
  This is a valid and level-headed analysis. The good news is that this is not unfixable; there is a venue and a governance organization to standardize the protocols and compositor interoperability that is needed. And there has been notable progress. Specifically when it comes to screen share / remote desktop, standardization of the API to invoke sharing is happening by way of the XDG portal API efforts. There is active collaboration there e.g. between the browser vendors and the compositor vendors to agree on an interface. Here is a recent progress report: https://jgrulich.cz/2022/11/21/webrtc-chromium-year-end-report/ https://jgrulich.cz/2022/11/21/webrtc-chromium-year-end-repo...
  - Aardwolf 4y ago
    > there is a venue and a governance organization to standardize the protocols and compositor interoperability that is needed I'm not sure if that applies specifically to this case, but I'm not a fan of some standardization of protocols that is going on in Linux desktops, because: - desktop managers can't properly keep state of your windows anymore on shutting off/on monitors. Claimed reason why this is not fixable: "the standard requires it" - I dislike MM/DD/YYYY date formats. File managers used to have their own setting to choose your date format. Now they use some common standard so you have to set your Linux locale to something non-US. This then breaks other things. It's much nicer to be able to configure things per-application. - Kolourpaint used to have a good color picker that showed you the numerical and hex values of colors. Now it has a horrible one that is only some palette where you can edit individual entries. You can't easily see the RGB values of a pixel in an image you open in Kolourpaint anymore. All due to "standardization", using a shared color picker component - Focus stealing prevention no longer properly works, all due to adhering to some desktop standards - Desktops like KDE and Cinnamon using horrible non-human editable json/xml/base64-encoded UTF-16 formats for their config - Some Qt or GDK applications not having icons sometimes, due to them expecting some common icons available somewhere. This issue used to not exist, applications came with their own icons that just worked I much preferred how unix and the desktop used to be, where you could manually edit textual config files to do whatever you want, and had the power and flexibility to change almost anything in intuitive ways
WhyNotHugo 4y ago
> taking screenshots There's plenty of tools for this. I wrote a light and simple one that shows a tiny thumbnail, [`shotman`](https://git.sr.ht/~whynothugo/shotman https://git.sr.ht/~whynothugo/shotman). But there's plenty others of all sorts. > auto keyboard/mouse scripting with xdotool There's a few tools for this: https://github.com/natpen/awesome-wayland#tools https://github.com/natpen/awesome-wayland#tools > not have unnecessary mouse/keyboard to monitor delay There's none that I can notice. Mice cursor are rendered with hardware support when available. Not sure what you reference is here. > 4K fullscreen, windowed fullscreen and windowed gaming with nvidia drivers, for native and steam proton games All this works on non-nvidia. I can't speak for nvidia, I'd suggest avoiding nvidia if you want to use Linux (or any other floss OS). Generally, nvidia on Linux isn't very pleasant. > choosing to have vsync enabled or disabled in games See this thread? https://www.reddit.com/r/swaywm/comments/ntszm9/how_can_i_make_sway_not_force_vsync_in_games/ https://www.reddit.com/r/swaywm/comments/ntszm9/how_can_i_ma... I'm not 100% sure what you're asking. > EDIT: I should another important one for me: xclip, read from and write to the clipboard in the command line https://github.com/bugaevc/wl-clipboard https://github.com/bugaevc/wl-clipboard
- BearOso 4y ago
  > There's none that I can notice. Mice cursor are rendered with hardware support when available. Not sure what you reference is here. Some compositors don't use the hw cursor plane. All others that do don't update the cursor position asynchronously on mouse events, just once on the next swap. Those cases add an extra half-frame latency on average. It's worse at lower refresh rates.
- yjftsjthsd-h 4y ago
  > There's plenty of tools for this. I wrote a light and simple one that shows a tiny thumbnail, [`shotman`](https://git.sr.ht/~whynothugo/shotman https://git.sr.ht/~whynothugo/shotman). But there's plenty others of all sorts. Your tool works on wlroots compositors, which is to say it doesn't work on GNOME or KDE.

edent 4y ago

I use Wayland and it has screenshot and screen recording tools. I don't notice any delay on keyboard or mouse entry across multiple monitors. Can't answer the rest.

maskros 4y ago
He is referring to input lag: the delay from input to visible change on the monitor. The double buffering and compositor step added by Wayland adds some delay. You may not personally notice it, or be used to it, but it's always there. Some people are more bothered by input lag than others, and there are so many compounding factors today that make it worse than ever. It's not only the double buffering in graphics subsystems like Wayland. Monitors are also often adding a frame or two delay to bump up their pixel "response times" and reduce ghosting by looking at future frames. I swear, using Wayland or MacOS or Windows 10 on the fastest hardware today still feels slower and laggier than 10 year old hardware running plain X11 or Windows 7 (with the compositor turned off). Given the choice between tearing and input lag, I'll take tearing any day.
- cycomanic 4y ago
  It seems your subjective feeling is not reflected in measurements. At least for kwin wayland is as fast as uncomposited x11 https://zamundaaa.github.io/wayland/2021/12/14/about-gaming-on-wayland.html https://zamundaaa.github.io/wayland/2021/12/14/about-gaming-...
  - zbuf 4y ago
    Don't these results show a 20% slower based on the median? Plus, the test uses a display at 120Hz, which is a substantial head start -- by making each frame of delay half as long compared to us mere mortals running at 60Hz.

colordrops 4y ago

- screenshots work - the keyboard and mouse can be controlled programmatically, but unaware if xdotool itself works - I don't notice any input delay with the monitors at 60Hz - I'm using the unsupported GPU flag with SwayWM and 4k games and windowed games work for me - never tried disabling vsync. I'm guessing it won't work I suspect if you use fractional scaling, the games wont run at 4k, but instead the fraction of 4k

seba_dos1 4y ago
> I suspect if you use fractional scaling, the games wont run at 4k, but instead the fraction of 4k X11 games maybe; SDL's Wayland backend can deal with fractional scales and make it render at native 4k.
- colordrops 4y ago
  Sure, I'd expect anything Wayland native will work as expected. Are there many games with Wayland support though? Honest question.
  - seba_dos1 4y ago
    SDL got a pretty decent Wayland support in its last releases, so: yes, there are.

dottedmag 4y ago

Protocol for disabling vsync just landed together with the fractional scaling, now it's up to applications and compositors to implement it.

boudin 4y ago

Taking screenshot just works, there's a fair amount of tools for it. The one difference is that some tools are compositor specific. I know there's automation tools like xdottool, never used those though. I never saw much difference in term of delay, I find playing on wayland better, some games being much smoother even when using xwayland. I have AMD hardware only so can't say here. There's a procol being worked on to allow tearing, it's not available yet though https://www.phoronix.com/news/Wayland-Tearing-Control-Proto https://www.phoronix.com/news/Wayland-Tearing-Control-Proto

pmontra 4y ago
> There's a procol being worked on to allow tearing The irony, to say the least.
- boudin 4y ago
  Why? It's quite a good idea IMO, the compositor allowing in specific case to optimise for speed rather than quality.
  - pmontra 4y ago
    I don't care about tearing. I'm sure my X11 tears all the time when watching videos but if I notice it I shrug it off. The point is that one of the main drivers of Wayland was to be frame perfect, have no tearing. Commendable goal, why not? but it's turning out that they had to write code to get no tearing and more code to allow it.
    - boudin 4y ago
      Wayland is frame perfect, and it's great. What's the issue with allowing users or the compositor to disable that in really specific case without sacrificing the frame perfect principle for all other uses? It's the best of both worlds
      - yjftsjthsd-h 4y ago

vbezhenar 4y ago

Screenshots work. No idea what xdotool is. Did not feel any delay. Not sure about games, Factorio works fine with Intel GPU. Not sure about vsync either.

RealStickman_ 4y ago

Have you tried ydotool as a replacement for xdotool? It also works on X, as it uses uinput. https://github.com/ReimuNotMoe/ydotool https://github.com/ReimuNotMoe/ydotool

yjftsjthsd-h 4y ago
There are a couple of tools that can programmatically perform input events. They have some caveats because they work at a lower level so you might need to give them root permissions when that wouldn't have been necessary before, but they do work. The question is if that's all that you were using xdotool for; it's not limited to faking input events. For instance, xdotool can monitor events and trigger actions when you change focus on windows, or specific windows, and it can search across all desktops to find a specific window, bring it to the foreground, resize it, and then feed it input events. If all you need to do is simulate keyboard and mouse events, there are alternatives, but that's not all the tool could do.
- FloatArtifact 4y ago
  This 1,000% for accessibility software or automation frameworks. We don't want a privileged root privileges for emulating mouse/key presses in any application. As a side note Monitoring events might be reasonable, but I wish service could register to monitor without root privileges. Therefore, allowing user discretion.

LeonM 4y ago

> choosing to have vsync enabled or disabled in games Good news: https://www.phoronix.com/news/Wayland-Tearing-Control-Proto https://www.phoronix.com/news/Wayland-Tearing-Control-Proto > Introduced now with Wayland Protocols 1.30 though is a new staging protocol to allow screen tearing.

enriquto 4y ago

> I still use X11, where and rely on the following features To which I would add: (1) taking screenshots from the command line (xwd) (2) moving windows around from the command line (xwit) (3) keyboard-free copy-paste between different programs: select to copy, middle-click to paste (4) global indicator of where my cursor is (xeyes) (5) define global key combinations that launch programs (xbindkeys) (6) globally configure the keyboard in a particular way, key by key, not according to some pre-configured "language" (setxkbmap, xmodmap, xkbset) (7) set keyboard repeat/delay to absurdly unusable values (xset) (8) run graphical programs from a headless virtual machine (ssh -X) I do not mind whether I'm running x11 or wayland, but I care a lot for all these features that are crucial to my workflow. How likely is it that items (1)--(8) will be supported somehow under wayland? I'm a bit concerned that wayland gives a lot of attention to things that are meaningless to me (tearing, scaling, etc), and does not care at all about these basic usability features.

deleted 4y ago
[deleted]
gbil 4y ago
adding mouse gestures with easystroke
from 4y ago
See: https://news.ycombinator.com/item?id=32297479 https://news.ycombinator.com/item?id=32297479 None of these discussions ever go anywhere. They will tell you that wlroots is standardizing all these things etc etc but as it stands today every compositor is at best reimplementing a subset of the features you describe. If I had enough money I would pay the Wayland people to work on something else and let the project collapse because they are constantly undermining the reasons I use Linux on the desktop.
- QEIAo7BCrzKtYQ 4y ago
  That post is some pretty bad misinformation. An API for global keyboard shortcuts was being worked on and just got merged 2 months ago. https://github.com/flatpak/xdg-desktop-portal/issues/624 https://github.com/flatpak/xdg-desktop-portal/issues/624 There is a way to protect against LD_PRELOAD: use sandboxing. X11 is bad for security because it's an intentional escape around the sandbox. The "tear it down and build something else argument" is also going nowhere, anything else you build is going to run into the same questions of how to go about implementing these features.

MichaelCollins 4y ago

Just do yourself a favor and stick with using what already works. Don't upgrade to the new shiny thing unless you already know the reasons why you want to. Among all the other technical issues, Wayland devs have an attitude issue. Users asked for fractional scaling for years and were faced with flat refusals and insulting quips from the wayland developers. The only reason they've added it now is because Valve asked them for it. Wayland devs think users are worms and corporations are gods.

mort96 4y ago
The thing is, the old way is also clearly broken. For me, X11 has always been a slow, stuttery, screen-tearing mess across a range of hardware, while Wayland is much better at shipping complete frames on time during normal desktop use. So it's a choice between the broken old thing and the broken new thing.

ybc37 4y ago

> xclip, read from and write to the clipboard in the command line There's wl-clipboard with the commands wl-copy and wl-paste: https://github.com/bugaevc/wl-clipboard https://github.com/bugaevc/wl-clipboard Works flawless in my experience.

mort96 4y ago
Doesn't that have to create a window to interact with the clipboard? That makes it quite disruptive in some contexts.
- chlorion 4y ago
  No it doesn't do anything like that. I am not sure where this idea came from but it's totally incorrect. I have also been using the wl-clipboard program with no issues like the parent commenter. I use it for my password store, which decrypts a file containing the password with GPG and pipes it into the clipboard!

luislezcair 4y ago

I also noticed this delay in mouse movement but I couldn't find anything online or even people noticing the same problem. For me it happens in the second monitor (120Hz with HDMI) there's a lag in the cursor movement. When I switch to X11 that lag is gone and the movement feels more fluid. The strange thing is that I don't see that effect on the laptop screen (144Hz). I'm using Plasma btw

hackyhacky 4y ago

People are responding to this comment by saying "Screenshots work," and yes, they do, somewhat. However, you're limited to using the screenshot tool built in to your Wayland compositor, rather than any third-party tool. For example, my favorite screenshot tool supports automatic timed screenshots, of particular windows or the whole screen or of a specified region, of one desktop or several, and various customizations. Those features aren't supported by my compositor, and I don't have a choice. So Wayland limits my options. Another area missing functionality is remote desktop. Yes, most Wayland compositors support VNC or similar remote desktop, but without the functionality of previous solutions. For example, I used x11vnc extensively: with it, I can share just one window or a whole screen, with various security options, and I can do so programmatically from the command line. Because VNC is now a feature built into the compositor, I no longer have a choice which remote desktop tool to use, and adding features is not a priority for maintainers of the compositors. So, while, yes technically, you're right that some analogues of screenshots and remote desktop exist on Wayland, they do so without any of the modularity and flexibility that Linux is (allegedly) proud of.

sho_hn 4y ago
This is a valid and level-headed analysis. The good news is that this is not unfixable; there is a venue and a governance organization to standardize the protocols and compositor interoperability that is needed. And there has been notable progress. Specifically when it comes to screen share / remote desktop, standardization of the API to invoke sharing is happening by way of the XDG portal API efforts. There is active collaboration there e.g. between the browser vendors and the compositor vendors to agree on an interface. Here is a recent progress report: https://jgrulich.cz/2022/11/21/webrtc-chromium-year-end-report/ https://jgrulich.cz/2022/11/21/webrtc-chromium-year-end-repo...
- Aardwolf 4y ago
  > there is a venue and a governance organization to standardize the protocols and compositor interoperability that is needed I'm not sure if that applies specifically to this case, but I'm not a fan of some standardization of protocols that is going on in Linux desktops, because: - desktop managers can't properly keep state of your windows anymore on shutting off/on monitors. Claimed reason why this is not fixable: "the standard requires it" - I dislike MM/DD/YYYY date formats. File managers used to have their own setting to choose your date format. Now they use some common standard so you have to set your Linux locale to something non-US. This then breaks other things. It's much nicer to be able to configure things per-application. - Kolourpaint used to have a good color picker that showed you the numerical and hex values of colors. Now it has a horrible one that is only some palette where you can edit individual entries. You can't easily see the RGB values of a pixel in an image you open in Kolourpaint anymore. All due to "standardization", using a shared color picker component - Focus stealing prevention no longer properly works, all due to adhering to some desktop standards - Desktops like KDE and Cinnamon using horrible non-human editable json/xml/base64-encoded UTF-16 formats for their config - Some Qt or GDK applications not having icons sometimes, due to them expecting some common icons available somewhere. This issue used to not exist, applications came with their own icons that just worked I much preferred how unix and the desktop used to be, where you could manually edit textual config files to do whatever you want, and had the power and flexibility to change almost anything in intuitive ways

WhyNotHugo 4y ago

> taking screenshots There's plenty of tools for this. I wrote a light and simple one that shows a tiny thumbnail, [`shotman`](https://git.sr.ht/~whynothugo/shotman https://git.sr.ht/~whynothugo/shotman). But there's plenty others of all sorts. > auto keyboard/mouse scripting with xdotool There's a few tools for this: https://github.com/natpen/awesome-wayland#tools https://github.com/natpen/awesome-wayland#tools > not have unnecessary mouse/keyboard to monitor delay There's none that I can notice. Mice cursor are rendered with hardware support when available. Not sure what you reference is here. > 4K fullscreen, windowed fullscreen and windowed gaming with nvidia drivers, for native and steam proton games All this works on non-nvidia. I can't speak for nvidia, I'd suggest avoiding nvidia if you want to use Linux (or any other floss OS). Generally, nvidia on Linux isn't very pleasant. > choosing to have vsync enabled or disabled in games See this thread? https://www.reddit.com/r/swaywm/comments/ntszm9/how_can_i_make_sway_not_force_vsync_in_games/ https://www.reddit.com/r/swaywm/comments/ntszm9/how_can_i_ma... I'm not 100% sure what you're asking. > EDIT: I should another important one for me: xclip, read from and write to the clipboard in the command line https://github.com/bugaevc/wl-clipboard https://github.com/bugaevc/wl-clipboard

BearOso 4y ago
> There's none that I can notice. Mice cursor are rendered with hardware support when available. Not sure what you reference is here. Some compositors don't use the hw cursor plane. All others that do don't update the cursor position asynchronously on mouse events, just once on the next swap. Those cases add an extra half-frame latency on average. It's worse at lower refresh rates.
yjftsjthsd-h 4y ago
> There's plenty of tools for this. I wrote a light and simple one that shows a tiny thumbnail, [`shotman`](https://git.sr.ht/~whynothugo/shotman https://git.sr.ht/~whynothugo/shotman). But there's plenty others of all sorts. Your tool works on wlroots compositors, which is to say it doesn't work on GNOME or KDE.