[BUG] Projecteur doesn't seem to work all that well on Gnome with Wayland on Fedora

mrshu commented 3 years ago

Description

While trying out Projecteur on Gnome with Wayland on Fedora, I came across a couple of issues. Projecteur is still very useful and I use it with Gnome on X.org with a great success but seeing how Wayland will probably be the only reasonable option in the future, I wanted to note my experience here.

Thanks!

To Reproduce

Just starting projecteur and clicking the main "zoom" button multiple times ends up generating the following log:

[2021-10-09T11:53:08.511][wrn][default] QObject::connect: No such signal QPlatformNativeInterface::systemTrayWindowChanged(QScreen*)
[2021-10-09T11:53:08.525][inf][projecteur.device] Connected device: Logitech Spotlight (USB) (046d:c53e)
[2021-10-09T11:53:08.563][inf][projecteur.HID] HID++ device '/dev/hidraw2' came online.
[2021-10-09T11:53:13.537][wrn][qt.qpa.wayland] Wayland does not support QWindow::requestActivate()
[2021-10-09T11:53:13.538][wrn][qt.qpa.wayland] Wayland does not support QWindow::requestActivate()
[2021-10-09T11:53:15.202][wrn][qt.qpa.wayland] Wayland does not support QWindow::requestActivate()
[2021-10-09T11:53:15.921][wrn][qt.qpa.wayland] Wayland does not support QWindow::requestActivate()
[2021-10-09T11:53:15.921][wrn][qt.qpa.wayland] Wayland does not support QWindow::requestActivate()
[2021-10-09T11:53:17.486][wrn][qt.qpa.wayland] Wayland does not support QWindow::requestActivate()
[2021-10-09T11:53:18.087][wrn][qt.qpa.wayland] Wayland does not support QWindow::requestActivate()
[2021-10-09T11:53:18.087][wrn][qt.qpa.wayland] Wayland does not support QWindow::requestActivate()
[2021-10-09T11:53:19.081][wrn][qt.qpa.wayland] Wayland does not support QWindow::requestActivate()

While all this is happening, the pointer doesn't respond to movement and it also seems that further clicking only generates the Wayland does not support QWindow::requestActivate() message.

Expected behavior

I would expect Projecteur to work the same way as it does on X.org (i.e. clicking and moving with the pointer would work out of the box).

Desktop/Linux Environment (please complete the following information):

Linux Distribution and Version: Fedora 34
Desktop/Window Manager and Version Gnome 40.4
Did you built Projecteur yourself?: n

What is the output of projecteur -f ?:

Projecteur 1.0-alpha.118
- git-branch: develop
- git-hash: 21e5e606ff2fb5daf712d66fc2a77cdb7aa3cdde
- compiler: GNU 10.1.1
- build-type: Release
- qt-version: (build: 5.13.2, runtime: 5.15.2)
- device-scan: (errors: 0, devices: 1 [readable: 1, writable: 1])

What is the output of projecteur -d ?: ...

Projecteur 1.0-alpha.118; device scan

 * Found 1 supported devices. (1 readable, 1 writable)

 +++ name:     'Logitech USB Receiver'
     userName: 'Logitech Spotlight (USB)'
     vendorId:  046d
     productId: c53e
     phys:      usb-0000:00:14.0-3
     busType:   BusType::Usb
     devices:   /dev/hidraw2, /dev/input/event19, /dev/input/event22, /dev/input/event20, /dev/input/event21
     readable:  true
     writable:  true

jahnf commented 3 years ago

Hello mrshu,

Thank for your report. have you tried starting Projecteur with QT_QPA_PLATFORM=wayland ./projecteur ? Do you have the 'zoom' setting activated or deactivated in the settings?

mrshu commented 3 years ago

Thanks for the reply @jahnf !

I have indeed tried to use QT_QPA_PLATFORM=wayland ./projecteur as well but it didn't seem to help.

With regards to enabling the zoom setting, it seems that that cause an even more interesting behavior, in which the actual "zoomed" part comes from a different part of the screen (i.e. it's certainly not under the cursor at the moment).

Let me just stress out once more than this doesn't preclude me from using Projecteur in any way -- it works very well with Xorg -- it's just something I thought would be best to share in here :)

jahnf commented 3 years ago

Alright, I am planning to install a Fedora 34 in a VM and try to first reproduce and see how this might be fixed with Qt5.

mrshu commented 3 years ago

Thanks @jahnf, I'd be happy to do any field testing you might find useful as well!

Gusser93 commented 3 years ago

Hi,

I can confirm the issue.

Desktop/Linux Environment (please complete the following information):

Linux Distribution and Version: Arch
Desktop/Window Manager and Version Gnome 40.4
Did you built Projecteur yourself?: y
What is the output of projecteur -f ?:

own Qt6 build

Projecteur 1.0-alpha.118
  - git-branch: develop
  - git-hash: 21e5e606ff2fb5daf712d66fc2a77cdb7aa3cdde
  - dirty-flag: 1
  - compiler: GNU 11.1.0
  - build-type: Release
  - qt-version: (build: 6.2.0, runtime: 6.2.0)
  - device-scan: (errors: 0, devices: 1 [readable: 1, writable: 1])

aur/projecteur-git

Projecteur 1.0-alpha.118
  - git-branch: develop
  - git-hash: 21e5e606ff2fb5daf712d66fc2a77cdb7aa3cdde
  - compiler: GNU 11.1.0
  - build-type: Release
  - qt-version: (build: 5.15.2, runtime: 5.15.2)
  - device-scan: (errors: 0, devices: 1 [readable: 1, writable: 1])

aur/projecteur

Projecteur 0.9.1
  - git-branch: master
  - git-hash: 483d4a36e72de3c00f3d7f76207cc73e5a88a812
  - compiler: GNU 11.1.0
  - qt-version: (build: 5.15.2, runtime: 5.15.2)
  - device-scan: (errors: 0, devices: 1 [readable: 1, writable: 1])

What is the output of `projecteur -d` ?: ...

Projecteur 1.0-alpha.118; device scan

 * Found 1 supported devices. (1 readable, 1 writable)

 +++ name:     'Logitech USB Receiver'
     userName: 'Logitech Spotlight (USB)'
     vendorId:  046d
     productId: c53e
     phys:      usb-0000:00:14.0-2
     busType:   BusType::Usb
     devices:   /dev/hidraw2, /dev/input/event19, /dev/input/event22, /dev/input/event20, /dev/input/event21
     readable:  true
     writable:  true

Additoinal information: If Projecteur is not running, I can control the cursor with the spotlight. If I use the spotlight-feature of Projecteur once I am not able to interact with anything on my screen until press ESC.

jahnf commented 3 years ago

@Gusser93 Are you using Wayland or Xorg?

Gusser93 commented 3 years ago

Sorry, I'm using Wayland.

jahnf commented 2 years ago

As a workaround you could use the following: QT_QPA_PLATFORM=xcb projecteur

This works at lease in a virtual machine with Fedora 34 I tried yesterday.

mrshu commented 2 years ago

@jahnf sadly, it doesn't seem to work all that well for me on the Fedora box I run -- the zoom button does indeed respond but moving the presenter doesn't seem to move the zoomed part, and the other two buttons do not seem to work either.

mrshu commented 2 years ago

When I closed the application, though, I did receive the following error log:

[2021-10-23T09:19:12.790][wrn][default] qrc:/main.qml:12: TypeError: Cannot read property 'currentSpotScreen' of null
[2021-10-23T09:19:12.790][wrn][default] qrc:/main.qml:30: TypeError: Cannot read property 'overlayVisible' of null
[2021-10-23T09:19:12.790][wrn][default] qrc:/main.qml:111: TypeError: Cannot read property 'showSpotShade' of null
[2021-10-23T09:19:12.790][wrn][default] qrc:/main.qml:96: TypeError: Cannot read property 'shadeColor' of null
[2021-10-23T09:19:12.790][wrn][default] qrc:/main.qml:91: TypeError: Cannot read property 'shadeOpacity' of null
[2021-10-23T09:19:12.790][wrn][default] qrc:/main.qml:169: TypeError: Cannot read property 'dotSize' of null
[2021-10-23T09:19:12.790][wrn][default] qrc:/main.qml:171: TypeError: Cannot read property 'dotColor' of null
[2021-10-23T09:19:12.790][wrn][default] qrc:/main.qml:172: TypeError: Cannot read property 'showCenterDot' of null
[2021-10-23T09:19:12.790][wrn][default] qrc:/main.qml:173: TypeError: Cannot read property 'dotOpacity' of null
[2021-10-23T09:19:12.791][wrn][default] qrc:/main.qml:155: TypeError: Cannot read property 'showBorder' of null
[2021-10-23T09:19:12.791][wrn][default] qrc:/main.qml:156: TypeError: Cannot read property 'borderOpacity' of null
[2021-10-23T09:19:12.791][wrn][default] qrc:/main.qml:89: TypeError: Cannot read property 'spotSize' of null
[2021-10-23T09:19:12.791][wrn][default] qrc:/main.qml:143: TypeError: Cannot read property 'borderSize' of null
[2021-10-23T09:19:12.791][wrn][default] qrc:/main.qml:106: TypeError: Cannot read property 'spotShape' of null
[2021-10-23T09:19:12.791][wrn][default] qrc:/main.qml:66: TypeError: Cannot read property 'multiScreenOverlayEnabled' of null
[2021-10-23T09:19:12.791][wrn][default] qrc:/main.qml:72: TypeError: Cannot read property 'cursor' of null
[2021-10-23T09:19:12.791][wrn][default] qrc:/main.qml:53: TypeError: Cannot read property 'zoomEnabled' of null
[2021-10-23T09:19:12.791][wrn][default] qrc:/main.qml:28: TypeError: Cannot read property 'spotRotationAllowed' of null
[2021-10-23T09:19:12.791][wrn][default] qrc:/main.qml:37: TypeError: Cannot read property 'zoomFactor' of null
[2021-10-23T09:19:12.791][wrn][default] qrc:/main.qml:129: TypeError: Cannot read property 'borderColor' of null

Could it be that my setup is rather strange?

jenschurchill commented 2 years ago

@mrshu I run Fedora 34, with Gnome and Wayland, and am seeing similar results.

Mouse cursor (now zoom window) stops moving once Projecteur is started, and forward/backwards stops responding. I thought that it might have been a permission issue with Wayland, but running as root doesn't fix it, so that partially disproves that theory.

Zoom window does appear, but is slow to initialise - I am guessing this might be due to ( if? ) the program has to take a screenshot first - maybe that is why it takes a second to appear?

Program output...

[2021-10-24T00:34:39.796][inf][projecteur.virtualdevice] Created uinput device: /sys/devices/virtual/input/input188
[2021-10-24T00:34:39.920][wrn][projecteur.mainapp] Qt 'xcb' platform and Wayland session detected.
[2021-10-24T00:34:40.018][inf][projecteur.device] Connected device: Logitech Spotlight (USB) (046d:c53e)
[2021-10-24T00:36:52.304][wrn][projecteur.input] Ignoring single SYN event received.
...
[2021-10-24T00:40:38.126][dbg][projecteur.input] Input map action, type =  1 , partial_hit =  false
[2021-10-24T00:40:38.126][dbg][projecteur.input] Emitting Key Sequence: Left
[2021-10-24T00:40:38.934][dbg][projecteur.input] Input map action, type =  1 , partial_hit =  false
[2021-10-24T00:40:38.934][dbg][projecteur.input] Emitting Key Sequence: Right

Journal states...

Oct 24 01:09:32 jmc-x1c6 kernel: input: Projecteur_input_device as /devices/virtual/input/input195
Oct 24 01:09:32 jmc-x1c6 systemd-logind[919]: Watching system buttons on /dev/input/event257 (Projecteur_input_device)
Oct 24 01:09:32 jmc-x1c6 gnome-shell[1466]: Could not open device /dev/input/event257: GDBus.Error:System.Error.ENODEV: No such device
Oct 24 01:09:44 jmc-x1c6 gnome-shell[1466]: Window manager warning: Invalid WM_TRANSIENT_FOR window 0x5400014 specified for 0x540001e.

I tried coding up a PyUSB module, to research a bit, I added some udev rules, to allow my user to interact with the USB device, and I am intercepting the data, but I have been unable to reverse the mouse coordinates data I am receiving, to anything meaningful I can use as reliable x,y coordinates (does anyone here know how the spotlights coordinates data is packed?).

Anyway, while able to receive from the unit, I too was unable to send keys and clicks directly to other apps, I decided to use ydotool to handle that part, which works great and is fast enough (by sort-of circumventing the security model of Wayland, and running ydotoold as root) - I guess Projecteur could do something similar?

Cheers, really wish we could get this running on Wayland!

jahnf commented 2 years ago

Thank you for all your feedback, Time is sparse right now but I will look into it.

Some details are just differently (or sometimes not implemented at all) on Qt side due to the different workings and restrictions of Wayland.

In any case, every detail or hint is appreciated.

About the zoom: The zoom with is working different with Wayland - since there is no Qt API to take a screenshot - Projecteur is using the KDE or Gnome DBus API - which saves a screenshot, which Projecteur then loads. This unfortunately takes longer then the implementation for Qt's xcb platform plugin.

jenschurchill commented 2 years ago

Cheers @jahnf - Thank you so much for Projecteur!

Some suggestions, if you like...

If a "run command" input mapping could be easily added, using the ydotool command could "solve" the left-key/right-key/click mouse button issue?
Taking ~1 second to open is survivable.*
That leaves zoom movement as the most important issue?.

*: I note that ksnip has added Wayland support for kde and gnome, and its screenshots seem very snappy - I just converted from flameshot to ksnip to test it, and there is a notable difference - it is also Qt5 based, so maybe there is something that can be learnt here?

mayanksuman commented 2 years ago

Hi @jahnf ,

we should implement xdg-desktop-portal based screenshot capture as it one of the cross-platform way for taking screenshots on wayland.

Reference: https://github.com/flatpak/xdg-desktop-portal/blob/master/data/org.freedesktop.portal.Screenshot.xml https://github.com/ksnip/ksnip/issues/243 https://github.com/flameshot-org/flameshot/issues/446 https://github.com/emersion/grim

mayanksuman commented 2 years ago

I briefly tested the program with Fedora 34 today. There are three different issues with Projecteur in wayland.

Issues with taking screenshot
Issue with setting the position of overlay window
Issue with setting different window flags

I have opened a new meta issue for discussing these problems (#174 ).

jahnf commented 1 year ago

MarcelWaldvogel commented 11 months ago

Just as another Wayland data point: On Debian Bookworm (Projecteur built from today's master), the overlay on my three-monitor system (GNOME, horizontal monitor arrangement, middle monitor holds the menu bar) works as follows:

In "Test" mode, the overlay consists of two rectangles of roughly screen size: The top left position of the first rectangle originates at the top left position of the inside of the preferences window. The other rectangle is to the right of it, slightly offset down (maybe by the difference in the monitor height?)
When using with a LibreOffice presentation (which uses the left two screens), the overlay is only on the rightmost screen, which is also permanently blanked.

It seems that the left two monitors are treated differently than the third?

Anyway, using QT_QPA_PLATFORM=xcb projecteur seems to be a viable workaround…

jahnf / Projecteur

[BUG] Projecteur doesn't seem to work all that well on Gnome with Wayland on Fedora #170