Re: [E-devel] photocam segfault
On Sat, Sep 17, 2011 at 06:06:22PM +0200, Vincent Torri wrote: hi everyone, i'm moving on on my little pdf viewer and I have a segfault bound to the photocam widget. the code is still compiled against latest svn trunk. reproducing the bug can be done this way: source code: http://www-id.imag.fr/Laboratoire/Membres/Wagner_Frederic/main.c two pdf files to open: http://www-id.imag.fr/Laboratoire/Membres/Wagner_Frederic/small.pdf http://www-id.imag.fr/Laboratoire/Membres/Wagner_Frederic/big.pdf as a dependency you need poppler-utils (pdfinfo and pdftoppm) in case it interest you, there is epdf, a lib that allow you to have an evas smart object that display a page of a pdf document hi, thanks for the hint. actually, I saw it when checkouting but the PROTO directory discouraged me from using it. anyway, i'd like to keep the dependencies low. as more info for my bug, I managed to avoid the segfault flusing the cache by using evas_render_idle_flush(evas_object_evas_get(photocam)); it doesn't segfault anymore but the image displayed is not correct Fred two scenarios: 1) open small.pdf zoom in open big.pdf - you can only see a subpart of big.pdf with size equal to size of small.pdf 2) open big.pdf zoom out open small.pdf - segfault here is gdb output: Program received signal SIGSEGV, Segmentation fault. evas_image_load_file_data_jpeg_internal (ie=0x87b1d0, map=0x7194c000, size=36281, error=0x7fffdc6c) at evas_image_load_jpeg.c:658 658 *ptr2 = ARGB_JOIN(0xff, ptr[0], ptr[1], ptr[2]); with the following stack trace: #0 evas_image_load_file_data_jpeg_internal (ie=0x87b1d0, map=0x7194c000, size=36281, error=0x7fffdc6c) at evas_image_load_jpeg.c:658 #1 0x714fbf1e in evas_image_load_file_data_jpeg (ie=0x87b1d0, file=optimized out, key=optimized out, error=0x7fffdc6c) at evas_image_load_jpeg.c:903 #2 0x7784f0fb in evas_common_load_rgba_image_data_from_file ( ie=0x87b1d0) at evas_image_load.c:338 #3 0x77827e87 in evas_cache_image_load_data (im=0x87b1d0) at evas_cache_image.c:1197 #4 0x778515ab in evas_common_rgba_image_scalecache_do ( ie=0x87b1d0, dst=0x7fffe8006750, dc=0x63f250, smooth=optimized out, src_region_x=0, src_region_y=0, src_region_w=512, src_region_h=512, dst_region_x=874, dst_region_y=213, dst_region_w=184, dst_region_h=184) at evas_image_scalecache.c:799 #5 0x71f887ad in eng_image_draw (data=optimized out, context=0x63f250, surface=0x7fffe8006750, image=0x87b1d0, src_x=0, src_y=0, src_w=512, src_h=512, dst_x=874, dst_y=213, dst_w=184, dst_h=184, smooth=0) at evas_engine.c:544 #6 0x777e2bab in evas_object_image_render (obj=0x7170a150, output=0x62f4c0, context=0x63f250, surface=0x7fffe8006750, x=0, y=0) at evas_object_image.c:2898 #7 0x7781c508 in evas_render_mapped (e=0x632fd0, obj=0x7170a150, context=0x63f250, surface=0x7fffe8006750, off_x=0, off_y=0, mapped=0, ecx=0, ecy=0, ecw=1920, ech=1118) at evas_render.c:1062 #8 0x7781efb6 in evas_render_updates_internal (e=0x632fd0, make_updates=1 '\001', do_draw=1 '\001') at evas_render.c:1378 #9 0x76717054 in _ecore_evas_x_render (ee=0x633b30) at ecore_evas_x.c:397 #10 0x767143c1 in _ecore_evas_idle_enter (data=optimized out) at ecore_evas.c:51 #11 0x7693065e in _ecore_call_task_cb (data=optimized out, func=optimized out) at ecore_private.h:246 #12 _ecore_idle_enterer_call () at ecore_idle_enterer.c:165 #13 0x76931cfb in _ecore_main_loop_iterate_internal (once_only=0) at ecore_main.c:1718 #14 0x7693233f in ecore_main_loop_begin () at ecore_main.c:861 #15 0x004022bf in elm_main (argc=optimized out, argv=optimized out) at main.c:288 #16 0x7744eead in __libc_start_main () from /lib/x86_64-linux-gnu/libc.so.6 #17 0x00401759 in _start () I also tried a quick run of valgrind but he seems to complain about other kind of problems. am I doing something wrong here ? I tried to invalidate the caches with elm_all_flush but it didn't change anything. Fred -- Frederic WAGNER Assistant professor ENSIMAG - INPG Laboratoire d'Informatique de Grenoble - MOAIS team http://www-id.imag.fr/Laboratoire/Membres/Wagner_Frederic/perso.html -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA http://p.sf.net/sfu/rim-devcon-copy2 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] pulseaudio in e17
Hi all, Finally had time to check the pulseaudio mixer in E17 and while it work, I do have some concerns regarding things below: - talking bare metal PA protocol is cumbersome, DBus API is the way to go according to developers; - sticking (id + 1) to address cards and channels, while the actual string name could be used (cosmetic, but would help debug); - not using the generic properties like device.class (to filter) and device.description (to provide human-readable name); - not providing source handling and thus no way to control microphone; - pulse code was mixed into e_mod*.c, something I'd like to avoid. Yes, what I did before was a compile-time module, thus symbols had to be defined in the correct module. But it's easy to change to a struct with defined pointers... e_mixer_pulse_setup() and e_mixer_default_setup() are cumbersome and will get ugly if we need to add a 3rd system :-( I've hacked a quick python-dbus test (attached) to show how it could be done with DBus, it does cover all our cases and if done properly will even create/remove elements on the fly given PA changes. What I noticed is that some changes to the internal sys_* API must be changed: - create sys_common.c to implement e_mixer_system* functions calling plugins (alsa, dummy, pulse) - replace detection of capture mode from channel and create 3 specific lists to be used by the app_mixer (dialog) * sources (capture channel) * sinks (output channel) * users (or applications?) - replace hard coded 2-volume (left, right) with a list of values and given names. However seems that PA will handle a single volume value, applying to all the same. No idea how useful will be to open a 5.1 video in VLC and have 6 sliders to show in E17. With these in place is easier to add a simpler PA and keep the same infra. I'd use DBus here, but there is no issue to use current bare metal code... just more work (now and in the long term). If people agree I can try to do these sys_* API changes soon and help with the dbus api. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 #!/usr/bin/env python import dbus import os import sys if -h in sys.argv or --help in sys.argv: print Usage: print \t%s dbus-device-path property value1 valueN % sys.argv[0] print very raw way to change values -- not user friendly. Caveats: \t- must provide full dbus object path for an org.PulseAudio.Core1.Device \t compatible interface (sinks or sources) \t- just Mute and Volume properties are supported \t- volume must be set in absolute number and for every channel Examples: \tSet volume of a 2-channel source (microphone): \t\tdbus-device-path: /org/pulseaudio/core1/source2 \t\tproperty: Volume \t\tvalues: 65536 65536 \tMute an output (sink) \t\tdbus-device-path: /org/pulseaudio/core1/sink0 \t\tproperty: Mute \t\tvalues: 1 raise SystemExit() try: conf_path = sys.argv[1] conf_prop = sys.argv[2] conf_values = sys.argv[3:] if conf_prop not in (Mute, Volume): raise SystemExit(Unsupported property: %s % conf_prop) except IndexError: conf_path = conf_prop = conf_values = None def connect(): if 'PULSE_DBUS_SERVER' in os.environ: address = os.environ['PULSE_DBUS_SERVER'] else: bus = dbus.SessionBus() server_lookup = bus.get_object(org.PulseAudio1, /org/pulseaudio/server_lookup1) address = server_lookup.Get(org.PulseAudio.ServerLookup1, Address, dbus_interface=org.freedesktop.DBus.Properties) return dbus.connection.Connection(address), address conn, address = connect() core = conn.get_object(object_path=/org/pulseaudio/core1) print Successfully connected to %s (%s) % (core.Get(org.PulseAudio.Core1, Name, dbus_interface=org.freedesktop.DBus.Properties), address) if conf_path and conf_prop and conf_values: o = conn.get_object(object_path=conf_path) iface = org.PulseAudio.Core1.Device old_vals = o.Get(iface, conf_prop) if isinstance(old_vals, dbus.Array): vals = dbus.Array([y.__class__(int(x)) for x, y in zip(conf_values, old_vals)], signature=old_vals.signature, variant_level=old_vals.variant_level) else: vals = old_vals.__class__(int(conf_values[0]), variant_level=old_vals.variant_level) o.Set(iface, conf_prop, vals) def print_props(o, iface, props): def prop(name): try: return o.Get(iface, name) except dbus.exceptions.DBusException: return None print %s: % (o.object_path,) for p in props: val = prop(p) if isinstance(val, dbus.Array): x = [] for e in val: x.append(str(e)) val = , .join(x) print \t%s: %s % (p, val) d = prop(PropertyList) if d:
Re: [E-devel] pulseaudio in e17
On Sun, 25 Sep 2011 04:14:55 -0300 Gustavo Sverzut Barbieri barbi...@profusion.mobi said: going to have to kill off your dbus idea. reality is the pa dbus api is experimental (testing branch). i'm staring here at ubuntu 11.04 - no pulseaudio dbus service. as jeff said: jeffdameth1 k-s: i heard the dbus interface is in a testing branch that will be merged with pulseadio 1.0. so this will take some time until adopted so... the only way to make it work is via the internal protocol - bare metal. unless you want to wait 2 years for it to stabilize, be adopted, released and actually on most peoples distributions. :) hands up those people who really desire to delay e17 release until then? :) yes the mapping of pa channels to the mixxer channels was cumbersome. i fixed it up to work and thus the id + 1 thnig so null (id 0) channels dont break stuff. as such the mixer infra doesn't quite cover everything pulse does, so really u'd need an alternate ui and infra setup. you can share the same gagdte and popup slider, but the rest would need to be different. Hi all, Finally had time to check the pulseaudio mixer in E17 and while it work, I do have some concerns regarding things below: - talking bare metal PA protocol is cumbersome, DBus API is the way to go according to developers; - sticking (id + 1) to address cards and channels, while the actual string name could be used (cosmetic, but would help debug); - not using the generic properties like device.class (to filter) and device.description (to provide human-readable name); - not providing source handling and thus no way to control microphone; - pulse code was mixed into e_mod*.c, something I'd like to avoid. Yes, what I did before was a compile-time module, thus symbols had to be defined in the correct module. But it's easy to change to a struct with defined pointers... e_mixer_pulse_setup() and e_mixer_default_setup() are cumbersome and will get ugly if we need to add a 3rd system :-( I've hacked a quick python-dbus test (attached) to show how it could be done with DBus, it does cover all our cases and if done properly will even create/remove elements on the fly given PA changes. What I noticed is that some changes to the internal sys_* API must be changed: - create sys_common.c to implement e_mixer_system* functions calling plugins (alsa, dummy, pulse) - replace detection of capture mode from channel and create 3 specific lists to be used by the app_mixer (dialog) * sources (capture channel) * sinks (output channel) * users (or applications?) - replace hard coded 2-volume (left, right) with a list of values and given names. However seems that PA will handle a single volume value, applying to all the same. No idea how useful will be to open a 5.1 video in VLC and have 6 sliders to show in E17. With these in place is easier to add a simpler PA and keep the same infra. I'd use DBus here, but there is no issue to use current bare metal code... just more work (now and in the long term). If people agree I can try to do these sys_* API changes soon and help with the dbus api. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Patch] edje_cc : group_inherit feature
Hi Jaehwan, 2011/9/24 Jaehwan Kim jae.hwan@samsung.com: 7. Do not increase the size of runtime structure, especially Edje_Part and also Edje_program as much as possible. The reorder is maybe doable when you find the keyword, that would avoid completly the reorder structure inside Edje_Part. If I increase the size of runtime structure, previously built edj files may have a problem. You concerned about it, right? I didn't think about that. then how can I change the code? Do you have any idea? I saw the code you change in 62086. Should I change like that? The issue is that with your change, we now have pointer that are not used at runtime, but are allocated. This is a waste of memory in my opinion. It will not break previous edje file, thanks to eet, but still that's not a good thing in my opinion. Maybe instead of adding this structure, you could try to put the part/program at the right place when you find the keyword that tell you where to put it. As for can_override, I think it should be part of a more generic infrastructure to detect when setting a value override an existing property. So lets forget about that one for the moment. You don't need to change the way you handle it in your patch. When we improve edje error, we could improve that at that time. I separated the structure of reorder from Edje_Part. And after reordering, the structure is deleted. Becuase Edje_Part just has the reorder pointer, I think there isn't the waste of the memory. Please check attached patch file. This change sounds good to me, just one question why didn't you put the can_override member inside the reorder member ? can_override is not related to reorder feature. So I think it is not proper. And can_override is in three structure but reorder is just in _Edje_Part structure. I think it's not proper in unity aspect, too. Yes, but can_override is a data only used by edje_cc. So puting it in Edje_Part make it increase the size of Edje at runtime. In fact, in my opinion, it would make sense to create an Edje_Part_Parser or something like that, that would hold this can_override and the reorder field to. And could you please split your patch in two part, one with just the change to use current_part and another with the inherit change. I will upload again ,after split the patch code. I will look at them. Thanks, -- Cedric BAIL -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
