Support Wayland #27
Comments
joshgoebel
added
help welcome
|
This would be a really huge addition to see & a big motivator for me to get Kinto over to keyszer yesterday if this gets added lol. I am not sure if I would daily drive Wayland or not still, but as it stands I can't even consider it realistically till this occurs but will likely have to occur on the DE level, aka Budgie, Gnome, KDE, Mate, XFCE, etc. And just to link this back to an earlier thread on this topic over at xkeysnail. mooz/xkeysnail#108 |
Yeah I saw that longer thread the other day... my current understanding is we're waiting on the Wayland people/DEs to make this all possible... if the APIs and libraries existed it should be trivial... our X11 integration code is only like 20 lines. We'll need some type of abstraction layer to a generic idea of a "window manager", but it makes no sense to think about that very hard until we know what the Wayland interface will be... obviously anything that gets us "app name" and "window name" would be great, and if that was pushed to us rather than us having to poll it, even better. |
|
Yea imo the best possible solution is they add the API to Wayland or XDG I think it is/was. Regardless some layer that will be accessible to all DEs & apps therein. |
|
It seems like it's going to be years before something like XDG or wlroots will add the ability to get the window class/name in "Wayland" in general, but there are existing ways to access the information in specific environments like GNOME (DBus calls) or sway. Meanwhile, even though Wayland is still a bit buggy and incomplete, a lot of users are seeing benefits like better multi-monitor support or high refresh rates, so I really can't fault them for wanting to use Wayland over X11 already. I ran into a keymapper project that claims to provide per-application remapping abilities in both X11 and Wayland, although they appear to use the techniques specific to limited environments like GNOME, sway, and hyprland that already provide this information in some way. Unfortunately this project is written in Rust rather than Python, so it would not exactly be a simple copy-paste job to try and bring the methods into Question is, how open are you to starting to integrate some Wayland solutions for per-application mappings that currently will only work in a few different Desktop Environments? I get the feeling that the X11 user base is going to start shrinking pretty quickly now, between all the distros that are starting to use Wayland as the default, and users that are actually moving to and liking Wayland on their own for one reason or another. Feels like the balance is really starting to shift lately. A large chunk of Linux users are on popular distros like Ubuntu and Fedora, which use GNOME by default, so it seems like a lot of users would be served by at least supporting GNOME's DBus method to get the window info in Wayland. The project is here: https://github.com/k0kubun/xremap Doesn't look like they've implemented matching on the window "name" (title) as opposed to the application "class" just yet, but I think that's more of them needing to implement the logic rather than not knowing how to get the window title. With Thoughts? |
|
I feel like we'd just go with modules/classes for the WM... so in your config you'd specify which module to use and that module would be responsible for providing the window context into the KeyContext. So anyone can use whatever WM they want, just so long as they can provide a module that (from Python) is able to learn a few key details about the windows (name and class hopefully?). I'm not sure the best way to structure that in Python off the top of my head, but it should be fairly trivial. Just a matter of how you inject/connect that module with KeyContext. Assuming they both have concepts like "name" and "class" you could seamlessly switch between them [window managers] by just changing one line of your config file (or perhaps even auto-detecting, though I'm not sure I'm interested in building that into the key mapper itself)... Right now you could start just by hacking the existing Once you get that working we could circle back to how to make which WM module to use a configurable choice.
If it turns out they are VERY different, than that would be a larger discussion. |
|
Apps need to be able to display unique window or tab titles, so I have little doubt that info is in Wayland the same way it is in X11. Not too worried about that.
I mildly disagree with this. Since users do sometimes have good reason (at this early juncture in Wayland's life cycle) to need to switch back and forth between X11 and Wayland sessions, I feel like we should at least make some attempt to do auto-detection. It really shouldn't be that hard. There was at least one environment variable I found that seemed to reliably hold info on whether the session is Wayland or X11. Something that would have fixed a problem the Kinto installer sometimes has with failing to detect Wayland, but it was never merged. A manual config setting as a backup, in case the auto-detect isn't working for some reason, shouldn't be too hard.
Yeah, I was going to look at that, study how it gets into KeyContext, etc. But also looking at the methods and seeing if I can get the info and just have it show up in the log, to start with. Bit by bit. As long as you're cool with a growing collection of patchwork solutions rather than waiting for a general "Wayland" solution to appear. Once the framework for adaptation is in place, it should allow a more general solution to just drop in place and replace the patchwork stuff, eventually. Seems like a good thing to waste some time on. |
When things finally get organized (in the Wayland ecosystem) it would just be a matter of writing another short module to handle the "official" API - or upgrading the existing one... should be pretty simple. Since it's easy to add/remove/upgrade I'm not sure why I should oppose. |
|
My new AI overlord says:
In my testing, the values have always been either
My thoughts exactly. Alright, I'll start chipping away at what I can, when I have the time. Probably will need some pointers now and then, as usual, if my own research fails me. |
|
Looks like Doesn't seem to be all that complicated to set it up, but it would need to be another installed Python module since it's not a built-in module at this time. Any thoughts on which road to go down? I didn't write any of the code in the example, and haven't started testing anything yet, I'm still just looking into how it's supposed to work. Looks like either way there would need to be something "external" added into the project. I feel like it can't possibly be as simple as it seems at first glance with PyWayland, because my source keeps saying "depends on the compositor", but it might at least work with GNOME shell right off the bat. https://pywayland.readthedocs.io/en/latest/ Relevant sections might be (if they still exist): pywayland.server.wl_surface.WlSurface |
|
I have the oddest thing happening. I've got the window class and name in Wayland with What seems to be happening is... The mapped combo will go through, but the input combo will also go through. I can set up a keymap for a specific application like GNOME Terminal, and that shortcut mapping will only work in that application, so the window matching is obviously working. But the keys from the input side end up not being suppressed, although the output keys also come out, as they should. So this remap of CapsLock you see below definitely types the output string, and only does it in GNOME Terminal, yet it also toggles CapsLock at the same time. Still in GNOME Terminal. And the tab nav shortcuts (Shift-Cmd-Braces) end up doing tab movement (Shift-Ctrl-PgUp/PgDn) instead of tav navigation, because the Shift key press is leaking through to mingle with the Ctrl-PgUp/PgDn of the output combo. Perhaps this is happening in all circumstances, but in other cases it doesn't seem to cause an issue. I'm just not sure how it's possible the output combo can get fired off without the input being properly suppressed. It should be doing either one or the other, not both. Is the suppression of a matching input combo decided in The new context module passes the exact same dictionary of information back to KeyContext when the "get context" function is called. It works just like If I can get past this weird side effect I should be able to clean this up without too much more trouble. The only thing missing for now is the ability to walk up the window tree to the "parent" of a window with no WM_CLASS and WM_NAME, which means it wouldn't work with JetBrains quite yet. I don't know of any other app that requires that particular workaround. The extension is called "Window Calls Extended". I tried to work with PyWayland, and [*] (With a LOT of help from a certain, suddenly very popular, AI language model.) |
|
Are you running keyszer at boot BEFORE the window manager? Perhaps weyland tries to grad the keyboard directly itself or something. Otherwise no idea. We do not pass the raw input (other than some of the non key events as you already know). |
|
Almost all the heavy lifting is in transform. |
No, the usual It’s my understanding that the grabbing of the keyboard device should be independent of the display server, with the only interaction with the display server being the context queries to see what the attributes of the focused window are at the moment you press the keys. The dict is sending x_error: False to KeyContext just like the xorg module. So it’s pretty strange. The logic should be stopping the unmapped keys from coming out. I’ll have to litter transform with debugging output and see if can catch it going somewhere it shouldn’t. Then figure out why. |
I'm not sure what this means... the log always shows input and output... so it's hard to imagine what you're seeing... a small log of a single combo might be nice to glance at. (X11 vs Weyland)
That would also have been my assumption. But Weyland is a whole other thing, in many ways not like X11 at all - perhaps it's ALSO grabbing the keyboard - which is why I was asking about load order.
Well there is no explicit logic to do that - we just only output what we choose... grabbing the input means that nothing else can hear it ... unless we proxy it - like we do in the case of non-key events, etc. |
It shouldn't be possible for anything but Maybe I'm misinterpreting what the logs are showing. There are "(OO)" lines for X11 for the input keys too. But in X11, the input keys don't actually end up doing anything. Actually, now that I think about it, it may be more like the app is ONLY seeing the real input, and NOT seeing the mapped output. Even though the correct keymap seems to be getting triggered and supposedly the output keys should be going out. In the other apps like Firefox, shortcuts like this are probably working OK because the shortcut works after just modmapping the modifiers, without needing to be transformed further. That would explain why it also isn't working correctly in GNOME Text Editor. Probably need to take a closer look at the actual window classes... If they're all slightly different from the X11 names... 😫 But wait, like I said, the string output I set up to output in the terminal absolutely works. Although, it should output "What the heck", but outputs "what the heck", with a lowercase "w". These log examples show different keymaps being triggered, but that's just because I set up a special keymap for the terminal in Wayland to try and figure out what's going on. Before that the log showed it triggering on the same shortcut from "General GUI" just like it should. This is one press of the physical keys Alt-Shift-Left_Brace (logical after modmap: RC-Shift-Left_Brace). Wayland. Has some added debugging lines. This is in X11: |
|
There is definitely a trend of the same app using a different class/name in Wayland vs X11. Annoying. Or maybe it's more of a difference between Fedora and Ubuntu? But no, I have an app was installed from Flahub in either case, and GNOME Terminal has always shown something different in X11 on either distro, so I think it's more of some apps choosing to show a different class and "title" for Wayland. But that should just be a matter of adding additional patterns to match those apps. Which was already a thing that often needed to be done for different distros somehow using a different WM_CLASS for the same app, and native packages vs Flatpak or other sources having a different WM_CLASS. Shouldn't be a big deal. And again, I can activate a special keymap for some app like GNOME Text Editor, with the class it's showing me in Wayland (org.gnome.TextEditor vs gnome-text-editor) and those mappings will only work in that app window. So the matching on the window attributes (in Wayland) is absolutely working. But, things just don't come out quite right. The string output when I press Grave in Text Editor is set up to be (after it clears isDoubleTap): But instead what I get is: All lower case. It's very consistent. But there isn't even a Shift key involved in the input combo. So why are the shifted characters consistently losing their shifted state, while the unshifted characters remain unshifted? And the result is the same whether I have CapsLock enabled or disabled. (This is a new pull of keyszer, without the unmerged fixes for the string and Unicode processors to adjust behavior for CapsLock LED status). The lack of the CapsLock fix doesn't explain what's happening, since toggling CapsLock has no effect on the output. I'm at a total loss to understand this so far. |
|
Straining my brain here... It's as if the modifier keys (and only the modifier keys) in the output side of the mapping are not actually making it to output. Meanwhile, "normal" keys (letters, numbers, punctuation keys) that aren't modifier keys are making it to output and being "seen". But, like those Shift key presses and releases that are supposed to be part of the string output, they are all there in the log. Just somehow they don't seem to be getting emitted by the virtual keyboard. So what the app sees is just lowercase letters, the number "1" instead of "Shift-Key_1", and so on. |
|
This is really making no sense to me. It's like something is "catching" the output keystrokes (and input keystrokes?), but only when they are modifier keys. The events are happening just the way they are supposed to, AFAICT. Press LEFT_SHIFT, press "Y", release "Y", release LEFT_SHIFT, etc. Maybe I should ask the |
|
Re: Shifting for "faking typing"... output looks like it's hitting shift, if that's not registering in Weyland, no idea. Re: X11 vs Weyland, both outputs look like "what I'd expect" IF you have suspend turned down super low... the original keys DO get sent thru right away - then they are lifted before the real combos... turning suspend up is what prevents this and what I always preferred it. I don't see anything unexpected happened at a glance in either log. |
Working in a Boxes VM on the same laptop with the touchpad that requires it be turned down for any kind of Mod+click to work. Thought maybe the device inside the VM would act more like a regular mouse, but doesn't seem to. So... if the original keys are always getting sent through with a low suspend timeout, why don't they ever seem to actually do anything, at least when things are working normally? I know there are combos I'm using where the input combo would make something else happen, if it was getting through to the app. Seems like I still don't precisely understand what happens to the input combo. Or is it just that the original modifier key presses get through, then released, before the full "combo" with the regular key and transformed modifiers are pressed?
That does seem to be the case, unfortunately. Like a selective filter. |
Yes. Most software doesn't seem to care about modifiers until a non-modifier is hit - and only the modifiers held down at that moment seem to matter. |
I see, better now than before. But the "normal" non-modifier key that completes the input combo, that doesn't end up going through before the input modifiers are released, right? (Or at all, if it's not in the transformed combo.) Or at least its not supposed to? Because that would actually make the app do whatever the input combo would do. But that normally doesn't happen. So there is ultimately one key press & release for each combo that should be getting suppressed, right? |
|
Cross-posting from Wait, adding a 0.05s delay to a part of the output module does have a significant effect. As in, it makes the intended transformed set of keystrokes "work" as they should. def __send_sync(self):
time.sleep(0.05)
_uinput.syn()But there is still the very strange problem where the input combo, that the app window is never supposed to "see", is still being "seen" in addition to the transformed keystrokes. I've been working with this keymapper for a couple of years in X11 environments and have never seen this phenomenon. Which is why I came over here to see if there is a chance the input is not being successfully isolated from Wayland when the keymapper "grabs" the device, which has always worked fine in X11. Alright, I slowed things WAAAY down with a 0.5s delay [in output.py sync function], and got this: The macro string is supposed to be: The CapsLock key that triggers the macro is "seen" by the app immediately (I see an on-screen notification for CapsLock and NumLock keys) and then this macro string is slowly typed out, with each character typed twice. Maybe because the long delay is before sending a sync, and something is interpreting as the key being tapped again? But there are two capital "W", which would require Shift-W in both cases. I'm not completely familiar with how the event code sequences work, and why this long delay causes this doubling up of the characters. |
|
Well, good news, in a way. The issue with CapsLock was actually a red herring. For some reason, when Boxes has the keyboard focus inside the VM window, it isn't really isolating the keyboard input within the VM. I guess it's doing the "shared keyboard" kind of thing, even though I have to move the mouse up to the window's top bar to Cmd+Tab away from the Boxes window. The CapsLock notifications were from the HOST outside the VM. Not inside. Which is why the output of the strings inside the VM never changed. Duh. Adding the delay in the sync function, if the delay is long enough completely fixes the behavior of transformed shortcuts not doing what they are supposed to do. But it has to be pretty long. Like 0.01 to 0.05 or so [Edit: After removing an additional 0.1s delay from the Unicode function, the minimum delay really seems to be at least 0.05s for any kind of reliability]. So once again we're talking about a pretty significant delay if you want to spit out a macro string or something. And it's still not 100% reliable. Stops part way through macro strings sometimes, even with the delay. But, in a very technical sense, you could say that I have actually succeeded in bringing support for app-specific mappings using Yay me. I'm amazing. It just really seems to have a major reliability problem, like when I was trying to get my Option-key special characters to work correctly in Kubuntu, and the only thing that seemed to help was a similar delay (before the Enter keystroke in the sequence that comes back from the Unicode processor) or disabling the sync entirely. 😞 I'm kind of expecting this to work better on a bare metal install, but have no direct evidence to support that yet. Will have to try that next. |
|
😡 😠 👿 |
|
How is this even possible, when the keystrokes that should produce the "!" character should be intrinsically connected to each other as a single combo, and the Shift key shouldn't even be pressed until after the "y" key is released? Seriously: I feel like this is a powerful clue. |
No such thing at the low-level, it's just a sequence of keyboard events - combos aren't really separated by anything... that said it should still be sequential, so that is quite confusing to me also - but what does the output log show for that? I imagine that could happen if you ripped out the SYNC events... so I'm not sure if you are still hacking such things... Because using sync is how you signal multiple events happened at the same time... so if you weren't SYCNing you could wind up where it's entirely ambiguous when shift was pressed if it was just part of a huge set of characters... |
|
Logs are fine. Both the keyszer log, and the log showing what I'm leaving the sync event alone in It really feels like a router with a buggy algorithm failing to put packets back together in the correct transmission sequence. Anyway, I found that regular typing can still be usable if we move the delay into This way, shortcuts are working as expected, with no obvious delay. Macros are quite slow, about like a 40wpm typist, but they don't get screwed up anymore even with sequences of several shifted characters together, and normal typing input is not messed with because the delay is not attached to the sync function. key_delay_testing = 0.03 # delay to insert between mod+key press/release
for key in mod_keys_we_need_to_lift:
# time.sleep(key_delay_testing)
self.send_key_action(key, RELEASE)
released_mod_keys.append(key)
time.sleep(key_delay_testing)
for key in [mod.get_key() for mod in mods_we_need_to_press]:
time.sleep(key_delay_testing)
self.send_key_action(key, PRESS)
pressed_mod_keys.append(key)
# time.sleep(key_delay_testing)
# normal key portion of the combo
time.sleep(key_delay_testing)
self.send_key_action(combo.key, PRESS)
self.send_key_action(combo.key, RELEASE)
time.sleep(key_delay_testing)I've tried many different iterations and this is about the best I've achieved. Tried leaving out the delay if there's no modifier involved, but the results were always bad. |
|
Nope, not reliable at 0.03s after further testing. Had to push it to 0.04s. And the only delay lines needed are around the "normal" key press-release event. The others didn't really help. |
I was really confused by this phenomenon, but think I figured out why this duplication of Unicode characters happens when the timing issue is particularly bad. Something is interpreting the keystroke sequence as somehow being both Unicode entry methods:
Thus, two identical Unicode characters sometimes. I can't replicate it manually, but this is the only possible explanation. Submitted a description of the overall issue in the |
|
I have to save this for posterity. What the actual... Supposed to be: |
|
I'm seeing window class and name output for JetBrains IntelliJ IDEA (Community Edition) in Wayland. At least with the Flatpak from Flathub. (DD) ## ctx_gnome_dbus.py - get_gnome_dbus_context():
wm_class = 'jetbrains-idea-ce'
wm_name = 'asdf \u2013 src/Main.java [asdf]'Interesting that this appears to be using an "En dash" Unicode character in the window title/name, rather than a simple dash/hyphen. The "\u2013" appeared to just be a hyphen in the terminal, before I copied the output and pasted it here. And in PyCharm (Community Edition): (DD) ## ctx_gnome_dbus.py - get_gnome_dbus_context():
wm_class = 'jetbrains-pycharm-ce'
wm_name = 'first_run.txt - .../share/jetbrains-flatpak-wrapper'So I'm not sure that it will actually be necessary to try to find a way to climb the window tree to get the parent window in Wayland the way the IntelliJ IDEA: WM_CLASS(STRING) = "jetbrains-idea-ce", "jetbrains-idea-ce"
_NET_WM_NAME(UTF8_STRING) = "testing – Main.java"Weird. Pretty sure that's still an "En dash" character, but it doesn't get converted into "\u2013" when copying and pasting from the host OS. Maybe that has something to do with copying inside the Boxes VM guest OS and pasting in a browser running on the host OS. PyCharm: WM_CLASS(STRING) = "jetbrains-pycharm-ce", "jetbrains-pycharm-ce"
_NET_WM_NAME(UTF8_STRING) = "first_run.txt - .../share/jetbrains-flatpak-wrapper"And, due to the usage of a non-ASCII character, these apps would have always triggered the "(COMPOUND_TEXT)" encoding bug, if anyone had tried matching on the window name before the fix that changed it to using _NET_WM_NAME. I must admit that at the moment I don't understand why the Ah, this is the problem: #########################
get_actual_window():
wmclass = ('Focus-Proxy-Window', 'FocusProxy')
wmname = 'FocusProxy'When But I'm already printing the retrieved class and title of these Java apps from within the So the function to climb up the window tree to the "actual" window doesn't appear to be necessary in a Wayland environment. Well, at least in the Wayland+GNOME "talking to shell extension via DBus" environment. That means I could technically say the Wayland+GNOME context module is finished. In the sense that it is doing everything it needs to do. 🎉 |
|
Still messing with some things, but I made a branch with everything that I've put together so far. https://github.com/RedBearAK/keyszer/tree/wayland_gnome_dbus It's going to show some extraneous changes like the unmerged updates to the Unicode and string processors, and some logging changes. This is the first time I'm attempting to do something this big, and using VSCode to do the commits. The strategy here is, I made a "connector" that uses environment info to transparently link |
|
Please open a draft PR so it's easier to see what you're working on over there. |
It's still kind of a mess so you'll have to be patient if you want any major changes. But I'll do that shortly. Oh, I forgot to mention it also includes the throttling delays I submitted in the most recent PR (#134), without which it would be totally unusable in the VM. |
|
Reminder to self: TODO: Implement an API function to allow manual override of the detection of session type and desktop environment from the user's config file, in case the automated detection fails for some reason but there's a chance Shouldn't be too difficult. I'll model it on the throttle delay API function that's already allowing me to inject keystroke delays from config. |
|
If auto-detection is possible (see my other question about env vars) it should be handled inside the display context manager with a simple state machine... stateDiagram-v2
[*] --> autodetect
autodetect --> connected
connected --> connection_error
connection_error --> autodetect
|
I'm not sure exactly which part you're referring to as the "display context manager". The new And the individual context module "getter" functions are passing back the same dict as So I feel like this is just describing what's already happening in what I've put together... ? Unless I'm doing something wrong. |
|
That code runs just once (that I see)... while for true auto-detection everytime you lost touch with the window manager you'd have to assume they might be logging out and switching into a different DE/WM, right?... hence my suggesting a class to manage that functionality and the current "state" of whether we are "connected" for a WM and which. |
Ah, I see what you're saying. You're thinking of it as a system service that just hangs around when the user logs out, but stops remapping things. Right. Honestly, I feel like the much more correct way of doing multi-user support will be a user-level service rather than a system service. Which will naturally stop running when the user logs out, and start again when the user logs in. In which case there would be no need for a state machine, as the environment is re-scanned at startup. Although I suppose there may be a benefit to having the system service "just work" when you do a "switch user" kind of thing, where it would just re-evaluate the environment as you log into the other user's desktop. But no, thinking about it, it seems like having a user service run a separate instance of Having a keymapper service running at system level really seems problematic, actually. Kinto's service file has always had the path to the user's config file hard-coded, making the idea of multi-user support difficult. Even if it's possible to have the service file draw from a per-user config file path, something would need to tell the service to restart in order to change to the new user's config. And if you're restarting to switch to a different config, surely there is no need for a state machine, again. If I'm thinking about this correctly, even if you did a switch-user or go-to-login-screen kind of thing without logging out, that would disable the remapping while the window attributes are inaccessible, but once you got back into your own graphical environment the window attribute getter should just automatically start working again. The environment itself can't actually change unless you really log out of your session, AFAIK, so what would trigger the need to re-evaluate the environment within that single run of the app? Am I way off base on something here? You know I like automating things, so it's not that I'm disagreeing that state machines are great when they are needed. The only thing I'm wondering about is whether a user-level service from a user that stays logged in would interfere with a user-level service in another account trying to grab the same input device(s). |
|
FYI, I just did a proof-of-concept setting up another module to use the GNOME shell extension maintained by the This ability to use multiple GNOME extensions should help alleviate the potential "fragility" of relying on third parties to keep their extensions updated to be compatible with each new release of GNOME. TODO: Add the ability to specify the extension to use as part of the environment config injection, if the auto-detection of the available extensions fails. (Seems problematic at the moment, talking to the extensions over D-Bus works but for some reason they don't show up in the list of all available D-Bus interfaces. Really odd.) Hmm. maybe I should just put it together so that it tries both and only returns the context error if neither of the D-Bus queries give anything back. I'll have to think about that. Oh, another FYI that I should toss in: The window classes are indeed sometimes different than expected in Wayland, but I think that's because the class string I'm getting back from these extensions is the first element of the "pair" that comes back for WM_CLASS even in Xlib/xprop, rather than the second element: WM_CLASS(STRING) = "gnome-terminal-server", "Gnome-terminal"So what I ended up seeing in Wayland for GNOME Terminal was the first string, whereas Kinto/xkeysnail/keyszer has always wanted to match on the second string of the pair, so that's what I've always looked at. In many cases these two elements are the same, or with one capitalized and the other uncapitalized, so with case-insensitive matching they end up identical. But in some cases the elements are very different. I'll have to look into whether these extensions are actually using the "wrong" element or somehow the first element is the only thing available to them. Or it might actually be more correct to use the first element, which often has a more "technical" appearance rather than a "pretty" appearance. In which case it may be smart to change the way the The only thing for sure right now is that there will be a difference for some apps currently, between when the It doesn't appear to be the case that the applications themselves are choosing to present a different string specifically for Wayland. It's just a different element of the existing WM_CLASS pairing. |
|
Aha, finally found a working dbus-send --session --dest=org.gnome.Shell.Extensions --print-reply /org/gnome/Shell/Extensions org.gnome.Shell.Extensions.ListExtensions |
|
I finished a state machine for working with the (two, for now) compatible GNOME Shell extensions. So the user could install, uninstall, enable, or disable any compatible extension that To make it as light as possible, it tries to only work with the extension that was "known good" the last time the function was called, keeping the extension uuid in a global. Which should mean that if the extension is never switched to a different one in the middle of a desktop session, it will just keep hitting only the one that already returned good results the last time. It will only re-evaluate the other extension(s) if the working one has an exception (i.e., because it's suddenly disabled or something). Then it will drop back through the function (one extra time) and try to check all extensions for a good result. This makes it capable of immediately recovering context functionality if there is another active and compatible extension present. Without so much as a hiccup. If there is no active compatible extension, it will be like the very first key press, attempting to find a working extension with each key press and returning Lather, rinse, repeat. Or rather: Lather, repeat, and only rinse if the soap runs out. 😆 As long as nothing goes wrong with the working extension, it's kind of like the context connector module, but operating independently so that even the context connector doesn't need to care about trying to use a specific GNOME Shell extension. This module will figure that out all by itself. Should be trivial to add other extensions to the module if anything else pops up that can provide the same information. I don't expect to find any others anytime soon. I was actually surprised to find even two different extensions capable of providing the window properties we need. |
|
Sounds nifty, lets see it. :) |
No. 😆 Just kidding. I'll be syncing the commits shortly. I'm sure you'll see some things that should be done better. I'm not convinced that the round-robin style of checking the extensions when there isn't a working "last" uuid is the most elegant way of getting the job done, for instance. But it is adapting automatically to the extent that I had intended. |
|
Alright, the changes should be showing online. The new module is:
And the separate per-extension modules should probably go away at some point: Since all the context modules are in the |
|
I was also thinking about the state machine thing earlier, for the rest of the environment, and remembered that I haven't found an equivalent tool for Wayland, just some whisperings about certain window managers possibly providing their own methods to give another user access to the Wayland display server. Unless I'm misunderstanding the situation entirely, the security model of Wayland being so different from X11 should mean that trying to run But I'll still have to set up a system service and separate user to verify any of this. |
|
A user on the xremap/xremap@master...N4tus:xremap:kde-wayland It's still kind of in flux, but seems to combine a KWin script and a D-Bus interface that asks the Plasma shell to give it the window attributes whenever the active window changes. Sort of the opposite of how the GNOME shell extensions work, advertising a D-Bus interface to be queried. But basically the same concept. Some of their comments indicate that they were not able to get the window information when running as root, due to the security model of Wayland. This confirms my belief that the proper way to run the keymapper in most situations is as a user service. I have a user service working on my machine, with a tray icon to allow stopping and restarting the service. But actually there are two services, one of which stops the keymapper when the user's "session" is no longer active. This seems to allow for a true multi-user setup, where the first user running This relies entirely on |
|
OK, so I think I managed to fix the things that were broken in my own branches, so I have:
I think I'm doing pretty good at this point, approaching the end goal of having a highly flexible variant of Kinto that runs on as many Linux distros as possible, while requiring minimal user input. I am now, for the first time, operating in Wayland on my main Fedora 36 install, as well as having tested the Wayland install in some VMs and on an old MacBook. It seems to usually need a bit more throttle delay than most bare metal installs, but that could be partially due to the need to use the GNOME Shell extensions to get the window info. Not sure if that could ever be improved as we wait for a more native Wayland solution for getting window context info. Should be possible to translate the Rust-based module, that makes Wayland+KDE_Plasma work now for Xremap, into a new provider class for I noticed during the testing of the class-based providers that the In any case, what I did feel a need to do was create the instance of the Of course it helps that my variant of Kinto is running from systemd "--user" services, or just shell scripts for verbose logging. It is not attempting in any way to be system-wide or operate outside the user session, where it might encounter a different session type during a single run of the keymapper. So that part might need to be looked at more closely. But I don't know how even my fancy config file powered by the I have not tackled yet the possibility of injecting a "custom" provider object from the config file side, although I've gone over how that might work with my online assistant. Seems like it will be a bit finicky trying to grab the custom provider class from memory by name, after the config is I've heard that at least one big distro has now declared that Xorg will be deprecated, so the time when the most popular distros will start actually removing Xorg and making users install it themselves is continuing to come closer. Let me know if you see any serious issues with the latest attempt at Wayland support infrastructure: PR #157 |
|
Well, it's still a bit rough around the edges as far as setting up the support files (a KWin script and a Python script that creates a D-Bus service that acts as a bridge between KWin and keyszer), but it looks like I finally broke through the wall that had me stymied for a couple of days. I now have working app-specific remaps on Wayland+KDE_Plasma. It's only in the Other than some continuing observations of minor differences in application names in the equivalent of WM_CLASS (resourceClass) under Wayland, which sometimes requires some new identifiers to be added to the config file for the relevant keymaps to engage, I'm not seeing much of an issue so far. Pretty much the same situation as when I got Wayland+GNOME working. It's looking good for quite a high percentage of desktop Linux users to be able to use Wayland with keyszer. Wonder what percentage of Linux desktop users are covered by support for both GNOME and KDE Plasma. I'm guessing at least 50%. Only tested completely on Fedora 38 KDE spin so far, but should work on other KDE distros equally well. |
|
Have tested the Wayland+KDE solution now on several distros with a KDE variant, or the ability to install a KDE desktop with a Wayland session. So far it's working pretty well. Ironed out a few bugs in the setup process while going through getting the installer working on openSUSE Tumbleweed, and I think it's pretty robust at this point. https://github.com/RedBearAK/toshy This installer now works on numerous different distros, and the end product will work if you are on X11/Xorg, Wayland+GNOME, or Wayland+KDE (Plasma). Any other environment will cause the branch of |
|
FYI to anyone who wants to use ./toshy_setup.py --barebones-configWhen using this installer option, Toshy becomes just a convenient way to install So Toshy can technically be useful now for those who just want to do some other kind of keymapping with For the Wayland+KDE support in particular, Toshy has to use multiple components separate from the keymapper to get the window attributes from Good news is the Toshy installer works on a pretty long list of popular distros now. And smoothly handles moving from one desktop environment to another on the same system, auto-detecting the environment. https://github.com/RedBearAK/toshy I'd like to hear from anyone who is using Toshy this way. |
|
I've added support for the Anyone interested can install for now from a zip downloaded from this this beta branch snapshot of the working version in the https://github.com/RedBearAK/toshy/tree/sway_beta At some point it will be merged into main, so if it's been a while since this was posted check the main branch README for references to The same branch also includes some code for Hyprland, but I can't test it myself. Anyone interested should try it and report any issues here: |
|
Added support for the upcoming Cinnamon/Muffin Wayland session. This required creating a Cinnamon shell extension modeled off the GNOME extensions I've been using for Wayland+GNOME support. Also confirmed that the Hyprland method is working, by installing Hyprland on Fedora 39 with this: |
|
Hi @RedBearAK, I just found out about Toshy and keyszer. I'm on hyprland and plasma playing with it, moving from xkeysnail. I've had my xkeysnail keyboard mappings set up for emacs, but I'm a little lost on how to get toshy to pull a new config file. I tried to look at the config files you have, like barebones. My understanding is that I should add them to toshy_config.py? But I'm not sure I'm understanding correctly. |
|
If you are not doing the Mac-style keymapper config, you will want to install Toshy with the ./setup_toshy.py install --barebones-configThis will install the barebones config file, or convert a standard Mac-like config file to the barebones config file. After that you just add whatever you want into the marked "slices" where your custom additions will be protected from a Toshy reinstall or upgrade. If you have trouble or need some pointers, open an issue on the Toshy repo. It uses a custom branch of |
Basically we just need a way for Wayland to provide us:
WM_NAME#2If this is possible, hooking it up should be largely trivial and adding a way for a user to tell the keymapper if they are using X or Wayland. (perhaps we could even auto-detect based on ENV)
The text was updated successfully, but these errors were encountered: