Closed frigaut closed 4 years ago
Thanks for the feedback - I'd love for the project to support Wayland. Unfortunately I do not have any experience with Wayland. I think the default Qt build for most systems and the precompiled version from Qt itself are using X11 by default. But qt has different platform plugins (https://doc.qt.io/qt-5/qpa.html) So one possibility is to try the qwayland plugin. (Be aware that this is easier said than done 🙂)
Thanks for the pointers, didn't know about the plugins. Because I have several other Qt applications running in my gnome environment, I probably won't try that for now, but I'll keep it in mind for the future, cheers ! Anyway, great work.
I also use Wayland with Gnome/Fedora and it works :
Warning: Ignoring XDG_SESSION_TYPE=wayland on Gnome. Use QT_QPA_PLATFORM=wayland to run on Wayland anyway.
, the spot always works but the preference menu icon isn't displaid.@frigaut: Did the QT_QPA_PLATFORM=wayland
as described by @alocquet do the trick?
Hi Jahnf,
Nope, not on archlinux (or my particular system implementation). The option does something (I get a different preference menu), but the screen greying keep jumping around and I get an error/warning message:
qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
Happy to test that further if it can help, but don't go out of your way for me, not a killer issue.
Ah yeah the different features available for Qt platforms is definitely an issue. As a side note, found an interesting blog article about Qt/Wayland: https://blog.martin-graesslin.com/blog/2015/07/porting-qt-applications-to-wayland/ (Most interesting section: No longer working API)
Ah, yes. I can see "Qwindow::requestactivate" is no longer supported in wayland. That probably makes it slightly awkward to support it for you. Interesting blog post anyway. Cheers. For me, I'll be running it under Xorg tomorrow while giving my lecture.
With Ubuntu 19.04 (in a virtual machine) and logging into an 'Ubuntu on Wayland' session I get the following behavior:
user@ubuntu1904:~/Projecteur/build$ ./projecteur --version
Projecteur 0.5-alpha.4
- git-branch: develop
- git-hash: 36916970ad9da316f0694c64d5d4ab40b0837f46
Running without any additional environment variables set, the system tray shows and it seems everything works, but Qt does not seem to run with it's wayland backend.
user@ubuntu1904:~/Projecteur/build$ ./projecteur
Warning: Ignoring XDG_SESSION_TYPE=wayland on Gnome. Use QT_QPA_PLATFORM=wayland to run on Wayland anyway.
When running with QT_QPA_PLATFORM=wayland
set, the system tray is not showing, but other than that everything seems to work.
user@ubuntu1904:~/Projecteur/build$ QT_QPA_PLATFORM=wayland ./projecteur
Warning: Ignoring XDG_SESSION_TYPE=wayland on Gnome. Use QT_QPA_PLATFORM=wayland to run on Wayland anyway.
QSocketNotifier: Can only be used with threads started with QThread
Using Wayland-EGL
FYI, currently you can bring Projecteur to show the Preferences dialog with
./projecteur -c settings=show
when an instance of the program is already running (this interface is not yet defined and documented and might change in the future)
When an instance is already running, you can also show and hide the the spot with ./projecteur -c spot=on
and ./projecteur -c spot=off
without the need of having an actual spotlight device connected and detected. ./projecteur -c quit
exits the already running Projecteur instance.
(As mentioned above the -c
command interface as it currently exists is not documented and might still change in future releases)
works for me on wayland except for the zoom feature, instead of zooming in the spotlight is just black. Spotlight seems to put the dark overlay on everything just fine though. The panel icon shows up as well.
@mogorman Thank you for the feedback
instead of zooming in the spotlight is just black
Interesting, if I put up a branch with some changes would you be able to do some tests?
First I'd like to narrow down where that black zoomed area is coming from (probably something with Qt's grabWindow
)
for sure just let me now the branch to try
Well as it turns out grabbing the whole screen on Wayland is a bug, see https://bugreports.qt.io/browse/QTBUG-34976 - :disappointed: doesn't look that it is going to be fixed anytime soon. But good to know so I can put it into the list of known issues/Troubleshooting.
Edit: Maybe it helps to create an account and upvote the bug issue QTBUG-34976 - I already did that.
KSnip added Wayland support so at some point we can have a look how they take a screenshot on wayland..
it looks like the way ksnip works around it is have a grabber for each type of environment. https://github.com/DamirPorobic/ksnip/tree/master/src/backend/imageGrabber
@mogorman thanks, For Wayland+KDE and Wayland+GNOME it is possible to get the screen via DBus commands, that can be done without too much code. I'll give it a try and push it to branch for testing this week.
I pushed some changes to feature/wayland-zoom-support
. Now when using Wayland at least on KDE and GNOME the zoom feature should work (gets a screen capture via their DBus interfaces).
It is a bit slower (means a little delay before the zoom-spot is shown), but as far as I tried it it works.
:star: It would be great if everyone that has uses Wayland and (KDE or GNOME) could test it, also multi-screen setups if possible and post the results.
You need to have Qt DBus development headers and libs installed when building (but as far as I noticed only on OpenSuse this is a special package libQt5DBus-devel
- all other distros seem to bundle that with some of the other qt5 packages). Thank you in advance.
Rebuilt on my nixos box and can confirm it works great on gnome on my laptop. I can try with laptop and external monitor tomorrow. Thank you for the patch and the project in general
one thing i did notice in this implementation is that the magnification does not update, meaning you get the screen state once the spot is created, and never again. so if the screen updates it will be showing wrong data.
I don't think that is a problem for my application as im only using this for slides, but just thought id mention it.
Thank you for testing :+1:
one thing i did notice in this implementation is that the magnification does not update, meaning you get the screen state once the spot is created, and never again.
Yes, that is a general problem that also other magnifier tools face. Although they can get around the problem by showing the magnified content rectangle always in the same position on the screen. But if I am showing the spotlight AND updating my screen capture, the spotlight itself will be in that zoomed image. Haven't found a way around it yet.
oh of course that is tricky. I think in wayland though you could get the state of the screen without the magnifier bit present and then overlay it. I'd have to look into how that works, but I think you are right that you can't do that with Xorg
Closing this issue. For the most part Projecteur seems to work for Wayland users. Any other issues should be put into a separate new issue.
Hi jahnf,
Thanks for the great tool. It works as expected under gnome (arch) running on Xorg, but does struggle on gnome Wayland (I get the spot occasionally when bringing up the preference menu, probably over Xorg control part of the screen?). Not complaining though, but do you have any pointer to make it work more reliably under wayland? Not too worry if you don't ! Congrats for the linux support of this gadget.