Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
GNOME Without Systemd
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2, 3, 4 ... 27, 28, 29  Next  
This topic is locked: you cannot edit posts or make replies.    Gentoo Forums Forum Index Unsupported Software
View previous topic :: View next topic  
Author Message
dantrell
Guru
Guru


Joined: 01 Jun 2007
Posts: 430
Location: Earth

PostPosted: Sat May 28, 2016 4:13 pm    Post subject: Reply with quote

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? :roll:

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
View user's profile Send private message
simonvanderveldt
Tux's lil' helper
Tux's lil' helper


Joined: 26 Jan 2016
Posts: 92

PostPosted: Sun May 29, 2016 6:42 pm    Post subject: Reply with quote

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
View user's profile Send private message
dantrell
Guru
Guru


Joined: 01 Jun 2007
Posts: 430
Location: Earth

PostPosted: Sun May 29, 2016 10:31 pm    Post subject: Reply with quote

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
View user's profile Send private message
Sakaki
Apprentice
Apprentice


Joined: 21 May 2014
Posts: 219

PostPosted: Sun Jun 05, 2016 9:54 am    Post subject: Reply with quote

+1; the revised behaviour seems sane to me.
_________________
Regards,

sakaki
Back to top
View user's profile Send private message
dantrell
Guru
Guru


Joined: 01 Jun 2007
Posts: 430
Location: Earth

PostPosted: Wed Jun 08, 2016 8:13 am    Post subject: Reply with quote

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
View user's profile Send private message
Shibotto
n00b
n00b


Joined: 19 Jun 2015
Posts: 70
Location: Italy

PostPosted: Wed Jun 08, 2016 9:44 am    Post subject: Reply with quote

Thank you, the corrupted background after resume from suspend is gone and I don't see any side effect :D

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 :D

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
View user's profile Send private message
dantrell
Guru
Guru


Joined: 01 Jun 2007
Posts: 430
Location: Earth

PostPosted: Wed Jun 08, 2016 4:47 pm    Post subject: Reply with quote

Shibotto wrote:
Thank you, the corrupted background after resume from suspend is gone and I don't see any side effect :D

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 :D

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
View user's profile Send private message
qu1j0t3
n00b
n00b


Joined: 02 Oct 2005
Posts: 24

PostPosted: Mon Jun 20, 2016 3:11 pm    Post subject: Reply with quote

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
View user's profile Send private message
dantrell
Guru
Guru


Joined: 01 Jun 2007
Posts: 430
Location: Earth

PostPosted: Mon Jun 20, 2016 6:22 pm    Post subject: Reply with quote

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 :wink:).

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
View user's profile Send private message
qu1j0t3
n00b
n00b


Joined: 02 Oct 2005
Posts: 24

PostPosted: Mon Jun 20, 2016 6:28 pm    Post subject: Reply with quote

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
View user's profile Send private message
qu1j0t3
n00b
n00b


Joined: 02 Oct 2005
Posts: 24

PostPosted: Mon Jun 20, 2016 9:10 pm    Post subject: Reply with quote

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
View user's profile Send private message
dantrell
Guru
Guru


Joined: 01 Jun 2007
Posts: 430
Location: Earth

PostPosted: Mon Jun 20, 2016 11:13 pm    Post subject: Reply with quote

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
View user's profile Send private message
qu1j0t3
n00b
n00b


Joined: 02 Oct 2005
Posts: 24

PostPosted: Mon Jun 20, 2016 11:54 pm    Post subject: Reply with quote

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
View user's profile Send private message
dantrell
Guru
Guru


Joined: 01 Jun 2007
Posts: 430
Location: Earth

PostPosted: Tue Jun 21, 2016 12:43 am    Post subject: Reply with quote

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
View user's profile Send private message
qu1j0t3
n00b
n00b


Joined: 02 Oct 2005
Posts: 24

PostPosted: Tue Jun 21, 2016 1:43 am    Post subject: Reply with quote

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
View user's profile Send private message
dantrell
Guru
Guru


Joined: 01 Jun 2007
Posts: 430
Location: Earth

PostPosted: Tue Jun 21, 2016 2:11 am    Post subject: Reply with quote

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
View user's profile Send private message
qu1j0t3
n00b
n00b


Joined: 02 Oct 2005
Posts: 24

PostPosted: Mon Jun 27, 2016 2:49 am    Post subject: Reply with quote

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
View user's profile Send private message
dantrell
Guru
Guru


Joined: 01 Jun 2007
Posts: 430
Location: Earth

PostPosted: Sat Jul 02, 2016 1:45 am    Post subject: Reply with quote

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
View user's profile Send private message
qu1j0t3
n00b
n00b


Joined: 02 Oct 2005
Posts: 24

PostPosted: Sat Jul 02, 2016 2:24 am    Post subject: Reply with quote

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
View user's profile Send private message
dantrell
Guru
Guru


Joined: 01 Jun 2007
Posts: 430
Location: Earth

PostPosted: Sat Jul 02, 2016 3:18 am    Post subject: Reply with quote

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:

Code:
eix udev

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
View user's profile Send private message
qu1j0t3
n00b
n00b


Joined: 02 Oct 2005
Posts: 24

PostPosted: Mon Jul 04, 2016 3:08 am    Post subject: Reply with quote

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
View user's profile Send private message
qu1j0t3
n00b
n00b


Joined: 02 Oct 2005
Posts: 24

PostPosted: Mon Jul 04, 2016 7:21 pm    Post subject: Reply with quote

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
View user's profile Send private message
dantrell
Guru
Guru


Joined: 01 Jun 2007
Posts: 430
Location: Earth

PostPosted: Mon Jul 04, 2016 8:39 pm    Post subject: Reply with quote

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
View user's profile Send private message
qu1j0t3
n00b
n00b


Joined: 02 Oct 2005
Posts: 24

PostPosted: Mon Jul 04, 2016 8:47 pm    Post subject: Reply with quote

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
View user's profile Send private message
dantrell
Guru
Guru


Joined: 01 Jun 2007
Posts: 430
Location: Earth

PostPosted: Mon Jul 04, 2016 9:22 pm    Post subject: Reply with quote

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
View user's profile Send private message
Display posts from previous:   
This topic is locked: you cannot edit posts or make replies.    Gentoo Forums Forum Index Unsupported Software All times are GMT
Goto page Previous  1, 2, 3, 4 ... 27, 28, 29  Next
Page 3 of 29

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum