(enh) deal with loss/error on X display

[joshgoebel]

Resolves #2. Resolves #40.

• Catches errors raised if the X display cannot be connected.
• If the X display cannot be connected the keymapper falls into a "safe mode" where it stops all mapping and merely makes sure input and output continue to function properly.

[joshgoebel]

@rbreaves How do you feel about reviewing code? I was moving really fast at first but as things slow down a bit I wouldn't mind eyes on PRs going forward (and transitioning to a more PR driven workflow overall)...

Is that something you might be comfortable/interesting in doing? If Kinto switches you'll instantly become one of the largest users of the project... :-)

[joshgoebel]

@RedBearAK Thanks for all your help - you wouldn't want to test this PR with some of your tough logging in/out/whatever tests? Hopefully after this lands I can release 0.6 and then take a break for a bit. :)

[RedBearAK]

@RedBearAK Thanks for all your help - you wouldn't want to test this PR with some of your tough logging in/out/whatever tests? Hopefully after this lands I can release 0.6 and then take a break for a bit. :)

🤔
I was thinking about that, but not sure if I'm actually running keyszer the way you are intending, since I'm still just running it in the venv in a terminal tab and doing git pull all the time to keep up with new changes. I presume that means I'm still running it "as my user" at this point.

If I pip install keyszer a this point, won't it still be running as my user, unless I pip install with sudo to install system-wide? And even then won't I have to find a way to launch it as the keymapper user upon login, to see what it will do when I attempt to log out or switch users?

In short I'm not clear on exactly what keyszer is now designed to do automatically with regards to running as a special user and dealing with the X errors.

Or is most of this irrelevant to just trying to test the X error handling mechanism?

[joshgoebel]

Or is most of this irrelevant to just trying to test the X error handling mechanism?

I think this... whichever way you were running it before and having all the problems - run in that way again. What we're looking for is no more problems.

[RedBearAK]

I think this... whichever way you were running it before and having all the problems - run in that way again.

Well, I had issues whether I was running as root or as user, so...

Alright, well, I took a leap of faith and tried "Switch User" from the user menu. I'm in Ubuntu 22.04, GNOME 42.1. In the past the "Switch User" was broken from this user for reasons unknown, but it looks like the upgrade to 22.04 LTS un-broke it.

Other than the fact that GNOME acted like I had just asked it to suddenly cure cancer and end world hunger when I hit "Switch User" (it took a WHILE and did weird things to the screen), things have appeared to go pretty well.

At first it was just asking me to log back in to my user, but I clicked on the icon in the corner that lets you select the session type, and suddenly I was back at the full multi-user login screen (where I was supposed to be in the first place). Even before that, I was able to type just fine into the password field. So that was a marked improvement.

At the full login screen, I was able to select a user with arrows and Enter, then enter the password without difficulty. Once I logged into the other user, I was able to open a text editor and type away with no issues.

I opened a terminal and saw keyszer still running away in the background (as the user I had switched away from), but no longer apparently trying to take over the keyboard while the other user was in X.

And then I logged out of that user and logged back into this one. Did NOT need to restart anything in order to have my shortcuts active once again. It's as if I never left.

What I didn't try is installing and running keyszer separately while in the other user's desktop, either as user or as root. But at this point I kind of suspect that would work just fine. Each process only actively remapping when it knows it's connected to the X session being shown on screen (or whatever is actually happening).

I think you'd be OK to allow yourself one cookie for the day, for being a Good Coder[TM] and accomplishing a minor miracle or two. Enjoy it while you can, tomorrow will probably be a disaster. 🤘🏽 😈 🤘🏽

What we're looking for is no more problems.

Remember to toss some salt over your shoulder when you say things like that.

[RedBearAK]

Oh, I forgot to checkout the xorg_errors branch before doing all that. So the necessary bits must already be in main. If there's some specific aspect of the unmerged commits left in this branch that you wanted tested, I'll have to do it again.

[joshgoebel]

Nope. I have not merged yet.

[joshgoebel]

What I didn't try is installing and running keyszer separately while in the other user's desktop, either as user or as root. But at this point I kind of suspect that would work just fine. Each process only actively remapping when it knows it's connected to the X session being shown on screen (or whatever is actually happening).

There is no magic here... Running two is not going to work. The remapper would be stepping all over itself. If the X display is the same then the new user that logged in would have all their keys mapped also (provided they gave X permissions to the keymapper user).

The keymapper works when it can access the X display it was told about at startup (via the ENV)... when it can't it goes dormant and just passes keys straight thru.