project-repo/cagebreak

Mouse not responding

kinleyd opened this issue · 34 comments

kinleyd commented

Greetings, It took me a while to get back. Hope all is well at Team Cagebreak.

Now I have Cagebreak 1.9.1-1 installed on my updated Arch Linux box.

While the cursor itself responds to movement, mouse clicks do not evoke any response.

project-repo commented

Hi, we are busy, but everything is going well here, thanks!

Huh, I can't reproduce this on my end. Do you have anything
mouse-related set in your cagebreak config? Does this problem occur with
the example configuration (https://github.com/project-repo/cagebreak/blob/master/examples/config)? What kind of
mouse are you using (information about this can be obtained for example
by running cagebreak -s, see the manual for more information)?

Cheers,
project-repo

kinleyd commented

Hi, thanks for getting back:

$ cagebreak -s
Outputs:
* WL
Inputs:
* 0:0:wayland-pointer-seat
* 0:0:wayland-keyboard-seat

In my cagebreak/config I have:
input 2385:5842:Kingston_HyperX_Alloy_FPS_Pro_Mechanical_Gaming_Keyboard click_method clickfinger
input 1133:49284:Logitech_G102_Prodigy_Gaming_Mouse_Keyboard click_method clickfinger

Both were there before the update and worked fine. After the update the keyboard works but not the mouse. It's weird.

project-repo commented

Could you run cagebreak -s outside of the cagebreak session (i.e. in
the TTY or wherever you start your cagebreak session from)? Namely,
cagebreak -s shows the devices that would be added if instead of
cagebreak -s, cagebreak were run, so the output you sent shows the
information for a nested cagebreak session.

Hmm that is indeed weird, so does removing this configuration change
anything? What is the version you were running before the update that
caused the issue? Also, I don't understand the configuration:

input 2385:5842:Kingston_HyperX_Alloy_FPS_Pro_Mechanical_Gaming_Keyboard click_method clickfinger

Is the keyboard also a mouse? If not, why are you setting a
click_method for it?

Cheers
project-repo

kinleyd commented

Could you run cagebreak -s outside of the cagebreak session (i.e. in the TTY or wherever you start your cagebreak session from)? Namely, cagebreak -s shows the devices that would be added if instead of cagebreak -s, cagebreak were run, so the output you sent shows the information for a nested cagebreak session.

$ cagebreak -s
Outputs:

  • DP-2
  • DP-1
    Inputs:
  • 2385:5842:Kingston_HyperX_Alloy_FPS_Pro_Mechanical_Gaming_Keyboard
  • 1133:49284:Logitech_G102_Prodigy_Gaming_Mouse_Keyboard

Hmm that is indeed weird, so does removing this configuration change anything?

The keyboard continues to work, but the mouse doesn't work at all.

What is the version you were running before the update that caused the issue?

Since it came in via the AUR, I couldn't look up the previous version. It is from around Jan/Feb 2022.

Also, I don't understand the configuration:
input 2385:5842:Kingston_HyperX_Alloy_FPS_Pro_Mechanical_Gaming_Keyboard click_method clickfinger
Is the keyboard also a mouse? If not, why are you setting a click_method for it?

It's a keyboard. The system doesn't boot if I don't provide params for this and I didn't know what other parameters to use. However, as noted above, the keyboard functions even if I don't set an input device setting for it.

Besides the weird mouse problem, there is another:

The workspace size for one of my monitors, DP-1, is being set to something much larger than what it is configured for in cagebreak/config:

output DP-1 pos 0 0 res 2560x1440 rate 60
output DP-2 pos 2560 0 res 1920x1080 rate 60

So a large part of any apps I run on DP-1 are beyond the physical screen. I'm not sure what's happening now, but previously this didn't happen. DP-1 is a 3840x2160 monitor on which I'm picking a lower res for scaling reasons. Cagebreak does not appear to be bounding the screen inside the selected resolution.

TIA

project-repo commented

Since it came in via the AUR, I couldn't look up the previous version.
It is from around Jan/Feb 2022.

OK, that narrows it down a bit. Did you perform a wlroots update simultaneously to the cagebreak update that broke your setup or was no wlroots update involved? Also, does downgrading solve the issue? Does the hardware (mouse/keyboard) work under Xorg (in case you have Xorg set up)?

It's a keyboard. The system doesn't boot if I don't provide params for
this and I didn't know what other parameters to use. However, as noted
above, the keyboard functions even if I don't set an input device setting
for it.

So you mean cagebreak doesn't start without the cagebreak configuration? Or do you really mean that the entire computer does not boot without it (that would indeed be very worrying)? At this point I'm afraid that we're pretty much guessing blindly (about both issues) without a debug log, so do you think it would be possible to upload some logs of when the bugs are happening?

Here are instructions to do so:

  1. If you don't already have this, download the cagebreak package from the AUR (i.e. not the cagebreak-bin package).
  2. In the PKGBUILD, change --buildtype=release to --buildtype=debug.
  3. Invoke makepkg.
  4. Find the cagebreak binary in the pkg dir. (should be pkg/usr/bin/cagebreak)
  5. Run this binary while redirecting the standard error and standard output to some file (e.g. ./cagebreak >cb_log 2>&1). Please start cagebreak from the environment you usually use it from (probably TTY) so that all errors are as reproducible as possible. We would be particularly interested in the following scenarios:
    • Cagebreak does not start (if this occurs)
    • Start cagebreak, open window on screen which is configured wrongly, close cagebreak.
    • Start cagebreak, try to click a few times, close cagebreak.

Cheers,
project-repo

kinleyd commented

Since it came in via the AUR, I couldn't look up the previous version.
It is from around Jan/Feb 2022.
OK, that narrows it down a bit.

I took a look at my /usr/bin and found I'd kept a copy of the executable I was using at the time - it was v1.8.2.

Did you perform a wlroots update simultaneously to the cagebreak update that broke your setup or was no wlroots update involved?

I'm not sure. I ran a system update (-Syu) so it's possible wlroots got updated as well. I updated from kerrnel 5.15.x to 5.19.2 so that seems highly likely.

Also, does downgrading solve the issue?

I haven't tried it but I think it would, because it was all working on kernel 5.15.x

Does the hardware (mouse/keyboard) work under Xorg (in case you have Xorg set up)?

Yes. The update on my Xorg system was also from kernel 5.15.x to 5.19.2. So it's definitely a Wayland only thing.

It's a keyboard. The system doesn't boot if I don't provide params for
this and I didn't know what other parameters to use. However, as noted
above, the keyboard functions even if I don't set an input device setting
for it.

So you mean cagebreak doesn't start without the cagebreak configuration? Or do you really mean that the entire computer does not boot without it (that would indeed be very worrying)? At this point I'm afraid that we're pretty much guessing blindly (about both issues) without a debug log, so do you think it would be possible to upload some logs of when the bugs are happening?

My apologies for my sloppy wording. I had my system auto login with agetty, and then I had cagebreak auto start with a call in .zprofile. So it was easy to confuse between system and cagebreak initialization. After I removed both those settings, I have no problem getting to a tty prompt and logging into a session. The failure to start is only when cagebreak is invoked.

Here are instructions to do so:
1. If you don't already have this, download the cagebreak package from the AUR (i.e. not the cagebreak-bin package).
2. In the PKGBUILD, change --buildtype=release to --buildtype=debug.
3. Invoke makepkg.
4. Find the cagebreak binary in the pkg dir. (should be pkg/usr/bin/cagebreak)
5. Run this binary while redirecting the standard error and standard output to some file (e.g. ./cagebreak >cb_log 2>&1). Please start cagebreak from the environment you usually use it from (probably TTY) so that all errors are as reproducible as possible. We would be particularly interested in the following scenarios:

   * Cagebreak does not start (if this occurs)
   * Start cagebreak, open window on screen which is configured wrongly, close cagebreak.
   * Start cagebreak, try to click a few times, close cagebreak.

Cagebreak started. Strangely, with this build mouse clicks respond in Firefox (it didn't earlier), but there is no response in Emacs to mouse clicks or movements.

The log is really long, so I've only put in the starting and ending sections: Hope it helps.
BTW, while googling this problem there was some chatter about xwindows being linked to a similar problem that others have experienced. Not sure if it applies here.

cb_log.txt

project-repo commented

Hi,
So we looked into this a bit and we're not quite sure what is going
on... But then we realized that the relevant code will most likely in
any case change in the next release when we switch to wlr_scene. So
the most elegant solution would be to get the release going as soon as
possible and as a side effect fix these issues too. To make sure that
this actually works, could you check out the current version of
cagebreak on the development branch? Attached to this message you
may find a PKGBUILD which compiles the latest version from the
development branch.

Cheers,
project-repo

# Maintainer: project-repo <archlinux-aur@project-repo.co>
pkgname=cagebreak
pkgver=1.9.1
pkgrel=1
pkgdesc='Tiling wayland compositor based on cage inspired by ratpoison'
arch=('x86_64')
url='https://github.com/project-repo/cagebreak'
license=('MIT')
depends=('wayland' 'libxkbcommon' 'wlroots<0.16.0' 'pango')
makedepends=('meson' 'ninja' 'scdoc' 'wayland-protocols')
optdepends=('wl-clipboard: clipboard support'
            'xorg-xwayland: x application support')
options=('!buildflags' '!strip')
conflicts=('cagebreak-bin')
source=("cagebreak::git+https://github.com/project-repo/cagebreak")
sha512sums=('SKIP')
build() {
	cd "$pkgname"
	git checkout development
	meson build --buildtype=debug -Dxwayland=true
	ninja -C build
}
package() {
	cd "$pkgname"
	mkdir -p "$pkgdir/usr/bin/"
	cp 'build/cagebreak' "$pkgdir/usr/bin/"
}
kinleyd commented

OK, I used the PKGBUILD that you shared. With this version Cagebreak doesn't start at all.
This version of cagebreak appears to be 1.8.2. If that is correct, then it is very likely not going to be compatible with all the relevant libraries that would have been upgraded in the current versions of Linux. Should the version number be more current?

project-repo commented

How exactly does cagebreak fail to start? Or does it fail to compile?

If it compiles but fails to start, can you please provide us with a
debug log (note that you can attach files to comments on github instead
of writing them in the issue directly, which is useful for long files)?

If it fails to compile, what is the compiler error?

The version number on the development branch does not have any
particular meaning, this only applies to releases. If you want to
indicate a precise version, indicate the commit hash.

cheers,
project-repo

kinleyd commented

How exactly does cagebreak fail to start? Or does it fail to compile?

Oops, sorry for being unspecific. Yes, it compiles and installs, but fails to start.

If it compiles but fails to start, can you please provide us with a debug log (note that you can attach files to comments on github instead of writing them in the issue directly, which is useful for long files)?

cb_log.txt
I've also updated the other comment to have the log file attached instead of that long string of text.

If it fails to compile, what is the compiler error?

It compiles.

The version number on the development branch does not have any particular meaning, this only applies to releases. If you want to indicate a precise version, indicate the commit hash.

OK, that makes sense.

cheers, project-repo

Thanks! I look forward to a fix for this. I have already tried the new additions like 'screen , etc. which I appreciate. I'm now keen to try out the other features in the dev branch (active screen follows mouse, etc)

project-repo commented

Hi kinleyd,
Thanks for the log, it looks like for some reason your DP-1 output
cannot be configured correctly. We've created a new branch
startup_failed which instead of failing to start disables the output
when this happens. It's not really a fix but it should help to get
cagebreak started so we can continue debugging the other problem. Could
you try checking out that branch? Attached you find a PKGBUILD which
compiles this branch.
Cheers
project-repo

# Maintainer: project-repo <archlinux-aur@project-repo.co>
pkgname=cagebreak
pkgver=1.9.1
pkgrel=1
pkgdesc='Tiling wayland compositor based on cage inspired by ratpoison'
arch=('x86_64')
url='https://github.com/project-repo/cagebreak'
license=('MIT')
depends=('wayland' 'libxkbcommon' 'wlroots<0.16.0' 'pango')
makedepends=('meson' 'ninja' 'scdoc' 'wayland-protocols')
optdepends=('wl-clipboard: clipboard support'
            'xorg-xwayland: x application support')
options=('!buildflags' '!strip')
conflicts=('cagebreak-bin')
source=("cagebreak::git+https://github.com/project-repo/cagebreak")
sha512sums=('SKIP')
build() {
	cd "$pkgname"
	git checkout startup_failed
	meson build --buildtype=debug -Dxwayland=true
	ninja -C build
}
package() {
	cd "$pkgname"
	mkdir -p "$pkgdir/usr/bin/"
	cp 'build/cagebreak' "$pkgdir/usr/bin/"
}
kinleyd commented

The new version compiles and installs, but still fails to start cagebreak:
cb_log.txt
Let me know what else I could try.

kinleyd commented

I also disconnected DP-1 and ran the same dev build of cagebreak referenced in my post just before this. This way it does run. The log is below:
cb_log.txt

project-repo commented

Hmm strange that it still doesn't start... But one issue at a time: So
is the original bug (with the mouse clicks) still present after you
disconnected DP-1?

Cheers,
project-repo

kinleyd commented
project-repo commented

I finally managed to get hold of a second monitor with which I can at
least reproduce the issue with cagebreak not starting when configuration
is applied. We are currently working on that issue and will get back to
you as soon as we have a solution.

Cheers
project-repo

  • 👍1
kinleyd commented

Great! I look forward to a fix.

project-repo commented

Hi kinleyd,
We just pushed some code to the startup_failed branch, could you see if that resolves the issue about the window size being incorrect when using a custom mode? What is the status of the original mouse bug on the current startup_failed branch?
Cheers
project-repo

  • 👍1
kinleyd commented

Awesome guys!

Mouse continues to respond to movement and clicks on Firefox.

Monitor size set in config now works as expected.

On Emacs mouse responds to clicks and mouse over on one of the three frames I have open. No response to mouse movements and clicks on the other two frames.

On Reaper the mouse movements are reflected, but there is still no response to clicks.

Debug report:
cb_log.txt
Note: Cagebreak wouldn't start in this mode.

kinleyd commented

BTW, does this branch contain support for Cagebreak state over ipc socket covered under #12?
If so, can you instruct me as to how to test this feature? Thanks.

project-repo commented

OK, thanks for the update, we're looking into the mouse issue (this one is trickier b.c. atm we don't have a possibility to reproduce it).
About the state over ipc: Yes, it does actually and that would be awesome if you could check it out! The state is printed over the cagebreak socket every time an event occurs. If you wish to receive a complete dump of the current cagebreak state, you can send dump over the cagebreak socket. It may very well be, that there are still issues with this and we would be very happy to hear if you find anything (or if there is an event which isn't reported but you would like to have reported, let us know)! Please either open a new issue for this or use #12.
Cheers
project-repo

project-repo commented

Also, could you check whether the windows which do not recognize mouse clicks are xwayland windows (if they are xwayland windows, then f.e. running xprop in a terminal and clicking on the window will show information about the window)?

kinleyd commented

OK, I checked with xprops:

The Firefox instance isn't xwindows per xprop as it does not provide any response, but responds to mouse clicks.

The emacs windows and frames are xwayland windows - but interestingly only one frame responds to mouse clicks, the others don't.

The Reaper instance is also interesting:
If I start the instance while in an Emacs frame, it isn't xwindows - with no response to xprop and mouse clicks.
If I start it outside the Emacs frames, then it is xwindows - with response to xprop AND mouse clicks.

Note: The behaviour changes depending on whether we cold or warm rebooted.

project-repo commented

Hmm strange, I can reproduce issues with xwayland, but I'm not quite
sure what is going on. Can you check out the commit we just pushed to
the startup_failed branch? Does this change anything?

Cheers,
project-repo

kinleyd commented

Hey, it all works now. Mouse clicks respond everywhere (Firefox, Emacs and Reaper), and mouse over triggers focus shift between Emacs windows. Awesome!

There are only a couple of errors when cagebreak is run related to seat and seatd, though cagebreak starts after the errors are reported:
cb_log.txt

project-repo commented

Perfect, great to hear! The errors you are referring to are completely
normal, as wlroots attempts several different backends before choosing
the correct one. You can also see that these lines are prefixed with the
"INFO" tag instead of "WARNING" or "ERROR". Thanks so much for
reporting!

Cheers
project-repo

kinleyd commented

Thanks for fixing it! Do I have the honour of closing this issue?

project-repo commented

Thank you. Please do not close this issue. It will remain open until
a release is published so that users of the release, which may have
stumbled upon the same bug, can see that the bug is known and don't have
to file another issue in the meantime.

cheers,
project-repo

kinleyd commented

Will do. I look forward to the next release. :)

kinleyd commented

I was wondering when the next version is planned to be released. No pressure or urgency, just wondering.
Meanwhile, seasons greetings and good wishes for the coming new year!

project-repo commented

Hi kinleyd
We're planning on getting the release done sometime soon (~days), but it
depends on how difficult the remaining features are to implement.

Meanwhile, seasons greetings and good wishes for the coming new year!

Thank you, happy new year to you too!
Cheers
project-repo

  • 👍1
project-repo commented

Hi kinleyd,

there might be some delays because we have to adapt cagebreak to wlroots
0.16.1 and other things are taking longer than expected too.

We still hope for a release soon.

cheers,
project-repo

  • 👍1
project-repo commented

Hi kinleyd,

this is fixed as part of release 2.0.0.

I am closing this issue.

cheers
project-repo

  • 👍1
kinleyd commented

Awesome - and congratulations on release 2.0.0!