In Fedora 25 there have been many improvements regarding dual graphics support and they recently added an option to Gnome to launch the application using a dicrete graphics card, by just overriding DRI_PRIME environment variable, see http://www.hadess.net/2016/10/dual-gpu-integration-in-gnome.html. This option is available based on simple dbus service implemented here https://github.com/hadess/switcheroo-control/ providing just a single property whether the user has dual GPU. This dbus thingie is enabled in Fedora 25 by default. This patch tries to add this option the same way as Gnome does. I'm just not sure about using qputenv(), but I couldn't find a better way as using QProcess, which allows to set environment variables, won't have that nice mouse effect of opening application, at least I think it won't.
Diff Detail
- Lint
Lint Skipped - Unit
Unit Tests Skipped
| applets/kicker/plugin/runnermatchesmodel.cpp | ||
|---|---|---|
| 169 | Please use KWindowSystem::isPlatformX11. | |
According to our bug report on this: https://bugs.kde.org/show_bug.cgi?id=371497 one also needs to restart kwin in xrender and mess about with some other things.
Have you tested this on a real dual machine? and did you have those problems?
I tested this on my laptop where I have both intel and nvidia cards and it seems to working without any issue for me. Note that in Fedora 25 here have been many improvements regarding dual graphics support so that may be the reason why it works for me. Another reason might be that I use Noveau driver and not the proprietary one.
Eh no, that seems to be just the user thinking it might make sense. Most likely the game tears down the compositor any way.
Hmm according to the bug report a compositor must be running. If that's in deed the case, then this will break with KWin's terminate compositing on game request. If the OpenGL compositor (or xrender compositor) needs to be on, then the overhead for the game will be so significant that it might destroy the benefit of running on concrete card.
This would require a 180 degree turn on KWin's "how to get game fast" approach. Our current approach is disabling compositing. We would need to significantly invest into gaming on compositing experience if we have to change that.
I'm not sure this is the right approach. If we add this to Kicker, it won't work in any of these other ways to launch an app:
- KRunner
- "Start New Instance" in the Task Manager
- The Icon applet in the panel or on the desktop
- The menu desktop containment action
- File associations
- Global shortcuts
...
We'd end up patching this in all over the place. :(
I think it would make more sense to do it a bit like this:
- A new X-KDE-* .desktop file key for "start on discrete"
- Code in KPropertiesDialog and kmenuedit to set this bit
The above write out a .desktop file in $HOME shadowing the system one; it's how you e.g. also change an app's icon on the system to a custom one.
Closing this review, there are new ones made into kio, kservice and kinit submitted to reviewboard.