-
Notifications
You must be signed in to change notification settings - Fork 153
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Tracking issue for Wayland development progress #1251
Comments
It seems that they've figured this out for waynergy https://github.com/r-c-f/waynergy Keyboard mapping is a bit wonky, and only works as a client but it's a start and let's us keep using barrier on wayland for now. |
Ubuntu is rolling out the LTS->LTS upgrade this month, prompting the bulk of its userbase to install 22.04. This time around staying off of Wayland is even more difficult, most people will default to it. Just threw $20 at the bounty. Any way to help this further? (my coding time is too limited) |
Closing this issue as a duplicate of #109. |
Where those changes on those components upstreamed at some point ? |
There is no reasonable "upstream" any longer (see this discussion). Nobody maintains barrier. From what I could gather, input-leap is the only reasonable chance at an active fork right now. Of course there's also always Symless, but I wouldn't hold my breath for them to come forward with a solution first. |
I am talking about the patches for their respective git repos.... |
Mutter, etc |
Symless have already started talking about With regards to upstream patches for the components needed, this is a good listing: https://gitlab.freedesktop.org/libinput/libei/-/issues/1 |
This issue is for Wayland development to be documented, and updates given on the progress of adding Wayland support to Barrier.
@p12tic Could you please push a branch to the repo with your local Barrier development work when you can, please? That way we can have contributions for Wayland support.
The libei project seems to be very interesting in the context of barrier. It seems to be what implementation of barrier working with Wayland compositors needs. Seeing that it's a part of libinput project, seems to be a safe choice to use because it is very likely that this will be used by majority if not all Wayland compositors.
https://gitlab.freedesktop.org/libinput/libei
https://github.com/whot/barrier/tree/wip/ei
The text was updated successfully, but these errors were encountered: