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

[mrshu]

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]

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]

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]

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]

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

[Gusser93]

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]

@Gusser93 Are you using Wayland or Xorg?

[Gusser93]

Sorry, I'm using Wayland.

[jahnf]

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]

@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]

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]

@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]

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]

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?