Re: [e-users] Desktop freeze on tooltip pop ups

2017-07-10 Thread The Rasterman 
On Mon, 10 Jul 2017 15:47:16 +0100 Mick  said:

> On Friday 30 Jun 2017 12:18:52 Mick wrote:
> > On Thursday 29 Jun 2017 07:37:46 Carsten Haitzler wrote:
> > > On Wed, 28 Jun 2017 15:06:48 +0100 Mick  said:
> > > > built mesa with debug flags and captured another crash.  Can you please
> > > > scan through the backtrace below and confirm if the verdict is still the
> > > > same and if anything mesa related in particular stands out which I enter
> > > > in a bug report?
> > > 
> > > sure. but keep in mind that just because e shows a bug doesnt mean other
> > > compositors will.
> > 
> > Yes, I tried had to make LO to crash KDE (plasma), but KDE's compositor
> > wouldn't have any of it.  No matter how much or how fast I moved the mouse
> > over the menu to cause tooltips to overlap as they popped up and
> > disappeared/reappeared, KDE continued to display them without freezing up. 
> > If I moved too fast over the tooltip generating area they just blurred a
> > bit without rendering fully their content in the milliseconds they were
> > given to render, before the mouse moved on to the next area.  Such blurring
> > would cause a freeze on evas/e.
> > 
> > Conclusion:  Plasma compositor will not cause the same crash by libdri.
> > 
> > > > https://pastebin.com/Y6SxaKGF
> > > 
> > > now to this...  it doesn't tell me more than it did before... it's a fence
> > > sync within the driver layer. it's a problem between the driver and itself
> > > across process boundaries. if you want i can explain what fences are and
> > > their purpose (in general) and why this would be the case and i can
> > > probably narrow down where the issues are being caused in the x 2d + dri
> > > driver stack... but it'll be a long explanation. i do not know the DETAILS
> > > of the fence implementations down at the dri level... but i do know what
> > > fences are, what they in general do and why this tells me the issue is not
> > > something we can solve in efl...
> > > 
> > > if you want the details - let me know. otherwise know that this is a bug
> > > you likely have to file with the dri3/mesa/xorg 2d/radeon driver
> > > people... :/
> > I thought this was a radeon driver problem.  On some further testing shows
> > this *also* occurs on Intel!  An old Acer Incorporated [ALI] Mobile 4 Series
> > Chipset (ICH9) Integrated Graphics Controller  crashed in the same manner.
> > This is using the i965 & intel flags in mesa, rather than
> > r600/radeon/radeonsi.  So it does not seem to be radeon specific.  I've
> > tried with mesa-17.0.6 which is when the problems seem to have started and
> > with mesa-17.1.3.
> > 
> > I've started with a report to Gentoo for now and will see what they advise.
> 
> Would there be a setting to disable tooltip hardware acceleration in the 
> compositor I could select, so as to continue using e without crashing?

no. it doesn't work like that. compositing is an all or nothing thing.

> I tried disabling composite effects for menus/popups but it still crashes.  
> What category of composite effects application windows' tooltips fall under?
> -- 
> Regards,
> Mick


-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-users mailing list
enlightenment-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-users

Re: [e-users] Desktop freeze on tooltip pop ups

2017-07-10 Thread Mick 
On Friday 30 Jun 2017 12:18:52 Mick wrote:
> On Thursday 29 Jun 2017 07:37:46 Carsten Haitzler wrote:
> > On Wed, 28 Jun 2017 15:06:48 +0100 Mick  said:
> > > built mesa with debug flags and captured another crash.  Can you please
> > > scan through the backtrace below and confirm if the verdict is still the
> > > same and if anything mesa related in particular stands out which I enter
> > > in a bug report?
> > 
> > sure. but keep in mind that just because e shows a bug doesnt mean other
> > compositors will.
> 
> Yes, I tried had to make LO to crash KDE (plasma), but KDE's compositor
> wouldn't have any of it.  No matter how much or how fast I moved the mouse
> over the menu to cause tooltips to overlap as they popped up and
> disappeared/reappeared, KDE continued to display them without freezing up. 
> If I moved too fast over the tooltip generating area they just blurred a
> bit without rendering fully their content in the milliseconds they were
> given to render, before the mouse moved on to the next area.  Such blurring
> would cause a freeze on evas/e.
> 
> Conclusion:  Plasma compositor will not cause the same crash by libdri.
> 
> > > https://pastebin.com/Y6SxaKGF
> > 
> > now to this...  it doesn't tell me more than it did before... it's a fence
> > sync within the driver layer. it's a problem between the driver and itself
> > across process boundaries. if you want i can explain what fences are and
> > their purpose (in general) and why this would be the case and i can
> > probably narrow down where the issues are being caused in the x 2d + dri
> > driver stack... but it'll be a long explanation. i do not know the DETAILS
> > of the fence implementations down at the dri level... but i do know what
> > fences are, what they in general do and why this tells me the issue is not
> > something we can solve in efl...
> > 
> > if you want the details - let me know. otherwise know that this is a bug
> > you likely have to file with the dri3/mesa/xorg 2d/radeon driver
> > people... :/
> I thought this was a radeon driver problem.  On some further testing shows
> this *also* occurs on Intel!  An old Acer Incorporated [ALI] Mobile 4 Series
> Chipset (ICH9) Integrated Graphics Controller  crashed in the same manner.
> This is using the i965 & intel flags in mesa, rather than
> r600/radeon/radeonsi.  So it does not seem to be radeon specific.  I've
> tried with mesa-17.0.6 which is when the problems seem to have started and
> with mesa-17.1.3.
> 
> I've started with a report to Gentoo for now and will see what they advise.

Would there be a setting to disable tooltip hardware acceleration in the 
compositor I could select, so as to continue using e without crashing?

I tried disabling composite effects for menus/popups but it still crashes.  
What category of composite effects application windows' tooltips fall under?
-- 
Regards,
Mick
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-users mailing list
enlightenment-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-users

Re: [e-users] Desktop freeze on tooltip pop ups

2017-06-30 Thread Mick 
On Thursday 29 Jun 2017 07:37:46 Carsten Haitzler wrote:
> On Wed, 28 Jun 2017 15:06:48 +0100 Mick  said:

> > built mesa with debug flags and captured another crash.  Can you please
> > scan through the backtrace below and confirm if the verdict is still the
> > same and if anything mesa related in particular stands out which I enter
> > in a bug report?
> 
> sure. but keep in mind that just because e shows a bug doesnt mean other
> compositors will. 

Yes, I tried had to make LO to crash KDE (plasma), but KDE's compositor 
wouldn't have any of it.  No matter how much or how fast I moved the mouse 
over the menu to cause tooltips to overlap as they popped up and 
disappeared/reappeared, KDE continued to display them without freezing up.  If 
I moved too fast over the tooltip generating area they just blurred a bit 
without rendering fully their content in the milliseconds they were given to 
render, before the mouse moved on to the next area.  Such blurring would cause 
a freeze on evas/e.

Conclusion:  Plasma compositor will not cause the same crash by libdri.


> > https://pastebin.com/Y6SxaKGF
> 
> now to this...  it doesn't tell me more than it did before... it's a fence
> sync within the driver layer. it's a problem between the driver and itself
> across process boundaries. if you want i can explain what fences are and
> their purpose (in general) and why this would be the case and i can
> probably narrow down where the issues are being caused in the x 2d + dri
> driver stack... but it'll be a long explanation. i do not know the DETAILS
> of the fence implementations down at the dri level... but i do know what
> fences are, what they in general do and why this tells me the issue is not
> something we can solve in efl...
> 
> if you want the details - let me know. otherwise know that this is a bug you
> likely have to file with the dri3/mesa/xorg 2d/radeon driver people... :/

I thought this was a radeon driver problem.  On some further testing shows 
this *also* occurs on Intel!  An old Acer Incorporated [ALI] Mobile 4 Series 
Chipset (ICH9) Integrated Graphics Controller  crashed in the same manner.  
This is using the i965 & intel flags in mesa, rather than 
r600/radeon/radeonsi.  So it does not seem to be radeon specific.  I've tried 
with mesa-17.0.6 which is when the problems seem to have started and with 
mesa-17.1.3.

I've started with a report to Gentoo for now and will see what they advise.  

-- 
Regards,
Mick
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-users mailing list
enlightenment-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-users

Re: [e-users] Desktop freeze on tooltip pop ups

2017-06-28 Thread The Rasterman 
On Wed, 28 Jun 2017 15:06:48 +0100 Mick  said:

> On Wednesday 28 Jun 2017 18:10:33 Carsten Haitzler wrote:
> > On Wed, 28 Jun 2017 08:52:56 +0100 Mick  said:
> 
> > > Styles: haven't changed this.
> > > Fast Effects: Enabled only fast composite effects for windows.
> > > Disable Effects: none selected.
> > > Rendering Behavior: Don't composite fullscreen windows,
> > > Engine: OpenGL,
> > > 
> > >OpenGL options:
> > >  Tear-free updates (VSynced),
> > 
> > btw... vsync/tear-free ... is a good thing to have :)
> 
> 
> Yes, I've made a note about this from you mentioning it in some previous 
> thread.  ;-)

:)

> I started a Fluxbox session and tried to cause the same crash, but failed to 
> make it happen.  Perhaps because Fluxbox does not use compositing.  Anyway,I 

yes. doesn't composite. so rendering takes a very different path (drawing from
clients never involves the windowmanager at all. just client + x).

> built mesa with debug flags and captured another crash.  Can you please scan 
> through the backtrace below and confirm if the verdict is still the same and 
> if anything mesa related in particular stands out which I enter in a bug 
> report?

sure. but keep in mind that just because e shows a bug doesnt mean other
compositors will. there will be a absolute boatload of permutations and
combinations of order, state etc. all of which are valid but only some produce
the bug. some compositors might hit it, others may not. e's rendering code will
likely be significantly more complex than 99% of compositors (if not every
single one) because it not only renders some "simple rectangles (2 triangles)
with bound glxpixmaps/eglimages" like many compositors... it renders tonnes of
detailed stuff with opengl - the titlebars are gl rendered (every letter in
them is a pair of triangles with texture coords). the titelbars themselves will
consist of many more triangles with layers and textures, as will the shadows,
the shelf content will be a whole bevvy of triangle content. where most
compositors will maybe render dozens of triangles with very large textures, e
will render 1000's of triangles with many many many texture sources etc.
actually e itself doesn't have the rendering code... evas does. it's the same
code that can be used by client apps that are written with efl to use opengl to
accelerate rendering. it's far more complex overall than most compositors. we
do this because we recycle the rendering code everywhere thanks to evas... it
makes e an immensely powerful wm/compositor inside of itself as it's fully
capable of everything client apps are directly itself... but it does mean we
put a completely different workload on the drivers etc.

> https://pastebin.com/Y6SxaKGF

now to this...  it doesn't tell me more than it did before... it's a fence sync
within the driver layer. it's a problem between the driver and itself across
process boundaries. if you want i can explain what fences are and their purpose
(in general) and why this would be the case and i can probably narrow down
where the issues are being caused in the x 2d + dri driver stack... but it'll
be a long explanation. i do not know the DETAILS of the fence implementations
down at the dri level... but i do know what fences are, what they in general do
and why this tells me the issue is not something we can solve in efl...

if you want the details - let me know. otherwise know that this is a bug you
likely have to file with the dri3/mesa/xorg 2d/radeon driver people... :/

> Thanks again.
> -- 
> Regards,
> Mick


-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-users mailing list
enlightenment-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-users

Re: [e-users] Desktop freeze on tooltip pop ups

2017-06-28 Thread Mick 
On Wednesday 28 Jun 2017 18:10:33 Carsten Haitzler wrote:
> On Wed, 28 Jun 2017 08:52:56 +0100 Mick  said:

> > Styles: haven't changed this.
> > Fast Effects: Enabled only fast composite effects for windows.
> > Disable Effects: none selected.
> > Rendering Behavior: Don't composite fullscreen windows,
> > Engine: OpenGL,
> > 
> >OpenGL options:
> >  Tear-free updates (VSynced),
> 
> btw... vsync/tear-free ... is a good thing to have :)


Yes, I've made a note about this from you mentioning it in some previous 
thread.  ;-)

I started a Fluxbox session and tried to cause the same crash, but failed to 
make it happen.  Perhaps because Fluxbox does not use compositing.  Anyway, I 
built mesa with debug flags and captured another crash.  Can you please scan 
through the backtrace below and confirm if the verdict is still the same and 
if anything mesa related in particular stands out which I enter in a bug 
report?

https://pastebin.com/Y6SxaKGF

Thanks again.
-- 
Regards,
Mick
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-users mailing list
enlightenment-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-users

Re: [e-users] Desktop freeze on tooltip pop ups

2017-06-28 Thread The Rasterman 
On Wed, 28 Jun 2017 08:52:56 +0100 Mick  said:

> On Tuesday 27 Jun 2017 23:22:55 you wrote:
> > On Sun, 25 Jun 2017 14:35:34 +0100 Mick  said:
> 
> > > OK, long backtrace uploaded here:
> > > 
> > >  https://pastebin.com/xiAUmsin
> > > 
> > >
> > > I see a lot of optimisations in there, probably because I built the
> > > packages  with O2.
> > 
> > h. driver (libdri) is stick on some fence operation of it's own... i'm
> > afraid you seem to have hit a driver bug. unless you have enabled in the
> > compositor settings under misc "grab server during draw". this can help
> > reduce tearing in x... but it could lock out other clients from releasing
> > some lock or triggering the fence... :/ this shouldnt really be the case
> > but it in theory could be. if you dont have grabs enabled... then its a
> > driver bug. :/
> 
> Right, just as I was suspecting, this mess started with a xorg drivers and 
> mesa update.
> 
> 'Grab Server during draw' is not enabled.  Anything else not mentioned 
> explicitly below is also NOT enabled.  I have the following settings in the 
> composer which I'm almost sure are the defaults:
> 
> Styles: haven't changed this.
> Fast Effects: Enabled only fast composite effects for windows.
> Disable Effects: none selected.
> Rendering Behavior: Don't composite fullscreen windows, 
> Engine: OpenGL, 
>OpenGL options:
>  Tear-free updates (VSynced),

btw... vsync/tear-free ... is a good thing to have :)

>  Texture from pixmap,Ass
>Assume swapping method:
>  Auto
> Misc:
>   X Messages:
> Send flush
> Send dump
>   Sync:
> Initial draw timeout for newly mapped windows: 0.15sec
> 
> 
> Thanks Carsten, I better check if this bug has been reported anywhere.

:)  :(.


-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-users mailing list
enlightenment-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-users

Re: [e-users] Desktop freeze on tooltip pop ups

2017-06-28 Thread Mick 
On Tuesday 27 Jun 2017 23:22:55 you wrote:
> On Sun, 25 Jun 2017 14:35:34 +0100 Mick  said:

> > OK, long backtrace uploaded here:
> > 
> >  https://pastebin.com/xiAUmsin
> > 
> >
> > I see a lot of optimisations in there, probably because I built the
> > packages  with O2.
> 
> h. driver (libdri) is stick on some fence operation of it's own... i'm
> afraid you seem to have hit a driver bug. unless you have enabled in the
> compositor settings under misc "grab server during draw". this can help
> reduce tearing in x... but it could lock out other clients from releasing
> some lock or triggering the fence... :/ this shouldnt really be the case
> but it in theory could be. if you dont have grabs enabled... then its a
> driver bug. :/

Right, just as I was suspecting, this mess started with a xorg drivers and 
mesa update.

'Grab Server during draw' is not enabled.  Anything else not mentioned 
explicitly below is also NOT enabled.  I have the following settings in the 
composer which I'm almost sure are the defaults:

Styles: haven't changed this.
Fast Effects: Enabled only fast composite effects for windows.
Disable Effects: none selected.
Rendering Behavior: Don't composite fullscreen windows, 
Engine: OpenGL, 
   OpenGL options:
 Tear-free updates (VSynced),
 Texture from pixmap,Ass
   Assume swapping method:
 Auto
Misc:
  X Messages:
Send flush
Send dump
  Sync:
Initial draw timeout for newly mapped windows: 0.15sec


Thanks Carsten, I better check if this bug has been reported anywhere.

-- 
Regards,
Mick
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-users mailing list
enlightenment-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-users

Re: [e-users] Desktop freeze on tooltip pop ups

2017-06-27 Thread The Rasterman 
On Sun, 25 Jun 2017 14:35:34 +0100 Mick  said:

> On Sunday 25 Jun 2017 16:43:51 Carsten Haitzler wrote:
> > On Sat, 24 Jun 2017 19:41:06 +0100 Mick  said:
> > > On Saturday 24 Jun 2017 12:49:09 you wrote:
> > > > On Fri, 23 Jun 2017 15:50:49 +0100 Mick  
> said:
> > > > > Does the above provide anything useful?
> > > > 
> > > > wrong process. that's enlightenment_start not enlightenment.
> > > 
> > > Oh!  When I tried to attach /usr/bin/enlightenment just now gdb informed
> > > me that this was already being traced by the PID
> > > of /usr/bin/enlightenment_start. So I went to
> > > /usr/bin/enlightenment_start.
> > 
> > killall -USR1 enlightenment_start
> > 
> > to get it to stop   monitoring enlightement... :)
> 
> Ha!  I thought it would also kill any children processes, but it didn't!  :-)
> 
> OK, long backtrace uploaded here:
> 
>  https://pastebin.com/xiAUmsin
> 
> I see a lot of optimisations in there, probably because I built the packages 
> with O2.

h. driver (libdri) is stick on some fence operation of it's own... i'm
afraid you seem to have hit a driver bug. unless you have enabled in the
compositor settings under misc "grab server during draw". this can help reduce
tearing in x... but it could lock out other clients from releasing some lock or
triggering the fence... :/ this shouldnt really be the case but it in theory
could be. if you dont have grabs enabled... then its a driver bug. :/

-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-users mailing list
enlightenment-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-users

Re: [e-users] Desktop freeze on tooltip pop ups

2017-06-27 Thread Mick 
On Sunday 25 Jun 2017 14:35:34 Mick wrote:
> On Sunday 25 Jun 2017 16:43:51 Carsten Haitzler wrote:
> > On Sat, 24 Jun 2017 19:41:06 +0100 Mick  said:
> > > On Saturday 24 Jun 2017 12:49:09 you wrote:
> > > > On Fri, 23 Jun 2017 15:50:49 +0100 Mick 
> 
> said:
> > > > > Does the above provide anything useful?
> > > > 
> > > > wrong process. that's enlightenment_start not enlightenment.
> > > 
> > > Oh!  When I tried to attach /usr/bin/enlightenment just now gdb informed
> > > me that this was already being traced by the PID
> > > of /usr/bin/enlightenment_start. So I went to
> > > /usr/bin/enlightenment_start.
> > 
> > killall -USR1 enlightenment_start
> > 
> > to get it to stop   monitoring enlightement... :)
> 
> Ha!  I thought it would also kill any children processes, but it didn't! 
> :-)
> 
> OK, long backtrace uploaded here:
> 
>  https://pastebin.com/xiAUmsin
> 
> I see a lot of optimisations in there, probably because I built the packages
> with O2.


Additional backtrace captured today, when Qpdfview crashed as a tooltip was 
trying to render when my mouse hovered over the main menu:

https://pastebin.com/gA9Up6np

Please let me know if you want me to recompile e or any other packages with a 
different optimization than O2.

-- 
Regards,
Mick
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-users mailing list
enlightenment-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-users

Re: [e-users] Desktop freeze on tooltip pop ups

2017-06-25 Thread Mick 
On Sunday 25 Jun 2017 16:43:51 Carsten Haitzler wrote:
> On Sat, 24 Jun 2017 19:41:06 +0100 Mick  said:
> > On Saturday 24 Jun 2017 12:49:09 you wrote:
> > > On Fri, 23 Jun 2017 15:50:49 +0100 Mick  
said:
> > > > Does the above provide anything useful?
> > > 
> > > wrong process. that's enlightenment_start not enlightenment.
> > 
> > Oh!  When I tried to attach /usr/bin/enlightenment just now gdb informed
> > me that this was already being traced by the PID
> > of /usr/bin/enlightenment_start. So I went to
> > /usr/bin/enlightenment_start.
> 
> killall -USR1 enlightenment_start
> 
> to get it to stop   monitoring enlightement... :)

Ha!  I thought it would also kill any children processes, but it didn't!  :-)

OK, long backtrace uploaded here:

 https://pastebin.com/xiAUmsin

I see a lot of optimisations in there, probably because I built the packages 
with O2.
-- 
Regards,
Mick
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-users mailing list
enlightenment-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-users

Re: [e-users] Desktop freeze on tooltip pop ups

2017-06-25 Thread The Rasterman 
On Sat, 24 Jun 2017 19:41:06 +0100 Mick  said:

> On Saturday 24 Jun 2017 12:49:09 you wrote:
> > On Fri, 23 Jun 2017 15:50:49 +0100 Mick  said:
> 
> > > Does the above provide anything useful?
> > 
> > wrong process. that's enlightenment_start not enlightenment.
> 
> Oh!  When I tried to attach /usr/bin/enlightenment just now gdb informed me 
> that this was already being traced by the PID
> of /usr/bin/enlightenment_start. So I went to /usr/bin/enlightenment_start.

killall -USR1 enlightenment_start

to get it to stop   monitoring enlightement... :)   
 
> My Display Manager is LightDM and I have a ~/.xsession file which contains:
> ===
> #!/bin/sh
> if [ -x /usr/bin/gpg-agent ]; then
> kill $(ps ux | awk '/gpg-agent/ && !/awk/ {print $2}') >/dev/null 2>&1
> fi
> 
> if [ -x /usr/bin/gpg-agent ]; then
>   eval "$(/usr/bin/gpg-agent --daemon)"
> fi 
> 
> # Uncomment the following lines to start rxvt-unicode which has the ability to
> # run multiple terminals in one single process, thus starting up faster and 
> # saving resources.
> # The --opendisplay ensures that the daemon quits when the X server 
> terminates,
> # therefore we don't need matching lines in agent-shutdown.sh.
> 
> if [ -x /usr/bin/urxvtd ]; then
> /usr/bin/urxvtd --opendisplay --fork --quiet
> fi
> 
> #exec ck-launch-session /usr/bin/enlightenment_start
> #exec /usr/bin/enlightenment_start
> #dbus-launch --sh-syntax --exit-with-session "/usr/bin/enlightenment_start"
> /usr/bin/enlightenment_start
> akonadictl stop
> wait 4
> ===
> 
> Is the above incorrect?
> 
> I seem to have enlightenment mentioned a number of times in ps:
> 
>  3853 ?SLsl   0:00 /usr/sbin/lightdm
>  3864 tty7 Ssl+   0:16  \_ /usr/bin/X :0 -seat seat0 -auth 
> /var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch
>  4126 ?SLl0:00  \_ lightdm --session-child 12 21
>  4153 ?Ss 0:00  \_ /usr/bin/enlightenment_start
>  4166 ?Ss 0:00  \_ /usr/bin/gpg-agent --sh --write-env-
> file /home/michael/.gnupg/.gpg-agent-info --daemon -- 
> /usr/bin/enlightenment_start
>  4167 ?Sl 1:11  \_ /usr/bin/enlightenment
>  4168 ?SNs0:00  \_ /usr/bin/efreetd
>  4190 ?SNsl   0:06  \_ gkrellm
>  4233 ?SNs0:00  \_ 
> /usr/lib64/enlightenment/utils/enlightenment_fm
> [snip ...]
> 
>  4164 ?S  0:00 /usr/bin/dbus-launch --exit-with-session 
> /usr/bin/gpg-agent --sh --write-env-file /home/michael/.gnupg/.gpg-agent-info 
> --daemon -- /usr/bin/enlightenment_start
> 
> Should this process tree be/look different?
> -- 
> Regards,
> Mick


-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-users mailing list
enlightenment-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-users

Re: [e-users] Desktop freeze on tooltip pop ups

2017-06-24 Thread Mick 
On Saturday 24 Jun 2017 12:49:09 you wrote:
> On Fri, 23 Jun 2017 15:50:49 +0100 Mick  said:

> > Does the above provide anything useful?
> 
> wrong process. that's enlightenment_start not enlightenment.

Oh!  When I tried to attach /usr/bin/enlightenment just now gdb informed me 
that this was already being traced by the PID of /usr/bin/enlightenment_start.  
So I went to /usr/bin/enlightenment_start.

My Display Manager is LightDM and I have a ~/.xsession file which contains:
===
#!/bin/sh
if [ -x /usr/bin/gpg-agent ]; then
kill $(ps ux | awk '/gpg-agent/ && !/awk/ {print $2}') >/dev/null 2>&1
fi

if [ -x /usr/bin/gpg-agent ]; then
  eval "$(/usr/bin/gpg-agent --daemon)"
fi 

# Uncomment the following lines to start rxvt-unicode which has the ability to
# run multiple terminals in one single process, thus starting up faster and 
# saving resources.
# The --opendisplay ensures that the daemon quits when the X server 
terminates,
# therefore we don't need matching lines in agent-shutdown.sh.

if [ -x /usr/bin/urxvtd ]; then
/usr/bin/urxvtd --opendisplay --fork --quiet
fi

#exec ck-launch-session /usr/bin/enlightenment_start
#exec /usr/bin/enlightenment_start
#dbus-launch --sh-syntax --exit-with-session "/usr/bin/enlightenment_start"
/usr/bin/enlightenment_start
akonadictl stop
wait 4
===

Is the above incorrect?

I seem to have enlightenment mentioned a number of times in ps:

 3853 ?SLsl   0:00 /usr/sbin/lightdm
 3864 tty7 Ssl+   0:16  \_ /usr/bin/X :0 -seat seat0 -auth 
/var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch
 4126 ?SLl0:00  \_ lightdm --session-child 12 21
 4153 ?Ss 0:00  \_ /usr/bin/enlightenment_start
 4166 ?Ss 0:00  \_ /usr/bin/gpg-agent --sh --write-env-
file /home/michael/.gnupg/.gpg-agent-info --daemon -- 
/usr/bin/enlightenment_start
 4167 ?Sl 1:11  \_ /usr/bin/enlightenment
 4168 ?SNs0:00  \_ /usr/bin/efreetd
 4190 ?SNsl   0:06  \_ gkrellm
 4233 ?SNs0:00  \_ 
/usr/lib64/enlightenment/utils/enlightenment_fm
[snip ...]

 4164 ?S  0:00 /usr/bin/dbus-launch --exit-with-session 
/usr/bin/gpg-agent --sh --write-env-file /home/michael/.gnupg/.gpg-agent-info 
--daemon -- /usr/bin/enlightenment_start

Should this process tree be/look different?
-- 
Regards,
Mick
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-users mailing list
enlightenment-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-users

Re: [e-users] Desktop freeze on tooltip pop ups

2017-06-23 Thread The Rasterman 
On Fri, 23 Jun 2017 15:50:49 +0100 Mick  said:

> On Sunday 18 Jun 2017 08:56:19 you wrote:
> > On Sat, 17 Jun 2017 17:27:50 +0100 Mick  said:
> > > ERR<4114>:evas-gl_x11 modules/evas/engines/gl_x11/evas_engine.c:2842
> > > eng_image_native_set() GLX Pixmap create fail
> > 
> > is your problem... evas is trying to create a glx pixmap for the x pixmap so
> > it can access it from opengl... as a texture. and that is failing. well
> > it's the first sign of trouble.
> > 
> > what happens after that - unknown. attaching gdb might help to get a
> > backtrace to where e is...
> > 
> > https://www.enlightenment.org/debugging/enlightenment_debugging
> > 
> > details how to do this...
> 
> Thanks Carsten, I had a go at capturing a backtrace, which happened with 
> LibreOffice when a tooltip was trying to come up:
> 
> GNU gdb (Gentoo 7.12.1 vanilla) 7.12.1
> Copyright (C) 2017 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later 
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-pc-linux-gnu".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> .
> Find the GDB manual and other documentation resources online at:
> .
> For help, type "help".
> Type "apropos word" to search for commands related to "word".
> (gdb) handle SIG33 pass no stop noprint
> SignalStopPrint   Pass to program Description
> SIG33 No  No  Yes Real-time event 33
> (gdb) set pagination 0
> (gdb) attach 4165
> Attaching to process 4165
> Reading symbols from /usr/bin/enlightenment_start...Reading symbols from 
> /usr/lib64/debug//usr/bin/enlightenment_start.debug...done.
> done.
> Reading symbols from /usr/lib64/libevas.so.1...Reading symbols from 
> /usr/lib64/debug//usr/lib64/libevas.so.1.18.4.debug...done.
> done.
> Reading symbols from /usr/lib64/libeina.so.1...Reading symbols from 
> /usr/lib64/debug//usr/lib64/libeina.so.1.18.4.debug...done.
> done.
> Reading symbols from /lib64/libpthread.so.0...Reading symbols from 
> /usr/lib64/debug//lib64/libpthread-2.23.so.debug...done.
> done.
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib64/libthread_db.so.1".
> Reading symbols from /lib64/libc.so.6...Reading symbols from 
> /usr/lib64/debug//lib64/libc-2.23.so.debug...done.
> done.
> Reading symbols from /usr/lib64/libfontconfig.so.1...Reading symbols from 
> /usr/lib64/debug/usr/lib64/libfontconfig.so.1.8.0.debug...(no debugging 
> symbols found)...done.
> (no debugging symbols found)...done.
> Reading symbols from /usr/lib64/libfreetype.so.6...Reading symbols from 
> /usr/lib64/debug//usr/lib64/libfreetype.so.6.14.0.debug...(no debugging 
> symbols found)...done.
> (no debugging symbols found)...done.
> Reading symbols from /usr/lib64/libluajit-5.1.so.2...Reading symbols from 
> /usr/lib64/debug//usr/lib64/libluajit-5.1.so.2.0.4.debug...(no debugging 
> symbols found)...done.
> (no debugging symbols found)...done.
> Reading symbols from /usr/lib64/libector.so.1...Reading symbols from 
> /usr/lib64/debug//usr/lib64/libector.so.1.18.4.debug...done.
> done.
> Reading symbols from /usr/lib64/libefl.so.1...Reading symbols from 
> /usr/lib64/debug//usr/lib64/libefl.so.1.18.4.debug...done.
> done.
> Reading symbols from /usr/lib64/libeet.so.1...Reading symbols from 
> /usr/lib64/debug//usr/lib64/libeet.so.1.18.4.debug...done.
> done.
> Reading symbols from /usr/lib64/libemile.so.1...Reading symbols from 
> /usr/lib64/debug//usr/lib64/libemile.so.1.18.4.debug...done.
> done.
> Reading symbols from /usr/lib64/libeo.so.1...Reading symbols from 
> /usr/lib64/debug//usr/lib64/libeo.so.1.18.4.debug...done.
> done.
> Traceback (most recent call last):
>   File "/usr/share/gdb/auto-load/usr/lib64/libeo.so.1.18.4-gdb.py", line 7,
> in 
> import eo_gdb
> ImportError: No module named 'eo_gdb'
> Reading symbols from /lib64/libdl.so.2...Reading symbols from 
> /usr/lib64/debug//lib64/libdl-2.23.so.debug...done.
> done.
> Reading symbols from /lib64/librt.so.1...Reading symbols from 
> /usr/lib64/debug//lib64/librt-2.23.so.debug...done.
> done.
> Reading symbols from /lib64/libm.so.6...Reading symbols from 
> /usr/lib64/debug//lib64/libm-2.23.so.debug...done.
> done.
> Reading symbols from /lib64/ld-linux-x86-64.so.2...Reading symbols from 
> /usr/lib64/debug//lib64/ld-2.23.so.debug...done.
> done.
> Reading symbols from /usr/lib64/libexpat.so.1...Reading symbols from 
> /usr/lib64/debug//usr/lib64/libexpat.so.1.6.3.debug...(no debugging symbols 
> found)...done.
> (no debugging symbols found)...done.
> Reading symbols from

Re: [e-users] Desktop freeze on tooltip pop ups

2017-06-23 Thread Mick 
On Sunday 18 Jun 2017 08:56:19 you wrote:
> On Sat, 17 Jun 2017 17:27:50 +0100 Mick  said:
> > ERR<4114>:evas-gl_x11 modules/evas/engines/gl_x11/evas_engine.c:2842
> > eng_image_native_set() GLX Pixmap create fail
> 
> is your problem... evas is trying to create a glx pixmap for the x pixmap so
> it can access it from opengl... as a texture. and that is failing. well
> it's the first sign of trouble.
> 
> what happens after that - unknown. attaching gdb might help to get a
> backtrace to where e is...
> 
> https://www.enlightenment.org/debugging/enlightenment_debugging
> 
> details how to do this...

Thanks Carsten, I had a go at capturing a backtrace, which happened with 
LibreOffice when a tooltip was trying to come up:

GNU gdb (Gentoo 7.12.1 vanilla) 7.12.1
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word".
(gdb) handle SIG33 pass no stop noprint
SignalStop  Print   Pass to program Description
SIG33 NoNo  Yes Real-time event 33
(gdb) set pagination 0
(gdb) attach 4165
Attaching to process 4165
Reading symbols from /usr/bin/enlightenment_start...Reading symbols from 
/usr/lib64/debug//usr/bin/enlightenment_start.debug...done.
done.
Reading symbols from /usr/lib64/libevas.so.1...Reading symbols from 
/usr/lib64/debug//usr/lib64/libevas.so.1.18.4.debug...done.
done.
Reading symbols from /usr/lib64/libeina.so.1...Reading symbols from 
/usr/lib64/debug//usr/lib64/libeina.so.1.18.4.debug...done.
done.
Reading symbols from /lib64/libpthread.so.0...Reading symbols from 
/usr/lib64/debug//lib64/libpthread-2.23.so.debug...done.
done.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Reading symbols from /lib64/libc.so.6...Reading symbols from 
/usr/lib64/debug//lib64/libc-2.23.so.debug...done.
done.
Reading symbols from /usr/lib64/libfontconfig.so.1...Reading symbols from 
/usr/lib64/debug/usr/lib64/libfontconfig.so.1.8.0.debug...(no debugging 
symbols found)...done.
(no debugging symbols found)...done.
Reading symbols from /usr/lib64/libfreetype.so.6...Reading symbols from 
/usr/lib64/debug//usr/lib64/libfreetype.so.6.14.0.debug...(no debugging 
symbols found)...done.
(no debugging symbols found)...done.
Reading symbols from /usr/lib64/libluajit-5.1.so.2...Reading symbols from 
/usr/lib64/debug//usr/lib64/libluajit-5.1.so.2.0.4.debug...(no debugging 
symbols found)...done.
(no debugging symbols found)...done.
Reading symbols from /usr/lib64/libector.so.1...Reading symbols from 
/usr/lib64/debug//usr/lib64/libector.so.1.18.4.debug...done.
done.
Reading symbols from /usr/lib64/libefl.so.1...Reading symbols from 
/usr/lib64/debug//usr/lib64/libefl.so.1.18.4.debug...done.
done.
Reading symbols from /usr/lib64/libeet.so.1...Reading symbols from 
/usr/lib64/debug//usr/lib64/libeet.so.1.18.4.debug...done.
done.
Reading symbols from /usr/lib64/libemile.so.1...Reading symbols from 
/usr/lib64/debug//usr/lib64/libemile.so.1.18.4.debug...done.
done.
Reading symbols from /usr/lib64/libeo.so.1...Reading symbols from 
/usr/lib64/debug//usr/lib64/libeo.so.1.18.4.debug...done.
done.
Traceback (most recent call last):
  File "/usr/share/gdb/auto-load/usr/lib64/libeo.so.1.18.4-gdb.py", line 7, in 

import eo_gdb
ImportError: No module named 'eo_gdb'
Reading symbols from /lib64/libdl.so.2...Reading symbols from 
/usr/lib64/debug//lib64/libdl-2.23.so.debug...done.
done.
Reading symbols from /lib64/librt.so.1...Reading symbols from 
/usr/lib64/debug//lib64/librt-2.23.so.debug...done.
done.
Reading symbols from /lib64/libm.so.6...Reading symbols from 
/usr/lib64/debug//lib64/libm-2.23.so.debug...done.
done.
Reading symbols from /lib64/ld-linux-x86-64.so.2...Reading symbols from 
/usr/lib64/debug//lib64/ld-2.23.so.debug...done.
done.
Reading symbols from /usr/lib64/libexpat.so.1...Reading symbols from 
/usr/lib64/debug//usr/lib64/libexpat.so.1.6.3.debug...(no debugging symbols 
found)...done.
(no debugging symbols found)...done.
Reading symbols from /lib64/libz.so.1...Reading symbols from 
/usr/lib64/debug//lib64/libz.so.1.2.11.debug...(no debugging symbols 
found)...done.
(no debugging symbols found)...done.
Reading symbols from /lib64/libbz2.so.1...Reading symbols from 
/usr/lib64/debug//lib64/libbz2.so.1.0.6.debug...(no debugging

Re: [e-users] Desktop freeze on tooltip pop ups

2017-06-17 Thread The Rasterman 
On Sat, 17 Jun 2017 17:27:50 +0100 Mick  said:

> ERR<4114>:evas-gl_x11 modules/evas/engines/gl_x11/evas_engine.c:2842
> eng_image_native_set() GLX Pixmap create fail

is your problem... evas is trying to create a glx pixmap for the x pixmap so it
can access it from opengl... as a texture. and that is failing. well it's the
first sign of trouble.

what happens after that - unknown. attaching gdb might help to get a backtrace
to where e is...

https://www.enlightenment.org/debugging/enlightenment_debugging

details how to do this...

-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-users mailing list
enlightenment-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-users