In response to Wayland Breaks Your Bad Software

I say that the technical merits are irrelevant because I don’t believe that they’re a major factor any more in most people moving or not moving to Wayland.

With only a slight amount of generalization, none of these people will be moved by Wayland’s technical merits. The energetic people who could be persuaded by technical merits to go through switching desktop environments or in some cases replacing hardware (or accepting limited features) have mostly moved to Wayland already. The people who remain on X are there either because they don’t want to rebuild their desktop environment, they don’t want to do without features and performance they currently have, or their Linux distribution doesn’t think their desktop should switch to Wayland yet.

  • @[email protected]
    4•1 year ago

    There a synergy/barrier replacement working on Wayland yet?

    No?

    Then I guess Wayland isn’t ready yet.

      • @[email protected]
        3•1 year ago

        I haven’t tried it yet because it appears to be a client, and my Linux machine is the synergy server in my setup (work windows laptop is the client).

        • @SquirtleHermit
          3•1 year ago

          Ah, yep, that pretty much kills that. Well, one day.

          • @[email protected]
            3•1 year ago

            Yup. I got nothing against Wayland, but been waiting on this particular use case to get tooling for years now.

      • @[email protected]
        2•1 year ago

        rerequisites

        wayland, including wayland-scanner and the base protocols
libxkbcommon
libtls (either from libressl, or libretls)
A compositor making use of wlroots, or (on an experimental basis) KDE, or (if all else fails) the willingness to run questionable networking utilities with the privileges to access /dev/uinput
wl-clipboard for clipboard support (only works on wlroots, not KDE/GNOME)

        …

        In my case, a ‘uinput’ group is created, and a udev rule is used to modify the permissions appropriately:

        /etc/udev/rules.d/49-input.rules, in my case

        KERNEL==“uinput”,GROUP:=“uinput”,MODE:=“0660”

        From here, one could assign one’s users to this group, but doing so would open up uinput to every program, with all the potential issues noted in the first paragraph. The safest approach is probably setgid:

        as root – adjust path as needed

        chown :uinput waynergy chmod g+s waynergy

        If this doesn’t still doesn’t seem to work (as in #38) be sure that the uinput module is loaded properly. This might be done by creating a file /etc/modules-load.d/uinput.conf with the contents of uinput

        This is compared to just installing synergy which takes 7 seconds. I’m not sure why anyone imagines this is a credible alternative.