Re: [E-devel] conf_randr - A Randr dialog for e17
On Fri, 29 Jul 2011 19:12:58 +0200 Leif Middelschulte leif.middelschu...@gmail.com said: why did you make it conf_randr. already months ago i merged config modules - it's part of conf_display - and e_int_config_display.[ch] in there. as already mentioned missing icon.png, which we dont have to worry about if you merge it in with conf_display. can you do that? :) Hey, thanks for your reply. Attached is yet another set, which fixes an issue when rearranging monitors multiple times. I will send further patches based on these. BR, Leif 2011/7/29 PaulTT pau...@gmail.com: it seems cool, thanx didn' try yet, i'll do -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Leif -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] conf_randr - A Randr dialog for e17
Hello. On Sat, 2011-07-30 at 05:20, Leif Middelschulte wrote: thanks for testing the patch :-) No problem. Looking forward to xrandr support in E. Especially the save and restore options to remember monitor settings is something that interests me. In my opinion such details are making the difference form a ok to a good experience. Anyway, back to topic. :) See comments in their context, respectively. Am 30.07.2011 um 00:15 schrieb Stefan Schmidt ste...@datenfreihafen.org: On Fri, 2011-07-29 at 23:11, Stefan Schmidt wrote: On Fri, 2011-07-29 at 19:12, Leif Middelschulte wrote: Attached is yet another set, which fixes an issue when rearranging monitors multiple times. /usr/local/bin/edje_cc -v -id ../../../src/modules/conf_randr/images -DLOWRES_PDA=1 -DMEDIUMRES_PDA=2 -DHIRES_PDA=3 -DSLOW_PC=4 -DMEDIUM_PC=5 -DFAST_PC=6 -DE17_PROFILE=SLOW_PC \ ../../../src/modules/conf_randr/e-module-conf_randr.edc \ ../../../src/modules/conf_randr/e-module-conf_randr.edj /usr/local/bin/edje_cc: Wrote 251 bytes ( 0Kb) for edje_file header /usr/local/bin/edje_cc: Error. Unable to load image icon.png used by file ../../../src/modules/conf_randr/e-module-conf_randr.edj: File (or file path) does not exist. Check if path to file icon.png is correct (both directory and file name). make[4]: *** [e-module-conf_randr.edj] Error 255 I'm sorry. I thought gut produced a hexdump of the image as a patch. It did in my previous patch. I'll check again tomorrow, if I can. Getting another icon over is trivial enough. Just wanted to let you and maybe other testers know the problems I run into. Hmm, either I'm to tired to think straight enough or something strange is going on here. I dropped in another icon and the edje compiled fine. Complete E rebuild and install and no sign of and randr module in modules neither any config options in the settings panel (no surprise if the module is not loaded). Is the any magic I'm missing to get the module show up? Its installed in the same folder as all the other E modules already checked that. Yeah, that's a weird issue I also faced. I need to fix it. See whether it shows up in the system modules list. If not use 'enlightenment_remote -module-load conf_randr' and '-module-enable conf_randr' for now. At least I'm not the only one facing this issue. :) This trick indeed gets me the module in the settings panel. Sadly it crashes E immediately if I want to open the randr settings. Whats the svn version you are testing this code against? I'm on head from yesterday here (61903). I'm really sorry for the inconvenience. I think it's because of wrong naming, or changes to the module API. Could be. Depending on how other stuff works out today I may also have a look myself. regards Stefan Schmidt -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] redraw problem
Hi, I had problems with redrawing of applications, menus, background. Sometimes application stopped redrawing after a while and just special action causing explicit redraw (desktop change, window move, ...) helps for a while. (from lspci) 00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (primary) (rev 0c) 00:02.1 Display controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (secondary) (rev 0c) (from Xorg.0.log) [99.924] (II) LoadModule: intel [99.924] (II) Loading /usr/lib64/xorg/modules/drivers/intel_drv.so [99.925] (II) Module intel: vendor=X.Org Foundation [99.925]compiled for 1.9.3, module version = 2.15.0 [99.925]Module class: X.Org Video Driver [99.925]ABI class: X.Org Video Driver, version 8.0 Workaround for the problem is to disable KMS. echo 'options i915 modeset=0' /etc/modprobe.d/i915-disable-kms.conf Maybe it will save some hours of madness. Best regards, Tomas Cech Sleep_Walker -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] conf_randr - A Randr dialog for e17
2011/7/30 Carsten Haitzler ras...@rasterman.com: On Fri, 29 Jul 2011 19:12:58 +0200 Leif Middelschulte leif.middelschu...@gmail.com said: why did you make it conf_randr. Because I thought maybe people don't need it all the time. Just to configure their setup once and afterwards they don't have to load it anymore. already months ago i merged config modules - it's part of conf_display - and e_int_config_display.[ch] in there. as already mentioned missing icon.png, which we dont have to worry about if you merge it in with conf_display. can you do that? :) The reason I didn't merge in conf_display in the first place was, that people might not even have multiple displays, so the entire adjustment/policy stuff is useless to them (e.g. if their drivers just supports RandR =1.1). But yes, I can merge in conf_display as another page in the toolbook. Though it'll have to wait a bit, until I'm finished with my next exam (end of next week). I planned to adjust e_int_config_display so it works with CRTCs (RandR 1.2) instead of just the primary screen (RandR 1.1) as it does right now. I won't support RandR 1.1 in that dialog anymore. People whose drivers just support RandR 1.1 shall stay with the current dialog. So actually we need a new name like 'conf_display2' or rename current dialog to e_int_config_single_display and the new one e_int_config_multiple_displays Hey, thanks for your reply. Attached is yet another set, which fixes an issue when rearranging monitors multiple times. I will send further patches based on these. BR, Leif 2011/7/29 PaulTT pau...@gmail.com: it seems cool, thanx didn' try yet, i'll do -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Leif -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler) ras...@rasterman.com -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Leif -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] conf_randr - A Randr dialog for e17
2011/7/30 Stefan Schmidt ste...@datenfreihafen.org: Hello. On Sat, 2011-07-30 at 05:20, Leif Middelschulte wrote: thanks for testing the patch :-) No problem. Looking forward to xrandr support in E. Especially the save and restore options to remember monitor settings is something that interests me. In my opinion such details are making the difference form a ok to a good experience. Anyway, back to topic. :) Yeah, that is some tricky thing. Need to lookup a good fitting algorithm and map it to the RandR environment. Problem is the way RandR works here. Identifiers for CRTCs are not deterministic, so it's kind of problematic to restore beyond guessing. But as I said, I'll come up with a solution. See comments in their context, respectively. Am 30.07.2011 um 00:15 schrieb Stefan Schmidt ste...@datenfreihafen.org: On Fri, 2011-07-29 at 23:11, Stefan Schmidt wrote: On Fri, 2011-07-29 at 19:12, Leif Middelschulte wrote: Attached is yet another set, which fixes an issue when rearranging monitors multiple times. /usr/local/bin/edje_cc -v -id ../../../src/modules/conf_randr/images -DLOWRES_PDA=1 -DMEDIUMRES_PDA=2 -DHIRES_PDA=3 -DSLOW_PC=4 -DMEDIUM_PC=5 -DFAST_PC=6 -DE17_PROFILE=SLOW_PC \ ../../../src/modules/conf_randr/e-module-conf_randr.edc \ ../../../src/modules/conf_randr/e-module-conf_randr.edj /usr/local/bin/edje_cc: Wrote 251 bytes ( 0Kb) for edje_file header /usr/local/bin/edje_cc: Error. Unable to load image icon.png used by file ../../../src/modules/conf_randr/e-module-conf_randr.edj: File (or file path) does not exist. Check if path to file icon.png is correct (both directory and file name). make[4]: *** [e-module-conf_randr.edj] Error 255 I'm sorry. I thought gut produced a hexdump of the image as a patch. It did in my previous patch. I'll check again tomorrow, if I can. Getting another icon over is trivial enough. Just wanted to let you and maybe other testers know the problems I run into. Right. Hmm, either I'm to tired to think straight enough or something strange is going on here. I dropped in another icon and the edje compiled fine. Complete E rebuild and install and no sign of and randr module in modules neither any config options in the settings panel (no surprise if the module is not loaded). Is the any magic I'm missing to get the module show up? Its installed in the same folder as all the other E modules already checked that. Yeah, that's a weird issue I also faced. I need to fix it. See whether it shows up in the system modules list. If not use 'enlightenment_remote -module-load conf_randr' and '-module-enable conf_randr' for now. At least I'm not the only one facing this issue. :) This trick indeed gets me the module in the settings panel. Sadly it crashes E immediately if I want to open the randr settings. Could you provide me with a backtrace? Whats the svn version you are testing this code against? I'm on head from yesterday here (61903). I tested on 61900. Works here, no crashing. So once again please provide a backtrace. I'm really sorry for the inconvenience. I think it's because of wrong naming, or changes to the module API. Could be. Depending on how other stuff works out today I may also have a look myself. Yes, feel free to provide a patch ;-) regards Stefan Schmidt -- Leif -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] redraw problem
Hi, On Sat, Jul 30, 2011 at 4:14 PM, Tomas Cech tc...@suse.cz wrote: I had problems with redrawing of applications, menus, background. Sometimes application stopped redrawing after a while and just special action causing explicit redraw (desktop change, window move, ...) helps for a while. (from lspci) 00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (primary) (rev 0c) 00:02.1 Display controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (secondary) (rev 0c) (from Xorg.0.log) [ 99.924] (II) LoadModule: intel [ 99.924] (II) Loading /usr/lib64/xorg/modules/drivers/intel_drv.so [ 99.925] (II) Module intel: vendor=X.Org Foundation [ 99.925] compiled for 1.9.3, module version = 2.15.0 [ 99.925] Module class: X.Org Video Driver [ 99.925] ABI class: X.Org Video Driver, version 8.0 Workaround for the problem is to disable KMS. echo 'options i915 modeset=0' /etc/modprobe.d/i915-disable-kms.conf Maybe it will save some hours of madness. Sounds like a bug, like many, in video driver. Did you talk to intel maintainer ? -- Cedric BAIL -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] redraw problem
Hi, On Sat, Jul 30, 2011 at 05:24:33PM +0200, Cedric BAIL wrote: Hi, On Sat, Jul 30, 2011 at 4:14 PM, Tomas Cech tc...@suse.cz wrote: I had problems with redrawing of applications, menus, background. Sometimes application stopped redrawing after a while and just special action causing explicit redraw (desktop change, window move, ...) helps for a while. (from lspci) 00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (primary) (rev 0c) 00:02.1 Display controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (secondary) (rev 0c) (from Xorg.0.log) [ 99.924] (II) LoadModule: intel [ 99.924] (II) Loading /usr/lib64/xorg/modules/drivers/intel_drv.so [ 99.925] (II) Module intel: vendor=X.Org Foundation [ 99.925] compiled for 1.9.3, module version = 2.15.0 [ 99.925] Module class: X.Org Video Driver [ 99.925] ABI class: X.Org Video Driver, version 8.0 Workaround for the problem is to disable KMS. echo 'options i915 modeset=0' /etc/modprobe.d/i915-disable-kms.conf Maybe it will save some hours of madness. Sounds like a bug, like many, in video driver. Did you talk to intel maintainer ? It's definitely bug. No, but I found several similar bugs on distro specific bugzillas. Bug report created for X.org here: https://bugs.freedesktop.org/show_bug.cgi?id=39695 Best regards, Tomas Cech Sleep_Walker -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] redraw problem
On Sat, 30 Jul 2011 18:38:53 +0200 Tomas Cech tc...@suse.cz said: Hi, On Sat, Jul 30, 2011 at 05:24:33PM +0200, Cedric BAIL wrote: Hi, On Sat, Jul 30, 2011 at 4:14 PM, Tomas Cech tc...@suse.cz wrote: I had problems with redrawing of applications, menus, background. Sometimes application stopped redrawing after a while and just special action causing explicit redraw (desktop change, window move, ...) helps for a while. (from lspci) 00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (primary) (rev 0c) 00:02.1 Display controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (secondary) (rev 0c) (from Xorg.0.log) [ 99.924] (II) LoadModule: intel [ 99.924] (II) Loading /usr/lib64/xorg/modules/drivers/intel_drv.so [ 99.925] (II) Module intel: vendor=X.Org Foundation [ 99.925] compiled for 1.9.3, module version = 2.15.0 [ 99.925] Module class: X.Org Video Driver [ 99.925] ABI class: X.Org Video Driver, version 8.0 Workaround for the problem is to disable KMS. echo 'options i915 modeset=0' /etc/modprobe.d/i915-disable-kms.conf Maybe it will save some hours of madness. Sounds like a bug, like many, in video driver. Did you talk to intel maintainer ? It's definitely bug. No, but I found several similar bugs on distro specific bugzillas. Bug report created for X.org here: https://bugs.freedesktop.org/show_bug.cgi?id=39695 Best regards, Tomas Cech Sleep_Walker and... what do you want us to do about it? :) -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] conf_randr - A Randr dialog for e17
On Sat, 30 Jul 2011 17:11:20 +0200 Leif Middelschulte leif.middelschu...@gmail.com said: 2011/7/30 Carsten Haitzler ras...@rasterman.com: On Fri, 29 Jul 2011 19:12:58 +0200 Leif Middelschulte leif.middelschu...@gmail.com said: why did you make it conf_randr. Because I thought maybe people don't need it all the time. Just to configure their setup once and afterwards they don't have to load it anymore. already months ago i merged config modules - it's part of conf_display - and e_int_config_display.[ch] in there. as already mentioned missing icon.png, which we dont have to worry about if you merge it in with conf_display. can you do that? :) The reason I didn't merge in conf_display in the first place was, that people might not even have multiple displays, so the entire adjustment/policy stuff is useless to them (e.g. if their drivers just supports RandR =1.1). this isn't just for multiple displays its for resolution too and just fyi.. people with laptops need this quite often. :) if its never used the code is never paged in from disk so it costs nothing (if its already part of a module loaded anyway). But yes, I can merge in conf_display as another page in the toolbook. Though it'll have to wait a bit, until I'm finished with my next exam (end of next week). well it really should be one and the same dialog. to set up resolution and rotation for each screen AND set up how many screens are enabled or not and what the policy is when a new screen is found (auto-enable, never enable, should it extend or clone etc.). I planned to adjust e_int_config_display so it works with CRTCs (RandR 1.2) instead of just the primary screen (RandR 1.1) as it does right now. I won't support RandR 1.1 in that dialog anymore. People whose drivers just support RandR 1.1 shall stay with the current dialog. So actually we need a new name like 'conf_display2' or rename current dialog to e_int_config_single_display and the new one e_int_config_multiple_displays it really should support the whole range - 1.1, 1.2 etc. - a user shouldnt have to switch dialogs to choose what version of a spec is supported. they have no clue which one is supported. they just want it to work. :) Hey, thanks for your reply. Attached is yet another set, which fixes an issue when rearranging monitors multiple times. I will send further patches based on these. BR, Leif 2011/7/29 PaulTT pau...@gmail.com: it seems cool, thanx didn' try yet, i'll do -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Leif -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler) ras...@rasterman.com -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Leif -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] redraw problem
On Sun, Jul 31, 2011 at 01:57:22AM +0900, Carsten Haitzler wrote: On Sat, 30 Jul 2011 18:38:53 +0200 Tomas Cech tc...@suse.cz said: Hi, On Sat, Jul 30, 2011 at 05:24:33PM +0200, Cedric BAIL wrote: Hi, On Sat, Jul 30, 2011 at 4:14 PM, Tomas Cech tc...@suse.cz wrote: I had problems with redrawing of applications, menus, background. Sometimes application stopped redrawing after a while and just special action causing explicit redraw (desktop change, window move, ...) helps for a while. (from lspci) 00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (primary) (rev 0c) 00:02.1 Display controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (secondary) (rev 0c) (from Xorg.0.log) [ 99.924] (II) LoadModule: intel [ 99.924] (II) Loading /usr/lib64/xorg/modules/drivers/intel_drv.so [ 99.925] (II) Module intel: vendor=X.Org Foundation [ 99.925] compiled for 1.9.3, module version = 2.15.0 [ 99.925] Module class: X.Org Video Driver [ 99.925] ABI class: X.Org Video Driver, version 8.0 Workaround for the problem is to disable KMS. echo 'options i915 modeset=0' /etc/modprobe.d/i915-disable-kms.conf Maybe it will save some hours of madness. ^^^ This. Sounds like a bug, like many, in video driver. Did you talk to intel maintainer ? It's definitely bug. No, but I found several similar bugs on distro specific bugzillas. Bug report created for X.org here: https://bugs.freedesktop.org/show_bug.cgi?id=39695 Best regards, Tomas Cech Sleep_Walker and... what do you want us to do about it? :) Funny, I think it was you who told me that someone else was fighting with this issue. This way it will be easier to google it. If it is too off topic, my apologies :) Best regards, Tomas Cech Sleep_Walker -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] conf_randr - A Randr dialog for e17
2011/7/30 Carsten Haitzler ras...@rasterman.com: On Sat, 30 Jul 2011 17:11:20 +0200 Leif Middelschulte leif.middelschu...@gmail.com said: 2011/7/30 Carsten Haitzler ras...@rasterman.com: On Fri, 29 Jul 2011 19:12:58 +0200 Leif Middelschulte leif.middelschu...@gmail.com said: why did you make it conf_randr. Because I thought maybe people don't need it all the time. Just to configure their setup once and afterwards they don't have to load it anymore. already months ago i merged config modules - it's part of conf_display - and e_int_config_display.[ch] in there. as already mentioned missing icon.png, which we dont have to worry about if you merge it in with conf_display. can you do that? :) The reason I didn't merge in conf_display in the first place was, that people might not even have multiple displays, so the entire adjustment/policy stuff is useless to them (e.g. if their drivers just supports RandR =1.1). this isn't just for multiple displays its for resolution too and just fyi.. people with laptops need this quite often. :) if its never used the code is never paged in from disk so it costs nothing (if its already part of a module loaded anyway). I know what conf_display did :-) I'll integrate its options into 'conf_randr'. But yes, I can merge in conf_display as another page in the toolbook. Though it'll have to wait a bit, until I'm finished with my next exam (end of next week). well it really should be one and the same dialog. to set up resolution and rotation for each screen AND set up how many screens are enabled or not and what the policy is when a new screen is found (auto-enable, never enable, should it extend or clone etc.). Per display stuff will be integrated along the integration of conf_display. Policy stuff is already there and works for me(TM). I planned to adjust e_int_config_display so it works with CRTCs (RandR 1.2) instead of just the primary screen (RandR 1.1) as it does right now. I won't support RandR 1.1 in that dialog anymore. People whose drivers just support RandR 1.1 shall stay with the current dialog. So actually we need a new name like 'conf_display2' or rename current dialog to e_int_config_single_display and the new one e_int_config_multiple_displays it really should support the whole range - 1.1, 1.2 etc. - a user shouldnt have to switch dialogs to choose what version of a spec is supported. they have no clue which one is supported. they just want it to work. :) But randr = and 1.1 work completly different. There is not code sharing. That's why I pliedge for leaving the dialog (conf_display) as is and just pop it up instead of integrating it into an else useless dialog (conf_randr), making the code more complicated than it needs to be. I went that way before and it's double effort without any advantage. As I proposed above: if (randr 1.2) return conf_display; else return conf_randr; //with conf_display2 integrated If you can point out a good reason why to rewrite most of the old craft, I'll do it. But else I see more benefit in getting other things done. Hey, thanks for your reply. Attached is yet another set, which fixes an issue when rearranging monitors multiple times. I will send further patches based on these. BR, Leif 2011/7/29 PaulTT pau...@gmail.com: it seems cool, thanx didn' try yet, i'll do -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Leif -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler) ras...@rasterman.com -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Leif -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler) ras...@rasterman.com -- Leif -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey
Re: [E-devel] redraw problem
On Sat, 30 Jul 2011 19:19:13 +0200 Tomas Cech tc...@suse.cz said: On Sun, Jul 31, 2011 at 01:57:22AM +0900, Carsten Haitzler wrote: On Sat, 30 Jul 2011 18:38:53 +0200 Tomas Cech tc...@suse.cz said: Hi, On Sat, Jul 30, 2011 at 05:24:33PM +0200, Cedric BAIL wrote: Hi, On Sat, Jul 30, 2011 at 4:14 PM, Tomas Cech tc...@suse.cz wrote: I had problems with redrawing of applications, menus, background. Sometimes application stopped redrawing after a while and just special action causing explicit redraw (desktop change, window move, ...) helps for a while. (from lspci) 00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (primary) (rev 0c) 00:02.1 Display controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (secondary) (rev 0c) (from Xorg.0.log) [ 99.924] (II) LoadModule: intel [ 99.924] (II) Loading /usr/lib64/xorg/modules/drivers/intel_drv.so [ 99.925] (II) Module intel: vendor=X.Org Foundation [ 99.925] compiled for 1.9.3, module version = 2.15.0 [ 99.925] Module class: X.Org Video Driver [ 99.925] ABI class: X.Org Video Driver, version 8.0 Workaround for the problem is to disable KMS. echo 'options i915 modeset=0' /etc/modprobe.d/i915-disable-kms.conf Maybe it will save some hours of madness. ^^^ This. Sounds like a bug, like many, in video driver. Did you talk to intel maintainer ? It's definitely bug. No, but I found several similar bugs on distro specific bugzillas. Bug report created for X.org here: https://bugs.freedesktop.org/show_bug.cgi?id=39695 Best regards, Tomas Cech Sleep_Walker and... what do you want us to do about it? :) Funny, I think it was you who told me that someone else was fighting with this issue. This way it will be easier to google it. If it is too off topic, my apologies :) E can;t go changing kernel module options. it is not root, nor does it even know HOW to change it as it will vary from distro to distro and user to user as to how they have config files set up. also e cant CHANGE the modules as it's already started and kernel modules are up and running and u cant unload and re-load once already in use. this is entirely out of our hands. it's not even out job to figure out what gfx card or driver you have - they all are meant to export the same api and features via x and opengl. opengl tells us what extensions are and are not supported in a generic way. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] conf_randr - A Randr dialog for e17
On Sat, 30 Jul 2011 19:26:51 +0200 Leif Middelschulte leif.middelschu...@gmail.com said: 2011/7/30 Carsten Haitzler ras...@rasterman.com: On Sat, 30 Jul 2011 17:11:20 +0200 Leif Middelschulte leif.middelschu...@gmail.com said: 2011/7/30 Carsten Haitzler ras...@rasterman.com: On Fri, 29 Jul 2011 19:12:58 +0200 Leif Middelschulte leif.middelschu...@gmail.com said: why did you make it conf_randr. Because I thought maybe people don't need it all the time. Just to configure their setup once and afterwards they don't have to load it anymore. already months ago i merged config modules - it's part of conf_display - and e_int_config_display.[ch] in there. as already mentioned missing icon.png, which we dont have to worry about if you merge it in with conf_display. can you do that? :) The reason I didn't merge in conf_display in the first place was, that people might not even have multiple displays, so the entire adjustment/policy stuff is useless to them (e.g. if their drivers just supports RandR =1.1). this isn't just for multiple displays its for resolution too and just fyi.. people with laptops need this quite often. :) if its never used the code is never paged in from disk so it costs nothing (if its already part of a module loaded anyway). I know what conf_display did :-) I'll integrate its options into 'conf_randr'. But yes, I can merge in conf_display as another page in the toolbook. Though it'll have to wait a bit, until I'm finished with my next exam (end of next week). well it really should be one and the same dialog. to set up resolution and rotation for each screen AND set up how many screens are enabled or not and what the policy is when a new screen is found (auto-enable, never enable, should it extend or clone etc.). Per display stuff will be integrated along the integration of conf_display. Policy stuff is already there and works for me(TM). I planned to adjust e_int_config_display so it works with CRTCs (RandR 1.2) instead of just the primary screen (RandR 1.1) as it does right now. I won't support RandR 1.1 in that dialog anymore. People whose drivers just support RandR 1.1 shall stay with the current dialog. So actually we need a new name like 'conf_display2' or rename current dialog to e_int_config_single_display and the new one e_int_config_multiple_displays it really should support the whole range - 1.1, 1.2 etc. - a user shouldnt have to switch dialogs to choose what version of a spec is supported. they have no clue which one is supported. they just want it to work. :) But randr = and 1.1 work completly different. There is not code sharing. That's why I pliedge for leaving the dialog (conf_display) as is and just pop it up instead of integrating it into an else useless dialog (conf_randr), making the code more complicated than it needs to be. I went that way before and it's double effort without any advantage. As I proposed above: if (randr 1.2) return conf_display; else return conf_randr; //with conf_display2 integrated If you can point out a good reason why to rewrite most of the old craft, I'll do it. But else I see more benefit in getting other things done. you are thinking like the programmer and not the USER. the USER doesnt know ifd their driver does 1.1 or 1.2 and they shouldnt NEED to know. it is the job of the app (e) to figure that out and present the appropriate UI for their situation AND to use the appropriate protocol. it is not the users job to try and figure out which protocol they have and then go choose the right config dialog for that protocol. it is the job of code in e to fgure that out and switch internally as appropriate and presetn at the ui level the features you can configure given that protocol version that our driver happens to do that we DISCOVEr at runtime. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] redraw problem
Em 30-07-2011 15:14, Tomas Cech escreveu: Hi, I had problems with redrawing of applications, menus, background. Sometimes application stopped redrawing after a while and just special action causing explicit redraw (desktop change, window move, ...) helps for a while. (from lspci) 00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (primary) (rev 0c) 00:02.1 Display controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (secondary) (rev 0c) (from Xorg.0.log) [99.924] (II) LoadModule: intel [99.924] (II) Loading /usr/lib64/xorg/modules/drivers/intel_drv.so [99.925] (II) Module intel: vendor=X.Org Foundation [99.925]compiled for 1.9.3, module version = 2.15.0 [99.925]Module class: X.Org Video Driver [99.925]ABI class: X.Org Video Driver, version 8.0 Workaround for the problem is to disable KMS. echo 'options i915 modeset=0' /etc/modprobe.d/i915-disable-kms.conf Maybe it will save some hours of madness. Best regards, Tomas Cech Sleep_Walker I've had some of that as well, but I thought it was my WeTab's touchscreen that was at fault. Nice catch! Rui -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] redraw problem
On Sun, Jul 31, 2011 at 02:56:41AM +0900, Carsten Haitzler wrote: On Sat, 30 Jul 2011 19:19:13 +0200 Tomas Cech tc...@suse.cz said: On Sun, Jul 31, 2011 at 01:57:22AM +0900, Carsten Haitzler wrote: On Sat, 30 Jul 2011 18:38:53 +0200 Tomas Cech tc...@suse.cz said: Hi, On Sat, Jul 30, 2011 at 05:24:33PM +0200, Cedric BAIL wrote: Hi, On Sat, Jul 30, 2011 at 4:14 PM, Tomas Cech tc...@suse.cz wrote: I had problems with redrawing of applications, menus, background. Sometimes application stopped redrawing after a while and just special action causing explicit redraw (desktop change, window move, ...) helps for a while. (from lspci) 00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (primary) (rev 0c) 00:02.1 Display controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (secondary) (rev 0c) (from Xorg.0.log) [ 99.924] (II) LoadModule: intel [ 99.924] (II) Loading /usr/lib64/xorg/modules/drivers/intel_drv.so [ 99.925] (II) Module intel: vendor=X.Org Foundation [ 99.925] compiled for 1.9.3, module version = 2.15.0 [ 99.925] Module class: X.Org Video Driver [ 99.925] ABI class: X.Org Video Driver, version 8.0 Workaround for the problem is to disable KMS. echo 'options i915 modeset=0' /etc/modprobe.d/i915-disable-kms.conf Maybe it will save some hours of madness. ^^^ This. Sounds like a bug, like many, in video driver. Did you talk to intel maintainer ? It's definitely bug. No, but I found several similar bugs on distro specific bugzillas. Bug report created for X.org here: https://bugs.freedesktop.org/show_bug.cgi?id=39695 Best regards, Tomas Cech Sleep_Walker and... what do you want us to do about it? :) Funny, I think it was you who told me that someone else was fighting with this issue. This way it will be easier to google it. If it is too off topic, my apologies :) E can;t go changing kernel module options. it is not root, nor does it even know HOW to change it as it will vary from distro to distro and user to user as to how they have config files set up. also e cant CHANGE the modules as it's already started and kernel modules are up and running and u cant unload and re-load once already in use. this is entirely out of our hands. it's not even out job to figure out what gfx card or driver you have - they all are meant to export the same api and features via x and opengl. opengl tells us what extensions are and are not supported in a generic way. Please, stop reminding me how stupid I'm that I sent it to -devel mailing list and not -users. Thank you! Best regards, Tomas Cech Sleep_Walker -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] conf_randr - A Randr dialog for e17
2011/7/30 Carsten Haitzler ras...@rasterman.com: On Sat, 30 Jul 2011 19:26:51 +0200 Leif Middelschulte leif.middelschu...@gmail.com said: 2011/7/30 Carsten Haitzler ras...@rasterman.com: On Sat, 30 Jul 2011 17:11:20 +0200 Leif Middelschulte leif.middelschu...@gmail.com said: 2011/7/30 Carsten Haitzler ras...@rasterman.com: On Fri, 29 Jul 2011 19:12:58 +0200 Leif Middelschulte leif.middelschu...@gmail.com said: why did you make it conf_randr. Because I thought maybe people don't need it all the time. Just to configure their setup once and afterwards they don't have to load it anymore. already months ago i merged config modules - it's part of conf_display - and e_int_config_display.[ch] in there. as already mentioned missing icon.png, which we dont have to worry about if you merge it in with conf_display. can you do that? :) The reason I didn't merge in conf_display in the first place was, that people might not even have multiple displays, so the entire adjustment/policy stuff is useless to them (e.g. if their drivers just supports RandR =1.1). this isn't just for multiple displays its for resolution too and just fyi.. people with laptops need this quite often. :) if its never used the code is never paged in from disk so it costs nothing (if its already part of a module loaded anyway). I know what conf_display did :-) I'll integrate its options into 'conf_randr'. But yes, I can merge in conf_display as another page in the toolbook. Though it'll have to wait a bit, until I'm finished with my next exam (end of next week). well it really should be one and the same dialog. to set up resolution and rotation for each screen AND set up how many screens are enabled or not and what the policy is when a new screen is found (auto-enable, never enable, should it extend or clone etc.). Per display stuff will be integrated along the integration of conf_display. Policy stuff is already there and works for me(TM). I planned to adjust e_int_config_display so it works with CRTCs (RandR 1.2) instead of just the primary screen (RandR 1.1) as it does right now. I won't support RandR 1.1 in that dialog anymore. People whose drivers just support RandR 1.1 shall stay with the current dialog. So actually we need a new name like 'conf_display2' or rename current dialog to e_int_config_single_display and the new one e_int_config_multiple_displays it really should support the whole range - 1.1, 1.2 etc. - a user shouldnt have to switch dialogs to choose what version of a spec is supported. they have no clue which one is supported. they just want it to work. :) But randr = and 1.1 work completly different. There is not code sharing. That's why I pliedge for leaving the dialog (conf_display) as is and just pop it up instead of integrating it into an else useless dialog (conf_randr), making the code more complicated than it needs to be. I went that way before and it's double effort without any advantage. As I proposed above: if (randr 1.2) return conf_display; else return conf_randr; //with conf_display2 integrated If you can point out a good reason why to rewrite most of the old craft, I'll do it. But else I see more benefit in getting other things done. you are thinking like the programmer and not the USER. the USER doesnt know ifd their driver does 1.1 or 1.2 and they shouldnt NEED to know. it is the job of the app (e) to figure that out and present the appropriate UI for their situation AND to use the appropriate protocol. it is not the users job to try and figure out which protocol they have and then go choose the right config dialog for that protocol. it is the job of code in e to fgure that out and switch internally as appropriate and presetn at the ui level the features you can configure given that protocol version that our driver happens to do that we DISCOVEr at runtime. Okay, I think we're arguing on different things. 1.) You're right about the dialog's behaviour. It should provide the user with a dialog resembling his driver's capabilities, no matter what they are. 2.) I tried to communicate: conf_display - conf_display1 conf_randr - conf_display //with integrated conf_display2 (for randr =1.2) and conf_display1 conf_display will then be displaying either the current dialog (if ran on randr 1.2) or the new all-in-wonder dialog if supported. Is that okay? Man, sometimes seeing people for really simplifies discussions a big deal :-/ Thanks for your interest :-) -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler) ras...@rasterman.com -- Leif -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey
Re: [E-devel] Ecore XCB
On Tue, Jul 12, 2011 at 01:10, Christopher Michael
cpmicha...@comcast.net wrote:
[…]
2) It may not build on your system (tho it builds on all boxes I have
tried so far).
It doesn't build on my boxes (gentoo and arch linux up-to-date).
I've got xcb 1.7 and it introduced a split up of xcb-util.
I've attached a patch to make ecore_xcb compatible with xcb 1.7.
I haven't committed it since it would break your setup.
--
Boris Faure
diff --git a/ecore/configure.ac b/ecore/configure.ac
index fa7ab9d..5c5ecde 100644
--- a/ecore/configure.ac
+++ b/ecore/configure.ac
@@ -784,7 +784,14 @@ if test x$want_ecore_x_xcb = xyes ; then
fi
## x11-xcb
- PKG_CHECK_MODULES(XCB, x11-xcb xcb xcb-shm xcb-icccm xcb-image xcb-keysyms,
+ PKG_CHECK_MODULES(XCB,
+x11-xcb
+xcb
+xcb-shm
+xcb-icccm = 0.3.8
+xcb-util = 0.3.8
+xcb-image
+xcb-keysyms,
[ have_ecore_x_xcb=yes
requirements_ecore_x=x11-xcb xcb xcb-shm xcb-icccm xcb-image xcb-keysyms ${requirements_ecore_x} ],
[ have_ecore_x_xcb=no ])
diff --git a/ecore/src/lib/ecore_x/xcb/ecore_xcb_error.c b/ecore/src/lib/ecore_x/xcb/ecore_xcb_error.c
index c58c13c..9f58feb 100644
--- a/ecore/src/lib/ecore_x/xcb/ecore_xcb_error.c
+++ b/ecore/src/lib/ecore_x/xcb/ecore_xcb_error.c
@@ -67,9 +67,9 @@ _ecore_xcb_error_handle(xcb_generic_error_t *err)
WRN(Got Error:);
WRN(\tEvent: %s, xcb_event_get_request_label(err-major_code));
WRN(\tError: %s, xcb_event_get_error_label(err-error_code));
- if (err-error_code == XCB_EVENT_ERROR_BAD_VALUE)
+ if (err-error_code == XCB_VALUE)
WRN(\tBad Value: %d, ((xcb_value_error_t *)err)-bad_value);
- else if (err-error_code == XCB_EVENT_ERROR_BAD_WINDOW)
+ else if (err-error_code == XCB_WINDOW)
WRN(\tBad Window: %d, ((xcb_window_error_t *)err)-bad_value);
_error_request_code = err-sequence;
diff --git a/ecore/src/lib/ecore_x/xcb/ecore_xcb_events.c b/ecore/src/lib/ecore_x/xcb/ecore_xcb_events.c
index eb2c959..8dbaade 100644
--- a/ecore/src/lib/ecore_x/xcb/ecore_xcb_events.c
+++ b/ecore/src/lib/ecore_x/xcb/ecore_xcb_events.c
@@ -240,14 +240,14 @@ _ecore_xcb_events_handle(xcb_generic_event_t *ev)
* so trap those cases and ignore. We also ignore BadValue from
* xcb_grab/ungrab_button (happens when we are using any_mod)
* and a few others */
-if (err-error_code == XCB_EVENT_ERROR_BAD_WINDOW) return;
-else if (err-error_code == XCB_EVENT_ERROR_BAD_MATCH)
+if (err-error_code == XCB_WINDOW) return;
+else if (err-error_code == XCB_MATCH)
{
if ((err-major_code == XCB_SET_INPUT_FOCUS) ||
(err-major_code == XCB_CONFIGURE_WINDOW))
return;
}
-else if (err-error_code == XCB_EVENT_ERROR_BAD_VALUE)
+else if (err-error_code == XCB_VALUE)
{
if ((err-major_code == XCB_KILL_CLIENT) ||
(err-major_code == XCB_GRAB_BUTTON) ||
@@ -1628,7 +1628,7 @@ _ecore_xcb_event_handle_client_message(xcb_generic_event_t *event)
ecore_event_add(ECORE_X_EVENT_WINDOW_STATE_REQUEST, e, NULL, NULL);
}
else if ((ev-type == ECORE_X_ATOM_WM_CHANGE_STATE)
-(ev-format == 32) (ev-data.data32[0] == XCB_WM_STATE_ICONIC))
+(ev-format == 32) (ev-data.data32[0] == XCB_ICCCM_WM_STATE_ICONIC))
{
Ecore_X_Event_Window_State_Request *e;
diff --git a/ecore/src/lib/ecore_x/xcb/ecore_xcb_icccm.c b/ecore/src/lib/ecore_x/xcb/ecore_xcb_icccm.c
index 6c86686..03dd2cb 100644
--- a/ecore/src/lib/ecore_x/xcb/ecore_xcb_icccm.c
+++ b/ecore/src/lib/ecore_x/xcb/ecore_xcb_icccm.c
@@ -161,7 +161,7 @@ EAPI char *
ecore_x_icccm_title_get(Ecore_X_Window win)
{
xcb_get_property_cookie_t cookie;
- xcb_get_text_property_reply_t prop;
+ xcb_icccm_get_text_property_reply_t prop;
uint8_t ret = 0;
char *title = NULL;
@@ -169,18 +169,18 @@ ecore_x_icccm_title_get(Ecore_X_Window win)
if (!win) return NULL;
- cookie = xcb_get_wm_name_unchecked(_ecore_xcb_conn, win);
- ret = xcb_get_wm_name_reply(_ecore_xcb_conn, cookie, prop, NULL);
+ cookie = xcb_icccm_get_wm_name_unchecked(_ecore_xcb_conn, win);
+ ret = xcb_icccm_get_wm_name_reply(_ecore_xcb_conn, cookie, prop, NULL);
if (ret == 0) return NULL;
if (prop.name_len 1)
{
-xcb_get_text_property_reply_wipe(prop);
+xcb_icccm_get_text_property_reply_wipe(prop);
return NULL;
}
if (!(title = malloc((prop.name_len + 1) * sizeof(char *
{
-xcb_get_text_property_reply_wipe(prop);
+xcb_icccm_get_text_property_reply_wipe(prop);
return NULL;
}
memcpy(title, prop.name, sizeof(char *) * prop.name_len);
@@ -210,7 +210,7 @@ ecore_x_icccm_title_get(Ecore_X_Window win)
}
}
-
[E-devel] NULL pointer dereferencing in evas' image preload
Hello all,
Apparently I'm facing a bug in evas' async image preloading mechanisms.
I can reproduce it by simply running 'shotgun' (an app many of you
already know).
Find attached a backtrace of the crash.
Shotgun works, if I disable async image preloading in evas.
If you need any further information, just let me know.
--
Leif
Starting program: /home/leif/Dokumente/source/shotgun/shotgun talk.google.com leif.middelschulte gmail.com
[Thread debugging using libthread_db enabled]
Detaching after fork from child process 25710.
Detaching after fork from child process 25711.
Detaching after fork from child process 25712.
[New Thread 0x7fffe89c9700 (LWP 25713)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffe89c9700 (LWP 25713)]
0x76af3219 in _evas_cache_image_async_heavy (data=0x13719c0)
at evas_cache_image.c:377
377 ((Evas_Image_Load_Func*) current-info.module)-threadable)
#0 0x76af3219 in _evas_cache_image_async_heavy (data=0x13719c0)
at evas_cache_image.c:377
cache = 0xf52490
current = 0x13719c0
error = 0
pchannel = 0
#1 0x76af7219 in _evas_preload_thread_worker (data=0x1370b10)
at evas_preload.c:100
pth = 0x1370b10
work = 0x143fc90
#2 0x003852607af1 in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#3 0x0038522dfb7d in clone () from /lib64/libc.so.6
No symbol table info available.
#0 0x76af3219 in _evas_cache_image_async_heavy (data=0x13719c0)
at evas_cache_image.c:377
377 ((Evas_Image_Load_Func*) current-info.module)-threadable)
$1 = (Image_Entry *) 0x13719c0
$2 = {module = 0x0, loader = 0x0}
--
Got Input? Slashdot Needs You.
Take our quick survey online. Come on, we don't ask for help often.
Plus, you'll get a chance to win $100 to spend on ThinkGeek.
http://p.sf.net/sfu/slashdot-survey___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] redraw problem
On Sat, 30 Jul 2011 20:41:15 +0200 Tomas Cech tc...@suse.cz said: E can;t go changing kernel module options. it is not root, nor does it even know HOW to change it as it will vary from distro to distro and user to user as to how they have config files set up. also e cant CHANGE the modules as it's already started and kernel modules are up and running and u cant unload and re-load once already in use. this is entirely out of our hands. it's not even out job to figure out what gfx card or driver you have - they all are meant to export the same api and features via x and opengl. opengl tells us what extensions are and are not supported in a generic way. Please, stop reminding me how stupid I'm that I sent it to -devel mailing list and not -users. (sorry i assumed since you were coming from suse and doing packages you wanted US to do fixes/workarounds of driver bugs - i.e. do what u did with an echo in code in a given situation). :) what you found is a driver bug. :) you REALLY REALLY REALLY should be filing bug reports with the driver writers. :) i'm trying to encourage you not to just mail here and have people do their own private work-arounds, or hope the developers will do in-app/evas workarounds, but make sure the actual problem is resolved at the driver level. :) if we have a bug in efl/e, i'd hope you file/report bugs with us so we fix it instead of work around them in packages+patches or other things. :) -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
