Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

System76 Driver does not launch on "Pop on Wayland" session #58

Open
strugee opened this issue Aug 24, 2018 · 7 comments
Open

System76 Driver does not launch on "Pop on Wayland" session #58

strugee opened this issue Aug 24, 2018 · 7 comments

Comments

@strugee
Copy link

strugee commented Aug 24, 2018

Distribution (run cat /etc/os-release): Pop!_OS 18.04

Related Application and/or Package Version (run apt policy $PACKAGE NAME): everything is up-to-date as of today; I'm happy to check exactly what versions everything is using but it's slightly inconvenient because I've rebooted into Qubes in order to access GitHub. Let me know if that's the case and I'll happily edit.

Issue/Bug Description:

Trying to launch the System76 Driver while logged into the "Pop on Wayland" session does not do anything after the password prompt (the Driver does not launch). Running system76-driver-pkexec
causes the same behavior and also prints a message about not being able to open the X display. $DISPLAY is set to :0 and running xclock works as expected, confirming that Xwayland is functioning correctly.

This bug also affects the System76 Firmware Updater, but I'm not 100% sure where to report bugs for that. I'm happy to open another issue if desired.

@mrcates
Copy link

mrcates commented Jul 9, 2019

I believe I may be running into a similar issue. This may or may not be related to Wayland, but I'm posting here as I happen to be running Wayland and believe that is the only change to my knowledge before/after breakage.

Distribution: Pop!_OS 19.04

Here's console output from running sudo system76-driver:

No protocol specified
Unable to init server: Could not connect: Connection refused
No protocol specified
Unable to init server: Could not connect: Connection refused
/usr/bin/system76-driver:62: DeprecationWarning: dist() and linux_distribution() functions are deprecated in Python 3.5
  log.info('OS: %r', platform.dist())

(system76-driver:25577): Gtk-CRITICAL **: 10:58:45.119: _gtk_style_provider_private_get_settings: assertion 'GTK_IS_STYLE_PROVIDER_PRIVATE (provider)' failed

(system76-driver:25577): Gtk-CRITICAL **: 10:58:45.119: _gtk_style_provider_private_get_settings: assertion 'GTK_IS_STYLE_PROVIDER_PRIVATE (provider)' failed

(system76-driver:25577): Gtk-CRITICAL **: 10:58:45.119: _gtk_style_provider_private_get_settings: assertion 'GTK_IS_STYLE_PROVIDER_PRIVATE (provider)' failed
Segmentation fault

Here's output from running sudo system76-driver-pkexec:

No protocol specified
Unable to init server: Could not connect: Connection refused
No protocol specified
Unable to init server: Could not connect: Connection refused
/usr/bin/system76-driver:62: DeprecationWarning: dist() and linux_distribution() functions are deprecated in Python 3.5
  log.info('OS: %r', platform.dist())

(system76-driver:25921): Gtk-CRITICAL **: 11:03:22.711: _gtk_style_provider_private_get_settings: assertion 'GTK_IS_STYLE_PROVIDER_PRIVATE (provider)' failed

(system76-driver:25921): Gtk-CRITICAL **: 11:03:22.711: _gtk_style_provider_private_get_settings: assertion 'GTK_IS_STYLE_PROVIDER_PRIVATE (provider)' failed

(system76-driver:25921): Gtk-CRITICAL **: 11:03:22.711: _gtk_style_provider_private_get_settings: assertion 'GTK_IS_STYLE_PROVIDER_PRIVATE (provider)' failed
Segmentation fault (core dumped)

@jacksondm33
Copy link

I have the same issue when running system76-driver (gui) on wayland. This is caused by the fact it has to have certain privileges and requires you to run it as root. Running gtk applications as root does not work in wayland though, but if you are using XWayland you can run this to temporarily fix the issue: xhost si:localuser:root. System76-driver-pkexec uses Polkit to work around this issue and does not need to be run as root. However, for me, it gives an error.

@ids1024
Copy link
Member

ids1024 commented Nov 12, 2020

System76-driver-pkexec uses Polkit to work around this issue and does not need to be run as root.

That's just a script that runs it with pkexec, which is basically a Polkit based sudo alternative. So I think that would have the same issue.

Perhaps system76-driver-pkexec should also set an env var to force gtk to use the X backend. But the correct solution would be to have the parts that require root run as a separate process in some way, which is more complicated.

@ids1024
Copy link
Member

ids1024 commented Nov 12, 2020

Hm, seems to start as root for me on Pop!_OS 20.10, in a Pop Wayland session. Uses XWayland, it seems. I guess the latest version of GTK automatically falls back to X when run as root?

@jacksondm33
Copy link

@ids1024 It would be nice to avoid running it as root at all. I didn't know much about how polkit works, but it seems like it still runs the application as root. If so, this wouldn't solve the issue, like you said.
Since I don't use XWayland, I haven't been able to run the driver gui. Optimally, the gui should have the same functionality as the cli, but I don't know if that's the case. If it does, root privileges could be isolated to being used only when running subprocesses of the cli. However, I'm assuming that the gui doesn't use the cli to operate, so this wouldn't work without a major rewrite. Either way, though, the best idea would be to modify the code to only use privileges on the subprocesses that require them. This would mean having to create a subprocess for writing to files that require root privileges since python doesn't implement any methods of doing so (without being run as root itself).

@ids1024
Copy link
Member

ids1024 commented Nov 13, 2020

Right. The GUI should probably be modified to spawn a subprocess running the CLI as root without being root itself. But probably not non-trivial to change.

I would definitely recommend using XWayland if you want to run Wayland, since there are still occasional things that don't work natively under Wayland (annoyingly Gimp still relies on Gtk 2, though I believe the git master branch at least is Gtk 3 now...) But I can understand wanting to not use it.

@jacksondm33
Copy link

@ids1024 Yeah, it wouldn't be simple to change, but it probably should be something worked on. I'm fine with the cli, but I really don't even know if it's necessary on the oryp6. The only "fix" it provides is some nvidia i2c module blacklist which causes nouveau not to work at all. Nouveau's support is already very limited for the RTX 2060, and I can't even use it without getting rather scary kernel general protection faults (which hopefully is not a hardware issue). Proprietary drivers aren't even an option since I use sway and nvidia decides to not use established standards.

This is a little off-topic, but yeah, I have used XWayland before, and it is useful. However, I decided not to use it since most of my applications use gtk or qt which both have native wayland support. I did have an issue with emacs, but I found a well-maintained fork that runs purely on gtk.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants