Mouse not responding

[kinleyd]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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

[kinleyd]

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]

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]

Yes, that bug remains. The status since switching from cagebreak-bin to cagebreak (both 1.9) and dev versions since:

Mouse responds to movement and clicks on Firefox.

Firefox window is always the physical max monitor resolution, and does not respect monitor size set in config.

On Emacs mouse responds to clicks and mouse over on one frame. No response on two other frames.

Edit:

And finally, and I think the only other GUI app I have on this system, on Reaper the mouse movements are reflected, but there is no response to clicks.

So basically a strange collection of mouse behaviour depending on the application being used.

On Sep 13, 2022, 10:31 PM, at 10:31 PM, project-repo @.***> wrote:

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

-- Reply to this email directly or view it on GitHub: https://github.com/project-repo/cagebreak/issues/30#issuecomment-1245659687 You are receiving this because you authored the thread.

Message ID: @.***>

[project-repo]

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

[kinleyd]

Great! I look forward to a fix.

[project-repo]

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

[kinleyd]

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]

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]

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]

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]

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]

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]

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]

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]

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

[project-repo]

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]

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

[kinleyd]

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]

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

[project-repo]

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

[project-repo]

Hi kinleyd,

this is fixed as part of release 2.0.0.

I am closing this issue.

cheers project-repo

[kinleyd]

Awesome - and congratulations on release 2.0.0!