| View previous topic :: View next topic |
| Author |
Message |
dantrell
l33t
Joined: 01 Jun 2007
Posts: 915
Location: Earth
|
 Posted: Sat May 28, 2016 4:13 pm Post subject: |
 |
|
| simonvanderveldt wrote: | | dantrell wrote: | | After some investigation, I found Unix & Linux Stack Exchange question #272005 (Change GDM display timeout) which led me to Gnome bug #710904 (Gnome screen turns off display after lock). |
That bug  2.5 years old, 80+ responses and no fix, sometimes one has to wonder what's going on in the GNOME camp. |
Yeah, what else is new? 
| simonvanderveldt wrote: | Maybe the dimming isn't necessary/could be disabled? Does it just show the screen but with less brightness?
Using the Blank screen time as the delay to blank the screen sounds like a nice improvement. |
To clarify, I was using the terminology I found in the code:
- blanking the screen = turning the display off
- dimming the screen = fading to black (although, the actual dimming could be laptop-specific)
After some more experimental changes, both the blanking and dimming effects are disabled. Assuming default values for "Blank Screen" and the subsequent "Lock Delay" here's how the behavior would work:
- on boot = screen turns off after 5 minutes
- on manual lock = screen turns off after 5 minutes
- on idle = screen turns off after 5 minute then immediately locks
Although, according to comments on that bug, it seems there might be a preference for the final behavior to be:
- on idle = screen locks after 5 minute then turns off after an additional 5 minutes
I'll be experimenting with utilizing the Blank Screen as the delay while I wait for feedback.
_________________
Dantrell B. |
|
| Back to top |
|
 |
simonvanderveldt
Apprentice
Joined: 26 Jan 2016
Posts: 151
|
| Posted: Sun May 29, 2016 6:42 pm Post subject: |
|
|
| dantrell wrote: | After some more experimental changes, both the blanking and dimming effects are disabled. Assuming default values for "Blank Screen" and the subsequent "Lock Delay" here's how the behavior would work:
- on boot = screen turns off after 5 minutes
- on manual lock = screen turns off after 5 minutes
- on idle = screen turns off after 5 minute then immediately locks
Although, according to comments on that bug, it seems there might be a preference for the final behavior to be:
- on idle = screen locks after 5 minute then turns off after an additional 5 minutes
|
Thanks for the clarification. This is pretty much how I'd expect it to work, personally I don't expect/need a separate delay for turning of the display if the screen was locked because of the idle timeout. |
|
| Back to top |
|
|
dantrell
l33t
Joined: 01 Jun 2007
Posts: 915
Location: Earth
|
| Posted: Sun May 29, 2016 10:31 pm Post subject: |
|
|
| simonvanderveldt wrote: | | This is pretty much how I'd expect it to work, personally I don't expect/need a separate delay for turning of the display if the screen was locked because of the idle timeout. |
After looping in the "Blank Screen" time and minimizing the code, here's the current behavior with the default values:
- on boot = screen turns off after 5 minutes
- on manual lock = screen turns off after 5 minutes
- on idle = screen:
(1) fades to black after 5 minute then immediately locks; and
(2) turns off after an additional 5 minutes
I'm pretty satisfied with this result.
_________________
Dantrell B. |
|
| Back to top |
|
|
Sakaki
Guru
Joined: 21 May 2014
Posts: 409
|
| Posted: Sun Jun 05, 2016 9:54 am Post subject: |
|
|
+1; the revised behaviour seems sane to me.
_________________
Regards,
sakaki |
|
| Back to top |
|
|
dantrell
l33t
Joined: 01 Jun 2007
Posts: 915
Location: Earth
|
| Posted: Wed Jun 08, 2016 8:13 am Post subject: |
|
|
While dealing with the screen blanking issue, I took the time to go over all the available Quality of Life Improvements (and threw in some new ones while I was at it). After some stress testing, these patches are now live and GNOME 3.20 has achieved a "Gold" grading.
Almost all of the QoL improvements are now on by default with the most visibly noticeable ones being the: (1) reordering of the context menu; and (2) adjustment of the icon grid and text width proportions in Nautilus (the latter of which is currently a WIP). You can view the details at the link above. If there are any objections to this default, let me know and I will most likely implement more fine grained USE flags.
As always, feedback is appreciated. 
_________________
Dantrell B. |
|
| Back to top |
|
|
Shibotto
Apprentice
Joined: 19 Jun 2015
Posts: 156
Location: CET/CEST
|
| Posted: Wed Jun 08, 2016 9:44 am Post subject: |
|
|
Thank you, the corrupted background after resume from suspend is gone and I don't see any side effect 
Concerning screen blanking:
| dantrell wrote: |
After looping in the "Blank Screen" time and minimizing the code, here's the current behavior with the default values:
- on boot = screen turns off after 5 minutes
- on manual lock = screen turns off after 5 minutes
- on idle = screen:
(1) fades to black after 5 minute then immediately locks; and
(2) turns off after an additional 5 minutes
I'm pretty satisfied with this result. |
on boot it doesn't seem to work for me as it blanks (not dims) and "locks" just like before. However the patched behavior works for manual lock. I didn't test the last one because I don't use lock on idle. Seeing this results, I think the incorrect behavior on boot is caused by something different than timeout, maybe something is triggering a "Hey! The lid is closed! Just shut the screen off already!"-like signal.
Humble personal opinion corner
I'll be unpopular, but I don't like this change very much. I agree with the GNOME devs idea (and it might very well be their only idea I agree with) that it is pointless keeping the screen on when you are clearly not interested in looking at it. Usually if I want to keep track of the time I fullscreen a tmux clock session. Luckily we are using a source-based distro, so everyone can be happy with just a USE flag change
Sorry if it took (and most likely will take) me some time to reply and thank you again for your great work! |
|
| Back to top |
|
|
dantrell
l33t
Joined: 01 Jun 2007
Posts: 915
Location: Earth
|
| Posted: Wed Jun 08, 2016 4:47 pm Post subject: |
|
|
| Shibotto wrote: | | Thank you, the corrupted background after resume from suspend is gone and I don't see any side effect |
Thanks for verifying.
| Shibotto wrote: | | Concerning screen blanking [...] on boot it doesn't seem to work for me as it blanks (not dims) and "locks" just like before. However the patched behavior works for manual lock. I didn't test the last one because I don't use lock on idle. Seeing this results, I think the incorrect behavior on boot is caused by something different than timeout, maybe something is triggering a "Hey! The lid is closed! Just shut the screen off already!"-like signal. |
Things work as expected on desktops so this issue seems laptop-specific. Double checking the relevant code sections showed nothing obvious and at first glance, the lid close action should only trigger if the lid is actually closed. Unfortunately, I don't have a device to test it out on so narrowing this down might be a bit slow going.
Just to clarify, after you restart xdm (which triggers the "on boot" scenario) the display does what you showed in the video?
| Shibotto wrote: | | I'll be unpopular, but I don't like this change very much. I agree with the GNOME devs idea (and it might very well be their only idea I agree with) that it is pointless keeping the screen on when you are clearly not interested in looking at it. Usually if I want to keep track of the time I fullscreen a tmux clock session. Luckily we are using a source-based distro, so everyone can be happy with just a USE flag change |
No problem, I can take critique. My rationale is that the Screen Blank delay is the idle time before the screen should turn off. On boot, that counter should start from when the login prompt displays. On manual lock, that counter should start from when the lock screen displays. On idle, that counter should start when you do nothing. The screen should turn off after that idle period is complete because that's what it's for (although, for on idle, I went with the implementation that suited the existing codebase).
It seems what you are saying is it should work like this:
- on boot = screen turns off after 5 minutes
- on manual lock = screen turns off then immediately locks
- on idle = screen fades to black and/or turns off after 5 minutes then immediately locks
Such changes are doable but more complex. If done, it would have to wait for the next round of updates and would be offered as an alternative patch that is off by default.
_________________
Dantrell B. |
|
| Back to top |
|
|
qu1j0t3
n00b
Joined: 02 Oct 2005
Posts: 24
|
| Posted: Mon Jun 20, 2016 3:11 pm Post subject: |
|
|
Hi dantrell!
Thanks for your work putting together the overlay.
I'm having a build problem w/ 3.16 (some details below; required version of gtkmm isn't available). Is it worth trying to debug this, or should I move to a different version?
| Code: |
# layman -l
* dantrell-gnome [Git ] (git://github.com/dantrell/gentoo-overlay-dantrell-gnome.git )
* dantrell-gnome-3-16 [Git ] (git://github.com/dantrell/gentoo-overlay-dantrell-gnome-3-16.git )
|
| Code: |
# emerge -av pangomm
...
Calculating dependencies... done!
[ebuild N ] dev-cpp/pangomm-2.40.0:1.4::dantrell-gnome USE="-doc" 0 KiB
[uninstall ] dev-cpp/gtkmm-2.8.1:2.4::__unknown__ USE="-debug"
[blocks b ] <dev-cpp/gtkmm-2.13:2.4 ("<dev-cpp/gtkmm-2.13:2.4" is blocking dev-cpp/pangomm-2.40.0)
Total: 1 package (1 new, 1 uninstall), Size of downloads: 0 KiB
Conflict: 1 block
...
Would you like to merge these packages? [Yes/No] y
>>> Verifying ebuild manifests
>>> Emerging (1 of 1) dev-cpp/pangomm-2.40.0::dantrell-gnome
* pangomm-2.40.0.tar.xz SHA256 SHA512 WHIRLPOOL size ;-) ... [ ok ]
>>> cfg-update-1.8.2-r1: Skipping checksum index updating...
>>> Unpacking source...
>>> Unpacking pangomm-2.40.0.tar.xz to /var/tmp/portage/dev-cpp/pangomm-2.40.0/work
>>> Source unpacked in /var/tmp/portage/dev-cpp/pangomm-2.40.0/work
>>> Preparing source in /var/tmp/portage/dev-cpp/pangomm-2.40.0/work/pangomm-2.40.0 ...
* Fixing OMF Makefiles ... [ ok ]
* Disabling deprecation warnings ... [ ok ]
* Running elibtoolize in: pangomm-2.40.0/
* Applying target-nm/2.4.2 patch ...
* Running elibtoolize in: pangomm-2.40.0/build/
* Applying portage/1.2.0 patch ...
* Applying sed/1.5.6 patch ...
* Applying as-needed/2.4.2 patch ...
>>> Source prepared.
>>> Configuring source in /var/tmp/portage/dev-cpp/pangomm-2.40.0/work/pangomm-2.40.0 ...
* abi_x86_32.x86: running multilib-minimal_abi_src_configure
* econf: updating pangomm-2.40.0/build/config.guess with /usr/share/gnuconfig/config.guess
* econf: updating pangomm-2.40.0/build/config.sub with /usr/share/gnuconfig/config.sub
/var/tmp/portage/dev-cpp/pangomm-2.40.0/work/pangomm-2.40.0/configure --prefix=/usr --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --disable-dependency-tracking --disable-silent-rules --libdir=/usr/lib --docdir=/usr/share/doc/pangomm-2.40.0 --disable-documentation
checking for a BSD-compatible install... /usr/lib/portage/python2.7/ebuild-helpers/xattr/install -c
checking whether build environment is sane... yes
...
checking for PANGOMM... no
configure: error: Package requirements (glibmm-2.4 >= 2.48.0 cairomm-1.0 >= 1.2.2 pangocairo >= 1.38.0) were not met:
Requested 'glibmm-2.4 >= 2.48.0' but version of glibmm is 2.46.4
You may find new versions of glibmm at http://www.gtkmm.org/
Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.
Alternatively, you may set the environment variables PANGOMM_CFLAGS
and PANGOMM_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.
!!! Please attach the following file when seeking support:
!!! /var/tmp/portage/dev-cpp/pangomm-2.40.0/work/pangomm-2.40.0-abi_x86_32.x86/config.log
* ERROR: dev-cpp/pangomm-2.40.0::dantrell-gnome failed (configure phase):
* econf failed
* ...
|
Last edited by qu1j0t3 on Sat Jun 25, 2016 4:06 pm; edited 1 time in total |
|
| Back to top |
|
|
dantrell
l33t
Joined: 01 Jun 2007
Posts: 915
Location: Earth
|
| Posted: Mon Jun 20, 2016 6:22 pm Post subject: |
|
|
| qu1j0t3 wrote: | | I'm having a build problem w/ 3.16 (some details below; required version of gtkmm isn't available). Is it worth trying to debug this, or should I move to a different version |
Changing GNOME release versions isn't necessary (I'm still on 3.14 myself  ).
Your problem is that you are either not using one of the bundled profiles or that you are overriding it.
The solution is to use one of the bundled profiles as it enforces compatibility. If you have a reason not to do so then you need to at least copy or adapt the relevant package.mask file.
For details, see Profile Selection.
_________________
Dantrell B. |
|
| Back to top |
|
|
qu1j0t3
n00b
Joined: 02 Oct 2005
Posts: 24
|
| Posted: Mon Jun 20, 2016 6:28 pm Post subject: |
|
|
Yes this is a somewhat stale system and I have not addressed profile change. I'll look into this.
Thanks for the pointer! |
|
| Back to top |
|
|
qu1j0t3
n00b
Joined: 02 Oct 2005
Posts: 24
|
| Posted: Mon Jun 20, 2016 9:10 pm Post subject: |
|
|
Switched profile:
| Code: |
# eselect profile list
Available profile symlink targets:
[1] default/linux/x86/13.0
[2] default/linux/x86/13.0/selinux
[3] default/linux/x86/13.0/desktop
[4] default/linux/x86/13.0/desktop/gnome
[5] default/linux/x86/13.0/desktop/gnome/systemd
[6] default/linux/x86/13.0/desktop/kde
[7] default/linux/x86/13.0/desktop/kde/systemd
[8] default/linux/x86/13.0/desktop/plasma
[9] default/linux/x86/13.0/desktop/plasma/systemd
[10] default/linux/x86/13.0/developer
[11] default/linux/x86/13.0/systemd
[12] hardened/linux/x86
[13] hardened/linux/x86/selinux
[14] hardened/linux/musl/x86
[15] default/linux/uclibc/x86
[16] hardened/linux/uclibc/x86
[17] dantrell-gnome:default/x86/3.14
[18] dantrell-gnome:default/x86/3.14/extended
[19] dantrell-gnome:default/x86/3.16 *
[20] dantrell-gnome:default/x86/3.16/extended
[21] dantrell-gnome:default/x86/3.18
[22] dantrell-gnome:default/x86/3.18/extended
[23] dantrell-gnome:default/x86/3.20
[24] dantrell-gnome:default/x86/3.20/extended
|
New obstacle: Major compilation explosion in cairomm:
| Code: |
libtool: compile: i686-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I.. -I/var/tmp/portage/dev-cpp/cairomm-1.10.0-r1/work/cairomm-1.10.0 -I. -I/usr/include/sigc++-2.0 -I/usr/lib/sigc++-2.0/include -I/usr/include/cairo -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libdrm -I/usr/include/libpng16 -Wall -O3 -march=pentium4 -pipe -fomit-frame-pointer -c /var/tmp/portage/dev-cpp/cairomm-1.10.0-r1/work/cairomm-1.10.0/cairomm/context_surface_quartz.cc -fPIC -DPIC -o .libs/context_surface_quartz.o
In file included from /usr/include/sigc++-2.0/sigc++/functors/slot.h:5:0,
from /usr/include/sigc++-2.0/sigc++/slot.h:19,
from /var/tmp/portage/dev-cpp/cairomm-1.10.0-r1/work/cairomm-1.10.0/cairomm/surface.h:33,
from /var/tmp/portage/dev-cpp/cairomm-1.10.0-r1/work/cairomm-1.10.0/cairomm/context_private.h:23,
from /var/tmp/portage/dev-cpp/cairomm-1.10.0-r1/work/cairomm-1.10.0/cairomm/context_surface_xlib.cc:20:
/usr/include/sigc++-2.0/sigc++/trackable.h:40:3: warning: identifier ‘noexcept’ is a keyword in C++11 [-Wc++0x-compat]
trackable_callback(void* data, func_destroy_notify func) noexcept
^
In file included from /usr/include/sigc++-2.0/sigc++/functors/slot.h:5:0,
from /usr/include/sigc++-2.0/sigc++/slot.h:19,
from /var/tmp/portage/dev-cpp/cairomm-1.10.0-r1/work/cairomm-1.10.0/cairomm/surface.h:33,
from /var/tmp/portage/dev-cpp/cairomm-1.10.0-r1/work/cairomm-1.10.0/cairomm/context_private.h:23,
from /var/tmp/portage/dev-cpp/cairomm-1.10.0-r1/work/cairomm-1.10.0/cairomm/context_surface_win32.cc:20:
/usr/include/sigc++-2.0/sigc++/trackable.h:40:3: warning: identifier ‘noexcept’ is a keyword in C++11 [-Wc++0x-compat]
trackable_callback(void* data, func_destroy_notify func) noexcept
^
In file included from /usr/lib/gcc/i686-pc-linux-gnu/4.9.3/include/g++-v4/type_traits:35:0,
from /usr/include/sigc++-2.0/sigc++/visit_each.h:22,
from /usr/include/sigc++-2.0/sigc++/functors/slot.h:6,
from /usr/include/sigc++-2.0/sigc++/slot.h:19,
from /var/tmp/portage/dev-cpp/cairomm-1.10.0-r1/work/cairomm-1.10.0/cairomm/surface.h:33,
from /var/tmp/portage/dev-cpp/cairomm-1.10.0-r1/work/cairomm-1.10.0/cairomm/context_private.h:23,
from /var/tmp/portage/dev-cpp/cairomm-1.10.0-r1/work/cairomm-1.10.0/cairomm/context_surface_win32.cc:20:
/usr/lib/gcc/i686-pc-linux-gnu/4.9.3/include/g++-v4/bits/c++0x_warning.h:32:2: error: #error This file requires compiler and library support for the ISO C++ 2011 standard. This support is currently experimental, and must be enabled with the -std=c++11 or -std=gnu++11 compiler options.
#error This file requires compiler and library support for the \
^
|
Does this mean a USE flag is missing on gcc perhaps?
Last edited by qu1j0t3 on Mon Jun 20, 2016 11:49 pm; edited 1 time in total |
|
| Back to top |
|
|
dantrell
l33t
Joined: 01 Jun 2007
Posts: 915
Location: Earth
|
| Posted: Mon Jun 20, 2016 11:13 pm Post subject: |
|
|
| qu1j0t3 wrote: | New obstacle: Major complication explosion in cairomm:
[...]
Does this mean a USE flag is missing on gcc perhaps? |
It's because you were initially building packages without using one of the bundled profiles so >dev-libs/libsigc++-2.4.1 (which isn't default in the overlays yet) slipped in. To resolve, downgrade libsigc++ first:
| Code: | | emerge -a1 --nodeps libsigc++ |
Then rebuild related dependencies (omitting any package isn't coded as "R"):
| Code: | | emerge -a1 --nodeps atkmm cairomm glibmm gtkmm gtksourceviewmm pangomm |
_________________
Dantrell B. |
|
| Back to top |
|
|
qu1j0t3
n00b
Joined: 02 Oct 2005
Posts: 24
|
| Posted: Mon Jun 20, 2016 11:54 pm Post subject: |
|
|
Thanks! Unfortunately this blows up in a similar way on the 2nd step (building dev-cpp/atkmm-2.22.7-r1):
| Code: |
In file included from /usr/lib/gcc/i686-pc-linux-gnu/4.9.3/include/g++-v4/type_traits:35:0,
from /usr/include/glibmm-2.4/glibmm/weakref.h:23,
from /usr/include/glibmm-2.4/glibmm.h:153,
from /var/tmp/portage/dev-cpp/atkmm-2.22.7-r1/work/atkmm-2.22.7/atk/atkmm/component.cc:4:
/usr/lib/gcc/i686-pc-linux-gnu/4.9.3/include/g++-v4/bits/c++0x_warning.h:32:2: error: #error This file requires compiler and library support for the ISO C++ 2011 standard. This support is currently experimental, and must be enabled with the -std=c++11 or -std=gnu++11 compiler options.
#error This file requires compiler and library support for the \
^
|
|
|
| Back to top |
|
|
dantrell
l33t
Joined: 01 Jun 2007
Posts: 915
Location: Earth
|
| Posted: Tue Jun 21, 2016 12:43 am Post subject: |
|
|
| qu1j0t3 wrote: | | Unfortunately this blows up in a similar way on the 2nd step (building dev-cpp/atkmm-2.22.7-r1) |
Rebuild glibmm before the other related dependencies:
| Code: | | emerge -a1 --nodeps glibmm |
_________________
Dantrell B. |
|
| Back to top |
|
|
qu1j0t3
n00b
Joined: 02 Oct 2005
Posts: 24
|
| Posted: Tue Jun 21, 2016 1:43 am Post subject: |
|
|
This seems to lead to a Catch-22 like situation:
| Code: |
Requested 'sigc++-2.0 >= 2.6.0' but version of libsigc++ is 2.4.1
|
Would it be of any help to literally rebuild gcc/g++ with "support for the ISO C++ 2011 standard … enabled with the -std=c++11 or -st
d=gnu++11 compiler options" ? |
|
| Back to top |
|
|
dantrell
l33t
Joined: 01 Jun 2007
Posts: 915
Location: Earth
|
| Posted: Tue Jun 21, 2016 2:11 am Post subject: |
|
|
| qu1j0t3 wrote: | | This seems to lead to a Catch-22 like situation |
I think you should prioritize fixing your integration with the overlays.
GNOME 3.16 pulls in dev-cpp/glibmm-2.44.0 which has >=dev-libs/libsigc++-2.3.2 as a dependency (see the line 65 in the sources for details).
You can force it with:
| Code: | | emerge -a1 --nodeps =glibmm-2.44.0 |
but you should figure out what went wrong.
| qu1j0t3 wrote: | Would it be of any help to literally rebuild gcc/g++ with "support for the ISO C++ 2011 standard … enabled with the -std=c++11 or -st
d=gnu++11 compiler options" ? |
A rebuild of gcc won't help. Upgrading to >=5.3 would suppress the ISO C++ 2011 errors, but as-is you would still get similar build failures, it just won't complain about that particular error. You need a properly built libsigc++ and *mm to begin with.
_________________
Dantrell B. |
|
| Back to top |
|
|
qu1j0t3
n00b
Joined: 02 Oct 2005
Posts: 24
|
| Posted: Mon Jun 27, 2016 2:49 am Post subject: |
|
|
Hi Dantrell
Thanks again. With your precise suggestion to downgrade gtkmm, I got a complete build of webkit-gtk-2.12.3 merged.
I still do not know exactly why I had newer packages than the overlay, but it was probably just an earlier out-of-sync somewhere.
Now to merge the rest... |
|
| Back to top |
|
|
dantrell
l33t
Joined: 01 Jun 2007
Posts: 915
Location: Earth
|
| Posted: Sat Jul 02, 2016 1:45 am Post subject: |
|
|
| qu1j0t3 wrote: | | Now to merge the rest... |
You know, I could have sworn you posted asked about a dev-libs/libgudev + sys-fs/eudev blocker. I was preoccupied at the time, otherwise I would have told you that it wasn't an overlay specific issue.
I guess you managed to resolve it on your own and have the overlays working?
_________________
Dantrell B. |
|
| Back to top |
|
|
qu1j0t3
n00b
Joined: 02 Oct 2005
Posts: 24
|
| Posted: Sat Jul 02, 2016 2:24 am Post subject: |
|
|
| dantrell wrote: | | qu1j0t3 wrote: | | Now to merge the rest... |
You know, I could have sworn you posted asked about a dev-libs/libgudev + sys-fs/eudev blocker. I was preoccupied at the time, otherwise I would have told you that it wasn't an overlay specific issue.
I guess you managed to resolve it on your own and have the overlays working? |
It did get resolved, somehow. I think I unmerge'd all udev related packages (udev, libgudev, approximately) then emerge'd eudev and the blocker went away.
However, I see that the blocker reappears when I attempt a world update. Basically I don't know how to permanently resolve it and googling didn't help.
I have some other technical issues with Gnome as well. It's very sluggish, and the machine doesn't actually restart if I use the upper right control. These are all new problems that I didn't have with the much older Gnome I was running before. |
|
| Back to top |
|
|
dantrell
l33t
Joined: 01 Jun 2007
Posts: 915
Location: Earth
|
| Posted: Sat Jul 02, 2016 3:18 am Post subject: |
|
|
| qu1j0t3 wrote: | It did get resolved, somehow. I think I unmerge'd all udev related packages (udev, libgudev, approximately) then emerge'd eudev and the blocker went away.
However, I see that the blocker reappears when I attempt a world update. Basically I don't know how to permanently resolve it and googling didn't help. |
Do you have virtual/udev installed as well?
| Code: | | emerge -a1 virtual/udev |
If that dosn't do it then share the results of:
| Code: | | emerge --search udev |
or:
| qu1j0t3 wrote: | | I have some other technical issues with Gnome as well. It's very sluggish, and the machine doesn't actually restart if I use the upper right control. These are all new problems that I didn't have with the much older Gnome I was running before. |
You'll have to elaborate on these issues. Sluggish in what way (and have you monitored your resource usage)?
As for the upper right dropdown menu, you are saying the power icon does nothing? It doesn't display a prompt or anything? Because that's starting to sound polkit-related. Is the dbus service enabled?
_________________
Dantrell B. |
|
| Back to top |
|
|
qu1j0t3
n00b
Joined: 02 Oct 2005
Posts: 24
|
| Posted: Mon Jul 04, 2016 3:08 am Post subject: |
|
|
Talking about the performance issue first of all - the symptoms are simple - basically a 2 second lag on any event. Also, dragging a window refreshes its position about once every 2 seconds.
I also notice that the X process is consuming exactly 28% CPU… constantly. This seems perhaps related?
It would be nice to resolve that before anything else. |
|
| Back to top |
|
|
qu1j0t3
n00b
Joined: 02 Oct 2005
Posts: 24
|
| Posted: Mon Jul 04, 2016 7:21 pm Post subject: |
|
|
Re udev, yes, virtual/udev is installed:
| Code: |
deepthought linux # equery list udev
[ Searching for package 'udev' in all categories among: ]
* installed packages
[I--] [ ] dev-libs/libgudev-230 (0/0)
[I--] [ ] sys-fs/eudev-3.1.5 (0)
[I--] [ ] sys-fs/udev-init-scripts-27 (0)
[I--] [ ] virtual/libgudev-230 (0/0)
[I--] [ ] virtual/libudev-215-r1 (0/1)
[I--] [ ] virtual/udev-215 (0)
deepthought linux # emerge --search udev
[ Results for search key : udev ]
Searching...
* app-text/uudeview
Latest version available: 0.5.20-r1
Latest version installed: [ Not Installed ]
Size of files: 256 KiB
Homepage: http://www.fpx.de/fp/Software/UUDeview/
Description: uu, xx, base64, binhex decoder
License: GPL-2
* app-vim/udev-syntax
Latest version available: 20051016-r1
Latest version installed: [ Not Installed ]
Size of files: 2 KiB
Homepage: http://www.vim.org/scripts/script.php?script_id=1381
Description: vim plugin: syntax highlighting for udev rules files
License: vim
* dev-dotnet/gudev-sharp
Latest version available: 0.1
Latest version installed: [ Not Installed ]
Size of files: 101 KiB
Homepage: https://launchpad.net/gudev-sharp
Description: GUDEV API C# binding
License: LGPL-2.1
* dev-libs/libgudev
Latest version available: 230
Latest version installed: 230
Size of files: 252 KiB
Homepage: https://wiki.gnome.org/Projects/libgudev
Description: GObject bindings for libudev
License: LGPL-2.1
* dev-python/python-gudev
Latest version available: 147.2-r1
Latest version installed: [ Not Installed ]
Size of files: 10 KiB
Homepage: https://github.com/nzjrs/python-gudev
Description: Python binding to the GUDev udev helper library
License: LGPL-3
* dev-python/pyudev
Latest version available: 0.16.1-r1
Latest version installed: [ Not Installed ]
Size of files: 74 KiB
Homepage: http://pyudev.readthedocs.org https://github.com/pyudev/pyudev
Description: Python binding to libudev
License: LGPL-2.1
* sys-apps/udevil
Latest version available: 0.4.4-r1
Latest version installed: [ Not Installed ]
Size of files: 467 KiB
Homepage: https://ignorantguru.github.com/udevil/
Description: mount and unmount removable devices without a password
License: GPL-3
* sys-fs/eudev
Latest version available: 3.1.5
Latest version installed: 3.1.5
Size of files: 1,705 KiB
Homepage: https://github.com/gentoo/eudev
Description: Linux dynamic and persistent device naming support (aka userspace devfs)
License: LGPL-2.1 MIT GPL-2
* sys-fs/udev [ Masked ]
Latest version available: 9999
Latest version installed: [ Not Installed ]
Size of files: 0 KiB
Homepage: https://www.freedesktop.org/wiki/Software/systemd
Description: Linux dynamic and persistent device naming support (aka userspace devfs)
License: LGPL-2.1 MIT GPL-2
* sys-fs/udev-init-scripts
Latest version available: 27
Latest version installed: 27
Size of files: 4 KiB
Homepage: https://www.gentoo.org
Description: udev startup scripts for openrc
License: GPL-2
* sys-libs/libudev-compat [ Masked ]
Latest version available: 186
Latest version installed: [ Not Installed ]
Size of files: 0 KiB
Homepage: http://gentoo.org/
Description: Wrapper around libudev.so.1 for packages needing the old libudev.so.0
License: LGPL-2.1+
* virtual/libgudev
Latest version available: 230
Latest version installed: 230
Size of files: 0 KiB
Homepage:
Description: Virtual for libgudev providers
License:
* virtual/libudev
Latest version available: 215-r1
Latest version installed: 215-r1
Size of files: 0 KiB
Homepage:
Description: Virtual for libudev providers
License:
* virtual/udev
Latest version available: 215
Latest version installed: 215
Size of files: 0 KiB
Homepage:
Description: Virtual to select between different udev daemon providers
License:
[ Applications found : 14 ]
|
|
|
| Back to top |
|
|
dantrell
l33t
Joined: 01 Jun 2007
Posts: 915
Location: Earth
|
| Posted: Mon Jul 04, 2016 8:39 pm Post subject: |
|
|
| qu1j0t3 wrote: | Talking about the performance issue first of all - the symptoms are simple - basically a 2 second lag on any event. Also, dragging a window refreshes its position about once every 2 seconds.
I also notice that the X process is consuming exactly 28% CPU… constantly. This seems perhaps related?
It would be nice to resolve that before anything else. |
Are you saying the X process is consuming CPU when you are not moving the mouse cursor at all? If that's the case, I think you have another problem.
However, if X is using CPU when you are actually interacting with GNOME, then this is normal. GNOME 3 is much more resource heavy than GNOME 2. On recent machines there should be no noticeable lag (if hardware rendering is enabled) and while window position refreshing is something that does take place, the overall performance impact is negligible.
You can try ruling out my patchset by disabling the old background code (which is probably the only relevant patch in your use case) and restarting gnome-shell:
| Code: | gnome-base/gnome-shell -deprecated-background
x11-wm/mutter -deprecated-background |
If that doesn't make a difference, then I'd bet that it's just GNOME. If you are on 3.16, perhaps you could try 3.20?
| qu1j0t3 wrote: | | Re udev, yes, virtual/udev is installed [...] |
Comparing the results, there isn't much difference between our installs. I currently use udev but I have successfully used eudev in the past. You are probably going to have to do some more digging to find a solution.
_________________
Dantrell B. |
|
| Back to top |
|
|
qu1j0t3
n00b
Joined: 02 Oct 2005
Posts: 24
|
| Posted: Mon Jul 04, 2016 8:47 pm Post subject: |
|
|
X consumes that amount of CPU constantly, when the machine is not being touched.
The problem can't be "just GNOME"; a machine that takes 2 seconds to respond to any event is not usable. (Also see window dragging, etc.) |
|
| Back to top |
|
|
dantrell
l33t
Joined: 01 Jun 2007
Posts: 915
Location: Earth
|
| Posted: Mon Jul 04, 2016 9:22 pm Post subject: |
|
|
| qu1j0t3 wrote: | | The problem can't be "just GNOME" [...] |
I think you misread what I said. I agreed that if X is as you described, then you do have a problem.
Start ruling things out: disable the USE flag on those two packages, move away from 3.16 if you are on it (as I have heard of performance problems with it which I haven't confirmed) or try another DE.
Basically, find out if it's GNOME or not. If it's GNOME, find out if its my patchset or not. If it's not, then the only resolution, if any, is a different GNOME release version or graphics configuration.
_________________
Dantrell B. |
|
| Back to top |
|
|
|
Unsupported Software
