search

jahnf / Projecteur

Linux Desktop Application for the Logitech Spotlight device (and similar devices) - Digital Laser Pointer
MIT License
379 stars 33 forks source link

Opaque black screen using rpm installs on OpenSUSE 15.1 KDE [solved] #24

Closed BriggsyUK1970 closed 4 years ago

BriggsyUK1970 commented 5 years ago

Hi,

I was encouraged to buy this tool as a colleague who uses OpenSUSE Leap (Gnome I think) said he got his working after using projeceur and talking with you. Thanks for your solution.

I have quickly used both your stable (0.5) and alpha latest (0.6) rpm builds on my Dell Precision 5530 with openSUSE Leap 15.1, KDE 5, not wayland (way too much trouble ;0), plasma 5.12.8. QT 4.8.7. I have tested against the Intel driver (non accelerated setup) and the NVIDIA setup (accelerated).

The results are consistent: It will not start under standard user (reports app already running). When running under root (sudo) the desktop tray app starts only when used the screen becomes black opaque when the spotlight is used (dark black for whole screen except the lighter grey opaque spotlight circle if I set it's colour to lighter than black).

In debugging I see that I have no group names "spotlight-xxx" at all after zypper in of rpm. Which seems odd and I assume connected. I also saw a lot of these type of messages in journalctl: qt.qpa.xcb: QXcbConnection: XCB error: 2 (BadValue), sequence: 14344, resource id: 58720261, major code: 142 (Unknown), minor code: 3

I'll happily try to build this from the git repo now, just wanted you to be aware of the issue I saw.

BriggsyUK1970 commented 5 years ago

Ha, so when I try to make the app I need a qt5 environment. So probably disregard the above ;0)

jahnf commented 5 years ago

Hi -

  1. regarding your first comment: If projecteur quits with Another application instance is already running. Exiting., there is another instance running. You can quit the running instance with ./projecteur -c quit.

  2. It should not be necessary to run as root - thats what the udev rules are for

  3. I don't know how to interpret your last comment - is it now working? :smile:

BriggsyUK1970 commented 5 years ago

OK thanks, it seems I was confused. As I read the instructions it looked to me the group "spotlight-device" is to be created by the rpm install and that the udev rules would only need to be applied when building through git clone process. I'm happy to test the rpm again, adding the group and then udev rule manually, but what properties should the group created have?

For the 3rd point - I have not got beyond working out what gcc should be called for cmake. So I haven't been able to install from git clone yet.

BriggsyUK1970 commented 5 years ago

OK thanks, it seems I was confused. As I read the instructions it looked to me the group "spotlight-device" is to be created by the rpm install and that the udev rules would only need to be applied when building through git clone process. I'm happy to test the rpm again, adding the group and then udev rule manually, but what properties should the group created have?

For the 3rd point - I have not got beyond working out what gcc should be called for cmake. So I haven't been able to install from git clone yet.

BriggsyUK1970 commented 5 years ago

Installing via the rpm, adding the udev rule does allow my standard user to move the cursor fine, but I still see the full blackened opaque screen rather than a spotlight effect, this tested when using the nvidia graphics driver (hardware accelerated). Error is now: qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 2151, resource id: 39845984, major code: 40 (TranslateCoords), minor code: 0 in terminal output when running as standard user

jahnf commented 5 years ago

@BriggsyUK1970 : When I have time I can try to run an OpenSuse 15.1 /w KDE in a VirtualBox and see if I can replicate the issue.

On my regular systems where I tested it (Opensuse 15.0 and Ubuntu 18.04), the built packages create a spotlight-device - this pre-installation script is included in the packages: https://github.com/jahnf/Projecteur/blob/develop/cmake/templates/preinst.in

You can also check the content of the package and see where the udev rule file is going to be installed, example:

user@os:~/build-projecteur> rpm -ql --info projecteur-0.6-alpha.2_opensuse-leap-15.0-x86_64.rpm
Name        : projecteur
Version     : 0.6.0
Release     : alpha.2
Architecture: x86_64
Install Date: (not installed)
Group       : unknown
Size        : 275620
License     : MIT
Signature   : (none)
Source RPM  : projecteur-0.6.0-alpha.2.src.rpm
Build Date  : Fr 14 Jun 2019 09:45:59 CEST
Build Host  : myhost
Relocations : (not relocatable)
Vendor      : unknown
Summary     : Linux/X11 application for the Logitech Spotlight device.
Description :
Linux/X11 application for the Logitech Spotlight device.
Homepage: https://github.com/jahnf/Projecteur
Distribution: (none)
/usr/lib/udev
/usr/lib/udev/rules.d
/usr/lib/udev/rules.d/55-spotlight.rules
/usr/local
/usr/local/bin
/usr/local/bin/projecteur
/usr/share/applications
/usr/share/applications/projecteur.desktop
/usr/share/icons
/usr/share/icons/hicolor
/usr/share/icons/hicolor/128x128
/usr/share/icons/hicolor/128x128/apps
/usr/share/icons/hicolor/128x128/apps/projecteur.svg
/usr/share/icons/hicolor/256x256
/usr/share/icons/hicolor/256x256/apps
/usr/share/icons/hicolor/256x256/apps/projecteur.svg
/usr/share/icons/hicolor/48x48
/usr/share/icons/hicolor/48x48/apps
/usr/share/icons/hicolor/48x48/apps/projecteur.svg
/usr/share/icons/hicolor/64x64
/usr/share/icons/hicolor/64x64/apps
/usr/share/icons/hicolor/64x64/apps/projecteur.svg
BriggsyUK1970 commented 5 years ago

Hi,

The issue was solved with the solution to #10 essentially I run: xcompmgr -c -t-6 -l-6 -o.1 & then start projecteur and spotlight works great

Thanks so much for your work!

jahnf commented 5 years ago

That is great. Thanks @rj-jesus for the reply to #10 I'll put it into the documentation/troubleshooting section for the next version.

mayanksuman commented 4 years ago

@rj-jesus A suggestion: Can be check that xcompmgr is running by command (pgrep xcompmgr &>/dev/null) and if not start it before starting projecteur?

Please check the script provided here. This way projecteur will work out of box in many more unsupported/untested WMs (solving this issue along with #10). There is no need to put this information in documentation/troubleshooting section (and force user remember one more troubleshooting step).

jahnf commented 4 years ago

Can be check that xcompmgr is running by command (pgrep xcompmgr &>/dev/null) and if not start it before starting projecteur?

I feel the need to comment on this, since I don't think just 'blindly' starting other programs in the background is a good idea. 1) How do I know it is necessary? On the machines I regularly use (that includes Ubuntu and OpenSuse and GNOME and KDE) you don't need xcompmgr at all 2) I don't like any software tool that runs something else behind by back just in case - do you? 3) The Linux desktop environments are so multi-faceted it almost impossible to cover all scenarios, that would end in maintaining a huge if/else that in the end will still fail in a lot of environments.

Feel free to challenge my arguments.

mayanksuman commented 4 years ago

How do I know it is necessary? On the machines I regularly use (that includes Ubuntu and OpenSuse and GNOME and KDE) you don't need xcompmgr at all

I want to clarify that starting xcompmgr is only a fallback mechanism. Software can test if the WM is supported it can skip starting xcompmgr.

I don't like any software tool that runs something else behind by back just in case - do you?

I don't too. But every software has some dependency (in case of projecteur a running composite manager is a dependency). I think the best way to resolve this question is to give user option in preference that let user select if in fallback xcompmgr will be used or not (as a checkbox button). Whenever the option is turned on and xcompmgr is started by projecteur, it can inform user.

Other wayaround for this: If we do not provide option/ start xcompmgr automatically, then at the start of projecteur can we check for any running supported composite manager and if none is found can we inform user with its possible troubleshooting step.

The Linux desktop environments are so multi-faceted it almost impossible to cover all scenarios, that would end in maintaining a huge if/else that in the end will still fail in a lot of environments.

That's why I suggest to use a generic piece of software. xcompmgr is coming from xorg and can be installed on any Linux system if it uses X11.

rj-jesus commented 4 years ago

Hello,

I also disagree with starting software automatically. I think an entry in the troubleshooting section would suffice. Moreover, if we could test in code for a running compositor, we could also output a warning message in case none was found.

Nevertheless, I do not think starting a program automatically to hide the issue is the way to go. We just have to make it clear that the issue may exist and how it can be solved.

-- Ricardo Jesus

jahnf commented 4 years ago

Updated README (2cf43106d58bfa8c59a6e4705a877cdb119ce435) - also on X11 platforms a warning in the preferences dialog is shown if no compositing manager is running.