Unsupported in Flatpak due to a combination of unresolved issues in Hyperland and Flatpak sandboxing security model.
Install the native Arch build instead for proper cursor tracking on Hyprland
Hugo Baldwin changed status to Completed
Team•
Mar 18
Pinned
I’ve narrowed the definition of this specific work to just Hyprland and can confirm that cursor tracking is now working correctly as of v0.1.123. Tested using the Flatpak build in Omarchy (Arch+Hyprland).
To update to the latest version of Hosaka Studio flatpak, use `flatpak update --user com.hosaka.studio`
Please let me know if you encounter any further issues with cursor tracking on Hyprland. Support will likely be added for Sway etc later - especially if anyone requests it.
Sujal Gurung
•
Mar 18
Thanks. Is cursor tracking used for where the zoom centers? The auto-zoom’s center position feels slightly better after the update.
Could you check the recording below? The fake cursor (added by the app) doesn’t appear on the screen but it appears near the end of the video on the right side (when I’m hovering over the tab list)
This line is still being logged to the console:
8:56:39.272 DEBUG hosaka.capture.wayland.portal:299- Created portal session: /org/freedesktop/portal/desktop/session/1_90/hosaka_iharihoj 18:56:39.275 INFO hosaka.capture.wayland.portal:251- Portal available cursor modes: 3 (hidden=True, embedded=True, metadata=False) 18:56:39.276 WARNING hosaka.capture.wayland.portal:321- Portal does not support CURSOR_MODE_METADATA (available=3), falling back to CURSOR_MODE_EMBEDDED — cursor tracking will be unavailable
I came across a similar bug for Recordly today though not sure if it’s relevant since it uses Electron.
Hugo Baldwin
Team•
Mar 18
Do you have a multi-monitor setup? I can’t reproduce this in Omarchy (with one or two screens). There are two bugs here (and one misleading log message):
one, the native cursor is still being displayed even when Hosaka’s cursor is being used - this should be a quick fix;
two, the “fake” cursor is one screen-width to the right of its correct position (but otherwise appears to be at the correct height) - I can’t reproduce this one;
the log messages simply say that Hyprland doesn’t include the cursor coordinates along with screen frames (unlike GNOME/KDE which do), so it needs to use a fallback method to get the cursor coords. The “cursor tracking will be unavailable“ is incorrect and I’ll fix it.
Sujal Gurung
•
Mar 19
I had a similar thought right before sleeping that maybe my monitor config was messing with it, but didn’t feel like getting up to test it :p
Sure enough it was. I had this hyprland config but have been using just the laptop display for a while now, so it was being positioned 1366px off.
Changed it and now the second bug is fixed. Maybe this thread will help someone else in the future
Sujal Gurung
•
Mar 17
Edit: Auto zooms started working but the other cursor settings (show, size) don’t work
Hello. I was testing the app on Arch+Hyprland and it can’t use some of the cursor related features (cursor appearance settings in the editor, zoom on click) due to being unable to capture the cursor properly? I’ve attached the app’s output below which has more useful info.
screen.txt
4.4 KB• Text
I saw you post elsewhere that the app works on Omarchy. Do the cursor features work on it too?
Sujal Gurung
•
Mar 17
Should add that before this, the app’s logs said that in order to capture the cursor, I needed to either install hosaka’s udev or run sudo usermod -aG input $USER & logout. I had saved those logs but they got deleted after running the command and rebooting. No longer shows now. Maybe this message should be shown in the GUI itself?
Hugo Baldwin
Team•
Mar 17
Hi Sujal thanks for the feedback and the attached log, it’s a big help!
I am aware of an issue where some laptop touchpads only register actual press-clicks as clicks but don’t register simple taps as a click. I will install Omarchy on a spare laptop now (I recently installed Linux Mint over it) and will get back to you later today.
Ignore the “sudo usermod -aG input $USER & logout“ in the logs - the cursor features should work without any extra user involvement - but if user involvement is required it will be displayed in the GUI itself as you suggested.
Lastly, you can get more informative log output by running the app with the --debug flag.
Sujal Gurung
•
Mar 18
Thank you. Will test further. The app is very promising.
Edit: Forgot to mention that the logs explicitly mention being unable to capture the cursor
Log in to comment and vote
Comments9
Mar 19
PinnedUnsupported in Flatpak due to a combination of unresolved issues in Hyperland and Flatpak sandboxing security model.
Install the native Arch build instead for proper cursor tracking on Hyprland
Mar 18
PinnedI’ve narrowed the definition of this specific work to just Hyprland and can confirm that cursor tracking is now working correctly as of v0.1.123. Tested using the Flatpak build in Omarchy (Arch+Hyprland).
To update to the latest version of Hosaka Studio flatpak, use `flatpak update --user com.hosaka.studio`
Please let me know if you encounter any further issues with cursor tracking on Hyprland. Support will likely be added for Sway etc later - especially if anyone requests it.
Sujal Gurung
Mar 18
Thanks. Is cursor tracking used for where the zoom centers? The auto-zoom’s center position feels slightly better after the update.
Could you check the recording below? The fake cursor (added by the app) doesn’t appear on the screen but it appears near the end of the video on the right side (when I’m hovering over the tab list)
This line is still being logged to the console:
8:56:39.272 DEBUG hosaka.capture.wayland.portal:299 - Created portal session: /org/freedesktop/portal/desktop/session/1_90/hosaka_iharihoj 18:56:39.275 INFO hosaka.capture.wayland.portal:251 - Portal available cursor modes: 3 (hidden=True, embedded=True, metadata=False) 18:56:39.276 WARNING hosaka.capture.wayland.portal:321 - Portal does not support CURSOR_MODE_METADATA (available=3), falling back to CURSOR_MODE_EMBEDDED — cursor tracking will be unavailableI came across a similar bug for Recordly today though not sure if it’s relevant since it uses Electron.
Hugo Baldwin
Mar 18
Do you have a multi-monitor setup? I can’t reproduce this in Omarchy (with one or two screens). There are two bugs here (and one misleading log message):
one, the native cursor is still being displayed even when Hosaka’s cursor is being used - this should be a quick fix;
two, the “fake” cursor is one screen-width to the right of its correct position (but otherwise appears to be at the correct height) - I can’t reproduce this one;
the log messages simply say that Hyprland doesn’t include the cursor coordinates along with screen frames (unlike GNOME/KDE which do), so it needs to use a fallback method to get the cursor coords. The “cursor tracking will be unavailable“ is incorrect and I’ll fix it.
Sujal Gurung
Mar 19
I had a similar thought right before sleeping that maybe my monitor config was messing with it, but didn’t feel like getting up to test it :p
Sure enough it was. I had this hyprland config but have been using just the laptop display for a while now, so it was being positioned 1366px off.
monitor = HDMI-A-1, preferred, 0x0, 1 monitor = eDP-1, 1366x768@60, 1366x0, 1Changed it and now the second bug is fixed. Maybe this thread will help someone else in the future
Sujal Gurung
Mar 17
Edit: Auto zooms started working but the other cursor settings (show, size) don’t work
Hello. I was testing the app on Arch+Hyprland and it can’t use some of the cursor related features (cursor appearance settings in the editor, zoom on click) due to being unable to capture the cursor properly? I’ve attached the app’s output below which has more useful info.
screen.txt
4.4 KB• Text
I saw you post elsewhere that the app works on Omarchy. Do the cursor features work on it too?
Sujal Gurung
Mar 17
Should add that before this, the app’s logs said that in order to capture the cursor, I needed to either install hosaka’s udev or run
sudo usermod -aG input $USER & logout. I had saved those logs but they got deleted after running the command and rebooting. No longer shows now. Maybe this message should be shown in the GUI itself?Hugo Baldwin
Mar 17
Hi Sujal thanks for the feedback and the attached log, it’s a big help!
I am aware of an issue where some laptop touchpads only register actual press-clicks as clicks but don’t register simple taps as a click. I will install Omarchy on a spare laptop now (I recently installed Linux Mint over it) and will get back to you later today.
Ignore the “
sudo usermod -aG input $USER & logout“ in the logs - the cursor features should work without any extra user involvement - but if user involvement is required it will be displayed in the GUI itself as you suggested.Lastly, you can get more informative log output by running the app with the
--debugflag.Sujal Gurung
Mar 18
Thank you. Will test further. The app is very promising.
Edit: Forgot to mention that the logs explicitly mention being unable to capture the cursor